Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

Re: CGI MySQL insert/update special characters

by Your Mother (Archbishop)
on Mar 28, 2020 at 15:30 UTC ( #11114758=note: print w/replies, xml ) Need Help??

in reply to CGI MySQL insert/update special characters

Probably all you need is to start with use CGI -utf8; to decode binary data in parameters to characters; CGI has info about what it does. But that does assume your DB is correct, which is rarely the case with default MySQL, and I believe there is a security issue with file uploads if youíre not careful with that default but I canít cite it. *Every* part of the interchange has to be right and guessing or just trying to patch stuff in one point is a losing game. Try to pick up as much as you can out of tchristís canonical answer to these issues:

Replies are listed 'Best First'.
Re^2: CGI MySQL insert/update special characters
by Takamoto (Scribe) on Mar 28, 2020 at 17:41 UTC

    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/$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);

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

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

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

        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?

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://11114758]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (8)
As of 2021-04-20 20:37 GMT
Find Nodes?
    Voting Booth?

    No recent polls found