Forgot your password?
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

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.
  • by Fred Porry (993637) on Monday August 14, 2006 @04:59AM (#15901324)
    shown like this, step by step, its even more scary. I mean, why shouldnt someone do that...its really easy.
  • 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.
  • 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.
    • by Anonymous Coward on Monday August 14, 2006 @05:13AM (#15901360)
      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
      • 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.
      • by Anonymous Coward on Monday August 14, 2006 @05:37AM (#15901419)
        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.
    • 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
      • by Anonymous Coward on Monday August 14, 2006 @07:44AM (#15901681)
        • 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 feature of PEAR::DB

        Or use PHP5's mysqli_ or pdo_.

        • Things like require_once("files/" + $input + ".html") actually read php files when it's called as ?input=file.php%00

        And if you absolutely have to include third-party files, use readfile as it passes the data right from the file to the output buffer without ever executing it.

        Also use readfile when you include parts of templates that don't and shouldn't have executable (php) code.

        Of course, the best advice one could give to a PHP developer would be "first and foremost, don't use PHP".

      • by Sepodati (746220) on Monday August 14, 2006 @07:56AM (#15901703) Homepage
        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 Holmes...

        • by kestasjk (933987) on Monday August 14, 2006 @01:12PM (#15903869) Homepage
          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.
        • by Christianfreak (100697) on Monday August 14, 2006 @02:15PM (#15904368) Homepage Journal
          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 large application one needs to be able to determine where variables are coming from. register_globals hides this, and makes it easier for the newbs to blow their whole leg off instead of just shooting themselves in the foot.

          PHP really needs something equivalent to Perl's taint mode (-T switch). The program dies unless you check the variable against something. You can still get around it but at least it makes you think twice before pulling the trigger.

      • 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 the connection for a fraction of a second.

            Considering the amount of keyloggers on the move and the amount of dummy windows users blindly running them really undercuts any meanings for the session id hunt anyway. There are workarounds, but none of them are really comfortable.

            For the article. You have an web application that allows execution of uploaded code files, aside from everything else, this is just intolerable. And without that fault the system on the whole still be unaffected in the large scale, only a single victim and his/her resources would be harmed.

            As noted by many people in other posts, ffs learn to escape your variables and don't let people run uploaded files. If this should prove to be too hard for you, practice "do you want fries with that" for the future.
        • by bmalia (583394) on Monday August 14, 2006 @09:56AM (#15902268) Journal
          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.
      • by Goaway (82658) on Monday August 14, 2006 @08:54AM (#15901899) Homepage
        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.

      • by kalirion (728907) on Monday August 14, 2006 @10:15AM (#15902379)
        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.
      • by MattHawk (215818) on Monday August 14, 2006 @10:32AM (#15902492) Homepage
        > 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 :)
      • by WoodstockJeff (568111) on Monday August 14, 2006 @11:15AM (#15902869) Homepage

        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 recently-discovered problem with that function and multibyte characters has caused some interesting issues, depending upon how the server gets "fixed".

    • by Skrynesaver (994435) on Monday August 14, 2006 @07:33AM (#15901662) Homepage
      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...
  • by Anonymous Coward on Monday August 14, 2006 @05:09AM (#15901346)
    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.
  • 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.

      • by SatanicPuppy (611928) * <Satanicpuppy@[ ]il.com ['gma' in gap]> on Monday August 14, 2006 @09:44AM (#15902197) Journal
        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 with idempotence.

        You could also try assigning client side cookies to double check against your server side cookies, but that will only work if the client isn't sending all their traffic through a compromised proxy. Forcing encryption might help (and frankly, should always be done for a login screen), but never underestimate the users ability to click-through a pop-up.

        I don't know. Good web development revolves around distrust of all incoming data; if someone uploads code and runs it on your site, you did something stupid. But there comes a point where the user has some responsibility. Man-in-the-middle is much more detectable on the user end than on the server end, and if a user does two or three dumb things to allow a session hijack, there isn't much you can do about it, serverside.
    • 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...


      • by seek31337 (520238) on Monday August 14, 2006 @07:47AM (#15901688) Homepage
        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 just... ew.

        And Smarty makes HTML escaping user input easy and fun!
        • by Sepodati (746220) on Monday August 14, 2006 @10:03AM (#15902309) Homepage
          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...
      • 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'))]
        .
    • by suffe (72090) on Monday August 14, 2006 @06:46AM (#15901558) Homepage Journal
      Typosquatting?
    • Re:Ok? (Score:2, Interesting)

      by Anonymous Coward on Monday August 14, 2006 @06:58AM (#15901576)
      >
      > 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 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"...).

      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...
      • Re:Ok? (Score:1, Interesting)

        by Anonymous Coward on Monday August 14, 2006 @07:10AM (#15901603)
        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...
    • by louisadkins (963165) on Monday August 14, 2006 @07:02AM (#15901588)
      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)
    • by sgt scrub (869860) <saintium&yahoo,com> on Monday August 14, 2006 @11:18AM (#15902915)
      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 on Monday August 14, 2006 @05:12AM (#15901355)
    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) on Monday August 14, 2006 @08:07AM (#15901727)
      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 reliable to assume that you can find a clueless victim easily. If you're targeting something specific which has presumably an admin with a Clue (capital C not a typo), anything that's been out for over a month is worthless. No matter whether it's been buzzworded or not.
  • 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.

    • 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.
      • by cras (91254) on Monday August 14, 2006 @05:50AM (#15901445) Homepage

        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. And never mind the other problems that you might have when manipulating the escaped input before printing or storing it..

        Or perhaps it's easier not to worry about the escaping problems at all that might come, and just always print data like: html_printf("Hello, %s", $_REQUEST["user"]); You can even verify that all prints are safe using a grep command that checks that no "print" commands exist and no variables are used as html_printf()'s first parameter.

      • by MrHali (985004) on Monday August 14, 2006 @06:26AM (#15901516)
        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 always a good exerise to think about application security.
        • by Sepodati (746220) on Monday August 14, 2006 @07:30AM (#15901654) Homepage
          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...
      • by wralias (862131) on Monday August 14, 2006 @09:12AM (#15901999)
        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 string input automatically. Even if you do something like this, though, you still need to validate input that is of a specific type (email address, file upload, zip code, etc).

        In the "serious" coding community, it seems like JavaScript and PHP suffer from the same image problem. Both languages are great once you get to know them (and both have their problems). It seems like the image problem comes mostly from the fact that both are easy to tinker with, and as such, lots of amateurs (who don't yet have experience with stuff like security) are able to hit the ground running with their first php/mysql or javascript web app.
    • by Savage-Rabbit (308260) on Monday August 14, 2006 @06:26AM (#15901515)
      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 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.
      • by cras (91254) on Monday August 14, 2006 @07:02AM (#15901587) Homepage

        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, the input may be modified in insecure ways within your application that's not so easily detectable.

        Of course once you know your program is already safe against any kind of user input, you may add input validation. But that's not to prevent security holes, only to give user (and admin) meaningful error messages and possibly guard against DoS attacks with eg. too large user inputs. I suppose input validation in your program may also help if the same input is transferred into other people's buggy programs, but that's not really your program's fault anymore..

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

  • 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.
    • 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.
      • by hagrin (896731) on Monday August 14, 2006 @06:23AM (#15901512) Homepage Journal
        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 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?

        Personally, I think not.
        • by Fallus Shempus (793462) on Monday August 14, 2006 @06:48AM (#15901560) Homepage
          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.
        • by ultranova (717540) on Monday August 14, 2006 @10:02AM (#15902300)

          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 the worst case change that reqularly. Humans are very bad memorizing such lists, so the users have little choice but to write them down. In other words, the security problem of sticky notes comes from your failure to implement an authentication shceme that functions properly within the user's limitations.

          Your failure is essentially similar to requiring such horribly complex and processor-intensive crypto algorithm to secure the channel that the user's machine is incapable of doing it fast enough so he has to use telnet instead. The overcomplex crypto might make the system secure in theory, but in practice it's an impediment to security.

          Learn your craft, and don't expect your users to suddenly get photographic memory, any more than you would expect an 8088 to magically get a gigabyte of memory. A bolt that's screwed too tight breaks, and security is no different: when it becomes too inconvenient, it gets broken, since getting work done takes priority. The trick is finding the maximum security you can have in practice, and not turn the screw any tighter than that.

    • by DahGhostfacedFiddlah (470393) on Monday August 14, 2006 @10:06AM (#15902322) Homepage
      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"
  • by PipoDeClown (668468) on Monday August 14, 2006 @05:20AM (#15901380)
    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.
    • by Sepodati (746220) on Monday August 14, 2006 @07:48AM (#15901689) Homepage
      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 article just because of the method this specific attack requires.

      Secondly is the ability to transfer a session.

      Wait, you're saying this is a worthless article because of how the author decided to propogate the hijacked session? The article would have been better if the guy used GET, or what?

      Thirdly, is simple abuse of a poorly designed web application

      Duh, no shit. That's what all XSS attacks are. Who's writing the article here? In fact, the rest of your reply falls into the "no shit" category, too. You're just repeating what everyone says when vulnerabilities like this are announced. At least the article writer went through the effort of going into all of the details of a specific attack so that those who are clueless (99% by your calculations) can see exactly why this is an issue.

      ---John Holmes...

    • by Jerf (17166) on Monday August 14, 2006 @10:53AM (#15902693) Journal
      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 bit lucky, he could have skipped that too. We don't know what site he was working on, but I wouldn't be surprised that he could have written an exploit that sent out code that used Javascript to strip off the maxlength parameter, loaded in his exploit code, and then proceeded onward, all without user intervention.
      • Have you not been reading the news? Phishing works all the time! If you have a large enough site, the odds of at least one of your users falling for it approaches 100%. If you're basing your security on "not being phished", it's not even worth calling "security".
      Thirdly, is simple abuse of a poorly designed web application.
      Your average web application is poorly designed. I've found XSS in commercial apps, but they do tend to converge on security. Eventually. But even names as prestigious as Oracle have had XSS flaws [red-databa...curity.com].

      The problem is that all of these flaws are of a kind; if you don't escape your user's input correctly when sending it back into the user's HTML page, it's a good guess that you also send the user's values into the database unescaped, or that you'll happily run uploaded PHP content unescaped. It's really all the same error, so they tend to all show up at once. And they do, often.

      Pointing out that XSS can only be done on poorly designed sites is really a tautology. The fact is, there's a lot of them, and I hope this article will open some eyes about how serious that poor design can be.
  • 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.
  • Meh. (Score:2, Funny)

    by goldenratiophi (878655) on Monday August 14, 2006 @08:38AM (#15901838)
    I was just hoping for a text box and a button saying "Crack Website!"
  • 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?
  • by Rainefan (969597) on Monday August 14, 2006 @09:26AM (#15902073)
    It woul be interesting anyone posting any java regular expression for detecting XSS attacks XD Tnx!
  • 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
  • by Vexorian (959249) on Monday August 14, 2006 @09:41AM (#15902174)
    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@@@chronos-tachyon...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.)

  • by dcam (615646) <.moc.tpecnocrebu. .ta. .divad.> on Monday August 14, 2006 @06:09PM (#15906477) Homepage
    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.

Federal grants are offered for... research into the recreation potential of interplanetary space travel for the culturally disadvantaged.

Working...