Ongeveer een jaar geleden zijn wij bij DataLine gelanceerd om kwetsbaarheden in IT-applicaties te zoeken en te analyseren. De dienst is gebaseerd op de cloudoplossing Qualys, waarvan de werking bekend is . In de loop van een jaar dat we met de oplossing werkten, hebben we 291 scans uitgevoerd voor verschillende sites en statistieken verzameld over veelvoorkomende kwetsbaarheden in webapplicaties.
In het onderstaande artikel laat ik je precies zien welke gaten in de websitebeveiliging verborgen zijn achter verschillende niveaus van kritiek. Laten we eens kijken welke kwetsbaarheden de scanner vooral vaak tegenkomt, waarom ze kunnen voorkomen en hoe u uzelf kunt beschermen.
Qualys verdeelt alle kwetsbaarheden in webapplicaties in drie niveaus van kritiekheid: laag, gemiddeld en hoog. Als je naar de verdeling op basis van “ernst” kijkt, lijkt het erop dat alles niet zo slecht is. Er zijn weinig kwetsbaarheden met een hoge mate van kritiek, maar meestal zijn ze allemaal niet-kritiek:
Maar onkritisch betekent niet onschadelijk. Ze kunnen ook ernstige schade veroorzaken.
Belangrijkste ‘niet-kritieke’ kwetsbaarheden
- Kwetsbaarheden met gemengde inhoud.
De standaard voor websitebeveiliging is de overdracht van gegevens tussen de client en de server via het HTTPS-protocol, dat codering ondersteunt en informatie beschermt tegen onderschepping.
Sommige sites gebruiken gemengde inhoud: Sommige gegevens worden overgedragen via het onveilige HTTP-protocol. Zo wordt het meestal overgebracht passieve inhoud – informatie die alleen van invloed is op de weergave van de site: afbeeldingen, CSS-stijlen. Maar soms is dit de manier waarop het wordt overgedragen actieve inhoud: scripts die het gedrag van de site bepalen. In dit geval kunt u met behulp van speciale software informatie analyseren met actieve inhoud die van de server komt, uw reacties direct aanpassen en de machine laten werken op een manier die niet door de makers ervan was bedoeld.
Nieuwere versies van browsers waarschuwen gebruikers dat sites met gemengde inhoud onveilig zijn en blokkeren de inhoud. Website-ontwikkelaars ontvangen ook browserwaarschuwingen in de console. Zo ziet het er bijvoorbeeld zo uit :
Hoe dan ook: Aanvallers gebruiken een onveilig protocol om namens hem gebruikersinformatie te onderscheppen, scripts te vervangen en verzoeken naar de site te sturen. Zelfs als een sitebezoeker geen gegevens invoert, beschermt dit hem niet phishing – het verkrijgen van vertrouwelijke informatie met behulp van frauduleuze methoden. Met behulp van een script kunt u de gebruiker bijvoorbeeld omleiden naar een onveilige site die zich voordoet als een site die de gebruiker kent. In sommige gevallen ziet de kwaadaardige site er zelfs beter uit dan het origineel en kan de gebruiker het formulier zelf invullen en vertrouwelijke gegevens verzenden.Wat een webontwikkelaar moet onthouden: Zelfs als de sitebeheerder een SSL/TLS-certificaat heeft geïnstalleerd en geconfigureerd, kan er door een menselijke fout een kwetsbaarheid ontstaan. Als u bijvoorbeeld op een van de pagina's geen relatieve link plaatst, maar een absolute link van http, en bovendien geen omleidingen van http naar https heeft ingesteld.
U kunt gemengde inhoud op een site detecteren met behulp van een browser: zoek in de broncode van de pagina, lees meldingen in de ontwikkelaarsconsole. De ontwikkelaar zal echter lang en vervelend aan de code moeten sleutelen. U kunt het proces versnellen met geautomatiseerde analysetools, bijvoorbeeld: , gratis Lighthouse-software of betaalde software Screaming Frog SEO Spider.
Ook kan het beveiligingslek ontstaan als gevolg van problemen met legacy-code, code die is geërfd. Als sommige pagina's bijvoorbeeld worden gegenereerd met behulp van een oude sjabloon, waarbij geen rekening wordt gehouden met de overgang van sites naar https.
- Cookies zonder de vlaggen "HTTPOnly" en "secure".
Het kenmerk 'HTTPOnly' beschermt cookies tegen verwerking door scripts die aanvallers gebruiken om gebruikersgegevens te stelen. De vlag "veilig" staat niet toe dat cookies in gewone tekst worden verzonden. Communicatie is alleen toegestaan als het beveiligde HTTPS-protocol wordt gebruikt voor het verzenden van cookies.
Beide attributen zijn gespecificeerd in de cookie-eigenschappen:
Set-Cookie: Secure; HttpOnlyHoe dan ook: Als de site-ontwikkelaar deze kenmerken niet opgeeft, kan een aanvaller de gebruikersinformatie uit de cookie onderscheppen en deze misbruiken. Als er cookies worden gebruikt voor authenticatie en autorisatie, kan hij de sessie van de gebruiker kapen en namens hem acties op de site uitvoeren.
Wat een webontwikkelaar moet onthouden: In populaire raamwerken worden deze attributen in de regel automatisch ingesteld. Maar controleer nog steeds de configuratie van de webserver en stel de vlag in: Set-Cookie HttpOnly; Zeker.
In dit geval zal het attribuut “HTTPOnly” cookies onzichtbaar maken voor uw eigen JavaScript.
- Padgebaseerde kwetsbaarheden.
De scanner meldt een dergelijke kwetsbaarheid als hij een openbaar toegankelijke bestands- of websitemap vindt met mogelijk vertrouwelijke informatie. Het detecteert bijvoorbeeld individuele systeemconfiguratiebestanden of toegang tot het volledige bestandssysteem. Deze situatie is mogelijk als de toegangsrechten op de site verkeerd zijn ingesteld.
Hoe dan ook: Als het bestandssysteem “uitsteekt”, kan een aanvaller in de interface van het besturingssysteem terechtkomen en proberen mappen met wachtwoorden te vinden als deze in duidelijke tekst zijn opgeslagen (doe dat niet!). Of je kunt wachtwoord-hashes stelen en het wachtwoord bruut forceren, en ook proberen de rechten in het systeem te vergroten en dieper in de infrastructuur te komen.
Wat een webontwikkelaar moet onthouden: Vergeet de toegangsrechten niet en configureer het platform, de webserver en de webapplicatie zo dat het onmogelijk is om uit de webdirectory te “ontsnappen”.
- Formulieren voor het invoeren van gevoelige gegevens met automatisch invullen ingeschakeld.
Als een gebruiker regelmatig formulieren op websites invult, slaat zijn browser deze informatie op met behulp van de functie voor automatisch aanvullen.
Formulieren op websites kunnen velden bevatten met gevoelige informatie, zoals wachtwoorden of creditcardnummers. Voor dergelijke velden is het de moeite waard om de functie voor automatisch aanvullen van formulieren op de site zelf uit te schakelen.
Hoe dan ook: Als de browser van de gebruiker gevoelige informatie opslaat, kan een aanvaller deze later onderscheppen, bijvoorbeeld via phishing. In wezen is een webontwikkelaar die deze nuance is vergeten, zijn gebruikers aan het opzetten.
Wat een webontwikkelaar moet onthouden: In dit geval hebben we te maken met een klassiek conflict: gemak versus veiligheid. Als een webontwikkelaar aan de gebruikerservaring denkt, kan hij bewust kiezen voor autocomplete. Bijvoorbeeld als het belangrijk is om te volgen – aanbevelingen voor de toegankelijkheid van inhoud voor gebruikers met een handicap.
Voor de meeste browsers kunt u automatisch aanvullen uitschakelen met het autocompete="off" attribuut, bijvoorbeeld:
<body> <form action="/nl/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>Maar voor Chrome werkt het niet. Met JavaScript wordt dit omzeild, er is een variant van het recept te vinden .
- De X-Frame-Options-header is niet ingesteld in de sitecode.
Deze header is van invloed op frame-, iframe-, embed- of objecttags. Met zijn hulp kunt u het insluiten van uw site in een frame volledig verbieden. Om dit te doen, moet u de waarde X-Frame-Options: deny opgeven. Of u kunt X-Frame-Options: sameorigin opgeven, waarna insluiten in een iframe alleen beschikbaar is op uw domein.
Hoe dan ook: Het ontbreken van een dergelijke header kan op kwaadaardige sites worden gebruikt clickjacking. Bij deze aanval creëert de aanvaller een transparant kader bovenop de knoppen en misleidt de gebruiker. Bijvoorbeeld: oplichters framen sociale netwerkpagina's op een website. De gebruiker denkt dat hij op een knop op deze site klikt. In plaats daarvan wordt de klik onderschept en wordt het verzoek van de gebruiker verzonden naar het sociale netwerk waar een actieve sessie plaatsvindt. Dit is de manier waarop aanvallers namens de gebruiker spam verzenden of abonnees en vind-ik-leuks verkrijgen.
Als u deze functie niet uitschakelt, kan een aanvaller uw applicatieknop op een kwaadwillende site plaatsen. Hij is mogelijk geïnteresseerd in uw verwijzingsprogramma of uw gebruikers.
Wat een webontwikkelaar moet onthouden: Het beveiligingslek kan optreden als X-Frame-Options met een conflicterende waarde is ingesteld op de webserver of load balancer. In dit geval zullen de server en de balancer eenvoudigweg de header herschrijven, omdat deze een hogere prioriteit hebben vergeleken met de backendcode.
De deny- en sameorigin-waarden van de X-Frame-Options-header zullen de werking van de Yandex-webviewer verstoren. Om het gebruik van iframes voor de webviewer toe te staan, moet u een aparte regel in de instellingen schrijven. Voor nginx kun je het bijvoorbeeld als volgt configureren:
http{ ... map $http_referer $frame_options { "~webvisor.com" "ALLOW-FROM http://webvisor.com"; default "SAMEORIGIN"; } add_header X-Frame-Options $frame_options; ... } - PRSSI-kwetsbaarheden (Path-relative stylesheet import).
Dit is een kwetsbaarheid in de stijl van de site. Het komt voor als relatieve links zoals href="/nl/somefolder/styles.css/" worden gebruikt om toegang te krijgen tot stijlbestanden. Een aanvaller zal hiervan profiteren als hij een manier vindt om de gebruiker om te leiden naar een kwaadaardige pagina. De pagina voegt een relatieve link in de URL in en simuleert een stijlenaanroep. Je krijgt een verzoek zoals badsite.ru/…/somefolder/styles.css/, dat kwaadaardige acties kan uitvoeren onder het mom van een stijl.
Hoe dan ook: Een fraudeur kan dit beveiligingslek misbruiken als hij een ander beveiligingslek ontdekt. Hierdoor is het mogelijk om gebruikersgegevens uit cookies of tokens te stelen.
Wat een webontwikkelaar moet onthouden: Stel de X-Content-Type-Options-header in op: nosniff. In dit geval controleert de browser het inhoudstype voor de stijlen. Als het type anders is dan tekst/css, zal de browser het verzoek blokkeren.
Kritieke kwetsbaarheden
- Een pagina met een wachtwoordveld wordt vanaf de server verzonden via een onveilig kanaal (HTML-formulier met wachtwoordveld(en) wordt via HTTP weergegeven).
De reactie van de server via een niet-versleuteld kanaal is kwetsbaar voor “Man in the middle”-aanvallen. Een aanvaller kan verkeer onderscheppen en zichzelf in een klem plaatsen tussen de client en de server terwijl de pagina van de server naar de client reist.
Hoe dan ook: De fraudeur kan de pagina vervangen en de gebruiker een formulier voor vertrouwelijke gegevens sturen, dat naar de server van de aanvaller gaat.
Wat een webontwikkelaar moet onthouden: sommige sites sturen gebruikers een eenmalige code per e-mail/telefoon in plaats van een wachtwoord. In dit geval is de kwetsbaarheid niet zo kritiek, maar het mechanisme zal de levens van gebruikers compliceren.
- Een formulier met login en wachtwoord verzenden via een onveilig kanaal (inlogformulier wordt niet via HTTPS verzonden).
In dit geval wordt een formulier met login en wachtwoord via een niet-versleuteld kanaal van de gebruiker naar de server verzonden.
Hoe dan ook: In tegenstelling tot het vorige geval is dit al een kritieke kwetsbaarheid. Het is gemakkelijker om gevoelige gegevens te onderscheppen, omdat je er niet eens code voor hoeft te schrijven.
- JavaScript-bibliotheken gebruiken met bekende kwetsbaarheden.
Tijdens de scan was jQuery de meest gebruikte bibliotheek met een uitgebreid aantal versies. Elke versie heeft minstens één of zelfs meer bekende kwetsbaarheden. De impact kan zeer verschillend zijn, afhankelijk van de aard van de kwetsbaarheid.
Hoe dan ook: Er zijn exploits voor bekende kwetsbaarheden, bijvoorbeeld:
Wat een webontwikkelaar moet onthouden: Regelmatig terugkeren naar de cyclus: zoeken naar bekende kwetsbaarheden - repareren - controleren. Als u opzettelijk verouderde bibliotheken gebruikt, bijvoorbeeld om oudere browsers te ondersteunen of om geld te besparen, zoek dan naar een mogelijkheid om een bekende kwetsbaarheid op te lossen. - Cross-site scripting (XSS).
Cross-Site Scripting (XSS), of cross-site scripting, is een aanval op een webapplicatie die ertoe leidt dat malware in de database wordt geïntroduceerd. Als Qualys een dergelijke kwetsbaarheid vindt, betekent dit dat een potentiële aanvaller zijn eigen js-script al in de sitecode kan of heeft geïntroduceerd om kwaadaardige acties uit te voeren.Opgeslagen XSS gevaarlijker, omdat het script op de server is ingebed en telkens wordt uitgevoerd wanneer de aangevallen pagina in de browser wordt geopend.
Gereflecteerde XSS gemakkelijker uit te voeren omdat een kwaadaardig script in een HTTP-verzoek kan worden geïnjecteerd. De applicatie ontvangt een HTTP-verzoek, valideert de gegevens niet, verpakt deze en verzendt deze onmiddellijk. Als een aanvaller verkeer onderschept en een script invoegt zoals
<script>/*+что+то+плохое+*/</script>dan wordt namens de cliënt een kwaadwillig verzoek verzonden.
Een treffend voorbeeld van XSS: js-sniffers die pagina's simuleren voor het invoeren van CVC, de vervaldatum van de kaart, enzovoort.
Wat een webontwikkelaar moet onthouden: Gebruik in de Content-Security-Policy-header het script-src-kenmerk om de clientbrowser te dwingen alleen code van een vertrouwde bron te downloaden en uit te voeren. script-src 'self' zet bijvoorbeeld alleen alle scripts van onze site op de witte lijst.
De beste praktijk is Inline-code: sta alleen inline JavaScript toe met de waarde unsafe-inline. Deze waarde staat het gebruik van inline js/css toe, maar verbiedt niet de opname van js-bestanden. In combinatie met script-src 'self' zorgen we ervoor dat externe scripts niet worden uitgevoerd.Zorg ervoor dat u alles registreert met behulp van report-uri en bekijk de pogingen om het in de site te implementeren.
- SQL-injecties.
Het beveiligingslek duidt op de mogelijkheid om SQL-code in een website te injecteren die rechtstreeks toegang heeft tot de database van de website. SQL-injectie is mogelijk als gegevens van de gebruiker niet worden gescreend: deze worden niet gecontroleerd op juistheid en worden direct gebruikt in de query. Dit gebeurt bijvoorbeeld als een formulier op een website niet controleert of de invoer overeenkomt met het gegevenstype.Hoe dan ook: Als een aanvaller een SQL-query in dit formulier invoert, kan hij de database laten crashen of vertrouwelijke informatie onthullen.
Wat een webontwikkelaar moet onthouden: Vertrouw niet wat er uit de browser komt. U moet uzelf zowel aan de clientzijde als aan de serverzijde beschermen.
Aan de clientzijde schrijft u veldvalidatie met JavaScript.
Ingebouwde functies in populaire raamwerken helpen ook om verdachte karakters op de server te ontwijken. Het wordt ook aanbevolen om geparametriseerde databasequery's op de server te gebruiken.
Bepaal waar precies de interactie met de database plaatsvindt op de webapplicatie.
Er vindt interactie plaats wanneer we informatie ontvangen: een verzoek met een ID (wijziging van ID), de creatie van een nieuwe gebruiker, een nieuwe opmerking of nieuwe vermeldingen in de database. Dit is waar SQL-injecties kunnen plaatsvinden. Zelfs als we een record uit de database verwijderen, is SQL-injectie mogelijk.
Algemene aanbevelingen
Vind het wiel niet opnieuw uit, maar gebruik beproefde raamwerken. In de regel zijn populaire raamwerken veiliger. Voor .NET - ASP.NET MVC en ASP.NET Core, voor Python - Django of Flask, voor Ruby - Ruby on Rails, voor PHP - Symfony, Laravel, Yii, voor JavaScript - Node.JS-Express.js, voor Java - Lente MVC.
Volg leveranciersupdates en update regelmatig. Ze zullen een kwetsbaarheid vinden, vervolgens een exploit schrijven, deze publiekelijk beschikbaar maken en alles zal opnieuw gebeuren. Abonneer u op updates voor stabiele versies van de softwareleverancier.
Controleer de toegangsrechten. Aan de serverkant moet u uw code altijd behandelen alsof deze, van de eerste tot de laatste letter, is geschreven door uw meest gehate vijand, die uw site kapot wil maken en de integriteit van uw gegevens wil schenden. Bovendien is dit soms waar.
Gebruik klonen, testlocaties en gebruik ze vervolgens voor productie. Dit zal in de eerste plaats helpen fouten en vergissingen in een productieve omgeving te voorkomen: een productieve omgeving brengt geld op, een eenvoudige productieve omgeving is van cruciaal belang. Bij het toevoegen, oplossen of sluiten van een probleem is het de moeite waard om in een testomgeving te werken, vervolgens de gevonden functionaliteit en kwetsbaarheden te controleren en vervolgens te plannen om met de productieomgeving te gaan werken.
Bescherm uw webapplicatie met en integreer rapporten van de kwetsbaarheidsscanner ermee. DataLine gebruikt bijvoorbeeld Qualys en FortiWeb als bundel van diensten.
Bron: www.habr.com