|
Posted by Scott W Gifford on March 23, 2006, 10:44 pm
If you were Registered and logged in, you could reply and use other advanced thread options
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.
|
|
Posted by Gunnar Hjalmarsson on March 24, 2006, 12:47 am
If you were Registered and logged in, you could reply and use other advanced thread options
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
|
|
Posted by David Dorward on March 24, 2006, 3:09 am
If you were Registered and logged in, you could reply and use other advanced thread options
> 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
|
|
Posted by Volker Birk on March 24, 2006, 3:33 am
If you were Registered and logged in, you could reply and use other advanced thread options > 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
|
|
Posted by Carolyn Marenger on March 24, 2006, 6:21 am
If you were Registered and logged in, you could reply and use other advanced thread options
> 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
|
| Similar Threads | Posted | | DFS security implications? | December 16, 2005, 9:08 am |
| Is Cybercrime Taking the Lead in Profit Margin for Criminals? | March 25, 2006, 9:26 am |
| Security Breaches Pandemic - Deloitte Touche 2006 Global Security Survey | June 29, 2006, 12:42 am |
| New site dedicated to security conferences : www.security-briefings.com | May 6, 2006, 11:16 am |
| New It Security News and Information site for security professionals | August 6, 2008, 2:46 am |
| Excellent website for IT Security (Security+) | February 8, 2008, 12:32 am |
| Google Closes Security Holes in Google Base Security | November 21, 2005, 5:37 pm |
| Security IP | June 10, 2005, 3:09 pm |
| BGP Security | October 4, 2005, 1:49 pm |
| MSc IT Security | February 28, 2006, 4:42 pm |
|
XML site map