The title is pretty self-explanatory. I know that the lack of CSRF token in login page could lead to privacy violations(according to this link). However what I am concerned about is that could it lead to any new vulnerability in an authentication server's login page?
-
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. – Linda Lawton - DaImTo Oct 17 '18 at 06:48
-
Hi. Thanks for the advice. But I think the question is limited to a specific problem(The security vulnerabilities of not having a CSRF token in an authentication server's login page in OpenID-Connect). I would gladly edit the post if you specify which part of the question is vague or does not have enough details. – Amir Qasemi Oct 18 '18 at 05:56
1 Answers
I would say that protections against Cross-Site Request Forgery (CSRF) are required, but having to use CSRF tokens is not necessarily required. These tokens are a typical and common solution, but anything that keeps the user safe from this attack should be adequate.
So, stepping back, OWASP says:
Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated.
Their CSRF cheatsheet has a number of possible protections (including non-token-based options). Some or all of these are what an OpenID Connect provider should support:
- Use of only SameSite cookies or a SameSite maker cookie to track cross-site requests
- Use of custom headers in the request
- Verification of the origin using standard headers
- Use of double submit cookies
- Never changing state in a GET request
Also, don't forget to also protect against Cross-Site Scripting (XSS) or else some of these protections can be defeated. That can be done using CSP and other techniques.
- 2,231
- 16
- 26