A cross site request forgery (CSRF) attack exploits the generally accepted logic of web browsers for managing a user session in open pages. The standard is that a user can only have one active session in the web application they are currently using. Any newly opened tab in your browser will automatically use the cookies of the user already logged in. The attacker uses this fact most often by sending his victim a specially prepared link after clicking on which action will be triggered (e.g. password changes) on the page where the victim has an active session.
Protection against this type of attack is most often by adding a special unique and unpredictable parameter, at least per session, which is glued as a variable to sensitive requests (e.g. changing the password, adding a new user) and the correctness of which is verified by the server. An attacker who does not know the value of this token is unable to generate a request that the server will not reject due to the antiCSRF token's non-compliance.
In one of the applications I tested, I discovered the possibility of carrying out many CSRF attacks. One example is to prepare a specially crafted page after entering which, by the logged-in user, a password-changing request will be made on the user's behalf. The following is the code for this page, along with the parameters that are responsible for giving the new password. Note that the selected line in the following printout shows the code that defines the input form fieldwhere the new password is defined.
An automatically sent request that uses sessions from the user who entered the substituted page looks like the following:
Host: XXXXX
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
[...]
-----------------------------70124987214088125821572825923
Content-Disposition: form-data; name="newpassword"
csrf
[...]
In response, the application confirms the password change, which is shown in the following screenshot:
