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.
How do you know if a hacking method has become unreliable and worthless?
When they use Buzzwords for it.
needed the xss to get the proxy going.
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.
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.
>
" . A lot of people will just click the link. The page redirects back to the attacked website, with the POST informations, but most people will just write a new comment, like "huh, it doesn't work for me"... To avoid any suspicion, you might post new comments with different nicknames, like "it works for me...", and continue with a comment on the linked "article". People will just think it is their connection, or their browser... even if multiple people have the problem, they will just think it is some kind of incompatibility... (you are being redirected from an unknown website, to the website where you just were... most people will think it is a problem on their part, because the unknown website "can't know you came from the website where you just were"...).
> 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
Now, if the user was not logged in, you got his session ID (note you have to redirect the user to the original news you were commenting, so he does not see any error message, and so he stays on the topic of the link you provided earlier -he might want to post a comment to tell you the link does not work, and voila, if the website does not allow anonymous comments, he will just login!). If he logs on during the time the session is valid, you bypassed the authentication system (now that I think about it, another countermeasure would be for the developer to simply change the session ID during the login procedure...).
If the user was logged in, and the website does not show a big fat "You have been logged out" message, when the user is being logged out (some websites just redirect to the home page, or to the page you just were -but then, you might use frames to hide the message), or if the website first check the email address and send the error message, before checking if the user was already logged on, you might, when the user is first visiting your link (do this for every user, most visitors will probably be logged in users... and if not, and you can hide the error message with frames, there's no problem), send POST informations to log him out, instead of trying to log him in... As the user will not understand why he was redirected back to the original page, he will most probably try it a second time... then you just detect it is his second time, and this time, send the POST informations to try to log him in (with the erroneous email address), and here you go, you have his session ID... and if the user was logged in, if most probably will try to use his account soon, so he will have to login again... (like to post comments about the link not working, at the very least...).
Now, we were just using a commenting system... Some people don't read comments, some others are more suspicious of links in comments (but if your comment is otherwise funny/interesting, who will be suspicious?).
What about websites which permit to post news? even checked by editors, this is no problem for your attack... you might just create a fake website, so the editor finds the link interesting/funny, and then, when the news is published, you just switch your website back to an attack machine... (people might even think the linked website was just "slashdotted", if the website has many visitors...).
Even if the website has few visitors, I'm pretty sure it would work quite well, even with "educated" users...
Other "tips":
- 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, and then you tried to log him in again, the second time), just send him your fake webpage... (no more suspicion...).
If well planned, you will succeed...
With a site offering e-mail, you could craft a message that looked like the timeout page (document.write(target=_TOP)). please login again .... Then if read via the webmail interface, the user thinks they timed out, the sender gets the login etc..
Just another thing to worry about, I'm off to check how our webmail server behaves...
"Linux is for noobs"-The new MS fud strategy
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.
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