Slashdot Mirror
How to Crack a Website - XSS, Cookies, Sessions
twistedmoney45 writes "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, an 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."
Sure, it is an interesting read.. that being said, nothing here is exactly shocking.
I may be reading this wrong, but, he gains access to the server by requiring a legitimate user to log on to the site, through a third party server of his (Might be done via phishing, etc..), then he nabs a valid php session id, via some injected javascript code. Why not just grab the users login and password when they submit the form through your server? If you already have them logging in via a proxy, this would be much easier, and more reliable- sessions expire, etc..
As with most of these articles on security- simply make sure you sterilize any incoming data. Again, its not exactly rocket science.
As if fate wanted to make it challenging, the maximum size of the HTML input field for the email address was 25 characters, and it only accepted POST data, which is somewhat limiting. As a result, I had to "outsource" my cross-site scripting attack to a third server. The end result was that I had to make a user click on a link that first took the victim to my server.
Sounds more like a phishing victim than anything else to me. I understand that the rest of the article brings you through the process of session hijacking, etc., but to me the real problem here is the phishing "attack" and the misuse by the user. Is a system really insecure if the user is diligent in what links he clicks on in this instance? I mean, if I leave the keys to my car in the ignition it's not going to take a skilled theif or laser cut keys to steal my car and the security implementations taken by the manufacturer won't matter.
Hagrin.com
While the crack is technically interesting the article doesn't answer two things: first how did he get the code for the login screen and how did he get a user to login via his evilsite.com mockup of the login screen.
Maybe he could guess that the email variable was printed unfiltered, and thus vunerable to XSS-attack, I dunno how he would get a user to login via a unrelated URL.
---
"The chances of a demonic possession spreading are remote -- relax."
Wrong, the root cause of all these exploits is developper's stupidity, JS is merely an attack vector, as is flash, and the only way to use them as attack vectors is if there are holes in the application (ability to upload executable files or scripts, reliance on unsafe authentification/securisation schemes, ...).
How about "forbid the upload of anything executable, be them script files, scriptable files (flash), CGI files (Python, Perl, ...) or executable pages (PHP/ASP)"? Of even better, "only ever allow uploads of explicitely specified file types, and validate every single file against these types explicitely at upload"? No amount of blacklisting will ever beat whitelisting.
Or use PHP5's mysqli_ or pdo_.
And if you absolutely have to include third-party files, use readfile as it passes the data right from the file to the output buffer without ever executing it.
Also use readfile when you include parts of templates that don't and shouldn't have executable (php) code.
Of course, the best advice one could give to a PHP developer would be "first and foremost, don't use PHP".
Why? There's no security gained by making this change. Shitty programmers can write shitty, unsecure code with register_globals enabled or disabled. I guess if you make a habit of running just anyone's code on your server, then turning this off may disable a specific vector, but certainly not all of them. The whole "register_globals enabled is bad for security" myth is just that. Bad programmers are bad for security and always will be.
---John Holmes...
Is this really a good idea? I've heard stories from people on mailing lists who claim that many people are behind routers/proxies that cause IP changes very often, and that's restricting a session to an IP causes more problems than it's worth.
It's easy to do a lot of things you shouldn't do, so it boils down to a question of ethics really, doesn't it?
The biggest problem here was not the XSS attack. Even w/o the XSS, this attack could have been carried out. The real problem here was the ability to upload executables. Even basic unixy permissions should stop write access to the web directory. Unescaped strings happen. (Especially when programming in these type of languages, which is another entire discussion.) The fix isn't to modify the thousands of print commands. It is to fix the one permission setting.
Suppose you want to keep mice from getting in to your flour. Do you seal every crack, windows, vent, hole, and drain in your house? Or do you put the flour in a sealed container?
How about, when people upload files, don't store them in a folder accessible to the outside world, which means they can't be run. It makes more sense to store them somewhere else, so that even if they upload a .php file, they can't call it. Also, when sending the files back downstream, ensure that it isn't in a way that will execute anything on the client side.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Having register_globals on does exactly what it says. Anything passed via get, post, cookies, etc becomes a global variable. If you do if ($username) assuming username is a session variable, people can just submit it via get and bypass your authorization code. So you turn off register_globals and use if ($_SESSION['username']) instead.
Of course disabling this setting (not enabling it like a moron actually, its been disabled by default for years and even the PHP developers tell you its a potential security risk) won't magically make your code perfectly secure. Just because you could still make security holes, doesn't mean you should just leave every possible security hole wide open.