Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Re: blocking CSRF attacks |
|---|---|
| Date: | Thu, 13 Dec 2007 15:44:17 -0500 |
any one on the list aware of any IDS/IPS capable of blocking CSRF attacks?
If not, what will be the best policy to block CSRF
One problem with CSRF attacks are that they obey the specs.
Are you looking for a server-side solution? Or client-side?
If you want a band-aid solution to apply enterprise-wide, your best bet is probably to check the Referer header. You need to be aware that there are some valid reasons that the Referer will not match where the form is eventually submitted (store.example.com could legitimately submit a form to checkout.example.com). And there have been some implementation problems with Flash and JavaScript that have allowed attackers to forge the Referer header. So this may be an entirely fruitless endeavor.
Another thing is to watch for the outgoing form and the reply. If you've never sent the form, you shouldn't get the reply. This is only useful in certain circumstances, obviously. If you apply this trick client-side you might have more information and be able to come up with a decent heuristic that correlates that you're dealing with the form that "looks right" or comes from the "right place," but I'm not sure that's an arms race that can be won. Correlating the form with the submission could be a nightmare.
If you're using HTTPS, your job just became a whole lot harder. Ironically, those are the probably the most important sessions to protect. (There do exist tools that that decrypt the SSL sessions if you share the server key with them. This has obvious trade-offs.)
If you're trying to protect all your users client-side, you'll probably get the most bang-for-the-buck by having them run something like NoScript everywhere. It's definitely not perfect, since I can still submit a POST form if I get the user to click on my hostile "submit" button.
We drew up a list of protection methods that can be done both by developers and end-users here: http://labs.calyptix.com/csrf-tracking.php
https://www.watchfire.com/securearea/whitepapers.aspx?id=70170000000940F -------------------------------------------------------------------------
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | RE: Defining scope of web application pentest (now scope of an annual medical exam), Vishal Garg |
|---|---|
| Next by Date: | Re: blocking CSRF attacks, Sverre H. Huseby |
| Previous by Thread: | RE: blocking CSRF attacks, Boaz Shunami |
| Next by Thread: | Re: FW: blocking CSRF attacks, Paul Johnston |
| Indexes: | [Date] [Thread] [Top] [All Lists] |