10 meest voorkomende kwetsbaarheden op het gebied van webbeveiliging

OWASP of Open Web Security Project is een non-profitorganisatie die zich richt op het verbeteren van de beveiliging van software en webapplicaties.

De organisatie publiceert een lijst met de belangrijkste kwetsbaarheden op het gebied van webbeveiliging, gebaseerd op de gegevens van verschillende beveiligingsorganisaties.

De kwetsbaarheden in de webbeveiliging krijgen prioriteit, afhankelijk van de exploiteerbaarheid, detecteerbaarheid en impact op software.

• Exploiteerbaarheid –Wat is er nodig om het beveiligingsprobleem te misbruiken? De hoogste exploiteerbaarheid wanneer de aanval alleen een webbrowser nodig heeft en de laagste wanneer er sprake is van geavanceerde programmering en hulpmiddelen.
• Detecteerbaarheid – Hoe makkelijk is het om de bedreiging te detecteren? Hoogst is de informatie die wordt weergegeven op URL, Formulier of Foutbericht en laagst is de broncode.
• Impact of schade –Hoeveel schade zal worden aangericht als het beveiligingsprobleem wordt blootgelegd of aangevallen? De hoogste is een complete systeemcrash en de laagste is helemaal niets.

Het hoofddoel van OWASP Top 10 is om ontwikkelaars, ontwerpers, managers, architecten en organisaties te informeren over de belangrijkste beveiligingsproblemen.

De top 10 beveiligingskwetsbaarheden volgens OWASP Top 10 zijn:

SQL Injection

Beschrijving

Injectie is een beveiligingsprobleem waardoor een aanvaller de backend kan wijzigen SQL verklaringen door de door de gebruiker aangeleverde gegevens te manipuleren.

Injectie vindt plaats wanneer de gebruikersinvoer naar een tolk wordt gestuurd als onderdeel van een opdracht of vraag, waardoor de tolk wordt misleid om onbedoelde opdrachten uit te voeren en toegang wordt verleend tot ongeautoriseerde gegevens.

De SQL-opdracht die, wanneer uitgevoerd door een webapplicatie, ook de back-enddatabase kan blootleggen.

implicatie

• Een aanvaller kan kwaadaardige inhoud in de kwetsbare velden injecteren.
• Gevoelige gegevens zoals gebruikersnamen, wachtwoorden etc. kunnen uit de database worden gelezen.
• Databasegegevens kunnen worden gewijzigd (Invoegen/Bijwerken/Verwijderen).
• Administratie OperaIn de database kunnen bewerkingen worden uitgevoerd

Kwetsbare objecten

• Invoervelden
• URL's die interactie hebben met de database.

Voorbeelden:

• SQL injectie op de inlogpagina

Inloggen bij een applicatie zonder geldige inloggegevens.

Er is een geldige gebruikersnaam beschikbaar en er is geen wachtwoord beschikbaar.

Test-URL: http://demo.testfire.net/default.aspx

Gebruikersnaam: sjones

Wachtwoord: 1=1′ of pass123

SQL-query gemaakt en verzonden naar Interpreter, zoals hieronder

SELECT * VAN Gebruikers WAAR Gebruikersnaam = sjones EN Wachtwoord = 1=1′ of pass123;

Aanbevelingen

1. Whitelist van de invoervelden
2. Vermijd het weergeven van gedetailleerde foutmeldingen die nuttig zijn voor een aanvaller.

Cross Site Scripting

Beschrijving

Cross Site Scripting wordt ook wel kortweg XSS genoemd.

XSS-kwetsbaarheden richten zich op scripts die zijn ingebed in een pagina en die worden uitgevoerd aan de clientzijde, dat wil zeggen de browser van de gebruiker, in plaats van aan de serverzijde. Deze fouten kunnen optreden wanneer de applicatie niet-vertrouwde gegevens verzamelt en deze zonder de juiste validatie naar de webbrowser verzendt.

Aanvallers kunnen XSS gebruiken om kwaadaardige scripts uit te voeren op de gebruikers, in dit geval de browsers van het slachtoffer. Omdat de browser niet kan weten of het script betrouwbaar is of niet, wordt het script uitgevoerd en kan de aanvaller sessiecookies kapen, websites beschadigen of de gebruiker omleiden naar ongewenste en kwaadaardige websites.

