RE: IIS log - GETs vs. POSTs

["Brown, James F." <James.F.Brown () FMR com>]

Don't forget the HTTP Referrer (sp?) field. Information placed in the URL by
a GET will be sent off to third-party sites.

====
- Jim Brown
  Fidelity Investments
  http://www.fidelity.com

-----Original Message-----
From: Matt Fisher [mailto:mattfisher () comcast net] 
Sent: Friday, August 29, 2003 6:13 PM
To: webappsec () securityfocus com
Subject: Fw: IIS log - GETs vs. POSTs


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!!!!!!!