![]() |
||
Total Website Security |
||
![]() |
||
![]() |
![]() |
|
|
|
Whitepapers ::
Cross Site Request Forgery (CSRF) :: August 2007 :: Cross-Site Request Forgeries (CSRF). Session Riding. Client-Side Trojans. Confused Deputy. Web Trojans. Confused? Every year, for the past several years, the exact same Web attack is discovered, analyzed, and subsequently renamed. Whatever it’s called, it all means the same thing: An attacker is forcing an unsuspecting user’s browser to send requests they didn’t intend and potentially compromising their own banking, e-commerce or other website accounts. Attackers have begun to actively exploit CSRF vulnerabilities across the Web. Why now? Because it’s incredibly easy and the vast majority of websites are vulnerable to it. How do you stop an attack originating from a “real user,” who could be properly logged-in, from making a legitimate request - except the problem is they did not intend to make the request? For those familiar with Cross-Site Scripting, Chris Shiflett (principal of OmniT) said it best: “Cross-Site Request Forgeries are an almost opposite style of attack. Rather than exploiting the trust that a user has for a website, they (CSRF attacks) exploit the trust that a website has for a user. Here’s an example of how a CSRF attack works: Let’s say you’re logged-in to your online bank, which has a “Transfer Funds” feature. To transfer money from one accountto another, you would fill out a Web-form similar to the one in Figure 1. After specifying the appropriate “From” account,
|
|
![]() |
||
|
||
![]() |
||
![]() |
||