XSS is een aanval waarmee de aanvaller de scripts in de browser van het slachtoffer kan uitvoeren.

Implicatie:

• Door gebruik te maken van dit beveiligingsprobleem kan een aanvaller scripts in de applicatie injecteren, sessiecookies stelen, websites beschadigen en malware op de machines van het slachtoffer uitvoeren.

Kwetsbare objecten

• Invoervelden
• URL's

Voorbeelden

1. http://www.vulnerablesite.com/home?”<script>alert(“xss”)</script>

Wanneer u het bovenstaande script in een browser uitvoert, wordt er een berichtvenster weergegeven als de site kwetsbaar is voor XSS.

De serieuzere aanval kan worden uitgevoerd als de aanvaller een sessiecookie wil weergeven of opslaan.

2. http://demo.testfire.net/search.aspx?txtSearch <iframe> http://google.com breedte = 500 hoogte 500>

Als het bovenstaande script wordt uitgevoerd, laadt de browser een onzichtbaar frame dat verwijst naar http://google.com.

De aanval kan ernstig worden gemaakt door een kwaadaardig script in de browser uit te voeren.

Aanbevelingen

1. White Listing-invoervelden
2. Ingang Uitgangscodering

Gebroken authenticatie en sessiebeheer

Beschrijving

De websites maken gewoonlijk een sessiecookie en sessie-ID aan voor elke geldige sessie, en deze cookies bevatten gevoelige gegevens zoals gebruikersnaam, wachtwoord, enz. Wanneer de sessie wordt beëindigd door uitloggen of door de browser abrupt te sluiten, moeten deze cookies ongeldig worden gemaakt, dat wil zeggen voor elke sessie. er zou een nieuwe cookie moeten zijn.

Als de cookies niet ongeldig worden gemaakt, zullen de gevoelige gegevens in het systeem aanwezig zijn. Als een gebruiker bijvoorbeeld een openbare computer (Cyber ​​Cafe) gebruikt, worden de cookies van de kwetsbare site op het systeem geplaatst en blootgesteld aan een aanvaller. Als een aanvaller dezelfde openbare computer gebruikt, komen na verloop van tijd de gevoelige gegevens in gevaar.

Op dezelfde manier sluit een gebruiker die een openbare computer gebruikt, in plaats van uit te loggen, de browser abrupt. Een aanvaller gebruikt hetzelfde systeem; wanneer hij op dezelfde kwetsbare site surft, wordt de vorige sessie van het slachtoffer geopend. De aanvaller kan doen wat hij wil, van het stelen van profielinformatie, creditcardinformatie, enz.

Er moet een controle worden uitgevoerd om de sterkte van de authenticatie en het sessiebeheer te bepalen. Sleutels, sessietokens en cookies moeten correct worden geïmplementeerd zonder de wachtwoorden in gevaar te brengen.

Kwetsbare objecten

• Sessie-ID's die op de URL worden weergegeven, kunnen leiden tot een aanval op sessiefixatie.
• Sessie-ID's zijn hetzelfde voor en na het uitloggen en inloggen.
• Sessietime-outs zijn niet correct geïmplementeerd.
• De toepassing wijst voor elke nieuwe sessie dezelfde sessie-ID toe.
• Geauthenticeerde delen van de applicatie worden beveiligd met SSL en wachtwoorden worden opgeslagen in gehasht of gecodeerd formaat.
• De sessie kan worden hergebruikt door een gebruiker met weinig rechten.

implicatie

• Door gebruik te maken van dit beveiligingslek kan een aanvaller een sessie kapen en ongeautoriseerde toegang krijgen tot het systeem, waardoor ongeautoriseerde informatie kan worden vrijgegeven en gewijzigd.
• De sessies kunnen worden gehackt met behulp van gestolen cookies of sessies met behulp van XSS.

Voorbeelden

