Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to protect against CSRF on a static site?

I have a static website, being served from a CDN, that communicates with an API via AJAX. How do I protect against CSRF?

Since I do not have control over how the static website is served, I cannot generate a CSRF token when someone loads my static website (and insert the token into forms or send it with my AJAX requests). I could create a GET endpoint to retrieve the token, but it seems like an attacker could simply access that endpoint and use the token it provides?

Is there an effective way to prevent against CSRF with this stack?


Additional details: authentication is completely separate here. Some of the API requests for which I want CSRF protection are authenticated endpoints, and some are public POST requests (but I want to confirm that they are coming from my site, not someone else's)

like image 957
Justin Avatar asked Jun 28 '17 17:06

Justin


People also ask

How can CSRF attacks be prevented?

What Are CSRF Tokens. The most popular method to prevent Cross-site Request Forgery is to use a challenge token that is associated with a particular user and that is sent as a hidden value in every state-changing form in the web app.

Does Same site prevent CSRF?

Some web sites defend against CSRF attacks using SameSite cookies. The SameSite attribute can be used to control whether and how cookies are submitted in cross-site requests.

Which of the following is the best defense against CSRF attacks?

The most robust way to defend against CSRF attacks is to include a CSRF token within relevant requests.

How do you prevent CSRF attacks in REST API?

Enable CSRF Protection With REST API If our project requires CSRF protection, we can send the CSRF token with a cookie by using CookieCsrfTokenRepository in a custom WebSecurityConfigurerAdapter. After restarting the app, our requests receive HTTP errors, which means that CSRF protection is enabled.


1 Answers

I could create a GET endpoint to retrieve the token, but it seems like an attacker could simply access that endpoint and use the token it provides?

Correct. But CSRF tokens are not meant to be secret. They only exist to confirm an action is performed in the order expected by one user (e.g. a form POST only follows a GET request for the form). Even on a dynamic website an attacker could submit their own GET request to a page and parse out the CSRF token embedded in a form.

From OWASP:

CSRF is an attack that tricks the victim into submitting a malicious request. It inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf.

It's perfectly valid to make an initial GET request on page load to get a fresh token and then submit it with the request performing an action.

If you want to confirm the identity of the person making the request you'll need authentication, which is a separate concern from CSRF.

like image 169
Matt S Avatar answered Oct 20 '22 03:10

Matt S