6 ms·
*NEVER* sanitize your inputs
- nraynaud 13y agoWell in HTML you can use a sandboxed iframe (or <webview> in technologies that have it), but it's not cheap.
- tokenizerrr 13y agoI just remembered visiting a website that used iframe's with script tags disabled for users their signatures. It was a pretty interesting approach.
- ceejayoz 13y agoI just hope they used a proper lib like Purifier to do it, or someone's going to have fun with `onmouseover`.
- nraynaud 13y agoI think that when it's sandboxed with the proper attributes, you can't do anything appart from trashing the content of the frame.
- ceejayoz 13y agoI had no clue that was so widely supported. No IE8/9 but virtually everything else. Neato! http://caniuse.com/#feat=iframe-sandbox http://caniuse.com/#feat=iframe-sandbox
- bevacqua 13y agoThis is terribly confusing advice: "NEVER sanitize your inputs!". He means: "just don't call it sanitizing".
- king_magic 13y ago"But that's what we mean by "sanitize"! Then you should stop calling it that." Ugh, eyeroll. Seriously, let's waste time arguing over what to call security vulnerabilities & ways to address them - instead of using consistent terminology that security-minded developers instantly recognize. To quote the hilarious Mean Girls - "stop trying to make fetch happen".
- billpg 13y agoOkay, let's keep advising people to "sanitize" inputs. Even though its confusing and there's another word that isn't confusing. Because reasons.
- awda 13y agoThere is no other word that isn't confusing. If you refuse to actually do some cursory research into something before implementing it, you're going to get the stupid delete-is-sanitization stuff the author describes. "Doctor, it hurts when I do this." Don't do that!
- mfisher87 13y agoExcept it looks like everyone's confused and there's a lot of misinformation or high signal-to-noise ratio already. My google search "Input sanitization" yielded these first 2 results http://en.wikipedia.org/wiki/Secure_input_and_output_handling http://en.wikipedia.org/wiki/Secure_input_and_output_handlin... 2nd page (or more with a lesser screen), under "other solutions," this is the only line about parameterization: "In particular, to prevent SQL injection, parameterized queries (also known as prepared statements and bind variables) are excellent for improving security while also improving code clarity and performance." Everything else is about filtering, blacklisting, whitelisting, escaping. http://www.esecurityplanet.com/browser-security/prevent-web-attacks-using-input-sanitization.html http://www.esecurityplanet.com/browser-security/prevent-web-... Discusses filtering as solution to HTML injection. Lastly discusses SQL injection, first recommending mysql_real_escape_string(), then in the second paragraph linking to another article about parameterization. It's not, to an inexperienced developer (this is the web remember?), a clear-cut best practice from just "cursory research". It's a popular tech joke with obvious but non-optimal solutions.
- TomGullen 13y agoFalse surely, as another poster commented you want to sanitise inputs for example for user signatures to remove Javascript and other nasties. Sanitising inputs isn't just about protecting against SQL injections. What the author actually means is the removal of apostraphes to prevent SQL injections can affect your data integrity, so paramatise your queries. Alternatively replace single apostraphes with double apostraphes in your queries also works, but paramatising queries is a much better practise to get into.
- IgorPartola 13y agoNo, TFA is right. If the user wants to post <script>alert("I am a hacker.")</script>, so be it. Display it literally. You do have to take care to escape it when you are rendering your HTML. But guess what? You have to anyways since <script> is not the only evil tag out there. XSS can be performed a number of ways and you are not going to catch them all by removing stuff from user input.
- blincoln 13y agoNo. What you are describing is a way of doing things that inherently leads to security vulnerabilities, because it depends on someone else remembering to include something in their code, and people will always forget to do the right thing at least some of the time. Developers should never allow input into the system that doesn't match their expectations about what is valid for that value/field/etc. If you have a user text input that only requires alphanumeric characters, space, period, and comma, then strip out any character which is not one of those things. That field is now no longer a possible source of XSS.
- zAy0LfpBZLC8mAC 13y agoBut instead you are randomly changing information, which is a terrible idea. If you get invalid input, you have to reject it, not just silently make it fit by changing the input (the only exception is when you can be sure that changing the data will not under any circumstances change its meaning).
- 13y ago
- gizmogwai 13y agoThis whole post is ridiculous. The problem he poorly tries to described has been solved by mathematicians a few millenniums ago. In a single word: CONTEXT. A word is nothing if not bound by a context. Developers have already developed part of this context. Design patterns names are an example of those words defined within the context. Sanitizing input is just another.
- billpg 13y agoPut yourself in the shoes of an inexperienced programmer building their first website. You've been advised to sanitize your inputs with the example of Bobby Tables. You know the plain English meaning of "Sanitize". Clearly, you need to remove those single quote characters as they are unsanitary?
- gizmogwai 13y agoPut yourself in the shoes of an inexperienced mathematician solving its first theorem. You've been advised to take care of infinity as described with two parallels crossing at infinity. Problem, your theorem is dealing with discrete numerable infinity... On the side note, English meaning of Sanitize is "Make clean and hygienic", nothing more. It says nothing about "removing". Other definitions are extensions based on CONTEXT, once again.
- zAy0LfpBZLC8mAC 13y ago... which is exactly what you should not do. Here, let me post this: "If you want to create a horizontal line in HTML, you write <hr>" See that? There is nothing "unclean" about it, hence you should not "clean" it. You just have to encode it if you output it embedded in HTML. That's why calling it "sanitizing" is misleading.
- gizmogwai 13y agoAgain, wrong. Encoding without proper context means "convert in a coded form". Hum that's not exactly what we want. So, let's add the "computing context", now we have, as an example, the ability to encode a WAVE file into a MP3. But wait, we lost information here! Bummer... Sanitization in the context of computing does not specifically means that you have to "encode", or better, "transcode". It means that you have to take appropriate measure so that your input DATA cannot be interpreted as CODE by the receiver. Bonus point is taken if the measure you choose is lossless in term of information carried by your data.
- IgorPartola 13y agoA somewhat related term, I really like "mogrify": http://initd.org/psycopg/docs/cursor.html#cursor.mogrify http://initd.org/psycopg/docs/cursor.html#cursor.mogrify
- rhizome31 13y agoI've been wondering where this word comes from. The only other occurrence I know of is the ImageMagick command of the same name. It doesn't seem to be a real English word. What does it evoke to a native English speaker? (ESL here)
- hyborg787 13y agoIt's short for transmogrify: http://www.merriam-webster.com/dictionary/transmogrify http://www.merriam-webster.com/dictionary/transmogrify Calvin & Hobbes may have played a part in popularizing the term? http://calvinandhobbes.wikia.com/wiki/Transmogrifier http://calvinandhobbes.wikia.com/wiki/Transmogrifier
- vidarh 13y agoFrom transmogrify, presumably. And despite probably being most commonly associated with Calvin and Hobbes transmogrifier these days, that _is_ a real English word with a few hundreds years worth of use.
- breischl 13y agoI guess the "never sanitize" headline is clickbait, but the point is valid. "Sanitizing" input is really hard, and can provide a false sense of security. That string has been sanitized, so it's safe! Wait, is it safe for SQL? What about HTML? What about inside a <script> tag? What about a different database engine, or Mongo, or Azure Tables? You are much better off giving up on the illusion of "safe input" that sanitization gives you, and instead always treating user input as data rather than mixing it up with your code. My major complaint is that after correctly identifying the solution for SQL, he ends up with nothing to say about HTML. The right approach for rendering user input into HTML is with the Javascript createTextNode() function. That's how you tell the browser that it absolutely shouldn't interpret that content as HTML.
- billpg 13y agoThanks for that. I'll add a note mentioning createTextNode once I've had a chance to read up on it.
- SlashmanX 13y ago> Perhaps this is why some Irish people prefer to spell their name using the letter Ó. After years of having their name mangled by naive software developers, they made a new letter. Stopped reading here as I assumed the rest of the article was satirical
- nubs 13y agoI've always seen "sanitization" as more of an output-encoding problem. People love to consider sanitizing the inputs, but how you do so doesn't depend on the inputs but on the specific usage of it - more-or-less the output of your program. Rather than trying to think of all the ways the inputs to your program could be abused to cause abuse, I find that it is safer to start at where the output occurs - database calls, system calls, etc. The most commonly used of these (database calls, shell commands, etc) tend to have a variety of encoding capabilities to ensure that when you want to stick a string in a particular place it does exactly that regardless of whether the string came from user input or elsewhere. For example, bind parameters for databases, or proper escaping functions. If you think about it as sanitizing input it means you tend to misplace your attention to detail and only consider the entry to your application. A single input is often used to do multiple things through a program so you cannot properly handle sanitization at input. The real push should be for proper output encoding, not input sanitization.
- mantrax4 13y agoThis is why I just call it encoding and decoding. Proper words, and assume context (encoding for what... decoding from what).
- peterwwillis 13y agoThe purpose of sanitizing input is not to prevent security vulnerabilities. It is to make sure the values taken by your program are valid. If you accept a number range, and the user inputs a word, it's invalid input for your parameter and your program will crash. Input sanitizing validates the input is correct for your use. It indirectly improves security, but is not itself a practice of making an app more secure.
- mantrax4 13y agoYou actually said it, which is funny, but the right word for this is "validating". Here's the chain: 1. Get raw input. 2. Validate it (number, not number, in range, not in range?) 3. Optionally format it to canonical format (i.e. trim whitespace etc.) ... later.... 4. Encode it for where you want to use it (SQL, HTML etc.). Sometimes steps 2 and 3 are done in the opposite order, or as an atomic single operation, but point is, we have perfectly reasonable words for all that: validating, formatting, encoding.
- zAy0LfpBZLC8mAC 13y agoThe overall point is very true indeed, though I think it's not made particularly clear what the actual problem with sanitizing input is. The problem is that you are silently changing information, and that's an absolute no-go for reliable data processing, and the cause is that people think of, say, html, as "some kind of text/strings". HTML is a serialization of a tree, similarly, SQL is a serialization of a syntax tree ... - and if you want to add plain-text user input to such a serialized tree, you have to _convert_ it from, say, "plain text" to "HTML character data". You have to think of them as two different data types, and so when you want to use a value presented as one of the types as the other type, you don't have to "sanitize" it, even calling it "escaping" is confusing - you have to _convert_ it. And if it happens that some input can not be represented in the target type, then you have to _validate_ the input and _reject_ broken input.
- chriswarbo 13y agoNot sure why this is being downvoted. This "some kind of text/strings" approach is why we have "escaping" functions which turn strings into strings, instead of conversion functions from, say, "plain text" to "HTML character data". This prevents our computers from helping us, even if we're using an ivory tower type system with a whizz-bang IDE, since everything's just "String" so the compiler says OK. Here's an example of the alternative http://blog.moertel.com/posts/2006-10-18-a-type-based-solution-to-the-strings-problem.html http://blog.moertel.com/posts/2006-10-18-a-type-based-soluti... (remember that most of the code there is building the libraries; using them is simple and terse).
- marcosdumay 13y ago"Convert" is ambiguous. When you read the text "<head>" from a template file, you probably want to represent it as the HTML "<head>", but when you read it from the database, you may, or may not want to represent it as "<head>". People started using the word "sanitize" exactly because it conveys that information that "you want to treat it differently, depending of where it comes from". We also use the words "dirty" (sometimes "tainted") and "clean" conserving their usual relations to "sanitize". Now somebody wants throw away a very concise and expressive jargon just because some people are giving bad advice on the Internet?
- simonw 13y agoThis article almost gets it right, then screws it up with the HTML example. Both SQLi and XSS have the same cause: concatenating strings when you are working with active code of some sort. They both have the same solution: you need to know the escaping rules for the active code you are assembling. You shouldn't be solving XSS by stripping tags (that's a great way to build a discussion forum where no-one can talk about how to use HTML) - you should be escaping user input before assembling it in to HTML. To protect against dumb mistakes (because it's really easy to screw up just once and have a huge security hole) you should use abstractions that do this for you. If you're working with Django the ORM will do this for SQLi and auto-escaping in the template language will do this for XSS (watch out for variables you are outputting in a script tag context though). Escaping, not sanitizing, should be the message.
- huxley 13y agoHate to disagree with you but you can have plenty of flexibility with element and attribute white-lists without abandoning sanitizing. Sanitize as much of your inputs as you are comfortable with and escape the outputs.
- marcosdumay 13y agoEscaping is a form of sanitizing.
- kijin 13y agoThe argument makes sense in the SQL injection example (don't escape, use prepared statements!) but falls apart when you get to the XSS example. Now we're just trying to redefine words. "HTML injection" does sound cool though. Since XSS nowadays is not necessarily about sending cookies to another site, perhaps we could adopt "HTML injection" as a more generic term. Now of course, the problem we're trying to fix is someone who does: $content = htmlspecialchars(mysql_real_escape_string(addslashes($content))); before $content ever hits the database, without any understanding of what those functions really do. It's a surprisingly common cargo cult among newbie web devs. Just throw all the security-related functions together and you'll be safe!
- vezzy-fnord 13y agoHTML injection already is a term: https://www.owasp.org/index.php/HTML_Injection https://www.owasp.org/index.php/HTML_Injection Same principle, but different method of exploitation. If we supply plain HTML tags in a vulnerable parameter, it's HTML injection. If we use JavaScript (via a script tag or whatnot), it's XSS.
- mikeash 13y agoTo me, "sanitize" implies a blacklist approach, which is inherently insecure. For the HTML example, it means you're going through and blocking <script> and such, while allowing the rest through. What you should be doing is keeping a small whitelist of allowed tags and blocking everything else, if you must support user-provided HTML in the first place. That to me isn't sanitizing but rather defining an HTML subset and then translating from it to full HTML.
- theboss 13y agoThis is stupid and I don't see anyone quite hitting the mail on the head as to why. People normally dumb web vulnerabilities together. Xss and sqli especially. Preventing xss you have to sanitize. Preventing sqli you used parameterized queries. To prevent stored xss you sanitize what you put in the database. So really... You still need to sanitize. I've also seen people make arguments about inexperienced web programmers and how this advice can cause them to write bad code. I think the argument is bad because so many resources exist to help them. There is real code on stack overflow, w3 schools, owasp, and other blogs that can be copied and pasted in to their projects.
- zAy0LfpBZLC8mAC 13y agoNo, you don't sanitize what you put in your database, you validate what you put in your database, and convert into the output format when using data from the database. Sanitizing is always(!) wrong.
- theboss 13y agoIf you never sanitize how do you prevent xss ... For the average web Dev my approach is plenty good enough.. It's funny because your approach still requires sanitizing
- splitbrain 13y agoby properly escaping the output, not sanitizing the input
- theboss 13y agoAnd... How is escaping different from sanitizing. I would expect escaping to inheret from sanitizing. The idea is the same. You take user input and put it in a safe format. The programmers needs may be different.
- zAy0LfpBZLC8mAC 13y ago
- mantrax4 13y agoI can't post a comment containing <script> in this comment form, because it's "disallowed", instead of just escaping it as plain text. The thick, thick irony of a guy who can't even follow his own advice.
- zAy0LfpBZLC8mAC 13y agoHe is perfectly following his own advice. Apparently, his form field takes HTML syntax with a subset of HTML tags. Your input does not conform to that. So, instead of silently altering what you wrote, it tells you about the validation failure and asks you to correct your input instead of silently changing what you wrote. The input field takes HTML, so you have to write "<script>" (I suppose, haven't tested it) in order to display "<script>" - that is perfectly consistent.
- mantrax4 13y agoNo form should accept just "HTML" if you don't want just any "HTML" in your form. I was actively trying to talk about his script example and instead I had to second-guess his parser to get past the validator (I eventually resigned and replaced < and > with [ and ]). If you want to support some tags, have your parser be an HTML-like DSL language with those tags supported. Don't disallow perfectly good input.
- zAy0LfpBZLC8mAC 13y agoI don't really understand what point you are trying to make, but in any case, he has a particular input format for that form field, your input did not conform to it, so it was rejected, nothing particularly surprising or wrong there. Now, I haven't tried it, but I suppose his form field expects HTML syntax? Have you tried entering your text in HTML syntax? Was that rejected?
- billpg 13y agoI know. I'm awful. :)
- huxley 13y ago> "Perhaps this is why some Irish people prefer to spell their name using the letter Ó. After years of having their name mangled by naive software developers, they made a new letter." I hope this is satire, Irish didn't "make up" the letter Ó, it was the standard historical form but was converted into O' when the names were anglicized. Frankly his advise about sanitizers seems equally suspect, I've processed a lot of complex scientific abstracts using html5lib and Bleach without any mangling like he describes. He must be using very naive sanitizers.