Slashdot Mirror

← Back to Stories (view on slashdot.org)

Major Flaw Found In Security Products

Posted by kdawson on 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."

2 of 153 comments (clear)

  1. Re:What the ... ? by bryguy5 · · Score: 3, Interesting

    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 both would require changes to the browser.

    1) Allow Users/Webservers to determine that a cookie should be bound to a particular window, so that a request originating from a different window containing the malicious site does not include the cookie.

    2) Add an extension to the cookie protocol where the cookie always sends the url and ipaddress that is the source of the request (I haven't thought out what the source is with confusing external js scripts which may be controled by js in the main html) - this would allow sites to weed out requests generated from malicious sources.

    Both of these would still allow the exploit to be used in XSS situations, but could plug the hole in the more general cases.

    Without a change to the browsers your best off generating some type of session token and passing it back and forth on the url and using that and a cookie as two part authentication. The malicious site shouldn't be able to read or guess the url's. A lot messier than simple cookie based authentication.

  2. Re:POST vsn GET by ckd · · Score: 5, Interesting

    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, 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?