what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

injectpaper.txt

injectpaper.txt
Posted May 22, 2006
Authored by Monte Toren | Site AlertPool.com

This paper discusses a simple technique for injecting code by manipulating hidden form fields.

tags | paper
SHA-256 | 0b4cb3450ed6fb3cf6fe7f9d2db8b581e808fc233c702aef0904dc6adfa52162

injectpaper.txt

Change Mirror Download


Code Injection via Hidden Form Field Manipulation

Date: 5/17/2006
Author: Monte Toren
mtoren@AlertPool.com
http://www.AlertPool.com (Security Alert Aggregator)

* Systems Affected:

Potentially any website that passes user supplied data via a hidden form field element.

* Overview:

This paper shows a simple technique for injecting code by manipulating hidden form fields.

Best practices for web development clearly dictates that user supplied input should always be sanitized for dangerous characters (such as '>') to avoid code injection in dynamically generated pages (see http://www.cert.org/advisories/CA-2000-02.html). However, what might not be as clear is that this sanitization must be done before any data is passed in a hidden form field. Since hidden form fields do not display in the browser, developers may feel safe passing unsanitized data in them (to be sanitized later). This practice is not safe, as will be shown.

Please note that I am not claiming to have discovered a new vulnerability here - I am simply highlighting a specific case of an existing vulnerability that might be less than obvious. I ran across this when auditing a real site, so I know sites have actually made this mistake.


* Description:

Imagine a web page that accepts user supplied input, but does not sanitize it before passing that data in a hidden form field. Perhaps the sanitization isn't done until later. An example might be a multi-page sign-up flow, where the username is passed from page to page, not to be displayed again until the final confirmation page. In this case, the developer may feel safe not sanitizing the data until being displayed on the confirmation page. Another possibility is that the page passes the data to an external script that does the sanitization via a hidden form field. Whatever the reason, any dynamic page that passes unsanitized data via a hidden form filed is potentially vulnerable.


* Examples:

The dynamically generated HTML for passing a user's name from one page to another with a hidden form filed looks something like this (where value is what the user entered - i.e. "Joe User".

<form>
<input type="hidden" name="username" value="Joe User" >
</form>

But what happens if the user enters " > Joe User (double quote followed by greater than then their name) for their username?

The above code now looks like this:

<form>
<input type="hidden" name="username" value="" >
Joe User">
</form>

We now have an empty value (since we ended the quotes), then we end the hidden tag by supplying the end '>'. We have Joe User "> as a line of HTML that will be output to the user's browser, despite the fact that it is hidden. To make this cleaner, we just need to insert a HTML tag that ends in ">, to get rid of the trailing ">. One such tag is the anchor tag.

So if we enter " > Joe User <a name="

The dynamic code now becomes:

<form>
<input type="hidden" name="username" value="" >
Joe User
<a name="">
</form>

Now the browser will just display "Joe User" without the trailing ">. The <a name=""> tag is just there to take up the ">, and doesn't change the output in the browser.

But Joe User isn't very interesting, what if we were to insert code instead? Using the above technique, the following value entered by the user and passed to a hidden form field will display their cookies:

"> <script>alert(document.cookie)</script> <a name ="

The dynamic code now becomes:

<form>
<input type="hidden" name="username" value="">
<script>alert(document.cookie)</script>
<a name ="">
</form>

At this point, we can inject any code between the "> and the <a name=", such as inserting an iframe to a site that steals login info, or code to post cookie data to a malicious site, etc.

But what if value isn't the final argument in the hidden field? What if they coded such as this?

<form>
<input type="hidden" value="Joe User" name="username">
</form>

We use almost the same technique. For example, we could enter
" > Joe User <a
and get the following code:

<form>
<input type="hidden" value="" >
Joe User" <a name="username">
</form>


* Solution:

Never pass unsanitized data in a hidden form field.
Login or Register to add favorites

File Archive:

September 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Sep 1st
    261 Files
  • 2
    Sep 2nd
    17 Files
  • 3
    Sep 3rd
    38 Files
  • 4
    Sep 4th
    52 Files
  • 5
    Sep 5th
    23 Files
  • 6
    Sep 6th
    27 Files
  • 7
    Sep 7th
    0 Files
  • 8
    Sep 8th
    1 Files
  • 9
    Sep 9th
    16 Files
  • 10
    Sep 10th
    38 Files
  • 11
    Sep 11th
    21 Files
  • 12
    Sep 12th
    40 Files
  • 13
    Sep 13th
    18 Files
  • 14
    Sep 14th
    0 Files
  • 15
    Sep 15th
    0 Files
  • 16
    Sep 16th
    21 Files
  • 17
    Sep 17th
    51 Files
  • 18
    Sep 18th
    23 Files
  • 19
    Sep 19th
    48 Files
  • 20
    Sep 20th
    36 Files
  • 21
    Sep 21st
    0 Files
  • 22
    Sep 22nd
    0 Files
  • 23
    Sep 23rd
    0 Files
  • 24
    Sep 24th
    0 Files
  • 25
    Sep 25th
    0 Files
  • 26
    Sep 26th
    0 Files
  • 27
    Sep 27th
    0 Files
  • 28
    Sep 28th
    0 Files
  • 29
    Sep 29th
    0 Files
  • 30
    Sep 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2024 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close