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.




Network Security Web-App-Sec
[Top] [All Lists]

Re: blocking CSRF attacks

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


-------------------------------------------------------------------------
Sponsored by: Watchfire Methodologies & Tools for Web Application Security Assessment With the rapid rise in the number and types of security threats, web application security assessments should be considered a crucial phase in the development of any web application. What methodology should be followed? What tools can accelerate the assessment process? Download this Whitepaper today!


https://www.watchfire.com/securearea/whitepapers.aspx?id=70170000000940F
-------------------------------------------------------------------------

<Prev in Thread] Current Thread [Next in Thread>