POST parameters are typically generated when forms are submitted by the user. However several other components will frequently POST data to the server such as Ajax JavaScript components and Shockwave flash files.

Standard POST (a.k.a Form) parameters are structured in the same was as in Query Strings with each parameter value pair separated with an ampersand delimiter. The following POST Request illustrates the submitting of two parameters “username” and “password” with the values “jill” and “hacker123” respectively:

POST /process_login2.asp HTTP/1.1
Accept: * / *
Accept-Encoding: gzip, deflate
Referer: http:/ /192.168.0.197/
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)
Host: www.sec-1.com
Content-Length: 32
Cookie: ASP.NET_SessionId=xxxxx

username=jill&password=hacker123

As with query strings the above example is typical but several variables exist. The following are the most common:

Multipart Post

Multipart POST is used when binary data such as the contents of a file or online HTML editor are required. Multipost forms can be implemented by including ENCTYPE=”multipart/form-data” within the form specification.

Example:

<FORM METHOD=”POST” ENCTYPE=”multipart/form-data” ACTION=”upload1.asp”>

Each parameter within a multipart post is separated using a randomly generated boundary value. The generated boundary is specified within the Content-Type request header as illustrated in the following example:

POST /admin/upload1.asp HTTP/1.1
Accept: * / *
Accept-Language: en-gb
Content-Type: multipart/form-data; boundary=7d84212124065c
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)
Proxy-Connection: Keep-Alive
Host: 192.168.0.197
Pragma: no-cache
Cookie: ASPSESSIONIDCSDRRRAC=xxxx
Content-Length:429
---------------------7d84212124065c
Content-Disposition: form-date; name=”FILE!”; filename=”C:\thefile.txt”
Content-Type: text/plain

I am the file contents

-----------------------7d84212124065c
Content-Disposition: form-data; name=”saveto’

disk

---------------------7d84212124065c

Within each boundary the first line defines the “Content-Disposition” MIME header along with the name and any additional parameter properties. For file uploads a Content-Type header specific to that boundary is included before the file data. The parameter values can be found within the body of the boundary following a mandatory blank line. For example the parameter “saveto” has a value of “disk” in the above example.

SOAP and XML-RPC provide a standardized platform-independent method of calling an application’s functions remotely. For example, Google provides an Application Programming Interface (API) accessible via XML-RPC to perform Google searches and access additional functionality. The primary benefit of such an interface is that it allows developers to share or export functionality across any platform and programming language. Both interfaces pass parameters by placing data within open and close tags;

SOAP Request

POST /Instock HTTP/1.1
Host: www.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn

<?xml version=”1.0”>
<soap:Envelope
xmlns:soap=http://www.w3.org/2001/12/soap-envelope
soap:encodingStyle=’ http://www.w3.org/2001/12/soap-encoding”>
<soap:Bodyxmlns:m=http://www.example.org/stock>
    <m:GetStockPrice>
<m:StockName>IBM</m:StockName>
    </m:GetStockPrice>
</soap:Body>
</soap:Envelope>

XML-RPC Request

POST /RPC2 HTTP/1.0
User-Agent: Frontier/5.1.2 (WinNT)
Host: betty.userland.com
Content-Type: text/xml
Content-length: 181

<?xml version=”1.0”?>
<methodCall>
<methodName>examples.getStateName</methodName>
<params>
<value><i4>41</i4></value>
</param>
</params>
</methodCall>

Referred to as SOAP envelopes or XML Elements

Cookies are typically implemented to store client specific data and to identify individual users of an application (see HTTP sessions). Cookies are set via the “Set-Cookie” server response header; the client browser reads the value and resubmits it with each subsequent request.

The following optional parameters define how are used by the client browser:

Example Server Response including the “Set-Cookie” Header

HTTP/1.1 200 OK
Date: Tue, 06 May 2008 10:48:42 GMT
Server: Mongrel 1.1.1
Status: 200 OK
Cache-Control: no-cache
Content-Type: text/html; charset=utf-8
Content-Length: 3737
Set-Cookie: sessionid=xxx; path=/
Connection: close

Example subsequent request including application set cookie:

GET / HTTP/1.1
Accept: * / *
Accept-Language: en-gb
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;)
Host: www.domain_name.com
Proxy-Connection: Keep-Alive
Cookie: sessionid=xxxxxx

HTTP is a plain text protocol, in order to support special characters and binary a number of encoding standards were introduced.

When attacking an application it is often necessary to encode your input to match the encoding scheme used by the application. In some cases it is possible to attack an application by encoding data in a certain way to bypass input validation filters or to manipulate the function that accepts the data.

URL Encoding

URLs and Form Post strings are permitted to include printable characters as defined by the US-ASCII standard (within the range 0x20-0x7e). Characters that have a special meaning or characters that are outside of the printable range must be encoded.

Special characters are defined as characters that have a special meaning within a URL or Form POST string, for example the ‘&’ character is used as a delimiter between parameters, therefore if you want to use this character as data it must be encoded. URL encoding operates by taking the decimal ASCII character code and prefixes it with a % symbol.

For example to have a value of fish&chips passed to the parameter food the following encoded string could be used;

http://www.sec-1.com/eat.asp?food=fish%26chips

The character ‘&’ has been encoded as %26 to ensure the application receives the value fish&chips and does not interpret ‘&’ as meaning ‘next parameter’.

URL characters such as &, ? and = should be used un-encoded when their special meaning is intended.

The following characters should be encoded when injected into a URL or POST string as data.

The following Perl script can be used to display the encoded version for each character entered at the keyboard. For complete listing see 🔗 http://www.asciitable.com/

# Perl script to encode URL characters
print “Enter string to encode:”;
$qstring = <STDIN>;chomp $qstring;
      $out = encode_http($qstring);
print $out
sub encode_http{
       @subvar=@_;
      my $sqlstr = $subvar[0];
      @ASCII = unpack(“C*”,$sqlstr);
       foreach $line (@ASCII){
            $encoded = sprint(‘%1x’’$line);
            $encoded_command .= “$encoded”;
      }
return $encoded_command;
}

HTML Encoding

HTML encoding is used to convert HTML special characters to a safe equivalent that can be displayed without interfering with HTML structure. There are two primary types of HTML encoding, the first uses an ampersand followed by an alias for the character terminated with a semicolon. A second method exists using the following format " where 34 is the character code in decimal.

All characters can be encoded using either scheme; however the following characters are usually encoded to prevent data written to a HTML page from interfering with the structure:

HTML encoding is frequently implemented to prevent Cross Site Scripting Attacks. This is covered in a section of the course dedicated to cross site scripting.

Unicode Encoding

Unicode encoding is implemented to support a wide range of character types from all languages that may fall outside of the 1 byte = 1 character that we typically use in the west (Basic Latin).

💡 From Wikipedia

You are likely to encounter this type of encoding when characters such as obscure mathematical symbols or characters from non-Latin based languages are entered as data to an application. Malicious hackers are interested in Unicode encoding because it can be used to bypass input validation filters. The following table lists common characters and their Unicode equivalents;

Common Special Characters

Alpha Numeric (Aa-Zz 0-9) Characters

Base64 Encoding

Base64 encoding allows any binary data to be represented as printable ASCII text using the following character set:

AB-YZab-yz-12-9+/=

Base64 encoding is commonly used for encoding email attachments to allow them to be delivered safely using SMTP protocol. It is also used to encode authentication credentials for transmission over HTTP.

Base64 encoding processes data in chunks of 3 bytes. If the length of the data to be encoded is not divisible by 3 the resulting base64 encoded string is padded using ‘=’ symbols.