In- en uitgangen

10 minuten

Het meest voorkomende zwakke punt in de beveiliging van huidige toepassingen is het niet correct verwerken van gegevens die zijn ontvangen van externe bronnen, met name gebruikersinvoer. U moet alle invoer altijd goed controleren om er zeker van te zijn dat deze vóór gebruik is gevalideerd. Wanneer gebruikersinvoer niet op mogelijke aanvallen wordt geanalyseerd, kan dat leiden tot verlies of blootstelling van gegevens, onrechtmatige uitbreiding van toegangsrechten of zelfs uitvoering van schadelijke code op computers van andere gebruikers.

Het tragische van deze situatie is dat hier sprake is van een probleem dat eenvoudig kan worden opgelost. In deze les wordt uitgelegd hoe u gegevens behandelt wanneer deze worden ontvangen, wanneer deze worden weergegeven op het scherm en wanneer deze worden opgeslagen voor later gebruik.

Waarom moeten we invoer valideren?

Stel dat u een interface bouwt waarmee een gebruiker een account op uw website kan maken. Onze profielgegevens bevatten een naam, e-mail en een bijnaam die we zullen weergeven aan iedereen die de site bezoekt. Wat gebeurt er als een nieuwe gebruiker een profiel maakt en een bijnaam invoert die een aantal SQL-opdrachten bevat? Wat als een kwaadwillende gebruiker bijvoorbeeld iets als het volgende fragment invoert:

Eve'); DROP TABLE Users;--

Als we de waarde blind aan een database toevoegen, kan deze mogelijk de SQL-instructie zo wijzigen dat er opdrachten worden uitgevoerd die we helemaal niet willen uitvoeren. Dit soort aanval wordt een 'SQL-injectie' genoemd. Het is een van de vele typen aanvallen die kunnen worden uitgevoerd wanneer u gebruikersinvoer niet goed verwerkt. Wat kunnen we doen om dit op te lossen? In deze eenheid laten we u zien wanneer u invoer moet valideren, hoe u uitvoer moet coderen en hoe u geparameteriseerde query's kunt maken (waarmee de bovengenoemde aanval wordt voorkomen). Dit zijn de drie belangrijkste technieken om te voorkomen dat schadelijke invoer in uw toepassingen terechtkomt.

Wanneer moet ik invoer valideren?

Het antwoord is altijd. U moet elke invoer voor uw toepassing valideren. Dit omvat parameters in de URL, invoer van de gebruiker, gegevens uit de database, gegevens van een API en alles wat wordt doorgegeven in het duidelijk dat een gebruiker mogelijk kan manipuleren. Gebruik altijd een allowlist-benadering , wat betekent dat u alleen 'bekende goede' invoer accepteert, in plaats van een bloklijst (waarbij u specifiek zoekt naar ongeldige invoer), omdat het onmogelijk is om een volledige lijst met mogelijk gevaarlijke invoer te bedenken. Doe dit op de server, niet aan de clientzijde (of naast de clientzijde), om ervoor te zorgen dat uw verdediging niet kan worden omzeild. Alle gegevens behandelen als niet-vertrouwd en u beschermt uzelf tegen de meeste veelvoorkomende beveiligingsproblemen met web-apps.

Als u ASP.NET gebruikt, biedt het framework uitstekende ondersteuning voor het valideren van invoer aan zowel de client- als de serverzijde.

Als u een ander webframework gebruikt, zijn er enkele handige technieken voor het uitvoeren van invoervalidatie beschikbaar in het cheatsheet voor invoervalidatie van OWASP.

Gebruik altijd geparameteriseerde query's

SQL-databases worden vaak gebruikt voor het opslaan van gegevens; Uw toepassing kan bijvoorbeeld gebruikersprofielgegevens opslaan in een database. U moet nooit inline SQL- of andere databasequery's in uw code maken met behulp van onbewerkte gebruikersinvoer en deze rechtstreeks naar de database verzenden; dit gedrag is een recept voor noodgevallen, zoals we eerder zagen.

Maak bijvoorbeeld geen code zoals het volgende inline SQL-voorbeeld:

string userName = Request.QueryString["username"]; // receive input from the user BEWARE!
...
string query = "SELECT *  FROM  [dbo].[users] WHERE userName = '" + userName + "'";

Hier voegen we teksttekenreeksen samen om de query te maken, waarbij de invoer van de gebruiker wordt gebruikt om een dynamische SQL-query te maken om de gebruiker op te zoeken. Nogmaals: als een kwaadwillende gebruiker zou zien dat we dit doen, of als deze gebruiker gewoon verschillende invoerstijlen probeert om te zien of er een beveiligingsprobleem bestaat, kan dat een groot probleem opleveren. Gebruik in plaats daarvan geparameteriseerde SQL-instructies of opgeslagen procedures, zoals deze:

-- Lookup a user
CREATE PROCEDURE sp_findUser
(
@UserName varchar(50)
)

SELECT *  FROM  [dbo].[users] WHERE userName = @UserName

Met deze methode kunt u de procedure veilig aanroepen vanuit uw code, waarbij u de userName tekenreeks doorgeeft zonder dat u zich zorgen hoeft te maken dat deze wordt behandeld als onderdeel van de SQL-instructie.

Codeer altijd uw uitvoer

Elke uitvoer die u visueel of in een document weergeeft, moet worden gecodeerd en geëscaped. Dit kan u beschermen voor het geval er iets is gemist in de opschoningspas of als de code per ongeluk iets genereert dat schadelijk kan worden gebruikt. Dit ontwerpprincipe zorgt ervoor dat alles wordt weergegeven als uitvoer en niet per ongeluk wordt geïnterpreteerd als iets wat moet worden uitgevoerd, wat een andere veelvoorkomende aanvalstechniek is die wordt aangeduid als Cross-Site Scripting (XSS).

Omdat XSS-preventie een algemene toepassingsvereiste is, is deze beveiligingstechniek een ander gebied waar ASP.NET het werk voor u zal doen. Standaard is alle uitvoer al gecodeerd. Als u een ander webframework gebruikt, kunt u uw opties voor uitvoercodering op websites controleren met het cheatsheet voor OWASP XSS-preventie.

Samenvatting

Het opschonen en valideren van uw invoer is vereist om ervoor te zorgen dat uw invoer geldig is en veilig kan worden gebruikt en opgeslagen. De meeste moderne webframeworks bieden ingebouwde functies die een deel van dit werk kunnen automatiseren. U kunt de documentatie van uw framework controleren en zien welke functies het biedt. Hoewel webtoepassingen de meest voorkomende plaats zijn waar dit gebeurt, moet u er rekening mee houden dat andere soorten toepassingen net zo kwetsbaar kunnen zijn. Denk niet dat u veilig bent omdat uw nieuwe toepassing een desktop-app is. U moet gebruikersinvoer nog steeds goed verwerken om ervoor te zorgen dat iemand uw app niet gebruikt om uw gegevens te beschadigen of de reputatie van uw bedrijf te beschadigen.