Tehát az a feladatunk, hogy beállítsunk egy jelszót egy bizonyos oldal eléréséhez. Kezdjük a védelem legprimitívebb módszerével – néhány sor JavaScriptben:

Var pass = prompt("Adja meg a jelszót:", ""); if (pass == null) window.location = "rossz.html"; else if (pass.toLowerCase() == "wwvsfc") window.location = "temp.html"; else window.location = "rossz.html"; Az olyan trükkök, mint a szkript elrejtése egy külön fájlba egy konstrukció segítségével, alapvetően nem változtatnak semmit.

Hasonló rendszer Javaban implementálva:

Java.applet importálása*; import java.awt.*; import java.net.*; public class Jelszó kiterjeszti a kisalkalmazást( TextField login, password; String Login = "bejelentkezés"; String Jelszó = "Jelszó"; public Password() ( ) public void init() ( Panel panel = new Panel(); panel.setLayout(new GridLayout(2,2)); new Button("Ok")); nyilvános logikai művelet(Event evt, Object obj) ( if(evt.target instanceof Button) ( String s; if(login.getText().equals(Login) && password.getText()) .equals(Password)) ( s = "http://www.hackzone.ru/articles/ok.html" ; ) else ( s = "http://www.hackzone.ru/articles/bad.html"); ) try ( getAppletContext().showDocument(új URL(ek)); ) catch(Exception e) ( password.setText (e.toString()); return true; return false)

Ha ezt a kisalkalmazást belefoglalja egy oldalba, valami ehhez hasonlót kaphat (minden következő példa az ok.html és a bad.html fájlokat használja):

Jelszó ellenőrzés

Lehet okosabbá tenni, minden felhasználónak külön oldalt készíteni, rákényszeríteni, hogy fájlból olvasson adatokat stb. Alapvető hátránya, hogy miután egy személy a keresett oldalra került, senki sem akadályozhatja meg, hogy megjegyezze ezt az URL-t, ezért ez egy egyszeri eszköz. Természetesen elrejtheti az oldalt egy keretben, hogy az URL ne jelenjen meg a címsorban, de megértheti, kitől származik ez a védelem. Az applet ismét teljes egészében az ügyfélhez kerül, és elvileg teljesen elérhető a kutatás számára.

A CGI használatán alapuló megoldásnak nincs utolsó hátránya. Egy egyszerű Perl-szkript valahogy így néz ki:

#!/usr/bin/perluse CGI qw(:standard); $query = új CGI;$ok = "ok.html";$cím = "rossz.html"; $login = "bejelentkezés";$password = "jelszó"; $l = $query->param("bejelentkezés"); $p = $query->param("jelszó"); if(($p eq $jelszó) && ($l eq $bejelentkezés))( $cím = $ok;)print $query->redirect($cím);

Használati példa:

Jelszó ellenőrzés

Az első hátrány kezelésére dinamikusan létrehozhat egy új oldalt a valahol elrejtett oldal alapján, anélkül, hogy megadná az URL-t.

Módosított kód:

#!/usr/bin/perluse CGI qw(:standard); $query = új CGI; $ok = "ok.html"; $cím = "rossz.html"; $docroot = $ENV("DOCUMENT_ROOT"); $localpath = "/cikk/"; $login = "bejelentkezés";$password = "jelszó"; $l = $query->param("bejelentkezés"); $p = $query->param("jelszó"); if(($p eq $jelszó) && ($l eq $bejelentkezés))( $cím = $ok;) print $query->header(); open(FL, $docroot.$localpath.$cím); while())(# Itt egyúttal menet közben is módosíthatod a html kódot# Miért? Hát, sosem lehet tudni... :) print $_;) close (FL);

Használati példa:

Jelszó ellenőrzés

Amint láthatja, a fájl URL-címe már nem jelenik meg, bár SSI költségén (azonban a kimenet során csak elkaphatók és manuálisan feldolgozhatók, de itt is megmarad az URL kitalálásának elméleti lehetősége, és). nem szabad megfeledkeznünk arról, hogy mindenféle kép rossz szolgálatot tehet az oldalaknak – persze ha relatív útvonalakat használunk.

Végül, a hozzáférési jelszó beállításának legmegbízhatóbb módja a szervereszközök használata – végül is nem véletlenül tették meg az emberek. Kettőre koncentrálok: az Apache a legnépszerűbb, az IIS pedig szintén népszerű :)

Az IIS-szel minden nagyon egyszerű - a védelmet NTFS segítségével végzik, ami természetesen némileg korlátozza a nem szerver rendszergazdák képességeit. Az ötlet a következő: az IUSR_xxxx felhasználótól, akinek fiókja alatt az oldal összes látogatója alapértelmezés szerint dolgozik, megtagadják a hozzáférést a kívánt fájlhoz/könyvtárhoz. Ezt követően csak azok a felhasználók férhetnek hozzá ezekhez a fájlokhoz, akiknek ez kifejezetten meg van adva a Tulajdonságok->Biztonság menüpontban. Nyilvánvaló, hogy sokkal kényelmesebb csoportokba egyesíteni őket. Van itt néhány finomság. Először is, a megadott felhasználóknak meg kell adni a helyi bejelentkezési jogot (Szabályzat->Felhasználói jogok a Felhasználókezelőben) Másodszor, ha a WWW beállításainál nem választja ki az Alap hitelesítés (Szöveg törlése) WWW szolgáltatást, akkor csak az Internet Explorer felhasználók kerülnek be. beengedték.

Az Apache-ban minden kicsit másképp történik. A védelem címtárszinten van beállítva. A megfelelő direktívák az általános php.ini konfigurációs fájlban és a .htaccess fájlokban is elhelyezhetők. A direktívák készlete mindkét esetben ugyanaz, és a legtöbb ember számára, aki webhelyet/oldalt bérel valaki más szerverén, az első lehetőség nem elérhető. Tehát létrehoz egy .htaccess fájlt abban a könyvtárban, amelyhez korlátozni kívánja a hozzáférést, majd beilleszti a következő direktívákat:

AuthType vezérlés típusa- Általában az alapszintet használják.

AuthName Név- megadja annak a területnek a nevét, ahol a felhasználónevek és jelszavak érvényesek. Ez ugyanaz a név, amelyet a böngésző a jelszó párbeszédpanelen jelenít meg. Ha a különböző könyvtárakhoz egy ilyen nevet ad meg, megspórolhatja a felhasználóknak az extra jelszó megadásának idejét.

AuthGroupFile Név- megadja annak a fájlnak a nevét, amelyben a csoportok és tagjaik nevei vannak tárolva. A formátuma:
csoport1: tag1 tag2...
csoport2: tag3 tag4 ...

AuthUserFile Név- megadja a fájl nevét jelszavakkal. Általánosságban elmondható, hogy a létrehozásához az Apache disztribúcióból származó htpasswd segédprogramot kell használni. De legalábbis a szerver egyes verzióinál ez a formátum a következő:
user1: jelszóhash1
user2: jelszóhash2

A Passwordhash könnyen beszerezhető a szabványos Perl függvény segítségével:
$hash=crypt($passz,$só);
ahol $pass a jelszó, a $salt egy kétkarakteres karakterlánc, amely részt vesz a hash létrehozásában.

Így teljesen lehetséges automatizálni az új felhasználók hozzáadásának folyamatát, a jelszavak megváltoztatását html űrlapokon stb.

felhasználót igényel felhasználó1 felhasználó2és csoportot igényel felhasználó1 felhasználó2 lehetővé teszi annak megadását, hogy mely felhasználók és csoportok férhetnek hozzá egy adott könyvtárhoz.

A request valid-user lehetővé teszi a hozzáférést a rendszerjelszófájlban megadott összes felhasználóhoz.

... , ahol módszer én HTTP metódust határoz meg. Például a beágyazott nem irányelvek használatát a GET és a POST metódusok használatára korlátozza (általában ez több mint elegendő a beágyazott direktívák követelménye, sorrendje, engedélyezése és megtagadása).

Egy másik hasznos direktíva a tiltás és engedélyezés – a hozzáférés tiltása és engedélyezése.
tagadja meg mindenkitől
engedélyezni 192.168-tól

