Central Govt owned Khadi India online e-commerce website leaking Personal data for Track Order page

Recently Khadi India launched their online shopping website - https://www.kviconline.gov.in/khadimask/index.jsp where khadi products can be ordered online.

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.

Will such kind of blunder acceptable from Govt owned website having pending Personal Data Protection Bill, 2019 ?


Can you please explain this bit in a non-technical language while explaining the data encryption part?

GET requests 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.

1 Like

This is not true.

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:

Screen Shot 2020-10-29 at 5.50.33 PM

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

However my point is that it leaks these details to multiple places via browser - Information exposure through query strings in url .
ISP and other malicious actors in wild can access those places where Personal Data is recorded.

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.

This was your original point. This is incorrect.

However my point is that it leaks these details to multiple places via browser - Information exposure through query strings in url .
ISP and other malicious actors in wild can access those places where Personal Data is recorded.

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?

You’re spreading FUD.

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.

I’ll edit my previous post.