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."
... can I crack pr0n sites with it?
(This would have even been a frosty piss if it weren't for a Slow Down Cowboy!)
Ignore this signature. By order.
shown like this, step by step, its even more scary. I mean, why shouldnt someone do that...its really easy.
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.
I suspect many slashdotters may have written CGI's that were vulnerable to XSS back in the day. Once XSS type vulns were known about, that was the end of it. If I wasn't capable of sanitizing user supplied data, I'd be shamed into finding a career other than web development. Users can disable moderate developer incompetance by disabling javascript, unfortunately higher levels of incompetance (sites that do not function without javascript) are also common.
So, after a quick read, it looks like the attacker has to convince a user to get to the attacked website via his own website - how else would he be able to forcefeed his own code into the $error variable to begin with?
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.
When information is power, privacy is freedom.
How do you know if a hacking method has become unreliable and worthless?
When they use Buzzwords for it.
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.
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
need crack for slashdot
As an administrator, if I were the BOFH, I could just create a dummy DNS zone for yahoo & force all the users on my network to sign in via my own personal sign-in page capturing all their user info in the process... or as an outside attacker, do some DNS poisioning to achieve the same result.
While first of all, none of this is actually new in any way or form. I thought most of the normal /. readers would know most of this, including at least anyone who actually codes in PHP
the real crux is that half of what was done, was only accomplished from a VERY poorly written site, such as not checking the user's id against the user who created the "update list". Stuff like being able to change a id variable and being able to see other users data is just basic poor php coding. Then you have the create admin page, which didn't seem to check the user's id or auth level.
It's the sort of article you would expect on "hackinpr0z.com"
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.
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, ...).
Hear! Hear!
Especially, I would like to emphasise this:
> Petition web site developers not to use JavaScript, or, at minimum, to produce sites that are fully functional when JavaScript is turned off in the user's web browser.
Thats one of the most retarded and uneducated posts I have read.
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!
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.
HTML is a markup language. It can't do anything other than display a document.
http://michaelsmith.id.au
http://www.clock.org/~fair/opinion/javascript-is-e vil.html
Mod parent plagiarist.
If I hadn't seen more examples than I care to count of code written by people who felt it unnecessary to authenticate user input I would think you trolling. Input validation is not optional any more than checking people's security clearance is optional before letting them into the Pentagon archives. Input validation is something you should always do regardless of what type of software you are writing, since it helps to prevent more than just code injections like this one. You should be especially careful to verify any and all user input if you are writing applications that are exposed to the general public. A Hacker will punish you for every mistake and failing to verify that input to the login field has the structure of a valid user-name/email-addess is a pretty basic error to make, especially since there are recipe books outlining how to do this and it would surprise me if you couldn't find a utility library containing commonly use validation routines on source-forge.
Only to idiots, are orders laws.
-- Henning von Tresckow
Nice Satire/Troll piece. pity there isn't +1 troll
- 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
Dear web 'developers',
Please learn how to write production quality code before putting your code into production.
Kind regards,
Common Sense
MSIE also allows developers to execute JavaScript in CSS code. A forum which translates
to is vulnerable when you can enter .The best way to accelerate a windows server is by 9.81 m/s2
http://www.cgisecurity.com/articles/xss-faq.shtml
Believe me, if I started murdering people, there would be none of you left.
I was just hoping for a text box and a button saying "Crack Website!"
I say: "Lets hope the web developers of http://client.webdesigngt.com/ don't wring your neck for failing to sanitize your screenshots, boasting at their expense, planting backdoors (you were asked to *test* it), and for forgetting to take your medicine."
As far as "how did he get the code for the login screen"?
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 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?
It's "piqued my interest", not "peaked my interest" (page 3).
It woul be interesting anyone posting any java regular expression for detecting XSS attacks XD Tnx!
I found that if you block outgoing http/ftp requests from your webserver attacker can not install his/her code.
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
The important thing is not to stop questioning --Albert Einstein.
When I first learned about php I read about XSS and SQL injection, I thought that sanitizing output/content to be used in queries was security 099 . I eventually got surprised that not even the big ones care enough about this. Google had an XSS exploit (although it was fixed the same day it was announced), Other sites that youtube, nsa , and msn got XSS flaws recently as well.
Copyright infringement is "piracy" in the same way DRM is "consumer rape"
I was going to say the same thing after reading the article, actually. While XSS may very well be a critical threat, the example relies heavily on man-in-the-middle-type attacks, which a naive web application is going to be prone to, anyway. Nothing to see here, move along.
Also, I haven't seen an unjustified anonymous RTFA comment get modded up that high since 99, what gives?
--- What
..you're making the mistake of conflating AOL users with legitimate users.
--- What
I understand how he managed to get arbitrary javascript into the page. But how does he manage to display it to other users, since it is returned as an error to the enterer of the javascript?
I read the article, it isnt that EASY, the guy had to dipose of 2 available servers or machine, then if it's in house software, you need to have physical access to the interface and the user machine to get the cookies,,,,i mean the Slashdot post makes it seem very easy but it's not.
...since one of his screenshots has the actual client URL in it.
That's why you always use whitelists to validate data instead of blacklists. If users can enter URLs, make sure it starts with ^(http(?:s)?|ftp) or whatever you think is reasonable. If users can enter colors, maintain a list of allowed colors, or at the very, very least only allow [a-z]+ or #[\da-f]{6}. And so on. It's much easier starting out real strict and whitelisting more cases as they become needed, than it is to start plugging every possible hole one by one.
Spine World
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, 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.)
Range Voting: preference intensity matters
heres how you do a TH attack..
Just run up, hit the wanker in the knee like so, and demand log/pass or wallet.
Kill your TV
Just my 0.2
Is that your 20 cents or your 1/5th of a cent?
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.
Ok, risking being called a dumbass; why didn't the attacker overcome the 25 character HTML limit by creating his own HTML form that pointed to the actual web application for him (not an unsuspecting user) to inject the code? The attacker's form doesn't have to have any size limits on the fields. What am I missing here?
While he does use XSS to manipulate the site, most of the damagins stuff he does is not done through XSS. The application is poorly designed because:
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 inject some XSS that will send the session cookie to another server, where he can pick it up later and use to log in as another user.
So yes, real use of XSS. But to actually own the server he needed to be able to upload the PHP file.
meh
He obviously didn't read the floating point math article.
Normally, that's what you'd do to get around limitations such as this (I do this all of the time). However, for a true XSS attack, you'd need to use GET vars. So, essentially, he wound up doing exactly that, but it was the victim that needed to submit the POST data (so that the user's browser would be in the valid domain when it executed the script (which grabbed the cookie)). The end result is that this is a phishing + XSS combo.