├── OWASP_Top10 ├── images │ └── mapping.png └── README.md ├── 4-Web_Application_Security_Testing ├── 01-Information_Gathering │ ├── images │ │ ├── Httprint.jpg │ │ ├── Netcraft2.png │ │ ├── OWASPZAPSP.png │ │ ├── Cakephp_cookie.png │ │ ├── Owasp-wappalyzer.png │ │ ├── Whatweb-sample.png │ │ ├── Zk_html_source.png │ │ ├── wp-syntaxerror.png │ │ ├── Banshee_bottom_page.png │ │ ├── Wordpress_dirbusting.png │ │ ├── Robots-info-disclosure.png │ │ ├── Drupal_botcha_disclosure.png │ │ ├── Google_cache_Operator_Search_Results_Example_20200406.png │ │ └── Google_site_Operator_Search_Results_Example_20200406.png │ ├── 09-Fingerprint_Web_Application.md │ ├── README.md │ ├── 07-Map_Execution_Paths_Through_Application.md │ ├── 01-Conduct_Search_Engine_Discovery_Reconnaissance_for_Information_Leakage.md │ ├── 02-Fingerprint_Web_Server.md │ ├── 05-Review_Web_Page_Content_for_Information_Leakage.md │ ├── 03-Review_Webserver_Metafiles_for_Information_Leakage.md │ ├── 06-Identify_Application_Entry_Points.md │ ├── 10-Map_Application_Architecture.md │ ├── 08-Fingerprint_Web_Application_Framework.md │ └── 04-Enumerate_Applications_on_Webserver.md ├── 04-Authentication_Testing │ ├── images │ │ ├── Basm-sessid.jpg │ │ ├── Basm-sessid2.jpg │ │ ├── Basm-sqlinj.jpg │ │ ├── Basm-sqlinj2.gif │ │ ├── Basm-directreq.jpg │ │ └── Basm-parammod.jpg │ ├── README.md │ └── 01-Testing_for_Credentials_Transported_over_an_Encrypted_Channel.md ├── 03-Identity_Management_Testing │ ├── images │ │ ├── Userisnotactive.png │ │ ├── Wordpress_useradd.png │ │ ├── AuthenticationFailed.png │ │ ├── Wordpress_authandusers.png │ │ ├── Google_registration_page.jpg │ │ └── Wordpress_registration_page.jpg │ ├── README.md │ ├── 05-Testing_for_Weak_or_Unenforced_Username_Policy.md │ ├── 03-Test_Account_Provisioning_Process.md │ ├── 02-Test_User_Registration_Process.md │ ├── 01-Test_Role_Definitions.md │ └── 04-Testing_for_Account_Enumeration_and_Guessable_User_Account.md ├── 02-Configuration_and_Deployment_Management_Testing │ ├── images │ │ ├── subdomain_takeover_ex1.jpeg │ │ └── subdomain_takeover_ex2.jpeg │ ├── 08-Test_RIA_Cross_Domain_Policy.md │ ├── README.md │ ├── 09-Test_File_Permission.md │ ├── 07-Test_HTTP_Strict_Transport_Security.md │ ├── 13-Test_for_Path_Confusion.md │ ├── 12-Test_for_Content_Security_Policy.md │ ├── 11-Test_Cloud_Storage.md │ ├── 05-Enumerate_Infrastructure_and_Application_Admin_Interfaces.md │ ├── 03-Test_File_Extensions_Handling_for_Sensitive_Information.md │ ├── 10-Test_for_Subdomain_Takeover.md │ ├── 01-Test_Network_Infrastructure_Configuration.md │ └── 06-Test_HTTP_Methods.md ├── README.md └── 00-Introduction_and_Objectives │ └── README.md └── README.md /OWASP_Top10/images/mapping.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/OWASP_Top10/images/mapping.png -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/01-Information_Gathering/images/Httprint.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/4-Web_Application_Security_Testing/01-Information_Gathering/images/Httprint.jpg -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/01-Information_Gathering/images/Netcraft2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/4-Web_Application_Security_Testing/01-Information_Gathering/images/Netcraft2.png -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/01-Information_Gathering/images/OWASPZAPSP.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/4-Web_Application_Security_Testing/01-Information_Gathering/images/OWASPZAPSP.png -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/04-Authentication_Testing/images/Basm-sessid.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/4-Web_Application_Security_Testing/04-Authentication_Testing/images/Basm-sessid.jpg -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/04-Authentication_Testing/images/Basm-sessid2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/4-Web_Application_Security_Testing/04-Authentication_Testing/images/Basm-sessid2.jpg -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/04-Authentication_Testing/images/Basm-sqlinj.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/4-Web_Application_Security_Testing/04-Authentication_Testing/images/Basm-sqlinj.jpg -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/04-Authentication_Testing/images/Basm-sqlinj2.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/4-Web_Application_Security_Testing/04-Authentication_Testing/images/Basm-sqlinj2.gif -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/01-Information_Gathering/images/Cakephp_cookie.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/4-Web_Application_Security_Testing/01-Information_Gathering/images/Cakephp_cookie.png -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/01-Information_Gathering/images/Owasp-wappalyzer.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/4-Web_Application_Security_Testing/01-Information_Gathering/images/Owasp-wappalyzer.png -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/01-Information_Gathering/images/Whatweb-sample.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/4-Web_Application_Security_Testing/01-Information_Gathering/images/Whatweb-sample.png -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/01-Information_Gathering/images/Zk_html_source.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/4-Web_Application_Security_Testing/01-Information_Gathering/images/Zk_html_source.png -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/01-Information_Gathering/images/wp-syntaxerror.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/4-Web_Application_Security_Testing/01-Information_Gathering/images/wp-syntaxerror.png -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/04-Authentication_Testing/images/Basm-directreq.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/4-Web_Application_Security_Testing/04-Authentication_Testing/images/Basm-directreq.jpg -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/04-Authentication_Testing/images/Basm-parammod.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/4-Web_Application_Security_Testing/04-Authentication_Testing/images/Basm-parammod.jpg -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/01-Information_Gathering/images/Banshee_bottom_page.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/4-Web_Application_Security_Testing/01-Information_Gathering/images/Banshee_bottom_page.png -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/01-Information_Gathering/images/Wordpress_dirbusting.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/4-Web_Application_Security_Testing/01-Information_Gathering/images/Wordpress_dirbusting.png -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/03-Identity_Management_Testing/images/Userisnotactive.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/4-Web_Application_Security_Testing/03-Identity_Management_Testing/images/Userisnotactive.png -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/01-Information_Gathering/images/Robots-info-disclosure.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/4-Web_Application_Security_Testing/01-Information_Gathering/images/Robots-info-disclosure.png -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/03-Identity_Management_Testing/images/Wordpress_useradd.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/4-Web_Application_Security_Testing/03-Identity_Management_Testing/images/Wordpress_useradd.png -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/01-Information_Gathering/images/Drupal_botcha_disclosure.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/4-Web_Application_Security_Testing/01-Information_Gathering/images/Drupal_botcha_disclosure.png -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/03-Identity_Management_Testing/images/AuthenticationFailed.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/4-Web_Application_Security_Testing/03-Identity_Management_Testing/images/AuthenticationFailed.png -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/03-Identity_Management_Testing/images/Wordpress_authandusers.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/4-Web_Application_Security_Testing/03-Identity_Management_Testing/images/Wordpress_authandusers.png -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/03-Identity_Management_Testing/images/Google_registration_page.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/4-Web_Application_Security_Testing/03-Identity_Management_Testing/images/Google_registration_page.jpg -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/03-Identity_Management_Testing/images/Wordpress_registration_page.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/4-Web_Application_Security_Testing/03-Identity_Management_Testing/images/Wordpress_registration_page.jpg -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/images/subdomain_takeover_ex1.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/images/subdomain_takeover_ex1.jpeg -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/images/subdomain_takeover_ex2.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/images/subdomain_takeover_ex2.jpeg -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/01-Information_Gathering/images/Google_cache_Operator_Search_Results_Example_20200406.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/4-Web_Application_Security_Testing/01-Information_Gathering/images/Google_cache_Operator_Search_Results_Example_20200406.png -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/01-Information_Gathering/images/Google_site_Operator_Search_Results_Example_20200406.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/whoismh11/owasp-wstg-fa/HEAD/4-Web_Application_Security_Testing/01-Information_Gathering/images/Google_site_Operator_Search_Results_Example_20200406.png -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/08-Test_RIA_Cross_Domain_Policy.md: -------------------------------------------------------------------------------- 1 | # Test RIA Cross Domain Policy (fa-IR) 2 | 3 | آزمایش سیاست دامنه متقابل RIA (فارسی) 4 | 5 | |شناسه | 6 | |------------| 7 | |WSTG-CONF-08| 8 | 9 | این محتوا حذف شده است. 10 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/04-Authentication_Testing/README.md: -------------------------------------------------------------------------------- 1 | # 4.4 Authentication Testing (fa-IR) 2 | 3 | آزمایش احراز هویت (فارسی) 4 | 5 | 4.4.1 [Testing for Credentials Transported over an Encrypted Channel (آزمایش برای اعتبارنامه های منتقل شده از طریق یک کانال رمزگذاری شده)](01-Testing_for_Credentials_Transported_over_an_Encrypted_Channel.md) 6 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/01-Information_Gathering/09-Fingerprint_Web_Application.md: -------------------------------------------------------------------------------- 1 | # Fingerprint Web Application (fa-IR) 2 | 3 | انگشت نگاری برنامه وب (فارسی) 4 | 5 | |شناسه | 6 | |------------| 7 | |WSTG-INFO-09| 8 | 9 | این محتوا در [Fingerprint Web Application Framework](08-Fingerprint_Web_Application_Framework.md) ادغام شده است. 10 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/04-Authentication_Testing/01-Testing_for_Credentials_Transported_over_an_Encrypted_Channel.md: -------------------------------------------------------------------------------- 1 | # Testing for Credentials Transported over an Encrypted Channel (fa-IR) 2 | 3 | آزمایش برای اعتبارنامه های منتقل شده از طریق یک کانال رمزگذاری شده (فارسی) 4 | 5 | |شناسه | 6 | |------------| 7 | |WSTG-ATHN-01| 8 | 9 | این محتوا در [آزمایش برای اطلاعات حساس ارسال شده از طریق کانال های رمزگذاری نشده](../09-Testing_for_Weak_Cryptography/03-Testing_for_Sensitive_Information_Sent_via_Unencrypted_Channels.md) ادغام شده است. 10 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/README.md: -------------------------------------------------------------------------------- 1 | # Web Application Security Testing (fa-IR) 2 | 3 | آزمایش امنیت برنامه وب (فارسی) 4 | 5 | 4.0 [Introduction and Objectives (مقدمه و اهداف)](00-Introduction_and_Objectives/README.md) 6 | 7 | 4.1 [Information Gathering (جمع آوری اطلاعات)](01-Information_Gathering/README.md) 8 | 9 | 4.2 [Configuration and Deployment Management Testing (آزمایش مدیریت پیکربندی و استقرار)](02-Configuration_and_Deployment_Management_Testing/README.md) 10 | 11 | 4.3 [Identity Management Testing (آزمایش مدیریت هویت)](03-Identity_Management_Testing/README.md) 12 | 13 | 4.4 [Authentication Testing (آزمایش احراز هویت)](04-Authentication_Testing/README.md) 14 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/03-Identity_Management_Testing/README.md: -------------------------------------------------------------------------------- 1 | # 4.3 Identity Management Testing (fa-IR) 2 | 3 | آزمایش مدیریت هویت (فارسی) 4 | 5 | 4.3.1 [Test Role Definitions (آزمایش تعاریف نقش)](01-Test_Role_Definitions.md) 6 | 7 | 4.3.2 [Test User Registration Process (آزمایش فرآیند ثبت نام کاربر)](02-Test_User_Registration_Process.md) 8 | 9 | 4.3.3 [Test Account Provisioning Process (آزمایش فرآیند ارائه حساب)](03-Test_Account_Provisioning_Process.md) 10 | 11 | 4.3.4 [Testing for Account Enumeration and Guessable User Account (آزمایش برای شمارش حساب و حساب کاربری قابل حدس زدن)](04-Testing_for_Account_Enumeration_and_Guessable_User_Account.md) 12 | 13 | 4.3.5 [Testing for Weak or Unenforced Username Policy (آزمایش برای سیاست نام کاربری ضعیف یا غیرقابل اجرا)](05-Testing_for_Weak_or_Unenforced_Username_Policy.md) 14 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/03-Identity_Management_Testing/05-Testing_for_Weak_or_Unenforced_Username_Policy.md: -------------------------------------------------------------------------------- 1 | # Testing for Weak or Unenforced Username Policy (fa-IR) 2 | 3 | آزمایش برای سیاست نام کاربری ضعیف یا غیرقابل اجرا (فارسی) 4 | 5 | |شناسه | 6 | |------------| 7 | |WSTG-IDNT-05| 8 | 9 | ## خلاصه 10 | 11 | نام‌های حساب کاربری اغلب ساختار بالایی دارند (مثلاً نام حساب Joe Bloggs ء jbloggs و نام حساب کاربری Fred Nurks ء fnurks است) و نام حساب‌های معتبر را به راحتی می‌توان حدس زد. 12 | 13 | ## اهداف آزمایش 14 | 15 | - تعیین کنید که آیا ساختار نام حساب سازگار، برنامه را در برابر شمارش حساب آسیب پذیر می کند یا خیر. 16 | - تعیین کنید که آیا پیام های خطای برنامه اجازه شمارش حساب را می دهد یا خیر. 17 | 18 | ## چگونه آزمایش کنیم 19 | 20 | - ساختار نام حساب ها را تعیین کنید. 21 | - پاسخ برنامه به نام‌های حساب معتبر و نامعتبر را ارزیابی کنید. 22 | - از پاسخ‌های مختلف به نام‌های حساب معتبر و نامعتبر برای برشمردن نام‌های حساب معتبر استفاده کنید. 23 | - از دیکشنری های نام حساب برای برشمردن نام حساب های معتبر استفاده کنید. 24 | 25 | ## اصلاح 26 | 27 | اطمینان حاصل کنید که برنامه در پاسخ به نام حساب نامعتبر، رمز عبور یا سایر اطلاعات کاربری که در طول فرآیند ورود به سیستم وارد شده اند، پیام های خطای عمومی ثابتی را برمی گرداند. 28 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/01-Information_Gathering/README.md: -------------------------------------------------------------------------------- 1 | # 4.1 Information Gathering (fa-IR) 2 | 3 | جمع آوری اطلاعات (فارسی) 4 | 5 | 4.1.1 [Conduct Search Engine Discovery Reconnaissance for Information Leakage (شناسایی و کشف موتورهای جستجو برای نشت اطلاعات)](01-Conduct_Search_Engine_Discovery_Reconnaissance_for_Information_Leakage.md) 6 | 7 | 4.1.2 [Fingerprint Web Server (انگشت نگاری وب سرور)](02-Fingerprint_Web_Server.md) 8 | 9 | 4.1.3 [Review Webserver Metafiles for Information Leakage (بررسی متافایل های وب سرور برای نشت اطلاعات)](03-Review_Webserver_Metafiles_for_Information_Leakage.md) 10 | 11 | 4.1.4 [Enumerate Applications on Webserver (شمارش برنامه ها در وب سرور)](04-Enumerate_Applications_on_Webserver.md) 12 | 13 | 4.1.5 [Review Web Page Content for Information Leakage (بررسی محتوای صفحه وب برای نشت اطلاعات)](05-Review_Web_Page_Content_for_Information_Leakage.md) 14 | 15 | 4.1.6 [Identify Application Entry Points (شناسایی نقاط ورودی برنامه)](06-Identify_Application_Entry_Points.md) 16 | 17 | 4.1.7 [Map Execution Paths Through Application (مسیرهای اجرای نقشه از طریق برنامه)](07-Map_Execution_Paths_Through_Application.md) 18 | 19 | 4.1.8 [Fingerprint Web Application Framework (انگشت نگاری چارچوب برنامه وب)](08-Fingerprint_Web_Application_Framework.md) 20 | 21 | 4.1.9 [Fingerprint Web Application (انگشت نگاری برنامه وب)](09-Fingerprint_Web_Application.md) 22 | 23 | 4.1.10 [Map Application Architecture (معماری برنامه نقشه)](10-Map_Application_Architecture.md) 24 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README.md: -------------------------------------------------------------------------------- 1 | # 4.2 Configuration and Deployment Management Testing (fa-IR) 2 | 3 | آزمایش مدیریت پیکربندی و استقرار (فارسی) 4 | 5 | 4.2.1 [Test Network Infrastructure Configuration (آزمایش پیکربندی زیرساخت شبکه)](01-Test_Network_Infrastructure_Configuration.md) 6 | 7 | 4.2.2 [Test Application Platform Configuration (آزمایش پیکربندی پلتفرم برنامه)](02-Test_Application_Platform_Configuration.md) 8 | 9 | 4.2.3 [Test File Extensions Handling for Sensitive Information (آزمایش مدیریت پسوند فایل برای اطلاعات حساس)](03-Test_File_Extensions_Handling_for_Sensitive_Information.md) 10 | 11 | 4.2.4 [Review Old Backup and Unreferenced Files for Sensitive Information (مرور فایل های پشتیبان قدیمی و بدون مرجع برای اطلاعات حساس)](04-Review_Old_Backup_and_Unreferenced_Files_for_Sensitive_Information.md) 12 | 13 | 4.2.5 [Enumerate Infrastructure and Application Admin Interfaces (شمارش زیرساخت و رابط های مدیریت برنامه)](05-Enumerate_Infrastructure_and_Application_Admin_Interfaces.md) 14 | 15 | 4.2.6 [Test HTTP Methods ‫(آزمایش روش های HTTP)](06-Test_HTTP_Methods.md) 16 | 17 | 4.2.7 [Test HTTP Strict Transport Security ‫(آزمایش امنیت حمل و نقل سخت HTTP)](07-Test_HTTP_Strict_Transport_Security.md) 18 | 19 | 4.2.8 [Test RIA Cross Domain Policy ‫(آزمایش سیاست دامنه متقابل RIA)](08-Test_RIA_Cross_Domain_Policy.md) 20 | 21 | 4.2.9 [Test File Permission (آزمایش مجوز فایل)](09-Test_File_Permission.md) 22 | 23 | 4.2.10 [Test for Subdomain Takeover (آزمایش تصاحب زیردامنه)](10-Test_for_Subdomain_Takeover.md) 24 | 25 | 4.2.11 [Test Cloud Storage (آزمایش فضای ذخیره سازی ابری)](11-Test_Cloud_Storage.md) 26 | 27 | 4.2.12 [Test for Content Security Policy (آزمایش برای سیاست امنیت محتوا)](12-Test_for_Content_Security_Policy.md) 28 | 29 | 4.2.13 [Test for Path Confusion (آزمایش برای سردرگمی مسیر)](13-Test_for_Path_Confusion.md) 30 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/03-Identity_Management_Testing/03-Test_Account_Provisioning_Process.md: -------------------------------------------------------------------------------- 1 | # Test Account Provisioning Process (fa-IR) 2 | 3 | آزمایش فرآیند ارائه حساب (فارسی) 4 | 5 | |شناسه | 6 | |------------| 7 | |WSTG-IDNT-03| 8 | 9 | ## خلاصه 10 | 11 | ارائه حساب‌ها فرصتی را برای مهاجم فراهم می‌کند تا یک حساب معتبر بدون استفاده از فرآیند شناسایی و مجوز مناسب ایجاد کند. 12 | 13 | ## اهداف آزمایش 14 | 15 | - بررسی کنید که کدام حساب‌ها ممکن است حساب‌های دیگری و از چه نوع ارائه کنند. 16 | 17 | ## چگونه آزمایش کنیم 18 | 19 | تعیین کنید کدام نقش‌ها می‌توانند کاربران را ارائه (provision) کنند و چه نوع حساب‌هایی را می‌توانند ارائه کنند. 20 | 21 | - آیا تأیید، بررسی و تأیید درخواست‌های ارائه وجود دارد؟ 22 | - آیا هیچ گونه راستی آزمایی، بازرسی و مجوزی برای درخواست های عدم ارائه وجود دارد؟ 23 | - آیا یک مدیر می تواند مدیران دیگر یا فقط کاربران را ارائه کند؟ 24 | - آیا یک سرپرست یا سایر حساب‌های ارائه‌دهنده کاربر می‌تواند دارای امتیازات بیشتر از خود باشد؟ 25 | - آیا یک مدیر یا کاربر می تواند خود را حذف کند؟ 26 | - فایل ها یا منابع متعلق به کاربر حذف شده چگونه مدیریت می شوند؟ آیا آنها حذف شده اند؟ آیا دسترسی منتقل می شود؟ 27 | 28 | ### مثال (Example) 29 | 30 | در وردپرس، فقط نام کاربر و آدرس ایمیل برای ارائه کاربر مورد نیاز است، همانطور که در زیر نشان داده شده است: 31 | 32 | ![WordPress User Add](images/Wordpress_useradd.png)\ 33 | *شکل 1-4.3.3: افزودن کاربر وردپرس* 34 | 35 | عدم ارائه کاربران به مدیر نیاز دارد تا کاربرانی را که قرار است حذف شوند انتخاب کند، از منوی کشویی (دایره شده) گزینه Delete را انتخاب کند و سپس این عمل را اعمال کند. سپس یک کادر محاوره ای به مدیر نمایش داده می شود که از شما می پرسد با پست های کاربر چه کاری انجام دهید (آنها را حذف یا انتقال دهید). 36 | 37 | ![WordPress Auth and Users](images/Wordpress_authandusers.png)\ 38 | *شکل 2-4.3.3: اعتبار و کاربران وردپرس* 39 | 40 | ## ابزارها 41 | 42 | در حالی که کامل ترین و دقیق ترین رویکرد برای تکمیل این آزمایش، انجام آن به صورت دستی است، ابزار پروکسی HTTP نیز می تواند مفید باشد. 43 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/09-Test_File_Permission.md: -------------------------------------------------------------------------------- 1 | # Test File Permission (fa-IR) 2 | 3 | آزمایش مجوز فایل (فارسی) 4 | 5 | |شناسه | 6 | |------------| 7 | |WSTG-CONF-09| 8 | 9 | ## خلاصه 10 | 11 | هنگامی که به یک منبع تنظیمات مجوز داده می شود که دسترسی به طیف وسیع تری از بازیگران را نسبت به نیاز فراهم می کند، می تواند منجر به افشای اطلاعات حساس یا تغییر آن منبع توسط اشخاص ناخواسته شود. این امر به ویژه زمانی خطرناک است که منبع مربوط به پیکربندی برنامه، اجرا یا داده های حساس کاربر باشد. 12 | 13 | یک مثال واضح یک فایل اجرایی است که توسط کاربران غیرمجاز قابل اجرا است. برای مثال دیگر، اطلاعات حساب یا یک مقدار رمز برای دسترسی به یک API - که به طور فزاینده ای در سرویس های وب مدرن یا میکروسرویس ها دیده می شود - ممکن است در یک فایل پیکربندی ذخیره شود که مجوزهای آن به طور پیش فرض روی قابل خواندن جهانی (world-readable) از نصب تنظیم شده است. چنین داده‌های حساسی می‌توانند توسط عوامل مخرب داخلی میزبان یا توسط یک مهاجم از راه دور که سرویس را با آسیب‌پذیری‌های دیگر در معرض خطر قرار داده است، اما تنها یک امتیاز کاربر عادی را به دست آورده است، افشا شود. 14 | 15 | ## اهداف آزمایش 16 | 17 | - هر گونه مجوز فایل سرکش (rogue) را بررسی و شناسایی کنید. 18 | 19 | ## چگونه آزمایش کنیم 20 | 21 | در لینوکس، از دستور `ls` برای بررسی مجوزهای فایل استفاده کنید. متناوبا، `namei` همچنین می تواند برای فهرست کردن مجوزهای فایل به صورت بازگشتی استفاده شود. 22 | 23 | `$ namei -l /PathToCheck/` 24 | 25 | فایل‌ها و دایرکتوری‌هایی که نیاز به آزمایش مجوز فایل دارند شامل موارد زیر است اما محدود به آنها نیست: 26 | 27 | - فایل های وب / دایرکتوری 28 | - فایل های پیکربندی / دایرکتوری 29 | - فایل های حساس (داده های رمزگذاری شده، رمز عبور، کلید) / دایرکتوری 30 | - فایل‌های گزارش (گزارش‌های امنیتی، گزارش‌های عملیات، گزارش‌های مدیریت) / دایرکتوری 31 | - فایل های اجرایی (اسکریپت ها، EXE، JAR، کلاس، PHP، ASP) / دایرکتوری 32 | - فایل های پایگاه داده / دایرکتوری 33 | - فایل های موقت / دایرکتوری 34 | - آپلود فایل / دایرکتوری 35 | 36 | ## اصلاح 37 | 38 | مجوزهای فایل ها و دایرکتوری ها را به درستی تنظیم کنید تا کاربران غیرمجاز نتوانند بدون نیاز به منابع مهم دسترسی داشته باشند. 39 | 40 | ## ابزارها 41 | 42 | - [Windows AccessEnum](https://technet.microsoft.com/en-us/sysinternals/accessenum) 43 | - [Windows AccessChk](https://technet.microsoft.com/en-us/sysinternals/accesschk) 44 | - [Linux namei](https://linux.die.net/man/1/namei) 45 | 46 | ## منابع 47 | 48 | - [CWE-732: Incorrect Permission Assignment for Critical Resource](https://cwe.mitre.org/data/definitions/732.html) 49 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/03-Identity_Management_Testing/02-Test_User_Registration_Process.md: -------------------------------------------------------------------------------- 1 | # Test User Registration Process (fa-IR) 2 | 3 | آزمایش فرآیند ثبت نام کاربر (فارسی) 4 | 5 | |شناسه | 6 | |------------| 7 | |WSTG-IDNT-02| 8 | 9 | ## خلاصه 10 | 11 | برخی از وب‌سایت‌ها فرآیند ثبت نام کاربر را ارائه می‌کنند که دسترسی به سیستم را برای کاربران خودکار (یا نیمه خودکار) می‌کند. الزامات هویت برای دسترسی بسته به الزامات امنیتی سیستم، از شناسایی مثبت تا عدم وجود متفاوت است. بسیاری از برنامه های عمومی فرآیند ثبت نام و تهیه را کاملاً خودکار می کنند زیرا اندازه پایگاه کاربر مدیریت دستی را غیرممکن می کند. با این حال، بسیاری از برنامه های شرکتی کاربران را به صورت دستی ارائه می کنند، بنابراین این مورد آزمایشی ممکن است اعمال نشود. 12 | 13 | ## اهداف آزمایش 14 | 15 | - بررسی کنید که الزامات هویت برای ثبت نام کاربر با الزامات تجاری و امنیتی همسو باشد. 16 | - فرآیند ثبت نام را تایید کنید. 17 | 18 | ## چگونه آزمایش کنیم 19 | 20 | بررسی کنید که الزامات هویت برای ثبت نام کاربر با الزامات تجاری و امنیتی همسو باشد: 21 | 22 | 1. آیا کسی می تواند برای دسترسی ثبت نام کند؟ 23 | 2. آیا ثبت‌نام‌ها قبل از ارائه توسط یک انسان بررسی می‌شوند، یا در صورت رعایت معیارها، به‌طور خودکار اعطا می‌شوند؟ 24 | 3. آیا یک شخص یا هویت می تواند چندین بار ثبت نام کند؟ 25 | 4. آیا کاربران می توانند برای نقش ها یا مجوزهای مختلف ثبت نام کنند؟ 26 | 5. برای موفقیت در ثبت نام چه مدرک هویتی لازم است؟ 27 | 6. آیا هویت های ثبت شده تایید می شود؟ 28 | 29 | تایید فرآیند ثبت نام: 30 | 31 | 1. آیا اطلاعات هویتی به راحتی قابل جعل هستند؟ 32 | 2. آیا تبادل اطلاعات هویتی در حین ثبت نام قابل دستکاری است؟ 33 | 34 | ### مثال (Example) 35 | 36 | در مثال وردپرس زیر، تنها شرط شناسایی یک آدرس ایمیل است که برای ثبت نام کننده قابل دسترسی باشد. 37 | 38 | ![WordPress Registration Page](images/Wordpress_registration_page.jpg)\ 39 | *شکل 1-4.3.2: صفحه ثبت نام وردپرس* 40 | 41 | در مقابل، در مثال گوگل زیر، الزامات شناسایی شامل نام، تاریخ تولد، کشور، شماره تلفن همراه، آدرس ایمیل و پاسخ CAPTCHA است. در حالی که تنها دو مورد از این موارد (آدرس ایمیل و شماره موبایل) قابل تایید است، الزامات شناسایی سخت‌تر از وردپرس است. 42 | 43 | ![Google Registration Page](images/Google_registration_page.jpg)\ 44 | *شکل 2-4.3.2: صفحه ثبت نام گوگل* 45 | 46 | ## اصلاح 47 | 48 | الزامات شناسایی و تأیید را که با الزامات امنیتی اطلاعاتی که اعتبارنامه محافظت می کند مطابقت دارد، اجرا کنید. 49 | 50 | ## ابزارها 51 | 52 | یک پروکسی HTTP می تواند ابزار مفیدی برای آزمایش این کنترل باشد. 53 | 54 | ## منابع 55 | 56 | [User Registration Design](https://mashable.com/2011/06/09/user-registration-design/) 57 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/07-Test_HTTP_Strict_Transport_Security.md: -------------------------------------------------------------------------------- 1 | # Test HTTP Strict Transport Security (fa-IR) 2 | 3 | آزمایش امنیت حمل و نقل سخت HTTP (فارسی) 4 | 5 | |شناسه | 6 | |------------| 7 | |WSTG-CONF-07| 8 | 9 | ## خلاصه 10 | 11 | ویژگی HTTP Strict Transport Security (HSTS) به یک برنامه وب اجازه می دهد تا از طریق استفاده از سربرگ پاسخ ویژه به مرورگر اطلاع دهد که هرگز نباید با استفاده از HTTP رمزگذاری نشده با سرورهای دامنه مشخص شده ارتباط برقرار کند. در عوض، باید به طور خودکار تمام درخواست های اتصال را برای دسترسی به سایت از طریق HTTPS ایجاد کند. همچنین از نادیده گرفتن خطاهای گواهی توسط کاربران جلوگیری می کند. 12 | 13 | با توجه به اهمیت این اقدام امنیتی، عاقلانه است که بررسی شود که وب سایت از این هدر HTTP استفاده می کند تا اطمینان حاصل شود که همه داده ها به صورت رمزگذاری شده بین مرورگر وب و سرور جابجا می شوند. 14 | 15 | هدر امنیتی حمل و نقل سخت HTTP از دو دستورالعمل استفاده می کند: 16 | 17 | - ا `max-age`: برای نشان دادن تعداد ثانیه هایی که مرورگر باید به طور خودکار تمام درخواست های HTTP را به HTTPS تبدیل کند. 18 | - ا `includeSubDomains`: نشان می دهد که همه زیر دامنه های مرتبط باید از HTTPS استفاده کنند. 19 | - ا `preload` غیر رسمی: برای نشان دادن اینکه دامنه(ها) در لیست(های) پیش بارگذاری قرار دارند و مرورگرها هرگز نباید بدون HTTPS متصل شوند. 20 | - این توسط همه مرورگرهای اصلی پشتیبانی می شود اما بخشی رسمی از مشخصات نیست. (برای اطلاعات بیشتر به [hstspreload.org](https://hstspreload.org/) مراجعه کنید.) 21 | 22 | در اینجا مثالی از اجرای هدر HSTS آورده شده است: 23 | 24 | `Strict-Transport-Security: max-age=31536000; includeSubDomains` 25 | 26 | استفاده از این هدر توسط برنامه های وب باید بررسی شود تا مشخص شود که آیا می توان مشکلات امنیتی زیر را ایجاد کرد: 27 | 28 | - مهاجمان ترافیک شبکه را استشمام (sniffing) می کنند و به اطلاعات منتقل شده از طریق یک کانال رمزگذاری نشده دسترسی پیدا می کنند. 29 | - مهاجمان از یک دستکاری کننده در حمله میانی به دلیل مشکل پذیرش گواهینامه هایی که مورد اعتماد نیستند سوء استفاده می کنند. 30 | - کاربرانی که به اشتباه آدرسی را در مرورگر وارد کرده‌اند که HTTP را به جای HTTPS قرار می‌دهد، یا کاربرانی که روی پیوندی در یک برنامه وب کلیک می‌کنند که به اشتباه استفاده از پروتکل HTTP را نشان می‌دهد. 31 | 32 | ## اهداف آزمایش 33 | 34 | - هدر HSTS و اعتبار آن را بررسی کنید. 35 | 36 | ## چگونه آزمایش کنیم 37 | 38 | وجود هدر HSTS را می توان با بررسی پاسخ سرور از طریق یک پروکسی رهگیری یا با استفاده از curl به شرح زیر تأیید کرد: 39 | 40 | ```bash 41 | $ curl -s -D- https://owasp.org | grep -i strict 42 | Strict-Transport-Security: max-age=31536000 43 | ``` 44 | 45 | ## منابع 46 | 47 | - [OWASP HTTP Strict Transport Security](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) 48 | - [OWASP Appsec Tutorial Series - Episode 4: Strict Transport Security](https://www.youtube.com/watch?v=zEV3HOuM_Vw) 49 | - [HSTS Specification](https://tools.ietf.org/html/rfc6797) 50 | - [Enable HTTP Strict Transport Security In Apache](https://https.cio.gov/hsts/) 51 | - [Enable HTTP Strict Transport Security In Nginx](https://www.nginx.com/blog/http-strict-transport-security-hsts-and-nginx/) 52 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/13-Test_for_Path_Confusion.md: -------------------------------------------------------------------------------- 1 | # Test Path Confusion (fa-IR) 2 | 3 | آزمایش سردرگمی مسیر (فارسی) 4 | 5 | |شناسه | 6 | |------------| 7 | |WSTG-CONF-13| 8 | 9 | ## خلاصه 10 | 11 | پیکربندی مناسب مسیرهای برنامه مهم است زیرا، اگر مسیرها به درستی پیکربندی نشده باشند، به مهاجم اجازه می‌دهند تا با استفاده از این پیکربندی نادرست، از آسیب‌پذیری‌های دیگر در مراحل بعدی سوء استفاده کند. 12 | 13 | به عنوان مثال، اگر مسیرها به درستی پیکربندی نشده باشند و هدف نیز از CDN استفاده کند، مهاجم می تواند از این پیکربندی نادرست برای اجرای حملات فریب کش وب (Web Cache Deception) استفاده کند. 14 | 15 | در نتیجه، برای جلوگیری از حملات دیگر، این پیکربندی باید توسط آزمایش کننده ارزیابی شود. 16 | 17 | ## اهداف آزمایش 18 | 19 | - مطمئن شوید که مسیرهای برنامه به درستی پیکربندی شده اند. 20 | 21 | ## چگونه آزمایش کنیم 22 | 23 | ### آزمایش جعبه سیاه (Black-Box Testing) 24 | 25 | در سناریوی آزمایش جعبه سیاه، آزمایش کننده باید تمام مسیرهای موجود را با مسیرهایی که وجود ندارند جایگزین کند و سپس رفتار و کد وضعیت هدف را بررسی کند. 26 | 27 | به عنوان مثال، مسیری در برنامه وجود دارد که داشبورد است و میزان موجودی حساب کاربر (پول، اعتبار بازی و غیره) را نشان می دهد. 28 | 29 | فرض کنید مسیر این است `https://example.com/user/dashboard`، آزمایش‌کننده باید حالت‌های مختلفی را که توسعه‌دهنده ممکن است برای این مسیر در نظر گرفته باشد، آزمایش کند. برای آسیب‌پذیری‌های فریب کش وب (Web Cache Deception)، تحلیلگر باید مسیری را در نظر بگیرد، مثلاً `https:// example.com/user/dashboard/non.js` اگر اطلاعات داشبورد قابل مشاهده است، و هدف از CDN (یا حافظه پنهان وب دیگر) استفاده می‌کند، سپس حملات فریب کش وب احتمالاً قابل اجرا هستند. 30 | 31 | ### آزمایش جعبه سفید (White-Box Testing) 32 | 33 | پیکربندی مسیریابی برنامه را بررسی کنید، بیشتر اوقات، توسعه دهندگان از عبارات منظم در مسیریابی برنامه استفاده می کنند. 34 | 35 | در این مثال، در فایل `urls.py` یک برنامه فریمورک جنگو، نمونه ای از سردرگمی مسیر (Path Confusion) را مشاهده می کنیم. توسعه دهنده از عبارت منظم درست استفاده نکرده است که منجر به آسیب پذیری می شود: 36 | 37 | ```python 38 | from django.urls import re_path 39 | from . import views 40 | 41 | urlpatterns = [ 42 | 43 | re_path(r'.*^dashboard', views.path_confusion ,name = 'index'), 44 | 45 | ] 46 | ``` 47 | 48 | اگر مسیر `https://example.com/dashboard/none.js` توسط کاربر در مرورگر نیز باز شود، اطلاعات داشبورد کاربر را می توان نمایش داد و اگر هدف از CDN یا کش وب استفاده کند، یک حمله فریب کش وب را می توان پیاده سازی کرد. 49 | 50 | ## ابزارها 51 | 52 | - [OWASP Zed Attack Proxy](https://www.zaproxy.org) 53 | - [Burp Suite](https://portswigger.net/burp) 54 | 55 | ## اصلاح 56 | 57 | - از طبقه‌بندی/مدیریت حافظه پنهان بر اساس پسوند یا مسیر فایل (نوع محتوای اهرمی) خودداری کنید. 58 | - اطمینان حاصل کنید که مکانیسم(های) کش به سربرگ های کنترل حافظه پنهان مشخص شده توسط برنامه شما پایبند هستند. 59 | - مدیریت و تغییر مسیرهای فایل Not Found سازگار با RFC را اجرا کنید. 60 | 61 | ## منابع 62 | 63 | - [Bypassing Web Cache Poisoning Countermeasures](https://portswigger.net/research/bypassing-web-cache-poisoning-countermeasures) 64 | - [Path confusion: Web cache deception threatens user information online](https://portswigger.net/daily-swig/path-confusion-web-cache-deception-threatens-user-information-online) 65 | - [Web Cache Deception Attack](https://omergil.blogspot.com/2017/02/web-cache-deception-attack.html) 66 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/01-Information_Gathering/07-Map_Execution_Paths_Through_Application.md: -------------------------------------------------------------------------------- 1 | # Map Execution Paths Through Application (fa-IR) 2 | 3 | مسیرهای اجرای نقشه از طریق برنامه (فارسی) 4 | 5 | |شناسه | 6 | |------------| 7 | |WSTG-INFO-07| 8 | 9 | ## خلاصه 10 | 11 | قبل از شروع آزمایش امنیتی، درک ساختار برنامه بسیار مهم است. بدون درک کامل از چیدمان برنامه، بعید است که به طور کامل آزمایش شود. 12 | 13 | ## اهداف آزمایش 14 | 15 | - برنامه مورد نظر را نقشه برداری کنید و گردش کار اصلی را درک کنید. 16 | 17 | ## چگونه آزمایش کنیم 18 | 19 | در آزمایش جعبه سیاه، آزمایش کل پایگاه کد بسیار دشوار است. نه فقط به این دلیل که آزمایش کننده هیچ دیدی از مسیرهای کد از طریق برنامه ندارد، بلکه حتی در صورت مشاهده، آزمایش همه مسیرهای کد بسیار زمان بر خواهد بود. یکی از راه های تطبیق این موضوع، مستندسازی مسیرهای کد کشف و آزمایش شده است. 20 | 21 | روش های مختلفی برای نزدیک شدن به آزمایش و اندازه گیری پوشش کد وجود دارد: 22 | 23 | - **مسیر (Path)** - هر یک از مسیرها را از طریق یک برنامه که شامل آزمایش تجزیه و تحلیل ارزش ترکیبی و مرزی برای هر مسیر تصمیم گیری است، آزمایش کنید. در حالی که این رویکرد دقت را ارائه می دهد، تعداد مسیرهای قابل آزمایش با هر شاخه تصمیم گیری به طور تصاعدی افزایش می یابد. 24 | - **جریان داده (یا تجزیه و تحلیل لکه دار) (Data Flow (or Taint Analysis))** - تخصیص متغیرها را از طریق تعامل خارجی (معمولاً کاربران) آزمایش می کند. بر روی نقشه برداری از جریان، تبدیل و استفاده از داده ها در سراسر یک برنامه تمرکز دارد. 25 | - **نژاد (Race)** - چندین نمونه از برنامه را همزمان آزمایش می کند که داده های مشابه را دستکاری می کند. 26 | 27 | مبادله در مورد اینکه چه روشی استفاده می شود و هر روشی تا چه حد استفاده می شود باید با مالک برنامه مذاکره شود. همچنین می توان رویکردهای ساده تری را اتخاذ کرد، از جمله پرسیدن از مالک برنامه ای که به خصوص در مورد چه توابع یا بخش های کدی نگران هستند و چگونه می توان به آن بخش های کد دسترسی پیدا کرد. 28 | 29 | برای نشان دادن پوشش کد به مالک برنامه، آزمایش کننده می تواند با یک صفحه گسترده شروع کند و همه پیوندهای کشف شده با عنکبوت کردن (spidering) برنامه (به صورت دستی یا خودکار) را مستند کند. سپس آزمایش کننده می تواند با دقت بیشتری به نقاط تصمیم در برنامه نگاه کند و بررسی کند که چه تعداد مسیر کد قابل توجهی کشف شده است. سپس این موارد باید در صفحه گسترده با نشانی های اینترنتی، نثر و توضیحات تصویری از مسیرهای کشف شده مستند شوند. 30 | 31 | ### اسپایدرینگ (عنکبوت کردن) خودکار (Automatic Spidering) 32 | 33 | عنکبوت خودکار ابزاری است که برای کشف خودکار منابع جدید (URL) در یک وب سایت خاص استفاده می شود. این فهرست با لیستی از URL های مورد بازدید به نام seed شروع می شود که بستگی به نحوه راه اندازی عنکبوت دارد. در حالی که ابزارهای اسپایدرینگ زیادی وجود دارد، مثال زیر از [Zed Attack Proxy (ZAP)](https://github.com/zaproxy/zaproxy) استفاده می کند: 34 | 35 | ![Zed Attack Proxy Screen](images/OWASPZAPSP.png)\ 36 | *شکل 1-4.1.7: صفحه پراکسی حمله Zed* 37 | 38 | ا ZAP گزینه های اسپایدرینگ خودکار مختلفی را ارائه می دهد که می تواند بر اساس نیازهای آزمایش کننده مورد استفاده قرار گیرد: 39 | 40 | - عنکبوت ([Spider](https://www.zaproxy.org/docs/desktop/start/features/spider/)) 41 | - عنکبوت AJAX ‫([AJAX Spider](https://www.zaproxy.org/docs/desktop/addons/ajax-spider/)) 42 | - پشتیبانی OpenAPI ‫([OpenAPI Support](https://www.zaproxy.org/docs/desktop/addons/openapi-support/)) 43 | 44 | ## ابزارها 45 | 46 | - [Zed Attack Proxy (ZAP)](https://github.com/zaproxy/zaproxy) 47 | - [List of spreadsheet software](https://en.wikipedia.org/wiki/List_of_spreadsheet_software) 48 | - [Diagramming software](https://en.wikipedia.org/wiki/List_of_concept-_and_mind-mapping_software) 49 | 50 | ## منابع 51 | 52 | - [Code Coverage](https://en.wikipedia.org/wiki/Code_coverage) 53 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/03-Identity_Management_Testing/01-Test_Role_Definitions.md: -------------------------------------------------------------------------------- 1 | # Test Role Definitions (fa-IR) 2 | 3 | آزمایش تعاریف نقش (فارسی) 4 | 5 | |شناسه | 6 | |------------| 7 | |WSTG-IDNT-01| 8 | 9 | ## خلاصه 10 | 11 | برنامه ها انواع مختلفی از عملکردها و خدمات دارند و آن ها بر اساس نیاز کاربر به مجوزهای دسترسی نیاز دارند. آن کاربر می تواند: 12 | 13 | - یک مدیر (administrator)، جایی که آنها عملکردهای برنامه را مدیریت می کنند. 14 | - یک حسابرس (auditor)، جایی که آنها معاملات برنامه را بررسی می کنند و گزارش مفصلی ارائه می دهند. 15 | - یک مهندس پشتیبانی (support engineer)، جایی که آنها به مشتریان کمک می کنند تا اشکالات را در حساب های خود رفع کنند. 16 | - یک مشتری (customer)، جایی که آنها با برنامه در تعامل هستند و از خدمات آن بهره مند می شوند. 17 | 18 | به منظور رسیدگی به این کاربردها و هر مورد دیگر برای آن برنامه، تعاریف نقش تنظیم شده است (که بیشتر به عنوان [RBAC](https://en.wikipedia.org/wiki/Role-based_access_control) شناخته می شود). بر اساس این نقش ها، کاربر قادر به انجام وظیفه مورد نیاز است. 19 | 20 | ## اهداف آزمایش 21 | 22 | - نقش های استفاده شده توسط برنامه را شناسایی و مستند کنید. 23 | - برای جابجایی، تغییر یا دسترسی به نقش دیگری تلاش کنید. 24 | - جزئیات نقش ها و نیازهای پشت مجوزهای داده شده را بررسی کنید. 25 | 26 | ## چگونه آزمایش کنیم 27 | 28 | ### شناسایی نقش ها (Roles Identification) 29 | 30 | آزمایش‌کننده باید با شناسایی نقش‌های برنامه در حال آزمایش از طریق یکی از روش‌های زیر شروع کند: 31 | 32 | - مستندات برنامه. 33 | - راهنمایی توسط توسعه دهندگان یا مدیران برنامه. 34 | - کامنت های (نظرات) برنامه. 35 | - نقش های احتمالی Fuzz: 36 | - متغیر کوکی (مثلاً `role=admin` ،`isAdmin=True`) 37 | - متغیر حساب (مثلاً `Role: manager`) 38 | - دایرکتوری ها یا فایل های مخفی (مثلاً `admin`، `/mod`، `/backups/`) 39 | - جابجایی به کاربران شناخته شده (مثلاً `admin`، `backups` و غیره) 40 | 41 | ### جابجایی به نقش های موجود (Switching to Available Roles) 42 | 43 | پس از شناسایی بردارهای حمله احتمالی، آزمایش کننده باید آزمایش و اعتبارسنجی کند که می تواند به نقش های موجود دسترسی داشته باشد. 44 | 45 | > برخی از برنامه‌ها نقش‌های کاربر را هنگام ایجاد، از طریق بررسی‌ها و سیاست‌های دقیق، یا با اطمینان از اینکه نقش کاربر به درستی از طریق امضای ایجاد شده توسط backend محافظت می‌شود، تعریف می‌کنند. یافتن اینکه نقش ها وجود دارند به این معنی نیست که آنها یک آسیب پذیری هستند. 46 | 47 | ### بررسی مجوزهای نقش (Review Roles Permissions) 48 | 49 | پس از دسترسی به نقش های موجود در سیستم، آزمایش کننده باید مجوزهای ارائه شده برای هر نقش را درک کند. 50 | 51 | یک مهندس پشتیبانی نباید بتواند عملکردهای اداری را انجام دهد، پشتیبان‌گیری‌ها را مدیریت کند یا تراکنش‌هایی را به جای کاربر انجام دهد. 52 | 53 | یک مدیر نباید قدرت کامل روی سیستم داشته باشد. عملکرد حساس ادمین باید از یک اصل چک‌کننده سازنده استفاده کند یا از MFA برای اطمینان از انجام تراکنش توسط مدیر استفاده کند. یک مثال واضح در این مورد [حادثه توییتر در سال 2020](https://blog.twitter.com/en_us/topics/company/2020/an-update-on-our-security-incident.html) بود. 54 | 55 | ## ابزارها 56 | 57 | آزمایش های فوق را می توان بدون استفاده از هیچ ابزاری به جز ابزاری که برای دسترسی به سیستم استفاده می شود انجام داد. 58 | 59 | برای ساده تر و مستندتر کردن کارها، می توان از موارد زیر استفاده کرد: 60 | 61 | - [Burp's Autorize extension](https://github.com/Quitten/Autorize) 62 | - [ZAP's Access Control Testing add-on](https://www.zaproxy.org/docs/desktop/addons/access-control-testing/) 63 | 64 | ## منابع 65 | 66 | - [Role Engineering for Enterprise Security Management, E Coyne & J Davis, 2007](https://www.bookdepository.co.uk/Role-Engineering-for-Enterprise-Security-Management-Edward-Coyne/9781596932180) 67 | - [Role engineering and RBAC standards](https://csrc.nist.gov/projects/role-based-access-control#rbac-standard) 68 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/12-Test_for_Content_Security_Policy.md: -------------------------------------------------------------------------------- 1 | # Testing for Content Security Policy (fa-IR) 2 | 3 | آزمایش برای سیاست امنیت محتوا (فارسی) 4 | 5 | |شناسه | 6 | |------------| 7 | |WSTG-CONF-12| 8 | 9 | ## خلاصه 10 | 11 | سیاست (خط‌مشی) امنیت محتوا (CSP) یک خط‌مشی فهرست مجاز اعلامی است که از طریق سرصفحه پاسخ `Content-Security-Policy` یا عنصر `` معادل آن اعمال می‌شود. این به توسعه دهندگان اجازه می دهد تا منابعی را که از آنها منابعی مانند جاوا اسکریپت، CSS، تصاویر، فایل ها و غیره بارگیری می شوند، محدود کنند. CSP یک تکنیک دفاعی موثر برای کاهش خطر آسیب‌پذیری‌هایی مانند Cross Site Scripting (XSS) و Clickjacking است. 12 | 13 | سیاست امنیت محتوا از دستورالعمل‌هایی پشتیبانی می‌کند که اجازه می‌دهد تا جریان سیاست‌ها را کنترل کند. ( برای جزئیات بیشتر به [منابع](#منابع) مراجعه کنید.) 14 | 15 | ## اهداف آزمایش 16 | 17 | - برای شناسایی پیکربندی‌های نادرست، سربرگ Content-Security-Policy یا متا را مرور کنید. 18 | 19 | ## چگونه آزمایش کنیم 20 | 21 | برای آزمایش پیکربندی نادرست در CSP، با بررسی سرصفحه پاسخ HTTP ا `Content-Security-Policy` یا عنصر CSP ا `meta` در یک ابزار پراکسی، به دنبال تنظیمات ناامن باشید: 22 | 23 | - دستورالعمل `unsafe-inline` اسکریپت ها یا استایل های درون خطی را فعال می کند که برنامه ها را مستعد حملات XSS می کند. 24 | - دستورالعمل `unsafe-eval` اجازه می دهد تا `()eval` در برنامه استفاده شود. 25 | - دستورالعمل `unsafe-hashes` استفاده از اسکریپت ها/سبک های درون خطی را با فرض مطابقت با هش های (hashes) مشخص شده امکان پذیر می کند. 26 | - منابعی مانند اسکریپت ها را می توان از هر مبدا ای با استفاده از منبع عام (`*`) بارگیری (لود) کرد. 27 | - همچنین حروف عام را بر اساس مطابقت های جزئی در نظر بگیرید، مانند: `*//:https` یا `cdn.com.*`. 28 | - در نظر بگیرید که آیا منابع فهرست شده مجاز، نقاط پایانی JSONP را ارائه می دهند که ممکن است برای دور زدن CSP یا سیاست همان مبدا استفاده شوند. 29 | - کادربندی را می توان برای همه مبداها با استفاده از منبع عام (`*`) برای دستورالعمل `frame-ancestors` فعال کرد. 30 | - برنامه های حیاتی تجاری باید به استفاده از یک سیاست سختگیرانه نیاز داشته باشند. 31 | 32 | ## اصلاح 33 | 34 | یک سیاست امنیتی محتوای قوی را پیکربندی کنید که سطح حمله برنامه را کاهش دهد. توسعه دهندگان می توانند با استفاده از ابزارهای آنلاین مانند [Google CSP Evaluator](https://csp-evaluator.withgoogle.com/)، قدرت سیاست امنیت محتوا را تأیید کنند. 35 | 36 | ### سیاست سختگیرانه (Strict Policy) 37 | 38 | سیاست سختگیرانه سیاستی است که در برابر حملات کلاسیک ذخیره شده، منعکس شده و برخی از حملات DOM XSS محافظت می کند و باید هدف بهینه هر تیمی باشد که سعی در پیاده سازی CSP دارد. 39 | 40 | گوگل پیش رفت و یک راهنمای برای اتخاذ یک CSP سختگیرانه بر اساس nonces تنظیم کرد. بر اساس یک ارائه در [LocoMocoSec](https://speakerdeck.com/lweichselbaum/csp-a-successful-mess-between-hardening-and-mitigation?slide=55)، دو سیاست زیر را می توان برای اعمال یک سیاست سخت استفاده کرد: 41 | 42 | سیاست سختگیرانه متوسط: 43 | 44 | ```HTTP 45 | script-src 'nonce-r4nd0m' 'strict-dynamic'; 46 | object-src 'none'; base-uri 'none'; 47 | ``` 48 | 49 | سیاست سختگیرانه قفل شده: 50 | 51 | ```HTTP 52 | script-src 'nonce-r4nd0m'; 53 | object-src 'none'; base-uri 'none'; 54 | ``` 55 | 56 | ## ابزارها 57 | 58 | - [Google CSP Evaluator](https://csp-evaluator.withgoogle.com/) 59 | - [CSP Auditor - Burp Suite Extension](https://portswigger.net/bappstore/35237408a06043e9945a11016fcbac18) 60 | - [CSP Generator Chrome](https://chrome.google.com/webstore/detail/content-security-policy-c/ahlnecfloencbkpfnpljbojmjkfgnmdc) / [Firefox](https://addons.mozilla.org/en-US/firefox/addon/csp-generator/) 61 | 62 | ## منابع 63 | 64 | - [OWASP Content Security Policy Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html) 65 | - [Mozilla Developer Network: Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) 66 | - [CSP Level 3 W3C](https://www.w3.org/TR/CSP3/) 67 | - [CSP with Google](https://csp.withgoogle.com/docs/index.html) 68 | - [Content-Security-Policy](https://content-security-policy.com/) 69 | - [Google CSP Evaluator](https://csp-evaluator.withgoogle.com/) 70 | - [CSP A Successful Mess Between Hardening And Mitigation](https://speakerdeck.com/lweichselbaum/csp-a-successful-mess-between-hardening-and-mitigation) 71 | - [The unsafe-hashes Source List Keyword](https://content-security-policy.com/unsafe-hashes/) 72 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/00-Introduction_and_Objectives/README.md: -------------------------------------------------------------------------------- 1 | # 4.0 Introduction and Objectives (fa-IR) 2 | 3 | مقدمه و اهداف (فارسی) 4 | 5 | این بخش روش آزمایش امنیت برنامه وب OWASP را شرح می دهد و نحوه آزمایش شواهد آسیب پذیری در برنامه را به دلیل نقص در کنترل های امنیتی شناسایی شده توضیح می دهد. 6 | 7 | ## آزمایش امنیت برنامه وب چیست؟ 8 | 9 | آزمایش امنیت روشی برای ارزیابی امنیت یک سیستم یا شبکه کامپیوتری از طریق اعتبارسنجی روشمند و تایید اثربخشی کنترل های امنیتی برنامه است. آزمایش امنیت برنامه وب فقط بر ارزیابی امنیت یک برنامه وب متمرکز است. این فرآیند شامل تجزیه و تحلیل فعال برنامه برای هر گونه ضعف، نقص فنی یا آسیب پذیری است. هرگونه مشکل امنیتی که پیدا شود، پیشنهادی برای کاهش یا راه حل فنی به مالک سیستم به همراه ارزیابی تأثیر ارائه می شود. 10 | 11 | ## آسیب پذیری چیست؟ 12 | 13 | آسیب پذیری یک نقص یا ضعف در طراحی، پیاده سازی، عملیات یا مدیریت یک سیستم است که می تواند برای به خطر انداختن اهداف امنیتی سیستم مورد سوء استفاده قرار گیرد. 14 | 15 | ## تهدید چیست؟ 16 | 17 | تهدید می توانید هر چیزی باشد (یک مهاجم خارجی مخرب، یک کاربر داخلی، یک ناپایداری سیستم و...) که ممکن است با سوء استفاده از یک آسیب پذیری، به دارایی های متعلق به یک برنامه (منابع با ارزش، مانند داده ها در پایگاه داده یا سیستم فایل) آسیب برساند. 18 | 19 | ## آزمایش (تست) چیست؟ 20 | 21 | آزمایش عملی است برای نشان دادن اینکه یک برنامه الزامات امنیتی ذینفعان خود را برآورده می کند. 22 | 23 | ## رویکرد در نگارش این راهنما 24 | 25 | رویکرد OWASP باز و مشارکتی است: 26 | 27 | - باز: هر متخصص امنیتی می تواند با تجربه خود در پروژه شرکت کند. همه چیز رایگان است. 28 | - مشارکتی: طوفان فکری قبل از نوشته شدن مقالات انجام می شود تا تیم بتواند ایده ها را به اشتراک بگذارد و دید جمعی از پروژه ایجاد کند. این به معنای اجماع، مخاطب گسترده تر و افزایش مشارکت است. 29 | 30 | این رویکرد منجر به یک روش آزمایش تعریف شده می شود که به شرح زیر است: 31 | 32 | - استوار 33 | - قابل تکرار 34 | - سختگیرانه 35 | - تحت کنترل کیفیت 36 | 37 | مشکلاتی که باید به آنها رسیدگی شود کاملاً مستند و آزمایش شده است. استفاده از روش های مختلف برای آزمایش تمام آسیب پذیری های شناخته شده و مستندسازی تمام فعالیت های آزمایش امنیتی مهم است. 38 | 39 | ## روش آزمایش OWASP چیست؟ 40 | 41 | آزمایش امنیت هرگز علمی دقیق نخواهد بود که در آن لیست کاملی از تمام مسائل احتمالی که باید آزمایش شوند را بتوان تعریف کرد. در واقع، آزمایش امنیت تنها یکی از چندین تکنیک مناسب برای آزمایش امنیت برنامه های وب تحت شرایط خاص است. هدف این پروژه جمع آوری تمام تکنیک های آزمایش ممکن، توضیح این تکنیک ها و به روز نگه داشتن راهنما است. روش آزمایش امنیت برنامه وب OWASP مبتنی بر رویکرد جعبه سیاه است. آزمایش کننده اطلاعات کمی در مورد برنامه ای که باید آزمایش شود دارد. 42 | 43 | مدل آزمایش شامل موارد زیر است: 44 | 45 | - آزمایش کننده (تستر): کسی که فعالیت های آزمایشی را انجام می دهد 46 | - ابزار و روش: هسته اصلی این پروژه راهنما 47 | - برنامه: جعبه سیاه برای آزمایش 48 | 49 | آزمایش را می توان به عنوان غیرفعال یا فعال دسته بندی کرد: 50 | 51 | ### آزمایش غیر فعال (پسیو) 52 | 53 | در طول آزمایش غیرفعال، یک آزمایش کننده سعی می کند منطق برنامه را بفهمد و برنامه را به عنوان یک کاربر نهایی بررسی کند. می توان از ابزارها برای جمع آوری اطلاعات استفاده کرد. به عنوان مثال، یک پروکسی HTTP(S) می تواند برای مشاهده تمام درخواست ها و پاسخ های HTTP(S) استفاده شود. در پایان این مرحله، آزمایش کننده باید به طور کلی تمام نقاط دسترسی و عملکرد سیستم (مانند سرصفحه های HTTP، پارامترها، کوکی ها، APIها، استفاده از فناوری/الگوها و...) را درک کند. بخش [Information Gathering](../01-Information_Gathering/README.md) (جمع آوری اطلاعات) نحوه انجام آزمایش غیرفعال را توضیح می دهد. 54 | 55 | برای مثال، یک آزمایش کننده ممکن است صفحه ای را در URL زیر پیدا کند: 56 | 57 | `https://www.example.com/login/auth_form` 58 | 59 | این ممکن است یک فرم احراز هویت را نشان دهد که در آن برنامه یک نام کاربری و رمز عبور درخواست می کند. 60 | 61 | پارامترهای زیر دو نقطه دسترسی به برنامه را نشان می دهند: 62 | 63 | `https://www.example.com/appx?a=1&b=1` 64 | 65 | در این مورد، برنامه دارای دو نقطه دسترسی (پارامترهای `a` و `b`) است. تمام نقاط ورودی یافت شده در این مرحله نشان دهنده اهدافی برای آزمایش هستند. پیگیری دایرکتوری یا درخت تماس (call tree) برنامه و تمام نقاط دسترسی می تواند در طول آزمایش فعال مفید باشد. 66 | 67 | ### آزمایش فعال (اکتیو) 68 | 69 | در طول آزمایش فعال، یک آزمایش کننده از روش هایی استفاده می کند که در بخش های زیر توضیح داده شده است 70 | 71 | مجموعه آزمایش های فعال به 12 دسته تقسیم شده است: 72 | 73 | - جمع آوری اطلاعات (Information Gathering) 74 | - آزمایش مدیریت پیکربندی و استقرار (Configuration and Deployment Management Testing) 75 | - آزمایش مدیریت هویت (Identity Management Testing) 76 | - آزمایش احراز هویت (Authentication Testing) 77 | - آزمایش مجوز (Authorization Testing) 78 | - آزمایش مدیریت جلسه (Session Management Testing) 79 | - آزمایش اعتبار سنجی ورودی (Input Validation Testing) 80 | - آزمایش رسیدگی به خطا (Testing for Error Handling) 81 | - آزمایش رمزنگاری ضعیف (Testing for Weak Cryptography) 82 | - آزمایش منطق کسب و کار (Business Logic Testing) 83 | - آزمایش سمت مشتری (Client-side Testing) 84 | - آزمایش API (‫API Testing) 85 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/11-Test_Cloud_Storage.md: -------------------------------------------------------------------------------- 1 | # Test Cloud Storage (fa-IR) 2 | 3 | آزمایش فضای ذخیره سازی ابری (فارسی) 4 | 5 | |شناسه | 6 | |------------| 7 | |WSTG-CONF-11| 8 | 9 | ## خلاصه 10 | 11 | سرویس‌های ذخیره‌سازی ابری برنامه‌ها و سرویس‌های وب را برای ذخیره و دسترسی به اشیاء در سرویس ذخیره‌سازی تسهیل می‌کنند. با این حال، پیکربندی نادرست کنترل دسترسی ممکن است منجر به قرار گرفتن در معرض اطلاعات حساس، دستکاری داده ها یا دسترسی غیرمجاز شود. 12 | 13 | یک مثال شناخته شده جایی است که یک سطل S3 آمازون (Amazon S3 bucket) به اشتباه پیکربندی شده است، اگرچه سایر سرویس های ذخیره سازی ابری نیز ممکن است در معرض خطرات مشابهی باشند. به‌طور پیش‌فرض، تمام سطل‌های S3 خصوصی هستند و فقط برای کاربرانی که صراحتاً به آنها اجازه دسترسی داده شده است، می‌توان به آنها دسترسی داشت. کاربران می توانند هم به خود سطل و هم به اشیاء جداگانه ذخیره شده در آن سطل دسترسی عمومی بدهند. این ممکن است منجر به این شود که یک کاربر غیرمجاز بتواند فایل‌های جدید را آپلود کند، فایل‌های ذخیره شده را تغییر دهد یا بخواند. 14 | 15 | ## اهداف آزمایش 16 | 17 | - ارزیابی کنید که پیکربندی کنترل دسترسی برای سرویس‌های ذخیره‌سازی به درستی در جای خود قرار دارد. 18 | 19 | ## چگونه آزمایش کنیم 20 | 21 | ابتدا URL را برای دسترسی به داده ها در سرویس ذخیره سازی شناسایی کنید و سپس آزمایش های زیر را در نظر بگیرید: 22 | 23 | - داده های غیرمجاز را بخوانید 24 | - یک فایل دلخواه جدید آپلود کنید 25 | 26 | می‌توانید از curl برای آزمایش‌ها با دستورات زیر استفاده کنید و ببینید آیا اقدامات غیرمجاز را می‌توان با موفقیت انجام داد. 27 | 28 | برای آزمایش توانایی خواندن یک شی: 29 | 30 | ```bash 31 | curl -X GET https:/// 32 | ``` 33 | 34 | برای آزمایش توانایی آپلود فایل: 35 | 36 | ```bash 37 | curl -X PUT -d 'test' 'https:///test.txt' 38 | ``` 39 | 40 | ### آزمایش پیکربندی نادرست سطل S3 آمازون (Testing for Amazon S3 Bucket Misconfiguration) 41 | 42 | ا URL های سطل S3 آمازون از یکی از دو فرمت پیروی می کنند، یا سبک میزبان مجازی (virtual host style) یا سبک مسیر (path-style). 43 | 44 | - دسترسی به سبک میزبانی مجازی 45 | 46 | ```text 47 | https://bucket-name.s3.Region.amazonaws.com/key-name 48 | ``` 49 | 50 | در مثال زیر، `my-bucket` نام سطل، `us-west-2` منطقه، و `puppy.png` نام کلید است: 51 | 52 | ```text 53 | https://my-bucket.s3.us-west-2.amazonaws.com/puppy.png 54 | ``` 55 | 56 | - دسترسی به سبک مسیر 57 | 58 | ```text 59 | https://s3.Region.amazonaws.com/bucket-name/key-name 60 | ``` 61 | 62 | مانند بالا، در مثال زیر، `my-bucket` نام سطل، `us-west-2` منطقه و `puppy.png` نام کلید است: 63 | 64 | ```text 65 | https://s3.us-west-2.amazonaws.com/my-bucket/puppy.jpg 66 | ``` 67 | 68 | برای برخی از مناطق، نقطه پایانی جهانی قدیمی که یک نقطه پایانی خاص منطقه را مشخص نمی کند، می تواند استفاده شود. فرمت آن نیز به سبک میزبانی مجازی یا به سبک مسیر است. 69 | 70 | - دسترسی به سبک میزبانی مجازی 71 | 72 | ```text 73 | https://bucket-name.s3.amazonaws.com 74 | ``` 75 | 76 | - دسترسی به سبک مسیر 77 | 78 | ```text 79 | https://s3.amazonaws.com/bucket-name 80 | ``` 81 | 82 | ####
URL سطل را شناسایی کنید (Identify Bucket URL)
83 | 84 | برای آزمایش جعبه سیاه، URL های S3 را می توان در پیام های HTTP یافت. مثال زیر نشان می دهد که یک URL سطلی در تگ `img` در یک پاسخ HTTP ارسال شده است. 85 | 86 | ```html 87 | ... 88 | 89 | ... 90 | ``` 91 | 92 | برای آزمایش جعبه خاکستری، می توانید URL های سطلی را از رابط وب آمازون، اسناد، کد منبع یا هر منبع موجود دیگری دریافت کنید. 93 | 94 | #### آزمایش با AWS-CLI ‫(Testing with AWS-CLI) 95 | 96 | علاوه بر آزمایش با curl، می توانید با ابزار خط فرمان AWS نیز آزمایش کنید. در این مورد از پروتکل `//:s3` استفاده می شود. 97 | 98 | ##### فهرست (List) 99 | 100 | دستور زیر تمام اشیاء سطل را هنگامی که به صورت عمومی پیکربندی می شود فهرست می کند. 101 | 102 | ```bash 103 | aws s3 ls s3:// 104 | ``` 105 | 106 | ##### بارگذاری (Upload) 107 | 108 | دستور زیر برای بارگذاری (آپلود) یک فایل است 109 | 110 | ```bash 111 | aws s3 cp arbitrary-file s3://bucket-name/path-to-save 112 | ``` 113 | 114 | این مثال زمانی که آپلود با موفقیت انجام شده است نتیجه را نشان می دهد. 115 | 116 | ```bash 117 | $ aws s3 cp test.txt s3://bucket-name/test.txt 118 | upload: ./test.txt to s3://bucket-name/test.txt 119 | ``` 120 | 121 | این مثال نتیجه را هنگامی که آپلود ناموفق است نشان می دهد. 122 | 123 | ```bash 124 | $ aws s3 cp test.txt s3://bucket-name/test.txt 125 | upload failed: ./test2.txt to s3://bucket-name/test2.txt An error occurred (AccessDenied) when calling the PutObject operation: Access Denied 126 | ``` 127 | 128 | ##### برداشتن (حذف کردن) (Remove) 129 | 130 | دستور زیر برای حذف یک شی است 131 | 132 | ```bash 133 | aws s3 rm s3://bucket-name/object-to-remove 134 | ``` 135 | 136 | ## ابزارها 137 | 138 | - [AWS CLI](https://aws.amazon.com/cli/) 139 | 140 | ## منابع 141 | 142 | - [Working with Amazon S3 Buckets](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingBucket.html) 143 | - [flAWS 2](http://flaws2.cloud) 144 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/05-Enumerate_Infrastructure_and_Application_Admin_Interfaces.md: -------------------------------------------------------------------------------- 1 | # Enumerate Infrastructure and Application Admin Interfaces (fa-IR) 2 | 3 | شمارش زیرساخت و رابط های مدیریت برنامه (فارسی) 4 | 5 | |شناسه | 6 | |------------| 7 | |WSTG-CONF-05| 8 | 9 | ## خلاصه 10 | 11 | رابط های مدیر (Administrator interfaces) ممکن است در برنامه یا سرور برنامه وجود داشته باشد تا به کاربران خاصی اجازه انجام فعالیت های ممتاز (privileged activities) در سایت را بدهد. باید آزمایش هایی انجام شود تا مشخص شود که آیا و چگونه می توان به این عملکرد ممتاز توسط یک کاربر غیرمجاز یا استاندارد دسترسی داشت یا خیر. 12 | 13 | یک برنامه ممکن است به یک رابط مدیر نیاز داشته باشد تا یک کاربر ممتاز (privileged user) را قادر سازد به عملکردی دسترسی داشته باشد که ممکن است در نحوه عملکرد سایت تغییراتی ایجاد کند. چنین تغییراتی ممکن است شامل موارد زیر باشد: 14 | 15 | - تامین حساب کاربری 16 | - طراحی و چیدمان سایت 17 | - دستکاری داده 18 | - تغییرات پیکربندی 19 | 20 | در بسیاری از موارد، چنین رابط‌هایی کنترل کافی برای محافظت از آنها در برابر دسترسی غیرمجاز ندارند. هدف آزمایش، کشف این رابط های مدیر و دسترسی به عملکردهای در نظر گرفته شده برای کاربران ممتاز است. 21 | 22 | ## اهداف آزمایش 23 | 24 | - رابط‌ها و عملکرد پنهان مدیر را شناسایی کنید. 25 | 26 | ## چگونه آزمایش کنیم 27 | 28 | ### آزمایش جعبه سیاه (Black-Box Testing) 29 | 30 | بخش زیر بردارهایی را توصیف می کند که ممکن است برای آزمایش وجود رابط های اداری استفاده شوند. این تکنیک‌ها همچنین ممکن است برای آزمایش مسائل مرتبط از جمله افزایش امتیازات مورد استفاده قرار گیرند و در جای دیگری در این راهنما توضیح داده شده‌اند (به عنوان مثال [Testing for bypassing authorization schema](../05-Authorization_Testing/02-Testing_for_Bypassing_Authorization_Schema.md) و [Testing for Insecure Direct Object References](../05-Authorization_Testing/04-Testing_for_Insecure_Direct_Object_References.md) با جزئیات بیشتر). 31 | 32 | - فهرست و فهرست فایل. یک رابط اداری ممکن است وجود داشته باشد اما به طور قابل مشاهده برای آزمایش کننده در دسترس نباشد. تلاش برای حدس زدن مسیر رابط اداری ممکن است به سادگی درخواست باشد: `admin/` یا `administrator/` و غیره. یا در برخی سناریوها می‌تواند در عرض چند ثانیه با استفاده از [Google dorks](https://www.exploit-db.com/google-hacking-database) آشکار شود. 33 | - ابزارهای زیادی برای انجام محتویات سرور وجود دارد، برای اطلاعات بیشتر به بخش ابزارها زیر مراجعه کنید. آزمایشگر ممکن است مجبور باشد نام فایل صفحه مدیریت را نیز شناسایی کند. مرور اجباری صفحه شناسایی شده ممکن است دسترسی به رابط را فراهم کند. 34 | - نظرات و پیوندها در کد منبع بسیاری از سایت ها از کدهای مشترک استفاده می کنند که برای همه کاربران سایت بارگذاری می شود. با بررسی تمام منابع ارسال شده به مشتری، پیوندهایی به عملکرد مدیر ممکن است کشف شوند و باید بررسی شوند. 35 | - بررسی اسناد سرور و برنامه اگر سرور یا برنامه در پیکربندی پیش‌فرض خود مستقر شده باشد، ممکن است با استفاده از اطلاعاتی که در پیکربندی یا مستندات راهنما توضیح داده شده است، به رابط مدیریت دسترسی پیدا کنید. در صورت یافتن یک رابط مدیریتی و نیاز به اعتبارنامه، باید از فهرست های رمز عبور پیش فرض استفاده شود. 36 | - اطلاعات در دسترس عموم بسیاری از برنامه ها مانند وردپرس دارای رابط های مدیریتی پیش فرض هستند. 37 | - پورت سرور جایگزین رابط های مدیریت ممکن است در پورت متفاوتی نسبت به برنامه اصلی روی هاست دیده شوند. به عنوان مثال، رابط مدیریت آپاچی تامکت (Apache Tomcat) اغلب در پورت 8080 قابل مشاهده است. 38 | - دستکاری پارامترها ممکن است یک پارامتر GET یا POST یا یک متغیر کوکی برای فعال کردن عملکرد مدیر مورد نیاز باشد. سرنخ های این امر شامل وجود فیلدهای مخفی مانند: 39 | 40 | ```html 41 | 42 | ``` 43 | 44 | یا در یک کوکی: 45 | 46 | `Cookie: session_cookie; useradmin=0` 47 | 48 | هنگامی که یک رابط اداری کشف شد، ترکیبی از تکنیک های فوق ممکن است برای دور زدن احراز هویت استفاده شود. اگر این مورد ناموفق باشد، آزمایش‌کننده ممکن است بخواهد حمله‌ای با نیروی brute force انجام دهد. در چنین نمونه‌ای، آزمایش‌کننده باید از احتمال قفل کردن حساب اداری در صورت وجود چنین عملکردی آگاه باشد. 49 | 50 | ### آزمایش جعبه خاکستری (Gray-Box Testing) 51 | 52 | بررسی دقیق تری از سرور و اجزای برنامه باید انجام شود تا از سخت شدن اطمینان حاصل شود (یعنی صفحات مدیر با استفاده از فیلتر IP یا سایر کنترل ها برای همه قابل دسترسی نیستند)، و در صورت لزوم، تأیید اینکه همه اجزا از اعتبار پیش فرض استفاده نمی کنند یا پیکربندی. کد منبع باید بازنگری شود تا اطمینان حاصل شود که مدل مجوز و احراز هویت از تفکیک واضح وظایف بین کاربران عادی و مدیران سایت اطمینان حاصل می کند. عملکردهای رابط کاربری مشترک بین کاربران عادی و مدیران باید بازنگری شوند تا از جدایی واضح بین ترسیم چنین اجزایی و نشت اطلاعات از چنین عملکرد مشترک اطمینان حاصل شود. 53 | 54 | هر چارچوب وب (web framework) ممکن است صفحات یا مسیر پیش‌فرض مدیر خود را داشته باشد. مثلا 55 | 56 | WebSphere: 57 | 58 | ```html 59 | /admin 60 | /admin-authz.xml 61 | /admin.conf 62 | /admin.passwd 63 | /admin/* 64 | /admin/logon.jsp 65 | /admin/secure/logon.jsp 66 | ``` 67 | 68 | PHP: 69 | 70 | ```html 71 | /phpinfo 72 | /phpmyadmin/ 73 | /phpMyAdmin/ 74 | /mysqladmin/ 75 | /MySQLadmin 76 | /MySQLAdmin 77 | /login.php 78 | /logon.php 79 | /xmlrpc.php 80 | /dbadmin 81 | ``` 82 | 83 | FrontPage: 84 | 85 | ```html 86 | /admin.dll 87 | /admin.exe 88 | /administrators.pwd 89 | /author.dll 90 | /author.exe 91 | /author.log 92 | /authors.pwd 93 | /cgi-bin 94 | ``` 95 | 96 | WebLogic: 97 | 98 | ```html 99 | /AdminCaptureRootCA 100 | /AdminClients 101 | /AdminConnections 102 | /AdminEvents 103 | /AdminJDBC 104 | /AdminLicense 105 | /AdminMain 106 | /AdminProps 107 | /AdminRealm 108 | /AdminThreads 109 | ``` 110 | 111 | WordPress: 112 | 113 | ```html 114 | wp-admin/ 115 | wp-admin/about.php 116 | wp-admin/admin-ajax.php 117 | wp-admin/admin-db.php 118 | wp-admin/admin-footer.php 119 | wp-admin/admin-functions.php 120 | wp-admin/admin-header.php 121 | ``` 122 | 123 | ## ابزارها 124 | 125 | - [OWASP ZAP - Forced Browse](https://www.zaproxy.org/docs/desktop/addons/forced-browse/) is a currently maintained use of OWASP's previous DirBuster project. 126 | - [THC-HYDRA](https://github.com/vanhauser-thc/thc-hydra) is a tool that allows brute-forcing of many interfaces, including form-based HTTP authentication. 127 | - A brute forcer is much better when it uses a good dictionary, for example the [netsparker](https://www.netsparker.com/blog/web-security/svn-digger-better-lists-for-forced-browsing/) dictionary. 128 | 129 | ## منابع 130 | 131 | - [Cirt: Default Password list](https://cirt.net/passwords) 132 | - [FuzzDB can be used to do brute force browsing admin login path](https://github.com/fuzzdb-project/fuzzdb/blob/master/discovery/predictable-filepaths/login-file-locations/Logins.txt) 133 | - [Common admin or debugging parameters](https://github.com/fuzzdb-project/fuzzdb/blob/master/attack/business-logic/CommonDebugParamNames.txt) 134 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/03-Test_File_Extensions_Handling_for_Sensitive_Information.md: -------------------------------------------------------------------------------- 1 | # Test File Extensions Handling for Sensitive Information (fa-IR) 2 | 3 | آزمایش مدیریت پسوند فایل برای اطلاعات حساس (فارسی) 4 | 5 | |شناسه | 6 | |------------| 7 | |WSTG-CONF-03| 8 | 9 | ## خلاصه 10 | 11 | پسوندهای فایل معمولاً در سرورهای وب استفاده می‌شوند تا به راحتی تعیین کنند که کدام فناوری‌ها، زبان‌ها و افزونه‌ها باید برای انجام درخواست وب مورد استفاده قرار گیرند. در حالی که این رفتار با RFC ها و استانداردهای وب مطابقت دارد، استفاده از پسوندهای فایل استاندارد اطلاعات مفیدی را در مورد فناوری‌های زیربنایی مورد استفاده در یک ابزار وب به آزمایش کننده نفوذ می‌دهد و کار تعیین سناریوی حمله برای استفاده در فناوری‌های خاص را بسیار ساده می‌کند. علاوه بر این، پیکربندی نادرست سرورهای وب به راحتی می تواند اطلاعات محرمانه در مورد اعتبار دسترسی را آشکار کند. 12 | 13 | بررسی پسوند اغلب برای تأیید اعتبار فایل‌هایی که باید آپلود شوند استفاده می‌شود، که می‌تواند منجر به نتایج غیرمنتظره شود زیرا محتوا آن چیزی نیست که انتظار می‌رود، یا به دلیل مدیریت غیرمنتظره نام فایل سیستم عامل. 14 | 15 | تعیین نحوه رسیدگی سرورهای وب به درخواست‌های مربوط به فایل‌های دارای پسوندهای مختلف ممکن است به درک رفتار وب سرور بسته به نوع فایل‌هایی که به آنها دسترسی دارد کمک کند. به عنوان مثال، می تواند به درک این که کدام پسوند فایل به صورت متنی یا ساده در مقابل آنهایی که باعث اجرای سمت سرور می شوند، بازگردانده می شوند، کمک کند. مورد دوم نشان‌دهنده فن‌آوری‌ها، زبان‌ها یا افزونه‌هایی هستند که توسط وب سرورها یا سرورهای برنامه استفاده می‌شوند و ممکن است بینش بیشتری در مورد نحوه مهندسی برنامه وب ارائه دهند. به عنوان مثال، یک پسوند "pl." معمولاً با پشتیبانی Perl سمت سرور مرتبط است. با این حال، پسوند فایل به تنهایی ممکن است فریبنده باشد و کاملاً قطعی نباشد. به عنوان مثال، منابع سمت سرور Perl ممکن است تغییر نام دهند تا این واقعیت پنهان شود که آنها واقعاً به Perl مرتبط هستند. برای اطلاعات بیشتر در مورد شناسایی فناوری‌ها و مؤلفه‌های سمت سرور، به بخش بعدی در مورد "اجزای وب سرور" مراجعه کنید. 16 | 17 | ## اهداف آزمایش 18 | 19 | - پسوندهای فایل حساس، یا پسوندهایی که ممکن است حاوی داده‌های خام باشند (مانند اسکریپت‌ها، داده‌های خام، اعتبار، و غیره). 20 | - تأیید کنید که هیچ دور زدن چارچوب سیستمی در مجموعه قوانین وجود ندارد. 21 | 22 | ## چگونه آزمایش کنیم 23 | 24 | ### مرور اجباری (Forced Browsing) 25 | 26 | درخواست هایی را با پسوندهای مختلف فایل ارسال کنید و نحوه رسیدگی به آنها را بررسی کنید. تأیید باید بر اساس هر فهرست وب باشد. دایرکتوری هایی که اجازه اجرای اسکریپت را می دهند را بررسی کنید. دایرکتوری های وب سرور را می توان با ابزارهای اسکن که به دنبال حضور دایرکتوری های شناخته شده هستند، شناسایی کرد. علاوه بر این، انعکاس ساختار وب‌سایت به آزمایش‌کننده اجازه می‌دهد تا درخت دایرکتوری‌های وب ارائه‌شده توسط برنامه را بازسازی کند. 27 | 28 | اگر معماری برنامه وب دارای بار متعادل باشد، ارزیابی همه سرورهای وب بسیار مهم است. این ممکن است آسان باشد یا نباشد، بسته به پیکربندی زیرساخت متعادل کننده. در یک زیرساخت با اجزای اضافی ممکن است تغییرات جزئی در پیکربندی سرورهای وب یا برنامه ها وجود داشته باشد. این ممکن است در صورتی اتفاق بیفتد که معماری وب از فناوری‌های ناهمگن استفاده کند (مجموعه‌ای از سرورهای وب IIS و آپاچی را در یک پیکربندی متعادل کننده بار در نظر بگیرید، که ممکن است رفتار نامتقارن جزئی بین آنها و احتمالاً آسیب‌پذیری‌های متفاوت ایجاد کند). 29 | 30 | #### مثال 31 | 32 | آزمایش کننده وجود فایلی به نام `connection.inc` را شناسایی کرده است. تلاش برای دسترسی مستقیم به آن محتویات آن را باز می گرداند که عبارتند از: 33 | 34 | ```php 35 | 39 | ``` 40 | 41 | آزمایش‌کننده وجود یک بک اند MySQL DBMS و اعتبارنامه‌های (ضعیف) استفاده شده توسط برنامه وب برای دسترسی به آن را تعیین می‌کند. 42 | 43 | پسوندهای فایل زیر هرگز نباید توسط وب سرور بازگردانده شوند، زیرا مربوط به فایل هایی هستند که ممکن است حاوی اطلاعات حساس باشند یا به فایل هایی که دلیلی برای ارائه آنها وجود ندارد. 44 | 45 | - `.asa` 46 | - `.inc` 47 | - `.config` 48 | 49 | پسوندهای فایل زیر مربوط به فایل‌هایی هستند که در صورت دسترسی، نمایش داده می‌شوند یا توسط مرورگر دانلود می‌شوند. بنابراین، فایل‌های دارای این پسوندها باید بررسی شوند تا تأیید شود که واقعاً قرار است ارائه شوند (و باقی‌مانده نیستند)، و حاوی اطلاعات حساس نیستند. 50 | 51 | - `.zip`, `.tar`, `.gz`, `.tgz`, `.rar`, etc.: (فشرده) فایل های آرشیو 52 | - `.java`: دلیلی برای دسترسی به فایل های منبع جاوا وجود ندارد 53 | - `.txt`: فایل های متنی 54 | - `.pdf`: ‫اسناد PDF 55 | - `.docx`, `.rtf`, `.xlsx`, `.pptx`, etc.: اسناد اداری 56 | - `.bak`, `.old` و سایر پسوندهای نشان دهنده فایل های پشتیبان ‫(به عنوان مثال: `~` برای فایل های پشتیبان Emacs) 57 | 58 | فهرستی که در بالا ارائه شد، تنها چند نمونه را توضیح می‌دهد، زیرا پسوندهای فایل بسیار زیاد هستند که نمی‌توان در اینجا به طور جامع به آنها پرداخت. برای یک پایگاه داده کاملتر از پسوندها به [FILExt](https://filext.com/) مراجعه کنید. 59 | 60 | برای شناسایی فایل های دارای پسوند معین می توان از ترکیبی از تکنیک ها استفاده کرد. این تکنیک‌ها می‌توانند شامل اسکنرهای آسیب‌پذیری، ابزارهای عنکبوتی و آینه‌سازی (انعکاس)، بازرسی دستی برنامه (این کار بر محدودیت‌های عنکبوتی خودکار غلبه می‌کند)، جستجو در موتورهای جستجو (به [آزمایش: Spidering و Googling](../01-Information_Gathering/01-Conduct_Search_Engine_Discovery_Reconnaissance_for_Information_Leakage.md) مراجعه کنید) باشد. همچنین به [آزمایش فایل‌های قدیمی، پشتیبان‌گیری و بدون مرجع](04-Review_Old_Backup_and_Unreferenced_Files_for_Sensitive_Information.md) مراجعه کنید که به مسائل امنیتی مربوط به فایل‌های "فراموش شده" می‌پردازد. 61 | 62 | ### آپلود فایل (File Upload) 63 | 64 | گاهی اوقات می توان از مدیریت فایل های قدیمی ویندوز 8.3 برای از بین بردن فیلترهای آپلود فایل استفاده کرد. 65 | 66 | مثال های استفاده: 67 | 68 | 1. `file.phtml` ‫به عنوان کد PHP پردازش می شود. 69 | 2. `FILE~1.PHT` ‫ارائه می شود، اما توسط کنترل کننده PHP ISAPI پردازش نمی شود. 70 | 3. `shell.phPWND` را می توان آپلود کرد. 71 | 4. `SHELL~1.PHP` ‫گسترش یافته و توسط پوسته سیستم عامل بازگردانده می شود، سپس توسط کنترل کننده PHP ISAPI پردازش می شود. 72 | 73 | ### آزمایش جعبه خاکستری (Gray-Box Testing) 74 | 75 | انجام آزمایش جعبه سفید در برابر مدیریت پسوند فایل به منزله بررسی پیکربندی سرورهای وب یا سرورهای برنامه‌ای است که در معماری برنامه‌های وب شرکت می‌کنند، و تأیید نحوه ارائه دستورالعمل‌های آنها برای ارائه پسوندهای مختلف فایل. 76 | 77 | اگر برنامه وب به یک زیرساخت ناهمگن و متعادل با بار متکی است، تعیین کنید که آیا این ممکن است رفتار متفاوتی را ایجاد کند یا خیر. 78 | 79 | ## ابزارها 80 | 81 | اسکنرهای آسیب‌پذیری، مانند Nessus و Nikto وجود فهرست‌های وب معروف را بررسی می‌کنند. آن‌ها ممکن است به آزمایش‌کننده اجازه دهند ساختار وب‌سایت را دانلود کند، که هنگام تلاش برای تعیین پیکربندی فهرست‌های وب و نحوه ارائه پسوند فایل‌های فردی مفید است. ابزارهای دیگری که می توان برای این منظور استفاده کرد عبارتند از: 82 | 83 | - [wget](https://www.gnu.org/software/wget) 84 | - [curl](https://curl.haxx.se) 85 | - google for "web mirroring tools". 86 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/10-Test_for_Subdomain_Takeover.md: -------------------------------------------------------------------------------- 1 | # Test for Subdomain Takeover (fa-IR) 2 | 3 | آزمایش تصاحب زیردامنه (فارسی) 4 | 5 | |شناسه | 6 | |------------| 7 | |WSTG-CONF-10| 8 | 9 | ## خلاصه 10 | 11 | بهره برداری موفقیت آمیز از این نوع آسیب پذیری به دشمن اجازه می دهد تا زیردامنه قربانی را ادعا کرده و کنترل کند. این حمله متکی بر موارد زیر است: 12 | 13 | 1. رکورد زیردامنه سرور DNS خارجی قربانی طوری پیکربندی شده است که به منبع / سرویس خارجی / نقطه پایانی موجود یا غیر فعال اشاره کند. گسترش محصولات XaaS (هر چیزی به عنوان سرویس) و خدمات ابری عمومی، اهداف بالقوه زیادی را برای در نظر گرفتن ارائه می دهد. 14 | 2. ارائه‌دهنده سرویس میزبان منبع/سرویس خارجی/نقطه پایانی تأیید مالکیت زیردامنه را به درستی انجام نمی‌دهد. 15 | 16 | در صورت موفقیت‌آمیز بودن تصاحب زیردامنه‌ها، طیف گسترده‌ای از حملات ممکن است (ارائه محتوای مخرب، فیشینگ، سرقت کوکی‌های جلسه کاربر، اطلاعات کاربری، و غیره). این آسیب پذیری می تواند برای طیف گسترده ای از سوابق منابع DNS از جمله: `A`، `CNAME`، `MX`، `NS`، `TXT` و غیره مورد سوء استفاده قرار گیرد. از نظر شدت حمله، تصاحب زیردامنه `NS` (اگرچه احتمال کمتری دارد) بیشترین تأثیر را دارد زیرا یک حمله موفقیت آمیز می تواند منجر به کنترل کامل بر کل ناحیه DNS ‫(DNS zone) و دامنه قربانی شود. 17 | 18 | ### گیت هاب (GitHub) 19 | 20 | 1. قربانی (victim.com) از GitHub برای توسعه استفاده می کند و یک رکورد DNS (`coderepo.victim.com`) برای دسترسی به آن پیکربندی کرده است. 21 | 2. قربانی تصمیم می گیرد مخزن کد خود را از GitHub به یک پلتفرم تجاری منتقل کند و `coderepo.victim.com` را از سرور DNS خود حذف نمی کند. 22 | 3. یک دشمن متوجه می شود که `coderepo.victim.com` در GitHub میزبانی شده است و از صفحات GitHub برای ادعای `coderepo.victim.com` با استفاده از حساب GitHub خود استفاده می کند. 23 | 24 | ### دامنه منقضی شده (Expired Domain) 25 | 26 | 1. قربانی (victim.com) صاحب دامنه دیگری است (victimotherdomain.com) و از یک رکورد CNAME (www) برای ارجاع به دامنه دیگر استفاده می کند (`www.victim.com` --> `victimotherdomain.com`) 27 | 2. در برخی مواقع، victimotherdomain.com منقضی می‌شود و برای هر کسی در دسترس است. از آنجایی که رکورد CNAME از ناحیه DNS ا victim.com حذف نمی‌شود، هرکسی که `victimotherdomain.com` را ثبت می‌کند کنترل کاملی بر `www.victim.com` دارد تا زمانی که رکورد DNS وجود داشته باشد. 28 | 29 | ## اهداف آزمایش 30 | 31 | - تمام دامنه های ممکن (قبلی و فعلی) را برشمارید. 32 | - دامنه های فراموش شده یا پیکربندی نادرست را شناسایی کنید. 33 | 34 | ## چگونه آزمایش کنیم 35 | 36 | ### آزمایش جعبه سیاه (Black-Box Testing) 37 | 38 | اولین قدم، شمارش سرورهای DNS قربانی و سوابق منابع است. راه های متعددی برای انجام این کار وجود دارد، به عنوان مثال شمارش DNS با استفاده از فهرستی از فرهنگ لغات زیردامنه های رایج، DNS brute force یا استفاده از موتورهای جستجوی وب و سایر منابع داده OSINT. 39 | 40 | با استفاده از دستور dig، آزمایش‌کننده پیام‌های پاسخ سرور DNS زیر را جستجو می‌کند که مستلزم بررسی بیشتر است: 41 | 42 | - `NXDOMAIN` 43 | - `SERVFAIL` 44 | - `REFUSED` 45 | - `no servers could be reached.` 46 | 47 | #### آزمایش DNS A، تصاحب زیردامنه رکورد CNAME ‫(Testing DNS A, CNAME Record Subdomain Takeover) 48 | 49 | یک شمارش اولیه DNS در دامنه قربانی (`victim.com`) با استفاده از `dnsrecon`: 50 | 51 | ```bash 52 | $ ./dnsrecon.py -d victim.com 53 | [*] Performing General Enumeration of Domain: victim.com 54 | ... 55 | [-] DNSSEC is not configured for victim.com 56 | [*] A subdomain.victim.com 192.30.252.153 57 | [*] CNAME subdomain1.victim.com fictioussubdomain.victim.com 58 | ... 59 | ``` 60 | 61 | شناسایی کنید که کدام سوابق منبع DNS مرده است و به سرویس های غیرفعال/استفاده نشده اشاره کنید. با استفاده از دستور dig برای رکورد `CNAME`: 62 | 63 | ```bash 64 | $ dig CNAME fictioussubdomain.victim.com 65 | ; <<>> DiG 9.10.3-P4-Ubuntu <<>> ns victim.com 66 | ;; global options: +cmd 67 | ;; Got answer: 68 | ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42950 69 | ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 70 | ``` 71 | 72 | پاسخ‌های DNS زیر مستلزم بررسی بیشتر `NXDOMAIN` است : 73 | 74 | برای آزمایش رکورد `A`، آزمایش کننده یک جستجوی پایگاه داده whois انجام می دهد و GitHub را به عنوان ارائه دهنده خدمات شناسایی می کند: 75 | 76 | ```bash 77 | $ whois 192.30.252.153 | grep "OrgName" 78 | OrgName: GitHub, Inc. 79 | ``` 80 | 81 | آزمایش‌کننده از `subdomain.victim.com` بازدید می‌کند یا یک درخواست HTTP GET صادر می‌کند که پاسخ "404 - File not found" را برمی‌گرداند که نشانه واضحی از آسیب‌پذیری است. 82 | 83 | ![GitHub 404 File Not Found response](images/subdomain_takeover_ex1.jpeg)\ 84 | *شکل 1-4.2.10: پاسخ GitHub 404 File Not Found* 85 | 86 | آزمایش‌کننده دامنه را با استفاده از صفحات GitHub ادعا می‌کند: 87 | 88 | ![GitHub claim domain](images/subdomain_takeover_ex2.jpeg)\ 89 | *شکل 2-4.2.10: ادعای دامنه GitHub* 90 | 91 | #### آزمایش تصاحب زیردامنه رکورد NS ‫(Testing NS Record Subdomain Takeover) 92 | 93 | همه سرورهای نام (nameservers) دامنه را در محدوده شناسایی کنید: 94 | 95 | ```bash 96 | $ dig ns victim.com +short 97 | ns1.victim.com 98 | nameserver.expireddomain.com 99 | ``` 100 | 101 | در این مثال ساختگی، آزمایش کننده با جستجوی ثبت کننده دامنه، فعال بودن دامنه `expireddomain.com` را بررسی می کند. اگر دامنه برای خرید در دسترس باشد، زیردامنه آسیب پذیر است. 102 | 103 | پاسخ‌های DNS روبرو مستلزم بررسی بیشتر است: `SERVFAIL` یا `REFUSED`. 104 | 105 | ### آزمایش جعبه خاکستری (Gray-Box Testing) 106 | 107 | آزمایش کننده فایل ناحیه DNS را در دسترس دارد که به این معنی است که شمارش DNS ضروری نیست. روش آزمایش یکسان است. 108 | 109 | ## اصلاح 110 | 111 | برای کاهش خطر تصاحب زیردامنه، رکورد(های) منبع آسیب پذیر DNS باید از ناحیه DNS حذف شود. نظارت مستمر و بررسی های دوره ای به عنوان بهترین عمل توصیه می شود. 112 | 113 | ## ابزارها 114 | 115 | - [dig - man page](https://linux.die.net/man/1/dig) 116 | - [recon-ng - Web Reconnaissance framework](https://github.com/lanmaster53/recon-ng) 117 | - [theHarvester - OSINT intelligence gathering tool](https://github.com/laramies/theHarvester) 118 | - [Sublist3r - OSINT subdomain enumeration tool](https://github.com/aboul3la/Sublist3r) 119 | - [dnsrecon - DNS Enumeration Script](https://github.com/darkoperator/dnsrecon) 120 | - [OWASP Amass DNS enumeration](https://github.com/OWASP/Amass) 121 | - [OWASP Domain Protect](https://owasp.org/www-project-domain-protect) 122 | 123 | ## منابع 124 | 125 | - [HackerOne - A Guide To Subdomain Takeovers](https://www.hackerone.com/blog/Guide-Subdomain-Takeovers) 126 | - [Subdomain Takeover: Basics](https://0xpatrik.com/subdomain-takeover-basics/) 127 | - [Subdomain Takeover: Going beyond CNAME](https://0xpatrik.com/subdomain-takeover-ns/) 128 | - [can-i-take-over-xyz - A list of vulnerable services](https://github.com/EdOverflow/can-i-take-over-xyz/) 129 | - [OWASP AppSec Europe 2017 - Frans Rosén: DNS hijacking using cloud providers – no verification needed](https://2017.appsec.eu/presos/Developer/DNS%20hijacking%20using%20cloud%20providers%20%E2%80%93%20no%20verification%20needed%20-%20Frans%20Rosen%20-%20OWASP_AppSec-Eu_2017.pdf) 130 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/01-Information_Gathering/01-Conduct_Search_Engine_Discovery_Reconnaissance_for_Information_Leakage.md: -------------------------------------------------------------------------------- 1 | # Conduct Search Engine Discovery Reconnaissance for Information Leakage (fa-IR) 2 | 3 | شناسایی و کشف موتورهای جستجو برای نشت اطلاعات (فارسی) 4 | 5 | |شناسه | 6 | |------------| 7 | |WSTG-INFO-01| 8 | 9 | ## خلاصه 10 | 11 | برای اینکه موتورهای جستجو کار کنند، برنامه های کامپیوتری (یا ربات ها) به طور منظم داده ها را از میلیاردها صفحه در وب دریافت (واکشی) می کنند (که به آن خزیدن ([crawling](https://en.wikipedia.org/wiki/Web_crawler)) می گویند). این برنامه ها محتوای وب و عملکرد را با دنبال کردن پیوندهایی از صفحات دیگر یا با مشاهده نقشه های سایت (sitemaps) پیدا می کنند. اگر سایتی از فایل خاصی به نام `robots.txt` برای فهرست کردن صفحاتی استفاده کند که نمی خواهد موتورهای جستجو واکشی کنند، صفحات فهرست شده در آنجا نادیده گرفته می شوند. این یک نمای کلی است - گوگل توضیح عمیق تری در مورد [نحوه عملکرد یک موتور جستجو](https://support.google.com/webmasters/answer/70897?hl=en) ارائه می دهد. 12 | 13 | آزمایش کنندگان می توانند از موتورهای جستجو برای انجام شناسایی در سایت ها و برنامه های وب استفاده کنند. عناصر مستقیم و غیرمستقیم برای کشف و شناسایی موتورهای جستجو وجود دارد: روش های مستقیم مربوط به جستجوی فهرست ها و محتوای مرتبط از حافظه پنهان است، در حالی که روش های غیرمستقیم به یادگیری اطلاعات حساس طراحی و پیکربندی از طریق جستجو در انجمن ها، گروه های خبری و سایت های مناقصه مربوط می شود. 14 | 15 | هنگامی که یک ربات موتور جستجو خزیدن را کامل کرد، شروع به فهرست بندی محتوای وب بر اساس برچسب ها و ویژگی های مرتبط می کند، مانند ``، به منظور بازگرداندن نتایج جستجوی مرتبط. اگر فایل `robots.txt` در طول عمر سایت بروزرسانی نشود و متاتگ های HTML درون خطی که به ربات ها دستور می دهد محتوا را فهرست بندی نکنند، استفاده نشده باشد، ممکن است فهرست ها حاوی محتوای وب باشند که در نظر صاحبان سایت قرار گرفته نشده است. صاحبان سایت ممکن است از `robots.txt`، متاتگ های HTML، احراز هویت و ابزارهای ارائه شده توسط موتورهای جستجو برای حذف چنین محتوایی استفاده کنند. 16 | 17 | ## اهداف آزمایش 18 | 19 | - شناسایی کنیم که چه اطلاعات طراحی و پیکربندی حساس برنامه، سیستم یا سازمان به طور مستقیم (در سایت سازمان) یا غیرمستقیم (از طریق خدمات شخص ثالث) در معرض دید قرار می گیرد. 20 | 21 | ## چگونه آزمایش کنیم 22 | 23 | از یک موتور جستجو برای جستجوی اطلاعات بالقوه حساس استفاده کنید. این ممکن است شامل موارد زیر باشد: 24 | 25 | - نمودارها و تنظیمات شبکه. 26 | - پست ها و ایمیل های آرشیو شده توسط مدیران یا سایر کارکنان کلیدی. 27 | - مراحل ورود و فرمت های نام کاربری. 28 | - نام کاربری، رمز عبور و کلیدهای خصوصی. 29 | - فایل های پیکربندی شخص ثالث یا سرویس ابری. 30 | - فاش کردن محتوای پیام خطا. 31 | - برنامه های غیر عمومی (توسعه، آزمایش، تست پذیرش کاربر (UAT)، و نسخه های مرحله بندی سایت ها). 32 | 33 | ### موتورهای جستجو (Search Engines) 34 | 35 | آزمایش را فقط به یک ارائه دهنده موتور جستجو محدود نکنید، زیرا موتورهای جستجوی مختلف ممکن است نتایج متفاوتی تولید کنند. نتایج موتورهای جستجو بسته به آخرین زمان خزیدن محتوا توسط موتور و الگوریتمی که موتور برای تعیین صفحات مرتبط استفاده می کند، می تواند از چند جهت متفاوت باشد. استفاده از موتورهای جستجوی زیر (به ترتیب حروف الفبا) را در نظر بگیرید: 36 | 37 | - بایدو ([Baidu](https://www.baidu.com/))، [محبوب ترین](https://en.wikipedia.org/wiki/Web_search_engine#Market_share) موتور جستجوی چین است. 38 | - بینگ ([Bing](https://www.bing.com/))، یک موتور جستجو که متعلق به مایکروسافت است و توسط آن اداره می شود و دومین موتور جستجوی [محبوب](https://en.wikipedia.org/wiki/Web_search_engine#Market_share) در سراسر جهان است. از کلمات کلیدی جستجوی پیشرفته ([advanced search keywords](http://help.bing.microsoft.com/#apex/18/en-US/10001/-1)) پشتیبانی میکند. 39 | - بین سرچ ([binsearch.info](https://binsearch.info/))، یک موتور جستجو برای گروه های خبری Usenet باینری است. 40 | - کامن کرول ([Common Crawl](https://commoncrawl.org/))، "یک مخزن باز از داده های خزیدن وب که برای هر کسی قابل دسترسی و تجزیه و تحلیل است." 41 | - داک داک گو ([DuckDuckGo](https://duckduckgo.com/))، یک موتور جستجوی متمرکز بر حریم خصوصی است که نتایج را از [منابع](https://help.duckduckgo.com/results/sources/) مختلف جمع آوری می کند. از نحو جستجو ([search syntax](https://help.duckduckgo.com/duckduckgo-help-pages/results/syntax/)) پشتیبانی می کند. 42 | - گوگل ([Google](https://www.google.com/))، که [محبوب ترین](https://en.wikipedia.org/wiki/Web_search_engine#Market_share) موتور جستجوی جهان را ارائه می دهد و از یک سیستم رتبه بندی برای بازگرداندن مرتبط ترین نتایج استفاده می کند. از اپراتورهای جستجو ([search operators](https://support.google.com/websearch/answer/2466433)) پشتیبانی می کند. 43 | - اینترنت آرشیو وی بک مشین ([Internet Archive Wayback Machine](https://archive.org/web/))، "ساخت یک کتابخانه دیجیتالی از سایت های اینترنتی و سایر مصنوعات فرهنگی به شکل دیجیتال است." 44 | - شدان ([Shodan](https://www.shodan.io/)) ، سرویسی برای جستجوی دستگاه ها و سرویس های متصل به اینترنت. گزینه های استفاده شامل یک طرح رایگان محدود و همچنین برنامه های اشتراک پولی است. 45 | 46 | ### اپراتورهای جستجو (Search Operators) 47 | 48 | اپراتور جستجو یک کلمه کلیدی یا نحو خاص است که قابلیت های جستجوی معمولی را گسترش می دهد و می تواند به دستیابی به نتایج خاص تری کمک کند. آنها به طور کلی به شکل `operator:query` هستند. در اینجا برخی از اپراتورهای جستجوی رایج پشتیبانی شده آورده شده است: 49 | 50 | - `site:` جستجو را به دامنه ارائه شده محدود می کند. 51 | - `inurl:` فقط نتایجی را برمی گرداند که شامل کلمه کلیدی در ‫URL باشد. 52 | - `intitle:` فقط نتایجی را برمی گرداند که کلمه کلیدی در عنوان صفحه دارند. 53 | - `intext:` یا `inbody:` فقط کلمه کلیدی را در بدنه ‫(body) صفحات جستجو می کند. 54 | - `filetype:` فقط با یک نوع فایل خاص مانند ‫`png.` یا ‫`php.` مطابقت دارد. 55 | 56 | به عنوان مثال، برای یافتن محتوای وب `owasp.org` که توسط یک موتور جستجوی معمولی فهرست (ایندکس) شده است، نحو (دستورالعمل) مورد نیاز عبارت است از: 57 | 58 | ```text 59 | site:owasp.org 60 | ``` 61 | 62 | ![Google Site Operation Search Result Example](images/Google_site_Operator_Search_Results_Example_20200406.png)\ 63 | *شکل 1-4.1.1: مثال نتیجه جستجوی عملیات سایت گوگل* 64 | 65 | ### مشاهده محتوای ذخیره شده در حافظه پنهان (Viewing Cached Content) 66 | 67 | برای جستجوی محتوایی که قبلاً ایندکس شده است، از عملگر `:cache` استفاده کنید. این برای مشاهده محتوایی که ممکن است از زمان فهرست (ایندکس) شدن تغییر کرده باشد یا دیگر در دسترس نباشد مفید است. همه موتورهای جستجو محتوای ذخیره شده را برای جستجو ارائه نمی کنند. مفیدترین منبع در زمان نگارش گوگل است. 68 | 69 | برای مشاهده `owasp.org` به صورت کش شده، نحو (دستورالعمل) به صورت زیر است: 70 | 71 | ```text 72 | cache:owasp.org 73 | ``` 74 | 75 | ![Google Cache Operation Search Result Example](images/Google_cache_Operator_Search_Results_Example_20200406.png)\ 76 | *شکل 2-4.1.1: مثال نتیجه جستجوی عملیات کش گوگل* 77 | 78 | ## <div dir="rtl" align="right">Google Hacking یا Dorking</div> 79 | 80 | جستجو با اپراتورها وقتی با خلاقیت آزمایشگر ترکیب شود می تواند یک تکنیک کشف بسیار مؤثر باشد. اپراتورها را می توان زنجیره ای کرد تا به طور موثر انواع خاصی از فایل ها و اطلاعات حساس را کشف کنند. این تکنیک که [Google hacking](https://en.wikipedia.org/wiki/Google_hacking) یا Dorking نام دارد با استفاده از موتورهای جستجوی دیگر نیز تا زمانی که اپراتورهای جستجو پشتیبانی می شوند امکان پذیر است. 81 | 82 | پایگاه داده ای از dorks، مانند [Google Hacking Database](https://www.exploit-db.com/google-hacking-database)، منبع مفیدی است که می تواند به کشف اطلاعات خاص کمک کند. برخی از دسته های dorks موجود در این پایگاه داده عبارتند از: 83 | 84 | - رد پا (Footholds) 85 | - فایل های حاوی نام کاربری 86 | - دایرکتوری های حساس 87 | - تشخیص وب سرور 88 | - فایل های آسیب پذیر 89 | - سرورهای آسیب پذیر 90 | - پیغام خطا 91 | - فایل های حاوی اطلاعات مهم 92 | - فایل های حاوی رمز عبور 93 | - اطلاعات حساس خرید آنلاین 94 | 95 | ## اصلاح 96 | 97 | قبل از ارسال آنلاین، حساسیت اطلاعات طراحی و پیکربندی را به دقت در نظر بگیرید. 98 | 99 | به طور دوره ای حساسیت اطلاعات طراحی و پیکربندی موجود که به صورت آنلاین ارسال می شود را مرور کنید. 100 | -------------------------------------------------------------------------------- /OWASP_Top10/README.md: -------------------------------------------------------------------------------- 1 | # OWASP Top 10 (fa-IR) 2 | 3 | 10 مورد برتر OWASP (فارسی) 4 | 5 | ## مقدمه و اهداف 6 | 7 | 10 مورد برتر OWASP، یک سند استاندارد آگاهی برای توسعه دهندگان و امنیت برنامه های وب است. این یک توافق گسترده در مورد حیاتی ترین خطرات امنیتی برای برنامه های وب را نشان می دهد. شرکت ها باید این سند را بپذیرند و فرآیند اطمینان از اینکه برنامه های وب آنها این خطرات را به حداقل می رساند، آغاز کنند. استفاده از OWASP Top 10 شاید موثرترین قدم اول برای تغییر فرهنگ توسعه نرم افزار در سازمان شما باشد تا بتوانید کد ایمن تری تولید کنید. 8 | 9 | ## آنچه در 10 مورد برتر سال 2021 تغییر کرده است 10 | 11 | سه مورد جدید، چهار مورد با تغییرات نام گذاری و محدوده، و مقداری ادغام در 10 مورد برتر برای سال 2021 وجود دارد. ما نام ها را در صورت لزوم تغییر داده ایم تا روی علت اصلی بیش از نماد تمرکز کنیم. 12 | 13 | ![OWASP Top 10 Mapping](images/mapping.png) 14 | 15 | ### [A01:2021-Broken Access Control (کنترل دسترسی خراب)](https://owasp.org/Top10/A01_2021-Broken_Access_Control/) 16 | 17 | با صعود از جایگاه پنجم، 94% از برنامه ها برای نوعی از کنترل دسترسی خراب با میانگین نرخ بروز 3.81% آزمایش شدند و با بیش از 318 هزار مورد، بیشترین وقوع را در مجموعه داده های ارائه شده دارند. شاخص های نقاط ضعف رایج (CWEs) شامل `CWE-200`: قرار گرفتن اطلاعات حساس در معرض یک کاربر غیرمجاز، `CWE-201`: درج اطلاعات حساس در داده های ارسال شده، و `CWE-352`: جعل درخواست های بین سایتی است. 18 | 19 | ### [A02:2021-Cryptographic Failures (خرابی های رمزنگاری)](https://owasp.org/Top10/A02_2021-Cryptographic_Failures/) 20 | 21 | تغییر یک موقعیت به سمت بالا، که قبلا به عنوان قرار گرفتن در معرض داده های حساس شناخته می شد، که بیشتر یک علامت گسترده است تا یک علت اصلی، تمرکز بر روی خرابی های مربوط به رمزنگاری (یا عدم وجود آن) است. که اغلب منجر به قرار گرفتن در معرض داده های حساس می شود. شاخص های نقاط ضعف رایج (CWEs) شامل `CWE-259`: استفاده از گذرواژه های رمزگذاری شده (هاردکد شده)، `CWE-327`: الگوریتم رمزنگاری شکسته یا مخاطره آمیز، و `CWE-331` آنتروپی ناکافی است. 22 | 23 | ### [A03:2021-Injection (تزریق)](https://owasp.org/Top10/A03_2021-Injection/) 24 | 25 | تزریق به موقعیت سوم تنزل کرد. 94% از برنامه ها برای نوعی از تزریق با حداکثر نرخ بروز 19%، میانگین نرخ بروز 3% و 274 هزار مورد آزمایش شدند. شاخص های نقاط ضعف رایج (CWEs) شامل `CWE-79`: اسکریپت بین سایتی، `CWE-89`: تزریق SQL، و `CWE-73`: کنترل خارجی نام یا مسیر فایل است. 26 | 27 | ### [A04:2021-Insecure Design (طراحی ناامن)](https://owasp.org/Top10/A04_2021-Insecure_Design/) 28 | 29 | دسته بندی جدید برای سال 2021 بر خطرات مربوط به طراحی و ایرادات معماری تمرکز دارد و خواستار استفاده بیشتر از مدل سازی تهدید، الگوهای طراحی ایمن و معماری های مرجع است. به عنوان یک جامعه، ما باید در فضای کدنویسی فراتر از "shift-left" حرکت کنیم و فعالیت هایی را پیش کدگذاری کنیم که برای اصول Secure by Design حیاتی هستند. شاخص های نقاط ضعف رایج (CWEs) شامل `CWE-209`: ایجاد پیام خطا حاوی اطلاعات حساس، `CWE-256`: ذخیره سازی محافظت نشده اعتبارنامه ها، `CWE-501`: نقض مرزهای اعتماد، و `CWE-522`: اعتبارنامه های ناکافی محافظت شده است. 30 | 31 | ### [A05:2021-Security Misconfiguration (پیکربندی اشتباه امنیتی)](https://owasp.org/Top10/A05_2021-Security_Misconfiguration/) 32 | 33 | با حرکت به بالا از شماره 6 در نسخه قبلی، 90% از برنامه ها برای نوعی از پیکربندی نادرست، با میانگین نرخ بروز 4.5% و بیش از 208 هزار مورد از یک سرشماری نقاط ضعف رایج (CWEs) در این دسته خطر آزمایش شدند. با جابجایی بیشتر به سمت نرم افزارهای بسیار قابل تنظیم، تعجب آور نیست که ببینیم این دسته به سمت بالا حرکت می کند. CWE های قابل توجه شامل `CWE-16`: پیکربندی و `CWE-611`: محدودیت نادرست مرجع موجودیت خارجی XML هستند. 34 | 35 | ### [A06:2021-Vulnerable and Outdated Components (مولفه های آسیب پذیر و قدیمی)](https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/) 36 | 37 | از نظرسنجی 10 مورد برتر انجمن، شماره 2 بود، اما همچنین دارای داده های کافی برای قرار گرفتن در 10 مورد برتر از طریق تجزیه و تحلیل داده ها بود. مؤلفه های آسیب پذیر یک مسئله شناخته شده است که ما برای آزمایش و ارزیابی ریسک آن تلاش می کنیم و تنها دسته ای است که هیچ گونه آسیب پذیری و قرار گرفتن در معرض خطر رایج (CVEs) در CWE های نگاشت شده گنجانده نشده است، بنابراین از وزن پیش فرض سواستفاده/تأثیر 5.0 استفاده می شود. CWE های قابل توجه شامل `CWE-1104`: استفاده از اجزای شخص ثالث حفظ نشده و دو CWE از 10 مورد برتر 2013 و 2017 هستند. 38 | 39 | ### [A07:2021-Identification and Authentication Failures (خرابی های شناسایی و احراز هویت)](https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/) 40 | 41 | این دسته که قبلاً به عنوان احراز هویت خراب (Broken Authentication) شناخته می شد، از جایگاه دوم پایین آمد و اکنون شامل نقاط ضعف رایج (CWEs) مربوط به خرابی های شناسایی و احراز هویت می شود. CWE های قابل توجه شامل `CWE-297`: اعتبار سنجی نامناسب گواهی با عدم تطابق میزبان، `CWE-287`: احراز هویت نامناسب و `CWE-384`: تثبیت جلسه هستند. 42 | 43 | ### [A08:2021-Software and Data Integrity Failures (خرابی های نرم افزار و یکپارچگی داده ها)](https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/) 44 | 45 | یک دسته بندی جدید برای سال 2021 بر ایجاد فرضیات مربوط به بروزرسانی نرم افزار، داده های حیاتی و CI/CD pipelines بدون تأیید یکپارچگی تمرکز دارد. یکی از بیشترین تاثیرات وزنی از داده های آسیب پذیری و قرار گرفتن در معرض خطر رایج / سیستم امتیازدهی آسیب پذیری رایج (CVE/CVSS) میباشد. شاخص های نقاط ضعف رایج (CWEs) شامل `CWE-829`: گنجاندن عملکرد از حوزه کنترل غیرقابل اعتماد، `CWE-494`: دانلود کد بدون بررسی یکپارچگی و `CWE-502`: سریال زدایی از داده های غیرقابل اعتماد است. 46 | 47 | ### [A09:2021-Security Logging and Monitoring Failures (خرابی های ثبت و مانیتورینگ امنیتی)](https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/) 48 | 49 | ثبت و نظارت امنیتی از نظرسنجی 10 مورد برتر انجمن (3#) حاصل شده است که نسبت به رتبه دهم در 10 مورد برتر OWASP 2017 اندکی افزایش یافته است. ثبت و نظارت ممکن است برای آزمایش چالش برانگیز باشد، اغلب شامل مصاحبه یا پرسیدن اینکه آیا حملات در طول آزمایش نفوذ شناسایی شده اند یا خیر. داده های CVE/CVSS زیادی برای این دسته وجود ندارد، اما شناسایی و پاسخ به نقض ها حیاتی است. با این حال، می تواند برای پاسخگویی، دید، هشدار حادثه و پزشکی قانونی بسیار تاثیرگذار باشد. این دسته فراتر از `CWE-778`: لاگ کردن ناکافی گسترش می یابد و `CWE-117`: خنثی سازی نامناسب خروجی برای گزارش ها، `CWE-223`: حذف اطلاعات مربوط به امنیت، و `CWE-532`: درج اطلاعات حساس در فایل لاگ را شامل می شود. 50 | 51 | ### [A10:2021-Server-Side Request Forgery (جعل درخواست سمت سرور)](https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/) 52 | 53 | این دسته از نظرسنجی 10 مورد برتر انجمن (1#) اضافه شده است. داده ها نرخ بروز نسبتاً پایینی را با پوشش آزمایش بالاتر از حد متوسط و رتبه بندی های بالقوه بهره برداری و تأثیر بالاتر از متوسط نشان می دهند. از آنجایی که ورودی های جدید احتمالاً یک دسته کوچک یا منفرد از نقاط ضعف رایج (CWEs) برای توجه و آگاهی هستند، امید این است که آنها در معرض تمرکز قرار گیرند و در نسخه های بعدی بتوان آنها را در یک دسته بزرگتر قرار داد. 54 | 55 | ## عوامل داده 56 | 57 | فاکتورهای داده ای وجود دارد که برای هر یک از 10 مورد برتر فهرست شده اند، در اینجا معنای آنها آمده است: 58 | 59 | - نقاط ضعف رایج نگاشت شده (CWEs Mapped): تعداد CWE هایی که توسط 10 تیم برتر به یک دسته نگاشت شده اند. 60 | - نرخ بروز (Incidence Rate): نرخ بروز درصدی از برنامه های آسیب پذیر به آن CWE آزمایش شده توسط آن سازمان برای آن سال است. 61 | - (آزمایش) پوشش ((Testing) Coverage): درصدی از برنامه هایی که توسط همه سازمان ها برای یک CWE آزمایش شده است. 62 | - بهره برداری وزنی (Weighted Exploit): امتیاز فرعی بهره برداری از نمرات CVSSv2 و CVSSv3 اختصاص داده شده به CVE ها که به CWE ها نگاشت شده، نرمال شده و در مقیاس 10pt قرار داده شده است. 63 | - تاثیر وزنی (Weighted Impact): امتیاز فرعی تاثیر از نمرات CVSSv2 و CVSSv3 اختصاص داده شده به CVE ها که به CWE ها نگاشت شده، نرمال شده و در مقیاس 10pt قرار داده شده است. 64 | - مجموع رخدادها (Total Occurrences): تعداد کل برنامه هایی که CWE ها را به یک دسته نگاشت دارند. 65 | - مجموع CVE ها (Total CVEs): تعداد کل CVE ها در NVD DB که به CWE های نگاشت شده به یک دسته نگاشت شده اند. 66 | 67 | ## منبع 68 | 69 | - [owasp.org/www-project-top-ten](https://owasp.org/www-project-top-ten/) 70 | - [owasp.org/Top10](https://owasp.org/Top10/) 71 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # OWASP Web Security Testing Guide (fa-IR) 2 | 3 | راهنمای آزمایش امنیت وب OWASP (فارسی) 4 | 5 | > این تنها ترجمه رسمی OWASP-WSTG به زبان فارسی میباشد که در [پروژه منبع](https://github.com/OWASP/wstg#translations) نیز لیست شده است. 6 | 7 | ## معرفی 8 | 9 | راهنمای آزمایش امنیت وب OWASP، یک راهنمای جامع برای آزمایش امنیت برنامه ها و سرویس های وب است. OWASP-WSTG چارچوبی از بهترین شیوه های مورد استفاده توسط آزمایش کنندگان نفوذ و سازمان ها در سراسر جهان را ارائه میدهد. 10 | 11 | ### نکته 12 | 13 | به دلیل فارسی (راست چین) بودن متن پروژه در گیت هاب، ممکن است هنگام کپی کردن متنی از پروژه، بعضی از کلمات انگلیسی که ابتدا یا انتهای آنها کاراکتر های متفرقه (مانند `/`، `.`، `~` و غیره) باشد، بصورت وارونه کپی شوند. فقط در صورتی این اتفاق میوفتد که متن انگلیسی همراه با متن فارسی در یک پاراگراف باشد. پس لطفاً بعد از کپی کردن، به صحیح بودن متن های انگلیسی دقت کنید (تمام متن ها در پروژه بصورت صحیح نمایش داده شده اند، تنها هنگام کپی کردن ممکن است این اتفاق بیوفتد). 14 | 15 | درصورت ایجاد تغییرات یا انتشار بروزرسانی های جدید در پروژه منبع، این پروژه نیز در سریع ترین زمان ممکن بروزرسانی خواهد شد. 16 | 17 | ## فهرست مطالب 18 | 19 | ## 4. [Web Application Security Testing (آزمایش امنیت برنامه وب)](4-Web_Application_Security_Testing/) 20 | 21 | ### 4.0 [Introduction and Objectives (مقدمه و اهداف)](4-Web_Application_Security_Testing/00-Introduction_and_Objectives/README.md) 22 | 23 | ### 4.1 [Information Gathering (جمع آوری اطلاعات)](4-Web_Application_Security_Testing/01-Information_Gathering/README.md) 24 | 25 | #### 4.1.1 [Conduct Search Engine Discovery Reconnaissance for Information Leakage (شناسایی و کشف موتورهای جستجو برای نشت اطلاعات)](4-Web_Application_Security_Testing/01-Information_Gathering/01-Conduct_Search_Engine_Discovery_Reconnaissance_for_Information_Leakage.md) 26 | 27 | #### 4.1.2 [Fingerprint Web Server (انگشت نگاری وب سرور)](4-Web_Application_Security_Testing/01-Information_Gathering/02-Fingerprint_Web_Server.md) 28 | 29 | #### 4.1.3 [Review Webserver Metafiles for Information Leakage (بررسی متافایل های وب سرور برای نشت اطلاعات)](4-Web_Application_Security_Testing/01-Information_Gathering/03-Review_Webserver_Metafiles_for_Information_Leakage.md) 30 | 31 | #### 4.1.4 [Enumerate Applications on Webserver (شمارش برنامه ها در وب سرور)](4-Web_Application_Security_Testing/01-Information_Gathering/04-Enumerate_Applications_on_Webserver.md) 32 | 33 | #### 4.1.5 [Review Web Page Content for Information Leakage (بررسی محتوای صفحه وب برای نشت اطلاعات)](4-Web_Application_Security_Testing/01-Information_Gathering/05-Review_Web_Page_Content_for_Information_Leakage.md) 34 | 35 | #### 4.1.6 [Identify Application Entry Points (شناسایی نقاط ورودی برنامه)](4-Web_Application_Security_Testing/01-Information_Gathering/06-Identify_Application_Entry_Points.md) 36 | 37 | #### 4.1.7 [Map Execution Paths Through Application (مسیرهای اجرای نقشه از طریق برنامه)](4-Web_Application_Security_Testing/01-Information_Gathering/07-Map_Execution_Paths_Through_Application.md) 38 | 39 | #### 4.1.8 [Fingerprint Web Application Framework (انگشت نگاری چارچوب برنامه وب)](4-Web_Application_Security_Testing/01-Information_Gathering/08-Fingerprint_Web_Application_Framework.md) 40 | 41 | #### 4.1.9 [Fingerprint Web Application (انگشت نگاری برنامه وب)](4-Web_Application_Security_Testing/01-Information_Gathering/09-Fingerprint_Web_Application.md) 42 | 43 | #### 4.1.10 [Map Application Architecture (معماری برنامه نقشه)](4-Web_Application_Security_Testing/01-Information_Gathering/10-Map_Application_Architecture.md) 44 | 45 | ### 4.2 [Configuration and Deployment Management Testing (آزمایش مدیریت پیکربندی و استقرار)](4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/README.md) 46 | 47 | #### 4.2.1 [Test Network Infrastructure Configuration (آزمایش پیکربندی زیرساخت شبکه)](4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/01-Test_Network_Infrastructure_Configuration.md) 48 | 49 | #### 4.2.2 [Test Application Platform Configuration (آزمایش پیکربندی پلتفرم برنامه)](4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/02-Test_Application_Platform_Configuration.md) 50 | 51 | #### 4.2.3 [Test File Extensions Handling for Sensitive Information (آزمایش مدیریت پسوند فایل برای اطلاعات حساس)](4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/03-Test_File_Extensions_Handling_for_Sensitive_Information.md) 52 | 53 | #### 4.2.4 [Review Old Backup and Unreferenced Files for Sensitive Information (مرور فایل های پشتیبان قدیمی و بدون مرجع برای اطلاعات حساس)](4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/04-Review_Old_Backup_and_Unreferenced_Files_for_Sensitive_Information.md) 54 | 55 | #### 4.2.5 [Enumerate Infrastructure and Application Admin Interfaces (شمارش زیرساخت و رابط های مدیریت برنامه)](4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/05-Enumerate_Infrastructure_and_Application_Admin_Interfaces.md) 56 | 57 | #### 4.2.6 [Test HTTP Methods ‫(آزمایش روش های HTTP)](4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/06-Test_HTTP_Methods.md) 58 | 59 | #### 4.2.7 [Test HTTP Strict Transport Security ‫(آزمایش امنیت حمل و نقل سخت HTTP)](4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/07-Test_HTTP_Strict_Transport_Security.md) 60 | 61 | #### 4.2.8 [Test RIA Cross Domain Policy ‫(آزمایش سیاست دامنه متقابل RIA)](4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/08-Test_RIA_Cross_Domain_Policy.md) 62 | 63 | #### 4.2.9 [Test File Permission (آزمایش مجوز فایل)](4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/09-Test_File_Permission.md) 64 | 65 | #### 4.2.10 [Test for Subdomain Takeover (آزمایش تصاحب زیردامنه)](4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/10-Test_for_Subdomain_Takeover.md) 66 | 67 | #### 4.2.11 [Test Cloud Storage (آزمایش فضای ذخیره سازی ابری)](4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/11-Test_Cloud_Storage.md) 68 | 69 | #### 4.2.12 [Test for Content Security Policy (آزمایش برای سیاست امنیت محتوا)](4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/12-Test_for_Content_Security_Policy.md) 70 | 71 | #### 4.2.13 [Test for Path Confusion (آزمایش برای سردرگمی مسیر)](4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/13-Test_for_Path_Confusion.md) 72 | 73 | ### 4.3 [Identity Management Testing (آزمایش مدیریت هویت)](4-Web_Application_Security_Testing/03-Identity_Management_Testing/README.md) 74 | 75 | #### 4.3.1 [Test Role Definitions (آزمایش تعاریف نقش)](4-Web_Application_Security_Testing/03-Identity_Management_Testing/01-Test_Role_Definitions.md) 76 | 77 | #### 4.3.2 [Test User Registration Process (آزمایش فرآیند ثبت نام کاربر)](4-Web_Application_Security_Testing/03-Identity_Management_Testing/02-Test_User_Registration_Process.md) 78 | 79 | #### 4.3.3 [Test Account Provisioning Process (آزمایش فرآیند ارائه حساب)](4-Web_Application_Security_Testing/03-Identity_Management_Testing/03-Test_Account_Provisioning_Process.md) 80 | 81 | #### 4.3.4 [Testing for Account Enumeration and Guessable User Account (آزمایش برای شمارش حساب و حساب کاربری قابل حدس زدن)](4-Web_Application_Security_Testing/03-Identity_Management_Testing/04-Testing_for_Account_Enumeration_and_Guessable_User_Account.md) 82 | 83 | #### 4.3.5 [Testing for Weak or Unenforced Username Policy (آزمایش برای سیاست نام کاربری ضعیف یا غیرقابل اجرا)](4-Web_Application_Security_Testing/03-Identity_Management_Testing/05-Testing_for_Weak_or_Unenforced_Username_Policy.md) 84 | 85 | ### 4.4 [Authentication Testing (آزمایش احراز هویت)](4-Web_Application_Security_Testing/04-Authentication_Testing/README.md) 86 | 87 | #### 4.4.1 [Testing for Credentials Transported over an Encrypted Channel (آزمایش برای اعتبارنامه های منتقل شده از طریق یک کانال رمزگذاری شده)](4-Web_Application_Security_Testing/04-Authentication_Testing/01-Testing_for_Credentials_Transported_over_an_Encrypted_Channel.md) 88 | 89 | ## [OWASP Top 10 ‫(10 مورد برتر OWASP)](OWASP_Top10/) 90 | 91 | ## مشارکت 92 | 93 | - [Discord](https://discord.gg/2JjvhAk) 94 | 95 | ## منبع 96 | 97 | - [owasp.org/www-project-web-security-testing-guide](https://owasp.org/www-project-web-security-testing-guide/) 98 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/01-Information_Gathering/02-Fingerprint_Web_Server.md: -------------------------------------------------------------------------------- 1 | # Fingerprint Web Server (fa-IR) 2 | 3 | انگشت نگاری وب سرور (فارسی) 4 | 5 | |شناسه | 6 | |------------| 7 | |WSTG-INFO-02| 8 | 9 | ## خلاصه 10 | 11 | انگشت نگاری وب سرور وظیفه شناسایی نوع و نسخه وب سروری را دارد که هدف روی آن اجرا می شود. در حالی که انگشت نگاری وب سرور اغلب در ابزارهای آزمایش خودکار محصور می شود، برای محققان مهم است که اصول چگونگی تلاش این ابزارها برای شناسایی نرم افزار و چرایی مفید بودن آن را درک کنند. 12 | 13 | کشف دقیق نوع وب سروری که یک برنامه روی آن اجرا می شود، می تواند آزمایش کنندگان امنیتی را قادر سازد تا تشخیص دهند که آیا برنامه در برابر حمله آسیب پذیر است یا خیر. به ویژه، سرورهایی که نسخه های قدیمی تر نرم افزار را بدون وصله های امنیتی به روز اجرا می کنند، می توانند در معرض سوء استفاده های خاص نسخه شناخته شده باشند. 14 | 15 | ## اهداف آزمایش 16 | 17 | - نسخه و نوع یک وب سرور در حال اجرا را تعیین کنید تا امکان کشف بیشتر هر گونه آسیب پذیری شناخته شده وجود داشته باشد. 18 | 19 | ## چگونه آزمایش کنیم 20 | 21 | تکنیک های مورد استفاده برای انگشت نگاری وب سرور عبارتند از گرفتن بنر ([banner grabbing](https://en.wikipedia.org/wiki/Banner_grabbing))، ایجاد پاسخ به درخواست های نادرست، و استفاده از ابزارهای خودکار برای انجام اسکن های قوی تر که از ترکیبی از تاکتیک ها استفاده می کنند. فرض اساسی که همه این تکنیک ها بر اساس آن عمل می کنند یکسان است. همه آنها تلاش می کنند تا برخی از پاسخ ها را از وب سرور استخراج کنند که سپس می تواند با پایگاه داده ای از پاسخ ها و رفتارهای شناخته شده مقایسه شود و بنابراین با یک نوع سرور شناخته شده مطابقت داده شود. 22 | 23 | ### گرفتن بنر (Banner Grabbing) 24 | 25 | گرفتن بنر با ارسال یک درخواست HTTP به وب سرور و بررسی هدر پاسخ ([response header](https://developer.mozilla.org/en-US/docs/Glossary/Response_header)) آن انجام می شود. این را می توان با استفاده از ابزارهای مختلف، از جمله `telnet` برای درخواست های HTTP، یا `openssl` برای درخواست های TLS/SSL انجام داد. 26 | 27 | به عنوان مثال، در اینجا پاسخ به یک درخواست ارسال شده به یک سرور آپاچی (Apache) است. 28 | 29 | ```text 30 | HTTP/1.1 200 OK 31 | Date: Thu, 05 Sep 2019 17:42:39 GMT 32 | Server: Apache/2.4.41 (Unix) 33 | Last-Modified: Thu, 05 Sep 2019 17:40:42 GMT 34 | ETag: "75-591d1d21b6167" 35 | Accept-Ranges: bytes 36 | Content-Length: 117 37 | Connection: close 38 | Content-Type: text/html 39 | ... 40 | ``` 41 | 42 | در اینجا پاسخ دیگری است، این بار از nginx ارسال شده است. 43 | 44 | ```text 45 | HTTP/1.1 200 OK 46 | Server: nginx/1.17.3 47 | Date: Thu, 05 Sep 2019 17:50:24 GMT 48 | Content-Type: text/html 49 | Content-Length: 117 50 | Last-Modified: Thu, 05 Sep 2019 17:40:42 GMT 51 | Connection: close 52 | ETag: "5d71489a-75" 53 | Accept-Ranges: bytes 54 | ... 55 | ``` 56 | 57 | در اینجا پاسخ ارسال شده توسط lighttpd اینگونه به نظر می رسد. 58 | 59 | ```text 60 | HTTP/1.0 200 OK 61 | Content-Type: text/html 62 | Accept-Ranges: bytes 63 | ETag: "4192788355" 64 | Last-Modified: Thu, 05 Sep 2019 17:40:42 GMT 65 | Content-Length: 117 66 | Connection: close 67 | Date: Thu, 05 Sep 2019 17:57:57 GMT 68 | Server: lighttpd/1.4.54 69 | ``` 70 | 71 | در این مثال ها، نوع و نسخه سرور به وضوح مشخص شده است. با این حال، برنامه های آگاه از امنیت ممکن است با تغییر هدر، اطلاعات سرور خود را مبهم کنند. به عنوان مثال، در اینجا گزیده ای از پاسخ به درخواست یک سایت با هدر اصلاح شده است: 72 | 73 | ```text 74 | HTTP/1.1 200 OK 75 | Server: Website.com 76 | Date: Thu, 05 Sep 2019 17:57:06 GMT 77 | Content-Type: text/html; charset=utf-8 78 | Status: 200 OK 79 | ... 80 | ``` 81 | 82 | در مواردی که اطلاعات سرور مبهم است، آزمایش کنندگان ممکن است بر اساس ترتیب فیلدهای سرصفحه، نوع سرور را حدس بزنند. توجه داشته باشید که در مثال آپاچی بالا، فیلدها از این ترتیب پیروی می کنند: 83 | 84 | - تاریخ (Date) 85 | - سرور (Server) 86 | - آخرین تغییر (Last-Modified) 87 | - ای تگ (ETag) 88 | - محدوده های پذیرش (Accept-Ranges) 89 | - طول محتوا (Content-Length) 90 | - ارتباط (Connection) 91 | - نوع محتوا (Content-Type) 92 | 93 | با این حال، در هر دو مثال nginx و سرور مبهم، فیلدهای مشترک از این ترتیب پیروی می کنند: 94 | 95 | - سرور (Server) 96 | - تاریخ (Date) 97 | - نوع محتوا (Content-Type) 98 | 99 | آزمایش کنندگان می توانند از این اطلاعات برای حدس زدن اینکه سرور مبهم nginx است استفاده کنند. با این حال، با توجه به اینکه تعدادی از وب سرورهای مختلف ممکن است ترتیب فیلدهای یکسانی را به اشتراک بگذارند و فیلدها قابل تغییر یا حذف باشند، این روش قطعی نیست. 100 | 101 | ### ارسال درخواست های نادرست (Sending Malformed Requests) 102 | 103 | سرورهای وب ممکن است با بررسی پاسخ های خطای آنها و در مواردی که سفارشی نشده اند، صفحات خطای پیش فرض آنها شناسایی شوند. یکی از راه های وادار کردن سرور به ارائه این درخواست ها، ارسال درخواست های عمدا نادرست یا نادرست است. 104 | 105 | به عنوان مثال، در اینجا پاسخ به درخواست متد غیر موجود `SANTA CLAUS` از یک سرور آپاچی است. 106 | 107 | ```xml 108 | GET / SANTA CLAUS/1.1 109 | 110 | 111 | HTTP/1.1 400 Bad Request 112 | Date: Fri, 06 Sep 2019 19:21:01 GMT 113 | Server: Apache/2.4.41 (Unix) 114 | Content-Length: 226 115 | Connection: close 116 | Content-Type: text/html; charset=iso-8859-1 117 | 118 | <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> 119 | <html><head> 120 | <title>400 Bad Request 121 | 122 |

