6 Öryggisáhætta á vefnum sem þarf að hafa í huga við þróun

Gerðu ráðstafanir í þróun til að herða og halda öryggisnetinu á Netinu.


Lítil fyrirtæki, bankar og margar atvinnugreinar eru háðar vefforritum. Frá því að bygging vefforrits er mikilvægt að vera viss um að hafa bókanir til að kanna varnarleysi þegar þróunin þróast til að forðast öryggisbrot, gagnaleka og fjárhagsleg vandamál.

Hættulegustu vefárásirnar eru þær sem eiga sér stað á netþjóninum þar sem gögn eru geymd og greind.

Hvað er stuðningur?

Vefforrit skiptist í tvo hluta – Frontend og Backend.

  • Framandinn er hlið viðskiptavinar, það er sá hluti sem notandinn hefur samskipti við. Venjulega er það byggt með HTML, CSS og Javascript.
  • The stuðningur er hlið hlið. Það er í grundvallaratriðum hvernig forritið virkar, beitir viðskiptatækni, breytingum og uppfærslum. Sumir af the vinsæll tækni hlið stafla framreiðslumaður fela í sér PHP, NodeJS, Java, Ruby, C, Python, gagnagrunn, öryggi (staðfesting, aðgangsstýring, osfrv), uppbyggingu og innihald stjórnun.

Smá áminning áður en við byrjum – staðfesting, aðgangsstýring & fundur stjórnun

Það er algengt að við ruglum skilmálunum. Svo skulum við skýra það fljótt:

  • Sannvottun snýr að því að sanna hver notandi er (td. Lykilorð, notandanafn, spurningaröryggi, fingraför)
  • Aðgangsstýring varðar það hvað notandinn getur fengið aðgang að forritinu. Það framfylgir þeirri stefnu að notendur geti ekki framkvæmt fyrirhugaðar heimildir.
  • Fundur stjórnun varðar svör og biðja um viðskipti í tengslum við sama notanda. Það er skiptibúnaður sem er notaður milli notandans og forritsins eftir að hann staðfesti með góðum árangri.

Við skulum kanna eftirfarandi fyrir betra öryggi á vefnum.

Gallar við stungulyf

Síðan 2010 flokkaði OSWAP stungulyf sem hættulegustu hættu á vefforritinu.

Gallar við stungulyf leyfa notanda að leggja fram gögn sem innihalda lykilorð sem munu breyta hegðun fyrirspurna sem byggðar eru í gagnagrunninum. Við skulum til dæmis ætla að við höfum SQL handrit sem athugar hvort samsvarandi færsla sé til í gagnagrunninum.

uname = beiðni.POST [‘notandanafn’]
passwd = request.POST [‘lykilorð’]
sql = "VELJA ID frá notendum HVAR notandanafn = ‘" + uname + "’OG lykilorð =’" + passwd + "’"
database.execute (sql)

Árásarmaður getur nú breytt lykilorðsreitnum með SQL innspýtingu, til dæmis með því að slá inn lykilorðið ‘OR 1 =’ 1, sem leiðir til eftirfarandi SQL fyrirspurnar:

sql = "VELJA ID frá notendum HVAR notandanafn = ” OG lykilorð = ‘lykilorð’ EÐA 1 = ‘1’

Með því móti getur árásarmaðurinn fengið aðgang að öllum notendatöflum gagnagrunnsins og lykilorðið er alltaf gilt (1 = ‘1’). Ef þeir skrá sig inn sem stjórnandi geta þeir gert allar breytingar sem hann vill.

Hvernig á að koma í veg fyrir það?

Það er mjög AUÐVELT til að forðast galla í sprautunni.

Besta og einfalda leiðin til að sannreyna hvort ekki séu gallar á sprautunni er ítarleg handvirk endurskoðun á frumkóða til að athuga hvort fyrirspurnir í gagnagrunninum séu gerðar með undirbúnum yfirlýsingum. Þú getur líka notað verkfæri til að athuga hvort varnarleysi sé fyrir hendi.

Og þú ættir líka að gera eftirfarandi.

  • Notaðu ORM-tæki (Object Relational Kortlagningartæki).
  • Flýja undan öllum aðföngum. Dagsetningarsvið ætti aldrei að hafa neitt annað geymt í þeim nema dagsetningar.
  • Einangraðu gögnin þín svo að aðeins það sem ætti að nálgast frá tilteknum stað er haldið á þeim stað.
  • Skrifaðu góða villukóða fyrir meðhöndlun. Ekki gera gagnagrunninn eða stuðninginn þinn of orðréttan.

