6 Sigurnosni rizici web izvoda za razmatranje u razvoju

Poduzmite mjere u razvoju kako biste učvrstili i zaštitili web pozadinu.


Mala poduzeća, banke i mnoge industrije ovise o web aplikacijama. Od trenutka izrade web aplikacije, ključno je biti sigurni da imate protokole za provjeru ranjivosti kako se razvoj razvija kako bi se izbjegli narušavanja sigurnosti, curenja podataka i financijski problemi..

Najopasniji web napadi su oni koji se događaju na strani poslužitelja gdje se podaci pohranjuju i analiziraju.

Što je Backend?

Web aplikacija podijeljena je u dva dijela – Frontend i Backend.

  • Prednja strana je na strani klijenta, to je dio s kojim korisnik komunicira. Obično je izgrađen s HTML-om, CSS-om i Javascript-om.
  • Povratna strana je na strani poslužitelja. U osnovi funkcionira kako aplikacija djeluje, primjenjuje poslovnu logiku, promjene i ažuriranja. Neki od popularnih tehnoloških skupova na strani poslužitelja uključuju PHP, NodeJS, Java, Ruby, C, Python, bazu podataka, sigurnost (provjeru autentičnosti, kontrolu pristupa itd.), Strukturu i upravljanje sadržajem.

Mali podsjetnik prije nego što započnemo – autentifikacija, kontrola pristupa & vođenje sesije

Uobičajeno je da zbunimo pojmove. Pa razjasnimo brzo:

  • Autentifikacija se odnosi na dokazivanje identiteta korisnika (npr. Lozinka, korisničko ime, sigurnost, otisci prstiju)
  • Kontrola pristupa tiče se onoga što korisnik može pristupiti aplikaciji. Primjenjuje pravilo da korisnici ne mogu djelovati izvan predviđenih dozvola.
  • Upravljanje sesijama odnosi se na odgovore i transakcije zahtjeva povezane s istim korisnikom. To je mehanizam razmjene koji se koristi između korisnika i aplikacije nakon uspješne provjere autentičnosti.

Istražimo sljedeće za bolju sigurnosnu web sigurnost.

Nedostaci ubrizgavanja

Od 2010. godine OSWAP je injekciju klasificirao kao najopasniji rizik web aplikacije.

Nedostaci ubrizgavanja omogućuju korisniku da pruži podatke koji sadrže ključne riječi koje će izmijeniti ponašanje upita ugrađenih u bazu podataka. Na primjer, pretpostavimo da imamo SQL skriptu koja provjerava postoji li u bazi podataka odgovarajući unos.

uname = request.POST [‘korisničko ime’]
passwd = request.POST [‘lozinka’]
sql = "ODABIR ID OD korisnika GDJE korisničko ime = ‘" + uname + "’I lozinka =’" + passwd + "’"
database.execute (SQL)

Napadač sada može manipulirati poljem lozinke koristeći SQL injekciju, na primjer, unosom lozinke ‘ILI 1 =’ 1, što dovodi do sljedećeg SQL upita:

sql = "ODABIR ID OD korisnika GDJE korisničko ime = ” I lozinka = ‘lozinka’ ILI 1 = ‘1’

Na taj način napadač može pristupiti svim korisničkim tablicama baze podataka, a lozinka je uvijek valjana (1 = ‘1’). Ako se prijave kao administrator, mogu izvršiti sve promjene koje on želi.

Kako to spriječiti?

Jako je LAKO kako bi se izbjegli nedostaci ubrizgavanja.

Najbolji i jednostavan način provjere da nema nedostataka injekcije je temeljit ručni pregled izvornog koda radi provjere da li se upiti u bazi podataka obavljaju putem pripremljenih izjava. Također možete koristiti alate za provjeru ranjivosti.

