Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Security The Internet IT

Major Flaw Found In Security Products 153

Posted by kdawson from the deploy-the-captchas dept.
ancientribe writes "A stealthy and potentially dangerous bug has been discovered in security products from eight different vendors, including Check Point Software, according to an article in Dark Reading. The so-called cross-site request forgery (CSRF) lets an attacker access the user's network and even conduct transactions on behalf of the user. It could affect over a million installations, but so far, Check Point is the only security vendor to step up and patch it. This vulnerability is found in most everything with a Web-based interface, including printers, firewalls, DSL routers, and IP phones." An article on the vulnerability from last fall quotes Jeremiah Grossman, CTO of WhiteHat Security, who calls CSRF "the sleeping giant" vulnerability: "It's not seen as a vulnerability because it works like the Web works."
This discussion has been archived. No new comments can be posted.

Major Flaw Found In Security Products More

Major Flaw Found In Security Products

Comments Filter:

  • Hope they used EEPROM (Score:3, Insightful)

    by jshriverWVU ( 810740 ) on Thursday June 28, 2007 @12:13PM (#19677151)
    routers, IP phones, etc

    because it sucks when there's a bug in hardware unless it's possible to do a firmware upgrade to fix or work around it.

  • Can someone explain this for me...? (Score:3, Insightful)

    by mikecardii ( 978929 ) * on Thursday June 28, 2007 @12:15PM (#19677173) Homepage
    I'm not completely retarded at computers, I just like reading comments on /. so I don't call attention to myself because for the most part I look like a complete dumbass. Yet this sentance makes no sense to me. "It's not seen as a vulnerability because it works like the Web works." What does this mean?

    • Re: (Score:2, Funny)

      by MDHowle ( 634114 )
      Sounds like the old saying "it's not a bug. it's a feature!"

    • Re:Can someone explain this for me...? (Score:5, Informative)

      by Anonymous Coward on Thursday June 28, 2007 @12:26PM (#19677325)
      What does this mean?

      It means that if you do something stupid like leave the default username/password for your "appliance" or log in and pick up a session cookie then go browse somewhere else, someone can set up a link like "http://192.168.0.1/networksetting.cgi?internet=di sabled&username=Admin&password=" and if they convince you to click on it, your internet turns off.

      Except that they don't have to convince you to click on it, they could set that as the source of an image... you'd see a broken image tag and then the internet would stop working. Then they just have to get that image tag onto a website you read, say through an ad vendor (some of whom obviously don't care that they're hosting malware, so why not?) or an email to a webmail address that doesn't filter image tags.

      This is how the internet works. Your browser follows links, and doesn't know or care about whats there until it gets there.

      • Re: (Score:2)

        by spood ( 256582 )
        Hence the reason to disable remote 3rd party images in your browser of choice (e.g. Firefox) and never click on 3rd party URLs. See also the Netflix CSRF vulnerability [webappsec.org] that allowed an attacker to add a movie to a user's queue, move it to the top of the list, and change the shipping address for the user to his own to get free movies. Who here checks the box to stay logged into Netflix? Note that the "add movie to queue" portion still hasn't been fixed.

        There may be a lot of comments saying CSRF is so 20006. W

        • Re: (Score:2, Funny)

          by gEvil (beta) ( 945888 )

          There may be a lot of comments saying CSRF is so 20006.
          Pfffft. I'm certain they'll have things fixed by then...

        • Re:Can someone explain this for me...? (Score:5, Informative)

          by planckscale ( 579258 ) on Thursday June 28, 2007 @02:34PM (#19679095) Journal
          By the way to not allow images execept from the original website, in FireFox2, open about:config, modify the value of the preference permissions.default.image

          from 1 to 0 .

          • Umm, I think this comment should probably be bumped [modded] up. I'ts darned helpful information.

          • Re:Can someone explain this for me...? (Score:5, Informative)

            by iago-vL ( 760581 ) on Thursday June 28, 2007 @03:08PM (#19679587)
            Of course, while that's generally good advice, it does very little to prevent CSRF. Instead of using an image, they could use an iframe or JavaScript code or anything else that loads a URL.

          • By the way to not allow images execept from the original website, in FireFox2, open about:config, modify the value of the preference permissions.default.image

            from 1 to 0 .

            The problem with this is that a lot of sites use different servers to legitimately host their images. ie, media.example.com hosting images for www.example.com.

            • Re: (Score:3, Interesting)

              by owlstead ( 636356 )
              The bigger problem is that, indeed, the browser accepts data from any source to be put in a page, as well as allow communications to any destination. This can be images, video's, web-casts, posts, redirects, css pages - the works. To make matters worse, you cannot even trust links anymore, you never know what the scripting which is behind the link is going to do. This is just like Outlook displaying mails in Internet explorer, it's damn convenient at times, but it's really, really bad for security.

              Now, if y
        • "Hence the reason to disable remote 3rd party images in your browser of choice (e.g. Firefox) "

          Is that automatic, or do you have to enable that?

      • Re: (Score:2)

        by dgatwood ( 11270 )

        That's pretty sad if that's all this is about. Isn't this basic stuff they teach you in college? :-) Didn't we learn anything from the "secret" backdoor passwords exploited by the UNIX worm of 1988? You don't have a single password built into ANY piece of software. You require the user to create a password when you first plug the device in. Really freaking basic stuff.

        For that matter, this one would be solved by simply using an expiring session key. For that matter, this one would be solved by makin

    • Re:Can someone explain this for me...? (Score:5, Informative)

      by stevey ( 64018 ) on Thursday June 28, 2007 @12:30PM (#19677375) Homepage

      There is a simple example / introduction to CSRF attacks here [debian-adm...ration.org].

      • Re:Can someone explain this for me...? (Score:5, Informative)

        by dch24 ( 904899 ) on Thursday June 28, 2007 @12:44PM (#19677565) Journal
        Parent link is very helpful in understanding CSRF. In brief: malicious site knows or guesses you are logged in at paypal, slashdot, some valuable site, etc. ... malicious site sends you javascript that generates a form and submits it to valuable site. Valuable site sees it coming from your browser, so the cookies are valid. You are logged in, aren't you?

        This lets malicious site do things like send $10 donations from your paypal account, submit blogspam, get your account balance, etc. if you can be convinced to visit malicious site.
        • Ok, but they say adding a token fixes the problem? So, website X shows me a form with some randomly-generated token field that's good for say 15 minutes, and unless my form submission has that field set to a valid token, then it is rejected? The token would need to be tied to something so that only a request I send creates a valid token for me... otherwise the malicious site can request the form itself, getting a valid token, and use it for the malicious submission.

          For that matter, the malicious site coul
          • No it can't. The same-origin policy prevents javascript from one website from accessing objects returned from another website. Kinda. It's complicated and there are occasionally ways to hack it, but generally speaking when same-origin is working, the token is a pretty secure mechanism.

            The best way to break tokens like that is to find some XSS on the site you're attacking -- that allows you to get javascript running within the domain of the remote site. /Then/ you can do what you described above and have

          • Re: (Score:2)

            by Intron ( 870560 )
            Suppose that when you request the page with the form on it from the legit site it encrypts your IP address and includes it on the page as a hidden field. Hitting submit returns the token which matches your IP address.

            The malicious page has a submit button that they trick you into hitting which sends a request to the legit site in your name from your browser but it can't get the same token, even though it knows your IP address, unless it can break the encryption or is behind the same NAT firewall as you. S

        • Re: (Score:2)

          by rthille ( 8526 )
          WTF? Javascript can do POSTs to unrelated sites, and the browser includes authentication/cookies appropriate to that site? (Please excuse my ignorance, I'm no web developer) Really? WTF?

          That's just insane!
          • You might ask "why are you allowed to submit forms to different URLs?" The answer is because that's how the web was specified to work from the beginning. In a way, the CSRF issue has grown because modern web-browsing includes multiple tabs and windows. JavaScript really isn't at fault. I suppose you could try to make it such that JavaScript cannot do any events, but that would totally break GMail. You can submit hostile forms without JavaScript, too. Just trick the user into clicking on a button that

            • Re: (Score:2)

              by jrumney ( 197329 )
              Javascript very much is at fault here, if it does allow submitting posts. Allowing HTTP requests only to the originating site is one of the basic security constraints of the Java sandbox, so its not like this is a brand new vulnerability that noone ever thought about before. Yes, it'll break AJAX mashups, but it needs to be done.
              • As others have posted, javascript is only one way to implement the hack. the HTML tags: img, form, a, and iframes all have the capability too!

                --jeffk++
          • i'm thinking we should at least discuss the option of having browsers prohibit any POST from one domain to another.
        • And I thought my friend who works as a vulnerability researcher was overly paranoid when he had a browser profile only for bank transactions.

          This class of attack has been known for years, its only recently that its come into the spotlight, and been named and quantified. Or maybe its just a slashvertisement since CheckPoint is the first to "Patch" it. When everyone was vulnerable, why make the sheeple scared, scared users don't make online transactions. Now its "Fixed," but only the people at CheckPoint h

  • What the ... ? (Score:3, Interesting)

    by khasim ( 1285 ) <brandioch.conner@gmail.com> on Thursday June 28, 2007 @12:17PM (#19677215)

    CSRF works like this: An attacker identifies a URL on a Website -- such as Netflix or a bank -- that initiates typical Web functions such as making a purchase, changing an email address or transferring funds. "The attacker takes that URL and loads it to a Web page they control," White Hat's Grossman says.

    The actual attack occurs when the user visits the attacker-controlled Web page via a legit link, which forces the browser -- using legitimate, authenticated cookies -- to make malicious requests. The user has no clue as to what's happening.

    And the catch is that neither the original Website nor the user's computer is necessarily compromised, Grossman says.

    Wouldn't this be easily killed by simply having the webpage dynamically generate a page with a life of 15 minutes or less?

    Or even by using some basic encryption that involves the IP address of the original request?

    sheesh!
    • The actual attack occurs when the user visits the attacker-controlled Web page via a legit link

      Does that also mean simply typing in the URL bypasses this as well?

      • Re: (Score:2)

        by Intron ( 870560 )
        No. Its not a phish address. The malicious webpage has elements that will be downloaded by your browser automatically, like images, javascript and styles. One of these could actually be a link to Slashdot (for example) that requests an action there. If you are still logged into Slashdot it will perform the action because the request really came from your browser, which knows the session and your Slashdot cookies.

        • Re: (Score:2)

          by Amouth ( 879122 )
          i find this kinda intresting.. exchange years ago disabled url's to the same domain as the mail server cause people where getting e-mails with links in them that would use OWA to delete mail or change passwords and so on and so forth

          needless to say i had to alter their proccessing page for this cause they blocked the whole damn domain not jsut the mail server..

    • Re: (Score:2)

      by ghoti ( 60903 )
      If I understand this correctly, the request comes from the user's browser, and so also from the same IP. But a timeout would help (it's just less convenient).

      But that makes me wonder if browsers could do something against this. If there's an iframe that is not visible to the user, and that tries to request a page from somewhere else, don't send cookies. Okay, maybe it's a bit more involved, but shouldn't this be doable on the browser side?

      • Re: (Score:1)

        by jmyers ( 208878 )
        The browser would have to second guess what you are trying to do and that would not be good.

        This really needs to be fixed a the web application level so that the program does not allow random access to important URLs but tracks the user in various ways. The program needs to use more that cookies to make sure you intend to make a purchase or modify information. For example if a direct link comes into amazon to order a product and the same user is not coming from a page that would have legitimately made that
        • I may be wrong, but I think Amazon already implements something like that. I cannot bookmark my "shopping cart" page ... and then go into it from a different computer with a different IP address. Even if I'm logged into Amazon on both computers.

          There seem to be a lot ways to defeat this "sleeping giant" of a vulnerability. And most of them seem to related to basic security practices by the websites themselves.

          "Solving" this at the firewall level just seems ... weird.
    • I think that's one of the changes Check Point is making to the Edge appliances. There are no details in the release notes for v7.0.45 of their Edge firmware, but I think they added some session timeout/cookie timeout stuff. This came out rather quickly, so it must not have been too hard to "fix".

    • Re: (Score:1)

      by jmyers ( 208878 )
      I don't think a timeout will help much. It seems to me the most likely or simple to implement attack would be to use this on a community site where the attacker and victim are currently logged in to the same site. From one article it appears myspace was already attacked this way some time ago.

    • Re: (Score:3, Interesting)

      by bryguy5 ( 512759 )
      Expiring the Session in a short time frame like 15 minutes does limit the damage, but doesn't eliminate the threat. The above example said Checkpoint was only vunerable when both were open at the same time.

      The IP address doesn't work because the initial exploit is from the orignal user on the same computer, same ip address. Just a different tab or window of the same browser that carries the same cookie/http-auth as the original, but comes from a seperate malicious webpage.

      I can think of 2 general fixes but
      • So long as the malicious site isn't on HTTPS you should get a url referrer with the request that doesn't look like the one you'd expect to get from a legitimate request.

        • Re: (Score:1)

          by bryguy5 ( 512759 )
          You're right I just thought of this. I generally do referrer filters, but didn't really think through why.

          What happens in the case of https? Does the referrer come through blank?
          Is there anyway you can think of around this outside of XSS?
        • Actually, there are a couple of ways to prevent an innocent third-party browser from sending referer information, HTTP redirects for one. That combined with the fact that many browser security extensions and firewalls block sending of referers means that you can't distinguish between users intentionally trying not to leak information and an innocent client tricked into visiting without a referer.

          As long as you're willing to inconvenience folks by requiring a valid referer, and not just trying to filter any
        • Oh, I don't know. If an attacker is going to research the target form page well enough to generate convincing POST content, I would hope he or she would go a little further and research the referrer URL pattern and synthesize that as well.
          • It should not be possible to ``synthesize'' the referer. Your browser should protect the referer header and make sure it's valid for you. So if you're visiting http://www.shadyhackerswebsite.com/ [shadyhackerswebsite.com] that contains an IFRAME which loads http://www.paypal.com/cgi-bin/transfer_money.pl?to =hacker@shady@shadyhackerswebsite.com&amount=10000 .00 >, your browser should enforce that the referer is http://www.shadyhackerswebsite.com/ [shadyhackerswebsite.com]. If your browser does not protect your referer, and lets http://www.shadyhack [shadyhackerswebsite.com]

            • In the context I'm talking about, the browser has no control over the referrer.

              Review TFA and read the pretty-good Wikipedia article about Cross-Site Request Forgery [wikipedia.org].

              Then imagine a Javascript program, uploaded to a victim's browser by your hypothetical shadyhackerswebsite. (The victim's looking for instructions for how to cut down the size of his window shades and got fooled by a seeded Google response, let's say.)

              The Javascript takes advantage of the breach in document security which is the subject of TFA

      • The above example said Checkpoint was only vunerable when both were open at the same time.

        While that does happen, it probably would be extremely rare.

        And the "attacker" would have to pre-craft the page. This would be easily defeated by simply dynamically generating each page and giving a short time to live.

        The attacker would need to know the dynamically generated ID
        and
        He'd need to know it before that page expired
        and
        He'd need to get that code into his webpage that you were looking at.

        Sure, this "attack" woul

        • Re: (Score:1)

          by bryguy5 ( 512759 )
          The problem is these security appliances use firmware that's not updated frequently so the format is very predictable.

          Hopefully they use a dynamic id and include it on url's and form requests, instead of just relying on a cookie. But a lot of us web developers have just used cookies cause their cleaner and easier.

          Maybe Checkpoint added the id with their patch.

      • Re: (Score:2, Insightful)

        by morgan_greywolf ( 835522 )
        I've said from the first day I learned what a 'cookie' was that using cookies alone for authentication is a very bad idea. Here is the real fix: don't use cookies alone for authentication. Your idea of using a session token passed on the URL is one such idea. Can anyone think of others?
        • It seems to me the real problem is that the cookie namespace is unnecessarily shared between multiple tabs/windows. Why not have different tabs run in a completely separate process? Clicking links or opening tabs to the same domain would be kept in the same process, but everything else (searching, typing in addresses, clicking bookmarks, etc.) would open tabs in a new process, with none of the session information of wherever you were before. I bet this would also decrease lock contention, help with memor
      • I think that simply creating a unique ID for each form/URL and validating that on the Post/Get request should stop the problem.

        Unless of course the javascript loaded the page containing the form, parsed it and pulled out the secret variable :-(

    • Re: (Score:2)

      by bhmit1 ( 2270 )

      Wouldn't this be easily killed by simply having the webpage dynamically generate a page with a life of 15 minutes or less?

      It's poor authentication on the server side. The browser is hitting links that it's given, and if you're doing something important, you shouldn't rely on the browser being fixed. The proper solution is for the server to give out a unique key with every form or link that needs to be secure, and if the key received don't match one given out to that user, it's rejected. Crackers wouldn

    • Re: (Score:2)

      by octaene ( 171858 )

      No, you're way off base. The problem is persistent credentials (cached stuff, and cookies that save your username and password). Sending your cached credentials through an encrypted connection does nothing to protect you; it only obfuscates the data being transmitted.

  • Update! (Score:4, Informative)

    by accessdeniednsp ( 536678 ) <detoler AT gmail DOT com> on Thursday June 28, 2007 @12:18PM (#19677229)
    Anyone here like me who does managed firewall work, please notify your clients and get them updated! But this is Slashdot, and we all update our stuff don't we? :) Also, this kind of thing is irrespective of whether or not you allow remote web management of your device. Also, this is further evidence for why you should not use the default internal IP range the device gives you. Please always change the local LAN IP range!

    I'm surprised it took this long to find something like this, but I'm not at all surprised it existed. I've loved web interfaces like these but I've always been nervous about them.

    • Also, this is further evidence for why you should not use the default internal IP range the device gives you. Please always change the local LAN IP range!
      I certainly need to read up some more on this, but from the sounds of the first article, it doesn't seem like changing the default IP range would stop this exploit from working.
      • The advisory I read earlier this week for the Check Point Edge firewall, specifically, said the URL would have been most effective if the attacker knew the device's IP. The proof-of-concept I saw worked to add a new admin user and password to the device. It used "https://192.168.10.1/blah blah" which is the default IP of the Edge out-of-the-box. Although for the Edge, specifically, it acts as a DNS proxy which can intercept the silly "my.firewall" and "my.vpn" DNS names and redirects them to the device i

  • The sky is falling? (Score:4, Insightful)

    by Verteiron ( 224042 ) on Thursday June 28, 2007 @12:22PM (#19677267) Homepage
    From TFA:
    In Check Point's case, CSRF was possible when a user was logged onto https://my.firewall/ [my.firewall] at the same time he or she was connected to a malicious Website, according to the company's patch release information.

    This bad, sure, but hardly the internet-destroying calamity the article makes it sound like. When you're connected to the web interface of something critical, make sure you trust the other websites you're viewing at the same time. Am I missing something, or is this Calyptix company just trying to get its name on everyone's lips?
    • For that matter, I can't think of a time when I've opened another website while using the web interface for a firewall. If I'm configuring a firewall that's what I'm doing, and the rest of my internet connection is probably non-fuctional until I get the firewall set up.

      But the vunlerablity isn't limited to firewalls, of course...

    • Trusted sites may inadvertently launch the attack (Score:1, Interesting)

      by Anonymous Coward
      Unfortunately, even if you trust all the sites and they are all trustworthy and well-known, you can still get hit. It is a _potential_ calamity (hence the "sleeping giant" reference) and this is why the advice to companies that require security in their public web-apps is to review them now.

      Drawing partially on a previous post, here is an example. You're on Disney's site and want to buy some toy. You think, eBay/Paypal to shop and pay for the toy would be much cheaper than Disney's site. You have both open

  • POST vsn GET (Score:3, Interesting)

    by El_Muerte_TDS ( 592157 ) on Thursday June 28, 2007 @12:32PM (#19677409) Homepage
    Is that not the reason to use POST for important actions (e.g. modification to data) rather than GET?

    • Re:POST vsn GET (Score:4, Informative)

      by stevey ( 64018 ) on Thursday June 28, 2007 @12:37PM (#19677473) Homepage

      Using POST will help, but it doesn't solve the problem.

      An attacker could still host a hidden FORM pointing at your local application, and use Javascript to submit it.

    • Re:POST vsn GET (Score:5, Interesting)

      by ckd ( 72611 ) on Thursday June 28, 2007 @12:40PM (#19677517) Homepage

      Is that not the reason to use POST for important actions (e.g. modification to data) rather than GET?
      Indeed it is, but why should the vendors of security appliances be any better at reading RFCs than anyone else?

      RFC 1945 [w3.org], section 12.2 (under the oh so stealthy heading of "Security Considerations"):

      The writers of client software should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they may take which may have an unexpected significance to themselves or others.

      In particular, the convention has been established that the GET and HEAD methods should never have the significance of taking an action other than retrieval. These methods should be considered "safe." This allows user agents to represent other methods, such as POST, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.
      But hey, that RFC was only written in 1996; why would we expect something that was specifically stated as a security problem eleven years ago to be taken into account by security vendors?

      • Re: (Score:1)

        by gazbo ( 517111 )
        Yeah! Useless fucks! Unleash the righteous rage, brother! Or, you know, talk about a subject you have basic understanding of. POST doesn't prevent CSRF in any significant way.

        • It increases the complexity and requirements of implementing the attack.

          With a GET request, all you need is for the victim's browser to visit the URL. You could hide a link, or even put it as the SRC for some other tag. You could hide it in an <IMAGE>, or even a <LINK>. (Or, as another poster pointed out, in an invisible <IFRAME>.)

          With POST, on the other hand, you have to get the victim to submit a deliberately crafted form. With JavaScript you could do this automatically, but that's not

          • Re: (Score:3, Interesting)

            by asdfghjklqwertyuiop ( 649296 )

            With POST, on the other hand, you have to get the victim to submit a deliberately crafted form. With JavaScript you could do this automatically, but that's not nearly as easy as

            Not nearly as easy? Here, lets transform your sample attack into a POST-based one:

            <form id="funnyform" action="http://www.bankofsomethingorother.com/acco unt.asp" method=post>
            <input type=hidden name="action" value="transfer">
            <input type=hidden name="amount" value="1000.00">
            <input type=hidden name="dest" value=

            • Re: (Score:2)

              by platypus ( 18156 )
              Yeah,

              maybe the problem is, that a scripted POST should not be allowed.
              I for one don't see a valid reason for the browser to allow a submit
              method on forms with the method POST.

              I'm sure this was also not in the intention of the authors of this
              respective RFC, because they actually a browser to follow
              a 301, 302 redirect for instance.

              • maybe the problem is, that a scripted POST should not be allowed. I for one don't see a valid reason for the browser to allow a submit method on forms with the method POST.

                What's "a valid reason"?

                We let JavaScript change the innerHTML of random form elements, reassign form actions, change URL's on the fly, make one button disabled when another checkbox is clicked. Maybe we can ask for the valid reasons for all those things.

                We can't call this a flaw in JavaScript. If you were to block, say, submit()


              • I don't have the time right now to give this issue any serious thought, but my immediate reaction is that the present cookie mechanism is too promiscuous. If we had the notion of a secure cookie, I suspect some of these problems could be eliminated.

                A secure cookie is a cookie which includes submission directives: don't send this cookie with any request unless A and B and C are true. These conditions could be that the referrer page was fetched through the same SLL authentication, or from a page with a corr
            • I can block your attack by turning off Javascript. There's nothing I can do in the typical browser to block a GET-based attack.

              • I can block your attack by turning off Javascript. There's nothing I can do in the typical browser to block a GET-based attack.

                There's nothing about this attack that makes it obviously look like an attack though (until maybe after it has happened). Unless you have javascript turned off always or have some sort of per-site whitelist, you wouldn't know when to turn it off.

                And even then, I could forget javascript and trick you into submitting the form yourself by making an image submit or button that looks lik

            • You forgot:
              <input type=hidden name=token value="34879cmaezwqph54yv78trvhzqwiurectwyerty">
              ... which stores my session, and can't be stolen by your form or even your JS on another page in another tab. Who needs cookies if every operation is a POST anyway?

              I've never understood why people put any trust whatsoever in cookie security, when the WHOLE POINT of them seems to be to replay something back to the same site regardless of where you came from.

              Cookies are a nice way to REMEMBER who you are

      • Re: (Score:2)

        by vipw ( 228 )
        And in the real world, who approves every post that scripts make on behalf of the user? I know that I don't.

      • Re:POST vsn GET (Score:4, Informative)

        by spood ( 256582 ) on Thursday June 28, 2007 @12:57PM (#19677759) Homepage Journal
        While it's true that it's much better to follow the RFC here, just switching to POST doesn't solve the CSRF problem. An attacker could set up a malicious Web page which has a form with all the necessary parameters and a JavaScript to automatically submit it, hence meeting the POST requirement. Similarly, if the client has an older version of Flash or a buggy version which does not obey same-source security principles, the attacker could embed a malicious SWF which creates the entire HTTP request from scratch, even forging the Referer header if you were checking that as a security measure.

        This is another good reason for using Firefox extensions such as Flashblock [mozilla.org] and Noscript [noscript.net]. As a client, you can protect yourself pretty easily from a lot of these attacks. Noscript also has some nice features which help filter out the more common brands of XSS attacks.
      • Standards? We don't need no stinkin' standards! ;-)

    • Re: (Score:2)

      by loginx ( 586174 )
      I can send any payload through POST by using AJAX, and you'll never even notice it's been done unless you're monitoring AJAX requests with firebug.

  • All it takes is one malicious site to be open at the same time the Web interface is, and the attacker can gain access to your network, he says.

    So don't manage any device on your network via it's web interface while browsing web sites you don't trust on the Internet. Problem solved. In this day and age you should be careful about opening links to non-trusted sites no matter what.

    If you absolutely must do both at the same time, use one browser for the web and another to manage the device. If you're on Win

    • This happens though. (Score:3, Interesting)

      by khasim ( 1285 )
      You'll be looking for the solution to a problem on a web page and trying it on your firewall.

      In that rare instance, I can see this as being a potential problem.
    • Personally, I surf with Firefox and control with IE (compatible with the intranet).

  • Check Point Edge firmware reset (Score:5, Informative)

    by accessdeniednsp ( 536678 ) <detoler AT gmail DOT com> on Thursday June 28, 2007 @12:35PM (#19677439)
    Anyone with a Check Point Edge or SofaWare appliance, be aware that if you do the reset procedure, you will be restoring both the original configuration *AND* the original firmware image that shipped with the product. Yes, the original image is still there. If you have a very old v3.x firmware box like I had one time, after upgrading to v6.5.x (back then) and then doing a reset, you're in for a surprise :)

  • A good explanation (Score:5, Informative)

    by athloi ( 1075845 ) on Thursday June 28, 2007 @12:43PM (#19677555) Homepage Journal
    CSRF explained [shiflett.org], albeit clumsily. The examples made the article. Solution: use POST requests for user actions, and add unique tokens to each form.

    • Re: (Score:3, Interesting)

      by rthille ( 8526 )
      You should never use GET for actions. The last company I was at had a 'delete' link that was a GET action. And we had a spider that indexed our intranet...

      And the spider deleted everything!

    • Re: (Score:2, Informative)

      by asdfghjklqwertyuiop ( 649296 )

      Solution: use POST requests for user actions


      Using POST will solve nothing. This sort of attack can still be pulled off by Javascript invoking a malicious POST request.

    • Re: (Score:2)

      by Bob9113 ( 14996 )
      Solution: use POST requests for user actions, and add unique tokens to each form.

      POST-only does help if your users have JavaScript and Flash disabled. Not entirely common, unfortunately.

      Adding a unique token to each form doesn't work either. I haven't read the vulnerability anywhere, so I'm not going to say how it fails - but suffice it to say you should use something more robust. Have the user type in something that a computer can't. EG: their password or use a good CAPTCHA.
  • Could anyone explain what this is all about? The article doesn't go into much detail. We all know that any http GET request can be accessed from another website, for example by putting it inside an IMG tag. When the user's browser visits the site, it goes and fetches all the image URIs. But that doesn't seem like an attack, because as we all know, you should never use GET requests for anything other than harmless idempotent information retrieval (to perform potentially dangerous operations use POST requ

    • Re: (Score:3, Informative)

      by bryguy5 ( 512759 )
      POST doesn't help onclick=form.submit()

      You can still do hidden posts with javascript. Just hook up the post to fire on onload or onclick of anything on the malicious site. The form response can be targeted to a hidden iframe so it's invisible to the user.

      Most people have already turned off their browsers post warning and even if they didn't they don't have any reason to think it's posting to their bank's website or firewall device instead of the malicious site.

    • Re: (Score:2, Informative)

      by nolife ( 233813 )
      I supply your browser a link like this:

      http://slashdot.org/users.pl?op=edituser?sig="blow me"

      If you are logged into /. and you happen to click on that link, your signature will be changed to "blow me"
      (okay, I know nothing about scripting and this is just an example but you get the idea)

      How do I supply this link to your browser? One example is on a malicious web page in an image tag, there are many others.
      Since you have a /. set to log in automatically and save your cookie, any request from your machine

      • Re: (Score:2)

        by fbjon ( 692006 )
        In principle, yes, but slashdot requires the correct form key to be submitted as well, so merely clicking on the link won't do. If you could sneak some javascript into the url, then it might be possible to fetch a key first, but slashdot is too restrictive for that, I believe.
        • Also JavaScript cannot retrieve information from remote sites (using AJAX) EXCEPT the server that served the script itself. This prevents lots of ugly cross-site scripting problems, but there is still nothing to prevent iframes and forms from going to any website with any data. Even reading back data might not be too much of a problem with iframes (iframe object has a contentDocument method).

      • Re: (Score:2)

        by Ed Avis ( 5917 )
        If that attack worked, it would be because of a bug in Slashdot - the users.pl script shouldn't allow any setting to be updated just from a GET request. It should require a form submission (POST request) to perform any operation that has a permanent effect. There is no limit to stupidity on the Internet, so I would not be surprised if some bank website allows you to get account.php?transfer_amount_dollars=1000000;dest_ a ccount=12345 but really, if you write web applications where a simple link can have da
  • It's things like this that make me laugh out loud any time I see a security related product, or any product where security is a strong concern for that matter, with a web interface.
  • UTM is the new buzzword for security appliances, which for the lay person is: unified threat management. As complicated as UTMs are, when sold to SMB users, as described in the article, most do not employ a full-time sys-ad and either self configure or hire a consultant. The problem is that daily business needs are dynamic and the average VP/CFO/CTO/CSO/CIO all in one will not configure all of the flags, filters, and rules to adequately protect the internal network, like accidentally placing the file server
  • This has been old news for years, there are much bigger and more real problems out there in commercial sites. Before I worry about CSRF, I'd far rather people sorted out SQL injection and XSS which are ridiculously common. If a site is (reasonably) secure (something I rarely see) then modern frameworks like django already provide tools that eliminate this issue see http://www.djangoproject.com/documentation/csrf/ [djangoproject.com]
  • And this is why - in order to forge the request you have to know the internal IP or host you're trying to exploit in order to construct the CSRF attack vector.

    So this attack ONLY works if you already have some knowledge of the companies internal network structure.

    Here is an example working CSRF attack

    a) I put a CSRF attack on my blog - some AJAX request or hidden image to go to http://internalcompanysite.net/somesoftware/dosome thing?badstuff=this [internalcompanysite.net]
    b) I send sysadmin an email poting at my cool blog
    c) Sysadmin

Slashdot Top Deals

Get hold of portable property. -- Charles Dickens, "Great Expectations"

Close