>get data is insecure by nature so the whole page is insecure and no 
>warnings, as soon as you post you invoke the security.

No, no, no.

POST data is *NO* *MORE* *SECURE* than GET data!  Period.

Okay, if you want to get picuyane -- A total idiot user can read the URL in
their location bar, and a total idiot user can maybe figure out a way to
munge it, and another total idiot, as webmaster, might build a web-site that
lets something bad happen when that happens...  And, technically, it's
possible that the first total idiot user couldn't figure out how to forge a

However, calling GET "less secure" than POST for that reason is, like, the
worst (best?) example of the well-debunked "security by obscurity" concept. 
It does not take a genius to forge POST just as quickly and easily as GET. 
"Hiding" your data by POST and thinking it's "more secure" is just plain

POST data is *not* transmitted by any more inherently secure method.  POST
data is not significantly hidden from the end user.  Unless you consider
"View Source" as more tricky than reading the Location box in the browser...
 Which I'm just not willing to buy as "more secure".

There is *NO* inherent technical superiority to a POST data for security

>You probably have a 
>url on your page that is coming from an insecure server (http://  instead 
>of https://)

This would be correct, except:

He has no HTML page on the HTTPS:// URL.  He has a PDF file.  There can be
no URL (images etc) on an HTML page that doesn't exist.

The *real* problem, as I said, is that he's forcing the browser to open a
blank window, and that blank window is given an HTTPS URL, and that blank
window is taking that HTTPS URL as a "promise" that some HTML will be
delivered securely.

Then, the server responds, *not* with some securely-delivered HTML, but with
some securely-delivered PDF data.

The *browser* fires up the PDF application (or plug-in) but *STILL* has this
browser window, hanging around, waiting for the promised securely-delivered
HTML that never arrived, never will arrive, and cannot arrive, since only
one (1) piece of content (the PDF) can be (*) delivered.

Thus, by definition, the HTML data for the browser window was not
transmitted securely, because no HTML was ever transmitted at all.

* Technically, the HTTP protocol could use keep-alive and deliver *TWO*
pieces of content:  some HTML, *and* the PDF file.  I have no idea if
keep-alive and spewing out HTML and PDF would make the browser happy, but
I'm willing to bet a dollar it would break a bunch more browsers, and an
extra HTML page isn't the desired behaviour in the first place.

Sorry for the repeat post, but I'm hoping I've stated it more succinctly
this time...

Like Music?  http://l-i-e.com/artists.htm

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to