Oförskämd auth php. HTTP Installera säkerhet på en sida med MySQL och PHP. Ansökan. Manuskälltexter
För att skicka ett meddelande om "Autentisering krävs" till klientens webbläsare, vilket i sin tur kommer att resultera i en dialogruta för inmatning av användarnamn och lösenord. Efter att klienten har skrivit in sitt namn och lösenord kommer skriptet att anropas igen, men med de fördefinierade variablerna PHP_AUTH_USER , PHP_AUTH_PW och AUTH_TYPE , som innehåller användarnamn, lösenord och autentiseringstyp. Dessa variabler kan hittas i arrayerna $_SERVER och $HTTP_SERVER_VARS. För närvarande stöds endast "Basic"-autentisering. Du kan också läsa en mer detaljerad beskrivning av funktionen rubrik() .
Ett exempel på ett skriptfragment som tvingar klienten att logga in för att se sidan:
Exempel på HTTP-autentisering
if (!isset($_SERVER [ "PHP_AUTH_USER" ])) ( Hej ($_SERVER["PHP_AUTH_USER"]). Du har angett ett lösenord ($_SERVER["PHP_AUTH_PW"]).
rubrik( "WWW-Authenticate: Basic realm="My Realm"");
eko "Text som ska skickas om
om användaren klickade på Avbryt-knappen";
utgång;
) annat (
eko"
eko "
}
?>
Kompatibilitetsnotering: Var särskilt försiktig när du anger HTTP-rubriker. För att garantera maximal kompatibilitet med det största antalet olika kunder måste ordet "Basic" skrivas med versaler "B", regionen (riket) måste omges av dubbla (inte enkla!) citattecken, och exakt ett mellanslag måste föregå koda 401 i titeln HTTP/1.0 401 .
Istället för att bara visa variablerna PHP_AUTH_USER och PHP_AUTH_PW på skärmen, kan du behöva kontrollera om de är korrekta. Använd frågan för detta databas eller sök efter en användare i en dbm-fil.
Du kan observera funktionerna i webbläsaren Internet Explorer. Det är mycket krävande på parametern för överförda rubriker. Rubrikspecifikation WWW-Autentisera innan du skickar HTTP/1.0 status 401 är ett litet knep.
Från och med PHP 4.3.0, för att förhindra att någon skriver ett skript som avslöjar lösenordet till en sida som använder extern autentisering, är PHP_AUTH-variablerna inte inställda om denna sida använder extern autentisering och är inställd på säkert läge. Oavsett vilket kan variabeln REMOTE_USER användas för att autentisera en externt autentiserad användare. Så du kan alltid använda variabeln $_SERVER["REMOTE_USER"].
Notera: PHP använder AuthType-direktivet för att specificera om extern autentisering används eller inte.
Det bör noteras att allt ovanstående inte hindrar lösenord för sidor som kräver auktorisering från att stjälas av någon som kontrollerar sidor utan behörighet som finns på samma server.
Både Netscape Navigator och Internet Explorer rensar det aktuella fönstrets autentiseringscache för den givna sfären när de tas emot från servern. Detta kan användas för att tvinga användaren att logga ut och visa dialogrutan för användarnamn och lösenord igen. Vissa utvecklare använder detta för att tidsbegränsa inloggningar eller för att tillhandahålla en utloggningsknapp.
Ett exempel på HTTP-autentisering med tvångsinmatning av ett nytt inloggnings-/lösenordspar
function authenticate()(
rubrik( "WWW-Authenticate: Basic realm="Test Authentication System"");
header("HTTP/1.0 401 obehörig");
eko "Du måste ange ett giltigt användarnamn och lösenord för att komma åt resursen \n";
utgång;
}
Om (!isset($_SERVER [ "PHP_AUTH_USER" ]) || Välkommen: ($_SERVER["PHP_AUTH_USER"])
($_POST [ "SeenBefore" ] == 1 && $_POST [ "OldAuth" ] == $_SERVER [ "PHP_AUTH_USER" ])) (
autentisera ();
}
annan(
eko"
"
eko "Föregående inloggning: ($_REQUEST["OldAuth"])";
eko ";
eko "\n";
eko "\n";
eko "\n";
eka"
}
?>
Detta beteende definieras inte av HTTP Basic Authentication-standarderna, så du bör inte lita på det. Som tester har visat rensar inte Lynx-webbläsaren auktoriseringscachen när den tar emot en 401-status från servern, och genom att klicka på "Tillbaka" och sedan på "Forward" i följd är det möjligt att öppna en sådan sida, förutsatt att det krävs behörighetsattribut har inte ändrats. Användaren kan dock trycka på "_"-tangenten för att rensa autentiseringscachen.
Observera också att före PHP 4.3.3 fungerade inte HTTP-autentisering på servrar som kör Microsoft IIS om PHP installerades som en CGI-modul, på grund av vissa IIS-begränsningar. För att uppnå korrekt funktion i PHP 4.3.3+ måste du redigera IIS-konfigurationsinställningen som heter "Directory Security". Klicka på etiketten "Redigera" och markera alternativet "Anonym åtkomst", alla andra fält ska förbli omarkerade.
En annan begränsning om du använder IIS via ISAPI: PHP_AUTH_*-variabler är inte definierade, men HTTP_AUTHORIZATION-variabeln är tillgänglig. Exempelkod du kan använda: list($user, $pw) = explode(":", base64_decode(substr($_SERVER["HTTP_AUTHORIZATION"], 6)));
Anmärkning om IIS: För att HTTP-autentisering ska fungera korrekt i IIS måste alternativet cgi.rfc2616_headers i PHP-konfigurationen sättas till 0 (standardvärdet).
Uppmärksamhet: Om skyddat läge används kommer UID för det aktuella skriptet att läggas till i sfären av WWW-Authenticate-huvudet.
| <<< Назад | Innehåll | Vidarebefordra >>> |
| Om du har fler frågor eller något är oklart - välkommen till vår | |
|
|
Att begränsa åtkomsten till något område på sajten ser vanligtvis ut
monotont: varje användare får ett användarnamn och lösenord eller han själv
väljer dem, och du måste ange dem för att komma in på den säkra delen av webbplatsen. Ur teknisk synvinkel använder lösenordsverifiering
olika metoder. Ett HTML-formulär kan användas för att ange ett användarnamn och lösenord.
I det här fallet skickas lösenordet till servern i klartext i POST-förfrågan.
Detta är oacceptabelt om användaren är i LAN där det är möjligt
med hjälp av en sniffer. För att lösa detta problem har en metod utvecklats
hash-autentisering, där lösenordet inte överförs, men
en hashsträng skickas, beroende på lösenordet, någon gång
parameter och eventuellt från andra parametrar. Denna metod är fortfarande
kallas utmaning/svar eftersom när du använder det, klienten
tar emot en begäran med en engångsparameter och skickar ett svar som innehåller hashen. På HTTP 1.1-protokollnivån är autentisering möjlig med metoden
Basic, vilket är ingenting bättre användning HTML-formulär och Digest, som
vi kommer att överväga i detalj.
När du använder Digest-metoden, som redan nämnt, lösenordet
överförs inte och kan inte sniffas, men det finns en annan sida
Problem. För att verifiera lösenordet måste servern beräkna
svar och jämför det med klientens svar, därför måste servern
lagra lösenordet eller data som är beroende av det, nödvändigt för
passerar autentisering. Av detta följer att en person som har fått rättigheter
att läsa konton (till exempel använda SQL-injektion), kommer att kunna få
åtkomst till sidor skyddade av Digest-metoden. När man använder metoden
Grundläggande är det möjligt att lagra hash istället för lösenord, vilket inte tillåter höjning av rättigheter,
efter att ha läst dessa hash (nedan ser vi att Digest också kan lagra hash,
men sådana att deras kunskap är tillräcklig för att beräkna svaret). Därför står vi inför ett dilemma: antingen kommer vårt lösenord att sniffas,
eller så kommer de att få det genom en webbsårbarhet som någon definitivt kommer att hitta,
för den som söker kommer alltid att finna. Finns det en autentiseringsmetod utan
båda dessa brister - autentiseringsmetoden för publik nyckel:
du behöver en offentlig nyckel för verifiering och en hemlig nyckel för verifiering,
HTTP 1.1 tillhandahåller dock inte en sådan metod. RFC 2069
rekommenderar att du använder SSL om säkerheten är så viktig. Endast överföringen av lösenordet är skyddad, och innehållet är inte krypterat, så
att det inte är meningsfullt att skydda resurser med denna metod, varifrån användaren
tar emot hemligstämplad information. De kräver SSL. Och det är vettigt
för att skydda till exempel ett forum eller ladda upp innehåll till en webbplats. Så, om hosting inte stöder SSL, och autentisering måste
för att vara säker använder vi Digest. Apache har en mod_digest-modul. Att använda den
i config (eller i .htaccess) skriver vi:
AuthType Digest
AuthUserFile<файл>
AuthName<название защищаемой области>
Kräv valid_user
Användarfiler skapas av verktyget
htdigest. Mod_digest har rapporterats ett tag som sårbart, så,
kanske finns det fortfarande några problem att hitta. Dessutom när
Jag försökte använda den hemma, fick ett fel
500 Server internt fel. Dessutom, om lägga till konton skulle ske
automatiskt, och det borde finnas många av dem, det borde de
lagras inte i Apache-konfigurationen, utan i MySQL. Lösning -
använd php. PHP har inte inbyggt stöd för detta.
metod, så den måste implementeras. För detta är det nödvändigt att studera
denna metod i detalj. Jag noterar direkt att artikeln som presenteras i denna artikel
implementering fungerar bara på Apache eftersom full tillgång till headers
request (funktion apache_request_headers) fungerar bara i Apache, men på
andra servrar kanske inte är tillgängliga. Vi behöver bara läsa
Auktoriseringshuvud.
Beskrivning av metoden
Den fullständiga beskrivningen av metoden finns i RFC 2069, och om
kort sagt, metoden fungerar så här. När servern tar emot en begäran relaterad till ett skyddat område,
den kastar ett 401 Auktorisation Required-fel och en begäran-header
autentisering så här:
WWW-Authenticate: Digest realm="secure area", nonce="123456123456"
rike är namnet på det skyddade området och nonce är den enda gången
menande. Det finns fler valfria parametrar som vi diskuterar
vi kommer inte. Klienten upprepar begäran med en rubrik så här:
Auktorisering: Digest realm="secure area", användarnamn="123", uri="/index.php", nonce="123456123456", response="1234567890abcdef1234567890abcdef"
Uri-parametern måste matcha URI i begäran och svaret är
svaret, som beräknas så här:
svar = H(H(A1) + ":" + nonce + ":" + H(A2))
H - hash-funktion, standard MD5
A1 = login + ":" + realm + ":" + lösenord
A2 = begäranmetod + ":" + URI
förfrågningsmetoden är GET, POST, etc.
Som du kan se är A1 inte beroende av vare sig frågan eller engångsfrågan
värden, så servern kanske inte lagrar lösenordet, men
H(Al). Så här är det implementerat i mod_digest i Apache.
Samma data räcker dock för kunden. Angriparen, efter att ha fått
denna hash, kan beräkna svaret med ovanstående formler och
generera en HTTP-förfrågan, till exempel med hjälp av programmet
AccessDriver och dess HTTP-verktyg
felsökare. Denna process kommer att visas mer i detalj nedan. Servern måste kontrollera om värdet är ett nonce
den som tidigare utfärdats till klienten och om den är inaktuell.
Om svaret matchar nonce-parametern, men värdet på denna parameter
inte relevant, svaret som beskrivs ovan med 401-koden utfärdas med den enda
skillnaden är att WWW-Authenticate-huvudet läggs till med parametern
stale=true vilket indikerar att åtkomst nekas enbart av denna anledning,
och bör försöka igen utan att be användaren om ett nytt lösenord. Detta, IMHO, är obekvämt, för om en sådan situation uppstår
när du begär ett POST eller PUT med ett stort datablock måste klienten göra det
överföra all data två gånger. För att undvika detta ger standarden
Authentication-Info-huvudet, där servern kan, när den svarar på
en lyckad begäran informerar kunden om nästa nonce.
Syntaxen är densamma som WWW-Authenticate, förutom nonce
ersätts av nextnonce. Men att döma av resultaten av min
experiment ignorerar Opera denna rubrik. En annan lösning: enligt
RFC 2068 (HTTP/1.1), servern KAN svara innan begäran slutförs,
så att klienten avbryter onödig dataöverföring, men på Apache+PHP detta
är inte implementerat, eftersom skriptet börjar köras först efter
hur Apache kommer att ta emot och analysera begäran fullt ut.
Lagring av data mellan förfrågningar
Det finns en subtil poäng i PHPs implementering av utmaning/svar-metoden.
Engångsparametern bildas och skickas till klienten i ett svar, och
kontrolleras redan i en annan session av skriptet.
Det vill säga, det måste sparas från ett skriptanrop till ett annat, och för detta måste du
använda filer eller databas. Mitt exempel använder filer som heter,
motsvarande engångsvärden, och själva filerna innehåller
IP-adresserna till de klienter som de är utfärdade till. Insamling är inte implementerad i exemplet
skräp: du måste regelbundet radera gamla filer.
Kodanalys
Detta skript kontrollerar bara lösenordet och fungerar oavsett
logga in. Beroende på framgången av kontrollen ges enkla svar.
$realm = "säkert område"; // Namn på skyddat område
$pass = "pass"; // Lösenord
$fileprefix = "./"; // Sökväg för etikettfiler som indikerar giltigheten av nonce
/*
Låt oss konstruera en engångsparameter som rekommenderas i RFC2069, även om det är möjligt på annat sätt. Parametern, enligt rekommendationen, bör bero på klientens adress, aktuell tid och den hemliga strängen. */
$nonce = md5($_SERVER["REMOTE_ADDR"] . ":" . time() . ":MyCooolPrivateKey");
// Får rubriker
$headers = apache_request_headers();
// Flagga som vi kommer att ställa till TRUE vid framgångsrik validering
$auth_success = FALSK;
$stale = "";
// Om det inte finns någon auktoriseringsrubrik finns det inget att kontrollera
if (isset($headers["Auktorisering"]))
{
$authorization = $headers["Authorization"];
/* Analysera titeln med ett reguljärt uttryck. Titeln innehåller ordet "Digest" och en lista
parametrar av formen param="värde" eller param=värde separerade med kommatecken. Detta reguljära uttryck matchar en sådan parameter. */
preg_match_all("/(,|\s|^)(\w+)=("([^"]*)"|([\w\d]*))(,|$)/",
$authorization, $matches, PREG_SET_ORDER);
/* Nu, för att underlätta ytterligare bearbetning, kommer vi att bilda en array, där nycklarna är namnen på parametrarna och värdena på arrayelementen är
parametervärden. */
$auth_params = array();
för ($i = 0; $i< count($matches); $i++)
{
$match = $matches[$i];
/* Namnet står alltid i den andra gruppen av parenteser, beroende på om det står inom citattecken eller inte så kan det
vara i 4:e eller 5:e gruppen. För grupper av parentes fångade
till en orealiserad gren, en tom sträng i arrayen,
så du kan bara lägga till värdena.*/
$auth_params[$match] = $match . $match;
}
/* Beräkna svaret som matchar
inloggningen som användaren angett, vårt lösenord och engångsparametern som användaren skickat.
*/
$a1 = $auth_params["användarnamn"] . ":" . $auth_params["realms"] . ":" . $pass;
$a2 = $_SERVER["REQUEST_METHOD"] . ":" . $_SERVER["REQUEST_URI"];
$resp = md5(md5($a1) . ":" . $auth_params["nonce"] . ":" . md5($a2));
// Vi kollar svaret.
if ($resp == $auth_params["svar"])
{
//
Kontrollera relevansen av en engångsparameter
$fn = $filprefix . $auth_params["nonce"];
if (@file_get_contents($fn) == $_SERVER["REMOTE_ADDR"])
{
unlink($fn); //Det här alternativet är inte längre relevant.
$auth_success = TRUE; //Autentisering godkänd
) annat
{
//
Engångsparameter är irrelevant
$stale = ", inaktuell = sant";
}
}
}
if ($auth_success)
{
skriva ut("
print("Autentiserats framgångsrikt\n");
var_dump($auth_params);
skriva ut("");
) annat
{
file_put_contents($filprefix . $nonce, $_SERVER["REMOTE_ADDR"]);
$proto = $_SERVER["SERVER_PROTOCOL"];
Header("$proto 401 inte auktoriserad");
Header("WWW-Authenticate: Digest realm=\"$realm\", nonce=\"$nonce\"$stale");
skriva ut("
");");
print("Du måste autentisera med Digest-metoden");
skriva ut("
}
Godkänd sammanfattning Auth med känd H(A1)
Jag kommer att visa med exempel hur man klarar verifieringen om lösenordet är okänt,
men H(A1) är känd. För att göra detta, som redan nämnts, behöver du
AccessDriver. Jag kommer att göra hashberäkningar genom att ringa från kommandoraden
PHP CLI. Låt den skyddade sidan finnas på
http://mrblack.local/auth1.php och H(A1)-hash är "a8fb5b2d780a7bf0782207a51a013f04".
Öppna AccessDriver->Verktyg->HTTP Debugger och ange adressen
"http://mrblack.local/auth1.php". Klicka på "Anslut". Vi får:
HTTP Header = HTTP/1.1 401-auktorisering krävs
HTTP Header = Datum: Mån, 04 Jul 2005 08:09:17 GMT
HTTP Header = Server: Apache/1.3.31 (Win32) PHP/5.0.2
HTTP Header=X-Powered-By: PHP/5.0.2
HTTP Header = WWW-Authenticate: Digest realm="secure area", nonce="5925bea78552224abda11bfe318a8a03"
HTTP Header = Anslutning: stäng
HTTP Header = Content-Type: text/html
Öppna konsolen, gå till mappen med PHP och kör in följande kommando:
php -r "print md5("a8fb5b2d780a7bf0782207a51a013f04:
: ".md5("GET:http://mrblack.local/auth1.php"));"
Vi får önskat Digest-svar: c6d0af0db239d75c
3f59640a4896d096
Nu i AccessDriver, markera kryssrutan "Header Data", kopiera den till den visade
fältrubriker som skickades i föregående begäran och lägg till dem
Tillstånd. Så här händer:
HÄMTA http://mrblack.local/auth1.php HTTP/1.1
Acceptera: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Acceptera-språk: en-us,en;q=0,5
Användaragent: Mozilla-kompatibel
Värd: mrblack.local
Pragma: ingen cache
Auktorisering: Digest användarnamn="mrblack", realm="secure area", nonce="5925bea78552224ab
da11bfe318a8a03", uri="http://mrblack.local/auth1.php", response="c6d0af0db239d75c3f59
640a4896d096"
Klicka på "Anslut". Vi får resultatet:
Ibland är det nödvändigt att stänga från extern tillgång PHP sida om du gör ett stängt område av webbplatsen. Det kan vara någon form av dold information för dina kunder eller webbplatsbesökare, något slags admingränssnitt för dig, etc. Du kan komma på hundratals olika uppgifter som kräver åtkomstbegränsningar.
Du kan stänga en sådan sida på flera kompletterande sätt:
- Lösenordsskydd (inloggning/lösenord) med hjälp av variabler $_SERVER["PHP_AUTH_USER"] och $_SERVER["PHP_AUTH_PW"].
- Skydd av IP klientadress med hjälp av en variabel $_SERVER["REMOTE_ADDR"].
- Skydd av MAC adress i lokala nätverk (utöver skydd av IP).
Låt oss först analysera den första metoden, som är den viktigaste. Det låter dig stänga åtkomsten till sidan med inloggning och lösenord, så att endast personer som känner till inloggningen och lösenordet kan få åtkomst. Dessutom kan de delas upp enligt denna funktion och ge ut olika information för var och en. Implementeras genom att utfärda specialfält i protokollhuvudet HTTP. Låt oss skapa en funktion auth_send():
" ,"
Verifieringsfel
" ,"Kontakta din administratör för ett användarnamn och lösenord.
",""; avsluta; ); ?>Denna funktion informerar webbläsaren om att behörighet med inloggning och lösenord krävs för åtkomst. Och ger även in sidan HTML för användaren.
" ,"
Välkommen!
" ,"Du är inloggad med användarnamnet ",$auth_user," och lösenordet ",$auth_pass,".
" ,""; ?>Verifieringskoden för inloggning och lösenord är inte alltför komplicerad i det här fallet, eftersom den är implementerad för en person. Operationslogiken är enkel om det inte finns någon variabel $_SERVER["PHP_AUTH_USER"] och $_SERVER["PHP_AUTH_PW"] eller deras värden inte matchar de önskade, anropa sedan funktionen auth_send(). Glöm inte att det ringer i slutet utgång, så programmet avslutas.
Nästa skyddsnivå implementeras genom filtrering IP anslutande klientadress. Naturligtvis, på Internet, många leverantörer problem IP adresser ett tag och det är värdelöst att använda detta skydd, men om vi pratar om företags lokala nätverk, kommer denna kontroll att ge ytterligare skydd.
Din IP hittades inte!!!"; avsluta; ); ?>
Här i raden $allowed_ipsåtskilda av ett mellanslag IP adresser som är tillåten åtkomst. Därefter får vi en array som använder explodera() och gör en sökning efter kundens adress från $_SERVER["REMOTE_ADDR"]. Jag använde sökfunktionen array_search(), eftersom det är osannolikt att hennes kod implementerad i C kommer att köras något snabbare än vad vi kan skriva i PHP använda cykler för eller för varje. Men hastigheten är inte huvudsaken här :)
Och det sista steget i försvaret är att kolla MAC adresser. Det tillhör kategorin paranoid och bör användas om du använder det från det lokala nätverket och den data du skyddar är verkligen mycket viktig. Hittills har jag implementerat denna kontroll endast på systemet linux på grund av den relativa lättheten att genomföra. Men du kan försöka implementera det för vilken annan plattform som helst. Vi skriver en funktion:
Som Linuxoids redan har förstått är den baserad på ARP systemtabell, som kan nås med hjälp av filen /proc/net/arp. Funktionen söker i strängarna efter det önskade IP adress och returnera den MAC adress:
Din IP=192.168.10.15 och MAC=00:04:31:E4:F8:37
I systemet Windows kanske finns det andra sätt att få MAC enklare, men av de som verkligen fungerar är detta slutsatsen ARP systemtabeller med kommandot:
C:\WINDOWS\>arp -a Gränssnitt: 192.168.10.15 på gränssnitt 0x1000003 IP-adress Fysisk adresstyp 192.168.10.1 00-50-22-b0-6a-aa dynamisk 192.168.10-6-e308.10-6 e8 dynamisk 192.168.10.3 00-04-61-9e-26-09 dynamisk 192.168.10.5 00-0f-38-6a-b1-18 dynamisk
Du kan implementera skydd baserat på denna adress själv om du verkligen behöver det :) Men kom ihåg att om du har ohanterad utrustning på ditt nätverk utan möjlighet att binda MAC adresser till porten, kanske detta skydd inte fungerar, eftersom det är möjligt att förfalska alla dina identifieringsdata som används för skydd (inloggning, lösenord, IP och MAC-adress).