6 Varnostna tveganja spletnega zaledja, ki jih je treba upoštevati pri razvoju

Sprejemite ukrepe za utrjevanje in varovanje spletnih strani.


Mala podjetja, banke in številne industrije so odvisne od spletnih aplikacij. Pri izdelavi spletne aplikacije je ključnega pomena, da imate protokole za preverjanje ranljivosti, saj se razvoj razvija, da se izognete kršitvam varnosti, uhajanju podatkov in finančnim težavam..

Najbolj nevarni spletni napadi so tisti, ki se zgodijo na strani strežnika, kjer se podatki shranjujejo in analizirajo.

Kaj je zadnji teden?

Spletna aplikacija je razdeljena na dva dela – Frontend in Backend.

  • Prednja stran je stranko, to je del, s katerim uporabnik sodeluje. Običajno je sestavljen s HTML, CSS in Javascript.
  • Podpora je na strani strežnika. V bistvu deluje aplikacija, uporablja poslovno logiko, spremembe in posodobitve. Nekateri izmed priljubljenih tehnoloških paketov na strani strežnika vključujejo PHP, NodeJS, Java, Ruby, C, Python, bazo podatkov, varnost (preverjanje pristnosti, nadzor dostopa itd.), Strukturo in upravljanje vsebine.

Še majhen opomnik, preden začnemo – preverjanje pristnosti, nadzor dostopa & upravljanje sej

Pogosto nas zmedejo izrazi. Pojasnimo ga na hitro:

  • Preverjanje pristnosti zadeva dokazovanje identitete uporabnika (npr. Geslo, uporabniško ime, varnost, prstni odtisi)
  • Nadzor dostopa zadeva, kaj lahko uporabnik dostopa do aplikacije. Uveljavlja pravilnik, da uporabniki ne morejo delovati zunaj predvidenih dovoljenj.
  • Upravljanje seje se nanaša na odgovore in transakcijske zahteve, povezane z istim uporabnikom. Gre za mehanizem izmenjave, ki se uporablja med uporabnikom in aplikacijo, potem ko se je uspešno overil.

Preučimo naslednje za boljšo varnost spletnih strani.

Napake vbrizgavanja

OSWAP je od leta 2010 injekcijo uvrstil med prvo nevarno spletno aplikacijo.

Napake vbrizgavanja omogočajo uporabniku, da posreduje podatke, ki vsebujejo ključne besede, ki bodo spremenili vedenje poizvedb, vgrajenih v bazo podatkov. Recimo, da imamo skript SQL, ki preverja, ali v bazi podatkov obstaja ustrezen vnos.

uname = request.POST [‘uporabniško ime’]
passwd = request.POST [‘geslo’]
sql = "IZBIRA ID ID uporabnikov KJE uporabniško ime = ‘" + unme + "’IN geslo =’" + passwd + "’"
database.execute (sql)

Napadalec lahko zdaj manipulira s poljem gesla s pomočjo injiciranja SQL, na primer z vnosom gesla ‘ALI 1 =’ 1, kar vodi do naslednje poizvedbe SQL:

sql = "IZBIRA ID ID uporabnikov KJE uporabniško ime = ” IN geslo = ‘geslo’ ALI 1 = ‘1’

S tem lahko napadalec dostopa do vseh uporabniških tabel baze podatkov, pri čemer je geslo vedno veljavno (1 = ‘1’). Če se prijavi kot skrbnik, lahko opravi kakršne koli spremembe.

Kako to preprečiti?

Je zelo LAHKO da bi se izognili napakam pri injiciranju.

Najboljši in preprost način za preverjanje, če ni napak na injekciji, je temeljit ročni pregled izvorne kode, s katerim preverite, ali poizvedbe v bazi podatkov potekajo s pripravljenimi stavki. Z orodji lahko preverite tudi ranljivosti.

In naredite tudi naslednje.

  • Uporabite ORM (Orodja za relacijsko preslikavo predmetov).
  • Pobegnite vsem vhodom. V datumskem polju ne bi smelo biti shranjeno ničesar drugega, razen datumov.
  • Izolirajte svoje podatke tako, da se na tej lokaciji zadržijo samo tiste stvari, do katerih je treba dostopati z določene lokacije.
  • Napišite dobre kode napak pri ravnanju. Ne delajte svoje baze podatkov ali zaledja preveč besedno.

