Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×

How to Crack a Website - XSS, Cookies, Sessions 167

Posted by CmdrTaco 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.

How to Crack a Website - XSS, Cookies, Sessions More

How to Crack a Website - XSS, Cookies, Sessions

Comments Filter:

  • So... (Score:5, Funny)

    by cp.tar ( 871488 ) <cp.tar.bz2@gmail.com> on Monday August 14, 2006 @04:52AM (#15901313) Journal

    ... 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)

      by mgblst ( 80109 ) on Monday August 14, 2006 @06:49AM (#15901561) Homepage
      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.
  • shown like this, step by step, its even more scary. I mean, why shouldnt someone do that...its really easy.

  • One of my old favourites... (Score:5, Interesting)

    by baadger ( 764884 ) on Monday August 14, 2006 @04:59AM (#15901325)
    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 [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)

    by mdobossy ( 674488 ) on Monday August 14, 2006 @05:07AM (#15901339)
    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.

    • Re:Interesting read, but... (Score:3, Informative)

      by Anonymous Coward
      if you already have them logging in via a proxy, this would be much easier, and more reliable- sessions expire, etc..

      RTFA. The whole A. 5 times or until you realise how dumb u are, whichever comes later

      • Re:Interesting read, but... (Score:4, Informative)

        by mdobossy ( 674488 ) on Monday August 14, 2006 @05:34AM (#15901408)
        Yes, I am a dumbass, I mis-read the first page.. (as I prefaced- I may be reading this wrong, in my original message)

        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.
        • Yes, I am a dumbass, I mis-read the first page..
          Welcome to the club brother! We are a select few. Soon, you will find the lazy dumbass club even more invigorating and exciting than this one. Join now! We do not even read the first page, or the article!

        • MitM (Score:2)

          by Marc2k ( 221814 )
          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?

      • Re:Interesting read, but... (Score:1, Interesting)

        by Anonymous Coward
        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.

    • Some simple fixes would be sufficient (Score:5, Informative)

      by vdboor ( 827057 ) on Monday August 14, 2006 @07:03AM (#15901589) Homepage
      As short summary, what every (PHP) developer should do is:
      • 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):
      • use mysql_real_escape_string() [php.net] on all database input, or better: the variable binding feature of PEAR::DB
      • disable register_globals, use $_GET, $_POST and $_COOKIE instead.
      • Use preg_replace( '/[^a-zA-Z0-9\-_]', '', $input ) on all input used in file names.
        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)

        by Anonymous Coward
        • secure file uploads to avoid uploading PHP code

        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.

        • use mysql_real_escape_string() on all database input, or better: the variable binding f
      • disable register_globals, use $_GET, $_POST and $_COOKIE instead.

        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

        • Programmers make mistakes, and it also helps to clarify where a variable comes from and that extra caution should be taken with it.

          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.
        • global $login;
          check_login( $user, $pass );

          if( $login == true )
          { // do something
          }
          else
          { // fail
          }

          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)

        by FooBarWidget ( 556006 ) on Monday August 14, 2006 @08:16AM (#15901756)
        limit the session to the IP-address of the visiting user.

        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.
        • Yeah, the ip/session_id chaindown doesn't work.

          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
          • Its not just ISPs, dual-wan routers are getting cheaper and some of us have our own load-balancing routers at our home/office. IP restrictions are more annoying than anything else. The amount of security gained pales in comparison to the annoyances.
        • 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

          You are correct. I read somewhere once that AOL users are on such proxies. Pissing off legitimate users are not worth the security gained.
      • Your "most important" section could better be stated as "don't use PHP, it's broken by design".
      • limit the session to the IP-address of the visiting user.

        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.

      • Use preg_replace( '/[^a-zA-Z0-9\-_]', '', $input ) on all input used in file names.

        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.
      • > limit the session to the IP-address of the visiting user

        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 :)

      • 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

    • 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...

  • Boring... (Score:1)

    by Anonymous Coward
    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.

    • Re:Boring... (Score:1, Funny)

      by Anonymous Coward
      Yup, Somebody Cracked Slashdot [slashdot.org]

      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)

    by Jah-Wren Ryel ( 80510 ) on Monday August 14, 2006 @05:11AM (#15901353)
    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.

    • Re:Ok? (Score:5, Informative)

      by PowerKe ( 641836 ) on Monday August 14, 2006 @05:41AM (#15901428)

      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.

      • Yea, as far as I know, there isn't much that can be done if a valid session cookie is stolen. I have some methods that I use when I do web code that do some double checky stuff...If you're not using GET-type pages, you can do some double checking to make sure nothings changed about the session, make sure they're coming from a page that they should be coming from, based off a stored value that checks the last page that session entered. That kind of thing adds a lot of overhead though, and doesn't work well w

    • Re:Ok? (Score:5, Informative)

      by Ford Prefect ( 8777 ) on Monday August 14, 2006 @06:10AM (#15901488) Homepage
      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?

      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 '&gt;' 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:

      •    
      • ALWAYS escape your output, whether it's user-provided or not. Be it a simple htmlspecialchars() in PHP, or a fancy {$your_variable|escape:'html':'UTF-8'} in Smarty, or whatever your templating or programming language provides, never forget.
           
      • Be suspicious of all user-provided content. If it's a URL, make sure it's not a javascript: one - and if it's an email address or subject, make sure it's not got mail()-mangling newlines in it. You can send spam by adding extra headers that way, you know.
           
      • Make sure all your database queries are clean. If it's supposed to be an integer, enforce that it's an integer. If it's a string, make sure it's properly escaped. Regardless of where it came from. Bound queries, or whatever they're called, are very useful for this - in my own stuff, I've been doing (integer )$id, ... '".mysql_real_escape_string( $text )."' ... when creating the queries.
           
      • Read up on anything potentially hazardous, or on anything you don't quite understand. When something goes in a header, make sure it's got appropriate content - both email and HTTP headers can easily be abused through the judicious addition of newlines...


      • Don't forget about the fect that none of this would be possible, as an unprivelaged user, without [warning: PDF!] Session Fixation [acrossecurity.com] which is easily avoided by using session_regenrate_id [php.net] in PHP when the user logs in. Those 'stored session IDs' would all bcome expired upon login, and contain no important information.

        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
        • This attack vector had nothing to do with session fixation, though. This attack simply grabs the session ID from the user right before they log in. It lets PHP set the session ID.

          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)

        by vdboor ( 827057 ) on Monday August 14, 2006 @08:02AM (#15901719) Homepage
        Most forums are vulnerable to simple JavaScript insertion attacks. One reason is MSIE is able to execute code like this:

        <a href="java
        script:alert('test')">

        MSIE also allows developers to execute JavaScript in CSS code. A forum which translates

        [color=blue]
        to
        <span style="color: blue">;
        is vulnerable when you can enter
        [color=expression(alert('test'))]
        .
        • 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.
        • Note that <a href="javascript:alert('test')">something</a> executes just as well under Firefox as it does in MSIE.

    • Re:Ok? (Score:2)

      by suffe ( 72090 )
      Typosquatting?

    • Re:Ok? (Score:2, Interesting)

      by Anonymous Coward
      >
      > 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)

        by Anonymous Coward
        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, a
    • It's been years since I had an account with any pr0n type websites, but I bet they still do free trials. Would some enterprising person not be able to sign up for a "free trial" account, log themselves in to the site via their site, initiate the required process to gain access, and then cancel their legitimate account before the "free" trial ends? (Sorry if this doesn't make sense; been a long night)
    • A public network and ettercap are all you need. With ettercap you should have no problem watching what other people browse, getting session ID's, plain text passwords etc... When ever I travel and get bored I'll watch the hotels network. The number of people that check their mail without encryption is disgusting. And, some of the sites they visit afterwards are worse.

  • Question,,, (Score:1, Interesting)

    by Anonymous Coward
    How do you know if a hacking method has become unreliable and worthless?

    When they use Buzzwords for it.

    • Re:Question,,, (Score:3, Informative)

      by Opportunist ( 166417 )
      It becomes obsolete as soon as the mainstream media pick it up. Until then, it's usually fairly useful.

      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)

    by cras ( 91254 ) on Monday August 14, 2006 @05:18AM (#15901372) Homepage
    The most problematic part from the article:
    The end result was that I had to make a user click on a link that first took the victim to my server

    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)

      by Corbets ( 169101 ) on Monday August 14, 2006 @05:30AM (#15901402) Homepage
      I'm not sure that validating output (escaping it) will be any easier than validating the input. Really, you just need to write a function that does generic parsing of the input in the same way you have a special function that escapes it. get_safe_input($string) could be a function that reads in from the user, fixes it up, and returns the safe string. Bam, done, use that every time instead of your read_string or whatever the php function is.

      • 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 &lt;). 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

      • There's a simple and painless way to validate all form input in php with one line of code. Since they are stored as an array, just run it through a foreach loop with the htmlspecialchars function sanatizing the variables like this.. (you can also flag the ENT_NOQUOTES or the ENT_QUOTES switch to prevent against sql injection too)

        foreach ($_REQUEST as $field_key => $field_value) { $_REQUEST[$field_key] = htmlspecialchars($field_value); }

        Also, I agree that this article is a bit alarmist, but it's a

        • That's not validating anything. That's taking the shotgun approach by running everything through a specific function. You're now screwed when you need the plain text version of what the user supplied because it's gone. If you use a user variable in a query without quotes (since you're expecting an integer), the query is still open to SQL injection.

          ---John Holmes...
      • get_safe_input($string) could be a function that reads in from the user, fixes it up, and returns the safe string.

        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

    • 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.

      If I hadn't seen more examples than I care to count of code written by people who felt it unnecessary to a

      • 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

    • 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.

      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)

    by hagrin ( 896731 ) on Monday August 14, 2006 @05:20AM (#15901379) Homepage Journal
    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.

    • Re:More Like a Phishing Attack (Score:5, Insightful)

      by Fallus Shempus ( 793462 ) on Monday August 14, 2006 @05:39AM (#15901422) Homepage
      So you're going to rely on user's intelligence?

      You're not a coder are you.
      • You may not want to admit it, but the answer is yes "us" coders (read, I am a full-time programmer) do rely on the users for security.

        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
        • require users to set passwords to optimal lengths and character combinations


          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.

        • I can write the most secure web application known to man, purchase a digital certificate, require users to set passwords to optimal lengths and character combinations, but if they write down their username and password on a sticky attached to their monitor (I walk around the office here in the morning and see it all the time), then does that mean we have failed as programmers?

          Yes. You created an user authentication scheme which requires the user to memorize a long, meaningless list of characters, and in

    • This bothers me:

      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"
  • need crack for slashdot

  • With all due respect (Score:5, Informative)

    by rehashed ( 948690 ) on Monday August 14, 2006 @05:49AM (#15901441)
    This is a perfect example of a shoddily developed website.
    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 .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'.

    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.
    • Additionally, it is, in certain respects, a retarded piece of journalism.

      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

    • The XSS mentioned requires the use of phishing techniques...

      To you and everybody else who keeps thinking this somehow discredits the article:

      • The only reason he needed to "phish" was that this site had a maxlength on the relevant textbox. Other sites won't. Many sites can be directly exploited. The phishing in this case shows that maxlength is not an adequate security mechanism (duh), not that phishing is required in general to exploit sites.

        Moreover, I'm pretty sure that if he was a bit more clever, or a b

  • Human engineering & login code (Score:5, Insightful)

    by YeeHaW_Jelte ( 451855 ) on Monday August 14, 2006 @05:56AM (#15901463) Homepage
    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.

    • 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.

      Yes he does. If you had read TFA, you would have noticed the following sentance in the first paragraph!

      In this article I am going to look at a real-life XSS attack and how it was used to bypass the authentication scheme of an online web application I was asked to test.

    • I dunno how he would get a user to login via a unrelated URL.

      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...no. Go back and read the article again.
        • Ah yes, sorry. To be precise, he used XSS (on the login form) to steal the session cookie, then redirect the user to the real login screen. If I understand PHP sessions correctly, then if the user then goes ahead and logs in (to the *real* login screen, not a fake version of it) said cookie might then be usable to impersonate the user. If the user is already logged in to the site, this may also work without the user having to log in again, depending on the implementation of the login form.
    • 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 Cross Site Scripting FAQ (Score:3, Informative)

    by mrkitty ( 584915 ) on Monday August 14, 2006 @08:23AM (#15901780) Homepage

    http://www.cgisecurity.com/articles/xss-faq.shtml [cgisecurity.com]

  • Meh. (Score:2, Funny)

    by goldenratiophi ( 878655 )
    I was just hoping for a text box and a button saying "Crack Website!"

  • XSS is not the biggest problem (Score:3, Insightful)

    by MobyDisk ( 75490 ) on Monday August 14, 2006 @09:21AM (#15902050) Homepage
    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 woul be interesting anyone posting any java regular expression for detecting XSS attacks XD Tnx!

  • Use Chroot jail and block outgoing http/ftp reques (Score:4, Interesting)

    by vivekg ( 795441 ) on Monday August 14, 2006 @09:31AM (#15902113) Homepage Journal
    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
  • 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.

  • Ugh (Score:3, Interesting)

    by CTachyon ( 412849 ) <chronos AT chronos-tachyon DOT net> on Monday August 14, 2006 @11:30AM (#15903016) Homepage

    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.)

  • 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 injec

Slashdot Top Deals

Two can Live as Cheaply as One for Half as Long. -- Howard Kandel

Close