CODEWITHSUNDEEP
asp.netforms
Mickael Caruso
Mickael Caruso

Reputation: 9491

ASP.net Protect Against Pasted Submit Button With In-Browser Developer Tools?

This is not a cross-site attack because it happens on the same website.

Before we render to the browser, we figure out in server-side whether to render a button or not based on whether the user has sufficient credit in their account (example case). So, if they have insufficient credit, the check out button doesn't even make it to the page on page load.

Here's what they did:

  1. Go to a purchase product page when they have sufficient credit. The check out button shows.
  2. They look at Inspector (FireFox) or any other in-browser developer tool and copy the html input element that submits the form.
  3. They purchase as normal. Now, they have insufficient credit.
  4. They go to another purchase product page, and of course, the check out button will no longer show (because it didn't even make it on page load in the first place).
  5. They open up their in-browser developer tool and paste the input element copied from the other previous page when they had sufficient credit. The button shows up on the rendered page. They click it, then they proceed as if they had sufficient credit.

The problem is, the submit button's event handler in code behind is unaware of the existence or non-existence of that submit button, and will execute if called, and that we give it a hard-coded id.

The obvious solution would be to do a credit vs. price check [again] on the click event handler. From inside the event handler, is there a way to determine whether the control existed on page load? I figure that the sender parameter would not be null if they pasted a control in-browser, so there's not much help there.

Any solutions on this?

Upvotes: 0

Views: 46

Answers (2)

TheCatWhisperer
TheCatWhisperer

Reputation: 981

The only safe solution to this is to check if the user has sufficient credits ON THE SERVER after the postback occurs.

protected void OnSubmit(object sender, eventargs e)
{
 if (product.Price > User.Credits) {
   throw new Exception();
 }
 purchase();
}

If you use the check the button approach then they can still use the JavaScript console to call __doPostBack

Never rely on the client side for authorization

Upvotes: 3

Brian Mains
Brian Mains

Reputation: 50728

You could store in ViewState whether the button was rendered or not; this is encrypted and cannot be changed on the client. If you set it as ViewState["ButtonRendered"] = true;, then you can check this to see if it's true or false, and act accordingly.

Because of the nature of the user opening up multiple browsers, and other tricks, I would 100% recommend you do another database query to make sure they have sufficient credit, and if not, display an error to the user. That would be the absolute best way of handling it. What would keep them from opening up firefox and chrome, and trying to attempt to simultaneously purchase two different items?

Upvotes: -2

Related Questions