6 veebi taustprogrammi turvariski, mida arendamisel arvestada

Võtke kasutusele arenduse abinõud, et veebi taustaprogramm kõvaks ja turvaliseks hoida.


Veebirakendustest sõltuvad väikeettevõtted, pangad ja paljud majandusharud. Veebirakenduse loomisest alates on ülioluline, et arenedes areneksid turvaaukude kontrollimiseks protokollid, et vältida turvarikkumisi, andmelekke ja finantsprobleeme.

Kõige ohtlikumad veebirünnakud on rünnakud serveripoolel, kus andmeid hoitakse ja analüüsitakse.

Mis on taustprogramm?

Veebirakendus jaguneb kaheks osaks – Frontend ja Backend.

  • Esikülg on kliendi poolel, see on osa, millega kasutaja suhelda saab. Tavaliselt on see ehitatud HTML, CSS ja Javascripti abil.
  • Taust on serveripoolne. Põhimõtteliselt on see, kuidas rakendus töötab, rakendab äriloogikat, muudab ja värskendab. Mõned populaarsed serveripoolsed tehnilised korstnad hõlmavad PHP, NodeJS, Java, Ruby, C, Python, andmebaasi, turvalisust (autentimine, juurdepääsu kontroll jne), struktuuri ja sisuhaldust.

Väike meeldetuletus enne alustamist – autentimine, juurdepääsu kontroll & seansi juhtimine

Tavaline on, et mõisteid ajame segamini. Nii et täpsustagem seda kiiresti:

  • Autentimine puudutab kasutaja identiteedi tõestamist (nt parool, kasutajanimi, küsimuste turvalisus, sõrmejäljed)
  • Juurdepääsukontroll puudutab seda, mida kasutaja saab rakendusele juurde pääseda. Sellega jõustatakse eeskirjad, mille kohaselt kasutajad ei saa tegutseda väljaspool kavandatud õigusi.
  • Seansihaldus puudutab sama kasutajaga seotud vastuseid ja päringutehinguid. See on vahetusmehhanism, mida kasutatakse kasutaja ja rakenduse vahel pärast edukat autentimist.

Veebiturbe parema turvalisuse huvides uurime järgmist.

Süstimisvead

Alates 2010. aastast klassifitseeris OSWAP süstimise kõige ohtlikumaks veebirakenduste riskiks.

Süstimisvead võimaldavad kasutajal esitada andmeid, mis sisaldavad märksõnu, mis muudavad andmebaasi üles ehitatud päringute käitumist. Oletagem näiteks, et meil on SQL-skript, mis kontrollib, kas andmebaasis on vastav kirje.

uname = request.POST [‘kasutajanimi’]
passwd = request.POST [‘parool’]
sql = "VALI ID kasutajatelt, kus kasutajanimi = ‘" + uname + "’JA parool =’" + passwd + "’"
andmebaas.execute (sql)

Ründaja saab nüüd SQL-i süstimisega parooliväljaga manipuleerida, näiteks sisestades parooli ‘OR 1 =’ 1, mis viib järgmise SQL-päringuni:

sql = "VALI ID kasutajatelt, kus kasutajanimi = ” JA parool = ‘parool’ või 1 = ‘1’

Sel viisil pääseb ründaja juurde kõigile andmebaasi kasutajatabelitele, parool on alati kehtiv (1 = ‘1’). Administraatorina sisse logides saavad nad soovitud muudatusi teha.

Kuidas seda vältida?

See on väga LIHTSALT süstimisvigade vältimiseks.

Parim ja lihtne viis süsteveade puudumise kontrollimiseks on põhjalik käsitsi kontrollitav lähtekoodi ülevaade, et kontrollida, kas päringud tehakse andmebaasis ettevalmistatud avalduste kaudu. Samuti saate haavatavuste kontrollimiseks kasutada tööriistu.

