CSRF stand for cross-site request forgery. It is where the attacker sit can remotely, create a dummy form, and submit it via a valid session of a user who is already logged in either via a chat application or a phishing attack. There are basically 2 ways by which this attack can be performed. First is, where the attacker tricks the victim to click a link or load a page. This is basically done by social engineering and malicious links. The second part is where the attacker sends a crafted, legitimate-looking request (Trojan) from the victim’s browser to the website.
As the name of the attack suggests this forgery is possible only after the request is granted i.e. when the following assumptions are fulfilled:
1) Valid session.
2) Form parameters.
3) Timing of the session execution on the same browser.
Although as mentioned above the attacker will need to get all the assumptions right to proceed with the CSRF attack, it also has to be to be considered that the attacker is no ordinary person. He can send millions of requests to random users and can easily get hold of at least few valid sessions.
Once this attack has been executed, the impact is greater than any, because the attacker gets full control over the application’s data and functionalities especially when the victim has privileged roles within the application. CSRF is successful even through phishing attack. Through this attacker can easily cause the victim user to carry out any action unintentionally which will impact the CIA model.
One of the way through which CSRF can be prevented is by implementing a hidden unique identity parameter within the form and validating the same from the server side. This is called CSRF token. This can ensure whether the session is being proceeded by a valid user or not because the attacker would need to guess the token to successfully trick a victim into sending a valid request. So 2 important things to be followed are: