تزریق اس‌کیوال

فیلتر اشتباه کاراکترهای "" یا

این آسیب‌پذیری از راه‌های گوناگونی پدید می‌آید. یک طریق فیلترنشدن کراکترهای (" و ') است. برای مثال:

statement = "SELECT * FROM users WHERE name = '" + userName + "';"

کار این کد استخراج اطلاعات یک نام کاربری (که به متغیر داده می‌شود) از جدول users است. اما نفوذگر می‌تواند با دادن مقدارهایی هوشمندانه به متغیر userName، سبب اجرای دستورهایی متفاوت از آنچه موردنظر کدنویس بوده‌است بشود. برای مثال با وارد کردن این کد به عنوان ورودی:

' OR 'a'='a

کد نهایی اینچنین رندر می‌شود:

SELECT * FROM users WHERE name = '' OR 'a'='a';

همچنین می‌توان با یکی از این سه روش، ادامهٔ کد را کامنت گرفت:

' OR 'a'='a' -- '
' OR 'a'='a' ({ '
' OR 'a'='a' /* '

که نتیجه چنین است:

SELECT * FROM users WHERE name = '' OR 'a'='a' -- ';

مثلاً ممکن است در کدی، ادامهٔ کد، مربوط به بررسی گذرواژه باشد. در آن حالت با این کار آن بخش از کد، کامنت گرفته می‌شود و پردازش نمی‌شود. به این ترتیب نفوذگر بدون واردکردن گذرواژه از مانع می‌گذرد.

یا مثلاً واردشدن چنین عبارتی:

a'; DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't

سبب حذف جدول users و نیز استخراج تمام اطلاعات جدول userinfo می‌شود.

این ورودی به صورت دستور SQL زیر رندر و مشخص می‌شود:

SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't';

در حالی که بسیاری از پیاده‌سازی‌های SQL Server امکان اجرای چندین دستور را در یک فراخوان، مانند این مثال، فراهم می-کنند، برخی از رابط‌های برنامه کاربردی SQL مثل تابع؛ ()mysql_query در زبان PHP به دلایل امنیتی اجازه این عملیات را نمی‌دهند. این محدودیت باعث جلوگیری از تزریق Queryهای کاملاً مجزا از هم توسط مهاجمان می‌شود، اما نمی‌تواند مانع تغییر Queryها شود.

مدیریت نادرست نوع ورودی

این شکل از تزریق زمانی اتفاق می‌افتد که یک فیلد کاربر از نظر محدودیت‌های نوع ورودی بررسی نشده باشد. این اتفاق زمانی می‌تواند رخ دهد که یک فیلد عددی در یک دستور SQL استفاده شده باشد، اما برنامه‌نویس هیچ‌گونه بررسی برای تعیین نوع ورودی کاربر و تأیید ورودی عددی، فراهم نساخته باشد. برای مثال:

statement := "<syntaxhighlight lang="sql" inline>SELECT * FROM userinfo WHERE id = </syntaxhighlight>" + a_variable + ";"

با توجه به این دستور واضح است که برنامه‌نویس a-variable را برای تعیین عدد مرتبط با فیلد id در نظر گرفته‌است. با این حال، اگر ورودی از نوع رشته تعیین شده باشد، کاربر نهایی می‌تواند دستور را به صورت دلخواه دستکاری کرده و به این وسیله نیاز به ورود کراکترهای Escape شده را دور بزند. برای مثال مقداردهی a-variable به صورت زیر جدول "users" را از پایگاه داده حذف خواهد کرد:

1;DROP TABLE users

چرا که دستور SQL معادل آن به صورت زیر خواهد شد:

SELECT * FROM userinfo WHERE id=1;DROP TABLE users;

تزریق SQL کور

این اصطلاح زمانی استفاده می‌شود که یک برنامه تحت وب در برابر تزریق SQL آسیب‌پذیر است، اما نتایج تزریق برای مهاجمان قابل رؤیت نیست. صفحه دارای آسیب‌پذیری ممکن است آن صفحه‌ای نباشد که داده‌ها را نمایش می‌دهد، اما تفاوت‌های حاصل از نتایج یک دستور تزریق منطقی به درون یک دستور SQL مشروع را، که برای صفحه مورد نظر فراخوانی شده‌است، نمایش خواهد داد. این نوع حمله با افزایش زمان، ممکن است شدیدتر شود، زیرا برای هر بیت بازیابی شده، ساخت یک دستور نیاز است. ابزارهایی وجود دارد که پس از به‌دست آوردن اطلاعات مربوط به هدف و مکان آسیب‌پذیری، امکان خودکار کردن این حمله را فراهم می‌کنند.

پاسخ‌های شرطی

نوعی از تزریق SQL کور است که پایگاه داده را مجبور به ارزیابی یک دستور منطقی بر روی صفحه یک برنامه معمولی می‌کند. به عنوان مثال یک وب‌سایت مرور کتاب از یک رشته Query برای مشخص کردن اینکه مرور کدام کتاب نمایش داده شود، استفاده می‌کند؛ بنابراین آدرس http://books.example.com/showReview.php?ID=5 باعث خواهد شد سرور Query زیر را اجرا کند:

SELECT * FROM bookreviews WHERE ID = 'Value(ID)';

که منجر به نمایش خلاصه مربوط به کتابی که با ID5 در جدول bookreview ذخیره شده‌است، خواهد شد. Query به‌طور کامل در سرور اتفاق می‌افتد؛ کاربر نام‌های مربوط به پایگاه داده، جدول یا فیلدها را نمی‌داند و از رشته Query نیز اطلاع ندارد. کاربر فقط می‌بیند که آدرس بالا خلاصه یک کتاب را برمی‌گرداند. یک هکر می‌تواند آدرس‌های http://books.example.com/showReview.php?ID=5 AND 1=1 و http://books.example.com/showReview.php?ID=5 AND 1=2 را بارگذاری کند که به ترتیب به صورت دستورات SQL زیر تبدیل می‌شوند:

SELECT * FROM bookreviews WHERE ID = '5' AND '1'='1';
SELECT * FROM bookreviews WHERE ID = '5' AND '1'='2';

اگر با آدرس "۱=۱" خلاصه اصلی بارگذاری شود و با اجرای آدرس "۲=۱" صفحه خطا یا خالی برگردانده شود، سایت احتمالاً در مقابل حمله تزریق SQL آسیب‌پذیر است.

هکر می‌تواند با وارد کردن رشته Query زیر موفق به کشف شماره نسخه MySQL در حال اجرا بر روی سرور شود: http://books.example.com/showReview.php?ID=5 AND substring(@@version,1,1)=4، که خلاصه کتاب را در صورتی که سرور بر روی MySQL 4 در حال اجرا باشد، نمایش خواهد داد و در غیر این صورت یک صفحه خطا یا خالی را نشان خواهد داد. هکر با استفاده از کد درون رشته‌های Query می‌تواند به اطلاعات بیشتری از سرور دست یابد تا مسیر اصلی حمله را کشف کرده و به اهداف خود دست یابد.

تزریق SQL سطح دوم

این تزریق زمانی اتفاق می‌افتد که مقادیر ارائه شده شامل حملات تزریق SQL باشد که به جای برخی دستورات اجرایی ذخیره شده‌اند. برنامه کاربردی ممکن است یک دستور SQL را به درستی رمزنگاری کرده و آن را به صورت یک دستور SQL معتبر ذخیره کند. سپس بخش دیگری از برنامه که بدون هیچ‌گونه کنترلی برای محافظت در برابر تزریق SQL طراحی شده‌است، ممکن است دستور SQL ذخیره شده را اجرا کند. این حمله نیازمند آگاهی بیشتر در مورد این است که مقادیر ارائه شده، بعداً چگونه استفاده خواهند شد. اسکن کننده‌های امنیت برنامه‌های کاربردی تحت‌وب خودکار به آسانی نمی‌توانند این گونه حمله را تشخیص دهند و ممکن است نیاز باشد که به صورت دستی، برای بررسی علائم این حمله، دستورنویسی شود.

دستورات پارامتریک

با توسعه بیشتر platformها، دستورات پارامتریک که با پارامترها کار می‌کنند می‌توانند به جای تعبیه ورودی کاربر در دستورات استفاده شوند (گاهی متغیر یا متغیرهای bind نامیده می‌شوند). یک متغیر تنها می‌تواند مقدار یک نوع داده و نه یک قطعه SQL دلخواه را ذخیره کند. از این رو تزریق SQL به راحتی به صورت یک مقدار پارامتری ناآشنا (و احتمالاً نامعتبر) عمل می-کند. در بسیاری از موارد، دستور SQL ثابت است و هر پارامتر یک اسکالر است و نه یک جدول. سپس ورودی کاربر به یک پارامتر اختصاص داده می‌شود (bound می‌شود).

اجرا در سطح برنامه‌نویسی

استفاده از کتابخانه‌های نگاشت مبتنی بر ارتباط اشیاء، نیاز به نوشتن کدهای SQL را برطرف می‌کند. کتابخانه ORM تحت تأثیر کدهای شیء گرا، دستورات SQL پارامتریک را تولید می‌کند.

Escaping

یک راه ساده اما مستعد خطا برای جلوگیری از تزریق، Escape کردن کراکترهایی است که در SQL معنای خاصی دارند. راهنمای پایگاه داده SQL توضیح می‌دهد که کدام کراکترها معنی خاص دارند، بنابراین این امکان را فراهم می‌کند که یک فهرست سیاه جامع از کراکترهایی که نیاز به ترجمه دارند تهیه شود. برای مثال، هر رخداد از نقل قول تکی (') در یک پارامتر، باید توسط دو نقل قول ('') جایگزین شود تا به شکل یک رشته SQL معتبر تبدیل شود. برای مثال، در PHP معمولاً پارامترها قبل از ارسال Query، به کمک تابع mysql_real_escape_string(); اسکیپ می‌شوند:

$mysqli = new mySqli('hostname', 'db_username', 'db_password', 'db_name');
$query = sprintf("SELECT * FROM `Users` WHERE UserName='%s' AND Password='%s'",
                  $mysqli->real_escape_string($Username),
                  $mysqli->real_escape_string($Password));
$mysqi->query($query);

نکته: در حال حاضر از عملکرد mysql نارضایتی وجود دارد، بنابراین از استفاده از آن اجتناب شده و به جای آن از 'mysqli' استفاده می‌شود.

این تابع، مثلاً ()mysql_real_escape_string، تابع mysql_real_escape_string را از کتابخانه MySQL فراخوانی می‌کند، که به کراکترهایی که بعد از backslashها می‌آیند توجه می‌کند:\x00, \n, \r, \, ', " و \x1a. این تابع باید همیشه (به جز چند استثنا) پیش از ارسال Query به MySQL برای ساخت داده امن استفاده شود.
توابع دیگری برای انواع پایگاه داده در PHP وجود دارد مانند ()pg_escape_string برای PostgreSQL. با این حال یک تابع وجود دارد که برای Escape کردن کراکترها کار می‌کند و به‌طور خاص برای گرفتن Query از پایگاه‌های داده‌ای که توابعی برای Escaping در PHP ندارند، استفاده می‌شود. این تابع (addslashes(string $str است. یک رشته برمی‌گرداند که شامل backslashهایی است که پیش از کراکترهای مورد نیاز در گزارش‌گیری از پایگاه داده، قرار می‌دهد. این کراکترها نقل قول تکی (')، نقل قول (")، backslash (\) و کراکتر پوچ (NULL) هستند.
به‌طور معمول عبور رشته‌های Escape شده به SQL مستعد خطا است زیرا امکان فراموش کردن Escape کردن رشته داده وجود دارد. ساخت یک لایه شفاف برای امن کردن ورودی می‌تواند این استعداد خطا را کاهش دهد، هر چند که به‌طور کامل آن را از بین نمی‌برد.

بررسی الگو

پارامترهای بولی، شناور یا صحیح می‌توانند از نظر نوع بررسی شوند که مقادیر مطابق با نوع آن‌ها وارد شده باشد. رشته‌هایی که باید برخی الگوها را رعایت کنند (تاریخ، UUID، … و غیره) می‌توانند بررسی شوند که با این الگوها مطابقت داشته باشند.

مجوزهای پایگاه داده

محدود کردن مجوزهای ورود به پایگاه داده که توسط برنامه‌های تحت‌وب تنها برای موارد مورد نیاز استفاده می‌شود، می‌تواند در جهت کاهش اثرات مربوط به هرگونه حمله تزریق SQL به کار رود. برای مثال، در سرور SQL مایکروسافت، هنگام ورود به پایگاه داده می‌توان گزینش را به برخی جداول سیستمی محدود کرد که این عمل باعث کاهش سوء استفاده‌هایی می‌شود که سعی در درج جاوا اسکریپت به تمام ستون‌های پایگاه داده دارند.

deny select on sys.sysobjects to webdatabaselogon;
deny select on sys.objects to webdatabaselogon;
deny select on sys.tables to webdatabaselogon;
deny select on sys.views to webdatabaselogon;
deny select on sys.packages to webdatabaselogon;

در ژوئیهٔ ۲۰۱۲ گروهی تحت عنوان D33D با نفوذ به زیردامنه‌ای از یاهو، Yahoo Voices، به همین شیوه، گواهی‌نامه‌های لاگین بیش از ۴۵۰۰۰۰ کاربر این وبگاه را ربودند.