Domanda su HTTPS e manomissione lato client

Question

Domanda su HTTPS e manomissione lato client

#1 da (2 voti)

1

Qualcuno potrebbe spiegarmi qualcosa per favore:

Sto intercettando richieste sul mio proxy locale su un server HTTPS. Il corpo POST ha dati come "ID = 4001" in testo normale quando lo intercetto. In primo luogo, è normale? L'HTTPS sul posto su questo server è debole o poco brillante in qualche modo?

Qualcuno può spiegare perché ciò che considero le informazioni sensibili sarebbe in chiaro qui?

Gli sviluppatori hanno lanciato la palla e la presentano in testo in chiaro affinché il client possa facilmente manomettere?
Questo sarebbe crittografato se l'HTTPS fosse configurato correttamente?
Siccome mi sto intercettando richieste localmente dalla mia stessa macchina, HTTPS non ha alcun beneficio fino a quando la richiesta non vola su tutta la rete / trasmissione?

Sto intercettando le richieste localmente dal mio cliente direttamente (non attraverso la rete, per così dire). Cercando di ottenere un po 'di chiarezza su questo per mia comprensione, ho ragione nel pensare in questa fase HTTPS ha poco o nessun impatto e l'ID = 4001 è un errore sugli sviluppatori fine?

ps. questo ID è molto sensibile e non vorremmo che qualcuno lo sapesse o lo manomesse con successo.

Aggiornamento: Credo che la mia domanda sia, posso vedere questo parametro / valore ID in testo normale in burpsuite quando si intercettano pacchetti client contro un'applicazione Web in esecuzione su un cert autofirmato di HTTP (presumo auto -segnato è irrilevante), è il fatto che posso vedere questo ID un errore sugli sviluppatori? o sono stupido e questo sarebbe criptato in un vero ambiente di produzione? vedi immagine:

tls tampering

posta symon 08.08.2017 - 00:20

fonte

1 risposta

Leggi altre domande sui tag tls tampering

Perché il malware non viene comunemente scritto in Haskell? È possibile utilizzare un HMAC TLS dopo il fatto per verificare l'autenticità di un messaggio? [duplicare]

score 2 · Answer 1

Sembra che tu abbia configurato BurpSuite per consentire il monitoraggio del traffico HTTPS. In base alla documentazione :

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.

Quindi, in sostanza, BurpSuite sta eseguendo un attacco man-in-the-middle, sfruttando il fatto che viene eseguito sul computer locale e sta installando il proprio certificato.

Nel caso di utilizzo normale, BurpSuite non è installato sul computer client e l'hacker non ha alcuna possibilità di installare i certificati di root. Senza questa abilità, l'hacker non sarebbe in grado di eseguire un attacco man-in-the-middle senza attivare un avviso di sicurezza nel browser, che sembrerebbe un po 'come questo su Chrome:

Per rispondere alle tue domande:

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

No. Il protocollo funziona come previsto. Ti proteggerà dagli attacchi Man-in-the-Middle lanciati sulla rete. Non ti proteggerà da un attacco Man-in-the-Middle lanciato da un processo in esecuzione sul tuo computer locale con un'autorità sufficiente per installare i certificati. Non esiste alcuna tecnologia nell'universo in grado di proteggere una macchina che è stata localmente compromessa in questo modo.

Would this be encrypted if the HTTPS was properly configured?

Si

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

Una corretta. In genere, HTTPS non ti protegge dall'accesso locale (dopotutto, gli strumenti di sviluppo di Chrome ti consentono anche di vedere il traffico); ti protegge da un ascoltatore sulla rete che sta tentando di eseguire l'eavsdrop.