1. De reserveringsapplicatie voor luchtvaartmaatschappijen ondersteunt het herschrijven van URL's, waarbij sessie-ID's in de URL worden geplaatst:http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Verkoop van tickets naar de Malediven)Een geauthenticeerde gebruiker van de site wil zijn vrienden op de hoogte stellen van de verkoop en stuurt een e-mail. De vrienden ontvangen de sessie-ID en kunnen worden gebruikt om ongeautoriseerde wijzigingen aan te brengen of de opgeslagen creditcardgegevens te misbruiken.
2. Een applicatie is kwetsbaar voor XSS, waardoor een aanvaller toegang kan krijgen tot de sessie-ID en kan worden gebruikt om de sessie te kapen.
3. Time-outs van applicaties zijn niet goed ingesteld. De gebruiker gebruikt een openbare computer en sluit de browser in plaats van uit te loggen en weg te lopen. De aanvaller gebruikt dezelfde browser enige tijd later en de sessie wordt geauthenticeerd.

Aanbevelingen

1. Alle vereisten voor authenticatie en sessiebeheer moeten worden gedefinieerd volgens de OWASP Application Security Verification Standard.
2. Geef nooit inloggegevens weer in URL's of logboeken.
3. Er moeten ook grote inspanningen worden geleverd om XSS-fouten te voorkomen, die kunnen worden gebruikt om sessie-ID's te stelen.

Onveilige verwijzingen naar directe objecten

Beschrijving

Het komt voor wanneer een ontwikkelaar een verwijzing naar een intern implementatieobject openbaar maakt, zoals een bestand, map of databasesleutel, zoals in URL of als een FORM-parameter. De aanvaller kan deze informatie gebruiken om toegang te krijgen tot andere objecten en kan een toekomstige aanval opzetten om toegang te krijgen tot de ongeautoriseerde gegevens.

implicatie

• Met behulp van dit beveiligingslek kan een aanvaller toegang krijgen tot ongeautoriseerde interne objecten, gegevens wijzigen of de applicatie compromitteren.

Kwetsbare objecten

• In de URL.

Voorbeelden:

Door de “userid” in de volgende URL te wijzigen, kan een aanvaller de informatie van andere gebruikers bekijken.

http://www.vulnerablesite.com/userid=123 Gewijzigd naar http://www.vulnerablesite.com/userid=124

Een aanvaller kan informatie van anderen bekijken door de waarde van de gebruikers-ID te wijzigen.

aanbevelingen:

1. Implementeren van toegangscontroles.
2. Vermijd het blootstellen van objectreferenties in URL's.
3. Controleer de autorisatie voor alle referentieobjecten.

Vervalsing van aanvragen voor meerdere sites

Beschrijving

Cross Site Request Forgery is een vervalst verzoek dat afkomstig is van de cross-site.

Een CSRF-aanval is een aanval die plaatsvindt wanneer een schadelijke website, e-mail of programma ervoor zorgt dat de browser van een gebruiker een ongewenste actie uitvoert op een vertrouwde site waarvoor de gebruiker op dat moment is geverifieerd.

Een CSRF-aanval dwingt de browser van een ingelogd slachtoffer om een ​​vervalst HTTP-verzoek, inclusief de sessiecookie van het slachtoffer en andere automatisch opgenomen authenticatie-informatie, naar een kwetsbare webapplicatie te sturen.

Er wordt door de aanvaller een link naar het slachtoffer gestuurd wanneer de gebruiker op de URL klikt wanneer hij is ingelogd op de oorspronkelijke website. De gegevens worden van de website gestolen.

implicatie

• Door dit beveiligingslek als aanvaller te gebruiken, kan de informatie over het gebruikersprofiel worden gewijzigd, de status worden gewijzigd, namens de beheerder een nieuwe gebruiker worden aangemaakt, enzovoort.

Kwetsbare objecten

• Gebruikersprofielpagina
• Formulieren voor gebruikersaccounts
• Zakelijke transactiepagina

Voorbeelden

Het slachtoffer logt in op een bankwebsite met geldige inloggegevens. Hij ontvangt een e-mail van een aanvaller met de tekst: "Klik hier om $ 1 te doneren aan het goede doel."

Wanneer het slachtoffer erop klikt, wordt er een geldig verzoek aangemaakt om $ 1 te doneren aan een bepaald account.

http://www.vulnerablebank.com/transfer.do?account=cause&amount=1

De aanvaller vangt dit verzoek op, maakt het onderstaande verzoek en sluit een knop in met de tekst 'Ik steun het doel'.

http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000

