[cups.bugs] [LOW] STR #2698: Cross-site request forgery in CUPSHTTP-commands

[Michael Sweet]

Mikhail Simvulidy wrote:
> I can make a simple form that makes POST request from my page by
> form.submit() to any site - not just only localhost, but also another
> site, where you have authorized - no matter, using cookie or
> HTTP-authentication. Even if that site uses HTTPS! I can perform any
> action in your account, because my request would use your cookies or
> HTTP-credentials. Referrer checking or random variables would solve
> this problem since attacker can't change referrer in client's browser
> and he can't see a value of that variable.

Wrong, you can set any HTTP header, and in fact do *any* HTTP/IPP
request, via the ill-conceived XMLHTTPRequest Javascript stuff.

Cookies don't protect against XMLHTTPRequest attacks, and there is
nothing we can do in CUPS to "fix" this.

> Spoofing possibility of
> HTTP is in completely different area. Again, on localhost and HTTPS
> man-in-the-middle attacks do not exist.

Traditional man-in-the-middle doesn't exist, however if you have
access to the user's browser and do something within that browser,
that is technically a man-in-the-middle attack, just at a different
spot than is usual.  And that type of attack applies to all
connections...

What needs to happen is for browser developers to lock out GET forms
and XMLHTTPRequest to addresses other than the one used by the page
they came from, however that will likely break too many existing
sites to be accepted.

A useful stop-gap solution would be to just block any access to
127.0.0.1 and ::1 when then page isn't on localhost, however that
doesn't address malicious pages that access servers on your LAN -
browsers pretty much can do anything behind a firewall once you
open an untrusted page with your browser.

Firefox add-ons like NoScript are somewhat useful at blocking this
sort of attack (you have to enable scripting for a page/site to make
the attack work), however not all users have this add-on or know how
to use it and it's an on-or-off proposition - it would be nice to
just "crack the door open" and allow specific functionality without
giving a site full access to your browser.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com