From what I understand, you can't make a call to the doPost( ) method
directly, it must come from within a form which would be served. I think
this means that the request must come from a page served by the server that
you are posting to. Whereas a call to doGet( ) can be made from anywhere.
So a request to "post" data can't come from just anywhere, it must be coming
from a page that was served from your server.
Tom
----- Original Message -----
From: "Jörn Nettingsmeier" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, May 03, 2007 11:05 AM
Subject: Re: [1.2.4] Login form for the live area
[EMAIL PROTECTED] wrote:
Hi Bob,
I agree using POSTs rather than GETs is better practice for most
forms, but there is little effect on security.
in general, i agree. there is no subsitute for transport layer encryption.
but it still makes sense not to GET passwords.
to me, querystrings are part of the metadata and POST bodies are part of
the data. not reading the former is nearly impossible when you're a man in
the middle, reading (and logging!) the latter requires effort and bad
intent.
take proxies or load balancers. your GET data *will* be cached and logged
in odd places out there.
i don't agree that server-side logging is not an issue either: granted, in
an ideal world, all logs are only readable by one user and properly
chmodded. on my planet, that's simply not the case.
a third issue is browser caching: of course, most browsers cache form data
nowadays. but they do protect passwords if the user wants them to.
if it's in the "history" or favourites list, every attacker can harvest
them locally even if the user has set a master passwort for his/her form
cache.
plus the goal is to make it hard for people glancing over the user's
shoulder. what's the point of annoying the user with a row of asterisks in
the login form (which leads to typos) when we display the data in
cleartext in the addressbar afterwards?
--
Jörn Nettingsmeier
Kurt is up in heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
