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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJB2JztHKZnYU9V4nv1EsZge8tDgsyC57rSZjY6RNM+FWap-vQ@mail.gmail.com>
Date: Fri, 16 Dec 2011 23:27:47 +0100
From: Mario Vilas <mvilas@...il.com>
To: Bouke van Laethem <vanlaethem@...il.com>
Cc: Jann Horn <jannhorn@...glemail.com>, bugtraq@...urityfocus.com
Subject: Re: <BASE> tag used for hijacking external resources (XSS)

I see what you mean. But unless it's a vulnerability in itself it's
not a security issue but a violation of standards - which is not such
a bad thing, but just following the principle of being strict in what
you generate and flexible in what you receive, to maximize
compatibility. In fact that would make it a feature rather than a bug.
:)

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.
That's why you need something like a poorly implemented XSS filter to
consider this a vulnerability (having the ability to inject *some*
content, gain the ability to inject *any* content). But even in that
case it'd be a vulnerability of the XSS filter rather than the
browser.

On Fri, Dec 16, 2011 at 10:44 PM, Bouke van Laethem
<vanlaethem@...il.com> wrote:
> On Fri, Dec 16, 2011 at 9:59 PM, Mario Vilas <mvilas@...il.com> wrote:
>> Makes sense as a trick to bypass some crappy XSS filters that look for
>> strings like "javascript:", but I don't think it's a vulnerability in
>> itself.
>
> I would consider it a browser bug (although I agree it would mostly be
> abused through bypassing what you refer to as "crappy XSS filters"),
> because the browsers are going too far out of their way to parse
> invalid html.
>
> From http://www.w3.org/TR/html4/struct/links.html#h-12.4:
> When present, the BASE element must appear in the HEAD section of an
> HTML document, before any element that refers to an external source.
> The path information specified by the BASE element only affects URIs
> in the document where the element appears.
>
> w3.org doc also refers to RFC1080, http://www.ietf.org/rfc/rfc1808.txt:
> 10, Appendix:
> [...]
> HTML defines a special element "BASE" which, when present in the
> "HEAD" portion of a document, signals that the parser should use the
> BASE element's "HREF" attribute as the base URL for resolving any
> relative URLs.  The "HREF" attribute must be an absolute URL.

-- 
“There's a reason we separate military and the police: one fights the
enemy of the state, the other serves and protects the people. When the
military becomes both, then the enemies of the state tend to become
the people.”