News

08:15 AM
Connect Directly
RSS
E-Mail
50%
50%

XSS Rx

Is input or output encoding the better way to protect against cross-site scripting?

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

Comment  | 
Print  | 
More Insights
Cartoon
Slideshows
Audio Interviews
Archived Audio Interviews
Jeremy Schulman, founder of Schprockits, a network automation startup operating in stealth mode, joins us to explore whether networking professionals all need to learn programming in order to remain employed.
White Papers
Register for Network Computing Newsletters
Current Issue
2014 State of Unified Communications
2014 State of Unified Communications
If you thought consumerization killed UC, think again: 70% of our 488 respondents have or plan to put systems in place. Of those, 34% will roll UC out to 76% or more of their user base. And there’s some good news for UCaaS providers.
Video
Twitter Feed