Protecție prin parolă. Setarea unei parole pentru pagină Script parola pentru pagină

Pune o parolă pe pagină

Acest articol nu pretinde a fi nicio revelație; toate aceste lucruri sunt destul de evidente și cunoscute pe scară largă. Dar după ce am primit recent mai multe întrebări despre restricționarea accesului la paginile web, am decis să aduc răspunsurile la acestea împreună.

Deci, sarcina noastră este să setăm o parolă pentru a accesa o anumită pagină. Să începem cu cea mai primitivă metodă, ca să spunem așa, de protecție - câteva linii de JavaScript

Var pass = prompt("Introduceți parola:", ""); if (pass == null) window.location = "bad.html"; else if (pass.toLowerCase() == „parolă”) window.location = „ok.html”; else window.location = "bad..js"> ele nu schimbă nimic fundamental.

La un nivel superior există un sistem similar implementat în Java.

Mai jos este codul sursă simplificat.

Import java.applet.*; import java.awt.*; import java.net.*; public class Parola extinde Applet ( autentificare TextField, parolă; String Login = „login”; String Password = „Parolă”; public Password() ( ) public void init() ( Panel panel = new Panel(); panel.setLayout(new GridLayout(2,2)); login = new TextField(20); Button nou(„Ok”); acțiune booleană publică (Event evt, Object obj) ( if(evt.target instanceof Button) ( String s; if(login.getText().equals(Login) && password.getText() .equals(Parola)) ( s = "http://www.webclub.ru/materials/ pagepsw/ok. html"; ) else ( s = "http://www.webclub.ru/materials/pagepsw/bad .html"; ) încercați ( getAppletContext().showDocument (adrese URL noi); ) catch(Excepție e) ( password.setText(e.toString()); ) return true; return false;

Incluzând acest applet într-o pagină, puteți obține ceva de genul acesta:

Verificarea parolei

Poate fi făcut mai inteligent, creați o pagină separată pentru fiecare utilizator, forțați-l să citească datele dintr-un fișier etc. Dezavantajul fundamental este că, odată ce o persoană a ajuns pe pagina pe care o caută, nimeni nu o poate împiedica să-și amintească această adresă URL, așa că acesta este un instrument de unică folosință. Desigur, puteți ascunde pagina într-un cadru, astfel încât adresa URL să nu apară în bara de adrese, dar înțelegeți de la cine este această protecție. Din nou, appletul merge în întregime către client și este, în principiu, complet disponibil pentru cercetare.

Soluția bazată pe utilizarea CGI nu are ultimul dezavantaj. Un script Perl simplu arată cam așa:

#!/usr/bin/perl folosește CGI qw(:standard); $interogare = CGI nou; $ok = "ok.html"; $address = "bad.html"; $login = "autentificare"; $parolă = „parolă”; $l = $interogare->param("login"); $p = $interogare->param("parola"); if(($p eq $parola) && ($l eq $login)) ( $adresa = $ok; ) print $interogare->redirect($adresa);

Exemplu de utilizare:

Verificarea parolei

Pentru a face față primului dezavantaj, puteți genera dinamic o nouă pagină pe baza celei ascunse undeva în interior, fără a furniza adresa URL.

Cod modificat:

#!/usr/bin/perl folosește CGI qw(:standard); $interogare = CGI nou; $ok = "ok.html"; $address = "bad.html"; $docroot = $ENV("DOCUMENT_ROOT"); $localpath = "/materiale/pagepsw/"; $login = "autentificare"; $parolă = „parolă”; $l = $interogare->param("login"); $p = $interogare->param("parola"); if(($p eq $parolă) && ($l eq $login)) ( $adresă = $ok; ) print $interogare->header(); deschide(FL, $docroot.$localpath.$adresa); in timp ce( ) ( # Aici puteți modifica și codul html din mers # De ce? Ei bine, nu se știe niciodată... :) print $_; )close(FL);

Exemplu de utilizare:

Verificarea parolei

După cum puteți vedea, URL-ul fișierului nu mai este afișat, deși cu prețul SSI, dacă ceva similar a fost prezent (cu toate acestea, acesta poate fi prins în timpul ieșirii și procesat manual). Dar și aici rămâne posibilitatea teoretică de a ghici URL-ul și nu trebuie să uităm că tot felul de imagini incluse în pagini pot face un deserviciu - atunci când se folosesc căi relative, desigur.

În cele din urmă, cea mai fiabilă modalitate de a seta o parolă de acces este utilizarea instrumentelor de server - nu degeaba oamenii le-au făcut, până la urmă. Mă voi concentra pe două - Apache ca cel mai popular și IIS ca și popular :)

Cu IIS totul este destul de simplu - protecția se realizează folosind NTFS, care, desigur, limitează oarecum capacitățile administratorilor non-server. Ideea este următoarea: utilizatorului IUSR_xxxx, sub contul căruia lucrează implicit toți vizitatorii site-ului, i se interzice accesul la fișierul/directorul dorit. După aceea, numai acei utilizatori pentru care acest lucru este specificat în mod explicit în Proprietăți->Securitate vor avea acces la aceste fișiere. Este clar că este mult mai convenabil să le combinați în grupuri. Există câteva subtilități aici.

În primul rând, utilizatorilor specificați trebuie să li se acorde dreptul de conectare la nivel local (Politici->Drepturi utilizator în User Manager). În al doilea rând, dacă nu selectați serviciul WWW Autentificare de bază (Clear Text) în setările WWW, vor fi doar utilizatorii Internet Explorer. permis în „A. În Apache, totul se face puțin diferit. Protecția este setată la nivel de director. Directivele corespunzătoare pot fi plasate fie în fișierul de configurare generală (în secțiunea

), și în fișierele .htaccess. Setul de directive în ambele cazuri este același, iar pentru majoritatea oamenilor care închiriază spațiu pentru un site web/pagină pe serverul altcuiva, a doua metodă este mult mai relevantă. Deci, creați un fișier .htaccess în directorul la care intenționați să restricționați accesul și apoi introduceți următoarele directive în el (le voi enumera pe cele principale): AuthType

tip de control - De obicei este folosit de bază. AuthName

Nume - De obicei este folosit de bază.- specifică numele zonei în care sunt valabile numele de utilizator și parolele. Acesta este același nume pe care îl arată browserul în dialogul pentru parolă. Setând un astfel de nume pentru diferite directoare, puteți economisi utilizatorilor timpul necesar introducerii unei parole suplimentare.
AuthGroupFile
- specifică numele fișierului în care sunt stocate numele grupurilor și membrii acestora. Formatul său:

grup1: membru1 membru2... - De obicei este folosit de bază. grupa 2: membru 3 membru 4 ...
AuthUserFile - specifică numele fișierului cu parole. În general, pentru a-l crea trebuie să utilizați utilitarul htpasswd din distribuția Apache. Dar cel puțin pentru unele versiuni ale serverului, acest format este astfel:
utilizator1: passwordhash1

utilizator 2:
passwordhash2
Passwordhash poate fi obținut cu ușurință folosind funcția standard Perl:

$hash=cripta($trece,$sare);

unde $pass este parola, $salt este un șir de două caractere implicat în generarea hash-ului. Deci este destul de posibil să automatizezi procesul de adăugare de noi utilizatori, schimbarea parolelor prin formulare html etc. necesită utilizator utilizator1 utilizator2 Deci este destul de posibil să automatizezi procesul de adăugare de noi utilizatori, schimbarea parolelor prin formulare html etc.Şi

necesită grup permite accesul tuturor utilizatorilor specificati în fișierul cu parole de sistem.

... , unde metoda i definește o metodă HTTP. De exemplu,

limitează utilizarea directivelor imbricate la cazurile de utilizare a metodelor GET și POST (de obicei, acest lucru este mai mult decât suficient). Directivele pot fi imbricate: cere, ordona, permite și refuza.
Alte două directive utile sunt deny și allow - denying și, respectiv, allowing access. Aplica ceva de genul asta:
nega de la toti

permite de la 192.168

În mod implicit, toate deny sunt executate mai întâi, apoi all allow, deci allow from all va permite accesul tuturor utilizatorilor, indiferent de orice refuz. Ordinul poate fi schimbat cu directiva de comandă: order allow, deny.

deny from all merge bine cu a doua metodă de protejare a paginilor prin CGI, această directivă este cea mai bună pentru a acoperi tot felul de parole pentru cărțile de oaspeți etc. Apropo, aici, în treacăt, este demonstrată gestionarea independentă a erorilor: în acest caz, codul 403, Interzis. Îndrăgitele 404, Not Found și 401, Unauthorized sunt procesate în mod similar. Pentru a face acest lucru, trebuie doar să adăugați directiva la .htaccess ErrorDocument:
codul URL
ErrorDocument 404 /cgi-bin/bad.pl
ErrorDocument 403 /cgi-bin/badaccess.pl

ErrorDocument 401 /cgi-bin/badaccess.pl

Tot ceea ce face scriptul este să genereze un mesaj de eroare folosind variabila de mediu REQUEST_URI, astfel încât să puteți indica în schimb o pagină potrivită.

Pentru exemplul final, folosim un fișier .htaccess cu următorul conținut: AuthType Basic AuthName Test AuthGroupFile /.../pagepsw/deny/tgroup AuthUserFile /.../pagepsw/deny/tuser

necesită un test de grup Există o singură linie în fișierul tgroup - test: test de conectare

, în fișierul tuser - parole criptate pentru autentificare (parolă) și testare (test).

Vă rugăm să rețineți că atunci când accesați din nou această pagină, browserul înțelege că tocmai a accesat această zonă și nu deranjează utilizatorul cu o solicitare inutilă a parolei.

Acesta este, pe scurt, setul minim de informații necesare pentru a proteja paginile web. După cum arată practica, ar trebui să aveți mai mult sau mai puțin încredere doar în soluțiile bazate pe instrumentele furnizate de server (și apoi până când se descoperă o altă gaură în server), așa că, dacă este posibil, este mai bine să le alegeți.

Am decis să descriu modalități de a proteja o parte a site-ului cu o parolă. Subiectul este de fapt destul de amplu, așa că pentru prima dată mă voi limita la autorizarea php+mysql.

Prima întrebare care apare de obicei este cum să închideți directorul cu scripturi de administrare cu o parolă. În acest caz, nu sunt necesare bibelouri - unul sau mai mulți administratori au aceleași drepturi, iar personalitățile se schimbă rar. Cel mai simplu mod în această situație este să folosiți autorizarea standard de server - puneți fișierele .htaccess și .htpasswd și scrieți parametrii necesari în ele.

Voi adăuga două lucruri. Primul este unde să puneți fișierul .htpasswd. Experimental, am aflat că dacă, de exemplu, calea către un document cu un mesaj de eroare (ErrorDocument) este scrisă relativ la variabila de sistem DocumentRoot. Dar calea către fișierul cu parole (UserFile) este scrisă relativ la ServerRoot. Din câte am înțeles, nu puteți pune .htpasswd deasupra ServerRoot - „../” nu este perceput. Toate acestea se fac astfel încât să puteți plasa un fișier cu parole, de exemplu, la un nivel deasupra directorului rădăcină al site-ului, astfel încât să nu existe deloc acces la fișierul din rețea.

Al doilea este că scriptul poate afla cine îl deschide și parola: variabilele $PHP_AUTH_USER și $PHP_AUTH_PW.

Principalul dezavantaj al acestei metode este că serverul nu poate bloca ghicirea parolei (după mai multe încercări de conectare nereușite, utilizatorului i se cere să aștepte o oră sau două, iar în acest timp apelurile de la adresa sa IP sunt ignorate). Aceasta este scrisă în documentație oficială conform lui Apache.

Un alt dezavantaj este necesitatea de a rescrie fișierele cu parole atunci când ștergeți un utilizator sau introduceți unul nou. Dar dacă acest lucru se întâmplă rar, această metodă este destul de suficientă și nu va trebui să vă faceți griji pentru a scrie un mecanism de autorizare.

Automatizarea autorizarii

Acest lucru este necesar nu numai pentru a simplifica munca cu un număr mare de utilizatori și cifra de afaceri ridicată a acestora. Dacă aveți nevoie să păstrați informații suplimentare despre utilizatori sau aveți nevoie de o diferențiere flexibilă a drepturilor, este mai bine să transferați autorizația în baza de date.

Fiecare pagină a unui teritoriu închis include un fișier cu următorul cod:

$rezultat = mysql_query(" SELECT * FROM person WHERE login="". preg_replace("/[^\\w_-]/","",$PHP_AUTH_USER). "" AND pass="". md5($PHP_AUTH_PW) . """); if (@mysql_num_rows($rezultat)!=1) ( header("WWW-Authenticate: Basic realm=\"Zona utilizator\""); header("HTTP/1.0 401 Neautorizat"); print("Pentru a vă conecta la domeniul utilizatorilor parte a site-ului, trebuie să introduceți un nume și o parolă."); exit(); ); $rând_utilizator = mysql_fetch_array($rezultat);

În prima linie, toate caracterele, cu excepția literelor, numerelor, liniuțelor și liniuțelor de subliniere sunt eliminate din autentificare. Numărul de rânduri primite este apoi verificat și numai dacă este un rând este acordat accesul. În alte cazuri, utilizatorul va vedea o fereastră în browser care vă va cere să introduceți o autentificare și o parolă. Dacă utilizatorul s-a autentificat cu succes, avem toate informațiile despre el în matricea $user_row.

Desigur, exemplul pe care l-am dat are o serie de neajunsuri semnificative. Nu o rescrieți unul la unu, pentru a nu fi victima încercărilor de ghicire a parolei, deoarece
1. nu există nicio protecție împotriva selecției aici
2. dacă tabelul de utilizatori este mare, atunci când ghicește parola, cel mai probabil un atacator va copleși baza de date

Și ultima metodă pentru astăzi este stocarea datelor criptate în cookie-uri.

Există un script pentru autentificare, restul includ un cod care doar permite continua acțiuni într-o zonă închisă - dacă cookie-urile expiră sau se deconectează, va trebui să revină la pagina de autentificare.

Scriptul de intrare verifică autentificarea și parola și emite două cookie-uri.

În primul - autentificarea, pentru a identifica imediat utilizatorul (în baza de date, câmpul de autentificare este, desigur, unic sau chiar cheie).

If (isset($HTTP_COOKIE_VARS[$cookie_login]) && isset($HTTP_COOKIE_VARS[$cookie_code])) ( $login = $HTTP_COOKIE_VARS[$cookie_login]; $code = $HTTP_COOKIE_VARS[$cookie_codul_SELECT]; date_format(log_date,"%Y%m%d%H%i%s") ca log_date1,pass,uid FROM user WHERE email="$login" AND log_date>"DATE_SUB(NOW(),INTERVAL 15 MINUTE)"" ); if (!mysql_error() && @mysql_num_rows($rezultat)==1) ( $log_time0 = time(); $log_time1 = data("YmdHis", $log_time0); $log_time2 = data("Y-m-d H:i :s", $log_time0); $current_user = mysql_fetch_array($result); if (md5($current_user["pass"].$current_user["log_date1"].$md5letter) == $cod) ( mysql_query("UPDATE") user SET log_date="$log_time2" WHERE uid=".$current_user["uid"]); setcookie($cookie_code, md5($current_user["pass"].$log_time1.$md5letter), time()+900, $site_path); $auth = true;

Din nou, aici nu există protecție împotriva selecției și atacurilor asupra serverului (apropo, aici puteți scrie adresa IP a utilizatorului în loc de litera „Y” - astfel încât, de exemplu, un vecin de birou să nu poată lua un fișier cu un cookie și conectați-vă de pe computerul său).

Parola pentru pagina. Partea 2. Blocarea recrutării

Când am postat această problemă data trecută, m-au lovit pe loc, spunând că un astfel de bloc ar putea deraia serverul.

Dar mai întâi, despre blocarea rebound. Banalități, dar totuși.

O parolă de zece caractere constând din litere și cifre latine înseamnă că există o mulțime de opțiuni. Dacă ghiciți o parolă de 1.000.000 de ori pe secundă, va dura câteva mii de ani. Dar, deoarece un astfel de gobbledygook este greu de reținut, adesea facem parole din cuvinte semnificative. În urmă cu câțiva ani, s-a dovedit că majoritatea parolelor pot fi ghicite folosind un dicționar de 10.000 de cuvinte. La un moment dat, în rețea a apărut un vierme (un virus de genul ăsta), care a urcat pe serverele Unix, folosindu-și găurile de securitate și a preluat parole pentru utilizatorii privilegiați folosind... dicționarul de ortografie a sistemului Unix. Nu era nevoie să cărați nimic!

• Fiecare utilizator, până când a introdus datele de conectare și parola corecte, este considerat un hacker rău. Cu ce ​​ne ocupăm atunci când utilizatorul introduce ceva incorect?
• uitare (pentru aceasta, site-urile web decente au un formular de „parolă uitată” pentru a trimite aceeași parolă la adresa de e-mail introdusă în setările sistemului)
• răsfăț („pentru că nu-mi pasă”)
• Atac DoS (pentru a nu supraîncărca serverul, trebuie să minimizați acțiunile pe care le va efectua scriptul în acest caz)

  M-am gândit mult timp la modul în care aș putea provoca o supraîncărcare pe server dacă mecanismul de protecție se bazează pe fișiere. S-a dovedit a fi ușor (cât va costa este o altă întrebare). Deci, să presupunem că serverul nu va putea să se ocupe de asta dacă scriptul încearcă să deschidă fișiere pentru a le scrie de 1000 de ori pe secundă și să le scrie date.

  

  Deoarece după 5 încercări nereușite de autentificare, utilizatorului i se va refuza imediat accesul (fără să fie scrise date într-un fișier), trebuie să găsiți 200 de IP-uri unice, de la care trebuie să contactați de cinci ori fiecare. Este posibil. Agățăm un banner html cu cinci etichete în scrollerul bannerului:

  Utilizatorul face instantaneu cinci solicitări, serverul scrie în fișier de cinci ori (apropo, în unele browsere, poate apărea o fereastră pentru introducerea numelui de utilizator și a parolei). Puteți face o pagină HTML cu cinci astfel de imagini și puteți introduce pagina în sine printr-un iframe pe site-ul pe care îl vizitați (prin un iframe - astfel încât câmpul de referință să nu fie găsit. Este puțin probabil ca serviciul de asistență al unui găzduirea se va ocupa de lucruri cum ar fi săparea prin fișierele jurnal în căutarea referrerilor). Exemplele pe care le-am dat sunt, desigur, exagerate, dar chiar faptul că se poate profita de un astfel de defect al sistemului a fost dovedit. Apropo, ceva asemănător s-a întâmplat deja.

  Dar tot voi da această metodă - am scris-o degeaba sau ce? Apropo, poate fi folosit fără prea multă teamă pentru un număr limitat de adrese (de exemplu, pentru rețeaua locală a unei companii) prin plasarea unui fișier .htaccess în directorul cu următorul conținut:

  Comanda refuzată, permite refuzul de la toate permise de la xxx.xxx.xxx

  Și aici este codul programului:< time()-3600) unlink($fn); else $errors = fread(fopen($fn, "r"), 2); }; if ($errors>$erori = 0; $fn = „ignora/”. preg_replace("[^\d\.]", "", $REMOTE_ADDR. ".". $HTTP_FORWARDED_FOR); if (este_fișier($fn)) ( dacă (filecttime($fn))

  5) ( print ("Accesul este închis. Vă rugăm să reveniți peste o oră."); ieșire(); );

  // aici se stabilește conexiunea cu serverul de baze de date. pentru a nu atinge degeaba dacă utilizatorul este imediat „bătut”.

  $rezultat = mysql_query("SELECT * FROM user WHERE login="". preg_replace("/[^\w_\-]/", "", $PHP_AUTH_USER). "" AND pass="". md5($PHP_AUTH_PW) . """); if (@mysql_num_rows($rezultat)!=1) ( header("WWW-Authenticate: Basic realm=\"zonă secretă\""); header("HTTP/1.0 401 Neautorizat"); imprimare ("Este necesară autorizarea") ; fwrite(fopen($fn, "w"), ++$erori); $current_user = mysql_fetch_array($rezultat); mysql_free_result($rezultat);

  CREATE TABLE unauth (nume de utilizator VARCHAR(64) NOT NULL, trece VARCHAR(64) NOT NULL, ip VARCHAR(255), TIMESTAMP de conectare)

  Și în loc să accesăm fișiere, lucrăm cu baza de date.

  $errors = @mysql_result(mysql_query("SELECT count(username) as false FROM unauth WHERE logintime>DATE_SUB(NOW(),INTERVAL 1 HOUR) AND ip="$REMOTE_ADDR""),0); if (mysql_error()) die(mysql_error()); if ($errors>5) ( print ("Accesul este închis. Vă rugăm să reveniți peste o oră."); exit(); ); $rezultat = mysql_query("SELECT * FROM user WHERE login="". preg_replace("/[^\w_\-]/", "", $PHP_AUTH_USER). "" AND pass="". md5($PHP_AUTH_PW) . """); if (@mysql_num_rows($rezultat)!=1) ( header("WWW-Authenticate: Basic realm=\"zonă secretă\""); header("HTTP/1.0 401 Neautorizat"); imprimare ("Este necesară autorizarea") ; mysql_query("INSERT INTO unauth (nume de utilizator, trecere, ip) VALUES ("$PHP_AUTH_USER", "$PHP_AUTH_PW", "$REMOTE_ADDR $HTTP_X_FORWARDED_FOR")"); $current_user = mysql_fetch_array($rezultat); mysql_free_result($rezultat);

  Dacă stocați sau nu înregistrările vechi pentru statistici, este o decizie de afaceri. În orice caz, acestea pot fi șterse executând următoarea solicitare înainte de autorizare:

  DELETE FROM unauth WHERE timpul de conectare

  Sub sarcini grele, un astfel de mecanism va funcționa mai rapid și mai fiabil decât fișierele - în baza de date, datele utilizate frecvent sunt stocate și procesate direct în RAM.

  Parola pentru pagina. Partea 3. Parola bazei de date

  Am avut odată o problemă: trebuia să închid partea administrativă a site-ului, dar în același timp nu puteam pune fișierul .htpasswd deasupra directorului rădăcină al site-ului. Suspiciunea înnăscută nu mi-a permis să pun un fișier cu o parolă și un director separat și să blochez accesul la acesta prin http.

  Am decis sa incerc sa fac protectie ca in phpMyAdmin: utilizatorului i se cere un login si o parola, cu care scriptul se conecteaza la baza de date. Am făcut exact acest lucru în analizorul meu de jurnal. Comoditatea metodei este că fișierul poate fi plasat oriunde - fără cookie-uri, fără directive de server pentru director. În același timp, dacă parola din baza de date se modifică, nu este nevoie să corectați nimic din script.

  Voi descrie metoda folosind MySQL ca exemplu. Scriem o funcție, de exemplu, mysql_die:

  Funcția mysql_die() ( header("HTTP/1.0 401 Neautorizat"); header("WWW-authenticate: basic realm=\"Statistics\""); print ("Accesul refuzat. Sunt necesare nume de utilizator și parolă."); ieșire ();

  La începutul programului, sunt indicate gazda serverului bazei de date și, dacă este necesar, numele bazei de date:

  Și pentru a se conecta la baza de date, sunt luate variabilele de server: $PHP_AUTH_USER și $PHP_AUTH_PW.

  $db_connect = @mysql_connect($db_host, $PHP_AUH_USER, $PHP_AUTH_PW) sau mysql_die();

  Asta e tot. Acum despre dezavantaje. Desigur, cu o astfel de protecție, puteți încerca să ghiciți parola (în principiu, puteți atașa un lacăt, dar atunci toată frumusețea metodei se va pierde). Parola, ca și în cazul protecției serverului, este trimisă în text clar. Dar pentru sarcini simple, acest lucru este destul de potrivit.

Parola pentru pagina. Partea 4. Cookie-uri

Această metodă este aplicabilă acolo unde, în primul rând, există mulți utilizatori, iar contingentul acestora este în continuă schimbare. În al doilea rând, unde trebuie să vă autentificați convenabil - astfel încât să vă puteți conecta în sistem introducând datele de conectare și parola în formularul de pe pagină.

Desenăm un formular și facem un fișier care primește o autentificare și o parolă (am descris deja protecția împotriva selecției, adăugați-l singur aici).

// procesează linia de conectare$login = str_repalce(""", "", $login); $login_result = mysql_query("SELECT ID FROM user WHERE login="$login" AND pass="". md5($pass). """); dacă (!mysql_error() && @mysql_num_rows($login_result)==1) ( /* emit cookie-uri. Este mai bine să definiți numele și căile cookie-urilor într-un singur fișier inclus pentru a evita confuzia. */ setcookie($COOKIE_LOGIN_NAME, $login, time()+3600, $COOKIE_PATH); setcookie($COOKIE_PASSW_NAME, $pass, time()+3600, $COOKIE_PATH);/* Imediat după conectare, utilizatorul este redirecționat către o adresă protejată prin parolă. */ header("Locație: /somepath/"); Ieșire; ) elseif (!mysql_error()) (

/* afișează un mesaj de eroare și un formular de reintroducere */

print(„Autentificare sau parolă incorectă.”); ) else print (mysql_error()); Toate paginile închise apelează la un fișier care verifică validitatea parolei obținute din cookie:

$login = str_repalce(""", "", $HTTP_COOKIE_VARS[$COOKIE_LOGIN_NAME]); $login_result = mysql_query("SELECT ID FROM user WHERE login="$login" AND pass="". md5($HTTP_COOKIE_VARS[$COOKIE_PASSW_NAME) ]). """); dacă (!mysql_error() && @mysql_num_rows($login_result)!=1) (

După cum puteți vedea, parola va călători prin canal și va fi stocată în fișierul cookie într-o formă clară, necriptată. Este foarte nesigur. În absența proprietarului, puteți merge la computer, puteți căuta fișierul în care browserul stochează cookie-uri și puteți nota parola pe o bucată de hârtie (și dacă totul este partajat în rețeaua locală, atunci nu trebuie să urcați și puteți fura parola chiar în fața proprietarului).

Pentru a preveni acest lucru, parola trebuie criptată. O opțiune acceptabilă este hash-ul md5. Aici nu mai puteți vedea parola și nu mai puteți să vă conectați la sistem notând-o pe o bucată de hârtie sau copiați-lipiți-o.

Apropo, exact așa vă puteți conecta la interfețele web care se bazează pe sesiuni pentru autorizare, folosind o parolă și fără știrea prietenului dvs.

Prin urmare, ultimul lucru pe care îl puteți face în această direcție este să schimbați cookie-ul de fiecare dată când pagina este încărcată. Eu însumi am făcut odată următoarea diagramă: în tabelul utilizatorilor există o coloană cu data ultimei solicitări. Utilizatorul primește această ultimă dată de acces și parolă, codificate prin md5, la fiecare acces. Sistemul preia un cookie cu un login, scoate acest șir din baza de date, generează un hash din câmpurile last_log și passwd și îl compară cu cel primit. Dacă se potrivesc, atunci vizitatorul poate fi admis. Pentru o mai mare securitate, puteți adăuga o verificare pentru expirarea cookie-ului - cookie-ul ar trebui să expire după o jumătate de oră de inactivitate și, în consecință, data ultimului jurnal din baza de date ar trebui să fie cu mai puțin de jumătate de oră în urmă.$login = str_repalce(""", "", $HTTP_COOKIE_VARS[$COOKIE_LOGIN_NAME]); $login_result = mysql_query("SELECT * FROM user WHERE login="$login" AND last_log>DATE_SUB(ACUM(), INTERVAL 30 MINUTE) "); dacă (!mysql_error() && @mysql_num_rows($login_result)==1) ( /* Obținem un rând de tabel și formăm un hash din câmpurile necesare. */$current_user = mysql_fetch_array($login_result); $hash_to_check = md5($current_user["passwd"]. "Y - ca să nu ghicească nimeni." $current_user); header("Locație: /login.php");

Ieșire; ); ) elseif (!mysql_error() && @mysql_num_rows($log_result)!=1) ( header("Locație: /login.php"); ieșire; ) else print (mysql_error()); Desigur

"Y - ca să nu ghicească nimeni"

De asemenea, este mai bine să o separați într-o variabilă separată și este mai bine să utilizați adresa IP a vizitatorului în loc de această linie (sau, pentru o comutare întreruptă, primele două/trei numere ale adresei IP).

Apropo, despre adresa IP. Este mai bine să o verifici, dar nu întreaga adresă, ci doar primele două (pentru ip care începe cu un număr mai mic de 127) sau trei (respectiv, mai mult de 127) numere ale adresei.

Acest lucru îi va scuti pe utilizatorii unei conexiuni proaste și întrerupte de a fi nevoiți să se conecteze din nou după pierderea conexiunii și, în același timp, nu va permite unui atacator care a furat cookie-ul să se conecteze. Desigur, nu va putea să sune înapoi și să se autentifice prin alt furnizor - adresa piscinei nu este aceeași, dar nu aceasta este problema noastră („pe vremea asta stau acasă”). Nici furtul de parole în cadrul companiei nu este problema noastră. Ne-am protejat de tovarăși curioși și de hackeri analfabeți, dar nu putem face nimic împotriva troienilor și sniffer-urilor care pot fi instalate asupra victimei.

Cazurile când este necesar lucrul în ședințe nu sunt atât de frecvente. De exemplu, în jocul meu „Monopolist” am început imediat să folosesc sesiuni, deoarece utilizatorul poate juca mai multe jocuri și aceeași pagină din aceeași sesiune poate conține date diferite.

Acolo este mai bine să stocați datele pentru unul dintre jocurile la care utilizatorul participă la o sesiune și să creați o pagină pentru comutarea între jocuri.

În general, nu spun că sesiunile nu ar trebui folosite. Este necesar, dar totul are locul lui. Voi reveni la întrebarea aplicabilității a trei metode de autorizare - prin antetul 401 ("domeniu"), cookie-uri sau sesiuni - mai târziu. Acum să vorbim despre sesiuni.

Sesiunile în PHP nu sunt de fapt o metodă de autorizare (conceptul în sine este incorect, dar pe forumuri se întreabă exact „cum se autorizează un utilizator prin sesiuni?”). Mecanismul de sesiune utilizator încorporat în PHP identifică doar acești utilizatori.

Nu vă voi spune prea multe despre mecanismul sesiunilor - s-a spus deja. În forma sa cea mai simplă (sau mai degrabă, în cea mai greșită formă), acest mecanism funcționează astfel: sistemul păstrează un fișier de sesiune pe server, care conține variabilele sale.

La începerea unei sesiuni, utilizatorul primește un identificator unic (de obicei printr-un cookie), iar la accesarea altor pagini, îl trimite. Când lansați mecanismul de sesiune în scriptul dvs., handlerul php verifică dacă există un fișier corespunzător identificatorului de sesiune de intrare - dacă acesta există, scriptul va putea citi datele din fișier, dacă nu, va fi lansată o nouă sesiune și fișierul va fi creat. Desigur, numele acestei variabile este definit în setările php.

Acum despre ce funcții folosim. session_start()

. Lansează mecanismul de sesiune în sine. Utilizatorul trebuie să aibă o variabilă și un fișier corespunzător. Dacă fișierul nu există, acesta este creat și sesiunea este pornită de la zero. Dacă nu există nici un fișier, nici o variabilă, atunci este generată o variabilă (de exemplu, este trimis un antet cu un cookie) și fișierul este creat.).

session_register(nume1, nume2, nume3...).

Setarea parametrilor cookie cu un identificator de sesiune (implicit, cookie-ul este setat la rădăcina serverului și timp de 0 secunde - până când browserul este închis).

Asta e tot deocamdată. Vor exista probleme separate despre sesiuni în detaliu. Deocamdată, voi descrie mecanismul de autorizare și identificare a utilizatorilor folosind sesiuni.

Deci, avem trei fișiere - login, verificare (auth) și output (logout).// decupează toate caracterele nedorite $login = preg_replace("/[^\w_\.\-]/", "", $HTTP_POST_VARS["login"]); $trece = trim($HTTP_POST_VARS["trece"]);// verificarea variabilelor if (strlen($login)==0 || strlen($pass)==0) $error = "Introduceți numele și parola"; altceva(// verificați autentificarea și parola $user_result = mysql_query("SELECT * FROM user WHERE login="$login" AND pass="". md5($pass). """);/* dacă apare o eroare în baza de date (de exemplu, utilizatorul a inserat o variabilă pe termen lung în sesiune, pe care baza de date nu a vrut să o digeră) sau s-a dovedit a fi mai mult de o linie, dăm cu piciorul utilizatorului */ if (mysql_error()) die(mysql_error()); elseif (@mysql_num_rows($user_result) != 1) $error = "Nume de utilizator sau parola invalide."; // dacă totul este bine, selectați datele, începeți sesiunea else ( $user = mysql_fetch_assoc($user_result); session_set_cookie_params(1800, "/"); session_start(); // reține datele utilizatorului session_register ("utilizator"); // și apoi trimite-l undeva if (isset($HTTP_POST_VARS["return"])) header("Locație: ($HTTP_POST_VARS["return"])"); else header("Locație: /");

Ieșire(); );

);/* aici utilizatorul nu mai este autorizat, dar poate trimite un cookie dintr-o sesiune închisă. hai sa-l curatam. */ if (isset($HTTP_COOKIE_VARS)) setcookie(session_name());// apoi desenăm forma, acest lucru nu este interesant. Acest script este atât un handler, cât și un formular de introducere a datelor. Când primește un login și o parolă, le prelucrează și, dacă sunt corecte, nu mai funcționează, trimițând utilizatorul la pagina dorită. Dacă datele sunt incorecte sau lipsesc cu totul, desenează formularul./* omorâți variabila utilizator, astfel încât după desenarea formularului să fie imposibil să trimiteți date într-o solicitare post. */ unset($utilizator);// steag „eroare de sesiune” - dacă este activat, lucrul se va opri. /* dacă întâmplător nu există login și parolă în matrice, se oprește și lucrul („nu știm nimic, ți le-am dat”) */ if (!isset($user["login"]) || !isset($user["pass"])) $session_error = true; );/* dacă utilizatorul a reușit până acum să evite eroic erorile, se face o verificare prin baza de date în același mod ca la intrare. */ if (!$session_error) ( $check_result = mysql_query("SELECT uid FROM user WHERE login="($user)" AND pass="($user)""); if (mysql_error() || @mysql_num_rows($user_result) ) != 1) $session_error = true );// dacă a existat vreo eroare, atunci dacă ($session_error) (// distruge datele sesiunii sesiune_distruge();// distruge cookie-ul dacă a fost unul if (!isset($HTTP_COOKIE_VARS)) setcookie(session_name(),"","/");/* trimite utilizatorul să se autentifice, cu posibilitatea de a reveni la adresa solicitată */ header("Locație: /login.php?return=$REQUEST_URI");// încetează să lucreze

Ieșire(); ); mysql_free_result($check_result);

Utilizatorul este verificat și în matricea $user - toate datele despre el, puteți, de exemplu, să-l salutați după prenumele și patronimul: Dacă(isset($HTTP_COOKIE_VARS)) (// pornește mecanismul de sesiune sesiune_start();// ștergerea fișierului sesiune_distruge();// șterge cookie-urile setcookie(session_name());

); // ies din pagina header("Locație: /login.php"); Câteva note: partea care este protejată de o parolă în acest exemplu este întregul server (de exemplu, service.firm.ru), pentru a închide directorul, trebuie să corectați căile. În loc de PHPSESSID folosit.

nume_sesiune()

astfel încât să puteți schimba liber numele identificatorului. Apropo, pe un server fizic puteți crea nume diferite pentru identificatorii de sesiune - trebuie doar să puneți fișierul .htaccess cu linia în partea necesară

php_value session.name „ABRACADABRA”

Dacă aveți alte întrebări sau ceva nu este clar - bine ați venit pe site-ul nostru

În zilele noastre există o mulțime de oferte pe internet în care se propune să participi la un training plătit sau să achiziționezi un curs pe tema monetizării site-urilor cu acces plătit la anumite pagini, dar nu ar trebui să le cumperi. Cel mai probabil, nu veți găsi nimic nou acolo, dar veți învăța cum să setați o parolă pe pagina unui site web și cum să o schimbați în acest articol, complet gratuit.

Cred că principiul de a face bani cu accesul plătit este clar: setați o parolă, acceptați plata, trimiteți parola de acces. Dacă aceasta este o taxă de abonament, atunci schimbați parola o dată pe lună, colectați din nou plata și trimiteți o nouă parolă. Toate acestea pot fi automatizate cu ajutorul unui serviciu excelent e-autopay.com, acest serviciu este foarte convenabil în ceea ce privește acceptarea plăților și trimiterea automată a bunurilor electronice și fizice, coduri PIN și așa mai departe, totul poate fi configurat până la un program de afiliere convenabil, vă sfătuiesc să fiți atenți, serviciul este folosit de toți bine -oameni de afaceri cunoscuți în informații precum Azamat Ushanov, Alexander Borisov și mulți alții. Apropo, este implementat și pe serviciu e-autopay.com.

Acum să aflăm cum să setăm o parolă pe pagina unui site WordPress. Pentru a face acest lucru, trebuie, desigur, să creăm mai întâi pagina dorită, apoi să mergeți la editarea postării și să mergeți la fila „Publicare” și să faceți clic pe linkul „editare”, vedeți figura.

Apoi veți vedea următoarea fereastră în care puteți selecta vizibilitate, public, privat sau protejat cu parolă și puteți fixa pagina în partea de sus a paginii de pornire, dar avem nevoie de o parolă, selectați funcția dorită și setați o parolă. pentru pagină, așa cum se arată în figura de mai jos.

După toți pașii de mai sus, tot ce trebuie să faceți este să publicați pagina la momentul potrivit. În acest mod simplu, puteți crea pagini cu o parolă pe blogul dvs. și, prin urmare, puteți crea acces plătit sau limitat la diferite informații. De exemplu, pe blogul meu, accesul la un curs gratuit este limitat, accesul se poate obține doar după abonarea la acest curs, după activarea abonamentului, o parolă de acces este trimisă pe email, totul este foarte simplu și totul este automat. După cum puteți vedea, nu este nimic complicat în acest sens, puteți seta parole pentru orice pagină și articole ale site-ului dvs.

Acum știi cum să pui o parolă pe o pagină sau un articol de pe un site. Sper că aceste informații vă vor aduce beneficii și idei noi pentru a face bani pe site-ul dvs. Ca întotdeauna, aștept cu nerăbdare întrebările și comentariile voastre la acest articol.

Parolele sunt principalul mijloc de protejare a informațiilor și sunt folosite peste tot pe un computer - de la autentificarea într-un cont până la autorizarea pe pagini de pe rețelele sociale. Un utilizator activ are atât de multe chei de securitate diferite încât este imposibil să le păstrezi pe toate în memorie. Aici vine în ajutor funcția de salvare a parolelor în setările browserului.

Funcționează astfel:

1. Deschideți un site web care necesită înregistrare.
2. Introduceți informațiile de conectare în profilul dvs.
3. Browserul vă solicită să salvați informațiile introduse - sunteți de acord.

Data viitoare când deschideți acest site, nu este nevoie să introduceți nimic; chiar dacă vă deconectați de la contul dvs., toate rândurile formularului de autorizare vor fi completate. Dar aici este dezvăluit un dezavantaj serios - să aflăm cum să vedem o parolă ascunsă cu asteriscuri și dacă este posibil să faceți acest lucru.

Deci, mergi pe site și vezi parola sub asteriscuri. S-ar părea un lucru convenabil - faceți clic pe „Autentificare” și nu trebuie să introduceți nimic altceva, iar alți utilizatori nu văd parola.

O parolă acoperită cu asteriscuri este o țintă ușoară pentru hacking.

Verificați-l pe computer. De exemplu, folosim browserul Google Chrome:

În același mod, puteți vizualiza cheile de acces la conturi în alte browsere - Mozilla Firefox, Opera, Internet Explorer. Să vedem cum se face acest lucru în Mozilla pentru fixarea materialului:

Apropo, nu este necesar să schimbați valoarea înapoi la „parolă”. Dacă închideți pagina și apoi reveniți la ea din nou, veți vedea că stelele s-au întors. Cu toate acestea, acum știți ce protectori nesiguri ai datelor personale sunt aceștia.

Setări browser

Dacă credeți că acesta este sfârșitul expunerii stelelor, atunci vă înșelați profund. Toate browserele au o modalitate și mai convenabilă de a vizualiza parola pe care ați salvat-o când v-ați conectat pentru prima dată pe site. De data aceasta, să luăm browserul web Opera ca exemplu:

Va apărea o fereastră care conține multe adrese de site-uri web și date din diferite conturi. La prima vedere, totul este în regulă: login-urile, desigur, sunt afișate, dar în loc de parole, există asteriscuri care ne sunt familiare. Cu toate acestea, dacă faceți clic pe un rând, veți vedea un buton Afișare care apare lângă stele.

Un clic și veți vedea cheia de securitate pentru site. Puteți dezvălui toate parolele, puteți face o captură de ecran și nici nu vă veți da seama că paginile dvs. protejate prin parolă sunt acum în pericol. Nu numai Opera, ci și alte browsere împărtășesc astfel de informații. În Google Chrome, de exemplu, un astfel de semn poate fi apelat în felul următor:

În Mozilla Firefox, se deschide un tabel cu toate cheile de acces salvate în secțiunea „Securitate” a setărilor.

În alte browsere situația este similară - toate datele pe care sunteți de acord să fie stocate trebuie să fie disponibile public.

Folosind software special

Dar nu numai browserele stochează date despre utilizatori, pe care utilizatorul le oferă și stochează cu amabilitate.

Orice program care vă cere să introduceți o parolă și să vă autentificați vă oferă, de asemenea, să vă amintiți aceste date pentru a nu le introduce de fiecare dată când îl porniți.

În consecință, există utilități speciale care vă permit să vizualizați aceste date salvate. Astfel de utilitare funcționează pe același principiu, așa că să luăm ca exemplu programul Password Cracker. Este distribuit gratuit și cântărește ridicol 45 KB.

În linia „Parolă” din fereastra utilitarului Password Cracker, cheia de securitate salvată va apărea pe afișaj alfanumeric.

Concluzie

După cum puteți vedea acum, aflarea parolei ascunse în browser, ascunsă cu asteriscuri, nu este dificilă. Tot ce aveți nevoie este accesul la un computer și câteva minute de timp pentru ca datele din conturile dvs. să ajungă în mâinile unor persoane neautorizate.

Desigur, în acest caz, riști să-ți uiți parola și să nu intri în profilul dorit. Cu toate acestea, acest lucru nu este înfricoșător: am scris deja despre cum să vă recuperați parola Gmail, cum să vă aflați parola Wi-Fi, cum să recâștigați accesul la contul dvs. în jocul WarFace etc. Dacă vă puteți conecta la căsuța poștală în care este înregistrat contul sau ați conectat un număr de telefon la profilul dvs., atunci, dacă este necesar, puteți recupera cu ușurință o parolă uitată.

Dar ce să faci cu acele chei de securitate pe care le-ai salvat deja în setările browserului tău? Răspunsul corect este ștergerea. Când te-ai uitat la parole prin setări, ar fi trebuit să vezi că funcția de salvare a codurilor poate fi dezactivată. Ștergeți tabelele cu cheile stocate, eliminând toate rândurile și apoi dezactivați funcția în sine.

Nu există articole similare.

Una dintre principalele axiome ale securității informațiilor afirmă că „confortul unui sistem este invers proporțional cu securitatea acestuia”. Aceasta înseamnă că atunci când alegeți un sistem de securitate, este necesar să găsiți echilibrul optim între complexitatea securității și confortul experienței utilizatorului.

Pe de altă parte, dezvoltarea și implementarea protecției necesită un anumit efort și bani. Prin urmare, este necesar să se adopte o abordare rezonabilă pentru proiectarea protecției. Mai simplu spus, nu este nevoie să creați un sistem de securitate complex și costisitor dacă pe site nu este stocat nimic valoros. Niciun atacator nu va încerca să vă spargă pagina de pornire, site-ul de cărți de vizită al unei companii mici sau site-ul unei grădinițe.

În lecția anterioară, am analizat autorizarea folosind un server Web (autorizare de bază). Acesta este probabil cel mai simplu și mai sigur mod de a restricționa accesul la resurse. Cu toate acestea, menținerea unui astfel de mecanism necesită destul de multă muncă, mai ales cu un număr mare de utilizatori cu drepturi diferite. În plus, nu toate serverele permit autentificarea HTTP.

O alternativă mai populară este protecția prin parolă. Înțelesul său este că serverul stochează liste de utilizatori și login-urile, parolele și drepturile de acces corespunzătoare acestora. Când accesează site-ul pentru prima dată, utilizatorul introduce un login/parolă și obține acces la resurse. Serverul „își amintește” utilizatorul și nu cere o parolă până când se deschide următoarea sesiune (repornirea browserului).

Organizarea protecției prin parolă cade în întregime pe umerii programatorului. Dezvoltatorul trebuie să asigure securitatea stocării listelor de utilizatori, verificării autentificărilor/parolelor, salvării contextelor de securitate și reutilizarii acestora. Contextul de securitate aici este înțeles ca un set de parametri care identifică în mod unic utilizatorul (cel puțin, acesta este un login, o parolă și un identificator de sesiune).

Luați în considerare un exemplu de implementare a celei mai simple protecție prin parolă. Să creăm un fișier logon.php

Când faceți clic pe butonul „login”, datele formularului vor fi trimise către server, unde scriptul va verifica login-ul și parola introduse și dacă sunt egale cu „admin” și respectiv „megaPass”, va afișa un mesaj că autentificarea este permisă. Dacă autentificarea sau parola este incorectă, utilizatorul va vedea un mesaj de avertizare.

Primul dezavantaj al acestui script: transmiterea datelor folosind metoda GET. Atunci când utilizați această metodă, datele sunt transmise direct în adresă și, prin urmare, vizibile chiar și cu ochiul liber. De exemplu, dacă ați introdus numele de utilizator și parola corecte, veți vedea în bara de adrese

Http://localhost/logon.php?login=admin&passwd=megaPass

Al doilea dezavantaj: numele de utilizator și parolele sunt codificate direct în cod. Aceasta înseamnă că pentru a adăuga noi utilizatori va trebui să schimbați constant codul fișierului. Imaginează-ți doar cât de mare va fi fișierul dacă ai cel puțin o mie de utilizatori înregistrați pe site-ul tău... Listele de utilizatori sunt cel mai bine stocate într-un fișier separat, sau mai bine zis într-o bază de date, deoarece... Este mult mai ușor pentru un atacator să fure un fișier decât să extragă ceva dintr-o bază de date.

Al treilea dezavantaj: rezultatele de conectare ale utilizatorului nu sunt reținute, adică. Doar reîmprospătați pagina și vi se va cere să introduceți din nou parola.

Deci, să ne uităm la modalități de a elimina aceste neajunsuri.

Cel mai simplu mod de a ascunde datele transmise este utilizarea metodei de transmisie POST. În acest caz, browserul însuși (ascuns utilizatorului) va transfera toate datele necesare către server și poate fi interceptat doar de programe speciale din arsenalul de specialiști IT, programatori sau hackeri.

După cum sa menționat mai sus, listele de utilizatori trebuie stocate separat. Să creăm un tabel în baza de date de testare:

CREATE TABLE `smplusers` (
`user_id` int(11) NOT NULL auto_increment,
`nume_utilizator` varchar(50) NOT NULL,
`user_login` varchar(50) NOT NULL,
`parola_utilizator` varchar(50) NOT NULL,
`reg_date` datetime NU NULL,
CHEIE PRIMARĂ (`user_id`)
)

și adăugați mai multe înregistrări de utilizator la acesta:

INSERT INTO smplUsers
(nume_utilizator, utilizator_login, parola_utilizator, data_reg)
valorile
("Ivanov I.I.", "ivanov-i-i", "pass1", NOW()),
("Petrov P.P.", "Petrovici", "pass2", ACUM()),
("Sidorov S.S.", "sidorov", "pass3", NOW())

Vă rugăm să rețineți că operatorul INSERT permite adăugarea mai multor înregistrări la tabel simultan, iar datele sunt listate în blocuri separate prin virgulă.

Acum să schimbăm logon.php, astfel încât numele de utilizator și parola să fie corect verificate direct în baza de date:

// se conectează la baza de date aici
// $link - link de conexiune
$link = mysql_connect("localhost", "db_user", "db_passwd");
mysql_select_db("nume_db", $link);
?>

Acum autentificarea și parola sunt transmise în secret și este foarte ușor să schimbați acreditările prin editarea tabelului din baza de date. Ultimul pas rămâne - să înveți serverul să-și amintească faptul înregistrării. Cel mai simplu mod de a face acest lucru este utilizarea mecanismului de sesiune. Să facem modificările necesare:

sesiune_start();
?>

...

echo "Utilizator: " . $row[„nume_utilizator”];

$_SESSION["user_id"] = $row["user_id"];