A trebali biste učiniti i sljedeće.

  • Koristite ORM-ove (Alati za relacijsko preslikavanje objekata).
  • Izlazite iz svih ulaza. U datumskom polju nikad se ne smije pohraniti ništa drugo u njima osim datuma.
  • Izolirajte svoje podatke tako da se na toj lokaciji drže samo one stvari kojima treba pristupiti s određene lokacije.
  • Napišite dobre kodove grešaka u rukovanju. Nemojte pretvoriti svoju bazu podataka ili pozadinu previše slogove.

Trojanski lov dobio sjajan tečaj o SQL injekciji. Ako ste zainteresirani, možete istražiti to.

Prekinuta provjera autentičnosti

Kao što je ranije spomenuto, autentifikacija se bavi pružanjem vjerodajnica. To je prva linija obrane od neograničenog pristupa. Međutim, loša provedba i nepoštivanje sigurnosnih politika može dovesti do prekida provjere autentičnosti.

Slomljena provjera autentičnosti uglavnom se odvija po tri obrasca:

  • Punjenje vjerodajnica: gdje napadač ima popis valjanih korisničkih imena i lozinki i može automatizirati napad da bi utvrdio da su vjerodajnice važeće.
  • Bruteforce napad: gdje aplikacija dopušta slabe lozinke za korisnike ili administratore.
  • Otmica sjednice: gdje aplikacija izlaže ID sesije, URL ili se ne rotira nakon prijave.

U svim slučajevima, napadač može dobiti pristup važnom računu i ovisiti o poslu koji može izazvati pranje novca, krađu identiteta ili otkriti zakonom zaštićene, vrlo osjetljive podatke.

Kako to spriječiti?

Prije primjene sustava provjere autentičnosti zapitajte se – što bi napadač mogao postići ako je sustav autentifikacije ugrožen?

A prema odgovoru možete učiniti sljedeće.

  • Provedite multifaktornu provjeru autentičnosti kako biste spriječili automatske napade.
  • Potaknite (ili prisilite) korisnika na usvajanje dobre politike o zaporkama.
  • Ograničite neuspjele prijave.
  • Koristite učinkovit hash algoritma. Prilikom odabira algoritma razmislite o maksimalnoj duljini lozinke.
  • Testirajte sustav vremenskog ograničenja sesije i provjerite je li znak sesije nevažeći nakon odjave.

Prekinuta kontrola pristupa

Postoji kontrola pristupa kako bi se osiguralo što ovlašteni korisnik može raditi. Autentifikacija i upravljanje sesijama su temelj ili pravila kontrole pristupa. Ali kad ta pravila nisu dobro postavljena, to može dovesti do značajnih problema.

