PDA

View Full Version : ایا با PDO وقتی از prepare استفاده میکنیم دیگه نیازی نیست از هیچ تابعی اطلاعات ورودی رو بگذرونیم؟



saeed-71
یک شنبه 08 تیر 1393, 16:47 عصر
سلام.
ایا با PDO وقتی از prepare استفاده میکنیم دیگه نیازی نیست از هیچ تابعی اطلاعات ورودی رو بگذرونیم؟برای حذف وردی های مخرب.
با خیال راحت این کار رو انجام بدم؟؟

Unique
یک شنبه 08 تیر 1393, 17:58 عصر
در صورت استفاده از paramterized query ها مقابل injection ها در امانید اما برای مقابله با xss باید ورودی را کنترل کنین. البته نیاز نیست خودتون این کار را انجام بدین و کافیه از کلاس HTML Purifier (http://htmlpurifier.org/) استفاده کنید.

cpuram
یک شنبه 08 تیر 1393, 18:18 عصر
در صورت استفاده از paramterized query ها مقابل injection ها در امانید اما برای مقابله با xss باید ورودی را کنترل کنین. البته نیاز نیست خودتون این کار را انجام بدین و کافیه از کلاس HTML Purifier (http://htmlpurifier.org/) استفاده کنید.

حجمش زیاد نیست؟ راه آسونتر ندارید؟

navid3d_69
یک شنبه 08 تیر 1393, 18:42 عصر
توی قسمت امنیت آموزشی گذاشتم ک کلا راه جلوگیری از sqli رو آموزش دادم که هم با Mysql_* و هم با PDO اون آموزش رو ببنید و رعایت کنید مشکلی نیست

saeed-71
یک شنبه 08 تیر 1393, 20:14 عصر
مثلا این کد insert کردن من هستش


$name = Check_Post($_POST['name']);
$email = Check_Post($_POST['email']);
$mobile = Check_Post($_POST['mobile']);
$maghta = Check_Post($_POST['maghta']);
$reshte = Check_Post($_POST['reshte']);
$ostan = Check_Post($_POST['ostan']);
$shahr = Check_Post($_POST['shahr']);
$pas = Check_Post($_POST['pas']);

$pas = hash_value($pas);
$sql = $connect->prepare("INSERT INTO `user` (`name`, `mobile`, `email`, `maghta`, `reshte`, `ostan`, `shahr`, `dore`, `pas`, `ip`, `date`, `code`) VALUES (:name,:mobile,:email,:maghta,:reshte,:ostan,:shah r,:dore,:pas,:ip,:date,:code) ");
if($sql->execute(array(
":name"=>$name,
":email"=>$email,
":mobile"=>$mobile,
":maghta"=>$maghta,
":reshte"=>$reshte,
":ostan"=>$ostan,
":shahr"=>$shahr,
":pas"=>$pas,
":dore"=>$dore,
":ip"=>$ip,
":date"=>$date,
":code"=>$code
)))

از ان تابع عم در کنار prepare کردن استفاده میکنم


function Check_Post($value){
$Return1 = addslashes($value);
$Return2 = htmlspecialchars($Return1);
$Return3 = strip_tags($Return2);
return $Return3;
}

//check get data
function Check_Get($value){
$Return1 = addslashes($value);
$Return2 = htmlspecialchars($Return1);
$Return3 = strip_tags($Return2);
$Return4 = intval($Return3);
return $Return4;
}

برا امنیتش کافیه؟

SA_Developer
یک شنبه 08 تیر 1393, 20:44 عصر
برا امنیتش کافیه؟
سلام
جواب این سوالتون رو هیچکس نمیتونه بده :لبخندساده:

وقتی از Prepared Statement استفاده میکنید دیگه نیازی به Sanitize کردن داده ها نیست.

Unique
دوشنبه 09 تیر 1393, 03:35 صبح
حجمش زیاد نیست؟ راه آسونتر ندارید؟

سمت سرور انجام میشه ! (حجمش چه مشکلی پیش میاره؟) بهترین راه جلوگیری از XSS که میشناسم همینه.


برا امنیتش کافیه؟
دوست عزیز ،‌به نظر من شما اطلاعاتتون نسبت به بحث های ابتدایی امنیت مثل SQL Injection و XSS کمه ! توی این انجمن خیلی بحث شده و نکات خیلی مهم را اگه جستجو کنید پیدا میکنید.

وقتی از mysql extension استفاده میکردیم و میخواستیم توی query اطلاعاتی بگذاریم ممکنه بدون کاربر با ارسال مقادیری باعث اختلال یا کلا عوض شدن اصلا query ما بشه و اصطلاحا sql injection اتفاق بیفته ! ولی وقتی از musqli و pdo و روش parametrized query یا همون prepared statement شما استفاده میکنیم ! ورودی های کاربر به عنوان مقدار هستند و هیچ تداخلی در اصل query پی ش نمیارند. پس کارهایی

تابع Check_Post و Check_Get شما اصلا کاربردی نیست ! برای xss که گفتم چیکار کنین ! اگر هم میخواین جایی مقادیر html را معادل سازی کنین یا مقدرای را به عدد تبدیل کنین ! نیاز به این توابع نیست و میشه مستقل انجام داد.

eshpilen
دوشنبه 09 تیر 1393, 08:19 صبح
البته امثال HTML Purifier (http://htmlpurifier.org/) برای وقتی استفاده میشن که میخوایم دیتا حاوی بخشی از تگهای بی خط یا کم خطر HTML باشه و در عین حال جلوی تگها و موارد خطرناک (اونایی که ما نمیخوایم اجازه بدیم) گرفته بشه.
وگرنه اگر اصولا قرار نیست در داده ها فرمت و تشکیلات HTML وجود داشته باشن و عمل کنن، باید با توابع ساده تری مثل striptags یا htmlspecialchars کلا امکان استفاده یا عمل کردن کدهای HTML رو از بین برد.
البته در استفاده از این توابع هم باید مواظب باشید چون بعضی موارد غیرمنتظره هست که نتیجه طبق انتظار نمیشه! فرضا اگر مقدار یک داده ای رو در داخل خود یک تگ ابتدایی وارد میکنید (مثلا بعنوان value یک attribute)، اونوقت striptags جلوش رو نمیگیره و مثلا دیتا ممکنه این باشه:

" onclick="javascript code..."
الان striptags میتونه جلوی این رو بگیره؟
یا همینطور فکر کنم htmlspecialchars در مواردی.
خلاصه بحث و جزییات زیاد داره. من خودمم با اینکه بارها کلی منابع خوندم الان حضور ذهن دقیق ندارم و برای اطمینان و اطلاعات جامع تر باید دوباره فکر و تحقیق کنم که الان اصولا وقتش رو ندارم!
امنیت یک مسئله ای است که فقط با حفظ دوتا فرمول و روش و تابع نمیشه ازش بقدر کافی مطمئن شد. امنیت مسئله ای همیشه در جریان است و به اشکال زیادی میتونه بروز کنه و به خیلی پارامترها و منطق و جزییات هر برنامه و کد خاص وابسته است و یک چیز کلیشه ای نیست که دوتا تابع و فرمول کلی و مطلق برای همهء نیازها داشته باشه. شما باید تمام روشها و نکات پایه نفوذ و دفاع رو بدونید و در عین حال همیشه فکر کنید که حالا در این مورد به چه شکلهایی ممکنه نفوذ صورت بگیره. باید خودتون رو بذارید جای کاربر یا نفوذگر و فکر کنید هر نوع داده ای به هر شکل و محتوی هرچیزی ممکنه ارسال بشه، بعد تمام حالتهای کلی و جزیی ممکن اون رو تحلیل کنید (اکثرا ذهنی و با سرعت میشه بیشتر موارد رو تحلیل کرد).
البته شاید بد نباشه همزمان چندتا یا حتی همهء این روشها، منجمله HTML Purifier (http://htmlpurifier.org/) رو با هم ترکیب کنیم، اما این یک روش بیش از حد مبتدیانه و هدر دهندهء منابع بنظر میاد بخصوص که در بیشتر موارد به این همه پیچیدگی و کار نیاز نیست و در بعضی موارد هم که اصولا نمیشه اینقدر محدودیت ایجاد کرد.

MMSHFE
دوشنبه 09 تیر 1393, 08:45 صبح
البته htmlentities اگه با پارامتر دوم ENT_QUOTES بکار گرفته بشه، کارکترهای کوتیشن رو هم خنثی سازی میکنه.

abolfazl-z
دوشنبه 09 تیر 1393, 10:11 صبح
میتونیم از htmlspecialchars با پارامتر EN_QUOTES هم استفاده کنیم.

من در ثبت اطلاعات، داده ایی را از لحاظ حمله xss بررسی نمیکنم بلکه تمامی داده ها را در قسمت خروجی بررسی میکنم و دلیل اش هح این هست که باعث میشود حجم اضافی ذخیره نشود.

ولی تمامی پروژه من روی یک کلاس حرفه ایی mysql می چرخد و تمامی کوئری ها در تمامی پروژه توسط این کلاس صورت میگیرد.

eshpilen
دوشنبه 09 تیر 1393, 10:14 صبح
آره ولی باز یه موارد دیگری هم داره مثل اینکه. بطور مثال در یک منبعی میخوندم اگر یادم باشه به درج دیتا در بین تگهای اسکریپت اشاره کرده بود و گفته بود که خیلی خطرناکه و راه جلوگیری از تمام روشهای نفوذ در این حالت هم چیز ساده و مختصری نیست. گفته بود اصلا تا میتونید سعی کنید هیچوقت دیتا از منابع غیرقابل اعتماد رو بین تگهای اسکریپت استفاده نکنید.

abolfazl-z
دوشنبه 09 تیر 1393, 11:00 صبح
آره ولی باز یه موارد دیگری هم داره مثل اینکه. بطور مثال در یک منبعی میخوندم اگر یادم باشه به درج دیتا در بین تگهای اسکریپت اشاره کرده بود و گفته بود که خیلی خطرناکه و راه جلوگیری از تمام روشهای نفوذ در این حالت هم چیز ساده و مختصری نیست. گفته بود اصلا تا میتونید سعی کنید هیچوقت دیتا از منابع غیرقابل اعتماد رو بین تگهای اسکریپت استفاده نکنید.

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

Unique
دوشنبه 09 تیر 1393, 15:54 عصر
فقط برای تکمیل صحبت های خودم بگم که به دوستمون توضیح ندادم که اصولا اگه قرار نیست محتوای html از کاربر بگیریم ! استفاده از توابعی مثل htmlspecialchars و htmlentities کفایت میکنه و HTML Purifier زمانی کاربرد داره که میخوایم کاربر بتونه محتوای html ذخیره کنه.



من در ثبت اطلاعات، داده ایی را از لحاظ حمله xss بررسی نمیکنم بلکه تمامی داده ها را در قسمت خروجی بررسی میکنم و دلیل اش هح این هست که باعث میشود حجم اضافی ذخیره نشود.

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

abolfazl-z
دوشنبه 09 تیر 1393, 18:28 عصر
زمانی که داده ها را در زمان ثبت بررسی میکنیم این بررسی یکبار انجام میشه ولی زمانی که در قسمت نمایش این کار انجام میشه بار ها ممکنه یک بررسی انجام بشه و حتی امکان داره به علت فراموشی یا کار گروهی جایی این بررسی انجام نشه و کار دستمون بده در صورتی که مثلا ذخیره چند کیلوبایت یا حالا چند مگابایت کمتر و بیشتر خطری برای شما نداره ! من این روش را به کل رد میکنم.

بله من هم به این نکات توجه کرده ام ولی بنده عرض کردم که در تمامی پروژه از یک کلاس mysql استفاده میشود و بصورت پیشفرض تمامی داده های خروجی بررسی می شوند.

Unique
چهارشنبه 11 تیر 1393, 02:52 صبح
بله من هم به این نکات توجه کرده ام ولی بنده عرض کردم که در تمامی پروژه از یک کلاس mysql استفاده میشود و بصورت پیشفرض تمامی داده های خروجی بررسی می شوند.

در اصل قضیه تفاوتی ایجاد نمیکنه ! اگه منظور از خروجی همان زمان نمایش هست و کلاسی دارین که همه خروجی را از اون میگزند و خود کلاس مرتبا داده خروجی را چک میکنه باز هم دارین over head الکی تولید میکنید و کدتون اصلا بهینه نخواهد بود. توی پروژه های متوسط به بالا به مشکل میخورین. اطلاعات باید در زمان ورود به پایگاه داده بررسی و مشکلاتشون رفع بشه.

saeed-71
دوشنبه 23 تیر 1393, 11:52 صبح
خوب الان من باید از چه فیلترای دیگه ای استفاده کنم؟فقط htmlentities
من از PDO استفاده میکنم.

Unique
دوشنبه 23 تیر 1393, 16:27 عصر
یاد ضرب المثل لیلی زن بود یا مرد افتادم !؟

دوست عزیز ، خیلی ساده :

۱ - برای جلوگیری از sql injection از pdo و mysqli به صورت Prepared statements استفاده کنید.
۲ - اگر محتوا قرار نیست به صورت html ذخیره بشه محتوا را از توابع htmlspecialchars (اگه این محتوا قراره در attribute های تگ ها و برخی موراد خاص استفاده بشه) یا htmlentities (در بین تگها نمایش داده میشه) بگذرونید.
۳ - در صورتی که محتوای html باید ذخیره و نمایش داده بشه با استفاده از کلاس HTML Purifier مانع از حملات XSS بشین.
۴ - علاوه بر XSS و SQL Injection حملات دیگهای مثل CSRF یا Remote Code Execution و هم هست که باید گام به گام برای امنیت برنامه بهینه سازی هایی انجام بشه.
۵ - شاید اون اوایل باید میومد ولی وقت بازنویسی ندارم و اون اینکه همیشه محتوا را نسبت به اون چیزی که باید باشه ارزیابی کنید ، مثلا وقتی مقداری از پارامترGET_$ باید عددی باشه حتما بررسی کنید که عدد باشه و از توابعی مثل Intval و .. بگذرونید تا مطمئن بشین. یا مثلا اگه مقدار یک comoobox باید چند گزینه خاص باشه حتما بررسی کنید مقدار دریافتی یکی از اون ها باشه. این کار را با توابعی مثل in_array براحتی میشه انجام داد.

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