Qual è lo scopo delle richieste HTTPS GET vs POST quando si esegue il blocco dei certificati?

Question

Qual è lo scopo delle richieste HTTPS GET vs POST quando si esegue il blocco dei certificati?

#1 da (2 voti)
#2 da (2 voti)

0

Ho un'app mobile che utilizza il blocco della chiave pubblica per assicurarmi di collegarmi solo ai server della mia CA. Funziona alla grande con https, e fa in modo che nessuno possa realmente proxyare il mio server e leggere le richieste senza passare attraverso un certo grado di difficoltà.

Un collega ha avuto l'idea che il blocco dei certificati lo rende così che le richieste POST non siano così utili perché non facciamo richieste a meno che il certificato / chiave pubblica del server con cui stiamo parlando corrisponda a quello appuntato sull'app mobile. Pertanto, le persone non sarebbero in grado di curiosare il corpo POST affatto.

C'è qualche motivo per cui GET sarebbe meno sicuro del POST per un caso in cui è presente il blocco della chiave pubblica per le app mobili?

mobile certificates

posta fjlksahfob 12.06.2014 - 18:43

fonte

2 risposte

2

% richieste diGET possono essere forzate su di te facilmente. Fondamentalmente, supponiamo che esista un server sicuro con cui parli con GET richieste sotto la protezione di HTTPS e blocco dei certificati e qualsiasi altra cosa tu possa immaginare come protezione extra. Chiamiamo www.example.com questo server. Alcune di queste richieste hanno lo scopo di avere un effetto, ad es. una richiesta di GET a:

https://www.example.com/[email protected]

attiva un processo sul tuo server che culmina con l'invio di una email all'indirizzo specificato.

Ora, un attaccante industrioso ti segue in giro e aspetta che tu ti sieda in un ristorante fast food con WiFi gratuito; sa che ti connetteresti a quella rete Wi-Fi e ti cimenterai in una navigazione Web casuale. L'attaccante tira fuori i propri punti di accesso WiFi portatili (come quello ) e aspetta che tu ti connetta al suo hardware . A quel punto, l'attaccante può vedere e modificare tutto il tuo traffico. Certo, SSL lo tiene fuori. Tuttavia, durante la navigazione casuale, non si visita solo il sito Web HTTPS. Se il tuo browser effettua una connessione a un sito Web HTTP (senza SSL), l'autore dell'attacco deve semplicemente inserire il seguente testo nel codice HTML restituito:

<img src="https://www.example.come/[email protected]"/>

eboom!HaiappenaspammatoilPapa.Infatti,dopoavervistoquelpiccolopezzodiHTML,iltuobrowserinviadoverosamenteunarichiestadiGETall'indirizzospecificato.QuestofunzionaindipendentementedallaprovenienzadellapaginaincuiapparequestotagHTML;lerichiestediGETda<img>tageludonototalmentela Politica Same-Origin .

% richieste diPOST non possono essere fabbricate in questo modo. Pertanto, indipendentemente da quanto sei sicuro di parlare con i server che intendi, dovrai utilizzare le richieste di GET solo per l'elaborazione di sola lettura .

risposta data 12.06.2014 - 19:03

fonte

Leggi altre domande sui tag mobile certificates

Come rilevare il cosiddetto "inosservabile" Gameover Zeus? Tor IP e cookie nei servizi nascosti

score 2 · Accepted Answer

Il blocco dei certificati è completamente ortogonale rispetto al metodo HTTP utilizzato nella richiesta. Il blocco dei certificati è utile per prevenire gli attacchi MITM e garantire la riservatezza e l'integrità del canale di comunicazione. Se quel canale trasporta richieste con metodo POST o GET o un mix è irrilevante.

Le richieste POST non sono più sicure delle richieste GET. Se CSRF è la tua preoccupazione, sia POST che GET sono vulnerabili a CSRF, le tecniche per POST CSRF sono ben stabiliti .

Si fa riferimento al "" corpo POST ", ma non importa.Un'attaccante non può vedere alcuna parte delle richieste HTTP quando HTTPS è in uso.L'intera connessione è crittografata, non solo il corpo POST.

Utilizza il metodo più appropriato per l'operazione che stai eseguendo. Se il recupero dei dati senza una modifica dello stato è il tuo obiettivo, utilizza GET. Se stai cambiando stato, usa POST (o anche PUT, DELETE, ecc., Se vuoi essere completamente RESTful).