6 Sikkerhetsrisikoer på nettet som må tas i betraktning i utviklingen

Ta tiltak i utvikling for å herde og sikre at webendensen din er sikker.


Små bedrifter, banker og mange bransjer er avhengige av webapplikasjoner. Fra det punktet når du bygger en webapplikasjon, er det avgjørende å være sikker på å ha protokoller for å sjekke sårbarheter når utviklingen utvikler seg for å unngå sikkerhetsbrudd, datalekkasjer og økonomiske problemer.

De farligste nettangrepene er de som oppstår på serversiden der data lagres og analyseres.

Hva er Backend?

En nettapplikasjon er delt inn i to deler – Frontend og Backend.

  • Frontenden er klientsiden, det er den delen brukeren samhandler med. Det er vanligvis bygget med HTML, CSS og Javascript.
  • Bakenden er serversiden. Det er i utgangspunktet hvordan applikasjonen fungerer, bruker forretningslogikken, endringene og oppdateringene. Noen av de populære teknologiske stablene på serversiden involverer PHP, NodeJS, Java, Ruby, C, Python, database, sikkerhet (autentisering, tilgangskontroll, etc.), struktur og innholdsstyring.

En liten påminnelse før vi starter – autentisering, tilgangskontroll & sesjonsledelse

Det er vanlig at vi forvirrer vilkårene. Så la oss avklare det raskt:

  • Autentisering gjelder bevis på brukeridentitet (f.eks. Passord, brukernavn, spørsmål om sikkerhet, fingeravtrykk)
  • Tilgangskontroll angår hva brukeren kan få tilgang til applikasjonen. Den håndhever retningslinjene om at brukere ikke kan handle utenfor de tiltenkte tillatelsene.
  • Øktadministrasjon gjelder svar og be om transaksjoner tilknyttet samme bruker. Det er en utvekslingsmekanisme som brukes mellom brukeren og applikasjonen etter at han har autentisert.

La oss utforske følgende for bedre back-end websikkerhet.

Injeksjonsfeil

Siden 2010 klassifiserte OSWAP injeksjon som den farligste risiko for webapplikasjoner.

Injeksjonsfeil gjør det mulig for en bruker å levere data som inneholder nøkkelord som vil endre oppførselen til spørsmål som er bygd i databasen. La oss for eksempel anta at vi har et SQL-skript som sjekker om det finnes en samsvarende oppføring i databasen.

uname = request.POST [‘brukernavn’]
passwd = request.POST [‘passord’]
sql = "VELG ID FRA brukere HVOR brukernavn = ‘" + uname + "’OG passord =’" + passwd + "’"
database.execute (SQL)

En angriper kan nå manipulere passordfeltet ved å bruke SQL-injeksjon, for eksempel ved å legge inn passordet ‘OR 1 =’ 1, som fører til følgende SQL-spørring:

sql = "VELG ID FRA brukere HVOR brukernavn = ” OG passord = ‘passord’ ELLER 1 = ‘1’

Ved å gjøre dette kan angriperen få tilgang til alle brukertabellene i databasen, idet passordet alltid er gyldig (1 = ‘1’). Hvis de logger seg på som administrator, kan de gjøre endringer han ønsker.

Hvordan forhindre det?

Det er veldig LETT for å unngå injeksjonsfeil.

Den beste og enkle måten å kontrollere om det ikke er noen injeksjonsfeil, er en grundig manuell gjennomgang av kildekoden for å sjekke om spørsmål i databasen gjøres via utarbeidede uttalelser. Du kan også bruke verktøy for å se etter sårbarheter.

Og du bør også gjøre følgende.

  • Bruk ORMer (Object Relational Mapping Tools).
  • Unngå alle innganger. Et datofelt skal aldri ha noe annet lagret i dem bortsett fra datoer.
  • Isoler dataene dine slik at bare de tingene som skal nås fra et gitt sted, holdes på det stedet.
  • Skriv gode håndteringsfeilkoder. Ikke gjør databasen din eller din backend for ordbok.

Troy Hunt fikk et strålende kurs om SQL-injeksjon. Hvis du er interessert, kan du utforske det.

Ødelagt autentisering

Som nevnt tidligere, handler autentisering om legitimasjonsopplysningene. Det er frontlinjen i forsvaret mot ubegrenset tilgang. Imidlertid kan dårlig implementering og manglende respekt for sikkerhetspolitikken føre til ødelagt autentisering.

Ødelagt autentisering skjer mest av tre mønstre:

  • Legitimasjonsstoppninger: der angriperen har en liste med gyldige brukernavn og passord og kan automatisere angrepet for å finne at legitimasjonen er gyldig.
  • Bruteforce-angrep: der applikasjonen tillater svake passord for brukere eller administratorer.
  • Økt kapring: der applikasjonen utsetter økt-ID, URL, eller ikke roterer etter innlogging.

I alle tilfeller kan angriperen få tilgang til en viktig konto og være avhengig av virksomheten som kan forårsake hvitvasking, identitetstyveri eller avsløre lovlig beskyttet, svært sensitiv informasjon.

Hvordan forhindre det?

Før du implementerer autentiseringssystemet, spør deg selv – hva kan en angriper oppnå hvis autentiseringssystemet er kompromittert?

Og i følge svaret, kan du gjøre følgende.

  • Implementere flerfaktorautentisering for å forhindre automatiserte angrep.
  • Oppfordre (eller tvinge) brukeren til å vedta en god passordpolicy.
  • Begrens mislykkede pålogginger.
  • Bruk effektiv algoritmeshash. Når du velger en algoritme, bør du vurdere maks passordlengde.
  • Test sesjonsavbruddssystemet, og sørg for at økttoken er ugyldig etter utlogging.

