Dödssynder i webbplatsens säkerhet: vad vi har lärt oss från statistiken från sårbarhetsskannern under året

För ungefär ett år sedan lanserade vi på DataLine tjänst en tjänst för att söka och analysera sårbarheter i IT-applikationer. Grunden för tjänsten är den molnbaserade lösningen Qualys, vars funktioner vi redan har berättat om. Under ett års arbete med lösningen har vi genomfört 291 skanningar för olika webbplatser och samlat statistik över vanliga sårbarheter i webbapplikationer. 

I artikeln nedan visar jag vilka specifika säkerhetsluckor som döljer sig bakom olika kritikalitetsnivåer. Låt oss titta på vilka sårbarheter skannern lyckades upptäcka särskilt ofta, varför de kan uppstå och hur man kan skydda sig. 

Qualys delar in alla sårbarheter i webbapplikationer i tre kritikalitetsnivåer: låg, medel och hög. Om man ser på fördelningen efter "svårighetsgrad" ser det inte så illa ut. Det finns få sårbarheter med hög kritikalitet, de flesta är icke-kritiska: 

Men icke-kritiska betyder inte ofarliga. De kan också orsaka allvarlig skada. 

Topp icke-kritiska sårbarheter

1. Sårbarheter kopplade till blandat innehåll.

   En säkerhetsstandard för webbplatser är att överföra data mellan klient och server via protokollet HTTPS, som möjliggör kryptering och skyddar informationen från att bli avlyssnad. 

   Vissa webbplatser använder blandat innehåll: de överför en del data över det oskyddade protokollet HTTP. Vanligtvis överförs passivt innehåll – information som endast påverkar webbplatsens visning: bilder, CSS-stilar. Men ibland överförs även aktivt innehåll: skript som styr webbplatsens beteende. I det här fallet kan man med hjälp av speciell programvara analysera information som kommer från servern med aktivt innehåll, modifiera sina svar i realtid och få systemet att fungera på ett sätt som inte var avsett av dess skapare. 

   Webbläsare i nya versioner varnar användare för att webbplatser med blandat innehåll är osäkra och blockerar innehåll. Webbplatsutvecklare får också varningar från webbläsaren i konsolen. Så här ser det ut i Firefox: 

   
   
   Vad är faran: Brottslingar utnyttjar det oskyddade protokollet för att avlyssna användarinformation, byta ut skript och skicka förfrågningar till webbplatsen i dess namn. Även om besökaren på webbplatsen inte har angett några uppgifter skyddar det inte mot fiske – att samla in konfidentiell information genom bedrägliga metoder. Till exempel, med hjälp av ett skript kan man omdirigera användaren till en osäker webbplats som maskerar sig som en bekant. I vissa fall kan den skadliga webbplatsen se till och med bättre ut än originalet, och användaren kan själv fylla i formuläret och överlämna känsliga uppgifter. 

   Vad webbprogrammerare bör komma ihåg: Även om webbplatsens administratör har installerat och konfigurerat SSL/TLS-certifikatet kan sårbarheter uppstå på grund av mänskliga faktorer. Om en av sidorna har angett en absolut länk med http istället för en relativ, och om vidare ingen omdirigering från http till https har konfigurerats. 

   För att upptäcka blandat innehåll på webbplatsen kan man använda webbläsaren: leta genom sidans källkod, läsa meddelanden i utvecklarkonsolen. Men utvecklaren kommer att behöva gräva djupt i koden. Processen kan påskyndas med automatiserade analysverktyg, till exempel: SSL Check, gratisprogrammet Lighthouse eller den betalda programvaran Screaming Frog SEO Spider.

   Sårbarhet kan också uppstå på grund av problem med legacy-kod – kod som har ärvts. Till exempel, om en del av sidorna genereras av en gammal mall där övergången till https inte beaktas.    

