One really important point in Frank's response is that even when using SSL
there are still copies of the GET query parameter(s) in the browser history
list and server logs. These can be important sources of inforamtion loss.
-----Original Message-----
From: Frank Knobbe [mailto:frank@knobbe.us]
Sent: Thursday, September 23, 2004 8:24 AM
To: webappsec@securityfocus.com
Subject: RE: XSS, SQL injection etc - permutations of input strings
On Tue, 2004-09-21 at 09:58, Scovetta, Michael V wrote:
1. The *only* difference between GET and POST is the "average" user
thinks that POST means the client can't see it. This is totally
untrue.
If your site is secure, then it shouldn't matter whether
it's GET or
POST. If it's not, then relying on POST to make it seem secure is
Security Through Obscurity (a Bad Thing(TM)).
That's not the only difference. Another one is that of
logging. Data posted in GET requests is typically logged to
server log files and proxy log files while posted data using
POST often is not.
GET data has a tendency to "linger" in caches... your
browsers URL cache but also proxy server caches. POST data is
not (except within the same browser session in a POST cache,
but it typically doesn't survive browser restarts).
GET data is observed by shoulder surfing, while POST data is
not. Lame point but a point nevertheless.
Both posting mechanisms pass data in clear text, so they
equal in security from the perspective of observing traffic
flow. However, there are benefits using POST data which would
rate the security of usage of POST a little bit higher than
that of GET.
Security is not a black-and-white thing. It's all shades of
gray. I believe POST is just a little more on the light-gray
scale than GET. The advantages of POST (logging/caching)
should make it more "attractive" to use than GET.
Cheers,
Frank