Troy Hunt fékk snilldar námskeið um SQL sprautu. Ef þú hefur áhuga gætirðu kannað það.

Brotin staðfesting

Eins og fyrr segir fjallar staðfesting um skilríki sem veita. Það er fremsta víglínan gegn óheftum aðgangi. Samt sem áður, léleg framkvæmd og ekki virðing á öryggisstefnu getur leitt til brotinnar staðfestingar.

Brotin staðfesting gerist aðallega með þremur mynstrum:

  • Persónuskilríki fyllingar: þar sem árásarmaðurinn er með lista yfir gild notendanöfn og lykilorð og getur gert sjálfvirkan árás til að reikna með að skilríkin séu gild.
  • Bruteforce árás: þar sem forritið leyfir veikt lykilorð fyrir notendur eða umsjónarmenn.
  • Ræningi þings: þar sem forrit afhjúpar lotuauðkenni, vefslóð eða snúist ekki eftir innskráningu.

Í öllum tilvikum getur árásarmaðurinn fengið aðgang að mikilvægum reikningi og verið háður því fyrirtæki sem getur valdið peningaþvætti, persónuþjófnaði eða afhjúpað lögverndaðar, mjög viðkvæmar upplýsingar.

Hvernig á að koma í veg fyrir það?

Áður en þú setur fram staðfestingarkerfið skaltu spyrja sjálfan þig – hvað gæti árásarmaður náð ef staðfestingarkerfið er í hættu?

Og samkvæmt svarinu geturðu gert eftirfarandi.

  • Innleiða staðfestingu fjölþátta til að koma í veg fyrir sjálfvirkar árásir.
  • Hvetjum (eða neyðir) notandann til að samþykkja góða lykilorðsstefnu.
  • Takmarka mistök innskráninga.
  • Notaðu duglegur reiknirit hass. Þegar þú velur reiknirit skaltu íhuga hámarks lengd lykilorðsins.
  • Prófaðu lotukerfið fyrir lotu og vertu viss um að fundartíminn sé ógildur eftir skráningu.

Brotið aðgangsstýring

Aðgangsstýring er til til að tryggja hvað staðfestur notandi hefur leyfi til að gera. Sannvottun og stjórnun setu eru grunn- eða aðgangsstýringarreglur. En þegar þessar reglur eru ekki vel settar getur það leitt til verulegra vandamála.

