Is this a true CSRF attack?

Question

I have been fixing a asp.net web forms application that has a number of vulnerabilities that were discovered by an outside pen testing firm.

I have recently implemented a double submit cookie with the asp.net AntiForgery library. Also setting ViewStateUserKey to use the sessionId.

The pen testers provided a POC CSRF script within an html page. It attempts to upload a file to the website. When I try to use it it does not succeed and invalid viewstate errors are logged on the web server.

I discovered that the pen testers are using a valid login to create the POC script but then they use the same login as the target victim.

Is the POC script not meant to be created from another valid login? Isn't that cheating by using the same login to create the attack script as well as the victim?

Answer 1

Yes, it is a true CSRF attack.

Keep in mind, a CSRF attack is designed to happen with an external forged link sent to somebody that's already logged in, to make them do an action in their session they didn't intend to do.

Classic example would be your banking website, you would be logged in, and somebody would send you an external email with a forged link.

So you receive that forged link in your email, you click on the link, it opens a new tab in your browser, assuming you're already logged in, and the command in the URL gets executed right in your bank's current session.

For example the way to transfer funds via a GET query could be something like: https://mybankingwebsite.com/transfer/500/to/attacker-bank-account

So now anybody that is using your bank, and that's logged in, and clicks on that link, will be sending 500$ to the attacker-bank-account. But it wasn't you that wanted to do that command, the link came from somewhere else, but it gets executed in your logged in bank account context. That's a CSRF.

Facebook used to be vulnerable to CSRF attacks as well, and a lot of other sites. For example, a forged link in Facebook could result in you posting something on your wall that you never intended to.

Answer 2

According to OWASP ViewStateUserKey is an acceptable way to prevent CSRF due to it's uniqueness in the context of the user and the session. Also using the same login creds as the one in the PoC script doesn't make much sense in that case. I would suggest talking directly to the auditor and ask what his intention with this script was.

Moreover, by only depending on the ViewState mechanism it won't prevent CSRF in your application. What if you're directly sending AJAX requests to your back-end? In this case you may need to implement a custom header with a CSRF token and check and validate this token in the server.