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."
One of my old favourite's oopsies are upload scripts that don't prevent you from uploading PHP or other web script files.
It's amazing how many webmasters leave little scripts in their public directories not stopping to think search engines may find them.
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.
So you're going to rely on user's intelligence?
You're not a coder are you.
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.
This is a perfect example of a shoddily developed website.
.php extension (or others depending on configuration) through the PHP parser. If there is no reason for a user to be able to upload files of this type, basic sanitization should be in place to prevent the upload of these file types, or, more easily only allow files with permissable extensions to be uploaded. The second issue is related to basic site administration, unless there is need for direct access to the files, uploads should be located in a directory outside of the webroot, preventing direct access to (and possible execution of) these documents. If direct access is require, all external handlers should be disabled for that directory by the simple usage of a .htaccess file. This would mean that any uploaded scripts/executables would be treated in the same manner as a regular file, and be downloaded as opposed to 'run'.
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.
Sure, depending on the site. If they let you post information to the site, like having a guest book, then you may be able to exploit a xss.
Also depending on what you want to do to their site, if they let you upload files, but don't handle it well. ie, they may let you upload pictures of your girlfriend/sister, but they don't check to see if it is a jpeg file, or a php/cfm/asp file. Also, they may let you execute that file from that directory or not.
Any site designed badly can be used.
I remember some free pron sites, trying different number at the end of pictures to get extra freebies, or trying different directories based on names. Even a google image search of that particular site would reveal a lot of extra images or movies.
- limit the session to the IP-address of the visiting user.
- use htmlentities() on all outputted HTML
- secure file uploads to avoid uploading PHP code
And most important (but not relevant for TFA):Things like require_once("files/" + $input + ".html") actually read php files when it's called as ?input=file.php%00
The best way to accelerate a windows server is by 9.81 m/s2