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."
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.
I knew, but... (Score:1)
Re:I knew, but... (Score:4, Funny)
Re:I knew, but... (Score:2, Insightful)
Re:I knew, but... (Score:2)
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.
Re:One of my old favourites... (Score:2)
If you find an upload.php script and it's not password protected, or use some other method of authentication, then you can upload files and utilise that websites bandwidth. If it doesn't block uploads of *.php, *.cgi, *.pl and maybe other files, you could well end up with the ability to run whatever code you want on the webserver (at low privilege, but you can still explore the website files and work you way up, e.g. dump out script source code and look for v
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.
Re:Interesting read, but... (Score:1)
MitM (Score:2)
Also, I haven't seen an unjustified anonymous RTFA comment get modded up that high since 99, what gives?
Re:Interesting read, but... (Score:1, Interesting)
but I don't think the issues with allowing update based on url, admin page accessable to all and file uploads are particulary xss and could be done by any user with a valid sessionid.
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
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:2)
Re:Some simple fixes would be sufficient (Score:2)
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:2)
If you don't think it's bad for security just check to see how many PHP vulnerabilities are limited to people who keep register_globals enabled.
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:2)
Re:Some simple fixes would be sufficient (Score:2)
Yes I know there are ways around that but there tend to be lots of people new to programming who start with PHP and they might not. In general I wish PHP did a better
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.
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:Some simple fixes would be sufficient (Score:1)
Re:Some simple fixes would be sufficient (Score:1)
You are correct. I read somewhere once that AOL users are on such proxies. Pissing off legitimate users are not worth the security gained.
It's 2006.. (Score:2)
Re:Some simple fixes would be sufficient (Score:2)
Re:Some simple fixes would be sufficient (Score:1, Troll)
Re:Some simple fixes would be sufficient (Score:1)
Unfortunately, that's not reliable. It has been known to happen that some networks use a load-balancing proxy scheme, such that subsequent requests from the same user can come from different IP addresses.
Re:Some simple fixes would be sufficient (Score:2)
I'm not a regular expressions expert (IANAREE?), but wouldn't this remove all periods from the filename? Someone uploading BigBoobs.jpg may not want it to be stored as BigBoobsjpg. '~' is also a legal character in filenames, and I'm sure there are others caught by the expression that I'm missing.
Re:Some simple fixes would be sufficient (Score:2)
Bad idea - using some sort of identification is good, but the IP address isn't the one to use - certain web providers (such as AOL) use a proxy scheme that can result in subsequent requests from the same user, even moments away from each other, appearing from a different IP.
Whether or not it's a bad thing to block AOL users from your site is a debatable point, but it doesn't change that it's a bad practice
Re:Some simple fixes would be sufficient (Score:2)
limit the session to the IP-address of the visiting user.
Yes, this is a good one - it also keeps AOL users from your site, as an added bonus!
use mysql_real_escape_string() on all database input, or better: the variable binding feature of PEAR::DB
It would be nice, but not always possible. If a site uses MS SQL or PostgreSQL, there is a good chance that the server wasn't configured with MySQL support, meaning mysql_real_escape_string() isn't available. Not everyone puts the PEAR library in. And a rec
Re:Interesting read, but... (Score:2, Interesting)
Boring... (Score:1)
Re:Boring... (Score:1, Funny)
My favorite quote from said article:
our db stores passwords in plaintext. Yes it's stupid, but I wrote this code 3 years ago and had no clue
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.
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:
Re:Ok? (Score:1)
Any serious PHP developer does this. Also, I wouldn't peronally choose to run or develop my software on PHP4. 5 is so much better. After having spent the past year developing PHP5, PHP4 is j
Re:Ok? (Score:1)
Although session fixation is another attack that programmers should account for and fix within their programs.
---John Holmes...
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 .Use whitelists. (Score:2)
Re:Additionally, checks for MSIE (Score:2)
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
Re:Ok? (Score:1, Interesting)
- Log the editor IP, and always send him the fake webpage, instead of the attack script... (so he won't get suspicious, and won't think about removing the link...).
- Allow some users to view the fake webpage, so they can comment back, saying "it works for them"... (even if you do the comments yourself, people will be less suspicious if the comment is from some user they know...).
- The third time someone visit your link (he was logged out if logged in, the first time he was visiting your link, a
Re:Ok? (Score:1)
Re:Ok? (Score:2)
Re:Ok? (Score:2)
Other similar attacks like this can use unvalidated user input to inject mail headers and data into seemingly unimportant contact for
Question,,, (Score:1, Interesting)
When they use Buzzwords for it.
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
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)
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:1)
Also, I agree that this article is a bit alarmist, but it's a
Re:Requires social engineering (Score:2)
---John Holmes...
Re:Requires social engineering (Score:2)
But you only made it "safe" to display on an HTML page or within a form on an HTML page. You're right, the options are endless and it's all depends on where the data is going. If all of your data goes to an HTML page or form, sure, you just protected it. If you have DELETE FROM table WHERE id = {$id} and $id can in any way come from user input, running it through htmlentities() doesn't protect you from crap. If you're taking the form data and placing it into email headers at all, yo
Re:Requires social engineering (Score:1)
Because I am forgetful and can't always remember to do something like this, I've gone as far as writing a function in a common include file that loops through $_REQUEST and sanitizes everything in it. As you probably know, $_REQUEST contains $_POST, $_GET, and $_SESSION. Then I would just use $_REQUEST for any input.
A function like this can take care of properly sanitizing / escaping s
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.
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:1)
Enforcing password restrictions is the best way to encourage people to write down their passwords;
just disable profiles after a set number of attempts.
Also 2 part authntication helps, especially when the users can be asked one of a set of 'personal' questions,
stuff they should know and not have to right down. Then a phishing attack has a lower chance of success.
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
Re:More Like a Phishing Attack (Score:1)
As if fate wanted to make it challenging, the maximum size of the HTML input field...
Someone who considers it challenging to send more than the maximum characters of an input field? And he's the one writing the article? I hope that was just flavour-text, not his true feelings about the "challenge"
crack (Score:1)
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
Re:With all due respect (Score:1)
Re:With all due respect (Score:1)
Re:With all due respect (Score:2)
To you and everybody else who keeps thinking this somehow discredits the article:
Moreover, I'm pretty sure that if he was a bit more clever, or a b
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:1)
Yes he does. If you had read TFA, you would have noticed the following sentance in the first paragraph!
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.
Re:Human engineering & login code (Score:1)
Re:Human engineering & login code (Score:2)
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?
Regular Expressions (Score:1)
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
XSS (Score:1)
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:Ugh (Score:2)
What do you think the "Scripting" in "Cross Site Scripting" refers to? It refers to client-side javascript. Please read some Bugtraq, or at least this FAQ [cgisecurity.com] or the Wikipedia article [wikipedia.org]. (The Wikipedia article is the easiest read. In particular, the section on types of XSS problems [wikipedia.org] is edifying.) Your example is a straightforward input validation bug in the browser, and it doesn't involve any scripting at all, cross-site or not, and therefore is not an XSS anything. It's just a malicious input that exploits
This isn't about XSS (Score:2)
1. It does not stop someone from URL hacking to edit the data of another client. This is just flat out poor coding.
2. It allows people to upload executable code and execute it, in this case PHP.
What XSS gives him is the potential to gain access to the site under another account. This was because the site maintains state by storing a session cookie. He can injec
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, ...).
Mod Parent Out Of Sight! (Score:1)
The issues are not with Javascript, but with the web application itself.
Your argument about there being some potentially unknown underlying issues could apply to HTML itself - as i said, retarded and uneducated - just scaremongering.
Someone just mod this troll out of my sight!
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:Looks OK to me (Score:1)
"Language is a virus..." - William S. Burroughs
Re:Looks OK to me (Score:1)
Re:Looks OK to me (Score:1)
Well, the grandparent poster was also talking about possible bugs in JavaScript interpreter which could lead to arbitrary code execution. Is well known that some any parser may contain buffer overflow bugs and the likes which could mean you can embed arbitrary code in every format, including HTML, and the most recent example being the PNG (and JPEG if i don't recall wrong) parsers. So while HTML itself cannot do anything, the pa
Re:JavaScript Must Be Eradicated From The Web (Score:1)