Let's be paranoid about CSS (cascaded style sheet) as an application data integrity attack vector!

2008-09-09 Thread Thierry Moreau

Dear security experts:

Suppose I want to use the HTML syntax and a plain web browser as a user 
interface for a secure application. By secure, I mean, among other 
things, that the application service provider is confident that the user 
sees the HTML contents without integrity vulnerabilities. Of course, 
https is the only allowed protocol for reaching this web page, and the 
only protocol present in any link from this page to a next one.



I am now concerned about the default and implicit style sheets that the 
web browser uses for HTML content rendering.



Here is a simple exploit which alters the ietf.org main page. Insert the 
following four lines


a[title=IETF Secretariat]:before
{content: Don't trust the }
a[title=IETF Secretariat]:after
{content:  for anything security-critical.}

to the file /usr/lib/firefox/res/html.css

then restart the Mozilla Firefox and bingo, the itef.org main page is 
subrepticiously changed. I.e. the link to IETF Secretariat is canged 
to Don't trust the IETF Secretariat for anything security-critical.



OK, this requires root access because the Linux community is generally 
security-conscious. But you should see the general idea: paranoia leads 
me to think of an adversary who would threatens application integrity 
(such as the above) without leaving much trace of computer system 
penetration.



This attack vector is trivial based on the HTML markup language 
philosophy - the above exploit merely alters default settings in a 
parameter specifications language (css) having a fine grained 
expressivity potential. CSS is about what the user sees when HTML 
contents is displayed on a media (typically a web browser.



Does anybody have any tip about how to mitigate this vulnerability, with 
minimal assumptions about the client web browser?



The basic idea would be to patch any default setting (that could alter 
the user display ...) in the CSS specifications with explicit parameter 
setting associated with the HTML contents. In the above case, the IETF 
can protect itself with the following HTML markup text near the 
beginning of the file:


STYLE type=text/css:before{content:}:after{content:}/STYLE


The habit of storing css style information in various style sheets files 
separate from the HTML contents is worrysome as each stylesheet 
retrieval operation is a potential attack vector.



Thanks in advance. More specifically, with the hope that paranoia can 
sometimes be a productive state of mind, I remain paranoid-ly grateful 
for your answers.



--

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [EMAIL PROTECTED]


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Let's be paranoid about CSS (cascaded style sheet) as an application data integrity attack vector!

2008-09-09 Thread nico
On Tue, Sep 09, 2008 at 01:52:30PM -0500, Thierry Moreau wrote:
 Here is a simple exploit which alters the ietf.org main page. Insert the 
 following four lines

 [...]

 to the file /usr/lib/firefox/res/html.css

 [...]

 OK, this requires root access because the Linux community is generally 
 security-conscious. But you should see the general idea: paranoia leads me 
 to think of an adversary who would threatens application integrity (such as 
 the above) without leaving much trace of computer system penetration.

 [...]

 Does anybody have any tip about how to mitigate this vulnerability, with 
 minimal assumptions about the client web browser?

As the service provider you have little choice but to assume local
security on the client side IF you want to allow clients that you don't
control (and you don't really have a choice about _that_; most SPs don't
anyways).

I don't see how to mitigate all possible attacks you can imagine that
involve a compromised client.

 The habit of storing css style information in various style sheets files 
 separate from the HTML contents is worrysome as each stylesheet retrieval 
 operation is a potential attack vector.

You could say the same thing about AJAX, ...  This train left the
station long ago, and I was on it then along with everyone else.

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]