Security Thoughts

Friday, August 17, 2007, 13:13

Preventing XSS with Data Binding

It's almost a couple of months that i'm researching and studying about how to implement the concept of Prepared Statements used in SQL Language, on Html in order to prevent XSS.
I asked Pdp, RSnake, Jeremiah Grossman, Kuza55, Romain Gaucher and some other researcher to have a look at it and to give me some feedback.

The raw Proof of Concept could be found here.

Here's some (technical) content of the mail i sent to some of them:

--8<-SNIP--8<----

The idea is about using something like prepared statements in SQL applied to Html which could be used to prevent XSS as PS-SQL are to prevent SQL injection.

Infact, server side filtering is often home made and moreover it doesn't cover all the stuff browsers are able to parse as well as proprietary well known interpretations of Html.

How this could be accomplished?
By separating html trusted data from untrusted data.
My idea is that semantical separation could be a good way to let browsers do validation/sanitization.

An example of semantical separation could be the deprecated' <plaintext> tag...because browsers parse every stuff after that as plaintext with no ending </plaintext> tag.

Even thought a more complex model could be proposed to vendors as a standard, from the client side point of view, it should be quite easy to implement some javascript code which parses and validates user data before attaching it to html.

A couple of examples follow:

Simple Text :

<html>
<body>
<bindtext id='someid'></bindtext>
</body>
</html><plaintext>someid|userdata

with a body onload event a javascript is further executed in order to :
1. Get the text after plaintext tag and parse it as an associative array
id => userdata
2. find all bindtext tags and use the
tag.appendChild(document.createTextNode(binding['id']) );

Attributes:

Altought attributes are more complex, by relying on data binding, I think, every attribute could be checked and sanitized with some preprocessing stage.

A simple href/src attribute check could be something like adding a new attribute named 'bindattr' like the following:

<a bindattr='href=ref|' > Click here </a>
<plaintext>
ref|java%09script:alert('hello')

and then using javascript to get the parsed internal protocol by using HtmlAnchorElement:

function getProtocol(url){
var a = document.createElement('A');
a.setAttribute("href",url);
return a.protocol;
}

so, as the protocol is the client side parsed one, it will be returned the "real" protocol ready to be checked and validated from client side.

These are, obviously, just examples of what could be done by taking advantage of Data binding and a preprocessing stage, anyway you could check every client/server side control i've implemented by looking at the source files linked on test.php.

I am planning to release a paper(as Minded Security) about this research on september.

Moreover i think it could be created a community based forum, if that idea is interesting fot a bunch of people, in order to implement a 360 degree client side validation engine.

Last, it would just stop only 80% of XSS (DOM Based XSS is on another level) but i think that if it would be implemented at browser code level, as a standard that would be some good interesting new methodology for XSS prevention.

---8<-SNIP-8<---

I also added style preprocessing code and some idea to preprocess untrusted data when dealing with mixed Html.

Even if i was planning to release a paper for Minded Security (http://www.mindedsecurity.com) on early september, RSnake posted a blog http://ha.ckers.org/blog/20070814/preventing-xss-using-data-binding/
entry probably in order to start some early discussion before i could write a complete, exaustive paper about this technique.
Well, the discussion started and it's already very interesting.
Kuza55 (a real browser hacker;) found a way to take advantage of the custom charset feature in order to stop plaintext markup to work and let the untrusted data to be parsed!
There are several workaround for this but i would like to use the most elegant and practical :)
Update: I used three plaintext markups in order to fix the issue. It's not so elegant but it should work.

Dean Brettle has already tried to add some contribute with an alternative solution using document.write in place of plaintext markup.
http://www.brettle.com/UntrustedHtmlWithJavascript.html

Next blog entry will be about some more technical details and workarounds.

Last, i ask you to have a bit of patience until early september when i'll release a more exhaustive paper, as the real will with this approach would be to write a proposal for a standard.

It seems there's no peace ... even when I'm on vacation. :)

Security Thoughts

Wisec is brought to you by...