I seem to misunderstand CSRF?

After reading many documents regarding CSRF, I'm still a little confused. So I hope someone can explain this to me:

  • Say, if I have a profile page that is only for authenticated users, say abc.com/profile, which shows me all my personal information. If I log in, go to the "bad" site, can this site somehow get and analyze my profile page? (I did a little work by opening the firebug console on another site, and then I request my profile page, and it seems that at least I can see all the content in the "response" of the "Network" tab, I did not understand how to get this content and analyze him, although perhaps perhaps?)

  • Now suppose I have a form on my profile page that, of course, has the csrf token. Now, if an attacker can get my page with advanced privileges, can he just parse this content, get a token and send a fake form?

  • Now suppose that 1 and 2 are correct, what should I do to prevent such cases?

+6
source share
3 answers

Your first question is incorrect.
You cannot read content from another domain on the client.

Therefore, a hostile site cannot read the CSRF token.

You can send requests to another domain (this is what CSRF attacks do), but you cannot read the answers.

+6
source

Your scores are not entirely correct ... But take this scenario.

Attack example


Imagine that a user has logged into the Official Bank of a fake country - GoodBank.com and has a balance of 1,000,000 gold.

At MaliciousSite.com there is <img> or some other generic JavaScript that forces you to make a GoodBank.com request.

<img> has src of http://www.goodbank.com/account/transfer.php?amount=10000&sentTo=malicioususer .


Now this site has made a request for your user account and made you link to a page that you would not otherwise have.

Now you might think that you can protect yourself from this using only POST, but they are also not safe. The right way is to use CSRF tokens in your forms, and when the form is submitted, you should check that the CSRF token you receive matches the one that was issued.

Do not use these measures to protect yourself :

  • Secret Cookies
  • Only accept POST requests
  • Multipage Forms
  • URL Rewriting

Instead, use the token as follows:

 <form action="/transfer.do" method="post"> <input type="hidden" name="CSRFToken" value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZjMTVi MGYwMGEwOA=="></form> 

See here for a great explanation: CSRF Cheat Sheet

+9
source

This may not be directly related to the issue, but it must be pointed out that attacks on cross-site scripting can open the door for CSRF. Even token-based solutions used to prevent CSRF can be compromised by XSS.

Run the following script.

The form used to update user information.

 <script> ... var userID=getUserId();//method makes AJAX call to get user ID ... </script> ... <form name="UpdateUserProfile"> <input type='hidden' id='userId' value='userID_attacker_cannot_guess'> <input type='hidden' id='userName' value='goodUser'> <input type='hidden' id='email' value=' goodUser@goodsite.com '> ... </form> 

Assuming that the user ID is unique and cannot be easily guessed, we can prevent CRSF without a token. (An attacker request cannot have the correct user ID).

But if an attacker can read the value of userID using an XSS attack, he can then process a fake request to include the correct user ID.

Although CSRF attacks do not require XSS, this will simplify the work.

Check out the following resources.

Cross Site Request Forgery (CSRF) -OWASP

Cross Site Scripting (XSS) -OWASP

+1
source

Source: https://habr.com/ru/post/896438/


All Articles