Ciò memorizzerebbe il collegamento di accesso con password e nome utente nella cronologia del browser. Potrebbe anche essere catturato accidentalmente da cose come i log del firewall, che non catturerebbero le variabili dei post.

Mi vengono in mente diversi motivi per cui questo non sarebbe l'ideale:

• Nello snippet di codice che hai pubblicato, ora stai codificando una chiave segreta nel codice sorgente del tuo programma. Questo è un male perché ora se vuoi pubblicare o condividere il tuo codice sorgente con qualcun altro, dovrai ricordarti di oscurare quella chiave. La sicurezza di un sistema non dovrebbe dipendere dal fatto che il suo codice sorgente rimanga nascosto.
• Questo non si adatta bene. Se si dispone di una sola chiave segreta che tutti gli amministratori devono condividere, diventa molto più facile perdere accidentalmente. Se dovesse fuoriuscire, non avresti modo di sapere chi era responsabile della fuoriuscita. Potresti fornire una chiave diversa a ciascun amministratore, ma questo diventa complicato molto rapidamente.
• Non puoi cambiare la chiave facilmente. In generale, probabilmente avrai bisogno di amministratori di sito che non sono anche operatori di server. Ma con questa configurazione, non puoi concedere a nessuno la possibilità di modificare la chiave senza concedere anche l'accesso al codice sorgente e al server, che possono o meno sapere come utilizzare handle. Modificare il codice sorgente in esecuzione su un sistema di produzione, volenti o nolenti, è soggetto a errori e probabilmente si tradurrà in tempi di inattività.
• Poiché utilizzi GET, è molto facile che la chiave trapeli attraverso le cronologie del browser o accidentalmente condivisione di link.
• Non è molto facile da usare. L'utilizzo di questo richiede sapere come manipolare manualmente un parametro GET specifico. Dici che la facilità d'uso per gli amministratori non è necessaria, ma questo non è assolutamente vero in generale. L'intero sito dovrebbe essere il più user-friendly possibile, compreso il pannello dell'amministratore.

In sintesi, posso vedere questo tipo di sistema in uso come misura temporanea su un piccolo sito, dove c'è un amministratore del sito che ha anche scritto il codice sorgente del sito e gestisce il server. Ma qualsiasi cosa più grande di questo, ti consigliamo di avere un vero pannello di accesso dell'amministratore, con credenziali sottoposte a hashing e salate memorizzate nel database come qualsiasi altro utente.

Non strettamente dal punto di vista della sicurezza, ma Hypertext Transfer Protocol - HTTP / 1.1 RFC 2616 lo rende abbastanza chiaro:

... la convenzione è stata stabilito che i metodi GET e HEAD NON DOVREBBERO avere il significato di intraprendere un'azione diversa dal recupero . Questi metodi dovrebbero essere considerati "sicuri". Ciò consente ai programmi utente di rappresentare altri metodi, come POST, PUT e DELETE, in un modo speciale, in modo che l'utente sia informato del fatto che viene richiesta un'azione possibilmente non sicura.

GET dovrebbe essere usato solo per il recupero. Nel tuo caso, stai inviando dati al server, il server sta eseguendo queste azioni specifiche (come minimo):

• Autenticazione di un utente
• Creazione di una sessione da monitorare stato utente (PHP crea i dati di sessione in file flat o in un database)
• Impostazione di un cookie di sessione per monitorare la sessione

POST su HTTPS sarebbe il metodo preferito per la trasmissione dati sensibili; nome utente, password in questo caso.

Quanto sei a tuo agio con l'archiviazione delle password di amministratore in testo non crittografato nei log di accesso del tuo server web?

Il problema che vedo qui è che una richiesta GET deve inserire tutti i nomi di campo e valori nell'URI della richiesta. Gli URI delle richieste vengono registrati da tutti i tipi di processi e probabilmente verranno archiviati, per intero, nel registro di accesso al server web.

