Ongeveer een jaar geleden hebben we bij DataLine een dienst gelanceerd voor het zoeken en analyseren van kwetsbaarheden in IT-applicaties. De basis van de service is de cloudoplossing Qualys, waar we al eerder over hebben gesproken. In het onderstaande artikel zal ik laten zien welke beveiligingslekken zich achter verschillende niveaus van kritischheid verbergen. Laten we kijken welke kwetsbaarheden de scanner het vaakst heeft aangetroffen, waarom ze kunnen optreden en hoe je jezelf kunt beschermen.
Qualys deelt alle kwetsbaarheden van webapplicaties in drie niveaus van kritischheid in: laag, gemiddeld en hoog. Als we naar de verdeling op 'ernst' kijken, lijkt het erop dat het allemaal niet zo slecht is. Er zijn weinig kwetsbaarheden met een hoog kritischiteitsniveau, voornamelijk zijn ze allemaal niet-kritisch:
Maar niet-kritisch betekent niet onschadelijk. Ze kunnen ook ernstige schade aanrichten.
Top 'niet-kritische' kwetsbaarheden
Kwetsbaarheden die verband houden met gemengd verkeer.
- De standaard voor websitebeveiliging is het overdragen van gegevens tussen de cliënt en de server via het HTTPS-protocol, dat encryptie ondersteunt en informatie beschermt tegen onderschepping.
Sommige websites gebruiken
gemengd verkeer : ze verzenden een deel van de gegevens via het onveilige HTTP-protocol. Dit gebeurt meestal voorpassieve inhoud - informatie die alleen van invloed is op de weergave van de website: afbeeldingen, css-stijlen. Maar soms wordt ook actieve inhoud : scripts die het gedrag van de website aansturen. In dit geval kan speciale software de informatie van de server met actieve inhoud analyseren, de antwoorden in realtime aanpassen en de machine laten functioneren op een manier die niet door de makers was bedoeld.Browsers van nieuwe versies waarschuwen gebruikers dat websites met gemengd verkeer onveilig zijn en blokkeren inhoud. Websiteontwikkelaars krijgen ook waarschuwingen van de browser in de console. Zo ziet dit eruit in
Wat is gevaarlijk :
: Aanvallers gebruiken het onveilige protocol om informatie over de gebruiker te onderscheppen, scripts te vervangen en verzoeken naar de website te sturen namens de gebruiker. Zelfs als de bezoeker geen gegevens invoert, beschermt dit hem niet tegenphishing. phishing – het verkrijgen van gevoelige informatie door middel van frauduleuze methoden. Bijvoorbeeld, met behulp van een script kan de gebruiker worden omgeleid naar een onveilige site die zich voordoet als een bekende. In sommige gevallen ziet de kwaadaardige site er zelfs beter uit dan het origineel, en kan de gebruiker zelf het formulier invullen en gevoelige gegevens verstrekken.Wat webontwikkelaars moeten onthouden: Zelfs als de sitebeheerder een SSL/TLS-certificaat heeft geïnstalleerd en geconfigureerd, kan er een kwetsbaarheid ontstaan door menselijke fouten. Bijvoorbeeld, als er op een van de pagina's geen relatieve link is geplaatst, maar een absolute link met http, en bovendien geen omleidingen van http naar https zijn ingesteld.
Gemengde content op een site kan worden gedetecteerd met behulp van een browser: zoek naar de broncode van de pagina, lees de meldingen in de ontwikkelaarsconsole. De ontwikkelaar moet echter uitgebreid door de code ploeteren. Het proces kan worden versneld met geautomatiseerde analysetools, bijvoorbeeld: , open source software Lighthouse of betaalde software Screaming Frog SEO Spider.
Ook kan een kwetsbaarheid ontstaan door problemen met legacy-code – code die is overgenomen. Bijvoorbeeld, als delen van de pagina's worden gegenereerd met een oud sjabloon, waarbij geen rekening wordt gehouden met de overstap naar https.
- Cookies zonder de vlaggen "HTTPOnly" en "secure".
De "HTTPOnly"-attribuut beschermt cookies tegen verwerking door scripts die door kwaadwillenden worden gebruikt om gebruikersgegevens te stelen. De "secure"-vlag staat niet toe dat cookies in open tekst worden verzonden. Gegevensuitwisseling is alleen toegestaan als voor het verzenden van cookies een beveiligd protocol HTTPS wordt gebruikt.
Beide attributen worden ingesteld in de cookie-eigenschappen:
Set-Cookie: Secure; HttpOnly: Aanvallers gebruiken het onveilige protocol om informatie over de gebruiker te onderscheppen, scripts te vervangen en verzoeken naar de website te sturen namens de gebruiker. Zelfs als de bezoeker geen gegevens invoert, beschermt dit hem niet tegen: Als de ontwikkelaar van de site deze attributen niet heeft opgegeven, kan een aanvaller gebruikersinformatie uit cookies onderscheppen en misbruiken. Als cookies worden gebruikt voor authenticatie en autorisatie, kan hij de gebruikerssessie overnemen en acties op de site uitvoeren namens de gebruiker.
Wat webontwikkelaars moeten onthouden: Over het algemeen worden deze attributen automatisch ingesteld in populaire frameworks. Maar controleer toch de configuratie van de webserver en zet de vlag: Set-Cookie HttpOnly; Secure.
Het "HTTPOnly"-attribuut maakt cookies ook onzichtbaar voor uw eigen JavaScript.
- Path-Based Vulnerabilities ("pad” kwetsbaarheden).
De scanner meldt een kwetsbaarheid als een publiek toegankelijk bestand of een directory van de site met potentieel vertrouwelijke informatie wordt gevonden. Bijvoorbeeld, als afzonderlijke bestanden met systeemconfiguraties of toegang tot het bestandssysteem als geheel worden ontdekt. Een dergelijke situatie kan zich voordoen als de toegangsrechten op de site niet correct zijn ingesteld.
: Aanvallers gebruiken het onveilige protocol om informatie over de gebruiker te onderscheppen, scripts te vervangen en verzoeken naar de website te sturen namens de gebruiker. Zelfs als de bezoeker geen gegevens invoert, beschermt dit hem niet tegen: Als het bestandssysteem 'buiten' zichtbaar is, kan een aanvaller via de interface van het besturingssysteem proberen om mappen met wachtwoorden te vinden, als deze openlijk zijn opgeslagen (doe dat alsjeblieft niet!). Of men kan hashes van wachtwoorden stelen en deze vervolgens raden, en ook proberen om de privileges binnen het systeem te verhogen en dieper in de infrastructuur door te dringen.
Wat webontwikkelaars moeten onthouden: Vergeet de toegangsrechten niet en configureer het platform, de webserver en het webapplicatie zodat men niet 'kan ontsnappen' uit de webdirectory.
- Formulieren voor het invoeren van vertrouwelijke gegevens met de functie voor automatisch aanvullen ingeschakeld.
Als een gebruiker vaak formulieren op websites invult, slaat zijn browser deze informatie op met de functie voor automatisch aanvullen.
Formulieren op websites kunnen velden met vertrouwelijke informatie bevatten, zoals wachtwoorden of creditcardnummers. Voor dergelijke velden is het aan te raden om op de website de functie voor automatisch aanvullen van formulieren uit te schakelen.
: Aanvallers gebruiken het onveilige protocol om informatie over de gebruiker te onderscheppen, scripts te vervangen en verzoeken naar de website te sturen namens de gebruiker. Zelfs als de bezoeker geen gegevens invoert, beschermt dit hem niet tegen: Als de browser van de gebruiker vertrouwelijke informatie opslaat, kan een aanvaller deze later onderscheppen, bijvoorbeeld via phishing. In feite stelt een webontwikkelaar die deze nuance vergeet zijn gebruikers bloot.
Wat webontwikkelaars moeten onthouden: In dat geval hebben we een klassiek conflict: gebruiksvriendelijkheid versus beveiliging. Als de webontwikkelaar nadenkt over het comfort van de gebruiker, kan hij bewust kiezen voor automatisch aanvullen. Bijvoorbeeld, als het belangrijk is om te volgen – richtlijnen voor de toegankelijkheid van content voor gebruikers met een beperking.
Voor de meeste browsers kan automatisch aanvullen worden uitgeschakeld met het attribuut autocompete=‘off’, bijvoorbeeld:
<body> <form action="/nl/form/submit/" method="get" autocomplete="off" data-trp-original-action="/form/submit"> <div> <input type="text" placeholder="Voornaam"> </div> <div> <input type="text" id="lname" placeholder="Achternaam" autocomplete="on"> </div> <div> <input type="number" placeholder="Creditcardnummer"> </div> <input type="submit"> <input type="hidden" name="trp-form-language" value="nl"/></form> </body>Maar voor Chrome werkt dat niet. Dit wordt omzeild met JavaScript; een alternatieve aanpak is te vinden. .
- In de code van de site is de X-Frame-Options header niet ingesteld.
Deze kop beïnvloedt de tags frame, iframe, embed of object. Hiermee kun je het volledig verbieden om je website in een frame in te voegen. Hiervoor moet je de waarde X-Frame-Options: deny opgeven. Of je kunt X-Frame-Options: sameorigin opgeven, dan is invoegen in een iframe alleen beschikbaar op je eigen domein.
: Aanvallers gebruiken het onveilige protocol om informatie over de gebruiker te onderscheppen, scripts te vervangen en verzoeken naar de website te sturen namens de gebruiker. Zelfs als de bezoeker geen gegevens invoert, beschermt dit hem niet tegen: Het ontbreken van deze kop kan door kwaadwillende websites worden gebruikt voor klikjacking. Bij deze aanval creëert de aanvaller een transparant frame bovenop knoppen en misleidt de gebruiker. Bijvoorbeeld: oplichters plaatsen een frame met pagina's van sociale netwerken. De gebruiker denkt dat hij op een knop op deze website klikt. In plaats daarvan wordt de klik onderschept en wordt een verzoek van de gebruiker naar het sociale netwerk gestuurd, waar een actieve sessie is. Zo verspreiden aanvallers spam namens de gebruiker of verhogen ze volgers en likes.
Als je deze mogelijkheid niet verbiedt, kan een aanvaller de knop van jouw applicatie op een kwaadwillende website plaatsen. Hij kan geïnteresseerd zijn in jouw affiliateprogramma of in jouw gebruikers.
Wat webontwikkelaars moeten onthouden: Een kwetsbaarheid kan zich voordoen als X-Frame-Options met een conflicterende waarde op de webserver of load balancer is ingesteld. In dat geval overschrijven de server en de load balancer gewoon de kop, aangezien zij een hogere prioriteit hebben dan de backend-code.
De waarden deny en sameorigin van de X-Frame-Options kop zullen de werking van de Yandex webvisor verstoren. Om iframe voor de webvisor toe te staan, moet je een aparte regel in de instellingen schrijven. Bijvoorbeeld, voor nginx kan dit als volgt worden ingesteld:
http{ ... map $http_referer $frame_options { "~webvisor.com" "ALLOW-FROM http://webvisor.com"; default "SAMEORIGIN"; } add_header X-Frame-Options $frame_options; ... } - Kwetsbaarheden PRSSI (Path-relative stylesheet import).
Dit is een kwetsbaarheid in de stijlen van de website. Deze ontstaat wanneer relatieve links zoals href="/somefolder/styles.css/" worden gebruikt om naar stijlbestanden te verwijzen. Een aanvaller zal hiervan profiteren als hij een manier vindt om de gebruiker naar een kwaadwillende pagina te leiden. De pagina zal de relatieve link in zijn URL invoegen en doet alsof deze naar stijlbestanden verwijst. Er ontstaat een aanvraag zoals badsite.ru/…/somefolder/styles.css/, die onder het mom van een stijl kwaadaardige acties kan ondernemen.
: Aanvallers gebruiken het onveilige protocol om informatie over de gebruiker te onderscheppen, scripts te vervangen en verzoeken naar de website te sturen namens de gebruiker. Zelfs als de bezoeker geen gegevens invoert, beschermt dit hem niet tegen: Een oplichter kan deze kwetsbaarheid misbruiken als hij een andere beveiligingslek vindt. Hierdoor kunnen gebruikt gegevens uit cookies of tokens worden gestolen.
Wat webontwikkelaars moeten onthouden: Stel de header X-Content-Type-Options: nosniff in. In dit geval controleert de browser het contenttype voor stijlen. Als het type verschilt van text/css, wordt het verzoek geblokkeerd door de browser.
Kritische kwetsbaarheden
- Een pagina met een invoerveld voor een wachtwoord wordt via een onveilige verbinding van de server verzonden (HTML-formulier met wachtwoordvelden wordt via HTTP verzonden).
Een antwoord van de server via een onversleutelde verbinding is kwetsbaar voor 'Man in the Middle'-aanvallen. Een aanvaller kan het verkeer onderscheppen en zich tussen de cliënt en de server plaatsen wanneer de pagina van de server naar de cliënt wordt verzonden.
: Aanvallers gebruiken het onveilige protocol om informatie over de gebruiker te onderscheppen, scripts te vervangen en verzoeken naar de website te sturen namens de gebruiker. Zelfs als de bezoeker geen gegevens invoert, beschermt dit hem niet tegen: Een oplichter kan de pagina vervangen en de gebruiker een formulier voor vertrouwelijke gegevens sturen, die naar de server van de oplichter worden verzonden.
Wat webontwikkelaars moeten onthouden: Sommige websites sturen gebruikers in plaats van een wachtwoord een eenmalige code per e-mail/telefoon. In dit geval is de kwetsbaarheid minder kritiek, maar het maakt het leven van gebruikers moeilijker.
- Het indienen van een formulier met inloggegevens via een onveilige verbinding (Inlogformulier wordt niet via HTTPS verzonden).
In dit geval wordt het formulier met inloggegevens door de gebruiker via een onversleutelde verbinding naar de server verzonden.
: Aanvallers gebruiken het onveilige protocol om informatie over de gebruiker te onderscheppen, scripts te vervangen en verzoeken naar de website te sturen namens de gebruiker. Zelfs als de bezoeker geen gegevens invoert, beschermt dit hem niet tegen: In tegenstelling tot het vorige geval is dit al een kritieke kwetsbaarheid. Het is eenvoudiger om vertrouwelijke gegevens te onderscheppen, aangezien er geen code voor geschreven hoeft te worden.
- Het gebruik van JavaScript-bibliotheken met bekende kwetsbaarheden.
Tijdens de scan bleek de meest gebruikte bibliotheek jQuery te zijn, met een breed scala aan versies. In elke versie zijn er minstens één of meer bekende kwetsbaarheden. De impact kan divers zijn, afhankelijk van de aard van de kwetsbaarheid.
: Aanvallers gebruiken het onveilige protocol om informatie over de gebruiker te onderscheppen, scripts te vervangen en verzoeken naar de website te sturen namens de gebruiker. Zelfs als de bezoeker geen gegevens invoert, beschermt dit hem niet tegen: Voor bekende kwetsbaarheden zijn er exploits, zoals:
Wat webontwikkelaars moeten onthouden: Keer regelmatig terug naar de cyclus: zoeken naar bekende kwetsbaarheden – verhelpen – controleren. Als u opzettelijk verouderde bibliotheken gebruikt, bijvoorbeeld ter ondersteuning van oude browsers of om kosten te besparen, zoek dan naar mogelijkheden om bekende kwetsbaarheden op te lossen. - Cross-Site Scripting (XSS).
Cross-Site Scripting (XSS), ofwel cross-site scripts, zijn aanvallen op webapplicaties waarbij schadelijke code in de database terechtkomt. Als Qualys een dergelijke kwetsbaarheid ontdekt, betekent dit dat een potentiële aanvaller een js-script heeft geüpload of al in de code van de website heeft ingebracht om schadelijke acties uit te voeren.Opgeslagen XSS (Stored XSS) zijn gevaarlijker, omdat het script op de server wordt ingebracht en elke keer wordt uitgevoerd bij het openen van de aangevallen pagina in de browser.
Reflected XSS (Reflected XSS) is makkelijker uit te voeren, omdat een kwaadwillend script in een HTTP-verzoek kan worden ingesloten. De applicatie ontvangt het HTTP-verzoek, controleert de gegevens niet, verpakt deze en verzendt deze onmiddellijk. Als de aanvaller het verkeer onderschept en een script invoegt zoals
<script>/*+что+то+плохое+*/</script>dan wordt er namens de klant een schadelijk verzoek verzonden.
Een duidelijk voorbeeld van XSS: js-sniffers die pagina's nabootsen voor het invoeren van CVC, vervaldatum van de kaart, enzovoort.
Wat webontwikkelaars moeten onthouden: In de header Content-Security-Policy moet je het attribuut script-src gebruiken, zodat de browser van de klant alleen code van een vertrouwde bron laadt en uitvoert. Bijvoorbeeld, script-src 'self' voegt alleen scripts van onze website toe aan de whitelist.
De beste praktijk is om Inline code toe te staan: alleen inline javascript met de waarde unsafe-inline. Deze waarde staat het gebruik van inline js/css toe, maar verbiedt niet het toevoegen van js-bestanden. In combinatie met script-src 'self' verbieden we het uitvoeren van externe scripts.Zorg ervoor dat je alles logt met report-uri en kijk naar pogingen om in de website te infiltreren.
- SQL-injecties.
De kwetsbaarheid duidt op de mogelijkheid om SQL-code in de website in te brengen die rechtstreeks toegang heeft tot de database van de website. SQL-injectie is mogelijk als de gegevens van de gebruiker niet worden geescaped: ze worden niet gevalideerd en direct in de query gebruikt. Bijvoorbeeld, dit kan gebeuren als een formulier op de site de invoer niet controleert op datatypes.: Aanvallers gebruiken het onveilige protocol om informatie over de gebruiker te onderscheppen, scripts te vervangen en verzoeken naar de website te sturen namens de gebruiker. Zelfs als de bezoeker geen gegevens invoert, beschermt dit hem niet tegen: Als een aanvaller dergelijke SQL-query's in een dergelijk formulier invoert, kan hij de database beschadigen of vertrouwelijke informatie onthullen.
Wat webontwikkelaars moeten onthouden: Vertrouw niet op wat van de browser komt. Bescherming moet zowel aan de clientzijde als aan de serverzijde plaatsvinden.
Schrijf aan de clientzijde een controle voor de velden met JavaScript.
Ingebouwde functies in populaire frameworks helpen ook om verdachte tekens op de server te escapen. Het wordt ook aanbevolen om geparametriseerde databasequeries op de server te gebruiken.
Bepaal waar de interactie met de database in de webapplicatie plaatsvindt.
Interacties ontstaan wanneer wij informatie opvragen: een verzoek met id (id wijzigen), een nieuwe gebruiker aanmaken, een nieuwe opmerking – nieuwe records in de database. Hier kunnen SQL-injecties optreden. Zelfs als we een record uit de database verwijderen, is een SQL-injectie mogelijk.
Algemene aanbevelingen.
Verzin het wiel niet opnieuw – gebruik bewezen frameworks.. Over het algemeen zijn populaire frameworks veiliger. Voor .NET zijn dit ASP.NET MVC en ASP.NET Core, voor Python zijn het Django of Flask, voor Ruby is het Ruby on Rails, voor PHP zijn het Symfony, Laravel, Yii, voor JavaScript is het Node.JS - Express.js, voor Java is het Spring MVC.
Blijf op de hoogte van de updates van de leverancier en update regelmatig.. Kwetsbaarheden worden ontdekt, vervolgens wordt er een exploit geschreven, vrijgegeven en begint alles weer opnieuw. Abonneer je op updates voor stabiele versies van de softwareleverancier.
Controleer de toegangsrechten.. Behandel je code altijd zo, alsof deze van je meest verschrikkelijke vijand is, die jouw website wil aanvallen en de integriteit van jouw gegevens wil schenden. Sterker nog, soms is dit ook daadwerkelijk zo.
Gebruik klonen, testomgevingen en pas daarna op productie.. Dit helpt, ten eerste, om fouten en problemen in de productieomgeving te voorkomen: de productieomgeving genereert geld en downtime is kritiek voor de productieomgeving. Bij het toevoegen, corrigeren of sluiten van een probleem moet men werkzaamheden in de testomgeving uitvoeren, daarna de functionaliteit en gevonden kwetsbaarheden verifiëren, en pas daarna de werkzaamheden in de productieomgeving plannen.
Bescherm de webapplicatie met en integreer rapporten van de kwetsbaarheidsscanner ermee.. Bijvoorbeeld, bij DataLine worden Qualys en FortiWeb als koppelingen tussen de diensten gebruikt.
Bron: habr.com
