in reply to Re: CGI MySQL insert/update special characters
in thread CGI MySQL insert/update special characters

Thank you, Your Mother. I certainly gave too little details. I solved the issue. MySQL was set correctly. I was passing the values with a GET and something like this: /cgi-bin/mobile/setNewAccount.pl?key=$LicenseKey&user=$CloudUserName&pw=$CloudUserPW This would have needed special care for special characters. So I simply switched to POST and sending my data with:

my $request = POST($url, Content_Type=>'application/json',
    Content => encode_json($data) );
my $response = $ua->request($request);

[download]

This works fine. Will now read on vulnerabilities of this approach.

Replies are listed 'Best First'.
Re^3: CGI MySQL insert/update special characters
by jcb (Parson) on Mar 28, 2020 at 22:50 UTC

    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).

[reply]
      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?)

[reply]

        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.

[reply]

      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?

[reply]

        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.

[reply]

        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.

[reply]

In Section Seekers of Perl Wisdom