2. Cookies utan flaggorna "HTTPOnly" och "secure".

   Attributet "HTTPOnly" skyddar cookies från att behandlas av skript som angripare använder för att stjäla användardata. Flaggan "secure" tillåter inte överföring av cookies i klartext. Datautbytet tillåts endast om säkrad protokoll HTTPS används för att skicka cookies. 

   Båda attributen anges i cookie-egenskaper:

   Set-Cookie: Secure; HttpOnly

   Vad är faran: Om webbplatsens utvecklare inte angav dessa attribut kan angriparen snappa upp användarinformation från cookies och använda den. Om cookies används för autentisering och auktorisering kan hen ta över användarens session och utföra åtgärder på webbplatsen i dennes namn. 

   Vad webbprogrammerare bör komma ihåg: I populära ramverk anges dessa attribut vanligtvis automatiskt. Men kontrollera alltid webbserverns konfiguration och ställ in flaggan: Set-Cookie HttpOnly; Secure.

   Observera att attributet "HTTPOnly" gör cookies osynliga även för din egen JavaScript.  

3. Path-Based Vulnerabilities ("vägbaserade" sårbarheter).

   Skannern rapporterar om en sårbarhet när den hittar en offentligt tillgänglig fil eller katalog på webbplatsen med potentiellt konfidentiell information. Till exempel upptäckta enskilda filer med systemkonfiguration eller åtkomst till hela filsystemet. Denna situation kan uppstå om åtkomsträttigheterna på webbplatsen är felaktigt inställda.

   Vad är faran: Om filsystemet "syns utåt" kan en angripare få tillgång till operativsystemets gränssnitt och försöka hitta mappar med lösenord om de lagras i klartext (gör inte så!). Alternativt kan de stjäla hash-koder för lösenord och försöka gissa lösenordet, samt försöka höja sina privilegier i systemet och avancera djupare in i infrastrukturen.  

   Vad webbprogrammerare bör komma ihåg: Glöm inte åtkomsträttigheterna och konfigurera plattformen, webbservern och webbapplikationen så att ingen kan "fly" från webbkatalogen.

4. Formulär för att ange konfidentiell information med aktiverad autofyllfunktion.

   Om en användare ofta fyller i formulär på webbplatser sparar deras webbläsare denna information med autofyllfunktionen. 

   Formulär på webbplatser kan inkludera fält med konfidentiell information, till exempel lösenord eller kreditkortsnummer. För sådana fält bör autofyllfunktionen inaktiveras på webbplatsen. 

   Vad är faran: Om användarens webbläsare sparar konfidentiell information kan en angripare fånga upp den senare, till exempel genom phishing. I grund och botten utsätter webbdesignern, som glömmer detta detalj, sina användare. 

   Vad webbprogrammerare bör komma ihåg: I detta fall har vi en klassisk konflikt: bekvämlighet vs säkerhet. Om webbdesignern prioriterar användarkomfort kan de medvetet välja autofyllning. Till exempel, om det är viktigt att följa Web Content Accessibility Guidelines – riktlinjer för tillgänglighet av innehåll för användare med funktionsnedsättningar. 

   För de flesta webbläsare kan autofyll inaktiveras med attributet autocompete="off", till exempel:

    <body>
       <form action="/sv/form/submit/" method="get" autocomplete="off" data-trp-original-action="/form/submit">
         <div>
           <input type="text" placeholder="Förnamn">
         </div>
         <div>
           <input type="text" id="lname" placeholder="Efternamn" autocomplete="on">
         </div>
         <div>
           <input type="number" placeholder="Kreditkortsnummer">
         </div>
         <input type="submit">
       <input type="hidden" name="trp-form-language" value="sv"/></form>
     </body>

   Men för Chrome fungerar det inte. Detta kringgås med hjälp av JavaScript, en variant av receptet kan hittas här. 

