• 1 رای - 5 میانگین
  • 1
  • 2
  • 3
  • 4
  • 5
انواع حمله های نفوذ و سوءاستفاده از صفحات وب
#31
نقل قول:2.هکر یک برنامه نوشته که تولید اسپمینگ می کنه(این برنامه برای هر اسپم دو مرحله داره. 1-ابتدا صفحه delete.php رو باز می کنه و مقدار توکن رو از صفحه می خونه و سپس این مقدار توکن رو به همراه session_id و بقیه متغیر ها در مرحله دوم به سرور ارسال می کنه) در خواستی مثل این
http://mysite.com/delete.php?id=100&toke...ewrawparpy
منظور از token همون session_id نیست .
دقت کن که حملات کی و کجا صورت میگیرده .
حملاتی که بصورت CSRF صورت میگیره ، باید یه لینک به خورد کاربر بدی و بدونی همون زمان توی سیستم لاگین هست .
در حقیقت CSRF یک حمله است نه هک کردن .

در مورد کپچایی که فرمودید
شما باید کاری کنید که کاربر(انسانی) رو از ربات تشحیص بدید .
حالا هر آلگوریتم منطقی پیاده کنید باز رباتی میشه نوشت که شبیه سازیش رو درخواست بده .
تنها راهی که برات میمونه یه کپچاست که اونم جناب vejmad کفتن دیگه
وبلاگ rezaonline.net/blog
سفارش برنامه نویسی reza.biz
Php , mysql , postgresql , redis , Yii and ... Cool
  پاسخ
تشکر شده توسط :
#32
(۱۳۹۰ فروردین ۳۰, ۰۹:۵۸ ب.ظ)vejmad نوشته: دوستان یه چیزی بگم درمورد XSS تا مطلب کامل بشه.
XSS و کلا بیشتر مسائل امنیتی گسترده تر از این حرفا هستن که ما اونا رو به چنتا مثال و مورد مطرح شده در این تاپیک محدود بکنیم.
این چنتا موردی هم که بنده گفتم برای توضیح کلی مطلب و چند مورد خیلی متداول و کاربردی بودن که در بیشتر برنامه های بیشتر افراد وجود دارن و نیاز هستن.
بجز اینا بازم هست و حتی مواردی هست که تابع htmlspecialchars به تنهایی کفایت نمیکنه.
مثلا در همین بحث در یک فروم دیگه یکی از دوستان که آدم واردی هست و تاحالا کلی نرم افزارهای خفن مثل ویبالتین رو هک کرده نظیر چنین موردی رو مطرح کرد:
کد پی‌اچ‌پی:
<html>
<
body>
<
a href="<?php echo htmlspecialchars($_REQUEST['link'], ENT_QUOTES); ?>">heyclick me!</a>
</
body>
</
html
در اینجا ما آدرس لینک رو از ورودی کاربر میگیریم و در صفحه درج میکنیم.
حالا بنظر شما آیا این کد امن هست؟
البته خوشبختانه بنده سربلند بیرون آمدم و با اینکه تاحالا چنین کدی نداشتم و یادم نمیاد چیزی درموردش خونده باشم اما تونستم اشکال این روش و راه حل امن رو بگم. و این جز با درک و بینش کامل و عمیق مطلب و دانش لازم ممکن نیست؛ واسه همین میگم باید کامل و عمیق علت و مکانیزم و کارکرد روش همه چیز رو درک کرد چون بتونید حداقل یکسری موارد خاص درشت و چیزهایی رو هم که تاحالا برخورد نکردید پیشبینی کنید (البته این فقط یکی از دلایلش هست).
اول ببینیم ضعف این روش در چیه.
شما اگر این صفحه رو با آدرسی مثل:
کد:
http://localhost/test.php?link=javascript:alert%281%29;

