Detta sparar inloggningslänken med lösenord och användarnamn i webbläsarhistoriken. Det kan också av misstag fångas av saker som brandväggsloggar, som inte skulle fånga inläggsvariabler.

Jag kan tänka mig en hel del anledningar till varför detta inte skulle vara idealiskt:

• I kodavsnittet som du publicerade kodar du nu in en hemlig nyckel i programmets källkod. Detta är dåligt, för om du nu vill publicera eller dela din källkod med någon annan måste du komma ihåg att ändra den nyckeln. Säkerheten i ett system borde inte vara beroende av att dess källkod förblir dold.
• Detta skalas inte bra. Om du bara har en hemlig nyckel som alla administratörer måste dela blir det mycket lättare att läcka av misstag. Om det läcker, skulle du inte ha något sätt att veta vem som var ansvarig för att läcka det. Du kan ge en annan nyckel till varje administratör, men det blir rörigt mycket snabbt.
• Du kan inte ändra nyckeln enkelt. Generellt sett kommer du troligtvis att behöva ha webbplatsadministratörer som inte också är serveroperatörer. Men med den här inställningen kan du inte ge någon möjlighet att ändra nyckeln utan att också ge åtkomst till källkoden och servern, som de kanske eller inte vet hur man använder handtaget. Att justera källkoden som körs i ett produktionssystem willy-nilly är felbenägen och kommer sannolikt att leda till stillestånd.
• Eftersom du använder GET är det väldigt enkelt för nyckeln att läcka genom webbläsarhistorik eller av misstag länkdelning.
• Det är inte särskilt användarvänligt. Att använda detta kräver att man vet hur man manuellt manipulerar en specifik GET-parameter. Du säger att användarvänlighet för administratörer inte behövs, men detta är definitivt inte sant i allmänhet. Hela din webbplats ska vara så användarvänlig som möjligt, inklusive administratörspanelen.

Sammanfattningsvis kan jag se att den här typen av system används som en tillfällig åtgärd på en liten webbplats, där det finns en webbplatsadministratör som också skrev webbplatsens källkod och hanterar servern. Men allt som är större än det, du vill ha en faktisk administratörsinloggningspanel, med hashade och saltade referenser lagrade i databasen som alla andra användare.

Inte strikt ur säkerhetssynpunkt, men Hypertext Transfer Protocol - HTTP / 1.1 RFC 2616 gör det helt klart:

... konventionen har varit fastställt att GET- och HEAD-metoderna INTE FÅR betydelsen av att vidta en annan åtgärd än att hämta . Dessa metoder bör betraktas som "säkra". Detta gör det möjligt för användaragenter att representera andra metoder, som POST, PUT och DELETE, på ett speciellt sätt så att användaren blir medveten om att en eventuellt osäker åtgärd begärs.

GET bör endast användas för hämtning. I ditt fall skickar du data till servern, servern utför dessa specifika åtgärder (åtminstone):

• Autentisering av en användare
• Skapa en session att spåra användartillstånd (PHP skapar sessionsdata i platta filer eller en databas)
• Att ställa in en session-cookie för att spåra sessionen

POST via HTTPS skulle vara den föredragna metoden att överföra känslig data; användarnamn, lösenord i det här fallet.

Hur bekväm är du med att lagra administratörslösenord i klartext i dina webbserveråtkomstloggar?

Problemet jag ser här är att en GET-begäran måste lägga alla fältnamn och värden i URI för begäran. Begärda URI: er loggas av alla slags processer och kommer sannolikt att sparas i sin helhet i webbserverns åtkomstlogg.

Det betyder att din webbserveråtkomstlogg ökar säkerhetsrisken eftersom den nu innehåller användarnamnen och lösenorden för GET-baserade inloggningssidor. Även om du i allmänhet kan behandla serverloggar som innehåller privilegierad information (till exempel din kunds IP: er), är de vanligtvis inte så känsliga att de innehåller tillräckligt med information för att äventyra en klients administrativa gränssnitt. eftersom fältnamnen och värdena inte lagras i loggen.

En skadlig användare får administratörsuppgifter. Använda en bildtagg

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

de lurar din webbläsare att logga in (bilder är inte föremål för gränsöverskridande begränsningar som standard). De kan sedan använda en serie "bild" -samtal för att få eller ändra data (många AJAX-samtal använder GET felaktigt också). Det finns sätt att undvika detta, men de flesta aktiverar inte dem. Om du använder POST fungerar inte denna attackvektor.

Problemet med att använda get-metoden är att data kommer att synas på skärmen och i webbserverloggarna som standard.

Min tumregel är att använda post för lösenord och stor information som bloggartikel redaktörer och användning får för mest allt annat. Naturligtvis finns det några undantag där data är för känsliga för att kunna visas även i loggarna. Men de är sällsynta även i företagssektorn.

Till exempel har jag en guide som funktionalitet med fem steg där jag genererar ett process-ID i första steget och i varje steg ser du ? proc_id = 123 . PHP stöder frågesträngen även i inläggsmetoder. Även i ett steg där formulärdata är för stora och jag tvingas använda postmetoden blir process-id fortfarande synligt i webbadressen som ?proc_id=123.

Detta gör det lättare att bokmärka saker, lättare att förstå åtkomstloggarna, och mer lärorik för tredje parter som vill integrera med mina appar.

Vissa försiktighetsåtgärder måste vidtas i det scenariot för att undvika problem med bakåtknappen såsom att rensa från historik-URL: er som inte får skickas igen. De flesta spara åtgärder är så.

Naturligtvis skyddar POST dig inte från en MiTM-attack. Det förhindrar endast känslig information som lösenord att skrivas i loggarna på din webbplats och i webbläsarens lokala historia.

Tänk också på att GET-Requests är avsedda att inte ändra någonting på serversidan. En tillståndsändring som "utloggad" -> "inloggad" måste alltid göras med en POST-begäran.

Att ha en GET-parameter som

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

är semantiskt exakt samma som

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

Så det finns ingen autentisering alls. Det är bara en "hemlig" URL som du måste veta för att "logga in".

För att göra det tydligare. Om du till exempel använder Apache kan du få samma resultat med en omdirigering så här:

 RedirectTemp-lösenord / topsecret mycketobfuscateddirectoryname / inloggad 

och placera sedan din session_start ()

Även om användaren och lösenordet inte lagrades i webbläsarens historik (vilket de är, som URL-parametrar) gör det det extremt enkelt för alla hackare att stjäla din information. Det kommer att visas i serverns loggar, det gör det ännu lättare att utföra en man-i-mitten-attack. Det möjliggör också mycket dålig praxis, som att människor bokmärker inloggnings-URL: n, glömmer bort det och låter andra människor använda sin webbläsare.

TL; DR: Det här är en hemsk idé.

Ja, det är dålig praxis. Alla säkerhetsfördelar som är tillgängliga genom att ha ett hemligt fältnamn kan också uppnås genom att förlänga den hemligheten till lösenordet. >

det vore bättre att använda POST med

  lösenord = elephantrthg4e5sdc  

Och naturligtvis kan du öka säkerheten igen genom att ändra det till något mer som

  lösenord = ehu3dva7rthg4e5sdc