Omdat de sessie is geverifieerd en het verzoek via de website van de bank komt, zou de server $ 1000 dollar overmaken naar de aanvaller.

Aanbeveling

1. Verplicht de aanwezigheid van de gebruiker tijdens het uitvoeren van gevoelige acties.
2. Implementeer mechanismen zoals CAPTCHA, herauthenticatie en unieke aanvraagtokens.

Verkeerde configuratie van de beveiliging

Beschrijving

Security Configuration moet worden gedefinieerd en geïmplementeerd voor de applicatie, frameworks, applicatieserver, webserver, databaseserver en platform. Als deze correct zijn geconfigureerd, kan een aanvaller ongeautoriseerde toegang hebben tot gevoelige gegevens of functionaliteit.

Soms leiden dergelijke gebreken tot een volledige systeemstoring. Keeping De software is up-to-date en biedt bovendien goede beveiliging.

implicatie

• Door gebruik te maken van dit beveiligingslek kan de aanvaller de onderliggende technologie, versie-informatie van de applicatieserver en database-informatie opsommen en informatie over de applicatie verkrijgen om nog een paar aanvallen uit te voeren.

Kwetsbare objecten

• URL
• Formuliervelden
• Invoervelden

Voorbeelden

1. De beheerconsole van de toepassingsserver wordt automatisch geïnstalleerd en niet verwijderd. Standaardaccounts worden niet gewijzigd. De aanvaller kan inloggen met standaardwachtwoorden en zich ongeautoriseerde toegang verschaffen.
2. Directory Listing is niet uitgeschakeld op uw server. De aanvaller ontdekt en kan eenvoudig mappen weergeven om elk bestand te vinden.

Aanbevelingen

1. Een sterke applicatiearchitectuur die zorgt voor een goede scheiding en beveiliging tussen de componenten.
2. Wijzig standaardgebruikersnamen en wachtwoorden.
3. Schakel directoryvermeldingen uit en implementeer toegangscontroles.

Onveilige cryptografische opslag

Beschrijving

Onveilig Cryptografische opslag is een veel voorkomende kwetsbaarheid die ontstaat wanneer de gevoelige gegevens niet veilig zijn opgeslagen.

Gebruikersgegevens, profielgegevens, gezondheidsgegevens, creditcardgegevens en dergelijke vallen onder de gevoelige gegevens op een website.

Deze gegevens worden opgeslagen in de applicatiedatabase. Wanneer deze gegevens op onjuiste wijze worden opgeslagen door geen gebruik te maken van encryptie of hashing*, zijn ze kwetsbaar voor aanvallers.

(*Hashing is de transformatie van de tekenreekstekens in kortere reeksen met een vaste lengte of een sleutel. Om de tekenreeks te decoderen, moet het algoritme dat wordt gebruikt om de sleutel te vormen beschikbaar zijn)

implicatie

• Door gebruik te maken van dit beveiligingslek kan een aanvaller dergelijke zwak beveiligde gegevens stelen en wijzigen om identiteitsdiefstal, creditcardfraude of andere misdaden uit te voeren.

Kwetsbare objecten

• Applicatiedatabase.

Voorbeelden

In een van de bankapplicaties gebruikt de wachtwoorddatabase ongezouten hashes * om ieders wachtwoorden op te slaan. Door een SQL-injectiefout kan de aanvaller het wachtwoordbestand ophalen. Alle ongezouten hashes kunnen in een mum van tijd bruut geforceerd worden, terwijl de gezouten wachtwoorden duizenden jaren zouden duren.

(*Ongezouten hashes – Salt is een willekeurige data die aan de originele data wordt toegevoegd. Salt wordt aan het wachtwoord toegevoegd vóór het hashen)

Aanbevelingen

1. Zorg voor geschikte sterke standaardalgoritmen. Maak geen eigen cryptografische algoritmen. Gebruik alleen goedgekeurde openbare algoritmen zoals AES, RSA public key cryptografie en SHA-256, etc.
2. Zorg ervoor dat externe back-ups gecodeerd zijn, maar dat de sleutels afzonderlijk worden beheerd en geback-upt.

Kan URL-toegang niet beperken

Beschrijving

