Pri súčasných požiadavkách na webové aplikácie je stále viac kladený dôraz na ich zabezpečenie ako zo strany užívateľov, tak od ich samotných prevádzkovateľov, oprávnený. Vzhľadom k stále častejšie sa opakujúcim útokom na webové stránky je potrebné, aby mal každý správca stránok vedomosť o základných bezpečnostných opatreniach na internej a verejnej časti webu, ktoré by pri prevádzkovaní akejkoľvek webovej stránky mali byť dodržiavané. Napriek tomu, že mnoho správcov prehľad o základných bezpečnostných opatreniach má, ich dodržiavanie často z rôznych dôvodov absentuje. Jedným z dôvodov môže byť fakt, že napríklad v porovnaní s funkčným a dizajnovým upgradom stránok nieje ten bezpečnostný navonok vidieť (kým sa stránky nestanú terčom útoku). Ako zo skúsenosti z prevádzkovania služby Skener webu, tak z osobných skúsenosti z penetračných testov webových aplikácií prinášame základné bezpečnostné pravidlá, ktoré by každý tvorca a správca stránok stránok mal mať na stránkach ošetrené.

1. Pravidelné updatovanie a sledovanie zraniteľností
Bez ohľadu na to, aký CMS (Content Management System), webový server či doplnky používate, je potrebné mať všetky verzie pravidelne updatované. Zraniteľnosti pre jednotlivé verzie softwaru niesú žiadne internetové tajomstvo a práve nedôslednosť pri updatoch je často využívaná pri plošných útokoch. Je žiadúce myslieť na pravidelné updaty a priebežne sledovať mailové konferencie jednotlivých SW produktov, ktoré využívate. Každá zraniteľnosť je označená mierou rizika, ktorá môže byť pri rozhodovaní o update smerodajná. Tzv. CVSS (Common Vulnerability Scoring System) je všeobecne uznávaná metóda na hodnotenie závažnosti zraniteľností. Zraniteľnosti označuje v rozmedzí od 0-3.9 ako nízke riziko, od 4.0-6.9 ako stredné a od 7.0-10 ako vysoké. Podľa závažnosti zraniteľnosti môžete zvážiť nakoľko je rýchly update potrebný. Každá zraniteľnosť podlieha označenie podľa CVE (Common Vulnerabilities and Exposures) systému a preto je každá označená unikátnym CVE ID s jej stručným popisom. Pokiaľ teda pravidelné updaty nerobíte, je dobré a vhodné sledovať tieto databázy a fóra zaoberajúce sa súčasnými hrozbami, aby ste prípadnú zraniteľnosť čo najskôr v systéme detekovali a opatchovali. V prípade, že nejaké SW doplnky na webe už nevyužívate, je vhodné a dobré ich odstrániť.

2. Nezverejňovanie informácií o použitých platformách
Na čom váš web beží a aké ďalšie softwarové doplnky využívate nieje informácia, ktorú by ste mali s užívateľmi/útočníkmi zdieľať. Dôvod je viacmenej načrtnutý v prvom bode. Na každú konkrétnu verziu sa vzťahujú zraniteľnosti a pravdepodobnosť, že váš web bude napadnutý/nakazený známou zraniteľnosťou je niekoľko násobne vyššia, ako že bude nakazený zraniteľnosťou neznámou (ak teda váš web nieje natoľko zaujímavý, aby bol terčom sofistikovaného, presne miereného útoku). Miest, kde by ste sa mali zverejňovaniu týchto informácií vyhýbať je niekoľko. Vo fingerprintoch servera ako sú hlavičky, poradie zložiek v hlavičkách a podobne. K vyzradeniu takýchto informácií môže dojsť aj v chybových hláškach či zdrojovom kóde. Užívateľ túto informáciu nepotrebuje a útočníkovi ju dať nechcete. Všetky výstupy ktoré by túto informáciu mohli obsahovať by mali byť ošetrené.

3. Šifrované spojenie a certifikáty
Šifrované spojenie sa postupne stáva štandardom na všetkých weboch, kde prebieha výmena informácií, ktoré by cestou mohli byť odchytené a zneužité treťou osobou (man-in-the-middle attacks). Šifrované spojenie je žiadúce najmä na rozhraniach, kde prebieha výmena citlivých informácií - prihlasovanie sa do administrátorského či užívateľského rozhrania, zadávanie osobných informácií, objednávanie cez e-shopy atď. Užívatelia, ktorí sa chcú pripojiť šifrovaným spojením na weby, ktoré používajú certifikáty neplatné, vydané neuznávanou certifikačnou autoritou či napríklad vydané pre iný subjekt sú na tento fakt v prehliadači upozornení. Okrem toho, že u užívateľov to môže vyvolať pocit neistoty, môžu začať považovať schvaľovanie nesprávnych certifikátov za bežnú prax čo sa im nemusí vyplatiť napríklad pri vstupe do služieb internetového bankovníctva. Na weboch je doporučené používať platný certifikát vydaný uznávanou certifikačnou autoritou pre konkrétnu doménu. Pre zaistenie, že užívateľ bude z prehliadača vstupovať do webovej aplikácie stále cez HTTPS je vhodné implementovať bezpečnostný mechanizmus HSTS (HTTP Strict Transport Security). Tento bezpečnostný doplnok, ktorý je zahrnutý v hlavičke odpovedi zo servera v poli "Strict-Transport-Security" zabezpečí, že prehliadač bude zasielať všetku komunikáciu cez HTTPS.

