10 najpogostejših ranljivosti spletne varnosti

Za vse preveč podjetij šele po prišlo do kršitve varnosti da najboljše prakse spletne varnosti postanejo prednostna naloga. V letih, ko delam kot strokovnjak za informacijsko varnost, sem vedno znova videl, kako nejasen je svet varnostnih vprašanj spletnega razvoja za toliko mojih kolegi programerji .

Učinkovit pristop k grožnjam spletne varnosti mora biti po definiciji proaktiven in obramben. V ta namen je ta prispevek namenjen vzbujanju varnostne miselnosti in upam, da bralcu vbrizga zdravo dozo paranoje.

Ta priročnik se osredotoča zlasti na 10 pogostih in pomembnih pasti spletne varnosti, ki se jih je treba zavedati, vključno s priporočili, kako jih je mogoče ublažiti. Poudarek je na 10 najboljših spletnih ranljivosti identificiral Odprti projekt zaščite spletnih aplikacij (OWASP) , mednarodna, neprofitna organizacija, katere cilj je izboljšati varnost programske opreme po vsem svetu.

Malo začetnika za kibernetsko varnost, preden začnemo - avtentikacija in avtorizacija

Ko govorim z drugimi programerji in strokovnjaki za informacijsko tehnologijo, pogosto naletim na zmedo glede razlikovanja med pooblastilom in preverjanjem pristnosti. In seveda, dejstvo okrajšava prist se pogosto uporablja za oboje, pomaga poslabšati to pogosto zmedo. Ta zmeda je tako pogosta, da bi bilo morda to težavo treba vključiti v to objavo kot 'Common Web Vulnerability Zero'.

Preden nadaljujemo, razjasnimo razliko med tema dvema izrazoma:

• Preverjanje pristnosti: Preverjanje, ali je oseba (ali se vsaj zdi, da je) določen uporabnik, saj je pravilno navedla svoje varnostne poverilnice (geslo, odgovore na varnostna vprašanja, skeniranje prstnih odtisov itd.).
• Dovoljenje: Potrditev, da ima določen uporabnik dostop do določenega vira ali mu je dano dovoljenje za izvedbo določenega dejanja.

Povedano drugače, preverjanje pristnosti ve, kdo je entiteta, medtem ko dovoljenje je vedeti, kaj lahko dana entiteta naredi. S tem v mislih pojdimo na 10 najboljših vprašanj internetne varnosti.

Pogosta napaka spletne varnosti # 1: Napake vbrizgavanja

Napake vbrizgavanja so posledica klasične neuspešnosti filtriranja nezaupljivega vnosa. To se lahko zgodi, ko nefiltrirane podatke posredujete strežniku SQL (vbrizgavanje SQL), brskalniku (XSS - o tem bomo govorili kasneje ), na strežnik LDAP (vbrizgavanje LDAP) ali kamor koli drugje. Težava je v tem, da lahko napadalec tem entitetam vbrizga ukaze, kar povzroči izgubo podatkov in ugrabitev brskalnikov odjemalcev.

Vse, kar vaša aplikacija prejme iz nezaupljivih virov, je treba filtrirati, po možnosti na belem seznamu. Črnega seznama skoraj nikoli ne bi smeli uporabljati, saj je njegovo pravilno uresničitev zelo težko in ga je običajno enostavno obiti. Protivirusni programski izdelki običajno ponujajo zvezdne primere neuspelih črnih seznamov. Ujemanje vzorcev ne deluje.

Preprečevanje: Dobra novica je, da je zaščita pred vbrizgom »preprosto« stvar pravilnega filtriranja vnosa in razmišljanja o tem, ali je vnosu mogoče zaupati. Slaba novica pa je taka vse vnos je treba pravilno filtrirati, razen če mu je nedvomno mogoče zaupati (toda tu mi res pride na misel rek 'nikoli ne reci nikoli').

V sistemu s 1.000 vhodi na primer uspešno filtriranje 999 od njih ne zadostuje, saj to še vedno pušča eno polje, ki lahko služi kot zdravilo Ahila za uničenje vašega sistema. In morda mislite, da je umestitev rezultata poizvedbe SQL v drugo poizvedbo dobra ideja, saj je zbirka podatkov zaupanja vredna, če pa obod ni, prispevek posredno prihaja od fantov z malintentom. To se imenuje SQL Injection drugega reda v primeru, da vas zanima.

Ker je filtriranje precej težko narediti pravilno (na primer kripto), običajno svetujem, da se zanesete na funkcije filtriranja vašega ogrodja: dokazano delujejo in so temeljito pregledane. Če ne uporabljate ogrodja, morate resnično dobro premisliti, ali ne njihova uporaba je resnično smiselna v varnostnem kontekstu strežnika. 99% časa ne.

Pogosta napaka spletne varnosti št. 2: Zlomljena overitev

To je zbirka več težav, ki se lahko pojavijo med prekinjenim preverjanjem pristnosti, vendar ne izhajajo iz istega osnovnega vzroka.

Ob predpostavki, da bi si kdo še vedno želel uvesti lastno kodo za preverjanje pristnosti v letu 2014 (o čem razmišljate ??), je odsvetujem. Zelo težko je priti prav in možnih pasti je nešteto, samo da omenim nekaj:

1. URL lahko vsebuje ID seje in ga v glavi referenca posreduje nekomu drugemu.
2. Gesla morda ne bodo šifrirana niti v pomnilniku niti v tranzitu.
3. ID-ji sej so lahko predvidljivi, zato je dostop do njih nepomemben.
4. Fiksiranje seje je mogoče.
5. Mogoče je ugrabiti sejo, časovne omejitve niso pravilno izvedene ali se uporablja HTTP (brez zaščite SSL) itd.

Preprečevanje: Najbolj neposreden način, da se tej ranljivosti spletne varnosti izognemo, je uporaba ogrodja. Morda boste to lahko pravilno izvedli, vendar je prvo veliko lažje. Če si želite predstaviti svojo kodo, bodite izjemno paranoični in se poučite, kakšne pasti so. Takih je kar nekaj.

Pogosta napaka spletne varnosti # 3: Medsebojno skriptiranje (XSS)

To je dokaj razširjena napaka pri sanaciji vhodnih podatkov (v bistvu poseben primer pogosta napaka # 1 ). Napadalec ob vnosu daje oznake JavaScript vaše spletne aplikacije. Ko je ta vnos vrnjen uporabniku nesenzificiran, ga bo uporabnikov brskalnik izvedel. Lahko je preprosto, kot je ustvariti povezavo in prepričati uporabnika, da jo klikne, ali pa je nekaj veliko bolj zloveščega. Pri nalaganju strani se skript zažene in na primer z njim lahko piškotke objavite napadalcu.

Preprečevanje: Obstaja preprosta rešitev za spletno varnost: odjemalcu ne vračajte oznak HTML. To ima dodatno prednost pri obrambi pred vbrizgavanjem HTML, podoben napad, pri katerem napadalec vbrizga navadno vsebino HTML (kot so slike ali glasni nevidni predvajalniki bliskavice) - ni močnega učinka, a zagotovo nadležno (»prosim, ustavite!«). Običajno rešitev preprosto pretvori vse Entitete HTML , tako da se vrne kot