M
M
MdaUZH2016-01-19 16:54:14
PHP
MdaUZH, 2016-01-19 16:54:14

CSRF secret key, eternal session?

Hello everyone, I'm interested in protection against CSRF attacks.
Everything would be fine, when initializing the session, I generate a unique token, insert it into all forms and check it before processing, but I don’t understand here.
Wouldn't such an attack work?
since the attack passes checks like -authorization and so on, won't it pass through the token?
Here is an example:
I went to the bank's website, logged in, a unique token was generated for protection, it is in session.
I go to the site where there is a post with a picture:

смотри на картиночку  <img src=" bank.example .com/peredat=100000&for=komu-to.. " alt="check me">

There is a check for a unique token, won't it pass?
after all, the token exists and there are no problems, it is clear that GET is not used for such tasks, but something similar can be done with POST, right?
Another thing is "harder" protection, where the token is generated every time for every form.
but here, too, there may be such a situation:
1. I went to the page with the form, the token was generated.
2. I didn't do anything left the site.
3. went to the site of the attacker, with the same picture
??? PROFIT, didn't the attack succeed?
If I don't understand something, could you explain to me why not?
Thank you very much

Answer the question

In order to leave comments, you need to log in

2 answer(s)
A
Andrey, 2016-01-19
@VladimirAndreev

no, it didn't work. if the token is issued by a POST request, then it will not be possible to get it from the victim's browser

S
Stalker_RED, 2017-01-25
@Stalker_RED

1. I went to the page with the form, the token was generated.
2. I didn't do anything left the site.
3. went to the site of the attacker, with the same picture

1. Generated, signed up for a session and a hidden form field.
2. The form is destroyed, the token is not saved in cookies, of course it remained in the session, well, figs with it. Even if the page is not closed, but lives in a separate tab, it doesn't matter, because:
3. the picture cannot send a POST request, and even if it could, there is no token in cookies , access to a hidden form field in another tab The picture doesn't have one either.
In summary: if the attacker didn’t inject his scripts onto the bank’s page, didn’t inject his plugin into the victim’s browser, didn’t plant a Trojan into his operating system, and didn’t decrypt the intercepted traffic, then he seems to be unable to do anything.
And if the bank transfers money on get requests, run away from it.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question