For omtrent et år siden lanserte vi i DataLine å søke og analysere sårbarheter i IT-applikasjoner. Tjenesten er basert på Qualys skyløsning, om driften av denne . I løpet av et års arbeid med løsningen gjennomførte vi 291 skanninger for ulike nettsteder og samlet statistikk over vanlige sårbarheter i nettapplikasjoner.
I artikkelen nedenfor vil jeg vise deg nøyaktig hvilke hull i nettstedsikkerhet som skjuler seg bak ulike nivåer av kritikk. La oss se hvilke sårbarheter skanneren fant spesielt ofte, hvorfor de kan oppstå og hvordan du kan beskytte deg selv.
Qualys deler alle sårbarheter i nettapplikasjoner inn i tre kritiske nivåer: lav, middels og høy. Hvis du ser på fordelingen etter "alvorlighet", ser det ut til at alt ikke er så ille. Det er få sårbarheter med et høyt nivå av kritikk, for det meste er alle ikke-kritiske:
Men ukritisk betyr ikke ufarlig. De kan også forårsake alvorlig skade.
Topp "ikke-kritiske" sårbarheter
- Sårbarheter med blandet innhold.
Standarden for nettstedsikkerhet er overføring av data mellom klienten og serveren via HTTPS-protokollen, som støtter kryptering og beskytter informasjon mot avlytting.
Noen nettsteder bruker blandet innhold: Noen data overføres via den usikre HTTP-protokollen. Slik blir det oftest formidlet passivt innhold – informasjon som kun påvirker visningen av nettstedet: bilder, css-stiler. Men noen ganger er det slik det overføres aktivt innhold: skript som kontrollerer oppførselen til nettstedet. I dette tilfellet, ved hjelp av spesiell programvare, kan du analysere informasjon med aktivt innhold som kommer fra serveren, endre svarene dine med en gang og få maskinen til å fungere på en måte som ikke var ment av skaperne.
Nyere versjoner av nettlesere advarer brukere om at nettsteder med blandet innhold er usikre og blokkerer innholdet. Nettstedutviklere mottar også nettleseradvarsler i konsollen. For eksempel er det slik det ser ut :
Hva er farlig: Angripere bruker en usikker protokoll for å fange opp brukerinformasjon, erstatte skript og sende forespørsler til nettstedet på hans vegne. Selv om en besøkende ikke la inn data, beskytter dette ham ikke mot phishing – innhenting av konfidensiell informasjon ved bruk av uredelige metoder. Ved å bruke et skript kan du for eksempel omdirigere brukeren til et usikkert nettsted som utgir seg for å være kjent for brukeren. I noen tilfeller ser det skadelige nettstedet enda bedre ut enn originalen, og brukeren kan fylle ut skjemaet selv og sende inn konfidensielle data.Hva en webutvikler bør huske: Selv om nettstedadministratoren har installert og konfigurert et SSL/TLS-sertifikat, kan det oppstå en sårbarhet på grunn av menneskelige feil. For eksempel hvis du på en av sidene ikke legger en relativ lenke, men en absolutt lenke fra http, og i tillegg ikke har satt opp omdirigeringer fra http til https.
Du kan oppdage blandet innhold på et nettsted ved hjelp av en nettleser: søk i sidens kildekode, les varsler i utviklerkonsollen. Utvikleren vil imidlertid måtte pusle med koden i lang tid og kjedelig. Du kan fremskynde prosessen med automatiserte analyseverktøy, for eksempel: , gratis Lighthouse-programvare eller betalt programvare Screaming Frog SEO Spider.
Også sårbarheten kan oppstå på grunn av problemer med legacy-code - kode som ble arvet. For eksempel, hvis noen sider er generert ved hjelp av en gammel mal, som ikke tar hensyn til overgangen av nettsteder til https.
- Informasjonskapsler uten "HTTPOnly" og "secure"-flagg.
"HTTPOnly"-attributtet beskytter informasjonskapsler fra å bli behandlet av skript som angripere bruker for å stjele brukerdata. "Secure"-flagget tillater ikke at informasjonskapsler sendes i klartekst. Kommunikasjon vil kun være tillatt hvis den sikre HTTPS-protokollen brukes til å sende informasjonskapsler.
Begge attributtene er spesifisert i informasjonskapselegenskapene:
Set-Cookie: Secure; HttpOnlyHva er farlig: Hvis nettstedutvikleren ikke spesifiserte disse attributtene, kan en angriper fange opp brukerens informasjon fra informasjonskapselen og utnytte den. Hvis informasjonskapsler brukes til autentisering og autorisasjon, vil han kunne kapre brukerens økt og utføre handlinger på siden på hans vegne.
Hva en webutvikler bør huske: Som regel settes disse attributtene automatisk i populære rammeverk. Men sjekk fortsatt webserverkonfigurasjonen og sett flagget: Set-Cookie HttpOnly; Sikre.
I dette tilfellet vil attributtet "HTTPOnly" gjøre informasjonskapsler usynlige for ditt eget JavaScript.
- Banebaserte sårbarheter.
Skanneren rapporterer en slik sårbarhet hvis den finner en offentlig tilgjengelig fil eller nettstedskatalog med potensielt konfidensiell informasjon. For eksempel oppdager den individuelle systemkonfigurasjonsfiler eller tilgang til hele filsystemet. Denne situasjonen er mulig hvis tilgangsrettigheter er satt feil på nettstedet.
Hva er farlig: Hvis filsystemet "stikker ut", kan en angriper falle inn i operativsystemgrensesnittet og prøve å finne mapper med passord hvis de er lagret i klartekst (ikke gjør det!). Eller du kan stjele passordhasher og brute force passordet, og også prøve å heve privilegier i systemet og bevege deg dypere inn i infrastrukturen.
Hva en webutvikler bør huske: Ikke glem tilgangsrettigheter og konfigurer plattformen, webserveren, webapplikasjonen slik at det er umulig å "unnslippe" nettkatalogen.
- Skjemaer for å legge inn sensitive data med autofyll aktivert.
Hvis en bruker ofte fyller ut skjemaer på nettsteder, lagrer nettleseren denne informasjonen ved hjelp av autofyll-funksjonen.
Skjemaer på nettsteder kan inneholde felt med sensitiv informasjon, for eksempel passord eller kredittkortnumre. For slike felt er det verdt å deaktivere skjemaautofyll-funksjonen på selve nettstedet.
Hva er farlig: Hvis brukerens nettleser lagrer sensitiv informasjon, kan en angriper avskjære den senere, for eksempel gjennom phishing. I hovedsak setter en nettutvikler som har glemt denne nyansen opp brukerne sine.
Hva en webutvikler bør huske: I dette tilfellet har vi en klassisk konflikt: bekvemmelighet vs sikkerhet. Hvis en nettutvikler tenker på brukeropplevelse, kan han bevisst velge autofullføring. For eksempel hvis det er viktig å følge med – anbefalinger for tilgjengelighet av innhold for brukere med nedsatt funksjonsevne.
For de fleste nettlesere kan du deaktivere autofullføring med attributtet autocompete="off", for eksempel:
<body> <form action="/no/form/submit" method="get" autocomplete="off"> <div> <input type="text" placeholder="First Name"> </div> <div> <input type="text" id="lname" placeholder="Last Name" autocomplete="on"> </div> <div> <input type="number" placeholder="Credit card number"> </div> <input type="submit"> </form> </body>Men det vil ikke fungere for Chrome. Dette omgås ved hjelp av JavaScript, en variant av oppskriften finnes .
- X-Frame-Options-overskriften er ikke angitt i nettstedskoden.
Denne overskriften påvirker ramme-, iframe-, embed- eller objekttagger. Med dens hjelp kan du fullstendig forby å bygge inn nettstedet ditt i en ramme. For å gjøre dette, må du spesifisere verdien X-Frame-Options: deny. Eller du kan spesifisere X-Frame-Options: sameorigin, så vil innebygging i en iframe kun være tilgjengelig på domenet ditt.
Hva er farlig: Fraværet av en slik overskrift kan brukes på ondsinnede nettsteder til clickjacking. For dette angrepet lager angriperen en gjennomsiktig ramme på toppen av knappene og lurer brukeren. For eksempel: svindlere rammer inn sosiale nettverkssider på et nettsted. Brukeren tror han klikker på en knapp på denne siden. I stedet blir klikket fanget opp og brukerens forespørsel sendes til det sosiale nettverket der det er en aktiv økt. Dette er hvordan angripere sender spam på vegne av brukeren eller får abonnenter og likes.
Hvis du ikke deaktiverer denne funksjonen, kan en angriper plassere applikasjonsknappen på et ondsinnet nettsted. Han kan være interessert i henvisningsprogrammet ditt eller brukerne dine.
Hva en webutvikler bør huske: Sårbarheten kan oppstå hvis X-Frame-Options med en motstridende verdi er satt på webserveren eller lastbalanseren. I dette tilfellet vil serveren og balanseren ganske enkelt omskrive overskriften, siden de har høyere prioritet sammenlignet med backend-koden.
Deny og sameorigin-verdiene til X-Frame-Options-overskriften vil forstyrre driften av Yandex-webviseren. For å tillate bruk av iframes for nettleseren, må du skrive en egen regel i innstillingene. For eksempel, for nginx kan du konfigurere det slik:
http{ ... map $http_referer $frame_options { "~webvisor.com" "ALLOW-FROM http://webvisor.com"; default "SAMEORIGIN"; } add_header X-Frame-Options $frame_options; ... } - PRSSI (Path-relative stylesheet import) sårbarheter.
Dette er en sårbarhet i nettstedets styling. Det oppstår hvis relative lenker som href="/no/somefolder/styles.css/" brukes for å få tilgang til stilfiler. En angriper vil dra nytte av dette hvis de finner en måte å omdirigere brukeren til en ondsinnet side. Siden vil sette inn en relativ lenke i sin url og simulere et stilkall. Du vil få en forespørsel som badsite.ru/…/somefolder/styles.css/, som kan utføre ondsinnede handlinger under dekke av en stil.
Hva er farlig: En bedrager kan utnytte dette sikkerhetsproblemet hvis de finner et annet sikkerhetshull. Som et resultat er det mulig å stjele brukerdata fra informasjonskapsler eller tokens.
Hva en webutvikler bør huske: Sett X-Content-Type-Options-overskriften til: nosniff. I dette tilfellet vil nettleseren sjekke innholdstypen for stilene. Hvis typen er en annen enn tekst/css, vil nettleseren blokkere forespørselen.
Kritiske sårbarheter
- En side med et passordfelt overføres fra serveren over en usikker kanal (HTML-skjema som inneholder passordfelt(er) serveres over HTTP).
Responsen fra serveren over en ukryptert kanal er sårbar for "Man in the middle"-angrep. En angriper kan avskjære trafikk og kile seg fast mellom klienten og serveren når siden går fra serveren til klienten.
Hva er farlig: Svindleren vil kunne erstatte siden og sende brukeren et skjema for konfidensielle data, som vil gå til angriperens server.
Hva en webutvikler bør huske: Noen nettsteder sender brukere en engangskode via e-post/telefon i stedet for et passord. I dette tilfellet er ikke sårbarheten så kritisk, men mekanismen vil komplisere brukernes liv.
- Sende et skjema med pålogging og passord over en usikker kanal (påloggingsskjema sendes ikke via HTTPS).
I dette tilfellet sendes et skjema med pålogging og passord fra brukeren til serveren via en ukryptert kanal.
Hva er farlig: I motsetning til det forrige tilfellet er dette allerede en kritisk sårbarhet. Det er lettere å fange opp sensitive data fordi du ikke engang trenger å skrive kode for å gjøre det.
- Bruker JavaScript-biblioteker med kjente sårbarheter.
Under skanningen var det mest brukte biblioteket jQuery med et omfattende antall versjoner. Hver versjon har minst én, eller enda flere, kjente sårbarheter. Virkningen kan være svært forskjellig avhengig av sårbarhetens natur.
Hva er farlig: Det er utnyttelser for kjente sårbarheter, for eksempel:
Hva en webutvikler bør huske: Gå jevnlig tilbake til syklusen: søk etter kjente sårbarheter - fiks - sjekk. Hvis du bruker eldre biblioteker bevisst, for eksempel for å støtte eldre nettlesere eller for å spare penger, se etter en mulighet til å fikse en kjent sårbarhet. - Cross-site scripting (XSS).
Cross-Site Scripting (XSS), eller cross-site scripting, er et angrep på en nettapplikasjon som resulterer i at skadevare blir introdusert i databasen. Hvis Qualys finner en slik sårbarhet, betyr det at en potensiell angriper kan eller allerede har introdusert sitt eget js-skript i nettstedskoden for å utføre ondsinnede handlinger.Lagret XSS farligere, siden skriptet er innebygd på serveren og kjøres hver gang den angrepne siden åpnes i nettleseren.
Reflektert XSS enklere å utføre siden et ondsinnet skript kan injiseres i en HTTP-forespørsel. Applikasjonen vil motta en HTTP-forespørsel, vil ikke validere dataene, pakke den og sende den umiddelbart. Hvis en angriper avskjærer trafikk og setter inn et skript som
<script>/*+что+то+плохое+*/</script>da vil en ondsinnet forespørsel sendes på vegne av klienten.
Et slående eksempel på XSS: js-sniffere som simulerer sider for inntasting av CVC, kortets utløpsdato og så videre.
Hva en webutvikler bør huske: I Content-Security-Policy-overskriften bruker du script-src-attributtet for å tvinge klientnettleseren til kun å laste ned og kjøre kode fra en pålitelig kilde. For eksempel hvitelister script-src 'self' alle skript fra nettstedet vårt.
Den beste fremgangsmåten er innebygd kode: tillat bare innebygd javascript ved å bruke den usikre innebygde verdien. Denne verdien tillater bruk av inline js/css, men forbyr ikke inkludering av js-filer. I kombinasjon med script-src 'self' deaktiverer vi eksterne skript fra å bli utført.Pass på å logge alt ved hjelp av report-uri og se på forsøk på å implementere det på nettstedet.
- SQL-injeksjoner.
Sårbarheten indikerer muligheten for å injisere SQL-kode på et nettsted som får direkte tilgang til nettstedets database. SQL-injeksjon er mulig hvis data fra brukeren ikke er skjermet: det kontrolleres ikke for riktighet og brukes umiddelbart i spørringen. Dette skjer for eksempel hvis et skjema på en nettside ikke sjekker om inndata stemmer med datatypen.Hva er farlig: Hvis en angriper legger inn en SQL-spørring i dette skjemaet, kan han krasje databasen eller avsløre konfidensiell informasjon.
Hva en webutvikler bør huske: Ikke stol på det som kommer fra nettleseren. Du må beskytte deg selv både på klientsiden og serversiden.
På klientsiden skriver du feltvalidering ved å bruke JavaScript.
Innebygde funksjoner i populære rammeverk bidrar også til å unnslippe mistenkelige karakterer på serveren. Det anbefales også å bruke parameteriserte databasespørringer på serveren.
Bestem hvor nøyaktig interaksjonen med databasen finner sted på nettapplikasjonen.
Interaksjon skjer når vi mottar informasjon: en forespørsel med en id (endring av id), opprettelse av en ny bruker, en ny kommentar eller nye oppføringer i databasen. Det er her SQL-injeksjoner kan oppstå. Selv om vi sletter en post fra databasen, er SQL-injeksjon mulig.
Generelle anbefalinger
Ikke oppfinn hjulet på nytt - bruk velprøvde rammer. Som regel er populære rammer sikrere. For .NET - ASP.NET MVC og ASP.NET Core, for Python - Django eller Flask, for Ruby - Ruby on Rails, for PHP - Symfony, Laravel, Yii, for JavaScript - Node.JS-Express.js, for Java - Fjær MVC.
Følg leverandøroppdateringer og oppdater regelmessig. De vil finne en sårbarhet, deretter skrive en utnyttelse, gjøre den offentlig tilgjengelig, og alt vil skje igjen. Abonner på oppdateringer til stabile versjoner fra programvareleverandøren.
Sjekk tillatelser. På serversiden, behandle alltid koden din som om den, fra den første til den siste bokstaven, ble skrevet av din mest forhatte fiende, som ønsker å ødelegge nettstedet ditt, krenke integriteten til dataene dine. Dessuten, noen ganger er dette sant.
Bruk kloner, teststeder, og bruk dem deretter til produksjon. Dette vil for det første bidra til å unngå feil og feil i et produktivt miljø: et produktivt miljø gir penger, et enkelt produktivt miljø er avgjørende. Når du legger til, fikser eller lukker et problem, er det verdt å jobbe i et testmiljø, deretter sjekke funksjonaliteten og sårbarhetene som er funnet, og deretter planlegge å jobbe med produksjonsmiljøet.
Beskytt nettapplikasjonen din med og integrere rapporter fra sårbarhetsskanneren med den. DataLine bruker for eksempel Qualys og FortiWeb som en pakke med tjenester.
Kilde: www.habr.com