comments (not for humans)

In this post I'll describe how OWASP Top 10: A2-Cross Site Scripting applies to javascript based applications. Cross site Scripting - or XSS - is probably one of the most common and one of the most difficult problems to fully mitigate. At first mitigation seems simple, but as contexts grow in complexity and the amount of code grows, it get's harder to discover all the different sinks.


[...]
"So now that you've seen how contexts are important when mitigating XSS, I'll give you a new example", David said. "Take a look at the following example from a social networking web site".
[...]

I recently presented on Web application security at Framsia (a user group for frontend development). Great crowd and lots of questions and good feedback afterwards. The slides from the presentation can be found below.


[...]
Recently we see frameworks altering behaviour in order to mitigate XSS. Ruby on Rails 3, Play Framework and ASP.NET MVC 3 all do HTML escaping by default for the standard output (<%=SomeVariable %>, ${SomeVariable} and @SomeVariable). While I applaude the frameworks for taking this step (and this is certainly a step in the right direction), you should be aware that this will not automatically block all XSS attacks. Here are some examples.
[...]

The brand new Rails 3.0 by default escapes data used in views. This is great news, because it hopefully means the applications will be protected from XSS by default, as long as you stick to the built-in helpers (UrlHelper etc.).


[...]
A lot of flash and flex applications use an XML-file for configuration. The XML-file sets up which texts and images to show. However if we don't pay attention, this flash application can be abused for phishing or spam, because the attacker can specify which file to use in the flash - a client-side RFI (Remote File Inclusion). Luckily this is not as dangerous as server-side RFI, but it's still something you want to avoid.
[...]
As shown in several articles and mailinglists lately, input validation is also required when developing flash files. However a lot of sites already have a lot of existing flash files, to which they may or may not have the source code available, possibly because it was created by a 3rd party. However there is still hope.
[...]
Recently there has been a lot of fuzz about security problems in flash files. At the recent Blackhat DC 2010 Mike Bailey also discussed this very topic. These problems are not new, but have somehow avoided getting much focus earlier. Input validation and output escaping in flash seem to be ignored.
[...]
In my previous posts JSONp - What's the risk? and Web2.0 - Who do you trust? I talked about the potential security problems that can occur when adding script tags and/or using jsonp. In this post I will show a couple of demos.
[...]
When it was first introduced, Mozilla Content Security Policy (CSP) seemed at bit interesting when developing new applications, but I couldn't really see any benifit for already existing apps, as they would have they would have to rewrite a lot of the code. However after many of the newer additions, I think this can help severely reduce the effect of many attacks.
[...]