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.
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:
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.
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.
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:
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.
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 . Druga pogosto uporabljena metoda sanacije je uporaba regularnih izrazov za odstranjevanje oznak HTML z uporabo regularnih izrazov na
<
in >
, vendar je to nevarno, saj si bodo mnogi brskalniki zelo dobro razlagali močno pokvarjen HTML. Bolje pretvoriti vse znake v pobegnjene kolege.
To je klasičen primer zaupanja uporabnikovemu vnosu in plačevanja cene zaradi nastale varnostne ranljivosti. Neposredna referenca predmeta pomeni, da je uporabniku izpostavljen notranji objekt, kot je datoteka ali ključ baze podatkov. Težava pri tem je, da lahko napadalec navede to referenco in, če pooblastilo ni uveljavljeno (ali je prekinjeno), lahko napadalec dostopa ali počne stvari, ki jim jih je treba onemogočiti.
Koda ima na primer download.php
modul, ki bere in omogoča uporabniku prenos datotek s pomočjo parametra CGI za določanje imena datoteke (npr. download.php?file=something.txt
). Po pomoti ali zaradi lenobe je razvijalec izpustil pooblastilo iz kode. Napadalec lahko zdaj to uporabi za prenos vseh sistemskih datotek, do katerih ima uporabnik, ki izvaja PHP, na primer kodo same aplikacije ali druge podatke, ki ostanejo na strežniku, na primer varnostne kopije. Ojoj.
Drug pogost primer ranljivosti je funkcija ponastavitve gesla, ki temelji na uporabnikovem vnosu, da določi, čigavo geslo ponastavljamo. Po kliku na veljaven URL lahko napadalec samo spremeni username
v URL-ju, da izgovorite nekaj takega kot 'admin'.
Mimogrede, oba primera sta stvari, ki sem jih sam videl, da se pogosto pojavljajo 'v naravi'.
Preprečevanje: Opravite pooblastilo uporabnika pravilno in dosledno ter izberite možnosti na belem seznamu. Pogosteje pa se celotni težavi lahko izognemo z internim shranjevanjem podatkov in ne zanašanjem na to, da jih odjemalci posredujejo prek parametrov CGI. V ta namen so zelo primerne spremenljivke seje v večini okvirov.
Po mojih izkušnjah so spletni strežniki in programi, ki so bili napačno konfigurirani, veliko bolj pogosti kot tisti, ki so bili pravilno konfigurirani. Morda zato, ker načinov za zajebanje ne manjka. Nekaj primerov:
Preprečevanje: Imeti dober (po možnosti avtomatiziran) postopek »izdelave in uvajanja«, ki lahko izvaja teste ob uvajanju. Rešitev za napačno konfiguracijo revnega človeka so kljuke po prevzemu, ki preprečujejo, da bi koda izginila z vgrajenimi privzetimi gesli in / ali razvojnimi stvarmi.
Ta ranljivost spletne varnosti je namenjena zaščiti kripto in virov. Občutljivi podatki bi morali biti vedno šifrirani, tudi med prenosom in v mirovanju. Brez izjem. Podatki o kreditni kartici in uporabniška gesla bi morali nikoli potujte ali jih hranite nekodirano, gesla pa je treba vedno razpršiti. Očitno algoritem kripto / razprševanja ne sme biti šibek - v dvomih priporočajo standardi spletne varnosti AES (256 bitov in več) in RSA (2048 bitov in več) .
Čeprav je samoumevno, da ID-ji sej in občutljivi podatki ne smejo potovati v URL-jih, občutljivi piškotki pa morajo imeti vklopljeno varno zastavico, je to zelo pomembno in ga ni mogoče preveč poudarjati.
Preprečevanje:
V tranzitu: Uporaba HTTPS z ustreznim potrdilom in PFS (popolna tajnost naprej) . Ne sprejemajte ničesar prek povezav, ki niso HTTPS. Na piškotkih imejte varno zastavico.
Na zalogi: To je težje. V prvi vrsti morate zmanjšati izpostavljenost. Če ne potrebujete občutljivih podatkov, jih razdrobite. Podatkov, ki jih nimate, ne more biti ukradeno . Ne shranjujte podatkov o kreditni kartici kdajkoli , saj verjetno ne želite imeti opravka s tem, da bi bili PCI skladen . Prijavite se pri plačilnem obdelovalcu, kot je Črta ali Braintree . Drugič, če imate občutljive podatke, ki jih dejansko potrebujete, jih shranite šifrirano in poskrbite, da so vsa gesla zgoščena. Za zgoščevanje uporabite bcrypt je priporočljivo. Če ne uporabljate bcrypt, se izobražujte soljenje in mavrične mize .
In s tveganjem, da navedemo očitno, ključev za šifriranje ne shranjujte poleg zaščitenih podatkov . To je kot shranjevanje kolesa s ključavnico, v kateri je ključ. Varnostne kopije zaščitite s šifriranjem, ključi pa naj bodo zelo zasebni. In seveda, ne izgubite ključev!
To je preprosto napaka avtorizacije. To pomeni, da ob klicu funkcije na strežniku ni bila izvedena ustrezna avtorizacija. Velikokrat se razvijalci zanašajo na dejstvo, da je strežniška stran ustvarila uporabniški vmesnik, in menijo, da odjemalec ne more dostopati do funkcionalnosti, ki je ne zagotavlja strežnik. Ni tako preprosto, saj lahko napadalec vedno ponareja zahteve za 'skrito' funkcionalnost in ga ne bo odvrnilo dejstvo, da uporabniški vmesnik te funkcije ne omogoča enostavno dostopne. Predstavljajte si, da obstaja /admin
plošča, gumb pa je v uporabniškem vmesniku prisoten samo, če je uporabnik dejansko skrbnik. Nič ne preprečuje, da bi napadalec odkril to funkcionalnost in jo zlorabil, če manjka pooblastilo.
Preprečevanje: Na strani strežnika mora avtorizacija nenehno storiti. Da, vedno. Nobena izjema ali ranljivost ne bo povzročila resnih težav.
To je lep primer zmeden poslanec napad, pri katerem katera druga stranka zavede brskalnik, da zlorabi svojo avtoriteto. Spletno mesto tretje osebe lahko na primer uporabnikov brskalnik zlorabi pooblastilo, da naredi kaj za napadalca.
V primeru CSRF spletno mesto tretje osebe izda zahteve ciljnemu mestu (npr. Vaši banki) z uporabo vašega brskalnika s piškotki / sejo. Če ste na primer prijavljeni na enem zavihku na domači strani banke in so ranljivi za ta napad, lahko na drugem zavihku vaš brskalnik zlorabi poverilnice v imenu napadalca, kar povzroči zmedeno težavo namestnika. Namestnik je brskalnik, ki zlorablja pooblastila (piškotki seje), da naredi nekaj, kar mu napadalec naroči.
Razmislite o tem primeru:
Napadalec Alice želi razsvetliti Toddovo denarnico tako, da ji nakaže nekaj svojega denarja. Toddova banka je ranljiva za CSRF. Za pošiljanje denarja mora Todd dostopati do naslednjega URL-ja:
img / back-end / 29/10-najpogostejša-spletna-varnost-ranljivost.jpg
Ko se ta URL odpre, se Toddu predstavi stran za uspeh in prenos je končan. Alice tudi ve, da Todd pogosto obišče spletno mesto pod njenim nadzorom na spletnem mestu blog.aliceisawesome.com, kamor postavi naslednji odlomek:
Ob obisku Aliceinega spletnega mesta Toddov brskalnik misli, da se Alice poveže s sliko, in samodejno izda HTTP GET zahtevo za pridobitev slike, toda to dejansko naloži Toddovi banki, naj Alici nakaže 1500 USD.
Mimogrede, ta primer poleg prikaza ranljivosti CSRF prikazuje tudi spreminjanje stanja strežnika z idempotentno zahtevo HTTP GET, kar je resna ranljivost. HTTP GET zahteve mora biti idempotenten (varno), kar pomeni, da ne morejo spremeniti vira, do katerega dostopate. Nikoli, nikoli in nikoli ne uporabljajte idempotentnih metod za spreminjanje stanja strežnika.
Zabavno dejstvo: CSRF je tudi metoda, ki so jo ljudje v preteklosti uporabljali za polnjenje piškotov, dokler podružnice niso postale pametnejše.
Preprečevanje: Skrivni žeton shranite v polje skrite oblike, ki je nedostopno s strani tretje osebe. Seveda morate vedno preveriti to skrito polje. Nekatera spletna mesta zahtevajo tudi vaše geslo pri spreminjanju občutljivih nastavitev (na primer e-poštni naslov z opomnikom za geslo), čeprav sumim, da je to tam, da se prepreči zloraba vaših zapuščenih sej (na primer v internetni kavarni).
Naslov pove vse. Ponovno bi to opredelil kot večjo težavo pri vzdrževanju / uvajanju. Preden vključite novo kodo, opravite nekaj raziskav, morda tudi nekaj revizij. Uporaba kode, ki ste jo dobili od naključne osebe GitHub ali kakšen forum je lahko zelo priročen, vendar ni brez tveganja resne ranljivosti spletne varnosti.
Videl sem na primer veliko primerov, kjer so spletna mesta prišla v lasti (torej tam, kjer tujec dobi administrativni dostop do sistema), ne zato, ker so bili programerji neumni, temveč zato, ker je bila programska oprema tretje osebe dolga leta v proizvodnji. To se na primer ves čas dogaja z vtičniki WordPress. Če mislite, da ne bodo našli vašega skritega phpmyadmin
namestitev, naj vam predstavim dirbuster.
Tu se naučimo, da se razvoj programske opreme ne konča, ko se aplikacija uvede. Obstajati mora dokumentacija, testi in načrti, kako jo vzdrževati in posodabljati, zlasti če vsebuje komponente tretjih oseb ali odprtokodne komponente.
Preprečevanje:
Bodite previdni. Poleg očitne previdnosti pri uporabi takšnih komponent ne bodite programirnik za kopiranje in lepljenje. Previdno preglejte del kode, ki jo nameravate vstaviti v svojo programsko opremo, saj bi lahko bila nepopravljiva (ali v nekaterih primerih namerno zlonamerna - napadi na spletno varnost so včasih na ta način nehote vabljeni).
Bodite na tekočem. Prepričajte se, da uporabljate najnovejše različice vsega, kar jim zaupate, in načrtujte, da jih redno posodabljate. Naročite se vsaj na glasilo o novih varnostnih ranljivostih glede izdelka.
To je še enkrat težava s filtriranjem vnosa. Recimo, da ima ciljno mesto redirect.php
modul, ki vzame URL kot GET
parameter. Z manipulacijo s parametrom lahko ustvarite URL na targetsite.com
ki preusmeri brskalnik na malwareinstall.com
. Ko uporabnik vidi povezavo, bo videl targetsite.com/blahblahblah
za katerega uporabnik meni, da mu zaupa in je varen za klik. Le malo vedo, da jih bo to dejansko preneslo na stran z zlonamerno programsko opremo (ali katero koli drugo zlonamerno). Lahko pa napadalec preusmeri brskalnik na targetsite.com/deleteprofile?confirm=1
.
Omeniti velja, da bi v glavo HTTP lahko vtaknilo nesenzificiran uporabniško določen vnos vbrizgavanje glave kar je precej slabo.
Preprečevanje: Možnosti vključujejo:
Upam, da mi je s to objavo uspelo malo pocrkljati možgane in predstaviti zdravo dozo paranoje in ozaveščenosti o varnosti spletnih strani.
Tukaj je bistveno, da obstajajo prastare prakse programske opreme z razlogom in tisto, kar se je takrat uporabljalo za prelive medpomnilnikov, še danes velja za vložene nize v Pythonu. Varnostni protokoli vam pomagajo napisati (več) pravilne programe, h katerim bi si morali prizadevati vsi programerji.
Prosimo, uporabite to znanje odgovorno in strani ne preizkušajte brez dovoljenja!
Za več informacij in več specifični napadi na strani strežnika , si oglejte: https://www.owasp.org/index.php/Category:Attack .
Povratne informacije o tej objavi in njeni nasveti za ublažitev so dobrodošli in hvaležni. Načrtovana so prihodnja delovna mesta, zlasti glede vprašanja porazdeljena zavrnitev storitve (DDoS) in starošolske (ne spletne) varnostne ranljivosti IT. Če imate posebno zahtevo o tem, o kakšni spletni zaščiti pišete, me prosim kontaktirajte neposredno na [e-pošta zaščitena]
Tukaj je varnost spletnega mesta! Na zdravje.
Sorodno:Grožnje z internetno varnostjo so metode zlorabe spletne tehnologije v škodo spletnega mesta, njegovih uporabnikov ali celo interneta na splošno. Izhajajo iz spletnih mest, ki so napačno konfigurirana, ki so bila nenamerno programirana z ranljivostmi ali ki se zanašajo na komponente, ki so same ranljive.
Najpomembnejših 10 internetnih varnostnih groženj so napake vbrizgavanja in preverjanja pristnosti, XSS, sklici na negotove neposredne predmete, napačna konfiguracija varnosti, izpostavljenost občutljivim podatkom, pomanjkanje pooblastila na ravni funkcije, CSRF, negotove komponente in nefiltrirane preusmeritve.
Prepričajte se, da se morebitne preusmeritve, ki jih naredi vaše spletno mesto (prek naslovov HTTP, metaoznake, JavaScript itd.), Ne zanašajo na uporabniški vnos ali, če je, da je uporabniški vnos saniran, na primer prek belega seznama.
Žeton CSRF strežniku sporoči, da je zahteva prišla od uporabnika njegovega spletnega mesta in ne od katerega drugega spletnega mesta, ki ga uporabnik obišče. To je zato, ker se pošlje z vsako zahtevo prek skritega polja obrazca, kar preprečuje, da zlonamerna spletna mesta delujejo v imenu svojih gledalcev z napadi CSRF.
Vnos, ki je znan tudi kot 'umazan' ali 'nezaupljiv', je vsak vhod, ki je poslan na vaš strežnik. Vsak del kode, ki uporablja tak vnos, ne da bi ga prej razkužil, je varnostna ranljivost, ki jo je mogoče obrniti proti vam, vašim uporabnikom in celo nedolžnim navzočim.
Vbrizgavanje SQL je, ko vaša koda neveljaven vnos vstavi neposredno v stavek SQL, namesto da bi uporabila parametrizirano poizvedbo (tj. Tisto z ogradami.) Na srečo so napadi vbrizgavanja SQL eno najlažjih za ublažitev, saj je podpora za parametrizirane poizvedbe vgrajena v vsako bazo podatkov. dostop do knjižnice.
XSS izkorišča napačne izvedbe skupne 'funkcije' spletne aplikacije: za sprejem HTML-ja od enega uporabnika in predstavitev drugim uporabnikom. Ker lahko nefiltrirani HTML vsebuje JavaScript, lahko napadalec ob naslednji uporabi zadevne spletne aplikacije zažene kodo v imenu drugih uporabnikov.
Napačna konfiguracija varnosti pogosto vključuje uporabo privzetih vrednosti, ki bi jih bilo treba spremeniti: tipke in gesla, dostop do podatkov in storitev, ki je bil sprva liberalen za udobje pri nastavitvi in preizkušanju, ter zanemarjanje tekočih varnostnih posodobitev.
Takrat strežnik ni programiran za preverjanje pooblastila za določeno funkcijo. Pogosto to izhaja iz miselnosti 'varnost skozi nejasnost': napačno se domneva, da potencialni napadalci zanjo nikoli ne bodo izvedeli, če občutljiva funkcija ni prikazana vsem.
Izpostavljenost občutljivim podatkom je, če aplikacija (bodisi zaradi lastne napake bodisi zaradi zlorabe ranljivosti napadalca) razkrije uporabnikove zasebne podatke (npr. Številke kreditnih kartic) nepooblaščeni tretji osebi: drugim uporabnikom, poslovnim partnerjem, zaposlenim ali javnosti.