digg

Facebook Connect Join Digg About

How to Crack a Website - XSS, Cookies, Sessions

informit.com — "Informit.com provides an insiders look at a real life XSS attack and how it was used to bypass the authentication scheme of an online web application, leading to "shell" access, and admin account, and more. XSS attacks are often discussed in theory — this walk through illustrates just how dangerous these types of attacks can be in reality.

Who dugg this? Made popular Aug 14, 2006

Digg DudeWhat is Digg?

Digg is a place for people to discover and share content from anywhere on the web. Digg surfaces the best stuff as submitted and voted on by the community. Take the Tour to learn more.

49 Comments

show profanity settings
expand all
  • SamKellett, on 10/12/2007, -10/+22Modded down simply because of the "(first post)".

    Excellent article for anybody who is interested in building a web application. There's nothing new here but it's good to know it.
  • fizzyalex, on 10/12/2007, -2/+14Use print view for a decent look at the article:

    http://www.informit.com/articles/printerfriendly.asp?p=603037&rl=1
  • caliform, on 10/12/2007, -1/+10Wow, the average digg-user really has something to say about the article, doesn't he? That includes me now, sadly.
  • GarethSaxby, on 10/12/2007, -0/+8Aren't you supposed to yell "OLD" instead? Or is that no longer customary for the elite sections of Digg?

    Anyway, as SamKellet said, this isn't just for the malicious types, learning how someone can work their way into your site to break things apart at the seams is something that every single web developer should know, and the first step to being able to prevent such things is understanding how they work.
  • gosix, on 10/12/2007, -1/+6Digg users are like drivers. We are all above average. Just ask!
  • jonrad, on 10/12/2007, -0/+5Don't you find it somewhat scary that someone who doesn't know about this is developing a website which contains such sensitive data? I'm not trying to be disrespectful, but it's a scary thought about how insecure information about us really is.
  • psyon, on 10/12/2007, -0/+4"The end result was that I had to make a user click on a link that first took the victim to my server."

    That kinda nullifies the whole thing. Did he manage to alter the login page before the XSS attack, or did he send out an email to every user asking them to click a link? In either case something else is more seriously wrong than the XSS attack.
  • psyon, on 10/12/2007, -0/+4What is wrong with storing a session ID in a cookie?
  • MicroBerto, on 10/12/2007, -1/+5Basic take-aways:

    1. Don't trust anything a user gives you, and certainly don't allow it to be spit out (or executed) in a script! Filter anything you don't need.

    2. Don't allow users to upload stuff to an executable directory.

    3. Don't let users a chance of executing a script that they ought not to be.
  • Trevahaha, on 10/12/2007, -0/+3This is actually an area where ASP.NET excels. With the combination of mac address and viewstate encryption, it really helps prevent these type of attacks. This check creates a hash signature of the ticket contents appended to the ticket, which allows the server to validate that no one interfered with the ticket by recomputing the hash and validating it against the signature.
  • jonrad, on 10/12/2007, -2/+51) PHP sessions are stored in cookies anyway (generally, sometimes they are stored in the URL)
    2) go = true is there probably for debugging purposes.
    3) you don't know what check_email_address does. Maybe it sets error = true? Oh yeah.
    4) He's still an incompetent web developer. But don't give false facts to support your cause, it doesn't help.
  • merreborn, on 10/12/2007, -0/+3"3. Don't let users a chance of executing a script that they ought not to be."

    This is why in our applications, EVERY PAGE checks for the appropriate security level. Even if there's a whole in one page that lets you *see* another user's data, the scripts that actually let you alter it re-check security, and inevitably catch you. We've had this save our asses several times now. For anything to go wrong, it'd require multiple points of failure.
  • duketime, on 10/12/2007, -0/+21) Let's see you throw together 100% secure code 100% of the time. I'm not necessarily saying that the developer in this case is the best PHP coder, but it's easy for you to note all of the flaws when **a security expert picks apart the flaws and presents them to you in an article**. Yeah, maybe if you had to go through who knows how many lines of code you'd miss (or make) the same errors this developer did.

    2) The replies to your post make a good point. Assuming you want a sessioned web site (read: remotely easy to use), then how do you suggest handling that? It should be clear that having the session in the URL (or in the page itself) is no more secure (and likely even easier to crack. The XSS attack on Myspace ( http://namb.la/popular/ ) I believe used ID information in the source to work. Cookies seem to me to be the best option (I'm trying to think of other means of handling this ... something with the db is the only other thing that immediately comes to mind). Present a solution before you start just lobbing criticisms.

    3) The point about uploading files into an executable directory is valid, though. It's essential to have private downloadables and uploaded content into a directory outside of public and have a separate request handle all of those uploads and downloads, if only so you can check security again.

    But, all in all, it seems to me like you jumped to the author's own recommendations, paraphrased them, and then went ahead and called the developer an idiot. You can do better.
  • armbo, on 10/12/2007, -0/+2damn, this was good. very informative on not only what he did, but why it worked. where can i find more like this?
  • inactive, on 10/12/2007, -0/+2So exactly how would you store the session id since you are such a bad ass web developer? HTTP is stateless. You have two options - Cookie or URL. If you think URL is better, you are fired.
  • MalDON, on 10/12/2007, -0/+2I find it sad how many sites can be exploited when it is so simple to prevent it!
  • Scruffydan, on 10/12/2007, -1/+3Sounds similar (not the same) as the Adrian Lamo case
    http://en.wikipedia.org/wiki/Adrian_Lamo

    Sure hope he wasn't arrested
  • RequiemAristos, on 10/12/2007, -0/+2Your comment can be read as "Wow, I didn't know about all this, maybe this tool will help" or "I know what I'm doing, but this may be a useful tool for making sure". I do hope it's the latter.

    The easiest way to not have a vulnerability? Don't trust user input, and understand what is and isn't user input. There's a bit more too it than that, but taking that basic concept to an extreme will get you more security than a testing tool.
  • merreborn, on 10/12/2007, -0/+2"If your web developer is so freaking stupid that he stores the session as a cookie"

    You have a better way?
    Storing the session_id in the URL is even _LESS_ secure.

    http://www.php.net/manual/en/ref.session.php#session.security
  • ReiToei, on 10/12/2007, -0/+2Should read "How to crack a really badly secured PHP web application"
  • detrate, on 10/12/2007, -0/+2Yeah... that script that got exploited is ***** for too many reasons to list... besides, if you're dumb enough to leave 'create_admin.php' on your server, you deserve to get owned.
  • mpeg, on 10/12/2007, -1/+3alert("PWNED BY MPEG LOLOLOL");

    oops
  • mathemagician, on 10/12/2007, -0/+2Nice to know about the burp-suite, will become very handy as I'm developing a web-app myself, which has to be secure due to the medical character of the stored data: I hate to think about all the possible holes and vulnerabilities :-)
    I hope the burp-scanner will be released anytime soon.
  • gosix, on 10/12/2007, -0/+1@Scruffydan
    Wow, never read about Lamo before. Another Sac resident!

    It sounds like the guy in the article knew the developer, so I doubt there was any problem.
  • Badfish, on 10/12/2007, -0/+1Now I'm a little rusty on XSS since I used to fiddle with XSS myself several years ago, just out of pure interest.

    I would look at security websites who publish vulnerabilities and exploits to help people who own forums fix the problems. Once I found a critical exploit, I'd look up the versions of forum software that the exploit is vulnerable to (certain exploits are only vulnerable to certain versions of the forum software), find a forum via Google search, and the rest you can guess. I never used the code maliciously, in that even if I granted myself Admin, I would take it away, e-mail the administrator the solution to the problem, and keep searching. It was a hobby of mine.

    I found that the administrators who are WISE about it, mostly forums with 10,000+ users, already have the vulnerability taken care of, but I found that the majority of those who were vulnerable to the code allowed HTML, Javascript, or PHP in posts. That is a HUGE no no. BBcode can suffice for forums. UPDATE your forum software and fix the vulnerabilities and you have a smaller chance of being affected by XSS.
  • JavaMac, on 10/12/2007, -0/+1First off, IMHO it's cool that this article is generating discussion and awareness regardless of what you think of it.

    But now I have a question...I guess I am missing something, but with the XSS link--assuming he created the link and found people willing to click on it--wouldn't it only return the cookie if the error message had been triggered? And if the error message had been triggered, wouldn't that assume the user wasn't logged in yet? The only way I see this working is if the victim was already logged and then clicked on a link, otherwise wouldn't you be grabbing an old session id that is expired? And I assume (obviously) the programmer erases the cookie when the user logs out.
  • jesstech, on 10/12/2007, -1/+2Invaluable.
  • utherwayn, on 10/12/2007, -0/+1Anyone who is good into security shares the motto, there is no safe system. The simple fact of the matter is Cookies or URL, doesn't matter theyre both insecure and can be forged. On top of all that it's pretty easy to think of a way around most every security measure but some good ones to look for are as follows.

    1. Multiple failed login attempts to any secure system lock that account and/or require some sort of user challenge question and/or reactivation. Or a system that implements you may only fail X logins within X minutes/hours/whatever.
    2. Any form of encrypted password should not be a simple plaintext md5, use salt to encrypt, (for those who don't know salt it is a random string of characters that is mixed predicatbly with the plaintext password in some sort of static operation that will allow you to test the md5 accuratly) or you can use a real encryption algorithm instead of just a simple hashing algorithm.
    3. Encrypted PHP Rendering. http://www.zend.com/products/zend_guard is one example. These systems are of course expensive, and they are slow (generally). You encrypt the entire output of the servers response, pass it back to the browser and theres some way to make it so view source actually displays the encrypted output instead of the decrypted output thus limiting the ability of your web pages to be source hacked. Of course someone with a custom standards compliant browser could pull the DOM data out anyway (and you might be able to do it with firefox DOM inspector as well, I don't know at the time I didn't use firefox's DOM inspector) regardless the browser has to know what to post back so the data has to in your memory somewhere.

    4. Theres a large number of frameworks that support authentication methodologies and you will generally get more bang for your buck from these guys because they try to implement authentication in such a fashion that it is generalized and reuseable, thus if you play within their framework you are adding value to your product when their authentication methods are updated.

    Prado v2 (http://www.xisc.com/)
    Prado v3 (http://www.pradosoft.com/)
    Symfony (http://www.symfony-project.net/)
    WASP (wasp.sourceforge.net/content/)

    Also worthy of note GACL (http://phpgacl.sourceforge.net/)

    Anyway thats the first bit of information that comes to mind and most of them are sort of common sense.
  • DarkJC, on 10/12/2007, -0/+1Everyone here is right: storing a session ID in a cookie is the best way. But don't use the standard PHP sessions. Sometimes it's better to fashion your own system. I had a system setup where it would not only check the session ID in the database to make sure it matches, but would also check the IP against the IP when the session was created. If there's a mismatch, it requires a relogin. That alone mitigates a lot of the security issues, in combination with other security "givens".
  • mathemagician, on 10/12/2007, -1/+2Oh well, the whole purpose of the project is to get some real-life experience. It started indeed as an external university project 2 years ago and we are probably not even halfway a fully operational system.
    During the whole dev. process I've learned vast amount of stuff about designing web applications (java btw) and I've taken great amounts of time to secure it. However I'm far from thinking I've eliminated most possible threats. Let's be realistic.
    Be sure: the system will not be going in a production environment until I'm (correction: WE are) absolutely, positively 100% sure it's mature enough.
    On the brup-suite: well always good to learn something new, even if it's not entirely new, but that doesn't mean we didn't look into security earlier.
    I appreciate your concerns though.
  • mpeg, on 10/12/2007, -1/+2alert("PWNED BY MPEG LOLOLOL");

    woops
  • jkramlich, on 10/12/2007, -0/+1"1. Multiple failed login attempts to any secure system lock that account and/or require some sort of user challenge question and/or reactivation. Or a system that implements you may only fail X logins within X minutes/hours/whatever."

    I would have to disagree with your recommendation. A jerk could inconvience legitimate users by simply knowing their username and attempting a failed login x number of times. However, what you can do is store the last failed login attempt on the server. If the last failed login attempt is within n seconds, simply deny to validate the login request, even if it is the correct user/pass combination. The reason is so that a brute forcer can't just look for a different output and deduce that the login credentials were valid.
  • utherwayn, on 10/12/2007, -0/+0@jkramlich, sorry how does that prevent the user from being inconvenienced?

    If I am brute forcing a website authentication through curl my algorithm is going to go for quite a while, that means that while I am attempting a brute force that account cannot be accessed because you are denying even valid logins within n seconds, I do like that idea but I would augment it further to include logging what IP the access is from and checking against if its the same, that would pretty much escalate the time needed to brute force to not in your lifetime. Of course in that case you would want the server to not blacklist the IP because that would indicate that the cracker has failed some sort of security measure. Definitely something I had overlooked.
  • mathemagician, on 10/12/2007, -1/+1oh, and it's the latter ;-)
  • amed, on 10/12/2007, -2/+2good read, didn't bother reading the whole thing though since I noticed that on the 2nd page or so, the author is promoting his book when it should be FREE!!!

    anyways, its actually a good that this article was published, Web developers needs to know that "dos" and don't" . My suggestion don't just buy a general book on website security, buy a book traget toward the program you are using ( ex: php, asp, perl, etc...)
  • hypoxide, on 10/12/2007, -1/+1This is simply phishing. Rather useless if you ask me. Its a hacker's last resort.
  • fiv3isaliv3, on 10/12/2007, -1/+1Waste of time to read. Most of it is common sense. Dugg it for the people who don't use common sense.
  • duketime, on 10/12/2007, -0/+0To paraphrase your comment:

    Useless, provides no meaningful content. Recommended because it will provide many with useful information.

    Edit: Oh I see the bit about the people without common sense. Yeah, judging from some of these comments, I didn't realize web devs were such snobs.
  • duketime, on 10/12/2007, -0/+0You're right. It is a form of phishing, but it was something that the website itself enabled, I believe.

    So he set his email to a redirect that would send him the user's cookie such that anybody viewing a page with his email on it would send him session information.

    This is something like what happened with the new Netscape some time back where you could submit stories with script in it. People exploited this by spawning popups or recommending digg, but you could have the redirect / cookie send in the script.
  • NapoleonGold, on 10/12/2007, -1/+0Well that was a lovely intro,

    I'm new to all this but interested and that article was a nice overview to jump off of.

    Dugg
  • Loath, on 10/12/2007, -3/+2Just for the masses: If your web developer is so freaking stupid that he stores the session as a cookie (there's no reason to do that for that situation) and allows you to upload files that YOU CAN RUN then you should fire his ass, preferably out of a cannon...into the sun! It's incredibly obvious by the first block of code he shows that the alleged web developer is not familiar with PHP (Like setting error = false after it's already been checked that it's false, and setting go to true then immediately checking if go is true.) I don't know anyone that is that stupid and I know a lot of dumb coders.

    Long story short, this kind of stuff is only possible if you have a really, really stupid developer and he just happens to make so many amateur mistakes that you can hop from one to the other. What this definitely is not would be "How to Crack a Website." This is more like "How to Know You Need a Mildly Competent Programmer."
  • spjmm0, on 10/12/2007, -5/+3according to a 16 year old that I was talking to all you need to do is "hack the binary" to hack websites.
  • glide256, on 10/12/2007, -8/+2You're just lucky print view is not trademarked.
    Or is it?
  • Casestheorm, on 10/12/2007, -10/+3Ah yes, this was on Slashdot...yesterday?
  • msodrew, on 10/12/2007, -10/+2I hate print view, its not GPL'ed.
  • gosix, on 10/12/2007, -17/+2"Fortunately, I knew both the developer and the owner of the website and was able to point out the deficiencies of the code and provide solutions to help keep the website secure from would-be hackers."

    I hope he got paid for it.
  • vanquish, on 10/12/2007, -26/+3your mom got paid for it
  • msodrew, on 10/12/2007, -34/+2Your mom's an excellent article... for ANYBODY!!

  • rayishu, on 10/12/2007, -78/+1WOOT THANK YOU SO MUCH i knew about XSS but not the Cookeis and sessions
    (first post)

  • Add a Comment

    Login or register to comment!
    Or, sign-in super fast with your Facebook account ...