Algengir gallar á aðgangsstýringu eru:

  • CORS rangstillingu sem leyfir óheimilan aðgang að API.
  • Metadata meðferð til að beina aðgangi að aðferðum.
  • Þvingað vafra: Árásarmaðurinn mun prófa vefslóð, breyta slóðum (td. Http: //website.domain/user/ til http: //website.domain/admin) og getur jafnvel uppgötvað mikilvægar skrár.

Hvernig á að koma í veg fyrir það?

Aðallega koma bilaðir aðgangsbrestir fram af fáfræði um grundvallarkröfur skilvirkrar aðgangsstýringar.

  • Neita sjálfgefið nema opinberum aðilum.
  • Slökkva á skráningu netskrár netþjónanna og vertu viss um að afritaskrár séu ekki til staðar.
  • Gefðu takmarkaðan aðgang að API til að draga úr áhrifum sjálfvirkra árása.
  • Ógildir JWT-tákn eftir að hafa verið skráðir út á aftanverðu hliðinni.

Útsetning gagna

Einnig vísað til sem gagnabrot, útsetning gagnanna er tölvuógn sem ógnar fyrirtækjum og viðskiptavinum þeirra.

Það kemur fram þegar forritið verndar ekki nægjanlega upplýsingar eins og persónuskilríki eða viðkvæm gögn eins og kreditkort eða heilsufarsskrár. Meira en 4000 skrár eru brotið á hverri mínútu.

Áhrifin á viðskipti eru mikil frá fjárhagslegri hlið: Að meðaltali brot getur kostað 3,92 milljónir dala, skv IBM.

Hvernig á að koma í veg fyrir það?

Sem stuðningur verktaki, ættir þú að spyrja hverjar upplýsingarnar sem þarfnast verndar.

Og svo til að koma í veg fyrir slíka galla:

  • Dulkóða viðkvæm gögn: Fyrir gögn í REST, dulkóða allt. Gakktu úr skugga um að nota örugga gáttir fyrir flutning,
  • Þekkja gögnin sem krefjast aukinnar verndar og takmarka aðgengi aðeins fyrir fullt af lögmætum notendum með því að framfylgja dulkóðun sem byggir á lyklum.
  • Forðastu svaka dulkóðunaralgrím: notaðu uppfærðar og sterk reiknirit.
  • Vertu með örugga afritunaráætlun.

Óörugg afsökun

Serialization og deserialization eru hugtök sem notuð eru þegar gögnum er breytt á hlutasnið sem á að geyma eða senda til annars forrits. Útreikningur samanstendur af því að umbreyta gögnum á hlutarformi eins og XML eða JSON til að gera þau nothæf. Deserialization er bara hið gagnstæða ferli.

Árásir á deserializers geta leitt til afneitunar á þjónustu, aðgangsstýringar og framkvæmdar árásum á fjarkóða (RCE) ef það eru flokkar sem hægt er að breyta til að breyta hegðun.

Annað dæmið um OWASP topp 10 skjalið veitir góða mynd af PHP mótaröð:

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

Þetta er ofurkaka sem inniheldur upplýsingar eins og notandakenni, stig notandans og aðgangsorð lykilorðsins.

Árásarmaður getur breytt raðhlutnum til að fá aðgang að stjórnunarréttindum:

a: 4: {i: 0; i: 1; i: 1; s: 5:"Lísa"; i: 2; s: 5:"stjórnandi";
i: 3; s: 32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Hvernig á að koma í veg fyrir það?

Það er lykilatriði að samþykkja ekki raðnúmeraða hluti frá óáreiðanlegum heimildum.

Þú ættir líka að:

  • Treystu aldrei inntaki notenda.
  • Staðfesta gögn: Ef forritið þitt nema strengur, vertu viss um að það sé strengur áður en þú notar það
  • Notaðu stöðva til að vera viss um að gögnum hefur ekki verið breytt. Það er gagnlegt að þú sendir gögn milli tveggja trausts heimilda (td. Að geyma gagna við hlið viðskiptavinar).

Server XSS

Server XSS (Handrit yfir vefsvæði) er tegund innspýtingar þegar árásarmaður notar vefforrit til að senda illgjarn kóða til mismunandi notenda. Það gerist þegar árásarmaðurinn setur inn smíðuð gögn sem innihalda skaðlegan kóða sem forritið geymir. Þessi varnarleysi er við hlið þjónsins; vafrinn skilar einfaldlega svarinu.

Til dæmis á vettvangi eru notendapóstar vistaðar í gagnagrunni, oft án staðfestingar. Árásarmenn nota tækifærið og bæta við færslum með skaðlegum forskriftum. Í kjölfarið fá aðrir notendur þennan hlekk með tölvupósti eða sjá umrædda færslu og smella á hann.

Hvernig á að koma í veg fyrir það?

Eftir að þú hefur fyrst og fremst bent á allar aðgerðir sem hugsanlega eru í hættu á XSS og vernda þarf, ættir þú að íhuga eftirfarandi.

  • Staðfesta innslátt: athugaðu hvort innsláttarlengd er notuð, notaðu regex-samsvörun og leyfir aðeins ákveðinn staf.
  • Staðfesta úttak: Ef forritið afritar í svör við einhverjum gagnagrein sem er upprunnin frá einhverjum notanda eða þriðja aðila, ættu þessi gögn að vera HTML-kóðuð til að hreinsa mögulega skaðlega stafi.
  • Leyfa takmarka HTML: til dæmis, ef þú ert með athugasemd bloggkerfi, leyfðu aðeins notkun ákveðinna merkja. Ef þú getur það skaltu nota viðeigandi ramma til að nota HTML merkingu sem notandi fylgir til að reyna að ganga úr skugga um að það innihaldi ekki neinar leiðir til að keyra JavaScript.

Niðurstaða

Þróunarstigið skiptir sköpum fyrir öryggi vefforrita. Og þú ættir að íhuga að setja öryggis varnarleysiskannann í þróun lífsferlisins svo að vandamálin sem eru auðkennd eru lagfærð fyrir framleiðslu.

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