Re: IIS log - GETs vs. POSTs

[RSnake <rsnake () shocking com>]

        That is not entirely accurate, unless IIS handles HTTP differently than
Apache anyway.  To clarify GET is used as default in cases of query strings,
unless POST is defined.  IE: I can POST to a cgi script with a query string:

        <FORM METHOD="POST" ACTION="/cgi-bin/useradd.cgi?data">

        Query strings have nothing to do with what method you use.
QUERY_STRING is defined only as a variable passed that is in the URI string
after a question mark, and has nothing to do with the type of method used.  As
is REQUEST_URI and others.

        Post should be used where you don't want users to be able to
inadvertantly change session variables, however it offers very little real
security benefit as the user has total control over their own environmental
variables and what they pass to remote machines if they want it.  The only
added benefit to POST from a security standpoint is when you are worried about
capturing refferers, etc...

On Sat, 30 Aug 2003, Jeremy Poteet wrote:

| Date: Sat, 30 Aug 2003 11:14:57 -0500
| From: Jeremy Poteet <lists () appdefense com>
| To: WebAppSec <webappsec () securityfocus com>
| Subject: Re: IIS log - GETs vs. POSTs
|
| 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!!!!!!!
| >
| >
| >
|

-R

The information in this email is confidential and may be legally
privileged.  It is intended solely for the addressee.  Access to
this email by anyone else is unauthorized.  If you are not the
intended recipient, any disclosure, copying, distribution or any
action taken or omitted to be taken in reliance on it is
expressly prohibited and may be unlawful.