What is CSRF cross site request forgery and basic concepts :
Cross-Site Request Forgery (CSRF) is also known as the one-click attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. When the victim is browsing an attacker can access functionality in a target web application via this already authenticated browser if the victim in this way. Targets include web applications like social media, in-browser email clients, online banking and web interfaces for network devices.
CSRF attacks specifically not to theft the data but mainly target on state-changing requests. By sending link via email or chat an attacker can use the victim’s browser easily to execute the actions easily. CSRF attack will be successful to force the user to perform state changing requests only if the victim is a normal user. Otherwise CSRF can manage the entire web application.
How Does Cross-Site Request Forgery Work :
An attacker sent a malicious requests to another site where the victim is validated against and these malicious requests are routed to the target site via the victim’s browser. The vulnerability lies in the affected web application, not the victim’s browser or the site hosting the CSRF.
Since cross-site requests do not need your permission, an attacker can abuse this and send requests without your consent and without you noticing.
The most commonly implementing CSRF protection techniques in the web application is the anti-CSRF tokens, which is resulting to reduce the overall risk. You are not protected from the CSRF attacks if your web application used the anti-CSRF tokens. Coding / implementation errors lead to vulnerable applications.
Use of CSRF tokens and how to prevent CSRF attack by using token :
The most common approach to prevent the Cross-site Request Forgery (CSRF) using an anti-CSRF token that has already been provided to the browser, or preventing the browser from sending Cookies to the web application.
When the user is browsing and wish to send any requests, it is necessary to append CSRF tokens to each request and associate them with the user’s session to prevent Cross-Site Request Forgery (CSRF) attacks . These tokens be unique per request and be unique per user session. And the developer can ensure the protection that the coming request is valid or coming from an unauthenticated user by using the challenging tokens.
The concept is simple, when a user submits a form or makes some other authenticated request the anti-CSRF token should be included in the request and before processing the request, the web application will then verify the existence and correctness of this token If the token is missing or incorrect, the request can be rejected.
The same-site Cookie is a new attribute that can be set on Cookies to instruct the browser to disable third-party usage for specific Cookies. That means, this attribute will set by the server when setting the Cookie, and requests the browser to only send the cookie in a first-party context, therefore, it ensure that the request has to originate from the authenticated origin – requests made by third-party sites will not include the same-site Cookie. This effectively eliminates Cross-site Request Forgery (CSRF) without the use of synchronizer tokens. But this method of CSRF is only effective in some modern browsers.
The easiest way to check whether an application is vulnerable or not by checking each link and forms that contain an unpredictable token for each user. An attacker can forge malicious requests without such an unpredictable token. Focus on the links and forms that invoke state-changing functions, since those are the most important CSRF targets.
The Google Chrome team added a new attribute to the
Set-Cookie header to help prevent CSRF, and it quickly became supported by the other browser vendors. The
Same-Site cookie attribute allows developers to instruct browsers to control whether cookies are sent along with the request initiated by third-party domains.
Setting a Same-Site attribute to a cookie is quite simple:
Set-Cookie: CookieName=CookieValue; SameSite=Lax; Set-Cookie: CookieName=CookieValue; SameSite=Strict;