Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
4  
You current plan is client-side input validation. Do not ever in any circumstances do client-side validation. You have to check the input in your php script, at the server side, and reject wrong and malformed data. –  ordag Mar 13 '12 at 20:38
1  
Would comparing the submited value with the actual values in the Type database table and returning a error if it does not match any of the values in the table solve this problem? –  Kevin Mist Mar 13 '12 at 20:47
1  
I'd recommend to first check the type of the input data, in your case it seems you want numbers as input. So check if it's a real number, and then if that number is in the range of values you accept, so if 1 is Option A, ..., and 5 is Option E, check if the input number is between 1 one 5 (inclusive of course). This shall just be an example to show the direction. A good resource for php is the manual, and it also has a chapter for filters. –  ordag Mar 13 '12 at 20:56
2  
@ordag well, client-side validation is fine. It's even good to do since it stops a needless postback, but it should also be backed up by server-side validation. –  Steve Mar 13 '12 at 20:57
1  
@SteveS What I meant with "client-side validation is always wrong" is that it is always wrong in terms of security. the other part you meant is, of course also important, UX –  ordag Mar 13 '12 at 20:59

3 Answers 3

up vote 9 down vote accepted

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).

share|improve this answer
1  
On Windows machines, I use fiddler2 as a great little debugging proxy. –  logicalscope Mar 13 '12 at 21:07
    
Not sure of your first sentence (missing something?) but the rest is spot on. –  Mark Beadles Mar 14 '12 at 0:28
    
@MarkBeadles, thank you. Fixed it now. –  Chris Andrè Dale Mar 14 '12 at 8:40
2  
+1. I'd also point out other things that can be tampered with (surprising to some), such as: cookies, referrer, user-agent, and any other header too. –  AviD Mar 14 '12 at 16:00

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.]

share|improve this answer

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).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.