Uobičajene pogreške u pristupu uključuju:

  • Pogrešna konfiguracija CORS-a koja omogućuje neovlašteni pristup API-ju.
  • Manipulacija metapodataka za izravan pristup metodama.
  • Prisilno pregledavanje: Napadač će isprobati URL, izmijeniti staze (npr., Http: //website.domain/user/ do http: //website.domain/admin), pa čak može otkriti važne datoteke.

Kako to spriječiti?

Uglavnom, neispravne nedostatke pristupa nastaju zbog neznanja o bitnim zahtjevima učinkovitog upravljanja pristupom.

  • Odbiti prema zadanom, osim javnih resursa.
  • Onemogućite popis direktorija poslužitelja i budite sigurni da datoteke sigurnosnih kopija ne postoje.
  • Ograničite ograničenje pristupa API-ju da biste smanjili utjecaj automatiziranih napada.
  • Nevažeći JWT tokene nakon odjave na stražnjoj strani.

Izloženost podataka

Također se naziva i kršenjem podataka, izlaganje podataka cyber je prijetnja koja prijeti tvrtkama i njihovim klijentima.

To se događa kada aplikacija ne štiti na odgovarajući način podatke poput vjerodajnica ili osjetljivih podataka poput kreditnih kartica ili zdravstvenih kartona. Više od 4000 zapisa je prekršila svake minute.

Utjecaj na poslovanje velik je s financijske strane: Prema prosječnom kršenju cijene mogu biti 3,92 milijuna USD IBM.

Kako to spriječiti?

Kao pomoćnik programera trebali biste se zapitati koji su podaci koji trebaju zaštitu.

A onda kako biste spriječili takve nedostatke:

  • Šifrirajte osjetljive podatke: Za podatke na REST-u kriptirajte sve. Za podatke u tranzitu, upotrijebite sigurne prolaze (SSL)
  • Prepoznajte podatke za koje je potrebna dodatna zaštita i ograničite dostupnost na samo nekoliko zakonitih korisnika samo provođenjem šifriranja na ključu.
  • Izbjegavajte slab algoritam šifriranja: koristite ažurne i jake algoritme.
  • Imajte siguran sigurnosni plan.

Nesigurna deserijalizacija

Serijalizacija i deserializacija koncepti su koji se koriste pri pretvaranju podataka u objektni oblik za pohranjivanje ili slanje u drugu aplikaciju. Serijalizacija se sastoji od pretvaranja podataka u objektni format poput XML ili JSON kako bi ih učinili upotrebljivima. Deserializacija je samo obrnuti proces.

Napadi na deserijalizatore mogu dovesti do odbijanja usluge, kontrole pristupa i napada daljinskog izvršavanja koda (RCE) ako postoje klase koje se mogu izmijeniti kako bi se promijenilo ponašanje.

Drugi primjer dokumenta 10 najboljih OWASP pruža dobru ilustraciju PHP serializer objekta:

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

Ovo je nadređeni kolačić koji sadrži podatke poput ID-a korisnika, razine korisnika i zaporke zaporke.

Napadač može promijeniti serializirani objekt da bi dobio pristup administrativnim povlasticama:

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

Kako to spriječiti?

Ključno je ne prihvaćati serializirane objekte iz nepouzdanih izvora.

Vi bi također trebali:

  • Nikada ne vjerujte korisničkom unosu.
  • Provjera podataka: Ako je vaša aplikacija osim niza, prije upotrebe provjerite da je niz
  • Da biste bili sigurni da podaci nisu promijenjeni, upotrijebite ček. Korisno je slanje podataka između dva pouzdana izvora (npr. Spremanje podataka na strani klijenta).

XSS poslužitelja

XSS poslužitelja (Križanje na više mjesta) vrsta je ubrizgavanja kada napadač koristi web aplikaciju za slanje zlonamjernog koda različitim korisnicima. To se događa kada napadač objavi neke izrađene podatke koji sadrže zlonamjerni kod koji aplikacija pohranjuje. Ova je ranjivost na strani poslužitelja; preglednik jednostavno daje odgovor.

Primjerice, na forumu se korisnički postovi spremaju u bazu podataka, često bez provjere. Napadači iskorištavaju ovu priliku kako bi dodali postove sa zlonamjernim skriptama. Nakon toga drugi korisnici dobivaju ovu vezu e-poštom ili pogledaju sporni post i kliknu na njega.

Kako to spriječiti?

Nakon primarne identifikacije svih operacija koje potencijalno prijete XSS-u i koje je potrebno zaštititi, trebali biste uzeti u obzir sljedeće.

  • Provjerite unos: provjerite duljinu ulaza, upotrijebite podudaranje regularnih izraza i dopušta samo određeni skup znakova.
  • Provjera izlaza: Ako aplikacija kopira u svoje odgovore na bilo koju stavku podataka koja je nastala od nekog korisnika ili treće strane, ovi podaci trebaju biti kodirani HTML-om kako bi se sanirali potencijalno zlonamjerni znakovi.
  • Dopusti ograničenje HTML-a: na primjer, ako imate blog blog komentara, dopustite upotrebu samo određenih oznaka. Ako možete, upotrijebite odgovarajući okvir za HTML oznaku koju ste dobili od korisnika da biste bili sigurni da ne sadrži nikakva sredstva za izvršavanje JavaScripta.

Zaključak

Faza razvoja ključna je za sigurnost web aplikacija. Također, trebali biste razmotriti uključivanje skenera sigurnosnih ranjivosti u životni ciklus razvoja, tako da su identificirani problemi riješeni prije proizvodnje.

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