Re: recent 'cross site scripting' CERT advisory

[metal_hurlant () YAHOO COM (Henri Torgemane)]

I believe you're not talking about the same kind of attack..
You're thinking about the traditional problems, where the servers tries to
protect itself from evil clients.
CSS is about a server trying to protect good clients from an evil third party.

For that purpose, the server should trust good clients in order to prevent
third party attacks.
If that trust gets abused, at most, someone will be able to grab his own
cookies, or modify his own form entries. Not a big deal.

However, relying on that REFERER thingy to solve the CSS problem is risky.
It's probably not reasonable to compare REFERERs to a set of every valid URLs,
so most implementation would simply check if the hostname or IP is valid.
This means it only takes one unprotected script somewhere on the web site to
completely void the benefits of the check:
The attacker would simply have to pipe his attack through the unprotected
script to then have full CSS abilities.

But if it is done right (i.e.: you're explicitely specifying which files don't
need a REFERRER check, rather than trying to keep a list of every script that
needs it), I believe it can provide instant CSS protection without having to
audit all these server scripts right away.

Regards,
Henri Torgemane

Ari Gordon-Schlosberg wrote:

> [Bill Thompson <bill () DIAL PIPEX COM>]
> > One form of protection from a truly *cross-site* attack that I didn't
> > see mentioned in the CERT advisory is the trusty "HTTP_REFERER"
> > check. But then, with so many sites using affiliate programs to get
> > their search boxes and book-buying links distributed across the Web,
> > there may be few major e-commerce sites that block requests based on
> > the referral source.
>
> HTTP_REFERER is trivial to spoof, and it's likely that anyone perpetrating
> a sophisticated attack would laugh at having to spoof the Referer: header.
> It's a form of trusting the client, which is a big, huge, no-no.  It's okay
> if you're trying to protect from someone seeing a page that should
> register for (like downloading a white paper), because it's not worth an
> attackers trouble to circumvent something like.  But Referer: should never
> be used as a security measure.  Hell, anyone with telnet can spoof a Refer:
> URL.
>
> --
> Ari                                                     there is no spoon
> -------------------------------------------------------------------------
> http://www.nebcorp.com/~regs/pgp for PGP public key