È una cattiva pratica utilizzare il metodo GET come nome utente / password di accesso per gli amministratori?

45

Lavoro su applicazioni Web e, come sai, avere un pannello di amministrazione è un must nella maggior parte dei casi. Possiamo vedere che molte applicazioni web hanno una pagina di accesso specifica per gli amministratori in cui esiste un modulo (di solito il metodo POST ) che gli amministratori possono utilizzare per accedere al proprio pannello.

Ma poiché i nomi dei campi sono noti, un hacker può tentare di violare le password anche se sono implementati alcuni metodi di sicurezza.

Quindi qual è il problema con una semplice GET key (come username) e il suo valore (come password)? Perché non è usato molto o almeno, non è suggerito in molti articoli?

Per gli amministratori, le pagine di accesso user-friendly non sono realmente necessarie! I dati verranno registrati in entrambi i casi ( GET / POST ) se è presente un MiTM attacker.

Ma usando questo metodo, i campi saranno sconosciuti aspettarsi per gli amministratori stessi.  Ecco un esempio di codice PHP:

"category.php": (Un nome di pagina senza senso)

<?php
if (isset($_GET['meaningless_user']) && $_GET['meaningless_word'] == "something"){
    session_start();
    $_SESSION["user"] = "test";
    header('Location: category.php');   // Redirect to same or other page so GET parameters will disappear from the url     
} else {
    die(); // So it'll be like a blank page
}
?>
    
posta Amirreza Nasiri 04.01.2017 - 03:44
fonte

9 risposte

58

Posso pensare a diversi motivi per cui questo non sarebbe l'ideale:

  • Nello snippet di codice che hai pubblicato, stai ora codificando una chiave segreta nel codice sorgente del tuo programma. Questo è un problema perché ora se vuoi pubblicare o condividere il tuo codice sorgente con chiunque altro, dovrai ricordarti di ridurlo. La sicurezza di un sistema non dovrebbe dipendere dal suo codice sorgente che rimane 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 perde, non avresti modo di sapere chi era responsabile di averlo perso. Puoi fornire una chiave diversa a ciascun amministratore, ma questo diventa molto caotico.
  • Non è possibile modificare facilmente la chiave. In generale, è probabile che sia necessario avere amministratori del sito che sono non anche operatori del server. Con questa configurazione, tuttavia, non è possibile concedere a nessuno la possibilità di modificare la chiave senza concedere l'accesso al codice sorgente e al server, che potrebbero o meno sapere come utilizzare. Modificando il codice sorgente in esecuzione su un sistema di produzione, willy-nilly è soggetto a errori e probabilmente causerà tempi di inattività.
  • Poiché utilizzi GET, è molto facile che la chiave passi attraverso le cronologie dei browser o la condivisione accidentale dei link.
  • Non è molto facile da usare. L'utilizzo di questo richiede sapere come manipolare manualmente uno specifico parametro GET. Tu 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, incluso il pannello di amministrazione.

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

    
risposta data 04.01.2017 - 04:51
fonte
132

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

    
risposta data 04.01.2017 - 04:29
fonte
25

Quanto sei a tuo agio con la memorizzazione delle password degli amministratori in chiaro nei log di accesso del tuo server web?

Il problema che vedo qui è che una richiesta GET deve inserire tutti i nomi e i valori dei campi nell'URI della richiesta. Gli URI di richiesta vengono registrati da tutti i tipi di processi e verranno probabilmente archiviati per intero nel registro di accesso del server Web.

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

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

    
risposta data 04.01.2017 - 12:40
fonte
25

Non rigorosamente da una posizione di sicurezza, ma Hypertext Transfer Protocol - HTTP / 1.1 RFC 2616 lo rende abbastanza chiaro:

...the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

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 per tenere traccia dello stato dell'utente (PHP crea i dati della sessione in file flat o in un database)
  • Impostazione di un cookie di sessione per tracciare la sessione

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

    
risposta data 04.01.2017 - 15:42
fonte
4

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 di domini per impostazione predefinita). Possono quindi utilizzare una serie di chiamate "immagine" per ottenere o modificare i dati (molte chiamate AJAX utilizzano GET in modo errato). Ci sono modi per evitare questo , ma la maggior parte delle persone non li abilita. Se utilizzi il POST, questo vettore di attacco non funziona.

    
risposta data 04.01.2017 - 19:04
fonte
3

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 empirica è usare post per password e grandi informazioni come gli editor di articoli di blog e utilizzare per ottenere 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 procedura guidata con 5 passaggi in cui viene generato un ID processo sul primo passaggio e in ogni passaggio verrà visualizzato ?proc_id=123 . PHP supporta la stringa di query anche nei metodi post. Anche in un passaggio in cui i dati del modulo sono troppo grandi e sono obbligato a utilizzare il metodo post, l'ID processo è ancora visibile nell'URL come ?proc_id=123 .

Ciò semplifica la creazione di segnalibri, una più facile comprensione dei log di accesso e anche più educativo per le terze parti che desiderano integrarsi con le mie app.

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

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

    
risposta data 04.01.2017 - 13:11
fonte
3

Considera inoltre che le richieste GET non intendono modificare nulla sul lato server. Un cambiamento di stato come "disconnesso" - > "loggato" deve sempre essere eseguito con una richiesta POST.

Avere un parametro GET come

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

è semanticamente esattamente come

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

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

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

RedirectTemp password/topsecret veryobfuscateddirectoryname/loggedin

e quindi nella pagina di accesso inserisci session_start()

    
risposta data 04.01.2017 - 17:04
fonte
1

Sì, è una cattiva pratica. Potresti anche ottenere un vantaggio di sicurezza disponibile con un nome di campo segreto anteponendo il segreto alla password.

Invece di ottenere con

elephant=rthg4e5sdc

sarebbe meglio usare POST con

password=elephantrthg4e5sdc

E ovviamente puoi aumentare nuovamente la sicurezza cambiandola in qualcosa di più simile a

password=ehu3dva7rthg4e5sdc
    
risposta data 07.01.2017 - 00:44
fonte
1

Anche se l'utente e la password non erano memorizzati nella cronologia del browser (quali sono, come parametri URL), ciò rende estremamente facile per qualsiasi hacker rubare le tue informazioni. Comparirà nei log del server, rendendolo ancora più facile per eseguire un attacco man-in-the-middle. Inoltre, consente di fare un sacco di cattive pratiche, come ad esempio la gente che segna l'URL di accesso, dimenticandosi di esso e lasciando che altri umani utilizzino il proprio browser Web.

TL; DR: Questa è un'idea orribile.

    
risposta data 07.01.2017 - 16:55
fonte

Leggi altre domande sui tag