5. I webbplatsens kod är X-Frame-Options-rubriken inte angiven. 

   Denna rubrik påverkar taggar som frame, iframe, embed eller object. Genom att använda den kan du helt förbjuda inbäddning av din webbplats i ett ramverk. För detta måste du ange värdet X-Frame-Options: deny. Alternativt kan du ange X-Frame-Options: sameorigin, vilket gör inbäddning i iframe tillgänglig endast på din egen domän.

   Vad är faran: Avsaknaden av denna rubrik kan användas på skadliga webbplatser för clickjacking. För denna attack skapar angriparen en genomskinlig ram ovanför knappar och lurar användaren. Till exempel placerar bedragare en ram för en sida med sociala medier. Användaren tror att de klickar på en knapp på denna webbplats. Istället fångas klicket och skickar en begäran från användaren till sociala medier där det finns en aktiv session. På så sätt skickar angriparna skräppost i användarens namn eller manipulerar prenumeranter och gilla-markeringar. 

   Om denna möjlighet inte förhindras kan angriparen placera en knapp för din applikation på en skadlig webbplats. Hen kan vara intresserad av ditt referralsprogram eller dina användare.  

   Vad webbprogrammerare bör komma ihåg: En sårbarhet kan uppstå om X-Frame-Options med ett konfliktvärde anges på webbservern eller lastbalanseraren. I detta fall kommer servern och lastbalanseraren helt enkelt att åsidosätta rubriken, eftersom de har högre prioritet än koden för backend-delen.  

   Värdena deny och sameorigin för X-Frame-Options-rubriken kommer att störa webvisorens funktioner från Yandex. För att tillåta användning av iframe för webvisor måste du skriva en separat regel i inställningarna. Till exempel kan det för nginx konfigureras så här:

   http{
   ...
    map $http_referer $frame_options {
    "~webvisor.com" "ALLOW-FROM http://webvisor.com";
    default "SAMEORIGIN";
    }
    add_header X-Frame-Options $frame_options;
   ...
   }
   
   

6. Sårbarheter PRSSI (Path-relative stylesheet import).  

   Detta är en sårbarhet i webbplatsens stilar. Den uppstår om relativa länkar av typen href="/somefolder/styles.css/" används för att referera till stilfiler. En angripare kommer att utnyttja detta om de hittar ett sätt att omdirigera användaren till en skadlig sida. Sidan kommer att infoga den relativa länken i sin URL och imitera en begäran om stilar. Resultatet blir en begäran liknande badsite.ru/.../somefolder/styles.css/, som under sken av stil kan utföra skadliga handlingar. 

   Vad är faran: En bedragare kan utnyttja denna sårbarhet om de hittar en annan säkerhetslucka. Som ett resultat kan användardata från cookies eller tokens stjälas.

   Vad webbprogrammerare bör komma ihåg: Sätt rubriken X-Content-Type-Options: nosniff. I så fall kommer webbläsaren att kontrollera innehållstypen för stilar. Om typen skiljer sig från text/css kommer webbläsaren att blockera begäran.

Kritiska sårbarheter

1. Sidan med fält för lösenord överförs från servern via en osäker kanal (HTML-formulär med lösenordsfält överförs via HTTP).

   Svaret från servern över en okrypterad kanal är sårbart för man-in-the-middle-attacker. En angripare kan fånga upp trafiken och klippa in sig mellan klienten och servern när sidan går från servern till klienten. 

   Vad är faran: En bedragare kan manipulera sidan och skicka en formulär för konfidentiella uppgifter till användaren, som sedan går till angriparens server. 

   Vad webbprogrammerare bör komma ihåg: Vissa webbplatser skickar en engångskod via e-post/telefon istället för ett lösenord. I detta fall är sårbarheten inte så kritisk, men mekanismen kan försvåra livet för användarna.

2. Skickar formulär med användarnamn och lösenord via en osäker kanal (Inloggningsformuläret skickas inte via HTTPS).

   I detta fall skickas formuläret med användarnamn och lösenord till servern via en okrypterad kanal.

   Vad är faran: Till skillnad från det föregående fallet är detta en kritisk sårbarhet. Att fånga konfidentiella uppgifter är enklare, eftersom du inte ens behöver skriva kod för det. 

3. Användning av JavaScript-bibliotek med kända sårbarheter.

   Under tiden för skanning har jQuery blivit det mest använda biblioteket med ett omfattande utbud av versioner. I varje version finns det åtminstone en, eller fler, kända sårbarheter. Effekten kan variera – beroende på sårbarhetens natur.

   Vad är faran: För kända sårbarheter finns det exploits, exempelvis:

   
   
   Vad webbprogrammerare bör komma ihåg: Återkom regelbundet till cykeln: söka kända sårbarheter – åtgärda – kontrollera. Om du medvetet använder föråldrade bibliotek, exempelvis för att stödja gamla webbläsare eller för att spara budgeten, leta efter möjligheter att åtgärda kända sårbarheter. 