Troy Hunt dobil sijajen tečaj injekcije SQL. Če vas zanima, lahko to raziščete.

Zlomljena avtentikacija

Kot smo že omenili, overjanje obravnava zagotavljanje poverilnic. To je prva linija obrambe pred neomejenim dostopom. Vendar lahko slabo izvajanje in neupoštevanje varnostne politike privede do okrnjene avtentikacije.

Zlomljeno preverjanje pristnosti se zgodi večinoma po treh vzorcih:

  • Polnila poverilnic: kjer ima napadalec seznam veljavnih uporabniških imen in gesel in lahko avtomatizira napad, da ugotovi, da so poverilnice veljavne.
  • Bruteforce napad: kadar aplikacija uporabnikom ali skrbnikom dovoljuje šibka gesla.
  • Ugrabitev seje: kadar aplikacija izpostavi ID seje, URL ali se ne vrti po prijavi.

V vseh primerih lahko napadalec pridobi dostop do pomembnega računa in je odvisen od podjetja, ki lahko povzroči pranje denarja, krajo identitete ali razkrije pravno zaščitene, zelo občutljive podatke.

Kako to preprečiti?

Preden začnete uporabljati sistem za preverjanje pristnosti, se vprašajte – kaj lahko napadalec doseže, če je sistem za preverjanje pristnosti ogrožen?

In glede na odziv lahko storite naslednje.

  • Izvedite večfaktorno overjanje, da preprečite samodejne napade.
  • Spodbujajte (ali silijte) uporabnika, da sprejme dobro politiko gesla.
  • Omejite neuspele prijave.
  • Uporabite učinkovit hash algoritma. Pri izbiri algoritma upoštevajte največjo dolžino gesla.
  • Preizkusite sistem časovne omejitve seje in se prepričajte, da žeton seje po odjavi ni veljaven.

Prekinjen nadzor dostopa

Nadzor dostopa obstaja za zagotovitev, kaj lahko overjeni uporabnik počne. Preverjanje pristnosti in upravljanje sej sta temelj ali pravila nadzora dostopa. Kadar pa ta pravila niso dobro nastavljena, lahko to privede do pomembnih težav.

