How to prevent against XSS and SQL injection [duplicate]

问题

i want to check my data from the user for XSS and SQL injection and this is how i tried

if (isset($_GET['membernumber'])) 
{
    $mem = htmlentities($_GET['membernumber']);
    $memberparamter = cleanData($mem);

}

But which method is the best/correct way to check?

Method 1

function cleanData($data)
    {
        $data=mysql_real_escape_string($data);
        $data=trim($data);
        $data=stripcslashes($data);
        $data=htmlspecialchars($data);
        $data=strip_tags($data);
        return $data;
    }

Method 2

function cleanData($data)
    {
        $data=mysql_real_escape_string($data);
        $data=trim($data);
        $data=strip_tags($data);
        return $data;
    }

Method3

htmlspecialchars(stripcslashes(trim($data)))

回答1:

As mentioned, prepared statements are one of the best ways to prevent SQL injections. i.e., you shouldn't add your parameters as part of the final query string. You should use parameter placeholders, and add the parameters via a key/value array.

If you're using PDO, have a look at this page, which describes prepared statements in greater detail:

http://php.net/manual/en/pdo.prepared-statements.php

A quite thorough explanation of PHP's input filters (and a good article on sanitization) can be found here:

http://coding.smashingmagazine.com/2011/01/11/keeping-web-users-safe-by-sanitizing-input-data/

Check here for PHP's own filters/sanitization functions:

http://www.php.net/manual/en/filter.filters.php

You are probably interested in the filter_var and filter_input functions:

http://www.php.net/manual/en/function.filter-var.php
http://www.php.net/manual/en/function.filter-input.php

Also, this question has some good pointers: What's the best method for sanitizing user input with PHP?

This question has very good pointers too: What are the best PHP input sanitizing functions?

回答2:

If you want to prevent SQL injection attacks use prepared statements. When you do something like

SELECT * FROM TABLE WHERE id = $_GET['x']

The problem with this query is the variable is considered a part of the SQL statement. What that means is the DBMS will parse/compile and execute the variable along with the remainder of the query. So effectively, I could provide something like

$x = "1); DROP TABLE users;"

and since its a part of the statement the server will execute that command.

When you introduce prepared statements, the variable scope will be limited to the scope of a parameter and will have no effect on the remainder of the query even if it is not escaped. That is because the SQL statement is parsed/optmised/compiled etc by the database and all you have to do is bind the parameters. The sql statement is a template.

SELECT * FROM TABLE WHERE id = ?

The added advantage of using prepared statements is speed. Since the template is already parsed/compiled etc the database will not need to repeat that process and therefore it can be reused, all you have to do is replace the parameters.

In PHP both PDO and mysqli_* functions support prepared statements.

For mysqli see http://php.net/manual/en/mysqli.prepare.php For PDO see http://php.net/manual/en/pdo.prepare.php

As for XSS attacks, you can take a few approaches with this. The first is to simply escape ANY user input when bring printed onto a page. So dangerous chars like:

 <>"" // and so on

Will be replaced with their html entity equivalent. So in the case of <script>, it will be converted to <script>.

You can also setup a whitelist approach, whereby you only allow X tags for user input. This is especially useful for content orientated sites where users might need access to certain html tags like divs, p tags and so on but not script tags for example. Any tags not within the whitelist will be filtered out. This is quite difficult to fully cover since there are so many ways of doing things, but nonetheless it can provide added security. See http://php.net/manual/en/function.filter-var.php for more.

The third approach is to substitute the html tags with custom tags (like SO does). So a star infront of a word might represent the <strong> html tag and so on.

Please note, if you do take up the latter two that you should STILL escape the data. All user input data should be consider potentially dangerous even if filtered because as they say, there is always more than one way to skin a cat.