SBN

The difference between Cross-Site and Server-Side Request Forgery

Introduction to CSRF and SSRF

Cross-Site Request Forgery and Server-Side Request Forgery attacks have similar names, and both take advantage of how servers process URLs. However, these attacks have very different purposes and impacts. Understanding the difference between them is an important part of penetration testing for web applications.

Cross-Site Request Forgery

Cross-Site Request Forgery (CSRF) vulnerabilities have been featured on the OWASP Top Ten List for web applications until the most recent version. The reason for dropping them from the 2017 edition was that many web application frameworks contain CSRF protections; however, they were still present in 5% of web applications at the time of release.

The purpose of CSRF attacks is to force a user to take undesired actions on their online account. Accomplishing this involves taking advantage of state-changing requests, where a web server will take some action based upon an authenticated user browsing to a particular page. Examples may include changing an account password or making a transaction via an online banking portal.

An attacker exploits a CSRF vulnerability when a user visits a website designed to force secondary requests to a certain site. For example, the website may include an image or iframe which claims that it needs to be fetched from a certain webpage on the target site. When the user’s browser tries to fetch the content, it makes a state-changing request on the target site and resets a password or performs a financial transaction.

CSRF attacks work because the user is already authenticated to the target site and the forced request includes the cookie containing session information. 

Standard CSRF attacks assume that a user is already authenticated to a site, but CSRF attacks can also be “stored.” For example, the malicious image or iframe may be an advertisement that digital ad (Read more...)

*** This is a Security Bloggers Network syndicated blog from Infosec Resources authored by Howard Poston. Read the original post at: http://feedproxy.google.com/~r/infosecResources/~3/fQj8YUw78V8/