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]
