WebApp Sec mailing list archives

Re: IIS log - GETs vs. POSTs


From: Jeremy Poteet <lists () appdefense com>
Date: Sat, 30 Aug 2003 11:14:57 -0500

A few minor points:

Sensitive information passed as part of a GET request is vulnerable to
"shoulder surfing".  I have seen several systems where information such as
clear text passwords were passed on the URL.  Besides the problems you
described, anyone who glanced at your screen while you were using the system
could see and record that information.

I agree that for an attacker with the proper tools or with a little more
time, POST does not offer any protection.  To keep an attacker from using
the ease of GET however, the application not only needs to use POST for the
form methods, but also needs to only access data through the POST method.
Many languages or web application frameworks allow the programmer to handle
either request type in the same manner or redirect handling of GET to the
POST handler.  This will allow an attacker to simply enter the form fields
on the URL and use a GET request even if the programmers intended a POST to
be utilized.

Finally is to make sure developers understand exactly when GET is used.  If
POST is not explicitly set, GET will always be used.  Therefore GET is used
in the following circumstances:

* When the GET method is set on a form
* When no method is set on a form
* When a URL is called with ?, such as http://www.test.com/test.jsp?id=1234

When I recommend that programmers stop using GET requests to pass sensitive
information, I often find they only deal with the first instance and ignore
uses of the next two.


Jeremy Poteet, CISSP
Chief Security Officer
appDefense
314-374-8073
http://www.appdefense.com


On 8/29/03 5:13 PM, "Matt Fisher" <mattfisher () comcast net> wrote:

Hi All -

I thought this was common knowledge, but after speaking to some developers
yesterday I thought it wouldn't hurt to explain some of the differences
between GETs and POSTs in more depth:

**** A GET passes information to the server through the HTTP Request URL,
like this:

GET /page.asp?parameter1=value1&parameter2=value2&parameter3=value3
HTTP/1.0
Referrer: http://server.com:80/index.asp
Connection: Close
Host: server.com
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Pragma: no-cache
Cookie: ASPSESSIONIDBLAHBLAH=DKDKEIEKDDGDDEOOJDG;

In Active Server Pages, the action page then accesses the values via
"request.querystring("parameter1") .  You can also just shorthand it to
"request("parameter1") . Sorry, I don't know the PHP nor Java equivalents.

There are a several  implications to this:

  a) The data passed to the server is directly modifiable by the user,
since the information is viewable in the address line of their browser.
This means they can easily erase parameters, modify parameter values, etc.
Note: This can be done on POSTs as well ... more on this later.

b) the data passed to the server is going to be logged by the web daemon.
This not only means credit-card numbers will be logged, but anything else
passed as well: PII, PHI, userids/passwords, session ID, account numbers,
etc.

c) the data passed to the server is going to be cached/recorded in areas,
like the History folder in the users' browser (very important if they're
using a kiosk or a hotel computer), possibly caching engines, and definitely
any statistical engines.  I once saw a website that had their web traffic
statistics on their website for the public to see.  In the "least
frequented" portion of the report they had their remote administrative site,
and since the login portion for that site used GETs instead of POSTs, the
username and password was right there in the link that the statistics engine
created, so that anyone who looked at their traffic reports could login to
their admin site just by clicking the link ... so very, very sad.

d) The maximum URL length allowed by Internet Explorer is  ~2,048
characters.  This includes the host name, directory, page, and all
parameters, so you can't use a GET for anything really large, like web-based
email, message boards, or other large text fields.

**** A POST does not send the data in the request URL, but rather sends it
as part of the HTTP Request BODY:

      POST /page.asp HTTP/1.0
      Referrer: http://server.com:80/index.asp?
      Content-Length: 48
      Content-Type: application/x-www-form-urlencoded
      Connection: Close
      Host: server.com
      User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
      Pragma: no-cache
      Cookie: ASPSESSIONIDASDFDF=ASDFASDFSDFSADFDFDFDFASDFOJDG

      user=root&password=rootkitme

The action page then gets the values via " request.form("user") " or again,
you can shorthand it to "request("user") " .

a) You can see here that the parameters (User and Password)  are NOT passed
in the URL.  This will prevent it from being logged accidentally logged,
cached, reported in traffic reports, etc.

b)   You can also transmit a lot more data via POST than you can via GET,
making it ideal for things like memo fields, email, etc.  I'm not aware of
any size limitations .... if anyone knows it for IE, I'd appreciate knowing.

c)   The data being sent to the server will also not be immediately apparent
in the browser to the user because it's not in the URL and a normal,
unmodified browser doesn't allow access to POST data (although the user
could modify the source HTML of the page to modify any hard-coded field
data).   This means your users can't break the app by erasing over
parameters etc.

VERY IMPORTANT:  Using a POST will prevent accidental recording of the data
and will help prevent a legitimate user from breaking the application but it
will NOT STOP A HACKER.  There are zillions of free proxies available that
let you modify the full HTTP packet at will, thus defeating the obscurity
offered by the POST.   It will just keep honest people (or insanely
ineffective webhackers) honest.

If I missed anything please chip in.

Thanks.
- Matt.

----- Original Message -----
From: "Nelson, Ernie" <Ernie.Nelson () wizards com>
To: <webappsec () securityfocus com>
Sent: Tuesday, August 05, 2003 6:35 PM
Subject: RE: IIS log


As others have stated and I was reminded earlier today...

IIS logs information that is placed in the query string via an http get.
If a post is used then the information will not be logged.  Generally it
is best in e-commerce applications to do most of your work via posts
since there is less in the users face to fiddle with.

Also if you have to keep some cc info in your database...try to do real
time auth and simply keep a hash of the users cc# or a first 4/last 4
span for auditing or reporting purposes.  That way if your box is ever
compromised you do not have a log or database full of cc#'s.  It also
helps when you do any web based functionality that requires the cc
identity....you aren't passing out their actual, usable number.

Yes, this is a serious issue.  Tell your web developers to get their
head
out of their a $ $  because they've coded a liability that could
destroy
the company!

Big time problem.

Copy a few lines of the log and past them into a response.


MAKE SURE YOU MODIFY THE CC NUMBERS!!!!!!!





Current thread: