31–38 of 38 posts
This seems like a total non-issue. Just CORRECTLY sanitize everything going into the database! By the way, just to let everyone know also. You should also sanitize form submissions.
Earlier quoted context omitted.
I put that in as a joke years ago. I can't believe it's still there.
I've tried to write a program ( https://gist.github.com/392445 ) which would be affected by this. It seems it should be `'); DROP TABLE servertypes; --` to actually drop any tables. All I was able to get now is syntax error.
Earlier quoted context omitted.
I've tried to write a program ( https://gist.github.com/392445 ) which would be affected by this. It seems it should be `'); DROP TABLE servertypes; --` to actually drop any tables. All I was able to get now is syntax error.
I had the same idea: https://gist.github.com/913402
If using PHP, use PDO and always use parameters. Use HTMLPurifier to avoid xss. You still need to be careful if building queries dynamically, such as dynamic WHERE or ORDER by clauses.
I'd take that one step further and use an ORM like Doctrine, because otherwise doing trivial stuff is completely annoying. If you don't use an ORM package you quickly start writing your own ORM anyway.
If using PHP, use PDO and always use parameters. Use HTMLPurifier to avoid xss. You still need to be careful if building queries dynamically, such as dynamic WHERE or ORDER by clauses.
HTMLPurifier? That thing should only be used if you are accepting html as input (eg: wysiwyg). Just escape everything in the view layer (not in the DBAL. There you only escape to avoid sql injection, not XSS!)
your db should never contain xss material. some jackass will forget to escape it on display.
Earlier quoted context omitted.
HTMLPurifier? That thing should only be used if you are accepting html as input (eg: wysiwyg). Just escape everything in the view layer (not in the DBAL. There you only escape to avoid sql injection, not XSS!)
what if someone puts html in a plain old text field? your db should never contain xss material. some jackass will forget to escape it on display.
Earlier quoted context omitted.
what if someone puts html in a plain old text field? your db should never contain xss material. some jackass will forget to escape it on display.
The thing is, you can't just 'escape XSS'. You need to know exactly where the data is going to be used, and you can't know that when you store it (in fact, you could use the same data in many different places). There are infinite ways of doing XSS, so if you don't escape properly, you are still vulnerable. The view layer should escape everything by default. Then if you need a different filter, or disable escaping (fo…