I placed few orders and while tracking my order on Khadi India Tracking page I’ve observed that they are submitting POST request including personal data e.g. - mobile number and other data as query parameters instead of submitting them as POST data which will be encrypted in this case.
Sending these details as query parameters over POST is publicly visible to ISPs as well as any other actor listening traffic on this website.
GETrequests a representation of the specified resource. One reason for this is that GET may be used arbitrarily by robots or crawlers, which should not need to consider the side effects that a request should cause.
POST submits data to be processed (e.g., from an HTML form) to the identified resource. The data is included in the body of the request. This may result in the creation of a new resource or the updates of existing resources or both.
~ reference link
By default POST body is not encrypted however is it is sent over HTTPS then body will be encrypted using browser negotiated public certificate of server.
Here Khadi India should have submitted POST form data as body of request instead of passing them in url as query parameters which is plaintext and visible to ISP and others.
Query parameters are encrypted when you are on HTTPS. What is not secure is HTTP.
You see those params in your browser because well, that’s where it originates. And you get to see those again where the request terminates i.e. khadi’s server. Everything in between is over an encrypted channel.
Khadi & Village Industries Corporation website allows both HTTP and HTTPS. It’s only when you use a HTTP connection that your data travels unencrypted. It appears, from your screenshot, that you were using HTTPS. Your data is probably fine.
So, you have nothing to worry as long as:
The SSL certificate had no warnings/errors
The private key used to initiate the SSL connection is not compromised
Which brings us to the question: How good is KVIC’s cert? Turns out, it’s not so good either:
This “Chain issues” is a warning – but one that can most likely be ignored (Khadi’s server is just being unhelpful by not sending you the whole cert chain, and making your browser work harder to verify the cert and OSCP stapling). And then it goes on to use a few weak ciphers. You can find the full result here.
Finally, just because we are on HTTPS, does it mean we should be passing sensitive data via query parameters? Absolutely not. That’s because query parameters are often logged (by default) in webserver log files – leading to an actual PII leak.
So, please take some time to understand your threat model before you jump to conclusions.
I agree that requested url including, query parameters, headers, and cookies will be encrypted over HTTPS and not part of even DNS resolution - https://security.stackexchange.com/a/34795
Basic usages of POST is to submit form data in request body which will not be recorded via browser in history if not asked explicitly to remember form data on submit.
You still haven’t understood the issue. I explained why using URL query parameters is bad, you link a OWASP page that says the same thing, and then go on to ISP and malicious actors in the wild.
Pray tell, how does an ISP get hold of your URL parameters? Or, malicious actors?
Folks, I hate to be the polite-police but we always envisioned this forum to be a non capitalised space. I know we can disagree strongly and I do value the points made but let us channel our inner zen! Even I fail often, so please hold me up to this standard!
Also, please do continue this conversation. I am following it closely and trying to understand it as much as I can!
Capitalizing was a difficult choice, and one I made keeping in mind the broader audience of this forum. The technical part around cybersecurity, and privacy can get very confusing very fast. If there was one takewaway I wanted anyone skimming this thread to have it would be that this is not a security lapse as described.
As you know well, it’s hard fighting for privacy and security. Lapses on our part undermine our credibility.