Skupne napake v nadzoru dostopa vključujejo:

  • Napačna konfiguracija CORS, ki omogoča nepooblaščen dostop do API-ja.
  • Manipulacija metapodatkov za neposreden dostop do metod.
  • Prisilno brskanje: Napadalec bo preizkusil URL, spremenil poti (npr. Http: //website.domain/user/ v http: //website.domain/admin) in lahko celo odkril pomembne datoteke.

Kako to preprečiti?

Večinoma do okvarjenih pomanjkljivosti dostopa pride zaradi nepoznavanja bistvenih zahtev učinkovitega upravljanja dostopa.

  • Zavrni privzeto, razen javnih virov.
  • Onemogočite seznam imenikov strežnika in se prepričajte, da datoteke varnostnih kopij ne obstajajo.
  • Omejite dostop do API-ja za zmanjšanje vpliva samodejnih napadov.
  • Neveljavni žetone JWT po odjavi na strani za izhod.

Izpostavljenost podatkov

Izpostavljenost podatkov je tudi kibernetska grožnja, ki grozi podjetjem in njihovim strankam.

Dogodi se, kadar aplikacija ne zaščiti ustrezno podatkov, kot so poverilnice ali občutljivi podatki, kot so kreditne kartice ali zdravstveni zapisi. Več kot 4000 plošč je prekršil vsako minuto.

Vpliv na poslovanje je velik s finančne strani: Povprečna kršitev lahko stane 3,92 milijona USD IBM.

Kako to preprečiti?

Kot nadomestni razvijalec bi morali vprašati, kakšne so informacije, ki jih potrebuje zaščita.

In potem za preprečevanje takšnih napak:

  • Šifriranje občutljivih podatkov: Za podatke na REST šifrirajte vse. Za podatke v prometu ne pozabite uporabiti varnih prehodov (SSL)
  • Prepoznajte podatke, ki zahtevajo dodatno zaščito in omejijo dostop samo na kup zakonitih uporabnikov samo z uveljavitvijo šifriranja na podlagi ključev.
  • Izogibajte se šibkemu algoritmu šifriranja: uporabite posodobljene in močni algoritmi.
  • Imeti varen rezervni načrt.

Nevarna deserializacija

Serializacija in deserializacija sta koncepta, ki se uporabljata pri pretvorbi podatkov v objektni obliki, ki jih je treba shraniti ali poslati v drugo aplikacijo. Serializacija je sestavljena iz pretvorbe podatkov v objektno obliko, kot sta XML ali JSON, da bi bili uporabni. Deserializacija je ravno obratni postopek.

Napadi na deserializatorje lahko privedejo do zavrnitve storitve, nadzora dostopa in napadov izvajanja oddaljene kode (RCE), če obstajajo razredi, ki jih je mogoče spremeniti, da spremenijo vedenje.

Drugi primer dokumenta 10 najboljših OWASP ponuja dobro ponazoritev serializatorja objektov PHP:

a: 4: {i: 0; i: 132; i: 1; s: 7:"Mallory"; i: 2; s: 4:"uporabnik";
i: 3; s: 32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

To je nadomestni piškotek, ki vsebuje podatke, kot so ID uporabnika, raven uporabnika in razpršeno geslo.

Napadalec lahko spremeni serijski objekt, da dobi dostop do skrbniških pravic:

a: 4: {i: 0; i: 1; i: 1; s: 5:"Alice"; i: 2; s: 5:"administrator";
i: 3; s: 32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Kako to preprečiti?

Ključno je, da ne sprejemate serijskih predmetov iz nezaupljivih virov.

Prav tako bi morali:

  • Nikoli ne zaupajte uporabnikovemu vnosu.
  • Preverjanje podatkov: Če je vaša aplikacija razen niza, se prepričajte, da je niz, preden jo uporabite
  • S čekom se prepričajte, da podatki niso bili spremenjeni. Koristno je, če podatke pošiljate med dva zaupanja vredna vira (npr. Shranjevanje podatkov na strani odjemalca).

Strežnik XSS

Strežnik XSS (Skriptnost med spletnimi stranmi) je vrsta injekcije, ko napadalec uporablja spletno aplikacijo za pošiljanje zlonamerne kode različnim uporabnikom. Pojavi se, ko napadalec objavi nekaj oblikovanih podatkov, ki vsebujejo zlonamerno kodo, ki jo shrani aplikacija. Ta ranljivost je na strani strežnika; brskalnik preprosto odgovori.

Na forumu se na primer uporabniške objave shranijo v bazo podatkov, pogosto brez preverjanja. Napadalci izkoristijo to priložnost za dodajanje objav z zlonamernimi skripti. Nato drugi uporabniki prejmejo to povezavo po e-pošti ali si ogledajo zadevno objavo in jo kliknejo.

Kako to preprečiti?

Po primarni identifikaciji vseh operacij, ki potencialno ogrožajo XSS in jih je treba zaščititi, morate upoštevati naslednje.

  • Preverjanje vnosa: preverite dolžino vnosa, uporabite ujemanje z regularnimi izrazi in dovoli le določen niz znakov.
  • Preverjanje izida: Če aplikacija kopira svoje odzive na kateri koli podatek, ki je nastal od nekega uporabnika ali tretje osebe, bi morali biti ti podatki kodirani s HTML, da se sanitizirajo potencialno zlonamerni znaki.
  • Dovoli omejitev HTML-ja: na primer, če imate sistem blog komentarjev, dovolite uporabo le določenih oznak. Če lahko, uporabite ustrezen okvir za oznako HTML, ki ga je priskrbel uporabnik, in se prepričajte, da ne vsebuje nobenega sredstva za izvajanje JavaScript.

Zaključek

Razvojna faza je ključna za varnost spletnih aplikacij. Razmislite o vključitvi skenerja varnostnih ranljivosti v življenjski cikel razvoja, tako da se opredeljene težave odpravijo pred proizvodnjo.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map