Security implications of taking a stylesheet URL from a CGIparameter

[Scott W Gifford]

Hello,

We've got a Web-based application written in Perl that is designed to
integrate as a frame into many different Web sites. We currently have
several stylesheets available to allow the user to match the look and
feel to their existing Web site. We're considering allowing our users
to host their own stylesheet, and just pass in its URL as a CGI
parameter. Something like this:

.../cgi-bin/script?stylesheet=http://example.com/style.css

with corresponding code like this in the HTML page template:

<link href="$STYLESHEET" rel="stylesheet" type="text/css" />

Of course, we have no control over what gets passed in to the
stylesheet parameter, so we have to be prepared for the possibility
that a malicious person sets it to something nasty.

We will escape $stylesheet so it can only contain letters, numbers,
underscore, dash, slashes, colons, and dots (to avoid cross-site
scripting), ensure it starts with "http://" or "https://" and contains
no port specification after the host (to avoid tricking the client
into opening local files or connecting to arbitrary services), and
require the filename to end with ".css" (to make it more difficult to
cause a script to run). Something like this:

/^https?:\/\/[\w.-]+\/[\w\/:.-]+\.css$/

I only have a rough knowledge of the full power of cascading
stylesheets. Are there any other security concerns I should be
thinking about? In particular, is there any way to embed
client-executed code (like JavaScript) into a stylesheet, implement
some other kind of cross-site scripting attack, or otherwise cause the
stylesheet to do anything besides alter the display of the page?

Any other risks I may not have considered?

Thanks for any thoughts and advice!

----Scott.

[Gunnar Hjalmarsson]

Scott W Gifford wrote:

We're considering allowing our users
to host their own stylesheet, and just pass in its URL as a CGI
parameter. Something like this:

.../cgi-bin/script?stylesheet=http://example.com/style.css

with corresponding code like this in the HTML page template:

<link href="$STYLESHEET" rel="stylesheet" type="text/css" />

Of course, we have no control over what gets passed in to the
stylesheet parameter, so we have to be prepared for the possibility
that a malicious person sets it to something nasty.

Better, maybe, to let your users upload their own stylesheets to your
server. Doing so would let you validate the stylesheet before it's used.

--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl

[David Dorward]

Scott W Gifford wrote:

I only have a rough knowledge of the full power of cascading
stylesheets. Are there any other security concerns I should be
thinking about? In particular, is there any way to embed
client-executed code (like JavaScript) into a stylesheet, implement
some other kind of cross-site scripting attack, or otherwise cause the
stylesheet to do anything besides alter the display of the page?

In standards conformant CSS? No

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).

(Follow up set)
--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

[Volker Birk]

In comp.security.misc Scott W Gifford <gi*****@umich.edu> wrote:

We will escape $stylesheet so it can only contain letters, numbers,
underscore, dash, slashes, colons, and dots (to avoid cross-site
scripting), ensure it starts with "http://" or "https://" and contains
no port specification after the host
The latter is a drawback.
and
require the filename to end with ".css" (to make it more difficult to
cause a script to run).
This is unneccessary.
Something like this:
/^https?:\/\/[\w.-]+\/[\w\/:.-]+\.css$/
Why not implementing RFC1738, 3.3 exactly?
I only have a rough knowledge of the full power of cascading
stylesheets. Are there any other security concerns I should be
thinking about?

With :before and :after there may be risks by inserting local scripting
code.

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

[Carolyn Marenger]

Scott W Gifford wrote:

Hello,

We've got a Web-based application written in Perl that is designed to
integrate as a frame into many different Web sites. We currently have
several stylesheets available to allow the user to match the look and
feel to their existing Web site. We're considering allowing our users
to host their own stylesheet, and just pass in its URL as a CGI
parameter. Something like this:
<snip>
Of course, we have no control over what gets passed in to the
stylesheet parameter, so we have to be prepared for the possibility
that a malicious person sets it to something nasty.

<snip>

I may be missing something here, but from the way you describe it, I as a
webmaster, can load your application in a frame within my site. The users
that come and browse my site, can access your application through the
frame.

