V minulom blogu sa na mna zviezla spŕška kritiky za nie úplné používanie best practices. Moja chyba.  Teraz si dáme viac teórie ako praxe a svoje zaváhanie napravím, snáď. Pokračujeme teda pri našom uploade, a v skratke si vysvetlíme, aké teda tie “best practices” pri písaní webu, v našom prípade pri písaní uploadu, sú.

Ako prvé by nám malo byť jasné, čo všetko sa môže stať, ak tomu nepriradíme výraznejšiu váhu, a vykašleme sa na zabezpečenie. Ak sa na to pozrieme, tak vplyv tejto chyby je naozaj rozsiahly, no je tu nízka pravdepodobnosť, takže ak to zaradíme do priečinka “Stredne nebezpečné”, tak myslím, že sa veľmi nezmýlime. V minulom blogu ste mali niekoľko názorných príkladov z praxe. Ale určite to nie sú všetky.

Aké sú teda riziká ?

• Útočník môže poškodiť náš web
• Ak nemáme zabezpečenú funkciu, ktorá chráni server pred vykonávaním shell príkazov pomocou napríklad “.php” scriptov, môže si to “odniesť” aj konfigurácia servera
• Útočník môže vložiť na web kód, za pomoci ktorého spustí inú formu útoku, napríklad XSS
• Útočník môže na web vložiť falošnú stránku, takzvanú “phishing page” a vydávať sa za prevádzkovateľa webu
•  Taktiež je možnosť, že sa server obete premení na warez, alebo web plný “vírusov”
• Nahraný škodlivý súbor môže napríklad aj odstaviť z prevádzky anti-vírusovú ochranu či iné real-time procesy

Rizík je tu skutočne dosť, možno som na nejaké zabudol, ale myslím, že pre ozrejmenie problematiky to stačí.

Slabé alebo zlé zabezpečenie…

Tu hneď spomeniem príklad z minulého blogu, ktorý mi ľudia najviac vytýkali. Áno, mám na mysli používanie black-listu namiesto white-listu prípon.

Pre naše vtedajšie demonštračné účely to stačilo, no chápem rozhorčenie zo strany iných vývojárov, takže si túto problematiku rozmeníme na drobné, pekne po poriadku.

Prečo nepoužívať black-list?

• Je tu obrovská možnosť, že zabudnete na nejaké prípony, prípadne existujú prípony, o ktorých ste ani nevedeli. Sám som na niektoré zabudol. Prípony ako .php5 .phtml .php4 a podobne nie sú bežné a preto s nimi ľudia často nerátajú.
• Niekedy stačí ak namiesto .php prípony napíšeme .pHP a script dostaneme na server
• Niekedy sa nám môže podariť obísť zabezpečenie jednoduchým pridaním bodiek a medzier za príponu súboru. Príklad ( script.php…. ….. … ..; script.php.) …
• Server môže použiť prvú príponu, ktorá nasleduje za bodkou a podľa nej zistiť, či je súbor bezpečný alebo nie. Toto však dokážeme oklamať relatívne jednoducho a to tým, že súbor pomenujeme napríklad script.php.jpg
• ďalšou možnosťou ako prepašovať súbor na server je použiť najslávnejší znak NULL (0x00) po prípone, ktorá je zakázaná a pred príponou, ktorá je povolená. Pri spracovaní súboru sa táto prípona za znakom NULL odstráni. Príklad script.php%00.jpg

Týchto dier je ešte oveľa viac, ale sám nepoznám všetky. Takže tie, ktoré poznám, som vám napísal, ostatné si verím jednoducho dohľadáte na internete.

Prečo nepoužívať LEN white-list

White-list patrí k “best practices”, ale sám o sebe nestačí. Veľa spôsobov, akými sa dá obísť, je totožných s black-listom, no je bezpečnejší.

Rovnako ako pri black-liste môžete na príponu zabudnúť, tak tu sa môžete pomýliť a pridať príponu, ktorá tam nemá čo robiť. Príklad shtml, ktorá povolí útok pomocu SSI. Viac o SSI na tomto linku: https://www.owasp.org/index.php/Server-Side_Includes_(SSI)_Injection

Prečo nepoužívať Content-Type z Headeru?

Prečo nepoužívať overenie pre Content-Type, sme si povedali aj názorne ukázali v minulom blogu, takže to môžem myslím vynechať.

Tipy ako sa brániť, alebo ako spraviť aplikáciu bezpečnejšou

• Nikdy nenechajte váš skript akceptovať súbor bez overenia prípony pomocou white-listu
• Ideálne je, ak skontrolujete, čo obsahuje názov súboru a odstránite všetky znaky, ktoré tam nemajú čo hľadať ako napríklad: “;”, “:”, “>”, “<”, “/” ,”\”,”$”,”?”… A v názve zostanú len alfanumerické znaky s jednou bodkou.  Príklad regexpu ( [a-zA-Z0-9]{1,200}\.[a-zA-Z0-9]{1,10})
• Ideálne je limitovať dĺžku názvu súboru na maximálne 255 vrátane prípony
• Ideálne je premenovať súbor po uploade, napríklad použiť SHA1 hash názvu ku ktorému pripojíte čas a dátum, kedy bol súbor nahratý
• Priečinok, do ktorého uploadujete súbory, by nemal byť priamo prístupný!
• Nastavte si rovnako tak kontrolu na veľkosť súboru alebo jeho rozmery (ak ide o obrázok), stanovte si maximálne rozmery a eliminujte možnosť  warezu
• Používajte CSRF (Cross Site Request Forgery) tokeny pri posielaní formulárov (toto platí aj pre obyčajné formuláre)
• Chráňte súbory pred prepísaním iným súborom s rovnakým hashom
• Skúste použiť skôr POST metódu než PUT (GET)
• Ak je to možné, zaznamenávajte si akcie používateľov. Ľahšie sa dopátrate k nekalým aktivitám.

Tipov by tu mohlo byť ešte o niečo viac, no myslím, že ak dodržíte tie čo som vám tu napísal, všetko by malo byť v poriadku, až kým niekto nepríde s novým spôsobom ako vám uškodiť.

Tento článok je viac teoretický, lebo po minulej skúsenosti, keby som chcel ku všetkému tomuto dať príklad a napísať kompletne celý blog s príkladmi a každú jednu možnosť, tak by mal blog minimálne 15 strán.

Ďalej sa budem venovať XSS a hlavným problémom, ktoré môžu spôsobiť, to už bude aj s príkladmi.