Securing dropdown boxes

Question

I have been creating selection boxes for years, yet I never knew you could modified it with firebug and submit them with nonpermitted values, of course this wouldn't happened if the code was secured.

Here is an example:

<select name="type">
<option value="1">Business</option>

I can open up firebug (firefox addon), and change the value to somethings else, for simpleness:

 <option value="200000000">Business</option>

And when submited the database enters the value 200000000. This is just a simple example, which can give the basic idea of what it can be done by someone trying to exploit the website.

Codeigniter provides form validation, but does not check for the value of the selection box, which is what is being inputed to the database.

How could I prevent a non-allowed parameter from being inputed in the selection box?

Answer 1

It is very important for you to understand that ANY input from the users has to be sanitized in one way or another, or you are potentialy opening up for security holes. Any input could mean dropdown boxes or other data you would think is static. Examples of this is simply anything returned from the user like for example:

• Radio buttons
• Dropdown boxes
• Data coming from plugins like flash, silverlight and so on.
• Simply anything that is sent to the client!

To better illustrate this I encourage you to download a simple proxy which will enable you to show all the data being sent to your server when submit a form. An example POST request is shown here:

POST /api/rest HTTP/1.1
Host: api.example.com
User-agent: Googlebot/2.1 (+http://www.google.com/bot.html)
Referer: example.com/admin.php
Content-Type: application/x-www-form-urlencoded
Content-Length: length
Cookie: username=karrax&password=855425718dfe4a50f6f0bbb9335d3c3b&userid=591

dropdownBox=string&staticTextField=string&hiddenElement=string

Anything that you have to rely on in your business logic coming from the client side has to be cleaned.

Remember that this goes for anything coming from the client side. IT CANNOT BE TRUSTED! ... Even if it is simply a string being returned to the client (e.g. a username) it should be cleaned so that it is not vulnerable for cross site scripting and other attack vectors.

Edit: As @Avid pointed out in the comments it is also imperative to know that data passed through cookies is also sent from the client side, making them vulnerable to tampering. This also applies for any other field in the headers (or anything coming from the client) like the user-agent or referrer field to name a few.

In the example above the HTTP request may foil some security systems if they rely on the referrer field to for example authorize the user. The example also makes it appear that it is the Google bot which may in some circumstances provide different content on the page you are requesting (source).

Answer 2

You need to implement some business logic on the server, which includes server-side input validation. Never let browser input flow directly through into your database.

If you want to do some client-side validation also (not instead of!) server-side validation to improve performance or usability, then by all means do so. But if you're not validating at the server you're not actually validating the data (as your own experiment showed).

You're doing PHP so this page might have some good pointers. [Details of how to do this of course depend on your server platform.]

Answer 3

Let's get back to first principles: What are you defending against?

If you are defending against invalid fields being submitted to your web app, as all of the other posts have pointed out, an attacker doesn't need to use HTML or JS to submit invalid data. They can make their own GET or POST and send it to your server (FF plugin tamper-data allows you to do this from the browser).

1. Use browser-side validation for usability. This validation is easy to circumvent, so the only reason to do this is to increase the usability of your site by helping the user submit valid values.

2. Server-side validation, sanitization, etc. All submitted data must be assumed to be dirty and a possible attack vector. Sanitize the submitted data before using it for anything (and use your DB in a safe manner -- prevent sql injection).