Ja peaksite tegema ka järgmist.

  • Kasutage ORM-e (objektide relatsiooni kaardistamise tööriistad).
  • Väljuge kõigist sisenditest. Kuupäevaväljale ei tohiks kunagi midagi muud peale kuupäevade salvestada.
  • Eraldage oma andmed nii, et selles kohas hoitaks ainult neid asju, millele peaks olema juurdepääs konkreetsest asukohast.
  • Kirjutage hea käsitlemise veakoodid. Ärge muutke oma andmebaasi ega taustaprogrammi liiga sõnaliseks.

Troy Hunt sai hiilgava kursuse SQL-i süstimise kohta. Kui olete huvitatud, võite seda uurida.

Katkine autentimine

Nagu varem mainitud, tegeleb autentimine mandaatide esitamisega. See on piiramatu juurdepääsu eest kaitsmise eesliin. Turvapoliitika kehv rakendamine ja mittejärgimine võib aga põhjustada autentimise katkemise.

Katkine autentimine toimub enamasti kolmel viisil:

  • Volikirjade täidised: kus ründajal on kehtivate kasutajanimede ja paroolide loend ning ta saab rünnaku automatiseerida, et mandaat oleks õige.
  • Bruteforce rünnak: kui rakendus lubab kasutajatel või administraatoritel nõrku paroole.
  • Seansi kaaperdamine: kus rakendus paljastab seansi ID, URL-i või ei pöördu pärast sisselogimist.

Kõigil juhtudel pääseb ründaja olulisele kontole ja sõltub ettevõttest, mis võib põhjustada rahapesu, identiteedivargust või avaldada seaduslikult kaitstud, ülitundlikku teavet..

Kuidas seda vältida?

Enne autentimissüsteemi juurutamist küsige endalt – mida ründaja saaks saavutada, kui autentimissüsteem on ohus?

Ja vastavalt vastusele saate teha järgmist.

  • Automaatsete rünnakute vältimiseks rakendage mitmefaktoriline autentimine.
  • Julgustage (või sundige) kasutajat võtma kasutusele hea paroolipoliitika.
  • Piirata ebaõnnestunud sisselogimisi.
  • Kasutage tõhusat algoritmi räsi. Algoritmi valimisel arvestage parooli maksimaalse pikkusega.
  • Testige seansi aegumissüsteemi ja veenduge, et seansi tunnus on pärast väljalogimist kehtetu.

Broken Access Control

Juurdepääsukontroll on olemas selleks, et tagada autentitud kasutajal lubatud toimingud. Autentimine ja seansihaldus on vundamendi või juurdepääsu kontrollimise reeglid. Kuid kui need reeglid pole täpselt paika pandud, võib see põhjustada olulisi probleeme.

