Anti-XSS script does not work, or is there a better method? [closed]

Question

Closed. This question needs details or clarity. It is not currently accepting answers.

---

Want to improve this question? Add details and clarify the problem by editing this post.

Closed 9 years ago.

Improve this question

I've been struggling with a certain script, its a function combination of 3 functions used in PHP to "clean" or " scrub" inputs in forms from special characters, white spaces and slashes/backslashes.

Problem is, it doesnt seem to work, which is really weird, since I reviewed the PHP official page about it, W3schools, and stack overflow, and didn't come up with an answer to why it might not work, since I THINK I have the right format for the functions.

but i could be mistaken, i am a young student without much knowledge after all.

here's the function I talked about:

<?php       
    $data = clean_data('d/ in\ g<script>e %&*$^s #% ');

    function clean_data($data) {
        $data = trim($data);
        $data = stripslashes($data);
        $data = htmlspecialchars($data);
    return $data;
    }
    echo $data;
?>

the random stuff inside of the ' symbols on the second line is the input (same result when i use it with my form), its to test, of course, in reality, there would be the $_POST function, getting the data from the form, and put it in another variable (called differently then $data).

I would be thankful if someone can point me into the right direction :)

EDIT: THanks to some very usefull comments, i learned what certain functions in my script really do, and after gettig pointed out that the script somehow works for everybody else except me, leaves me mistefied, so if anyone else has a suggestion if there is a better way to "prevent", or atleast minimize XSS attacks by implenting security in my PHP script (sanitizing entities for example), that would be appriciated

Answer 1

If you are going to this much effort... you are doing it wrong.

Here are a few contexts where user input must be handled with care, and the correct way to handle them:

1. HTML. Anything the user inputs that is sent to the browser is interpreted by said browser as HTML. As such, care must be taken to prevent users from injecting code of their choice. Luckily, it's quite simple. htmlspecialchars will escape all the necessary characters to ensure that whatever the user typed is what they get back.¹

2. JavaScript. Sometimes you may need to drop a variable from PHP into JavaScript. Whether or not it contains user input, you must be careful that you generate valid JavaScript. Luckily, json_encode is practically designed for that. Give it a variable and it will output it in a way that JavaScript will understand flawlessly. Strings will have quotes added and characters within will be suitably escaped.

3. MySQL. Perhaps the most argued over, and yet the easiest one to get right! If (and only if) you are stuck maintaining ancient code, you can use mysql_real_escape_string to sanitise your input and prevent SQL injection, but really you should be using PDO's prepared statements feature. Like json_encode above, prepared statements just take a variable and do all the hard work for you!

4. PHP. Just... don't use eval with user input. Ever. Okay?

5. Bash/Shell. Use of shell_exec and related functions with user input is rare, but just in case you happen to need it, be sure to always wrap arguments in escapeshellarg. This, again, handles automatic quoting of strings and escaping of dangerous characters.

Overall, there are built-in, simple ways to do things based on the context you are in. There is no catch-all solution because the contexts are all different with their different rules. Restricting what a user can type in is bad, especially when it's so easy to allow arbitrary input in a safe manner.

^{1: Spaces will still be collapsed, just like if you type several spaces in the source code. This can be left as desired behaviour, or fixed with the CSS white-space: pre-wrap;. Consider also word-wrap: break-word; to ensure that people don't enter stupidly long words to break your layout.}