it-swarm-eu.dev

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

Lavoro su applicazioni Web e come sai, nella maggior parte dei casi è indispensabile avere un pannello di amministrazione. 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 usare per accedere al proprio pannello.

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

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

Per gli amministratori, le pagine di accesso intuitive non sono davvero necessarie! I dati verranno registrati in entrambi i casi (GET/POST) se esiste un attaccante MiTM.

Ma usando questo metodo, i campi saranno sconosciuti aspettarsi dagli amministratori stessi. Ecco un esempio PHP:

"category.php": (un nome di pagina senza significato)

<?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
}
?>
51
Amirreza Nasiri

Posso pensare ad alcuni 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 è male perché ora se vuoi pubblicare o condividere il tuo codice sorgente con qualcun altro, dovrai ricordarti di redarre 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 hai solo una chiave segreta che tutti gli amministratori devono condividere, diventa molto più facile perdere accidentalmente. Se perde, non avresti modo di sapere chi era responsabile della perdita. Potresti fornire una chiave diversa a ciascun amministratore, ma questo diventa molto disordinato.
  • Non è possibile cambiare facilmente la chiave. In generale, sarà probabilmente necessario che gli amministratori del sito siano non anche operatori del server. Ma con questa configurazione, non è possibile concedere a nessuno la possibilità di modificare la chiave senza concedere anche l'accesso al codice sorgente e al server, che potrebbero o meno sapere come utilizzare handle. L'ottimizzazione del codice sorgente in esecuzione su un sistema di produzione, volenti o nolenti, è soggetta a errori e probabilmente causerà tempi di inattività.
  • Poiché usi GET, è molto facile che la chiave passi attraverso la cronologia del browser o la condivisione accidentale dei collegamenti.
  • 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ù intuitivo possibile, incluso il pannello di amministrazione.

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

63
tlng05

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 post.

137
jdow

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

... è stata stabilita la convenzione che il OTTIENI e HEAD NON DOVREBBERO avere il significato di intraprendere un'azione diversa dal recupero . Questi metodi dovrebbero essere considerati "sicuri". Ciò consente agli agenti utente di rappresentare altri metodi, come POST, PUT e DELETE, in modo speciale, in modo tale che l'utente sia consapevole del fatto che un possibile non sicuro è richiesta un'azione.

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

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

28
AbraCadaver

Quanto sei a tuo agio nell'archiviare le password dell'amministratore in chiaro nei log di accesso al tuo server web?

Il problema che vedo qui è che una richiesta GET must inserisce tutti i nomi e i valori dei campi 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 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 i registri dei server vengano trattati come contenenti informazioni privilegiate (ad esempio gli IP dei clienti), in genere non sono così sensibili da contenere informazioni sufficienti a compromettere l'interfaccia amministrativa di un client.

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

26
Andy Holland

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

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

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

4
Machavity

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

La mia regola empirica è l'uso di post per password e informazioni importanti come editor di articoli di blog e uso get per quasi tutto il resto. Naturalmente ci sono alcune eccezioni in cui i dati sono troppo sensibili per apparire anche nei registri. Ma quelli sono rari anche nel settore aziendale.

Ad esempio, ho una procedura guidata come la funzionalità con 5 passaggi in cui generi un ID processo sul primo passaggio e su ogni passaggio vedrai ?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 costretto a utilizzare il metodo post, l'ID del processo diventa ancora visibile nell'URL come ?proc_id=123.

Ciò semplifica l'inserimento di segnalibri nelle cose, facilita la comprensione dei log di accesso, oltre a essere più istruttivo per le terze parti che desiderano integrarsi con le mie app.

In questo scenario devono essere prese alcune precauzioni 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. Eviterà solo che informazioni sensibili come le password vengano scritte nei log del tuo sito e nella cronologia locale del browser.

3
Lucas

Considera anche che le richieste GET sono destinate a non modificare nulla sul lato server. Un cambio di stato come "disconnesso" -> "connesso" deve sempre essere fatto 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 esiste alcuna autenticazione. È solo un URL "segreto" che devi sapere per "accedere".

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

 Reindirizza Password/topsecret molto dirottatodirettorio/login 

e quindi nella pagina di accesso posiziona la tua session_start()

3
Andre Geddert

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. Apparirà nei registri del server, renderà ancora più facile eseguire un attacco man-in-the-middle. Permette anche molte cattive pratiche, come le persone che segnalano l'URL di accesso, lo dimenticano e permettono ad altri umani di usare il proprio browser Web.

TL; DR: questa è un'idea orribile.

2
Leo Wilson

Sì, è una cattiva pratica. Qualsiasi vantaggio di sicurezza disponibile avendo un nome di campo segreto potrebbe anche essere ottenuto anteponendo tale 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

password=ehu3dva7rthg4e5sdc
1
bdsl