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

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

طبق نسخهٔ ۲۰۲۳ فهرست OWASP Top Ten، آسیب‌پذیری‌های «تزریق» در رتبهٔ سوم قرار دارند و همچنان یکی از آسیب‌پذیری‌های رایج نرم‌افزارهای وب محسوب می‌شوند.

علت‌های متداول بروز تزریق SQL مربوط به مدیریت نادرست ورودی‌ها و اعتبارسنجی ناکافی در لایهٔ کاربرد است. حملهٔ تزریق SQL زمانی رخ می‌دهد که داده‌های ورودی کاربر بدون پاک‌سازی یا پارامترایز شدن مستقیماً در رشتهٔ پرس‌وجوی SQL درج شوند و مهاجم بتواند با تغییر این عبارت‌ها، منطق پرس‌وجو را بازنویسی یا دستورات جدیدی اضافه کند؛ پیامدهای این وضعیت می‌تواند شامل افشای اطلاعات حساس، تغییر یا حذف داده‌ها و دورزدن کنترل‌های دسترسی باشد.

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

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

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

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


```
' OR 'a'='a
```


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

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


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


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


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

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

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

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


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


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

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

```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 معادل آن به صورت زیر خواهد شد:

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


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

### پاسخ‌های شرطی
نوعی از تزریق SQL کور است که پایگاه داده را مجبور به ارزیابی یک دستور منطقی بر روی صفحه یک برنامه معمولی می‌کند. به عنوان مثال یک وب‌سایت مرور کتاب از یک رشته Query برای مشخص کردن اینکه مرور کدام کتاب نمایش داده شود، استفاده می‌کند؛ بنابراین آدرس **<code></code>** باعث خواهد شد سرور Query زیر را اجرا کند:

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

که منجر به نمایش خلاصه مربوط به کتابی که با ID5 در جدول bookreview ذخیره شده‌است، خواهد شد. Query به‌طور کامل در سرور اتفاق می‌افتد؛ کاربر نام‌های مربوط به پایگاه داده، جدول یا فیلدها را نمی‌داند و از رشته Query نیز اطلاع ندارد. کاربر فقط می‌بیند که آدرس بالا خلاصه یک کتاب را برمی‌گرداند. یک هکر می‌تواند آدرس‌های **<code></code>** و **<code></code>** را بارگذاری کند که به ترتیب به صورت دستورها SQL زیر تبدیل می‌شوند:

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

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

هکر می‌تواند با وارد کردن رشته Query زیر موفق به کشف شماره نسخه MySQL در حال اجرا بر روی سرور شود:
**<code></code>**، که خلاصه کتاب را در صورتی که سرور بر روی 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();` اسکیپ می‌شوند:


```php
$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 مایکروسافت، هنگام ورود به پایگاه داده می‌توان گزینش را به برخی جداول سیستمی محدود کرد که این عمل باعث کاهش سوء استفاده‌هایی می‌شود که سعی در درج جاوا اسکریپت به تمام ستون‌های پایگاه داده دارند.

```tsql
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، به همین شیوه، گواهی‌نامه‌های لاگین بیش از ۴۵۰۰۰۰ کاربر این وبگاه را ربودند.

## منابع

* Wikipedia contributors, "SQL injection," Wikipedia, The Free Encyclopedia, http://en.wikipedia.org/w/index.php?title=SQL_injection&oldid=473084301 (accessed January 25, 2012).
* SQL-Injections - eine Analyse an PHP & MySQL

## پیوند به بیرون

* SQL Injection on the Nameless Wiki
* Blind Sql injection with Regular Expression
* BUGTRAQ-VULNERABLE SITE TRACKER (injection vulnerability)
* WASC Threat Classification - SQL Injection Entry, by the Web Application Security Consortium
* Why SQL Injection Won't Go Away, by Stuart Thomas
* SQL Injection Attacks by Example, by Steve Friedl
* SQL Injection Prevention Cheat Sheet, by OWASP
* SQL Injection Tutorial, by BTS.
* Free SQL Injection Testing and Exploitation Tool
* 10 years of sql injection history
* SDL Quick security references on SQL injection by Bala Neerumalla

رده:اس‌کیوال
رده:امنیت رایانه‌ای
رده:سوءاستفاده از تزریق
رده:سوءاستفاده امنیتی از رایانه
رده:مدیریت داده‌ها