Hacker News Reader

Comment by noodle | Hacker News Reader

rule of thumb: sanitize your inputs.

if you do this correctly and thoroughly, you're better off than like 70% of the web apps out there. doesn't take much time, just requires that you set up everything and remember to do it for everything from GET/POST to cookies to manipulating the DOM.

edit to clarify, based on child comments:

sanitizing inputs doesn't necessarily mean you apply one filter to everything. it just means that you're ensuring that what you're taking in from the app is something your code is expecting and can handle. if you're expecting a sql query or some unescaped html, you don't need to filter out the query or the html.

View on HN

For Rails folks, we wrote a plugin to sanitize the entire params hash in a before filter. This is protection against XSS attacks.

http://code.google.com/p/sanitizeparams/

Not a rails specialist, but I don't understand the point of sanitizing input? It seems to me the correct place to sanitize is output (in HTML or SQL). Otherwise it will all get messy - "escaped" text ends up in the database and might be escaped once more during output (if you use the typical Rails h() method). And what do you escape, SQL, or HTML, or both (and don't forget JavaScript)?

Also sometimes the user might want to save code snippets in the database, would be bad to escape them.

Sanitizing input is one of the best defense's against the Cross site scriting and sql injection attacks, since those account for most of the security attacks, also equally important is to html encode the output so that it does not contain any characters which could be used in these kinds of attacks.

Cross site scripting and sql injection attacks could almost be prevented by checking the input for the unwanted characters and in case if they got in to your system second level of defense is to html encode them when you ouput on the screen.

Sure, sanitizing on input doesn't fit all situations but I think it's good for many. Note, I'm only talking about XSS (think preventing iframe and script tags).

1. The number one reason is that it reduces programmer error. If we never store corrupted data then we're never at risk for displaying it. This is a practical concern because I've observed I and other programmers I've worked with often make errors. I have no knowledge of whether or not this is true for all programmers.

2. Nothing gets messy because we don't escape anything. Certain types of data simply aren't let in.

3. There are some edge cases where we do relax the rules, primarily for the admin user.

4. People should still be able to store code snippits but they need to escape them first.

there's a difference between correctly sanitizing your inputs and reformatting everything you take in.

you don't restrict all things to the same conditions. if you need to take in text that shouldn't be escaped, don't escape it. just make sure you deal with it correctly.

edit:

if that doesn't help and you still are wondering why you should sanitize inputs, read up more on xss and sql injection vulnerabilities.

Surely this approach means it's impossible to discuss XSS attacks on a forum-style site running that filter?

Reply on news.ycombinator.com