Security implications of taking a stylesheet URL from a CGIparameter

On 2006-03-24, David Dorward <dorward (AT) yahoo (DOT) com> wrote:

In a file served with a text/css media type? Yes.

http://archivist.incutio.com/viewlist/css-discuss/44263 has a simple
example, but expression lets any JavaScript be executed in Internet
Explorer (and can call ActiveX controls etc).

mozilla supports javascript: urls in CSS


--

Bye.
Jasen

In comp.security.misc Scott W Gifford <gifford (AT) umich (DOT) edu> wrote:

The goal is to limit the possibility of doing something like:
http://10.0.0.5:445/
to cause the client machine to connect to a fileserver in their
internal network.

Then you'd better remove access of this machine to your internal network
for such purposes completely. Additionally, you could filter out URLs
which are resulting in internal network addresses.

You're wrong to have constraints for the port number then.

and
require the filename to end with ".css" (to make it more difficult to
cause a script to run).
This is unneccessary.
The goal here is to reduce the possibility of doing something like:
http://www.somesite.com/runsomething.cgi

Why? I cannot see any security drawback from this.

Something like this:
/^https?:\/\/[\w.-]+\/[\w\/:.-]+\.css$/
Why not implementing RFC1738, 3.3 exactly?
I explicity don't want to allow some of the reserved characters
mentioned in section 2.2 of that RFC, to make it impossible to send
queries. Like the above restriction, I expect this to reduce the risk
of running executable content.

Hm...

Yours,
VB.
--
At first there was the word. And the word was Content-type: text/plain

Toby Inkster wrote:

So I say, accept any style sheets -- just make sure you replace '"' with
'&quot;' and '<' with '&lt;'.

Doesn't help against malicious JPEG images on IE (refering to the
second, unpatched vulnerability).

Toby Inkster <usenet200603 (AT) tobyinkster (DOT) co.uk> writes:

[...]

But look at the bigger picture. If this malicious person has linked to
your application like this:

iframe src="http://example.org/application.cgi?stylesheet=http://example.net/evil.css"
/iframe

then the visitor who recieves evil.css is *already* looking at the
malicious person's website, so the malicious person has already had ample
opportunity to load up evil.css.

Right, but the URL to the site containing that IFRAME will be to the
attacker's site, which should at least be a clue that something's
fishy (or phishy, as the case may be).

I tried a variety of attacks with stylesheets, to see if I could get
JavaScript code to execute. I couldn't get any of them to work in the
latest version of FireFox, but in a fully patched IE6 this worked:

@import url("javascript:alert('Gotcha!')");

So, it looks like this really isn't a safe thing to do.

Thanks for all the replies and information!

----Scott.

Scott W Gifford wrote:

I tried a variety of attacks with stylesheets, to see if I could get
JavaScript code to execute. I couldn't get any of them to work in the
latest version of FireFox, but in a fully patched IE6 this worked:

@import url("javascript:alert('Gotcha!')");

So, it looks like this really isn't a safe thing to do.

JavaScript in IE is never safe against Cross Site Scripting, by design.