XSS Rx

6:15 PM -- There are two philosophies in which to protect against cross-site scripting (XSS) attacks: input encoding and output encoding. Input encoding means that the application takes whatever the user gives it and then encodes it so that when the information is outputted it has already been sanitized. Output encoding means that the application takes whatever data is given to it in whatever form it takes and stores it. Once it is ready for output it is sanitized before being shown to the user.

I've heard people say that output encoding is the right way to deal with HTML injection and XSS attacks as well. There's one concept I haven't bought off on personally. Let's take an example where you have a single input, which is your name. On a community board this will be exposed in more than one place. It could be presented in dozens of locations and have dozens of places to interact with the surrounding HTML on the page.

In this way, the developer has to make sure they output encode at every one of those potential places... or you could encode it upon input. Which sounds easier? Of course you must insure that the encoding you performed is adequate for the situation, but at least you only have to remember to do it once per input, rather than once per output. Remember, there is a one to zero or more relationship for inputs compared to outputs. That means for every one input there may be dozens of places it is shown back to the user. That means lots of places you have to encode if you do it upon output.

Another issue with output encoding verses input encoding is SQL injection. If you don't encode the information prior to being stored in a database, you are heavily at risk of SQL injection attacks. Here is one location for which there is no argument. Input encoding is the only answer. It stands to reason that logic is sound and that for any input you should encode it to ensure it is safe for later retrieval.

The only hole in that logic is where the output is used in different ways. Some places may have distinct requirements and cannot be encoded in the same way as others. That's not an edge case as it comes up a lot, depending on the use of the input. For instance, cookies must be formatted in a particular way, and if the encoding used for HTML output doesn't match cookie syntax requirements it makes sense to use a one-off encoding method for that output situation. So what will it be? Input encoding or output encoding?

I'll have some of both, thanks.

— RSnake is a red-blooded lumberjack whose rants can also be found at Ha.ckers and F*the.net. Special to Dark Reading