RE: Fixing XSS Vulns

[Jeff Robertson <Jeff.Robertson () DigitalInsight com>]

 Another reason to use output encoding is that a big chunk of the XSS in any
web site is not stored in the database at all, it is reflected XSS. If you
focus solely on encoding stuff before you save it in the database, you'll
miss all the potential XSS in places where input from forms, headers,
cookies, etc., is displayed directly.

-----Original Message-----
From: Stephen de Vries
To: wilsonc
Cc: webappsec () securityfocus com
Sent: 8/12/2005 8:48 AM
Subject: Re: Fixing XSS Vulns 


Hi CW,

While the approach of encoding the input on entry will work, and will  
protect you from XSS attack, IMO it's not the most elegant solution,  
primarily because it makes your app less modular.  And if it's less  
modular then you're going to have a hard time extending it or reusing  
any of the components for other apps.
You've said that this data won't be displayed any other way except  
through a browser, but can you be sure that this will be the case 12  
months down the road?  Making a decision to store encoded data in a  
database would be to design yourself into a corner that could be  
difficult to escape when the application needs to be extended.

I think a more flexible approach would be:
- Firstly, implement strict validation on user supplied data so that  
only the minimum set of characters are permitted.  This should be  
implemented as a white-list approach where the valid character set  
for each piece of data is defined and used to filter input.  For  
example, a regex for a telephone number could be: [0-9\(\)\-\ \+]+
You should not only be filtering character sets, but where  
appropriate length and range too.  Check that values that should be  
positive integers are indeed positive and not floats, etc.
- Secondly, you should implement encoding mechanisms where your data  
is processed.  So that if your data is being displayed as HTML, it  
should be encoded as HTML, if it is being used in an LDAP query, it  
should first be encoded for safe LDAP use etc.  It will be helpful  
here if you can use existing functions to perform the encoding, such  
as prepared statements for SQL queries.  Modern MVC application  
frameworks like Struts or JSF will also do the HTML encoding for you  
- but in case you're not using one of these, I'd recommend writing a  
function to properly encode HTML output, and then ensuring that all  
data that is displayed to the user is first sent through this function.

Implementing it this way will mean that your app is more modular:  
each piece takes care of itself without relying on monolithic  
encoding controls.  And, if you ever need to display that data in  
something other than a browser, you can.

regards,
Stephen


On 12 Aug 2005, at 13:41, wilsonc wrote:

>             I'm a new developer to a project, and I've found that  
> our web
> app is wide open for XSS exploits. (thankfully, its not in  
> production use).
> I'm not a security expert, but I did some googling and found that the
> standard procedure is basically to "encode" the string before  
> displaying it
> to the user, so that specific characters are transformed into their  
> HTML
> 'escape sequence'. For example, the left paren, '(' would be  
> encoded to be
> (
>
>             A more experience developer has suggested that instead of
> writing a function to do this when we display, we write a trigger to
> encode/filter on capture. I explained to him that it would be that
> HTML-specific 'escape sequences' would then be stored in the  
> database, and
> what I learned from googling. He feels confident that our data will  
> only be
> displayed through a web app, and not through any kind of reporting  
> module,
> and he feels the trigger to encode text is a cleaner implementation.
> Assuming your data was only going to be displayed back to the user  
> via the
> same website that captured the input, is there anything wrong with  
> encoding
> the string on capture?
>
> --CW