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

From: Bouke van Laethem <>
To: Mario Vilas <>
Cc: Jann Horn <>,
Subject: Re: <BASE> tag used for hijacking external resources (XSS)

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:,  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]

Copyright © 1995-2021 All rights reserved.