For omkring et år siden lancerede vi hos DataLine at søge og analysere sårbarheder i it-applikationer. Tjenesten er baseret på Qualys cloud-løsning, om driften af denne . I løbet af et års arbejde med løsningen gennemførte vi 291 scanninger for forskellige websteder og akkumulerede statistikker over almindelige sårbarheder i webapplikationer.
I artiklen nedenfor vil jeg vise dig præcis, hvilke huller i webstedssikkerhed, der gemmer sig bag forskellige niveauer af kritik. Lad os se, hvilke sårbarheder scanneren fandt særligt ofte, hvorfor de kan opstå, og hvordan du beskytter dig selv.
Qualys opdeler alle webapplikationssårbarheder i tre kritiske niveauer: lav, medium og høj. Hvis man ser på fordelingen efter "sværhedsgrad", ser det ud til, at alt ikke er så slemt. Der er få sårbarheder med et højt niveau af kritik, for det meste er alle ikke-kritiske:
Men ukritisk betyder ikke harmløs. De kan også forårsage alvorlig skade.
Top "ikke-kritiske" sårbarheder
- Sårbarheder med blandet indhold.
Standarden for webstedssikkerhed er overførsel af data mellem klienten og serveren via HTTPS-protokollen, som understøtter kryptering og beskytter information mod aflytning.
Nogle websteder bruger blandet indhold: Nogle data overføres via den usikre HTTP-protokol. Sådan formidles det oftest passivt indhold – oplysninger, der kun påvirker visningen af webstedet: billeder, css-stile. Men nogle gange er det sådan, det overføres aktivt indhold: scripts, der styrer webstedets adfærd. I dette tilfælde kan du ved hjælp af speciel software analysere information med aktivt indhold, der kommer fra serveren, ændre dine svar på farten og få maskinen til at fungere på en måde, der ikke var tiltænkt af dens skabere.
Nyere versioner af browsere advarer brugere om, at websteder med blandet indhold er usikre og blokerer indholdet. Webstedsudviklere modtager også browseradvarsler i konsollen. Sådan ser det for eksempel ud i :
Hvorfor er det farligt?: Angribere bruger en usikker protokol til at opsnappe brugeroplysninger, erstatte scripts og sende anmodninger til webstedet på hans vegne. Selvom en besøgende ikke indtastede data, beskytter dette ham ikke mod phishing – indhentning af fortrolige oplysninger ved hjælp af svigagtige metoder. Ved at bruge et script kan du f.eks. omdirigere brugeren til et usikkert websted, der udgiver sig som et, som brugeren kender. I nogle tilfælde ser det ondsindede websted endnu bedre ud end originalen, og brugeren kan selv udfylde formularen og indsende fortrolige data.Hvad en webudvikler skal huske: Selvom webstedsadministratoren har installeret og konfigureret et SSL/TLS-certifikat, kan der opstå en sårbarhed på grund af menneskelige fejl. For eksempel hvis du på en af siderne ikke lægger et relativt link, men et absolut link fra http, og derudover ikke har opsat omdirigeringer fra http til https.
Du kan registrere blandet indhold på et websted ved hjælp af en browser: søg i sidens kildekode, læs meddelelser i udviklerkonsollen. Udvikleren bliver dog nødt til at pille ved koden i lang tid og kedeligt. Du kan fremskynde processen med automatiserede analyseværktøjer, for eksempel: , gratis Lighthouse-software eller betalt software Screaming Frog SEO Spider.
Sårbarheden kan også opstå på grund af problemer med legacy-code - kode, der blev nedarvet. For eksempel hvis nogle sider er genereret ved hjælp af en gammel skabelon, som ikke tager højde for overgangen af websteder til https.
- Cookies uden "HTTPOnly" og "secure" flag.
"HTTPOnly"-attributten beskytter cookies mod at blive behandlet af scripts, som angribere bruger til at stjæle brugerdata. Det "sikre" flag tillader ikke, at cookies sendes i klartekst. Kommunikation vil kun være tilladt, hvis den sikre HTTPS-protokol bruges til at sende cookien.
Begge attributter er angivet i cookieegenskaberne:
Set-Cookie: Secure; HttpOnlyHvorfor er det farligt?: Hvis webstedsudvikleren ikke specificerede disse attributter, kunne en angriber opsnappe brugerens oplysninger fra cookien og udnytte dem. Hvis cookies bruges til autentificering og autorisation, vil han være i stand til at kapre brugerens session og udføre handlinger på siden på hans vegne.
Hvad en webudvikler skal huske: Som regel indstilles disse attributter automatisk i populære rammer. Men tjek stadig webserverens konfiguration og sæt flaget: Set-Cookie HttpOnly; Sikker.
I dette tilfælde vil "HTTPOnly"-attributten gøre cookies usynlige for dit eget JavaScript.
- Stibaserede sårbarheder.
Scanneren rapporterer en sådan sårbarhed, hvis den finder en offentligt tilgængelig fil eller webstedsmappe med potentielt fortrolige oplysninger. For eksempel registrerer den individuelle systemkonfigurationsfiler eller adgang til hele filsystemet. Denne situation er mulig, hvis adgangsrettigheder er indstillet forkert på webstedet.
Hvorfor er det farligt?: Hvis filsystemet "stikker ud", kan en angriber falde ind i operativsystemets grænseflade og forsøge at finde mapper med adgangskoder, hvis de er gemt i klartekst (det skal du ikke gøre!). Eller du kan stjæle adgangskode-hashes og brute force-adgangskoden, og også prøve at hæve privilegier i systemet og bevæge dig dybere ind i infrastrukturen.
Hvad en webudvikler skal huske: Glem ikke adgangsrettigheder og konfigurer platformen, webserveren, webapplikationen, så det er umuligt at "undslippe" webbiblioteket.
- Formularer til indtastning af følsomme data med automatisk udfyldning aktiveret.
Hvis en bruger ofte udfylder formularer på websteder, gemmer deres browser disse oplysninger ved hjælp af autofyld-funktionen.
Formularer på websteder kan indeholde felter med følsomme oplysninger, såsom adgangskoder eller kreditkortnumre. For sådanne felter er det værd at deaktivere formularens autoudfyldningsfunktion på selve webstedet.
Hvorfor er det farligt?: Hvis brugerens browser gemmer følsomme oplysninger, kan en angriber opsnappe dem senere, for eksempel gennem phishing. I bund og grund sætter en webudvikler, der har glemt denne nuance, sine brugere op.
Hvad en webudvikler skal huske: I dette tilfælde har vi en klassisk konflikt: bekvemmelighed vs. sikkerhed. Hvis en webudvikler tænker på brugeroplevelse, kan han bevidst vælge autofuldførelse. For eksempel hvis det er vigtigt at følge med – anbefalinger til tilgængelighed af indhold for brugere med handicap.
For de fleste browsere kan du deaktivere autofuldførelse med attributten autocompete="off", for eksempel:
<body> <form action="/da/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 virker ikke for Chrome. Dette omgås ved hjælp af JavaScript, en variant af opskriften kan findes .
- X-Frame-Options-headeren er ikke angivet i webstedskoden.
Denne header påvirker ramme-, iframe-, embed- eller objekttags. Med dens hjælp kan du helt forbyde indlejring af dit websted i en ramme. For at gøre dette skal du angive værdien X-Frame-Options: deny. Eller du kan angive X-Frame-Options: sameorigin, så vil indlejring i en iframe kun være tilgængelig på dit domæne.
Hvorfor er det farligt?: Fraværet af en sådan header kan bruges på ondsindede websteder til clickjacking. Til dette angreb skaber angriberen en gennemsigtig ramme oven på knapperne og narre brugeren. For eksempel: svindlere rammer sociale netværkssider på et websted. Brugeren tror, han klikker på en knap på denne side. I stedet opsnappes klikket, og brugerens anmodning sendes til det sociale netværk, hvor der er en aktiv session. Sådan sender angribere spam på vegne af brugeren eller får abonnenter og likes.
Hvis du ikke deaktiverer denne funktion, kan en hacker placere din applikationsknap på et ondsindet websted. Han kan være interesseret i dit henvisningsprogram eller dine brugere.
Hvad en webudvikler skal huske: Sårbarheden kan opstå, hvis X-Frame-Options med en modstridende værdi er indstillet på webserveren eller belastningsbalanceren. I dette tilfælde vil serveren og balanceren blot omskrive headeren, da de har en højere prioritet sammenlignet med backend-koden.
Deny og sameorigin-værdierne i X-Frame-Options-headeren vil forstyrre driften af Yandex-webfremviseren. For at tillade brug af iframes til webfremviseren skal du skrive en separat regel i indstillingerne. For eksempel, for nginx kan du konfigurere det sådan:
http{ ... map $http_referer $frame_options { "~webvisor.com" "ALLOW-FROM http://webvisor.com"; default "SAMEORIGIN"; } add_header X-Frame-Options $frame_options; ... } - PRSSI (sti-relative stylesheet import) sårbarheder.
Dette er en sårbarhed i webstedets styling. Det opstår, hvis relative links som href="/da/somefolder/styles.css/" bruges til at få adgang til stilfiler. En angriber vil drage fordel af dette, hvis de finder en måde at omdirigere brugeren til en ondsindet side. Siden vil indsætte et relativt link i sin url og simulere et stilkald. Du vil få en anmodning som badsite.ru/…/somefolder/styles.css/, som kan udføre ondsindede handlinger under dække af en stil.
Hvorfor er det farligt?: En svindler kan udnytte denne sårbarhed, hvis de finder et andet sikkerhedshul. Som følge heraf er det muligt at stjæle brugerdata fra cookies eller tokens.
Hvad en webudvikler skal huske: Indstil X-Content-Type-Options overskriften til: nosniff. I dette tilfælde vil browseren kontrollere indholdstypen for stilene. Hvis typen er en anden end tekst/css, vil browseren blokere anmodningen.
Kritiske sårbarheder
- En side med et adgangskodefelt sendes fra serveren over en usikker kanal (HTML-formular, der indeholder adgangskodefelt(er) serveres over HTTP).
Svaret fra serveren over en ukrypteret kanal er sårbart over for "Man in the middle"-angreb. En angriber kan opsnappe trafik og kile sig ind mellem klienten og serveren, når siden bevæger sig fra serveren til klienten.
Hvorfor er det farligt?: Svindleren vil være i stand til at erstatte siden og sende brugeren en formular til fortrolige data, som vil gå til angriberens server.
Hvad en webudvikler skal huske: Nogle websteder sender brugere en engangskode via e-mail/telefon i stedet for en adgangskode. I dette tilfælde er sårbarheden ikke så kritisk, men mekanismen vil komplicere brugernes liv.
- Afsendelse af en formular med login og adgangskode over en usikker kanal (Loginformular sendes ikke via HTTPS).
I dette tilfælde sendes en formular med login og adgangskode fra brugeren til serveren via en ukrypteret kanal.
Hvorfor er det farligt?: I modsætning til det tidligere tilfælde er dette allerede en kritisk sårbarhed. Det er nemmere at opsnappe følsomme data, fordi du ikke engang behøver at skrive kode for at gøre det.
- Brug af JavaScript-biblioteker med kendte sårbarheder.
Under scanningen var det mest brugte bibliotek jQuery med et stort antal versioner. Hver version har mindst én eller endnu flere kendte sårbarheder. Virkningen kan være meget forskellig afhængig af sårbarhedens karakter.
Hvorfor er det farligt?: Der er udnyttelse af kendte sårbarheder, for eksempel:
Hvad en webudvikler skal huske: Vend jævnligt tilbage til cyklussen: søg efter kendte sårbarheder - fix - tjek. Hvis du bruger ældre biblioteker bevidst, for eksempel for at understøtte ældre browsere eller for at spare penge, skal du kigge efter en mulighed for at rette en kendt sårbarhed. - Cross-site scripting (XSS).
Cross-Site Scripting (XSS), eller cross-site scripting, er et angreb på en webapplikation, der resulterer i, at malware introduceres i databasen. Hvis Qualys finder en sådan sårbarhed, betyder det, at en potentiel angriber kan eller allerede har introduceret sit eget js-script i webstedskoden for at udføre ondsindede handlinger.Lagret XSS mere farligt, da scriptet er indlejret på serveren og udføres hver gang den angrebne side åbnes i browseren.
Reflekteret XSS lettere at udføre, da et ondsindet script kan injiceres i en HTTP-anmodning. Applikationen vil modtage en HTTP-anmodning, vil ikke validere dataene, pakke dem og sende dem med det samme. Hvis en angriber opsnapper trafik og indsætter et script som f.eks
<script>/*+что+то+плохое+*/</script>så vil en ondsindet anmodning blive sendt på vegne af klienten.
Et slående eksempel på XSS: js sniffere, der simulerer sider til indtastning af CVC, kortets udløbsdato og så videre.
Hvad en webudvikler skal huske: I overskriften Content-Security-Policy skal du bruge script-src-attributten til at tvinge klientbrowseren til kun at downloade og udføre kode fra en pålidelig kilde. For eksempel hvidlister script-src 'self' kun alle scripts fra vores side.
Den bedste praksis er Inline-kode: tillad kun inline-javascript ved hjælp af unsafe-inline-værdien. Denne værdi tillader brugen af inline js/css, men forbyder ikke inkludering af js-filer. I kombination med script-src 'self' deaktiverer vi eksterne scripts fra at blive udført.Sørg for at logge alt ved hjælp af report-uri og se på forsøg på at implementere det på webstedet.
- SQL-injektioner.
Sårbarheden angiver muligheden for at injicere SQL-kode i en hjemmeside, der tilgår hjemmesidens database direkte. SQL-injektion er mulig, hvis data fra brugeren ikke er screenet: det kontrolleres ikke for korrekthed og bruges straks i forespørgslen. Det sker for eksempel, hvis en formular på en hjemmeside ikke tjekker, om input passer til datatypen.Hvorfor er det farligt?: Hvis en angriber indtaster en SQL-forespørgsel i denne formular, kan han crashe databasen eller afsløre fortrolige oplysninger.
Hvad en webudvikler skal huske: Stol ikke på det, der kommer fra browseren. Du skal beskytte dig selv på både klientsiden og serversiden.
På klientsiden skal du skrive feltvalidering ved hjælp af JavaScript.
Indbyggede funktioner i populære frameworks hjælper også med at undslippe mistænkelige karakterer på serveren. Det anbefales også at bruge parameterbaserede databaseforespørgsler på serveren.
Bestem, hvor nøjagtigt interaktionen med databasen finder sted på webapplikationen.
Interaktion opstår, når vi modtager information: en anmodning med et id (ændring af id), oprettelse af en ny bruger, en ny kommentar eller nye poster i databasen. Det er her SQL-injektioner kan forekomme. Selvom vi sletter en post fra databasen, er SQL-injektion mulig.
Generelle anbefalinger
Opfind ikke hjulet igen - brug afprøvede rammer. Generelt er populære rammer mere sikre. For .NET - ASP.NET MVC og ASP.NET Core, for Python - Django eller Flask, for Ruby - Ruby on Rails, til PHP - Symfony, Laravel, Yii, for JavaScript - Node.JS-Express.js, til Java - Fjeder MVC.
Følg leverandøropdateringer og opdater regelmæssigt. De vil finde en sårbarhed, så skrive en udnyttelse, gøre den offentlig tilgængelig, og alt vil ske igen. Abonner på opdateringer til stabile versioner fra softwareleverandøren.
Tjek adgangsrettigheder. På serversiden skal du altid behandle din kode, som om den, fra det første til det sidste bogstav, er skrevet af din mest hadede fjende, som ønsker at bryde dit websted, krænke integriteten af dine data. Desuden er dette nogle gange sandt.
Brug kloner, teststeder, og brug dem derefter til produktion. Dette vil for det første hjælpe med at undgå fejl og fejl i et produktivt miljø: et produktivt miljø giver penge, et enkelt produktivt miljø er afgørende. Når du tilføjer, retter eller lukker ethvert problem, er det værd at arbejde i et testmiljø, derefter kontrollere den fundne funktionalitet og sårbarheder og derefter planlægge at arbejde med produktionsmiljøet.
Beskyt din webapplikation med og integrere rapporter fra sårbarhedsscanneren med det. For eksempel bruger DataLine Qualys og FortiWeb som en pakke af tjenester.
Kilde: www.habr.com