4 ms·
Isn't passing the session token in the query string insecure? The payload of the requests will be encrypted (assuming HTTPS), but the urls are not. So I think
by rdeboo 12y ago
Isn't passing the session token in the query string insecure?
The payload of the requests will be encrypted (assuming HTTPS), but the urls are not. So I think you're opening the door to session hijacking in this way.
edit: I was wrong about this. The URL will be confidential in transit. Thanks for setting me straight.
I still think it is not a great design, but for different reasons: the url will be visible in your browser history and on the server side in the logs.
- leeoniya 12y agoeverything over HTTPS is encrypted except the ip addresses and port #. hostname is also encrypted (cause it's a header), though your insecure DNS pre-queries will give that away to anyone listening on the wire.
- icebraining 12y agoHostname is not encrypted if you're using SNI[1], and if you're not, you can only connect to IPs that serve a single HTTPS site, so it's not meaningfully hidden anyway. [1] http://en.wikipedia.org/wiki/Server_Name_Indication http://en.wikipedia.org/wiki/Server_Name_Indication
- leeoniya 12y agoah yes, forgot about that :)
- batbomb 12y agoI don't think you understand HTTPS. The URLs are, in fact, encrypted. That's why it's called TLS.
- tankerdude 12y agoPutting keys in query strings does leak information on the server though. Query strings are usually logged with the request in log files so you have to be sure to filter out the specific query string for the session token. That's the security concern that I see, especially if the logs get sent out somewhere/someone else for analysis.
- leeoniya 12y agowell, you need authentication data in every request, which includes GET/DELETE/HEAD/OPTIONS requests with no payload. so either you use query strings (which suffers from the logging issue) or you use headers/cookies which some people argue isn't "REST"ful.