Search options (Page 258 of 307)

Smartys wrote:

http://namb.la/popular/tech.html
#9 on that list

I'm about 90% through getting my head around this totally, so could still be wrong.

It looks like the above is only possible because the 'attacker' was able to run Javascript code in the context of the MySpace site. As a result, this code could know any cookie information it needed, and create an HTTP GET request supplying that cookie info in order to obtain the 'secret' token MySpace include in the form.

If I merely follow a link from my PunBB forum - even while logged in - to a malicious site, that site can send an HTTP request to my PunBB forum admin pages, but where will it get the cookie from? Without the cookie, PunBB won't give it the secret token; it can make my browser submit to the PunBB admin section, but the submission will lack the secret token, and nothing will happen.

Edit

The reason why I'm not keen on all this referrer checking is because I long since learned that you can't rely on the referrer to be there when you want it, and it's just too easy to falsify.

The MySpace exploit uses XMLHTTPRequest to do all the 'clever' stuff... and guess what, one of the options you have is to set any HTTP header. So, you could just make up an HTTP Referrer.

Try this URL or Google for xmlhttprequest:
http://en.wikipedia.org/wiki/XMLHTTP

thanks Jesus . I was waiting for help for a long time.,.....

Rickard wrote:

Aha. Maybe that was in a different topic.

Without the referrer check, it would be possible for a malicious user to construct a web page somewhere and then trick an admin or a moderator to visit that page. On the page, a hidden form would be posted via Javascript that posts to a page in the forums (an admin page or maybe someones profile). It would be easy to e.g. upgrade a user to admin status. However, with the referrer check, this wouldn't be allowed because the forums would check the referrer and notice that the form was posted from somewhere outside the forums.

I've been thinking about this problem.

I haven't tested it, but... the above scenario seems to be possible because when our hapless admin posts a form hosted on rogue.example.net site to punbb.example.com, their browser will helpfully send back cookies related to punbb.example.com and not rogue.example.net; the session will be valid, the form submission will go through. There's nothing in the form itself to validate whether it's genuine or not.

So, on the genuine admin page forms, why not output the session id in a hidden form field? This can then be checked with the form submission. The rogue site can't know in advance what session id to hack up in their nasty little form - and if they do know, then they don't need the form in the first place. You're already sending these cookies out in the clear in the HTTP headers, so having an admin being able to see it via View Source is no worse than being able to see it via View Cookies.

A variant on the above is to generate (and track) some new token especially for the purpose, perhaps cryptographically related to the session id. But I'm not sure that's necessary.

I think this would be less problematic than the referrer checking... which just bit me because I have more than one way of getting into my test site.