Testovacia úloha pre vývojára PHP v skúšobnej dobe. Jednoduchý príklad pomocou PHP a AJAX Testovanie úspechu php

7,4 tis
V tomto článku popíšem, ako vytvoriť a odoslať formulár AJAX. Potom sa môžeme pozrieť na implementáciu animácie pomocou animate.css, validáciu údajov pomocou JavaScriptu.

V čase písania tohto článku je aktuálna verzia rámca Bootstrap 3.3.5. V tomto článku používame predvolenú zostavu Bootstrap (12 stĺpcov). Keď dokončíte úlohy v tomto článku, uistite sa, že používate najnovšie úryvky a štruktúru kódu popísanú v Bootstrap dokumentácia.

Štruktúra súborov a priečinkov

Vytvoríme koreňový adresár a pridáme doň nasledujúce súbory a priečinky:

Bootstrap-Form:

Budeme musieť zahrnúť niektoré front-end knižnice:

• Bootstrap;
• jQuery.

S ohľadom na tieto knižnice bude štruktúra súborov vyzerať takto:

Bootstrap-Form:

Vytváranie formulárov

Otvorte svoj súbor index.html a skopírujte doň nasledujúcu základnú štruktúru Kontaktné formuláre AJAX:

"

Toto je základná HTML šablóna, do ktorej pridáme obsah formulára. Zahrnuli sme všetky požadované súbory CSS a JavaScript. Všimnite si, že pre tento konkrétny príklad nepotrebujeme bootstrap.js.

Do Bootstrapu sme zahrnuli metaznačku zobrazovanej oblasti pre mediálne dopyty. JavaScript bol umiestnený na spodok súboru, takže hlavný kód sa spracuje ako prvý.

Do značky body sme zaradili div s triedou col-sm-6 col-sm-offset-3. To znamená, že v rámci a na vrchu sm (malého) výrezu chceme zobraziť stĺpec široký 50 % ( maximálny počet stĺpcov 12). Trieda col-sm-offset-3 nastavuje ľavý okraj na 25 %.

Vznikne tak rozloženie, ktoré zaberá polovicu dostupného priestoru a je horizontálne vycentrované. Potom sme zapli h3 a potom ide základný tvar. Uistite sa, že na formulár použijete ID, aby ste k nemu mohli neskôr pripojiť udalosť a odoslať formulár AJAX JQuery:

Bez boja niet víťazstva

Predložiť

Toto sú všetky vstupné polia a tlačidlá, s ktorými bude používateľ pracovať. Počiatočný riadok triedy priradený divu je klasická syntax Bootstrap, čo je horizontálne zoskupenie prvkov col. Stĺpce v rámci Bootstrap vytvárajú výplň alebo medzery. Ich odstránením dosiahnete, že vlasec zapadne do nádoby rovnomerne.

Vytvorili sme dva stĺpce s triedou col-sm-6 (50%), ktoré použijeme na oddelenie hornej časti formulára. V prvom stĺpci col-sm-6 sme vytvorili štítok a polia pre meno a e-mail. Každý z nich obsahuje štítok so zodpovedajúcim atribútom for, takže štítok je spojený s príslušným poľom.

Každý z týchto stĺpcov obsahuje skupinu formulárov, ktorá sémanticky zoskupuje menovky a vytvára mierny spodný okraj:

Typografia

Bootstrap umožňuje triedy pre H1-H6. Pomôžu vám vytvoriť štýl vložených prvkov bez pridávania ďalších polí alebo vytvárania super blokov prvkov kontaktného formulára AJAX. Použili sme triedu pre H4 na úpravu štítkov a ich zväčšenie.

Trieda form-control sa aplikuje na každý vstupný prvok tak, aby pokrýval celú šírku kontajnera (100 % šírka). Táto trieda tiež pridáva rôzne štýly na vytvorenie ľahko čitateľného prvku formulára ( veľké rozmery, ostré hrany atď.).

Za tieto stĺpce zahrnieme telo správy. Zabalíme ho do skupiny formulárov a použijeme rovnaké štýly ako na štítky a textové polia.

Výzva do akcie

Vytvorme tlačidlo Odoslať. Bootstrap obsahuje triedy pre rôzne tlačidlá a ich stavy. Rozhodli sme sa použiť tlačidlo „ úspech” (btn-úspech), ktorá je predvolene zelená.

Musíte tiež použiť základnú triedu btn na resetovanie základných parametrov tlačidla ( rám, odsadenie, zarovnanie textu, veľkosť písma). Použili sme triedu btn-lg, ktorá vytvára veľké tlačidlo, a potom triedu pull-right, ktorá sa obtáča okolo tlačidla vľavo.

Po tlačidle sme zahrnuli div s #msgSubmit ID a použili nasledujúce triedy: “ h3 textové centrum skryté". Trieda h3 pomáha vytvoriť väčší nadpis, text-center nastaví zarovnanie textu na stred a skryté nastaví zobrazenie: žiadne a viditeľné: skryté:

Pridanie funkcie odosielania údajov

Vytvorili sme základný formulár Bootstrap JQuery AJAX, ktorý však zatiaľ nič nerobí. Naším ďalším krokom je vytvorenie funkcie, ktorá prevezme vstup od používateľa a odošle ho asynchrónne do PHP.

Otvorte súbor scripts.js a skopírujte doň nasledujúci kód:

