Summary
JavaScript is not as innocuous as some would like to believe.
Advertisement
There was some doubt in the follow-up to my last blog entry about whether JavaScript, or other scripting languages for that matter, can be used to mount effective XSS attacks.
Unless you disable scripts in your browser, you can, as I hope to show here.
Here is a button that shows your session cookie and takes you to my web site.
The cookie is not sent to my server when you press the button, but, technically, there is nothing stopping me from doing that.
I can then hijack your session, for example.
But I thought the whole idea behind using cookies was that they are the only thing the browsers let you get/set on the client system and are pretty innocuous -- they only contain a little scrap of data from the site you are on (in this case, a little ID info so Jive can show you your watches). Can you use that information to do something nefarious? After all hijacking my session is not much worse that pop-unders, is it?
For example, if I click the button and you do collect the cookie info on your web site, could you then use that to get into my Artima account (by having your browser sending it or something) and post a bogus blog by me?
I do not know the ins and outs of Jive, but my guess is that, yes, I would effectively be you as far as Jive is concerned if I pass it your session cookie. So I could then start blogging as Matt, change your password, ...
I have always felt that being to see, let alone change, the values of cookies on the client side was not a feature.
i.e. a.) Cookies should only be able to be set from the server side. b.) The browser remembers and passes back a server's cookies. c.) But client side code can not examine or change cookie values.
I think this was the original intention but was somehow lost.
Previous Topic
