Judofyr: This isn't a question to ask _why. It simply cannot be done.
Stealing cookies is not the same thing as XSS, and locking cookies to
an IP address will not stop XSS at all. Locking cookies to an IP
address (as I wrote in my git commit where I removed it) will lock out
AOL users, and surely many others on large NAT based networks. We
aren't just talking getting logged out occasionally. Every single
request from an AOL user comes from a seemingly random IP address,
often from a different continent to where the user is. This is because
AOL user's don't have their own internet IP address. The network is a
giant nat, but it's a nat with several outgoing IP's, and every time a
connection is made, it's sent through a different IP.
In a world where IPv6 still hasn't gained serious traction and the
IPv4 address space continues to shrink, this practice is only becoming
more and more common. In some countries, they only have 2-5 IP's to
NAT the whole country through.
To understand why we can't fix XSS in the cookies handler you have to
understand what XSS is. Imagine a bank, who has a camping app for
internet banking. Imagine they have a /login controller, and a /
transfer_monies controller. XSS is when a bad person creates a webpage
with a tag in it capable of loading remote resources, like img, and
sets the src attribute to http://mybank.com/transfer_monies?to=888422243name=Hahahahaha
Then they direct the user to this page, which could be on myspace or
anywhere else html embedding is allowed, while the target is logged in
to their banking website. When their browser reaches the page, and
parses the img, it throws that get request on to the queue, and when
it gets around to it, it goes right ahead and loads that address with
a get request with all the users cookies in tact. This can't be worked
around by requiring important things to be done with the 'post' method
either as it is incredibly easy to make an invisible form that
automatically submits as soon as it is parsed.
The one attack binding cookies to the user's IP address prevents (in
countries and ISP's where each user has their own IP address, and
their ISP's don't allow other user's to request a specific IP from the
DHCP server's and get it if it is available now) is someone who
inserts a script or a java applet or flash player in to the page,
and then puts scripting in the script, applet, or flash, to read the
value of document.cookie, url encode it, and send it to a remote
server the attacker controls... or even just to a guestbook or
something. The lesson here is don't let your user's embed nasty html
code if your site has valuable stuff in it, or if you have admin
accounts that can do damage if stolen.
One way to put a stop to XSS attacks is to require important requests
to have a token on the end, something only the server knows. The token
is added to all the links that change some state on the server, and
all of those controllers have to check it and instantly redirect the
user back to a page where there is no token. If they don't redirect
back, the user is left on a url with a token in it and they are then
vulnerable to social engineering.
I've put up a simple implementation of this here:
http://code.whytheluckystiff.net/camping/wiki/XssBeGoneWithSessions
But I'm sure you can imagine why this process cannot be automated.
Camping can't know which controllers are important and which aren't,
and the user still has to consciously make them redirect back to some
place. Using that little script, the attacker can't figure out the url
to put in their img and so they can't make a valid request. One
thing that would also help against XSS would be to dump all requests
that have a referrer from some place else, but then.. nobody would be
able to get to your app from a link on some website anymore.
All these things are far beyond the scope of Session anyway. I feel
very strongly that if you make the cookies locked down to an IP
address then you are making camping incompatible with the internet.
On the plus side: Yay! We have working sessions! ^_^
Does the stuff I changed now work? Can you safely use @body, @headers,
@cookies from anywhere inside a service?
—
Jenna
On 07/06/2008, at 6:06 AM, Devin Chalmers wrote:
On Fri, Jun 6, 2008 at 6:07 AM, Magnus Holm [EMAIL PROTECTED] wrote:
It looks like everyone has tried to fix the cookies lately, and no-
one managed
to get it 100% correctly...
Thanks for the code, that seems to work really well and prettily. I
admit that, though I love writing apps in it, I am very new to
hacking on the dark underbelly of Camping. (Me, I just wanted to get
sessions to work in the Junebug wiki for a Ruby class I'm teaching
some friends.)
Your new patch makes sense to me. I'd be interested to hear a
discussion of why the Bluebie version didn't work, because I thought
that made sense too. :)