Ciò significa che il tuo registro di accesso al server web aumenta il rischio per la sicurezza perché ora contiene i nomi utente e le password per le pagine di accesso basate su GET. Sebbene in genere si possa trattare i log del server come contenenti informazioni privilegiate (ad esempio gli IP del cliente), in genere non sono così sensibili da contenere informazioni sufficienti per compromettere l'interfaccia amministrativa di un client.

POST è superiore per questo, perché i nomi e i valori dei campi non vengono memorizzati nel registro.

Un utente malintenzionato ottiene le credenziali di amministratore. Utilizzo di un tag immagine

  <img src = "https://example.com/login?username=admin&amp;password=topsecret" style = "display: none" >  

ingannano il tuo browser per accedere (le immagini non sono soggette a restrizioni interdominio per impostazione predefinita). Possono quindi utilizzare una serie di chiamate "immagine" per ottenere o modificare dati (molte chiamate AJAX utilizzano anche GET in modo errato). Esistono modi per evitarlo, ma la maggior parte delle persone non li abilita. Se stai utilizzando POST, questo vettore di attacco non funziona.

Il problema dell'utilizzo del metodo get è che i dati saranno visibili sullo schermo e nei log del server web per impostazione predefinita.

La mia regola pratica è utilizzare post per password e grandi informazioni come l'articolo del blog editor e usa get per quasi tutto il resto. Ovviamente ci sono alcune eccezioni in cui i dati sono troppo sensibili per apparire anche nei log. Ma quelli sono rari anche nel settore aziendale.

Ad esempio, ho una funzionalità simile a una procedura guidata con 5 passaggi in cui genero un ID di processo sul primo passaggio e ad ogni passaggio vedrai ? proc_id = 123 . PHP supporta la stringa di query anche nei metodi di post. Anche in un passaggio in cui i dati del modulo sono troppo grandi e sono costretto a utilizzare il metodo post, l'id del processo è ancora visibile nell'URL come ?proc_id=123.

Questo rende più facile inserire i segnalibri, più facile capire i log di accesso, nonché più educativo per le terze parti che vogliono integrarsi con le mie app.

Alcune precauzioni devono essere prese in questo scenario per evitare problemi con il pulsante indietro come la cancellazione dagli URL della cronologia che non devono essere reinviati. La maggior parte delle azioni di salvataggio sono così.

Ovviamente il POST non ti proteggerà da un attacco MiTM. Impedirà solo che informazioni sensibili come password vengano scritte nei log del tuo sito e nella cronologia locale del browser.

Considera anche che le richieste GET hanno lo scopo di non modificare nulla sul lato server. Un cambio di stato come "disconnesso" -> "connesso" deve sempre essere eseguito con una richiesta POST.

Avere un parametro GET come

  https: / /example.com/loginpage.php?password=topsecret 

è semanticamente esattamente uguale a

  https://example.com/loginpage/password / topsecret 

Quindi non c'è alcuna autenticazione. È solo un URL "segreto" che devi conoscere per "accedere".

Per renderlo più chiaro. Se usi Apache, ad esempio, puoi ottenere lo stesso risultato con un reindirizzamento come questo:

 RedirectTemp password / topsecret veryobfuscateddirectoryname / loggato 

e poi nella pagina di login inserisci il tuo session_start ()

Anche se l'utente e la password non sono stati memorizzati nella cronologia del browser (quali sono, come parametri URL), questo rende estremamente facile per qualsiasi hacker rubare le tue informazioni. Apparirà nei log del server, rende ancora più facile eseguire un attacco man-in-the-middle. Permette anche molte cattive pratiche, come le persone che aggiungono ai segnalibri l'URL di accesso, se ne dimenticano e consentono ad altri utenti di utilizzare il proprio browser Web.

TL; DR: Questa è un'idea orribile.

Sì, è una cattiva pratica. Qualsiasi vantaggio di sicurezza disponibile avendo un nome di campo segreto può essere ottenuto anche anteponendo quel segreto alla password.

Invece di GET con

  elephant = rthg4e5sdc  

sarebbe meglio usare POST con

  password = elephantrthg4e5sdc  

E ovviamente puoi aumentare di nuovo la sicurezza cambiandolo in qualcosa di più simile

  password = ehu3dva7rthg4e5sdc