2

Could someone explain something to me please:

I am intercepting requests on my local proxy to a HTTPS server. The POST body has data such as "ID=4001" in plain text when I intercept it. Firstly, is this normal? Is the HTTPS in place on this server weak or lackluster somehow?

Can someone explain why what I deem sensitive information would be in plaintext here?

  • Did the devs drop the ball and present it in plaintext for the client to easily tamper with?
  • Would this be encrypted if the HTTPS was properly configured?
  • Because im intercepting requests locally from my own machine, HTTPS has no benefit until the request flies off across the network/transmission?

I am intercepting the requests locally from my client directly (not across the network so to speak). Trying to gain a little clarity on this for my own understanding, am I right in thinking at this stage HTTPS has little to no impact and the ID=4001 is a fault on the developers end?

ps. this ID is very sensitive and we wouldn't want someone knowing it or tampering with it successfully.

Update: I guess my question is, I can see this ID param/value in plaintext in burpsuite when intercepting client packets against a web application running on a self-signed HTTPs cert(I assume self-signed is irrelevant), is the fact I can see this ID a fault on the developers? or am I being silly and this would be encrypted in a real production environment? see image:

enter image description here

symon
  • 131
  • 3
  • 1
    Could you explain your proxy setup and which tools you are using to intercept the request? – Arminius Aug 07 '17 at 22:27
  • Agreed with @Arminius above. Network topology would help. – DrDamnit Aug 07 '17 at 22:36
  • @DrDamnit - A little more on the scenario, im intercepting locally from my machine using the burpsuite proxy using a web application that is running over HTTPS with a self signed certificate, I'm assuming my data is decrypted as im logged in as a valid user tampering with the requests and thats why I can see ID=4001 to tamper with it on my client side and it would infact be a serious security vulnerability (i can leverage this ID=4001 to compromise other user accounts successfully) – symon Aug 07 '17 at 22:46
  • @Arminius forgive me, my explanation is tough because im not overly educated on the matter. I guess i'm wondering at which point HTTPS helps, I assume it cannot help vs client-side tampering of the requests before they are sent to the server ? – symon Aug 07 '17 at 22:50
  • updated my question with a little more information, thanks – symon Aug 07 '17 at 22:57
  • Burp is simply decrypting the TLS layer for you. There is no indication of a misconfiguration. – Arminius Aug 07 '17 at 23:24
  • What is this token and why do you need to protect it? As mentioned elsewhere in this thread, it will be protected from tampering by a third party via SSL, but SSL will not prevent the local user from changing it. As far as the web server can tell, BurpSuite proxy server is the browser. – Dan Landberg Aug 08 '17 at 17:01

1 Answers1

3

Sounds like you have configured BurpSuite to allow monitoring of HTTPS traffic. According to the documentation:

By default, when you browse an HTTPS website via Burp, the Proxy generates an SSL certificate for each host, signed by its own Certificate Authority (CA) certificate. This CA certificate is generated the first time Burp is run, and stored locally. To use Burp Proxy most effectively with HTTPS websites, you will need to install Burp's CA certificate as a trusted root in your browser.

Note: If you install a trusted root certificate in your browser, then an attacker who has the private key for that certificate may be able to man-in-the-middle your SSL connections without obvious detection, even when you are not using an intercepting proxy. To protect against this, Burp generates a unique CA certificate for each installation, and the private key for this certificate is stored on your computer, in a user-specific location. If untrusted people can read local data on your computer, you may not wish to install Burp's CA certificate.

So essentially, BurpSuite is performing a man-in-the-middle attack, taking advantage of the fact that it runs on the local machine and installing its own certificate.

In the normal use case, BurpSuite is not installed on the client machine, and the hacker does not have any ability to install root certificates. Without this ability, the hacker would be unable to perform a man-in-the-middle attack without triggering a security warning in the browser, which would look a bit like this on Chrome:

enter image description here

To answer your questions:

Did the devs drop the ball and present it in plaintext for the client to easily tamper with?

No. The protocol is working as intended. It will protect you from Man-in-the-Middle attacks launched on the network. It will not protect you from a Man-in-the-Middle attack launched by a process running on your local machine with sufficient authority to install certificates. There is no technology in the universe that can protect a machine that has been locally compromised in this fashion.

Would this be encrypted if the HTTPS was properly configured?

Yes

Because im intercepting requests locally from my own machine, HTTPS has no benefit until the request flies off across the network/transmission?

Correct. HTTPS in general does not protect you from local access (after all, the Chrome dev tools also let you see the traffic); it protects you from a listener on the network attempting to eavsdrop.

Community
  • 1
John Wu
  • 9,101
  • 1
  • 28
  • 39