Brutt tilgangskontroll

Tilgangskontroll eksisterer for å sikre hva autentisert bruker har lov til å gjøre. Godkjenning og sesjonsstyring er grunnlaget eller adgangskontrollreglene. Men når disse reglene ikke er godt satt, kan dette føre til betydelige problemer.

Vanlige feil med tilgangskontroll inkluderer:

  • CORS-feilkonfigurasjon som tillater uautorisert API-tilgang.
  • Metadata-manipulasjon for å direkte tilgang til metoder.
  • Tvungen surfing: Angriperen vil prøve en URL, endre baner (f.eks. Http: //website.domain/user/ til http: //website.domain/admin), og kan til og med oppdage viktige filer.

Hvordan forhindre det?

Stort sett oppstår ødelagte tilgangsfeil ved uvitenhet om de essensielle kravene til effektiv tilgangsstyring.

  • Nekt som standard unntatt offentlige ressurser.
  • Deaktiver serverkatalogoppføring, og sørg for at sikkerhetskopifiler ikke er til stede.
  • Rate limit API access for å redusere virkningen av automatiserte angrep.
  • Ugyldig JWT-symboler etter utlogging på baksiden.

Datoeksponering

Også kjent som datainnbrudd, er dataeksponering en cybertrussel som truer virksomheter og deres kunder.

Det oppstår når applikasjonen ikke beskytter informasjon som legitimasjon eller sensitive data som kredittkort eller helsejournaler tilstrekkelig. Mer enn 4000 poster er det brøt hvert minutt.

Virkningen på virksomheten er stor fra den økonomiske siden: Et gjennomsnittlig brudd kan koste 3,92 millioner dollar, ifølge IBM.

Hvordan forhindre det?

Som backend-utvikler bør du spørre hva informasjonen som trenger beskyttelse er.

Og for å forhindre slike feil:

  • Krypter sensitive data: Krypter alt for REST-data. For data under transport, sørg for å bruke sikre gateways (SSL)
  • Identifiser dataene som krever ekstra beskyttelse og begrenser tilgjengeligheten for bare en gjeng legitime brukere bare ved å håndheve nøkkelbasert kryptering.
  • Unngå svak krypteringsalgoritme: bruk oppdaterte og sterke algoritmer.
  • Ha en sikker backupplan.

Usikker deserialisering

Serialisering og deserialisering er begreper som brukes når data blir konvertert i objektformat som skal lagres eller sendes til et annet program. Serialisering består av å konvertere data i objektformat som XML eller JSON for å gjøre dem brukbare. Deserialisering er bare omvendt prosess.

Angrep mot deserialisatorer kan føre til angrep mot tjenestenekt, tilgangskontroll og utførelse av fjernkode (RCE) hvis det er klasser som kan endres for å endre atferd.

Det andre eksemplet på OWASP topp 10-dokumentet gir en god illustrasjon av PHP-objekt-serienummer:

a: 4: {i: 0; i: 132; i: en; s: 7:"Mallory"; I: 2; s: 4:"bruker";
I: 3; s: 32:"b6a8b3bea87fe0e05022f8f3c88bc960";}

Dette er en superkjeks som inneholder informasjon som bruker-ID, brukerens nivå og passordet for hash.

En angriper kan endre det serialiserte objektet for å få tilgang til administratorrettigheter:

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

Hvordan forhindre det?

Det er avgjørende å ikke godta serialiserte objekter fra pålitelige kilder.

Du bør også:

  • Stol aldri på brukerens innspill.
  • Valider data: Hvis søknaden din bortsett fra en streng, må du forsikre deg om at den er en streng før du bruker den
  • Bruk en sjekk for å være sikker på at data ikke er endret. Det er nyttig at du sender data mellom to pålitelige kilder (f.eks. Lagring av data klientsiden).

Server XSS

Server XSS (Skripting på tvers av sider) er en type injeksjon når en angriper bruker et webapplikasjon for å sende ondsinnet kode til forskjellige brukere. Det oppstår når angriperen legger ut noen lagde data som inneholder skadelig kode som applikasjonen lagrer. Dette sikkerhetsproblemet er serversiden; nettleseren gir ganske enkelt svaret.

I et forum lagres for eksempel brukerinnlegg i en database, ofte uten bekreftelse. Angripere benytter anledningen til å legge til innlegg med ondsinnede skript. Deretter mottar andre brukere denne lenken via e-post eller ser innlegget det gjelder og klikker på den.

Hvordan forhindre det?

Etter primær identifisering av alle operasjoner som potensielt er utsatt for XSS og som må beskyttes, bør du vurdere følgende.

  • Valider inndata: sjekk for inngangslengde, bruk regex-matching, og tillater bare et visst sett med tegn.
  • Valider utdata: Hvis applikasjonen kopierer til svarene på dataelement som stammer fra en bruker eller en tredjepart, skal disse dataene HTML-kodes for å rense potensielt skadelige tegn.
  • Tillat begrensning av HTML: Hvis du for eksempel har et kommentarblogsystem, tillater du bare bruk av bestemte koder. Hvis du kan, kan du bruke et passende rammeverk for brukerstyrt HTML-markering for å prøve å sikre at den ikke inneholder noen måter å utføre JavaScript på.

Konklusjon

Utviklingsfasen er avgjørende for webapplikasjonssikkerhet. Og du bør vurdere å inkludere en sikkerhetssårbarhetsskanner i utviklingslivssyklusen, slik at de identifiserte problemene løses før produksjonen.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Комментариев нет, будьте первым кто его оставит

    Комментарии закрыты.

    Adblock
    detector