SEC504: Hacker Tools, Techniques, and Incident Handling

Experience SANS training through course previews.
Learn MoreLet us help.
Contact usConnect, learn, and share with other cybersecurity professionals
Engage, challenge, and network with fellow CISOs in this exclusive community of security leaders
Become a member for instant access to our free resources.
Sign UpMission-focused cybersecurity training for government, defense, and education
Explore industry-specific programming and customized training solutions
Sponsor a SANS event or research paper
We're here to help.
Contact UsCross Site Request Forgery (CWE-352) is one of the more common vulnerabilities in existent today. Although it is relatively common, not all instances of vulnerability provide sufficient incentive for an attacker to exploit the vulnerability.
The vulnerability is based on the fact that the web application assumes any request by the user is a legitimate request intended by the user. This assumption may sound logical but is not always correct. An attacker can craft a web page with a link to the vulnerable page, to the web page that is the victim, there is no indication that the user followed a link or instruction on another site to visit the victim page. When a user visit any web page, the browser automatically follow all the instructions like scripting or grabbing remote images from other sites. While the browser is following instruction, it might have triggered actions on another site without the user or the browser even noticing about it. CSRF attacks allow the attackers to perform actions on behalf of the victim (user), all without the knowledge and approval of the victim.
When CSRF attack happens, the attacker does not have ability to "see" the interaction between the attacker and the victim site. A request has to be crafted before the attack. Leveraging this fact, one of the CSRF mitigation is to generate a random token to be submitted with every input form so that only the user and the site knows the token, an attacker not being able to "see" the traffic would not know the correct token value and therefore would not be able to launch an attack. The best way to inject such token into every form should be done by standard API such as the OWASP CSRFGuard. If you are using ViewState with a .Net application, you can also use ViewStateUserKey to prevent CSRF attack.
One thing worth noticing is that XSS undermine the controls put in place to stop CSRF. With XSS, the browser is effectively being controlled by the attacker, any tokens set inside the browser can be retrieved by the attacker as well. XSS should be eliminated before CSRF protection becomes fully effective. CSRF is often combined in real life attacks so that the attacker can perform actions on behalf of the user and in turn benefit the attacker.
Jason is a leading consultant sought after by Global 500 companies across finance, healthcare, and technology sectors worldwide. Over the years, he has led intrusion detection, penetration testing, defense improvement programs, and incident response.
Read more about Jason Lam