$ ("# contactForm"). odoslať (funkcia (udalosť) (// zruší odosielanie údajov formulára event.preventDefault (); submitForm ();));

Toto útržok kódu jQuery ktorý počúva funkcie odosielania údajov #contactForm ( ako bolo uvedené skôr). Pred touto funkciou spracovávame premennú udalosti, ktorá obsahuje akciu odoslania formulára pre funkciu.

event.preventDeafult () zastaví odosielanie údajov formulára, keď sa stránka obnoví bez výberu akcie vo formulári. A na konci tento kód požaduje funkciu submitForm (); :

function submitForm () (// Inicializácia premennej s obsahom formulára var name = $ ("# meno"). val (); var email = $ ("# email"). val (); var message = $ ("# správa ") .val (); $ .ajax ((typ:" POST ", url:" php / form-process.php ", údaje:" meno = "+ meno +" & email = "+ email +" & message = " + správa, úspech: funkcia (text) (if (text == "úspech") (formSuccess ();))));) funkcia formSuccess () ($ ("# msgSubmit"). removeClass ("skryté"); )

Tri spúšťané premenné zachytávajú hodnoty každého zo vstupných polí formulára a odovzdávajú ich premennej JavaScriptu na neskoršie použitie.

Iniciujeme Objekt AJAX vo vnútri JQuery a nastavte parametre pre príspevok, umiestnenie súboru PHP, údaje, ktoré chceme odoslať, a funkciu spätného volania. Údaje zahŕňajú všetky tri premenné so zodpovedajúcim id. Funkcia spätného volania sa volá, keď objekt AJAX úspešne prijal informácie zo skriptu PHP. Funkcia zachytí vrátený text a skontroluje, či sa rovná reťazcu “ úspech“. Ak áno, spustí sa funkcia final formSuccess.

Odstráni skrytú triedu z #msgSubmit DIV, ktorý sme použili predtým, čím sa vykreslí text.

Pripojenie k funkcii PHP Mail

Teraz musíte napísať skript, ktorý bude prijímať údaje z formulára AJAX a odosielať obsah prostredníctvom funkcie PHP Mail. Otvorte súbor process.php a pridajte doň nasledujúci kód:

Musíme uložiť premenné, ktoré chceme použiť. Tri vstupné premenné je možné získať z poštovej funkcie a dať im rovnaké názvy v PHP. Premenná $ EmailTo je e-mailová adresa, ktorú je možné nastaviť v skripte. $ Predmet je reťazec popisujúci predmet e-mailu.

Telo listu je vytvorené ľubovoľne pridaním troch vytvorených premenných. Najprv nastavíme popisný text, napríklad „ Názov:“, Nasleduje premenná a potom nový riadok (/ n). Opakujeme rovnaké kroky, pričom všetky údaje naviažeme na premennú $ body.

Ak chcete odoslať e-mail, pripojíme ho k funkcii pošty. Priradením hodnoty premennej $ success nastavíme emailovú adresu, na ktorú bude email odoslaný, predmet emailu, telo odosielateľa a emailovú adresu.

Ak chcete spustiť proces odosielania e-mailu, musíte ho zavolať v príkaze if. Týmto spôsobom môžete skontrolovať, či boli údaje formulára úspešne odoslané alebo nie. Ak sa funkcia Mail vráti „ pravda“, Skript sa vráti“ úspech", Ak funkcia vyvolá chybu, vráti" neplatný”.

Tento výsledok sa vráti do objektu AJAX a spracuje sa na strane klienta. Výhodou AJAXu je, že všetko prebieha asynchrónne na strane klienta. To umožňuje používateľovi pokračovať v interakcii so stránkou pri odosielaní údajov formulára AJAX:

Lesknite sa

Teraz sa zameriame na poskytovanie spätnej väzby od používateľov prostredníctvom rôznych doplnkových funkcií, ktoré je možné povoliť. Predovšetkým sa pozrieme na spätnú väzbu formulára pomocou spracovania chýb na strane klienta aj servera.

Na overenie formulára používame aj niektoré nástroje:

• Animate.css:;
• Bootstrap Validator.

Pridajte ich do svojho projektu, ako sme to urobili predtým s Bootstrap a JQuery. Tieto nástroje pomôžu používateľovi poskytnúť spätnú väzbu po odoslaní údajov.

Štruktúra projektu by teraz mala vyzerať takto:

Overenie formulára

Začnime inštaláciou validátora po zadaní údajov formulára spätnej väzby PHP AJAX. Prejdite na scripts.js a upravte prvú časť kódu, ktorá volá funkciu SubmitForm () po odoslaní údajov formulára.
Je potrebné ho zmeniť nasledovne:

$ ("# contactForm"). validator (). on ("submit", funkcia (udalosť) (if (event.isDefaultPrevented ()) (// spracovanie chyby formulára ...) else (// v poriadku! udalosť .preventDefault (); odoslať formulár ();)));

Tento nový útržok kódu kontroluje, či Bootstrap Validator nenašiel problémy a zastavil spustenie kódu. Ak nie, pokračujeme vo vykonávaní akcií v štandardnom režime. Stále musíme vylúčiť predvolenú akciu ( znovu načítajte stránku bez vyplnenia formulára) zo skriptu na odoslanie formulára.

Ak teraz klikneme na tlačidlo odoslať údaje z formulára bez vyplnenia všetkých polí, prázdne polia sa zvýraznia červenou farbou:

V procese pridávania overenia sme zablokovali natívne overenie HTML5. Do overenia môžete pridať ďalší kontext zahrnutím chybových hlásení. Bootstrap Validator má praktickú funkciu, ktorá vám umožňuje zobraziť chybové hlásenia pre každé z polí. Ak ich chcete pridať, musíte dokončiť označenie HTML.

Do každej skupiny formulárov pod poľom na zadávanie údajov musíte umiestniť nasledujúci kód HTML:

Ako príklad je nižšie uvedený ďalší div, ktorý môžete pridať do polí mena a e-mailu:

Teraz sa pri opätovnom odoslaní údajov formulára AJAX JQuery zobrazí chybové hlásenie, ak polia formulára neboli vyplnené: “ Vyplňte toto pole.“. Pridaním atribútu údajov pre vstupné údaje s názvom „ chyba údajov“, Môžete zahrnúť vlastnú chybovú správu.

Napríklad:

Pridáva sa animácia spätnej väzby

Pridali sme funkcie na označenie prázdnych polí formulára. Bolo by však pekné pridať do formulára nejakú extra animáciu a niekoľko správ, aby používateľ vedel, čo sa deje. V súčasnosti, ak boli údaje formulára úspešne odoslané, správa „ Správa odoslaná!„Ale čo chrobáky?

Ak chcete použiť existujúci kód, upravíme úspešne existujúcu správu. Najprv odstráňte text „ Správa odoslaná!"Z označenia HTML a ponechajte div prázdny:

Teraz musíme vytvoriť novú funkciu na spracovanie stavu správy. Pridajte túto funkciu do spodnej časti súboru scripts.js:

function submitMSG (valid, msg) (var msgClasses; if (valid) (msgClasses = "h3 text-center tada animated text-success";) else (msgClasses = "h3 text-center text-danger";) $ ("# msgSubmit "). removeClass (). addClass (msgClasses) .text (msg);)

Táto funkcia má dva argumenty. valid bude booleovská premenná: ak je jej hodnota true, zobrazí sa hlásenie o úspešnom odoslaní údajov. Ak je hodnota false, zobrazí sa chybové hlásenie. msg je správa, ktorú zobrazíme na obrazovke v bloku div.

Táto funkcia skontroluje, či máme do činenia s hlásením o úspešnom odoslaní údajov alebo chybovým hlásením. To sa vykonáva kontrolou platnej hodnoty premennej. V každom prípade nastaví premennú s príslušnými triedami CSS ( musíme znova povoliť h3 a textové centrum, pretože ich odstránime).

Poznámka: Pre triedu správ o úspechu používame niektoré triedy animate.css. Animácia tada sa prehrá po úspešnom odoslaní údajov kontaktného formulára AJAX JQuery.

Nakoniec funkcia odstráni všetky triedy z #msgSubmit ( aby sa predišlo prekrývaniu tried) a potom nastaví triedy priority a pridá text príspevku do prvku div.

V rámci inicializácie validátora na začiatku tejto časti aktualizujeme kód tak, aby sa do príkazu if pridalo volanie nasledujúcej funkcie, keď sa vyhodnotí ako true:

submitMSG (nepravda, "Vyplnili ste formulár správne?");

Teraz, ak ste nevyplnili všetky polia, zobrazí sa chybové hlásenie „ Vyplnili ste formulár správne?»

Posledným krokom pre túto novú funkciu submitMSG je jej zavolanie po úspešnom odoslaní údajov formulára. Aktualizujte funkciu formSuccess () takto:

$ ("# kontaktný formulár"). reset (); submitMSG (pravda, "Správa bola odoslaná!")

Chceme obnoviť formulár a vymazať hodnoty, keď zavoláme funkciu submitMSG, ako je uvedené vyššie so správou o úspešnom odoslaní. Teraz, po úspešnom odoslaní údajov formulára, by sa mala zobraziť zodpovedajúca správa s animáciou animate.css tada:

Poďme to rozhýbať

Pridajme chybovú animáciu k celému formuláru, generická animácia „trasenia“ by mala stačiť!

Vytvorte nový hneď po funkcii formSuccess () a nazvite ho formError ():

function formError () ($ ("# contactForm"). removeClass (). addClass ("shake animated"). one ("webkitAnimationEnd mozAnimationEnd MSAnimationEnd oanimationend animationend", function () ($ (this) .removeClass ();)) ;)

Táto funkcia využíva prístup opísaný na ukážkovej stránke animate.css, ktorá vám umožňuje pridať animáciu k prvku a potom ho znova vyvolať.

Animácie CSS majú nepríjemnú vlastnosť: nie je možné ich prehrať, aj keď sa trieda odstráni a znova pridá. Táto funkcia pomáha obnoviť koncové triedy animácie, aby ste ich mohli znova pridať. Keď používateľ klikne na tlačidlo Odoslať bez vyplnenia všetkých polí AJAX formulára spätnej väzby, prehráme animáciu trasenia. A ak znova nevyplní všetky polia, musíte túto animáciu prehrať znova.

Túto funkciu môžete zavolať formError () nad funkciou submitMSG (), ktorú sme vytvorili pre chybové hlásenie. Napríklad takto:

formError (); submitMSG (nepravda, "Vyplnili ste formulár správne?");

Teraz, keď sa používateľ pokúsi odoslať údaje formulára bez vyplnenia všetkých polí, zatrasie sa tak, že si uvedomí, že niečo nie je v poriadku.

Ďalšie overenie

Overenie na strane klienta je v poriadku, ale ktokoľvek ho môže vypnúť a odoslať formulár s prázdnymi poľami úpravou kódu v prehliadači. Musíte vytvoriť overovaciu službu na strane servera.

Musíme otvoriť súbor process.php a vykonať potrebné zmeny, aby sme zaistili, že sú skontrolované všetky polia. Vytvoríme premennú $ errorMSG na zachytenie chybových správ a potom povolíme dodatočnú kontrolu $ _POST:

Tento kód PHP skontroluje, či existujú prázdne polia formulára AJAX pred nastavením ich údajov ako vhodných premenných ( nahrádza existujúce premenné nastavené v kóde z $ _POST). Ak sú polia prázdne, nastavíme generickú správu, ktorú pošleme späť klientovi.

V reakcii na pôvodné volanie AJAX musíme odoslať chybové hlásenie, ktoré sa zobrazí v prehliadači. Ak to chcete urobiť, upravte príkaz if, ktorý sme vytvorili predtým, v spodnej časti kódu PHP:

Prostredníctvom príkazu if skontrolujeme, či je premenná $ errorMSG prázdna ("") a stav vstavanej funkcie Mail, ktorú sme použili pre premennú $ success. Do klauzuly else sme zahrnuli ďalšiu kontrolu, aby sme zistili, či chyba nie je výsledkom neúspešného úspechu $. Ak áno, pošleme späť správu “ Niečo sa pokazilo:“. V opačnom prípade zobrazíme správu, ktorá bola zostavená pri kontrole prázdnych polí.

A posledným krokom je prijatie novej správy v AJAX a jej zobrazenie vo formulári. Musíme aktualizovať objekt AJAX v súbore scripts.js takto:

$ .ajax ((typ: "POST", url: "php / form-process.php", údaje: "meno =" + meno + "& email =" + email + "& správa =" + správa, úspech: function ( text) (if (text == "úspech") (formSuccess ();) else (formError (); submitMSG (false, text);))));

Práve sme aktualizovali klauzuly else, ktoré testujú text == úspech. V else zavoláme funkciu formError (), ktorá aplikuje animáciu trasenia a požiada funkciu submitMSG () o text vrátený z PHP.

Záver

Prejdite na Github a zobrazte celý kód. Teraz Formulár spätnej väzby PHP AJAX poskytuje užívateľovi informáciu, ktoré z polí nemá vyplnené. Kontextové správy zobrazujeme na základe stavu a správy vrátenej z PHP. Implementovali sme aj ďalšiu vrstvu overovania na strane servera pre používateľov, ktorí sa pokúšajú obísť overenie front-endu.

Dúfam, že sa vám tento článok páčil. Prosím, zanechajte svoje otázky a pripomienky v komentároch.

Táto publikácia je prekladom článku " Vytvorenie kontaktného formulára Bootstrap pomocou PHP a AJAX„Pripravil priateľský projektový tím

K základnej funkcionalite by sa mali pridať nasledujúce funkcie:

• Používateľ môže v príspevkoch použiť nasledujúce značky HTML:
• Musí existovať kontrola uzatvárania značiek, kód musí byť platný XHTML

Kniha návštev. JavaScript a AJAX.

K základnej funkcionalite by sa mali pridať nasledujúce funkcie:

• Overenie vstupu na strane servera a klienta
• Funkcia zobrazenia ukážky a pridania správy bez opätovného načítania stránky
• V prípade značiek HTML vytvorte panel s tlačidlami (,,,,)
• Pridanie vizuálnych efektov je tiež vítané.

Požiadavky

Systém by mal správne fungovať na operačnom systéme Linux s nasledujúcou konfiguráciou:

• PHP 5.1+
• MySQL 4.1+
• Apache 2.2+

Môžu sa použiť tieto knižnice:

• PHP Zend Framework alebo PEAR
• JS jQuery alebo prototyp

P.S. Obrázok ukazuje Stirlingov motor, wikipedia často dáva jedlo pre myseľ ...

Upd: na mojom blogu sa objavil veľmi správny komentár:

ľudia, asi nechápete, pre koho je táto úloha určená. Človek so skúsenosťami to PRIRODZENE neurobí z dvoch dôvodov: a) nebude chcieť strácať čas a b) nebude mu to dané.

Realita je ale taká, že často ide o prvú viac či menej objemnú prácu uchádzača o pozíciu junior php developer.

Preto je 80 hodín poskytnutých nie preto, aby jednoducho urobil túto úlohu, ale aby zosúladil realitu (svoje vedomosti) so zaškrtávacími políčkami v jeho životopise oproti php, html, css, js, ajax, mysql.

Výsledkom je, že získame určitý integrálny ukazovateľ zručnosti a schopnosti učiť sa a schopnosti googliť.

V skutočnosti sa s tým úloha vyrovná.

A kandidáti, ktorí majú čo ukázať, idú prirodzene priamo do projektov.

Štítky: Pridať štítky

V ére moderného webu sa väčšina stránok stáva interaktívnejšou. Ak sme predtým, aby sme dostali aktualizované údaje, museli úplne aktualizovať stránku, teraz sa objavili technológie, ktoré umožňujú nenačítať celú stránku, ale iba jej samostatnú časť. Na druhej strane to poskytuje pohodlie používateľom aj vlastníkom servera, pretože pre používateľa bude načítanie stránky rýchlejšie, pretože sa načíta iba samostatná časť stránky a server nemusí stránku zakaždým generovať a dávať. používateľovi. Tieto funkcie sa dajú ľahko implementovať pomocou php a ajax.

Dnes si rozoberieme malý príklad, aby sme lepšie pochopili, ako koncept funguje. AJAX... Niekedy je pre začiatočníkov ťažké pochopiť, ako php a ajax navzájom spolupracujú, veľa ľudí hľadá príklady, ako overiť formuláre za behu bez opätovného načítania celej stránky. Stručne vám ukážem, ako na to, aby ste pochopili základy a princípy, ktoré vám v budúcnosti umožnia rýchlejšie sa naučiť ďalšie nástroje a písať si vlastné skripty.

Poďme si vymyslieť malú úlohu, skontrolujeme prítomnosť e-mailovej adresy v databáze bez opätovného načítania stránky pomocou php a ajaxu. Takýto príklad dobre demonštruje, ako môžeme interagovať so serverom bez opätovného načítania stránky v prehliadači, a tiež sa často používa pri rôznych druhoch overovania používateľských formulárov. V koreňovom adresári vytvorte 3 súbory s názvom index.php, email.php, validate.js.

Vytvorte stránku

Vytvorme si jednoduchú stránku s jedným formulárom, ktorý obsahuje len jedno emailové pole.
Syntax súboru Index.php

Najjednoduchší spôsob práce AJAX Ide o pripojenie rámca jQuery, čo som vlastne urobil. jQuery nám poskytuje ľahko zrozumiteľnú a ľahko použiteľnú syntax na odosielanie AJAXžiadosti, prečo to nevyužiť?

Vytvorenie skriptu Js

Syntax súboru validate.js je

$ (dokument) .ready (funkcia () (var email = ""; $ ("# email"). keyup (funkcia () (hodnota var = $ (toto) .val (); $ .ajax ((typ: "POST", url: "email.php", údaje: "email =" + hodnota, úspech: funkcia (msg) (if (msg == "platné") ($ ("# správa"). Html (" Tento email je možné použiť.Tento email sa už používa.");))));)); $ (" # odoslať "). kliknúť (funkcia () (ak (e-mail ==" ") (upozornenie (" Uveďte údaje do všetkých e-mailov ");) inak ( $ .ajax ((typ: "POST", url: "email.php", údaje: "add_email =" + e-mail, úspech: funkcia (msg) ($ ("# správa"). html (msg);)) ;))));));

Ovládač PHP

Tento skript dostane POST požiadavku od klienta, spracovať ju a vrátiť výsledok. AJAX prečíta výsledok a na základe neho sa rozhodne.
Syntax súboru email.php je

$ connection = mysqli_connect („localhost“, „e-mail“, „e-mail“, „e-mail“); if (isset ($ _ POST ["e-mail"]) && $ _POST ["e-mail"]! = "") ($ email = $ _POST ["e-mail"]; $ email = mysqli_real_escape_string ($ spojenie, $ email); if (! filter_var ($ email, FILTER_VALIDATE_EMAIL)) (echo "neplatný";) else ($ sql = "SELECT id FROM email WHERE email =" $ email ""; $ result = mysqli_query ($ pripojenie, $ sql); ak ( mysqli_num_rows (výsledok $) == 1) (echo "neplatné";) else (echo "platné";))) if (isset ($ _ POST ["add_email"]) && $ _POST ["add_email"]! = "" ) ($ email = mysqli_real_escape_string (spojenie $, $ _ POST ["add_email"]); $ sql = "INSERT INTO email (e-mail) VALUES (" $ email ")"; if (mysqli_query (pripojenie $, $ sql )) ( ozvena Úspech";) inak (echo" Chyba"; } }

V našom php skripte je to najbežnejší kód, ktorý spracuje požiadavku na príspevok a vytlačí nejaký text na stránku. Ako výsledok AJAX odošle požiadavku do php skriptu, skript ju spracuje a vráti výsledok, AJAX prečíta výsledok a zmení stránku v reálnom čase.

AJAX odovzdá požiadavku POST skriptu prostredníctvom tohto kódu:

$ .ajax ((typ: "POST", url: "email.php", údaje: "email =" + hodnota, úspech: funkcia (msg) (if (msg == "platné") ($ ("# správa ") .html (" Tento email je možné použiť."); email = hodnota;) else ($ (" # správa "). html (" Tento email sa už používa."); } } });

typ – typ požiadavky, POST alebo GET. V našom prípade POST;
url - adresa skriptu, na ktorý je odoslaná požiadavka;
údaje - údaje, ktoré sa prenášajú v žiadosti;
úspech - čo robiť v dôsledku úspešného vykonania žiadosti. V našom prípade sa funkcia volá;

V samotnom skripte sa pri každom zadaní znaku do poľa email vykonáva kontrola prítomnosti emailu v databáze. V skripte $ ("# email"). Keyup (funkcia () ()); ktorý skontroluje stlačenie klávesu v poli s id = "e-mail".
Ako vidíte, kód je pomerne jednoduchý a nevyžaduje špeciálne zručnosti na pochopenie, všetko je spojené so spracovaním udalostí keyup () - stlačenie klávesu, kliknutie () - kliknutie na prvok. Nasledovaný AJAXžiadosť a odpoveď zo skriptu. Pomocou php a ajaxu tak môžete získať takmer nekonečné možnosti vytvárania interaktívnych stránok.
Tento kód netvrdí, že je vysoko kvalitný, ale ak ho vyviniete, pridáte správne overenia na úrovni klienta a servera, zadáte css, potom ho môžete celkom použiť vo svojich projektoch.
Ak máte nejaké otázky, neváhajte napísať komentáre.
Prajem pekný deň a do skorého videnia 🙂

Je to cenovo dostupný a bezpečný spôsob platby za tovar a služby cez internet. Pridajte obsluhu tohto systému do svojho internetového obchodu a prijímajte platby bezodkladne.

Aktualizovaný protokol Yandex.Money 3.0 vám umožňuje používať rôzne typy platieb:

• Vlastne Peniaze Yandex;
• Bankové karty;
• Terminálne platby;
• Mobilné platby.

Okrem toho je na platforme vytvorený postup na pripojenie obchodov 1C-Bitrix: Správa stránok, na Yanedeks. Peniaze sú výrazne zjednodušené. Musíte zanechať žiadosť na webovej stránke Yandex.Money (v komentároch uveďte, že máte webovú stránku s verziou protokolu 3.0.) a vyplňte zjednodušený dotazník (pozostávajúci iba z 3 polí).

Ak chcete pripojiť nový protokol Yandex.Money v internetovom obchode na platforme 1C-Bitrix, musíte vytvoriť nový platobný systém a vybrať operátora

Skontrolujte, či váš web odpovedá cez https. Toto je predpoklad na prijímanie platieb pomocou protokolu Yanedeks.Money 3.0.

Môžete použiť SSL certifikát s vlastným podpisom alebo náš virtuálny stroj, kde je už všetko nakonfigurované.

Ďalej špecifikujte ID obchodu v CPP, Číslo výkladu v CPP ktoré musíte dostať od spoločnosti Yandex pri uzatváraní zmluvy a Heslo obchodu (shopPassword) z profilu obchodu pre Yandex.

Pre každý typ platby si budete musieť vytvoriť svoj vlastný handler a vybrať požadovaný typ platby.

Ak chcete platbu otestovať, musíte do poľa zadať hodnotu „Y“. Testovací mód... Keď odošlete žiadosť o pripojenie protokolu Yandex.Money 3.0, dostanete špeciálny odkaz, pomocou ktorého doplníte zostatok svojej peňaženky na test za 1 000 rubľov.

V nastaveniach modulu Internetový obchod si môžete predefinovať cesty k stránkam s hlásením o úspešnej platbe alebo chybe.

Všetko. Nastavenie je dokončené.

Klienti, ktorí majú pripojenú predchádzajúcu verziu Yandex.Money (1.6), nemusia inovovať na verziu 3.0. Tie. obe verzie sú podporované ako Yandex.Money, tak aj 1C-Bitrix: Site Management. ALE verzia 1.6 nepridáva možnosť používať iné platby ako Yandex.Money. Noví klienti tohto platobného systému sa pripájajú protokolom 3.0.

Pri dodaní produktu 1C-Bitrix: Správa stránok Procesor Yandex.Money (3.0) bude vydaný vo verzii 14.0.0 modulu Online obchod (predaj). Pred vydaním tejto aktualizácie (predpokladáme, že bude vydaná v alfa verzii koncom mesiaca) je možné požiadať o handler prostredníctvom technickej podpory.

Code Injection a XSS (Cross-Site Scripting) útoky sú na prvých dvoch miestach v rebríčku OWASP Top 10 Attack Types. Idú ruka v ruke, pretože XSS, podobne ako množstvo iných typov útokov, závisí od úspechu injekčných útokov. Tento názov skrýva celú triedu útokov, pri ktorých sa údaje vkladajú do webovej aplikácie, aby ju prinútili spustiť alebo interpretovať škodlivý kód tak, ako to chce útočník. Medzi tieto útoky patria napríklad XSS, SQL Injection, Header Injection, Code Injection a Full Path Disclosure. A to je len malá časť.

Injekčné útoky sú hororovým príbehom pre všetkých programátorov. Sú najbežnejšie a najúspešnejšie kvôli ich rozmanitosti, rozsahu a (niekedy) ťažkostiam pri obrane proti nim. Všetky aplikácie musia odniekiaľ brať dáta. Časté sú najmä XSS a UI Redress, preto som im venoval samostatné kapitoly a oddelil som ich od všeobecnej triedy.

OWASP poskytuje nasledujúcu definíciu injekčných útokov:

Príležitosti na vloženie, ako sú SQL, OS a LDAP, sa objavia, keď interpret dostane nedôveryhodné údaje ako súčasť príkazovej požiadavky. Škodlivé údaje môžu oklamať tlmočníka, aby vykonal určité príkazy alebo získal neoprávnené údaje.

SQL injekcia

SQL injection je najbežnejšia a mimoriadne nebezpečná forma injekčných útokov. Je ťažké preceňovať závažnosť tejto hrozby, preto je mimoriadne dôležité pochopiť, čo ovplyvňuje úspešnosť útokov a ako sa proti nim brániť.

Údaje sa teda vložia do webovej aplikácie a potom sa použijú v dotazoch SQL. Zvyčajne pochádzajú z nedôveryhodných vstupných zdrojov, ako sú webové formuláre. Injekciu však možno vykonať z iných miest, ako je napríklad samotná databáza. Programátori často veria v úplnú bezpečnosť svojej základne, pričom si neuvedomujú, že ak bola bezpečná v jednom prípade, vôbec to neznamená, že bude bezpečná aj v budúcnosti. Údaje z databázy by sa mali považovať za nespoľahlivé, kým sa nepreukáže opak, teda kým nebudú overené.

Ak je útok úspešný, útočník môže manipulovať s dotazom SQL tak, aby v databáze vykonal operácie, ktoré vývojári nezamýšľali.

Pozrite sa na tento dotaz:

$ db = new mysqli ("localhost", "username", "heslo", "storedb"); $ výsledok = $ db-> dotaz ("SELECT * FROM transakcií WHERE user_id =". $ _POST ["user_id"]);

Nachádza sa tu množstvo zárubní. Po prvé, nekontrolovali sme obsah údajov POST na správnosť user_id. Po druhé, umožňujeme nedôveryhodnému zdroju, aby nám povedal, ktoré user_id máme použiť: útočník môže podsunúť akékoľvek platné user_id. Možno bol obsiahnutý v skrytom poli formulára, ktorý sme považovali za bezpečný, pretože ho nemožno upravovať (zabúdajúc, že ​​útočníci môžu zadať akékoľvek údaje). Po tretie, neunikli sme user_id a neodovzdali ho dotazu ako viazaný parameter, čo tiež umožňuje útočníkovi vložiť ľubovoľné reťazce, ktoré budú manipulovať s SQL dotazom, keďže sme ho neboli schopní overiť. .

Tieto tri opomenutia sú vo webových aplikáciách veľmi bežné.

Pokiaľ ide o dôveryhodnosť databázy, predstavte si, že sme hľadali transakcie pomocou poľa user_name. Názvy sú široké a môžu obsahovať úvodzovky. Povedzme, že útočník uložil hodnotu vloženého reťazca do jedného z používateľských mien. Keď túto hodnotu znova použijeme v jednom z nasledujúcich dotazov, bude to manipulovať s reťazcom dotazu, keďže sme databázu považovali za spoľahlivý zdroj, neizolovali sme ani neobmedzili napadnutý dotaz.

Venujte pozornosť aj ďalšiemu faktoru vstrekovania SQL: Trvalé úložisko nemusí byť vždy na serveri. HTML 5 podporuje použitie databázy na strane klienta, kde je možné odosielať dotazy pomocou SQL a JavaScript. Na to existujú dve API: WebSQL a IndexedDB. V roku 2010 W3C neodporúčalo zvoliť WebSQL; podporujú ho prehliadače WebKit využívajúce SQLite ako backend. S najväčšou pravdepodobnosťou zostane podpora zachovaná z dôvodu spätnej kompatibility, a to aj napriek odporúčaniu W3C. Ako už názov napovedá, toto API akceptuje SQL dotazy, a preto môže byť cieľom injekčných útokov. IndexedDB je novšia alternatíva, databáza NoSQL (nevyžaduje SQL dotazy).

Príklady vstrekovania SQL

Manipulácia s SQL dotazmi môže slúžiť na tieto účely:

1. Únik údajov.
2. Zverejnenie uložených informácií.
3. Manipulácia s uloženými informáciami.
4. Autorizačný bypass.
5. Injekcia SQL na strane klienta.

Ochrana vstrekovania SQL

Ochrana SQL injection je založená na princípe separácie. Pred použitím údajov v žiadosti je potrebné skontrolovať správnosť jej formy. Pred zahrnutím do dotazu tiež musíte izolovať údaje alebo ich zahrnúť ako parameter prechodu.

Vyšetrenie

Stále opakujem: všetky dáta, ktoré neboli explicitne vytvorené v pôvodnom PHP kóde aktuálnej požiadavky, sú nespoľahlivé. Prísne ich kontrolujte a odmietnite všetko, čo v kontrolách neprejde. Nepokúšajte sa dáta „opravovať“, môžete len mierne, kozmeticky upraviť formát.

K bežným chybám patrí overovanie údajov pre ďalšie aktuálne použitie (napríklad pre zobrazenie na obrazovke alebo výpočty) a nekontrolovanie polí databázy, do ktorých sa následne informácie uložia.

Tienenie

Pomocou rozšírenia mysqli môžete izolovať všetky údaje zahrnuté v dotaze SQL. Robí to funkcia mysqli_real_escape_string (). Rozšírenie pgsql pre PostgresSQL ponúka funkcie pg_escape_bytea (), pg_escape_identifier (), pg_escape_literal () a pg_escape_string (). V rozšírení mssql (Microsoft SQL Server) nie sú žiadne izolačné funkcie a prístup typu addlashes () je neúčinný – potrebujete vlastnú funkciu.

Aby som vám ešte viac sťažil život, poviem, že pri izolácii údajov zadaných do dopytu nemáte priestor na chyby. Jedna chyba a ste zraniteľní voči útoku.

Zhrnúť. Tienenie nie je najlepšou možnosťou ochrany. Stojí za to uchýliť sa k poslednej možnosti. Môže to byť potrebné, ak databázová knižnica, ktorú používate na abstrakciu, umožňuje prispôsobenie holých SQL dotazov alebo častí dotazu bez vynútenia viazania parametrov. V iných prípadoch je najlepšie sa izolácii úplne vyhnúť. Tento prístup je zložitý, náchylný na chyby a líši sa v závislosti od rozšírenia databázy.

Parametrizované dopyty (pripravené výpisy)

Parametrizácia alebo viazanie parametrov je odporúčaný spôsob vytvárania dotazov SQL. Všetky dobré databázové knižnice ho štandardne používajú. Tu je príklad použitia rozšírenia PDO PHP:

if (ctype_digit ($ _ POST ["id"]) && is_int ($ _ POST ["id"])) ($ validatedId = $ _POST ["id"]; $ pdo = nový PDO ("mysql: store.db ") ; $ stmt = $ pdo-> pripraviť ("SELECT * FROM transakcie WHERE user_id =: id"); $ stmt-> bindParam (": id", $ validatedId, PDO :: PARAM_INT); $ stmt-> spustiť () ;) else (// odmietnuť hodnotu id a informovať používateľa o chybe)

Metóda bindParam () dostupná pre výrazy PDO vám umožňuje naviazať parametre na „zástupné symboly“ poskytnuté v pripravenom výraze. Táto metóda akceptuje parametre pre základné dátové typy ako PDO :: PARAM_INT, PDO :: PARAM_BOOL, PDO :: PARAM_LOB a PDO :: PARAM_STR. Pre PDO :: PARAM_STR je to predvolená hodnota, pokiaľ nie je uvedené inak, takže pamätajte aj na ostatné hodnoty!

Na rozdiel od manuálnej izolácie, viazanie parametrov (alebo iná metóda používaná vašou databázovou knižnicou) správne izoluje automaticky viazané údaje, takže si nemusíte pamätať, ktorú funkciu použiť. Konzistentné viazanie parametrov je tiež oveľa spoľahlivejšie, ako sa snažiť zapamätať si, že treba všetko ručne izolovať.

Implementácia princípu najmenších privilégií

Prerušenie úspešnej injekcie SQL je rovnako dôležité ako jej úplné zabránenie. Keď útočník získa možnosť vykonávať SQL dotazy, urobí to ako konkrétny používateľ databázy. Princíp najmenších privilégií zabezpečuje, že všetci používatelia majú len tie privilégiá, ktoré sú absolútne nevyhnutné pre ich úlohy.

Ak má používateľ široké privilégiá, útočník môže zrušiť tabuľky a zmeniť privilégiá iných používateľov vykonaním novej injekcie SQL v ich mene. Aby ste tomu zabránili, nikdy nepristupujte k databáze z webovej aplikácie ako root, správca alebo iný používateľ s vysokými oprávneniami.

Ďalšou aplikáciou princípu je oddelenie úloh čítania a zápisu dát do databázy. Vyberte jedného používateľa s oprávneniami len na zápis a ďalšieho s oprávneniami len na čítanie. Ak je útok zameraný na „čítajúceho“ používateľa, potom útočník nebude môcť manipulovať s údajmi v tabuľke ani ich zapisovať. Prístup môžete obmedziť ešte užšie, čím sa zmierni dopad úspešných útokov SQL injection.

Mnohé webové aplikácie, najmä tie s otvoreným zdrojovým kódom, sú navrhnuté tak, aby používali iba jedného používateľa databázy, ktorého úroveň privilégií sa takmer určite nikdy nekontroluje. Nezabudnite teda na tento bod a nepokúšajte sa spúšťať aplikácie pod účtom správcu.

Vloženie kódu (známe ako Remote File Inclusion)

Vloženie kódu je akákoľvek metóda, ktorá umožňuje útočníkovi pridať zdrojový kód do webovej aplikácie, aby ho bolo možné interpretovať a spustiť. Zároveň nehovoríme o vstrekovaní kódu na stranu klienta, napríklad v JavaScripte sa tu už používajú XSS útoky.

Zdrojový kód môžete vložiť priamo z nedôveryhodného vstupného zdroja alebo prinútiť webovú aplikáciu, aby ho načítala z lokálneho súborového systému alebo externého zdroja, ako je adresa URL. Keď je kód vložený v dôsledku zahrnutia externého zdroja, bežne sa to označuje ako zahrnutie vzdialeného súboru (RFI), hoci samotné RFI je vždy určené na použitie na vloženie kódu.

Hlavné dôvody vloženia kódu sú:

• vynechanie overenia vstupu,
• vloženie nedôveryhodných vstupov do akéhokoľvek kontextu, kde by boli interpretované ako kód PHP,
• hackovanie bezpečnosti úložísk zdrojového kódu,
• vypnutie upozornení na načítanie knižníc tretích strán,
• Prekonfigurovanie servera tak, aby prenášal iné súbory ako PHP do interpreta PHP.

Venujte zvláštnu pozornosť poslednému bodu: v tomto prípade môžu nedôveryhodní používatelia nahrať na server akékoľvek súbory.

Príklady vloženia kódu

PHP má veľa cieľov na vloženie kódu, takže tento typ útoku je na vrchole zoznamu sledovaných programátorov.

Vrátane súboru

Najzrejmejšie ciele pre vstrekovanie kódu sú include (), include_once (), require () a require_once (). Ak nespoľahlivé vstupné údaje umožňujú určiť parameter cesty odovzdaný týmto funkciám, potom bude možné na diaľku ovládať výber súboru, ktorý sa má zahrnúť. Je potrebné poznamenať, že priložený súbor nemusí byť skutočným súborom PHP, môžete použiť súbor akéhokoľvek formátu, ktorý je schopný ukladať textové údaje (t.j. takmer neobmedzene).

Parameter cesty môže byť tiež zraniteľný voči útokom Directory Traversal alebo vzdialenému zahrnutiu súboru. Použitie kombinácií znakov ../ alebo ... v ceste umožňuje útočníkovi prejsť na takmer akýkoľvek súbor, ku ktorému má proces PHP prístup. V predvolenej konfigurácii PHP tiež vyššie uvedené funkcie akceptujú adresy URL, pokiaľ nie je zakázané allow_url_include.

Vyšetrenie

Funkcia PHP eval () akceptuje na vykonanie riadok kódu PHP.

Implementácia regulárneho výrazu

Funkcia PCRE (Perl Compatible Regular Expression) preg_replace () v PHP akceptuje modifikátor e (PREG_REPLACE_EVAL). To znamená náhradný reťazec, s ktorým sa po nahradení bude zaobchádzať ako s PHP kódom. A ak sú v tomto riadku nespoľahlivé vstupy, potom budú môcť vložiť spustiteľný PHP kód.

Chybná logika zahrnutia súboru

Webové aplikácie podľa definície obsahujú súbory potrebné na obsluhu akejkoľvek požiadavky. Ak využijete chyby v logike smerovania, správy závislostí, automatického načítavania a iných procesov, potom manipulácia s cestou požiadavky alebo jej parametrami prinúti server zahrnúť špecifické lokálne súbory. Keďže webová aplikácia nie je navrhnutá na zvládnutie takýchto manipulácií, následky môžu byť nepredvídateľné. Aplikácia napríklad neúmyselne zvýrazní trasy, ktoré sú určené len na použitie v príkazovom riadku. Alebo odhalí iné triedy, ktorých konštruktéri vykonávajú úlohy (radšej takto triedy nenavrhovať, ale aj tak sa to deje). Ktorýkoľvek z týchto scenárov môže zasahovať do backendových operácií aplikácie, čo umožňuje manipuláciu s údajmi alebo útok DOS na operácie náročné na zdroje, ktoré neznamenajú priamy prístup.

Úlohy vkladania kódu

Rozsah úloh je extrémne široký, keďže tento typ útoku umožňuje spustiť ľubovoľný PHP kód podľa výberu útočníka.

Obrana proti vstrekovaniu kódu

Príkazové vstrekovanie

Príklady príkazového vstrekovania

Obrana proti Command Injection

Log Injection (známe ako Log File Injection)

Mnoho aplikácií zhromažďuje protokoly a prihlásení používatelia si ich často prezerajú cez rozhranie HTML. Preto sú protokoly jedným z hlavných cieľov kyberzločincov, ktorí chcú zamaskovať ďalšie útoky, oklamať tých, ktorí si protokoly prezerajú, a potom dokonca spustiť útok na používateľov monitorovacej aplikácie, ktorá slúži na čítanie a analýzu protokolov.

Zraniteľnosť protokolov závisí od mechanizmov kontroly nad zaznamenávaním protokolov, ako aj od zaobchádzania s údajmi protokolu ako s nespoľahlivým zdrojom pri prezeraní a analýze záznamov.

Jednoduchý protokolovací systém dokáže zapisovať textové riadky do súboru pomocou file_put_contents (). Napríklad programátor zaznamená chybné pokusy o prihlásenie ako reťazce v nasledujúcom formáte:

sprintf („Neúspešný pokus o prihlásenie % s“, $ používateľské meno);

Čo ak útočník vo formulári použije názov „AdminnSuccessful login by Adminn“?

Ak je tento riadok vložený do protokolu z nespoľahlivých vstupných údajov, útočník úspešne zamaskuje neúspešný pokus o autorizáciu nevinným zadaním hesla správcu. Podozrenie na údaje sa ešte zníži, ak pridáte úspešný pokus o autorizáciu.

Ide o to, že útočník môže do denníka pridať všetky druhy záznamov. Môžete tiež vložiť vektor XSS a dokonca aj symboly, ktoré sťažujú čítanie záznamov denníka v konzole.

Log implementačné úlohy

Jedným z cieľov implementácie sú interpreti formátu protokolov. Ak analytický nástroj používa regulárne výrazy na analýzu záznamov denníka, aby ich rozdelil na časti a rozptýlil ich do rôznych polí, potom môžete vytvoriť a vložiť taký riadok, ktorý prinúti regulárne výrazy vybrať vložené polia namiesto správnych. . Tento záznam môže byť napríklad zdrojom niekoľkých problémov:

$ username = "iamnothacker! v pondelok 1. januára 00:00:00 + 1000 2009"; sprintf ("Neúspešný pokus o prihlásenie od % s at% s", $ používateľské meno,)

Sofistikovanejšie útoky na vkladanie denníka sa spoliehajú na útoky prechádzajúce cez adresár, aby sa denník zobrazil v prehliadači. Za správnych podmienok vloženie PHP kódu do logovej správy a otvorenie súboru so záznamami v prehliadači povedie k úspešnému vloženiu kódu, ktorý je úhľadne naformátovaný a spustený na žiadosť útočníka. A ak príde na spustenie škodlivého PHP na serveri, potom môžeme len dúfať v efektívnosť oddelenia ochrany, ktorá môže znížiť škody.

Ochrana proti vstrekovaniu guľatiny

Najjednoduchší spôsob, ako filtrovať všetky správy externého denníka, je použiť bielu listinu. Povedzme, že obmedzíme znakovú sadu iba na čísla, písmená a medzery. Správy obsahujúce nepovolené znaky sa považujú za poškodené. Potom sa zobrazí záznam protokolu o možnom pokuse o vloženie súboru protokolu. Toto je jednoduchý spôsob ochrany jednoduchých textových protokolov, keď sa nedá vyhnúť nedôveryhodným vstupným údajom.

Druhým spôsobom ochrany je transformácia častí nespoľahlivých vstupných údajov pomocou systému ako base64, ktorý podporuje obmedzenú množinu znakov, pričom umožňuje ukladať rôzne informácie v textovej forme.

Prechod cesty (známy ako prechod cez adresár)

Path traversal útoky sú pokusy zasahovať do operácií čítania alebo zápisu súborov v backende webovej aplikácie. Robí sa to vložením parametrov, ktoré vám umožňujú manipulovať s cestami súborov zapojených do backendových operácií. Útoky tohto typu teda uľahčujú sprístupnenie informácií a lokálne/vzdialené vkladanie súborov.

Takéto útoky zvážime samostatne, ale ich úspech je založený na prechode cesty. Keďže funkcie opísané nižšie sú špecifické pre manipuláciu s cestami k súborom, má zmysel spomenúť, že mnohé funkcie PHP neakceptujú cesty k súborom v obvyklom zmysle slova. Namiesto toho funkcie ako include () alebo file () berú URI.

Vyzerá to úplne neprirodzene. To však znamená, že nasledujúce dve volania funkcií sú ekvivalentné a používajú absolútne cesty (napríklad bez spoliehania sa na automatické načítanie relatívnych ciest).

include (‘/ var / www / vendor / library / Class.php’); zahrnúť („súbor: ///var/www/vendor/library/Class.php“);

Ide o to, že relatívna cesta je spracovaná na strane (nastavenie include_path v php.ini a dostupných autoloaderoch). V takýchto prípadoch sú funkcie PHP obzvlášť zraniteľné voči mnohým formám manipulácie s parametrami, vrátane nahradenia schémy URI súboru, kde útočník môže vložiť URI HTTP alebo FTP, ak sú na začiatku cesty k súboru vložené nedôveryhodné údaje. Viac si o tom povieme v časti o vzdialených útokoch na inklúziu súborov, no zatiaľ sa zameriame na prechádzanie ciest súborového systému.

Táto chyba zabezpečenia znamená zmenu cesty tak, aby odkazovala na iný súbor. Zvyčajne sa to dosiahne vložením série sekvencií ../ do argumentu, ktorý sa potom pripojí k funkciám alebo sa úplne vloží do funkcií, ako sú include (), require (), file_get_contents () a ešte menej podozrivé (pre niektorých ľudí) funguje ako DOMDocument: : load ().

Pomocou sekvencie ../ útočník prinúti systém vrátiť sa do nadradeného adresára. Takže cesta /var/www/public/../vendor v skutočnosti smeruje do / var / www / vendor. Sekvencia ../ za / public nás vráti do nadradeného adresára, teda do / var / www. Útočník tak získa prístup k súborom umiestneným mimo adresára / public dostupného z webového servera.

Prejdenie cesty sa samozrejme neobmedzuje len na návrat. Nové prvky cesty môžu byť vložené na prístup k podradeným adresárom, ktoré nie sú prístupné z prehliadača kvôli nastaveniam obmedzení v .htaccess. Operácie súborového systému PHP sa nestarajú o konfiguráciu riadenia prístupu k neverejným súborom a adresárom na webovom serveri.

Príklady prechodu cesty

Obrana proti prechodu cesty

XML injekcia

Napriek zavedeniu JSON ako ľahkého prostriedku na prenos údajov medzi serverom a klientom zostáva XML populárnou alternatívou, pričom rozhrania API webových služieb ho často podporujú paralelne s JSON. XML sa tiež používa na výmenu údajov pomocou schém XML: RSS, Atom, SOAP a RDF atď.

XML je všadeprítomné: možno ho nájsť na webových aplikačných serveroch, prehliadačoch (ako preferovaný formát pre požiadavky a odpovede XMLHttpRequest) a rozšíreniach prehliadačov. Vzhľadom na jeho prevalenciu a predvolené spracovanie populárnym syntaktickým analyzátorom, akým je libxml2, ktorý používa PHP v DOM a v rozšíreniach SimpleXML a XMLReader, sa XML stalo cieľom injekčných útokov. Keď sa prehliadač aktívne zúčastňuje výmeny XML, treba mať na pamäti, že oprávnení používatelia môžu používať XSS na prenos požiadaviek XML, ktoré sú v skutočnosti vytvorené útočníkmi.

Vloženie externej entity XML (XXE)

Takéto útoky existujú, pretože knižnice na analýzu XML často podporujú používanie vlastných odkazov na entity. Dozviete sa o štandardnom dokončovaní entity XML, ktorá sa používa na reprezentáciu špeciálnych znakov, ako sú>, & lt; a & apos;. XML vám umožňuje rozšíriť množinu štandardných entít definovaním vlastných entít prostredníctvom samotného dokumentu XML. Môžu byť definované ich priamym zahrnutím do voliteľného DOCTYPE. Rozšírená hodnota, ktorú predstavujú, môže odkazovať na externý zdroj, ktorý sa má zahrnúť. Útoky XXE sa stali populárnymi práve vďaka schopnosti bežného XML ukladať vlastné odkazy, ktoré môžu rásť vďaka obsahu externých zdrojov. Za normálnych okolností by nedôveryhodné vstupy nikdy nemali neočakávane interagovať s naším systémom. A väčšina programátorov XXE takmer určite nepredpokladá útoky XXE, čo je obzvlášť znepokojujúce.

Napríklad definujme novú vlastnú neškodnú entitu:

]>

Dokument XML s touto definíciou môže teraz odkazovať na entitu všade tam, kde sú entity vôbec povolené:

]> Tento výsledok je

Keď analyzátor XML ako PHP DOM interpretuje tento XML, spracuje túto vlastnú entitu hneď po načítaní dokumentu. Preto, keď sa zobrazí výzva na zadanie príslušného textu, vráti toto:

Tento výsledok je úplne neškodný

Je zrejmé, že vlastné entity majú tú výhodu, že predstavujú duplicitný text a XML s kratšími názvami entít. Často sa stáva, že XML musí dodržiavať špecifickú gramatiku a vlastné entity uľahčujú úpravy. Vzhľadom na našu nedôveru k externým vstupom však musíme byť veľmi opatrní s akýmkoľvek XML spotrebovaným našou aplikáciou. Napríklad toto nie je vôbec bezpečná odroda:

]> &harmless;

V závislosti od obsahu požadovaného lokálneho súboru môžu byť údaje použité pri rozširovaní entity. A potom môže byť rozšírený obsah extrahovaný z analyzátora XML a zahrnutý do odchádzajúcich údajov webovej aplikácie na analýzu útočníkom. Napríklad na zverejnenie informácií. Extrahovaný súbor bude interpretovaný ako XML, aj keď neexistujú žiadne špeciálne znaky na spustenie takejto interpretácie. To obmedzuje rozsah zverejnenia obsahu lokálneho súboru. Ak je súbor interpretovaný ako XML, ale neobsahuje platný XML, potom s najväčšou pravdepodobnosťou dostaneme chybu, ktorá zabráni rozšíreniu obsahu. PHP však poskytuje úhľadný trik na obídenie obmedzenia rozsahu tak, že vzdialené požiadavky HTTP ovplyvňujú webovú aplikáciu, aj keď vrátenú odpoveď nemožno odovzdať späť útočníkovi.

Existujú tri bežné metódy analýzy a používania XML v PHP: PHP DOM, SimpleXML a XMLReader. Všetky používajú rozšírenie libxml2, podpora pre externé entity je štandardne povolená. V dôsledku toho má PHP predvolenú zraniteľnosť XXE, ktorú je veľmi ľahké prehliadnuť pri zvažovaní bezpečnosti webovej aplikácie alebo knižnice, ktorá používa XML.

Pamätajte tiež, že XHTML a HTML 5 môžu byť serializované ako dobre sformované XML. To znamená, že niektoré stránky XHTML alebo HTML 5 serializované do XML možno analyzovať ako XML pomocou DOMDocument :: loadXML () namiesto DOMDocument :: loadHTML (). Toto použitie analyzátora XML je citlivé aj na externé vloženie entity XML. Pamätajte, že libxml2 ešte nerozpoznáva ani HTML 5 DOCTYPE, takže ho nemôže overiť ako XHTML DOCTYPES.

Príklady vloženia externých entít XML

Obsah súboru a zverejnenie

Vyššie sme sa pozreli na príklad sprístupnenia informácií, pričom sme si všimli, že vlastná entita XML môže odkazovať na externý súbor.

]> &harmless;

V tomto prípade sa vlastná entita rozšíri o obsah súborov. Keďže všetky takéto požiadavky sa vykonávajú lokálne, umožňuje vám to rozšíriť obsah všetkých súborov, ktoré môže aplikácia čítať. To znamená, že keď je rozšírená entita zahrnutá do odchádzajúcich údajov aplikácie, útočník bude môcť preskúmať súbory, ktoré sú v súkromnom prístupe. V tomto prípade však existuje vážne obmedzenie: súbory musia byť buď vo formáte XML, alebo vo formáte, ktorý nepovedie k chybe analyzátora XML. Ide však o to, že toto obmedzenie možno v PHP úplne ignorovať:

]> &harmless;

PHP poskytuje prístup k wrapperu vo forme URI, jedného z protokolov akceptovaných štandardnými funkciami pre prácu so súborovým systémom: file_get_contents (), require (), require_once (), file (), copy () a mnohé ďalšie iní. PHP wrapper podporuje množstvo filtrov, ktoré možno použiť na konkrétny zdroj, takže výsledky sú vrátené volaním funkcie. Vo vyššie uvedenom príklade aplikujeme filter convert.base-64-encode na cieľový súbor, ktorý chceme čítať.

To znamená, že útočník môže čítať akýkoľvek súbor prístupný PHP, bez ohľadu na formát textu. Stačí len dekódovať dáta prichádzajúce z aplikácie a potom ich beztrestne rozoberať. Aj keď to priamo nepoškodzuje koncových používateľov alebo backend aplikácie, umožňuje útočníkom dobre sa pozrieť na štruktúru aplikácie v snahe nájsť ďalšie slabé miesta. Navyše riziko odhalenia útočníkov je minimálne.

Obísť kontrolu prístupu

Prístup je riadený rôznymi spôsobmi. Keďže útoky XXE sa vykonávajú na backende webovej aplikácie, nebude fungovať použitie relácie aktuálneho používateľa. Útočník však stále môže obísť riadenie prístupu na serveri pomocou požiadaviek z lokálneho servera. Zvážte primitívne riadenie prístupu, ako je toto:

if (isset ($ _ SERVER ["HTTP_CLIENT_IP"]) || isset ($ _ SERVER ["HTTP_X_FORWARDED_FOR"]) ||! in_array (@ $ _ SERVER ["REMOTE_ADDR"], pole ("127.0.0.1", " :: 1 ",))) (hlavička (" HTTP / 1.0 403 Forbidden "); exit (" Nemáte povolený prístup k tomuto súboru. ");)

Táto časť PHP, podobne ako nespočetné množstvo ďalších podobných, obmedzuje prístup k určitým súborom PHP na lokálnom serveri, t. j. localhost. Útok XXE na front-end aplikácie však útočníkovi poskytne presné poverenia potrebné na obídenie tohto riadenia prístupu, pretože všetky požiadavky HTTP na analyzátor XML budú odosielané z localhost.

]> &harmless;

Aj keby bolo prezeranie denníkov obmedzené na miestne požiadavky, útočník by stále mohol získať denníky. To isté platí pre rozhrania údržby alebo správy, ktoré sú podobne obmedzené.

DOS útoky

Na útoky DOS môžete použiť takmer čokoľvek, čo určuje spotrebu zdrojov servera. Vložením externej entity XML môže útočník zadávať ľubovoľné požiadavky HTTP, ktoré za správnych podmienok vyčerpávajú zdroje servera.

O ďalších potenciálnych použitiach útokov XXE v ​​systéme DOS si povieme neskôr, pokiaľ ide o rozšírenia entity XML.

Ochrana pred externým vložením entity XML

Tieto útoky sú veľmi obľúbené, preto vás prekvapí, aké ľahké je brániť sa im. Keďže DOM, SimpleXML a XMLReader sa spoliehajú na libxml2, na zakázanie používania externých entít stačí použiť funkciu libxml_disable_entity_loader (). Toto však nezakáže vlastné entity preddefinované v DOCTYPE, pretože nepoužívajú externé zdroje, ktoré vyžadujú požiadavku HTTP alebo operáciu súborového systému.

$ oldValue = libxml_disable_entity_loader (pravda); $ dom = nový dokument DOMD (); $ dom-> loadXML ($ xml); libxml_disable_entity_loader ($ oldValue);

Toto je potrebné vykonať pre všetky operácie, ktoré zahŕňajú načítanie XML z reťazcov, súborov alebo vzdialených URI.

Tam, kde aplikácia nikdy nevyžaduje externé entity a pre väčšinu jej požiadaviek, môžete vo všeobecnosti zakázať načítanie externých zdrojov na globálnejšej úrovni. Vo väčšine prípadov je to oveľa vhodnejšie na identifikáciu všetkých bodov zaťaženia XML, keďže mnohé knižnice majú prirodzenú zraniteľnosť voči útokom XXE:

libxml_disable_entity_loader (pravda);

Nezabudnite vrátiť hodnotu TRUE zakaždým, keď dočasne povolíte načítanie externých zdrojov. Možno ho budete potrebovať pri neškodných úlohách, ako je konverzia Docbook XML do HTML, kde šablóny so štýlmi XSL závisia od externých entít.

Funkcia deaktivácie libxml2 však nie je všeliekom. Analyzujte ďalšie rozšírenia a knižnice PHP, ktoré analyzujú alebo inak spracúvajú XML, aby ste našli ich „prepínače“ na používanie externých entít.

Ak to nie je možné, potom dodatočne skontrolujte, či dokument XML deklaruje DOCTYPE. Ak áno, a ak sú externé entity deaktivované, potom jednoducho vyhoďte dokument XML, odmietnite nedôveryhodný prístup XML k potenciálne zraniteľnému analyzátoru a zaznamenajte ho ako pravdepodobný útok. Toto je nevyhnutný krok, pretože nebudú existovať žiadne ďalšie znaky - žiadne chyby, žiadne výnimky. Zabudujte toto overenie do svojho bežného overenia vstupu. Táto metóda však nie je ani zďaleka ideálna, preto sa dôrazne odporúča zásadne vyriešiť problém externých subjektov.

/ ** * Pokus o rýchlu detekciu * / $ zbalenýXML = preg_replace ("/ [: medzera:] /", "", $ xml); if (preg_match ("/

Je tiež vhodnejšie okamžite odstrániť podozrivé údaje, ktoré môžu byť výsledkom útoku. Prečo ďalej pracovať s niečím, čo vyzerá nebezpečne? Takže kombinácia dvoch vyššie uvedených opatrení vám umožňuje vopred ignorovať zjavne škodlivé údaje a zároveň sa chrániť v prípade, že údaje nemožno odstrániť (napríklad ak ide o knižnice tretích strán). Musíte tiež odstrániť údaje, pretože libxml_disable_entity_loader () nezakáže všetky vlastné entity, ale iba tie, ktoré odkazujú na externé zdroje. Čo ponecháva možnosť útoku XML Entity Expansion.

Rozšírenie entity XML

Tento útok je veľmi podobný útoku XML Entity Injection. V tomto prípade je však dôraz kladený na útok DOS s pokusom o vyčerpanie zdrojov serverového prostredia cieľovej aplikácie. DOCTYPE XML vytvára vlastnú definíciu entity, ktorá napríklad dokáže generovať štruktúry XML v pamäti, ktoré sú oveľa väčšie ako originál. To môže zaplniť pamäť a znížiť výkon servera. Tento útok sa vzťahuje aj na HTML 5 serializáciu XML, ak táto nie je rozpoznaná ako HTML rozšírením libxml2.

Príklady rozšírenia entity XML

Existuje niekoľko spôsobov, ako rozšíriť vlastné entity XML na požadované vyčerpanie zdrojov servera.

Všeobecné rozšírenie entity

Iný názov je „útok štvorcového zväčšenia“. Vlastná entita je definovaná ako veľmi dlhý reťazec. Ak ho znova použijete v dokumente, zakaždým sa rozrastie, v dôsledku čoho štruktúra XML spotrebuje oveľa viac pamäte RAM v porovnaní s pôvodným XML.

]> Teraz zahrňte veľakrát, aby ste rozšírili veľkosť tejto štruktúry XML v pamäti Pokračuj v tom ... ...

Ak nájdete rovnováhu medzi veľkosťou riadku vlastnej entity a množstvom použitia v tele dokumentu, môžete vytvoriť súbor XML alebo riadok, ktorý po rozbalení bude predpovedať spotrebu pamäte servera. Ak to naplníte takýmito opakujúcimi sa otázkami, tak vyjde poriadny DOS útok. Nevýhoda prístupu: Pôvodné XML musí byť tiež dosť veľké, pretože spotreba pamäte závisí od jednoduchého multiplikačného efektu.

Rekurzívna expanzia entity

Zatiaľ čo všeobecné rozšírenie vyžaduje použitie pôvodne veľkého XML, rekurzívne rozšírenie poskytuje oveľa vyšší faktor zväčšenia. Táto metóda je založená na exponenciálnom rozlíšení (rozlíšení) množín malých entít tak, aby sa výrazne zväčšovali. Dáva zmysel, že táto technika je často označovaná ako XML bomba a útok miliardy smiechu.

]> Vybuchnúť za 3 ... 2 ... 1 ...

XML Bomb nevyžaduje veľké XML, ktorého veľkosť môže byť niekedy obmedzená aplikáciou. Útok vedie k tomu, že pamäť je upchatá textom, ktorého veľkosť je 2 ^ 100-krát väčšia ako veľkosť pôvodnej hodnoty entity -. Skutočná BOMBA!

Rozšírenie vzdialenej entity

Oba vyššie uvedené útoky využívajú lokálne definované entity v XML DTD. Útočník je však schopný určiť entitu na diaľku, ak analyzátor XML môže vykonávať externé požiadavky HTTP. Ako sme videli v popise XXE (XML External Entity Injection), táto funkcia by mala byť zablokovaná ako základné bezpečnostné opatrenie. Keď sa teda bránime XXE, bránime sa aj tomuto typu útoku.

V každom prípade: Pre tento útok musí analyzátor XML vykonať externé požiadavky HTTP na získanie rozšírenej hodnoty zodpovedajúcich entít. Na druhej strane budú nezávisle definovať nové externé entity, na ktoré bude musieť syntaktický analyzátor zadávať ďalšie požiadavky HTTP. Pár neškodne vyzerajúcich dopytov sa teda rýchlo vymkne kontrole, čím sa zvýši zaťaženie dostupných zdrojov servera, čo môže v dôsledku toho viesť k rekurzívnej expanzii entít a zhoršiť situáciu.

]> 3..2..1 ... & kaskáda

Vyššie uvedený kód tiež umožňuje jemnejší útok DOS: externé požiadavky musia byť prispôsobené lokálnej aplikácii alebo akejkoľvek inej aplikácii, ktorá zdieľa zdroje servera. Výsledkom je, že systém zaútočí sám na seba: pokusy o vyriešenie (vyriešenie) externých entít pomocou analyzátora XML vyvolávajú odosielanie mnohých požiadaviek do lokálnych aplikácií a spotrebujú veľa zdrojov servera. Tento útok možno použiť na zosilnenie účinku útoku XXE, aby sa ďalej vykonal útok DOS.

Ochrana rozšírenia entity XML

Metódy ochrany sú rovnaké ako v prípade jednotlivých útokov XXE. Je potrebné zakázať rozlíšenie (rozlíšenie) vlastných XML entít do lokálnych súborov, ako aj funkcií; zakázať externé požiadavky HTTP pomocou nasledujúcej funkcie, ktorá sa globálne vzťahuje na všetky rozšírenia PHP XML založené na libxml2.

libxml_disable_entity_loader (pravda);

PHP však neimplementuje zjavný prostriedok na úplné zakázanie definície vlastných entít pomocou XML DTD cez DOCTYPE. PHP definuje konštantu LIBXML_NOENT a existuje aj verejný majetok DOMDocument :: $ substituEntities, ale tie situáciu nezlepšujú. Zdá sa, že musíte použiť svoje vlastné sady riešení.

libxml2 má vrodenú neznášanlivosť na rekurzívny rozklad entít, takže váš protokol o chybách bude ozdobený ako vianočný stromček. Preto nemáme žiadnu osobitnú potrebu implementovať špecifickú ochranu proti rekurzívnym entitám; aj keď je potrebné niečo urobiť v prípade, že libxml2 má recidívu.

Primárnou novou hrozbou je teda hrubá XML bomba alebo generické rozšírenie entity. Tieto útoky nevyžadujú miestne alebo vzdialené systémové volania, ani rekurziu entít. Jediným riešením je v podstate odstrániť alebo vyprázdniť XML, ak obsahuje DOCTYPE. Bezpečnejšie je mazanie, ak nepotrebujeme použiť DOCTYPE a ak sme ho nedostali zo spoľahlivého dôveryhodného zdroja, teda cez overené HTTPS pripojenie. V opačnom prípade musíme vytvoriť nejakú vlastnú logiku, pretože PHP nám neposkytuje funkčnú možnosť vypnúť DTD. Za predpokladu, že môžete zavolať libxml_disable_entity_loader (TRUE), potom bude nasledujúci kód bezpečný, pretože entita sa nerozšíri, kým nebude mať prístup k hodnote uzla infikovaného rozšírením. A to sa počas tejto kontroly nestane.

$ dom = nový dokument DOMD; $ dom-> loadXML ($ xml); foreach ($ dom-> childNodes ako $ child) (if ($ child-> nodeType === XML_DOCUMENT_TYPE_NODE) ​​​​(vyhodiť novú \ InvalidArgumentException ("Neplatný XML: Zistilo sa použitie nelegálneho DOCTYPE");))

Samozrejme, stále musíte byť na bezpečnej strane a nastaviť libxml_disable_entity_loader na hodnotu TRUE, aby sa odkazy na externé entity nevyriešili pri prvom načítaní XML. Toto môže byť jediné zabezpečenie, kde syntaktický analyzátor XML nezávisí od knižnice libxml2, pokiaľ syntaktický analyzátor nemá komplexnú sadu možností na riadenie rozkladu entity.

Ak máte v úmysle použiť SimpleXML, majte na pamäti, že overený objekt DOMDocument môžete importovať pomocou funkcie simplexml_import_dom ().