[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: <BASE> tag used for hijacking external resources (XSS)
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
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
> 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]