-1

Hey so am new to pentesting and I learnt that using https makes the traffic encrypted so hackers cannot decipher credentials passed in a body for example in a login page or read the traffic properly. So I was practicing with both GET and POST requests for a login page app over https and in both the credentials are present in the request body when I intercept them using burpsuite. In GET the params are available in the URL and in POST they are present in the body. Can someone explain then how can the privacy of credentials be maintained if they are present in plaintext in the request body. Won't everyone be able to read them??

Testing:

Submitted credentials through a login page application over Https. Passed them through both GET and POST methods. Result: Able to see creds in both types of calls in the request body.

Improve this question
1

1 Answer 1

Reset to default
0

All traffic within HTTPS requests and responses - credentials very much included - is protected by TLS. TLS provides encryption, along with server (and optionally client) authentication, integrity protection, and replay protection.

However, Burp Suite performs TLS termination so that it can see the plain-text requests and responses. In other words, instead of your browser establishing a secure TLS tunnel all the way to the web server, it establishes that tunnel only to Burp. Burp then (optionally) creates a new tunnel from itself to the actual server, generally encrypted with a totally different key, and passes the (possibly modified!) request down it. Responses follow the reverse process.

Remember that step in setting up Burp where you had to install its private certificate authority (CA) root certificate on the device/browser being tested? That, in effect, authorizes Burp to pretend to be arbitrary TLS servers (spoofing the server authentication part of TLS), and gives the browser the key exchange data needed for establishing an encrypted channel to Burp. As the recipient of the encrypted traffic, Burp can of course decrypt it. This happens automatically, and invisibly to the user.

Each installation of Burp generates a unique CA certificate, and only devices/apps where a particular installation's CA cert is installed will trust that cert. As such, traffic from other devices you own can't be decrypted by that installation of Burp (until you install the cert on them too), and nobody else's installation of Burp (or of any other intercepting proxy, such as Fiddler or Zap, which work the same way) can decrypt traffic from any of your devices (unless at some point you decide to install their certificate. Don't install unknown root CAs, folks!)

If you want to verify that HTTPS traffic is in fact encrypted, try reading it using a tool like Wireshark (in its default configuration, without providing the decryption key). You'll see a TLS handshake, and some TLS metadata in headers after that, but everything else will be seemingly-random nonsense.

Improve this answer
1
  • So thanks for clarifying that and I have used wireshark so I get the encrypted traffic but here's the dilemma, just like me, an attacker will be using burp too so when they intercept or pickup my traffic of logging in, they'd have my creds even if I used a POST call, so in the end aren't they compromised??
    – Rakoshin
    Mar 30 at 10:21

Not the answer you're looking for? Browse other questions tagged or ask your own question.