How to Crack a Website - XSS, Cookies, Sessions 167
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."
Ok? (Score:5, Informative)
What are the chances that:
1) A user will go to the bad guy's website
2) That the user will have an account on the attacked website
3) That said user will want to log into the attacked website right after going to the badguy website?
Sure, it is possible and a potential risk, but it sure seems to be highly-specific, probably only good if you are targetting known users to begin with.
Re:Interesting read, but... (Score:3, Informative)
RTFA. The whole A. 5 times or until you realise how dumb u are, whichever comes later
Re:Requires social engineering (Score:5, Informative)
Re:Interesting read, but... (Score:4, Informative)
This still doesn't change the fact that what he is doing relies heavily on phishing/getting a user to go to his server first to gain initial access to the server, which, IMHO, makes this more than just a hack- it relies on social engineering/hacking/whatever you want to call it. It is just another form of playing off a user's lack of knowledge/ignorance, and letting unsterilized (sanitized, whatever you want to call it) data pass to the server. That being said, if you can get a user to fall for a "click here, come to my server to log in to your server", you can probably get a lot more out of them than just a session ID.
As I said- it is an interesting article, but what it really boils down to is what should have been pounded into every web developers head from the start- make sure there is no way to inject melicious code into your POSTS.
Re:Ok? (Score:5, Informative)
1) A user will go to the bad guy's website
Well, that's the hard part, but you could even try using an HTML formatted mail.
2) That the user will have an account on the attacked website
The place to put the code injection was on the login screen, so it's open for anyone. You could hide the login page in an invisable iframe.
3) That said user will want to log into the attacked website right after going to the badguy website?
The important thing is that the target logs on during the timeframe where the cookie is valid. If you're lucky and the site uses a permanent cookie, you could even take over a login session from days ago. If it's a session cookie you could take over a previous session if the user didn't close his browser after previously using the admin application.
With all due respect (Score:5, Informative)
Additionally, it is, in certain respects, a retarded piece of journalism.
The XSS mentioned requires the use of phishing techniques - why not simply capture username and password and this point of the exercise, it will allow you to regain entry once the session expires, and will allow you to overcome and further validation that the session handler may require.
The XSS technique itself, printing the value of the cookie data via javascript to perform a get request to the evil server should not occur in the first place. That is simply shoddy website development. Sanitize input, escape output. Its not more difficult than that. Any developer who fails to grasp this most basic concept should not be in that line of work.
Secondly is the ability to transfer a session. In the example, the attacker utilizes a third party utility to modify the request data. Why he has done this is beyond me - much easier to simply edit the cookie itself, or even pass the session id back as a 'get' request, a tehnique accepted by default on many PHP installs. It is rather basic to overcome this kind of attack by utilizing a more sophisticated session handler, although this is rarely done as it is taken as a given that the attacker is not going to easily obtain a session ID.
Thirdly, is simple abuse of a poorly designed web application. There is no validation in place to ensure that the user has permission to perform a task on a designated object. In this case, there is no validation to ensure that user 42 has permission to modify data related to user 36. This is simply poorly designed, and again would not happen where a developer has half a clue about what he is doing.
Finally, is the mother of all attacks - the ability to upload and run abitrary code. This is a combination of two blatantly obvious (to those who are not clueless) issues that should not arise in a professional web application. Firstly, is the ability to upload files of a certain type. Apache, for example, doesnt require PHP files to be marked as executable, it will simply run anything with a
In short, this was a very poorly designed web application. It didnt take into consideration any secure web development practices, such as Sanitization, Validation, Authorization and Limitation.
Unfortunately, in todays climate, every man and his dog is a web developer, and 99% of them are complete and utter idiots.
Re:Ok? (Score:5, Informative)
Cross-site scripting attacks are possible through many different vectors - sometimes you can include it in a GET address (e.g. 'image.php?name=foo.jpg&caption=<script goes here>'), sometimes in text submitted to the website (one I saw wasn't escaping private, inter-user messages - so I promptly sent Javascript to the administrator), or whatever.
Essentially, if you can get the website to output your own text in an unescaped form (i.e. '>' and friends aren't converted into '>' etc.), you can print raw Javascript, which the user's browser promptly executes. Javascript is quite a helpful language, so has functions for getting the values of cookies, etc. - which you can then send off to a third-party server under your control.
I had to do a rough security audit about a year ago on a website. From knowing absolutely nothing about the specifics of cross-site-scripting and SQL injection attacks, in a couple of hours I was hijacking administrator sessions or getting the website to dump passwords, private data, you name it. It was embarrassingly easy. So, some tips for web programmers on the receiving end of all this:
Some simple fixes would be sufficient (Score:5, Informative)
Things like require_once("files/" + $input + ".html") actually read php files when it's called as ?input=file.php%00
Additionally, checks for MSIE (Score:5, Informative)
MSIE also allows developers to execute JavaScript in CSS code. A forum which translates
to is vulnerable when you can enter .Re:Question,,, (Score:3, Informative)
Few of the self proclaimed "admins" have a clue. Fewer know what they're doing and a selected, carefully handpicked number can actually understand what that article is about. Essentially, as long as there is no out-of-the-box fix for this issue that can be used by even the most braindead zombie out there, a hacking method retains its worth.
If you're just looking for a bounce-off server, it's usually fairly reliable to assume that you can find a clueless victim easily. If you're targeting something specific which has presumably an admin with a Clue (capital C not a typo), anything that's been out for over a month is worthless. No matter whether it's been buzzworded or not.
The Cross Site Scripting FAQ (Score:3, Informative)
http://www.cgisecurity.com/articles/xss-faq.shtml [cgisecurity.com]
Re:Some simple fixes would be sufficient (Score:3, Informative)
check_login( $user, $pass );
if( $login == true )
{
}
else
{
}
Ooops! With register_globals on, if I do ?login=true in the URL, suddenly I have access!
Granted, the function should return the variable and it wouldn't be a problem. But with register_globals off, while the code would still be bad, it would be harmless, and there are more complex examples as well.
I don't get register_globals anyway, unless you're doing something really short (and even then questionable). With a large application one needs to be able to determine where variables are coming from. register_globals hides this, and makes it easier for the newbs to blow their whole leg off instead of just shooting themselves in the foot.
PHP really needs something equivalent to Perl's taint mode (-T switch). The program dies unless you check the variable against something. You can still get around it but at least it makes you think twice before pulling the trigger.