6 Web-backend-sekuriteitsrisiko’s wat in ag geneem moet word by ontwikkeling

Neem maatreëls in die ontwikkeling om u web-backend veilig te hou en te beveilig.


Klein ondernemings, banke en baie nywerhede is afhanklik van webtoepassings. Vanaf die punt wanneer u ‘n webtoepassing oprig, is dit uiters belangrik om seker te wees dat u protokolle het om kwesbaarhede na te gaan, aangesien die ontwikkeling ontwikkel om sekuriteitsoortredings, datalekkasies en finansiële probleme te vermy..

Die gevaarlikste webaanvalle is dié wat voorkom op die bediener-kant waar data gestoor en ontleed word.

Wat is Backend?

‘N Webtoepassing word in twee dele verdeel – Frontend en Backend.

  • Die frontend is aan die kant van die kliënt, dit is die deel waarmee die gebruiker interaksie het. Tipies is dit gebou met HTML, CSS en Javascript.
  • Die agterkant is aan die bedkant. Dit is basies hoe die toepassing werk, die sakelogika, veranderings en opdaterings toepas. Sommige van die gewilde tegniese stapels aan die serverkant behels PHP, NodeJS, Java, Ruby, C, Python, databasis, sekuriteit (verifikasie, toegangsbeheer, ens.), Struktuur en inhoudbestuur.

‘N Klein herinnering voordat ons begin – verifikasie, toegangsbeheer & sessie bestuur

Dit is algemeen dat ons die voorwaardes verwar. Laat ons dit vinnig uitklaar:

  • Verifikasie handel oor die bewys van gebruikersidentiteit (bv. Wagwoord, gebruikersnaam, vrae oor veiligheid, vingerafdrukke)
  • Toegangsbeheer handel oor wat die gebruiker toegang tot die toepassing kan hê. Dit handhaaf die beleid dat gebruikers nie buite hul beoogde regte mag optree nie.
  • Sessiebestuur handel oor antwoorde en versoek transaksies wat met dieselfde gebruiker geassosieer word. Dit is ‘n uitruilmeganisme wat tussen die gebruiker en die toepassing gebruik word nadat hy suksesvol bevestig is.

Kom ons ondersoek die volgende vir beter web-sekuriteit.

Tekortkominge in die inspuiting

Sedert 2010 het OSWAP inspuiting as die gevaarlikste webtoepassingsrisiko geklassifiseer.

Inspuitingsfoute stel die gebruiker in staat om data te verskaf wat sleutelwoorde bevat wat die gedrag van navrae op die databasis kan verander. Gestel ons het byvoorbeeld ‘n SQL-skrip wat kyk of ‘n bypassende inskrywing in die databasis bestaan.

uname = request.POST [‘gebruikersnaam’]
passwd = request.POST [‘wagwoord’]
sql = "SELEK ID VAN gebruikers WAAR gebruikersnaam = ‘" + uname + "’EN wagwoord =’" + passwd + "’"
database.execute (SQL)

‘N Aanvaller kan nou die wagwoordveld manipuleer met behulp van SQL-inspuiting, byvoorbeeld deur die wagwoord’ OF 1 = ‘1 in te voer, wat lei tot die volgende SQL-navraag:

sql = "KIES ID VAN gebruikers WAAR gebruikersnaam = ” EN wagwoord = ‘wagwoord’ OF 1 = ‘1’

Sodoende kan die aanvaller toegang tot al die gebruikertabelle van die databasis kry, en die wagwoord is altyd geldig (1 = ‘1’). As hulle as administrateur aanmeld, kan hulle die nodige wysigings aanbring.

Hoe om dit te voorkom?

Dit is baie EASY om inspuitingsfoute te vermy.

Die beste en eenvoudige manier om te verifieer dat daar geen foute met die inspuiting is nie, is ‘n deeglike handboek van die bronkode om na te gaan of vrae in die databasis via voorbereide stellings gedoen word. U kan ook instrumente gebruik om na kwesbaarhede te kyk.

En u moet ook die volgende doen.

  • Gebruik ORM’s (hulpmiddel-relasionele kartering-instrumente).
  • Ontsnap aan alle insette. ‘N Datumveld mag nooit iets anders daarin behou nie, behalwe datums.
  • Isoleer u data sodat slegs die dinge wat vanaf ‘n gegewe plek verkry moet word, op daardie plek aangehou word.
  • Skryf goeie hanteerfoutkodes. Moenie u databasis of u agterkant te woordelik maak nie.

Troy Hunt het ‘n briljante kursus oor SQL-inspuiting gekry. As u belangstel, kan u dit ondersoek.

Gebroke verifikasie

Soos vroeër genoem, handel verifikasie met die gegewe geloofsbriewe. Dit is die voorste linie van verdediging teen onbeperkte toegang. Swak implementering en die nie-respek van die veiligheidsbeleid kan lei tot gebroke verifikasie.

Gebroke verifikasie vind meestal plaas deur drie patrone:

  • Geloofsopvullings: waar die aanvaller ‘n lys met geldige gebruikersname en wagwoorde het en die aanval kan outomatiseer om te bepaal dat die geloofsbriewe geldig is.
  • Bruteforce-aanval: waar die toepassing swak wagwoorde vir gebruikers of beheerders toelaat.
  • Sessie kaping: waar die program sessie-ID, URL blootstel of nie roteer na aanmelding nie.

In alle gevalle kan die aanvaller toegang tot ‘n belangrike rekening verkry en is hy afhanklik van die onderneming wat geldwassery, identiteitsdiefstal kan veroorsaak, of wettig beskermde, baie sensitiewe inligting kan openbaar..

Hoe om dit te voorkom?

Vra jouself af voordat jy die verifikasiestelsel implementeer: wat kan ‘n aanvaller bereik as die verifikasiestelsel in die gedrang kom??

En volgens die antwoord kan u die volgende doen.

  • Implementeer multifaktor-verifikasie om outomatiese aanvalle te voorkom.
  • Moedig die gebruiker aan (of dwing) om ‘n goeie wagwoordbeleid in te stel.
  • Beperk mislukte aanmeldings.
  • Gebruik effektiewe algoritme-hash. Oorweeg die maksimum wagwoordlengte wanneer u ‘n algoritme kies.
  • Toets die sessie-time-outstelsel en maak seker dat die sessietoken na afmelding ongeldig is.

Gebreekte toegangsbeheer

Toegangsbeheer bestaan ​​om te verseker dat die geverifieerde gebruiker mag doen. Verifikasie en sessiebestuur is die grondslag- of toegangsbeheerreëls. Maar wanneer hierdie reëls nie goed opgestel is nie, kan dit tot belangrike probleme lei.