4. Cross-Site Scripting (XSS). 
   Cross-Site Scripting (XSS), eller mellanwebbskrift, är attacker mot webbapplikationer där skadlig kod hamnar i databasen. Om Qualys hittar en sådan sårbarhet innebär det att en potentiell angripare kan ha injicerat eller redan har injicerat sin js-kod i webbplatsens kod för att utföra skadliga handlingar.

   Lagrat XSS (Stored XSS) är mer farliga eftersom skriptet injiceras på servern och körs varje gång den attackerade sidan öppnas i webbläsaren.

   Reflekterat XSS (Reflected XSS) är enklare att genomföra, eftersom den skadliga skriptet kan injiceras i HTTP-förfrågan. Applikationen tar emot HTTP-förfrågan, kontrollerar inte data, packar dem och skickar dem omedelbart. Om angriparen fångar trafiken och sätter in ett skript av typen

   <script>/*+что+то+плохое+*/</script> 

   går en skadlig begäran från klientens namn.

   Ett tydligt exempel på XSS: js-sniffers som imiterar sidor för att ange CVC, utgångsdatum på kort och så vidare. 

   Vad webbprogrammerare bör komma ihåg: I rubriken Content-Security-Policy använd attributet script-src för att klientens webbläsare endast ska ladda och köra kod från en betrodd källa. Till exempel, script-src 'self' lägger alla skript från vår webbplats på vitlistan. 
   Den bästa metoden anses vara Inline-kod: tillåt endast inline javascript med värdet unsafe-inline. Detta värde tillåter användning av inline js/css, men förbjuder inte laddning av js-filer. I kombination med script-src 'self' förbjuder vi körning av externa skript.

   Se till att logga allt med hjälp av report-uri och titta på försök att injicera kod på webbplatsen.

5. SQL-injektioner.
   Sårbarheten antyder att det finns möjlighet att injicera SQL-kod på webbplatsen, som direkt kontaktar webbplatsens databas. SQL-injektion är möjlig om användardata inte är korrekt säkerställd: de kontrolleras inte för giltighet och används omedelbart i förfrågan. Till exempel sker detta om formuläret på webbplatsen inte kontrollerar att indata överensstämmer med datatypen. 

   Vad är faran: Om en angripare matar in en SQL-fråga i ett sådant formulär kan han förstöra databasen eller avslöja konfidentiell information. 

   Vad webbprogrammerare bör komma ihåg: Lita inte på det som kommer från webbläsaren. Skydd bör göras både på klientsidan och på serversidan. 

   På klientsidan, skriv en kontroll av fälten med hjälp av JavaScript. 

   Inbyggda funktioner i populära ramverk hjälper också till att skydda misstänkta tecken på servern. På servern rekommenderas det också att använda parametriserade databasfrågor.

   Definiera var interaktionen med databasen sker i webbapplikationen. 

   Interaktionen uppstår när vi hämtar någon information: en förfrågan med id (ändring av id), skapande av en ny användare, ny kommentar – nya poster i databasen. Här kan SQL-injektioner uppstå. Även när vi tar bort en post från databasen kan en SQL-injektion vara möjlig.

Allmänna rekommendationer

Hitta inte på hjulet – använd beprövade ramverk. Vanligtvis är populära ramverk mer säkra. För .NET är det ASP.NET MVC och ASP.NET Core, för Python – Django eller Flask, för Ruby – Ruby on Rails, för PHP – Symfony, Laravel, Yii, för JavaScript – Node.JS-Express.js, för Java – Spring MVC.

Håll dig uppdaterad med leverantörens nyheter och uppdatera regelbundet. Sårbarheter hittas, exploateringskod skrivs, publiceras och allt händer igen. Prenumerera på uppdateringar till stabila versioner från programvaruleverantören.

Kontrollera åtkomsträttigheter. Behandla alltid din kod från serverns sida som om den är skriven av din mest avskyvärda fiende, som vill bryta din webbplats och bryta integriteten av dina data. Dessutom är det ibland faktiskt så.

Använd kloner, testmiljöer, och implementera sedan på produktion. Detta hjälper, å ena sidan, att undvika misstag och brister i produktionsmiljön: produktionsmiljön genererar pengar, driftstopp i produktionsmiljö är kritiska. Vid tillägg, korrigering eller stängning av ett problem bör arbetet utföras i testmiljö, sedan kontrolleras funktionaliteten och identifierade sårbarheter, och först därefter planera arbete med produktionsmiljön. 

Skydda webbapplikationen med Web Application Firewall och integrera med den rapporter från sårbarhetsscannern. Till exempel i DataLine används Qualys och FortiWeb som en bindande tjänst.

Källa: habr.com