Wilsonator123 / Secure-Blog-Page

DSS Projecy
1 stars 0 forks source link

Research CSRF preventions methods #13

Open Wilsonator123 opened 6 months ago

Wilsonator123 commented 6 months ago
thealextaft commented 5 months ago

### Research Synchronizer Token Pattern (CSRF Tokens) are the most popular and even recommended form to mitigate CSRF attacks.

They are generated on server-side and will be generated on a “per-request” basis, these are more secure but cause more problems as even using the back button can bring up a false positive flag as the token may have expired. “per sessions” are stored in the session and is used for each request until session ends.

Each request that a client issues the server-side component will verify the existence and validity of the token and compare it to the one found in the session. Requests will be rejected if that token was not found within the request or the value provided does not match the value within the users session. Attacks should be logged.

These tokens will be: Unique per user session, unpredictable and private.

The token will be transmitted to the client as part of a response payload such as a HTML or JSON reply. It'll then be transmitted back to server as a hidden field on a form submission . They shouldn't be transmitted through cookies, must not be leaked in the server logs / URL. Get requests can leak the token at several locations e.g. browser history, logs, network utils and referer headers.

It is more secure to put the token in a custom HTTP request header via JS than adding a CSRF token in the hidden field form parameter.

Cross Site Scripting Prevention - OWASP Cheat Sheet Series XSS ^^^^

Wilsonator123 commented 5 months ago

Can you explain this a bit more. Is this different to a session id/cookie.
Maybe a step-by-step on what the process looks like

Wilsonator123 commented 5 months ago

Also can we have a more specified list of changes/features we are actively implemented.

E.g.

  1. Implement CSRF Token
  2. Sensitive forms require 2fa or CAPTCHA to be completed
Wilsonator123 commented 5 months ago

@thealextaft

thealextaft commented 5 months ago

Session Token = Authenticate User. CSRF Token = Authenticate Request.

CAPTCHA for sensitive forms (blog posts) - to prevent from spam posts from bots 2FA for log in.

Step-by-step incoming

thealextaft commented 5 months ago

How will i implement CSRF.txt

stepbystep.docx

Wilsonator123 commented 5 months ago

Step-by-step CSRF

  1. Page loads, server-side will generate one CSRF which will be provided to both the users cookies and the form
  2. User interacts with form on the frontend
  3. Before submitting the form, the frontend code injects the CSRF token into the hidden input field (not visible to user)
  4. User submits form, data is sent to server form processing
  5. This is then intercepted by the server-side CSRF middleware
  6. Middleware validates the token included in request to see if they match
  7. if valid, server processes normally; otherwise rejects

Tokens look like this:

Image


CSRF Tokens are random/unique, these are typically stored in the user’s session data and are generated on a per-request basis. They are generated as the page is opened, the tokens on other pages will then expire. As previously explained in the step-by-step, the token is sent through the hidden field and then compared on the server-side (using the HTTP header and form data).

Different tokens = not processed, Same token = processed.

thealextaft commented 5 months ago

thank you george for making it not have to be downloaded

Wilsonator123 commented 5 months ago

Screenshot_20240328-202436.png

Wilsonator123 commented 5 months ago

Kill yourself