Webes projektek során egyre gyakrabban fordul elő, hogy bár a tesztelt alkalmazás megvalósít valamiféle bemeneti szűrést, az adatbázis segít kikerülni számunkra ezeket a megkötéseket. 

SQL Smugglingról korábban már írtam (bár ideje lenne frissíteni azt a posztot...), mostanában a leggyakoribb példa az XSS-ek keresztülverése például az ASP.NET ValidateRequest filterén vagy reguláris kifejezéseken:

Bár a filter kivételt dob a legtöbb értelmes <-el kezdődő bemenetre, a %uff1c unicode karaktert a MSSQL szerver éppen erre az ASCII jelre alakítja, ha unicode tartalmat akarunk CHAR vagy VARCHAR  típusú mezőbe tölteni (NCHAR illetve NVARCHAR helyett), így a szűrés szépen megkerülhető. 

Nem olyan régen kisebb gondba kerültem, ugyanis egy gonosz karakter-feketelistába botlottam, ami egy csomó, JavaScriptben hasznos karaktert (pl. zárójeleket) nem engedett át, így szükségem lett volna egy megfeleltetési táblázatra a háttérben ülő MSSQL szerver Unicode->ASCII konverzióiról. Miután a kézi próbálatás nem vezetett eredményre, fellőttem egy SQL Server példányt az Azure-ban (tanulság: a Microsoft szoftverek telepítése még a felhőben is lassú), és írtam egy rövid T-SQL szkriptet, ami egy táblába töltötte az összes 2-byte-os karakter értékét egész számként, Unicode illetve ASCII karakterként. 

Az eredmény megtalálható a GitHub-on, a további adatbázis motorokkal illetve konfigurációkkal kapcsolatban várom a hozzájárulásokat!

A tanulság a fejlesztőknek és üzemeltetőknek egyrészt annyi, hogy készüljetek fel adatbázis szinten a spéci karakterek fogadására, másrészt próbáljatok a naív karakterszűrések helyett valami robosztusabb megoldásban (pl. DOM-alapú validáció) gondolkodni!