Biztonságos dinamikus SQL írása az SQL Serveren

ADO.NET letöltése

Az SQL-injektálás az a folyamat, amellyel egy rosszindulatú felhasználó érvényes bemenet helyett Transact-SQL utasításokat ad meg. Ha a bemenetet közvetlenül a kiszolgálónak továbbítja ellenőrzés nélkül, és ha az alkalmazás véletlenül végrehajtja az injektált kódot, a támadás kárt okozhat vagy megsemmisíthet adatokat.

Az SQL-utasításokat összeállító eljárásokat felül kell vizsgálni az injektálási biztonsági rések miatt, mivel az SQL Server végrehajtja az összes kapott szintaktikailag érvényes lekérdezést. Még a paraméteres adatokat is manipulálhatja egy képzett és határozott támadó. Ha dinamikus SQL-t használ, győződjön meg arról, hogy paraméterezi a parancsokat, és soha ne adjon meg paraméterértékeket közvetlenül a lekérdezési sztringbe.

SQL-injektálási támadás anatómiája

Az injektálási folyamat úgy működik, hogy idő előtt megszakítja a karakterláncot, és hozzáfűz egy új parancsot. Mivel a beszúrt parancshoz a végrehajtás előtt további karakterláncok is hozzáfűzhetők, a támadó egy "--" megjegyzésjellel zárja le az injektált karakterláncot. A rendszer a végrehajtáskor figyelmen kívül hagyja a következő szöveget. Több parancs is beszúrható pontosvesszővel (;) elválasztójellel.

Mindaddig, amíg az injektált SQL-kód szintaktikailag helyes, az illetéktelen módosítás nem észlelhető programozott módon. Ezért ellenőriznie kell az összes felhasználói bemenetet, és gondosan át kell tekintenie azokat a kódot, amelyek a használt kiszolgálón létrehozott SQL-parancsokat hajtanak végre. Soha ne fűzz össze olyan felhasználói bemenetet, amely nincs érvényesítve. A szkriptinjektálás elsődleges belépési pontja a sztringösszefűzés.

Íme néhány hasznos útmutató:

• Soha ne hozzon létre Transact-SQL utasításokat közvetlenül a felhasználói bemenetből; tárolt eljárásokkal ellenőrizheti a felhasználói bemenetet.

• Felhasználói bevitel ellenőrzése tesztelési típus, hossz, formátum és tartomány szerint. A Transact-SQL QUOTENAME() függvényt használja a rendszernevek megszökítésére vagy a REPLACE() függvényt a sztring bármelyik karakterének cseréjére.

• Implementáljon több érvényesítési réteget az alkalmazás minden szintjén.

• Tesztelje a bemenet méretét és adattípusát, és kényszerítse ki a megfelelő korlátokat. Ez segíthet megelőzni a puffer szándékos túllépését.

• Tesztelje a sztringváltozók tartalmát, és csak a várt értékeket fogadja el. Elutasíthatja a bináris adatokat, a feloldósorozatokat és a megjegyzés karaktereket tartalmazó bejegyzéseket.

• Ha XML-dokumentumokkal dolgozik, a beíráskor ellenőrizze az összes adatot a sémájában.

• Többrétegű környezetekben minden adatot ellenőrizni kell a megbízható zónába való belépés előtt.

• Ne fogadja el a következő sztringeket olyan mezőkben, amelyekből fájlneveket lehet létrehozni: AUX, CLOCK$, COM1–COM8, CON, CONFIG$, LPT1–LPT8, NUL és PRN.

• Az SqlParameter objektumok tárolt eljárásokkal és parancsokkal biztosítják a típusellenőrzést és a hossz-ellenőrzést.

• Érvénytelen karakterek szűréséhez használjon Regex kifejezéseket az ügyfélkódban.

Dinamikus SQL-stratégiák

A dinamikusan létrehozott SQL-utasítások végrehajtása az eljárási kódban megszakítja a tulajdonjogi láncot, így az SQL Server ellenőrzi a hívó engedélyeit a dinamikus SQL által elért objektumokon.

Az SQL Server metódusokkal biztosít hozzáférést a felhasználóknak az adatokhoz tárolt eljárások és a dinamikus SQL-t végrehajtó felhasználó által definiált függvények használatával.

• Transact-SQL EXECUTE AS záradék használata impersonálással.

• Tárolt eljárások aláírása tanúsítványokkal.

VÉGREHAJTÁS MÁSKÉNT

Az EXECUTE AS záradék lecseréli a hívó engedélyeit az EXECUTE AS záradékban megadott felhasználó engedélyére. A beágyazott tárolt eljárások vagy eseményindítók a proxyfelhasználó biztonsági környezetében futnak. Ez megszakíthatja azokat az alkalmazásokat, amelyek sorszintű biztonságra támaszkodnak, vagy naplózást igényelnek. Egyes függvények, amelyek visszaadják a felhasználó identitását, az EXECUTE AS záradékban megadott felhasználót adja vissza, nem az eredeti hívót. A végrehajtási környezet csak az eljárás végrehajtása vagy a REVERT utasítás kiadása után lesz visszaállítva az eredeti hívóra.

Tanúsítvány aláírása

Amikor egy tanúsítvánnyal aláírt tárolt eljárás fut, a rendszer egyesíti a tanúsítványfelhasználónak adott engedélyeket a hívóéival. A végrehajtási környezet változatlan marad; a tanúsítványfelhasználó nem személyesíti meg a hívót. A tárolt eljárások aláírásához több lépésre van szükség. Az eljárás minden módosításakor újra alá kell írni.

Adatbázisközi hozzáférés

Az adatbázisok közötti tulajdonjog-láncolás nem működik a dinamikusan létrehozott SQL-utasítások végrehajtásakor. Ezt az SQL Serveren megkerülheti egy olyan tárolt eljárás létrehozásával, amely egy másik adatbázisban lévő adatokhoz fér hozzá, és az eljárást egy mindkét adatbázisban található tanúsítvánnyal aláírja. Ez hozzáférést biztosít a felhasználóknak az eljárás által használt adatbázis-erőforrásokhoz anélkül, hogy adatbázis-hozzáférést vagy engedélyeket ad nekik.

Külső erőforrások

További információkért lásd a következő forrásanyagokat.

Resource	Description
Tárolt eljárások és SQL-injektálás az SQL Server Books Online-ban	A témakörök ismertetik a tárolt eljárások létrehozását és az SQL Injection működését.

Következő lépések

• Alkalmazásbiztonsági forgatókönyvek az SQL Serverben