فراخوانی کنید، شاهد تزریق اسکریپت خواهید بود. با وجودی که از تابع htmlspecialchars استفاده کردیم.
البته این مشکل خوشبختانه درمورد PHP_SELF وجود نداره، چون PHP_SELF محتوی آدرس فراخوانی اسکریپت هست که کسی نمیتونه دستکاریش کنه تا با چیزی مثل:
کد:
javascript:
شروع بشه.
البته درکنار این تابع و روش، اطمینان حاصل کنید که مشکل رجیسترگلوبالز وجود نداره و رجیسترگلوبالز خاموش هست یا از طریق کدها و روشهای دیگر چک کنید که PHP_SELF دستکاری نشده باشه. بعدا به مورد رجیسترگلوبالز هم خواهیم رسید که روشش خیلی ساده هست. اصلا همینجا یه روش سرراست و کارا رو بهتون میگم! این کد رو در ابتدای هر اسکریپت خودتون بذارید. قبل از هرچیزی دیگری:
کد:
if(ini_get('register_globals')) exit("<center><h3>Error: Turn that damned register globals off!</h3></center>");
خب برگردیم به مشکل لینک و javascript:. برای رفع این مشکل باید ورودی کاربر رو چک کنید که فقط با پروتکل های شناخته شده و بی خطری که شما تعیین میکنید شروع شده باشه. مثلا آدرس فقط با http: یا ftp: و امثالهم شروع شده باشه. به این میگن روش لیست سفید که روش سختگیرانه ولی لازم در چنین مواردی هست. در روش لیست سفید تعداد محدودی عبارتهای مجاز رو تعیین میکنیم و هرچیز دیگری بغیر از اونها رد میشه. در روش لیست سیاه (Black list) بعکس تعداد محدودی عبارتهای غیرمجاز رو تعیین میکنیم و هرچیز دیگری بغیر از اونها تایید میشه. لیست سیاه روش آزادتری هست.
اینکه از لیست سفید استفاده میکنیم بخاطر اینه که ممکنه تمام پروتکل ها و URI scheme های خطرناک رو ندونیم یا در آینده URI scheme های جدیدی بوجود بیان که قابل سوء استفاده باشن. ضمنا خوشبختانه این روش مشکل و محدودیت خاصی درمورد چنین چیزهایی مثل درج لینک های کاربران ایجاد نمیکنه چون میشه 99% آدرسهایی رو که کاربران نیاز دارن به این روش تایید کرد. مثلا حتی آدرسهایی مثل لینک فراخوانی یاهومسنجر و غیره رو.

حالا میتونیم با یک سوال ظرافت های این مسائل و بینش لازم رو محک بزنیم:
یکی ممکنه بجای http: رشتهء http رو چک کنه (بدون کالن). آیا بنظر شما این روش بقدر روش قبلی اصولی/امن هست و چرا؟

با عرض سلام خدمت اساتید
من کل این تاپیک رو مطالعه کردم
قسمت مربوط به لیست سفید برام گنگ بود کسی در مورد نحوه ی پیاده سازی اون میتونه مثالی بزنه؟
آیا منظور اینه که وقتی ورودیی از سمت کاربر از تابع htmlspecialchars عبور کرد ، باز هم یکسری فیلتر دیگه باید براش تعریف کنیم آیا این باز بحث محدود سازی ورودی کاربر رو باعث نمیشه ؟
اگر کسی مثالی داره ممنون میشم.
  پاسخ
تشکر شده توسط :
#33
XSRF
بوسیلهء این حمله یک دستور/عملیات از طرف کاربر بدون اینکه خودش خبر داشته باشه میتونه در سایتی که احتمالا کاربر در اون لاگین هست اجرا بشه. یعنی کاربر بدون اینکه متوجه بشه آدرسی از سایت هدف رو که عملیات خاصی انجام میده در مرورگر خودش تحت ظاهرا سایت دیگری باز میکنه. اینم باز حملهء مستقیمی به خود سایت نیست، بلکه به کاربران سایت حمله میشه.
  پاسخ
تشکر شده توسط : زیرنویس انگلیسی فیلم


پرش به انجمن:


کاربران در حال بازدید این موضوع: 1 مهمان