Alapértelmezés szerint először az összes megtagadás kerül végrehajtásra, majd az összes engedélyezés, tehát az engedélyezés minden felhasználó számára engedélyezi a hozzáférést minden felhasználó számára, függetlenül a megtagadásoktól. A sorrend az order utasítással módosítható: order enable, deny .

A deny from all jól megy az oldalak CGI-n keresztüli védelmének második módszerével, ez a direktíva a legjobb a vendégkönyvek stb. jelszavainak lefedésére. Amikor a címtárból próbál meg oldalakat elérni, a felhasználó üzenetet kap egy nem létező oldalról.

Mellesleg itt mellékesen bemutatják a független hibakezelést: ebben az esetben a 403-as kód, Tilos. Mindenki kedvenc 404 - Nem található és 401 - Jogosulatlan feldolgozása ugyanúgy történik. Ehhez adja hozzá az ErrorDocument direktívát a .htaccess fájlhoz url kód:
ErrorDocument 404 /cgi-bin/bad.pl
ErrorDocument 403 /cgi-bin/badaccess.pl
ErrorDocument 401 /cgi-bin/badaccess.pl

A szkript csak egy hibaüzenetet generál a REQUEST_URI környezeti változó használatával, így helyette csak egy megfelelő oldalra mutathat.

Az utolsó példában a következő tartalommal rendelkező .htaccess fájlt használjuk:

AuthType BasicAuthName TestAuthGroupFile /my/local/path/tgroupAuthUserFile /my/local/path/tuserrequire group test

Csak egy sor van a tgroup fájlban - teszt: bejelentkezési teszt, a felhasználói fájlban - titkosított jelszavak a bejelentkezéshez (jelszó) és a teszthez (teszt). Kérjük, vegye figyelembe, hogy amikor ismét belép erre az oldalra, a böngésző megérti, hogy most lépett be erre a területre, és nem zavarja a felhasználót felesleges jelszókéréssel.

Ez röviden a weboldalak védelméhez szükséges minimális információkészlet. A gyakorlat azt mutatja, hogy többé-kevésbé csak a szerver által biztosított eszközökön alapuló megoldásokban szabad megbízni (majd addig, amíg egy újabb lyukat nem fedeznek fel a szerveren), ezért lehetőség szerint érdemesebb ezeket választani.

Kedves Barátaim, Örülök, hogy ismét üdvözölhetlek benneteket a "" blogomon. Ma arról fogunk beszélni, hogyan állíthatunk be jelszót a WordPress webhely oldalán, itt minden nagyon egyszerű, de mire való? Ma megpróbálok válaszolni ezekre és más kérdésekre.

Miért kell jelszót tenni az oldalra?

Néha korlátozni kell a webhely bizonyos szakaszaihoz való hozzáférést, ezek a szakaszok tartalmazhatnak információkat a privilegizált felhasználók számára (gyakran gyakorolják), vagy a rejtett szakaszokhoz való hozzáférés fizetős lehet. A díjat akár egyszer, akár előfizetési díj formájában, például havonta egyszer lehet felszámítani. Így biztonságos weboldalt készíthet, és fizetős hozzáférést biztosíthat látogatóinak.

Manapság sok olyan ajánlat található az interneten, ahol azt javasolják, hogy vegyen részt egy fizetett képzésen vagy vásároljon tanfolyamot a webhelyek bevételszerzésének témájában, bizonyos oldalakhoz fizetős hozzáféréssel, de ne vásárolja meg őket. Valószínűleg semmi újat nem fog találni ott, de ebben a cikkben teljesen ingyenesen megtudhatja, hogyan állíthat be jelszót egy webhely oldalon, és hogyan módosíthatja azt.

Szerintem egyértelmű a fizetős hozzáféréssel való pénzkeresés elve: állítson be jelszót, fogadja el a fizetést, küldje el a hozzáférési jelszót. Ha ez előfizetési díj, akkor havonta egyszer változtassa meg a jelszót, vegye fel újra a fizetést, és küldjön új jelszót. Mindez automatizálható az e-autopay.com kiváló szolgáltatással, ez a szolgáltatás nagyon kényelmes a fizetések elfogadása és az elektronikus és fizikai áruk, PIN kódok stb. automatikus küldése szempontjából, mindent be lehet állítani egy kényelmes affiliate programba, I azt tanácsoljuk, hogy figyeljen, a szolgáltatást minden jól ismert információs üzletember használja, mint például Azamat Ushanov, Alexander Borisov és még sokan mások. Egyébként az e-autopay.com szolgáltatáson is implementálva van.

Most nézzük meg, hogyan állíthat be jelszót egy WordPress webhely oldalon. Ehhez természetesen először létre kell hoznunk a kívánt oldalt, majd át kell lépnünk a bejegyzés szerkesztéséhez, és a „Közzététel” fülre kattintva a „szerkesztés” linkre kell kattintanunk, lásd az ábrát.

Ekkor megjelenik a következő ablak, ahol kiválaszthatja a láthatóságot, nyilvános, privát vagy jelszóval védett, illetve a Főoldalon a legfelső oldalt is rögzítheti, de szükségünk van egy jelszóra, válassza ki a kívánt funkciót és állítson be jelszót oldalhoz, ahogy az alábbi ábrán is látható.

A fenti lépések után nincs más dolgod, mint a megfelelő időben közzétenni az oldalt. Ezzel az egyszerű módon jelszóval rendelkező oldalakat hozhat létre a blogjában, és ezáltal fizetős vagy korlátozott hozzáférést biztosít különféle információkhoz. Például az én blogomon egy ingyenes tanfolyamhoz korlátozott a hozzáférés, csak a tanfolyamra való feliratkozás után lehet belépni, az előfizetés aktiválása után egy hozzáférési jelszót küldenek az email címedre, minden nagyon egyszerű és minden automatikus. Amint látja, ebben nincs semmi bonyolult, beállíthat jelszavakat webhelye bármely oldalán és cikkében.

Most már tudja, hogyan kell jelszót elhelyezni egy oldalon vagy cikkben egy webhelyen. Remélem, hogy ezek az információk előnyöket és új ötleteket hoznak a webhelyén való bevételszerzéshez. Mint mindig, most is várom kérdéseit és megjegyzéseit ezzel a cikkel kapcsolatban.

Írj be egy jelszót az oldalra

Ez a cikk nem úgy tesz, mintha bármiféle kinyilatkoztatás lenne, mindez nyilvánvaló és széles körben ismert. Mivel azonban nemrégiben több kérdés is érkezett a weboldalakhoz való hozzáférés korlátozásával kapcsolatban, úgy döntöttem, hogy a válaszokat összegyűjtöm.

Tehát a feladatunk az, hogy beállítsunk egy jelszót egy bizonyos oldal eléréséhez. Kezdjük a védelem legprimitívebb módszerével – néhány soros JavaScripttel. A kód valami ilyesmi

Var pass = prompt("Adja meg a jelszót:", ""); if (pass == null) window.location = "rossz.html"; else if (pass.toLowerCase() == "jelszó") window.location = "ok.html"; else window.location = "bad..js"> alapvetően nem változtat semmit.

Magasabb szinten van egy hasonló rendszer Java-ban implementálva.

Az alábbiakban az egyszerűsített forráskód található.

