Next generation vulnerabilities in 2.0 Web Applications
how to hijack functions and objects in order to have transparent attacks
Maybe it's just me, but when I hear "Web 2.0" uttered by someone, they lose
all credibility with me.
What an utterly meaningless, unnecessary term.
However, I've heard that Web 3.0 kicks ass.
It is pure marketing-speak. I expressed a similar notion to my boss last
week, and he said, "Don't let the marketing department hear you saying
that as they love the introduction of the term. It gives them a positive
sounding non-technical label for what we make" (paraphrased a bit, and
> However, I've heard that Web 3.0 kicks ass.
So we don't get a 'Web 2.1'? ;-)
The security article was interesting (though included nothing new) but
failed to explain how the mentioned vulnerabilities become significant.
your address bar, and by extension do anything you like to a running
and do it habitually to break stupid client-side validation scripts),
but compromising your own browser is not going to get you very far
(presumably you already know your own back details, etc.). To be useful,
the ability to wrap an XML HTTP request object in something malicious
requires that you do the wrapping in someone else's browser. So the real
security issue is the ability for the malicious individual to introduce
scripts to a site in a way that will have them executed in the browsers
of other visitors to the site.
That makes script insertion the real issue, and the potential
sophistication of the inserted script an irrelevance once its insertion
has been rendered impossible. Of course that is not as simple as it
sounds. I have spent the last few years repeatedly telling the
server-side developers who I work with that whenever they take
user-entered text from a database and dump it into a web page they
should entify, escape or encode it appropriately for the context in
which it is placed. I still catch them not doing so, and the fact that
99% of such insertions are automatically handled by the template system
is one of the factors leading them to omit that required step on the
rare occasions when they have to step outside the template system.
IMO they are barking up the wrong tree or - more exactly - they did not
see the forest behind the tree. :-)
The real problem is that the current ECMAScript implementations do not
provide any real protection for default object properties and methods.
This keeps the doors wide open for what we call in-house "maskons".
Note: I'm oftenly accused of inventing new terms, but this one is not
mine, it was coined by Stanislaw Lem in his "The Futurological
Congress" novell, btw another must-to-read after Orwell's "1984". Over
the last 40 years this term seems gained some popularity in different
domains, but we are using it in the original sense which could be
briefly described as an "artificially created illusion hiding some real
This way in the programming maskon is a property created atop of the
default property in order to shadow it. A really good written maskon
not only shadows the real property but it also acts in the way to make
it most difficult to notice the substitution. For that it may implement
the necessary bogus methods and even return some true-looking values.
XMLHttpRequest "vulnerabilities" discussed in the article is only small
and actually the least relevant outcome of the maskon problem in
No one is calling for a conference on say arrayObject.push(value) being
used to submit the value to some 3rd party server and only then
So the real problem is that the current implementations do not provide
a simple and obvious method to bypass maskons and to deal with real
properties, methods and constructors.
It means that if one is not cautious enough she may end up with her
script running in totally maskoned environment where open, alert, send
etc are doing nothing of what you think they are.
The problem complicates even more because of some twist of thinking an
ability to programmatically recognize and remove maskons considered as
vulnerability(!) by many browser producers. I once tried to find any
logic behind it and the only one possible explanation could be with
window.open method. Namely on the cheap-chat "vulnerability and popup
blockers" dumped on the market the code simply hides the real open()
behind the maskon. You bypass the maskon - you bypass that sorry
"blocker". I still don't understand though why producers started to
"fix" engines instead of simply suggest to McAffee and Co to stop
making junky top-level "web protector" scripts and start doing normal
system-level integrated plugins.
This way in the practical programming for all important steps one
should ensure first that you are going to deal with the reality and not
with a maskon: say that XMLHttpRequest is _that_ XMLHttpRequest and say
XMLHttpRequest.send() doesn't submit first a copy of your data to some
3rd party server.
The technics to bypass possible maskons differs by UAs but always
possible. At the same time until the above mentioned twist of thinking
is in effect I'm cautious to discuss it publicly.
Interesting analysis and read. Thanks!