Cross-site scripting Attack Help

[anups]

Hi I need to test for XSS attack and aim is to break my own site.

 

I am using strip_tags to strip all the HTML and tags.

 

Is there any way for successful XSS  attack even if strip_tags is used.

 

 

[creata.physics]

http://php.net/manual/en/function.mysql-real-escape-string.php

http://php.net/manual/en/function.htmlspecialchars.php

 

Will be some of your best options to safely protect your site against xss attacks. You'll eventually want to sanitize all $_REQUEST data to prevent from xss and sql injection.

[AyKay47]

To expand this a little further, the basic logic is to escape all user data before inserting into a db using your RDBMS escape string function, and to use htmlentities() upon grabbing data from a db. This converts things like quotes etc into their HTML entities before being executed. IMO, the safest way to work with databases is to use PDO, which separates the SQL and the user data.

[Drongo_III]

Sorry to jump in on this one. But on the subject of PDO - is it right that it automatically escapes all your data so you don't need to mysql_real_escape_string ?

 

To expand this a little further, the basic logic is to escape all user data before inserting into a db using your RDBMS escape string function, and to use htmlentities() upon grabbing data from a db. This converts things like quotes etc into their HTML entities before being executed. IMO, the safest way to work with databases is to use PDO, which separates the SQL and the user data.

[AyKay47]

Sorry to jump in on this one. But on the subject of PDO - is it right that it automatically escapes all your data so you don't need to mysql_real_escape_string ?

 

To expand this a little further, the basic logic is to escape all user data before inserting into a db using your RDBMS escape string function, and to use htmlentities() upon grabbing data from a db. This converts things like quotes etc into their HTML entities before being executed. IMO, the safest way to work with databases is to use PDO, which separates the SQL and the user data.

 

no, it executes the SQL and the PHP data separately, so escaping isn't an issue.

If you need a further explanation, read here

[Drongo_III]

Please tell me to get out of this thread if it seems like i am hijacking it. Just trying to undertand PDO a better.

 

I read your link but I'm slightly confused about the quote below (taken from the pdo php manual page):

 

 

The parameters to prepared statements don't need to be quoted; the driver automatically handles this. If an application exclusively uses prepared statements, the developer can be sure that no SQL injection will occur (however, if other portions of the query are being built up with unescaped input, SQL injection is still possible).

 

I might be being slow in interpreting this but in one part of that explanation it says PDO guards against sql injectionss and you don't need to escape the data. But then it says "(however, if other portions of the query are being built up with unescaped input, SQL injection is still possible)".

 

So is this saying if you use a combination of mysql_query and PDO you're open to attack (which would seem reasonable)?

 

Or is it saying that when you're building the query you still need to escape the data you use in your parameters?

 

I don't quite understand this and would very much like to ensure i'm adopting the best practice...

 

 

Sorry to jump in on this one. But on the subject of PDO - is it right that it automatically escapes all your data so you don't need to mysql_real_escape_string ?

 

To expand this a little further, the basic logic is to escape all user data before inserting into a db using your RDBMS escape string function, and to use htmlentities() upon grabbing data from a db. This converts things like quotes etc into their HTML entities before being executed. IMO, the safest way to work with databases is to use PDO, which separates the SQL and the user data.

 

no, it executes the SQL and the PHP data separately, so escaping isn't an issue.

If you need a further explanation, read here

[AyKay47]

If the SQL is a static string that has absolutely no user data effecting it at all, then SQL injection is not possible.

Say that you are building a query to use in PDO, but you are using a variable to determine which table to select from, and that variable comes from user data. This means that if you do not escape this user data, then the SQL query can be polluted and SQL injection is still possible even though you are using PDO.

If the SQL query is clean, then you are good to go.

[Drongo_III]

Aha! Thank you Akay I understand it now

 

If the SQL is a static string that has absolutely no user data effecting it at all, then SQL injection is not possible.

Say that you are building a query to use in PDO, but you are using a variable to determine which table to select from, and that variable comes from user data. This means that if you do not escape this user data, then the SQL query can be polluted and SQL injection is still possible even though you are using PDO.

If the SQL query is clean, then you are good to go.