Cross-Site Request Forgery
Learn about cross-site request forgery, same-site cookie, and using components with known vulnerabilities.
We'll cover the following...
What is CSRF?
Cross-site request forgery (CSRF) used to be a bigger issue than it is now. These days, most web frameworks automatically include defenses against it. But a lot of old applications are out there. Some are vulnerable targets, while others can be used as stooges.
A CSRF attack starts on another site. An attacker uses a web page with JavaScript, CSS, or HTML that includes a link to our system. When the hapless user’s browser accesses our system, our system thinks it’s a valid request from that user. Boom,your user is roasted. Note that the user’s browser will send all the usual cookies, including session cookies. Just because the user appears to have a logged-in session doesn’t mean the request is intentional. The first thing to do is make sure our site can’t be used to launch CSRF attacks. XSS is a common trap. If the attacker can supply input that we display without proper escaping, the attacker can trick people into viewing it through our site. Second, make sure that requests with side effects, such as, password changes, mailing address updates, or purchases, use anti-CSRF tokens. These are extra fields containing random data that our system emits when rendering a form. Our code expects to get the same token back when the user submits the form. If the token is missing or doesn’t match, it means the request is bogus. Most frameworks today do this for you, but we might have to enable CSRF protection in our service’s configuration.
SameSite cookie
We can also tighten up our cookie policy with the relatively new SameSite attribute
...