4. Neverejne dostupné rozhrania a informácie
To, čo je prístupné pre užívateľov a to, čo je prístupné pre adminov prípadne iné osoby, ktoré nejakým spôsobom stránky administrujú, by malo byť oddelené. Prihlasovanie do administrácie webu či interné dokumenty by nemali byť užívateľom dostupné a prístup k nim by mal byť obmedzený napríklad iba z určitého adresného rozsahu alebo cez VPN. Prihlasovanie do administrácie webu z verejného rozhrania v kombinácií s absenciou ochrany proti brute force a neexistujúcou politikou hesiel predstavuje pre webové stránky kritické riziko.

5. Ošetrenie všetkých vstupov
Aj napriek filtrom na strane prehliadača je nevyhnutné ošetrenie vstupov aj na webe. Čím je web rozsiahlejší, tým viac pozornosti vyžaduje kontrola vstupov do aplikácie. Či už ide o prihlasovanie sa do aplikácie, vyhľadávanie v rámci aplikácie alebo polia pre vkladanie/zmenu užívateľských údajov. V každom poli by mali byť escapované znaky čím sa predíde ako pokusom o dotazovanie na SQL, tak útokom typu XSS. Jedným zo spôsobov, ako zabezpečiť obranu na strane užívateľa, je vloženie príznaku X-XSS-Protection do hlavičiek. Tento príznak vynucuje použitie XSS filtru, ktorý síce v prehliadačoch je väčšinou defaultne nastavený, ale užívateľ ho môže vypnúť.

6. Využívanie autorizačných tokenov
Cross-site Request Forgery (CSRF) umožňuje napadnutie stránok sfalšovaním požiadavky webovej aplikácie tak, že server nerozlíši, či požiadavok prišiel od legitímnej osoby alebo od útočníka. Obranou môže byť napríklad sledovanie refereru HTTP hlavičky, prípadne sledovanie HTTP Origin. Oboje však môžu byť pre časť užívateľov obmedzujúce. Preto je najlepším spôsobom obrany použitie autorizačného tokenu. Token by sa mal generovať pre každý formulár osobitne. Po zaslaní požiadavku sa hodnota tokenu porovná s predtým uloženou hodnotou a v prípade zhody požiadavok prejde. Token by sa mal meniť v závislosti od užívateľa a formulára. Kvôli možnému oklamaniu užívateľa prekrytím stránky a vynútením prepísaním tokenu pod zámienkou napríklad CAPTCHY, je dobré doplniť použitie autorizačných tokenov aj o hlavičky X-Frame-Options. Tento príznak obmedzí alebo úplne vylúči vloženie stránok do a zároveň tak chráni stránky proti Clickjackingu.

7. Silná politika hesiel
Vo všetkých užívateľských a administrátorských účtoch by mala byť implementovaná dostatočne silná politika hesiel. Požiadavky na minimálne 8 znakov dlhé heslo obsahujúce malé a veľké písmena, čísla a špeciálne znaky môže mať u užívateľoch formu aspoň doporučovacej povahy. V administrátorských účtoch by mala mať už vynucovaciu povahu. S tým súvisí tiež nakladanie s heslami tak, aby neboli uložené v čitateľnej podobe a aby sa neposielali nikde cez Internet v otvorenej podobe (napr. do mailu).

8. Implementácia DNSSECu
S webovou stránkou priamo súvisí aj zabezpečenie DNS (Systému doménových men). DNSSEC zabezpečí úplnosť a integritu informácií poskytovaných z DNS a pomôže tak zvýšiť dôveryhodnosť svojich informačných zdrojov a služieb. Pri zavedení DNSSECu je potrebné spolupracovať s vaším registrátorom, ktorý musí časť DNSSEC údajov o vašej doméne umiestniť do registra domén. Pre zavedenie DNSSECu na vašej doméne je tak nevyhnutné, aby registrátor správu DNSSEC údajov umožňoval. Viac o implementácií DNSSECu a registrátoroch, ktorí DNSSEC podporujú, nájdete na stránkach dnssec.cz.

9. Bezpečné a správne implementované cookies
Cookies obsahujú informácie o užívateľskom sedení a stávajú sa tak citlivým prvkom každej webovej aplikácie. Spôsobov implementácie cookies je niekoľko. Hodnota cookie by sa však mala meniť v závislosti od užívateľa a sedenia a zároveň by mala byť nepredvídateľná. Tiež je potrebné myslieť na ukončenie platnosti sedenia v prípade vypnutia prehliadača či odhlásenia užívateľa a akceptáciu iba cookies zasielané serverom (nie klientom). Netreba tiež opomenúť bezpečnostné flagy "HttpOnly" a "secure". Flag "secure" zabezpečí, že cookies budú zasielané iba cez šifrované spojenie a zabráni tak odchyteniu v clear texte. Flag "HttpOnly" zase zabezpečí, že cookie prejde iba cez požiadavok typu http alebo https. Ku cookies je totiž tiež možné pristupovať prostredníctvom Javascriptu. Ak útočník na vašich stránkach zraniteľnosť typu XSS nájde, flag "HttpOnly" znemožní získanie cookie prihlásených klientov.

10. Na čo ešte netreba zabudnúť:
a.) V prípade webovej aplikácie je nutné myslieť aj na otvorené porty. Pokiaľ nejaké služby na portoch nevyužívate, alebo by mohli slúžiť ako brána prieniku k vám, je lepšie tieto porty uzavrieť. Viac informácií o detekcii otvorených portov sa dočítate v našom návode "Ako detekovať a zabezpečiť otvorené služby".
b.) Čo tiež môže na webe spôsobiť nechcené problémy a komplikácie je početné prelinkovanie s inými, hlavne cudzími webmi, ktoré môžu cez priamy odkaz na web šírit nákazu. Preto je počet externých URL na webe vhodné zredukovať na minimum.
c.) V prípade, že na web môže užívateľ uploadovať nejaký súbor, správca webu by mal ošetriť možný typ a maximálnu veľkosť súboru, ktorý je možné uploadovať.