Stavo usando wireshark e mi aspettavo di vedere un JSESSIONID in una richiesta HTTP, ma non sembrava essere lì per le richieste HTTP. Potrei comunque vedere il mio JSESSIONID. Le richieste di upgrade non sicure aiutano a proteggere una stringa di query sniffing?
I was using wireshark and expecting to see a JSESSIONID in a HTTP request, but it did not seem to be there for HTTP requests. I could see my own JSESSIONID however.
JSESSIONID è un cookie che viene solitamente contrassegnato con i flag "sicuro" e "nessun script". Il flag "sicuro" indica ai browser compatibili di non inviare quel cookie su HTTP, solo HTTPS.
Would upgrade-insecure-requests help protect a query string form sniffing?
L'intestazione HTTP Upgrade-Insecure-Requests request invia un segnale al server che esprime la preferenza del client per una risposta crittografata e autenticata ... altro: link
Se il server riceve la richiesta con Upgrade-Insecure-Requests: 1 , può reindirizzare il client che ha espresso la preferenza per le richieste protette alla versione HTTPS del sito.
IN GENERALE:
La stringa di query fa parte dell'URL nella richiesta. L'URL viene visualizzato nella riga di richiesta della richiesta HTTP:
GET /some/url?a=b HTTP/1.1
Per proteggerlo dallo sniffing è necessario disporre di SSL / TLS che stabilisca una sessione TCP protetta prima di inviare i dati e quindi di crittografare le comunicazioni / i dati.
Prima di tutto usare HTTP per trasmettere dati sensibili non è una buona idea se si usano stringhe di query o altri meccanismi perché si è vulnerabili in molti modi. Anche se utilizzi HTTPS, ci sono molti aspetti che devi considerare quando stai distribuendo.
protect a query string
Penso che tu sia preoccupato per attacchi come XSS e SSRF qui? Se si utilizzano dati nella stringa di query, è necessario eseguire la sanificazione dei dati , la codifica dell'URL e, soprattutto, la convalida dei dati lato server come ben prima di elaborare i tuoi dati.
Leggi altre domande sui tag web-application