Bugtraq mailing list archives

Re: <BASE> tag used for hijacking external resources (XSS)


From: Bouke van Laethem <vanlaethem () gmail com>
Date: Sat, 17 Dec 2011 01:10:47 +0100

Hey Mario,
Even defending it, I'm still not a 100% sure how (/by whom) this
should be classified/solved, so thanks for your input.

but just following the principle of being strict in what
you generate and flexible in what you receive, to maximize
compatibility.

I agree that is what is happening. I'm also strongly reminded of the
quote "As the Web grew larger and more diverse, a sneaky disease
spread across browser engines under the guise of fault tolerance."
[Michal Zalewski, The Tangled Web, p 11.]

Simply ignoring the tag would be the better option in my opinion.
That way compatibility (or better: fault tolerance) is maximized,
without creating unexpected situations.
This issue is just so damn easy to fix (browser-side), compared to
some others...

Another way to see it: if you require the ability to inject HTML
content in order to inject HTML content, you're not getting any more
than you already have, so by definition it's not a vulnerability.

Wouldn't you agree that by this definition no XSS is ever a
vulnerability: you are just using the ability to inject HTML in order
to inject some unaccounted for HTML, right?
Semantics aside, I think it is something slightly different than just
another XSS vector (as such the <base> tag is already discussed by
RSnake here: http://ha.ckers.org/xss.html),  Yes, web developers
should have good XSS filters, but this element should not be parsed by
browsers outside the <head> to begin with.

Finally, I consider the part that goes beyond the injection of code
the more interesting one: taking over the base, means taking over all
*internal* relative links and forms(!) on the page. I do not have to
inject HTML in order to inject HTML: I just have to inject HTML once
and prepare a remote site to receive all information flowing my way
through forms and links transparently.

-- 
Be strict when sending and tolerant when receiving. [RFC 1958, 3.9]


Current thread: