0

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?

ParleParle
  • 1
  • 1
    It's hard to say without knowing more about the POC. Could you try going through exactly what it does? Is the script just the attack, or perhaps some setup as well? What do you mean with "using a valid login to crehate the POC"? – Anders Dec 15 '17 at 09:14
  • 2
    Unsure what you're asking here, but if they've proven CSRF is an issue, it's irrelevant who they're logged in as. –  Dec 15 '17 at 10:24
  • I think based on his title "Is this a true CSRF attack?" if it only works when the person is logged in and can't be used on anyone on demand, he wants to know if the pen testers are not giving "make believe" vulnerabilities and he wants to confirm it's truly a vulnerability. I've addressed it in my answer. – Wadih M. Jan 30 '18 at 16:21

2 Answers2

3

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.

Wadih M.
  • 1,102
  • 6
  • 20
0

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.

shawkyz1
  • 126
  • 4
  • To provide closure I did exactly this. I discussed it with the auditor, there was several back and forth emails of debate. He ended up demoting the vulnerability from a HIGH to a LOW due to the need of a very targeted attack being needed with the combination of a successful XSS attack preceeding it. And then in the end he closed the the vulnerability completely when I also implemented origin and referer url checks. – ParleParle Jun 01 '18 at 03:05