Het goed afhandelen van user input.

Downloads

Powerpoint
Lab 3

Lesvideo

Aantekeningen

Most dynamic web applications accept some kind of input from the client. This input may decide what to do next, it may be stored somewhere, included in a new web page, used in a legacy system, e-mailed to someone, and almost everything else, depending on the application.

Without this input, we cannot shop, transfer money, give votes, send web-based greeting cards, use search engines, or any other service that relies on data being passed from the browser to the web server.

Accepting input from the client is probably the greatest threat to the security of a web application. Accepting wrong input may make the programs make wrong decisions, and the results may vary from harmless, via annoying to devastating.

To make sure our application does not make the wrong decisions, we need to analyze every piece of input. The analysis is known as input validation.

Input

It is quite clear that URL parameters must be considered as input: url parameters

It is also quite obvious that whatever the user enters in text fields and text areas are input to the web application, whether it enters the application through GET or POST. html input

These are known as user-generated input.

Another kind of input that quite a few developers do not consider “real” input:

  • Select lists
  • Checkboxes
  • Radio buttons
  • Hidden fields

These can be called server-generated input, even if they come from the client, as the values are dictated by our web application. The user interface does not give the user an opportunity to change the values.

In most cases, server-generated input will come back to us with a well-defined value, that is the value or one of the possible values that our application included in the HTML. However, An attacker may have modified the values before sending the request:

  • If a GET request is used, parameter manipulation is just a matter of modifying the URL in the location bar of the browser.
  • If a POST request is used, the attacker may have to modify the form details of our HTML before sending the request.

Nothing stops an attacker from making country, gender and userid any value he wants them to be. So we need to view the server-generated hidden fields, check boxes, radio buttons and select list values as input, just as we see user-generated text fields as input.

Anything entering the application from the outside, typically through some request object or request stream, must be considered input. Input thus includes:

  • All URL parameters.
  • POST-ed data from textual input, check boxes, radio buttons, select lists, hidden fields, submit buttons and so on.
  • Cookies and other HTTP headers used by the application, even those used behind the scenes by the programming platform.

A web application may take input from sources other than the web client. Input may come from files and database tables generated by other parts of the total system.

Validation input

Input validation is the process of determining whether an input parameter is valid, according to rules set out by our application. The validity rules govern domain types rather than programming language data types.

Typical domain types include “E-mail address”, “account”, “country code”, “customer ID”, “date”, “file name”, “payment amount”, “phone number”, “real name”, “URL”, “user name”, “VISA”, and so on.

The main goal of input validation is not to avoid nasty metacharacter problems such as SQL Injection and Cross-site Scripting. The main goal of input validation is to make sure our application works with data that have the expected format.

Suggestions for good input validation:

  • Make sure you identify and validate all input.
  • Create validation functions
  • Check the range (For certain domain types, particularly the numeric ones, there may be range limitations as well as format limitations)
  • Check the length
  • Check for the presence of Null-bytes
  • Perform input validation before doing anything else
  • Perform authorization tests along with input validation
  • Try to automate input validation

Regular Expressions
Input validation is about deciding whether data are valid or not. We raise a question that results in true or false, and the answer is based on whether the input matches our expectations.

When it comes to matching text, nothing beats regular expressions (RE). RE is a pattern matching language supported by most programming platforms, either natively, or through third-party addons.

Validation of an e-mail address in PHP using RE: RE in PHP

Whitelisting VS Blacklisting
When filtering data, we look at characters or combinations of characters to remove something, rewrite something, or detect something.

The filtering can be done in one of two ways:

  • Identify bad data and filter it (blacklisting)
  • Identify good data and filter the rest (whitelisting)

Whitelisting is the preferred approach in a security context. It implements what firewall people would probably call deny by default.

Handling invalid input

  1. User-generated input is what comes from input fields of type text and password, or from textareas
    • User-generated input may be invalid due to typing errors
  2. Server-generated input is all the rest, such as hidden fields, URL parameters that are part of an anchor tag, values from selection boxes, cookies, HTTP headers, and so on
    • Server-generated input, which is not directly modifiable by the user, will never be incorrect during normal usage
    • If it is incorrect, it means that someone is tampering with values that are normally out of their reach, and not supposed to be changed

We should handle suspicious user- and server-generated input differently.

For faulty user-generated input, our application should politely tell the user that something is not right, and encourage him to change his input field. For bad server-generated input, we do not need to be that polite.

  • In that case, we know that someone has deliberately tried to alter data that are not easily modifiable. The application should abort the operation and log the incident
  • A clean page with “Bad input. Incident logged.” is enough
  • It may even stop him from having further attempts

Caution: Whatever you do, be very careful if you try to massage or modify the invalid input to make it valid.