Gli hacker possono trovare i token segreti passati alle richieste HTTP GET?

Stai facendo affidamento su un principio chiamato sicurezza attraverso l'oscurità , che è generalmente disapprovato. Esiste un principio ampiamente accettato chiamato Principio di Kerckhoffs che afferma:

A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

Una forma alternativa e più generale del principio è chiamata massima di Shannon:

The enemy knows the system.

In sostanza, ciò significa che mai fare affidamento su un meccanismo di oscurità per proteggere il sistema. Dovresti dare per scontato che gli hacker conoscano il codice e possano scoprire eventuali vulnerabilità come questa.

Pertanto, il tuo meccanismo di accesso dovrebbe comportare un'autenticazione corretta, ad es. inserendo una serie di credenziali che possono essere verificate sul lato server, utilizzando corretto hashing delle password . Ciò significa che anche se un utente malintenzionato conosce il tuo codice, non può sfruttarlo.

Come menzionato altrove su questo sito (vedi questo e questo , il tuo "segreto" può essere scoperto nei log del server web e in molti altri modi.

L'utilizzo di questo come mezzo di controllo degli accessi è noto come "sicurezza attraverso l'oscurità" e può essere facilmente scoperto.

Tuttavia, alcuni siti meno sicuri utilizzeranno una variante di questo tema e lo utilizzeranno per proteggere una sessione dopo l'accesso dell'utente. L'idea qui è di usare un valore GET HTTP invece di un cookie di sessione. Non consiglierei di implementarlo da solo, ma è incluso in molti pacchetti software (Microsoft Windows Identity Foundation), ad esempio, quando i cookie lato client sono disabilitati.

Se questa è una funzione privilegiata che non dovrebbe essere eseguita da chiunque, devi proteggere la tua funzione controllando anche l'identità dell'utente (ad esempio, id di sessione).

Inoltre dovresti assicurarti di avere un token CSRF, se qualcuno dovesse inviare un link a uno dei tuoi utenti con tale richiesta GET e l'utente lo apra, potrebbe finire per eseguire una funzione che non voleva eseguire.

Ora, a seconda di cosa fa la tua funzione e qual è il parametro GET, "hacker" potrebbe scoprire cosa fa.

Potrebbe essere che la tua funzione mostri solo informazioni (immutabili) che questo può essere ok. Vorrei fare riferimento a questa domanda: Quanto è improbabile che un link a Google Doc sia stato indovinato?

Oltre alle altre risposte pubblicate, c'è il problema generale che i browser Web e i loro utenti in genere non considerano le informazioni sensibili come URL. Sono archiviati in file di cronologia, segnalibri, ecc. Senza crittografia da parte dei browser e gli utenti li condivideranno felicemente via e-mail, messaggi istantanei o servizi di condivisione bookmark / url cloud, senza aspettarsi che un URL da solo ne dia accesso. Possono anche essere acquisiti nei registri proxy web, nei registri del firewall e in altri intermediari, che ritengono che le informazioni sensibili non vengano trovate nell'URL.

Se qualcuno di questi viene visto da un web spider, o un utente copia semplicemente l'URL dal proprio browser al proprio blog o wiki, verrà indicizzato e facilmente individuabile dagli hacker nei motori di ricerca.

Nascondere e non proteggere la funzionalità non è una buona pratica di sicurezza.

Ci sono modi indiretti in cui questa funzionalità può perdere, come ad esempio:

• Le vulnerabilità in altre parti della tua applicazione web possono portare ad accessi arbitrari ai file rendendo il tuo file index.php leggibile.
• Il testo HTML e il codice JavaScript possono perdere il nome della variabile nascosta oppure possono suggerire il tipo di quella funzionalità nascosta.
• Messaggi di errore che contengono snippet del codice something .
• Indovinare nomi di variabili comuni o brute-forzandoli.
• Il backup o l'utilizzo di più versioni di quel index.php con estensioni diverse ( index.bak , index.php.1 , ecc.) può rendere il contenuto leggibile.

Prima di tutto, assicurati che il token segreto sia abbastanza lungo e cambi con ogni accesso. Usare sempre lo stesso token è molto rischioso, per le ragioni indicate dalle altre risposte.

Quando utilizzi token diversi, ci sono ancora diverse minacce qui, che possono essere (parzialmente) mitigate:

• Sniffing HTTP: se la connessione non è crittografata, una persona con uno sniffer wifi o un uomo nel mezzo da qualche parte nella rete può vedere il token e usarlo immediatamente. Assicurati che la connessione sia sempre su HTTPS.
• Perdita di dati utente: se l'utente seleziona l'URL o lo invia tramite posta elettronica e il computer degli utenti viene violato / rubato, il segreto è fuori. Questa minaccia può essere mitigata rendendo il token valido solo per un breve periodo di tempo. Se il token può essere collegato a una funzione utente come l'indirizzo IP o l'agente utente, la sicurezza aumenta un po '(ma l'usabilità potrebbe risentirne).
• Perdita di dati lato server: il più facile da mitigare è la perdita di log HTTP: una breve durata del token e il collegamento a fature utente aiutano anche qui.

Un'altra buona strategia consiste nel limitare il livello di accesso degli utenti identificati solo da un token: consentire solo azioni molto specifiche e potenzialmente non pericolose.