Bad Request

123 |

Your browser sent a request that this server could not understand.
124 |

125 | 126 | ``` 127 | 128 | در اینجا پاسخ به همان درخواست از nginx است. 129 | 130 | ```xml 131 | GET / SANTA CLAUS/1.1 132 | 133 | 134 | 135 | 404 Not Found 136 | 137 |

404 Not Found

138 |
nginx/1.17.3
139 | 140 | 141 | ``` 142 | 143 | در اینجا پاسخ به همان درخواست از lighttpd است. 144 | 145 | ```xml 146 | GET / SANTA CLAUS/1.1 147 | 148 | 149 | HTTP/1.0 400 Bad Request 150 | Content-Type: text/html 151 | Content-Length: 345 152 | Connection: close 153 | Date: Sun, 08 Sep 2019 21:56:17 GMT 154 | Server: lighttpd/1.4.54 155 | 156 | 157 | 159 | 160 | 161 | 400 Bad Request 162 | 163 | 164 |

400 Bad Request

165 | 166 | 167 | ``` 168 | 169 | از آنجایی که صفحات خطای پیش فرض فاکتورهای متمایزکننده زیادی را بین انواع سرورهای وب ارائه می دهند، بررسی آنها می تواند روشی موثر برای انگشت نگاری حتی زمانی که فیلدهای هدر سرور مبهم هستند باشد. 170 | 171 | ### استفاده از ابزارهای اسکن خودکار (Using Automated Scanning Tools) 172 | 173 | همانطور که قبلاً گفته شد، انگشت نگاری وب سرور اغلب به عنوان یک عملکرد ابزار اسکن خودکار گنجانده شده است. این ابزارها می توانند درخواست هایی مشابه آنچه در بالا نشان داده شد، و همچنین سایر تحقیقات اختصاصی سرور را ارسال کنند. ابزارهای خودکار می توانند پاسخ های سرورهای وب را بسیار سریعتر از آزمایش دستی مقایسه کنند و از پایگاه داده های بزرگی از پاسخ های شناخته شده برای شناسایی سرور استفاده کنند. به این دلایل، ابزارهای خودکار احتمال بیشتری برای تولید نتایج دقیق دارند. 174 | 175 | در اینجا برخی از ابزارهای اسکن رایج مورد استفاده که شامل عملکرد انگشت نگاری وب سرور هستند، آورده شده است. 176 | 177 | - نت کرفت ([Netcraft](https://toolbar.netcraft.com/site_report))، یک ابزار آنلاین که سایت ها را برای اطلاعات، از جمله جزئیات وب سرور اسکن می کند. 178 | - نیکتو ([Nikto](https://github.com/sullo/nikto))، یک ابزار اسکن خط فرمان (command-line) منبع باز است. 179 | - اِن مپ ([Nmap](https://nmap.org/))، یک ابزار خط فرمان (command-line) منبع باز است که دارای رابط کاربری گرافیکی، [Zenmap](https://nmap.org/zenmap/) است. 180 | 181 | ## اصلاح 182 | 183 | در حالی که اطلاعات افشا شده سرور لزوماً به خودی خود یک آسیب پذیری نیست، اما اطلاعاتی است که می تواند به مهاجمان در سوء استفاده از آسیب پذیری های دیگر که ممکن است وجود داشته باشد کمک کند. اطلاعات سرور افشا شده همچنین می تواند مهاجمان را به یافتن آسیب پذیری های سرور خاص نسخه ای که می تواند برای بهره برداری از سرورهای وصله نشده استفاده شود، سوق دهد. به همین دلیل توصیه می شود اقدامات احتیاطی انجام شود. این اقدامات عبارتند از: 184 | 185 | - پنهان کردن اطلاعات وب سرور در هدرها، مانند ماژول [mod_headers](https://httpd.apache.org/docs/current/mod/mod_headers.html) آپاچی. 186 | - استفاده از یک سرور پراکسی معکوس ([reverse proxy server](https://en.wikipedia.org/wiki/Proxy_server#Reverse_proxies)) سخت شده برای ایجاد یک لایه امنیتی اضافی بین وب سرور و اینترنت. 187 | - اطمینان از به روز بودن وب سرورها با آخرین نرم افزارها و وصله های امنیتی. 188 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/01-Test_Network_Infrastructure_Configuration.md: -------------------------------------------------------------------------------- 1 | # Test Network Infrastructure Configuration (fa-IR) 2 | 3 | آزمایش پیکربندی زیرساخت شبکه (فارسی) 4 | 5 | |شناسه | 6 | |------------| 7 | |WSTG-CONF-01| 8 | 9 | ## خلاصه 10 | 11 | پیچیدگی ذاتی زیرساخت سرور وب به هم پیوسته و ناهمگن، که می تواند صدها برنامه وب را شامل شود، مدیریت پیکربندی و بررسی را به مرحله ای اساسی در آزمایش و استقرار هر برنامه تبدیل می کند. تنها به یک آسیب‌پذیری نیاز است تا امنیت کل زیرساخت را تضعیف کند، و حتی مشکلات کوچک و به ظاهر بی‌اهمیت ممکن است برای برنامه دیگری در همان سرور به خطرات جدی تبدیل شوند. برای رسیدگی به این مشکلات، پس از نقشه برداری از کل معماری، بررسی عمیق پیکربندی و مسائل امنیتی شناخته شده از اهمیت بالایی برخوردار است. 12 | 13 | مدیریت پیکربندی صحیح زیرساخت وب سرور به منظور حفظ امنیت خود برنامه بسیار مهم است. اگر عناصری مانند نرم افزار وب سرور، سرورهای پایگاه داده پشتیبان یا سرورهای احراز هویت به درستی بررسی و ایمن نشوند، ممکن است خطرات ناخواسته ای را معرفی کنند یا آسیب پذیری های جدیدی را معرفی کنند که ممکن است خود برنامه را به خطر بیندازند. 14 | 15 | به عنوان مثال، یک آسیب پذیری وب سرور که به مهاجم راه دور اجازه می دهد تا کد منبع برنامه خود را فاش کند (آسیب پذیری که چندین بار در سرورهای وب یا سرورهای برنامه ایجاد شده است) می تواند برنامه را در معرض خطر قرار دهد، همانطور که کاربران ناشناس می توانند از آن استفاده کنند. اطلاعات افشا شده در کد منبع برای اهرم حملات علیه برنامه یا کاربران آن. 16 | 17 | برای آزمایش زیرساخت مدیریت پیکربندی باید مراحل زیر انجام شود: 18 | 19 | - عناصر مختلفی که زیرساخت را تشکیل می دهند باید تعیین شوند تا بفهمیم چگونه با یک برنامه وب تعامل دارند و چگونه بر امنیت آن تأثیر می گذارند. 20 | - تمام عناصر زیرساخت باید بازنگری شوند تا مطمئن شویم که هیچ آسیب پذیری شناخته شده ای ندارند. 21 | - ابزارهای اداری مورد استفاده برای حفظ همه عناصر مختلف باید بررسی شود. 22 | - سیستم‌های احراز هویت باید مورد بازبینی قرار گیرند تا اطمینان حاصل شود که نیازهای برنامه را برآورده می‌کنند و نمی‌توانند توسط کاربران خارجی برای افزایش دسترسی دستکاری شوند. 23 | - فهرستی از پورت های تعریف شده که برای برنامه مورد نیاز است باید حفظ شود و تحت کنترل تغییر نگه داشته شود. 24 | 25 | پس از نگاشت عناصر مختلفی که زیرساخت را تشکیل می‌دهند (به [Map Network and Application Architecture](../01-Information_Gathering/10-Map_Application_Architecture.md) مراجعه کنید)، می‌توان پیکربندی هر عنصر ایجاد شده را بررسی کرد و آسیب‌پذیری‌های شناخته شده را آزمایش کرد. 26 | 27 | ## اهداف آزمایش 28 | 29 | - تنظیمات برنامه ها را که در سراسر شبکه تنظیم شده اند مرور کنید و آسیب پذیر نبودن آنها را تأیید کنید. 30 | - تأیید کنید که چارچوب‌ها و سیستم‌های مورد استفاده امن هستند و به دلیل نرم‌افزار نگهداری‌نشده یا تنظیمات و اعتبارنامه‌های پیش‌فرض در معرض آسیب‌پذیری‌های شناخته‌شده نیستند. 31 | 32 | ## چگونه آزمایش کنیم 33 | 34 | ### آسیب پذیری های شناخته شده سرور (Known Server Vulnerabilities) 35 | 36 | آسیب‌پذیری‌هایی که در بخش‌های مختلف معماری برنامه یافت می‌شوند، چه در سرور وب یا در پایگاه داده پشتیبان، می‌توانند به شدت خود برنامه را به خطر بیندازند. به عنوان مثال، یک آسیب پذیری سرور را در نظر بگیرید که به کاربر راه دور و احراز هویت نشده اجازه می دهد فایل ها را در وب سرور آپلود کند یا حتی فایل ها را جایگزین کند. این آسیب‌پذیری می‌تواند برنامه را به خطر بیندازد، زیرا یک کاربر سرکش ممکن است بتواند خود برنامه را جایگزین کند یا کدی را معرفی کند که بر سرورهای بک‌اند تأثیر بگذارد، زیرا کد برنامه آن مانند هر برنامه دیگری اجرا می‌شود. 37 | 38 | بررسی آسیب‌پذیری‌های سرور در صورتی که نیاز باشد آزمایش از طریق آزمایش نفوذ کور انجام شود، ممکن است سخت باشد. در این موارد، آسیب‌پذیری‌ها باید از یک سایت راه دور، معمولاً با استفاده از یک ابزار خودکار، آزمایش شوند. با این حال، آزمایش برخی آسیب‌پذیری‌ها می‌تواند نتایج غیرقابل‌پیش‌بینی روی سرور وب داشته باشد، و آزمایش برای برخی دیگر (مانند مواردی که مستقیماً در حملات انکار سرویس دخالت دارند) ممکن است به دلیل خرابی سرویس در صورت موفقیت‌آمیز بودن آزمایش امکان‌پذیر نباشد. 39 | 40 | برخی از ابزارهای خودکار، آسیب‌پذیری‌ها را بر اساس نسخه وب سرور بازیابی شده علامت‌گذاری می‌کنند. این منجر به مثبت کاذب و منفی کاذب می شود. از یک طرف، اگر نسخه وب سرور توسط مدیر سایت محلی حذف یا مبهم شده باشد، ابزار اسکن سرور را به عنوان آسیب پذیر نشان نمی دهد، حتی اگر آسیب پذیر باشد. از سوی دیگر، اگر فروشنده ارائه‌دهنده نرم‌افزار، نسخه وب سرور را هنگام رفع آسیب‌پذیری‌ها به‌روزرسانی نکند، ابزار اسکن آسیب‌پذیری‌هایی را که وجود ندارند پرچم‌گذاری می‌کند. مورد دوم در واقع بسیار رایج است زیرا برخی از فروشندگان سیستم عامل وصله‌های پورت (port patches) آسیب‌پذیری‌های امنیتی را به نرم‌افزاری که در سیستم عامل ارائه می‌کنند برمی‌گردانند، اما آپلود کامل را در آخرین نسخه نرم‌افزار انجام نمی‌دهند. این در اکثر توزیع‌های گنو/لینوکس (GNU/Linux) مانند دبیان (Debian)، رد هت (Red Hat) یا SuSE اتفاق می‌افتد. در بیشتر موارد، اسکن آسیب پذیری یک معماری برنامه، تنها آسیب پذیری های مرتبط با عناصر "در معرض" معماری (مانند وب سرور) را پیدا می کند و معمولاً نمی تواند آسیب پذیری های مرتبط با عناصری را که مستقیماً در معرض نمایش نیستند، پیدا کند، مانند بک اند احراز هویت، پایگاه داده پشتیبان یا پروکسی های معکوس [1] در حال استفاده. 41 | 42 | در نهایت، همه فروشندگان نرم‌افزار آسیب‌پذیری‌ها را به صورت عمومی افشا نمی‌کنند، و بنابراین این ضعف‌ها در پایگاه‌های اطلاعاتی آسیب‌پذیری شناخته‌شده عمومی ثبت نمی‌شوند [2]. این اطلاعات فقط برای مشتریان افشا می شود یا از طریق اصلاحاتی منتشر می شود که توصیه های همراهی ندارند. این کار مفید بودن ابزارهای اسکن آسیب پذیری را کاهش می دهد. به طور معمول، پوشش آسیب‌پذیری این ابزارها برای محصولات رایج (مانند وب سرور آپاچی (Apache web server)، سرور اطلاعات اینترنتی مایکروسافت (Microsoft's Internet Information Server)، یا لوتوس دومینو آی‌بی‌ام (IBM's Lotus Domino)) بسیار خوب خواهد بود، اما برای محصولات کمتر شناخته‌شده وجود ندارد. 43 | 44 | به همین دلیل است که بررسی آسیب‌پذیری‌ها زمانی بهتر انجام می‌شود که آزمایش کننده اطلاعات داخلی نرم‌افزار مورد استفاده، از جمله نسخه‌ها و نسخه‌های استفاده‌شده و وصله (patch) های اعمال‌شده روی نرم‌افزار را در اختیار آزمایش‌کننده قرار دهد. با استفاده از این اطلاعات، آزمایش کننده می‌تواند اطلاعات را از خود فروشنده بازیابی کند و تجزیه و تحلیل کند که چه آسیب‌پذیری‌هایی ممکن است در معماری وجود داشته باشد و چگونه می‌تواند بر خود برنامه تأثیر بگذارد. در صورت امکان، این آسیب‌پذیری‌ها را می‌توان برای تعیین اثرات واقعی آن‌ها و شناسایی عناصر خارجی (مانند سیستم‌های تشخیص نفوذ یا پیشگیری) که ممکن است احتمال بهره‌برداری موفقیت‌آمیز را کاهش یا نفی کند، آزمایش کرد. حتی ممکن است آزمایش‌کنندگان از طریق بررسی پیکربندی تشخیص دهند که این آسیب‌پذیری حتی وجود ندارد، زیرا بر یک مؤلفه نرم‌افزاری که استفاده نمی‌شود تأثیر می‌گذارد. 45 | 46 | همچنین شایان ذکر است که فروشندگان گاهی اوقات آسیب‌پذیری‌ها را بی‌صدا رفع می‌کنند و با نسخه‌های نرم‌افزار جدید، رفع‌ها را در دسترس قرار می‌دهند. فروشندگان مختلف چرخه‌های انتشار متفاوتی خواهند داشت که حمایتی را که ممکن است برای نسخه‌های قدیمی‌تر ارائه کنند، تعیین می‌کند. یک آزمایش‌کننده با اطلاعات دقیق از نسخه‌های نرم‌افزاری که توسط معماری استفاده می‌شود، می‌تواند خطر مرتبط با استفاده از نسخه‌های نرم‌افزار قدیمی را که ممکن است در کوتاه‌مدت پشتیبانی نمی‌شوند یا اکنون پشتیبانی نمی‌شوند، تجزیه و تحلیل کند. این بسیار مهم است، زیرا اگر آسیب‌پذیری در یک نسخه نرم‌افزار قدیمی که دیگر پشتیبانی نمی‌شود ظاهر شود، ممکن است پرسنل سیستم مستقیماً از آن آگاه نباشند. هیچ وصله ای برای آن در دسترس نخواهد بود و توصیه ها ممکن است آن نسخه را به عنوان آسیب پذیر فهرست نکنند زیرا دیگر پشتیبانی نمی شود. حتی در صورتی که از وجود آسیب‌پذیری و آسیب‌پذیر بودن سیستم آگاه باشند، باید یک نسخه جدید نرم‌افزاری را به‌روزرسانی کامل انجام دهند، که ممکن است باعث خرابی قابل توجهی در معماری برنامه شود یا به دلیل ناسازگاری با آخرین نسخه نرم افزار ممکن است برنامه را مجبور به کدگذاری مجدد کند. 47 | 48 | ### ابزارهای مدیریتی (Administrative Tools) 49 | 50 | هر زیرساخت وب سرور نیاز به وجود ابزارهای مدیریتی برای نگهداری و بروزرسانی اطلاعات مورد استفاده توسط برنامه دارد. این اطلاعات شامل محتوای ثابت (صفحات وب، فایل‌های گرافیکی)، کد منبع برنامه، پایگاه‌های داده احراز هویت کاربر و غیره است. ابزارهای مدیریتی بسته به سایت، فناوری یا نرم‌افزار مورد استفاده متفاوت خواهند بود. به عنوان مثال، برخی از وب سرورها با استفاده از رابط های مدیریتی مدیریت می شوند که خود سرورهای وب هستند (مانند وب سرور iPlanet) یا توسط فایل های پیکربندی متن ساده (در مورد آپاچی [3]) یا از ابزارهای رابط کاربری گرافیکی سیستم عامل (هنگام استفاده از سرور IIS مایکروسافت یا ASP.Net) اداره می شود. 51 | 52 | در بیشتر موارد، پیکربندی سرور با استفاده از ابزارهای مختلف نگهداری فایل که توسط وب سرور استفاده می‌شود، مدیریت می‌شود که از طریق سرورهای FTP، WebDAV، سیستم‌های فایل شبکه (NFS، CIFS) یا مکانیسم‌های دیگر مدیریت می‌شوند. بدیهی است که سیستم عامل عناصر تشکیل دهنده معماری اپلیکیشن نیز با استفاده از ابزارهای دیگر مدیریت خواهد شد. برنامه ها همچنین ممکن است دارای رابط های اداری تعبیه شده در آنها باشند که برای مدیریت خود داده های برنامه (کاربران، محتوا و غیره) استفاده می شود. 53 | 54 | پس از نقشه‌برداری از رابط‌های مدیریتی مورد استفاده برای مدیریت بخش‌های مختلف معماری، بررسی آنها مهم است، زیرا اگر مهاجم به هر یک از آنها دسترسی پیدا کند، می‌تواند معماری برنامه را به خطر بیاندازد یا به آن آسیب برساند. برای انجام این کار مهم است: 55 | 56 | - مکانیسم‌هایی را که دسترسی به این رابط‌ها و حساسیت‌های مرتبط با آن‌ها را کنترل می‌کنند، تعیین کنید. این اطلاعات ممکن است به صورت آنلاین در دسترس باشد. 57 | - نام کاربری و رمز عبور پیش فرض را تغییر دهید. 58 | 59 | برخی از شرکت‌ها تصمیم می‌گیرند تمام جنبه‌های برنامه‌های وب سرور خود را مدیریت نکنند، اما ممکن است طرف‌های دیگری مدیریت محتوای ارائه‌شده توسط برنامه وب داشته باشند. این شرکت خارجی ممکن است فقط بخش‌هایی از محتوا را ارائه کند (به‌روزرسانی‌های خبری یا تبلیغات) یا ممکن است سرور وب را به طور کامل مدیریت کند (از جمله محتوا و کد). یافتن واسط های اداری در دسترس از اینترنت در این شرایط معمول است، زیرا استفاده از اینترنت ارزان تر از ارائه یک خط اختصاصی است که شرکت خارجی را از طریق یک رابط مدیریتی به زیرساخت برنامه متصل می کند. در این شرایط، آزمایش اینکه آیا رابط های اداری می توانند در برابر حملات آسیب پذیر باشند، بسیار مهم است. 60 | 61 | ## منابع 62 | 63 | - [1] WebSEAL, also known as Tivoli Authentication Manager, is a reverse proxy from IBM which is part of the Tivoli framework. 64 | - [2] Such as Symantec's Bugtraq, ISS' X-Force, or NIST's National Vulnerability Database (NVD). 65 | - [3] There are some GUI-based administration tools for Apache (like NetLoony) but they are not in widespread use yet. 66 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/01-Information_Gathering/05-Review_Web_Page_Content_for_Information_Leakage.md: -------------------------------------------------------------------------------- 1 | # Review Web Page Content for Information Leakage (fa-IR) 2 | 3 | بررسی محتوای صفحه وب برای نشت اطلاعات (فارسی) 4 | 5 | |شناسه | 6 | |------------| 7 | |WSTG-INFO-05| 8 | 9 | ## خلاصه 10 | 11 | بسیار متداول است و حتی توصیه می شود که برنامه نویسان کامنت ها و متادیتا های دقیق را در کد منبع خود قرار دهند. با این حال، کامنت ها و متادیتا های موجود در کد HTML ممکن است اطلاعات داخلی را نشان دهد که نباید در دسترس مهاجمان بالقوه باشد. بررسی کامنت ها و متادیتا باید انجام شود تا مشخص شود که آیا اطلاعاتی درز کرده است یا خیر. به علاوه برخی از برنامه ها ممکن است اطلاعاتی را در بدنه پاسخ های تغییر مسیر نشت دهند. 12 | 13 | برای برنامه های وب مدرن، استفاده از جاوا اسکریپت سمت مشتری (client-side JavaScript) برای قسمت فرانت اند محبوب تر می شود. فناوری های محبوب ساخت وساز فرانت اند از جاوا اسکریپت سمت کلاینت مانند ReactJS ،AngularJS یا Vue استفاده می کنند. مشابه کامنت ها و متادیتا ها در کد HTML، بسیاری از برنامه نویسان نیز اطلاعات حساس را در متغیرهای جاوا اسکریپت در قسمت فرانت اند کدگذاری می کنند. اطلاعات حساس می تواند شامل (اما محدود به این ها نیست): کلیدهای API خصوصی (به عنوان مثال یک کلید API نقشه Google بدون محدودیت)، آدرس های IP داخلی، مسیرهای حساس (مثلا مسیر به صفحات مدیریت مخفی یا عملکرد)، یا حتی اعتبارنامه ها. این اطلاعات حساس را می توان از چنین کدهای جاوا اسکریپت فرانت اند فاش کرد. برای تعیین اینکه آیا اطلاعات حساسی که می تواند توسط مهاجمان برای سوء استفاده استفاده شود، به بیرون درز کرده است، باید بررسی شود. 14 | 15 | برای برنامه های وب بزرگ، مسائل مربوط به عملکرد یک نگرانی بزرگ برای برنامه نویسان است. برنامه نویسان از روش های مختلفی برای بهینه سازی عملکرد فرانت اند استفاده کرده اند، از جمله Syntactically Awesome Style Sheets (SASS)، Sassy CSS (SCSS)، webpack و غیره. با استفاده از این فناوری‌ها، گاهی اوقات درک کدهای فرانت اند سخت‌تر و اشکال‌زدایی آن دشوار می‌شود، و به همین دلیل، برنامه‌نویسان اغلب فایل‌های نقشه منبع (source map) را برای اهداف اشکال‌زدایی مستقر می‌کنند. "نقشه منبع" یک فایل ویژه است که یک نسخه کوچک شده/مثل یک دارایی (CSS یا جاوا اسکریپت) را به نسخه تالیف اصلی متصل می کند. برنامه نویسان هنوز در حال بحث هستند که آیا فایل های نقشه منبع را به محیط تولید بیاورند یا نه. با این حال، غیرقابل انکار است که فایل های نقشه منبع یا فایل هایی برای اشکال زدایی در صورت انتشار در محیط تولید، منبع آنها را برای انسان قابل خواندن تر می کند. این می تواند یافتن آسیب پذیری ها از قسمت فرانت اند یا جمع آوری اطلاعات حساس از آن را برای مهاجمان آسان تر کند. بررسی کد جاوا اسکریپت باید انجام شود تا مشخص شود که آیا فایل های اشکال زدایی از قسمت فرانت اند در معرض دید قرار می گیرند یا خیر. بسته به زمینه و حساسیت پروژه، یک کارشناس امنیتی باید تصمیم بگیرد که آیا فایل ها باید در محیط تولید وجود داشته باشند یا خیر. 16 | 17 | ## اهداف آزمایش 18 | 19 | - کامنت های صفحه وب (web page)، متادیتا ها، و تغییر مسیر برای یافتن هرگونه نشت اطلاعات را بررسی کنید. 20 | - فایل های جاوا اسکریپت را جمع آوری کنید و کد JS را برای درک بهتر برنامه و یافتن هرگونه نشت اطلاعات بررسی کنید. 21 | - مشخص کنید که آیا فایل های نقشه منبع یا سایر فایل های اشکال زدایی فرانت اند وجود دارند یا خیر. 22 | 23 | ## چگونه آزمایش کنیم 24 | 25 | ### کامنت ها و متادیتا های صفحه وب را مرور کنید (Review Web Page Comments and Metadata) 26 | 27 | کامت های HTML اغلب توسط توسعه دهندگان برای گنجاندن اطلاعات اشکال زدایی در مورد برنامه استفاده می شود. گاهی کامنت ها را فراموش می کنند و در محیط های تولیدی رها می کنند. آزمایش کنندگان باید به دنبال کامنت های HTML باشند که با `--!>` شروع میشوند. 28 | 29 | کد منبع (سورس کد) HTML را برای کامنت های حاوی اطلاعات حساس که می تواند به مهاجم کمک کند بینش بیشتری در مورد برنامه کسب کند، بررسی کنید. ممکن است کد SQL، نام کاربری و رمز عبور، آدرس IP داخلی یا اطلاعات اشکال زدایی باشد. 30 | 31 | ```html 32 | ... 33 |
34 |
1
Mary
35 |
2
Peter
36 |
3
Joe
37 | 38 | 39 | 40 |
41 | ... 42 | ``` 43 | 44 | آزمایش کننده حتی ممکن است چیزی شبیه به این پیدا کند: 45 | 46 | ```html 47 | 48 | ``` 49 | 50 | اطلاعات نسخه HTML را برای شماره های نسخه معتبر و URL های تعریف نوع داده (DTD) بررسی کنید. 51 | 52 | ```html 53 | 54 | ``` 55 | 56 | - `strict.dtd` -- ‫DTD سخت پیش فرض 57 | - `loose.dtd` -- ‫DTD شل 58 | - `frameset.dtd` -- ‫DTD برای اسناد فریم ست 59 | 60 | برخی از `META` تگ ها بردارهای حمله فعال را ارائه نمی کنند، اما در عوض به مهاجم اجازه می دهند تا یک برنامه را نمایه کند: 61 | 62 | ```html 63 | 64 | ``` 65 | 66 | یک تگ رایج `META` (اما نه مطابق با [WCAG](https://www.w3.org/WAI/standards-guidelines/wcag/)) [Refresh](https://en.wikipedia.org/wiki/Meta_refresh) است. 67 | 68 | ```html 69 | 70 | ``` 71 | 72 | استفاده رایج از تگ `META`، تعیین کلمات کلیدی است که یک موتور جستجو ممکن است برای بهبود کیفیت نتایج جستجو استفاده کند. 73 | 74 | ```html 75 | 76 | ``` 77 | 78 | اگرچه اکثر وب سرورها فهرست (ایندکس) کردن موتور جستجو را از طریق فایل `robots.txt` مدیریت می کنند، اما می توان آن را با `META` تگ ها نیز مدیریت کرد. تگ زیر به ربات ها توصیه می کند که پیوند (لینک) های موجود در صفحه HTML حاوی برچسب را ایندکس نکنند و دنبال نکنند. 79 | 80 | ```html 81 | 82 | ``` 83 | 84 | [پلتفرم برای انتخاب محتوای اینترنتی (PICS)](https://www.w3.org/PICS/) و [پروتکل برای منابع توصیف وب (POWDER)](https://www.w3.org/2007/powder/) زیرساختی را برای مرتبط کردن متادیتا با محتوای اینترنتی فراهم می کند. 85 | 86 | ### شناسایی کد جاوا اسکریپت و جمع آوری فایل های جاوا اسکریپت (Identifying JavaScript Code and Gathering JavaScript Files) 87 | 88 | برنامه نویسان اغلب اطلاعات حساس را با متغیرهای جاوا اسکریپت در فرانت اند هاردکد می کنند. آزمایش کنندگان باید کد منبع HTML را بررسی کنند و به دنبال کد جاوا اسکریپت بین تگ های ` 115 | ``` 116 | 117 | در برخی موارد، آزمایش کنندگان ممکن است مسیرهای حساسی را از کد جاوا اسکریپت پیدا کنند، مانند پیوندهایی به صفحات مدیریت داخلی یا پنهان. 118 | 119 | ```html 120 | 125 | ``` 126 | 127 | ### شناسایی فایل های نقشه منبع (Identifying Source Map Files) 128 | 129 | فایل های نقشه منبع معمولاً با باز شدن DevTools بارگذاری می شوند. آزمایش کنندگان همچنین می توانند فایل های نقشه منبع را با افزودن پسوند "map." پس از پسوند هر فایل جاوا اسکریپت خارجی پیدا کنند. برای مثال، اگر آزمایش کننده ای فایل `static/js/main.chunk.js/` را ببیند، می تواند با مراجعه به فایل نقشه منبع آن را بررسی کند `static/js/main.chunk.js.map/`. 130 | 131 | فایل های نقشه منبع را برای هرگونه اطلاعات حساسی که می تواند به مهاجم کمک کند بینش بیشتری در مورد برنامه کسب کند، بررسی کنید. مثلا: 132 | 133 | ```json 134 | { 135 | "version": 3, 136 | "file": "static/js/main.chunk.js", 137 | "sources": [ 138 | "/home/sysadmin/cashsystem/src/actions/index.js", 139 | "/home/sysadmin/cashsystem/src/actions/reportAction.js", 140 | "/home/sysadmin/cashsystem/src/actions/cashoutAction.js", 141 | "/home/sysadmin/cashsystem/src/actions/userAction.js", 142 | "..." 143 | ], 144 | "..." 145 | } 146 | ``` 147 | 148 | وقتی سایت ها فایل های نقشه منبع را بارگیری می کنند، کد منبع فرانت اند قابل خواندن و اشکال زدایی آسان تر می شود. 149 | 150 | ### شناسایی پاسخ های تغییر مسیر که اطلاعات درز می کنند (Identify Redirect Responses which Leak Information) 151 | 152 | اگرچه به طور کلی انتظار نمی رود که پاسخ های تغییر مسیر حاوی محتوای وب قابل توجهی باشند، هیچ اطمینانی وجود ندارد که آنها نمی توانند حاوی محتوا باشند. بنابراین، در حالی که پاسخ های سری 300 (redirect) اغلب حاوی محتوای نوع "`/redirecting to https://example.com`" هستند، ممکن است محتوا نیز به بیرون درز کند. 153 | 154 | وضعیتی را در نظر بگیرید که در آن یک پاسخ تغییر مسیر نتیجه یک بررسی احراز هویت یا مجوز است، اگر این بررسی ناموفق باشد، سرور ممکن است پاسخ دهد و کاربر را به صفحه "ایمن" یا "پیش فرض" هدایت کند، اما پاسخ تغییر مسیر ممکن است همچنان حاوی محتوا باشد. که در مرورگر نشان داده نمی شود اما در واقع به مشتری (client) منتقل می شود. این را می توان با استفاده از ابزارهای توسعه دهنده مرورگر یا از طریق یک پروکسی شخصی (مانند ZAP، Burp، Fiddler یا Charles) مشاهده کرد. 155 | 156 | ## ابزارها 157 | 158 | - [Wget](https://www.gnu.org/software/wget/wget.html) 159 | - Browser "view source" function 160 | - Eyeballs 161 | - [Curl](https://curl.haxx.se/) 162 | - [Zaproxy](https://www.zaproxy.org) 163 | - [Burp Suite](https://portswigger.net/burp) 164 | - [Waybackurls](https://github.com/tomnomnom/waybackurls) 165 | - [Google Maps API Scanner](https://github.com/ozguralp/gmapsapiscanner/) 166 | 167 | ## منابع 168 | 169 | - [KeyHacks](https://github.com/streaak/keyhacks) 170 | - [RingZer0 Online CTF](https://ringzer0ctf.com/challenges/104) - Challenge 104 "Admin Panel". 171 | 172 | ### کاغذهای سفید (Whitepapers) 173 | 174 | - [HTML version 4.01](https://www.w3.org/TR/1999/REC-html401-19991224) 175 | - [XHTML](https://www.w3.org/TR/2010/REC-xhtml-basic-20101123/) 176 | - [HTML version 5](https://www.w3.org/TR/html5/) 177 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/03-Identity_Management_Testing/04-Testing_for_Account_Enumeration_and_Guessable_User_Account.md: -------------------------------------------------------------------------------- 1 | # Testing for Account Enumeration and Guessable User Account (fa-IR) 2 | 3 | آزمایش برای شمارش حساب و حساب کاربری قابل حدس زدن (فارسی) 4 | 5 | |شناسه | 6 | |------------| 7 | |WSTG-IDNT-04| 8 | 9 | ## خلاصه 10 | 11 | دامنه این آزمایش بررسی این است که آیا امکان جمع آوری مجموعه ای از نام های کاربری معتبر با تعامل با مکانیسم احراز هویت برنامه وجود دارد یا خیر. این آزمایش برای آزمایش brute force مفید خواهد بود، که در آن آزمایش کننده بررسی می کند که آیا با دادن یک نام کاربری معتبر، امکان یافتن رمز عبور مربوطه وجود دارد یا خیر. 12 | 13 | اغلب، برنامه های وب زمانی که یک نام کاربری در سیستم وجود دارد، یا به عنوان یک نتیجه از پیکربندی اشتباه یا به عنوان یک تصمیم طراحی، نشان می دهد. به عنوان مثال، گاهی اوقات زمانی که اعتبارنامه اشتباه ارسال می کنیم، پیامی دریافت می کنیم که یا نام کاربری در سیستم وجود دارد یا رمز عبور ارائه شده اشتباه است. اطلاعات به دست آمده می تواند توسط یک مهاجم برای به دست آوردن لیستی از کاربران در سیستم استفاده شود. از این اطلاعات می توان برای حمله به برنامه وب استفاده کرد، به عنوان مثال، از طریق یک حمله brute force یا نام کاربری و رمز عبور پیش فرض. 14 | 15 | آزمایش‌کننده باید با مکانیسم احراز هویت برنامه تعامل داشته باشد تا بفهمد آیا ارسال درخواست‌های خاص باعث می‌شود برنامه به روش‌های مختلف پاسخ دهد یا خیر. این مشکل به این دلیل وجود دارد که اطلاعات منتشر شده از برنامه وب یا وب سرور زمانی که کاربر یک نام کاربری معتبر ارائه می‌کند با زمانی که از نام کاربری نامعتبر استفاده می‌کند متفاوت است. 16 | 17 | در برخی موارد، پیامی دریافت می‌شود که نشان می‌دهد اعتبارنامه‌های ارائه شده اشتباه هستند، زیرا از نام کاربری نامعتبر یا رمز عبور نامعتبر استفاده شده است. گاهی اوقات، آزمایش کنندگان می توانند کاربران موجود را با ارسال یک نام کاربری و یک رمز عبور خالی شمارش کنند. 18 | 19 | ## اهداف آزمایش 20 | 21 | - فرآیندهای مربوط به شناسایی کاربر (مانند ثبت نام، ورود به سیستم و غیره) را بررسی کنید. 22 | - در صورت امکان از طریق تجزیه و تحلیل پاسخ، کاربران را برشمارید. 23 | 24 | ## چگونه آزمایش کنیم 25 | 26 | در آزمایش جعبه سیاه، آزمایش کننده هیچ چیز در مورد برنامه خاص، نام کاربری، منطق برنامه، پیام های خطا در صفحه ورود یا امکانات بازیابی رمز عبور نمی داند. اگر برنامه آسیب‌پذیر باشد، آزمایش‌کننده پیام پاسخی دریافت می‌کند که به‌طور مستقیم یا غیرمستقیم، برخی از اطلاعات مفید برای شمارش کاربران را نشان می‌دهد. 27 | 28 | ### پیام پاسخ HTTP ‫(HTTP Response Message) 29 | 30 | #### آزمایش برای اعتبارنامه های معتبر (Testing for Valid Credentials) 31 | 32 | هنگامی که یک شناسه کاربری معتبر و رمز عبور معتبر ارسال می کنید، پاسخ سرور را ثبت کنید. 33 | 34 | > با استفاده از یک پروکسی وب، به اطلاعات بازیابی شده از این احراز هویت موفق توجه کنید (پاسخ HTTP 200، طول پاسخ). 35 | 36 | #### آزمایش برای کاربر معتبر با رمز عبور اشتباه (Testing for Valid User with Wrong Password) 37 | 38 | حال، آزمایش کننده باید سعی کند یک شناسه کاربری معتبر و یک رمز عبور اشتباه وارد کند و پیام خطای ایجاد شده توسط برنامه را ثبت کند. 39 | 40 | > مرورگر باید پیامی مشابه پیام زیر نمایش دهد: 41 | > 42 | > ![Authentication Failed](images/AuthenticationFailed.png)\ 43 | > *شکل 1-4.3.4: احراز هویت ناموفق بود* 44 | > 45 | > بر خلاف هر پیامی که وجود کاربر را آشکار می کند مانند موارد زیر: 46 | > 47 | > `Login for User foo: invalid password` 48 | > 49 | > با استفاده از یک پروکسی وب، به اطلاعات بازیابی شده از این تلاش احراز هویت ناموفق توجه کنید (پاسخ HTTP 200، طول پاسخ). 50 | 51 | #### آزمایش برای نام کاربری ناموجود (Testing for a Nonexistent Username) 52 | 53 | حال، آزمایش کننده باید سعی کند یک شناسه کاربری نامعتبر و یک رمز عبور اشتباه وارد کند و پاسخ سرور را ثبت کند (آزمایش کننده باید مطمئن باشد که نام کاربری در برنامه معتبر نیست). پیام خطا و پاسخ سرور را ضبط کنید. 54 | 55 | > اگر آزمایش‌کننده یک شناسه کاربری ناموجود وارد کند، می‌تواند پیامی شبیه به زیر دریافت کند: 56 | > 57 | > ![This User is Not Active](images/Userisnotactive.png)\ 58 | > *شکل 2-4.3.4: این کاربر فعال نیست* 59 | > 60 | > یا پیامی مانند زیر: 61 | > 62 | > `Login failed for User foo: invalid Account` 63 | > 64 | > به طور کلی برنامه باید با یک پیام خطا و طول یکسان به درخواست های مختلف نادرست پاسخ دهد. اگر پاسخ‌ها یکسان نیستند، آزمایش‌کننده باید کلیدی را که بین دو پاسخ تفاوت ایجاد می‌کند، بررسی کرده و بیابد. مثلا: 65 | > 66 | > 1. درخواست مشتری: کاربر معتبر / رمز عبور اشتباه 67 | > 2. پاسخ سرور: رمز عبور صحیح نیست 68 | > 3. درخواست مشتری: کاربر اشتباه / رمز عبور اشتباه 69 | > 4. پاسخ سرور: کاربر شناسایی نشد 70 | > 71 | > پاسخ‌های بالا به مشتری (Client) اجازه می‌دهد بفهمد که برای اولین درخواست یک نام کاربری معتبر دارد. بنابراین آنها می توانند با درخواست مجموعه ای از شناسه های کاربری احتمالی و مشاهده پاسخ با برنامه تعامل داشته باشند. 72 | > 73 | > با نگاهی به پاسخ سرور دوم، آزمایش‌کننده به همان شیوه متوجه می‌شود که نام کاربری معتبری ندارد. بنابراین آنها می توانند به همان شیوه تعامل داشته باشند و لیستی از شناسه کاربری معتبر را با نگاه کردن به پاسخ های سرور ایجاد کنند. 74 | 75 | ### راه های دیگر برای شمارش کاربران (Other Ways to Enumerate Users) 76 | 77 | آزمایش کنندگان می توانند کاربران را به روش های مختلفی شمارش کنند، مانند: 78 | 79 | #### تجزیه و تحلیل کد خطای دریافت شده در صفحات ورود (Analyzing the Error Code Received on Login Pages) 80 | 81 | برخی از برنامه های وب کد خطا یا پیام خاصی را منتشر می کنند که ما می توانیم آن را تجزیه و تحلیل کنیم. 82 | 83 | #### تجزیه و تحلیل URL ها و تغییر مسیرهای URL ‫(Analyzing URLs and URL Redirections) 84 | 85 | مثلا: 86 | 87 | - `http://www.foo.com/err.jsp?User=baduser&Error=0` 88 | - `http://www.foo.com/err.jsp?User=gooduser&Error=2` 89 | 90 | همانطور که در بالا مشاهده می شود، هنگامی که یک آزمایش کننده یک شناسه کاربری و رمز عبور را برای برنامه وب ارائه می دهد، پیامی را می بیند که نشان می دهد خطایی در URL رخ داده است. در مورد اول آنها یک شناسه کاربری بد و رمز عبور بد ارائه کرده اند. در دوم، یک شناسه کاربری خوب و یک رمز عبور بد، بنابراین آنها می توانند یک شناسه کاربری معتبر را شناسایی کنند. 91 | 92 | ####
URI Probing
93 | 94 | گاهی اوقات یک وب سرور در صورتی که درخواستی برای یک فهرست موجود دریافت کند یا نه، پاسخ متفاوتی می دهد. به عنوان مثال در برخی از پورتال ها هر کاربر با یک فهرست مرتبط است. اگر آزمایش‌کنندگان سعی کنند به یک فهرست موجود دسترسی پیدا کنند، ممکن است یک خطای وب سرور دریافت کنند. 95 | 96 | برخی از خطاهای رایج دریافتی از وب سرورها عبارتند از: 97 | 98 | - کد خطای 403 ممنوعه (Forbidden) 99 | - کد خطای 404 یافت نشد (Not found) 100 | 101 | مثال: 102 | 103 | - `http://www.foo.com/account1`- از وب سرور دریافت می کنیم: 403 ممنوعه 104 | - `http://www.foo.com/account2` - از وب سرور دریافت می کنیم: 404 فایل یافت نشد 105 | 106 | در حالت اول کاربر وجود دارد، اما آزمایش کننده نمی تواند صفحه وب را مشاهده کند، در حالت دوم در عوض کاربر "account2" وجود ندارد. با جمع آوری این اطلاعات، آزمایش کنندگان می توانند کاربران را برشمارند. 107 | 108 | #### تجزیه و تحلیل عناوین صفحات وب (Analyzing Web Page Titles) 109 | 110 | آزمایش‌کنندگان می‌توانند اطلاعات مفیدی را در عنوان صفحه وب دریافت کنند، جایی که می‌توانند کد خطا یا پیام‌هایی را دریافت کنند که نشان می‌دهد آیا مشکلات مربوط به نام کاربری یا رمز عبور است. 111 | 112 | به عنوان مثال، اگر کاربر نتواند در یک برنامه احراز هویت کند و یک صفحه وب دریافت کند که عنوان آن شبیه به: 113 | 114 | - `Invalid user` 115 | - `Invalid authentication` 116 | 117 | #### تجزیه و تحلیل یک پیام دریافت شده از یک مرکز بازیابی (Analyzing a Message Received from a Recovery Facility) 118 | 119 | هنگامی که از یک تسهیلات بازیابی استفاده می کنیم (یعنی یک تابع رمز عبور فراموش شده)، یک برنامه آسیب پذیر ممکن است پیامی را برگرداند که نشان دهد نام کاربری وجود دارد یا نه. 120 | 121 | به عنوان مثال، پیام های مشابه زیر: 122 | 123 | - `Invalid username: email address is not valid or the specified user was not found.` 124 | - `Valid username: Your password has been successfully sent to the email address you registered with.` 125 | 126 | #### پیام خطای دوستانه 404 (Friendly 404 Error Message) 127 | 128 | وقتی از کاربری در فهرستی که وجود ندارد درخواست می کنیم، همیشه کد خطای 404 را دریافت نمی کنیم. در عوض، ممکن است "200 OK" را با یک تصویر دریافت کنیم، در این مورد می توانیم فرض کنیم که وقتی تصویر خاص را دریافت می کنیم، کاربر وجود ندارد. این منطق را می توان به سایر پاسخ سرور وب اعمال کرد. ترفند تجزیه و تحلیل خوبی از وب سرور و پیام های برنامه وب است. 129 | 130 | #### تجزیه و تحلیل زمان پاسخگویی (Analyzing Response Times) 131 | 132 | علاوه بر نگاه کردن به محتوای پاسخ ها، زمان پاسخگویی نیز باید در نظر گرفته شود. به خصوص در مواردی که درخواست باعث تعامل با یک سرویس خارجی می شود (مانند ارسال یک ایمیل رمز عبور فراموش شده)، این می تواند چند صد میلی ثانیه به پاسخ اضافه کند، که می تواند برای تعیین معتبر بودن کاربر درخواست شده استفاده شود. 133 | 134 | ### حدس زدن کاربران (Guessing Users) 135 | 136 | در برخی موارد، شناسه‌های کاربری با سیاست‌های خاص مدیر یا شرکت ایجاد می‌شوند. برای مثال می‌توانیم کاربری را با شناسه کاربری که به ترتیب ایجاد شده است مشاهده کنیم: 137 | 138 | ```text 139 | CN000100 140 | CN000101 141 | ... 142 | ``` 143 | 144 | گاهی اوقات نام های کاربری با نام مستعار REALM و سپس اعداد ترتیبی ایجاد می شوند: 145 | 146 | - ا R1001 – کاربر 001 برای REALM1 147 | - ا R2001 – کاربر 001 برای REALM2 148 | 149 | در نمونه بالا می‌توانیم اسکریپت‌های shell ساده ایجاد کنیم که شناسه‌های کاربر را می‌سازند و درخواستی را با ابزاری مانند wget ارسال می‌کنیم تا یک جستجوی وب را خودکار کند تا شناسه‌های کاربری معتبر را تشخیص دهد. برای ایجاد یک اسکریپت می توانیم از Perl و Curl نیز استفاده کنیم. 150 | 151 | سایر امکانات عبارتند از: - شناسه های کاربری مرتبط با شماره کارت اعتباری، یا به طور کلی اعداد با یک الگو. - شناسه های کاربری مرتبط با نام های واقعی، به عنوان مثال اگر Freddie Mercury شناسه کاربری "fmercury" داشته باشد، ممکن است حدس بزنید که Roger Taylor شناسه کاربری "rtaylor" را داشته باشد. 152 | 153 | باز هم، می‌توانیم نام کاربری را از اطلاعات دریافتی از یک پرس و جو LDAP یا از جمع‌آوری اطلاعات Google، به عنوان مثال، از یک دامنه خاص حدس بزنیم. گوگل می تواند از طریق پرس و جوهای خاص یا از طریق اسکریپت یا ابزار پوسته ساده به یافتن کاربران دامنه کمک کند. 154 | 155 | > با برشمردن حساب های کاربری، خطر قفل کردن حساب ها پس از تعداد از پیش تعریف شده کاوش های ناموفق (بر اساس سیاست برنامه) وجود دارد. همچنین، گاهی اوقات، آدرس IP شما می تواند توسط قوانین پویا در فایروال برنامه یا سیستم جلوگیری از نفوذ ممنوع (ban) شود. 156 | 157 | ### آزمایش جعبه خاکستری (Gray-Box Testing) 158 | 159 | #### آزمایش پیام های خطای احراز هویت (Testing for Authentication Error Messages) 160 | 161 | بررسی کنید که برنامه برای هر درخواست مشتری که احراز هویت ناموفق ایجاد می کند، به همان شیوه پاسخ می دهد. برای این موضوع، آزمایش جعبه سیاه و آزمایش جعبه خاکستری بر اساس تجزیه و تحلیل پیام ها یا کدهای خطا دریافت شده از برنامه وب، مفهوم یکسانی دارند. 162 | 163 | > برنامه باید برای هر تلاش ناموفق برای احراز هویت به همان شیوه پاسخ دهد. 164 | > 165 | > به عنوان مثال: اعتبارنامه های ارسال شده معتبر نیستند 166 | 167 | ## اصلاح 168 | 169 | اطمینان حاصل کنید که برنامه در پاسخ به نام حساب نامعتبر، رمز عبور یا سایر اطلاعات کاربری که در طول فرآیند ورود به سیستم وارد شده اند، پیام های خطای عمومی ثابتی را برمی گرداند. 170 | 171 | اطمینان حاصل کنید که حساب‌های پیش‌فرض سیستم و حساب‌های آزمایشی قبل از عرضه سیستم به تولید (یا قرار دادن آن در معرض یک شبکه غیرقابل اعتماد) حذف شده‌اند. 172 | 173 | ## ابزارها 174 | 175 | - [OWASP Zed Attack Proxy (ZAP)](https://www.zaproxy.org) 176 | - [curl](https://curl.haxx.se/) 177 | - [PERL](https://www.perl.org) 178 | 179 | ## منابع 180 | 181 | - [Username Enumeration Vulnerabilities](https://www.gnucitizen.org/blog/username-enumeration-vulnerabilities/) 182 | - [Prevent WordPress Username Enumeration](https://www.jinsonvarghese.com/prevent-wordpress-username-enumeration/) 183 | - [Marco Mella, Sun Java Access & Identity Manager Users enumeration](https://www.exploit-db.com/exploits/32762) 184 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/01-Information_Gathering/03-Review_Webserver_Metafiles_for_Information_Leakage.md: -------------------------------------------------------------------------------- 1 | # Review Webserver Metafiles for Information Leakage (fa-IR) 2 | 3 | بررسی متافایل های وب سرور برای نشت اطلاعات (فارسی) 4 | 5 | |شناسه | 6 | |------------| 7 | |WSTG-INFO-03| 8 | 9 | ## خلاصه 10 | 11 | این بخش نحوه آزمایش فایل های متادیتا مختلف را برای نشت اطلاعات مسیر(ها) یا عملکرد برنامه وب توضیح می دهد. علاوه بر این، فهرست دایرکتوری هایی که باید توسط عنکبوت ها، ربات ها یا خزنده ها اجتناب شود، می تواند به عنوان یک وابستگی برای مسیرهای اجرای نقشه از طریق برنامه ([Map execution paths through application](07-Map_Execution_Paths_Through_Application.md)) ایجاد شود. اطلاعات دیگری نیز ممکن است برای شناسایی سطح حمله، جزئیات فناوری، یا برای استفاده در تعامل مهندسی اجتماعی جمع آوری شود. 12 | 13 | ## اهداف آزمایش 14 | 15 | - شناسایی مسیرها و عملکردهای مخفی یا مبهم از طریق تجزیه و تحلیل فایل های متادیتا. 16 | - استخراج و نقشه برداری اطلاعات دیگری که می تواند منجر به درک بهتر سیستم های موجود شود. 17 | 18 | ## چگونه آزمایش کنیم 19 | 20 | > هر یک از اقدامات انجام شده در زیر با `wget` و با `curl` نیز می تواند انجام شود. بسیاری از ابزارهای Dynamic Application Security Testing (DAST) (تست امنیت برنامه های پویا) مانند ZAP و Burp Suite شامل بررسی یا تجزیه این منابع به عنوان بخشی از عملکرد عنکبوت/خزنده خود هستند. آنها همچنین می توانند با استفاده از [Google Dorks](https://en.wikipedia.org/wiki/Google_hacking) مختلف یا استفاده از ویژگی های جستجوی پیشرفته مانند `:inurl` باشند. 21 | 22 | ### ربات ها (Robots) 23 | 24 | عنکبوت های وب، ربات ها یا خزنده ها یک صفحه وب را بازیابی می کنند و سپس به صورت بازگشتی از لینک ها عبور می کنند تا محتوای وب بیشتری را بازیابی کنند. رفتار پذیرفته شده آنها توسط پروتکل حذف ربات ها ([Robots Exclusion Protocol](https://www.robotstxt.org)) فایل [robots.txt](https://www.robotstxt.org/) در فهرست اصلی وب مشخص شده است. 25 | 26 | به عنوان مثال، ابتدای فایل `robots.txt` از [Google](https://www.google.com/robots.txt) نمونه برداری شده در 5 مه 2020 در زیر نقل شده است: 27 | 28 | ```text 29 | User-agent: * 30 | Disallow: /search 31 | Allow: /search/about 32 | Allow: /search/static 33 | Allow: /search/howsearchworks 34 | Disallow: /sdch 35 | ... 36 | ``` 37 | 38 | دستورالعمل عامل کاربر ([User-Agent](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent)) به عنکبوت/ربات/خزنده وب خاص اشاره دارد. به عنوان مثال، `User-Agent: Googlebot` به عنکبوت از گوگل اشاره دارد در حالی که `User-Agent: bingbot` به خزنده ای از مایکروسافت اشاره دارد. `* :User-Agent` در مثال بالا برای همه [عنکبوت ها / ربات ها / خزنده های وب](https://support.google.com/webmasters/answer/6062608?visit_id=637173940975499736-3548411022&rd=1) اعمال می شود. 39 | 40 | این دستورالعمل `Disallow` مشخص می کند که کدام منابع توسط عنکبوت ها / ربات ها / خزنده ها ممنوع است. در مثال بالا موارد زیر ممنوع است: 41 | 42 | ```text 43 | ... 44 | Disallow: /search 45 | ... 46 | Disallow: /sdch 47 | ... 48 | ``` 49 | 50 | عنکبوت ها/ربات ها/خزنده های وب می توانند عمدا دستورالعمل های `Disallow` مشخص شده در یک فایل `robots.txt` را نادیده بگیرند ([intentionally ignore](https://blog.isc2.org/isc2_blog/2008/07/the-attack-of-t.html)). از این رو، `robots.txt` نباید به عنوان مکانیزمی برای اعمال محدودیت در نحوه دسترسی، ذخیره یا انتشار مجدد محتوای وب توسط اشخاص ثالث در نظر گرفته شود. 51 | 52 | فایل `robots.txt` از دایرکتوری ریشه وب سرور وب بازیابی می شود. به عنوان مثال، بازیابی `robots.txt` از `www.google.com` با استفاده از `wget` یا `curl`: 53 | 54 | ```bash 55 | $ curl -O -Ss http://www.google.com/robots.txt && head -n5 robots.txt 56 | User-agent: * 57 | Disallow: /search 58 | Allow: /search/about 59 | Allow: /search/static 60 | Allow: /search/howsearchworks 61 | ... 62 | ``` 63 | 64 | ### تجزیه و تحلیل robots.txt با استفاده از Google Webmaster Tools 65 | 66 | صاحبان سایت می توانند از "Google "Analyze robots.txt برای تجزیه و تحلیل سایت به عنوان بخشی از [Google Webmaster Tools](https://www.google.com/webmasters/tools) استفاده کنند. این ابزار می تواند به آزمایش کمک کند و روش آن به شرح زیر است: 67 | 68 | 1. با یک حساب Google وارد Google Webmaster Tools شوید. 69 | 2. در داشبورد، آدرس سایت مورد تجزیه و تحلیل را وارد کنید. 70 | 3. از بین روش های موجود یکی را انتخاب کنید و دستورالعمل روی صفحه را دنبال کنید. 71 | 72 | ### متاتگ ها (META Tags) 73 | 74 | تگ های `` در بخش `HEAD` هر سند HTML قرار دارند و در صورتی که نقطه شروع ربات/عنکبوت/خزنده از پیوند سندی غیر از webroot یعنی پیوند عمیق ([deep link](https://en.wikipedia.org/wiki/Deep_linking)) شروع نشود، باید در سراسر یک سایت سازگار باشند. دستورالعمل ربات ها را می توان با استفاده از یک متاتگ ([META tag](https://www.robotstxt.org/meta.html)) خاص نیز مشخص کرد. 75 | 76 | #### متاتگ ربات ها (Robots META Tag) 77 | 78 | اگر ورودی `< ... "META NAME="ROBOTS>` وجود نداشته باشد، "پروتکل حذف روبات ها (Robots Exclusion Protocol)" به ترتیب به صورت پیش فرض `INDEX,FOLLOW` در نظر گرفته می شود. بنابراین، دو ورودی معتبر دیگر که توسط "پروتکل حذف روبات ها" تعریف شده اند با پیشوند `...NO` یعنی `NOINDEX` و `NOFOLLOW` هستند. 79 | 80 | بر اساس دستور(های) Disallow فهرست شده در فایل `robots.txt` در webroot، جستجوی عبارات منظم برای `"META NAME="ROBOTS>` در هر صفحه وب انجام می شود. سپس نتیجه با فایل `robots.txt` در webroot مقایسه می شود. 81 | 82 | #### تگ های متفرقه اطلاعاتی متا (Miscellaneous META Information Tags) 83 | 84 | سازمان ها اغلب متاتگ های اطلاعاتی (informational META tags) را در محتوای وب تعبیه می کنند تا از فناوری های مختلفی مانند صفحه خوان ها، پیش نمایش شبکه های اجتماعی، فهرست سازی موتورهای جستجو و غیره پشتیبانی کنند. چنین فرااطلاعاتی می تواند برای آزمایش کنندگان در شناسایی فناوری های مورد استفاده، و مسیرها/کارکردهای اضافی برای کاوش و آزمایش ارزشمند باشد. متا اطلاعات (meta information) زیر از `www.whitehouse.gov` طریق View Page Source در 5 مه 2020 بازیابی شده است: 85 | 86 | ```html 87 | ... 88 | 89 | 90 | 91 | 92 | 93 | 94 | 95 | 96 | 97 | 98 | 99 | 100 | 101 | 102 | 103 | ... 104 | 105 | 106 | 107 | 108 | ... 109 | ``` 110 | 111 | ### نقشه های سایت (Sitemaps) 112 | 113 | نقشه سایت (sitemap) فایلی است که در آن یک توسعه دهنده یا سازمان می تواند اطلاعاتی در مورد صفحات، ویدیوها و سایر فایل های ارائه شده توسط سایت یا برنامه و ارتباط بین آنها ارائه دهد. موتورهای جستجو می توانند از این فایل برای پیمایش موثرتر سایت شما استفاده کنند. به همین ترتیب، آزمایش کنندگان می توانند از فایل های `sitemap.xml` برای به دست آوردن بینش عمیق تر در مورد سایت یا برنامه تحت بررسی استفاده کنند. 114 | 115 | گزیده زیر از نقشه سایت اصلی گوگل است که در 5 می 2020 بازیابی شده است. 116 | 117 | ```xml 118 | $ wget --no-verbose https://www.google.com/sitemap.xml && head -n8 sitemap.xml 119 | 2020-05-05 12:23:30 URL:https://www.google.com/sitemap.xml [2049] -> "sitemap.xml" [1] 120 | 121 | 122 | 123 | 124 | https://www.google.com/gmail/sitemap.xml 125 | 126 | 127 | https://www.google.com/forms/sitemaps.xml 128 | 129 | ... 130 | ``` 131 | 132 | با کاوش از آنجا، آزمایش کننده ممکن است بخواهد نقشه سایت gmail را بازیابی کند `https://www.google.com/gmail/sitemap.xml`: 133 | 134 | ```xml 135 | 136 | 137 | 138 | https://www.google.com/intl/am/gmail/about/ 139 | 140 | 141 | 142 | 143 | ... 144 | ``` 145 | 146 | ###
TXT امنیتی (Security TXT)
147 | 148 | ا [security.txt](https://securitytxt.org) توسط IETF به عنوان [RFC 9116 - یک فرمت فایل برای کمک به افشای آسیب پذیری های امنیتی](https://www.rfc-editor.org/rfc/rfc9116.html) تصویب شد که به سایت ها اجازه می دهد تا سیاست های امنیتی و جزئیات تماس را تعریف کنند. دلایل متعددی وجود دارد که چرا این ممکن است در سناریوهای آزمایشی جالب باشد، که شامل اما نه محدود به: 149 | 150 | - شناسایی مسیرها یا منابع بیشتر برای گنجاندن در کشف/تحلیل. 151 | - جمع آوری اطلاعات منبع باز. 152 | - یافتن اطلاعات در مورد Bug Bounties و غیره. 153 | - مهندسی اجتماعی. 154 | 155 | فایل ممکن است در ریشه وب سرور یا دایرکتوری `/well-known.` وجود داشته باشد، به عنوان مثال: 156 | 157 | - `https://example.com/security.txt` 158 | - `https://example.com/.well-known/security.txt` 159 | 160 | در اینجا یک نمونه دنیای واقعی است که از LinkedIn در 5 مه 2020 بازیابی شده است: 161 | 162 | ```bash 163 | $ wget --no-verbose https://www.linkedin.com/.well-known/security.txt && cat security.txt 164 | 2020-05-07 12:56:51 URL:https://www.linkedin.com/.well-known/security.txt [333/333] -> "security.txt" [1] 165 | # Conforms to IETF `draft-foudil-securitytxt-07` 166 | Contact: mailto:security@linkedin.com 167 | Contact: https://www.linkedin.com/help/linkedin/answer/62924 168 | Encryption: https://www.linkedin.com/help/linkedin/answer/79676 169 | Canonical: https://www.linkedin.com/.well-known/security.txt 170 | Policy: https://www.linkedin.com/help/linkedin/answer/62924 171 | ``` 172 | 173 | ###
TXT انسان ها (Humans TXT)
174 | 175 | ا `humans.txt` ابتکاری برای شناخت افراد پشت سایت است. این به شکل یک فایل متنی است که حاوی اطلاعاتی در مورد افراد مختلفی است که در ساخت سایت مشارکت داشته اند. این فایل اغلب (اما نه همیشه) حاوی اطلاعات مرتبط به مشاغل یا سایت‌ها/مسیرهای شغلی است. 176 | 177 | مثال زیر در 5 مه 2020 از Google بازیابی شده است: 178 | 179 | ```bash 180 | $ wget --no-verbose https://www.google.com/humans.txt && cat humans.txt 181 | 2020-05-07 12:57:52 URL:https://www.google.com/humans.txt [286/286] -> "humans.txt" [1] 182 | Google is built by a large team of engineers, designers, researchers, robots, and others in many different sites across the globe. It is updated continuously, and built with more tools and technologies than we can shake a stick at. If you'd like to help us out, see careers.google.com. 183 | ``` 184 | 185 | ### سایر منابع اطلاعاتی well-known. 186 | 187 | ا RFC ها و پیش نویس های اینترنتی دیگری نیز وجود دارند که استفاده استاندارد شده از فایل ها را در `/well-known.` دایرکتوری پیشنهاد می کنند. لیست آنها را می توانید در [اینجا](https://en.wikipedia.org/wiki/List_of_/.well-known/_services_offered_by_webservers) یا [اینجا](https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml) پیدا کنید. 188 | 189 | بررسی RFC یا پیش نویس ها و ایجاد فهرستی برای ارائه به یک خزنده یا fuzzer برای یک آزمایش کننده نسبتاً ساده است تا وجود یا محتوای چنین فایل هایی را تأیید کند. 190 | 191 | ## ابزارها 192 | 193 | - Browser (View Source or Dev Tools functionality) 194 | - curl 195 | - wget 196 | - Burp Suite 197 | - ZAP 198 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/01-Information_Gathering/06-Identify_Application_Entry_Points.md: -------------------------------------------------------------------------------- 1 | # Identify Application Entry Points (fa-IR) 2 | 3 | شناسایی نقاط ورودی برنامه (فارسی) 4 | 5 | |شناسه | 6 | |------------| 7 | |WSTG-INFO-06| 8 | 9 | ## خلاصه 10 | 11 | برشمردن برنامه و سطح حمله آن یک پیشرو کلیدی قبل از انجام هر گونه آزمایش کامل است، زیرا به آزمایش کننده اجازه می دهد نقاط ضعف احتمالی را شناسایی کند. هدف این بخش کمک به شناسایی و ترسیم مناطق درون برنامه است که باید پس از تکمیل شمارش و نقشه برداری بررسی شوند. 12 | 13 | ## اهداف آزمایش 14 | 15 | - نقاط ورود و تزریق احتمالی را از طریق تجزیه و تحلیل درخواست و پاسخ شناسایی کنید. 16 | 17 | ## چگونه آزمایش کنیم 18 | 19 | قبل از شروع هر آزمایشی، آزمایش کننده باید همیشه درک خوبی از برنامه و نحوه ارتباط کاربر و مرورگر با آن داشته باشد. هنگامی که آزمایش کننده در برنامه قدم می زند، باید به تمام درخواست های HTTP و همچنین هر پارامتر و فیلد فرمی که به برنامه ارسال می شود توجه کند. باید توجه ویژه ای به زمان استفاده از درخواست های GET و زمان استفاده از درخواست های POST برای ارسال پارامترها به برنامه داشته باشد. علاوه بر این، همچنین باید به زمان استفاده از روش های دیگر برای خدمات RESTful توجه کنند. 20 | 21 | توجه داشته باشید که برای دیدن پارامترهای ارسال شده در بدنه درخواست ها مانند درخواست POST، آزمایش کننده ممکن است بخواهد از ابزاری مانند یک پروکسی رهگیری (intercepting proxy) استفاده کند (به [ابزارها](#ابزارها) مراجعه کنید). در درخواست POST، آزمایش کننده باید هر فیلد فرم پنهانی را که به برنامه ارسال می شود، یادداشت ویژه ای داشته باشد، زیرا این فیلدها معمولاً حاوی اطلاعات حساسی هستند، مانند اطلاعات وضعیت، تعداد اقلام، قیمت اقلام، در نظر گرفته شده برای هر کسی که ببیند یا تغییر دهد. که توسعه دهنده هرگز آن ها را ندارد. 22 | 23 | در تجربه نویسنده، استفاده از یک پروکسی رهگیری و یک صفحه گسترده برای این مرحله از آزمایش بسیار مفید بوده است. پروکسی هر درخواست و پاسخی را که بین آزمایش کننده و برنامه بررسی می کند، پیگیری می کند. علاوه بر این، در این مرحله، آزمایش کننده ها معمولاً هر درخواست و پاسخی را به دام می اندازند تا بتوانند دقیقاً هر هدر، پارامتر و غیره ای را که به برنامه ارسال می شود و آنچه برگردانده می شود، ببینند. این ممکن است گاهی اوقات بسیار خسته کننده باشد، به خصوص در سایت های تعاملی بزرگ (به یک برنامه بانکی فکر کنید). با این حال، تجربه نشان خواهد داد که به دنبال چه چیزی باشید و این مرحله می تواند به میزان قابل توجهی کاهش یابد. 24 | 25 | وقتی آزمایش کننده در برنامه قدم می زند، باید هر پارامتر جالب در URL، سرصفحه های سفارشی یا بدنه درخواست ها/پاسخ ها را یادداشت کند و آنها را در صفحه گسترده ذخیره کند. صفحه گسترده باید شامل صفحه درخواست شده باشد (ممکن است خوب باشد که شماره درخواست از پروکسی را نیز برای مراجعات بعدی اضافه کنید)، پارامترهای جالب، نوع درخواست (GET، POST و غیره)، اگر دسترسی احراز هویت یا احراز هویت نشده باشد، اگر از TLS استفاده می شود، اگر بخشی از یک فرآیند چند مرحله ای است، اگر از WebSockets استفاده می شود، و هر یادداشت مرتبط دیگری. هنگامی که آنها هر منطقه از برنامه را ترسیم کردند، سپس می توانند برنامه را مرور کنند و هر یک از مناطقی را که شناسایی کرده اند آزمایش کنند و یادداشت برداری کنند که چه چیزی کار می کند و چه چیزی کار نکرده است. بقیه این راهنما نحوه آزمایش هر یک از این زمینه های مورد علاقه را مشخص می کند. 26 | 27 | در زیر برخی از نکات مورد علاقه برای همه درخواست ها و پاسخ ها آمده است. در بخش درخواست ها، روی روش های GET و POST تمرکز کنید، زیرا این روش ها اکثر درخواست ها را نشان می دهند. توجه داشته باشید که از روش های دیگری مانند PUT و DELETE نیز می توان استفاده کرد. اغلب، این درخواست های نادرتر، اگر مجاز باشند، می توانند آسیب پذیری ها را آشکار کنند. بخش ویژه ای در این راهنما برای آزمایش این روش های HTTP اختصاص داده شده است. 28 | 29 | ### درخواست ها 30 | 31 | - محل استفاده از GET و محل استفاده از POST را مشخص کنید. 32 | - تمام پارامترهای مورد استفاده در یک درخواست POST را شناسایی کنید (این پارامترها در بدنه درخواست هستند). 33 | - در درخواست POST، به پارامترهای پنهان توجه ویژه ای داشته باشید. هنگامی که یک POST ارسال می شود، تمام فیلدهای فرم (از جمله پارامترهای پنهان) در متن پیام HTTP به برنامه ارسال می شود. اینها معمولاً دیده نمی شوند مگر اینکه از یک پروکسی یا مشاهده کد منبع HTML استفاده شود. علاوه بر این، صفحه بعدی نشان داده شده، داده های آن و سطح دسترسی بسته به مقدار پارامتر(های) پنهان می تواند متفاوت باشد. 34 | - تمام پارامترهای مورد استفاده در یک درخواست GET (یعنی URL)، به ویژه رشته کوئری (معمولاً پس از علامت ?) را شناسایی کنید. 35 | - تمام پارامترهای رشته پرس و جو را شناسایی کنید. اینها معمولاً در قالب جفت هستند، مانند `foo=bar`. همچنین توجه داشته باشید که بسیاری از پارامترها می توانند در یک رشته پرس و جو باشند، مثلاً با یک `&`, `~\`, `:` یا هر کاراکتر خاص یا رمزگذاری دیگری از هم جدا شوند. 36 | - یک نکته خاص در مورد شناسایی چند پارامتر در یک رشته یا در یک درخواست POST این است که برخی یا همه پارامترها برای اجرای حملات مورد نیاز خواهند بود. آزمایش کننده باید تمام پارامترها را شناسایی کند (حتی اگر رمزگذاری شده باشد) و شناسایی کند که کدام یک توسط برنامه پردازش می شوند. بخش های بعدی راهنما نحوه آزمایش این پارامترها را مشخص می کند. در این مرحله، فقط مطمئن شوید که هر یک از آنها شناسایی شده است. 37 | - همچنین به هر نوع هدر اضافی یا سفارشی که معمولاً دیده نمی شود توجه کنید (مانند `debug: false`). 38 | 39 | ### پاسخ ها 40 | 41 | - محل تنظیم کوکی های جدید (`Set-Cookie` سرصفحه (هدر))، اصلاح یا اضافه شدن به آن را مشخص کنید. 42 | - در طول پاسخ های معمولی (یعنی درخواست های اصلاح نشده) مکان هایی را که تغییر مسیرها وجود دارد (کد وضعیت HTTP 3xx)، کد وضعیت 400، به ویژه 403 ممنوعه (Forbidden)، و 500 خطای داخلی سرور (internal server errors) وجود دارد. 43 | - همچنین توجه داشته باشید که در کجا از هدرهای جالب استفاده می شود. به عنوان مثال، `Server: BIG-IP` نشان می دهد که سایت دارای بار متعادل است. بنابراین، اگر یک سایت دارای بار متعادل باشد و یک سرور به درستی پیکربندی نشده باشد، ممکن است آزمایش کننده مجبور باشد بسته به نوع متعادل سازی بار مورد استفاده، چندین درخواست برای دسترسی به سرور آسیب پذیر ارائه دهد. 44 | 45 | ### آشکارساز سطح حمله OWASP ‫(OWASP Attack Surface Detector) 46 | 47 | ابزار Attack Surface Detector (ASD) کد منبع را بررسی می کند و نقاط پایانی یک برنامه وب، پارامترهایی که این نقاط پایانی می پذیرند و نوع داده آن پارامترها را آشکار می کند. این شامل نقاط پایانی بدون پیوندی است که عنکبوت قادر به یافتن آن نخواهد بود یا پارامترهای اختیاری که کاملاً در کد سمت مشتری (client-side) استفاده نشده اند. همچنین این قابلیت را دارد که تغییرات سطح حمله را بین دو نسخه از یک برنامه محاسبه کند. 48 | 49 | آشکارساز سطح حمله به عنوان یک پلاگین (افزونه) برای ZAP و Burp Suite در دسترس است و یک ابزار خط فرمان نیز در دسترس است. ابزار خط فرمان سطح حمله را به عنوان یک خروجی JSON صادر می کند، که سپس می تواند توسط افزونه ZAP و Burp Suite استفاده شود. این برای مواردی مفید است که کد منبع مستقیماً در اختیار آزمایش کننده نفوذ قرار نمی گیرد. برای مثال، آزمایش کننده نفوذ می تواند فایل خروجی json را از مشتری (client) دریافت کند که نمی خواهد خود کد منبع را ارائه کند. 50 | 51 | ### نحوه استفاده 52 | 53 | فایل CLI jar برای دانلود از [https://github.com/secdec/attack-surface-detector-cli/releases](https://github.com/secdec/attack-surface-detector-cli/releases) در دسترس است. 54 | 55 | می توانید دستور زیر را برای ASD اجرا کنید تا نقاط پایانی را از کد منبع برنامه وب مورد نظر شناسایی کنید. 56 | 57 | `java -jar attack-surface-detector-cli-1.3.5.jar [flags]` 58 | 59 | در اینجا مثالی از اجرای دستور در برابر [OWASP RailsGoat](https://github.com/OWASP/railsgoat) آورده شده است. 60 | 61 | ```text 62 | $ java -jar attack-surface-detector-cli-1.3.5.jar railsgoat/ 63 | Beginning endpoint detection for '<...>/railsgoat' with 1 framework types 64 | Using framework=RAILS 65 | [0] GET: /login (0 variants): PARAMETERS={url=name=url, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/controllers/sessions_contro 66 | ller.rb (lines '6'-'9') 67 | [1] GET: /logout (0 variants): PARAMETERS={}; FILE=/app/controllers/sessions_controller.rb (lines '33'-'37') 68 | [2] POST: /forgot_password (0 variants): PARAMETERS={email=name=email, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/controllers/ 69 | password_resets_controller.rb (lines '29'-'38') 70 | [3] GET: /password_resets (0 variants): PARAMETERS={token=name=token, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/controllers/p 71 | assword_resets_controller.rb (lines '19'-'27') 72 | [4] POST: /password_resets (0 variants): PARAMETERS={password=name=password, paramType=QUERY_STRING, dataType=STRING, user=name=user, paramType=QUERY_STRING, dataType=STRING, confirm_password=name=confirm_password, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/controllers/password_resets_controller.rb (lines '5'-'17') 73 | [5] GET: /sessions/new (0 variants): PARAMETERS={url=name=url, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/controllers/sessions_controller.rb (lines '6'-'9') 74 | [6] POST: /sessions (0 variants): PARAMETERS={password=name=password, paramType=QUERY_STRING, dataType=STRING, user_id=name=user_id, paramType=SESSION, dataType=STRING, remember_me=name=remember_me, paramType=QUERY_STRING, dataType=STRING, url=name=url, paramType=QUERY_STRING, dataType=STRING, email=name=email, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/controllers/sessions_controller.rb (lines '11'-'31') 75 | [7] DELETE: /sessions/{id} (0 variants): PARAMETERS={}; FILE=/app/controllers/sessions_controller.rb (lines '33'-'37') 76 | [8] GET: /users (0 variants): PARAMETERS={}; FILE=/app/controllers/api/v1/users_controller.rb (lines '9'-'11') 77 | [9] GET: /users/{id} (0 variants): PARAMETERS={}; FILE=/app/controllers/api/v1/users_controller.rb (lines '13'-'15') 78 | ... snipped ... 79 | [38] GET: /api/v1/mobile/{id} (0 variants): PARAMETERS={id=name=id, paramType=QUERY_STRING, dataType=STRING, class=name=class, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/controllers/api/v1/mobile_controller.rb (lines '8'-'13') 80 | [39] GET: / (0 variants): PARAMETERS={url=name=url, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/controllers/sessions_controller.rb (lines '6'-'9') 81 | Generated 40 distinct endpoints with 0 variants for a total of 40 endpoints 82 | Successfully validated serialization for these endpoints 83 | 0 endpoints were missing code start line 84 | 0 endpoints were missing code end line 85 | 0 endpoints had the same code start and end line 86 | Generated 36 distinct parameters 87 | Generated 36 total parameters 88 | - 36/36 have their data type 89 | - 0/36 have a list of accepted values 90 | - 36/36 have their parameter type 91 | --- QUERY_STRING: 35 92 | --- SESSION: 1 93 | Finished endpoint detection for '<...>/railsgoat' 94 | ---------- 95 | -- DONE -- 96 | 0 projects had duplicate endpoints 97 | Generated 40 distinct endpoints 98 | Generated 40 total endpoints 99 | Generated 36 distinct parameters 100 | Generated 36 total parameters 101 | 1/1 projects had endpoints generated 102 | To enable logging include the -debug argument 103 | ``` 104 | 105 | همچنین می توانید یک فایل خروجی JSON با استفاده از پرچم (flag) `json-` ایجاد کنید، که می تواند توسط افزونه برای ZAP و Burp Suite استفاده شود. برای جزئیات بیشتر به لینک های زیر مراجعه کنید. 106 | 107 | - [صفحه اصلی پلاگین ASD برای OWASP ZAP](https://github.com/secdec/attack-surface-detector-zap/wiki) 108 | - [صفحه اصلی پلاگین ASD برای PortSwigger Burp](https://github.com/secdec/attack-surface-detector-burp/wiki) 109 | 110 | ### تست نقاط ورودی برنامه (Testing for Application Entry Points) 111 | 112 | در زیر دو مثال در مورد نحوه بررسی نقاط ورودی برنامه آورده شده است. 113 | 114 | #### مثال 1 115 | 116 | این مثال یک درخواست GET را نشان می دهد که می تواند یک کالا را از یک برنامه خرید آنلاین خریداری کند. 117 | 118 | ```text 119 | GET /shoppingApp/buyme.asp?CUSTOMERID=100&ITEM=z101a&PRICE=62.50&IP=x.x.x.x HTTP/1.1 120 | Host: x.x.x.x 121 | Cookie: SESSIONID=Z29vZCBqb2IgcGFkYXdhIG15IHVzZXJuYW1lIGlzIGZvbyBhbmQgcGFzc3dvcmQgaXMgYmFy 122 | ``` 123 | 124 | > تمام پارامترهای درخواست مانند CUSTOMERID، ITEM، PRICE، IP و Cookie که فقط می توانند پارامترها یا پارامترهای مورد استفاده برای وضعیت جلسه کدگذاری شوند. 125 | 126 | #### مثال 2 127 | 128 | این مثال یک درخواست POST را نشان می دهد که شما را به یک برنامه وارد می کند. 129 | 130 | ```text 131 | POST /example/authenticate.asp?service=login HTTP/1.1 132 | Host: x.x.x.x 133 | Cookie: SESSIONID=dGhpcyBpcyBhIGJhZCBhcHAgdGhhdCBzZXRzIHByZWRpY3RhYmxlIGNvb2tpZXMgYW5kIG1pbmUgaXMgMTIzNA==;CustomCookie=00my00trusted00ip00is00x.x.x.x00 134 | 135 | user=admin&pass=pass123&debug=true&fromtrustIP=true 136 | ``` 137 | 138 | می توان توجه داشت که پارامترها در چندین مکان ارسال می شوند: 139 | 140 | 1. در رشته پرس و جو: `service` 141 | 2. در هدر کوکی: `SESSIONID`, `CustomCookie` 142 | 3. در بدنه درخواست: `user`, `pass`, `debug`,`fromtrustIP` 143 | 144 | وجود انواع مکان های تزریق، فرصت های زنجیره ای را برای مهاجم فراهم می کند که می تواند شانس یافتن یک اشکال در کد مدیریت را افزایش دهد. 145 | 146 | ## ابزارها 147 | 148 | - [OWASP Zed Attack Proxy (ZAP)](https://www.zaproxy.org/) 149 | - [Burp Suite](https://www.portswigger.net/burp/) 150 | - [Fiddler](https://www.telerik.com/fiddler) 151 | 152 | ## منابع 153 | 154 | - [RFC 2616 – Hypertext Transfer Protocol – HTTP 1.1](https://tools.ietf.org/html/rfc2616) 155 | - [OWASP Attack Surface Detector](https://owasp.org/www-project-attack-surface-detector/) 156 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/06-Test_HTTP_Methods.md: -------------------------------------------------------------------------------- 1 | # Test HTTP Methods (fa-IR) 2 | 3 | آزمایش روش های HTTP (فارسی) 4 | 5 | |شناسه | 6 | |------------| 7 | |WSTG-CONF-06| 8 | 9 | ## خلاصه 10 | 11 | ا HTTP تعدادی روش (یا افعال) را ارائه می دهد که می توان از آنها برای انجام اقدامات در وب سرور استفاده کرد. در حالی که GET و POST با اختلاف رایج‌ترین روش‌هایی هستند که برای دسترسی به اطلاعات ارائه‌شده توسط وب سرور استفاده می‌شوند، روش‌های مختلفی نیز وجود دارد که ممکن است پشتیبانی شوند و گاهی اوقات می‌توانند توسط مهاجمان مورد سوء استفاده قرار گیرند. 12 | 13 | ا [RFC 7231](https://datatracker.ietf.org/doc/html/rfc7231) روش های اصلی درخواست معتبر HTTP (یا افعال) را تعریف می کند، اگرچه روش های اضافی در RFC های دیگر مانند [RFC 5789](https://datatracker.ietf.org/doc/html/rfc5789) اضافه شده است. چندین مورد از این افعال برای اهداف مختلف در برنامه‌های [RESTful](https://en.wikipedia.org/wiki/Representational_state_transfer)، که در جدول زیر فهرست شده‌اند، دوباره استفاده شده‌اند. 14 | 15 | | روش | هدف اصلی | RESTful هدف | 16 | |--------|------------------|-----------------| 17 | | [`GET`](https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.1) | درخواست یک فایل | درخواست یک شی| 18 | | [`HEAD`](https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.2) | ‫درخواست یک فایل، اما فقط هدر های HTTP را برمیگرداند | | 19 | | [`POST`](https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.3) | ارسال داده ها | | 20 | | [`PUT`](https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.4) | آپلود یک فایل | ایجاد یک شی | 21 | | [`DELETE`](https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.5) | حذف یک فایل | حذف یک شی | 22 | | [`CONNECT`](https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.6) | برقرار کردن ازتباط با یک سیستم دیگر | | 23 | | [`OPTIONS`](https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.7) | ‫فهرست کردن روش های HTTP پشتیبانی شده | ‫انجام دادن یک درخواست [CORS Preflight](https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request) | 24 | | [`TRACE`](https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.8) | ‫تکرار (Echo) کردن درخواست HTTP برای اهداف اشکال زدایی | | 25 | | [`PATCH`](https://datatracker.ietf.org/doc/html/rfc5789#section-2) | | تغییر دادن یک شی | 26 | 27 | ## اهداف آزمایش 28 | 29 | - روش های HTTP پشتیبانی شده را برشمارید. 30 | - آزمایش بای پس کنترل دسترسی. 31 | - روش های غلبه بر روش HTTP را آزمایش کنید. 32 | 33 | ## چگونه آزمایش کنیم 34 | 35 | ### روش های پشتیبانی شده را کشف کنید (Discover the Supported Methods) 36 | 37 | برای انجام این آزمایش، آزمایش کننده به روشی نیاز دارد تا تشخیص دهد کدام روش های HTTP توسط وب سروری که در حال بررسی است پشتیبانی می شود. ساده ترین راه برای انجام این کار، ارسال یک درخواست `OPTIONS` به سرور است: 38 | 39 | ```http 40 | OPTIONS / HTTP/1.1 41 | Host: example.org 42 | ``` 43 | 44 | سپس سرور باید با لیستی از روش های پشتیبانی شده پاسخ دهد: 45 | 46 | ```http 47 | HTTP/1.1 200 OK 48 | Allow: OPTIONS, GET, HEAD, POST 49 | ``` 50 | 51 | با این حال، برخی از سرورها ممکن است به درخواست های `OPTIONS` پاسخ ندهند، یا ممکن است اطلاعات نادرست را برگردانند. علاوه بر این، سرورها ممکن است از روش‌های مختلفی برای مسیرهای مختلف پشتیبانی کنند - بنابراین فقط به این دلیل که یک روش برای دایرکتوری `/` ریشه (root) پشتیبانی نمی‌شود، لزوماً به این معنی نیست که در جای دیگری پشتیبانی نمی‌شود. 52 | 53 | یک راه مطمئن تر برای آزمایش روش های پشتیبانی شده این است که به سادگی یک درخواست با آن نوع روش ارسال کنید و پاسخ سرور را بررسی کنید. اگر روش مجاز نباشد، سرور باید وضعیت `405 Method Not Allowed` را برگرداند. 54 | 55 | توجه داشته باشید که برخی از سرورها روش‌های ناشناخته را معادل `GET` تلقی می‌کنند، بنابراین ممکن است به روش‌های دلخواه مانند درخواست نشان داده شده در زیر پاسخ دهند. گاهی اوقات این می تواند برای فرار از فایروال برنامه وب یا هر فیلتر دیگری که روش های خاص را مسدود می کند مفید باشد. 56 | 57 | ```http 58 | FOO / HTTP/1.1 59 | Host: example.org 60 | ``` 61 | 62 | درخواست هایی با روش های دلخواه را می توان با استفاده از curl با گزینه `X-` نیز انجام داد: 63 | 64 | ```bash 65 | curl -X FOO https://example.org 66 | ``` 67 | 68 | همچنین انواع مختلفی از ابزارهای خودکار وجود دارند که می توانند روش های پشتیبانی شده را تعیین کنند، مانند [`http-methods`](https://nmap.org/nsedoc/scripts/http-methods.html) اسکریپت Nmap. با این حال، این ابزارها ممکن است روش‌های خطرناک را آزمایش نکنند (یعنی روش‌هایی که ممکن است باعث تغییراتی مانند `PUT` یا `DELETE`) شوند، یا در صورت پشتیبانی از این روش‌ها ممکن است ناخواسته تغییراتی در وب سرور ایجاد کنند. به این ترتیب، آنها باید با احتیاط استفاده شوند. 69 | 70 | ### قرار دادن و حذف (PUT and DELETE) 71 | 72 | متدهای `PUT` و `DELETE` بسته به اینکه توسط وب سرور تفسیر می شوند یا توسط برنامه ای که روی آن اجرا می شود، می توانند اثرات متفاوتی داشته باشند. 73 | 74 | #### وب سرورهای قدیمی (Legacy Web Servers) 75 | 76 | برخی از وب سرورهای قدیمی اجازه استفاده از روش `PUT` را برای ایجاد فایل روی سرور می دادند. برای مثال، اگر سرور به گونه‌ای پیکربندی شده باشد که این اجازه را بدهد، درخواست زیر فایلی را در سرور به نام `test.html` ایجاد می‌کند که حاوی محتویات `` می باشد. 77 | 78 | ```http 79 | PUT /test.html HTTP/1.1 80 | Host: example.org 81 | Content-Length: 25 82 | 83 | 84 | ``` 85 | 86 | درخواست های مشابهی را نیز می توان با cURL انجام داد: 87 | 88 | ```bash 89 | curl https://example.org --upload-file test.html 90 | ``` 91 | 92 | این به مهاجم اجازه می‌دهد تا فایل‌های دلخواه را در وب‌سرور آپلود کند، که در صورت امکان آپلود کدهای اجرایی مانند فایل‌های PHP، به طور بالقوه می‌تواند منجر به خطر افتادن کامل سیستم شود. با این حال، این پیکربندی بسیار نادر است و بعید است در هیچ سیستم مدرنی دیده شود. 93 | 94 | به طور مشابه، روش `DELETE` می تواند برای حذف فایل ها از وب سرور استفاده شود. توجه داشته باشید که این یک اقدام مخرب است، بنابراین هنگام آزمایش این روش باید مراقب باشید. 95 | 96 | ```http 97 | DELETE /test.html HTTP/1.1 98 | Host: example.org 99 | ``` 100 | 101 | یا با cURL: 102 | 103 | ```bash 104 | curl http://example.org/test.html -X DELETE 105 | ``` 106 | 107 | ####
API های RESTful ‫(RESTful APIs)
108 | 109 | در مقابل، روش‌های `PUT` و `DELETE` معمولاً توسط برنامه‌های RESTful مدرن برای ایجاد و حذف اشیا استفاده می‌شوند. به عنوان مثال، درخواست API زیر می تواند برای ایجاد کاربری به نام "foo" با نقش "user" استفاده شود: 110 | 111 | ```http 112 | PUT /api/users/foo HTTP/1.1 113 | Host: example.org 114 | Content-Length: 34 115 | 116 | { 117 | "role": "user" 118 | } 119 | ``` 120 | 121 | یک درخواست مشابه با روش DELETE می تواند برای حذف یک شی استفاده شود. 122 | 123 | ```http 124 | DELETE /api/users/foo HTTP/1.1 125 | Host: example.org 126 | ``` 127 | 128 | اگرچه ممکن است توسط ابزارهای اسکن خودکار گزارش شود، وجود این روش ها در RESTful API یک مشکل امنیتی نیست. با این حال، این عملکرد ممکن است دارای آسیب‌پذیری‌های دیگری باشد (مانند کنترل دسترسی ضعیف)، و باید کاملاً آزمایش شود. 129 | 130 | ### پی گیری (TRACE) 131 | 132 | روش `TRACE` (یا معادل روش `TRACK` مایکروسافت) باعث می شود که سرور محتوای درخواست را بازتاب دهد. این منجر به آسیب‌پذیری به نام Cross-Site Tracing (XST) شد که در سال [2003](https://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf) (PDF) منتشر شد، که می‌توان از آن برای دسترسی به کوکی‌هایی استفاده کرد که دارای پرچم `HttpOnly` هستند (flag set). روش `TRACE` سال‌هاست که در همه مرورگرها و افزونه‌ها مسدود شده است و به همین دلیل این مشکل دیگر قابل استفاده نیست. با این حال، ممکن است همچنان توسط ابزارهای اسکن خودکار علامت گذاری شود، و روش `TRACE` فعال شده در یک وب سرور نشان می دهد که به درستی سخت نشده است. 133 | 134 | ### اتصال (CONNECT) 135 | 136 | روش `CONNECT` باعث می شود وب سرور یک اتصال TCP را به سیستم دیگری باز کند و سپس ترافیک مشتری را به آن سیستم منتقل کند. این می تواند به مهاجم اجازه دهد تا ترافیک پروکسی را از طریق سرور، به منظور پنهان کردن آدرس منبع خود، دسترسی به سیستم های داخلی یا دسترسی به خدماتی که به لوکال هاست متصل هستند، انجام دهد. نمونه ای از یک درخواست `CONNECT` در زیر نشان داده شده است: 137 | 138 | ```http 139 | CONNECT 192.168.0.1:443 HTTP/1.1 140 | Host: example.org 141 | ``` 142 | 143 | ### پچ (PATCH) 144 | 145 | روش `PATCH` در [RFC 5789](https://datatracker.ietf.org/doc/html/rfc5789) تعریف شده است و برای ارائه دستورالعمل‌هایی در مورد چگونگی تغییر یک شی استفاده می‌شود. خود RFC تعریف نمی‌کند که این دستورالعمل‌ها در چه قالبی باید باشند، اما روش‌های مختلفی در استانداردهای دیگر تعریف شده‌اند، مانند [RFC 6902 - JavaScript Object Notation (JSON) Patch](https://datatracker.ietf.org/doc/html/rfc6902). 146 | 147 | به عنوان مثال، اگر کاربری به نام "foo" با ویژگی های زیر داشته باشیم: 148 | 149 | ```json 150 | { 151 | "role": "user", 152 | "email": "foo@example.org" 153 | } 154 | ``` 155 | 156 | درخواست JSON PATCH زیر می تواند برای تغییر نقش این کاربر "admin" بدون تغییر آدرس ایمیل استفاده شود: 157 | 158 | ```http 159 | PATCH /api/users/foo HTTP/1.1 160 | Host: example.org 161 | 162 | { "op": "replace", "path": "/role", "value": "admin" } 163 | ``` 164 | 165 | اگرچه RFC بیان می‌کند که باید شامل دستورالعمل‌هایی برای نحوه اصلاح شی (object) باشد، روش `PATCH` معمولاً برای گنجاندن محتوای تغییر یافته استفاده می‌شود، همانطور که در زیر نشان داده شده است. مانند درخواست قبلی، این مقدار "role" را بدون تغییر بقیه شی به "admin" تغییر می‌دهد. این برخلاف روش `PUT` است که کل شی را بازنویسی می‌کند (و در نتیجه منجر به یک شی بدون ویژگی "email" می‌شود). 166 | 167 | ```http 168 | PATCH /api/users/foo HTTP/1.1 169 | Host: example.org 170 | 171 | { 172 | "role": "admin" 173 | } 174 | ``` 175 | 176 | مانند روش `PUT`، این عملکرد ممکن است دارای ضعف های کنترل دسترسی یا آسیب پذیری های دیگر باشد. به‌علاوه، برنامه‌ها ممکن است در هنگام تغییر یک شی، همان سطح اعتبارسنجی ورودی را انجام ندهند که هنگام ایجاد آن انجام می‌دهند. این می تواند به طور بالقوه اجازه تزریق مقادیر مخرب را بدهد (مانند یک حمله اسکریپت نویسی بین سایتی ذخیره شده (stored cross-site scripting attack))، یا می تواند به اشیاء شکسته یا نامعتبر اجازه دهد که ممکن است منجر به مشکلات مربوط به منطق تجاری (business logic) شود. 177 | 178 | ### آزمایش بای پس کنترل دسترسی (Testing for Access Control Bypass) 179 | 180 | اگر صفحه ای در برنامه زمانی که کاربران تلاش می کنند و مستقیماً به آن دسترسی پیدا می کنند، به صفحه ورود با کد `302` هدایت می کند، ممکن است بتوان با درخواست با روش HTTP متفاوت، مانند `HEAD`، `POST` یا حتی یک روش ساخته شده مانند `FOO`، اگر برنامه وب با `HTTP/1.1 200 OK` به جای `HTTP/1.1 302 Found` مورد انتظار پاسخ دهد، ممکن است امکان دور زدن احراز هویت یا مجوز وجود داشته باشد. مثال زیر نشان می‌دهد که چگونه درخواست `HEAD` ممکن است منجر به تنظیم صفحه کوکی‌های مدیریتی به جای هدایت کاربر به صفحه ورود به سیستم شود: 181 | 182 | ```http 183 | HEAD /admin/ HTTP/1.1 184 | Host: example.org 185 | ``` 186 | 187 | ```http 188 | HTTP/1.1 200 OK 189 | [...] 190 | Set-Cookie: adminSessionCookie=[...]; 191 | ``` 192 | 193 | از طرف دیگر، ممکن است درخواست مستقیم به صفحاتی که باعث عملکرد می شوند وجود داشته باشد، مانند: 194 | 195 | ```http 196 | HEAD /admin/createUser.php?username=foo&password=bar&role=admin HTTP/1.1 197 | Host: example.org 198 | ``` 199 | 200 | یا: 201 | 202 | ```http 203 | FOO /admin/createUser.php 204 | Host: example.org 205 | Content-Length: 36 206 | 207 | username=foo&password=bar&role=admin 208 | ``` 209 | 210 | ### آزمایش برای نادیده گرفتن روش HTTP ‫(Testing for HTTP Method Overriding) 211 | 212 | برخی از چارچوب‌های وب راهی برای نادیده گرفتن روش HTTP واقعی در درخواست با شبیه‌سازی افعال HTTP از دست رفته و ارسال سرصفحه سفارشی در درخواست‌ها ارائه می‌کنند. هدف اصلی از این کار دور زدن یک برنامه میان افزاری (مانند فایروال پروکسی یا برنامه وب) است که روش های خاصی را مسدود می کند. هدرهای جایگزین HTTP زیر به طور بالقوه می توانند مورد استفاده قرار گیرند: 213 | 214 | - `X-HTTP-Method` 215 | - `X-HTTP-Method-Override` 216 | - `X-Method-Override` 217 | 218 | به منظور آزمایش این، در سناریوهایی که افعال محدود شده مانند `PUT` یا `DELETE` یک `405 Method not allowed` را برمی‌گردانند، همان درخواست را با اضافه کردن سرصفحه‌های جایگزین برای نادیده گرفتن روش HTTP دوباره پخش کنید و مشاهده کنید که سیستم چگونه پاسخ می‌دهد. برنامه باید با یک کد وضعیت متفاوت پاسخ دهد (به عنوان مثال `200 OK`) در مواردی که نادیده گرفتن روش پشتیبانی می شود. 219 | 220 | وب سرور در مثال زیر به روش `DELETE` اجازه نمی دهد و آن را مسدود می کند: 221 | 222 | ```http 223 | DELETE /resource.html HTTP/1.1 224 | Host: example.org 225 | ``` 226 | 227 | ```http 228 | HTTP/1.1 405 Method Not Allowed 229 | [...] 230 | ``` 231 | 232 | پس از افزودن هدر `X-HTTP-Method`، سرور با 200 به درخواست پاسخ می دهد: 233 | 234 | ```http 235 | GET /resource.html HTTP/1.1 236 | Host: example.org 237 | X-HTTP-Method: DELETE 238 | ``` 239 | 240 | ```http 241 | HTTP/1.1 200 OK 242 | [...] 243 | ``` 244 | 245 | ## اصلاح 246 | 247 | - مطمئن شوید که فقط روش های مورد نیاز مجاز هستند و روش های مجاز به درستی پیکربندی شده اند. 248 | - اطمینان حاصل کنید که هیچ راه حلی برای دور زدن اقدامات امنیتی اجرا شده توسط عوامل کاربر، چارچوب ها یا سرورهای وب اجرا نمی شود. 249 | 250 | ## ابزارها 251 | 252 | - [Ncat](https://nmap.org/ncat/) 253 | - [cURL](https://curl.haxx.se/) 254 | - [Nmap http-methods NSE script](https://nmap.org/nsedoc/scripts/http-methods.html) 255 | 256 | ## منابع 257 | 258 | - [RFC 7231 - Hypertext Transfer Protocol (HTTP/1.1)](https://datatracker.ietf.org/doc/html/rfc7231) 259 | - [RFC 5789 - PATCH Method for HTTP](https://datatracker.ietf.org/doc/html/rfc5789) 260 | - [HTACCESS: BILBAO Method Exposed](https://web.archive.org/web/20160616172703/http://www.kernelpanik.org/docs/kernelpanik/bme.eng.pdf) 261 | - [Fortify - Misused HTTP Method Override](https://vulncat.fortify.com/en/detail?id=desc.dynamic.xtended_preview.often_misused_http_method_override) 262 | - [Mozilla Developer Network - Safe HTTP Methods](https://developer.mozilla.org/en-US/docs/Glossary/Safe/HTTP) 263 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/01-Information_Gathering/10-Map_Application_Architecture.md: -------------------------------------------------------------------------------- 1 | # Map Application Architecture (fa-IR) 2 | 3 | معماری برنامه نقشه (فارسی) 4 | 5 | |شناسه | 6 | |------------| 7 | |WSTG-INFO-10| 8 | 9 | ## خلاصه 10 | 11 | برای اینکه به طور موثر یک برنامه را آزمایش کنید و بتوانید توصیه های معناداری در مورد نحوه رسیدگی به هر یک از مسائل شناسایی شده ارائه دهید، مهم است که بفهمید واقعاً چه چیزی را آزمایش می کنید. علاوه بر این، می تواند به تعیین اینکه آیا اجزای خاص باید خارج از محدوده آزمایش در نظر گرفته شوند، کمک کند. 12 | 13 | برنامه های وب مدرن می توانند به طور قابل توجهی از نظر پیچیدگی متفاوت باشند، از یک اسکریپت ساده که روی یک سرور واحد اجرا می شود تا یک برنامه بسیار پیچیده که در ده ها سیستم، زبان و مؤلفه مختلف پخش شده است. همچنین ممکن است اجزای دیگری در سطح شبکه مانند فایروال ها یا سیستم های حفاظت از نفوذ وجود داشته باشد که می تواند تأثیر قابل توجهی در آزمایش داشته باشد. 14 | 15 | ## اهداف آزمایش 16 | 17 | - معماری برنامه و فناوری های مورد استفاده را درک کنید. 18 | 19 | ## چگونه آزمایش کنیم 20 | 21 | هنگام آزمایش از منظر جعبه سیاه، مهم است که سعی کنید تصویر واضحی از نحوه عملکرد برنامه و اینکه چه فناوری ها و مؤلفه هایی در آن وجود دارند ایجاد کنید. در برخی موارد امکان آزمایش اجزای خاص (مانند فایروال برنامه وب) وجود دارد، در حالی که برخی دیگر را می توان با بررسی رفتار برنامه شناسایی کرد. 22 | 23 | بخش های زیر یک نمای کلی از اجزای معماری رایج را به همراه جزئیات نحوه شناسایی آنها ارائه می دهد. 24 | 25 | ### اجزای برنامه (Application Components) 26 | 27 | #### وب سرور (Web Server) 28 | 29 | برنامه های ساده ممکن است روی یک سرور اجرا شوند که با استفاده از مراحلی که در بخش [Fingerprint Web Server](02-Fingerprint_Web_Server.md) در راهنما توضیح داده شده است، قابل شناسایی هستند. 30 | 31 | #### پلتفرم به عنوان سرویس ‫(PaaS) (Platform-as-a-Service (PaaS)) 32 | 33 | در مدل پلتفرم به عنوان سرویس (PaaS)، وب سرور و زیرساخت های زیربنایی توسط ارائه دهنده خدمات مدیریت می شوند و مشتری فقط مسئول برنامه ای است که این برنامه بر روی آنها مستقر شده است. از دیدگاه آزمایش، دو تفاوت اصلی وجود دارد: 34 | 35 | - مالک برنامه به زیرساخت اصلی دسترسی ندارد، بنابراین نمی تواند مستقیماً هیچ مشکلی را برطرف کند. 36 | - آزمایش زیرساخت به احتمال زیاد خارج از محدوده هر گونه تعاملی است. 37 | 38 | در برخی موارد، شناسایی استفاده از PaaS امکان پذیر است، زیرا ممکن است برنامه از یک نام دامنه خاص استفاده کند (به عنوان مثال، برنامه های مستقر در Azure App Services یک دامنه `azurewebsites.net.*` دارند - اگرچه ممکن است از دامنه های سفارشی نیز استفاده کنند). با این حال، در موارد دیگر، تعیین اینکه آیا PaaS در حال استفاده است یا خیر دشوار است. 39 | 40 | #### بدون سرور (Serverless) 41 | 42 | در یک مدل بدون سرور، توسعه دهندگان کدی را ارائه می کنند که مستقیماً بر روی یک پلتفرم میزبانی به عنوان توابع جداگانه اجرا می شود، نه به عنوان یک برنامه وب بزرگتر سنتی که در وبروت (webroot) مستقر شده است. این باعث می شود آن را به خوبی برای معماری های مبتنی بر میکروسرویس مناسب کند. همانند محیط PaaS، آزمایش زیرساخت احتمالاً خارج از محدوده است. 43 | 44 | در برخی موارد استفاده از کد بدون سرور ممکن است با وجود هدرهای خاص HTTP نشان داده شود. به عنوان مثال، توابع AWS Lambda معمولاً هدرهای زیر را برمی گرداند: 45 | 46 | ```text 47 | X-Amz-Invocation-Type 48 | X-Amz-Log-Type 49 | X-Amz-Client-Context 50 | ``` 51 | 52 | توابع Azure کمتر آشکار هستند. آنها معمولاً هدر `Server: Kestrel` را برمی گردانند - اما این به تنهایی برای اطمینان از اینکه یک تابع Azure App است، به جای کد دیگری که روی Kestrel اجرا می شود کافی نیست. 53 | 54 | #### میکروسرویس ها (Microservices) 55 | 56 | در معماری مبتنی بر میکروسرویس، API برنامه از چندین سرویس گسسته تشکیل شده است، نه اینکه به عنوان یک برنامه یکپارچه اجرا شود. خود سرویس ها اغلب در داخل کانتینرها (معمولاً با Kubernetes) اجرا می شوند و می توانند از سیستم عامل ها و زبان های مختلف استفاده کنند. اگرچه آنها معمولاً پشت یک دروازه و دامنه API واحد قرار دارند، استفاده از چندین زبان (اغلب در پیام های خطای دقیق نشان داده می شود) می تواند نشان دهد که میکروسرویس ها در حال استفاده هستند. 57 | 58 | #### ذخیره سازی استاتیک (Static Storage) 59 | 60 | بسیاری از برنامه ها محتوای ثابت را به جای میزبانی مستقیم بر روی سرور اصلی وب، بر روی پلتفرم های ذخیره سازی اختصاصی ذخیره می کنند. دو پلتفرم متداول عبارتند از Amazon's S3 Buckets و Azure's Storage Accounts و به راحتی با نام دامنه قابل شناسایی هستند: 61 | 62 | - سطل های S3 آمازون (Amazon S3 Buckets) `BUCKET.s3.amazonaws.com` یا `s3.REGION.amazonaws.com/BUCKET` هستند 63 | - حساب های ذخیره سازی Azure (یا Azure Storage Accounts) `ACCOUNT.blob.core.windows.net` هستند 64 | 65 | این حساب‌های ذخیره‌سازی اغلب می‌توانند فایل‌های حساس را افشا کنند، همانطور که در بخش [Testing Cloud Storage Guide](../02-Configuration_and_Deployment_Management_Testing/11-Test_Cloud_Storage.md) بحث شد. 66 | 67 | #### پایگاه داده (Database) 68 | 69 | اکثر برنامه های وب غیر پیش پا افتاده از نوعی پایگاه داده برای ذخیره محتوای پویا استفاده می کنند. در برخی موارد امکان تعیین پایگاه داده وجود دارد، اگرچه معمولاً به مسائل دیگر در برنامه متکی است. این اغلب می تواند توسط: 70 | 71 | - پورت سرور را اسکن می کند و به دنبال هر پورت باز مرتبط با پایگاه داده خاص است. 72 | - راه‌اندازی پیام‌های خطای مرتبط با SQL (یا NoSQL) (یا یافتن خطاهای موجود از [موتور جستجو](../01-Information_Gathering/01-Conduct_Search_Engine_Discovery_Reconnaissance_for_Information_Leakage.md)). 73 | 74 | در مواردی که تعیین قطعی پایگاه داده امکان پذیر نیست، اغلب می توانید بر اساس سایر جنبه های برنامه حدس درستی بزنید: 75 | 76 | - ا Windows، IIS و ASP.NET اغلب از سرور Microsoft SQL استفاده می کنند. 77 | - ا سیستم های جاسازی شده اغلب از SQLite استفاده می کنند. 78 | - ا PHP اغلب از MySQL یا PostgreSQL استفاده می کند. 79 | - ا APEX اغلب از Oracle استفاده می کند. 80 | 81 | اینها قوانین سختی نیستند، اما اگر اطلاعات بهتری در دسترس نباشند، مطمئناً می توانند نقطه شروع معقولی به شما بدهند. 82 | 83 | #### احراز هویت (Authentication) 84 | 85 | اکثر برنامه ها دارای نوعی احراز هویت برای کاربران هستند. چندین بک اند های (back ends) احراز هویت وجود دارد که می توان از آنها استفاده کرد، مانند: 86 | 87 | - پیکربندی وب سرور (از جمله فایل های `htaccess.`) یا رمزهای عبور سخت کدگذاری شده در اسکریپت ها. 88 | - معمولاً به عنوان احراز هویت پایه HTTP نشان داده می شود که با یک پنجره بازشو (pop-up) در مرورگر و یک HTTP هدر `WWW-Authenticate: Basic` نشان داده می شود. 89 | - حساب های کاربری محلی در پایگاه داده. 90 | - معمولاً در یک فرم یا نقطه پایانی (endpoint) API در برنامه یکپارچه می شود. 91 | - یک منبع احراز هویت مرکزی موجود مانند اکتیو دایرکتوری یا یک سرور LDAP. 92 | - ممکن است از احراز هویت NTLM استفاده کند که با HTTP هدر `WWW-Authenticate: NTLM` نشان داده شده است. 93 | - ممکن است در یک فرم به برنامه وب ادغام شود. 94 | - ممکن است نیاز باشد که نام کاربری در قالب "DOMAIN\username" وارد شود، یا ممکن است فهرستی از دامنه های موجود ارائه شود. 95 | - Single Sign-On (SSO) با ارائه دهنده داخلی یا خارجی. 96 | - معمولاً از OAuth، OpenID Connect یا SAML استفاده می‌کند. 97 | 98 | برنامه‌ها ممکن است گزینه‌های متعددی را برای احراز هویت کاربر فراهم کنند (مانند ثبت یک حساب محلی یا استفاده از حساب فیس‌بوک موجود خود)، و ممکن است از مکانیسم‌های مختلفی برای کاربران و مدیران عادی استفاده کنند. 99 | 100 | #### خدمات و APIهای شخص ثالث (Third Party Services and APIs) 101 | 102 | تقریباً همه برنامه‌های وب شامل منابع شخص ثالثی هستند که توسط مشتری بارگذاری می‌شوند یا با آنها تعامل دارند. این موارد می تواند شامل موارد زیر باشد: 103 | 104 | - محتوای فعال ([Active content](https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content#mixed_active_content)) (مانند اسکریپت ها، شیوه نامه ها، فونت ها و iframe ها). 105 | - محتوای غیرفعال ([Passive content](https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content#mixed_passivedisplay_content)) (مانند تصاویر و ویدیوها). 106 | - API های خارجی 107 | - دکمه های رسانه های اجتماعی 108 | - شبکه های تبلیغاتی 109 | - درگاه های پرداخت 110 | 111 | این منابع مستقیماً توسط مرورگر کاربر درخواست می شوند، بنابراین با استفاده از ابزارهای توسعه دهنده یا یک پروکسی رهگیری به راحتی قابل شناسایی هستند. در حالی که شناسایی آنها مهم است (زیرا می توانند بر امنیت برنامه تأثیر بگذارند)، به یاد داشته باشید که آنها معمولاً خارج از محدوده آزمایش هستند، زیرا متعلق به اشخاص ثالث هستند. 112 | 113 | ### اجزای شبکه (Network Components) 114 | 115 | #### پروکسی معکوس (Reverse Proxy) 116 | 117 | یک پروکسی معکوس در مقابل یک یا چند سرور بک‌اند قرار می‌گیرد و درخواست‌ها را به مقصد مناسب هدایت می‌کند. آنها می توانند عملکردهای مختلفی را اجرا کنند، مانند: 118 | 119 | - به عنوان [متعادل کننده بار](#متعادل-کننده-بار-load-balancer) یا [فایروال برنامه وب](#فایروال-برنامه-وب-web-application-firewall-waf) عمل می کند. 120 | - امکان میزبانی چندین برنامه در یک آدرس IP یا دامنه (در زیر پوشه ها (subfolders)). 121 | - اجرای فیلتر IP یا سایر محدودیت ها. 122 | - ذخیره محتوا از بک اند برای بهبود عملکرد. 123 | 124 | شناسایی یک پروکسی معکوس همیشه امکان پذیر نیست (مخصوصاً اگر فقط یک برنامه در پشت آن وجود داشته باشد)، اما گاهی اوقات می توانید آن را با موارد زیر شناسایی کنید: 125 | 126 | - عدم تطابق بین سرور فرانت اند و برنامه (مانند هدر `Server: nginx` با یک برنامه ASP.NET). 127 | - این گاهی اوقات می تواند منجر به آسیب پذیری های قاچاق در درخواست ([request smuggling vulnerabilities](https://portswigger.net/web-security/request-smuggling)) شود. 128 | - هدرهای تکراری (مخصوصا هدر `Server`). 129 | - چندین برنامه میزبانی شده در یک آدرس IP یا دامنه (به خصوص اگر از زبان های مختلف استفاده می کنند). 130 | 131 | #### متعادل کننده بار (Load Balancer) 132 | 133 | یک Load Balanser در مقابل چندین سرور بک‌اند قرار می‌گیرد و درخواست‌ها را بین آنها تخصیص می‌دهد تا افزونگی و ظرفیت پردازش بیشتری را برای برنامه فراهم کند. 134 | 135 | تشخیص متعادل کننده بار ها ممکن است دشوار باشد، اما گاهی اوقات می توان با درخواست های متعدد و بررسی پاسخ ها برای تفاوت ها آن ها را تشخیص داد، مانند: 136 | 137 | - زمان سیستم متناقض 138 | - آدرس های IP داخلی مختلف یا نام میزبان در پیام های خطای دقیق. 139 | - آدرس‌های مختلف از جعل درخواست سمت سرور (SSRF) ‫([Server-Side Request Forgery (SSRF)](../07-Input_Validation_Testing/19-Testing_for_Server-Side_Request_Forgery.md)) بازگردانده شد. 140 | 141 | همچنین ممکن است با وجود کوکی های خاصی مشخص شوند (برای مثال، متعادل کننده بار F5 BIG-IP یک کوکی به نام `BIGipServer` ایجاد می کند. 142 | 143 | #### شبکه تحویل (توزیع) محتوا (CDN) ‫(Content Delivery Network (CDN)) 144 | 145 | شبکه تحویل محتوا (CDN) مجموعه‌ای از سرورهای پراکسی ذخیره‌سازی شده از نظر جغرافیایی است که برای بهبود عملکرد وب‌سایت و ایجاد انعطاف‌پذیری بیشتر برای وب‌سایت طراحی شده است. 146 | 147 | معمولاً با اشاره به دامنه عمومی به سرورهای CDN، و سپس پیکربندی CDN برای اتصال به سرورهای پشتیبان صحیح (که گاهی اوقات به عنوان "منبع" شناخته می شود) پیکربندی می شود. 148 | 149 | ساده ترین راه برای شناسایی یک CDN، انجام جستجوی WHOIS برای آدرس های IP است که دامنه به آنها رسیدگی می کند. اگر آنها متعلق به یک شرکت CDN هستند (مانند Akamai، Cloudflare یا Fastly - برای فهرست کاملتر به [ویکی‌پدیا](https://en.wikipedia.org/wiki/Content_delivery_network#Notable_content_delivery_service_providers) مراجعه کنید) مانند این است که یک CDN در حال استفاده است. 150 | 151 | هنگام آزمایش یک سایت پشت CDN، باید نکات زیر را در نظر داشته باشید: 152 | 153 | - ا IP ها و سرورها متعلق به ارائه دهنده CDN هستند و احتمالاً خارج از محدوده آزمایش زیرساخت هستند. 154 | - ا بسیاری از CDN ها همچنین دارای ویژگی هایی مانند تشخیص ربات، محدود کردن نرخ و فایروال برنامه های وب هستند. 155 | - ا CDN ها معمولاً محتوا را در حافظه پنهان نگه می دارند، بنابراین هر تغییری که در بک اند وب سایت ایجاد می شود ممکن است بلافاصله ظاهر نشود. 156 | 157 | اگر سایت پشت یک CDN باشد، شناسایی سرورهای بک‌اند می‌تواند مفید باشد. اگر کنترل دسترسی مناسبی برای آنها اعمال نشده باشد، ممکن است بتوانید CDN (و هرگونه حفاظتی که ارائه می دهد) را با دسترسی مستقیم به سرورهای پشتیبان دور بزنید. روش‌های مختلفی وجود دارد که به شما امکان می‌دهد سیستم پشتیبان را شناسایی کنید: 158 | 159 | - ایمیل‌های ارسال شده توسط برنامه ممکن است مستقیماً از سرور پشتیبان ارسال شوند که می‌تواند نشانی IP آن را نشان دهد. 160 | - سنگ زنی DNS، انتقال منطقه یا لیست های شفافیت گواهی برای دامنه ممکن است آن را در یک زیر دامنه نشان دهد. 161 | - اسکن محدوده IP شناخته شده برای استفاده توسط شرکت ممکن است سرور انتهایی را پیدا کند. 162 | - سوء استفاده از جعل درخواست سمت سرور ([Server-Side Request Forgery (SSRF)](../07-Input_Validation_Testing/19-Testing_for_Server-Side_Request_Forgery.md)) ممکن است آدرس IP را آشکار کند. 163 | - پیام‌های خطای دقیق از برنامه ممکن است آدرس‌های IP یا نام میزبان را در معرض نمایش بگذارد. 164 | 165 | ### اجزای امنیتی (Security Components) 166 | 167 | #### فایروال (دیوار آتشی) شبکه (Network Firewall) 168 | 169 | اکثر وب سرورها توسط یک فیلترینگ بسته یا فایروال بازرسی حالتی محافظت می شوند که هر گونه ترافیک شبکه را که مورد نیاز نیست مسدود می کند. برای تشخیص این مورد، پورت اسکن سرور را انجام دهید و نتایج را بررسی کنید. 170 | 171 | اگر اکثر پورت ها به صورت "بسته" نشان داده شوند (یعنی یک بسته (پکت) `RST` را در پاسخ به بسته اولیه `SYN` برمی گردانند) این نشان می دهد که سرور ممکن است توسط فایروال محافظت نشود. اگر پورت ها به صورت "فیلتر شده" نشان داده شوند (یعنی هنگام ارسال بسته `SYN` به یک پورت استفاده نشده پاسخی دریافت نمی شود) به احتمال زیاد یک فایروال در محل وجود دارد. 172 | 173 | علاوه بر این، اگر سرویس‌های نامناسبی در معرض دید جهانیان قرار گیرند (مانند SMTP، IMAP، MySQL، و غیره)، این نشان می‌دهد که یا فایروال وجود ندارد، یا اینکه فایروال به‌خوبی پیکربندی شده است. 174 | 175 | #### سیستم تشخیص و پیشگیری از نفوذ شبکه (Network Intrusion Detection and Prevention System) 176 | 177 | یک سیستم تشخیص نفوذ شبکه (Intrusion Detection System (IDS)) فعالیت های مشکوک یا مخرب در سطح شبکه (مانند پورت یا اسکن آسیب پذیری) را شناسایی می کند و هشدارها را افزایش می دهد. یک سیستم پیشگیری از نفوذ (Intrusion Prevention System (IPS)) مشابه است، اما همچنین برای جلوگیری از فعالیت - معمولاً با مسدود کردن آدرس IP منبع، اقداماتی را انجام می دهد. 178 | 179 | یک IPS را معمولاً می‌توان با اجرای ابزارهای اسکن خودکار (مانند اسکنر پورت) در مقابل هدف و مشاهده مسدود شدن IP منبع شناسایی کرد. با این حال، بسیاری از ابزارهای سطح برنامه ممکن است توسط یک IPS شناسایی نشوند (به خصوص اگر TLS را رمزگشایی نکند). 180 | 181 | #### فایروال برنامه وب (Web Application Firewall (WAF)) 182 | 183 | فایروال برنامه وب (WAF) محتویات درخواست‌های HTTP را بررسی می‌کند و مواردی را که مشکوک یا مخرب به نظر می‌رسند مسدود می‌کند، یا به صورت پویا سایر کنترل‌ها مانند CAPTCHA یا محدود کردن نرخ را اعمال می‌کند. آنها معمولاً بر اساس مجموعه ای از امضاهای بد شناخته شده و عبارات منظم، مانند مجموعه قوانین اصلی OWASP ‫([OWASP Core Rule Set](https://owasp.org/www-project-modsecurity-core-rule-set/)) هستند. WAF ها می توانند در محافظت در برابر برخی از انواع حملات (مانند تزریق SQL یا اسکریپت بین سایتی (cross-site scripting)) موثر باشند، اما در برابر انواع دیگر (مانند کنترل دسترسی یا مسائل مربوط به منطق تجاری) موثر نیستند. 184 | 185 | یک WAF را می توان در چندین مکان مستقر کرد، از جمله: 186 | 187 | - در خود وب سرور. 188 | - در یک ماشین مجازی یا دستگاه سخت افزاری جداگانه. 189 | - در فضای ابری مقابل سرور انتهایی. 190 | 191 | از آنجایی که WAF درخواست‌های مخرب را مسدود می‌کند، می‌توان با افزودن رشته‌های حمله رایج به پارامترها و مشاهده مسدود بودن یا نبودن آنها، آن را شناسایی کرد. برای مثال، سعی کنید پارامتری به نام `foo` با مقداری مانند `UNION SELECT 1 '` یا `<` اضافه کنید. اگر این درخواست‌ها مسدود شوند، نشان می‌دهد که ممکن است یک WAF وجود داشته باشد. علاوه بر این، محتویات صفحات مسدود ممکن است اطلاعاتی در مورد فناوری خاصی که در حال استفاده است ارائه دهد. در نهایت، برخی از WAF ها ممکن است کوکی ها یا هدرهای HTTP را به پاسخ ها اضافه کنند که می تواند حضور آنها را آشکار کند. 192 | 193 | اگر یک WAF مبتنی بر ابر استفاده می‌شود، ممکن است با استفاده از روش‌های مشابهی که در بخش [شبکه تحویل محتوا](#شبکه-تحویل-توزیع-محتوا-cdn-content-delivery-network-cdn) بحث شده است، با دسترسی مستقیم به سرور پشتیبان، آن را دور بزنید. 194 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/01-Information_Gathering/08-Fingerprint_Web_Application_Framework.md: -------------------------------------------------------------------------------- 1 | # Fingerprint Web Application Framework (fa-IR) 2 | 3 | انگشت نگاری چارچوب برنامه وب (فارسی) 4 | 5 | |شناسه | 6 | |------------| 7 | |WSTG-INFO-08| 8 | 9 | ## خلاصه 10 | 11 | هیچ چیز جدیدی در زیر نور خورشید وجود ندارد و تقریباً هر برنامه وب که ممکن است به توسعه آن فکر کنید قبلاً توسعه یافته است. با وجود تعداد زیادی از پروژه های نرم افزاری رایگان و متن باز که به طور فعال در سرتاسر جهان توسعه یافته و مستقر شده اند، به احتمال زیاد یک آزمایش امنیتی برنامه با هدفی مواجه خواهد شد که به طور کامل یا تا حدی به این برنامه ها یا چارچوب (فریمورک) های شناخته شده (مثلاً WordPress، phpBB، Mediawiki و غیره) وابسته است. دانستن اجزای برنامه وب که در حال آزمایش هستند کمک قابل توجهی به فرآیند آزمایش می کند و همچنین تلاش مورد نیاز در طول آزمایش را به شدت کاهش می دهد. این برنامه های وب شناخته شده دارای هدرهای HTML، کوکی ها و ساختارهای دایرکتوری هستند که می توان آنها را برای شناسایی برنامه شمارش کرد. اکثر چارچوب های وب دارای چندین نشانگر (marker) در آن مکان ها هستند که به مهاجم یا آزمایش کننده کمک می کند تا آنها را تشخیص دهد. این اساساً کاری است که همه ابزارهای خودکار انجام می دهند، آنها به دنبال یک نشانگر از یک مکان از پیش تعریف شده می گردند و سپس آن را با پایگاه داده امضاهای شناخته شده مقایسه می کنند. برای دقت بهتر معمولا از چندین نشانگر استفاده می شود. 12 | 13 | ## اهداف آزمایش 14 | 15 | - انگشت نگاری اجزای مورد استفاده توسط برنامه های وب. 16 | 17 | ## چگونه آزمایش کنیم 18 | 19 | ### آزمایش جعبه سیاه (Black-Box Testing) 20 | 21 | چندین مکان متداول (رایج) وجود دارد که باید به منظور شناسایی چارچوب ها یا مؤلفه ها در نظر گرفته شود: 22 | 23 | - هدرهای HTTP 24 | - کوکی ها 25 | - کد منبع (سورس کد) HTML 26 | - فایل ها و پوشه های خاص 27 | - پسوند فایل 28 | - پیغام خطا 29 | 30 | #### هدرهای HTTP ‫(HTTP Headers) 31 | 32 | ابتدایی ترین شکل شناسایی یک چارچوب وب، نگاه کردن به فیلد `X-Powered-By` در هدر پاسخ HTTP ‫(HTTP response header) است. ابزارهای زیادی را می توان برای انگشت نگاری یک هدف استفاده کرد، ساده ترین آنها netcat است. 33 | 34 | ا HTTP Request-Response زیر را در نظر بگیرید: 35 | 36 | ```text 37 | $ nc 127.0.0.1 80 38 | HEAD / HTTP/1.0 39 | 40 | HTTP/1.1 200 OK 41 | Server: nginx/1.0.14 42 | [...] 43 | X-Powered-By: Mono 44 | ``` 45 | 46 | از فیلد `X-Powered-By`، می فهمیم که چارچوب برنامه وب احتمالاً `Mono` خواهد بود. با این حال، اگرچه این رویکرد ساده و سریع است، اما این روش در 100% موارد کار نمی کند. این امکان وجود دارد که به راحتی هدر `X-Powered-By` را با یک پیکربندی مناسب غیرفعال کنید. همچنین چندین تکنیک وجود دارد که به یک وب سایت اجازه می دهد هدرهای HTTP را مبهم کند (به یک مثال در بخش [اصلاح](#اصلاح) مراجعه کنید). در مثال بالا همچنین می توانیم توجه داشته باشیم که نسخه خاصی از `nginx` برای ارائه محتوا استفاده می شود. 47 | 48 | بنابراین در همان مثال، آزمایش کننده می تواند هدر `X-Powered-By` را از دست بدهد یا پاسخی مانند زیر دریافت کند: 49 | 50 | ```text 51 | HTTP/1.1 200 OK 52 | Server: nginx/1.0.14 53 | Date: Sat, 07 Sep 2013 08:19:15 GMT 54 | Content-Type: text/html;charset=ISO-8859-1 55 | Connection: close 56 | Vary: Accept-Encoding 57 | X-Powered-By: Blood, sweat and tears 58 | ``` 59 | 60 | گاهی اوقات هدرهای HTTP بیشتری وجود دارد که به یک چارچوب خاص اشاره می کنند. در مثال زیر، با توجه به اطلاعات درخواست HTTP، می توان مشاهده کرد که هدر `X-Powered-By` حاوی نسخه PHP است. با این حال، هدر `X-Generator` اشاره می کند که چارچوب استفاده شده در واقع `Swiftlet` است، که به آزمایش کننده نفوذ کمک می کند تا بردارهای حمله خود را گسترش دهد. هنگام انجام انگشت نگاری، هر هدر HTTP را برای وجود چنین نشتی به دقت بررسی کنید. 61 | 62 | ```text 63 | HTTP/1.1 200 OK 64 | Server: nginx/1.4.1 65 | Date: Sat, 07 Sep 2013 09:22:52 GMT 66 | Content-Type: text/html 67 | Connection: keep-alive 68 | Vary: Accept-Encoding 69 | X-Powered-By: PHP/5.4.16-1~dotdeb.1 70 | Expires: Thu, 19 Nov 1981 08:52:00 GMT 71 | Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 72 | Pragma: no-cache 73 | X-Generator: Swiftlet 74 | ``` 75 | 76 | #### کوکی ها (Cookies) 77 | 78 | یکی دیگر از روش های مشابه و تا حدودی مطمئن تر برای تعیین چارچوب فعلی وب، کوکی های فریمورک خاص (framework-specific cookies) هستند. 79 | 80 | درخواست HTTP زیر را در نظر بگیرید: 81 | 82 | ![Cakephp HTTP Request](images/Cakephp_cookie.png)\ 83 | *شکل 1-4.1.8: Cakephp HTTP Request* 84 | 85 | کوکی `CAKEPHP` به طور خودکار تنظیم شده است، که اطلاعاتی در مورد چارچوب مورد استفاده ارائه می دهد. لیستی از نام های رایج کوکی ها در بخش کوکی ها ارائه شده است. هنوز محدودیت هایی در تکیه بر این مکانیسم شناسایی وجود دارد - امکان تغییر نام [کوکی ها](#کوکی-ها-cookies) وجود دارد. به عنوان مثال، برای چارچوب `CakePHP` انتخاب شده، این کار را می توان از طریق پیکربندی زیر انجام داد (گزیده ای از `core.php`): 86 | 87 | ```php 88 | /** 89 | * The name of CakePHP's session cookie. 90 | * 91 | * Note the guidelines for Session names states: "The session name references 92 | * the session id in cookies and URLs. It should contain only alphanumeric 93 | * characters." 94 | * @link http://php.net/session_name 95 | */ 96 | Configure::write('Session.cookie', 'CAKEPHP'); 97 | ``` 98 | 99 | با این حال، احتمال ایجاد این تغییرات نسبت به تغییرات هدر `X-Powered-By` کمتر است، بنابراین این رویکرد برای شناسایی را می توان به عنوان قابل اعتمادتر در نظر گرفت. 100 | 101 | #### کد منبع HTML ‫(HTML Source Code) 102 | 103 | این تکنیک بر اساس یافتن الگوهای خاصی در کد منبع صفحه HTML است. اغلب می توان اطلاعات زیادی پیدا کرد که به آزمایش کننده کمک می کند تا یک جزء خاص را تشخیص دهد. یکی از نشانگرهای رایج کامنت های HTML هستند که مستقیماً به افشای چارچوب منجر می شوند. اغلب مسیرهای خاص فریمورک (چارچوب) را می توان یافت، به عنوان مثال پیوند (لینک) هایی به پوشه های CSS یا JS مخصوص چارچوب. در نهایت، متغیرهای اسکریپت خاص نیز ممکن است به چارچوب خاصی اشاره کنند. 104 | 105 | از اسکرین شات زیر به راحتی می توان چارچوب مورد استفاده و نسخه آن را با نشانگرهای ذکر شده یاد گرفت. کامنت ها، مسیرهای خاص و متغیرهای اسکریپت همگی می توانند به مهاجم کمک کنند تا به سرعت نمونه ای از چارچوب ZK را تعیین کند. 106 | 107 | ![ZK Framework Sample](images/Zk_html_source.png)\ 108 | *شکل 2-4.1.8: نمونه منبع HTML چارچوب ZK* 109 | 110 | اغلب چنین اطلاعاتی در بخش `` پاسخ های HTTP، در تگ `` ها یا در انتهای صفحه قرار می گیرند. با این وجود، کل پاسخ ها باید تجزیه و تحلیل شوند، زیرا می تواند برای اهداف دیگری مانند بازرسی سایر کامنت های مفید و زمینه های پنهان مفید باشد. گاهی اوقات، توسعه دهندگان وب اهمیت زیادی به مخفی کردن اطلاعات مربوط به فریمورک )چارچوب) ها یا اجزای مورد استفاده نمی دهند. هنوز هم ممکن است به چیزی شبیه به این در پایین صفحه برخورد کنید: 111 | 112 | ![Banshee Bottom Page](images/Banshee_bottom_page.png)\ 113 | *شکل 3-4.1.8: صفحه پایین Banshee* 114 | 115 | ### فایل ها و پوشه های خاص (Specific Files and Folders) 116 | 117 | رویکرد دیگری وجود دارد که به مهاجم یا آزمایش کننده کمک می کند تا برنامه ها یا اجزای سازنده را با دقت بالا شناسایی کند. هر جزء وب ساختار فایل و پوشه خاص خود را در سرور دارد. اشاره شده است که می توان مسیر خاصی را از منبع صفحه HTML مشاهده کرد اما گاهی اوقات آنها به صراحت در آنجا ارائه نمی شوند و همچنان در سرور قرار دارند. 118 | 119 | برای کشف آنها از تکنیکی به نام مرور اجباری (forced browsing) یا "dirbusting" استفاده می شود. Dirbusting عبارت است از وادار کردن یک هدف با نام پوشه ها و فایل های شناخته شده و نظارت بر پاسخ های HTTP برای شمارش محتوای سرور. از این اطلاعات می توان هم برای یافتن فایل های پیش فرض و حمله به آنها و هم برای انگشت نگاری برنامه وب استفاده کرد. Dirbusting را می توان به روش های مختلفی انجام داد، مثال زیر یک حمله موفقیت آمیز dirbusting علیه یک هدف مبتنی بر وردپرس را با کمک لیست تعریف شده و عملکرد مزاحم Burp Suite نشان می دهد. 120 | 121 | ![Dirbusting with Burp](images/Wordpress_dirbusting.png)\ 122 | *شکل 4-4.1.8: Dirbusting با Burp* 123 | 124 | ما می توانیم ببینیم که برای برخی از پوشه های خاص وردپرس (به عنوان مثال، `/wp-includes/` و `/wp-admin/` و `/wp-content/`) پاسخهای HTTP به ترتیب 403 (ممنوع)، 302 (یافت، هدایت به `wp-login.php`) و 200 (OK) هستند. این نشان دهنده خوبی است که هدف از وردپرس پشتیبانی می کند. به همین ترتیب می توان پوشه های پلاگین برنامه های مختلف و نسخه های آنها را پاکسازی کرد. در تصویر زیر می توانید یک فایل CHANGELOG معمولی از یک پلاگین Drupal را مشاهده کنید که اطلاعاتی در مورد برنامه مورد استفاده ارائه می دهد و یک نسخه آسیب پذیر افزونه را فاش می کند. 125 | 126 | ![Drupal Botcha Disclosure](images/Drupal_botcha_disclosure.png)\ 127 | *شکل 5-4.1.8: افشای Drupal Botcha* 128 | 129 | نکته: قبل از شروع پخش، ابتدا فایل `robots.txt` را بررسی کنید. گاهی اوقات پوشه های خاص برنامه و سایر اطلاعات حساس را می توان در آنجا یافت. نمونه ای از چنین فایل `robots.txt` در تصویر زیر ارائه شده است. 130 | 131 | ![Robots Info Disclosure](images/Robots-info-disclosure.png)\ 132 | *شکل 6-4.1.8: افشای اطلاعات ربات ها* 133 | 134 | فایل ها و پوشه های خاص برای هر برنامه خاص متفاوت است. اگر برنامه یا مؤلفه شناسایی شده منبع باز باشد، ممکن است راه اندازی یک نصب موقت در طول آزمایش های نفوذ برای درک بهتر زیرساخت ها یا قابلیت هایی که ارائه می شود و چه فایل هایی ممکن است روی سرور باقی بماند، ارزش داشته باشد. با این حال، چندین لیست فایل خوب در حال حاضر وجود دارد. یکی از مثال های خوب، [فهرست واژه های FuzzDB از فایل ها/پوشه های قابل پیش بینی](https://github.com/fuzzdb-project/fuzzdb) است. 135 | 136 | #### پسوندهای فایل (File Extensions) 137 | 138 | ا URL ها ممکن است شامل پسوندهای فایل باشند که می تواند به شناسایی پلتفرم یا فناوری وب نیز کمک کند. 139 | 140 | به عنوان مثال، ویکی OWASP از PHP استفاده می کند: 141 | 142 | ```text 143 | https://wiki.owasp.org/index.php?title=Fingerprint_Web_Application_Framework&action=edit§ion=4 144 | ``` 145 | 146 | در اینجا برخی از پسوندهای رایج فایل های وب و فناوری های مرتبط آورده شده است: 147 | 148 | - `.php` -- PHP 149 | - `.aspx` -- Microsoft ASP.NET 150 | - `.jsp` -- صفحات سرور جاوا 151 | 152 | #### پیغام خطا(Error Messages) 153 | 154 | همانطور که در تصویر زیر مشاهده می شود، مسیر فایل سیستم فهرست شده به استفاده از وردپرس (`wp-content`) اشاره دارد. همچنین آزمایش کنندگان باید بدانند که وردپرس مبتنی بر PHP است (`functions.php`). 155 | 156 | ![WordPress Parse error](images/wp-syntaxerror.png)\ 157 | *شکل 7-4.1.8: خطای تجزیه وردپرس* 158 | 159 | ## شناسه های مشترک (Common Identifiers) 160 | 161 | ### کوکی ها (Cookies) 162 | 163 | | چارچوب | نام کوکی | 164 | |--------------|-----------------------------------| 165 | | Zope | zope3 | 166 | | CakePHP | cakephp | 167 | | Kohana | kohanasession | 168 | | Laravel | laravel_session | 169 | | phpBB | phpbb3_ | 170 | | WordPress | wp-settings | 171 | | 1C-Bitrix | BITRIX_ | 172 | | AMPcms | AMP | 173 | | Django CMS | django | 174 | | DotNetNuke | DotNetNukeAnonymous | 175 | | e107 | e107_tz | 176 | | EPiServer | EPiTrace, EPiServer | 177 | | Graffiti CMS | graffitibot | 178 | | Hotaru CMS | hotaru_mobile | 179 | | ImpressCMS | ICMSession | 180 | | Indico | MAKACSESSION | 181 | | InstantCMS | InstantCMS[logdate] | 182 | | Kentico CMS | CMSPreferredCulture | 183 | | MODx | SN4[12symb] | 184 | | TYPO3 | fe_typo_user | 185 | | Dynamicweb | Dynamicweb | 186 | | LEPTON | lep[some_numeric_value]+sessionid | 187 | | Wix | Domain=.wix.com | 188 | | VIVVO | VivvoSessionId | 189 | 190 | ### کد منبع HTML ‫(HTML Source Code) 191 | 192 | | برنامه | کلمه کلیدی | 193 | |-------------|--------------------------------------------------------------------------------| 194 | | WordPress | `` | 195 | | phpBB | `` | 197 | | Joomla | `` | 198 | | Drupal | `` | 199 | | DotNetNuke | `DNN Platform - [http://www.dnnsoftware.com](http://www.dnnsoftware.com)` | 200 | 201 | #### نشانگرهای عمومی (General Markers) 202 | 203 | - `%framework_name%` 204 | - `powered by` 205 | - `built upon` 206 | - `running` 207 | 208 | #### نشانگرهای خاص (Specific Markers) 209 | 210 | | چارچوب | کلمه کلیدی | 211 | |-------------------|--------------------------------| 212 | | Adobe ColdFusion | `` | 216 | | Indexhibit | `ndxz-studio` | 217 | 218 | ## اصلاح 219 | 220 | در حالی که می توان تلاش هایی برای استفاده از نام های مختلف کوکی ها (از طریق تغییر تنظیمات)، مخفی کردن یا تغییر مسیرهای فایل/دایرکتوری (از طریق بازنویسی یا تغییر کد منبع)، حذف هدرهای شناخته شده و غیره انجام داد. صاحبان/مدیران سیستم باید بدانند که این تلاش ها فقط باعث کاهش ابتدایی ترین دشمنان می شود. زمان/تلاش ممکن است برای آگاهی ذینفعان و فعالیت های تعمیر و نگهداری راه حل بهتر استفاده شود. 221 | 222 | ## ابزارها 223 | 224 | لیستی از ابزارهای عمومی و شناخته شده در زیر ارائه شده است. همچنین بسیاری از ابزارهای کاربردی دیگر و همچنین ابزارهای انگشت نگاری مبتنی بر چارچوب وجود دارد. 225 | 226 | ###
WhatWeb
227 | 228 | وب سایت: [https://github.com/urbanadventurer/WhatWeb](https://github.com/urbanadventurer/WhatWeb) 229 | 230 | در حال حاضر یکی از بهترین ابزارهای انگشت نگاری موجود در بازار است. در یک ساخت پیش فرض کالی لینوکس ([Kali Linux](https://www.kali.org/)) گنجانده شده است. زبان: روبی (Ruby) مچ شده برای انگشت نگاری با: 231 | 232 | - رشته های متنی (حساس به حروف کوچک و بزرگ) 233 | - عبارات با قاعده 234 | - پرس و جو های پایگاه داده گوگل هک (مجموعه محدودی از کلمات کلیدی) 235 | - هش های MD5 236 | - تشخیص URL 237 | - الگوهای تگ HTML 238 | - کد ruby سفارشی برای عملیات غیرفعال و تهاجمی 239 | - خروجی نمونه در تصویر زیر ارائه شده است: 240 | 241 | ![Whatweb Output sample](images/Whatweb-sample.png)\ 242 | *شکل 8-4.1.8: نمونه خروجی Whatweb* 243 | 244 | ###
Wappalyzer
245 | 246 | وب سایت: [https://www.wappalyzer.com/](https://www.wappalyzer.com/) 247 | 248 | ا Wappalyzer در مدل های چندگانه موجود است که محبوب ترین آنها احتمالاً افزونه های Firefox/Chrome است. آنها فقط بر روی تطبیق عبارات معمولی کار می کنند و به هیچ چیز دیگری غیر از صفحه برای بارگذاری در مرورگر نیاز ندارند. به طور کامل در سطح مرورگر کار می کند و نتایج را در قالب آیکون می دهد. اگرچه گاهی اوقات دارای نکات مثبت کاذب است، اما این بسیار مفید است که بدانید چه فناوری هایی برای ساختن یک وب سایت هدف بلافاصله پس از مرور یک صفحه استفاده شده است. 249 | 250 | نمونه خروجی یک افزونه در تصویر زیر ارائه شده است. 251 | 252 | ![Wappalyzer Output for OWASP Website](images/Owasp-wappalyzer.png)\ 253 | *شکل 9-4.1.8: خروجی Wappalyzer برای وب سایت OWASP* 254 | 255 | ## منابع 256 | 257 | ### کاغذهای سفید (Whitepapers) 258 | 259 | - [Saumil Shah: "An Introduction to HTTP fingerprinting"](https://web.archive.org/web/20190526182734/https://net-square.com/httprint_paper.html) 260 | - [Anant Shrivastava : "Web Application Finger Printing"](https://anantshri.info/articles/web_app_finger_printing.html) 261 | -------------------------------------------------------------------------------- /4-Web_Application_Security_Testing/01-Information_Gathering/04-Enumerate_Applications_on_Webserver.md: -------------------------------------------------------------------------------- 1 | # Enumerate Applications on Webserver (fa-IR) 2 | 3 | شمارش برنامه ها در وب سرور (فارسی) 4 | 5 | |شناسه | 6 | |------------| 7 | |WSTG-INFO-04| 8 | 9 | ## خلاصه 10 | 11 | یک مرحله مهم در آزمایش آسیب پذیری های برنامه های وب، این است که بفهمیم کدام برنامه های خاص روی سرور وب میزبانی می شوند. بسیاری از برنامه ها دارای آسیب پذیری ها و استراتژی های حمله شناخته شده هستند که می توانند برای به دست آوردن کنترل از راه دور یا سوء استفاده از داده ها مورد سوء استفاده قرار گیرند. علاوه بر این، بسیاری از برنامه ها اغلب به اشتباه پیکربندی می شوند یا بروزرسانی نمی شوند، زیرا این تصور وجود دارد که آنها فقط "داخلی" استفاده می شوند و بنابراین هیچ تهدیدی وجود ندارد. با گسترش وب سرورهای مجازی، رابطه سنتی نوع 1:1 بین یک آدرس IP و یک وب سرور در حال از دست دادن اهمیت اصلی خود است. غیر معمول نیست که چندین وب سایت یا برنامه داشته باشیم که نام نمادین آنها به آدرس IP یکسان منتقل شود. این سناریو به محیط های میزبانی محدود نمی شود، بلکه برای محیط های معمولی شرکت ها نیز اعمال می شود. 12 | 13 | گاهی اوقات به متخصصان امنیتی مجموعه ای از آدرس های IP به عنوان هدف برای آزمایش داده می شود. می توان بحث کرد که این سناریو بیشتر شبیه یک درگیری از نوع آزمایش نفوذ است، اما در هر صورت انتظار می رود که چنین تخصیصی تمام برنامه های وب قابل دسترسی از طریق این هدف را آزمایش کند. مشکل این است که آدرس IP داده شده میزبان یک سرویس HTTP در پورت 80 است، اما اگر آزمایش کننده باید با مشخص کردن آدرس IP به آن دسترسی پیدا کند (که تنها چیزی است که می دانند) "No web server configured at this address" یا پیامی مشابه را گزارش می کند. اما آن سیستم می تواند تعدادی از برنامه های وب مرتبط با نام های نمادین (DNS) نامرتبط را "پنهان کند". بدیهی است که میزان تجزیه و تحلیل عمیقاً تحت تأثیر این است که آزمایش کننده همه برنامه ها را آزمایش می کند یا فقط برنامه هایی را آزمایش می کند که از آنها آگاه است. 14 | 15 | گاهی اوقات، مشخصات هدف غنی تر است. ممکن است به آزمایش کننده فهرستی از آدرس های IP و نام های نمادین مربوط به آنها داده شود. با این وجود، این لیست ممکن است اطلاعات جزئی را منتقل کند، به عنوان مثال، می تواند برخی از نام های نمادین را حذف کند و مشتری ممکن است حتی از آن آگاه نباشد (این امر در سازمان های بزرگ بیشتر اتفاق می افتد). 16 | 17 | سایر مسائلی که بر دامنه ارزیابی تأثیر می گذارد توسط برنامه های وب منتشر شده در URL های غیر آشکار (به عنوان مثال، `http://www.example.com/some-strange-URL`) نشان داده می شود که در جای دیگری به آنها اشاره نمی شود. این ممکن است به اشتباه (به دلیل پیکربندی نادرست)، یا عمدی (به عنوان مثال، رابط های اداری تبلیغ نشده) اتفاق بیفتد. 18 | 19 | برای رسیدگی به این مسائل، لازم است که برنامه وب را کشف کنید. 20 | 21 | ## اهداف آزمایش 22 | 23 | - برنامه های در محدوده موجود در وب سرور را برشمارید. 24 | 25 | ## چگونه آزمایش کنیم 26 | 27 | کشف برنامه وب فرآیندی است با هدف شناسایی برنامه های وب در یک زیرساخت معین. بعدی معمولاً به عنوان مجموعه ای از آدرس های IP (شاید یک بلوک خالص) مشخص می شود، اما ممکن است شامل مجموعه ای از نام های نمادین DNS یا ترکیبی از این دو باشد. این اطلاعات قبل از اجرای یک ارزیابی (آزمایش)، خواه یک آزمون نفوذ به سبک کلاسیک باشد یا یک ارزیابی متمرکز بر برنامه، ارائه می شود. در هر دو مورد، مگر اینکه قوانین تعامل خلاف این را مشخص کند (به عنوان مثال، فقط برنامه واقع در URL را آزمایش کنید `/http://www.example.com`)، ارزیابی باید تلاش کند تا جامع ترین دامنه باشد، یعنی باید همه برنامه های قابل دسترسی از طریق هدف داده شده را شناسایی کند. مثال های زیر به بررسی چند تکنیک می پردازد که می توان برای دستیابی به این هدف به کار برد. 28 | 29 | > برخی از تکنیک های زیر برای وب سرورهای اینترنتی استفاده می شود، یعنی خدمات جستجوی مبتنی بر وب DNS و IP معکوس و استفاده از موتورهای جستجو. نمونه ها از آدرس های IP خصوصی (مانند `192.168.1.100`) استفاده می کنند (مگر اینکه خلاف آن مشخص شده باشد) که نشان دهنده آدرس های IP عمومی هستند و فقط برای مقاصد ناشناس استفاده می شوند. 30 | 31 | سه عامل وجود دارد که بر تعداد برنامه های مرتبط با یک نام DNS (یا یک آدرس IP) تأثیر می گذارد: 32 | 33 | **
1- URL پایه متفاوت (Different Base URL)
** 34 | 35 | نقطه ورود واضح برای یک برنامه وب `www.example.com` است، به عنوان مثال، با این علامت کوتاه، ما به برنامه وب فکر می کنیم که منشا آن `/http://www.example.com` است (همین مورد برای HTTPS نیز صدق می کند). با این حال، حتی اگر این رایج ترین وضعیت است، هیچ چیز برنامه را مجبور به شروع در `/` نمیکند. 36 | 37 | به عنوان مثال، یک نام نمادین ممکن است به سه برنامه وب مرتبط باشد. مانند: 38 | 39 | `http://www.example.com/url1` `http://www.example.com/url2` `http://www.example.com/url3` 40 | 41 | در این حالت، آدرس `/http://www.example.com` با یک صفحه معنادار مرتبط نمی شود و این سه برنامه پنهان می شوند، مگر اینکه آزمایش کننده صریحاً بداند چگونه به آنها دسترسی پیدا کند، یعنی آزمایش کننده url2 ،url1 یا url3 را بشناسد. معمولاً نیازی به انتشار برنامه های تحت وب به این روش نیست، مگر اینکه مالک بخواهد به صورت استاندارد در دسترس باشد و آماده باشد تا کاربران را از موقعیت مکانی دقیق آنها مطلع کند. این بدان معنا نیست که این برنامه ها مخفی هستند، فقط وجود و مکان آنها به صراحت تبلیغ نشده است. 42 | 43 | **2- پورت های غیر استاندارد (Non-standard Ports)** 44 | 45 | در حالی که برنامه های وب معمولاً روی پورت 80 (HTTP) و 443 (HTTPS) هستند، هیچ چیز جادویی در مورد این شماره پورت ها وجود ندارد. در واقع، برنامه های وب ممکن است با پورت های TCP دلخواه مرتبط باشند و می توان با تعیین شماره پورت به صورت زیر به آنها ارجاع داد: `/http[s]://www.example.com:port`. به عنوان مثال، `/http://www.example.com:20000`. 46 | 47 | **3- هاست (میزبان) های مجازی (Virtual Hosts)** 48 | 49 | ا DNS اجازه می دهد تا یک آدرس IP واحد با یک یا چند نام نمادین مرتبط شود. برای مثال، آی پی آدرس `192.168.1.100` ممکن است با DNS نام های `www.example.com`، `helpdesk.example.com`، `webmail.example.com` مرتبط باشد. لزومی ندارد که همه نام ها متعلق به یک دامنه DNS باشند. این رابطه 1 به N ممکن است برای ارائه محتوای مختلف با استفاده از به اصطلاح میزبان های مجازی منعکس شود. اطلاعاتی که میزبان مجازی مورد نظر ما را مشخص می کند در سربرگ میزبان HTTP 1.1 ([Host header](https://tools.ietf.org/html/rfc2616#section-14.23)) تعبیه شده است. 50 | 51 | کسی به وجود برنامه های وب دیگر علاوه بر `www.example.com` واضح مشکوک نیست، مگر اینکه از `helpdesk.example.com` و `webmail.example.com` اطلاع داشته باشد. 52 | 53 | ### رویکردها به آدرس شماره 1 - URL های غیر استاندارد 54 | 55 | هیچ راهی برای اطمینان کامل از وجود برنامه های وب غیر استاندارد وجود ندارد. از آنجایی که استاندارد نیست، هیچ معیار ثابتی بر قرارداد نامگذاری حاکم نیست، با این حال تعدادی تکنیک وجود دارد که آزمایش کننده می تواند برای به دست آوردن بینش بیشتر از آنها استفاده کند. 56 | 57 | اول، اگر وب سرور به درستی پیکربندی نشده باشد و امکان مرور فهرست را فراهم کند، ممکن است بتوان این برنامه ها را شناسایی کرد. اسکنرهای آسیب پذیری ممکن است در این زمینه کمک کنند. 58 | 59 | دوم، این برنامه ها ممکن است توسط صفحات وب دیگر ارجاع داده شوند و این احتمال وجود دارد که توسط موتورهای جستجوی وب فهرست بندی و فهرست بندی شده باشند. اگر آزمایش کنندگان به وجود چنین برنامه های مخفی در `www.example.com` مشکوک شوند، می توانند با استفاده از اپراتور سایت جستجو کنند و نتیجه یک پرس و جو را برای `site: www.example.com` بررسی کنند. در میان URL های بازگردانده شده ممکن است یکی وجود داشته باشد که به چنین برنامه غیر آشکاری اشاره می کند. 60 | 61 | گزینه دیگر این است که URL هایی را که احتمالاً کاندیدای برنامه های منتشر نشده باشند بررسی کنید. به عنوان مثال، ممکن است یک صفحه ایمیل وب از آدرس های اینترنتی مانند `/https://www.example.com/webmail`، `https://webmail.example.com` و یا `/https://mail.example.com` قابل دسترسی باشد. همین امر در مورد رابط های اداری نیز صدق می کند، که ممکن است در URL های مخفی (مثلاً یک رابط اداری Tomcat) منتشر شوند و در عین حال به جایی ارجاع داده نشده باشند. بنابراین انجام کمی جستجو به سبک فرهنگ لغت (یا "حدس زدن هوشمند") می تواند نتایجی را به همراه داشته باشد. اسکنرهای آسیب پذیری ممکن است در این زمینه کمک کنند. 62 | 63 | ## رویکردها به آدرس شماره 2 - پورت های غیر استاندارد 64 | 65 | بررسی وجود برنامه های وب در پورت های غیر استاندارد آسان است. یک اسکنر پورت مانند nmap می تواند با استفاده از `sV-` گزینه شناسایی سرویس را انجام دهد و سرویس های http[s] را در پورت های دلخواه شناسایی کند. آنچه مورد نیاز است اسکن کامل فضای آدرس پورت 64k TCP است. 66 | 67 | برای مثال، دستور زیر با اسکن اتصال TCP، تمام پورت های آی پی `192.168.1.100` را باز می کند و سعی می کند مشخص کند که چه سرویس هایی به آن ها متصل هستند (فقط سوئیچ های ضروری نشان داده می شوند – nmap دارای مجموعه گسترده ای از گزینه ها است که بحث در مورد آنها خارج از محدوده است): 68 | 69 | `nmap –Pn –sT –sV –p0-65535 192.168.1.100` 70 | 71 | کافی است خروجی را بررسی کنید و به دنبال HTTP یا نشانه سرویس های پوشیده شده با TLS باشید (که باید برای تایید اینکه HTTPS هستند) بررسی شود. به عنوان مثال، خروجی دستور قبلی می تواند به صورت زیر باشد: 72 | 73 | ```text 74 | Interesting ports on 192.168.1.100: 75 | (The 65527 ports scanned but not shown below are in state: closed) 76 | PORT STATE SERVICE VERSION 77 | 22/tcp open ssh OpenSSH 3.5p1 (protocol 1.99) 78 | 80/tcp open http Apache httpd 2.0.40 ((Red Hat Linux)) 79 | 443/tcp open ssl OpenSSL 80 | 901/tcp open http Samba SWAT administration server 81 | 1241/tcp open ssl Nessus security scanner 82 | 3690/tcp open unknown 83 | 8000/tcp open http-alt? 84 | 8080/tcp open http Apache Tomcat/Coyote JSP engine 1.1 85 | ``` 86 | 87 | از این مثال می توان دید که: 88 | 89 | - یک سرور HTTP آپاچی روی پورت 80 اجرا می شود. 90 | - به نظر می رسد یک سرور HTTPS در پورت 443 وجود دارد (اما این باید تأیید شود، مثلاً با مراجعه `https://192.168.1.100` به مرورگر). 91 | - در پورت 901 یک رابط وب Samba SWAT وجود دارد. 92 | - سرویس در پورت 1241 HTTPS نیست، بلکه Nessus daemon با TLS پوشیده شده است. 93 | - پورت 3690 دارای یک سرویس نامشخص است (nmap انگشت نگاری خود را - در اینجا برای وضوح حذف شده است - همراه با دستورالعمل هایی برای ارسال آن برای ادغام در پایگاه داده انگشت نگاری nmap، پس می دهد، مشروط بر اینکه بدانید کدام سرویس را نشان می دهد). 94 | - سرویس نامشخص دیگری در پورت 8000. این احتمالاً HTTP است، زیرا یافتن سرورهای HTTP در این پورت غیر معمول نیست. بیایید این موضوع را بررسی کنیم: 95 | 96 | ```text 97 | $ telnet 192.168.10.100 8000 98 | Trying 192.168.1.100... 99 | Connected to 192.168.1.100. 100 | Escape character is '^]'. 101 | GET / HTTP/1.0 102 | 103 | HTTP/1.0 200 OK 104 | pragma: no-cache 105 | Content-Type: text/html 106 | Server: MX4J-HTTPD/1.0 107 | expires: now 108 | Cache-Control: no-cache 109 | 110 | 111 | ... 112 | ``` 113 | 114 | این تایید می کند که در واقع یک سرور HTTP است. از طرف دیگر، آزمایش کنندگان می توانستند URL را با یک مرورگر وب بازدید کنند. یا از دستورات GET یا HEAD Perl استفاده کرد که تعاملات HTTP مانند آنچه در بالا داده شد را تقلید می کند (هر چند درخواست های HEAD ممکن است توسط همه سرورها رعایت نشود). 115 | 116 | - آپاچی تامکت (Apache Tomcat) در پورت 8080 اجرا می شود. 117 | 118 | همین کار ممکن است توسط اسکنرهای آسیب پذیری انجام شود، اما ابتدا بررسی کنید که اسکنر انتخابی قادر به شناسایی سرویس های HTTP[S] است که روی پورت های غیر استاندارد اجرا می شوند. به عنوان مثال، Nessus قادر است آنها را بر روی پورت های دلخواه شناسایی کند (به شرطی که دستور اسکن تمام پورت ها داده شود)، و با توجه به nmap، تعدادی آزمایش بر روی آسیب پذیری های وب سرور شناخته شده و همچنین پیکربندی TLS/SSL ارائه خواهد کرد. خدمات HTTPS همانطور که قبلا اشاره شد، Nessus همچنین می تواند برنامه های محبوب یا رابط های وب را که در غیر این صورت ممکن است مورد توجه قرار نگیرند (به عنوان مثال، یک رابط اداری Tomcat) شناسایی کند. 119 | 120 | ### رویکردها به آدرس شماره 3 - میزبان های مجازی 121 | 122 | تعدادی تکنیک وجود دارد که ممکن است برای شناسایی نام های DNS مرتبط با یک آدرس IP معین استفاده شود `x.y.z.t`. 123 | 124 | #### انتقالات منطقه DNS ‫(DNS Zone Transfers) 125 | 126 | این تکنیک امروزه استفاده محدودی دارد، با توجه به این واقعیت که انتقال منطقه تا حد زیادی توسط سرورهای DNS رعایت نمی شود. با این حال، ممکن است ارزش امتحان کردن را داشته باشد. اول از همه، آزمایش کننده ها باید سرورهای نام (name servers) سرویس دهنده `x.y.z.t` را تعیین کنند. اگر یک نام نمادین برای آن `x.y.z.t` شناخته شود (بگذارید باشد `www.example.com`)، سرورهای نام (name servers) آن را می توان با ابزارهایی مانند `nslookup`، `host` یا `dig` با درخواست رکوردهای DNS NS تعیین کرد. 127 | 128 | اگر هیچ نام نمادینی برای آن `x.y.z.t` شناخته نشده باشد، اما تعریف هدف شامل حداقل یک نام نمادین باشد، آزمایش کنندگان ممکن است سعی کنند همان فرآیند را اعمال کنند و سرور نام (name server) آن نام را پرس و جو کنند (به این امید که `x.y.z.t` توسط آن سرور نام نیز ارائه شود). به عنوان مثال، اگر هدف شامل آدرس آی پی `x.y.z.t` و نام `mail.example.com` باشد، سرورهای نام دامنه `example.com` را تعیین کنید. 129 | 130 | مثال زیر نحوه شناسایی سرورهای نام `www.owasp.org` را با استفاده از دستور `host` نشان می دهد: 131 | 132 | ```text 133 | $ host -t ns www.owasp.org 134 | www.owasp.org is an alias for owasp.org. 135 | owasp.org name server ns1.secure.net. 136 | owasp.org name server ns2.secure.net. 137 | ``` 138 | 139 | اکنون ممکن است یک انتقال منطقه به سرورهای نام دامنه `example.com` درخواست شود. اگر آزمایش کننده خوش شانس باشد، لیستی از ورودی های DNS برای این دامنه را دریافت می کند. این شامل موارد بدیهی `www.example.com` و نه چندان آشکار `helpdesk.example.com` و `webmail.example.com` (و احتمالاً دیگران) خواهد بود. همه نام هایی را که با انتقال منطقه بازگردانده شده اند بررسی کنید و همه نام هایی را که مربوط به هدف مورد ارزیابی هستند در نظر بگیرید. 140 | 141 | تلاش برای درخواست انتقال منطقه `owasp.org` از یکی از سرورهای نام آن: 142 | 143 | ```text 144 | $ host -l www.owasp.org ns1.secure.net 145 | Using domain server: 146 | Name: ns1.secure.net 147 | Address: 192.220.124.10#53 148 | Aliases: 149 | 150 | Host www.owasp.org not found: 5(REFUSED) 151 | ; Transfer failed. 152 | ``` 153 | 154 | #### پرس و جوهای معکوس DNS ‫(DNS Inverse Queries) 155 | 156 | این فرآیند مشابه فرآیند قبلی است، اما به رکوردهای DNS معکوس (PTR) متکی است. به جای درخواست انتقال منطقه، نوع رکورد را روی PTR تنظیم کنید و یک پرس و جو در آدرس IP داده شده صادر کنید. اگر آزمایش کننده ها خوش شانس باشند، ممکن است یک ورودی نام DNS را دریافت کنند. این تکنیک به وجود نقشه های نام نمادین IP ‫(IP-to-symbolic name maps) متکی است که تضمینی نیست. 157 | 158 | #### جستجوهای DNS مبتنی بر وب (Web-based DNS Searches) 159 | 160 | این نوع جستجو شبیه به انتقال منطقه DNS است، اما متکی به خدمات مبتنی بر وب است که جستجوهای مبتنی بر نام را در DNS امکان پذیر می کند. یکی از این خدمات، سرویس [Netcraft Search DNS](https://searchdns.netcraft.com/?host) است. آزمایش کننده ممکن است فهرستی از نام های متعلق به دامنه انتخابی شما را جستجو کند، مانند `example.com`. سپس آنها بررسی خواهند کرد که آیا نام هایی که به دست آورده اند با هدف مورد بررسی مرتبط است یا خیر. 161 | 162 | #### خدمات IP معکوس (Reverse-IP Services) 163 | 164 | سرویس های IP معکوس مشابه پرس وجوهای معکوس DNS هستند، با این تفاوت که آزمایش کننده ها به جای سرور نام، یک برنامه مبتنی بر وب را درخواست می کنند. تعدادی از این خدمات در دسترس است. از آنجایی که آنها تمایل به بازگرداندن نتایج جزئی (و اغلب متفاوت) دارند، بهتر است از چندین سرویس برای به دست آوردن تجزیه و تحلیل جامع تر استفاده کنید. 165 | 166 | - [MxToolbox Reverse IP](https://mxtoolbox.com/ReverseLookup.aspx) 167 | - [DNSstuff](https://www.dnsstuff.com/) (خدمات متعدد در دسترس است) 168 | - [Net Square](https://web.archive.org/web/20190515092354/http://www.net-square.com/mspawn.html) ‫(درخواست های متعدد در دامنه ها و آدرس های IP، نیاز به نصب دارد) 169 | 170 | #### گوگل کردن (Googling) 171 | 172 | به دنبال جمع آوری اطلاعات از تکنیک های قبلی، آزمایش کنندگان می توانند به موتورهای جستجو برای اصلاح و افزایش تحلیل خود اعتماد کنند. این ممکن است شواهدی از نام های نمادین اضافی متعلق به هدف، یا برنامه های قابل دسترسی از طریق URL های غیر آشکار به دست دهد. 173 | 174 | برای مثال، با در نظر گرفتن مثال قبلی در مورد `www.owasp.org`، آزمایش کننده می تواند از گوگل و سایر موتورهای جستجو به دنبال اطلاعات (از این رو، نام های DNS) مربوط به دامنه های جدید کشف شده `webgoat.org`، `webscarab.com` و `webscarab.net` پرس و جو کند. 175 | 176 | تکنیک های گوگل در [تست: عنکبوت ها، ربات ها و خزنده ها](01-Conduct_Search_Engine_Discovery_Reconnaissance_for_Information_Leakage.md) توضیح داده شده است. 177 | 178 | #### گواهی های دیجیتال (Digital Certificates) 179 | 180 | اگر سرور اتصالات را از طریق HTTPS بپذیرد، نام مشترک (CN) و نام جایگزین موضوع (SAN) در گواهی ممکن است شامل یک یا چند نام میزبان (hostname) باشد. با این حال، اگر وب سرور گواهی قابل اعتمادی نداشته باشد، یا علامت های عام در حال استفاده باشد، ممکن است هیچ اطلاعات معتبری برنگردد. 181 | 182 | ا CN و SAN را می توان با بازرسی دستی گواهی یا از طریق ابزارهای دیگر مانند OpenSSL به دست آورد: 183 | 184 | ```text 185 | openssl s_client -connect 93.184.216.34:443 /dev/null | openssl x509 -noout -text | grep -E 'DNS:|Subject:' 186 | 187 | Subject: C = US, ST = California, L = Los Angeles, O = Internet Corporation for Assigned Names and Numbers, CN = www.example.org 188 | DNS:www.example.org, DNS:example.com, DNS:example.edu, DNS:example.net, DNS:example.org, DNS:www.example.com, DNS:www.example.edu, DNS:www.example.net 189 | ``` 190 | 191 | ## ابزارها 192 | 193 | - DNS lookup tools such as `nslookup`, `dig` and similar. 194 | - Search engines (Google, Bing, and other major search engines). 195 | - Specialized DNS-related web-based search service: see text. 196 | - [Nmap](https://nmap.org/) 197 | - [Nessus Vulnerability Scanner](https://www.tenable.com/products/nessus) 198 | - [Nikto](https://www.cirt.net/nikto2) 199 | --------------------------------------------------------------------------------