To make it nice and pretty, you are allowing me to create a stylesheet for
your application so that it will fit with the look and feel of my site.
You are worried that I might insert malicious code into my user's computer
via the style sheet for your application's frame within my site.

If that understanding is correct, then here are my thoughts on the matter.

As a webmaster, my concern is that I get lots of traffic on my site. If I
introduce malicious code on my site that harms a user in any way, then I am
shooting myself in the foot. I will not get many return customers, and I
will probably not get many customers at all. I would in fact be concerned
that by offering your application, I am not introducing something harmful
to my customers.

The only feasible way that I can see to do extensive damage with your
application in a frame on my site, would be to heavily market my site, have
a nice, clean and SAFE presentation. When I have thousands of regular
users coming on a daily basis, then I could insert something malicious into
the site to attack them all. At that point, what I introduce does not even
have to be in your application, or in the css related to your application.
If it can go there, it can go in the css for my own site. Anyway, at that
point, I will very quickly lose my customers, my revenue, and probably
start collecting lawsuits.

From your point of view - are you being more concerned with a possibly
unrealistic security threat, than you need to? In my mind security boils
down to making it more expensive to 'steal' something than they get in
reward for having done it. Are you going beyond this?

Just my thoughts,

Carolyn
--
Carolyn Marenger

[Jasen Betts]

> In particular, is there any way to embed client-executed code (like

JavaScript) into a stylesheet,

yes.
Bye.
Jasen

[Jim Ley]

On Fri, 24 Mar 2006 08:09:38 +0000, David Dorward <do*****@yahoo.com>
wrote:

Scott W Gifford 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).

Similar exploits exist against Mozilla.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[dingbat]

Scott W Gifford wrote:

We're considering allowing our users
to host their own stylesheet,

That's safe, so long as you don't let people link to or upload
stylesheets that _others_ will use.

You can fit nastiness into a stylesheet. You can do it legitimately by
setting a content property that adds embarassing text to a page. You
can also use exploits to get executable client-side code into a page
via a stylesheet and that opens up a big can o' worms.

However there's nothing I can do through a stylesheet that I couldn't
already do to my own browser. A phishing attack that only targets
myself isn't a risk. A phish hook that I can target other people with
_is_ a problem.

[Sebastian Gottschalk]

Scott W Gifford wrote:

Any other risks I may not have considered?

What about the stylesheets themselves?

a {content-before:@url(somesites.com/mycontent.blah)}

with the content being any html you'd like to see, including JavaScript?

[Scott W Gifford]

Hi Volker,

Thanks for your thoughts. A few quick responses...

Volker Birk <bu****@dingens.org> writes:

In comp.security.misc Scott W Gifford <gi*****@umich.edu> wrote:

We will escape $stylesheet so it can only contain letters, numbers,
underscore, dash, slashes, colons, and dots (to avoid cross-site
scripting), ensure it starts with "http://" or "https://" and contains
no port specification after the host
The latter is a drawback.

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. It certainly is a limitation, but I suspect it will
be an acceptable one to our users.

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

to cause the client machine to execute a script somewhere. Requiring
a .css extension is in by no means foolproof, but executable content
with a .css extension is uncommon, so I suspect this will help
mitigate risk.

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.

I only have a rough knowledge of the full power of cascading
stylesheets. Are there any other security concerns I should be
thinking about?

With :before and :after there may be risks by inserting local scripting
code.

Thanks, that's exactly the sort of risk I was hoping to find out
about!

----Scott.

[Volker Birk]

In comp.security.misc Scott W Gifford <gi*****@umich.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

[Jasen Betts]

On 2006-03-24, David Dorward <do*****@yahoo.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

[Toby Inkster]

Scott W Gifford wrote:

We've got a Web-based application written in Perl that is designed to
integrate as a frame into many different Web sites. We currently have
several stylesheets available to allow the user to match the look and
feel to their existing Web site. We're considering allowing our users
to host their own stylesheet, and just pass in its URL as a CGI
parameter.

As others have already posted, there may or may not be ways for a
malicious person to craft a nasty stylesheet.

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.

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

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact

[Sebastian Gottschalk]

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).

[Scott W Gifford]

Toby Inkster <us**********@tobyinkster.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.

[Sebastian Gottschalk]

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.