XSS Zones

One of the impossible problems of the web is how do you protect against site that has a persistent XSS hole yet requires JavaScript to function. I thought about this for a while and worked out you could create a XSS zone where you expect user input. Declaring a zone is tricky because if you have a start and end marker the attacker can manipulate that with their markup and break out of the zone.

Lets take a look at some code as a reference:- <code lang="html"> <!-- Begin XSS zone --> Hello I am a twitter..I mean webgoat <!-- End XSS zone --> </code>

So we define a XSS zone where we allow untrusted input. The idea of the zone is that JavaScript, events, css is locked down or disabled stopping the worm or evil input from spreading or cause information disclosure. But now the attacker has a new string to inject <!-- End XSS zone --><img src=1 onerror=alert(1)> and they have broken out of the zone.

The solution to this problem is to randomize the zone name:- <code lang="html" > <!-- Begin XSS zone 9cb3c2fd7ef861d762471c90de049603806e315eea3daf 13e0b8faadd6b9e85db09afeab9430d8f58d1f7e8551745 ec3f3961be932b79247f56c12db5c7e2e8d --> Evil content <!-- End XSS zone 9cb3c2fd7ef861d762471c90de049603806e315eea3daf13e0b8f aadd6b9e85db09afeab9430d8f58d1f7e8551745 ec3f3961be932b79247f56c12db5c7e2e8d --> </code>

Before the HTML is rendered the browser looks for XSS zone name, when it finds the first zone name it continues parsing the HTML until the matched ending zone is found. Any existing zones inside are ignored. The randomization of the zone name is generated on every request and are removed from the markup before render.

XSS zones would require a inbuilt JavaScript/HTML/CSS sandbox which would only allow harmless markup. Any input that is accepted from the user would have to be declared with a XSS zone and the feature would have a OFF/ON switch somewhere maybe HTTP header. The zones themselves could have a simple configurable attributes e.g. javascript=false css=false html=true urls=sameorigin.

Defining a zone could be done manually by generating a random name and outputting the HTML comment or the server side language could detect where variables are used and output the zone names automatically. Using HTML comments is interesting because they act as both a HTML and JavaScript comment enabling nice fallback.

One final way to enable XSS zones would be using the browser itself similar how Firebug and IE developer toolbar allow you to select DIVs and other elements, the advanced user could select an area of a site that they determine requires a XSS zone. The browser would then monitor this section of the site and automatically add a random XSS zone to the markup.

Configuration of zones

Zones should always follow the format of <!-- Begin XSS zone RANDOMKEY CONFIGURATION_DATA --> and end with <!-- End XSS zone RANDOMKEY -->

The configuration should be simple and precise. The following commands should be supported. javascript=no|yes|domains* css=no|yes|domains* urls=sameorigin|domains|proxied*

• Domain list should be a whitelist only, no global wildcards allowed.
• Proxied should place all urls through a proxied service that obtains the image data or follows a link without sending cookie information and pre checked with a malware scanner.

That was the basis of my idea, if you like it implement it.