Introduction
I think I can speak for a lot of developers out there when I say that it’s not always easy to look at your own application with the eye of a hacker. It’s easy to get the application to work like it’s supposed to when it receives input you expect. It’s relatively easy to write code and test for incorrect but otherwise benign input since this would happen during the normal process flow of the application. But writing code that is as hacker-proof as we can make it forces us to look outside of the process flow, and also forces us to take nothing for granted. Unfortunately it's pretty easy for a malicious user to get around some common security measures using JavaScript; but if you know what's possible, you can prevent these attacks.
Distrust Disabled Controls
One common mistake that I see is making a control disabled if you don't want the user changing the value. I've seen this done on a single control or on an entire section of a page, but the end result is the same. The user will see a control (perhaps a textbox or dropdown list), but can't do anything to change the value in that control. One example would be if you're building an e-commerce site and your customers should be able to view their order, but they should only be able to edit the quantity, not the price. You want to give an administrator the ability to edit the price, however, in case they need to make adjustments. To enable changing price and quantity, you put these values into textboxes, but you disable the price textbox for everyone other than administrators. Sounds simple, doesn't it? Unfortunately, the user can access JavaScript just as easily as you can. They can type the following into their address bar to enable the textbox:
javascript:void(document.getElementById('YourPriceTextBoxID').disabled = '')
With the textbox now enabled, they can set the value to whatever they want. If you don't do any server-side role checking, your customer just purchased whatever they wanted at their price, not yours. This doesn't mean that you should avoid disabling controls in JavaScript entirely, but it does mean that you should double-check all of your values on the server.
It's important to note that buttons aren't safe from this either. You could add JavaScript to the page to enable your "Save" button only when all of the controls are filled out, but your user could enable the button just as easily as you can. Here again, you need to double-check all of your assumptions on the server.
Prevent Abuse of the ASP.NET Validators
The ASP.NET Framework contains validation controls, such as the RequiredFieldValidator and RegularExpressionValidator, which contain browser and server validation. Because the client-side validation works so well in most cases, it is often easy to forget that the server-side validation MUST be done as well. Why? The JavaScript validation doesn't work if the browser has JavaScript turned off. (That seems like it should be obvious, but it is a fact often overlooked by developers.) What you may not know is that even if you force your users to have JavaScript turned on, they can still get around the validators relatively easily. To see why, let's look at the JavaScript that ASP.NET uses in your button's onclick event to post back to the server:
Validation turned off: __doPostBack(/* arguments */);
Validation turned on: WebForm_DoPostBackWithOptions(/* arguments */);
In other words, the function __doPostBack is called when validation is not needed; WebForm_DoPostBackWithOptions is called when it is. If a hacker wants to get around your JavaScript validation code, all he/she needs to do is manually call __doPostBack('ButtonUniqueID', ''). Fortunately the fix for this is easy. ASP.NET checks all validators on the server for you, and you can check to see if all tests pass by checking Page.IsValid on the server. If this is false, then one or more of your validators failed, and you should take appropriate action.
Use AJAX Wisely
You should also keep in mind that all of the tools you use to debug your web site, such as Firebug for Firefox and Fiddler for Internet Explorer, are available to hackers as well. These tools can be used to find your validation and AJAX methods surprisingly easily. There is no way that I know of to create a server method, available by a JavaScript function, that is only accessible when you want it to be, and simply hoping that a malicious user won't find your functions isn't a good idea. The best you can do here is:
- Limit the data that is accessible from Web Services and AJAX methods
- If you use authentication of some sort, check the permissions of the user on every call
Conclusion
Unfortunately, the conclusion is don't trust JavaScript to do anything important. If you let them, malicious users can use JavaScript fairly easily in order to call any method you create, view any data you return, or get around any browser-specific security measures. Your best bet to make your web sites secure is to assume that any JavaScript your page calls could be compromised at any time, and to check every important value once it is returned to the server.
History
- 8th September, 2009: Initial post