Üldised juurdepääsu kontrollimise puudused hõlmavad järgmist:

  • CORS-i valesti konfigureerimine, mis võimaldab volitamata juurdepääsu API-le.
  • Metaandmetega manipuleerimine meetoditele otsese juurdepääsu saamiseks.
  • Sunnitud sirvimine: ründaja proovib URL-i, muudab teid (nt http: //website.domain/user/ kuni http: //website.domain/admin) ja võib isegi leida olulisi faile.

Kuidas seda vältida?

Enamasti ilmnevad purunenud juurdepääsuvead teadmatusest tõhusa juurdepääsuhalduse põhinõuete kohta.

  • Keelduge vaikimisi, välja arvatud avalikud ressursid.
  • Keelake serverikataloogi kirjed ja veenduge, et varufaile pole.
  • Hinnake API-l juurdepääsu, et vähendada automatiseeritud rünnakute mõju.
  • JWT-lubade kehtetuks tunnistamine pärast logi väljalülitamist tagaküljel.

Andmete kokkupuude

Andmetega seotud rikkumisteks on ka andmetega kokkupuude küberoht, mis ähvardab ettevõtteid ja nende kliente.

See ilmneb siis, kui rakendus ei kaitse piisavalt teavet, nagu mandaadid või tundlikud andmed, näiteks krediitkaardid või tervisekaardid. Üle 4000 plaadi on rikuti iga minutiga.

Mõju ettevõtlusele on rahalisest küljest suur: keskmine rikkumine võib maksta vastavalt 3,92 miljonit USA dollarit IBM.

Kuidas seda vältida?

Taustprogrammi arendajana peaksite küsima, mis on kaitset vajav teave.

Ja siis selliste puuduste vältimiseks:

  • Krüpti tundlikud andmed: kui soovite REST-i andmeid, krüpteerige kõik. Transporditavate andmete jaoks kasutage kindlasti turvalisi väravaid (SSL)
  • Lisateavet vajavate andmete tuvastamine ja juurdepääsu piiramine ainult hulgale õigustatud kasutajatele, rakendades võtmepõhist krüptimist.
  • Vältige nõrka krüptimisalgoritmi: kasutage ajakohaseid ja tugevad algoritmid.
  • Kas teil on turvaline varuplaan.

Ebakindel vääristamine

Järjestuse seadmine ja väärtuse muutmine on mõisted, mida kasutatakse andmete teisendamisel objektide vormingus, et neid säilitada või saata teise rakendusse. Serialiseerimine seisneb andmete teisendamises objektide vormingus nagu XML või JSON, et muuta need kasutatavaks. Deserialiseerimine on lihtsalt vastupidine protsess.

Rünnakud asjatundjate vastu võivad põhjustada teenuse keelamise, juurdepääsu juhtimise ja kaugkoodi täitmise (RCE) rünnakuid, kui on klasse, mida saab käitumise muutmiseks muuta.

OWASP top 10 dokumendi teine ​​näide annab hea ülevaate PHP-objekti serialiseerijast:

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

See on superkokk, mis sisaldab teavet, näiteks kasutajatunnus, kasutaja tase ja räsitud parool.

Ründaja saab administraatoriõigustele juurdepääsu saamiseks muuta seerialiseeritud objekti:

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

Kuidas seda vältida?

Äärmiselt oluline on mitte vastu võtta seerialiseeritud objekte ebausaldusväärsetest allikatest.

Te peaksite ka:

  • Ärge kunagi usaldage kasutaja sisestatud andmeid.
  • Andmete valideerimine: kui teie rakendus, välja arvatud string, veenduge enne selle kasutamist, et see oleks string
  • Kontrollige, kas andmeid pole muudetud. On kasulik, kui saadate andmeid kahe usaldusväärse allika vahel (nt andmete kliendi poolel andmete salvestamine).

Serveri XSS

Serveri XSS (Saidiülene skriptimine) on teatud tüüpi süstimine, kui ründaja kasutab pahatahtliku koodi erinevatele kasutajatele veebirakendust. See ilmneb siis, kui ründaja postitab viimistletud andmeid, mis sisaldavad pahatahtlikku koodi ja mida rakendus talletab. See haavatavus on serveripoolne; brauser lihtsalt reageerib.

Näiteks foorumis salvestatakse kasutaja postitused andmebaasi, sageli ilma kontrollimiseta. Ründajad kasutavad seda võimalust, et lisada pahatahtlike skriptidega postitusi. Seejärel saavad teised kasutajad selle lingi e-postiga või näevad seda postitust ja klikivad sellel.

Kuidas seda vältida?

Pärast kõigi operatsioonide esmast tuvastamist, mis võivad XSS-i ohus olla ja mida tuleb kaitsta, peaksite kaaluma järgmist.

  • Valideeri sisend: kontrollige sisendi pikkust, kasutage regex-sobitamist ja see lubab ainult teatud tähemärkide komplekti.
  • Valideeri väljund: kui rakendus kopeerib oma vastusena mõnele kasutajale või kolmandalt osapoolelt pärinevale andmeüksusele, peaksid need andmed olema HTML-kodeeritud, et võimalike pahatahtlike märkide desinfitseerimiseks.
  • Luba HTML-i piiramine: näiteks kui teil on kommentaari ajaveebisüsteem, lubage ainult teatud siltide kasutamist. Kui saate, kasutage kasutajate edastatud HTML-i märgistuseks sobivat raamistikku, et veenduda, et see ei sisalda JavaScripti täitmise vahendeid.

Järeldus

Arendusetapp on veebirakenduste turvalisuse jaoks ülioluline. Ja peaksite kaaluma turvaaukude skanneri lisamist arenduse olelusringi, nii et tuvastatud probleemid lahendatakse enne tootmist.

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