‫Another attack against session management mechanisms is cross site request forgery, CCF attack.
‫See, SRF is an attack that forces an end user to execute unwanted actions on a web application in which
‫she is currently authenticated.
‫In this attack, the attacker has no way to see the response to the forged request.
‫The attack scenario of CRF is as follows User visits his online banking website, which has CRF vulnerability.
‫He realizes that the website is a brand new interface he can't find.
‫The money transaction function in the new interface, opens a new tab on the browser and searches for
‫the words How to use the new interface of my bank.
‫He finds a website about the new interface of the bank, which is prepared for the attacker who already
‫knows about this SRF vulnerability of the bank website.
‫The page of the attacker's website contains a request to the bank website, and it's about the money
‫transfer from the user's first account to the attacker's account.
‫So when the user visits the attacker's website, he sends the money transfer request to the bank without
‫realizing it.
‫So there are three things we shouldn't miss in this scenario.
‫One.
‫The bank's website is vulnerable to see SRF.
‫To the user visits the attacker's Web site while he is logged in to the bank website and three.
‫The attacker won't see the response of the money transfer request.
‫Does he really need to see it?
‫He will see the response in his bank account so quickly.
‫How is this sees her vulnerability exploited?
‫Go too -- vulnerable.
‫Web application in oash broken web applications log in using admin admin credential quickly sees her
‫link on the menu.
‫We're on a page to change the password of the admin user and current passwords.
‫Not even asked.
‫So let's change a password, for example.
‫One to three.
‫Now log out and log in again.
‫We see that the password of the admin user is changed.
‫Now again, go to see surf page.
‫Great HTML file on the desktop.
‫This is a malicious website that a hacker tries to make the victim click on.
‫View the source of the sea surf page of Dam Vulnerable Web application.
‫Copy the part, which is to change the password and paste it in the HTML file you created on the desktop
‫with his example.
‫First, the victim needs to click a button to exploit CCRC vulnerability.
‫Clear the redundant parts.
‫It's not necessary, but this is just to purify the demo.
‫Phil, the request action clearly.
‫Change the input type is hidden because we don't want to display any field to the victim, give the
‫input value, for example, one one one one in both the new password field and the password confirmation
‫field.
‫Save the file while you're logged in to -- vulnerable web application.
‫Open a new tab on the browser and open the file you prepared.
‫You could open the file by dragging and dropping it onto the tab when you click the button.
‫You will see the password change page and the message, which says the password has been changed.
‫That means we succeeded to change the password of -- vulnerable web application from another website.
‫Now, if you try to log in to dam vulnerable web application using one two three, you cannot because
‫hackers changed the password to one one one one.
‫So with a little help of scripting, we can eliminate the button phase easily.
‫So a simple visit of the victim will be enough to change the password.
‫Give an idea name to the action.
‫Changed the password to understand if the attack succeeds, for example one.
‫Make the change input type hidden.
‫Now let's write the script code, which triggers the action we wrote.
‫Save the file.
‫When you're logged in to -- vulnerable Web application, open a new tab on the browser and open the
‫file you prepared again, you can open the file by dragging and dropping it onto the tab.
‫In this case, you will see the message password changed as soon as you open the page when you want
‫to log into the application again.
‫You will see that the password is no longer one one one one.