Another improvement on the HTTPRequest documentation

[arthurpaulino]

Raising flag about lack of encryption when sending data as a query string in the URL.

Sorry, I had just opened a PR on this same part of the documentation, but I think this is a rather important piece of information to be delivered to our gamedev folks.

[arthurpaulino]

And I have no idea why the static checks are breaking. Does anyone know why?

[YuriSizov]

And I have no idea why the static checks are breaking. Does anyone know why?

Seems to be this: pypa/setuptools-scm#608

We'll look into it.

[Calinou]

Is this actually the case? I was always convinced that when using HTTPS, the only bit of information that could leak to third parties was the domain name browsed due to DNS queries being made over a unencrypted protocol.

Of course, query strings may be logged in HTTP server logs regardless, which makes them a bad idea for sending credentials and the like.

[arthurpaulino]

Is this actually the case? I was always convinced that when using HTTPS, the only bit of information that could leak to third parties was the domain name browsed due to DNS queries being made over a unencrypted protocol.

Of course, query strings may be logged in HTTP server logs regardless, which makes them a bad idea for sending credentials and the like.

Good points! On a quick search I found these topics:

• https://security.stackexchange.com/questions/233795/are-url-parameters-of-get-and-post-requests-over-https-secure
• https://stackoverflow.com/questions/14765073/how-secure-is-file-get-contents-with-get-parameters-over-https

What you said seems to be accurate. But should we warn the user about the logs or let it be? I feel more inclined to raising awareness when possible. I can adjust the PR if you think it's a good idea. Otherwise we can just drop it.

[Faless]

due to DNS queries being made over a unencrypted protocol.

And also when using SNI.

But as noted, HTTP request headers are encrypted in SSL.
So while using it for sensitive information might not be a great idea stating they are not encrypted is simply wrong.
Additionally, if you have control over both the client (i.e. it's not a web browser visiting a page), and the server (e.g. your VPS where you did setup logs correctly), you can safely use query parameters for that scope.

I'm okay with mentioning potential pitfalls, but we should not bring false informations.

[arthurpaulino]

Alright, let me fix it and then we can decide after that.

[arthurpaulino]

Done! Thanks for the information. I learned something 🎉

I hope the way I wrote it is correct and objective enough.

[Faless]

Even if ssl_validate_domain is false, the information is encrypted if the URL is HTTPS (though susceptible to MITM attacks).
Even if ssl_validate_domain is true, the information is not encrypted if the url is HTTP.

So, this is not exactly correct, and might generate even more confusion :/

[arthurpaulino]

More learning! Let me clean up that part some more.

[arthurpaulino]

Okay, is this version better?

[mhilbrunner]

I'd just replace it with a comment stating that requests transmitting sensitive information should use encryption and to avoid using GET parameters for such information if possible.

[arthurpaulino]

Thanks everyone for the input!
PR updated. LMK if anything needs to be changed.

[mhilbrunner]

Thanks for sparking this discussion :) For me, the new text currently says:

However, when sending sensitive data (such as login credentials), it's recommended to make a proper POST request using encryption and the [code]request_data[/code] parameter.

Recommending POST requests this heavily just because of sensitive data seems ill advised.

In common use, the main difference being GET and POST is retrieving data vs. submitting/modifying data (i.e, posting). (See REST.)
The difference isn't sensitive vs. non-sensitive data, which this now somewhat implies.
Both may need login credentials. In these cases, putting credentials in HTTP headers is common.

So we should

1. suggest using encryption (SSL/TLS), especially when transmitting sensitive information (but its a good practice anyway)
2. recommend against transmitting sensitive information in HTTP GET URL parameters (and maybe suggest using a HTTP POST request or HTTP headers)

Something like this?

It's recommended to use transport encryption (SSL/TLS) and to avoid sending sensitive information (such as login credentials) in HTTP GET URL parameters. Consider using HTTP POST requests or HTTP headers for such information instead.

[arthurpaulino]

@mhilbrunner I've changed it to your wording but I've done it in a new note as the previous paragraph was already quite dense. Please let me know what you think 👍

[mhilbrunner]

Thanks for helping to improve the docs :)