Java.applet importálása*; import java.awt.*; import java.net.*; public class Jelszó kiterjeszti a kisalkalmazást ( TextField bejelentkezés, jelszó; String Login = "bejelentkezés"; String Jelszó = "Jelszó"; public Password() ( ) public void init() ( Panel panel = new Panel(); panel.setLayout(new GridLayout(2,2)); new Button("Ok")); nyilvános logikai művelet(Event evt, Object obj) ( if(evt.target instanceof Button) ( String s; if(login.getText().equals(Login) && password.getText()) .equals(Password)) ( s = "http://www.webclub.ru/materials/ pagepsw/ok. html"; ) else ( s = "http://www.webclub.ru/materials/pagepsw/bad .html"; ) try ( getAppletContext().showDocument (új URL(ek)); ) catch(e. kivétel) ( password.setText(e.toString()); ) return true; return false;

Ha ezt a kisalkalmazást belefoglalja egy oldalba, valami ehhez hasonlót kaphat:

Jelszó ellenőrzés

Lehet okosabbá tenni, minden felhasználónak külön oldalt készíteni, rákényszeríteni, hogy fájlból olvasson adatokat stb. Alapvető hátránya, hogy miután egy személy a keresett oldalra került, senki sem akadályozhatja meg, hogy megjegyezze ezt az URL-t, ezért ez egy egyszeri eszköz. Természetesen elrejtheti az oldalt egy keretben, hogy az URL ne jelenjen meg a címsorban, de megértheti, kitől származik ez a védelem. Az applet ismét teljes egészében az ügyfélhez kerül, és elvileg teljesen elérhető a kutatás számára.

A CGI használatán alapuló megoldásnak nincs utolsó hátránya. Egy egyszerű Perl-szkript valahogy így néz ki:

#!/usr/bin/perl használja a CGI-t qw(:standard); $query = új CGI; $ok = "ok.html"; $cím = "rossz.html"; $login = "bejelentkezés"; $password = "jelszó"; $l = $query->param("bejelentkezés"); $p = $query->param("jelszó"); if(($p eq $jelszó) && ($l eq $bejelentkezés)) ( $cím = $ok; ) print $query->redirect($cím);

Használati példa:

Jelszó ellenőrzés

Az első hátrány kezelésére dinamikusan létrehozhat egy új oldalt a valahol elrejtett oldal alapján, anélkül, hogy megadná az URL-t.

Módosított kód:

#!/usr/bin/perl használja a CGI-t qw(:standard); $query = új CGI; $ok = "ok.html"; $cím = "rossz.html"; $docroot = $ENV("DOCUMENT_ROOT"); $localpath = "/anyagok/pagepsw/"; $login = "bejelentkezés"; $password = "jelszó"; $l = $query->param("bejelentkezés"); $p = $query->param("jelszó"); if(($p eq $jelszó) && ($l eq $bejelentkezés)) ( $cím = $ok; ) print $query->header(); open(FL, $docroot.$localpath.$cím); while() ( # Itt menet közben is módosíthatod a html kódot # Miért? Hát, sosem tudod... :) print $_; )bezár(FL);

Használati példa:

Jelszó ellenőrzés

Amint láthatja, a fájl URL-címe már nem jelenik meg, bár SSI árán, ha valami hasonló volt jelen (ez azonban a kimenet során elkapható és manuálisan feldolgozható). De itt is megmarad az elméleti lehetőség az URL kitalálására, és nem szabad megfeledkezni arról, hogy az oldalakon található mindenféle kép rossz szolgálatot tehet - természetesen relatív útvonalak használatakor.

Végül, a hozzáférési jelszó beállításának legmegbízhatóbb módja a szervereszközök használata – végül is nem véletlenül tették meg az emberek. Kettőre koncentrálok: az Apache a legnépszerűbb, az IIS pedig szintén népszerű :)

Az IIS-szel minden nagyon egyszerű - a védelmet NTFS segítségével végzik, ami természetesen némileg korlátozza a nem szerver rendszergazdák képességeit. Az ötlet a következő: az IUSR_xxxx felhasználótól, akinek a fiókja alatt alapértelmezés szerint minden webhelylátogató dolgozik, megtagadják a hozzáférést a kívánt fájlhoz/könyvtárhoz. Ezt követően csak azok a felhasználók férhetnek hozzá ezekhez a fájlokhoz, akiknek ez kifejezetten meg van adva a Tulajdonságok->Biztonság menüpontban. Nyilvánvaló, hogy sokkal kényelmesebb csoportokba egyesíteni őket. Van itt néhány finomság. Először is, a megadott felhasználóknak meg kell adni a helyi bejelentkezési jogot (Szabályzat->Felhasználói jogok a Felhasználókezelőben) Másodszor, ha a WWW beállításainál nem választja ki az Alap hitelesítés (Szöveg törlése) WWW szolgáltatást, akkor csak az Internet Explorer felhasználók kerülnek be. engedélyezett "A.

Az Apache-ban minden kicsit másképp történik. A védelem címtárszinten van beállítva. A megfelelő direktívák az általános konfigurációs fájlban (a szakaszban) és a .htaccess fájlokban is elhelyezhetők. A direktívák készlete mindkét esetben ugyanaz, és a legtöbb ember számára, aki webhelyet/oldalt bérel valaki más szerverén, a második módszer sokkal relevánsabb. Tehát létrehoz egy .htaccess fájlt abban a könyvtárban, amelyhez korlátozni kívánja a hozzáférést, majd beilleszti a következő direktívákat (a főbbeket felsorolom):

AuthType vezérlés típusa- Általában az alapszintet használják.

AuthName Név- megadja annak a területnek a nevét, ahol a felhasználónevek és jelszavak érvényesek. Ez ugyanaz a név, amelyet a böngésző a jelszó párbeszédpanelen jelenít meg. Ha a különböző könyvtárakhoz egy ilyen nevet ad meg, megspórolhatja a felhasználóknak az extra jelszó megadásának idejét.

AuthGroupFile Név- megadja annak a fájlnak a nevét, amelyben a csoportok és tagjaik nevei vannak tárolva. A formátuma:
csoport1: tag1 tag2...
csoport2: tag3 tag4 ...

AuthUserFile Név- megadja a fájl nevét jelszavakkal. Általánosságban elmondható, hogy a létrehozásához az Apache disztribúcióból származó htpasswd segédprogramot kell használni. De legalábbis a szerver egyes verzióinál ez a formátum a következő:
user1: jelszóhash1
user2: jelszóhash2

A Passwordhash könnyen beszerezhető a szabványos Perl függvény segítségével:
$hash=crypt($passz,$só);
ahol $pass a jelszó, a $salt egy két karakterből álló karakterlánc, amely részt vesz a hash létrehozásában.

Így teljesen lehetséges automatizálni az új felhasználók hozzáadásának folyamatát, a jelszavak megváltoztatását html űrlapokon stb.

felhasználót igényel felhasználó1 felhasználó2és csoportot igényel felhasználó1 felhasználó2 lehetővé teszi annak megadását, hogy mely felhasználók és csoportok férhetnek hozzá egy adott könyvtárhoz.

A request valid-user lehetővé teszi a hozzáférést a rendszerjelszófájlban megadott összes felhasználóhoz.

... , ahol módszer én HTTP metódust határoz meg. Például a beágyazott direktívák használatát a GET és POST metódusok használatára korlátozza (általában ez több mint elég). Az irányelvek egymásba ágyazhatók: megkövetelik, elrendelheti, engedélyezheti és megtagadhatja.

További néhány hasznos direktíva a deny és az engedélyezés – a hozzáférés tiltása és engedélyezése. Alkalmazzon valami ilyesmit:
tagadja meg mindenkitől
engedélyezni 192.168-tól

Alapértelmezés szerint először az összes megtagadás kerül végrehajtásra, majd az összes engedélyezés, tehát az engedélyezés minden felhasználó számára engedélyezi a hozzáférést minden felhasználó számára, a megtagadástól függetlenül. A sorrend az order utasítással módosítható: order enable, deny.

A deny from all jól megy az oldalak CGI-n keresztüli védelmének második módszerével, ez a direktíva a legjobb a vendégkönyvek stb. jelszavainak lefedésére.

Mellesleg itt mellékesen bemutatják a független hibakezelést: ebben az esetben a 403-as kód, Tilos. A szeretett 404-es, a Nem található és a 401-es, az engedély nélküli feldolgozása hasonlóan történik. Ehhez adja hozzá az ErrorDocument direktívát a .htaccess fájlhoz url kód:
ErrorDocument 404 /cgi-bin/bad.pl
ErrorDocument 403 /cgi-bin/badaccess.pl
ErrorDocument 401 /cgi-bin/badaccess.pl

A szkript csak egy hibaüzenetet generál a REQUEST_URI környezeti változó használatával, így helyette csak egy megfelelő oldalra mutathat.

Az utolsó példában a következő tartalommal rendelkező .htaccess fájlt használjuk:

AuthType Basic AuthName teszt AuthGroupFile /.../pagepsw/deny/tgroup AuthUserFile /.../pagepsw/deny/tuser csoporttesztet igényel

Csak egy sor van a tgroup fájlban - teszt: bejelentkezési teszt, a felhasználói fájlban - titkosított jelszavak a bejelentkezéshez (jelszó) és a teszthez (teszt). Kérjük, vegye figyelembe, hogy amikor ismét belép erre az oldalra, a böngésző megérti, hogy most lépett be erre a területre, és nem zavarja a felhasználót felesleges jelszókéréssel.

Ez röviden a weboldalak védelméhez szükséges minimális információkészlet. A gyakorlat azt mutatja, hogy többé-kevésbé csak a szerver által biztosított eszközökön alapuló megoldásokban szabad megbízni (majd addig, amíg egy újabb lyukat nem fedeznek fel a szerveren), ezért lehetőség szerint érdemesebb ezeket választani.

A könyvtár vagy a fájlok jelszóval történő zárolásának egyszerű módjait tárgyaljuk. Hogyan engedélyezzük a felhasználót cookie-kon keresztül. Felhasználó azonosítása a PHP4-be épített munkamenet mechanizmuson keresztül.

Jelszó az oldalhoz. 1. rész Inkább elméleti.

Úgy döntöttem, leírom a webhely egy részének jelszóval való védelmének módjait. A téma valójában elég nagy, ezért most először a php+mysql jogosultságra korlátozom magam.

A legelső kérdés, ami általában felmerül, hogy hogyan lehet jelszóval zárni a könyvtárat az adminisztrációs szkriptekkel. Ebben az esetben nincs szükség sallangra – egy vagy több adminisztrátornak ugyanazok a jogai, és a személyiségek ritkán változnak. Ebben a helyzetben a legegyszerűbb a szabványos szerverengedélyezés használata – helyezze el a .htaccess és .htpasswd fájlokat, és írja be a szükséges paramétereket.

Két dolgot adok hozzá. Az első a .htpasswd fájl elhelyezése. Kísérletileg rájöttem, hogy ha például egy hibaüzenetet tartalmazó dokumentum elérési útja (ErrorDocument) a DocumentRoot rendszerváltozóhoz képest van írva. De a jelszófájl (UserFile) elérési útja a ServerRoothoz képest van írva. Ha jól értem, a .htpasswd nem helyezhető a ServerRoot fölé - a "../" nem érzékelhető. Mindez azért történik, hogy egy jelszavas fájlt például egy szinttel a webhely gyökérkönyvtára fölé helyezzen el, így a hálózatról egyáltalán nem lehet hozzáférni a fájlhoz.

A második az, hogy a szkript meg tudja találni, hogy ki nyitja meg és a jelszót: a $PHP_AUTH_USER és $PHP_AUTH_PW változókat.

Ennek a módszernek a fő hátránya, hogy a szerver nem tudja blokkolni a jelszókitalálást (többszöri sikertelen bejelentkezési kísérlet után a felhasználót egy-két óra várakozásra kérik, és ezalatt az IP-címéről érkező hívásokat figyelmen kívül hagyja). Ez le van írva az Apache hivatalos dokumentációjában.

Egy másik hátránya, hogy a fájlokat jelszóval kell átírni egy felhasználó törlésekor vagy új bevezetésekor. De ha ez ritkán történik meg, ez a módszer teljesen elegendő, és nem kell aggódnia az engedélyezési mechanizmus megírása miatt.

Az engedélyezés automatizálása

Ez nem csak a nagyszámú felhasználóval és nagy forgalmukkal végzett munka egyszerűsítése miatt szükséges. Ha további információkat kell megőrizni a felhasználókról, vagy a jogok rugalmas megkülönböztetésére van szüksége, jobb, ha a jogosultságot átviszi az adatbázisba.

Egy zárt terület minden oldala tartalmaz egy fájlt a következő kóddal:

$result = mysql_query(" SELECT * FROM személy WHERE login="". preg_replace("/[^\\w_-]/","",$PHP_AUTH_USER). "" AND pass="". md5($PHP_AUTH_PW) """); if (@mysql_num_rows($result)!=1) ( header("WWW-Authenticate: Basic realm=\"Felhasználói terület\""); header("HTTP/1.0 401 Unauthorized"); print("Bejelentkezés felhasználói terület része, meg kell adnia felhasználónevét és jelszavát."); exit(); ); $user_row = mysql_fetch_array($eredmény);

Az első sorban a betűk, számok, kötőjelek és aláhúzásjelek kivételével minden karakter törlődik a bejelentkezésből. A kapott sorok számát a rendszer ezután ellenőrzi, és csak akkor kap hozzáférést, ha az egy sor. Más esetekben a felhasználó egy ablakot lát a böngészőben, amely bejelentkezési név és jelszó megadására kéri. Ha a felhasználó sikeresen bejelentkezett, akkor a $user_row tömbben minden információ megtalálható róla.

Természetesen az általam felhozott példának számos jelentős hiányossága van. Ne írd át egy az egyben, nehogy áldozatul ess a jelszókitaláló kísérleteknek, mert
1. itt nincs védelem a szelekció ellen
2. Ha a felhasználói tábla nagy, a jelszó kitalálásakor a támadó nagy valószínűséggel túlterheli az adatbázist

A mai utolsó módszer pedig a titkosított adatok sütikben való tárolása.

A bejelentkezéshez van egy szkript, a többi olyan kódot tartalmaz, amivel csak egy zárt területen lehet folytatni a műveleteket - ha lejárnak a cookie-k, vagy kijelentkezik onnan, akkor vissza kell térni a bejelentkezési oldalra.

A bemeneti szkript ellenőrzi a bejelentkezést és a jelszót, és két cookie-t bocsát ki. Az elsőben - a bejelentkezés, a felhasználó azonnali azonosítása érdekében (az adatbázisban a bejelentkezési mező természetesen egyedi vagy akár kulcs). A második süti a bejelentkezési idő és a jelszó hash-jét tartalmazza (a teljes titoktartás érdekében ezekhez a sorokhoz hozzáadom az „Y” betűt - akkor szinte lehetetlen megtalálni a hash-t :).

Minden más program tartalmaz olyan kódot, amely a következőket teszi. Kérést intéz az adatbázishoz - kiválasztja a kapott bejelentkezési adatokat tartalmazó sort. Ebből a sorból veszi a „log_time” mezőt és a jelszót, és kivonatot készít belőlük, a fent leírtak szerint. Összehasonlítja azzal, amit kapott, és ha egyeznek, új hash cookie-t bocsát ki a jelszóból, az időből és az "Y" betűből, és lekérdezi az "UPDATE user SET log_time="..." WHERE login adatbázist. = "$cookie_login"".

If (isset($HTTP_COOKIE_VARS[$cookie_login]) && isset($HTTP_COOKIE_VARS[$cookie_code])) ( $bejelentkezés = $HTTP_COOKIE_VARS[$cookie_login]; $code = $HTTP_COOKIE_VARS[$cookie_ultque =s"qSELECT_ults] date_format(log_date,"%Y%m%d%H%i%s") as log_date1,pass,uid FROM user WHERE email="$bejelentkezés" AND log_date>"DATE_SUB(NOW(),INTERVAL 15 PERC)"" Ha :s", $log_time0); $aktuális_felhasználó = mysql_fetch_array($eredmény); if (md5($current_user["pass"].$current_user["log_date1"].$md5letter) == $kód) ( mysql_query("UPDATE felhasználó SET log_date="$log_time2" WHERE uid=".$current_user["uid"]); setcookie($cookie_code, md5($current_user["pass"].$log_time1.$md5letter), idő()+900, $site_útvonal); $auth = igaz else unset($current_user);

Itt megint nincs védelem a kiválasztás és a szerver elleni támadás ellen (egyébként itt az „Y” betű helyett a felhasználó IP-címét is beírhatjuk – így pl. egy irodaszomszéd ne tudjon fájlt venni cookie és jelentkezzen be a számítógépéről).

Jelszó az oldalhoz. 2. rész. Toborzás blokkolása

Amikor legutóbb közzétettem ezt a kérdést, ott helyben felrúgtak, mondván, hogy egy ilyen blokk kisiklathatja a szervert.

De először a visszapattanás elleni blokkolásról. Banalitások, de mégis. A tíz karakterből álló, latin betűket és számokat tartalmazó jelszó azt jelenti, hogy sok lehetőség van. Ha másodpercenként 1 000 000-szer kitalál egy jelszót, az több ezer évig tart. De mivel az ilyen zagyvaságokat nehéz megjegyezni, gyakran értelmes szavakból készítünk jelszavakat. Néhány évvel ezelőtt kiderült, hogy a legtöbb jelszó kitalálható egy 10 000 szavas szótár segítségével. Egy időben megjelent a hálózaton egy féreg (egy ilyen vírus), amely felmászott a Unix szerverekre, kihasználva azok biztonsági réseit, és a Unix rendszer helyesírási szótárát használva felvette a jelszavakat a kiváltságos felhasználók számára. Nem kellett semmit cipelni!

Minden felhasználó, amíg meg nem adta a helyes bejelentkezési nevet és jelszót, gonosz hackernek minősül. Mit tegyünk, ha a felhasználó valamit rosszul ír be?

• feledékenység (ehhez a tisztességes weboldalakon van egy „elfelejtett jelszó” űrlap, amely ugyanazt a jelszót küldi el a rendszerbeállításokban megadott e-mail címre)
• kényeztetés ("mert nem érdekel")
• jelszó kiválasztása szótár segítségével (a sikeres kiválasztás valószínűsége nagy, ezért be kell zárni, különösen, ha az oldal kereskedelmi jellegű)
• DoS támadás (a kiszolgáló túlterhelésének elkerülése érdekében minimálisra kell csökkentenie a szkript által végrehajtott műveleteket ebben az esetben)

  Sokáig gondolkodtam azon, hogyan tudnék túlterhelést okozni a szerveren, ha a védelmi mechanizmus fájlokon alapul. Könnyűnek bizonyult (az más kérdés, hogy mennyibe kerül). Tehát tegyük fel, hogy a szerver nem fogja tudni kezelni, ha a szkript másodpercenként 1000-szer megpróbálja megnyitni a fájlokat írásra, és adatokat írni hozzájuk. Mivel 5 sikertelen bejelentkezési kísérlet után a felhasználó azonnal megtagadja a hozzáférést (anélkül, hogy adatot írnának egy fájlba), meg kell találni 200 egyedi IP-t, ahonnan ötször lehet kapcsolatba lépni. Lehetséges. Felakasztunk egy html bannert öt címkével a banner görgetőbe:

  

  A felhasználó azonnal öt kérést küld a kiszolgálónak, és ötször ír a fájlba (egyes böngészőkben egyébként felugrik egy ablak a bejelentkezési név és a jelszó megadására). Öt ilyen képből készíthet egy HTML oldalt, és magát az oldalt iframe-en keresztül beillesztheti a meglátogatott oldalra (iframe-en keresztül - így a hivatkozó mező nem található. Nem valószínű, hogy egy ingyenes támogatási szolgáltatás A tárhely olyan dolgokkal fog foglalkozni, mint például a naplófájlok böngészése hivatkozók keresésére). Az általam felhozott példák természetesen messziről jöttek, de maga a tény, hogy ki lehet használni a rendszer ilyen hibáját, bebizonyosodott. Egyébként valami hasonló már történt.

  De akkor is megadom ezt a módszert - hiába írtam, vagy mi? Egyébként különösebb félelem nélkül használható korlátozott számú címhez (például egy cég helyi hálózatához), ha egy .htaccess fájlt helyez el a könyvtárban a következő tartalommal:

  Rendelés megtagadás, megtagadás engedélyezése az összes engedélyezéstől az xxx.xxx.xxx címről

  És itt a program kódja:

  $hibák = 0; $fn = "figyelmen kívül hagyja/". preg_replace("[^\d\.]", "", $REMOTE_CÍM. ".". $HTTP_FORWARDED_FOR); if (is_file($fn)) ( if (fájlidő($fn)< time()-3600) unlink($fn); else $errors = fread(fopen($fn, "r"), 2); }; if ($errors>5) ( print ("A hozzáférés zárva. Kérem, jöjjön vissza egy óra múlva."); kilépés(); );

  // itt jön létre a kapcsolat az adatbázis-kiszolgálóval. hogy ne érjen hiába, ha a felhasználót azonnal „megverik”.

  $result = mysql_query("SELECT * FROM user WHERE login="". preg_replace("/[^\w_\-]/", "", $PHP_AUTH_USER). "" AND pass="". md5($PHP_AUTH_PW) """); if (@mysql_num_rows($result)!=1) ( header("WWW-Authenticate: Basic realm=\"titkos terület\""); header("HTTP/1.0 401 Unauthorized"); print ("Engedélyezés szükséges") fwrite(fopen($fn, "w"), ++$errors()); $aktuális_felhasználó = mysql_fetch_array($eredmény); mysql_free_result($eredmény);

  Azonban bűn fájlokkal dolgozni, ha van adatbázis. Tréfa. Sikertelen engedélyezések esetén hozzon létre egy táblázatot:

  TÁBLÁZAT LÉTREHOZÁSA unauth (VARCHAR(64) felhasználónév NOT NULL, VARCHAR(64) NOT NULL átadás, ip VARCHAR(255), bejelentkezési idő TIMESTAMP)

  A fájlok elérése helyett az adatbázissal dolgozunk.

  $errors = @mysql_result(mysql_query("SELECT count(username) as false FROM unath WHERE bejelentkezési idő>DATE_SUB(NOW(),INTERVAL 1 HOUR) AND ip="$REMOTE_ADDR"),0); if (mysql_error()) die(mysql_error()); if ($errors>5) ( print ("A hozzáférés le van zárva. Gyere vissza egy óra múlva."); exit(); ); $result = mysql_query("SELECT * FROM user WHERE login="". preg_replace("/[^\w_\-]/", "", $PHP_AUTH_USER). "" AND pass="". md5($PHP_AUTH_PW) """); if (@mysql_num_rows($result)!=1) ( header("WWW-Authenticate: Basic realm=\"titkos terület\""); header("HTTP/1.0 401 Unauthorized"); print ("Engedélyezés szükséges") ; mysql_query("INSERT INTO unauth (felhasználónév, pass, ip) VALUES ("$PHP_AUTH_USER", "$PHP_AUTH_PW", "$REMOTE_ADDR $HTTP_X_FORWARDED_FOR")); $aktuális_felhasználó = mysql_fetch_array($eredmény); mysql_free_result($eredmény);

  Üzleti döntés, hogy tároljuk-e a régi rekordokat statisztikai célokra vagy sem. Ha valami, akkor törölhetők az alábbi kérés végrehajtásával az engedélyezés előtt:

  DELETE FROM unauth WHERE logintimeDATE_SUB(NOW(), INTERVAL 30 PERC)"); if (!mysql_error() && @mysql_num_rows($login_result)==1) ( /* Szerezzen be egy táblázatsort, és hozzon létre egy hash-t a szükséges mezőkből. */ $ aktuális_felhasználó = mysql_fetch_array($login_result); $hash_to_check = md5($current_user["passwd"]. "Y - hogy senki ne találja ki." $current_user == $HTTP_COOKIE_VARSHA ) ( $current_time = time(); /* Frissítse az utolsó bejelentkezési mezőt, és adjon ki egy új cookie-t */ mysql_query("UPDATE user SET last_log="". date("Y-m-d H:i:s", $current_time). " " WHERE login=". $login""); setcookie($COOKIE_HASH_NAME, md5(date("Y-m-d H:i:s", $current_time). "Y - hogy senki ne találja ki." $current_user["passwd") ]), $current_time + 1800 , $COOKIE_PATH ) else ( /* Ha a hash nem egyezik, a felhasználó a bejelentkezési oldalra kerül. */ header ("Hely: /login.php"); kilépés; ) elseif (!mysql_error() && @mysql_num_rows ($log_result)!=1) ( header("Hely: /login.php"); kijárat;

  ) else print (mysql_error()); természetesen"Igen, hogy senki ne találja ki"

  Érdemes külön változóra is szétválasztani, és jobb, ha e sor helyett a látogató IP-címét (vagy hibás betárcsázás esetén az IP-cím első két/három számjegyét) használjuk.

  Egyébként az IP-címről. Érdemes ellenőrizni, de nem a teljes címet, hanem csak a cím első két (127-nél kisebb számmal kezdődő ip esetén) vagy három (illetve 127-nél nagyobb) számát. Ezzel megkíméli a rossz és megszakadt betárcsázó felhasználóit attól, hogy a kapcsolat megszakadása után újra be kelljen jelentkezniük, ugyanakkor nem engedi meg a cookie-t ellopó támadó bejelentkezését. Természetesen nem fog tudni visszahívni és bejelentkezni egy másik szolgáltatón keresztül - a medence címe nem ugyanaz, de ez nem a mi problémánk ("ilyen időben otthon maradnak"). A cégen belüli jelszavak ellopása sem a mi problémánk. Megvédtük a kíváncsi elvtársakat és az írástudatlan hackereket, de nem tehetünk semmit az áldozatra telepíthető trójaiak és szippantókkal szemben.

  Itt ér véget a „harangok és sípok”. A védelmet nem lehet megbízhatóbbá tenni. Senki nem fog bemenni a hash cookie fájljába és felvenni. Egyszerűbb lenne egy szippantót elhelyezni a felhasználó és a webes felület közé, és ezzel megkeresni a jelszót. Telepíthetsz egy trójai programot, amely mindent megjegyez, amit a felhasználó beírt a billentyűzeten, de ez már nem a mi problémánk. A csatornalehallgatás elleni védelem érdekében SSL-kapcsolatokat vagy adattitkosítást kell használnia.

  Miért írtam megjegyzést a cookie-król? "Nem értem, miért kell sütiről írni, ha a PHP-nek vannak munkamenetei?!" Majd, hogy ne lapos kép legyen az olvasóknak a szemük előtt. Még nem mindenhol van a PHP 4-es verziója, és a 3-as verzió sem támogatott. Ráadásul a munkamenetek nem mindenhol szükségesek - ritka kivételektől eltekintve az engedélyezési algoritmus ellenőrzi a bejelentkezési/jelszó helyességét és a munkamenet adatainak helyességét, majd vagy visszaküldi a klienst a bejelentkezési oldalra, vagy vesz egy tömböt (vagy objektumot). ) a felhasználó adataival.

  Nem olyan gyakoriak azok az esetek, amikor munkamenetben kell dolgozni. Például a "Monopolist" játékomban azonnal elkezdtem használni a munkameneteket, mivel a felhasználó több játékot is játszhat, és ugyanaz az oldal ugyanabban a munkamenetben különböző adatokat tartalmazhat. Ott jobb, ha adatokat tárol az egyik játékhoz, amelyben a felhasználó részt vesz egy munkamenetben, és hozzon létre egy oldalt a játékok közötti váltáshoz.

  Általánosságban elmondható, hogy nem azt mondom, hogy az üléseket nem szabad használni. Szükséges, de mindennek megvan a maga helye. Három engedélyezési mód – a 401-es fejlécen ("birodalmon"), a cookie-k vagy a munkamenetek - alkalmazhatóságának kérdésére később visszatérek. Most beszéljünk az ülésekről.

  A PHP-ben a munkamenetek valójában nem hitelesítési módszerek (maga a koncepció hibás, de a fórumokon pontosan azt kérdezik, hogy „hogyan kell a felhasználót munkameneteken keresztül engedélyezni?”). A PHP-be épített felhasználói munkamenet-mechanizmus csak ezeket a felhasználókat azonosítja, ismét a szkript munkája.

  Nem árulok el sokat az ülések mechanizmusáról – már elhangzott. Ez a mechanizmus a legegyszerűbb (vagy inkább a leghibásabb) formájában a következőképpen működik: a rendszer egy session fájlt tart a szerveren, amely tartalmazza a változóit. A munkamenet indításakor a felhasználó egyedi azonosítót kap (általában cookie-n keresztül), más oldalak elérésekor pedig elküldi azt. Amikor elindítja a munkamenet mechanizmust a szkriptben, a php kezelő ellenőrzi, hogy létezik-e a bejövő munkamenet azonosítójának megfelelő fájl - ha létezik, akkor a szkript képes adatokat olvasni a fájlból, ha nem, akkor új munkamenet indul. és a fájl létrejön. Természetesen ennek a változónak a neve a php beállításokban van megadva.

  Most arról, hogy milyen funkciókat használunk.

  session_start() . Elindítja magát a munkamenet mechanizmust. A felhasználónak rendelkeznie kell egy változóval és egy megfelelő fájllal. Ha a fájl nem létezik, akkor létrejön, és a munkamenet elölről indul. Ha nincs sem fájl, sem változó, akkor a rendszer egy változót generál (például elküld egy sütit tartalmazó fejlécet), és létrehozza a fájlt.

  session_register(név1, név2, név3...) . Annak jelzése, hogy mely változókat kell megjegyezni a szkript végén lévő fájlban. Miután a felhasználó egy másik oldalra navigált, elindítható a munkamenet mechanizmus, és ennek a függvénynek a meghívása után elérhetővé válnak a változók.

  session_destroy() . Törli a munkamenet adatfájlt (cookie-k használatakor ezeket manuálisan kell törölni egy üres cookie beállításával: "setcookie(session_name())" ).

  session_set_cookie_params(élet, elérési út, domain) . Cookie-paraméterek beállítása munkamenet-azonosítóval (alapértelmezés szerint a cookie a szerver gyökérkönyvtárába van beállítva, és 0 másodpercig - a böngésző bezárásáig).

  Egyelőre ennyi. A foglalkozásokról részletesen külön lapszámok lesznek. Egyelőre leírom a munkamenetek segítségével történő engedélyezési és felhasználóazonosítási mechanizmust.

  Tehát három fájlunk van - bejelentkezés, ellenőrzés (auth) és kimenet (kijelentkezés).

  // kivágja az összes nem kívánt karaktert $login = preg_replace("/[^\w_\.\-]/", "", $HTTP_POST_VARS["bejelentkezés"]); $pass = trim($HTTP_POST_VARS["pass"]); // változók ellenőrzése if (strlen($login)==0 || strlen($pass)==0) $error = "Adja meg bejelentkezési nevét és jelszavát"; else ( // bejelentkezési név és jelszó ellenőrzése $user_result = mysql_query("SELECT * FROM user WHERE login="$login" AND pass="". md5($pass). """); /* ha hiba történt a adatbázis (például a felhasználó beszúrt egy hosszú változót a munkamenetbe, amit az adatbázis nem akart megemészteni) vagy több sor is kiderült, kirúgjuk a felhasználót */ if (mysql_error()) die(mysql_error()) ; elseif (@mysql_num_rows($user_result) != 1) $error = "Érvénytelen felhasználónév vagy jelszó." // ha minden rendben, válassza ki az adatokat, indítsa el a sessiont else ( $user = mysql_fetch_assoc($user_result); session_params_cookie_ (1800, "/") ($HTTP_POST_VARS["return"]) "); else header("Hely: /"); exit(); ); ); /* itt a felhasználó már nem jogosult, de küldhet cookie-t egy zárt munkamenetből. takarítsuk ki. */ if (isset($HTTP_COOKIE_VARS)) setcookie(session_name()); // ezután megrajzoljuk az alakzatot, ez nem érdekes.

  Ez a szkript egyben kezelő és adatbeviteli űrlap is. Amikor megkapja a bejelentkezési nevet és jelszót, feldolgozza azokat, és ha azok helyesek, leállítja a működését, és a felhasználót a kívánt oldalra küldi. Ha az adatok hibásak vagy hiányoznak, nyomtatványt rajzol.

  /* megöli a felhasználói változót, hogy az űrlap megrajzolása után ne lehessen postai kérésben adatokat küldeni. */ unset($user); // "session error" jelző - ha engedélyezve van, a munka leáll. $session_error = false; // ha nincs munkamenet azonosítójú cookie, emelje fel a jelzőt if (!isset($HTTP_COOKIE_VARS)) $session_error = true; // ha létezik, indítsa el a munkamenet mechanizmust, és regisztrálja a $user változót. else ( session_start(); session_register("user"); /* ha véletlenül nincs bejelentkezési név és jelszó a tömbben, akkor a munka is leáll ("nem tudunk semmit, átadtuk" */ if (!isset($user[" login"]) || !isset($user["pass"])) $session_error = true ); /* ha a felhasználónak eddig hősiesen sikerült elkerülnie a hibákat, akkor az adatbázison keresztül az ellenőrzés ugyanúgy történik, mint a bemenetnél. */ if (!$session_error) ( $check_result = mysql_query("SELECT uid FROM user WHERE login="($user)" AND pass="($user)""); if (mysql_error() || @mysql_num_rows( $felhasználói_eredmény) != 1) $session_error = igaz ); // ha valami hiba történt, akkor if ($session_error) ( // megsemmisíti a munkamenet adatait session_destroy(); // törli a cookie-t, ha volt ilyen if (!isset($HTTP_COOKIE_VARS)) setcookie(session_name()," " ,"/"); /* elküldi a felhasználót a bejelentkezésre, azzal a lehetőséggel, hogy visszatérjen a kért címre */ header("Hely: /login.php?return=$REQUEST_URI"); // munka leállítása exit() ; mysql_free_result($check_result);

  A felhasználó be van jelölve, és a $user tömbben - az összes adatot róla, például üdvözölheti a keresztnevével és a családnevével:

  If(isset($HTTP_COOKIE_VARS)) ( // elindítja a session mechanizmust session_start(); // törli a session_destroy() fájlt; // törli a cookie-t setcookie(session_name()); ); // kilépés az oldal fejlécéből ("Hely: /login.php");

  Néhány megjegyzés: ebben a példában a jelszóval védett rész a teljes szerver (például service.firm.ru), a könyvtár bezárásához ki kell javítani az elérési utakat. A Session_name() a PHPSESSID helyett, így az azonosító neve szabadon megváltoztatható. Egyébként egy fizikai szerveren különböző neveket adhatunk a munkamenet-azonosítóknak – csak tedd a .htaccess fájlt a kívánt részbe a php_value session.name "ABRACADABRA" sorral.

  
  
  
  

  Ha bármilyen más kérdése van, vagy valami nem világos, üdvözöljük oldalunkon

  Úgy döntöttem, leírom a webhely egy részének jelszóval való védelmének módjait. A téma valójában elég nagy, ezért most először a php+mysql jogosultságra korlátozom magam.

  A legelső kérdés, ami általában felmerül, hogy hogyan lehet jelszóval zárni a könyvtárat az adminisztrációs szkriptekkel. Ebben az esetben nincs szükség sallangra – egy vagy több adminisztrátornak ugyanazok a jogai, és a személyiségek ritkán változnak. Ebben a helyzetben a legegyszerűbb a szabványos szerverengedélyezés használata – helyezze el a .htaccess és .htpasswd fájlokat, és írja be a szükséges paramétereket. Sokat írtak már erről, úgyhogy nem mondok semmi különösebb újat.

  Két dolgot adok hozzá. Az első a .htpasswd fájl elhelyezése. Kísérletileg rájöttem, hogy ha például egy hibaüzenetet tartalmazó dokumentum elérési útja (ErrorDocument) a DocumentRoot rendszerváltozóhoz képest van írva. De a jelszófájl (UserFile) elérési útja a ServerRoothoz képest van írva. Ha jól értem, a .htpasswd nem helyezhető a ServerRoot fölé - a "../" nem érzékelhető. Mindez azért történik, hogy egy jelszavas fájlt például egy szinttel a webhely gyökérkönyvtára fölé helyezzen el, így a hálózatról egyáltalán nem lehet hozzáférni a fájlhoz.

  A második az, hogy a szkript meg tudja találni, hogy ki nyitja meg és a jelszót: a $PHP_AUTH_USER és $PHP_AUTH_PW változókat.

  Ennek a módszernek a fő hátránya, hogy a szerver nem tudja blokkolni a jelszókitalálást (többszöri sikertelen bejelentkezési kísérlet után a felhasználót egy-két óra várakozásra kérik, és ezalatt az IP-címéről érkező hívásokat figyelmen kívül hagyja). Ez le van írva az Apache hivatalos dokumentációjában.

  Egy másik hátránya, hogy a fájlokat jelszóval kell átírni egy felhasználó törlésekor vagy új bevezetésekor. De ha ez ritkán történik meg, ez a módszer teljesen elegendő, és nem kell aggódnia az engedélyezési mechanizmus megírása miatt.

  Az engedélyezés automatizálása

  Ez nem csak a nagyszámú felhasználóval és nagy forgalmukkal végzett munka egyszerűsítése miatt szükséges. Ha további információkat kell megőrizni a felhasználókról, vagy a jogok rugalmas megkülönböztetésére van szüksége, jobb, ha a jogosultságot átviszi az adatbázisba.

  Egy zárt terület minden oldala tartalmaz egy fájlt a következő kóddal:

  $result = mysql_query(" SELECT * FROM személy WHERE login="". preg_replace("/[^w_-]/","",$PHP_AUTH_USER). "" AND pass="". md5($PHP_AUTH_PW). " ""); if (@mysql_num_rows($result)!=1) ( header("WWW-Authenticate: Basic realm="Felhasználói terület""); header("HTTP/1.0 401 Unauthorized"); print("Bejelentkezés a felhasználói területre a webhelyen meg kell adnia felhasználónevét és jelszavát."); exit(); ); $user_row = mysql_fetch_array($eredmény);

  Az első sorban a betűk, számok, kötőjelek és aláhúzásjelek kivételével minden karakter törlődik a bejelentkezésből. A kapott sorok számát a rendszer ezután ellenőrzi, és csak akkor kap hozzáférést, ha az egy sor. Más esetekben a felhasználó egy ablakot lát a böngészőben, amely bejelentkezési név és jelszó megadására kéri. Ha a felhasználó sikeresen bejelentkezett, a $user_row tömbben minden információ megtalálható róla.

  Természetesen az általam felhozott példának számos jelentős hiányossága van. Ne írd át egy az egyben, nehogy áldozatul ess a jelszókitaláló kísérleteknek, mert
  1. itt nincs védelem a szelekció ellen
  2. Ha a felhasználói tábla nagy, a jelszó kitalálásakor a támadó nagy valószínűséggel túlterheli az adatbázist

  A mai utolsó módszer pedig a titkosított adatok sütikben való tárolása.

  A bejelentkezéshez van egy szkript, a többi olyan kódot tartalmaz, amivel csak egy zárt területen lehet folytatni a műveleteket - ha lejárnak a cookie-k, vagy kijelentkezik onnan, akkor vissza kell térni a bejelentkezési oldalra.

  A bemeneti szkript ellenőrzi a bejelentkezést és a jelszót, és két cookie-t bocsát ki. Az elsőben - a bejelentkezés, a felhasználó azonnali azonosítása érdekében (az adatbázisban a bejelentkezési mező természetesen egyedi vagy akár kulcs). A második süti a bejelentkezési idő és a jelszó hash-jét tartalmazza (a teljes titoktartás érdekében ezekhez a sorokhoz hozzáadom az „Y” betűt - akkor szinte lehetetlen megtalálni a hash-t :).

  Minden más program tartalmaz olyan kódot, amely a következőket teszi. Kérést intéz az adatbázishoz - kiválasztja a kapott bejelentkezési adatokat tartalmazó sort. Ebből a sorból veszi a „log_time” mezőt és a jelszót, és kivonatot készít belőlük, a fent leírtak szerint. Összehasonlítja azzal, amit kapott, és ha egyeznek, új hash cookie-t bocsát ki a jelszóból, az időből és az "Y" betűből, és lekérdezi az "UPDATE user SET log_time='..." WHERE login adatbázist. ='$ cookie_login'".

  if (isset($HTTP_COOKIE_VARS[$cookie_login]) && isset($HTTP_COOKIE_VARS[$cookie_code])) ( $bejelentkezés = $HTTP_COOKIE_VARS[$cookie_login]; $code = $HTTP_COOKIE_VARS[$cookie_ultque] date_format(log_date,"%Y%m%d%H%i%s") as log_date1,pass,uid FROM user WHERE email="$bejelentkezés" AND log_date>"DATE_SUB(NOW(),INTERVAL 15 PERC)"" Ha :s", $log_time0); $aktuális_felhasználó = mysql_fetch_array($eredmény); if (md5($current_user["pass"].$current_user["log_date1"].$md5letter) == $kód) ( mysql_query("UPDATE felhasználó SET log_date="$log_time2" WHERE uid=".$current_user["uid"]); setcookie($cookie_code, md5($current_user["pass"].$log_time1.$md5letter), idő()+900, $site_útvonal); $auth = igaz else unset($current_user);

  Itt megint nincs védelem a kiválasztás és a szerver elleni támadás ellen (egyébként itt az „Y” betű helyett a felhasználó IP-címét is beírhatjuk – így pl. egy irodaszomszéd ne tudjon fájlt venni cookie és jelentkezzen be a számítógépéről).

  Jelszó az oldalhoz. 2. rész. Toborzás blokkolása

  Amikor legutóbb közzétettem ezt a kérdést, ott helyben felrúgtak, mondván, hogy egy ilyen blokk kisiklathatja a szervert.

  De először a visszapattanás elleni blokkolásról. Banalitások, de mégis. A tíz karakterből álló, latin betűket és számokat tartalmazó jelszó azt jelenti, hogy sok lehetőség van. Ha másodpercenként 1 000 000-szer kitalál egy jelszót, az több ezer évig tart. De mivel nehéz megjegyezni az ilyen zagyvaságokat, gyakran értelmes szavakból készítünk jelszavakat. Néhány évvel ezelőtt kiderült, hogy a legtöbb jelszó kitalálható egy 10 000 szavas szótár segítségével. Egy időben megjelent a hálózaton egy féreg (egy ilyen vírus), amely felmászott a Unix szerverekre, kihasználva azok biztonsági réseit, és a Unix rendszer helyesírási szótárát használva felvette a jelszavakat a kiváltságos felhasználók számára. Nem kellett semmit cipelni!

  Minden felhasználó, amíg meg nem adta a helyes bejelentkezési nevet és jelszót, gonosz hackernek minősül. Mit tegyünk, ha a felhasználó valamit rosszul ír be?
  feledékenység (ehhez a tisztességes weboldalakon van egy „elfelejtett jelszó” űrlap, amely ugyanazt a jelszót küldi el a rendszerbeállításokban megadott e-mail címre)
  kényeztetés ("mert nem érdekel")
  jelszó kiválasztása szótár segítségével (a sikeres kiválasztás valószínűsége nagy, ezért be kell zárni, különösen, ha az oldal kereskedelmi jellegű)
  DoS támadás (a kiszolgáló túlterhelésének elkerülése érdekében minimálisra kell csökkentenie a szkript által végrehajtott műveleteket ebben az esetben)

  Sokáig gondolkodtam azon, hogyan tudnék túlterhelést okozni a szerveren, ha a védelmi mechanizmus fájlokon alapul. Könnyűnek bizonyult (az más kérdés, hogy mennyibe kerül). Tehát tegyük fel, hogy a szerver nem fogja tudni kezelni, ha a szkript másodpercenként 1000-szer megpróbálja megnyitni a fájlokat írásra, és adatokat írni hozzájuk. Mivel 5 sikertelen bejelentkezési kísérlet után a felhasználó azonnal megtagadja a hozzáférést (anélkül, hogy adatot írnának egy fájlba), meg kell találni 200 egyedi IP-t, ahonnan ötször lehet kapcsolatba lépni. Lehetséges. Felakasztunk egy html bannert öt címkével a banner görgetőbe:

  

  A felhasználó azonnal öt kérést küld a kiszolgálónak, és ötször ír a fájlba (egyes böngészőkben egyébként felugrik egy ablak a bejelentkezési név és a jelszó megadására). Öt ilyen képből készíthet egy HTML oldalt, és magát az oldalt iframe-en keresztül beillesztheti a meglátogatott oldalra (iframe-en keresztül - így a hivatkozó mező nem található. Nem valószínű, hogy egy ingyenes támogatási szolgáltatás A tárhely olyan dolgokkal fog foglalkozni, mint például a naplófájlok böngészése hivatkozók keresésére). Az általam felhozott példák természetesen messziről jöttek, de maga a tény, hogy ki lehet használni a rendszer ilyen hibáját, bebizonyosodott. Egyébként valami hasonló már történt.

  De akkor is megadom neked ezt a módszert - hiába írtam, vagy mi? Egyébként különösebb félelem nélkül használható korlátozott számú címhez (például egy cég helyi hálózatához), ha egy .htaccess fájlt helyez el a könyvtárban a következő tartalommal:

  parancs megtagadása, engedélyezése
  tagadja meg mindenkitől
  engedélyezése a következőről: xxx.xxx.xxx

  És itt a program kódja:

  $hibák = 0; $fn = "figyelmen kívül hagyja/". preg_replace("[^d.]", "", $REMOTE_ADDR. ".". $HTTP_FORWARDED_FOR); if (is_file($fn)) ( if (fájlidő($fn)< time()-3600) unlink($fn); else $errors = fread(fopen($fn, "r"), 2); }; if ($errors>5) ( print ("A hozzáférés zárva. Kérem, jöjjön vissza egy óra múlva."); kilépés(); ); // itt jön létre a kapcsolat az adatbázis-kiszolgálóval. hogy ne érjen hiába, ha a felhasználót azonnal „megverik”. $result = mysql_query("SELECT * FROM user WHERE login="". preg_replace("/[^w_-]/", "", $PHP_AUTH_USER). "" AND pass="". md5($PHP_AUTH_PW). " ""); if (@mysql_num_rows($result)!=1) ( header("WWW-Authenticate: Basic realm="titkos terület""); header("HTTP/1.0 401 Unauthorized"); print ("Engedélyezés szükséges"); fwrite (fopen($fn, "w"), ++$errors); $aktuális_felhasználó = mysql_fetch_array($eredmény); mysql_free_result($eredmény); Azonban bűn fájlokkal dolgozni, ha van adatbázis. Tréfa. Sikertelen jogosultságokhoz táblát készítünk: CREATE TABLE unauth (VARCHAR(64) NOT NULL felhasználónév, VARCHAR(64) NOT NULL átadás, ip VARCHAR(255), bejelentkezési idő TIMESTAMP) És a fájlok elérése helyett az adatbázissal dolgozunk. $errors = @mysql_result(mysql_query("SELECT count(username) as false FROM unath WHERE bejelentkezési idő>DATE_SUB(NOW(),INTERVAL 1 HOUR) AND ip="$REMOTE_ADDR"),0); if (mysql_error()) die(mysql_error()); if ($errors>5) ( print ("A hozzáférés le van zárva. Gyere vissza egy óra múlva."); exit(); ); $result = mysql_query("SELECT * FROM user WHERE login="". preg_replace("/[^w_-]/", "", $PHP_AUTH_USER). "" AND pass="". md5($PHP_AUTH_PW). " ""); if (@mysql_num_rows($result)!=1) ( header("WWW-Authenticate: Basic realm="titkos terület""); header("HTTP/1.0 401 Unauthorized"); print ("Engedélyezés szükséges"); mysql_query ("INSERT INTO unauth (felhasználónév, belépő, ip) ÉRTÉKEK ("$PHP_AUTH_USER", "$PHP_AUTH_PW", "$REMOTE_ADDR $HTTP_X_FORWARDED_FOR")); $aktuális_felhasználó = mysql_fetch_array($eredmény); mysql_free_result($eredmény);

  Üzleti döntés, hogy tároljuk-e a régi rekordokat statisztikai célokra vagy sem. Ha valami, akkor törölhetők az alábbi kérés végrehajtásával az engedélyezés előtt:

  DELETE FROM unauth WHERE bejelentkezési idő