Webapplicaties controleren de URL-toegangsrechten voordat beveiligde links en knoppen worden weergegeven. Applicaties moeten soortgelijke toegangscontroles uitvoeren telkens wanneer deze pagina's worden geopend.

In de meeste toepassingen worden de bevoorrechte pagina's, locaties en bronnen niet aan de bevoorrechte gebruikers gepresenteerd.

Door een intelligente gok kan een aanvaller toegang krijgen tot privilegepagina's. Een aanvaller kan toegang krijgen tot gevoelige pagina's, functies aanroepen en vertrouwelijke informatie bekijken.

implicatie

• Door gebruik te maken van deze kwetsbaarheid kan de aanvaller toegang krijgen tot de ongeautoriseerde URL's, zonder in te loggen op de applicatie en de kwetsbaarheid te misbruiken. Een aanvaller kan toegang krijgen tot gevoelige pagina's, functies aanroepen en vertrouwelijke informatie bekijken.

Kwetsbare objecten:

• URL's

Voorbeelden

1. De aanvaller merkt dat de URL de rol aangeeft als '/user/getaccounts'. Hij wijzigt als “/admin/getaccounts”.
2. Een aanvaller kan een rol aan de URL toevoegen.

http://www.vulnerablsite.com kan worden gewijzigd als http://www.vulnerablesite.com/admin

Aanbevelingen

1. Implementeer strenge toegangscontroles.
2. Authenticatie- en autorisatiebeleid moet op rollen gebaseerd zijn.
3. Beperk de toegang tot ongewenste URL's.

Onvoldoende transportlaagbescherming

Beschrijving

Het betreft de uitwisseling van informatie tussen de gebruiker (client) en de server (applicatie). Applicaties maken vaak gebruik van deze informatie-uitwisseling. transmit gevoelige informatie zoals authenticatiegegevens, creditcardgegevens en sessietokens via een netwerk.

Door zwakke algoritmen te gebruiken, verlopen of ongeldige certificaten te gebruiken of geen SSL te gebruiken, kan de communicatie worden blootgesteld aan niet-vertrouwde gebruikers. Dit kan een webapplicatie in gevaar brengen en/of gevoelige informatie stelen.

implicatie

• Door gebruik te maken van dit beveiligingslek in de webbeveiliging kan een aanvaller de inloggegevens van legitieme gebruikers opsnuiven en toegang krijgen tot de applicatie.
• Kan creditcardgegevens stelen.

Kwetsbare objecten

• Gegevens verzonden via het netwerk.

Aanbevelingen

1. Schakel beveiligde HTTP in en dwing de overdracht van inloggegevens alleen via HTTPS af.
2. Zorg ervoor dat uw certificaat geldig is en niet is verlopen.

Voorbeelden:

1. Bij een applicatie die geen SSL gebruikt, zal een aanvaller eenvoudigweg het netwerkverkeer monitoren en een geverifieerde slachtoffersessiecookie waarnemen. Een aanvaller kan dat cookie stelen en een Man-in-the-Middle-aanval uitvoeren.

Niet-gevalideerde omleidingen en doorsturen

Beschrijving

De webapplicatie gebruikt weinig methoden om gebruikers voor een bepaald doel om te leiden en door te sturen naar andere pagina's.

Als er geen goede validatie plaatsvindt bij het omleiden naar andere pagina's, kunnen aanvallers hiervan gebruik maken en slachtoffers doorsturen naar phishing- of malwaresites, of forwards gebruiken om toegang te krijgen tot niet-geautoriseerde pagina's.

implicatie

• Een aanvaller kan een URL naar de gebruiker sturen die een echte URL bevat, waaraan een gecodeerde kwaadaardige URL is toegevoegd. Een gebruiker die alleen het authentieke deel van de door de aanvaller verzonden URL ziet, kan er doorheen bladeren en kan slachtoffer worden.

Voorbeelden

1.http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com

Gewijzigd naar

http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com

Aanbevelingen

1. Vermijd eenvoudigweg het gebruik van omleidingen en doorsturen in de applicatie. Als u dit gebruikt, betrek dan geen gebruikersparameters bij het berekenen van de bestemming.
2. Als de bestemmingsparameters niet kunnen worden vermeden, zorg er dan voor dat de opgegeven waarde geldig is en geautoriseerd voor de gebruiker.