So cross site request forgery or SRF is another session management problem.
So this vulnerability hits the all the applications that set their authentication and session management
mechanisms solely on the use of cookies.
And yeah, I said earlier that Web applications use cookies for differentiating users, but I certainly
did not say that this is 100 percent secure.
So allow me to explain.
Think of what you need to put into an HDP request when you perform an action on an application.
You need to submit both the data and the session and to the Web server.
Now, that way the server will understand it as your legitimate request and then it processes it.
So the server can differentiate you by your session ID.
And if somehow someone uses your session ID instead of you, what can happen?
Well, here's where the problem arises.
So let's see what we have.
Open carry, as always, and log in to be web.
Now, open cross site request forgery with the change password option from the menu.
And here are several CSR scenarios here.
And we're going to look at how they work, so the first one is a password change form.
So also open burb and enable foxy piroxicam.
And let's type something to change a password.
And we have a request in berp.
And this is the password change request.
And this is a legitimate request, right?
So I'm going to send it to the compare tool.
And forward it.
And looky here, the password has been changed, so now, right, click and view the page source.
Here's a source of the form.
This form produces the previous request.
So don't you wonder if you use the same form in your application, so now send the request to be Web?
How would be to behave in a situation like this?
Why don't we have a look?
So open up your terminal.
Now, I quoted this page, which produces this same request as a password change form, you can download
it from here.
So here's an iFrame, which requests a password change from Web.
And we also have a second option.
And this one's almost the same as the actual form.
So let's look at the values, so these are the values that we want to set as password.
And the form submitted by a JavaScript code when the page opens.
OK, now I'm going to clear all the information in Firefox and I'm going to open one of these pages
from County directly.
Remember to enable berp.
Now, double click this one, and it will immediately open in a browser and Birbal capture it.
So it's similar to the previous one, right?
So send it to compare as well.
You can drop it.
And here's a source of the page.
OK, so go to compare her.
So Compar is yet another valuable tool in burb sweet.
And both requests are here.
And now click on words in order to compare them word for word.
And here is a result.
So the request on the right is our fake request.
Is almost the same to the actual one.
Can you see the difference?
There's an important small header.
So it's not the same, it's the cookie cutter.
The request on the left is a legitimate and authenticated request.
The other is not so the browser adds the cookie to the original request.
Because the actual user triggers a password change form.
So anyway, we can create such a fake request, but we cannot send it to the server on behalf of the
actual user because we need the users session ID.
So we need to force the user to open our page while he is displaying the same page.
OK, so close it up and clear.
So I'm going to go back to burb here again and I will open that page and remember to enable berp.
So I'm going to change the password again.
Send it to compare as well.
OK, so as a victim, I'm displaying the page that contains an insecure form.
Now, at the same time, I'll open a suspicious application in another tab in the same browser.
And again, you need to use some social engineering techniques in order to deceive the victim.
I almost forgot to enable berp again.
OK, so refresh the suspicious page.
And this is a fake request.
Send it to compare as well.
And just leave it.
Now, go to compare.
And click to see the difference between them.
So this time, there is no important difference because the browser tries to request a server that is
the server of the application that's open in another tab.
So our fake request will go to the B Web server.
And naturally, the browser adds a cookie header to the request.
So now there is the user session ID in our FAQ request.
So that way we can change the user's password.
It's also an example of insecure resat or the change function in applications.
All right, so go ahead and close it.
And on this show, the result.
So go to my admin interface, a B box.
And then browse the user's table.
And this is the changed password.
So search it on Google.
Go to the first one.
And here is a result, we're able to change the victim's password.