Canonicalize: Attackers will use tricks to attempt to bypass your validation. By using various kinds of encoding, either alone or in combination, they hide code inside data. You have to decode this data to its simplest form - "canonicalize" it - before validating, or you may allow code to reach some backend system that decodes it and enables the attack. But canonicalizing is easier said than done. Take a string that's been doubly encoded using multiple different (possibly unknown) encoding schemes, add any number of backend parsers, consider the browser's permissive parsing, and you have a real mess - as seen here:

?input=test%2522%2Bonblur%253D%26quotalert&amp%23x28document.cookie%2529

Encode output: Encoding isn't all bad. You can use encoding to tell the browser that data shouldn't be run as code. "Whitelist output encoding" is simply replacing everything except a small list of safe characters (such as alphanumerics) with HTML entities before sending to the browser. The browser will render these entities instead of interpreting them, which defuses XSS attacks. Except that it doesn't always work. First, many frameworks and libraries use "blacklist" encoding where only a very small set of characters is encoded. Also, there are some places in HTML, such as href and src attributes, which allow HTML entities to be executed. So the following insane URL is actually executed by browsers:

Assign character set: Even if you're doing great input validation and output encoding, attackers may try to trick the browser into using the wrong character set to interpret the data. An innocuous string in one character set may be interpreted as a dangerous string in a different character set. Many browsers will attempt to guess the character set if one is not specified. So, the harmless-looking string +ADw- will be interpreted as a < character if the browser decides to use UTF-7. This is why you should always be careful to set a sane character set like UTF-8, as seen here:

Content-Type: text/html; charset=UTF-8

Page:

• ← Prev
• 1
• 2
• 3
• Next →

Related stories

• Rich data: the dark side to Web 2.0 applications (1 August 2008)
• Time to dismount the hamster security wheel of pain (23 June 2008)
• Too much code, too few application security specialists (28 May 2008)
• RSA Security experts warn against Web 2.0 charlatans and 'premature AJAXulation' (14 April 2008)
• ID and the triple-A challenge of mashup security (10 April 2008)
• The trinity of RIA security explained (8 April 2008)
• RSA Stay focused on fuzzy tests, warn security experts (7 April 2008)
• Is Google Gears safe? (2 April 2008)
• Open AJAX frameworks not fit for 'power users' (28 March 2008)
• AJAX patent threat to giants under the hammer (25 March 2008)
• Reduce your exposure to AJAX threats (18 February 2008)
• NetBeans and Ruby, part 2 Ruby runs on Rails with NetBeans (13 February 2008)
• Betamax 2.0: the future of mashups? (11 February 2008)
• 'Tofu' license pits open source against meat (26 January 2008)
• Major HTML update unveiled (22 January 2008)
• Librarians challenge Web 2.0 youf-work myths (22 January 2008)
• Mashups haunted by past experience (18 January 2008)
• Contest seeks the most diminutive XSS worm (5 January 2008)
• Serious Flash vulns menace at least 10,000 websites (21 December 2007)
• Adobe plugs multi-platform Flash vulns (20 December 2007)
• OpenWorld Oracle bets business data on OpenSocial (14 November 2007)
• Yahoo! battered by second ActiveX vulnerability (3 September 2007)
• Researcher crosses swords with Google over XSS 'flaw' (21 August 2007)
• Interview Worms 2.0! (27 June 2007)
• Cookie monster menaces Google (18 January 2007)
• Oracle blocks 51 security holes (17 January 2007)