Algemene foute met toegangsbeheer is:

  • CORS-foutkonfigurasie wat ongemagtigde API-toegang moontlik maak.
  • Metadata-manipulasie om direkte toegang tot metodes te verkry.
  • Gedwonge blaai: die aanvaller sal ‘n URL probeer, paaie verander (bv. Http: //website.domain/user/ tot http: //website.domein/admin) en kan selfs belangrike lêers ontdek.

Hoe om dit te voorkom?

Gebroke toegangsgebreke kom meestal voor deur onkunde oor die wesenlike vereistes van effektiewe toegangsbestuur.

  • Weier standaard, behalwe openbare bronne.
  • Deaktiveer die lys van bedienergids en maak seker dat rugsteunlêers nie teenwoordig is nie.
  • Koerslimiet toegang tot API om die impak van outomatiese aanvalle te verminder.
  • Ongeldige JWT-tekens na afmelding aan die agterkant.

Data-blootstelling

Dit word ook databeskrywings genoem, en blootstelling is ‘n kuberbedreiging wat ondernemings en hul kliënte bedreig.

Dit kom voor wanneer die toepassing nie voldoende inligting, soos geloofsbriewe of sensitiewe data soos kredietkaarte of gesondheidsrekords, voldoende beskerm nie. Meer as 4000 rekords is elke minuut oortree.

Die finansiële impak op die onderneming is groot: ‘n Gemiddelde oortreding kan volgens US $ 3,92 miljoen kos IBM.

Hoe om dit te voorkom?

As backend-ontwikkelaar moet u vra wat die inligting is wat beskerming benodig.

En om sulke gebreke te voorkom:

  • Enkripteer sensitiewe data: kodifiseer alles vir REST. Maak seker dat u veilige gateways (SSL) gebruik vir gegewens
  • Identifiseer die data wat ekstra beskerming benodig en beperk die toeganklikheid vir slegs ‘n klomp wettige gebruikers deur sleutelgebaseerde kodering te handhaaf.
  • Vermy swak koderingsalgoritme: gebruik die nuutste en sterk algoritmes.
  • Hou ‘n veilige rugsteunplan.

Onseker deserialisering

Serialisering en deserialisering is konsepte wat gebruik word wanneer data in objekformaat omgeskakel word om op te slaan of na ‘n ander toepassing te stuur. Serialisering bestaan ​​uit die omskakeling van data in objekformaat soos XML of JSON om dit bruikbaar te maak. Deserialisering is net die omgekeerde proses.

Aanvalle teen deserializers kan lei tot aanvalle van die diens, toegangsbeheer en uitvoering van eksterne kode (RCE) indien daar klasse is wat verander kan word om gedrag te verander.

Die tweede voorbeeld van die OWASP top 10-dokument gee ‘n goeie illustrasie van die PHP-voorwerp-serienommer:

‘n: 4: {i: 0; i: 132; i: 1; s: 7:"Mallory"; I: 2; s: 4:"gebruiker";
i: 3; s: 32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Dit is ‘n superkoekie wat inligting bevat soos gebruikers-ID, die gebruiker se vlak en die hash-wagwoord.

‘N Aanvaller kan die opgesomde voorwerp verander om toegang tot admin-regte te kry:

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

Hoe om dit te voorkom?

Dit is uiters belangrik om nie seriële voorwerpe uit onbetroubare bronne te aanvaar nie.

U moet ook:

  • Vertrou nooit gebruikersinvoer nie.
  • Valideer data: as u toepassing, behalwe vir ‘n string, seker maak dat dit ‘n string is voordat u dit gebruik
  • Gebruik ‘n tjek om seker te maak dat data nie verander is nie. Dit is nuttig dat u data stuur tussen twee betroubare bronne (bv. Die stoor van data aan die kliënt).

Bediener XSS

Bediener XSS (Skripsie oor die hele webwerf) is ‘n tipe inspuiting wanneer ‘n aanvaller ‘n webtoepassing gebruik om kwaadwillige kode na verskillende gebruikers te stuur. Dit kom voor wanneer die aanvaller sekere inligting bevat wat kwaadwillige kode bevat wat die program stoor. Hierdie kwesbaarheid is aan die kant van die bediener; die blaaier lewer bloot die antwoord.

In ‘n forum word gebruikersposte byvoorbeeld in ‘n databasis gestoor, dikwels sonder verifikasie. Aanvallers neem van hierdie geleentheid gebruik om plasings met kwaadwillige skrifte by te voeg. Vervolgens ontvang ander gebruikers hierdie skakel per e-pos of sien die betrokke pos en klik daarop.

Hoe om dit te voorkom?

Na die primêre identifikasie van al die operasies wat moontlik die risiko vir XSS het en wat beskerm moet word, moet u die volgende oorweeg.

  • Valideer invoer: kyk vir invoerlengte, gebruik regex-matching en laat slegs ‘n sekere stel karakters toe.
  • Valideer die uitvoer: As die toepassing kopieërs in sy antwoorde op enige gegewens bevat wat van die een of ander gebruiker of ‘n derde party afkomstig is, moet hierdie data HTML-gekodeer word om potensieel kwaadwillige karakters te ontsmet..
  • Laat HTML beperk: as u byvoorbeeld ‘n kommentaarblogstelsel het, laat slegs die gebruik van sekere etikette toe. As u dit kan doen, gebruik u ‘n geskikte raamwerk om HTML-opmerkings wat deur die gebruiker verskaf word, te probeer om seker te maak dat dit geen manier bevat om JavaScript uit te voer nie.

Afsluiting

Die ontwikkelingsfase is van kardinale belang vir webtoepassingsekuriteit. U moet dit ook oorweeg om ‘n skandeerder vir sekuriteitsveilighede in die lewensiklus vir ontwikkeling in te sluit, sodat die geïdentifiseerde probleme voor die produksie opgelos word.

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