Re^3: CGI MySQL insert/update special characters

[jcb]

Your new approach using POST is far safer than what you were doing and has far better compliance with RFC2616's rules for "safe" and "idempotent" methods. In brief, GET requests are "defined" to not have side effects, while other methods, including POST, have no such restrictions. You must use POST if the request is intended to do something.

Further, request URLs often appear in logs, but POST data is generally understood to be potentially sensitive. You should never submit a password with a GET request; logins need to always use POST and, if you are sending them over the open Internet, TLS. Plaintext HTTP is safe on an isolated network, but sending anything remotely sensitive over the open Internet needs HTTPS (or the TLS upgrade sequence for HTTP/TLS over port 80).

[haukex]

Plaintext HTTP is safe on an isolated network

You make some good points, but I disagree with this bit, on principle. At the very least, one should use a scheme such as Digest access authentication. (And what network is really isolated anymore nowadays?)

[jcb]

The problem with digest authentication is that it requires the server to store a plaintext password or password-equivalent and that leads to the server being a very attractive target for stealing the password list. (Windows networking has gone through several variants of this that all fall to "pass the hash" attacks. Then Microsoft started using Kerberos in Active Directory and screwed that up too, leading to the "golden ticket" and "silver ticket" attacks.)

I consider the house embedded device LAN an isolated network, since it does not cross with Internet-connected segments except at dual-NIC hosts (all of which are considered "secure" and none of which are configured to bridge LANs or route traffic) that are on both networks, nor are there any wireless APs on it, nor does it leave the building. Embedded devices often have really bad security anyway; I have worked with one embedded network stack that (unless I missed something in the code) used a 32-bit entropy variable for everything — including SSL session keys.

[haukex]

The problem with digest authentication is that it requires the server to store a plaintext password or password-equivalent

Yes, good point as well. (I did say "at the very least" - but I should have made it clear that more advanced schemes would be much better.)

I consider the house embedded device LAN an isolated network ... Embedded devices often have really bad security anyway

Taking this point together with the above, I'm confused about the message, whether plaintext passwords are okay or not. When an embedded or proprietary device has limitations, then one might not be able to do anything about its security, sure. But anything else, personally I like to play it safe. And when it comes to recommendations to others, personally I'd very much avoid saying that plaintext passwords are okay (when they can be avoided, as in the context of this thread) - that's all I was trying to say.

[bliako]

just to clarify: if you use GET even on HTTPS, the GET parameters, just like the url, will not be encrypted (unless already encrypted). But POST over HTTPS will send its parameters (even plain-text ones) using the negotiated secure channel, right?

[hippo]

No, that's incorrect. With an https GET the entire URL is sent over the encrypted channel. That's why we need SNI to distinguish between vhosts on the server side.

[Your Mother]

Adding: URLs are often seen as nothing special though and end up in logs galore or visible to various intermediary software to forward/proxy/cache. I think they should/must always be kept free of any special information.

[bliako]

understand thanks

[jcb]

If the client drives the use of a secure channel, either using TLS on port 443 or TLS upgrade on port 80, the entire request (including the URL) will be sent encrypted. If the server demands an upgrade to HTTP/TLS (RFCs define a way to do this on port 80) before responding, then the entire request (including the body of a POST(!)) will have been initially sent in plaintext and then be repeated encrypted after the TLS negotiation is performed.

The bigger problem with putting login parameters in URLs is that URLs are generally assumed to not be sensitive and tend to get stored all over the place, including server logs and browser history.