Supervan Posted July 29, 2014 Share Posted July 29, 2014 Hi,This escape function will only block quotesHow would you stop java script insertion? function escape($string) { return htmlentities($string, ENT_QUOTES, 'UTF-8'); } Thanks Quote Link to comment Share on other sites More sharing options...
ginerjm Posted July 29, 2014 Share Posted July 29, 2014 htmlspecialchars? Quote Link to comment Share on other sites More sharing options...
Jacques1 Posted July 29, 2014 Share Posted July 29, 2014 This escape function will only block quotes No, it doesn't. It escapes “<”, “>”, “&”, single and double quotes and a whole lot of harmless characters. If you need anything else, you're doing it wrong. Are you trying to insert user input into an existing script element? This is simply wrong and mustn't be done at all. Quote Link to comment Share on other sites More sharing options...
Supervan Posted July 30, 2014 Author Share Posted July 30, 2014 No, it doesn't. It escapes “<”, “>”, “&”, single and double quotes and a whole lot of harmless characters. If you need anything else, you're doing it wrong. Are you trying to insert user input into an existing script element? This is simply wrong and mustn't be done at all. Hi Im trying to sanitize user input, i bit corncerned about java script insertion. Using pdo and prepared queries. Thanks Quote Link to comment Share on other sites More sharing options...
Jacques1 Posted July 30, 2014 Share Posted July 30, 2014 It's still not clear what you want. What does JavaScript insertion have to do with database queries? If you want to somehow magically “clean” the user input before you store it in the database, this is neither possible nor sensible. Cross-site scripting is an output problem, not an input problem. You leave the input as is when you store it in the database. But when you output the data, you escape it for the specific context. As a concrete example: Let's say you have a form on your site where people can enter an arbitrary comment. When you store the comment, you don't do anything with it. No escaping, no “sanitizing” (whatever that means). You just store the raw text. But when you put this comment into your HTML page, you escape it for the specific target context. For example, if the comment is supposed to go into a simple HTML element like div or p, you need htmlspecialchars(). It's very important to understand that escaping is done when you use the data, not when you receive or store it. You should avoid terms like “sanitizing”, because they carry the idea that you could just take the input, apply some magical cleaning function and then safely use the result in any context. This is wrong. Quote Link to comment Share on other sites More sharing options...
Supervan Posted July 30, 2014 Author Share Posted July 30, 2014 It's still not clear what you want. What does JavaScript insertion have to do with database queries? If you want to somehow magically “clean” the user input before you store it in the database, this is neither possible nor sensible. Cross-site scripting is an output problem, not an input problem. You leave the input as is when you store it in the database. But when you output the data, you escape it for the specific context. As a concrete example: Let's say you have a form on your site where people can enter an arbitrary comment. When you store the comment, you don't do anything with it. No escaping, no “sanitizing” (whatever that means). You just store the raw text. But when you put this comment into your HTML page, you escape it for the specific target context. For example, if the comment is supposed to go into a simple HTML element like div or p, you need htmlspecialchars(). It's very important to understand that escaping is done when you use the data, not when you receive or store it. You should avoid terms like “sanitizing”, because they carry the idea that you could just take the input, apply some magical cleaning function and then safely use the result in any context. This is wrong. Ok, how would I protect my site's output from Cross-site scripting? Some example code would be appreciated. Quote Link to comment Share on other sites More sharing options...
ginerjm Posted July 30, 2014 Share Posted July 30, 2014 See my first post? Quote Link to comment Share on other sites More sharing options...
Jacques1 Posted July 30, 2014 Share Posted July 30, 2014 <?php function html_escape($input, $encoding) { return htmlspecialchars($input, ENT_QUOTES, $encoding); } ?> <!DOCTYPE HTML> <html lang="en"> <head> <meta charset="utf-8"> <title>Escaping test</title> </head> <body> <?php if ($_SERVER['REQUEST_METHOD'] == 'POST'): ?> <h1>The escaped output</h1> <p> <?= html_escape($_POST['markup'], 'UTF-8'); ?> </p> <?php else: ?> <h1>The input</h1> <form method="post"> <label for="some_text">Enter some HTML markup:</label> <textarea id="markup" name="markup"></textarea> <input type="submit"> </form> <?php endif; ?> </body> </html> 1 Quote Link to comment Share on other sites More sharing options...
Psycho Posted July 30, 2014 Share Posted July 30, 2014 You leave the input as is when you store it in the database. But when you output the data, you escape it for the specific context. Agreed. Some other comments/considerations: Manipulating the user input without their knowledge is generally a bad idea because the result may be something very different than they intended. I've seen situations where code would parse out characters which someone felt should not belong in an input - e.g. removing special characters from a person's name. They could forget to not remove dashes (hyphenated names), apostrophes, or even accented characters. Even if you managed to keep all those I have no clue if there are other characters that may be used in other dialects. As stated above, escaping before storing is a bad approach. You may only be planning to use the value in an HTML output now, but what if you need it for something else in the future? For example, let's say you need a plain-text output or to send the data in a JSON format for a service? You would not want all the characters translated into their HTML entities. And, even though there is a function to reverse HTML entities you cannot guarantee you will get the same original content. Making the conversion when you store the data seems to have the advantage of a one and done approach. I.e. you don't have to worry when writing any output code to escape it correctly. But, that is a lazy approach that will come back to haunt you at some time. Quote Link to comment Share on other sites More sharing options...
Supervan Posted July 30, 2014 Author Share Posted July 30, 2014 Thank you all, greate help. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.