Skriva säker dynamisk SQL i SQL Server

Ladda ned ADO.NET

SQL-inmatning är den process genom vilken en obehörig användare anger Transact-SQL-instruktioner i stället för giltiga indata. Om indata skickas direkt till servern utan att verifieras och om programmet oavsiktligt kör den inmatade koden kan attacken skada eller förstöra data.

Alla procedurer som konstruerar SQL-instruktioner bör granskas för sårbarheter vid inmatning eftersom SQL Server kör alla syntaktiskt giltiga frågor som den tar emot. Även parametriserade data kan manipuleras av en skicklig och bestämd angripare. Om du använder dynamisk SQL måste du parametrisera dina kommandon och aldrig inkludera parametervärden direkt i frågesträngen.

Anatomi för en SQL-inmatningsattack

Inmatningsprocessen fungerar genom att en textsträng avslutas i förtid och ett nytt kommando läggs till. Eftersom det infogade kommandot kan ha ytterligare strängar tillagda innan det körs, avslutar malefactor den inmatade strängen med kommentarstecknet "--". Efterföljande text ignoreras vid körning. Flera kommandon kan infogas med hjälp av ett semikolon (;) avgränsare.

Så länge den inmatade SQL-koden är syntaktiskt korrekt kan manipulering inte identifieras programmatiskt. Därför måste du verifiera alla användarindata och noggrant granska kod som kör konstruerade SQL-kommandon på den server som du använder. Sammanfoga aldrig användarindata som inte har verifierats. Strängsammanfogning är den primära startpunkten för skriptinmatning.

Här följer några användbara riktlinjer:

• Skapa aldrig Transact-SQL-instruktioner direkt från användarindata. använd lagrade procedurer för att verifiera användarindata.

• Verifiera användarindata genom att testa typ, längd, format och intervall. Använd funktionen Transact-SQL QUOTENAME() för att undkomma systemnamn eller funktionen REPLACE() för att undvika tecken i en sträng.

• Implementera flera valideringslager på varje nivå i ditt program.

• Testa indatatypens storlek och datatyp och tillämpa lämpliga gränser. Detta kan bidra till att förhindra avsiktliga buffertöverskridanden.

• Testa innehållet i strängvariabler och acceptera endast förväntade värden. Avvisa poster som innehåller binära data, escape-sekvenser och kommentarstecken.

• När du arbetar med XML-dokument verifierar du alla data mot schemat när de anges.

• I miljöer med flera nivåer bör alla data verifieras innan de tas emot i den betrodda zonen.

• Acceptera inte följande strängar i fält som filnamn kan konstrueras från: AUX, CLOCK$, COM1 via COM8, CON, CONFIG$, LPT1 till LPT8, NUL och PRN.

• Använd SqlParameter objekt med lagrade procedurer och kommandon för att tillhandahålla typkontroll och längdverifiering.

• Använd Regex uttryck i klientkoden för att filtrera ogiltiga tecken.

Dynamiska SQL-strategier

Körningen av dynamiskt skapade SQL-instruktioner i din procedurkod bryter ägarskapskedjan, vilket gör att SQL Server kontrollerar anroparens behörigheter mot de objekt som används av den dynamiska SQL-filen.

SQL Server har metoder för att ge användare åtkomst till data med hjälp av lagrade procedurer och användardefinierade funktioner som kör dynamisk SQL.

• Använda personifiering med Transact-SQL EXECUTE AS-satsen.

• Signera lagrade procedurer med certifikat.

KÖR SOM

EXECUTE AS-satsen ersätter anroparens behörigheter med de behörigheter som tillhör den användare som anges i EXECUTE AS-satsen. Kapslade lagrade procedurer eller utlösare körs under proxyanvändarens säkerhetskontext. Detta kan bryta program som förlitar sig på säkerhet på radnivå eller som kräver granskning. Vissa funktioner som returnerar användarens identitet returnerar användaren som anges i EXECUTE AS-satsen, inte den ursprungliga anroparen. Körningskontexten återförs till den ursprungliga anroparen först efter att proceduren har körts eller när ett REVERT-kommando utfärdas.

Certifikatsignering

När en lagrad procedur som har signerats med ett certifikat körs sammanfogas behörigheterna som beviljats certifikatanvändaren med anroparens behörigheter. Körningskontexten förblir densamma. certifikatanvändaren personifierar inte anroparen. Signering av lagrade procedurer kräver flera steg att implementera. Varje gång proceduren ändras måste den signeras igen.

Åtkomst mellan databaser

Ägarskapslänkning mellan databaser fungerar inte i de fall där dynamiskt skapade SQL-instruktioner körs. Du kan kringgå detta i SQL Server genom att skapa en lagrad procedur som kommer åt data i en annan databas och signera proceduren med ett certifikat som finns i båda databaserna. Detta ger användarna åtkomst till de databasresurser som används av proceduren utan att ge dem databasåtkomst eller behörigheter.

Externa resurser

Mer information finns i resurserna nedan.

Resource	Description
Lagrade procedurer och SQL-inmatning i SQL Server Books Online	Ämnen beskriver hur du skapar lagrade procedurer och hur SQL-inmatning fungerar.

Nästa steg

• Programsäkerhetsscenarier i SQL Server