WebApp Sec mailing list archives
RE: IIS log - GETs vs. POSTs
From: "Brown, James F." <James.F.Brown () FMR com>
Date: Wed, 17 Sep 2003 12:02:36 -0400
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¶meter2=value2¶meter3=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:
- Fw: IIS log - GETs vs. POSTs Matt Fisher (Aug 30)
- Re: IIS log - GETs vs. POSTs Jeremy Poteet (Aug 30)
- Re: IIS log - GETs vs. POSTs RSnake (Aug 30)
- Re: IIS log - GETs vs. POSTs Lucas Holt (Aug 30)
- Re: IIS log - GETs vs. POSTs RSnake (Aug 31)
- Re: IIS log - GETs vs. POSTs RSnake (Aug 30)
- Re: IIS log - GETs vs. POSTs Jeremy Poteet (Aug 30)
- <Possible follow-ups>
- RE: IIS log - GETs vs. POSTs Calderon, Juan C (EM, DDEMESIS) (Sep 01)
- RE: IIS log - GETs vs. POSTs RSnake (Sep 01)
- RE: IIS log - GETs vs. POSTs Guille -bisho- (Sep 01)
- RE: IIS log - GETs vs. POSTs RSnake (Sep 01)
- RE: IIS log - GETs vs. POSTs RSnake (Sep 01)