Slashdot Log In
How to Crack a Website - XSS, Cookies, Sessions
Posted by
CmdrTaco
on Mon Aug 14, 2006 03:48 AM
from the waste-your-time dept.
from the waste-your-time dept.
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
So... (Score:5, Funny)
... can I crack pr0n sites with it?
(This would have even been a frosty piss if it weren't for a Slow Down Cowboy!)
Re:So... (Score:5, Interesting)
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.
Parent
One of my old favourites... (Score:5, Interesting)
It's amazing how many [google.co.uk] webmasters leave little scripts in their public directories not stopping to think search engines may find them.
Interesting read, but... (Score:5, Insightful)
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.
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: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.
Parent
MitM (Score:2)
Also, I haven't seen an unjustified anonymous RTFA comment get modded up that high since 99, what gives?
Some simple fixes would be sufficient (Score:5, Informative)
- limit the session to the IP-address of the visiting user.
- use htmlentities() [php.net] 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
Parent
Re:Some simple fixes would be sufficient (Score:2, Insightful)
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.
Re:Some simple fixes would be sufficient (Score:3, Insightful)
Re:Some simple fixes would be sufficient (Score:3, Insightful)
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
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 la
Re:Some simple fixes would be sufficient (Score:5, Insightful)
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.
Parent
Re:Some simple fixes would be sufficient (Score:2)
There are a dozen of isp's out there that have load balancing on their proxies based on the idea that the dns record of the proxy has multiple hits as ip addresses, now if the user computer hops from one to another, it seems to the server that the "client has changed his address", if you cut the wire here, the users will just be angry and disapointed. It would be very annoying to login everywhere again if your dog knocks over your dsl modem and you lose
Re:Interesting read, but... (Score:2, Interesting)
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: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.
Parent
Re:Ok? (Score:2)
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:
Parent
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 .Parent
Re:Ok? (Score:2)
Re:Ok? (Score:2, Interesting)
> What are the chances that [...] a user will go to the bad guy's website?
>
Example:
The attacked website features a news commenting system. You write a good comment, or a joke, and you link to a website you control (but you should say it is not your website -indirectly, don't insist...), maybe asking people their view on the link... You might make the link looks like "http://www.example.org/2006/08/Foo_article_title" . A lot of people will just click the link. The page redirects back to the attacke
Requires social engineering (Score:5, Funny)
I think this is the reason why people aren't that concerned about XSS. This requires that the attacker knows someone who has access to the web site and a way to get him to click on the link. I would certainly never click on a suspicious looking link. But sure, not everyone does that and if there are other post-login holes to get yourself into an admin, that's a problem for you too.
One thing that annoys me when discussing XSS problems and such is that people always just suggest to validate input. I've built perfectly secure PHP applications that don't validate input at all, they just don't print the output using "print" but another function that properly escapes the output. So much more easier that way than having to think about input validation for every single new field you add.
Re:Requires social engineering (Score:5, Informative)
Parent
Re:Requires social engineering (Score:2)
Sure that works if all you do with the string is print it out. Now what if you also want to store it into a SQL database, as is usually done? You'll have to unescape it before inserting it, or alternatively both waste more space in the database and remember to have to NOT escape data that comes from the SQL database so it won't get escaped twice (< shown as <). And if you're not escaping data that comes from SQL database you better make sure that ALL the data that is stored in there is escaped. An
Re:Requires social engineering (Score:2)
---John Holmes...
Input validation (Score:2)
If I hadn't seen more examples than I care to count of code written by people who felt it unnecessary to a
Re:Input validation (Score:2)
Sorry, but I don't agree. I think if you rely on user input validation you're going to have more security holes in your program than if you built it from the assumption that every single string in your code may contain whatever data. It's much easier to figure out where the few problematic areas are (typically only printing and SQL queries, maybe also writing to logs) and just make sure that those are done securely no matter what their input is. If your security comes only from validating the user input, th
Re:Requires social engineering (Score:2)
OK, so what do you do with the input? Insert it into a database? Pass it as a parameter to a shell application? Unless you're going to just drop it on the floor, almost anything you do can be exploited.
More Like a Phishing Attack (Score:5, Insightful)
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.
Re:More Like a Phishing Attack (Score:5, Insightful)
You're not a coder are you.
Parent
Re:More Like a Phishing Attack (Score:2)
Have you not heard the addage "a system is only secure as the person administering it"? Until systems are designed by and administered by infallible, AI capable machines, then we will always be strapped to the lowest common denominator - the user using the system.
I can write the most secure web application known to man, purchase a digital certificate, require users to
Re:More Like a Phishing Attack (Score:2)
Yes. You created an user authentication scheme which requires the user to memorize a long, meaningless list of characters, and in
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:With all due respect (Score:2)
No, it's an example to those "complete and utter idiots" out there that write off XSS attacks as meaningless.
The XSS mentioned requires the use of phishing techniques
Sure, this one does, but many don't even require that. Many take input directly from the URL so you don't have to use a third site. The passed info in the URL can be obfuscated, too, so it's not obvious that some JavaScript is being passed. Don't say this is a retarded
Human engineering & login code (Score:5, Insightful)
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.
Re:Human engineering & login code (Score:2)
Didn't have to; he used an XSS hole in the site to steal the user's session cookie. As long as the user was already logged into the victim site, all he had to do was to get them to go to his page, and voila.
Umm... (Score:2)
I would have thought the answer was obvious... It's probably an Open Source CMS framework of some sort, and the code is available at sourceforge.
The second question is answered by phishing. I get these all the time for paypal.com.
The Cross Site Scripting FAQ (Score:3, Informative)
http://www.cgisecurity.com/articles/xss-faq.shtml [cgisecurity.com]
Meh. (Score:2, Funny)
XSS is not the biggest problem (Score:3, Insightful)
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?
Use Chroot jail and block outgoing http/ftp reques (Score:4, Interesting)
Run Apache web server in chrooted jail where bash or any other shell/commands are not available to attacker
Run almost all critical services in chrooted jail
Use dedicated DB server
Other extreme solution - is to put root file system on read only media such as CDROM (not useful for everyday)
And yes I know that no computer system can ever be completely secure, you can make crackers job hard only with above techniques
Just my 0.2
Ugh (Score:3, Interesting)
The article uses an awful example of an XSS exploit. The vast majority of XSS exploits don't have to jump through the hoop of an HTTP POST, so they're mindlessly simple to pull off, and there's no phishing involved. Plus, the fact that he used a proxy to modify his own web browsing is a complete red herring and detracts from the article.
In contrast to phishing (and in contrast to what's been said in most of the posts so far), an XSS exploit is a legitimate link to the target website. No amount of looking at the host part of the URL will tell you that it's a phish, because it truly, honestly isn't. If you take the time to manually browse the GET parameters individually before you click the link, you might catch that it's an XSS exploit (or an attempt at one) if you know some HTML and Javascript.
What's worse, though, is that instead of a clickable link, the exploit could even be the URL of an <iframe> tag. Completely automatic, no clicking required, and AFAIK no modern browser allows the user to disable or manually confirm <iframe> tags. Even worse, XSS attacks on some sites are persistent and shared. For instance, if someone home-rolls their own comment system and forgets some checks, it might be possible to post an XSS exploit in the subject line of the comment, which not only affects everyone who reads the post, but also everyone who even reads a list of new messages.
The important characteristic of an XSS attack is that, unlike most web-based attacks, XSS attacks are exploiting the website itself -- not you, and not your browser. You click the link, the website ships some HTML to your browser, and whaddya know, there's one of them newfangled <script> tags to run.... The injected Javascript code, which the webmaster didn't intend but nonetheless his website actually delivered to your browser, runs with the same permissions as any of his own code, which includes access to the document.cookie property. Since most websites these days stick session IDs or even *groan* username/passwords in cookies, all it takes is for the Javascript to e.g. generate an <img> or <iframe> tag that points to the attacker's website, with '?'+document.cookie tacked onto the end of the GET request. Now the attacker can log in as you, and can explore other, non-XSS exploits that require him to be logged in.
Your only recourse as a user is to disable Javascript. Full stop. You can't even enable it on "trusted" sites, because if you mark them as "trusted", you're saying "I trust that this website will never, ever be hacked so long as I live". One or more of your "trusted" sites might have undiscovered XSS flaws in their backends, and you can't "untrust" them faster than the blackhats can exploit them.
There is nothing, I repeat nothing that you can do as a user or as a browser designer that will simultaneously (a) prevent XSS and other server-side exploits, and (b) allow the features that modern web sites depend on by design. If you think you want a browser that's completely safe from server-side exploits, spend a week browsing the web using strictly Lynx [browser.org], then see if you're still of the same opinion. (While XSS requires Javascript to pull off, there are other server-side data validation problems on many websites, and those can be exploited by something as innocuous as a CSS stylesheet reference.)
Re:JavaScript Must Be Eradicated From The Web (Score:2, Insightful)
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, ...).
Looks OK to me (Score:2)
Javascript is an easy way for somebody else to start software running on your computer. Unlike java it doesn't really have a security model. If you browse from within your intranet the javascript code you pick up from elsewhere can do things on your LAN. That can't be good.
HT
Re:Looks OK to me (Score:2)
Re:I knew, but... (Score:4, Funny)
Parent
Re:I knew, but... (Score:2, Insightful)
Re:I knew, but... (Score:2)
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