Hi Tom, A skilled techie with a telnet client (such as putty) can fake a POST request. Or create a local page with <FORM METHOD="POST" ACTION="your login"> to create a POST request.
Servers rarely check that the form came from the server. A common method is to add a graphic and make the user type in the characters on the graphic. Another method adds a random number to the original form and checks that number against the submission.Both methods add much work to prevent people from spoofing the form. Lenya does not use either by default. solprovider On 5/4/07, Tom Mitchell <[EMAIL PROTECTED]> wrote:
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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
