=====[BEGIN-SCL-REPORT]=====
 
________________________________________________________________________

                   Scovetta Labs Security Advisory

 Title:         Simultaneous GET and POST Requests
 Status:        Public
 Release Date:  2006-09-10
________________________________________________________________________

 Package:       Various Web and Application Servers
 Vendor:        n/a
 Priority:      Low
 Vulnerability: n/a


Affected Versions:
==================

  n/a

Background: (official description)
===========

 WebCalendar is a PHP-based calendar application that can be configured 
 as a single-user calendar, a multi-user calendar for groups of users, 
 or as an event calendar viewable by visitors. MySQL, PostgreSQL, 
 Oracle, DB2, Interbase, MS SQL Server, or ODBC is required. 
 WebCalendar can be downloaded from [1].

 The HTTP protocol defines two methods for passing parameters from the 
 client to the server, "GET" and "POST". The GET method is seen by the
 user as parameters contained in the URL, as in: 

   http://www.google.com/search?q=walnut+shells. 

 The POST method has some advantages over the GET method, such as being
 able to handle file uploads and having content usually not cached by 
 proxy servers.

 Depending on the programming environment used on the server to 
 interpret parameters passed in, it is possible to use both GET-style 
 and POST-style variables simultaneously to exploit a vulnerability 
 in a web application.


Description:
============

 A standard HTTP GET request looks like:

  GET /index.php?a=b&c=d HTTP/1.1

 A standard POST request looks like:

  POST /index.php HTTP/1.1
  (various HTTP headers)

  a=b&c=d

 Languages have different mechanisms for accessing GET and POST 
 variables. Some examples include:

  ASP:
   Request("getOrPostVariable")
   Request.Form("postVariable")
   Request.QueryString("getVariable")

  Java:
   request.getParameter("getOrPostVariable")

  Perl:
   $cgi->query("getOrPostVariable")

  PHP:
   $_REQUEST["getOrPostVariable"]
   $_GET["getVariable"]
   $_POST["postVariable"]

 Consider the following HTML form:

 01  <form method="post" action="page.asp?a=b">
 02    <input type="hidden" name="a" value="c"/>
 03    <input type="submit"/>
 04  </form>

 We have two different parameters passed in with the same name, but 
 different values. This will be the basis of our attack.


Analysis:
=========

 Consider the following PHP file:

 01  <form method="post" action="page.php">
 02    Enter password:
 03    <input type="password" name="password" />
 04    <input type="submit" />
 05  </form>
 06
 07  <?php
 08    if ( $_REQUEST['password'] == 'abc' ) {
 09      $isAdmin = true;
 10    }
 11
 12    doSomethingWithPassword( $_POST['password'] );
 13  ?>

 Consider an attacker submitting the following data:

 01  POST /index.php?password=<correct password> HTTP/1.1
 02  Host: server.com
 03
 04  password=<some other password>

 In this case, the $isAdmin variable would be set to true, but 
 the function doSomethingWithPassword would have the incorrect 
 password (def) passed in.

 A survey of a few different application servers reveals the
 following:

 ===============================================================
 Web Server    Environment    Output from GET(a=b) and POST(a=c)
 ===============================================================
  Apache        PHP 5.x        $_REQUEST: b
                               $_POST: c
                               $_GET: b
 ---------------------------------------------------------------
  Apache        Perl/CGI       $query->param: c
 ---------------------------------------------------------------
  IIS           ASP            Request: b
                               Request.Form: c
                               Request.QueryString: b
 ---------------------------------------------------------------
  Tomcat 5.5	JSP            request.getParameter: b
 ===============================================================


Work-around:
============

 The easiest way to protect against this is to use a single method
 of extracting parameters from the HTTP request. Such a function
 could look something like:

  function get_var($name, $default="") {
    if ($name != null && isset($_REQUEST[$name]))
      return $_REQUEST[$name];
    else
      return $default;
  }

 It doesn't matter whether you use $_REQUEST, $_GET, or $_POST
 (regardless of language), since a vulnerability would only be
 introduced when program code accesses the variable inconsistently.


Timeline
========

 2006-02-15 - Vulnerability discovered.
 2006-09-15 - Advisory released.


Revision History
================
 
2006-08-25: Initial Draft
2006-09-10: Public Release [1]
 

Credits:
========

 To the best of his knowledge, Michael Scovetta of Scovetta Labs 
 discovered this vulnerability.


References:
==========

 [1] http://www.scovettalabs.com/advisory/SCL-2006.001.txt
 [2] RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1. Available
     online: http://www.w3.org/Protocols/rfc2616/rfc2616.txt 
 [3] http://www.squarefree.com/securitytips/web-developers.html


Disclaimer
==========

 The content of this report is purely informational and meant only 
 for the purpose of education and protection. Scovetta Labs and 
 Michael Scovetta shall in no event be liable for any damage 
 whatsoever, direct or implied, arising from use or spread of this 
 information. All identifiers (hostnames, IP addresses, company names, 
 individual names etc.) used in examples and demonstrations are used 
 only for explanatory purposes and have no connection with any real 
 host, company or individual. In no event should it be assumed that 
 use of these names means specific hosts, companies or individuals 
 are vulnerable to any attacks nor does it mean that they consent to 
 being used in any vulnerability tests. The use of information in 
 this report is entirely at user's risk.

 
Copyright
=========
 
 (c) 2006 Michael Scovetta. Forwarding and publishing of this document 
 is permitted providing the content between "[BEGIN-SCL-REPORT]" and
 "[END-SCL-REPORT]" marks remains unchanged.


=====[END-SCL-REPORT]=====