A week of cross-site scripting headlines and how to protect against the problem

Three words have been prominent over the past week and have caused a fair share of headaches – cross-site scripting.

The vulnerability, attack vector and general website hole has received plenty of coverage in recent times. Written up as XSS, it was the cause of a highlighted vulnerability in the Orkut social network and was named as the largest attack vector by Veracode in its State of Software Security report.

Veracode's vice president of EMEA Matt Peachey told SC Magazine that the XSS is the ‘number one issue, most well-known and documented security flaw', as it accounted for 51 per cent of all vulnerabilities uncovered in the testing process.

So if this issue is so prevalent, should it be an easy one to resolve? Blogger Dinis Cruz claimed that XSS is ‘probably one of the harder problems to solve in a web application because fixing it properly implies that one has a perfect understanding of what is code and what is data'.

He said: “The problem with XSS (and most other web injection variation) is that the attacker/exploit is able to move from a 'data' field into a 'code' execution environment. So saying that XSS is easy to fix and eradicate is the same thing as saying that Buffer Overflows are easy to fix and eradicate.

“Also, saying that we know how to solve XSS is a red-herring because we don't know how to solve it. What we do know is how to mitigate it and for the cases where we do understand where we are mixing code and data, we can apply special protections.”

He said that protecting against XSS is something that the developers must do; against something that happens (and is enforced) by default by the frameworks/APIs used.

Cruz highlighted seven points that he said would be ‘the only way we will ever start dealing properly with XSS':

1) The framework(s) developers use have context-aware encoding on all outputs

2) There is no easy way to write raw HTML directly to the response-stream

3) There is no easy way for developers to mix HTML code with data

4) When HTML needs to be created programmatically, that needs to be outputted via an HTML DOM aware encoding API/method (such as the ones that .NET AntiXSS has)

5) There are static analysis rule packs for each of the frameworks that document (in rules) the programmatically combinations that make XSS possible (in that framework/API)

6) The developers have immediate (or before checking-in code into production) feedback when they create a XSS in their applications

7) Web applications have a communication channel with browsers, which will allow browsers to better understand what is code and what is data (Mozilla CSP is a great step in this direction).

“The key to really deal with XSS is 5) and 6), since these take into account the scenario that developers will mix code, and even in the best designed APIs/frameworks there will always be combinations that create XSS. Also, without this understanding of the data/code mappings (which is where XSS lives) we will struggle to create mappings for 7),” said Cruz.

“Bottom line: Solving XSS means solving the separation of code vs data in web applications, and that is something that we are still quite far off.”

Veracode's senior director of security research Chris Eng said on his Twitter feed: “I see hundreds, sometimes thousands of XSS a week. Majority ARE easy to fix.”

The Twitter worm from last week caused headlines around the world, as users spread suspicious code by simply moving their cursor over another's tweet. The vulnerability was exploited with no user interaction automatically and allowed secondary JavaScript to be loaded from an external URL with no user interaction.

Talking to SC Magazine, Bradley Anstis, VP technical strategy at M86 Security, congratulated Twitter on fixing it so quickly and said that the problem is that hackers are paying attention to incidents such as this.

He said: “Look at black hat search engine optimisation, how quickly do they jump on the hot topics? They are jumping on it quicker sometimes than the news organisations are.

“The whole Twitter worm thing is a great example of that, although you have to question the change control through one of their upgrades that re-introduced the issue. It also highlights some of the dangers of assuming cloud providers have this stuff covered.

"If you were relying on someone like Twitter and asked them what their testing processes are and what is in development and how they managed those processes, because actually I can guarantee that it is different to the processes that we have to do – if we sent out an upgrade that crashed machines we would have a problem.

“It just goes to show that sort of upgrade affected Twitter users, compared to how many workstations McAfee changed, cloud has given you a whole new division in terms of the user base.”

The term cross-site scripting has risen in notoriety over the last year, with the past few months particularly prevalent in how often it has been mentioned. This time last year it was the SQL injection that was generally perceived to be the most prominent threat, however as the last week has demonstrated we are only a three-letter acronym away from a new risk.

close

Next Article in Security Cats Blog

SC Webcasts UK

Sign up to our newsletters

FOLLOW US