In the context of a stored XSS attack^ it is used to avoid signature based detection. Think about malicious Javascript as a virus. Current virus scanners search for signatures within programs^^ to determine whether a program is a virus or not. Signatures are unique strings^^^ that identify a program. If you can encode your virus as a bunch of symbols, you can avoid detection by automated scanners. Then, once a user loads the page, the decoder function gets called and the malicious Javascript gets executed.
Of course, a signature could be generated for the decoder function. As is common in many areas of the security industry, signature based detection is an arms race. Obstrufication is one method the attackers use.
In the context of a reflected XSS^^^^ obstrufication simply makes it less obvious there is an embedded script.
-
^ Javascript permanently stored on the vulnerable host's server.
^^ They also use other methods too, but signature based detection has been the primary method used by anti-virus since the industry started.
^^^ In practice they are not unique.
^^^^ Javascript embedded in a link to a site. User clicks on link and Javascript gets executed in the context of the vulnerable host.
A lot of people do input validation by disallowing 'bad' characters.
The idea is to stop people buying JavaScript in comments, as that would be bad. Just strip enough characters that you can't do functions and everything will be...
...oops. Hope you remembered to filter out + and [] as well! Never mind, now all your visitors are automatically posting/up-voting spam comments or something similar. Better luck next time.
Captain Obvious here again. Doesn't all this go away if you use Javascript to inject untrusted text directly into the DOM rather than rendering it as HTML which is then interpreted by the browser?
And if so, it seems to me that there's a fairly obvious way to build that directly into templating engines and meta-languages like HAML.
That would work, but with the downside of lowering the accessibility of your site. Not everyone has JavaScript enabled, and so dynamic insertion of text wouldn't be accommodating to them.
That's true for people that don't need alternate browsers. It's like, "why build wheelchair ramps outside of businesses when 99.99% of people are able to walk up steps?"
Comments
At the risk of summoning Captain Obvious...
Is this for sneaking code past XSS filters? Or for making XSS attacks more difficult? Can someone explain the utility?
It's used for attacks.
In the context of a stored XSS attack^ it is used to avoid signature based detection. Think about malicious Javascript as a virus. Current virus scanners search for signatures within programs^^ to determine whether a program is a virus or not. Signatures are unique strings^^^ that identify a program. If you can encode your virus as a bunch of symbols, you can avoid detection by automated scanners. Then, once a user loads the page, the decoder function gets called and the malicious Javascript gets executed.
Of course, a signature could be generated for the decoder function. As is common in many areas of the security industry, signature based detection is an arms race. Obstrufication is one method the attackers use.
In the context of a reflected XSS^^^^ obstrufication simply makes it less obvious there is an embedded script.
-
^ Javascript permanently stored on the vulnerable host's server.
^^ They also use other methods too, but signature based detection has been the primary method used by anti-virus since the industry started.
^^^ In practice they are not unique.
^^^^ Javascript embedded in a link to a site. User clicks on link and Javascript gets executed in the context of the vulnerable host.
A lot of people do input validation by disallowing 'bad' characters.
The idea is to stop people buying JavaScript in comments, as that would be bad. Just strip enough characters that you can't do functions and everything will be...
...oops. Hope you remembered to filter out + and [] as well! Never mind, now all your visitors are automatically posting/up-voting spam comments or something similar. Better luck next time.
Captain Obvious here again. Doesn't all this go away if you use Javascript to inject untrusted text directly into the DOM rather than rendering it as HTML which is then interpreted by the browser?
And if so, it seems to me that there's a fairly obvious way to build that directly into templating engines and meta-languages like HAML.
That would work, but with the downside of lowering the accessibility of your site. Not everyone has JavaScript enabled, and so dynamic insertion of text wouldn't be accommodating to them.
How many people don't have JavaScript enabled these days? I guess you have to consider your audience. http://www.w3schools.com/browsers/browsers_stats.asp has some clues.
That's true for people that don't need alternate browsers. It's like, "why build wheelchair ramps outside of businesses when 99.99% of people are able to walk up steps?"
http://www.section508.gov/
the former.