Skip to content
Home » Security issue-1: Invalidated Input Errors

Security issue-1: Invalidated Input Errors

What is it:

  • Invalidated input is the most common and well-known security flaws in web applications and is the root cause of many of the exploits.
  • You should consider every one of your Web application users as malevolent since it is certain that some of them will be, so data provided by them cannot be trusted at all.

Ways it can happen:

  • Attackers may add, delete or modify URL parameters in a query string.
  • Hidden form fields can be changed and then resubmitted the form.
  • Database information, especially fields written by other applications, might be either purposely or accidentally tainted.

Potential Vulnerabilities:

  1. Affect user interface:
    • Here issue would be an unprofessional rendering of your site that is tainted input can render your user interface unusable.
    • Attackers can force errors in application output to gain some idea of the caution with which your developers tighten-up their code.
    • And finally, if it is easy to hack a user interface then its pretty easy to crack other components of an application.
  2. By-passed client-side validation:

    • In reality, client-side validation is not a security validation.
    • It is very easy for an attacker to disable script execution at client side and enter malicious inputs and then submit the form.
    • If there is no validation on the server side then server crashes and the execution of rogue commands are just two of the possible outcomes.
  3. Cross-site scripting:

    • Text fields that are not validated might contain HTML.
    • Tags–like <script> and <object>–that execute code unexpectedly.
  4. Generation of informational error messages:

    • By forcing certain types of error messages, an attacker can obtain an application and operating system version, patch level information about your system. This information is commonly used in the first phase of an attack.
  5. Buffer overflow:

    • Attackers can use buffer overflows to crash a system or to execute malicious code.
  6. Unauthorized access:

    • Access to files might be obtained by manipulating paths.
    • For example, the following is a path to a file to which the user has authorized access:
      <a href=”dashboard.php?dashboard_id=876”>Dashboard</a>
      By manipulating the dashboard_id, an attacker could potentially retrieve sensitive information to which he does not have authorized access.
  7. SQL Injection:

    • This type of attack exposes company databases to unauthorized addition, modification or deletion of data.
    • It is caused by an attacker including SQL code in the input to a form field or by directly manipulating query strings.


  • You may write the following code to allow a user to view a calendar that displays a specified month by calling the UNIX cal command.
    $month = $_GET['month'];
    $year = $_GET['year'];
    exec("cal $month $year", $result);
    foreach ($result as $r) {
        print "$r<BR>";
  • In the above code, the application will work fine as long as the month is a number between 1 and 12, the year is a proper four-digit year.
  • But since $_GET[‘month’] and $_GET[‘year’] variables are not validated at all, it created a gaping security hole.
  • A malicious user may append “; ls -la” to the year value and see the listing of your Website’s HTML directory or may append “; rm -rf *” to the year value and delete your entire Website!
  • So the proper way to correct this is to ensure that the input you receive from the user is what you expect it to be.
  • Do not use JavaScript validation for this; such validation methods are easily worked around by an exploiter who creates their own form or disables javascript.
  • Regular expressions are a great tool for input validation. They can be difficult to grasp but are extremely useful in this type of situation.
  • You need to add PHP code to ensure that the month and year inputs are digits and only digits, as shown below.
    $month = $_GET['month'];
    $year = $_GET['year'];
    if ( ! preg_match("/^[0-9]{1,2}$/", $month)) {
        die("Bad month, please re-enter.");
    if ( ! preg_match("/^[0-9]{4}$/", $year)) {
        die("Bad year, please re-enter.");
    exec("cal $month $year", $result);
    foreach ($result as $r) {
        print "$r<BR>";

Some principles to be considered for validating user inputs:

  1. Perform all validation on the server. Inspect what you expect and reject anything unexpected.
  2. If some characters do not need to be included, you should probably either strip them out or reject the input completely.
  3. You should be as restrictive as possible when you validate any input.
  4. Use positive filtering instead of negative filtering. that is, check for what should be present instead of for what should not be.
    Validating what should not be in the input can leave too many open holes in the validation process.
  5. There are many variations to check. Possible filtering checks include:
    • Is it the right data type (string, integer, etc.)?
    • Is the parameter required? Is NULL allowed? Is the character set allowed?
    • If selected from a list, does the parameter contain a valid value?
    • If numeric, is the input within range constraints?
    • Does the input meet the minimum and maximum length constraints?
    • Does the input cause data duplication, and if so is it acceptable?
    • Does the input meet format requirements (e.g., when compared to a regular expression)?
  6. Make sure that Quality Assurance processes include testing not only valid input but also invalid input.

Leave a Reply

Your email address will not be published. Required fields are marked *