Owasp Top 10 2007 Persian

OWASP TOP 10

‫دﻩ ﺁﺳﻴﺐ ﭘﺬﻳﺮﯼ ﻣﻬﻢ اﻣﻨﻴﺘﯽ ﻧﺮم اﻓﺰارهﺎﯼ ﺗﺤﺖ وب‬

:‫ﻣﺘﺮﺟﻤﻴﻦ‬ [email protected] ‫ﻣﻴﺘﺮا ﻣﻮﺳﻮي‬ [email protected] ‫آﻧﺎﻫﻴﺘﺎ ﻃﺎﻫﺮي‬

:‫ﺑﺎ ﺳﭙﺎس از‬ CISSP ،‫ﺑﻬﺮﻧﮓ ﻓﻮﻻدي‬

2007 UPDATE © 2002-2007 OWASP Foundation

This document is licensed under the Creative Commons Attribution-ShareAlike 2.5 license

‫ﻓﻬﺮﺳﺖ ﻣﻄﺎﻟﺐ‬

2 .................................................................................................................................................................. ‫ﻓﻬﺮﺳﺖ ﻣﻄﺎﻟﺐ‬ 3 ................................................................................................................................................................................. ‫ﻣﻘﺪﻣﻪ‬ 5 ...............................................................................................................................................................................‫ﺧﻼﺻﻪ‬ 6 ..................................................................................................................................................................... ‫روش ﺷﻨﺎﺳﻲ‬ 10 .............................................................................. A1 - Cross Site Scripting (Xss) -‫اﺟﺮاي اﺳﻜﺮﻳﭙﺖ ﺑﻴﻦ ﺳﺎﻳﺘﻲ‬ 14 ............................................................................................................... A2 - Injection Flows -‫ﺿﻌﻒ ﻫﺎي ﺗﺰرﻳﻘﻲ‬ 18 ............................................................................................. A3 - Malicious File Execution -‫اﺟﺮاي ﻓﺎﻳﻞ ﻣﺨﺮب‬ 22 ................................................................. A4 - Insecure Direct Object Reference –‫ارﺟﺎع ﻧﺎاﻣﻦ ﻣﺴﺘﻘﻴﻢ ﺑﻪ ﺷﻲ‬ 26 ............................................................ A5 - Cross Site Request Forgery (CSRF) -‫ﺟﻌﻞ درﺧﻮاﺳﺖ ﺑﻴﻦ ﺳﺎﻳﺘﻲ‬ 30 ...... A6 - Information Leakage and Improper Error Handling -‫ﻧﺸﺖ اﻃﻼﻋﺎت و ﻣﺪﻳﺮﻳﺖ ﺧﻄﺎي ﻧﺎدرﺳﺖ‬ 32 ................. A7 - Broken Authentication and Session Management -‫اﺣﺮاز ﻫﻮﻳﺖ و ﻣﺪﻳﺮﻳﺖ ﻧﺸﺴﺖ ﻧﺎﻗﺺ‬ 37 ............................................................. A8 – Insecure Cryptographic Storage -‫اﻧﺒﺎره ﻣﺤﺎﻓﻈﺖ ﻧﺸﺪه رﻣﺰﻧﮕﺎري‬ 40 .................................................................................................. A9 – Insecure Communication – ‫ارﺗﺒﺎﻃﺎت ﻧﺎاﻣﻦ‬ 43 ........................................ A10 – Failure to Restrict URL Access -URL ‫ﻛﻮﺗﺎﻫﻲ در ﻣﺤﺪود ﻛﺮدن دﺳﺘﺮﺳﻲ ﺑﻪ‬ 46 ...................................................................................................................................................................... ‫ﻣﻘﺼﺪ ﻧﻬﺎﻳﻲ‬ 49 ................................................................................................................................................................................. ‫ﻣﻨﺎﺑﻊ‬

‫ﻣﻘﺪﻣﻪ‬ ‫ﺑﻪ ‪ OWASP Top 10‬ﺧﻮش آﻣﺪﻳﺪ! ﺑﻪ ﻃﻮر ﻛﻠﻲ اﻳﻦ ﻧﺴﺨﻪ ﺑﺎزﻧﻮﻳﺴﻲ ﺷﺪه‪ ،‬ﻣﻬﻢ ﺗﺮﻳﻦ آﺳﻴﺐ ﭘﺬﻳﺮي ﻫﺎي ﻧﺮم اﻓﺰار ﻫﺎي ﺗﺤـﺖ‬ ‫وب را ﻓﻬﺮﺳﺖ ﻛﺮده و درﺑﺎره ﭼﮕﻮﻧﮕﻲ ﺣﻔﺎﻇﺖ از آن ﻫﺎ ﺑﺤﺚ ﻣﻲ ﻛﻨﺪ و ﻣﻨﺎﺑﻌﻲ را ﺑﺮاي اﻃﻼﻋﺎت ﺑﻴﺸﺘﺮ اراﺋﻪ ﻣﻲ دﻫﺪ‪.‬‬

‫ﻫﺪف‬ ‫ﻫﺪف اوﻟﻴﻪ ‪ OWASP Top 10‬آﻣﻮزش ﭘﻴﺎﻣﺪﻫﺎي راﻳﺞ ﺗﺮﻳﻦ آﺳﻴﺐ ﭘﺬﻳﺮي ﻫـﺎي اﻣﻨﻴﺘـﻲ ﻧـﺮم اﻓﺰارﻫـﺎي ﺗﺤـﺖ وب ﺑـﻪ ﺑﺮﻧﺎﻣـﻪ‬ ‫ﻧﻮﻳﺴﺎن‪ ،‬ﻃﺮاﺣﺎن‪ ،‬ﻣﻌﻤﺎران و ﺳﺎزﻣﺎن ﻫﺎ ﻣﻲ ﺑﺎﺷﺪ‪ Top 10 .‬روﺷﻬﺎي اﺳﺎﺳﻲ را ﺑﺮاي ﻣﺤﺎﻓﻈﺖ در ﻣﻘﺎﺑﻞ اﻳﻦ آﺳﻴﺐ ﭘﺬﻳﺮي ﻫﺎ اراﺋﻪ‬ ‫ﻣﻲ دﻫﺪ ‪ -‬ﺷﺮوﻋﻲ ﺑﺮاي ﺑﺮﻧﺎﻣﻪ ﻧﻮﻳﺴﻲ اﻣﻦ‪.‬‬ ‫اﻣﻨﻴﺖ روﻳﺪادي ﻧﻴﺴﺖ ﻛﻪ ﻳﻜﺒﺎره اﺗﻔﺎق ﺑﻴﻔﺘﺪ‪ .‬ﺻﺮﻓﺎ ﻳﻜﺒﺎر اﻣﻦ ﻛﺮدن ﻛﺪﻫﺎ ﻧﺎﻛﺎﻓﻲ اﺳﺖ‪ Top 10 .‬ﻫﺮ ﺳﺎل ﺗﻐﻴﻴﺮ ﭘﻴـﺪا ﻣـﻲ ﻛﻨـﺪ و‬ ‫ﺑﺪون ﺗﻐﻴﻴﺮ ﻛﺪﻫﺎ‪ ،‬ﻧﺮم اﻓﺰار ﻫﺎي ﺗﺤﺖ وب ﻣﻲ ﺗﻮاﻧﻨﺪ آﺳﻴﺐ ﭘﺬﻳﺮ ﺑﺎﺷﻨﺪ‪.‬‬ ‫ﺑﺮﻧﺎﻣﻪ ﻧﻮﻳﺴﻲ اﻣﻦ ﺑﺎﻳﺪ در ﺗﻤﺎﻣﻲ ﻣﺮاﺣﻞ ﭼﺮﺧﻪ ﺣﻴﺎت ﺑﺮﻧﺎﻣﻪ ﻣﺪ ﻧﻈﺮ ﻗﺮار ﺑﮕﻴﺮد‪ .‬ﻧﺮم اﻓﺰارﻫـﺎي ﺗﺤـﺖ وب اﻣـﻦ ﺗﻨﻬـﺎ درﺻـﻮرت‬ ‫ﺑﻜﺎرﮔﻴﺮي از ﻣﻜﺎﻧﻴﺰم ‪ SDLC‬اﻣﻦ و در ﺗﻤﺎﻣﻲ ﻣﺮاﺣﻞ اﻋﻢ از ﻃﺮاﺣﻲ‪ ،‬ﺗﻮﺳﻌﻪ و‪ ...‬ﺣﺎﺻﻞ ﻣﻲ ﮔﺮدد‪ .‬ﺣﺪاﻗﻞ ﺳﻴﺼﺪ ﭘﻴﺎﻣﺪ اﻣﻨﻴﺘـﻲ‬ ‫ﻧﺮم اﻓﺰارﻫﺎي ﺗﺤﺖ وب را ﺗﺤﺖ ﺗﺎﺛﻴﺮ ﻗﺮار ﻣﻴﺪﻫﻨﺪ ﻛﻪ ﺑﻪ ﺗﻔﺼﻴﻞ در ‪ OWASP GUIDE‬ﺑﻪ آن اﺷﺎره ﺷﺪه اﺳﺖ و ﺧﻮاﻧﺪن ان را‬ ‫ﺑﻪ ﺑﺮﻧﺎﻣﻪ ﻧﻮﻳﺴﺎن ﻧﺮم اﻓﺰارﻫﺎي ﺗﺤﺖ وب ﺗﻮﺻﻴﻪ ﻣﻲ ﻛﻨﻴﻢ‪.‬‬ ‫اﻳﻦ ﻣﺴﺘﻨﺪ اوﻟﻴﻦ و ﺑﻬﺘﺮﻳﻦ ﻧﻤﻮﻧﻪ آﻣﻮزﺷﻲ اﺳﺖ ﻧﻪ ﻓﻘﻂ ﻳﻚ اﺳﺘﺎﻧﺪارد‪ .‬ﻟﻄﻔﺎ اﻳﻦ ﻣﺴﺘﻨﺪ را ﺑﻪ ﻋﻨﻮان ﻳﻚ ﺳﻴﺎﺳﺖ ﻳﺎ اﺳﺘﺎﻧﺪارد ﺑـﺪون‬ ‫ﺻﺤﺒﺖ اوﻟﻴﻪ ﺑﺎ ﻣﺎ ﺑﻪ ﻃﻮر رﺳﻤﻲ ﻗﺒﻮل ﻧﻜﻨﻴﺪ‪ .‬اﮔﺮ ﺑﻪ ﺳﻴﺎﺳﺖ ﻳﺎ اﺳﺘﺎﻧﺪاردي ﺑﺮاي ﺑﺮﻧﺎﻣﻪ ﻧﻮﻳـﺴﻲ اﻣـﻦ اﺣﺘﻴـﺎج دارﻳـﺪ‪OWASP ،‬‬ ‫ﭘﺮوژه ﻫﺎﻳﻲ در ﻣﻮرد اﺳﺘﺎﻧﺪاردﻫﺎ و ﺳﻴﺎﺳﺘﻬﺎي ﺑﺮﻧﺎﻣﻪ ﻧﻮﻳﺴﻲ اﻣﻦ را در دﺳﺖ اﻗﺪام دارد‪.‬‬

‫ﻗﺪرداﻧﻲ‬ ‫از ‪ MITRE‬ﺑﺮاي اراﺋﻪ راﻳﮕﺎن و ﻗﺎﺑﻞ دﺳﺘﺮس آﺳﻴﺐ ﭘـﺬﻳﺮي ﻫـﺎ در ‪ CVE‬ﺗـﺸﻜﺮ ﻣـﻲ ﻛﻨـﻴﻢ‪.‬‬ ‫ﭘﺮوژه ‪ OWASP TOP 10‬ﺗﻮﺳﻂ ‪ Aspect Security‬رﻫﺒﺮي و ﺣﻤﺎﻳﺖ ﻣﻲ ﺷﻮد‪.‬‬ ‫ﻣﺪﻳﺮ ﭘﺮوژه‪) Andrew van der Stock :‬ﻣﺪﻳﺮ اﺟﺮاﻳﻲ ﺑﻨﻴﺎد ‪(OWASP‬‬ ‫ﺳﺎﻳﺮ ﻧﻮﻳﺴﻨﺪﮔﺎن‪) Jeff Wiliams :‬رﺋﻴﺲ ﺑﻨﻴﺎد ‪ (OWASP‬و ‪) Dave Wichers‬رﺋﻴﺲ ﻛﻨﻔﺮاﻧﺲ ‪(OWASP‬‬ ‫و ﻫﻤﭽﻨﻴﻦ ﺗﺸﻜﺮ ﻣﻲ ﻛﻨﻴﻢ از‪:‬‬

‫‪٢‬‬

‫‪OWASP Top 10 2007‬‬

‫‪ :Raul Endres 9‬ﺑﺨﺎﻃﺮ ﻣﺴﺎﻋﺪت در ﺗﻬﻴﻪ ‪ TOP 10‬ﺑﺎ ﺗﻮﺿﻴﺤﺎت ارزﺷﻤﻨﺪش‬ ‫‪ :Steve Christery (MITRE) 9‬ﺑﺮاي ﺗﺠﺪﻳﺪ ﻧﻈﺮ دﻗﻴﻖ و اﻓﺰودن اﻃﻼﻋﺎت ‪MITRE CWE‬‬ ‫‪9‬‬

‫)‪ :Jeremiah Grossman (Wite Hat Security‬ﺑﻪ ﺧﺎﻃﺮ ﺗﺠﺪﻳﺪ ﻧﻈﺮ دﻗﻴﻖ و اراﺋـﻪ اﻃﻼﻋـﺎت در ﺑـﺎره ﻣﻮﻓﻘﻴـﺖ‬ ‫اﺑﺰار ﺗﺸﺨﻴﺺ ﺧﻮدﻛﺎر‬

‫‪ :Sylvan von Stuppe 9‬ﺑﺨﺎﻃﺮ ﺗﺠﺪﻳﺪ ﻧﻈﺮ دﻗﻴﻖ و ﺷﺎﻳﺎن ﺗﻮﺟﻪ‬ ‫‪ Andre Gironda ، Nigel Evans ، Colin wrang 9‬و ‪ :Neil Smithline‬ﺑﺮاي ﺗﻮﺿـﻴﺤﺎت ﻣﻮﺛﺮﺷـﺎن از ﻃﺮﻳـﻖ‬ ‫‪email‬‬

‫‪٣‬‬

‫ﺧﻼﺻﻪ‬ ‫ﺿﻌﻔﻬﺎي ‪ XSS‬زﻣﺎﻧﻲ روي ﻣﻲ دﻫﻨﺪ ﻛﻪ ﻧـﺮم اﻓﺰارﻫـﺎي ﺗﺤـﺖ وب داده ﻫـﺎي ورودي ﻛـﺎرﻳﺮ را‬ ‫اﺟﺮاي اﺳﻜﺮﻳﭙﺖ ﺑﻴﻦ ﺳﺎﻳﺘﻲ‬

‫ﺑﺪون اﻋﺘﺒﺎرﺳﺎزي اوﻟﻴﻪ ﻳﺎ ‪ encode‬ﻛﺮدن ﺑﻪ ﻣﺮورﮔﺮ وب ارﺳﺎل ﻣـﻲ ﻛﻨـﺪ‪ .‬ﺿـﻌﻔﻬﺎي ‪ XSS‬ﺑـﻪ‬

‫‪A1-Cross Site Scripting‬‬

‫ﻣﻬﺎﺟﻤﻴﻦ اﺟﺎزه اﺟـﺮاي اﺳـﻜﺮﻳﭙﺖ ﻫﺎﻳـﺸﺎن را در ﻣﺮورﮔـﺮ ﻗﺮﺑـﺎﻧﻲ داده و اﻗـﺪام ﺑـﻪ ‪Session‬‬ ‫‪ Web site Deface ، Hijacking‬ﻳﺎ اﻧﺘﺸﺎر ‪Worm‬ﻫﺎي ﺗﺤﺖ وب ﻣﻲ ﻛﻨﻨﺪ‪.‬‬ ‫ﺿـــﻌﻔﻬﺎي ﺗﺰرﻳﻘـــﻲ ﺑـــﻮﻳﮋه ﺗﺰرﻳـــﻖ ‪ SQL‬از ﺟﻤﻠـــﻪ آﺳـــﻴﺐ ﭘـــﺬﻳﺮي ﻫـــﺎي راﻳـــﺞ‬ ‫ﻧﺮم اﻓﺰارﻫﺎي ﺗﺤﺖ وب ﻣﻲ ﺑﺎﺷﻨﺪ‪ .‬ﺗﺰرﻳﻖ ﻫﻨﮕﺎﻣﻲ ﻛـﻪ داده ورودي ﻛـﺎرﺑﺮ ﺑـﻪ ﻋﻨـﻮان ﺑﺨـﺸﻲ از‬

‫ﺿﻌﻒ ﻫﺎي ﺗﺰرﻳﻘﻲ‬

‫دﺳــــﺘﻮر ﻳــــﺎ ﭘــــﺮس و ﺟــــﻮ )‪ (query‬ﺑــــﻪ ﻣﻔــــﺴﺮ ﻓﺮﺳــــﺘﺎده ﻣــــﻲ ﺷــــﻮد‪ ،‬اﺗﻔــــﺎق‬

‫‪A2-Injection Flaws‬‬

‫ﻣﻲ اﻓﺘﺪ‪ .‬ورودي ﻫﺎي ﻣﺨﺮب ﻣﻬﺎﺟﻢ‪ ،‬ﻣﻔﺴﺮ را ﺑﺮاي اﺟﺮاي ﻏﻴﺮﻋﻤﺪي دﺳـﺘﻮرات ﻳـﺎ ﺗﻐﻴﻴـﺮ دادن‬ ‫داده ﻫﺎ ﻓﺮﻳﺐ ﻣﻲ دﻫﺪ‪.‬‬ ‫ﺑﺮﻧﺎﻣﻪ در ﺑﺮاﺑﺮ اﻟﺤﺎق ﻓﺎﻳﻞ از راه دور ‪ RFI‬آﺳﻴﺐ ﭘﺬﻳﺮاﺳﺖ و ﺑﻪ ﻣﻬﺎﺟﻢ اﺟﺎزه اﻟﺤـﺎق داده ﻫـﺎ و‬

‫اﺟﺮاي ﻓﺎﻳﻞ ﻣﺨﺮب‬

‫ﻛﺪﻫﺎي ﻣﺨﺮب را ﻣﻲ دﻫﺪ ﻛﻪ ﺳﺒﺐ اﻳﺠﺎد ﺣﻤﻼت ﻣﺨﺮب ﻣﺎﻧﻨﺪ ﻧﻔﻮذ ﺑﻪ ﺳﺮور ﻣﻲ ﺷﻮد‪ .‬ﺣﻤﻼت‬

‫‪A3-Malicoious File Execution‬‬

‫ﻣﺒﺘﻨﻲ ﺑﺮ ﻛﺪ ﻣﺨﺮب ﺑﺎ اﻟﺤﺎق ﻓﺎﻳﻞ ‪ XML ، PHP‬و ﻫﺮ ﺳﺎﺧﺘﺎري ﻛﻪ ﻓﺎﻳﻞ ﻳﺎ ﻧﺎم ﻓﺎﻳﻞ را از ﻛﺎرﺑﺮ‬ ‫درﻳﺎﻓﺖ ﻣﻲ ﻛﻨﺪ‪ ،‬ﺗﺤﺖ ﺗﺎﺛﻴﺮ ﻗﺮار ﻣﻲ دﻫﺪ‪.‬‬

‫ارﺟﺎع ﻣﺤﺎﻓﻈﺖ ﻧﺸﺪه ﻣﺴﺘﻘﻴﻢ ﺑﻪ ‪object‬‬ ‫‪A4-Insecure Direct Object‬‬ ‫‪Reference‬‬

‫ارﺟﺎع ﻣﺴﺘﻘﻴﻢ ﺑﻪ ‪ object‬ﻫﻨﮕﺎﻣﻲ رخ ﻣﻲ دﻫﺪ ﻛﻪ ﺑﺮﻧﺎﻣﻪ ﻧﻮﻳﺲ ﻳﻚ ارﺟـﺎع ﻳـﺎ ‪ reference‬ﺑـﻪ‬ ‫ﺷﻲ داﺧﻠﻲ ﻧﺮم اﻓﺰار ﻣﺎﻧﻨﺪ ﻓﺎﻳﻞ‪ ،‬ﭘﻮﺷﻪ‪ ،‬رﻛﻮرد ﭘﺎﻳﮕﺎه داده ﻳﺎ ﻛﻠﻴﺪ را ﺑﻪ ﻋﻨـﻮان ﭘـﺎراﻣﺘﺮ ‪ URL‬ﻳـﺎ‬ ‫ﻓﺮم در دﺳﺘﺮس ﻗﺮار ﻣﻲ دﻫﺪ‪ .‬ﻣﻬﺎﺟﻤﻴﻦ ﻣﻲ ﺗﻮاﻧﻨﺪ اﻳﻦ ‪ reference‬را ﺑﺮاي دﺳﺘﻴﺎﺑﻲ ﻏﻴﺮ ﻣﺠﺎز ﺑﻪ‬ ‫ﺳﺎﻳﺮ ‪ object‬ﻫﺎي ﻧﺮم اﻓﺰار دﺳﺘﻜﺎري ﻛﻨﺪ‪.‬‬ ‫ﺣﻤﻠﻪ ‪ ، CSRF‬ﻣﺮورﮔﺮ وب ﻗﺮﺑﺎﻧﻲ اﺣﺮاز ﻫﻮﻳﺖ ﺷﺪه را ﺑﻪ ﺻﻔﺤﻪ وﺑﻲ ﻫﺪاﻳﺖ ﻣﻲ ﻛﻨﺪ ﻛﻪ ﻋﻤﻞ‬

‫ﺟﻌﻞ درﺧﻮاﺳﺖ ﺑﻴﻦ ﺳﺎﻳﺘﻲ‬

‫ﻣﺨﺮب دﻟﺨﻮاه ﻣﻬﺎﺟﻢ ﻣﺎﻧﻨﺪ ﺗﻐﻴﻴﺮ آدرس ‪ email‬ﻛﺎرﺑﺮ را اﻧﺠـﺎم ﻣـﻲ دﻫـﺪ‪ .‬ﻣﻴـﺰان ﺧﻄـﺮ ﺣﻤﻠـﻪ‬

‫‪A5-Cross Site Request‬‬ ‫)‪Forgery(CSRF‬‬

‫‪ CSRF‬واﺑﺴﺘﻪ ﺑﻪ ﻗﺎﺑﻠﻴﺖ ﻫﺎﻳﻲ اﺳﺖ ﻛﻪ ﻧﺮم اﻓﺰار آﺳﻴﺐ ﭘﺬﻳﺮ در اﺧﺘﻴﺎر ﻛﺎرﺑﺮ ﻗﺮار ﻣﻲ دﻫﺪ‪.‬‬

‫ﻧﺸﺖ اﻃﻼﻋﺎت و ﻣﺪﻳﺮﻳﺖ ﺧﻄﺎي ﻧﺎدرﺳﺖ‬ ‫‪A6-Information Leakage and‬‬ ‫‪Improper Error Handling‬‬ ‫اﺣﺮاز ﻫﻮﻳﺖ و ﻣﺪﻳﺮﻳﺖ ﻧﺸﺴﺖ ﻧﺎﻗﺺ‬ ‫‪A7-Broken Authentication and‬‬ ‫‪Session Management‬‬ ‫اﻧﺒﺎره ﻣﺤﺎﻓﻈﺖ ﻧﺸﺪه رﻣﺰﻧﮕﺎري‬

‫ﻧﺮم اﻓﺰار ﻣﻲ ﺗﻮاﻧﺪ ﺑﻪ ﻃﻮر ﻏﻴﺮﻋﻤﺪي داراي ﻧﺸﺖ اﻃﻼﻋﺎت درﺑﺎره ﭘﻴﻜﺮﺑﻨﺪي‪ ،‬ﻃﺮز ﻛﺎر داﺧﻠﻲ ﻳـﺎ‬ ‫ﻧﻘﺾ ﺣﺮﻳﻢ ﺧﺼﻮﺻﻲ ﺑﻪ ﻋﻠﺖ ﻣﺸﻜﻼت ﻣﺨﺘﻠﻒ ﻧﺮم اﻓﺰاري ﺑﺎﺷﺪ‪ .‬ﻣﻬﺎﺟﻤﻴﻦ از اﻳﻦ ﺿﻌﻒ ﺑـﺮاي‬ ‫ﺳﺮﻗﺖ داده ﻫﺎي ﺣﺴﺎس ﻳﺎ اﺟﺮاي ﺣﻤﻼت ﺧﻄﺮﻧﺎﻛﺘﺮ اﺳﺘﻔﺎده ﻣﻲ ﻛﻨﻨﺪ‪.‬‬ ‫اﻋﺘﺒﺎرﻧﺎﻣﻪ ﻫﺎي ﺣﺴﺎب ﻛﺎرﺑﺮي و ‪ token‬ﻫﺎي ﻧﺸﺴﺖ اﻏﻠﺐ اوﻗـﺎت ﺑـﻪ ﺧـﻮﺑﻲ ﻣﺤﺎﻓﻈـﺖ ﻧﻤـﻲ‬ ‫ﺷﻮﻧﺪ‪ .‬ﺑﻪ اﻳﻦ ﺗﺮﺗﻴﺐ ﻣﻬﺎﺟﻤﻴﻦ ﻣﻲ ﺗﻮاﻧﻨﺪ ﺑﺎ ﺑﺪﺳﺖ آوردن ﮔﺬرواژه ﻫـﺎ‪ ،‬ﻛﻠﻴـﺪﻫﺎ ﻳـﺎ ‪ token‬ﻫـﺎي‬ ‫اﺣﺮاز ﻫﻮﻳﺖ از ﻫﻮﻳﺖ ﻛﺎرﺑﺮان ﺳﻮءاﺳﺘﻔﺎده ﻛﻨﻨﺪ‪.‬‬ ‫ﻧﺮم اﻓﺰار ﺗﺤﺖ وب ﺑﻪ ﻧﺪرت از ﺗﻮاﺑﻊ رﻣﺰﻧﮕﺎري ﺟﻬﺖ ﺣﻔﺎﻇﺖ از داده ﻫﺎ و اﻋﺘﺒﺎرﻧﺎﻣﻪ ﻫﺎ اﺳﺘﻔﺎده‬ ‫ﻣﻲ ﻛﻨﻨﺪ‪ .‬ﻣﻬﺎﺟﻤﻴﻦ از داده ﻫﺎﻳﻲ ﻛﻪ ﺑﺼﻮرت ﺿﻌﻴﻒ ﻣﺤﺎﻓﻈﺖ ﻣﻲ ﺷﻮﻧﺪ ﺑـﺮاي رﺑـﻮدن ﻫﻮﻳـﺖ و‬

‫‪A8-Insecure Cryptography‬‬ ‫‪Storage‬‬

‫دﻳﮕﺮ ﺟﺮاﺋﻤﻲ ﻣﺜﻞ ﺟﻌﻞ ﻛﺎرت ﻫﺎي اﻋﺘﺒﺎري اﺳﺘﻔﺎده ﻣﻲ ﻛﻨﻨﺪ‪.‬‬

‫ارﺗﺒﺎﻃﺎت ﻣﺤﺎﻓﻈﺖ ﻧﺸﺪه‬

‫ﻧﺮم اﻓﺰار ﻫﺎي ﺗﺤﺖ وب ﻋﻠﻲ رﻏﻢ ﺿﺮورت رﻣﺰﻧﮕﺎري ﺗﺮاﻓﻴﻚ ﺷﺒﻜﻪ ﺑﺮاي ﺣﻔﺎﻇﺖ از ارﺗﺒﺎﻃـﺎت‬

‫‪A9-Insecure Communication‬‬

‫ﺣﺴﺎس‪ ،‬در اﻳﻦ اﻣﺮ ﻛﻮﺗﺎﻫﻲ ﻣﻲ ﻛﻨﻨﺪ‪.‬‬

‫ﻛﻮﺗﺎﻫﻲ در ﻣﺤﺪود ﻛﺮدن دﺳﺘﺮﺳﻲ ﺑﻪ‬

‫ﻧﺮم اﻓﺰار ﻫﺎ ﺟﻬﺖ ﻣﺤﺎﻓﻈﺖ از ﻋﻤﻠﻜﺮدﻫﺎي ﺣﺴﺎس ﺗﻨﻬﺎ ﭘﻴﺸﮕﻴﺮي از ﻧﻤﺎﻳﺶ ﻟﻴﻨـﻚ ﻫـﺎ و ‪URL‬‬

‫‪URL‬‬ ‫‪A10-Failure To Restrict URL‬‬ ‫‪Access‬‬

‫ﻫﺎ را ﺑﺮاي ﻛﺎرﺑﺮان ﻏﻴﺮ ﻣﺠﺎز ﺑﻪ ﻛﺎر ﻣﻲ ﮔﻴﺮﻧﺪ در ﺣﺎﻟﻴﻜﻪ ﻣﻬﺎﺟﻤﻴﻦ ﺑﺎ دﺳﺘﺮﺳﻲ ﻣﺴﺘﻘﻴﻢ ﺑـﻪ ‪URL‬‬ ‫ﻫﺎ ﻣﻲ ﺗﻮاﻧﻨﺪ از اﻳﻦ ﺿﻌﻒ ﺑﺮاي دﺳﺘﺮﺳﻲ و اﻧﺠﺎم ﻛﺎرﻫﺎي ﻏﻴﺮ ﻣﺠﺎز اﺳﺘﻔﺎده ﻛﻨﻨﺪ‪.‬‬

‫ﺟﺪول‪ 10 :1‬آﺳﻴﺐ ﭘﺬﻳﺮي ﺑﺮﺗﺮ ﻧﺮم اﻓﺰارﻫﺎي ﺗﺤﺖ وب در ﺳﺎل ‪2007‬‬

‫‪٤‬‬

‫‪OWASP Top 10 2007‬‬

‫روش ﺷﻨﺎﺳﻲ‬ ‫روش ﻣﺎ ﺑﺮاي ‪ TOP 10 2007‬ﺳﺎده ﺑﻮد‪ :‬روﻧﺪ آﺳﻴﺐ ﭘﺬﻳﺮي ﻫﺎي ﺳﺎل ‪ 2006‬را از ‪ MITRE‬درﻳﺎﻓﺖ ﻛﺮدﻳﻢ و ﺣﺎﺻﻞ ﺧﻼﺻﻪ‬ ‫آن ‪ TOP 10‬اﻣﻨﻴﺖ ﻧﺮم اﻓﺰارﻫﺎي ﺗﺤﺖ وب ﭘﻴﺶ رو اﺳﺖ‪.‬‬ ‫ﻧﺘﺎﻳﺞ رﺗﺒﻪ ﺑﻨﺪي ﺷﺎﻣﻞ ﻧﻤﻮدار زﻳﺮ ﻣﻲ ﺑﺎﺷﺪ‪:‬‬

‫داده ﻫﺎي ‪ MITRE‬درﺑﺎره ده ﻣﻮرد آﺳﻴﺐ ﭘﺬﻳﺮي ﻧﺮم اﻓﺰارﻫﺎي ﺗﺤﺖ وب در ﺳﺎل ‪ : 2006‬ﻧﻤﻮدار )‪(2‬‬

‫ﺷﻜﻞ ‪ :2‬اﻃﻼﻋﺎت ‪ MITRE‬در ﻣﻮرد ‪ 10‬آﺳﻴﺐ ﭘﺬﻳﺮي ﺑﺮﺗﺮ ﻧﺮم اﻓﺰارﻫﺎي ﺗﺤﺖ وب در ﺳﺎل ‪2006‬‬ ‫اﮔﺮ ﭼﻪ ﻣﺎ در ﺣﻔﻆ ﻳﻜﺎﻳﻚ داده ﻫﺎي آﺳﻴﺐ ﭘﺬﻳﺮي اوﻟﻴﻪ ‪ MITRE‬در ﺗﺒﺪﻳﻞ ﺑﻪ ﻋﻨﺎوﻳﻦ ﺳﺮﻓﺼﻞ ﻫﺎﻳﻤﺎن ﺗـﻼش ﻛـﺮده اﻳـﻢ وﻟـﻲ‬ ‫ﺑﻌﻀﻲ از ﻃﺒﻘﻪ ﺑﻨﺪي ﻫﺎ را ﺑﺮاي ﺗﺮﺳﻴﻢ دﻗﻴﻖ ﺗﺮ ﻋﻠﺖ ﻫﺎي اﺳﺎﺳﻲ ﺗﻐﻴﻴﺮ داده اﻳﻢ‪ .‬اﮔﺮ ﻋﻼﻗﻪ ﻣﻨﺪ ﺑـﻪ داده ﻫـﺎي اوﻟﻴـﻪ ‪ MITRE‬در‬ ‫ﭘﺎﻳﺎن ﺳﺎل ‪ 2006‬ﻫﺴﺘﻴﺪ ﻣﻲ ﺗﻮاﻧﻴﺪ آن را ﺑﺼﻮرت ﻓﺎﻳﻞ ‪ Excel‬در ﺳﺎﻳﺖ ‪ OWASP TOP 10‬ﺑﻴﺎﺑﻴﺪ‪.‬‬ ‫ﺗﻤﺎﻣﻲ ﻣﺤﺎﻓﻈﺖ ﻫﺎي ﺗﻮﺻﻴﻪ ﺷﺪه راه ﺣﻞ ﻫﺎﻳﻲ را ﺑﺮاي ﻣﺘﺪاوﻟﺘﺮﻳﻦ ﺳﺎﺧﺘﺎرﻫﺎي ﻧـﺮم اﻓﺰارﻫـﺎي ﺗﺤـﺖ وب ﻣﺜـﻞ ‪ Ruby‬ﺑـﺮ روي‬ ‫‪ Rails‬ﻳﺎ ‪ Perl‬را ﻣﻲ ﺗﻮان ﺑﻪ آﺳﺎﻧﻲ ﺑﺎ ﺗﻮﺻﻴﻪ ﻫﺎي ﻣﺘﻨﺎﺳﺐ ﺑﺎ ﻧﻴﺎزﻫﺎي ﺧﺎص اﻳﻦ ﻧﺮم اﻓﺰارﻫﺎ ﺗﻄﺎﺑﻖ داد‪.‬‬

‫ﭼﺮا ﺑﺮﺧﻲ ﻣﻮﺿﻮﻋﺎت ﻣﻬﻢ را ﺣﺬف ﻛﺮده اﻳﻢ؟‬ ‫ورودي ﻣﻌﺘﺒﺮﺳﺎزي ﻧﺸﺪه ﻳﻜﻲ از ﭼﺎﻟﺶ ﻫﺎي ﻣﻬﻢ ﺑﺮاي ﻫﺮ ﮔﺮوه ﺑﺮﻧﺎﻣﻪ ﻧﻮﻳﺴﻲ و از اﺳﺎﺳﻲ ﺗﺮﻳﻦ ﻣﺸﻜﻼت اﻣﻨﻴﺘﻲ ﺑﺴﻴﺎري از ﻧـﺮم‬ ‫اﻓﺰارﻫﺎي ﺗﺤﺖ وب ﻣﻲ ﺑﺎﺷﺪ‪ .‬در ﺣﻘﻴﻘﺖ‪ ،‬ﺑﺴﻴﺎري از آﻳﺘﻢ ﻫﺎي ﻣﻮﺟﻮد در ﻓﻬﺮﺳﺖ ﻣﻄﺎﻟﺐ‪ ،‬ورودي ﻫﺎي ﻣﻌﺘﺒﺮ را ﺑﻪ ﻋﻨﻮان ﺑﺨﺸﻲ‬ ‫از راه ﺣﻞ ﻣﻌﺮﻓﻲ ﻣﻲ ﻛﻨﻨﺪ‪ .‬ﻣﺎ ﺷﺪﻳﺪا ﺑﻪ اﻳﺠﺎد ﻳﻚ ﻣﻜﺎﻧﻴﺰم ﻣﻌﺘﺒﺮﺳﺎزي ورودي ﻣﺘﻤﺮﻛﺰ ﺑﻪ ﻋﻨﻮان ﺑﺨـﺸﻲ از ﻧـﺮم اﻓـﺰار ﺗﺤـﺖ وب‬ ‫ﺗﻮﺻﻴﻪ ﻣﻲ ﻛﻨﻴﻢ‪ .‬ﺑﺮاي اﻃﻼﻋﺎت ﺑﻴﺸﺘﺮ ﻣﻘﺎﻻت ﻣﺸﺮوﺣﻪ زﻳﺮ درﺧﺼﻮص ﻣﻌﺘﺒﺮﺳﺎزي داده ﻫﺎ را در ﺳﺎﻳﺖ ‪ OWASP‬ﻣﻄﺎﻟﻌﻪ ﻛﻨﻴﺪ‪:‬‬ ‫ƒ‬

‫‪http://www.owasp.org/index.php/Data_Validation‬‬

‫‪٥‬‬

‫ƒ‬

‫‪http://www.owasp.org/index.php/Testing_for_Data_Validation‬‬

‫ﭘﻴﺎﻣﺪﻫﺎي ‪ Integer overflows ، Buffer overflows‬و ‪ Format string‬ﺑﻪ ﻋﻨﻮان آﺳـﻴﺐ ﭘـﺬﻳﺮﻳﻬﺎي ﺑـﺴﻴﺎر‬ ‫ﺟﺪي ﺑﺮاي ﺑﺮﻧﺎﻣﻪ ﻫﺎي ﻧﻮﺷﺘﻪ ﺷﺪه ﺑﻪ زﺑﺎﻧﻬﺎﻳﻲ ﻣﺎﻧﻨﺪ ‪ C‬ﻳﺎ ‪ C++‬ﺗﻠﻘﻲ ﻣﻲ ﺷﻮﻧﺪ‪ .‬اﺻﻼﺣﺎﺗﻲ ﺑﺮاي اﻳـﻦ ﮔﻮﻧـﻪ ﭘﻴﺎﻣـﺪﻫﺎ‬ ‫ﺑﻮﺳﻴﻠﻪ اﻧﺠﻤﻦ ﻫﺎي اﻣﻨﻴﺘﻲ ﺑﺮﻧﺎﻣﻪ ﻫﺎي ﻏﻴﺮ وﺑﻲ ﻣﺜﻞ ‪ SANS‬و ‪ CERT‬و ﻓﺮوﺷﻨﺪﮔﺎن اﺑﺰارﻫﺎي زﺑﺎن ﺑﺮﻧﺎﻣﻪ ﻧﻮﻳﺴﻲ اراﺋﻪ‬ ‫ﻣﻲ ﺷﻮد‪ .‬اﮔﺮ ﺑﺮﻧﺎﻣﻪ ﺷﻤﺎ ﺑﻪ زﺑﺎﻧﻲ ﻧﻮﺷﺘﻪ ﺷﺪه اﺳﺖ ﻛﻪ اﺣﺘﻤﺎل دارد در ﻣﻘﺎﺑﻞ ‪ buffer overflows‬آﺳﻴﺐ ﭘﺬﻳﺮ ﺑﺎﺷﺪ‪،‬‬ ‫ﻣﺎ ﺷﻤﺎ را ﺑﻪ ﺧﻮاﻧﺪن ﻣﻄﺎﻟﺒﻲ در ﻣﻮرد ‪ Buffer overflow‬در ﺳﺎﻳﺖ ‪ OWASP‬دﻋﻮت ﻣﻲ ﻛﻨﻴﻢ‪.‬‬ ‫‪http://www.owasp.org/index.php/Buffer_overflow‬‬

‫ƒ‬

‫‪http://www.owasp.org/index.php/Testing_for_Buffer_Overflow‬‬

‫ƒ‬

‫‪ Denial of service‬ﻳﻜﻲ از ﺣﻤﻼت ﻣﻬﻤﻲ اﺳﺖ ﻛﻪ ﻣﻲ ﺗﻮاﻧﺪ ﻫﺮ ﺳﺎﻳﺘﻲ را ﺑﺎ ﻫﺮ زﺑﺎﻧﻲ ﺗﺤﺖ ﺗﺎﺛﻴﺮ ﻗﺮار دﻫﺪ‪ .‬رﺗﺒﻪ ‪ DOS‬ﻛـﻪ‬ ‫ﺑﻮﺳﻴﻠﻪ ‪ MITRE‬اﻋﻼم ﺷﺪه ﺑﺮاي ﭘﺬﻳﺮﻓﺘﻦ آن در ده آﺳﻴﺐ ﭘﺬﻳﺮي ﺑﺮﺗﺮ ﻛﺎﻓﻲ ﻧﻴﺴﺖ‪ .‬اﮔﺮ ﺷﻤﺎ درﺑﺎره ﺣﻤﻠﻪ ‪ DOS‬ﻧﮕﺮان ﻫـﺴﺘﻴﺪ‪،‬‬ ‫ﺑﺎ ﺳﺎﻳﺖ ‪ OWASP‬ﻣﺸﻮرت و راﻫﻨﻤﺎي آزﻣﺎﻳﺶ آن را ﻣﻄﺎﻟﻌﻪ ﻛﻨﻴﺪ‪:‬‬ ‫‪http://www.owasp.org/index.php/Category:Denial_of_Service_Attack‬‬

‫ƒ‬

‫‪http://www.owasp.org/index.php/Testing_for_Denial_of_Service‬‬

‫ƒ‬

‫ﻣﺪﻳﺮﻳﺖ ﺣﻔﺎﻇﺖ ﻧﺸﺪه ﭘﻴﻜﺮﺑﻨﺪي‪ ،‬ﺗﻤﺎﻣﻲ ﺳﻴﺴﺘﻢ ﻫﺎ ﺑﻮﻳﮋه ‪ PHP‬را ﺗﺤﺖ ﻧﺎﺛﻴﺮ ﻗﺮار ﻣﻲ دﻫﺪ‪ .‬اﻣﺎ رﺗﺒﻪ ﺑﻨﺪي اﻣﺴﺎل ‪ MITRE‬ﺑـﻪ‬ ‫ﻣﺎ اﺟﺎزه ﮔﻨﺠﺎﻧﺪن اﻳﻦ ﻣﻮﺿﻮع را ﻧﻤﻲ دﻫﺪ‪ .‬ﻫﻨﮕﺎم ﺗﻮﺳﻌﻪ ﻧﺮم اﻓﺰار آﺧﺮﻳﻦ راﻫﻨﻤﺎي ‪ OWASP‬و راﻫﻨﻤﺎي آزﻣـﺎﻳﺶ ‪OWASP‬‬ ‫را ﺑﺮاي اﻃﻼﻋﺎت ﺟﺰﺋﻲ ﺗﺮ در ﻣﻮرد ﺑﺮرﺳﻲ و ﻣﺪﻳﺮﻳﺖ ﺣﻔﺎﻇﺖ ﺷﺪه ﭘﻴﻜﺮﺑﻨﺪي ﻣﻄﺎﻟﻌﻪ ﻛﻨﻴﺪ‪:‬‬ ‫‪http://www.owasp.org/index.php/Configuration‬‬

‫ƒ‬

‫‪http://www.owasp.org/index.php/Testing_for_infrastructure_configuration_management‬‬

‫ƒ‬

‫ﭼﺮا ﺑﺮﺧﻲ ﻣﻮﺿﻮﻋﺎت ﻣﻬﻢ را اﺿﺎﻓﻪ ﻛﺮده اﻳﻢ؟‬ ‫)‪ Cross Site Request Forgery (CSRF‬ﻣﻮﺿﻮع ﻣﻬﻢ و ﺟﺪﻳـﺪ اﺿـﺎﻓﻪ ﺷـﺪه ﺑـﻪ اﻳـﻦ ﻧـﺴﺨﻪ ‪OWASP TOP 10‬‬ ‫ﻣﻲ ﺑﺎﺷﺪ‪ .‬اﮔﺮ ﭼﻪ رﺗﺒﻪ آن در داده ﻫﺎي اوﻟﻴﻪ رﺗﺒﻪ ﺳﻲ و ﺷﺸﻢ اﺳﺖ وﻟﻲ ﻣﺎ ﻣﻌﺘﻘﺪﻳﻢ اﻫﻤﻴﺖ آن ﺑﻪ ﻗﺪري اﺳﺖ ﻛﻪ ﻧﺮم اﻓﺰارﻫﺎ ﺑﺎﻳﺪ‬

‫‪٦‬‬

‫‪OWASP Top 10 2007‬‬

‫ﺑﺮاي ﻣﺤﺎﻓﻈﺖ در ﻣﻘﺎﺑﻞ آن ﺗﻼش ﻛﻨﻨﺪ‪ .‬ﺑﻮﻳﮋه ﺑﺮاي ﻧﺮم اﻓﺰارﻫﺎي ﺑﺎ ارزش ﺑﺎﻻ و ﺑﺮﻧﺎﻣﻪ ﻫﺎﻳﻲ ﻛﻪ ﺑﺎ داده ﻫـﺎي ﺣـﺴﺎس ﺳـﺮ و ﻛـﺎر‬ ‫دارﻧﺪ‪ CSRF .‬اﻛﻨﻮن ﺷﺎﻳﻊ ﺗﺮ از رﺗﺒﻪ ﺑﻨﺪي ﻛﻪ ﺗﺎﻛﻨﻮن ﻧﺸﺎن داده ﻇﺎﻫﺮ ﺷﺪه و ﻣﻤﻜﻦ اﺳﺖ ﺑﺴﻴﺎر ﺧﻄﺮﻧﺎك ﺑﺎﺷﺪ‪.‬‬ ‫‪ :Cryptography‬ﺑﺮ اﺳﺎس داده ﻫﺎي اوﻟﻴﻪ ‪ MITRE‬ﺑﻜﺎرﮔﻴﺮي ﺣﻔﺎﻇﺖ ﻧﺸﺪه رﻣﺰﻧﮕﺎري ﻣﻮﺿﻮع ﻫﺸﺘﻢ و ﻧﻬﻢ اﻣﻨﻴـﺖ ﻧـﺮم‬ ‫اﻓﺰارﻫﺎي ﺗﺤﺖ وب ﻧﻴﺴﺖ‪ .‬اﻣﺎ ﻋﻠﺖ اﺻﻠﻲ ﺑﺴﻴﺎري از ﻧﺸﺖ ﻫﺎي اﻃﻼﻋﺎت ﺧﺼﻮﺻﻲ و ﻧﺘﻴﺠﻪ ﭘﻴﺎﻣﺪﻫﺎي آن ﻣﻲ ﺑﺎﺷﺪ‪) .‬ﻣﺨـﺼﻮﺻﺎ‬ ‫ﺑﺎ ﭘﺬﻳﺮش ‪(PCI DSS 1.1‬‬

‫آﺳﻴﺐ ﭘﺬﻳﺮي ﻫﺎ‪ ،‬ﻧﻪ ﺣﻤﻼت‬ ‫ﻧﺴﺨﻪ ﻗﺒﻠﻲ ‪ TOP 10‬ﺗﺮﻛﻴﺒﻲ از ﺣﻤﻼت‪ ،‬آﺳﻴﺐ ﭘﺬﻳﺮي ﻫـﺎ واﻗـﺪاﻣﺎت ﻣﺘﻘﺎﺑـﻞ را در ﺑـﺮ ﻣـﻲ ﮔﺮﻓـﺖ‪ .‬ﻫـﺮ ﭼﻨـﺪ ﮔـﺎﻫﻲ اوﻗـﺎت‬ ‫اﺻﻄﻼﺣﺎﺗﻲ ﺗﺮﻛﻴﺒﻲ از آﺳﻴﺐ ﭘﺬﻳﺮي ﻫﺎ و ﺣﻤﻼت ﺑﻜﺎر رﻓﺘـﻪ اﻣـﺎ در اﻳـﻦ ﻧـﺴﺨﻪ ﻣـﺎ ﻓﻘـﻂ ﺑـﺮ روي آﺳـﻴﺐ ﭘـﺬﻳﺮي ﻫـﺎ ﻣﺘﻤﺮﻛـﺰ‬ ‫ﺷﺪه اﻳﻢ‪ .‬اﺳﺘﻔﺎده ﺳﺎزﻣﺎن ﻫﺎ از اﻳﻦ ﻣﺴﺘﻨﺪ ﺑﺮاي اﻣﻦ ﻛﺮدن ﺑﺮﻧﺎﻣﻪ ﻫﺎ و ﻛﺎﻫﺶ ﻣﺨﺎﻃﺮات ﺗﺠﺎري ﻣﻨﺠﺮ ﺑـﻪ ﻛـﺎﻫﺶ ﻣـﺴﺘﻘﻴﻢ اﺣﺘﻤـﺎل‬ ‫وﻗﻮع ﻣﻮارد زﻳﺮ ﻣﻲ ﺷﻮد‪:‬‬ ‫ƒ‬

‫ﺣﻤﻼت ‪ : Phishing‬اﻳﻦ ﺣﻤﻼت ﻣﻲ ﺗﻮاﻧﻨﺪ از ﻫﺮ ﻛﺪام از اﻳﻦ آﺳﻴﺐ ﭘﺬﻳﺮي ﻫﺎ ﺑﻮﻳﮋه ‪ ، XSS‬ﺿﻌﻒ و ﻋﺪم وﺟـﻮد‬ ‫اﺣﺮاز ﻫﻮﻳﺖ ﻳﺎ ﺑﺮرﺳﻲ ﻫﺎي ﻣﺠﺎزﺷﻤﺎري )‪ (A1,A4,A7,A10‬ﺑﻬﺮه ﺑﺮداري )‪ (exploit‬ﻛﻨﻨﺪ‪.‬‬

‫ƒ‬

‫ﻧﻘــﺾ ﺣــﺮﻳﻢ ﺧــﺼﻮﺻﻲ‪ :‬از ﻣﻌﺘﺒﺮﺳــﺎزي ﺿــﻌﻴﻒ‪ ،‬ﻗــﻮاﻧﻴﻦ ﺗﺠــﺎري و ﺿــﻌﻒ ﺑﺮرﺳــﻲ ﻣﺠﺎزﺷــﻤﺎري اﺳــﺘﻔﺎده‬ ‫ﻣﻲ ﻛﻨﺪ‪(A2,A4,A6,A7,A10).‬‬

‫ƒ‬

‫ﺳﺮﻗﺖ ﻫﻮﻳﺖ‪ :‬از ﻃﺮﻳﻖ ﻧﺒﻮد ﻳﺎ ﺿﻌﻒ ﻛﻨﺘﺮل ﻫﺎي ﻣﺠﺎزﺷﻤﺎري )‪ ،(A8,A9‬اﻟﺤﺎق ﻓﺎﺑﻞ از راه دور )‪،(A3‬ﺑﺮرﺳـﻲ ﻫـﺎي‬ ‫اﺣﺮاز ﻫﻮﻳﺖ‪ ،‬ﻗﻮاﻋﺪ ﺗﺠﺎري و ﻣﺠﺎزﺷﻤﺎري ﺻﻮرت ﻣﻲ ﮔﻴﺮد‪.‬‬

‫ƒ‬

‫ﻧﻔﻮذ ﺑﻪ ﺳﻴﺴﺘﻢ ﻫﺎ‪ ،‬ﺗﻐﻴﻴﺮ ﻳﺎ ﺗﺨﺮﻳﺐ داده ﻫﺎ‪ :‬اﻳﻦ ﺣﻤﻼت از ﻃﺮﻳﻖ ﺗﺰرﻳـﻖ ﻫـﺎ )‪ (A2‬و اﻟﺤـﺎق ﻓﺎﻳـﻞ از راه دور )‪(A3‬‬ ‫ﺻﻮرت ﻣﻲ ﭘﺬﻳﺮد‪.‬‬

‫ƒ‬

‫ﺧﺴﺎرت ﻣﺎﻟﻲ‪ :‬از ﻃﺮﻳﻖ ﺗﺮاﻛﻨﺶ ﻫﺎي ﻏﻴﺮ ﻣﺠﺎز و ﺣﻤﻼت ‪ CSRF‬ﺻﻮرت ﻣﻲ ﭘﺬﻳﺮد‪(A4,A5,A7,A10) .‬‬

‫ƒ‬

‫ﻋﺪم اﻧﻜﺎر‪ :‬از ﻃﺮﻳﻖ ﺑﻬﺮه ﺑﺮداري )‪ (exploit‬از ﻫﺮ ﻛﺪام از آﺳﻴﺐ ﭘﺬﻳﺮي ﻫﺎي ﺑﺎﻻ اﻣﻜﺎن ﭘﺬﻳﺮاﺳﺖ‪(A1 … A10) .‬‬

‫‪٧‬‬

‫ ﻛـﺎﻫﺶ‬،‫ ﻣﻮﻓﻘﻴـﺖ در ﻛـﺎﻫﺶ ﻣﺨـﺎﻃﺮات ﻛـﺎرﺑﺮدي ﺗﺠـﺎري‬،‫رﻫﺎﻳﻲ ﺳﺎزﻣﺎن از ﻫـﺮ ﮔﻮﻧـﻪ ﻧﮕﺮاﻧـﻲ درﺑـﺎره ﻛﻨﺘـﺮل ﻫـﺎي واﻛﻨـﺸﻲ‬ ‫ اﻓﺰاﻳﺶ رﺿﺎﻳﺖ ﻫﻤﺮاه ﺑﺎ ﭘﻴﺸﺮﻓﺖ ﻗﺎﻋﺪه ﻣﻨﺪ و در اﺧﺘﻴﺎر داﺷﺘﻦ ﺳﻴﺴﺘﻢ ﻫﺎي اﻣـﻦ و ﻗـﻮي ﺑـﻪ ﻋﻨـﻮان ﻧﺘـﺎﻳﺞ‬،‫ﻫﺰﻳﻨﻪ ﻫﺎي ﻋﻤﻠﻴﺎﺗﻲ‬ .‫ﻣﺤﺎﻓﻈﺖ ﺳﻴﺴﺘﻢ در ﻣﻘﺎﺑﻞ اﻳﻦ آﺳﻴﺐ ﭘﺬﻳﺮي ﻫﺎ اﺳﺖ‬

‫اﻋﺘﺒﺎر‬ ‫ ﺑﻮﻳﮋه ﮔﺰارش ﻫﺎي اراﻳـﻪ ﺷـﺪه آن درﺑـﺎره ﺷـﻴﻮه ﻫـﺎي ﺑﻜﺎرﮔﺮﻓﺘـﻪ ﺷـﺪه ﺗﻮﺳـﻂ‬actual attack ‫اﻳﻦ ﻃﺮح ﻣﺸﺎﺑﻪ روش ﻫﺎي‬ ‫ ﺣﻔﺎﻇﺖ اﻧﺪﻛﻲ را در‬، ‫ آﺳﻴﺐ ﭘﺬﻳﺮي ﻣﻬﻢ‬10 ‫ ﻣﺤﺎﻓﻈﺖ از ﻧﺮم اﻓﺰار ﺗﻨﻬﺎ در ﻣﻘﺎﺑﻞ اﻳﻦ‬.‫ ﻣﻲ ﺑﺎﺷﺪ‬script kiddy ‫ﻣﻬﺎﺟﻤﻴﻦ ﻣﺒﺘﺪي‬ .‫ اﻣﺎ ﻣﻬﻢ ﺗﺮ از آن ﺑﻜﺎرﮔﻴﺮي روش ﻫﺎي ارﺗﻘﺎء اﻣﻨﻴﺘﻲ ﻧﺮم اﻓﺰار ﻣﻲ ﺑﺎﺷﺪ‬،‫ﻣﻘﺎﺑﻞ راﻳﺞ ﺗﺮﻳﻦ ﻧﻮع ﺣﻤﻼت اﻣﻜﺎن ﭘﺬﻳﺮ ﻣﻲ ﺳﺎزد‬

‫ﺗﻐﻴﻴﺮات‬ ‫ ﺑـﻪ دﻟﻴـﻞ ﺑـﻪ روز ﻧـﺸﺪن‬.‫ در ﻣﻮاردي ﻧﻴـﺰ ﻣﺤﺘـﻮا ﺑـﺴﻴﺎر ﻧﺰدﻳـﻚ ﺑـﻪ ﻣﺤﺘـﻮاي ﻗﺒﻠـﻲ اﺳـﺖ‬،‫ﺗﻐﻴﻴﺮاﺗﻲ در ﺳﺮﻓﺼﻞ ﻫﺎ ﺑﻮﺟﻮد آﻣﺪه‬ ‫ ﺟﺪول زﻳـﺮ ﭼﮕـﻮﻧﮕﻲ ﺗﺒـﺪﻳﻞ‬.‫ ﺧﻮدداري ﻛﺮده اﻳﻢ‬WAS XML ‫ از ﻣﻄﺮح ﻛﺮدن ﻧﺎم‬،‫ ﺣﻤﻼت و اﻗﺪاﻣﺎت ﻣﺘﻘﺎﺑﻞ‬،‫آﺳﻴﺐ ﭘﺬﻳﺮﻳﻬﺎ‬ .‫ ﻧﺸﺎن ﻣﻲ دﻫﺪ‬MITRE ‫ و رﺗﺒﻪ ﺑﻨﺪي اوﻟﻴﻪ‬2007 ‫ را ﺑﻪ ﻧﺴﺨﻪ‬TOP 10 2004 ‫ﻧﺴﺨﻪ‬ OWASP Top 10 2007

OWASP Top 10 2004

MITRE 2006 Raw Ranking

A1. Cross Site Scripting (XSS)

A4. Cross Site Scripting (XSS)

1

A2. Injection Flaws

A6. Injection Flaws

2

A3. Malicious File Execution (NEW) A4. Insecure Direct Object Reference

3 A2. Broken Access Control (split in 2007 T10)

A5. Cross Site Request Forgery (CSRF)

36

(NEW) A6. Information Leakage and Improper Error Handling A7. Broken Authentication and Session Management A8. Insecure Cryptographic Storage A9. Insecure Communications (NEW)

5

A7. Improper Error Handling

6

A3. Broken Authentication and Session Management

14

A8. Insecure Storage

8

Discussed under A10. Insecure Configuration Management

8

A10. Failure to Restrict URL Access

A2. Broken Access Control (split in 2007 T10)

14



A1. Unvalidated Input

7



A5. Buffer Overflows

4,8 and 10



A9. Denial of Service

17



A10. Insecure Configuration Management

29

٨

‫‪OWASP Top 10 2007‬‬

‫اﺟﺮاي اﺳﻜﺮﻳﭙﺖ ﺑﻴﻦ ﺳﺎﻳﺘﻲ‬

‫)‪A1 – CROSS SITE SCRIPTING (XSS‬‬

‫‪ Cross Site Scripting‬ﻛﻪ ﺑﻪ ‪ XSS‬ﻧﻴﺰ ﻣﺸﻬﻮر اﺳﺖ‪ ،‬در ﺣﻘﻴﻘـﺖ زﻳـﺮ ﻣﺠﻤﻮﻋـﻪاي از ‪ HTML injection‬اﺳـﺖ‪XSS .‬‬ ‫ﻣﺘﺪاول ﺗﺮﻳﻦ و ﻣﺨﺮبﺗﺮﻳﻦ ﺣﻤﻠﻪ ﺑﺮاي ﺑﻪ ﺧﻄﺮ اﻧـﺪاﺧﺘﻦ اﻣﻨﻴـﺖ ﻧـﺮماﻓﺰارﻫـﺎي ﺗﺤـﺖ وب اﺳـﺖ‪ .‬ﺿـﻌﻔﻬﺎي ‪ XSS‬زﻣـﺎﻧﻲ روي‬ ‫ﻣﻲ دﻫﻨﺪ ﻛﻪ ﻧﺮم اﻓﺰار‪ ،‬داده ﻫﺎي ورودي ﻛﺎرﺑﺮ را ﺑﺪون ارزﻳﺎﺑﻲ ﻳﺎ ‪ encode‬ﻛﺮدن ﺑﻪ ﻣﺮورﮔﺮ وب ارﺳﺎل ﻛﻨﺪ‪ XSS .‬ﺑﻪ ﻣﻬـﺎﺟﻤﻴﻦ‬ ‫اﺟﺎزه اﺟﺮاي اﺳﻜﺮﻳﭙﺘﻲ را در ﻣﺮورﮔﺮ ﻗﺮﺑﺎﻧﻲ ﻣﻲدﻫﺪ ﻛﻪ ﻣﻲﺗﻮاﻧﺪ ﻣﻨﺠﺮ ﺑﻪ ﺳﺮﻗﺖ ‪ Session‬ﻫـﺎ )‪ ،(Session hijacking‬ﺗﻐﻴﻴـﺮ‬ ‫ﻇﺎﻫﺮ وب ﺳﺎﻳﺖ)‪ ،(defacing‬ورود ﻛﺪ ﻣﺨﺮب )‪ (hostil content‬و ﻧﻴﺰ ﺣﻤﻼت ﺳﺮﻗﺖ اﻃﻼﻋﺎت )‪ (phishing attack‬ﺷﻮد‬ ‫و ﻣﺮورﮔﺮ ﻛﺎرﺑﺮ را ﺑﺎ اﺳﺘﻔﺎده از اﺳﻜﺮﻳﭙﺖ ﻣﺨﺮب در اﺧﺘﻴﺎر ﺑﮕﻴﺮد‪ .‬اﺳﻜﺮﻳﭙﺖ ﻣﺨﺮب ﻣﻌﻤﻮﻻً ﺟﺎوا اﺳﻜﺮﻳﭙﺖ اﺳـﺖ؛ اﻣـﺎ ﻫـﺮ زﺑـﺎن‬ ‫اﺳﻜﺮﻳﭙﺖ ﻧﻮﻳﺴﻲ ﻛﻪ ﺑﻪ وﺳﻴﻠﻪ ﻣﺮورﮔﺮ ﻗﺮﺑﺎﻧﻲ ﭘﺸﺘﻴﺒﺎﻧﻲ ﺷﻮد ﻫﺪف ﺑﺎﻟﻘﻮهاي ﺑﺮاي اﻳﻦ ﺣﻤﻠﻪ ﺑﻪ ﺷﻤﺎر ﻣﻲرود‪.‬‬

‫ﻣﺤﻴﻂ ﻫﺎي ﻣﺘﺎﺛﺮ‬ ‫ﺗﻤﺎﻣﻲ ﺳﺎﺧﺘﺎرﻫﺎي ﻧﺮماﻓﺰارﻫﺎي ﺗﺤﺖ وب در ﺑﺮاﺑﺮ ‪ XSS‬آﺳﻴﺐﭘﺬﻳﺮ ﻫﺴﺘﻨﺪ‪.‬‬

‫آﺳﻴﺐ ﭘﺬﻳﺮي‬ ‫ﺳﻪ ﻧﻮع ﺷﻨﺎﺧﺘﻪ ﺷﺪه از ‪ XSS‬وﺟﻮد دارد‪:‬‬ ‫‪) Reflected XSS 9‬ﺑﺎزﺗﺎﺑﻲ(‬ ‫‪) Stored XSS 9‬ذﺧﻴﺮه اي(‬ ‫‪Dom injection 9‬‬ ‫‪ XSS‬ﺑﺎزﺗﺎﺑﻲ)‪ (Reflected‬ﺑﺮاي ‪ Exploit‬آﺳﺎﻧﺘﺮ اﺳﺖ و ﻣﻲﺗﻮاﻧﺪ ﺻﻔﺤﻪاي ﺑﺎﺷـﺪ ﻛـﻪ دادهﻫـﺎي ﻛـﺎرﺑﺮ را در ﻣﺮاﺣـﻞ ﺑﻌـﺪي‬ ‫ﻣﺴﺘﻘﻴﻤﺎ ﺑﻪ ﻣﺮورﮔﺮ او ﺑﺮ ﻣﻲﮔﺮداﻧﺪ‪.‬‬ ‫;]'‪echo $_REQUEST['userinput‬‬ ‫‪ XSS‬ذﺧﻴﺮه اي )‪ (Stored‬دادهﻫﺎي ﻣﺨﺮب را ﮔﺮﻓﺘﻪ و داﺧﻞ ﻓﺎﻳﻠﻲ ذﺧﻴﺮه ﻣﻲﻛﻨﺪ )ﭘﺎﻳﮕﺎه ﻳﺎ ﺳﻴﺴﺘﻢ ﻛﺎرﺑﺮان ﻧﻬﺎﺋﻲ( و در ﻣﺮﺣﻠـﻪ‬ ‫ﺑﻌﺪ دادهﻫﺎ را ﺑﺪون ﻓﻴﻠﺘﺮ و ارزﻳﺎﺑﻲ ﺑﻪ ﻛﺎرﺑﺮ ﻧﻤﺎﻳﺶ ﻣﻲ دﻫﺪ‪ .‬اﻳﻦ ﻋﻤﻞ در ﺳﻴـﺴﺘﻢﻫـﺎﻳﻲ ﻣﺜـﻞ ‪ ،CMS‬ﺑـﻼگﻫـﺎ ﻳـﺎ ﻓﺮﻳـﻮم ﻫـﺎ و‬ ‫ﻣﻜﺎن ﻫﺎﻳﻲ ﻛﻪ ﺑﺴﻴﺎري از ﻛﺎرﺑﺮان وروديﻫﺎي اﻓﺮاد دﻳﮕﺮ را ﺧﻮاﻫﻨﺪ دﻳﺪ‪ ،‬ﺑﺴﻴﺎر ﺧﻄﺮﻧﺎك ﻣﻲﺑﺎﺷﺪ‪.‬‬ ‫در ﺣﻤﻼت ‪ XSS‬ﻣﺒﺘﻨﻲ ﺑﺮ ‪ ،DOM‬ﻛﺪﻫﺎي ﺟﺎوا اﺳﻜﺮﻳﭙﺖ و ﻣﺘﻐﻴﺮﻫﺎ ﺑﻴﺸﺘﺮ از ﻋﻨﺎﺻﺮ ‪ HTML‬دﺳﺘﻜﺎري ﻣﻲﺷﻮﻧﺪ‪.‬‬ ‫ﺣﻤﻠﻪ ‪ XSS‬ﻣﻲﺗﻮاﻧﺪ ﺗﺮﻛﻴﺒﻲ از اﻳﻦ ﺳﻪ ﻧﻮع ﺑﺎﺷﺪ‪ .‬رﻓﺘﺎرﻫﺎي ﭘﻴﺶﺑﻴﻨﻲ ﻧﺸﺪه ﻳﺎ ﻏﻴﺮ اﺳﺘﺎﻧﺪارد ﻣﺮورﮔﺮ ﻣـﻲﺗﻮاﻧـﺪ روشﻫـﺎي دﻗﻴـﻖ‬ ‫ﺣﻤﻠﻪ را ﻣﺸﺨﺺ ﻛﻨﺪ‪ .‬ﻫﻤﭽﻨﻴﻦ ‪ XSS‬از ﻃﺮﻳﻖ اﺟﺰاء ﻣﻮرد اﺳﺘﻔﺎده ﻣﺮورﮔﺮ ﻧﻴﺰ ﻗﺎﺑﻞ اﺟﺮا ﻣﻲﺑﺎﺷﺪ‪ .‬ﺣـﻤﻼت ﺑﺎ اﺳﺘﻔﺎده از ﺟـﺎوا‬

‫‪٩‬‬

‫اﺳﻜﺮﻳﭙﺖ ﻛﻪ زﺑﺎن ﻗﺪرﺗﻤﻨﺪي اﺳﺖ اﻧﺠﺎم ﻣﻲﮔﻴﺮد‪ .‬اﺳﺘﻔﺎده از ﺟﺎوا اﺳﻜﺮﻳﭙﺖ ﺑﻪ ﻣﻬﺎﺟﻤﻴﻦ اﺟﺎزه دﺳﺘﻜﺎري ﺻـﻔﺤﻪ ﻣﻨﺘﻘـﻞ ﺷـﺪه را‬ ‫ﺷﺎﻣﻞ اﺿﺎﻓﻪ ﻛﺮدن ﻋﻨﺎﺻﺮ ﺟﺪﻳﺪ )ﻣﺜﻞ اﺿﺎﻓﻪ ﻛﺮدن ﻣﻜﺎﻧﻲ ﺑﺮاي درﻳﺎﻓﺖ ورودي ‪ login tile‬ﺟﻬﺖ ارﺳﺎل اﻋﺘﺒﺎرﻧﺎﻣﻪﻫـﺎ ﺑـﻪ ﺳـﺎﻳﺖ‬ ‫ﻣﻬﺎﺟﻢ( ﻳﺎ دﺳﺘﻜﺎري درﺧﺖ ‪ DOM‬داﺧﻠﻲ و ﺣﺬف ﻳﺎ ﺗﻐﻴﻴﺮ ﻧﺤﻮه ﻧﻤﺎﻳﺶ ﺻﻔﺤﻪ را ﻣﻲدﻫﺪ‪ .‬ﺟـﺎوا اﺳـﻜﺮﻳﭙﺖ اﺟـﺎزه اﺳـﺘﻔﺎده از‬ ‫‪ XML HTTP Request‬ﻛﻪ ﺗﻮﺳﻂ ﺳﺎﻳﺘﻬﺎي اﺳﺘﻔﺎده ﻛﻨﻨﺪه از ﻓﻨﺎوريﻫﺎي ‪ AJAX‬ﺑﻜﺎر ﮔﺮﻓﺘﻪ ﻣﻲﺷـﻮﻧﺪ را ﺣﺘـﻲ اﮔـﺮ ﺳـﺎﻳﺖ‬ ‫ﻗﺮﺑﺎﻧﻲ از ‪ AJAX‬ﻧﻴﺰ اﺳﺘﻔﺎده ﻧﻜﻨﺪ‪ ،‬ﻣـﻲ دﻫـﺪ‪ .‬ﺑـﺎ اﺳـﺘﻔﺎده از ‪ XML HTTP Request‬ﻣـﻲﺗـﻮان از ﺳﻴﺎﺳـﺖ ﻣﺒـﺪاء ﻳﻜـﺴﺎن‬ ‫)‪ (same source origination policy‬ﻣﺮورﮔﺮ ﮔﺬﺷﺖ‪ .‬ﺑﻪ اﻳﻦ ﻣﻌﻨﻲ ﻛﻪ دادهﻫﺎي ﻗﺮﺑﺎﻧﻲ را ﺑﻪ ﺳﺎﻳﺖﻫﺎي ﻣﻬﺎﺟﻢ ارﺳـﺎل ﻛﺮده‬ ‫و ‪Worm‬ﻫﺎي ﭘﻴﭽﻴﺪه و زاﻣﺒﻲﻫﺎي ﻣﺨﺮﺑﻲ ﻛﻪ ﺗﺎ زﻣـﺎن ﺑﺎز ﺑﻮدن ﻣﺮورﮔﺮ دوام ﺧﻮاﻫﻨﺪ داﺷﺖ‪ ،‬اﻳﺠﺎد ﻛﺮد‪ .‬ﺣﻤﻼت ‪ AJAX‬ﻧﻴﺎزي‬ ‫ﺑﻪ دﻳﺪه ﺷﺪن ﻳﺎ ﺗﻌﺎﻣﻞ ﺑﺎ ﻛﺎرﺑﺮ ﺑﺮاي اﺟﺮاي ﺣﻤﻼت ﺧﻄﺮﻧﺎك ‪ CSRF‬را ﻧﺪارد‪.‬‬

‫ﺑﺮرﺳﻲ اﻣﻨﻴﺖ‬ ‫ﻫﺪف ﺑﺮرﺳﻲ ﺗﻤﺎم ﭘﺎراﻣﺘﺮﻫﺎﻳﻲ اﺳﺖ ﻛﻪ ﻗﺒﻞ از ﺟﺎي ﮔﺬاري در ﺻﻔﺤﺎت ‪ HTML‬ﻣﻌﺘﺒﺮ ﺳﺎزي و ﻳﺎ ‪ encode‬ﻣﻲﺷﻮﻧﺪ‪.‬‬ ‫روشﻫﺎي ﺧﻮدﻛﺎر‪ :‬اﺑﺰارﻫﺎي آزﻣﺎﻳﺶ ﻧﻔﻮذ ﺧﻮدﻛﺎر از ﻃﺮﻳﻖ ﺗﺰرﻳﻖ ﭘﺎراﻣﺘﺮ ﻗـﺎدر ﺑـﻪ ﺗـﺸﺨﻴﺺ ‪ Reflected XSS‬ﻫـﺴﺘﻨﺪ‪ .‬اﻣـﺎ‬ ‫اﻏﻠﺐ اوﻗﺎت ﺑﺮاي ﭘﻴﺪا ﻛﺮدن ‪ XSS‬ﭘﺎﻳﺪار )‪ (Persistent XSS‬ﺑﺎ ﺷﻜﺴﺖ ﻣﻮاﺟﻪ ﻣﻲﺷﻮﻧﺪ‪ ،‬ﺑﻮﻳﮋه اﮔـﺮ ﺧﺮوﺟـﻲ ‪ XSS‬ﺗﺰرﻳـﻖ‬ ‫ﺷﺪه از ﻃﺮﻳﻖ ﺑﺮرﺳﻲﻫﺎي ﻣﺠﺎز ﺷﻤﺎري‪ ،‬ﭘﻴﺸﮕﻴﺮي ﺷﺪه ﺑﺎﺷﺪ‪) .‬ﻣﺜﻼً اﮔﺮ ﻛﺎرﺑﺮي دادهﻫﺎي ﻣﺨﺮﺑﻲ را ﻛﻪ ﻓﻘﻂ ﻣﺪﻳﺮان ﺳﺎﻳﺖ ﺑﺘﻮاﻧﻨـﺪ‬ ‫ﺑﻌﺪاً آن را ﺑﺒﻴﻨﻨﺪ وارد ﻛﻨﺪ(‪ ،‬اﺑﺰارﻫﺎي ﭘﻮﻳﺶ ﺧﻮدﻛﺎر ﻣﻲﺗﻮاﻧﻨﺪ ‪ API‬ﻫﺎي ﺿﻌﻴﻒ ﻳﺎ ﺧﻄﺮﻧﺎك را ﭘﻴﺪا ﻛﻨﻨﺪ اﻣﺎ ﻣﻌﻤـﻮﻻ ﻧﻤـﻲﺗﻮاﻧﻨـﺪ‬ ‫اﻧﺠﺎم ﻋﻤﻞ اﻋﺘﺒﺎرﺳﺎزي ﻳﺎ ﻛﺪ ﮔﺬاري را ﺗﻌﻴﻴﻦ ﻛﻨﻨﺪ‪ ،‬ﻛﻪ اﻳﻦ اﻣﺮ ﻣﻤﻜﻦ اﺳـﺖ ﺑﺎﻋـﺚ اﻳﺠـﺎد ﻣﺜﺒـﺖ ﻧﺎدرﺳـﺖ )‪(False Positive‬‬ ‫ﮔﺮدد‪ .‬ﻫﻴﭻ ﻳﻚ از اﺑﺰارﻫﺎ ﻗﺎدر ﺑﻪ ﭘﻴﺪا ﻛﺮدن ‪ XSS‬ﻫﺎي ﻣﺒﺘﻨﻲ ﺑﺮ ‪ DOM‬ﻧﻴﺴﺘﻨﺪ‪ .‬ﺑﻪ اﻳﻦ ﻣﻌﻨﻲ ﻛﻪ ﻧﺮم اﻓﺰارﻫﺎي ﻛﺎرﺑﺮدي ﻣﺒﺘﻨﻲ ﺑـﺮ‬ ‫‪ AJAX‬ﺣﺘﻲ اﮔﺮ آزﻣﺎﻳﺶ ﺧﻮدﻛﺎر ﻫﻢ روي آنﻫﺎ اﻧﺠﺎم ﮔﺮﻓﺘﻪ ﺑﺎﺷﺪ در ﺧﻄﺮ ﻫﺴﺘﻨﺪ‪.‬‬ ‫روشﻫﺎي دﺳﺘﻲ‪ :‬ﻣﻮﺛﺮﺗﺮﻳﻦ روش ﺑﺮاي ﺑﺮرﺳﻲ اﻣﻨﻴﺖ ﻛﺪﻫﺎ اﺳﺘﻔﺎده از ﻣﻜﺎﻧﻴﺰم ﻣﻌﺘﺒﺮﺳﺎزي و ﻛﺪﮔﺬاري اﺳﺖ‪ .‬اﮔﺮ ﭘﻴﺎده ﺳـﺎزي ﺑـﻪ‬ ‫ﺻﻮرت ﺗﻮزﻳﻊ ﺷﺪه اﻧﺠﺎم ﺷﻮد‪ ،‬اﻋﺘﺒﺎرﺳﺎزي ﺑﻪ ﻃﻮر ﻗﺎﺑﻞ ﻣﻼﺣﻈﻪاي زﻣﺎن ﺑﺮ ﺧﻮاﻫﺪ ﺑﻮد‪ .‬آزﻣﺎﻳﺶ ﺑﺪﻟﻴﻞ وﺳﻴﻊ ﺑﻮدن ﺳـﻄﺢ ﺣﻤﻠـﻪ‬ ‫در اﻛﺜﺮ ﻧﺮماﻓﺰارﻫﺎ ﺑﺴﻴﺎر زﻣﺎن ﺑﺮ اﺳﺖ‪.‬‬

‫‪١٠‬‬

‫‪OWASP Top 10 2007‬‬

‫ﺣﻔﺎﻇﺖ‬ ‫ﺑﻬﺘﺮﻳﻦ راه ﻣﺤﺎﻓﻈﺖ در ﺑﺮاﺑﺮ ‪ XSS‬ﺗﻬﻴﻪ و اﻋﻤـﺎل ﻟﻴـﺴﺘﻲ از ﻛﺎراﻛﺘﺮﻫـﺎي ﻣﺠـﺎز در ورودي و ‪ Encode‬ﻛـﺮدن ﺗﻤـﺎم دادهﻫـﺎي‬ ‫ﺧﺮوﺟﻲ اﺳﺖ‪ .‬ﻟﻴﺴﺖ ورودي ﻫﺎي ﻣﺠﺎز اﺟﺎزه ﺗﺸﺨﻴﺺ ﺣﻤﻼت را ﻣﻲ دﻫﺪ و ‪ Encode‬ﻛﺮدن از اﺟﺮاي ﻣﻮﻓﻖ ﺗﺰرﻳﻖ اﺳﻜﺮﻳﭙﺖ‬ ‫در ﻣﺮورﮔﺮ ﺟﻠﻮﮔﻴﺮي ﻣﻲﻛﻨﺪ‪.‬‬ ‫ﭘﻴﺸﮕﻴﺮي از اﺟﺮاي ‪ XSS‬در ﺗﻤﺎم ﻗﺴﻤﺖﻫﺎي ﻧﺮماﻓﺰار ﺑﻪ ﻣﻌﻤﺎري ﻣﻨﺴﺠﻤﻲ ﻧﻴﺎز دارد‪:‬‬ ‫ƒ‬

‫ﻣﻌﺘﺒﺮﺳﺎزي ورودي‪ :‬اﺳﺘﻔﺎده از ﻣﻜﺎﻧﻴﺰم ﻣﻌﺘﺒﺮﺳﺎزي ﻗﺒﻞ از ﭘﺬﻳﺮش داده ﺑﺮاي ﻧﻤﺎﻳﺶ ﻳﺎ ذﺧﻴﺮه‪ ،‬ﺗﺄﻳﻴﺪ اﻋﺘﺒـﺎر ﺗﻤـﺎﻣﻲ داده‬ ‫ﻫــــﺎي ورودي از ﻟﺤــــﺎظ ﻃــــﻮل‪ ،‬ﻧــــﻮع‪ ،‬ﮔﺮاﻣــــﺮ و ﻛــــﺎرﺑﺮي‪ .‬اﺳــــﺘﻔﺎده از اﺳــــﺘﺮاﺗﮋي ﺗﺎﻳﻴــــﺪ اﻋﺘﺒــــﺎر‬ ‫”‪ “accept known good‬و ﻫﻤﭽﻨﻴﻦ ﻋﺪم ﭘﺬﻳﺮش ورودي ﻧﺎﻣﻌﺘﺒﺮ ﺑﺠـﺎي ﺗـﻼش در ﺟﻬـﺖ ﺳـﺎﻟﻢ ﺳـﺎزي دادهﻫـﺎي‬ ‫ﻣﺨﺮب و ﻓﺮاﻣﻮش ﻧﻜﺮدن اﻳﻦ ﻣﻮﺿﻮع ﻛﻪ ﭘﻴﻐﺎمﻫﺎي ﺧﻄﺎ ﻧﻴﺰ ﻣﻲﺗﻮاﻧﻨﺪ ﺷﺎﻣﻞ دادهﻫﺎي ﻏﻴﺮ ﻣﻌﺘﺒﺮ ﺑﺎﺷﻨﺪ‪.‬‬

‫ƒ‬

‫ﻛﺪﮔﺬاري ﻗﻮي ﺧﺮوﺟﻲﻫﺎ‪ :‬از ﻛﺪﮔﺬاري درﺳﺖ ﺗﻤﺎم دادهﻫﺎي ورودي ﻛـﺎرﺑﺮ ﻗﺒـﻞ از ﺗﻐﻴﻴـﺮ )‪ HTML‬ﻳـﺎ ‪ XML‬ﺑـﺮ‬ ‫ﺣﺴﺐ ﻣﻜﺎﻧﻴﺰم ﺧﺮوﺟﻲ( اﻃﻤﻴﻨﺎن ﺣﺎﺻﻞ ﻛﻨﻴﺪ‪ .‬ﻫﻤﭽﻨﻴﻦ روﺷﻲ را ﺑﺮاي ﻛﺪاﮔﺬاري ﺗﻤﺎم ﻛﺎراﻛﺘﺮﻫﺎ در ﻧﻈـﺮ ﺑﮕﻴﺮﻳـﺪ‪ .‬اﻳـﻦ‬ ‫روش ﻣﻲﺗﻮاﻧﺪ‪ Anti XSS library‬ﻣﺎﻳﻜﺮوﺳﺎﻓﺖ ﻳﺎ ﻛﺘﺎﺑﺨﺎﻧـﻪ آﻣـﺎده اراﺋـﻪ ‪ Anti-XSS‬ﺑـﻪ زﺑـﺎن ‪ PHP‬ﻣﺘﻌﻠـﻖ ﺑـﻪ‬ ‫‪ OWASP‬ﺑﺎﺷﺪ‪ .‬از ﻛﺪﮔﺬاري ﻛﺎراﻛﺘﺮي ﺻﻔﺤﻪﻫﺎي ﺧﺮوﺟﻲ ﺑﺮاي ﻛﺎﻫﺶ اﻓﺸﺎء ﺑﺴﻴﺎري از ﻣﺘﻐﻴﺮﻫﺎ اﺳﺘﻔﺎده ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫ﺗﻌﻴﻴﻦ ﻛﺪﮔﺬاري ﺧﺮوﺟﻲ )ﻣﺎﻧﻨﺪ ‪ ISO 8959-1‬ﻳﺎ ‪ :(UTF-8‬ﺑﻪ ﻣﻬﺎﺟﻤﻴﻦ اﺟﺎزه اﻧﺘﺨﺎب اﻳـﻦ ﮔﻮﻧـﻪ ﻣـﻮارد در ﻣﻘﺎﺑـﻞ‬ ‫ﻛﺎرﺑﺮان را ﻧﺪﻫﻴﺪ‪.‬‬

‫ƒ‬

‫ﺑﺮاي ﻣﻌﺘﺒﺮﺳﺎزي از ﻟﻴﺴﺖ ﺳﻴﺎه اﺳﺘﻔﺎده ﻧﻜﻨﻴﺪ‪ :‬از اﻳﻦ روش ﺑﺮاي ﺗﺸﺨﻴﺺ ‪ XSS‬در وروديﻫﺎ ﻳﺎ ﻛﺪﮔﺬاري ﺧﺮوﺟـﻲ‬ ‫ﻫﺎ اﺳﺘﻔﺎده ﻧﻜﻨﻴﺪ‪ .‬ﺗﻨﻬﺎ ﺟﺴﺘﺠﻮ و ﺟﺎي ﮔﺬاري ﺗﻌﺪاد ﻛﻤﻲ از ﻛﺎراﻛﺘﺮﻫـﺎ ) ">"‪ "<",‬و ﭘﺎراﻣﺘﺮﻫـﺎ ﻳـﺎ ﻋﺒـﺎرات ﻣـﺸﺎﺑﻬﻲ‬ ‫ﻣﺎﻧﻨﺪ"‪ ("script‬ﺿﻌﻴﻒ اﺳﺖ و ﺑﺎ ﻣﻮﻓﻘﻴﺖ ﻣﻮرد ﺣﻤﻠﻪ ﻗﺮار ﻣﻲ ﮔﻴﺮﻧﺪ‪ .‬ﺣﺘﻲ ﻳﻚ ﺗﮓ ﺑﺮرﺳﻲ ﻧـﺸﺪه ">‪ "
‫ƒ‬

‫ﻣﺮاﻗﺒﺖ از ﻣﺘﻌﺎرف ﺳﺎزي ﺧﻄﺎﻫﺎ‪ :‬دادهﻫﺎي ورودي ﺑﺎﻳﺪ ﻗﺒﻞ از ﻣﻌﺘﺒﺮﺳﺎزي‪ ،‬رﻣﺰﮔﺸﺎﻳﻲ و ﻣﺘﻌﺎرف ﺳﺎزي ﺷﻮﻧﺪ‪ .‬از ﻋـﺪم‬ ‫رﻣﺰﮔﺸﺎﻳﻲ ﻣﺠﺪد ورودي ﻫﺎي ﻳﻜﺴﺎن ﺗﻮﺳﻂ ﻧﺮم اﻓﺰار اﻃﻤﻴﻨﺎن ﺣﺎﺻﻞ ﻛﻨﻴﺪ‪ .‬اﻳﻦ ﺧﻄﺎﻫﺎ ﻣـﻲﺗﻮاﻧﻨـﺪ ﺑـﺮاي ﻋﺒـﻮرﻛﺮدن از‬ ‫ﻟﻴﺴﺖ ﺳﻔﻴﺪ ﺑﺎ ﻣﻌﺮﻓﻲ دادهﻫﺎي ورودي ﺑﻌﺪ از ﺑﺮرﺳﻲ آنﻫﺎ‪ ،‬ﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار ﺑﮕﻴﺮﻧﺪ‪.‬‬

‫‪١١‬‬

:‫ﺗﻮﺻﻴﻪﻫﺎي ﺧﺎص زﺑﺎن‬ ‫ در ﺗﮓ‬XML="true" ‫< ﻳﺎ از ﭘﻴﺶﻓﺮض‬been:write …>‫ از ﻣﻜﺎﻧﻴﺰمﻫﺎي ﺧﺮوﺟﻲ ﻣﺎﻧﻨﺪ‬:JAVA

ƒ

(‫< )ﻳﻌﻨﻲ ﺧﺎرج از ﻳﻚ ﻣﻜﺎﻧﻴﺰم ﺧﺮوﺟـﻲ رﻣﺰﮔـﺬاري ﺷـﺪه ﻣﻨﺎﺳـﺐ‬% =... % > ‫ از اﺳﺘﻔﺎده ﻏﻴﺮ ﺗﻮ در ﺗﻮي‬.‫اﺳﺘﻔﺎده ﻛﻨﻴﺪ‬ .‫ﺑﭙﺮﻫﻴﺰﻳﺪ‬ ‫ دادهﻫﺎي درون ﻓﻴﻠـﺪﻫﺎي ﻓـﺮم‬.‫ اﺳﺘﻔﺎده ﻛﻨﻴﺪ‬MSDN ‫ راﻳﮕﺎن ﻣﺎﻳﻜﺮوﺳﺎﻓﺖ در‬Anti-XSS Library 1.5 ‫ از‬:NET

ƒ

‫ ﺑـﻪ ﻃـﻮر ﻣـﺴﺘﻘﻴﻢ و‬Request object: username.text = Request.QueryString ("username"); ‫را از‬ ‫ ﺑﻪ ﻃﻮر اﺗﻮﻣﺎﺗﻴﻚ دادهﻫﺎي ﺧﺮوﺟﻲ را ﻛﺪﮔﺬاري‬.NET ‫ از اﻳﻨﻜﻪ ﻛﻨﺘﺮل ﻫﺎي‬.‫ﺑﺪون اﺳﺘﻔﺎده از اﻳﻦ ﻛﺘﺎﺑﺨﺎﻧﻪ ارﺟﺎع ﻧﺪﻫﻴﺪ‬ .‫ﻣﻲﻛﻨﺪ آﮔﺎه ﺑﺎﺷﻴﺪ‬ Anti-XSS library‫ و ﻳﺎ از‬htmlspecialchars() ‫ ﻳﺎ‬htmlentities() ‫ از ﻋﺒﻮر ﺧﺮوﺟﻲﻫﺎ از داﺧﻞ ﺗﻮاﺑﻊ‬:PHP

ƒ

.‫ ﻛﻪ ﺑﺰودي ﻣﻨﺘﺸﺮ ﺧﻮاﻫﺪ ﺷﺪ اﻃﻤﻴﻨﺎن ﺣﺎﺻﻞ ﻛﻨﻴﺪ‬OWASP ‫ در‬PHP ‫زﺑﺎن‬

‫ﻧﻤﻮﻧﻪ ﻫﺎ‬ ƒ ƒ ƒ

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4206 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-3966 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5204

‫ﻣﺮاﺟﻊ‬ ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ

ƒ

CWE: CWE-79, Cross-Site scripting (XSS) WASC Threat Classification: http://www.webappsec.org/projects/threat/classes/crosssite_scripting.shtml OWASP – Cross site scripting, http://www.owasp.org/index.php/Cross_Site_Scripting OWASP – Testing for XSS, http://www.owasp.org/index.php/Testing_for_Cross_site_scripting OWASP Stinger Project (A Java EE validation filter) – http://www.owasp.org/index.php/Category:OWASP_Stinger_Project OWASP PHP Filter Project - http://www.owasp.org/index.php/OWASP_PHP_Filters OWASP Encoding Project http://www.owasp.org/index.php/Category:OWASP_Encoding_Project RSnake, XSS Cheat Sheet, http://ha.ckers.org/xss.html Klein, A., DOM Based Cross Site Scripting, http://www.webappsec.org/projects/articles/071105.shtml .NET Anti-XSS Library http://www.microsoft.com/downloads/details.aspx?FamilyID=efb9c819-53ff-4f82-bfafe11625130c25&DisplayLang=en

١٢

‫‪OWASP Top 10 2007‬‬

‫‪A2 – INJECTION FLOWS‬‬

‫ﺿﻌﻒ ﻫﺎي ﺗﺰرﻳﻘﻲ‬

‫ﺿﻌﻒﻫﺎي ﺗﺰرﻳﻘﻲ‪ :‬ﺑﻮﻳﮋه ‪ SQL injection‬در ﻧﺮماﻓﺰاﻫﺎي ﺗﺤﺖ وب ﺑﺴﻴﺎر راﻳﺞ اﺳﺖ‪ .‬اﻧﻮاع ﻣﺨﺘﻠﻒ از ﺗﺰرﻳﻖﻫﺎ وﺟﻮد دارﻧـﺪ‪:‬‬ ‫‪، XML ،XSLT ،Xpath ،LDAP ،SQL‬ﻓﺮﻣﺎن ‪ OS injection‬و ﻣﻮارد دﻳﮕﺮ‪.‬‬ ‫ﺗﺰرﻳﻖ‪ ،‬زﻣﺎﻧﻲ ﻛﻪ دادهﻫﺎي ورودي ﻛﺎرﺑﺮ ﺑﻪ ﻋﻨﻮان ﺑﺨﺸﻲ از دﺳﺘﻮر ﻳﺎ ﭘﺮس و ﺟﻮ ﺑﻪ ﻣﻔﺴﺮ ارﺳﺎل ﻣﻲﺷﻮد‪ ،‬اﺗﻔﺎق ﻣﻲاﻓﺘﺪ‪ .‬ﻣﻬﺎﺟﻤﻴﻦ‬ ‫از ﻃﺮﻳﻖ ﺗﻮﻟﻴﺪ دادهﻫﺎي ﺟﻌﻠﻲ ﺑﺮاي اﺟﺮاي ﻏﻴﺮﻋﻤﺪي‪ ،‬ﻣﻔﺴﺮ را ﻓﺮﻳﺐ ﻣﻲدﻫﻨﺪ‪ .‬ﺿﻌﻒﻫـﺎي ﺗﺰرﻳﻘـﻲ ﺑـﻪ ﻣﻬـﺎﺟﻤﻴﻦ اﺟـﺎزه اﻳﺠـﺎد‪،‬‬ ‫ﺧﻮاﻧﺪن‪ ،‬ﺑﺮوزرﺳﺎﻧﻲ ﻳﺎ ﺣﺬف ﻫﺮ داده دﻟﺨﻮاه را در ﻧﺮماﻓﺰار ﻣﻲدﻫﻨﺪ‪ .‬در ﺳﻨﺎرﻳﻮﻳﻲ ﺑﺪﺗﺮ‪ ،‬اﻳﻦ ﺿﻌﻒﻫﺎ ﺑﻪ ﻣﻬﺎﺟﻢ اﺟـﺎزه ﺑـﻪ ﺧﻄـﺮ‬ ‫اﻧﺪاﺧﺘﻦ ﻛﺎﻣﻞ ﻧﺮماﻓﺰار و ﺳﻴﺴﺘﻢﻫﺎي ﺗﺤﺖ ﭘﻮﺷﺶ آن را ﻣﻲدﻫﺪ و ﻧﻴﺰ ﻣﻲﺗﻮاﻧﺪ از ﻣﺤﻴﻂﻫﺎي داراي ﻓﺎﻳﺮوال ﻫﺎي ﺗﻮدرﺗﻮي ﺑـﺴﻴﺎر‬ ‫ﺳﺨﺖ ﻋﺒﻮر ﻛﻨﺪ‪.‬‬

‫ﻣﺤﻴﻂ ﻫﺎي ﻣﺘﺎﺛﺮ‬ ‫ﺗﻤﺎﻣﻲ ﺳﺎﺧﺘﺎرﻫﺎي ﻧﺮماﻓﺰارﻫﺎي ﺗﺤﺖ وب ﻛﻪ از ﻣﻔﺴﺮ اﺳﺘﻔﺎده ﻣﻲﻛﻨﻨﺪ و ﻳﺎ ﻓﺮآﻳﻨـﺪﻫﺎي دﻳﮕـﺮي را ﻓﺮاﺧـﻮاﻧﻲ ﻣـﻲﻛﻨﻨـﺪ در ﺑﺮاﺑـﺮ‬ ‫ﺣﻤﻼت ﺗﺰرﻳﻘﻲ آﺳﻴﺐﭘﺬﻳﺮ ﻫﺴﺘﻨﺪ‪ .‬اﺟﺰاي ﺳﺎﺧﺘﺎرﻫﺎﻳﻲ ﻛﻪ ﻣﻔﺴﺮﻫﺎي ‪ back-end‬را ﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار ﻣﻲدﻫﻨﺪ ﻧﻴـﺰ ﺗﺤـﺖ ﺗـﺄﺛﻴﺮ‬ ‫ﻫﺴﺘﻨﺪ‪.‬‬

‫آﺳﻴﺐ ﭘﺬﻳﺮي‬ ‫اﮔﺮ داده ورودي ﻛﺎرﺑﺮ ﺑﺪون ﻣﻌﺘﺒﺮﺳﺎزي ﻳﺎ ﻛﺪﮔﺬاري ﺑﻪ ﻣﻔﺴﺮ را ه ﻳﺎﺑﺪ‪ ،‬ﻧﺮماﻓﺰار آﺳﻴﺐ ﭘﺬﻳﺮ ﺧﻮاﻫـﺪ ﺑـﻮد‪ .‬ﺑﺮرﺳـﻲ ﻛﻨﻴـﺪ ﻛـﻪ آﻳـﺎ‬ ‫ورودي ﻛﺎرﺑﺮ ﺑﻨﺎﺑﺮ درﺧﻮاﺳﺖﻫﺎي ﭘﻮﻳﺎ ﻋﺮﺿﻪ ﻣﻲﺷﻮد ﻳﺎ ﺧﻴﺮ ﻣﺎﻧﻨﺪ‪:‬‬ ‫‪PHP:‬‬ ‫;"’" ‪$sql = "SELECT * FROM table WHERE id = '" . $_REQUEST['id’] .‬‬ ‫‪Java:‬‬ ‫‪String query = "SELECT user_id FROM user_data WHERE user_name = ' " + req.getParameter‬‬ ‫;" ' "‪("userID") + " ' and user_password = ' " + req.getParameter("pwd") +‬‬

‫ﺑﺮرﺳﻲ اﻣﻨﻴﺖ‬ ‫ﻫﺪف ﺑﺮرﺳﻲ اﻳﻦ ﻣﻄﻠﺐ اﺳﺖ ﻛﻪ دادهﻫﺎي ﻛﺎرﺑﺮ ﻗﺎدر ﺑﻪ ﺗﻐﻴﻴﺮ ﻣﻔﻬﻮم دﺳﺘﻮرات و ﭘﺮس و ﺟﻮﻫﺎي ارﺳﺎل ﺷﺪه ﺑﻪ ﻣﻔﺴﺮ درﺧﻮاﺳﺘﻲ‬ ‫ﻧﺮم اﻓﺰار ﻫﺴﺘﻨﺪ ﻳﺎ ﺧﻴﺮ‪.‬‬

‫‪١٣‬‬

‫روشﻫﺎي ﺧﻮدﻛﺎر‪ :‬اﺑﺰارﻫﺎي ﭘﻮﻳﺸﮕﺮ آﺳﻴﺐ ﭘﺬﻳﺮي ﻓﺮاواﻧﻲ ﺑﺮاي ﭘﻴﺪا ﻛﺮدن ﺿﻌﻒﻫﺎي ﺗﺰرﻳﻘﻲ ﺑﻮﻳﮋه ‪ SQL injection‬وﺟـﻮد‬ ‫دارﻧﺪ‪ .‬اﺑﺰارﻫﺎي ﺗﺤﻠﻴﻞ اﻳﺴﺘﺎﻳﻲ ﻛﻪ اﺳﺘﻔﺎده از ‪ API‬ﻫﺎي ﻣﻔﺴﺮﻫﺎي ﻣﺤﺎﻓﻈﺖ ﻧﺸﺪه را ﺟﺴﺘﺠﻮ ﻣﻲﻛﻨﻨﺪ‪ ،‬ﻣﻔﻴﺪ ﻫﺴﺘﻨﺪ اﻣﺎ ﻧﻤﻲﺗﻮاﻧﻨـﺪ‬ ‫ﺑﺮرﺳﻲ ﻛﻨﻨﺪ ﻛﻪ آﻳﺎ ﻣﻌﺘﺒﺮﺳﺎزي ﻳﺎ ﻛﺪﮔﺬاري ﻣﻨﺎﺳﺒﻲ ﺑﺮاي ﺣﻔﺎﻇﺖ در ﻣﻘﺎﺑﻞ آﺳﻴﺐﭘﺬﻳﺮي در ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﺷﺪه اﺳﺖ ﻳﺎ ﺧﻴـﺮ‪ .‬ﻫﺮﮔـﺎه‬ ‫ﻧﺮم اﻓﺰاري ﺧﺎﻃﺎﻫﺎي ‪ 501‬ﻳﺎ ‪ 500‬داﺧﻠﻲ ﺳﺮوﻳﺲ دﻫﻨﺪه ﻳﺎ ﺧﻄﺎﻫﺎي ﭘﺮ از ﺟﺰﺋﻴﺎت ﭘﺎﻳﮕـﺎه داده را درﻳﺎﻓـﺖ ﻛﻨـﺪ ﺑـﻪ ﻃـﻮر ﻗﺎﺑـﻞ‬ ‫ﺗﻮﺟﻬﻲ ﻣﻲﺗﻮاﻧﺪ اﺑﺰارﻫﺎي ﺧﻮدﻛﺎر را ﻣﺨﺘﻞ ﻛﻨﺪ‪ .‬اﻣﺎ ﻣﻤﻜﻦ اﺳﺖ ﻛﺪﻫﺎ ﻫﻨﻮز در ﺧﻄﺮ ﺑﺎﺷﻨﺪ‪ .‬اﺑﺰارﻫﺎي ﺧﻮدﻛﺎر ﻣﻲﺗﻮاﻧﻨﺪ ﺗﺰرﻳﻖﻫﺎي‬ ‫‪ LDAP‬ﻳﺎ ‪ XML‬ﻳﺎ ‪ Xpath‬را ﺗﺸﺨﻴﺺ دﻫﻨﺪ‪.‬‬ ‫روشﻫﺎي دﺳﺘﻲ‪ :‬ﺑﺮرﺳﻲ ﻛﺪﻫﺎي درﺧﻮاﺳﺖ ﻛﻨﻨﺪه ﻣﻔﺴﺮﻫﺎ روشﻫﺎي ﻣﻮﺛﺮ و ﺻﺤﻴﺤﻲ ﻣﻲﺑﺎﺷﻨﺪ ﻛﻪ ﺑﺎﻳﺪ ﺟﻬـﺖ اﺳـﺘﻔﺎده از ‪API‬‬ ‫ﻫﺎي اﻣﻦ‪ ،‬ﻳﺎ ﻣﻌﺘﺒﺮﺳﺎزي و ﻛﺪﮔﺬاري ﺑﺮرﺳﻲ ﺷﻮد‪ .‬ﺑﺪﻟﻴﻞ وﺳﻴﻊ ﺑﻮدن ﺳﻄﺢ ﺣﻤﻠﻪ اﻛﺜﺮ ﻧﺮماﻓﺰارﻫﺎ‪ ،‬اﻳﻦ روش ﺑﺴﻴﺎر زﻣﺎن ﺑﺮ اﺳﺖ‪.‬‬

‫ﻣﺤﺎﻓﻈﺖ‬ ‫از اﺳﺘﻔﺎده ﻣﻔﺴﺮﻫﺎ ﺗﺎ ﺣﺪ اﻣﻜﺎن ﺟﻠﻮﮔﻴﺮي ﻛﻨﻴﺪ‪ .‬اﮔﺮ ﺑﺎﻳﺪ ﻣﻔﺴﺮي را درﺧﻮاﺳﺖ ﻛﻨﻴﺪ‪ ،‬راه ﺣﻞ ﻛﻠﻴـﺪي ﺑـﺮاي ﺟﻠـﻮﮔﻴﺮي از ﺗﺰرﻳـﻖ‪،‬‬ ‫اﺳﺘﻔﺎده از ‪ API‬ﻫﺎي اﻣﻦ ﻣﺎﻧﻨﺪ ﭘﺮس و ﺟﻮﻫﺎي ﺗﺸﺨﻴﺺ دﻫﻨﺪه ﻧﻮع ﭘﺎراﻣﺘﺮ )‪(strongly typed parameterized queries‬‬ ‫و ﻛﺘﺎﺑﺨﺎﻧﻪﻫﺎي ﻣﺒﺪل اﺷﻴﺎء )‪ object relational mapping (ORM‬ﻣﻲﺑﺎﺷﺪ‪ .‬اﻳﻦ واﺳﻂ ﻫﺎ ﺗﻤـﺎم ﻣﺮاﺣـﻞ ﻻزم ﺑـﺮاي ‪Data‬‬ ‫‪ scaping‬را ﺑﻪ ﻃﻮر ﺧﻮدﻛﺎر اﻧﺠﺎم ﻣﻴﺪﻫﻨﺪ‪ .‬اﮔﺮﭼﻪ اﻳﻦ واﺳﻂﻫﺎ ﻣﺸﻜﻞ را ﺣﻞ ﻣﻲﻛﻨﻨﺪ‪ ،‬اﻣـﺎ ﻣﻌﺘﺒﺮﺳـﺎزي داده ﻫـﺎي ورودي ﺑـﺮاي‬ ‫ﺗﺸﺨﻴﺺ ﺣﻤﻼت ﺗﻮﺻﻴﻪ ﻣﻲﺷﻮد‪ .‬ﺑﻜﺎرﮔﻴﺮي ﻣﻔﺴﺮﻫﺎ ﺧﻄﺮﻧﺎك اﺳﺖ‪ ،‬ﺑﻨﺎﺑﺮاﻳﻦ اﻳﻦ ارزش را دارد ﻛﻪ ﻣﺮاﻗﺒﺖ ﻫـﺎي ﺑﻴـﺸﺘﺮي ﻣﺎﻧﻨـﺪ‬ ‫ﻣﻮارد ذﻳﻞ را در ﻧﻈﺮ ﺑﮕﻴﺮﻳﺪ‪:‬‬ ‫ƒ‬

‫ﻣﻌﺘﺒﺮﺳﺎزي ورودي‪ :‬از ﻣﻜﺎﻧﻴﺰم ﻣﻌﺘﺒﺮﺳﺎزي ورودي اﺳﺘﺎﻧﺪاردي ﻗﺒﻞ از ﭘﺬﻳﺮﻓﺘﻦ داده ﺑﺮاي ﻧﻤﺎﻳﺶ ﻳﺎ ذﺧﻴﺮه ﺳﺎزي ﺟﻬﺖ ﺗﺎﻳﻴﺪ‬

‫اﻋﺘﺒﺎر ﺗﻤﺎم دادهﻫﺎي ورودي از ﻧﻈﺮ ﻃﻮل‪ ،‬ﻧﻮع‪ ،‬ﮔﺮاﻣﺮ و ﻛﺎرﺑﺮي اﺳﺘﻔﺎده ﻛﻨﻴﺪ‪ .‬از اﺳﺘﺮاﺗﮋي ﻣﻌﺘﺒﺮﺳﺎزي"‪"accept known good‬‬ ‫اﺳﺘﻔﺎده ﻛﻨﻴﺪ‪ .‬ﺑﺠﺎي ﺗﻼش ﺑﺮاي ﺳﺎﻟﻢ ﺳﺎزي دادهﻫﺎي ﻗﺎﺑﻞ ﺗﺨﺮﻳﺐ‪ ،‬از ﭘﺬﻳﺮش داده ﻫﺎي ورودي ﻧﺎﻣﻌﺘﺒﺮ ﺟﻠﻮﮔﻴﺮي ﻛﻨﻴﺪ‪ .‬ﻓﺮاﻣﻮش‬ ‫ﻧﻜﻨﻴﺪ ﻛﻪ ﭘﻴﻐﺎمﻫﺎي ﺧﻄﺎ ﻧﻴﺰ ﻣﻲﺗﻮاﻧﻨﺪ ﺷﺎﻣﻞ دادهﻫﺎي ﻧﺎﻣﻌﺘﺒﺮ ﺑﺎﺷﻨﺪ‪.‬‬ ‫ƒ‬

‫از ‪ API‬ﻫﺎي ﭘﺮس و ﺟﻮي ﺗﺸﺨﻴﺺ دﻫﻨﺪه ﻧﻮع ﭘﺎراﻣﺘﺮ )‪ (Strongly typed parameterized query‬ﺣﺘﻲ در زﻣﺎن‬

‫ﻓﺮاﺧﻮاﻧﻲ ﺗﻮاﺑﻊ ذﺧﻴﺮه ﺷﺪه )‪ (Stored procedure‬ﻧﻴﺰ اﺳﺘﻔﺎده ﻛﻨﻴﺪ‪.‬‬ ‫ƒ‬

‫از ﺣﺪاﻗﻞ اﻣﺘﻴﺎز دﺳﺘﺮﺳﻲ )‪ (permission‬را در زﻣﺎن اﺗﺼﺎل ﺑﻪ ﭘﺎﻳﮕﺎه داده ﻳﺎ ﺳﺎﻳﺮ ﺳﻴﺴﺘﻢﻫﺎي ‪ back end‬اﺳﺘﻔﺎده ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫از اراﺋﻪ ﭘﻴﺎمﻫﺎي ﺧﻄﺎي ﭘﺮ از ﺟﺰﺋﻴﺎت ﻛﻪ ﺑﺮاي ﻣﻬﺎﺟﻢ ﻣﻔﻴﺪ ﻫﺴﺘﻨﺪ ﺑﭙﺮﻫﻴﺰﻳﺪ‪.‬‬ ‫‪١٤‬‬

‫‪OWASP Top 10 2007‬‬

‫ƒ‬

‫از ﺗﻮاﺑﻊ ذﺧﻴﺮه ﺷﺪه )‪ (Stored procedure‬ﻛﻪ ﻣﻌﻤﻮﻻ در ﺑﺮاﺑﺮ ﺗﺰرﻳﻖ ‪ SQL‬اﻳﻤﻦ ﻫﺴﺘﻨﺪ اﺳﺘﻔﺎده ﻛﻨﻴﺪ‪ .‬اﻟﺒﺘﻪ ﻣﺮاﻗﺐ ﺑﺎﺷﻴﺪ‬

‫ﭼﺮا ﻛﻪ اﻳﻦ ﺗﻮاﺑﻊ ﻣﻲﺗﻮاﻧﻨﺪ ﻗﺎﺑﻞ ﺗﺰرﻳﻖ ﺑﺎﺷﻨﺪ‪) .‬ﻣﺎﻧﻨﺪ اﺳﺘﻔﺎده از آرﮔﻮﻣﺎﻧﻬﺎي اﻟﺤﺎﻗﻲ ) (‪ exec‬داﺧﻞ ﺗﻮاﺑﻊ ذﺧﻴﺮه ﺷﺪه(‬ ‫ƒ‬

‫از واﺳﻂﻫﺎي ﭘﺮس و ﺟﻮي ﭘﻮﻳﺎ)‪ (Dynamic‬ﻣﺎﻧﻨﺪ ) (‪ mysql-query‬ﻳﺎ ﻣﺸﺎﺑﻪ آن اﺳﺘﻔﺎده ﻧﻜﻨﻴﺪ‪.‬‬

‫ƒ‬

‫از ﺗﻮاﺑﻊ ‪ escaping‬ﺳﺎده ﻣﺎﻧﻨﺪ ) (‪ addslashes‬ﻳﺎ ﺗﻮاﺑﻊ ﺟﺎﻳﮕﺬاري ﻛﺎراﻛﺘﺮ ﻣﺎﻧﻨﺪ ‪ str-replace‬اﺳﺘﻔﺎده ﻧﻜﻨﻴﺪ‪ .‬اﻳﻦ ﺗﻮاﺑﻊ‬

‫ﺿﻌﻴﻒ ﻫﺴﺘﻨﺪ و ﺑﺎ ﻣﻮﻓﻘﻴﺖ از ﻃﺮف ﻣﻬﺎﺟﻤﻴﻦ ﺑﻜﺎرﮔﺮﻓﺘﻪ )‪ (exploit‬ﻣﻲﺷﻮﻧﺪ‪ .‬ﺑﺮاي زﺑﺎن ‪ PHP‬اﮔﺮ از ‪ mysql‬اﺳﺘﻔﺎده ﻣﻲﻛﻨﻴﺪ‬ ‫از ﺗﻮاﺑﻊ ) ( ‪ mysql – real – escape – string‬ﻳﺎ ﺗﺮﺟﻴﺤﺎً از ‪ PDO‬ﻛﻪ ﻧﻴﺎزي ﺑﻪ ﺟﺎﻳﮕﺰﻳﻨﻲ ﻧﺪارد اﺳﺘﻔﺎده ﻛﻨﻴﺪ‪.‬‬ ‫ƒ‬

‫در ﻫﻨﮕﺎم اﺳﺘﻔﺎده از ﻣﻜﺎﻧﻴﺰم ﻫﺎي ﺟﺎﻳﮕﺰﻳﻨﻲ ﺳﺎده ﺗﻮﺟﻪ داﺷﺘﻪ ﺑﺎﺷﻴﺪ ﻛﻪ ﺗﻮاﺑﻊ ﺟﺎﻳﮕﺰﻳﻨﻲ ﺳﺎده ﻧﻤﻲﺗﻮاﻧﻨﺪ ﻛﺎراﻛﺘﺮﻫﺎي‬

‫ﺧﻄﺮﻧﺎك را در ﻧﺎم ﺟﺪاول را ﺟﺎﻳﮕﺰﻳﻦ ﻛﻨﻨﺪ‪ .‬ﻧﺎم ﺟﺪاول ﺑﺎﻳﺪ ﻣﻄﺎﺑﻖ ﺑﺎ ﻗﻮاﻋﺪ ‪ SQL‬ﺑﺎﺷﺪ و ﺑﺪﻳﻦ ﺟﻬﺖ ﺑﺮاي دادهﻫﺎي ورودي‬ ‫ﻛﺎرﺑﺮ ﭼﻨﺪان ﻣﻨﺎﺳﺐ ﻧﻴﺴﺘﻨﺪ‪.‬‬ ‫ƒ‬

‫ﻣﺮاﻗﺐ ﺧﻄﺎﻫﺎي ﻣﺘﻌﺎرف ﺳﺎزي ﺑﺎﺷﻴﺪ‪ .‬دادهﻫﺎي ورودي ﺑﺎﻳﺪ ﻗﺒﻞ از اﻋﺘﺒﺎرﺳﻨﺠﻲ ﺷﻮﻧﺪدر داﺧﻞ ﻧﺮم اﻓﺰار‪ ،‬ﻛﺪﮔﺸﺎﻳﻲ و‬

‫ﻣﺘﻌﺎرف ﺳﺎزي ﺷﻮﻧﺪ‪ .‬ﻣﻄﻤﺌﻦ ﺑﺎﺷﻴﺪ ﻛﻪ ﻧﺮم اﻓﺰار ﻳﻚ ﻣﻘﺪار ورودي را دوﺑﺎر ‪ decode‬ﻧﻜﻨﺪ‪ .‬ﭼﻨﻴﻦ ﺧﻄﺎﻫﺎﻳﻲ ﻣﻲﺗﻮاﻧﺪ ﺑﺮاي‬ ‫ﮔﺬﺷﺘﻦ از ‪ whitelist‬ﻛﺎراﻛﺘﺮﻫﺎي ﻣﺠﺎز ﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار ﺑﮕﻴﺮد‪.‬‬

‫ﺗﻮﺻﻴﻪﻫﺎي ﺧﺎص زﺑﺎن‪:‬‬ ‫ƒ‬

‫‪ - Java EE‬از دﺳﺘﻮراتِ ‪ Strongly typed PreparedStatement‬ﻳﺎ ‪ ORM‬ﻫﺎﻳﻲ ﻣﺎﻧﻨﺪ ‪ Hibernate‬ﻳﺎ ‪Spring‬‬

‫اﺳﺘﻔﺎده ﻛﻨﻴﺪ‪.‬‬ ‫ƒ‬

‫‪ – .NET‬از ﭘﺮس و ﺟﻮﻫﺎي ﺗﺸﺨﻴﺺ دﻫﻨﺪه ﻧﻮع ﭘﺎراﻣﺘﺮﻫﺎ )‪ (strongly typed parameterized queries‬ﻣﺎﻧﻨﺪ‬

‫‪ SqlCommand‬ﺑﺎ ‪ SqlParameter‬ﻳﺎ ﻳﻚ ‪ ORM‬ﺷﺒﻴﻪ ‪ Hibernate‬اﺳﺘﻔﺎده ﻛﻨﻴﺪ‪.‬‬ ‫ƒ‬

‫‪ - PHP‬از ‪ PDO‬ﻫﻤﺮاه ﺑﺎ ﭘﺮس و ﺟﻮﻫﺎي ﺗﺸﺨﻴﺺ دﻫﻨﺪه )‪ (strongly typed parameterized query‬ﻣﺎﻧﻨﺪ‬

‫) (‪ bindParam‬اﺳﺘﻔﺎده ﻛﻨﻴﺪ‪.‬‬

‫ﻧﻤﻮﻧﻪ ﻫﺎ‬ ‫‪http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5121‬‬ ‫‪http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4953‬‬ ‫‪http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4592‬‬

‫‪١٥‬‬

‫ƒ‬ ‫ƒ‬ ‫ƒ‬

‫ﻣﺮاﺟﻊ‬ ƒ ƒ

ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ

CWE: CWE-89 (SQL Injection), CWE-77 (Command Injection), CWE-90 (LDAP Injection), CWE-91 (XML Injection), CWE-93 (CRLF Injection), others. WASC Threat Classification: http://www.webappsec.org/projects/threat/classes/ldap_injection.shtml http://www.webappsec.org/projects/threat/classes/sql_injection.shtml http://www.webappsec.org/projects/threat/classes/os_commanding.shtml OWASP, http://www.owasp.org/index.php/SQL_Injection OWASP Guide, http://www.owasp.org/index.php/Guide_to_SQL_Injection OWASP Code Review Guide, http://www.owasp.org/index.php/Reviewing_Code_for_SQL_Injection OWASP Testing Guide, http://www.owasp.org/index.php/Testing_for_SQL_Injection SQL Injection, http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf Advanced SQL Injection, http://www.ngssoftware.com/papers/advanced_sql_injection.pdf More Advanced SQL Injection, http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf Hibernate, an advanced object relational manager (ORM) for J2EE and .NET, http://www.hibernate.org/ J2EE Prepared Statements, http://java.sun.com/docs/books/tutorial/jdbc/basics/prepared.html How to: Protect from SQL injection in ASP.Net, http://msdn2.microsoft.com/enus/library/ms998271.aspx PHP PDO functions, http://php.net/pdo

١٦

‫‪OWASP Top 10 2007‬‬

‫اﺟﺮاي ﻓﺎﻳﻞ ﻣﺨﺮب‬

‫‪A3 – MALICIOUS FILE EXECUTION‬‬

‫آﺳﻴﺐﭘﺬﻳﺮيﻫﺎي ﺣﺎﺻﻞ از اﺟﺮاي ﻓﺎﻳﻞ ﻣﺨﺮب در ﺑﺴﻴﺎري از ﻧﺮم اﻓﺰارﻫﺎ ﻳﺎﻓﺖ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺑﺮﻧﺎﻣﻪ ﻧﻮﻳﺴﺎن اﻏﻠﺐ ﺑﻪ ﻃﻮر ﻣﺴﺘﻘﻴﻢ و‬ ‫ﻳﺎ ﺑﻮﺳﻴﻠﻪ اﻟﺤﺎق داده ورودي ﻣﺨﺮب از ﻃﺮﻳﻖ ﻓﺎﻳﻞ ﻳﺎ ﺗﻮاﺑﻊ رﺷﺘﻪاي و ﻳﺎ ﺑﻪ ﺷﻜﻞ ﻧﺎﻣﻨﺎﺳﺐ از ﻓﺎﻳﻞ ﻫﺎي ورودي ﻗﺎﺑﻞ اﻋﺘﻤﺎد‬ ‫اﺳﺘﻔﺎده ﻣﻲﻛﻨﻨﺪ‪ .‬در ﺑﺴﻴﺎري از ‪ Platform‬ﻫﺎ‪ ،‬ﺳﺎﺧﺘﺎرﻫﺎ اﺟﺎزه اﺳﺘﻔﺎده از ارﺟﺎع ﺑﻪ ﺷﻲ ﺧﺎرﺟﻲ )‪ (Object Reference‬ﻣﺎﻧﻨﺪ‬ ‫ارﺟﺎع ﺑﻪ ‪ URL‬ﻫﺎ ﻳﺎ ﺳﻴﺴﺘﻢ ﻓﺎﻳﻞ را ﻣﻲدﻫﻨﺪ‪.‬‬ ‫ﺑﺮرﺳﻲ ﻧﺎﻣﻨﺎﺳﺐ داده ﻣﻲﺗﻮاﻧﺪ ﻣﻨﺠﺮ ﺑﻪ ﻛﻨﺘﺮل از راه دور ﻛﺪﻫﺎي ﻣﺨﺮب ﺷﻮد ﻛﻪ ﺗﻮﺳﻂ ﺳﺮور وب در ﺣﺎل ﭘﺮدازش ﻳﺎ درﺧﻮاﺳﺖ‬ ‫اﺳﺖ‪.‬‬ ‫اﻳﻦ اﻣﺮﺑﻪ ﻣﻬﺎﺟﻤﻴﻦ اﺟﺎزه اﻧﺠﺎم اﻗﺪاﻣﺎت زﻳﺮ را ﻣﻲدﻫﺪ‪:‬‬ ‫ƒ‬

‫اﺟﺮاي ﻛﺪﻫﺎ از راه دور‬

‫ƒ‬

‫ﻧﺼﺐ ‪ root kit‬از راه دور و ﻧﻔﻮذ ﻛﺎﻣﻞ ﺑﻪ ﺳﻴﺴﺘﻢ‬

‫ƒ‬

‫در وﻳﻨﺪوز‪ ،‬ﻧﻔﻮذ ﺑﻪ ﺳﻴﺴﺘﻢ داﺧﻠﻲ ﻣﻲﺗﻮاﻧﺪ ﺑﺎ اﺳﺘﻔﺎده از ﭘﻮﺷﻪ ﻫﺎي )‪ (wrappers‬ﻓﺎﻳﻞ ‪ SMB‬در زﺑﺎن ‪ PHP‬ﺻﻮرت‬

‫ﭘﺬﻳﺮد‪.‬‬ ‫ƒ‬

‫اﻳﻦ ﺣﻤﻠﻪ در زﺑﺎن ‪ PHP‬ﺑﺴﻴﺎر راﻳﺞ اﺳﺖ و ﻫﺮ رﺷﺘﻪ ﻳﺎ ﻋﻤﻠﻜﺮد ﻓﺎﻳﻞ ﻣﻲ ﺑﺎﻳﺴﺖ ﺑﺮاي اﻃﻤﻴﻨﺎن از ﻋﺪم ﺗﺎﺛﻴﺮﭘﺬﻳﺮي ﻧﺎم‬

‫ﻓﺎﻳﻞ ﻫﺎ از ﻃﺮﻳﻖ دادهﻫﺎي ورودي ﻛﺎرﺑﺮ‪ ،‬ﻣﺤﺎﻓﻈﺖ ﺷﻮد‪.‬‬

‫ﻣﺤﻴﻂ ﻫﺎي ﻣﺘﺎﺛﺮ‬ ‫اﻧﻮاع ﺳﺎﺧﺘﺎرﻫﺎي ﻧﺮم اﻓﺰارﻫﺎي ﺗﺤﺖ وب ﻫﻨﮕﺎم درﻳﺎﻓﺖ ﻓﺎﻳﻞ ﻳﺎ ﻧﺎم ﻓﺎﻳﻞ ﻫﺎ از ﻛﺎرﺑﺮ در ﺑﺮاﺑﺮ اﺟﺮاي ﻓﺎﻳـﻞ ﻣﺨـﺮب آﺳـﻴﺐ ﭘـﺬﻳﺮ‬ ‫ﻫﺴﺘﻨﺪ‪ .‬ﺑﻪ ﻃﻮر ﻣﺜﺎل زﺑﺎن ﺑﺮﻧﺎﻣﻪ ﻧﻮﻳﺴﻲ ‪ .NET‬ﺑﻪ ﻛﺎرﺑﺮ اﺟﺎزه اﻧﺘﺨﺎب آرﮔﻮﻣﺎنﻫﺎي ﻧﺎم ﻓﺎﻳﻞ در ‪ URL‬و ﻧﻴﺰ ﻛﺪﻫﺎي ﭘﺬﻳﺮش ﻧﺎم‬ ‫ﻓﺎﻳﻞ را ﺑﺮاي ﻓﺎﻳﻞ ﻫﺎي ﻣﺤﻠﻲ را ﻣﻲ دﻫﺪ‪.‬‬ ‫زﺑﺎن ‪ PHP‬از ﻃﺮﻳﻖ ﻓﺎﻳﻞ ﻳﺎ رﺷﺘﻪﻫﺎي ﻣﺒﺘﻨﻲ ﺑﺮ ‪ API‬در ﺑﺮاﺑﺮ ﺣﻤﻠﻪ اﻟﺤﺎق ﻓﺎﻳﻞ از راه دور‪ ،‬آﺳﻴﺐﭘﺬﻳﺮ اﺳﺖ‪.‬‬

‫آﺳﻴﺐ ﭘﺬﻳﺮي‬ ‫ﺳﺎﺧﺘﺎر آﺳﻴﺐﭘﺬﻳﺮ ﺑﻪ ﺷﺮح ذﻳﻞ ﻣﻲﺑﺎﺷﺪ‪:‬‬ ‫;]'‪include $_REQUEST['filename‬‬

‫‪١٧‬‬

‫اﻳﻦ ﻣﻮرد ﻧﻪ ﻓﻘﻂ ﺑﺮرﺳﻲ اﺳﻜﺮﻳﭙﺖﻫﺎي ﻣﺨﺮب از راه دور را اﻣﻜﺎنﭘﺬﻳﺮ ﻣﻲ ﺳﺎزد‪ ،‬ﺑﻠﻜﻪ ﻣـﻲﺗﻮاﻧـﺪ ﺑـﺮاي دﺳﺘﺮﺳـﻲ ﺑـﻪ ﺳـﺮورﻫﺎي‬ ‫ﻣﺤﻠﻲ )اﮔﺮ از زﺑﺎن ‪ PHP‬ﭘﺸﺘﻴﺒﺎﻧﻲ ﮔﺮدد( ﺑﺪﻟﻴﻞ ﭘﺸﺘﻴﺒﺎﻧﻲ ‪ SMB‬در ﭘﻮﺷﻪﻫﺎي ﺳﻴﺴﺘﻢ ﻓﺎﻳﻞ ‪ PHP‬اﺳﺘﻔﺎده ﺷﻮد‪.‬‬ ‫ﺳﺎﻳﺮ روﺷﻬﺎي ﺣﻤﻠﻪ ﺷﺎﻣﻞ ﻣﻮارد ذﻳﻞ ﻣﻲﮔﺮدد‪:‬‬ ‫ƒ‬

‫دادهﻫﺎي ﻣﺨﺮب ﺑﺮروي ﻓﺎﻳﻞ ﻫﺎي ﻧﺸﺴﺖ ‪ ،Session Files‬دادهﻫـﺎي ﻧﺸـﺴﺖ ﻫﻤـﺮاه ﺑـﺎ ﺑﺎرﮔـﺬاري ﺗـﺼﻮﻳﺮ‪ ،‬ﺑﺎرﮔـﺬاري‬ ‫ﻣﻲ ﺷﻮﻧﺪ‪.‬‬

‫ƒ‬

‫اﺳﺘﻔﺎده از ﻓﺸﺮده ﺳﺎزي ﻳﺎ ﺟﺮﻳﺎنﻫﺎي ﺻـﻮﺗﻲ ﻣﺎﻧﻨـﺪ ‪ Zlib://‬ﻳـﺎ ‪ Dgg://‬ﻛـﻪ ﻧـﺸﺎﻧﻪ )‪ (flag‬داﺧﻠـﻲ ‪ URL‬در ‪ PHP‬را‬ ‫ﺑﺎزرﺳﻲ ﻧﻤﻲ ﻛﻨﻨﺪ و ﺑﻨﺎﺑﺮاﻳﻦ اﺟﺎزه دﺳﺘﺮﺳﻲ ﺑﻪ ﻣﻨﺎﺑﻊ از راه دور ﺣﺘﻲ اﮔـﺮ ‪ allow-url-fopen‬ﻳـﺎ ‪allow-url-include‬‬ ‫ﻏﻴﺮﻓﻌﺎل ﺑﺎﺷﻨﺪ‪ ،‬را ﻣﻲدﻫﻨﺪ‪.‬‬

‫ƒ‬ ‫ƒ‬

‫اﺳﺘﻔﺎده از ﭘﻮﺷﻪﻫﺎي ‪ PHP‬ﻣﺎﻧﻨﺪ ورودي ‪ php://‬و ﻏﻴﺮه ﺑﺮاي ﭘﺬﻳﺮﻓﺘﻦ ورودي از درﺧﻮاﺳﺖ داده ‪ POST‬ﺑﻪ ﺟﺎي ﻳﻚ ﻓﺎﻳﻞ‬ ‫اﺳﺘﻔﺎده از دادهﻫﺎي ‪ :PHP‬ﭘﻮﺷﺎﻧﻨﺪه ﻣﺎﻧﻨﺪ‬ ‫‪Data : ; base64 , PD9waHAgcGhwaW5mbygpOz8+‬‬

‫از آﻧﺠﺎﻳﻲ ﻛﻪ اﻳﻦ ﻓﻬﺮﺳﺖ وﺳﻴﻊ اﺳﺖ )و ﺑﻪ ﺻﻮرت دورهاي ﺗﻐﻴﻴﺮ ﭘﻴﺪا ﻣﻲﻛﻨﺪ(‪ ،‬اﺳﺘﻔﺎده از ﻣﻌﻤﺎري اﻣﻨﻴﺘﻲ ﻣﻨﺎﺳﺐ و ﻃﺮاﺣﻲ ﻗـﻮي‬ ‫در ﻫﻨﮕﺎم ارﺗﺒﺎط ﺑﺎ دادهﻫﺎي ورودي ﻛﺎرﺑﺮ ـ ﻛﻪ اﻧﺘﺨﺎب ﻧﺎم ﻓﺎﻳﻠﻬﺎي ﺳﻤﺖ ﺳﺮور و دﺳﺘﺮﺳﻲ آن را ﻣﺘﺎﺛﺮ ﻣﻲ ﺳﺎزد ـ ﺣﻴﺎﺗﻲ اﺳﺖ‪.‬‬ ‫ﻫﺮﭼﻨﺪ ﻣﺜﺎﻟﻬﺎﻳﻲ از زﺑﺎن ‪ PHP‬اراﻳﻪ ﺷﺪ‪ ،‬اﻣﺎ اﻳﻦ ﺣﻤﻠﻪ ﻣﻲﺗﻮاﻧﺪ ﺑﻪ روﺷﻬﺎي ﻣﺨﺘﻠـﻒ در ‪ ، .NET‬و ﻧﻴـﺰ ‪ J2EE‬ﻧﻴـﺰ اﺟـﺮا ﮔـﺮدد‪.‬‬ ‫ﻧﺮم اﻓﺰارﻫﺎي ﻧﻮﺷﺘﻪ ﺷﺪه در ﺳﺎﺧﺘﺎرﻫﺎي ‪ .NET‬و ‪ J2EE‬ﻧﻴﺎز ﺑﻪ ﺗﻮﺟﻬﻲ وﻳﮋه ﺑﻪ ﻣﻜﺎﻧﻴﺰم ﻫﺎي اﻣﻨﻴﺘﻲ ﺟﻬﺖ دﺳﺘﺮﺳـﻲ ﺑـﻪ ﻛـﺪﻫﺎ‪،‬‬ ‫ﺑﺮاي اﻃﻤﻴﻨﺎن از ﻋﺪم دﻓﻊ ﻛﻨﺘﺮلﻫﺎي اﻣﻨﻴﺘﻲ از ﻃﺮﻳﻖ ﻧﺎم ﻓﺎﻳﻞﻫﺎي ﺗﻮﻟﻴﺪي ﻳﺎ ﺗﺤﺖ ﻧﻔﻮذ ﻛﺎرﺑﺮ دارﻧﺪ‪ .‬ﺑﻪ ﻃﻮر ﻣﺜﺎل ﻣﻤﻜﻦ اﺳﺖ اﺳﻨﺎد‬ ‫‪ XML‬اراﺋﻪ ﺷﺪه ﺗﻮﺳﻂ ﻣﻬﺎﺟﻢ ﺷﺎﻣﻞ ﻳﻚ ‪ DTD‬ﻣﺨﺮب ﺑﺎﺷﺪ ﻛﻪ ﺗﺠﺰﻳﻪ ﻛﻨﻨﺪه ‪ XML‬را ﻣﺠﺒﻮر ﺑﻪ ﺑﺎرﮔﺬاري ‪ DTD‬از راه دور‬ ‫و ﺗﺠﺰﻳﻪ و ﭘﺮدازش ﻧﺘﺎﻳﺞ ﻛﻨﺪ‪ .‬ﻳﻚ ﺷﺮﻛﺖ اﻣﻨﻴﺘﻲ اﺳﺘﺮاﻟﻴﺎﻳﻲ اﻳﻦ روش را ﺑﺮاي ﭘﻮﻳﺶ ﭘﻮرت در ﭘﺸﺖ دﻳﻮارهﻫﺎي آﺗﺶ اراﺋﻪ ﻛـﺮده‬ ‫اﺳﺖ‪ .‬ﺑﺮاي اﻃﻼﻋﺎت ﺑﻴﺸﺘﺮ ‪ SIF01‬را در ﻣﻨﺎﺑﻊ اﻳﻦ ﺑﺨﺶ ﺑﺒﻴﻨﻴﺪ‪.‬‬ ‫ﺧﻄﺮات ﻋﻠﻞ اﻳﻦ آﺳﻴﺐﭘﺬﻳﺮي وﻳﮋه ﻣﺴﻘﻴﻤﺎً ﺑﻪ ﻗﺪرت ﻛﻨﺘﺮلﻫﺎي ﺟﺪاﺳﺎزي ‪ platform‬ﻳﺎ ‪ sandbox‬ﻣﻮﺟﻮد در ﺳـﺎﺧﺘﺎر ﻣـﺮﺗﺒﻂ‬ ‫اﺳﺖ‪ .‬از آﻧﺠﺎﺋﻴﻜﻪ ‪ PHP‬ﺑﻪ ﻧﺪرت ﺗﺠﺰﻳﻪ ﻣﻲﺷﻮد و ﻫﻴﭽﮕﻮﻧﻪ ﻣﻔﻬﻮم ‪ sandbox‬ﻳﺎ ﻣﻌﻤﺎري اﻣﻨﻴﺘﻲ ﻧﺪارد‪ ،‬ﺧﻄﺮ ﺣﻤﻠﻪ در آن زﺑـﺎن‬ ‫از ﺳﺎﻳﺮ ﺳﺎﺧﺘﺎرﻫﺎ ﺑﺎ اﻃﻤﻴﻨﺎن ﻛﻤﺘﺮ‪ ،‬ﻳﺎ ﺳﺎﺧﺘﺎرﻫﺎﻳﻲ ﻛﻪ داﺧﻞ ﻳﻚ ‪ sandbox‬ﻣﻨﺎﺳﺐ ﻗﺮار ﻣﻲﮔﻴﺮﻧﺪ )ﺑﻪ ﻃﻮر ﻣﺜـﺎل زﻣـﺎﻧﻲ ﻛـﻪ ﻳـﻚ‬ ‫ﻧﺮم اﻓﺰار وب ﺗﺤﺖ ‪ JVM‬ﻛﻪ ﺑﺪرﺳﺘﻲ ﺗﻮﺳﻂ ﻣﺪﻳﺮ اﻣﻨﻴﺘﻲ ﻓﻌﺎل و ﭘﻴﻜﺮﺑﻨﺪي ﺷﺪه اﺟﺮا ﮔﺮدد(‪ ،‬ﺑﺴﻴﺎر ﺑﻴﺸﺘﺮ اﺳﺖ‪.‬‬

‫‪١٨‬‬

‫‪OWASP Top 10 2007‬‬

‫ﺑﺮرﺳﻲ اﻣﻨﻴﺖ‬ ‫روش ﻫﺎي ﺧﻮدﻛﺎر‪ :‬اﺑﺰارﻫﺎي ﭘﻮﻳﺶ آﺳﻴﺐﭘﺬﻳﺮي ﺑﻪ ﺳﺨﺘﻲ ﭘﺎراﻣﺘﺮﻫﺎﻳﻲ را ﻛﻪ ﺑﺮاي اﻟﺤﺎق ﻳﻚ ﻓﺎﻳﻞ اﺳﺘﻔﺎده ﻣﻲﺷﻮﻧﺪ و ﻳﺎ ﮔﺮاﻣـﺮ‬ ‫‪ syntax‬اﺟﺮاﻳﻲ ﻓﻌﺎﻟﻴﺖ ﻫﺎ را ﺷﻨﺎﺳﺎﻳﻲ ﻣﻲﻛﻨﻨﺪ‪ .‬اﺑﺰارﻫﺎي ﺗﺤﻠﻴﻞ اﻳﺴﺘﺎ ﻣﻲﺗﻮاﻧﻨﺪ اﺳﺘﻔﺎده از ‪ API‬ﻫﺎي ﺧﻄﺮﻧﺎك را ﺟﺴﺘﺠﻮ ﻛﻨﻨـﺪ‪،‬‬ ‫اﻣﺎ ﻧﻤﻲ ﺗﻮاﻧﻨﺪ اﻋﺘﺒﺎرﺳﻨﺠﻲ ﻳﺎ ‪ Encode‬ﻛﺮدن ﻣﻨﺎﺳﺐ ﺑﺮاي ﻣﺤﺎﻓﻈﺖ در ﻣﻘﺎﺑﻞ آﺳﻴﺐﭘﺬﻳﺮي را ﺑﺮرﺳﻲ ﻛﻨﻨﺪ‪.‬‬ ‫روش ﻫﺎي دﺳﺘﻲ‪ :‬از ﻃﺮﻳﻖ ﺑﺎزﺑﻴﻨﻲ ﻛﺪ )‪ (code review‬ﻣﻲ ﺗﻮان ﻛﺪ اﺟﺮاﻳﻲ اﻟﺤﺎق ﻓﺎﻳﻞ ﺑﻪ ﻧﺮم اﻓﺰار را ﺟﺴﺘﺠﻮ ﻛﺮد‪ .‬اﻣﺎ ﻣﻤﻜـﻦ‬ ‫اﺳﺖ اﺷﺘﺒﺎﻫﺎت زﻳﺎدي در ﺗﺸﺨﻴﺺ آن رخ دﻫﺪ‪ .‬آزﻣﺎﻳﺶ ﻣﻲﺗﻮاﻧﺪ اﻳﻦ آﺳﻴﺐﭘﺬﻳﺮي را ﺗـﺸﺨﻴﺺ دﻫـﺪ‪ ،‬اﻣـﺎ ﺷـﻨﺎﺧﺖ ﭘﺎراﻣﺘﺮﻫـﺎي‬ ‫ﺧﺎص و ﮔﺮاﻣﺮ ﺻﺤﻴﺢ ﻣﻲﺗﻮاﻧﺪ دﺷﻮار ﺑﺎﺷﺪ‪.‬‬

‫ﻣﺤﺎﻓﻈﺖ‬ ‫ﭘﻴﺸﮕﻴﺮي از ﺿﻌﻒﻫﺎي اﻟﺤﺎق ﻓﺎﻳﻞ از راه دور ﺑﻪ ﺑﺮﻧﺎﻣﻪرﻳﺰي دﻗﻴﻖ در ﻣﺮاﺣﻞ ﻃﺮاﺣﻲ و ﻣﻌﻤﺎري در ﻃـﻮل آزﻣـﺎﻳﺶ ﻧﻴـﺎز دارد‪ .‬ﺑـﻪ‬ ‫ﻃﻮر ﻛﻠﻲ ﻧﺮماﻓﺰاري ﻛﻪ ﺑﻪ ﻃﻮر ﺻﺤﻴﺢ ﻧﮕﺎرش ﻳﺎﻓﺘﻪ ﺑﺎﺷﺪ‪ ،‬از دادهﻫﺎي ورودي ﻛﺎرﺑﺮ ﺑﺮاي ﺗﻌﻴﻴﻦ ﻧﺎم ﻓﺎﻳـﻞ )ﻣﺎﻧﻨـﺪ ﺗـﺼﺎوﻳﺮ‪ ،‬اﺳـﻨﺎد‬ ‫ﺗﺒﺪﻳﻞ ‪ XML‬و ‪ XSL‬ﻳﺎ ﻣﺤﺘﻮﻳﺎت اﺳﻜﺮﻳﭙﺘﻲ( اﺳﺘﻔﺎده ﻧﻜﺮده و داراي ﻗﻮاﻧﻴﻦ دﻳﻮاره آﺗﺶ ﻣﻨﺎﺳـﺐ ﺑـﺮاي ﺟﻠـﻮﮔﻴﺮي از اﺗـﺼﺎﻻت‬ ‫ﺟﺪﻳﺪ ﺧﺎرج از ﻣﺤﺪوده )‪ (outbound‬ﺑﻪ اﻳﻨﺘﺮﻧﺖ ﻳﺎ اﺗـﺼﺎﻻت داﺧﻠـﻲ ﺑـﻪ ﺳـﺮورﻫﺎي دﻳﮕـﺮ ﺧﻮاﻫـﺪ ﺑـﻮد‪ .‬ﻫﺮﭼﻨـﺪ ﺑـﺴﻴﺎري از‬ ‫ﻧﺮم اﻓﺰارﻫﺎي ﻗﺪﻳﻤﻲ ﺑﻪ ﭘﺬﻳﺮش دادهﻫﺎي ورودي ﻧﻴﺎز دارﻧﺪ‪.‬‬ ‫از ﺟﻤﻠﻪ ﻣﻬﻤﺘﺮﻳﻦ ﭘﻴﺸﮕﻴﺮي ﻫﺎ ﻣﻲ ﺗﻮان ﺑﻪ ﻣﻮار ذﻳﻞ اﺷﺎره ﻛﺮد‪:‬‬ ‫ƒ‬

‫اﺳﺘﻔﺎده از ﻃﺮح ارﺟﺎع )‪ (Reference‬ﻏﻴﺮ ﻣﺴﺘﻘﻴﻢ ﺑﻪ ﺷﻲ )ﺑﺮاي اﻃﻼﻋﺎت ﺑﻴﺸﺘﺮ ﺑﺨﺶ ‪ A4‬را ﺑﺒﻴﻨﻴﺪ(‪ .‬ﺑﻪ ﻃﻮر ﻣﺜﺎل در ﺟﺎﻳﻲ‬ ‫ﻛﻪ ﻧﺎم ﻓﺎﻳﻞ اﺳﺘﻔﺎده ﻣﻲﺷﻮد‪ Hash ،‬ارﺟﺎع را در ﻧﻈﺮ ﺑﮕﻴﺮﻳﺪ‪.‬‬

‫ﺑﻪ ﺟﺎي اﺳﺘﻔﺎده از ﻛﺪ ذﻳﻞ‪:‬‬ ‫>"‪<select name="language‬‬ ‫>‪English
‫>"‪<select name="language‬‬ ‫>‪English
‫‪١٩‬‬

‫از ‪ Salt‬ﻫﺎ ﺑﺮاي ﺟﻠﻮﮔﻴﺮي از ﺣﻤﻠﻪ ‪ Bruteforce‬ﺑﻪ ‪ Reference‬ارﺟﺎع ﻏﻴﺮ ﻣﺴﺘﻘﻴﻢ ﺑﻪ اﺷـﻴﺎء اﺳـﺘﻔﺎده ﻛﻨﻴـﺪ‪ .‬ﻣﺘﻨﺎوﺑـﺎ ﻓﻘـﻂ از‬ ‫ﻣﻘــﺪارﻫﺎي ‪ index‬ﻣﺎﻧﻨــﺪ ‪1‬و ‪2‬و ‪ 3‬اﺳــﺘﻔﺎده ﻛﻨﻴــﺪ و ﻣﻄﻤــﺌﻦ ﺑﺎﺷــﻴﺪ ﻛــﻪ ﺧــﻮد آراﻳــﻪ ﺑــﺮاي ﺗــﺸﺨﻴﺺ ﻣﺪاﺧﻠــﻪ ﭘــﺎراﻣﺘﺮي‬ ‫)‪ (Parameter Tampering‬ﺑﺮرﺳﻲ ﻣﻲﺷﻮﻧﺪ‪.‬‬ ‫ƒ‬

‫از ﻣﻜﺎﻧﻴﺰم ﻫﺎي ﺻﺤﻴﺢ ﺑﺮرﺳﻲ ﻋﻴﻮب )‪ (Explicit taint‬در ﺻﻮرﺗﻲ ﻛﻪ زﺑﺎن ﺑﺮﻧﺎﻣﻪ آن را ﭘﺸﺘﻴﺒﺎﻧﻲ ﻣﻲﻛﻨﺪ‪ ،‬اﺳـﺘﻔﺎده ﻛﻨﻴـﺪ‪.‬‬ ‫در ﻏﻴﺮ اﻳﻦ ﺻﻮرت از اﻟﮕﻮي ﻧﺎﻣﮕﺬاري ﻣﺘﻐﻴﺮ ﺑﺮاي ﻛﻤﻚ ﺑﻪ ﺑﺮرﺳﻲ ﻋﻴﻮب اﺳﺘﻔﺎده ﻛﻨﻴﺪ‪:‬‬ ‫‪$hostile = &$_POST; // refer to POST variables, not $_REQUEST‬‬ ‫‪$safe[ ' filename ' ] = validate_file_name ($hostile[ ' unsafe_filename ' ] ) ; // make it safe‬‬

‫ﺑﻨﺎﺑﺮاﻳﻦ ﻫﺮ ﻋﻤﻠﻜﺮدي ﺑﺮ ﻣﺒﻨﺎي ورودي ﻣﺨﺮب ﻓﻮرا آﺷﻜﺎر ﻣﻲﺷﻮد‪:‬‬ ‫;)'‪: require_once ($_POST[‘unsafe_filename’] . 'inc.php‬‬ ‫;)'‪; require_once ($safe ['filename'] . 'inc.php‬‬ ‫ƒ‬

‫ﻣﻮﻛﺪا ﺑﺎ اﺳﺘﻔﺎده از "‪ "accept known good‬ﺑﻪ ﻋﻨﻮان ﻳﻚ اﺳﺘﺮاﺗﮋي‪ ،‬ورودي ﻛﺎرﺑﺮ را ﻣﻌﺘﺒﺮﺳﺎزي ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫ﻗﻮاﻧﻴﻦ دﻳﻮاره آﺗﺶ را ﺑﺮاي ﺟﻠـﻮﮔﻴﺮي از ﺑﺮﻗـﺮاري ارﺗﺒـﺎط ﺟﺪﻳـﺪ از ﻃﺮﻳـﻖ ﺳـﺮورﻫﺎ ﺑـﻪ ﺳـﺎﻳﺖﻫـﺎي وب ﺧـﺎرﺟﻲ و‬ ‫ﺳﻴﺴﺘﻢ ﻫﺎي داﺧﻠﻲ اﺿﺎﻓﻪ ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫ﺑﺮرﺳﻲ ﻛﻨﻴﺪ ﻛﻪ ﻓﺎﻳﻞﻫﺎ ﻳﺎ ﻧﺎم ﻓﺎﻳﻞ ﻫﺎي ورودي ﻛﺎرﺑﺮ ﻧﺘﻮاﻧـﺪ ﺳـﺎﻳﺮ ﻛﻨﺘـﺮلﻫـﺎ ﻣﺎﻧﻨـﺪ آﻟـﻮده ﻛـﺮدن دادهﻫـﺎي ﻣﻮﺟـﻮد در‬ ‫‪ avatar ،session object‬ﻫﺎ و ﺗﺼﺎوﻳﺮ‪ ،‬ﮔﺰارﺷﻬﺎي ‪ ، PDF‬ﻓﺎﻳﻠﻬﺎي ﻣﻮﻗﺖ و ﻏﻴﺮه را ﺣﺬف ﻛﻨﺪ‪.‬‬

‫ƒ‬

‫ﭘﻴﺎدهﺳﺎزي ‪ chroot jail‬ﻳﺎ ﺳﺎﻳﺮ ﻣﻜﺎﻧﻴﺰﻣﻬﺎي ‪ sandbox‬از ﻗﺒﻴﻞ ﻣﺠﺎزي ﺳﺎزي ﺑﺮاي ﺟﺪاﺳﺎزي ﻧﺮم اﻓﺰارﻫﺎ از ﻫﻤﺪﻳﮕﺮ را‬ ‫ﻣﺪﻧﻈﺮ ﺑﮕﻴﺮﻳﺪ‪.‬‬

‫ƒ‬

‫‪ rejister – globals :PHP‬را ﻏﻴﺮ ﻓﻌﺎل ﻛﻨﻴﺪ و ﺑﺮاي ﭘﻴﺪا ﻛﺮدن ﻣﺘﻐﻴﺮﻫﺎي ﻓﺎﻗﺪ ﻣﻘﺪار اوﻟﻴﻪ از ‪ E-STRICT‬اﺳـﺘﻔﺎده‬ ‫ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫‪ allow-url-fopen :PHP‬و ‪ allow-url-include‬را در ‪ php.ini‬ﻏﻴﺮ ﻓﻌﺎل ﻛﻨﻴﺪ و ﺳﺎﺧﺘﻤﺎن ﻣﺤﻠﻲ ‪ PHP‬را ﻛـﻪ‬ ‫ﺷﺎﻣﻞ اﻳﻦ ﻋﻤﻠﻜﺮد ﻧﺒﺎﺷﺪ ﻟﺤﺎظ ﻛﻨﻴﺪ‪ .‬ﺗﻌﺪاد ﻛﻤﻲ از ﻧﺮم اﻓﺰارﻫﺎ ﺑﻪ اﻳﻦ ﻋﻤﻠﻜﺮد ﻧﻴﺎز دارﻧﺪ ﭘﺲ ﺑﻬﺘـﺮ اﺳـﺖ اﻳـﻦ ﺗﻨﻈﻴﻤـﺎت‬ ‫ﺑﺮروي ﻧﺮم اﻓﺰار ﻓﻌﺎل ﺷﻮد‪.‬‬

‫‪٢٠‬‬

OWASP Top 10 2007

‫( و ﻋـﺪم ﭘـﺸﺘﻴﺒﺎﻧﻲ ﺗﻮاﺑـﻊ از‬stream_*) ‫( ﻣﺎﻧﻨﺪ‬streams functions) ‫ از ﺑﺮرﺳﻲ دﻗﻴﻖ ﻓﺎﻳﻞ و ﺗﻮاﺑﻊ رﺷﺘﻪ اي‬:PHP

ƒ

:‫ ﻣﺎﻧﻨﺪ‬.‫ ﻣﻄﻤﺌﻦ ﺷﻮﻳﺪ‬،‫داده ﻫﺎي ورودي ﻛﺎرﺑﺮ ﻛﻪ ﺑﻪ ﻋﻨﻮان آرﮔﻮﻣﺎن ﻧﺎم ﻓﺎﻳﻞ ﭘﺬﻳﺮﻓﺘﻪ ﻣﻲ ﺷﻮﻧﺪ‬ include( ) include_once( ) require( ) require_once( ) fopen( ) imagecreatefromXXX( ) file( ) file_get_contents( ) copy( ) delete( ) unlink( ) upload_tmp_dir( ) $_FILES move_uploaded_file( )

.(the back tick operator) ‫ ﻳـﺎ‬pass thru( ) ، eval( ) ، system( ) ‫ در ﺻﻮرت ارﺳﺎل دادهﻫﺎ ﺑـﻪ ﺗﻮاﺑـﻊ‬:PHP

ƒ

.‫ﻫﻮﺷﻴﺎراﻧﻪ ﻋﻤﻞ ﻛﻨﻴﺪ‬ ‫ و اﻋﻄﺎء درﺳﺖ ﻣﺠﻮزﻫـﺎ ﺗﻮﺳـﻂ‬security manager ‫ از ﻓﻌﺎل ﺑﻮدن و ﭘﻴﻜﺮﺑﻨﺪي ﺻﺤﻴﺢ‬J2EE ‫در ﺻﻮرت اﺳﺘﻔﺎده از‬

ƒ

.‫ﺑﺮﻧﺎﻣﻪ ﻛﺎرﺑﺮدي اﻃﻤﻴﻨﺎن ﺣﺎﺻﻞ ﻛﻨﻴﺪ‬ ‫ ﻣﺮاﺟﻌﻪ ﻛﻨﻴﺪ و ﻧﺮم اﻓﺰار را ﺑﻪ ﺷـﻜﻠﻲ ﻣﻄﻤـﺌﻦ ﻃﺮاﺣـﻲ ﻛﻨﻴـﺪ ﻛـﻪ ﺑـﻪ‬Partial trust ‫ ﺑﻪ ﻣﺴﺘﻨﺪات در‬ASP.NET ‫در‬

ƒ

.‫ﻗﺴﻤﺖ ﻫﺎي ﻣﺨﺘﻠﻒ اﻣﻦ ﺗﻘﺴﻴﻢ ﺷﻮد در ﺣﺎﻟﻴﻜﻪ اﻛﺜﺮ ﻧﺮم اﻓﺰارﻫﺎي ﻣﻮﺟﻮد در ﭘﺎﻳﻴﻦ ﺗﺮﻳﻦ ﺳﻄﺢ اﻋﺘﻤﺎد ﺗﻨﻈﻴﻢ ﺷﺪه اﻧﺪ‬

‫ﻧﻤﻮﻧﻪ ﻫﺎ‬ ƒ

. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0360

ƒ ƒ

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5220 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4722

‫ﻣﺮاﺟﻊ‬ ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ

CWE: CWE-98 (PHP File Inclusion), CWE-78 (OS Command Injection), CWE-95 (Eval injection), CWE-434 (Unrestricted file upload) WASC Threat Classification: http://www.webappsec.org/projects/threat/classes/os_commanding.shtml OWASP Guide, http://www.owasp.org/index.php/File_System#Includes_and_Remote_files OWASP Testing Guide, http://www.owasp.org/index.php/Testing_for_Directory_Traversal OWASP PHP Top 5, http://www.owasp.org/index.php/PHP_Top_5#P1:_Remote_Code_Execution Stefan Esser, http://blog.php-security.org/archives/45-PHP-5.2.0-andallow_url_include.html [SIF01] SIFT, Web Services: Teaching an old dog new tricks, http://www.ruxcon.org.au/files/2006/web_services_security.ppt http://www.owasp.org/index.php/OWASP_Java_Table_of_Contents#Defining_a_Java_ Security_Policy Microsoft - Programming for Partial Trust, http://msdn2.microsoft.com/enus/library/ms364059(VS.80).aspx ٢١

‫ارﺟﺎع ﻧﺎاﻣﻦ ﻣﺴﺘﻘﻴﻢ ﺑﻪ ﺷﻲ‬

‫‪A4 – INSECURE DIRECT OBJECT REFERENCE‬‬

‫ارﺟﺎع ﻣﺴﺘﻘﻴﻢ ﺑﻪ ﺷﻲ‪ ،‬زﻣﺎﻧﻲ ﻛﻪ ﺑﺮﻧﺎﻣﻪﻧﻮﻳﺲ ارﺟﺎﻋﻲ ﺑﻪ ﺷﻲ داﺧﻠﻲ ﻣﺜﻞ ﻓﺎﻳﻞ‪ ،‬داﻳﺮﻛﺘﻮري‪ ،‬رﻛﻮرد ﭘﺎﻳﮕﺎه داده ﻳﺎ ﻓﻴﻠﺪ را ﺑـﻪ ﻋﻨـﻮان‬ ‫‪ URL‬ﻳﺎ ﭘﺎراﻣﺘﺮ ﻓﺮم در دﺳﺘﺮس ﮔﺬاﺷﺘﻪ ﺑﺎﺷﺪ‪ ،‬روي ﻣﻲ دﻫﺪ‪ .‬ﻣﻬﺎﺟﻢ ﻣﻲﺗﻮاﻧﺪ ارﺟﺎع ﻣﺴﺘﻘﻴﻢ ﺑﻪ ﺷﻲ را ﺑﺮاي دﺳﺘﺮﺳـﻲ ﺑـﻪ دﻳﮕـﺮ‬ ‫اﺷﻴﺎء ﻳﺎ ‪object‬ﻫﺎ ﺑﻪ ﺻﻮرت ﻏﻴﺮﻣﺠﺎز ﺗﻐﻴﻴﺮ دﻫﺪ‪ ،‬ﻣﮕﺮ اﻳﻨﻜﻪ ﻣﻜﺎﻧﻴﺰم ﻛﻨﺘﺮل دﺳﺘﺮﺳﻲ در ﻣﺤﻞ وﺟﻮد داﺷﺘﻪ ﺑﺎﺷﺪ‪ .‬ﺑـﺮاي ﻣﺜـﺎل‪ :‬در‬ ‫اﻳﻨﺘﺮﻧﺖ در ﻧﺮماﻓﺰارﻫﺎي ﺑﺎﻧﻜﺪاري‪ ،‬اﺳﺘﻔﺎده از ﺷﻤﺎره ﺣﺴﺎب ﻛﺎرﺑﺮي ﺑﻪ ﻋﻨﻮان ﻛﻠﻴﺪ اوﻟﻴﻪ راﻳﺞ اﺳـﺖ‪ .‬ﺑﻨـﺎﺑﺮاﻳﻦ اﺳـﺘﻔﺎده از ﺷـﻤﺎره‬ ‫ﺣــﺴﺎب ﺑــﻪ ﺻــﻮرت ﻣــﺴﺘﻘﻴﻢ در واﺳــﻂ )‪ (interface‬وب ﺣﺘــﻲ اﮔــﺮ ﺑﺮﻧﺎﻣــﻪ ﻧــﻮﻳﺲ از ﭘــﺮس و ﺟــﻮ ﻫــﺎي ﺗــﺸﺨﻴﺺ دﻫﻨــﺪه‬ ‫‪ prametarized query‬در ‪ SOL‬ﺑﺮاي ﺟﻠﻮﮔﻴﺮي از ﺗﺰرﻳﻖ ‪ sql‬اﺳﺘﻔﺎده ﻛﺮده ﺑﺎﺷﺪ‪ ،‬وﺳﻮﺳﻪاﻧﮕﻴﺰ اﺳﺖ‪ .‬اﮔﺮ روﺷـﻬﺎي ﺑﺮرﺳـﻲ‬ ‫ﺑﻴﺸﺘﺮي ﺟﻬﺖ ﻣﺠﺎزﺷﻤﺎري ﻛﺎرﺑﺮ ﺑﺮاي دﻳﺪن ﺣﺴﺎب و اﻳﻨﻜﻪ ﻛﺎرﺑﺮ‪ ،‬دارﻧﺪه ﺣﺴﺎب اﺳﺖ ﻳﺎ ﺧﻴﺮ وﺟﻮد ﻧﺪاﺷـﺘﻪ ﺑﺎﺷـﺪ‪ ،‬ﻣﻬـﺎﺟﻢ ﺑـﺎ‬ ‫اﺳﺘﻔﺎده از ‪ Tampering‬ﭘﺎراﻣﺘﺮ ﺷﻤﺎره ﺣﺴﺎب ﻣﻲﺗﻮاﻧﺪ ﻫﻤﻪ ﺣﺴﺎب ﻫﺎي ﻛﺎرﺑﺮي را ﺗﻐﻴﻴﺮ دﻫﺪ‪ .‬اﻳﻦ ﻧﻮع ﺣﻤﻠﻪ در ﺳﺎﻳﺖ ﺷـﺮﻛﺖ‬ ‫‪ GST startup Assistance‬در ‪ Taxetion‬اﺳﺘﺮاﻟﻴﺎ در ﺳﺎل ‪ 2000‬اﺗﻔﺎق اﻓﺘﺎد و در آن ﻛﺎرﺑﺮي ﻣﺘﺨﺎﺻﻢ ﺑﻪ ﺳـﺎدﮔﻲ ﻣﻮﺟـﻮدي‬ ‫)ﺷﺮﻛﺖ ﻣﺎﻟﻴﺎﺗﻲ( ‪ ABN‬در ‪ URL‬را ﺗﻐﻴﻴﺮ داد‪ .‬ﻛﺎرﺑﺮ رﻳﺰ ﺣﺴﺎب ‪ 17000‬ﺷﺮﻛﺖ را از ﺳﻴﺴﺘﻢ رﺑﻮد و ﺳـﭙﺲ ﺑـﻪ ﺗﻤـﺎﻣﻲ ‪17000‬‬ ‫ﺷﺮﻛﺖ ﺟﺰﺋﻴﺎت ﻣﺤﻠﻪاش را ‪ email‬ﻛﺮد‪ .‬اﻳﻦ ﻧﻮع آﺳﻴﺐ ﭘﺬﻳﺮي ﺑﺴﻴﺎر راﻳﺞ اﺳﺖ در ﺣﺎﻟﻴﻜﻪ در ﺑﺴﻴﺎري از ﻧـﺮم اﻓﺰارﻫـﺎ آزﻣـﺎﻳﺶ‬ ‫ﻧﺸﺪه اﺳﺖ‪.‬‬

‫ﻣﺤﻴﻂ ﻫﺎي ﻣﺘﺎﺛﺮ‬ ‫ﺗﻤﺎﻣﻲ ﺳﺎﺧﺘﺎرﻫﺎي ﻧﺮماﻓﺰارﻫﺎي ﺗﺤﺖ وب در ﺑﺮاﺑﺮ ﺣﻤﻼت ارﺟﺎﻋﺎت ﻧﺎاﻣﻦ ﻣﺴﺘﻘﻴﻢ ﺑﻪ ﺷﻲ آﺳﻴﺐﭘﺬﻳﺮ ﻫﺴﺘﻨﺪ‪.‬‬

‫آﺳﻴﺐ ﭘﺬﻳﺮي‬ ‫ﺑﺴﻴﺎري از ﻧﺮم اﻓﺰارﻫﺎ ارﺟﺎﻋﺎت ﺑﻪ ‪ object‬داﺧﻠﻲ را در دﺳﺘﺮس ﻛﺎرﺑﺮان ﻗﺮار ﻣـﻲدﻫﻨـﺪ ﻣﻬـﺎﺟﻤﻴﻦ ﺑـﺎ اﺳـﺘﻔﺎده اﻳﺠـﺎد ﭘﺎراﻣﺘﺮﻫـﺎ‬ ‫)‪ (parameter tampering‬ارﺟﺎﻋﺎت را ﺗﻐﻴﻴﺮ ﻣﻲدﻫﻨﺪ و ﻋﻤﺪاً ﺳﻴﺎﺳﺖ ﻛﻨﺘﺮل دﺳﺘﺮﺳﻲ را ﻧﻘﺾ ﻣﻲﻛﻨﻨﺪ‪ .‬اﻳﻦ ارﺟﺎﻋﺎت ﺑﺎرﻫﺎ ﺑﻪ‬ ‫ﺳﻴﺴﺘﻢ‪-‬ﻓﺎﻳﻞﻫﺎ و ﭘﺎﻳﮕﺎه ﻫﺎي داده اﺷﺎره ﻣﻲﻛﻨﻨﺪ‪ .‬ﻫﺮ ﻧﺮماﻓﺰار ﺑﺪون ﻣﺤﺎﻓﻈﺖ ﻣﻲﺗﻮاﻧﺪ آﺳﻴﺐﭘﺬﻳﺮ ﺑﺎﺷﺪ‪ .‬ﺑﺮاي ﻣﺜﺎل‪ :‬اﮔﺮ ﺑﺮﻧﺎﻣﻪ ﺑﺮاي‬ ‫ﺗﻌﻴﻴﻦ ﻧﺎم ﻓﺎﻳﻞﻫﺎ ﻳﺎ ﻣﺴﻴﺮﻫﺎ از ورودي ﻛﺎرﺑﺮ اﺳﺘﻔﺎده ﻧﻤﺎﻳـﺪ‪ ،‬ﺑـﺪﻳﻦ ﺗﺮﺗﻴـﺐ ﻣﻬـﺎﺟﻤﻴﻦ ﻣـﻲ ﺗﻮاﻧﻨـﺪ از اﻳـﻦ ﺿـﻌﻒ ﺑـﺮاي ﻋﺒـﻮر از‬ ‫داﻳﺮﻛﺘﻮري ﻧﺮم اﻓﺰار و دﺳﺘﺮﺳﻲ ﺑﻪ ﻣﻨﺎﺑﻊ دﻳﮕﺮ اﺳﺘﻔﺎده ﻧﻤﺎﻳﻨﺪ‪.‬‬ ‫>‪<select name="language">Français
‫‪٢٢‬‬

‫‪OWASP Top 10 2007‬‬ ‫;)"‪require_once ($_REQUEST['language']."lang.php‬‬ ‫ﭼﻨﻴﻦ ﻛﺪي ﻣﻲﺗﻮاﻧﺪ ﺑﺎ اﺳﺘﻔﺎده از رﺷﺘﻪاي ﺷﺒﻴﻪ اﻳـﻦ "‪ "../../../../etc/passwd%00‬و ﺑـﺎ اﺳـﺘﻔﺎده از ‪null byte injection‬‬ ‫)ﺑﺮاي اﻃﻼﻋﺎت ﺑﻴﺸﺘﺮ راﻫﻨﻤﺎي ‪ OWASP‬را ﺑﺒﻴﻨﺪ( ﻫﻨﮕﺎم دﺳﺘﺮﺳﻲ ﻓﺎﻳﻞﻫﺎي ﺳﻴﺴﺘﻢ ﻓﺎﻳﻞ ﺳﺮور وب ﻣﻮرد ﺣﻤﻠﻪ واﻗﻊ ﺷﻮد‪.‬‬ ‫ﻫﻤﻴﻨﻄﻮر ارﺟﺎﻋﺎت ﻓﻠﻴﺪﻫﺎي ﭘﺎﻳﮕﺎه داده ﺑﺎرﻫﺎ در دﺳﺘﺮس ﻗﺮار داده ﻣﻲ ﮔﻴﺮﻧﺪ‪ .‬ﺑﻨﺎﺑﺮاﻳﻦ ﻣﻬﺎﺟﻢ ﻣﻲﺗﻮاﻧﺪ از اﻳﻦ ﭘـﺎراﻣﺘﺮ ﺑـﻪ ﺳـﺎدﮔﻲ‬ ‫ﺑﺮاي ﺣﻤﻠﻪ ﺑﻪ دﻳﮕﺮ ﻓﻴﻠﺪﻫﺎي ﻣﻌﺘﺒﺮ ﺑﻮﺳﻴﻠﻪ ﺣﺪس ﻳﺎ ﺟﺴﺘﺠﻮ اﺳﺘﻔﺎده ﻛﻨﺪ‪ .‬در ﻣﺜﺎل زﻳﺮ اﮔﺮ ﻧﺮم اﻓﺰاري ﻫﻴﭻ ﻟﻴﻨﻜـﻲ ﺑـﺮاي ﻛﺎرﺗﻬـﺎي‬ ‫ﻏﻴﺮ ﻣﺠﺎز اراﺋﻪ ﻧﺪﻫﺪ و ﻫﻴﭻ ﺗﺰرﻳﻖ ‪ SQL‬ﻳﻲ ﻣﻤﻜﻦ ﻧﺒﺎﺷﺪ‪ ،‬ﻣﻬﺎﺟﻢ ﻣﻲﺗﻮاﻧﺪ ﺷﻨﺎﺳﻪ ﻛﺎرت را ﺑﻪ ﻫﺮ ﻛﺎرﺗﻲ ﻛﻪ ﻣﻲﺧﻮاﻫﺪ ﺗﻐﻴﻴﺮ دﻫﺪ‪.‬‬ ‫;) ) "‪int cartID = Integer.parseInt( request.getParameter( "cartID‬‬ ‫;‪String query = "SELECT * FROM table WHERE cartID=" + cartID‬‬

‫ﺑﺮرﺳﻲ اﻣﻨﻴﺖ‬ ‫ﻫﺪف ﺗﻌﻴﻴﻦ ﻋﺪم ﺗﻮاﻧﺎﻳﻲ ﻣﻬﺎﺟﻢ ﺟﻬﺖ ﺗﻐﻴﻴﺮ ارﺟﺎﻋﺎت ﻣﺴﺘﻘﻴﻢ ﺑﻪ ﺷﻲ در ﻧﺮم اﻓﺰار اﺳﺖ‪.‬‬ ‫روش ﻫﺎي ﺧﻮدﻛﺎر‪ :‬اﺑﺰارﻫﺎي ﭘﻮﻳﺶ آﺳﻴﺐﭘﺬﻳﺮي ﺑﻪ دﺷﻮاري ﭘﺎراﻣﺘﺮﻫـﺎي ﻣـﺴﺘﻌﺪ ﺗﻐﻴﻴـﺮ ﻳـﺎ دﺳـﺘﻜﺎري را ﺗـﺸﺨﻴﺺ ﻣـﻲدﻫﻨـﺪ‪.‬‬ ‫اﺑﺰارﻫﺎي ﺗﺤﻠﻴﻞ اﻳﺴﺘﺎ واﻗﻌﺎً ﻧﻤﻲﺗﻮاﻧﻨﺪ ﭘﺎراﻣﺘﺮﻫﺎﻳﻲ را ﻛﻪ ﺑﻪ ﺑﺮرﺳﻲ ﻛﻨﺘﺮل دﺳﺘﺮﺳﻲ ﻗﺒﻞ از اﺳﺘﻔﺎده اﺣﺘﻴﺎج دارﻧﺪ‪ ،‬ﺷﻨﺎﺳﺎﻳﻲ ﻛﻨﻨﺪ‪.‬‬ ‫روشﻫﺎي دﺳﺘﻲ‪ :‬ﺑﺎزﺑﻴﻨﻲ ﻛﺪ در ﺑﺴﻴﺎري ﻣﻮارد ﻣﻲﺗﻮاﻧﺪ ﭘﺎراﻣﺘﺮﻫﺎي ﺑﺤﺮاﻧﻲ را ﺷﻨﺎﺳﺎﻳﻲ و ﺗﻌﻴﻴﻦ ﻛﻨﺪ ﻛﻪ آﻳﺎ آﻧﻬـﺎ ﻣـﺴﺘﻌﺪ ﺗﻐﻴﻴـﺮ ﻳـﺎ‬ ‫دﺳﺘﻜﺎري ﻫﺴﺘﻨﺪ ﻳﺎ ﺧﻴﺮ‪ .‬ﺗﺴﺖ ﻧﻔﻮذ ﭘﺬﻳﺮي ﻧﻴﺰ ﻣﻲﺗﻮاﻧﺪ اﻣﻜﺎن دﺳﺘﻜﺎري را ﺗﻌﻴﻴﻦ ﻛﻨﺪ اﻣﺎ ﻫﺮ دوي اﻳﻦ ﺗﻜﻨﻴﻚﻫﺎ زﻣﺎن ﺑﺮ ﻫﺴﺘﻨﺪ‪.‬‬

‫ﻣﺤﺎﻓﻈﺖ‬ ‫ﺑﻬﺘﺮﻳﻦ روش‪ ،‬ﺣﻔﺎﻇﺖ از ارﺟﺎﻋﺎت ﻣﺴﺘﻘﻴﻢ ﺑﻪ ﺷﻲ ﺑﻮﺳﻴﻠﻪ اﺳﺘﻔﺎده از ‪ Index‬و ﻫﻤﭽﻨﻴﻦ اﺳﺘﻔﺎده از ﻃﺮح ارﺟﺎع ﻏﻴﺮ ﻣﺴﺘﻘﻴﻢ ﻳﺎ‬ ‫دﻳﮕﺮ روش ﻫﺎي ﻏﻴﺮ ﻣﺴﺘﻘﻴﻤﻲ اﺳﺖ ﻛﻪ ﺑﻪ راﺣﺘﻲ ﻣﻌﺘﺒﺮ ﺳﺎزي ﻣﻲﺷﻮﻧﺪ‪ .‬اﮔﺮ ﺑﺎﻳﺪ از ارﺟﺎع ﻣﺴﺘﻘﻴﻢ ﺑﻪ ﺷﻲ اﺳﺘﻔﺎده ﺷﻮد از‬ ‫ﻣﺠﺎز ﺷﻤﺎري ﻛﺎرﺑﺮ ﻗﺒﻞ از اﺳﺘﻔﺎده از ارﺟﺎﻋﺎت ﻣﻄﻤﺌﻦ ﺷﻮﻳﺪ‪.‬‬ ‫اﻳﺠﺎد ﻳﻚ روش اﺳﺘﺎﻧﺪارد ﺟﻬﺖ ارﺟﺎع ﺑﻪ ﺷﻲ در ﻧﺮم اﻓﺰار ﺑﺴﻴﺎر ﻣﻬﻢ اﺳﺖ‪:‬‬ ‫ƒ‬

‫از ارﺟﺎﻋﺎت ﺑﻪ ﺷﻲ ﺧﺼﻮﺻﻲ )‪ (private object‬ﺑﺪون ﺣﻔﺎظ ﻣﺜﻞ ﻛﻠﻴﺪ اوﻟﻴﻪ ﺑﺎ ﻧﺎم ﻓﺎﻳﻞ ﺗﻮﺳﻂ ﻛﺎرﺑﺮان ﺟﻠﻮﮔﻴﺮي ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫ارﺟﺎع ﺑﻪ ﺷﻲ ﺧﺼﻮﺻﻲ را در ﻫﺮ ﻣﻜﺎﻧﻲ ﺑﻮﺳﻴﻠﻪ روش "‪ "accept known good‬اﻋﺘﺒﺎرﺳﻨﺠﻲ ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫ﻣﺠﻮزﻫﺎي واﮔﺬار ﺷﺪه ﺟﻬﺖ ارﺟﺎع ﺑﻪ اﺷﻴﺎء را ﺑﺮرﺳﻲ ﻛﻨﻴﺪ‪.‬‬

‫ﺑﻬﺘﺮﻳﻦ راه ﺣﻞ ﺑﺮاي ﺟﻠﻮﮔﻴﺮي از ﺣﻤﻼت دﺳﺘﻜﺎري ﭘﺎراﻣﺘﺮ اﺳﺘﻔﺎده از ﻣﻘﺪار ‪ Index‬ﻳﺎ ﻃﺮح ارﺟﺎع ﻣﻲﺑﺎﺷﺪ‪.‬‬ ‫‪http://www.example.com/application?file=1‬‬

‫‪٢٣‬‬

‫ و دﻳﮕﺮ روشﻫﺎي‬SQL ‫ ﻣﻄﻤﺌﻦ ﺷﻮﻳﺪ ﻛﻪ ﻋﺒﺎرات‬،‫اﮔﺮ ﺑﺎﻳﺪ ارﺟﺎﻋﺎت ﻣﺴﺘﻘﻴﻢ ﺑﻪ ﺳﺎﺧﺘﺎرﻫﺎي ﭘﺎﻳﮕﺎه داده را در دﺳﺘﺮس ﻗﺮار دﻫﻴﺪ‬ .‫دﺳﺘﻴﺎﺑﻲ ﺑﻪ ﭘﺎﻳﮕﺎه داده ﻓﻘﻂ ﺑﻪ رﻛﻮردﻫﺎي ﻣﺠﺎز اﺟﺎزه ﻧﻤﺎﻳﺶ ﻣﻲدﻫﻨﺪ‬ int cartID = Integer.parseInt ( request.getParameter( "cartID" ) ); User user = (User) request.getSession( ).getAttribute( "user" ); String query = "SELECT * FROM table WHERE cartID=" + cartID + " AND userID=" + user.getID();

‫ﻧﻤﻮﻧﻪ ﻫﺎ‬ ƒ ƒ ƒ

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0329 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4369 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0229

‫ﻣﺮاﺟﻊ‬ ƒ ƒ ƒ ƒ ƒ ƒ

CWE: CWE-22 (Path Traversal), CWE-472 (Web Parameter Tampering) WASC Threat Classification: http://www.webappsec.org/projects/threat/classes/abuse_of_functionality.shtml http://www.webappsec.org/projects/threat/classes/insufficient_authorization.shtml OWASP Testing Guide, http://www.owasp.org/index.php/Testing_for_business_logic OWASP Testing Guide, http://www.owasp.org/index.php/Testing_for_Directory_Traversal OWASP, http://www.owasp.org/index.php/Category:Access_Control_Vulnerability GST Assist attack details, http://www.abc.net.au/7.30/stories/s146760.htm

٢٤

‫‪OWASP Top 10 2007‬‬

‫ﺟﻌﻞ درﺧﻮاﺳﺖ ﺑﻴﻦ ﺳﺎﻳﺘﻲ‬

‫)‪A5 – CROSS SITE REQUEST FORGERY (CSRF‬‬

‫ﺟﻌﻞ درﺧﻮاﺳﺖ ﺑﻴﻦ ﺳﺎﻳﺘﻲ )‪ (CSRF‬ﺣﻤﻠﻪ ﺟﺪﻳﺪي ﻧﻴﺴﺖ‪ ،‬اﻣﺎ ﺳﺎده و ﻣﺨﺮب اﺳﺖ‪ .‬ﺣﻤﻠﻪ ‪ CSRF‬ﻣﺮورﮔﺮ وب ﻗﺮﺑﺎﻧﻲ‬ ‫اﺣﺮاز ﻫﻮﻳﺖ ﺷﺪه را ﺑﻪ ﺻﻔﺤﻪ وﺑﻲ ﻫﺪاﻳﺖ ﻣﻲﻛﻨﺪ ﻛﻪ ﻋﻤﻞ دﻟﺨﻮاه ﻣﻬﺎﺟﻢ ﻣﺎﻧﻨﺪ ﺗﻐﻴﻴﺮ آدرس ‪ email‬ﻛﺎرﺑﺮ را اﻧﺠﺎم دﻫﺪ‪ .‬اﻳﻦ‬ ‫آﺳﻴﺐﭘﺬﻳﺮي ﺑﻄﻮر ﮔﺴﺘﺮدهاي ﻣﻨﺘﺸﺮ ﺷﺪه و ﻫﻤﻪ ﻧﺮماﻓﺰارﻫﺎ ﺑﺎ وﻳﮋﮔﻲﻫﺎي زﻳﺮ در ﺧﻄﺮ ﻗﺮار ﻣﻲ ﮔﻴﺮﻧﺪ‪:‬‬ ‫ƒ ﺑﺮرﺳﻲﻫﺎي ﻣﺠﺎزﺷﻤﺎري ﻓﺎﻗﺪ ﻣﻜﺎﻧﻴﺰمﻫﺎي ﻣﺠﺎزﺷﻤﺎري ﺟﻬﺖ ﺟﻠﻮﮔﻴﺮي از اِﻋﻤﺎل آﺳﻴﺐﭘﺬﻳﺮي ﺑﺎﺷﺪ‪.‬‬ ‫ƒ اﮔﺮ ورودي ﭘﻴﺶ ﻓﺮض ﻗﺎدر ﺑﻪ اراﺋﻪ در ﻳﻚ درﺧﻮاﺳﺖ ﺑﺎﺷﺪ‪ ،‬اﻣﻜﺎن ﭘﺮدازش آن ﻋﻤﻠﻜﺮد ﻣﻴﺴﺮ ﺑﺎﺷﺪ‪ ) .‬ﻣﺎﻧﻨﺪ‪:‬‬ ‫)‪http://www.example.com/admin/dosomthing.ctl?username=admin&passwd=admin‬‬ ‫ƒ درﺧﻮاﺳﺖ ﻫﺎي ﻣﺠﺎز ﻓﻘﻂ ﺑﺮ اﻋﺘﺒﺎرﻧﺎﻣﻪﻫﺎﻳﻲ ﻛﻪ ﺑﻪ ﺻﻮرت اﺗﻮﻣﺎﺗﻴﻚ ﺛﺒﺖ ﺷﺪهاﻧﺪ ﻣﺒﺘﻨﻲ ﺑﺎﺷﻨﺪ‪ .‬ﻣﺎﻧﻨﺪ ﻛﻮﻛﻲ ‪ session‬در‬ ‫ﺻﻮرت ورود ﺑﻪ ﺑﺮﻧﺎﻣﻪ در زﻣﺎن ﺟﺎري ﻳﺎ ﻋﻤﻠﻜﺮد ﮔﺰﻳﻨﻪ "‪ "Remember me‬در ﺻﻮرت ﻋﺪم ورود ﺑﻪ ﺑﺮﻧﺎﻣﻪ ﻳﺎ ﻧﺸﺎﻧﻪ‬ ‫‪ Kerberos‬در ﺻﻮرت ﺷﺮﻛﺖ ﻛﺮدن در اﻳﻨﺘﺮﻧﺖ از ﻃﺮﻳﻖ ورود ﻣﺠﺘﻤﻊ ﺑﺎ ا ‪. Active Directory‬‬ ‫ﻣﺘﺎﺳﻔﺎﻧﻪ اﻣﺮوزه اﻏﻠﺐ ﻧﺮم اﻓﺰارﻫﺎ ﻓﻘﻂ ﺑﺮ اﻋﺘﺒﺎرﻧﺎﻣﻪﻫﺎي اراﺋﻪ ﺷﺪه ﺑﻪ ﺻﻮرت ﺧﻮدﻛﺎر ﻣﺜﻞ ﻛﻮﻛﻲﻫﺎي ﻧﺸﺴﺖ‪ ،‬اﻋﺘﺒﺎرﻧﺎﻣﻪﻫﺎي اﺣﺮاز‬ ‫ﻫﻮﻳﺖ اوﻟﻴﻪ‪ ،‬آدرس ‪ IP‬ﻣﺒﺪأ‪ ،‬ﮔﻮاﻫﻴﻨﺎﻣﻪ ﻫﺎي ‪ SSL‬ﻳﺎ اﻋﺘﺒﺎرﻧﺎﻣﻪﻫﺎي داﻣﻨﻪ وﻳﻨﺪوز اﺳﺘﻨﺎد ﻣﻲﻛﻨﻨﺪ‪.‬‬ ‫اﻳﻦ آﺳﻴﺐ ﭘﺬﻳﺮي ﺑﻪ ﻧﺎم ﻫﺎي دﻳﮕﺮ ﻣﺎﻧﻨﺪ ‪ ، Session Riding‬ﺣﻤﻼت ‪، Cross Site Reference Forgery ،One–Click‬‬ ‫‪ Hostile Linking‬و ﺣﻤﻠﻪ ‪ Automation‬ﻧﻴﺰ ﺷﻨﺎﺧﺘﻪ ﻣﻲﺷﻮد‪ .‬ﻣﺨﻔﻒ ‪ XSRF‬ﻧﻴﺰ ﻣﻌﻤﻮﻻ در ﻣﻮرد آن ﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار‬ ‫ﻣﻲ ﮔﻴﺮد‪ OWASP .‬و ‪ MITRE‬ﻫﺮ دو اﺻﻄﻼح اﺳﺘﺎﻧﺪارد ‪ Cross Site Request Forgery‬و ‪ CSRF‬را ﺑﺮﮔﺰﻳﺪﻧﺪ‪.‬‬

‫ﻣﺤﻴﻂ ﻫﺎي ﻣﺘﺎﺛﺮ‬ ‫ﺗﻤﺎﻣﻲ ﻧﺮماﻓﺰارﻫﺎي ﺗﺤﺖ وب در ﺑﺮاﺑﺮ ‪ CSRF‬آﺳﻴﺐﭘﺬﻳﺮ ﻫﺴﺘﻨﺪ‪.‬‬

‫آﺳﻴﺐ ﭘﺬﻳﺮي‬ ‫ﺣﻤﻠﻪ ‪ CSRF‬در ﻣﻮاﺟﻬﻪ ﺑﺎ ﻳﻚ ‪ Forum‬ﻣﻌﻤﻮﻻ روش ﻫﺪاﻳﺖ ﻛﺎرﺑﺮ را ﺑﺮاي درﺧﻮاﺳﺖ ﺑﺴﻴﺎري از ﺗﻮاﺑﻊ ﺑﻜﺎر ﻣﻲ ﮔﻴﺮد‪ ،‬ﻣﺎﻧﻨـﺪ‬ ‫درﺧﻮاﺳﺖ ﺻﻔﺤﻪ ‪ logout‬در ﻧﺮم اﻓﺰار‪ Tag .‬زﻳﺮ در ﻫﻤﻪ ﺻﻔﺤﺎت وب ﺗﻮﺳﻂ ﻗﺮﺑﺎﻧﻲ دﻳﺪه ﻣﻲ ﺷﻮد ﻛـﻪ ﺑـﻪ ﺗﻮﻟﻴـﺪ درﺧﻮاﺳـﺖ‬ ‫ﺑﺮاي ‪ logout‬ﻣﻨﺠﺮ ﻣﻲ ﮔﺮدد‪.‬‬ ‫>"‪"‪&toAcct=4345754&toSWIFTid=434343&amt=3434.43‬‬ ‫ﺟِﺮِﻣﻲ ﮔِﺮاﺳﻤ‪‬ﻦ )‪ (Jeremiah Grossman‬در ﻛﺘﺎب ‪ BlackHat‬در ﺳﺎل ‪ 2006‬ﺑﺎ ﻋﻨﻮان‪» :‬ﻫﻚ ﻛﺮدن ﺳﺎﻳﺖ ﻫﺎي اﻳﻨﺘﺮاﻧـﺖ از‬ ‫ﺧﺎرج« )‪ (Hacking Intranet Sites from the outside‬ﻧﺸﺎن ﻣﻲ دﻫﺪ ﻛﻪ اﺟﺒﺎر ﻛﺎرﺑﺮ ﺑﺮاي اﻧﺠـﺎم ﺗﻐﻴﻴـﺮات در ﻣـﺴﻴﺮﻳﺎب‬ ‫‪ DSL‬ﺑﺪون رﺿﺎﻳﺖ وي ﺣﺘﻲ اﮔﺮ ﻛﺎرﺑﺮ ﻧﺪاﻧﺪ ﻛﻪ ﻣﺴﻴﺮﻳﺎب ‪ DSL‬ﻳﻚ واﺳﻂ )‪ (interface‬وب دارد‪ ،‬اﻣﻜـﺎن ﭘـﺬﻳﺮ ﻣـﻲ ﺑﺎﺷـﺪ‪.‬‬ ‫ﺟِﺮِﻣﻲ از ﻧﺎم ﭘﻴﺶ ﻓﺮض ﻣﺴﻴﺮ ﻳﺎب ﺑﺮاي اﻧﺠﺎم ﺣﻤﻠﻪ اﺳﺘﻔﺎده ﻛﺮد‪.‬‬ ‫ﺗﻤﺎم اﻳﻦ ﺣﻤﻼت ﺑﻪ اﻳﻦ دﻟﻴﻞ ﻛﻪ اﻋﺘﺒﺎرﻧﺎﻣﻪ اﺣﺮازﻫﻮﻳﺖ ﻛﺎرﺑﺮ )ﻣﻌﻤﻮﻻً ﻛﻮﻛﻲ ﻧﺸﺴﺖ( ﺑﻪ ﻃﻮر ﺧﻮدﻛـﺎر از ﻃﺮﻳـﻖ ﻣﺮورﮔـﺮ ﺷـﺎﻣﻞ‬ ‫اﻳﻨﮕﻮﻧﻪ درﺧﻮاﺳﺖ ﻫﺎ ﻣﻲ ﺷﻮﻧﺪ‪ ،‬در ﺻﻮرت ﻋﺪم اﺳﺘﻔﺎده ﻣﻬﺎﺟﻢ از اﻋﺘﺒﺎرﻧﺎﻣﻪ ﻗﺎﺑﻞ اﺟﺮا ﺧﻮاﻫﺪ ﺑﻮد‪.‬‬ ‫اﮔﺮ ‪ tag‬در ﺑﺮدارﻧﺪه ﺣﻤﻠﻪ ﺑﺘﻮاﻧﺪ ﺑﻪ ﻧﺮم اﻓﺰار آﺳﻴﺐ ﭘﺬﻳﺮ ﻓﺮﺳﺘﺎده ﺷﻮد ﭘﺲ اﺣﺘﻤﺎل ﻳـﺎﻓﺘﻦ ﻗﺮﺑـﺎﻧﻲ وارد ﺷـﺪه )‪ (logged in‬ﺑـﻪ‬ ‫ﺷﻜﻞ ﻗﺎﺑﻞ ﺗﻮﺟﻬﻲ اﻓﺰاﻳﺶ ﭘﻴﺪا ﻣﻲ ﻛﻨﺪ‪ .‬ﻣﺎﻧﻨﺪ اﻓﺰاﻳﺶ ﺧﻄﺮ ﺑﻴﻦ ﺿﻌﻒ ﻫﺎي ‪ stored XSS‬و ‪ . reflected XSS‬ﺿـﻌﻒ ﻫـﺎي‬ ‫‪ XSS‬ﺑﺮاي اﺟﺮا ﺷﺪن ﺑﻪ ﺣﻤﻠﻪ ‪ CSRF‬اﺣﺘﻴﺎج ﻧﺪارﻧﺪ‪ .‬اﮔﺮﭼﻪ ﻫﺮ ﻧﺮم اﻓﺰاري ﺑﺎ ﺿﻌﻒ ﻫﺎي ‪ XSS‬ﻣﺴﺘﻌﺪ ﺣﻤﻠـﻪ ‪ CSRF‬اﺳـﺖ‬ ‫وﻟﻲ ﺣﻤﻠﻪ ‪ CSRF‬ﻣﻲ ﺗﻮاﻧﺪ از ﺿﻌﻒ ‪ XSS‬ﺑﺮاي ﺳﺮﻗﺖ اﻋﺘﺒﺎرﻧﺎﻣﻪ ﻫﺎي ﻏﻴﺮﺧﻮدﻛﺎر ﻛﻪ ﺑﺮاي ﻣﺤﺎﻓﻈﺖ در ﺑﺮاﺑﺮ ﺣﻤﻠـﻪ ‪CSRF‬‬ ‫در ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﻣﻲ ﺷﻮﻧﺪ‪ ،‬ﺑﻬﺮه ﺑﺮداري )‪ (Exploit‬ﻛﻨﺪ‪ .‬ﺑﺴﻴﺎري از ‪ worm‬ﻫﺎي ﻧﺮم اﻓﺰاري از ﻫﺮ دو ﺗﻜﻨﻴﻚ ﺑـﻪ ﺻـﻮرت ﺗﺮﻛﻴﺒـﻲ‬ ‫اﺳﺘﻔﺎده ﻣﻲ ﻛﻨﻨﺪ‪.‬‬ ‫ﻫﻨﮕﺎم دﻓﺎع در ﻣﻘﺎﺑﻞ ﺣﻤﻼت ‪ CSRF‬ﻣﻲ ﺑﺎﻳﺴﺖ ﺑﺮ ﺣﺬف آﺳﻴﺐ ﭘﺬﻳﺮي ﻫـﺎي ‪ XSS‬در ﻧـﺮم اﻓـﺰار ﺗـﺎ زﻣـﺎن ﺑﻜـﺎرﮔﻴﺮي اﻳـﻦ‬ ‫ﺿﻌﻒ ﻫﺎ ﺑﺮاي ﻋﺒﻮر از ﺣﻔﺎظ ﻫﺎي ‪ XSS‬ﺑﻜﺎر رﻓﺘﻪ در ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﺷﻮﻧﺪ‪.‬‬

‫ﺑﺮرﺳﻲ اﻣﻨﻴﺖ‬ ‫ﻫﺪف‪ ،‬ﻣﺤﺎﻓﻈﺖ از ﻧﺮم اﻓﺰار در ﻣﻘﺎﺑﻞ ﺣﻤﻼت ‪ CSRF‬ﺑﻮﺳﻴﻠﻪ ﺗﻮﻟﻴـﺪ و ﺳـﭙﺲ ﻣﻄﺎﻟﺒـﻪ ﺑﺮﺧـﻲ از اﻧـﻮاع ﻧـﺸﺎﻧﻪ ﻫـﺎي )‪(tokens‬‬ ‫اﺣﺮازﻫﻮﻳﺖ اﺳﺖ ﻛﻪ از ﻃﺮﻳﻖ ﻣﺮورﮔﺮ ﺑﻪ ﺷﻜﻞ ﺧﻮدﻛﺎر اراﺋﻪ ﻧﻤﻲ ﺷﻮد‪.‬‬ ‫روش ﻫﺎي ﺧﻮدﻛﺎر‪ :‬اﻣﺮوزه‪ ،‬ﺗﻌﺪاد ﻛﻤﻲ از ﭘﻮﻳﺸﮕﺮﻫﺎي ﺧﻮدﻛﺎر ﻣﻲ ﺗﻮاﻧﻨﺪ آﺳﻴﺐ ﭘﺬﻳﺮي ﻫﺎي ‪ CSRF‬را ﻛﺸﻒ ﻛﻨﻨـﺪ‪ .‬اﮔـﺮ ﭼـﻪ‬ ‫ﻛﺸﻒ ﺿﻌﻒ ﻫﺎي ‪ CSRF‬ﺑﺮاي ﻣﻮﺗﻮرﻫﺎي ﭘﻮﻳﺸﮕﺮ ﻛﻪ ﺑﻪ ﻗﺪر ﻛﺎﻓﻲ در ﺗﺸﺨﻴﺺ اﻳﻦ ﺿﻌﻒ ﺗﻮاﻧﺎ ﻫﺴﺘﻨﺪ‪ ،‬ﻣﻤﻜﻦ ﻣﻲ ﺑﺎﺷﺪ اﻣﺎ اﮔﺮ‬

‫‪٢٦‬‬

‫‪OWASP Top 10 2007‬‬

‫ﭘﻮﻳﺸﮕﺮ ﻧﺮم اﻓﺰار ﻳﻚ آﺳﻴﺐ ﭘﺬﻳﺮي ‪ XSS‬را ﭘﻴﺪا ﻛﺮده و در ﻣﻘﺎﺑﻞ از ﺣﻔﺎظ ﺿﺪ ‪ (Anti-CSRF) CSRF‬اﺳﺘﻔﺎده ﻧﻜﺮده ﺑﺎﺷـﺪ‪،‬‬ ‫اﺣﺘﻤﺎل ﺑﻪ ﺧﻄﺮ اﻓﺘﺎدن آن ﺗﻮﺳﻂ ﺣﻤﻼت از ﭘﻴﺶ آﻣﺎده ‪ CSRF‬اﻓﺰاﻳﺶ ﭘﻴﺪا ﻣﻲ ﻛﻨﺪ‪.‬‬ ‫روش ﻫﺎي دﺳﺘﻲ‪ :‬آزﻣﺎﻳﺶ ﻧﻔﻮذﭘﺬﻳﺮي روﺷﻲ ﺳﺮﻳﻊ ﺑﺮاي ﺗﻌﻴﻴﻦ دﻓﺎع ﻣﻨﺎﺳﺐ در ﻣﻘﺎﺑﻞ ‪ CSRF‬ﻣﻲ ﺑﺎﺷﺪ‪ .‬ﺑﺮاي ﺗﻌﻴﻴﻦ ﻣﻜـﺎﻧﻴﺰﻣﻲ‬ ‫ﻛﻪ ﺑﻪ ﺷﻜﻞ ﺻﺤﻴﺢ و ﻗﺪرﺗﻤﻨﺪ ﭘﻴﺎده ﺳﺎزي ﺷﺪه ﺑﺎﺷﺪ‪ ،‬ﺑﺮرﺳﻲ ﻛﺪ)ﺑﺮﻧﺎﻣﻪ( ﻣﺆﺛﺮﺗﺮﻳﻦ روش اﺳﺖ‪.‬‬

‫ﻣﺤﺎﻓﻈﺖ‬ ‫ﻧﺮم اﻓﺰارﻫﺎ ﻧﺒﺎﻳﺪ ﺑﻪ اﻋﺘﺒﺎرﻧﺎﻣﻪ ﻫﺎ ﻳﺎ ﻧﺸﺎﻧﻪ ﻫﺎﻳﻲ)‪ (Token‬ﻛﻪ ﺑﻪ ﺻﻮرت ﺧﻮدﻛﺎر از ﻃﺮﻳﻖ ﻣﺮورﮔﺮ اراﺋﻪ ﻣﻲ ﺷﻮﻧﺪ اﺳﺘﻨﺎد ﻛﻨﻨﺪ‪ .‬ﺗﻨﻬـﺎ‬ ‫راه ﺣﻞ‪ ،‬اﺳﺘﻔﺎده از ﻧﺸﺎﻧﻪ ﺳﻔﺎرﺷﻲ )‪ (custom Token‬اﺳﺖ ﻛﻪ ﻣﺮورﮔﺮ آن را ﺑﻪ ﺧﺎﻃﺮ ﻧﻴﺎورد و ﺑﻪ ﺷﻜﻞ ﺧﻮدﻛـﺎر دﭼـﺎر ﺣﻤﻠـﻪ‬ ‫‪ CSRF‬ﻧﮕﺮدد‪.‬‬ ‫اﺳﺘﺮاﺗﮋي ﻫﺎي زﻳﺮ ﺑﺎﻳﺪ در ﺗﻤﺎﻣﻲ ﻧﺮم اﻓﺰارﻫﺎ ﻧﻬﺎدﻳﻨﻪ ﺷﻮد‪:‬‬ ‫ƒ‬

‫از ﻋﺪم وﺟﻮد آﺳﻴﺐ ﭘﺬﻳﺮي ‪ XSS‬در ﻧﺮم اﻓﺰارﻫﺎ ﻣﻄﻤﺌﻦ ﺷﻮﻳﺪ‪.‬‬

‫ƒ‬

‫از ﻧﺸﺎﻧﻪ ﻫﺎي ﺳﻔﺎرﺷﻲ ﺗﺼﺎدﻓﻲ )‪ (custom random tokens‬در ﻓﺮم ﻫﺎ و ‪ URL‬ﻫﺎﻳﻲ ﻛﻪ ﺑﻮﺳﻴﻠﻪ ﻣﺮورﮔﺮ ﺑـﻪ ﻃـﻮر‬ ‫ﺧﻮدﻛﺎر اراﺋﻪ ﻧﻤﻲ ﺷﻮﻧﺪ‪ ،‬اﺳﺘﻔﺎده ﻧﻤﺎﻳﻴﺪ‪ .‬ﻣﺎﻧﻨﺪ‪:‬‬ ‫>"‪

٢٨

‫‪OWASP Top 10 2007‬‬

‫ﻧﺸﺖ اﻃﻼﻋﺎت و ﻣﺪﻳﺮﻳﺖ ﻧﺎدرﺳﺖ ﺧﻄﺎ‬ ‫‪A6 – INFORMATION LEAKAGE AND IMPROPER ERROR HANDLING‬‬ ‫ﻧﺮماﻓﺰارﻫﺎ ﻣﻲﺗﻮاﻧﻨﺪ ﺑﻪ ﻃﻮر ﻏﻴﺮﻋﻤﺪي ﻧَﺸﺖ اﻃﻼﻋﺎت درﺑﺎره ﭘﻴﻜﺮﺑﻨﺪي‪ ،‬ﻃﺮز ﻛـﺎر داﺧﻠـﻲ ﻳـﺎ ﻧﻘـﺺ ﺣـﺮﻳﻢ ﺧـﺼﻮﺻﻲ ﺑـﻪ دﻟﻴـﻞ‬ ‫ﻣﺸﻜﻼت ﻣﺨﺘﻠﻒ ﻧﺮماﻓﺰار را داﺷﺘﻪ ﺑﺎﺷﺪ‪ .‬ﻫﻤﭽﻨﻴﻦ ﺑﺮﻧﺎﻣﻪﻫﺎ ﻣﻲﺗﻮاﻧﻨﺪ وﺿـﻌﻴﺖ دروﻧـﻲ ﺧـﻮد را از ﻃﺮﻳـﻖ ﻣـﺪت زﻣـﺎن ﭘـﺮدازش‬ ‫ﻋﻤﻠﻴﺎت ﻫﺎي ﻣﻌﻴﻦ ﻳﺎ دادن ﭘﺎﺳﺦ ﻫﺎي ﻣﺘﻔﺎوت ﺑﻪ وروديﻫﺎي ﻣﺨﺘﻠﻒ از ﻗﺒﻴﻞ ﻧﻤﺎﻳﺶ ﻣﺘﻦ ﺧﻄـﺎي ﻳﻜـﺴﺎن ﺑـﺎ ﺷـﻤﺎره ﺧﻄـﺎ ﻫـﺎي‬ ‫ﻣﺨﺘﻠﻒ‪ ،‬ﻓﺎش ﻛﻨﻨﺪ‪ .‬ﻧﺮم اﻓﺰارﻫﺎي ﺗﺤﺖ وب ﻣﻜﺮرا اﻃﻼﻋﺎت وﺿﻌﻴﺖ دروﻧﻲ ﺧﻮد را از ﻃﺮﻳﻖ ﭘﻴﻐﺎمﻫﺎي ﭘﺮﺟﺰﺋﻴـﺎت ﻳـﺎ ﺧﻄﺎﻫـﺎي‬ ‫اﺷﻜﺎل زداﻳﻲ )‪ (debug‬ﻓﺎش ﻣﻲ ﻛﻨﻨﺪ‪ .‬اﻏﻠﺐ اوﻗﺎت اﻳﻦ اﻃﻼﻋﺎت ﺷﻴﻮه اي ﺑﺮاي آﻏﺎز ﻳﺎ ﺣﺘﻲ ﺑﻜـﺎر اﻧـﺪاﺧﺘﻦ ﺣﻤـﻼت ﺧﻮدﻛـﺎر‬ ‫ﻗﺪرﺗﻤﻨﺪﺗﺮ را اراﺋﻪ ﻣﻲ دﻫﺪ‪.‬‬

‫ﻣﺤﻴﻂ ﻫﺎي ﻣﺘﺎﺛﺮ‬ ‫ﺗﻤﺎم ﺳﺎﺧﺘﺎرﻫﺎي ﻣﺨﺘﻠﻒ ﻧﺮماﻓﺰارﻫﺎي ﺗﺤﺖ وب در ﺑﺮاﺑﺮ ﻧﺸﺖ اﻃﻼﻋﺎت و ﻣﺪﻳﺮﻳﺖ ﻧﺎدرﺳﺖ ﺧﻄﺎ آﺳﻴﺐﭘﺬﻳﺮ ﻫﺴﺘﻨﺪ‪.‬‬

‫آﺳﻴﺐ ﭘﺬﻳﺮي‬ ‫ﻧﺮماﻓﺰارﻫﺎ ﻣﻜﺮراً ﭘﻴﻐﺎمﻫﺎي ﺧﻄﺎ را ﺗﻮﻟﻴﺪ ﻛﺮده و ﺑﻪ ﻛﺎرﺑﺮان ﻧﻤﺎﻳﺶ ﻣﻲدﻫﻨﺪ‪ .‬اﻳﻦ ﭘﻴﻐـﺎمﻫـﺎي ﺧﻄـﺎ ﺑﺨـﻮﺑﻲ ﺑـﺮاي ﻣﻬـﺎﺟﻤﻴﻦ ﻣﻔﻴـﺪ‬ ‫ﻫﺴﺘﻨﺪ‪ .‬ﺑﻄﻮرﻳﻜﻪ آﻧﻬﺎ ﺟﺰﺋﻴﺎت ﭘﻴﺎدهﺳﺎزي ﻳﺎ اﻃﻼﻋﺎﺗﻲ را ﻛﻪ ﺑﺮاي اﺳﺘﻔﺎده از ﻳﻚ آﺳﻴﺐﭘﺬﻳﺮي ﻣﻔﻴﺪ اﺳﺖ آﺷﻜﺎر ﻣﻲ ﻛﻨﻨﺪ‪ .‬در اﻳﻨﺠﺎ‬ ‫ﺑﻪ ذﻛﺮ ﭼﻨﺪ ﻣﺜﺎل اﺷﺎره ﻣﻲ ﻛﻨﻴﻢ‪:‬‬ ‫ƒ ﻣﺪﻳﺮﻳﺖ ﺧﻄﺎي ﺗﻔﺼﻴﻠﻲ و ﭘﺮ از ﺟﺰﺋﻴﺎت‪ ،‬ﻛﻪ اﻃﻼﻋﺎﺗﻲ ﺑﻴﺶ از اﻧﺪازه ﻣﺎﻧﻨـﺪ ﺗـﻮاﻟﻲ ﭘـﺸﺘﻪﻫـﺎ )‪ ،(stack traces‬دﺳـﺘﻮرات‬ ‫ﻧﺎﻣﻮﻓﻖ ‪ SQL‬ﻳﺎ ﺳﺎﻳﺮ اﻃﻼﻋﺎت اﺷﻜﺎل زداﻳﻲ )‪ (debugging‬را ﻧﺸﺎن ﻣﻲ دﻫﺪ‪.‬‬ ‫ƒ ﻋﻤﻠﻜﺮدﻫﺎﻳﻲ ﻛﻪ ﺑﺮ ﻣﺒﻨﺎي وروديﻫﺎي ﻣﺨﺘﻠﻒ‪ ،‬ﻧﺘﺎﻳﺞ ﻣﺘﻔﺎوﺗﻲ را ﺗﻮﻟﻴﺪ ﻣﻲﻛﻨﻨﺪ‪ .‬ﻣﺎﻧﻨـﺪ ﭘـﺸﺘﻴﺒﺎﻧﻲ از ﻧـﺎم ﻛـﺎرﺑﺮي ﻳﻜـﺴﺎن ﺑـﺎ‬ ‫رﻣﺰﻫﺎي ﻋﺒﻮر ﻣﺨﺘﻠﻒ ﺑﺮاي ﻋﻤﻠﻴﺎت ورود ﺑﻪ ﺳﻴﺴﺘﻢ )‪ (login‬ﻣﻲ ﺑﺎﻳﺴﺖ ﺑﺮاي ﻛﺎرﺑﺮان ﻣﺘﻔﺎوت و ﻫﻤﭽﻨﻴﻦ در ﻣﻮرد ﻛﻠﻤﺎت‬ ‫ﻋﺒﻮر ﻣﺘﻔﺎوت ﻣﺘﻦ ﻳﻜﺴﺎﻧﻲ را ﺗﻮﻟﻴﺪ ﻛﻨﺪ‪ .‬ﻫﺮﭼﻨﺪ ﺑﺴﻴﺎري از ﺳﻴﺴﺘﻢ ﻫﺎ ﻛﺪﻫﺎي ﺧﻄﺎي ﻣﺘﻔﺎوﺗﻲ را ﺗﻮﻟﻴﺪ ﻣﻲﻛﻨﻨﺪ‪.‬‬

‫ﺑﺮرﺳﻲ اﻣﻨﻴﺖ‬ ‫ﻫﺪف‪ ،‬ﺑﺮرﺳﻲ ﻧﺮم اﻓﺰار از ﻟﺤﺎظ ﻋﺪم اﻓﺸﺎي اﻃﻼﻋﺎت از ﻃﺮﻳﻖ ﭘﻴﻐﺎمﻫﺎي ﺧﻄﺎ ﻳﺎ روش ﻫﺎي دﻳﮕﺮ اﺳﺖ‪.‬‬ ‫‪.‬روشﻫﺎي ﺧﻮدﻛﺎر‪ :‬اﺑﺰارﻫﺎي ﭘﻮﻳﺶ آﺳﻴﺐﭘﺬﻳﺮي ﻣﻌﻤﻮﻻً ﺑﺎﻋﺚ ﺗﻮﻟﻴﺪ ﭘﻴﻐﺎمﻫﺎي ﺧﻄﺎ ﻣﻲ ﺷﻮﻧﺪ‪ .‬اﺑﺰارﻫﺎي ﺗﺤﻠﻴﻞ اﻳﺴﺘﺎ ﻣـﻲﺗﻮاﻧﻨـﺪ‬ ‫اﺳﺘﻔﺎده از ‪ API‬ﻫﺎﻳﻲ را ﻛﻪ ﻣﻮﺟﺐ اﻓﺸﺎء اﻃﻼﻋﺎت ﻣﻲﺷﻮﻧﺪ را ﺟﺴﺘﺠﻮ ﻛﻨﻨﺪ اﻣﺎ ﻗﺎدر ﺑﻪ ﺑﺮرﺳﻲ ﻣﻌﺎﻧﻲ ﭘﻴﻐﺎمﻫﺎ ﻧﻴﺴﺘﻨﺪ‪.‬‬

‫‪٢٩‬‬

‫روشﻫﺎي دﺳﺘﻲ‪ :‬ﺑﺮرﺳﻲ ﻛﺪ )‪ (code review‬ﻣﻲﺗﻮاﻧـﺪ ﻣـﺪﻳﺮﻳﺖ ﻧﺎﻣﻨﺎﺳـﺐ ﺧﻄـﺎ و اﻟﮕﻮﻫـﺎﻳﻲ را ﻛـﻪ ﺑﺎﻋـﺚ ﻧـﺸﺖ اﻃﻼﻋـﺎت‬ ‫ﻣﻲ ﺷﻮﻧﺪ را ﺟﺴﺘﺠﻮ ﻛﻨﺪ اﻣﺎ اﻳﻦ ﻛﺎر ﺑﺴﻴﺎر زﻣﺎن ﺑﺮ ﺧﻮاﻫﺪ ﺑﻮد‪ .‬آزﻣﺎﻳﺶ ﻧﻴﺰ ﭘﻴﻐﺎم ﻫﺎي ﺧﻄﺎﻳﻲ را ﺗﻮﻟﻴﺪ ﻣﻲﻛﻨﺪ اﻣـﺎ ﻓﻬﻤﻴـﺪن اﻳﻨﻜـﻪ‬ ‫ﻛﺪام ﻣﺴﻴﺮﻫﺎي ﺧﻄﺎ ﭘﻮﺷﺶ داده ﺷﺪهاﻧﺪ‪ ،‬آﻏﺎز رﻗﺎﺑﺖ ﺗﺎزهاي اﺳﺖ‪.‬‬

‫ﻣﺤﺎﻓﻈﺖ‬ ‫ﺑﺮﻧﺎﻣﻪﻧﻮﻳﺴﺎن وب ﺑﺎﻳﺪ از اﺑﺰارﻫﺎﻳﻲ ﻣﺎﻧﻨﺪ ‪ web scarab‬ﺳﺎﻳﺖ ‪ OWASP‬ﺑﺮاي اﻣﺘﺤﺎن ﺗﻮﻟﻴﺪ ﭘﻴﻐﺎمﻫﺎي ﺧﻄـﺎ در ﻧـﺮم اﻓﺰارﻫـﺎي‬ ‫ﺗﺤﺖ وب ﺧﻮد اﺳﺘﻔﺎده ﻛﻨﻨﺪ‪ .‬ﻧﺮم اﻓﺰارﻫﺎﻳﻲ ﻛﻪ ﺑﻪ اﻳﻦ روش آزﻣﺎﻳﺶ ﻧﺸﺪهاﻧﺪ ﻣﻄﻤﺌﻨﺎً ﺧﻄﺎي ﻏﻴﺮﻣﻨﺘﻈﺮه اي را ﺗﻮﻟﻴﺪ ﺧﻮاﻫﻨـﺪ ﻛـﺮد‪.‬‬ ‫ﻧﺮم اﻓﺰارﻫﺎ ﺑﺎﻳﺪ درﺑﺮدارﻧﺪه ﻣﻌﻤـﺎري اﺳـﺘﺎﻧﺪارد اﺳـﺘﺜﻨﺎﮔﺮداﻧﻲ )‪ (exception handling‬ﺑـﺮاي ﺟﻠـﻮﮔﻴﺮي از اﻓـﺸﺎي ﻧﺎﺧﻮاﺳـﺘﻪ‬ ‫اﻃﻼﻋﺎت ﺑﻪ ﻣﻬﺎﺟﻤﻴﻦ ﺑﺎﺷﻨﺪ‪.‬‬ ‫ﭘﻴﮕﺸﻴﺮي از اﻓﺸﺎي اﻃﻼﻋﺎت ﻣﺴﺘﻠﺰم رﻋﺎﻳﺖ ﻧﻈﻢ ﺧﺎﺻﻲ )‪ (discipline‬اﺳﺖ‪ .‬ﻣﺮاﺣﻞ زﻳﺮ ﺑﻪ ﻃﻮر ﻣﻮﺛﺮ آزﻣﺎﻳﺶ ﺷﺪهاﻧﺪ‪:‬‬ ‫ƒ‬

‫از اﻳﻨﻜﻪ ﻫﻤﻪ اﻓﺮاد ﮔﺮوه ﺑﺮﻧﺎﻣﻪﻧﻮﻳﺴﻲ ﻧﺮماﻓﺰار‪ ،‬در اﺟﺮاي روش ﻫﺎي ﻋﻤﻮﻣﻲ اﺳﺘﺜﻨﺎء ﮔﺮداﻧﻲ ﺳﻬﻴﻢ ﻫﺴﺘﻨﺪ‪ ،‬ﻣﻄﻤﺌﻦ ﺷﻮﻳﺪ‪.‬‬

‫ƒ‬

‫ﻣﺪﻳﺮﻳﺖ ﺧﻄﺎي ﺗﻔﺼﻴﻠﻲ )‪ (detailed error handling‬را ﻏﻴﺮﻓﻌﺎل ﻳﺎ ﻣﺤﺪود ﻛﻨﻴﺪ‪ .‬ﺑـﻮﻳﮋه اﻃﻼﻋـﺎت اﺷـﻜﺎل زداﻳـﻲ‪،‬‬ ‫ﺗﻮاﻟﻲ ﭘﺸﺘﻪﻫﺎ )‪ (stack traces‬ﻳﺎ اﻃﻼﻋﺎت ﻣﺴﻴﺮ را ﺑﻪ ﻛﺎرﺑﺮان ﻧﻬﺎﻳﻲ ﻧﻤﺎﻳﺶ ﻧﺪﻫﻴﺪ‪.‬‬

‫ƒ‬

‫اﻃﻤﻴﻨﺎن ﭘﻴﺪا ﻛﻨﻴﺪ ﻛﻪ ﻣﺴﻴﺮﻫﺎي اﻣﻦ ﻛﻪ ﺧﺮوﺟﻲ ﭼﻨﺪﮔﺎﻧﻪ دارﻧﺪ ﭘﻴﻐﺎم ﻫﺎي ﺧﻄﺎي ﻳﻜـﺴﺎن ﻳـﺎ ﻣـﺸﺎﺑﻪ و ﺗﻘﺮﻳﺒـﺎً در زﻣـﺎن‬ ‫ﻳﻜﺴﺎن را ﺑﺎزﮔﺮداﻧﻨﺪ‪ .‬در ﺻﻮرت ﻏﻴﺮﻣﻤﻜﻦ ﺑﻮدن اﻳﻦ روش از ﺑﺮﻗﺮاري زﻣﺎن اﻧﺘﻈﺎر ﺗﺼﺎدﻓﻲ ﺑﺮاي ﺗﻤﺎﻣﻲ ﺗـﺮاﻛﻨﺶﻫـﺎ ﺑـﻪ‬ ‫ﻣﻨﻈﻮر ﭘﻨﻬﺎن ﻛﺮدن ﺟﺰﺋﻴﺎت از ﻣﻬﺎﺟﻤﻴﻦ اﺳﺘﻔﺎده ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫ﻻﻳﻪﻫﺎي ﻣﺨﺘﻠﻒ ﻣﺎﻧﻨﺪ ﻻﻳﻪ ﭘﺎﻳﮕﺎه داده‪ ،‬ﺳﺮوﻳﺲ دﻫﻨﺪه وب اﺻﻠﻲ )‪ Apache, IIS‬و ﻏﻴﺮه( ﻣﻤﻜﻦ اﺳﺖ ﻧﺘـﺎﻳﺞ ﻣﺨـﺮب‬ ‫ﻳﺎ اﺳﺘﺜﻨﺎﻳﻲ را ﺑﺎزﮔﺮداﻧﺪ‪ .‬ﺑﺮرﺳﻲ و ﭘﻴﻜﺮﺑﻨﺪي ﺧﻄﺎﻫﺎ در ﺗﻤﺎﻣﻲ ﻻﻳﻪﻫﺎ ﺑﻪ ﻣﻨﻈـﻮر ﭘﻴـﺸﮕﻴﺮي از ﺑﻬـﺮه ﺑـﺮداري)‪(Exploit‬‬ ‫ﭘﻴﻐﺎمﻫﺎي ﺧﻄﺎ ﺗﻮﺳﻂ ﻧﻔﻮذﮔﺮان ﺑﺴﻴﺎر ﻣﻬﻢ اﺳﺖ‪.‬‬

‫ƒ‬

‫ﺑﺪاﻧﻴﺪ ﻛﻪ ‪ framework‬ﻫﺎي راﻳﺞ ﺑﺮ ﺣﺴﺐ اﻳﻨﻜﻪ ﺧﻄﺎ در ﻛﺪ ﺳﻔﺎرﺷﻲ )‪ (custom‬ﺑﺎﺷﺪ ﻳﺎ داﺧﻞ ﻛﺪ ﺳﻴﺴﺘﻢ‪ ،‬ﻛﺪﻫﺎي‬ ‫ﺧﻄﺎي ‪ HTTP‬ﻣﺨﺘﻠﻔﻲ را ﺑﺮﻣﻲﮔﺮداﻧﻨﺪ‪ .‬اﻳﺠﺎد اداره ﻛﻨﻨﺪه ﭘﻴﺶ ﻓﺮض ﺧﻄﺎ ﺑﻪ ﻣﻨﻈﻮر ﺑﺎزﮔﺮداﻧـﺪن ﭘﻴﻐـﺎم ﺧﻄـﺎي ﻣﻄـﺎﺑﻖ‬ ‫ﻗﻮاﻧﻴﻦ ﺑﺮاي اﻛﺜﺮ ﻛﺎرﺑﺮان و ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻣﺴﻴﺮﻫﺎي ﺧﻄﺎ ارزﺷﻤﻨﺪ اﺳﺖ‪.‬‬

‫‪٣٠‬‬

OWASP Top 10 2007

‫ ﺗﻮاﻧﺎﻳﻲ اﺑﺰارﻫـﺎي ﭘـﻮﻳﺶ‬،‫( را ﺑﺮﻣﻲﮔﺮداﻧﺪ‬ok) "200" ‫اداره ﻛﻨﻨﺪه ﭘﻴﺶ ﻓﺮض ﺧﻄﺎ ﺑﺪﻟﻴﻞ اﻳﻨﻜﻪ ﻫﻤﻴﺸﻪ ﺻﻔﺤﺎت ﺧﻄﺎي‬

ƒ

‫ ﻣﺎداﻣﻲ ﻛﻪ اﻣﻨﻴﺖ از ﻃﺮﻳـﻖ‬.‫ﺧﻮدﻛﺎر را ﺑﺮاي ﺗﻌﻴﻴﻦ اﻳﻨﻜﻪ آﻳﺎ ﻳﻚ ﺧﻄﺎي ﺟﺪي اﺗﻔﺎق اﻓﺘﺎده اﺳﺖ ﻳﺎ ﺧﻴﺮ را ﻛﺎﻫﺶ ﻣﻲدﻫﺪ‬ .‫ ﺑﻪ ﻻﻳﻪ دﻓﺎﻋﻲ اﻓﺰونﺗﺮي را ﻧﻴﺎز اﺳﺖ‬،‫“ اراﺋﻪ ﻣﻲﺷﻮد‬security through obscurity" ‫اﺑﻬﺎم‬ ‫ اﻳﻦ روش ﺑﻪ‬.‫ﺑﺮﺧﻲ از ﺳﺎزﻣﺎن ﻫﺎي ﺑﺰرﮔﺘﺮ ﻛﺪﻫﺎي ﺧﻄﺎي ﺗﺼﺎدﻓﻲ ﻳﺎ ﻳﻜﺘﺎﻳﻲ را در ﻫﻤﻪ ﻧﺮم اﻓﺰارﻫﺎي ﺧﻮد ﻗﺮار ﻣﻲدﻫﻨﺪ‬

ƒ

‫ از ﻃﺮﻓـﻲ‬.‫( ﺑﺮاي ﭘﻴﺪا ﻛﺮدن راه ﺣﻠﻲ ﻣﻨﺎﺳﺐ ﺟﻬﺖ رﻓﻊ ﻳﻚ ﺧﻄﺎي ﺧـﺎص ﻛﻤـﻚ ﻛﻨـﺪ‬help desk) ‫ﺑﺨﺶ ﭘﺸﺘﻴﺒﺎﻧﻲ‬ .‫ﻣﻤﻜﻦ اﺳﺖ ﺑﻪ ﻣﻬﺎﺟﻤﻴﻦ روش دﻗﻴﻖ ﺷﻜﺴﺘﻦ ﻧﺮم اﻓﺰار را ﻫﻢ اراﺋﻪ دﻫﺪ‬

‫ﻧﻤﻮﻧﻪ ﻫﺎ‬ ƒ ƒ ƒ

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4899 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3389 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0580

‫ﻣﺮاﺟﻊ‬ ƒ ƒ ƒ ƒ

CWE: CWE-200 (Information Leak), CWE-203 (Discrepancy Information Leak), CWE-215 (Information Leak Through Debug Information), CWE-209 (Error Message Information Leak), others. WASC Threat Classification: http://www.webappsec.org/projects/threat/classes/information_leakage.shtml OWASP, http://www.owasp.org/index.php/Error_Handling OWASP, http://www.owasp.org/index.php/Category:Sensitive_Data_Protection_Vulnerability

٣١

‫اﺣﺮاز ﻫﻮﻳﺖ و ﻣﺪﻳﺮﻳﺖ ﻧﺸﺴﺖ ﻧﺎﻗﺺ‬ ‫‪A7 – BROKEN AUTHENTICATION AND SESSION MANAGEMENT‬‬ ‫اﺣﺮاز ﻫﻮﻳﺖ ﻣﻨﺎﺳﺐ و ﻣﺪﻳﺮﻳﺖ ﻧﺸﺴﺖ )‪ (session management‬در ﺟﻬﺖ ﺗﺎﻣﻴﻦ اﻣﻨﻴﺖ ﻧﺮم اﻓـﺰار ﻣـﺴﺌﻠﻪاي ﺑﺤﺮاﻧـﻲ اﺳـﺖ‪.‬‬ ‫ﺿﻌﻒﻫﺎي اﻳﻦ ﻧﺎﺣﻴﻪ اﻛﺜﺮا ﺷﺎﻣﻞ ﻋﺪم ﻣﻮﻓﻘﻴﺖ در ﺣﻔﺎﻇﺖ از اﻋﺘﺒﺎرﻧﺎﻣﻪﻫﺎ و ‪Token‬ﻫﺎي ﻧﺸﺴﺖ ﺑﻪ واﺳـﻄﻪ ﭼﺮﺧـﻪ ﺣﻴـﺎت آﻧﻬـﺎ‬ ‫اﺳﺖ‪ .‬اﻳﻦ ﺿﻌﻒﻫﺎ ﻣﻲ ﺗﻮاﻧﻨـﺪ ﻣﻨﺠـﺮ ﺑـﻪ ﺳـﺮﻗﺖ ﺣـﺴﺎب ﻫـﺎي ﻛـﺎرﺑﺮان ﻳـﺎ ﻣـﺪﻳﺮان )‪ ، (hijacking of accounts‬ﺗﺨﺮﻳـﺐ‬ ‫ﻣﺠﺎز ﺷﻤﺎري )‪ (undermine authorization‬و ﻛﻨﺘﺮل ﻫﺎي ﭘﺎﺳﺨﮕﻮﻳﻲ )‪ (accountability controls‬و ﺗﺠـﺎوز ﺑـﻪ ﺣـﺮﻳﻢ‬ ‫ﺧﺼﻮﺻﻲ )‪ (privacy violation‬ﺷﻮﻧﺪ‪.‬‬

‫ﻣﺤﻴﻂ ﻫﺎي ﻣﺘﺎﺛﺮ‬ ‫ﺗﻤﺎﻣﻲ ﻧﺮماﻓﺰارﻫﺎي ﺗﺤﺖ وب در ﺑﺮاﺑﺮ ﺿﻌﻒﻫﺎي ﻣﺪﻳﺮﻳﺖ ﻧﺸـﺴﺖ )‪ (session management‬و ﻣﺠﺎزﺷـﻤﺎري‪ ،‬آﺳـﻴﺐ ﭘـﺬﻳﺮ‬ ‫ﻫﺴﺘﻨﺪ‪.‬‬

‫آﺳﻴﺐ ﭘﺬﻳﺮي‬ ‫ﺿﻌﻒﻫﺎي ﻣﻮﺟﻮد در ﻣﻜﺎﻧﻴﺰم اﺻﻠﻲ اﺣﺮاز ﻫﻮﻳﺖ ﻏﻴﺮﻋﺎدي ﻧﻴﺴﺘﻨﺪ‪ ،‬اﻣﺎ ﺿﻌﻒﻫﺎ اﻏﻠﺐ اوﻗﺎت در ﻓﻌﺎﻟﻴﺖ ﻫﺎي اﺣﺮاز ﻫﻮﻳﺖ ﻓﺮﻋﻲ‬ ‫ﻣﺎﻧﻨﺪ ﺧﺮوج از ﺳﻴﺴﺘﻢ )‪ ،(logout‬ﻣﺪﻳﺮﻳﺖ رﻣﺰ ﻋﺒﻮر‪ ،‬ﺑﻪ ﭘﺎﻳﺎن رﺳﻴﺪن زﻣـﺎن )‪ ، (time out‬ﺑـﻪ ﻳـﺎدآوري )‪، (remember me‬‬ ‫ﺳﻮال ﻣﺤﺮﻣﺎﻧﻪ )‪ (secret question‬و ﺑﺮوزرﺳﺎﻧﻲ ﺣﺴﺎب ﻣﺮﺳﻮم ﻫﺴﺘﻨﺪ‪.‬‬

‫ﺑﺮرﺳﻲ اﻣﻨﻴﺖ‬ ‫ﻫﺪف‪ ،‬ﺑﺮرﺳﻲ اﻳﻦ ﻣﻮﺿﻮع اﺳﺖ ﻛﻪ ﻧﺮم اﻓﺰار ﺑﻪ درﺳﺘﻲ ﻛﺎرﺑﺮان را ﺗﺼﺪﻳﻖ ﻛﺮده و ﺑﺪرﺳﺘﻲ از ﻫﻮﻳﺖﻫﺎ و اﻋﺘﺒﺎرﻧﺎﻣﻪﻫـﺎي ﻛـﺎرﺑﺮان‬ ‫ﻣﺤﺎﻓﻈﺖ ﻛﻨﺪ‪.‬‬ ‫روشﻫﺎي ﺧﻮدﻛﺎر‪ :‬اﺑﺰارﻫﺎي ﭘﻮﻳﺶ آﺳﻴﺐﭘﺬﻳﺮي زﻣﺎن ﻫﺎي ﺑﺴﻴﺎر ﻣﺨﺘﻠﻔـﻲ را ﺑـﺮاي ﺗـﺸﺨﻴﺺ آﺳـﻴﺐﭘـﺬﻳﺮي ﻫـﺎ در اﻟﮕﻮﻫـﺎي‬ ‫ﻣﺪﻳﺮﻳﺖ ﻧﺸﺴﺖ و اﺣﺮاز ﻫﻮﻳﺖ ﺳﻔﺎرﺷـﻲ )‪ (custom authentication‬دارﻧـﺪ‪ .‬اﺑﺰارﻫـﺎي ﺗﺤﻠﻴـﻞ اﻳـﺴﺘﺎ ﻧﻴـﺰ ﺑـﺮاي ﺗـﺸﺨﻴﺺ‬ ‫ﻣﺸﻜﻼت ﻣﺪﻳﺮﻳﺖ ﻧﺸﺴﺖ و اﺣﺮاز ﻫﻮﻳﺖ در ﺑﺮﻧﺎﻣﻪ ﺳﻔﺎرﺷﻲ )‪ (custom code‬اﺳﺘﻔﺎده ﻧﻤﻲ ﺷﻮﻧﺪ‪.‬‬ ‫روشﻫﺎي دﺳﺘﻲ‪ :‬آزﻣﺎﻳﺶ و ﻣﺮور ﻛﺪ‪ ،‬ﺧـﺼﻮﺻﺎً ﺑﻄـﻮر ﺗﺮﻛﻴﺒـﻲ در ﺑﺮرﺳـﻲ درﺳـﺘﻲ ﭘﻴـﺎدهﺳـﺎزي ﺗـﺼﺪﻳﻖ‪ ،‬ﻣـﺪﻳﺮﻳﺖ ﻧﺸـﺴﺖ و‬ ‫ﻋﻤﻠﻜﺮدﻫﺎي ﻓﺮﻋﻲ ﻛﺎﻣﻼً ﻣﻮﺛﺮ اﺳﺖ‪.‬‬

‫‪٣٢‬‬

‫‪OWASP Top 10 2007‬‬

‫ﻣﺤﺎﻓﻈﺖ‬ ‫اﺣﺮاز ﻫﻮﻳﺖ ﺑﻪ ارﺗﺒﺎط اﻣﻦ و ذﺧﻴﺮهﺳﺎزي اﻋﺘﺒﺎرﻧﺎﻣﻪ اﺳﺘﻨﺎد ﻣﻲ ﻛﻨﺪ‪ .‬اﺑﺘـﺪا از اﻳﻨﻜـﻪ ‪ SSL‬ﺗﻨﻬـﺎ ﮔﺰﻳﻨـﻪ ﺑـﺮاي ﺗﻤـﺎم ﻗـﺴﻤﺖ ﻫـﺎي‬ ‫اﺣﺮازﻫﻮﻳﺖ ﺷﺪه ﻧﺮم اﻓﺰار اﺳﺖ )ﺑﺨﺶ ‪ -A9‬ارﺗﺒﺎﻃﺎت ﻣﺤﺎﻓﻈﺖ ﻧﺸﺪه را ﺑﺒﻴﻨﻴﺪ( و اﻳﻨﻜﻪ ﻫﻤﻪ اﻋﺘﺒﺎرﻧﺎﻣﻪﻫﺎ ﺑﻪ ﺷﻜﻞ ‪ hash‬ﺷﺪه ﻳـﺎ‬ ‫رﻣﺰ ﺷﺪه ذﺧﻴﺮه ﻣﻲﺷﻮد )ﺑﺨﺶ ‪ A8‬ـ ذﺧﻴﺮهﺳﺎزي ﻣﺤﺎﻓﻈﺖ ﻧﺸﺪه رﻣﺰﻧﮕﺎري را ﺑﺒﻴﻨﻴﺪ( اﻃﻤﻴﻨﺎن ﺣﺎﺻﻞ ﻛﻨﻴﺪ‪.‬‬ ‫ﭘﻴﺸﮕﻴﺮي از ﺿﻌﻒﻫﺎي ﺗﺼﺪﻳﻖ ﺑﻪ ﺑﺮﻧﺎﻣﻪرﻳﺰي دﻗﻴﻘﻲ ﻧﻴﺎز دارد‪ .‬از ﺟﻤﻠﻪ ﻣﻬﻤﺘﺮﻳﻦ ﻣﻼﺣﻈﺎت ﻣﻮارد زﻳﺮ اﺳﺖ‪:‬‬ ‫ƒ‬

‫ﻓﻘﻂ از ﻣﻜﺎﻧﻴﺰم ﻣﺪﻳﺮﻳﺖ ﻧﺸﺴﺖ دروﻧـﻲ )‪ (inbuilt session management mechanism‬اﺳـﺘﻔﺎده ﻛﻨﻴـﺪ‪ ،‬ﺗﺤـﺖ‬ ‫ﻫﻴﭻ ﺷﺮاﻳﻄﻲ اداره ﻛﻨﻨﺪه ﻫﺎي ﻧﺸﺴﺖ ﺛﺎﻧﻮﻳﻪ را ﻧﻨﻮﺷﺘﻪ و اﺳﺘﻔﺎده ﻧﻜﻨﻴﺪ‪.‬‬

‫ƒ‬

‫ﺗﻌﻴﻴﻦ ﻛﻨﻨﺪﮔﺎن ﻫﻮﻳﺖ ﻧﺸﺴﺖ ﺟﺪﻳﺪ‪ ،‬از ﭘﻴﺶ ﺗﻨﻈﻴﻢ ﺷﺪه ﻳﺎ ﻏﻴﺮ ﻣﻌﺘﺒﺮ را از ‪ URL‬ﻳـﺎ درﺧﻮاﺳـﺖ ﻧﭙﺬﻳﺮﻳـﺪ‪ .‬اﻳـﻦ ﻋﻤـﻞ‬ ‫ﺣﻤﻠﻪ ﺗﺜﺒﻴﺖ ﻧﺸﺴﺖ )‪ (session fixation attack‬ﻧﺎﻣﻴﺪه ﻣﻲﺷﻮد‪.‬‬

‫ƒ‬

‫ﻛﺪ ﻛﻮﻛﻲﻫﺎي ﺳﻔﺎرﺷﻲ )‪ (custom cookies‬را ﺑﺮاي ﻣﺪﻳﺮﻳﺖ ﻧﺸﺴﺖ ﻳﺎ اﺣﺮاز ﻫﻮﻳﺖ‪ ،‬ﻣﺤﺪود ﻳﺎ ﭘﺎك ﻛﻨﻴﺪ‪ .‬ﻣﺎﻧﻨﺪ ﻧﻮع‬ ‫ﺳﻮدﻣﻨﺪ ﻳﺎدآوري )‪ (remember me‬ﻳﺎ ﺛﺒـﺖ اﻧﻔـﺮادي ﺧـﺎﻧﮕﻲ ))‪ . (home grown single–sign on (sso‬اﻳـﻦ‬ ‫ﻋﻤﻞ ﺑﺮاي راهﺣﻞ ﻫﺎي اﺣﺮاز ﻫﻮﻳـﺖ واﺑـﺴﺘﻪ )‪ (federated authentication‬ﻳـﺎ ‪ SSO‬آزﻣـﺎﻳﺶ ﺷـﺪه ﻗـﻮي ﺑﻜـﺎر‬ ‫ﻧﻤﻲ رود‪.‬‬

‫ƒ‬

‫از ﻣﻜﺎﻧﻴﺰم اﺣﺮاز ﻫﻮﻳﺖ واﺣﺪ ﺑﺎ ﻗﺪرت ﻛﺎﻓﻲ و ﺗﻌﺪاد ﻓﺎﻛﺘﻮرﻫﺎي ﻣﻨﺎﺳﺐ اﺳﺘﻔﺎده ﻛﻨﻴﺪ‪ .‬از اﻳﻨﻜﻪ اﻳﻦ ﻣﻜﺎﻧﻴﺰم ﺑﻪ راﺣﺘﻲ در‬ ‫ﻣﻌﺮض ﺣﻤﻼت ‪ spoofing‬ﻳﺎ ‪ replay‬ﻗﺮار ﮔﻴﺮد‪ ،‬اﻃﻤﻴﻨﺎن ﺣﺎﺻﻞ ﻛﻨﻴﺪ‪ .‬اﻳﻦ ﻣﻜـﺎﻧﻴﺰم را ﭘﻴﭽﻴـﺪه ﻧـﺴﺎزﻳﺪ زﻳـﺮا ﻣﻤﻜـﻦ‬ ‫اﺳﺖ در ﺟﻬﺖ ﺣﻤﻠﻪ ﺑﻪ ﺧﻮدش ﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار ﮔﻴﺮد‪.‬‬

‫ƒ‬

‫اﺟﺎزه ﻧﺪﻫﻴﺪ ﻓﺮآﻳﻨﺪ ورود ﺑﻪ ﺳﻴﺴﺘﻢ )‪ (login‬از ﺻﻔﺤﻪ رﻣﺰﮔﺬاري ﻧﺸﺪه ﺷﺮوع ﺷﻮد‪ .‬ﻫﻤﻴﺸﻪ ﻓﺮآﻳﻨﺪ ‪ login‬را از ﺻﻔﺤﻪ‬ ‫دوم و رﻣﺰﮔﺬاري ﺷﺪه آﻏﺎز ﻛﺮده و ﺻﻔﺤﻪ را ﺑﻮﺳﻴﻠﻪ ‪ Token‬ﻧﺸﺴﺖ ﺟﺪﻳﺪ ﻳﺎ ﺗﺎزه ﺷـﺪه )‪ (fresh‬ﺑـﺮاي ﺟﻠـﻮﮔﻴﺮي از‬ ‫ﺳﺮﻗﺖ اﻋﺘﺒﺎرﻧﺎﻣﻪ ﻫﺎ و ‪ session‬ﻫﺎ ﻳﺎ ﺣﻤﻼت ‪ phishing‬و ﺣﻤﻼت ﺗﺜﺒﻴﺖ ﻧﺸﺴﺖ )‪ (session fixation‬رﻣﺰﻧﮕﺎري‬ ‫ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫اﺣﻴﺎء ﻧﺸﺴﺖ ﺟﺪﻳﺪ را ﺑﺮ اﺳﺎس اﺣﺮاز ﻫﻮﻳﺖ ﻣﻮﻓﻖ ﻳﺎ ﺗﻐﻴﻴﺮ ﺳﻄﺢ ﻣﺠﻮزﻫﺎ در ﻧﻈﺮ ﺑﮕﻴﺮﻳﺪ‪.‬‬

‫ƒ‬

‫ﻣﻄﻤﺌﻦ ﺷﻮﻳﺪ ﻫﺮ ﺻﻔﺤﻪ‪ ،‬ﻟﻴﻨﻚ ﺧﺮوج از ﺳﻴﺴﺘﻢ )‪ (logout‬را دارد‪ .‬ﺧﺮوج از ﺳﻴﺴﺘﻢ )‪ (logout‬ﺑﺎﻳـﺪ ﺗﻤـﺎﻣﻲ ﺟﺰﺋﻴـﺎت‬ ‫ﻧﺸﺴﺖ ﺳﻤﺖ ﺳﺮور )‪ (server side‬و ﻛﻮﻛﻲ ﻫﺎي ﺳﻤﺖ ﻛﺎرﺑﺮ )‪ (client side‬را ﭘﺎك ﻛﻨﺪ‪ .‬ﻋﻮاﻣﻞ اﻧﺴﺎﻧﻲ را در ﻧﻈﺮ‬

‫‪٣٣‬‬

‫ﺑﮕﻴﺮﻳﺪ‪ :‬ﭼﻨﺎﻧﭽﻪ ﻛﺎرﺑﺮان ﺑﻪ ﺟﺎي ﺧﺮوج ﻣﻮﻓﻘﻴﺖ آﻣﻴﺰ )‪ (logout‬از ﺳﻴﺴﺘﻢ ﺗﻨﻬﺎ ﺑﻪ ﺑـﺴﺘﻦ ﺑﺮﮔـﻪ )‪ (tab‬ﻳـﺎ ﭘﻨﺠـﺮه اﻛﺘﻔـﺎ‬ ‫ﻣﻲ ﻛﻨﻨﺪ از آﻧﻬﺎ ﺑﺮاي ﺗﺼﺪﻳﻖ ﺳﻮال ﻧﻜﻨﻴﺪ‪.‬‬ ‫ƒ‬

‫ﺑﺮ ﻃﺒﻖ ارزش دادهﻫﺎي در ﺣﺎل ﺣﻔﺎﻇﺖ از اﺧﺘﺼﺎص دوره زﻣﺎﻧﺒﻨﺪي ﭘﺎﻳﺎن ﭘﺬﻳﺮ )‪ (timeout period‬اﺳﺘﻔﺎده ﻛﻨﻴـﺪ ﺗـﺎ‬ ‫ﺑﻄﻮر ﺧﻮدﻛﺎر ارﺗﺒﺎط ﻧﺸﺴﺖ ﻏﻴﺮﻓﻌﺎل )‪ (inactive session‬ﻗﻄﻊ ﺷﻮد‪) .‬ﻫﺮﭼﻪ ﻛﻮﺗﺎﻫﺘﺮ ﺑﻬﺘﺮ(‬

‫ƒ‬

‫ﻓﻘﻂ از ﻋﻤﻠﻜﺮدﻫﺎي اﺣﺮاز ﻫﻮﻳﺖ ﻛﻤﻜﻲ ﻗﻮي اﺳﺘﻔﺎده ﻛﻨﻴﺪ )ﭘﺮﺳﺶﻫﺎ و ﭘﺎﺳﺦﻫﺎ‪ ،‬ﺗﻨﻈﻴﻢ ﻣﺠﺪد رﻣﺰ ﻋﺒﻮر(‪ .‬ﻣﺎداﻣﻲ ﻛـﻪ از‬ ‫اﻋﺘﺒﺎرﻫــﺎﻳﻲ ﻣﺎﻧﻨــﺪ رﻣﺰﻫــﺎي ﻋﺒــﻮر و ﻧﺎﻣﻬــﺎي ﻛــﺎرﺑﺮي ﻳــﺎ ‪ token‬ﻫــﺎ اﺳــﺘﻔﺎده ﻣــﻲ ﻛﻨﻴــﺪ‪ ،‬درﻫــﻢ ﺳــﺎزي ﻳــﻚ ﻃﺮﻓــﻪ‬ ‫)‪ (one-way hash‬ﭘﺎﺳﺦﻫﺎ را ﺑﺮاي ﺟﻠﻮﮔﻴﺮي از ﺣﻤﻼت اﻓﺸﺎء )‪ (disclosure attacks‬ﺑﻜﺎر ﺑﮕﻴﺮﻳﺪ‪.‬‬

‫ƒ‬

‫ﺗﻌﻴﻴﻦ ﻛﻨﻨﺪﮔﺎن ﻫﻮﻳﺖ ‪ session‬ﻳﺎ ﻫﺮ ﺑﺨﺸﻲ از اﻋﺘﺒﺎرﻧﺎﻣﻪﻫﺎي ﻣﻌﺘﺒﺮ در ‪ URL‬ﻳﺎ ‪log‬ﻫـﺎ را در دﺳـﺘﺮس ﻗـﺮار ﻧﺪﻫﻴـﺪ‪.‬‬ ‫)ﺑﺎزﻧﻮﻳﺴﻲ ‪ Session‬ﻫﺎ ﻳﺎ ذﺧﻴﺮه ﺳﺎزي رﻣﺰﻫﺎي ﻋﺒﻮر ﻛﺎرﺑﺮ در ﻓﺎﻳﻞﻫﺎي ﺛﺒﺖ را ﺑﻜﺎر ﻧﮕﻴﺮﻳﺪ(‪.‬‬

‫ƒ‬

‫ﻫﻨﮕﺎم اﺳﺘﻔﺎده ﻛﺎرﺑﺮ از رﻣﺰ ﻋﺒﻮر ﺟﺪﻳﺪ‪ ،‬رﻣﺰ ﻋﺒﻮر ﻗﺪﻳﻤﻲ را ﺑﺮرﺳﻲ ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫ﺑــﻪ اﻋﺘﺒﺎرﻧﺎﻣــﻪﻫــﺎي ﻗﺎﺑــﻞ ﻛﻼﻫﺒــﺮداري )‪ (Spoofable‬ﻣﺎﻧﻨــﺪ آدرس ﻫــﺎي ‪ IP‬ﻳــﺎ ﻣﺤــﺪوده آدرس ﻫــﺎي ‪mask‬‬ ‫)‪ DNS ، (address range masks‬ﻳﺎ ﺟﺴﺘﺠﻮي ﻣﻌﻜﻮس ‪ ، DNS‬ﺳﺮآﻳﻨﺪﻫﺎي ﺑﺎزﮔﺸﺖﻛﻨﻨﺪه )‪ (referrer headers‬ﻳـﺎ‬ ‫ﻣﺸﺎﺑﻪ آﻧﻬﺎ ﺑﻪ ﻋﻨﻮان ﺗﻨﻬﺎ ﻣﻜﺎﻧﻴﺰم اﺣﺮاز ﻫﻮﻳﺖ اﻋﺘﻤﺎد ﻧﻜﻨﻴﺪ‪.‬‬

‫ƒ‬

‫ﻣﺮاﻗﺐ ارﺳﺎل ﻣﻮارد ﻣﺤﺮﻣﺎﻧﻪ ﺑﻪ آدرسﻫﺎي ‪ email‬ﺑﻌﻨﻮان ﻣﻜﺎﻧﻴﺰﻣﻲ ﺑﺮاي ﺗﻨﻈﻴﻢ ﻣﺠﺪد )‪ (reset‬ﻛﻠﻤـﻪ ﻋﺒـﻮر ﺑﺎﺷـﻴﺪ‪ .‬از‬ ‫اﻋﺪاد ﺗﺼﺎدﻓﻲ ﺑﺎ ﻣﺤﺪودﻳﺖ زﻣﺎﻧﻲ ﺑﺮاي ﺗﻨﻈﻴﻢ ﻣﺠﺪد دﺳﺘﻴﺎﺑﻲ اﺳﺘﻔﺎده ﻛﻨﻴﺪ و ‪ email‬ﭘﻴﮕﻴﺮي را ﺑﻪ ﻣﺤﺾ ﺗﻨﻈﻴﻢ ﻣﺠـﺪد‬ ‫ﻛﻠﻤﻪ ﻋﺒﻮر ارﺳﺎل ﻛﻨﻴﺪ‪ .‬ﻣﺮاﻗﺐ ﺑﺎﺷﻴﺪ ﻛﺎرﺑﺮانِ ﺧﻮد‪-‬ﺛﺒﺖ )‪ (self–registered‬ﻣﺠـﺎز ﺑـﻪ ﺗﻐﻴﻴـﺮ آدرس ‪ ،email‬ﻗﺒـﻞ از‬ ‫اِﻋﻤﺎل ﺗﻐﻴﻴﺮ آدرس‪ ،‬ﭘﻴﻐﺎﻣﻲ را ﺑﻪ آدرس ‪ email‬ﻗﺒﻠﻲ ﺧﻮد ارﺳﺎل ﻛﻨﻨﺪ‪.‬‬

‫ﻧﻤﻮﻧﻪ ﻫﺎ‬ ‫‪http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6145‬‬ ‫‪http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6229‬‬ ‫‪http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6528‬‬

‫ƒ‬ ‫ƒ‬ ‫ƒ‬

‫ﻣﺮاﺟﻊ‬ ‫‪CWE: CWE-287 (Authentication Issues), CWE-522 (Insufficiently Protected‬‬ ‫‪Credentials), CWE-311 (Reflection attack in an authentication protocol), others.‬‬

‫‪٣٤‬‬

‫ƒ‬

OWASP Top 10 2007 ƒ

ƒ ƒ ƒ ƒ

WASC Threat Classification: http://www.webappsec.org/projects/threat/classes/insufficient_authentication.shtml http://www.webappsec.org/projects/threat/classes/credential_session_prediction.shtml http://www.webappsec.org/projects/threat/classes/session_fixation.shtml OWASP Guide, http://www.owasp.org/index.php/Guide_to_Authentication OWASP Code Review Guide, http://www.owasp.org/index.php/Reviewing_Code_for_Authentication OWASP Testing Guide, http://www.owasp.org/index.php/Testing_for_authentication RSNAKE01 - http://ha.ckers.org/blog/20070122/ip-trust-relationships-xss-and-you

٣٥

‫اﻧﺒﺎره ﻣﺤﺎﻓﻈﺖ ﻧﺸﺪه رﻣﺰﻧﮕﺎري‬

‫‪A8 – INSECURE CRYPTOGRAPHIC STORAGE‬‬

‫ﻣﺤﺎﻓﻈﺖ از دادهﻫﺎي ﺣﺴﺎس ﺑﻮﺳﻴﻠﻪ رﻣﺰﻧﮕﺎري‪ ،‬ﺑﺨﺶ ﻛﻠﻴﺪي اﻛﺜﺮ ﻧﺮماﻓﺰارﻫﺎي ﺗﺤﺖ وب ﻣﻲ ﺑﺎﺷﺪ‪ .‬ﺑـﺎ اﻳـﻦ وﺟـﻮد ﻛﻮﺗـﺎﻫﻲ در‬ ‫رﻣﺰﻧﮕﺎري دادهﻫﺎي ﺣﺴﺎس ﺑﻪ دﻟﻴﻞ اﺳﺘﻔﺎده ﻧﺮم اﻓﺰارﻫﺎ از روش ﻫـﺎي رﻣﺰﻧﮕـﺎري ﺿـﻌﻴﻒ در اﺳـﺘﻔﺎده از رﻣﺰﻫـﺎي ﻧﺎﻣﻨﺎﺳـﺐ ﻳـﺎ‬ ‫اﺷﺘﺒﺎﻫﺎت ﺟﺪي در اﺳﺘﻔﺎده از رﻣﺰﻫﺎي ﻗﻮي ﺑﺴﻴﺎر ﺷﺎﻳﻊ ﻣﻲ ﺑﺎﺷﺪ‪ .‬اﻳﻦ ﺿﻌﻒﻫﺎ ﻣﻲﺗﻮاﻧﻨﺪ ﻣﻨﺠﺮ ﺑﻪ اﻓﺸﺎي دادهﻫﺎي ﺣﺴﺎس و ﻧﻘﺾ‬ ‫ﻗﻮاﻧﻴﻦ ﺷﻮﻧﺪ‪.‬‬

‫ﻣﺤﻴﻂ ﻫﺎي ﻣﺘﺎﺛﺮ‬ ‫ﺗﻤﺎﻣﻲ ﻧﺮماﻓﺰارﻫﺎي ﺗﺤﺖ وب در ﺑﺮاﺑﺮ اﻧﺒﺎره ﻣﺤﺎﻓﻈﺖ ﻧﺸﺪه رﻣﺰﻧﮕﺎري آﺳﻴﺐﭘﺬﻳﺮ ﻫﺴﺘﻨﺪ‪.‬‬

‫آﺳﻴﺐ ﭘﺬﻳﺮي‬ ‫ﭘﻴﺸﮕﻴﺮي از ﺿﻌﻒﻫﺎي رﻣﺰﻧﮕﺎري ﺑﺮﻧﺎﻣﻪرﻳﺰي دﻗﻴﻘﻲ را ﻣﻲﻃﻠﺒﺪ‪ .‬راﻳﺞﺗﺮﻳﻦ ﻣﺸﻜﻼت ﺷﺎﻣﻞ ﻣﻮارد زﻳﺮ ﻣﻲﺷﻮد‪:‬‬ ‫ƒ‬

‫ﻋﺪم رﻣﺰﮔﺬاري دادهﻫﺎي ﺣﺴﺎس‬

‫ƒ‬

‫اﺳﺘﻔﺎده از اﻟﮕﻮرﻳﺘﻢﻫﺎي ﺧﺎﻧﮕﻲ‬

‫ƒ‬

‫اﺳﺘﻔﺎده ﺣﻔﺎﻇﺖ ﻧﺸﺪه از اﻟﮕﻮرﻳﺘﻢﻫﺎي ﻗﻮي‬

‫ƒ‬

‫اﺳﺘﻔﺎده ﻣﺪاوم از اﻟﮕﻮرﻳﺘﻢﻫﺎي آزﻣﺎﻳﺶ ﺷﺪه ﺿﻌﻴﻒ )‪ RC4 ،RC3 ،SHA-1 ،MP5‬و ﻏﻴﺮه(‬

‫ƒ‬

‫ﻛﻠﻴﺪﻫﺎي ﻛﺪﮔﺬاري ﺳﺨﺖ )‪ (hard coding keys‬و ﻧﮕﻬﺪاري ﻛﻠﻴﺪﻫﺎ در ﻣﺤﻞ ﻫﺎي ﻣﺤﺎﻓﻈﺖ ﻧﺸﺪه‪.‬‬

‫ﺑﺮرﺳﻲ اﻣﻨﻴﺖ‬ ‫ﻫﺪف‪ ،‬ﺗﻌﻴﻴﻦ رﻣﺰﮔﺬاري ﺻﺤﻴﺢ اﻃﻼﻋﺎت ﺣﺴﺎس اﻧﺒﺎره ﺗﻮﺳﻂ ﻧﺮماﻓﺰار اﺳﺖ‪.‬‬ ‫روشﻫﺎي ﺧﻮدﻛﺎر‪ :‬اﺑﺰارﻫﺎي ﭘﻮﻳﺶ آﺳﻴﺐﭘﺬﻳﺮي ﺑﻪ ﻫﻴﭻ وﺟﻪ ﻗﺎدر ﺑﻪ ﺑﺮرﺳـﻲ اﻧﺒـﺎره رﻣﺰﻧﮕـﺎري ﻧﻴـﺴﺘﻨﺪ‪ .‬اﺑﺰارﻫـﺎي ﭘـﻮﻳﺶ ﻛـﺪ‬ ‫ﻣﻲﺗﻮاﻧﻨﺪ اﺳﺘﻔﺎده از ‪ API‬ﻫﺎي رﻣﺰﻧﮕﺎري ﺷﻨﺎﺧﺘﻪ ﺷﺪه را ﺗﺸﺨﻴﺺ دﻫﻨﺪ‪ ،‬اﻣﺎ ﻗﺎدر ﺑﻪ ﺗﺸﺨﻴﺺ درﺳﺘﻲ اﺳﺘﻔﺎده از آﻧﻬـﺎ ﻳـﺎ اﺟـﺮاي‬ ‫رﻣﺰﮔﺬاري در اﺟﺰاي ﺧﺎرﺟﻲ ﻧﻴﺴﺘﻨﺪ‪.‬‬ ‫روشﻫﺎي دﺳﺘﻲ‪ :‬اﻳﻦ روش ﻣﺎﻧﻨﺪ ﭘﻮﻳﺶ ﻧﻤﻲﺗﻮاﻧـﺪ اﻧﺒـﺎره رﻣﺰﻧﮕـﺎري را ﺑﺮرﺳـﻲ ﻛﻨـﺪ‪ .‬ﻣـﺮور ﻛـﺪ ﺑﻬﺘـﺮﻳﻦ روش ﺑـﺮاي ﺑﺮرﺳـﻲ‬ ‫رﻣﺰﮔﺬاري دادهﻫﺎي ﺣﺴﺎس ﺑﻮﺳﻴﻠﻪ ﻧﺮماﻓﺰار و ﭘﻴﺎدهﺳﺎزي ﺻﺤﻴﺢ ﻣﻜﺎﻧﻴﺰم و ﻣﺪرﻳﺖ ﻛﻠﻴﺪ ﻣـﻲﺑﺎﺷـﺪ‪ .‬اﻳـﻦ روش در ﺑﺮﺧـﻲ ﻣـﻮارد‬ ‫ﺷﺎﻣﻞ آزﻣﺎﻳﺶ ﭘﻴﻜﺮﺑﻨﺪي ﺳﻴﺴﺘﻢﻫﺎي ﺧﺎرﺟﻲ اﺳﺖ‪.‬‬

‫‪٣٦‬‬

‫‪OWASP Top 10 2007‬‬

‫ﻣﺤﺎﻓﻈﺖ‬ ‫ﻣﻬﻤﺘﺮﻳﻦ ﻧﻜﺘﻪ اﻃﻤﻴﻨﺎن از رﻣﺰﮔﺬاري ﺻﺤﻴﺢ آﻧﭽﻪ ﻛﻪ ﺑﺎﻳﺪ رﻣﺰﮔﺬاري ﺷﻮد اﺳﺖ‪ .‬ﭘﺲ از آن ﺑﺎﻳﺪ از ﭘﻴﺎدهﺳﺎزي ﺻـﺤﻴﺢ رﻣﺰﻧﮕـﺎري‬ ‫اﻃﻤﻴﻨﺎن ﺣﺎﺻﻞ ﻛﺮد‪ .‬از آﻧﺠﺎﺋﻴﻜﻪ ﻛﻪ روشﻫﺎي ﺑﺴﻴﺎر زﻳﺎدي ﺑﺮاي اﺳـﺘﻔﺎده ﻧﺎدرﺳـﺖ از رﻣﺰﻧﮕـﺎري وﺟـﻮد دارد‪ ،‬ﭘﻴـﺸﻨﻬﺎدات زﻳـﺮ‬ ‫ﻣﻲ ﺑﺎﻳﺴﺖ ﺑﻪ ﻋﻨﻮان ﺑﺨﺸﻲ از ﺑﺮﻧﺎﻣﻪ آزﻣﺎﻳﺸﻲ ﺑﺮاي اﻃﻤﻴﻨﺎن از ﻣﺪﻳﺮﻳﺖ اﻣﻦ اﺻﻮل رﻣﺰﻧﮕﺎري در ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﺷﻮﻧﺪ‪:‬‬ ‫ƒ‬

‫اﻟﮕﻮرﻳﺘﻢﻫﺎي رﻣﺰﻧﮕﺎري را ﺗﻮﻟﻴﺪ ﻧﻜﻨﻴﺪ‪ ،‬ﺗﻨﻬﺎ از اﻟﮕﻮرﻳﺘﻢﻫﺎي ﻋﻤﻮﻣﻲ ﺗﺎﻳﻴﺪ ﺷﺪه ﻣﺎﻧﻨﺪ ‪ ،AES‬رﻣﺰﻧﮕـﺎري ﻛﻠﻴـﺪ ﻋﻤـﻮﻣﻲ‬ ‫‪ RSA‬و ‪ SHA – 256‬ﻳﺎ از اﻟﮕﻮرﻳﺘﻢ ﻫﺎي ﺑﻬﺘﺮ ﺑﺮاي درﻫﻢ ﺳﺎزي )‪ (hashing‬اﺳﺘﻔﺎده ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫از اﻟﮕﻮرﻳﺘﻢﻫﺎي ﺿﻌﻴﻒ اﺳﺘﻔﺎده ﻧﻜﻨﻴﺪ‪ ،‬ﻣﺎﻧﻨﺪ ‪ MD5‬ﻳﺎ ‪ .SHA–1‬از ﺟﺎﻳﮕﺰﻳﻦﻫﺎي اﻳﻤﻦﺗﺮ ﻣﺎﻧﻨﺪ ‪ SHA–256‬ﻳـﺎ ﺑﻬﺘـﺮ‬ ‫اﺳﺘﻔﺎده ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫ﻛﻠﻴﺪﻫﺎ را ﺑﺼﻮرت ‪ Offline‬ﺗﻮﻟﻴﺪ و ﻛﻠﻴﺪﻫﺎي ﺧﺼﻮﺻﻲ را در ﻧﻬﺎﻳﺖ ﻣﺮاﻗﺒﺖ ﻧﮕﻬﺪاري ﻛﻨﻴﺪ‪ .‬ﻫﺮﮔﺰ ﻛﻠﻴﺪﻫﺎي ﺧﺼﻮﺻﻲ‬ ‫را ﺑﺮ روي ﻛﺎﻧﺎلﻫﺎي ﻣﺤﺎﻓﻈﺖ ﻧﺸﺪه اﻧﺘﻘﺎل ﻧﺪﻫﻴﺪ‪.‬‬

‫ƒ‬

‫از اﻳﻨﻜــﻪ اﻋﺘﺒﺎرﻧﺎﻣــﻪﻫــﺎي زﻳﺮﺳــﺎﺧﺖ ﻣﺎﻧﻨــﺪ اﻋﺘﺒﺎرﻧﺎﻣــﻪﻫــﺎي ﭘﺎﻳﮕــﺎه داده ﻳــﺎ ﺟﺰﺋﻴــﺎت دﺳﺘﺮﺳــﻲ ﺻــﻒ ‪MQ‬‬ ‫)‪ (MQ queue access details‬از ﻃﺮﻳﻖ ﻛﻨﺘﺮلﻫﺎ و ﻣﺠﻮزﻫﺎي ﺳﺨﺖ ﺳﻴﺴﺘﻢ ﻓﺎﻳﻞ ﻣﺤﺎﻓﻈﺖ ﻣﻲ ﺷﻮﻧﺪ ﻳﺎ ﺑـﻪ ﺷـﻜﻞ‬ ‫اﻣﻦ رﻣﺰﮔﺬاري ﺷﺪه و ﺑﻪ آﺳﺎﻧﻲ ﺗﻮﺳﻂ ﻛﺎرﺑﺮان ﻣﺤﻠﻲ ﻳﺎ راه دور ﻗﺎﺑﻞ رﻣﺰﮔﺸﺎﻳﻲ ﻧﺒﺎﺷﺪ‪ ،‬اﻃﻤﻴﻨﺎن ﺣﺎﺻﻞ ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫از ﻋﺪم رﻣﺰﮔﺸﺎﻳﻲ آﺳﺎن دادهﻫﺎي رﻣﺰﮔﺬاري ﺷﺪه ﺑﺮ روي دﻳﺴﻚ اﻃﻤﻴﻨﺎن ﺣﺎﺻﻞ ﻛﻨﻴﺪ‪ .‬ﺑﻪ ﻃﻮر ﻣﺜﺎل در ﺻﻮرﺗﻴﻜﻪ ﻣﺨﺰن‬ ‫ارﺗﺒﺎط ﭘﺎﻳﮕﺎه داده دﺳﺘﺮﺳﻲ رﻣﺰﮔﺬاري ﻧﺸﺪه را ﻣﻴﺴﺮ ﺳﺎزد‪ ،‬رﻣﺰﮔﺬاري ﭘﺎﻳﮕﺎه داده ﺑﻲﻓﺎﻳﺪه اﺳﺖ‪.‬‬

‫ƒ‬

‫ﺑﺮ ﻃﺒﻖ ﻧﻴﺎزﻣﻨﺪي ‪ 3‬اﺳﺘﺎﻧﺪارد اﻣﻨﻴـﺖ داده ‪ ،PCI‬ﺑﺎﻳـﺪ از دادهﻫـﺎي دارﻧـﺪه ﻛـﺎرت ﻣﺤﺎﻓﻈـﺖ ﻛﻨﻴـﺪ‪ .‬ﭘـﺬﻳﺮش اﺳـﺘﺎﻧﺪارد‬ ‫‪ PCI DSS‬ﺑﺮاي ﺑﺎزرﮔﺎﻧﺎن و ﻫﺮ ﻓﺮد دﻳﮕﺮي ﻛﻪ ﺑﻪ ﻧﺤﻮي ﺑﺎ ﻛﺎرت ﻫﺎي اﻋﺘﺒـﺎري ﺳـﺮوﻛﺎر دارد ﭘـﻴﺶ از ﺳـﺎل ‪2008‬‬ ‫اﺟﺒﺎري اﺳﺖ‪ .‬ﺑﻬﺘﺮﻳﻦ روش‪ ،‬ﻋﺪم ذﺧﻴﺮه دادهﻫﺎي ﻏﻴﺮﺿﺮوري ﻣﺎﻧﻨﺪ اﻃﻼﻋﺎت ﻋﻼﻣﺖ ﻣﻐﻨﺎﻃﻴﺴﻲ ﻳﺎ ﺷﻤﺎره ﺻﺎﺣﺐ اﺻﻠﻲ‬ ‫)‪ PAN‬و ﻳﺎ آﻧﭽﻪ ﻛﻪ ﺑﻪ ﻋﻨﻮان ﺷﻤﺎره ﻛﺎرت اﻋﺘﺒﺎري ﺷﻨﺎﺧﺘﻪ ﻣﻲ ﺷﻮد( اﺳﺖ‪ .‬اﮔـﺮ ﺷـﻤﺎره ‪ PAN‬را ذﺧﻴـﺮه ﻣـﻲ ﻛﻨﻴـﺪ‪،‬‬ ‫ﭘﺬﻳﺮش ﻣﻠﺰوﻣﺎت ‪ DSS‬ﻧﻴﺰ ﺿﺮوري اﺳﺖ‪ .‬ﺑﻪ ﻃﻮر ﻣﺜﺎل ﻫﺮﮔﺰ و ﺗﺤﺖ ﻫﻴﭻ ﺷﺮاﻳﻄﻲ اﺟﺎزه ذﺧﻴﺮه ﺷـﻤﺎره ‪) CVV‬ﺳـﻪ‬ ‫رﻗﻢ ﭘﺸﺖ ﻛﺎرت( را ﻧﺪﻫﻴﺪ‪ .‬ﺑﺮاي اﻃﻼﻋﺎت ﺑﻴﺸﺘﺮ راﻫﻨﻤﺎي ‪ PCI DSS‬و ﻛﻨﺘﺮلﻫﺎي ﭘﻴﺎدهﺳﺎزي ﻻزم را ﺑﺒﻴﻨﻴﺪ‪.‬‬

‫‪٣٧‬‬

‫ﻧﻤﻮﻧﻪ ﻫﺎ‬ ƒ ƒ ƒ

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6145 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1664 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-1101 (True of most Java EE servlet containers, too)

‫ﻣﺮاﺟﻊ‬ ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ ƒ

CWE: CWE-311 (Failure to encrypt data), CWE-326 (Weak Encryption), CWE-321 (Use of hard-coded cryptographic key), CWE-325 (Missing Required Cryptographic Step), others. WASC Threat Classification: No explicit mapping OWASP, http://www.owasp.org/index.php/Cryptography OWASP Guide, http://www.owasp.org/index.php/Guide_to_Cryptography OWASP, http://www.owasp.org/index.php/Insecure_Storage OWASP, http://www.owasp.org/index.php/How_to_protect_sensitive_data_in_URL’s PCI Data Security Standard v1.1, https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf Bruce Schneier, http://www.schneier.com/ CryptoAPI Next Generation, http://msdn2.microsoft.com/en-us/library/aa376210.aspx

٣٨

‫‪OWASP Top 10 2007‬‬

‫ارﺗﺒﺎﻃﺎت ﻧﺎاﻣﻦ‬

‫‪A9 – INSECURE COMMUNICTION‬‬

‫ﻧﺮماﻓﺰارﻫﺎي ﺗﺤﺖ وب ﻣﻜﺮرا در رﻣﺰﮔﺬاري ﺗﺮاﻓﻴﻚ ﺷﺒﻜﻪ‪ ،‬ﻋﻠﻲ رﻏﻢ ﺿﺮوري ﺑﻮدن اﻳﻦ اﻣﺮ ﺑﺮاي ﻣﺤﺎﻓﻈﺖ از ارﺗﺒﺎﻃـﺎت ﺣـﺴﺎس‬ ‫ﺷﻜﺴﺖ ﻣﻲﺧﻮرﻧﺪ‪ .‬رﻣﺰﮔﺬاري )ﻣﻌﻤﻮﻻً ‪ (SSL‬ﺑﺎﻳﺪ ﺑﺮاي ﻫﻤﻪ ارﺗﺒﺎﻃﺎت اﺣﺮاز ﻫﻮﻳﺖ ﺷﺪه ﺑﻮﻳﮋه ﺻـﻔﺤﺎت وب ﻗﺎﺑـﻞ دﺳـﺘﻴﺎﺑﻲ از‬ ‫ﻃﺮﻳﻖ اﻳﻨﺘﺮﻧﺖ‪ ،‬ﻫﻤﺎﻧﻨﺪ ارﺗﺒﺎﻃﺎت ﭘﺸﺖ ﺧﻂ )‪ (backend connections‬در ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﺷﻮد‪ ،‬در ﻏﻴﺮ اﻳﻨﺼﻮرت ﻧﺮم اﻓـﺰار ﻧـﺸﺎﻧﻪ‬ ‫)‪ (token‬اﺣﺮاز ﻫﻮﻳﺖ ﻳﺎ ﻧﺸﺴﺖ را در دﺳﺘﺮس ﻗﺮار ﻣﻲدﻫﺪ‪ .‬ﻋﻼوه ﺑﺮ اﻳﻦ رﻣﺰﮔﺬاري ﺑﺎﻳﺪ در زﻣﺎن اﻧﺘﻘﺎل دادهﻫﺎي ﺣﺴﺎس ﻣﺎﻧﻨـﺪ‬ ‫اﻃﻼﻋﺎت ﻛﺎرت اﻋﺘﺒﺎري ﻳﺎ ﺳﻼﻣﺘﻲ ﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار ﮔﻴﺮﻧﺪ‪ .‬ﻧﺮماﻓﺰارﻫﺎﻳﻲ ﻛﻪ ﻋﻘﺐ ﻧﺸﻴﻨﻲ )‪ (fall back‬ﻣﻲﻛﻨﻨﺪ ﻳﺎ وادار ﺑﻪ ﻋﻘﺐ‬ ‫ﻧﺸﻴﻨﻲ از ﺣﺎﻟﺖ رﻣﺰﮔﺬاري ﻣﻲﺷﻮﻧﺪ‪ ،‬ﻣﻲﺗﻮاﻧﻨﺪ ﺗﻮﺳﻂ ﻣﻬﺎﺟﻤﻴﻦ ﻣﻮرد ﺳﻮء اﺳﺘﻔﺎده ﻗﺮار ﺑﮕﻴﺮﻧﺪ‪ .‬اﺳﺘﺎﻧﺪارد ‪ PCI‬ﻻزم ﻣـﻲداﻧـﺪ ﻛـﻪ‬ ‫ﻫﻤﻪ اﻃﻼﻋﺎت ﻛﺎرت اﻋﺘﺒﺎري ﺑﺮروي اﻳﻨﺘﺮﻧﺖ ﺑﺼﻮرت رﻣﺰﮔﺬاري اﻧﺘﻘﺎل داده ﺷﻮد‪.‬‬

‫ﻣﺤﻴﻂ ﻫﺎي ﻣﺘﺎﺛﺮ‬ ‫ﺗﻤﺎﻣﻲ ﺳﺎﺧﺘﺎرﻫﺎي ﻧﺮماﻓﺰارﻫﺎي ﺗﺤﺖ وب در ﺑﺮاﺑﺮ ارﺗﺒﺎﻃﺎت ﻧﺎاﻣﻦ آﺳﻴﺐﭘﺬﻳﺮ ﻫﺴﺘﻨﺪ‪.‬‬

‫آﺳﻴﺐ ﭘﺬﻳﺮي‬ ‫ﻛﻮﺗﺎﻫﻲ در رﻣﺰﮔﺬاري ارﺗﺒﺎﻃﺎت ﺣﺴﺎس ﺑﻪ اﻳﻦ ﻣﻌﻨﻲ اﺳﺖ ﻛﻪ ﻣﻬﺎﺟﻤﻲ ﻛﻪ ﺗﺮاﻓﻴﻚ ﺷﺒﻜﻪ را اﺳﺘﺮاق ﺳـﻤﻊ ﻣـﻲﻛﻨـﺪ ﻣـﻲﺗﻮاﻧـﺪ ﺑـﻪ‬ ‫ﺗﺒﺎدﻻﺗﻲ ﺷﺎﻣﻞ اﻋﺘﺒﺎرﻧﺎﻣﻪﻫﺎ ﻳﺎ اﻃﻼﻋﺎت ﺣﺴﺎس ﻣﺒﺎدﻟﻪ ﺷﺪه‪ ،‬دﺳﺘﺮﺳﻲ ﭘﻴﺪا ﻛﻨﺪ‪ .‬در ﻧﻈﺮ داﺷﺘﻪ ﺑﺎﺷﻴﺪ ﻛﻪ ﺷﺒﻜﻪﻫﺎي ﻣﺨﺘﻠﻒ در ﺑﺮاﺑـﺮ‬ ‫ﺧﻄﺮ اﺳﺘﺮاق ﺳﻤﻊ در ﺳﻄﻮح ﻣﺘﻔﺎوﺗﻲ ﻗﺮار دارﻧﺪ‪ .‬ﺑﻪ ﻫﺮ ﺣﺎل درك اﻳﻦ ﻣﻮﺿﻮع ﻛﻪ ﺳﺮاﻧﺠﺎم ﻳﻚ ﻣﻴﺰﺑﺎن در ﻫﺮ ﺷﺒﻜﻪاي ﻣﻮرد ﻧﻔـﻮذ‬ ‫ﻗﺮار ﻣﻲﮔﻴﺮد و ﻣﻬﺎﺟﻤﻴﻦ ﺑﺮاي رﺑﻮدن اﻋﺘﺒﺎرﻧﺎﻣﻪﻫﺎي ﺳﻴﺴﺘﻢﻫﺎي ﻣﺨﺘﻠﻒ‪ ،‬ﻧﺮماﻓﺰارﻫﺎي اﺳﺘﺮاق ﺳﻤﻊ )‪ (sniffer‬را ﻧـﺼﺐ ﺧﻮاﻫﻨـﺪ‬ ‫ﻛﺮد‪ ،‬ﺣﺎﺋﺰ اﻫﻤﻴﺖ اﺳﺖ‪ .‬از آﻧﺠﺎﺋﻴﻜﻪ اﺳﺘﻔﺎده از ﺷﺒﻜﻪﻫﺎي ﻧﺎاﻣﻦ ﺑﺮاي دﺳﺘﺮﺳﻲ ﺑﻪ ﻧﺮماﻓﺰارﻫﺎ ﺑﺴﻴﺎر ﻣﺤﺘﻤﻞ اﺳﺖ‪ ،‬اﺳـﺘﻔﺎده از ‪SSL‬‬ ‫ﺑﺮاي ارﺗﺒﺎط ﺑﺎ ﻛﺎرﺑﺮان ﻧﻬﺎﻳﻲ ﺣﻴﺎﺗﻲ اﺳﺖ‪ .‬از آﻧﺠﺎﺋﻴﻜﻪ ‪ HTTP‬ﺑﺎ ﻫﺮ درﺧﻮاﺳﺖ ﺷﺎﻣﻞ اﻋﺘﺒﺎرﻧﺎﻣﻪﻫﺎي اﺣﺮاز ﻫﻮﻳـﺖ ﻳـﺎ ‪session‬‬ ‫‪ token‬ﻣﻲﺷﻮد ﻧﻪ ﺗﻨﻬﺎ درﺧﻮاﺳﺖ واﻗﻌﻲ ورود ﺑﻪ ﺳﻴﺴﺘﻢ )‪ (login‬ﺑﻠﻜﻪ ﺗﻤﺎﻣﻲ ﺗﺮاﻓﻴﻚ اﺣﺮاز ﻫﻮﻳﺖ ﺷﺪه ﺑﻪ ﻋﺒﻮر از ﻃﺮﻳﻖ ‪SSL‬‬ ‫ﻧﻴﺎزﻣﻨﺪ ﻣﻲﺑﺎﺷﻨﺪ‪.‬‬ ‫رﻣﺰﮔﺬاري ارﺗﺒﺎﻃﺎت ﺑﺎ ﺳﺮورﻫﺎي ﭘﺸﺖ ﺧﻂ )‪ (backend servers‬ﻧﻴﺰ ﻣﻬﻢ اﺳﺖ‪ .‬اﮔﺮﭼﻪ اﻳﻦ ﺷﺒﻜﻪﻫـﺎ اﻣـﻦ ﺗـﺮ ﻣـﻲﺑﺎﺷـﻨﺪ اﻣـﺎ‬ ‫اﻃﻼﻋﺎت و اﻋﺘﺒﺎرﻧﺎﻣﻪﻫﺎﻳﻲ را ﻛﻪ اﻧﺘﻘﺎل ﻣﻲدﻫﻨﺪ ﺣﺴﺎسﺗﺮ و ﺑﻴﺸﺘﺮ اﺳﺖ‪ .‬ﺑﻨﺎﺑﺮاﻳﻦ اﺳﺘﻔﺎده از ‪ SSL‬ﺑﺮروي ﺳﺮور ﻫﺎي ﭘـﺸﺖ ﺧـﻂ‬ ‫ﻓﻮقاﻟﻌﺎده ﻣﻬﻢ اﺳﺖ‪ .‬رﻣﺰﮔﺬاري دادهﻫﺎي ﺣﺴﺎس ﻣﺎﻧﻨﺪ ﻛﺎرت ﻫﺎي اﻋﺘﺒﺎري و ﺷﻤﺎرهﻫﺎي اﻣﻨﻴﺘﻲ اﺟﺘﻤﺎﻋﻲ‪ ،‬ﺑﻪ ﻋﻨﻮان ﺣﺮﻳﻢ‬

‫‪٣٩‬‬

‫ﺧﺼﻮﺻﻲ و ﻗﻮاﻧﻴﻦ ﻣﺎﻟﻲ ﺑﺮاي ﺑﺴﻴﺎري از ﺳﺎزﻣﺎنﻫﺎ ﻣﺤﺴﻮب ﻣﻲﺷﻮﻧﺪ‪ .‬اﻫﻤﺎل در اﺳﺘﻔﺎده از ‪ SSL‬ﺑﺮاي ﻣـﺪﻳﺮﻳﺖ اﺗـﺼﺎﻻت ﻣﺎﻧﻨـﺪ‬ ‫دادهﻫﺎ‪ ،‬ﭘﺬﻳﺮش رﻳﺴﻚ را ﺑﻪ دﻧﺒﺎل ﺧﻮاﻫﺪ داﺷﺖ‪.‬‬

‫ﺑﺮرﺳﻲ اﻣﻨﻴﺖ‬ ‫ﻫﺪف‪ ،‬ﺑﺮرﺳﻲ رﻣﺰﮔﺬاري ﻣﻨﺎﺳﺐ ﺑﺮاي ﺗﻤﺎﻣﻲ ارﺗﺒﺎﻃﺎت ﺣﺴﺎس و ﻣﻌﺘﺒﺮ ﺗﻮﺳﻂ ﻧﺮماﻓﺰار ﻣﻲ ﺑﺎﺷﺪ‪.‬‬ ‫روشﻫﺎي ﺧﻮدﻛﺎر‪ :‬اﺑﺰارﻫﺎي ﭘـﻮﻳﺶ آﺳـﻴﺐﭘـﺬﻳﺮي ﻗـﺎدر ﺑـﻪ ﺑﺮرﺳـﻲ اﺳـﺘﻔﺎده از ‪ SSL‬ﺑـﺮروي ﺧﻄـﻮط ارﺗﺒـﺎﻃﻲ ﺑـﺎ ﻛـﺎرﺑﺮان‬ ‫)‪ (front end‬و ﻫﻤﭽﻨﻴﻦ ﻳﺎﻓﺘﻦ ﺿﻌﻒ ﻫﺎي ﻣﺮﺗﺒﻂ ﺑﺎ ‪ SSL‬ﻫـﺴﺘﻨﺪ‪ .‬اﻳـﻦ اﺑﺰارﻫـﺎ ﺑـﻪ اﺗـﺼﺎﻻت ‪ backend‬دﺳﺘﺮﺳـﻲ ﻧﺪارﻧـﺪ و‬ ‫ﻧﻤﻲﺗﻮاﻧﻨﺪ اﻣﻨﻴﺖ آﻧﻬﺎ را ﺑﺮرﺳﻲ ﻛﻨﻨﺪ‪ .‬اﺑﺰارﻫﺎي ﺗﺤﻠﻴﻞ اﺑﺘﺪا ﻣﻤﻜﻦ اﺳﺖ ﻗـﺎدر ﺑـﻪ ﻛﻤـﻚ در ﺗﺤﻠﻴـﻞ ﺑـﺴﻴﺎري از ﻓﺮاﺧـﻮاﻧﻲﻫـﺎ ﺑـﻪ‬ ‫ﺳﻴﺴﺘﻢﻫﺎي ‪ backend‬ﺑﺎﺷﻨﺪ اﻣﺎ روش ﻣﻨﻄﻘﻲ ﻣﻮرد ﻧﻴﺎز ﺑﺮاي اﻧﻮاع ﺳﻴﺴﺘﻢﻫﺎ را درك ﻧﺨﻮاﻫﻨﺪ ﻛﺮد‪.‬‬ ‫روﺷﻬﺎي دﺳﺘﻲ‪ :‬اﻳﻦ روش ﻣﻲﺗﻮاﻧﺪ اﺳﺘﻔﺎده ‪ SSL‬و ﺿﻌﻒﻫﺎي ﻣﺮﺗﺒﻂ ﺑﺎ ‪ SSL‬را ﺑﺮروي ارﺗﺒﺎط ‪ front end‬ﺑﺮرﺳـﻲ ﻛﻨـﺪ اﻣـﺎ‬ ‫روﺷﻬﺎي ﺧﻮدﻛﺎر اﺣﺘﻤﺎﻻً ﻣﻮﺛﺮﺗﺮ اﺳﺖ‪ .‬ﻣﺮور ﻛﺪ ﺑﺮاي ﺑﺮرﺳﻲ اﺳﺘﻔﺎده درﺳﺖ از ‪ SSL‬در ﺗﻤﺎﻣﻲ اﺗﺼﺎﻻت ‪ back end‬ﺑﺴﻴﺎر ﻣﻮﺛﺮ‬ ‫اﺳﺖ‪.‬‬

‫ﻣﺤﺎﻓﻈﺖ‬ ‫ﻣﻬﻤﺘﺮﻳﻦ ﻣﺤﺎﻓﻈﺖ‪ ،‬اﺳﺘﻔﺎده از ‪ SSL‬در اﺗﺼﺎﻻت اﺣﺮاز ﻫﻮﻳﺖ ﺷﺪه ﻳﺎ ﻫﺮ ﻣﺤﻠﻲ ﻛﻪ دادهﻫﺎي ﺣﺴﺎس اﻧﺘﻘﺎل داده ﻣﻲﺷﻮﻧﺪ‪ ،‬اﺳـﺖ‪.‬‬ ‫ﺟﺰﺋﻴﺎت ﺑﺴﻴﺎري در ارﺗﺒﺎط ﺑﺎ ﭘﻴﻜﺮﺑﻨﺪي ﻣﻨﺎﺳﺐ ‪ SSL‬ﺑﺮاي ﻧﺮماﻓﺰارﻫﺎ وﺟﻮد دارد‪ ،‬در ﻧﺘﻴﺠﻪ درك و ﺗﺤﻠﻴﻞ ﻣﺤﻴﻂ ﻣﻬﻢ اﺳـﺖ‪ .‬ﺑـﻪ‬ ‫ﻃﻮر ﻣﺜﺎل ‪ IE 7.0‬ﻧﻮار ﺳﺒﺰرﻧﮕﻲ را ﺑﺮاي ﮔﻮاﻫﻴﻨﺎﻣﻪﻫﺎي ‪ SSL‬ﺑﺎ اﻃﻤﻴﻨﺎن ﺑﺎﻻ ﻓﺮاﻫﻢ ﻣﻲﻛﻨﺪ‪ ،‬اﻣﺎ اﻳﻦ روش ﺑﻪ ﺗﻨﻬﺎﻳﻲ ﻛﻨﺘﺮل ﻣﻨﺎﺳـﺒﻲ‬ ‫ﺑﺮاي ﺗﺎﻳﻴﺪ اﺳﺘﻔﺎده اﻣﻦ از رﻣﺰﻧﮕﺎري ﻧﻴﺴﺖ‪.‬‬ ‫ƒ‬

‫از ‪ SSL‬ﺑﺮاي ﺗﻤﺎﻣﻲ اﺗﺼﺎﻻﺗﻲ ﻛﻪ دادهﻫﺎي ﺣﺴﺎس ﻳﺎ ﺑﺎ ارزش را ﻣﻌﺘﺒﺮﺳﺎزي ﻳـﺎ اﻧﺘﻘـﺎل ﻣـﻲدﻫﻨـﺪ ﻣﺎﻧﻨـﺪ اﻋﺘﺒﺎرﻧﺎﻣـﻪﻫـﺎ‪،‬‬ ‫ﺟﺰﺋﻴﺎت ﻛﺎرت ﻫﺎي اﻋﺘﺒﺎري‪ ،‬ﺳﻼﻣﺖ و ﺳﺎﻳﺮ اﻃﻼﻋﺎت ﺷﺨﺼﻲ‪ ،‬اﺳﺘﻔﺎده ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫از ﺣﻔﺎﻇﺖ ﻣﻨﺎﺳﺐ ارﺗﺒﺎﻃﺎت ﺑﻴﻦ ﻋﻨﺎﺻﺮ زﻳﺮﺳﺎﺧﺖ ﻣﺎﻧﻨﺪ ارﺗﺒﺎط ﺑﻴﻦ ﺳﺮور وب و ﺳﺮورﻫﺎي ﭘﺎﻳﮕﺎه داده از ﻃﺮﻳﻖ اﺳـﺘﻔﺎده‬ ‫از اﻣﻨﻴﺖ ﻻﻳﻪ اﻧﺘﻘﺎل ﻳﺎ رﻣﺰﮔﺬاري ﺳﻄﺢ ﭘﺮوﺗﻜﻞ ﺑﺮاي اﻋﺘﺒﺎرﻧﺎﻣﻪﻫﺎ و دادهﻫﺎي ﺑﺎ ارزش اﻃﻤﻴﻨﺎن ﺣﺎﺻﻞ ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫ﺑﺮاﺳﺎس ﻧﻴﺎزﻣﻨﺪيﻫﺎي ‪ 4‬اﺳﺘﺎﻧﺪارد اﻣﻨﻴﺖ داده ‪ ،PCI‬ﺑﺎﻳﺪ از دادهﻫﺎي دارﻧﺪﮔﺎن ﻛﺎرت ﻫﺎ در زﻣـﺎن اﻧﺘﻘـﺎل داده ﻣﺤﺎﻓﻈـﺖ‬ ‫ﻛﻨﻴﺪ‪ .‬ﺑﻪ ﻃﻮر ﻛﻠﻲ دﺳﺘﺮﺳﻲ ﺑﺮﺧﻂ ﻛﺎرﺑﺮ ‪ ،‬ﺷﺮﻛﺎء ﻳﺎ ﻛﺎرﻛﻨﺎن و راﻫﺒﺮان ﺳﻴﺴﺘﻢ‪ ،‬ﺑﻪ ﺳﻴﺴﺘﻢﻫﺎ ﺑﺎﻳﺪ ﺑﺎ اﺳﺘﻔﺎده از ‪ SSL‬ﻳﺎ‬

‫‪٤٠‬‬

OWASP Top 10 2007

‫ و ﭘﻴـﺎدهﺳـﺎزي ﻛﻨﺘـﺮلﻫـﺎ را در ﺻـﻮرت ﻟـﺰوم‬PCI DSS ‫ ﺑﺮاي اﻃﻼﻋﺎت ﺑﻴﺸﺘﺮ راﻫﻨﻤﺎﻫﺎي‬.‫ رﻣﺰﮔﺬاري ﺷﻮد‬،‫ﻣﺸﺎﺑﻪ آن‬ .‫ﻣﺸﺎﻫﺪه ﻛﻨﻴﺪ‬

‫ﻧﻤﻮﻧﻪ ﻫﺎ‬ ƒ ƒ ƒ

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6430 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4704 http://www.schneier.com/blog/archives/2005/10/scandinavian_at_1.html

‫ﻣﺮاﺟﻊ‬ ƒ ƒ ƒ ƒ ƒ ƒ ƒ

CWE: CWE-311 (Failure to encrypt data), CWE-326 (Weak Encryption), CWE-321 (Use of hard-coded cryptographic key), CWE-325 (Missing Required Cryptographic Step), others. WASC Threat Classification: No explicit mapping OWASP Testing Guide, Testing for SSL / TLS, https://www.owasp.org/index.php/Testing_for_SSL-TLS OWASP Guide, http://www.owasp.org/index.php/Guide_to_Cryptography Foundstone - SSL Digger, http://www.foundstone.com/index.htm?subnav=services/navigation.htm&subcontent=/s ervices/overview_s3i_des.htm NIST, SP 800-52 Guidelines for the selection and use of transport layer security (TLS) Implementations, http://csrc.nist.gov/publications/nistpubs/800-52/SP800-52.pdf NIST SP 800-95 Guide to secure web services, http://csrc.nist.gov/publications/drafts.html#sp800-95

٤١

‫ﻛﻮﺗﺎﻫﻲ در ﻣﺤﺪود ﻛﺮدن دﺳﺘﺮﺳﻲ ﺑﻪ ‪URL‬‬

‫‪A10 – FAILURE TO URL ACCESS‬‬

‫اﻏﻠﺐ اوﻗﺎت ﺗﻨﻬﺎ راه ﻣﺤﺎﻓﻈﺖ ﺑﺮاي ‪ URL‬اﻳﻦ اﺳﺖ ﻛﻪ ﭘﻴﻮﻧﺪﻫﺎ )‪ (links‬ﺑﻪ ﺻﻔﺤﻪ ﻣﻮرد ﻧﻈﺮ‪ ،‬ﺑﺮاي ﻛﺎرﺑﺮان ﻏﻴﺮﻣﺠﺎز اراﻳﻪ ﻧﺸﻮد‪.‬‬ ‫اﻣﺎ ﻳﻚ ﻣﻬﺎﺟﻢ ﺑﺎ اﻧﮕﻴﺰه‪ ،‬ﻣﺎﻫﺮ‪ ،‬ﻳﺎ ﺣﺘﻲ ﺧﻮش ﺷﺎﻧﺲ ﻗﺎدر ﺑﻪ ﻳﺎﻓﺘﻦ و دﺳﺘﺮﺳﻲ ﺑﻪ اﻳﻦ ﺻﻔﺤﺎت ﻣـﻲ ﺑﺎﺷـﺪ‪ ،‬و ﻣـﻲ ﺗﻮاﻧـﺪ ﺗﻮاﺑـﻊ را‬ ‫درﺧﻮاﺳﺖ ﻛﺮده و دادهﻫﺎ را ﺑﺒﻴﻨﺪ‪ .‬اﻣﻨﻴﺖ از ﻃﺮﻳﻖ ﮔﻤﻨﺎﻣﻲ )‪ (security by obscurity‬ﺑﺮاي ﻣﺤﺎﻓﻈﺖ از ﺗﻮاﺑﻊ ﺣﺴﺎس و دادهﻫﺎ‬ ‫در ﻧﺮم اﻓﺰار ﻣﻮﺛﺮ ﻧﻴﺴﺖ‪ .‬روش ﻫﺎي ﻛﻨﺘﺮل دﺳﺘﺮﺳﻲ ﺑﺎﻳﺪ ﻗﺒﻞ از اﻳﻨﻜﻪ ﻳﻚ درﺧﻮاﺳﺖ ﺑﺮاي ﻳﻚ ﺗﺎﺑﻊ ﺣﺴﺎس ﭘﺬﻳﺮﻓﺘﻪ ﺷﻮد‪ ،‬اﻧﺠـﺎم‬ ‫ﺷﺪه و از اﻳﻨﻜﻪ ﻛﺎرﺑﺮ ﻣﺠﺎز ﻗﺎدر ﺑﻪ دﺳﺘﺮﺳﻲ ﺑﻪ آن ﺗﺎﺑﻊ ﺑﺎﺷﺪ‪ ،‬اﻃﻤﻴﻨﺎن ﺣﺎﺻﻞ ﺷﻮد‪.‬‬

‫ﻣﺤﻴﻂ ﻫﺎي ﻣﺘﺎﺛﺮ‬ ‫ﺗﻤﺎﻣﻲ ﺳﺎﺧﺘﺎرﻫﺎي ﻧﺮماﻓﺰارﻫﺎي ﺗﺤﺖ وب در ﺑﺮاﺑﺮ ﻛﻮﺗﺎﻫﻲ در ﻣﺤﺪود ﻛﺮدن دﺳﺘﺮﺳﻲ ﺑﻪ ‪ URL‬آﺳﻴﺐﭘﺬﻳﺮ ﻫﺴﺘﻨﺪ‪.‬‬

‫آﺳﻴﺐ ﭘﺬﻳﺮي‬ ‫روش اﺻـﻠﻲ ﺣﻤﻠـﻪ ﺑـﺮاي اﻳـﻦ آﺳـﻴﺐﭘـﺬﻳﺮي ﺑﻨـﺎم )‪ (forced browsing‬اﺳـﺖ ﻛـﻪ ﺷـﺎﻣﻞ ﺣـﺪس ﻟﻴﻨـﻚﻫـﺎ و روش ﻫـﺎي‬ ‫‪ brute force‬ﺑﺮاي ﻳﺎﻓﺘﻦ ﺻﻔﺤﺎت ﻧﺎاﻣﻦ ﻣﻲﺑﺎﺷﺪ‪ .‬ﻧﺮماﻓﺰارﻫﺎ اﻏﻠﺐ اوﻗﺎت ﺑﻪ ﻛﺪﻫﺎي ﻛﻨﺘﺮل دﺳﺘﺮﺳﻲ اﺟﺎزه ﻣﻲدﻫﻨﺪ ﻛـﻪ در ﺗﻤـﺎم‬ ‫‪ code base‬اﻳﺠﺎد و ﭘﺨﺶ ﺷﻮﻧﺪ ﻛﻪ ﻣﻨﺠﺮ ﺑﻪ ﻣﺪﻟﻲ ﭘﻴﭽﻴﺪه ﮔﺸﺘﻪ ﻛﻪ ﺗﺸﺨﻴﺺ آن ﺑﺮاي ﺑﺮﻧﺎﻣﻪﻧﻮﻳﺴﺎن و ﻣﺘﺨﺼﺼﻴﻦ اﻣﻨﻴﺘﻲ ﻣـﺸﻜﻞ‬ ‫اﺳﺖ‪ .‬اﻳﻦ ﭘﻴﭽﻴﺪﮔﻲ ﺑﺎﻋﺚ ﺑﺮوز ﺧﻄﺎﻫﺎ‪ ،‬از دﺳﺖ دادن ﺻﻔﺤﺎت و در دﺳﺘﺮس ﻗﺮار ﮔﺮﻓﺘﻦ آﻧﻬﺎ ﺷﻮد‪ .‬ﺑﺮﺧﻲ ﻣﺜﺎلﻫﺎ از اﻳﻦ ﺿﻌﻒﻫﺎ‬ ‫ﺷﺎﻣﻞ ﻣﻮارد زﻳﺮ ﻣﻲﮔﺮدد‪:‬‬ ‫ƒ‬

‫‪URL‬ﻫﺎي ﺧﺎص ﻳﺎ ﻣﺨﻔﻲ ﻛﻪ ﻓﻘﻂ ﺑﺮاي راﻫﺒﺮان ﺳﺎﻳﺖ ﻳﺎ ﻛﺎرﺑﺮان ﻣﺠﺎز‪ ،‬در ﻻﻳﻪ ﻧﻤﺎﻳﺶ اراﺋﻪ ﻣﻲﺷﻮد‪ ،‬اﻣﺎ اﮔـﺮ ﻛـﺎرﺑﺮان‬ ‫از وﺟﻮد آن ﻣﻄﻠﻊ ﺑﺎﺷﻨﺪ ﺑﺮاي ﻫﻤﻪ ﻗﺎﺑﻞ دﺳﺘﺮﺳﻲ اﺳﺖ‪ .‬ﻣﺜﻞ ‪ /admin/adduser.php‬ﻳﺎ ‪، /approveTransfer.do‬‬ ‫ﻛﻪ ﺧﺼﻮﺻﺎ ﺑﺎ ﻣﻨﻮي ﻛﺪ ﻣﻨﺘﺸﺮ ﻣﻲﺷﻮد‪.‬‬

‫ƒ‬

‫ﻧﺮماﻓﺰارﻫﺎ اﻏﻠﺐ اﺟﺎزه دﺳﺘﺮﺳﻲ ﺑﻪ ﻓﺎﻳﻞﻫﺎي ﻣﺨﻔﻲ ﻣﺎﻧﻨﺪ ‪ XML‬اﻳﺴﺘﺎ ﻳﺎ ﮔﺰارشﻫﺎي ﺗﻮﻟﻴـﺪ ﺷـﺪه از ﻃﺮﻳـﻖ ﺳﻴـﺴﺘﻢ را‬ ‫ﻣﻲدﻫﻨﺪ‪ .‬اﻣﻨﻴﺖ ﻣﻄﻤﺌﻦ ﺑﻪ واﺳﻄﻪ ﻣﺨﻔﻲ ﻛﺮدن ﻓﺎﻳﻞ ﻫﺎي ﭘﻨﻬﺎن ﺑﺪﺳﺖ ﻣﻲآﻳﺪ‪.‬‬

‫ƒ‬

‫ﻛــﺪﻫﺎﻳﻲ ﻛــﻪ ﺳﻴﺎﺳــﺖ ﻛﻨﺘــﺮل دﺳﺘﺮﺳــﻲ را اﺟــﺮا ﻣــﻲﻛﻨﻨــﺪ‪ ،‬ﻗــﺪﻳﻤﻲ ﻳــﺎ ﻧﺎﻛﺎرآﻣــﺪ ﻫــﺴﺘﻨﺪ‪ .‬ﺑــﺮاي ﻣﺜــﺎل ﺗــﺼﻮر ﻛﻨﻴــﺪ‬ ‫‪ /approveTransfer.do‬ﺳﺎﺑﻘﺎً ﺑﺮاي ﻫﻤﻪ ﻛﺎرﺑﺮان در دﺳﺘﺮس ﺑﻮد اﻣﺎ زﻣﺎﻧﻲ ﻛﻪ ﻛﻨﺘﺮلﻫﺎي ‪ SOX‬آورده ﺷـﺪﻧﺪ‪ ،‬ﺗﻨﻬـﺎ‬ ‫ﺑﺮاي ﻛﺎرﺑﺮان ﺗﺎﻳﻴﺪ ﺷﺪه ﻗﺎﺑﻞ دﺳﺘﺮﺳﻲ ﻣﻲ ﺑﺎﺷﻨﺪ‪ .‬ﺗﻨﻈﻴﻤﺎت ﺑﺎﻳﺪ ﺑﮕﻮﻧﻪاي ﺑﺎﺷﺪ ﻛﻪ ﺑﺮاي ﻛﺎرﺑﺮان ﻏﻴﺮﻣﺠﺎز اراﻳﻪ ﻧﺸﻮد‪ ،‬اﻣـﺎ‬ ‫در زﻣﺎن درﺧﻮاﺳﺖ ﺻﻔﺤﻪ واﻗﻌﺎً ﻫﻴﭻ ﻛﻨﺘﺮل دﺳﺘﺮﺳﻲ اﺟﺮا ﻧﺸﻮد‪.‬‬

‫‪٤٢‬‬

‫‪OWASP Top 10 2007‬‬

‫ƒ‬

‫ﻛﺪي ﻛﻪ ﻣﺠﻮزﻫﺎ را ﺗﻨﻬﺎ ﺑﺮ روي ﻛﻼﻳﻨﺖ ارزﻳﺎﺑﻲ ﻣﻲﻛﻨﺪ ﻧﻪ ﺑﺮ روي ﺳﺮور‪ .‬ﻣﺎﻧﻨـﺪ ﺣﻤﻠـﻪ ﺑـﺮروي ‪MacWord 2007‬‬ ‫)ﻛﻪ اﻧﺘﻘﺎل ﭘﻼﺗﻴﻦ ﺑﻪ ارزش ‪ 1700‬دﻻر از ﻃﺮﻳﻖ ‪ JavaScript‬روي ﻣﺮروﮔﺮ ﺻﻮرت ﮔﺮﻓﺖ‪(.‬‬

‫ﺑﺮرﺳﻲ اﻣﻨﻴﺖ‬ ‫ﻫﺪف‪ ،‬ﺑﺮرﺳﻲ اﺟﺮاي ﺳﺎزﮔﺎر ﻛﻨﺘﺮل دﺳﺘﺮﺳﻲ ﺑﺮاي ﻫﻤـﻪ ‪ URL‬ﻫـﺎي ﻣﻮﺟـﻮد در ﻧـﺮماﻓـﺰار در ﻻﻳـﻪ ﻧﻤـﺎﻳﺶ و ﻣﻨﻄـﻖ ﺗﺠـﺎرت‬ ‫)‪ (business logic‬ﻣﻲ ﺑﺎﺷﺪ‪.‬‬ ‫روشﻫﺎي ﺧﻮدﻛﺎر‪ :‬ﻣﺎداﻣﻲ ﻛﻪ ﻣﻮﺗﻮرﻫﺎي ﺗﺤﻠﻴﻞ اﻳﺴﺘﺎ در ﺗﻌﻴﻴﻦ روش ﻛﻨﺘﺮلﻫﺎي دﺳﺘﺮﺳﻲ در ﻛﺪﻫﺎ و ﻟﻴﻨﻚ ﻫﺎي ﻻﻳﻪ ﻧﻤـﺎﻳﺶ ﺑـﺎ‬ ‫ﻣﻨﻄﻖ ﺗﺠﺎري درﮔﻴﺮ ﻫﺴﺘﻨﺪ‪ ،‬ﭘﻮﻳﺸﮕﺮﻫﺎي آﺳﻴﺐﭘﺬﻳﺮي و اﺑﺰارﻫﺎي ﺗﺤﻠﻴﻞ اﻳﺴﺘﺎ ﺑﺪﻻﻳﻞ ﻣﺨﺘﻠﻒ در ﺑﺮرﺳﻲ ﻛﻨﺘﺮل دﺳﺘﺮﺳـﻲ ‪URL‬‬ ‫ﺑﺎ ﻣﺸﻜﻞ ﻣﻮاﺟﻪ ﻫﺴﺘﻨﺪ‪ .‬ﭘﻮﻳﺸﮕﺮﻫﺎي آﺳﻴﺐﭘﺬﻳﺮي در ﺗﺸﺨﻴﺺ ﺻﻔﺤﺎت ﻣﺨﻔﻲ و ﺗﻌﻴﻴﻦ ﻣﺠﺎز ﺑـﻮدن ﺻـﻔﺤﺎت ﺑـﺮاي ﻛـﺎرﺑﺮان ﺑـﺎ‬ ‫ﻣﺸﻜﻞ ﻣﻮاﺟﻪ ﻣﻲﮔﺮدﻧﺪ‪.‬‬ ‫روش ﻫﺎي دﺳﺘﻲ‪ :‬روش ﻣﻮﺛﺮ و دﻗﻴﻖﺗﺮ ﺑﺮاي ﺑﺮرﺳﻲ ﻣﻜﺎﻧﻴﺰم ﻛﻨﺘﺮل دﺳﺘﺮﺳﻲ اﺳﺘﻔﺎده از ﺗﺮﻛﻴﺒﻲ از ﺑﺎزﺑﻴﻨﻲ ﻛـﺪ و آزﻣـﺎﻳﺶ اﻣﻨﻴـﺖ‬ ‫اﺳﺖ‪ .‬اﮔﺮ ﻣﻜﺎﻧﻴﺰم ﺑﻪ ﺻﻮرت ﺗﻤﺮﻛﺰ ﻳﺎﻓﺘﻪ اﻧﺠﺎم ﮔﻴﺮد ﺑﺎزﺑﻴﻨﻲ ﻣﻲﺗﻮاﻧﺪ ﻛﺎﻣﻼً ﻣﻮﺛﺮ ﺑﺎﺷﺪ‪ .‬اﮔﺮ ﻣﻜـﺎﻧﻴﺰم در ﻣﻴـﺎن ﺗﻤـﺎﻣﻲ ‪codebase‬‬ ‫ﺗﻮزﻳﻊ ﺷﺪه ﺑﺎﺷﺪ ﺑﺎزﺑﻴﻨﻲ زﻣﺎنﺑﺮ ﺧﻮاﻫﺪ ﺑﻮد و اﮔﺮ ﻣﻜﺎﻧﻴﺰم از ﺧﺎرج اﺟﺮا ﺷﻮد ﭘﻴﻜﺮﺑﻨﺪي ﻧﻴﺰ ﺑﺎﻳﺪ ﺑﺎزرﺳﻲ و آزﻣﺎﻳﺶ ﮔﺮدد‪.‬‬

‫ﻣﺤﺎﻓﻈﺖ‬ ‫ﮔﺎم ﻛﻠﻴﺪي در ﻣﻘﺎﺑﻞ دﺳﺘﺮﺳﻲ ﻧﺎﻣﺤﺪود ‪ ،URL‬ﻃﺮحرﻳﺰي ﻣﺠﺎزﺷﻤﺎري از ﻃﺮﻳﻖ اﻳﺠـﺎد ﻳـﻚ ﻣـﺎﺗﺮﻳﺲ ﺑـﺮاي ﺗﺮﺳـﻴﻢ ﻧﻘـﺶﻫـﺎ و‬ ‫وﻇﺎﻳﻒ ﻧﺮماﻓﺰار ﻣﻲﺑﺎﺷﺪ‪ .‬ﻧﺮماﻓﺰارﻫﺎي ﺗﺤﺖ وب ﻛﻨﺘﺮل دﺳﺘﺮﺳﻲ را ﺑﺎﻳﺪ ﺑﺮروي ﻫﺮ ﻋﻤﻠﻜﺮد ﺗﺠﺎري و ‪ URL‬اﺟﺮا ﻛﻨﻨﺪ‪ .‬ﮔﺬاﺷـﺘﻦ‬ ‫ﻛﻨﺘﺮل دﺳﺘﺮﺳﻲ در ﻻﻳﻪ ﻧﻤﺎﻳﺶ و ﺑﺪون ﻣﺤﺎﻓﻈﺖ رﻫﺎ ﻛﺮدن ﻣﻨﻄﻖ ﺗﺠﺎري ﻣﻮﺛﺮ ﻧﻤﻲﺑﺎﺷﺪ‪ .‬ﺑﺮرﺳﻲ ﻳﻜﺒﺎره ﻣﺠﺎز ﺑﻮدن ﻛﺎرﺑﺮ در ﻃـﻮل‬ ‫ﻓﺮآﻳﻨﺪ و ﻋﺪم ﺑﺮرﺳﻲ ﻣﺠﺪد آن در ﮔﺎم ﻫﺎي ﺑﻌﺪي ﻛﺎﻓﻲ ﻧﻴﺴﺖ‪ .‬ﺑﺎ اﻳـﻦ ﺣـﺎل ﻳـﻚ ﻣﻬـﺎﺟﻢ ﻣـﻲ ﺗﻮاﻧـﺪ ﺑـﺴﺎدﮔﻲ از ﻣﺮﺣﻠـﻪاي ﻛـﻪ‬ ‫ﻣﺠﺎزﺷﻤﺎري ﺑﺮرﺳﻲ ﻣﻲﺷﻮﻧﺪ‪ ،‬ﺑﮕﺬرد و ﻣﻘﺎدﻳﺮ ﭘﺎراﻣﺘﺮ ﺿﺮوري اوﻟﻴﻪ را در ﮔﺎم ﺑﻌﺪي ﺟﻌﻞ ﻛﻨﺪ‪.‬‬ ‫ﻓﻌﺎل ﻛﺮدن ﻛﻨﺘﺮل دﺳﺘﺮﺳﻲ ‪ URL‬ﺑﺮﻧﺎﻣﻪرﻳﺰي دﻗﻴﻘﻲ را ﻣﻲﻃﻠﺒﺪ‪ .‬ﻛﻪ ﻣﻬﻤﺘﺮﻳﻦ ﻣﻼﺣﻈﺎت ﺷﺎﻣﻞ ﻣﻮارد ذﻳﻞ ﻣﻲﮔﺮدد‪:‬‬ ‫ƒ‬

‫اﻃﻤﻴﻨﺎن از اﻳﻨﻜﻪ ﻣﺎﺗﺮﻳﺲ ﻛﻨﺘﺮل دﺳﺘﺮﺳﻲ ﺑﺨﺸﻲ از ﺗﺠﺎرت‪ ،‬ﻣﻌﻤﺎري و ﻃﺮاﺣﻲ ﻧﺮماﻓﺰار اﺳﺖ‪.‬‬

‫‪٤٣‬‬

‫ƒ‬

‫از ﻣﺤﺎﻓﻈﺖ از ﺗﻤﺎﻣﻲ ‪URL‬ﻫﺎ و ﻋﻤﻠﻜﺮدﻫﺎي ﺗﺠﺎري ﺑـﻪ وﺳـﻴﻠﻪ ﻣﻜـﺎﻧﻴﺰم ﻛﻨﺘـﺮل دﺳﺘﺮﺳـﻲ ﻣـﻮﺛﺮ ﻛـﻪ ﻧﻘـﺶ ﻛـﺎرﺑﺮ و‬ ‫درﺧﻮاﺳﺖ ﻫﺎي ﻗﺒﻠﻲ او را ﺑﺮاي ﻫﺮ ﭘﺮدازش ﺑﺮرﺳﻲ ﻣﻲﻛﻨﺪ اﻃﻤﻴﻨﺎن ﺣﺎﺻﻞ ﻛﻨﻴﺪ‪ .‬از اﻳﻨﻜﻪ اﻳﻦ روش ﻧـﻪ ﻓﻘـﻂ ﻳـﻚ ﺑـﺎر‬ ‫ﺑﺮاي آﻏﺎز ﻓﺮآﻳﻨﺪ ﭼﻨﺪ ﻣﺮﺣﻠﻪاي‪ ،‬ﺑﻠﻜﻪ در ﻃﻮل ﻫﺮ ﻣﺮﺣﻠﻪ اﻧﺠﺎم ﻣﻲﮔﻴﺮد اﻃﻤﻴﻨﺎن ﺣﺎﺻﻞ ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫ﺑﺮاي اﻃﻤﻴﻨﺎن از ﻋﺪم ﺑﻬﺮهﺑﺮداري ﻧﺮماﻓﺰار ﺑﻮﺳﻴﻠﻪ ﻣﻬﺎﺟﻢ ﻣﺎﻫﺮ و ﺑﺎ اﻧﮕﻴﺰه‪ ،‬آزﻣﺎﻳﺶ ﻧﻔﻮذﭘﺬﻳﺮي را ﻗﺒﻞ از اﻳﺠـﺎد و ﺗﺤﻮﻳـﻞ‬ ‫ﻛﺪ اﺟﺮا ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫ﺑﻪ ﻓﺎﻳﻠﻬﺎي ‪ ، include/library‬ﻣﺨﺼﻮﺻﺎ اﮔﺮ ﺷﺎﻣﻞ ﭘﺴﻮﻧﺪ اﺟﺮاﻳﻲ ﻣﺎﻧﻨﺪ ‪ .php‬ﺑﺎﺷﻨﺪ ﺗﻮﺟﻪ وﻳﮋهاي داﺷﺘﻪ ﺑﺎﺷـﻴﺪ‪ ،‬و در‬ ‫ﺻﻮرت اﻣﻜﺎن آﻧﻬﺎ را ﺧﺎرج از ‪ web root‬ﻧﮕﻬﺪاري ﻛﻨﻴﺪ‪ .‬آﻧﻬﺎ ﺑﺎﻳﺪ ﺑﺮاي ﻋﺪم دﺳﺘﺮﺳﻲ ﻣﺴﺘﻘﻴﻢ ﻣﺎﻧﻨﺪ ﺑﺮرﺳﻲ ﻣﻘﺎدﻳﺮ ﺛﺎﺑﺖ‬ ‫ﻛﻪ ﺗﻨﻬﺎ ﻣﻲ ﺗﻮاﻧﺪ ﺑﻮﺳﻴﻠﻪ ﻓﺮاﺧﻮاﻧﻲ ﻛﺘﺎﺑﺨﺎﻧﻪاي )‪ (library's caller‬اﻳﺠﺎد ﺷﻮد ﺑﺮرﺳﻲ ﺷﻮد‪ .‬ﮔﻤﺎن ﻧﻜﻨﻴﺪ ﻛـﻪ ﻛـﺎرﺑﺮان از‬ ‫‪ URL‬ﻫﺎ ﻳﺎ ‪ API‬ﻫﺎي ﻣﺨﻔﻲ و ﺧﺎص ﺑﻲﺧﺒﺮ ﻫﺴﺘﻨﺪ‪ .‬ﻫﻤﻴﺸﻪ از ﻣﺤﺎﻓﻈﺖ از ﻓﻌﺎﻟﻴﺖﻫﺎي راﻫﺒﺮي و ﻣﺠﻮزﻫﺎي ﺳﻄﺢ ﺑﺎﻻ‬ ‫اﻃﻤﻴﻨﺎن ﺣﺎﺻﻞ ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫دﺳﺘﺮﺳﻲ ﺑﻪ اﻧﻮاع ﻓﺎﻳﻞﻫﺎﻳﻲ ﻛﻪ ﻧﺒﺎﻳﺪ در ﻧﺮماﻓﺰار ﺑﻜﺎر ﮔﺮﻓﺘﻪ ﺷﻮﻧﺪ را ﺑﺮرﺳﻲ ﻛﻨﻴﺪ‪ ،‬ﺑﻪ ﻃﻮر ﻛﺎﻣﻞ اﻳـﻦ ﻓﻴﻠﺘـﺮ ﺑﺎﻳـﺪ دﻳـﺪﮔﺎه‬ ‫"‪ "accept known good‬را دﻧﺒﺎل ﻛﻨﺪ و ﻓﻘﻂ اﻧﻮاع ﻓﺎﻳﻞ ﻫﺎﻳﻲ ﻛﻪ ﻗﺼﺪ ﺑﻜﺎرﮔﻴﺮي آﻧﻬـﺎ را دارﻳـﺪ ﻣﺎﻧﻨـﺪ ‪php, pdf,‬‬ ‫‪ html‬را ﻣﺠﺎز ﺷﻤﺎرد و ﻫﺮﮔﻮﻧﻪ ﺗﻼش ﺑﺮاي دﺳﺘﺮﺳﻲ ﺑﻪ ﻓﺎﻳﻠﻬﺎي ﺛﺒﺖ‪ ،‬ﻓﺎﻳﻠﻬﺎي ‪ XML‬و ‪ ...‬را ﻛﻪ ﻫﺮﮔﺰ ﻗﺼﺪ ﺑﻜﺎرﮔﻴﺮي‬ ‫ﻣﺴﺘﻘﻴﻢ آﻧﻬﺎ را ﻧﺪارﻳﺪ‪ ،‬ﻣﺴﺪود ﻛﻨﺪ‪.‬‬

‫ƒ‬

‫اﺟﺰاﻳﻲ ﻣﺎﻧﻨﺪ ﭘﺮدازﺷﮕﺮ ‪ ،XML‬ﭘﺮدازﺷﮕﺮ واژه‪ ،‬ﭘﺮدازﺷﮕﺮ ﺗﺼﻮﻳﺮ و ‪ ...‬ﻛﻪ ﺑﺎ وروديﻫﺎي ﻛﺎرﺑﺮ ﺳﺮوﻛﺎر دارﻧـﺪ از ﻃﺮﻳـﻖ‬ ‫ﺣﻔﺎﻇﺖ در ﻣﻘﺎﺑﻞ وﻳﺮوس و ‪ patch‬ﻫﺎ ﺑﻪروز ﻧﮕﻪ دارﻳﺪ‪.‬‬

‫ﻧﻤﻮﻧﻪ ﻫﺎ‬ ‫‪http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0147‬‬ ‫‪http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0131‬‬ ‫‪http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1227‬‬

‫ƒ‬ ‫ƒ‬ ‫ƒ‬

‫ﻣﺮاﺟﻊ‬ ‫‪CWE: CWE-325 (Direct Request), CWE-288 (Authentication Bypass by Alternate Path),‬‬ ‫)‪CWE-285 (Missing or Inconsistent Access Control‬‬ ‫‪WASC Threat Classification:‬‬ ‫‪http://www.webappsec.org/projects/threat/classes/predictable_resource_location.shtml‬‬

‫‪٤٤‬‬

‫ƒ‬ ‫ƒ‬

OWASP Top 10 2007 ƒ ƒ

OWASP, http://www.owasp.org/index.php/Forced_browsing OWASP Guide, http://www.owasp.org/index.php/Guide_to_Authorization

٤٥

‫ﻣﻘﺼﺪ ﻧﻬﺎﻳﻲ‬ ‫‪ ، OWASP Top 10‬ﺗﻨﻬﺎ ﺳﺮآﻏﺎزي ﺑﺮاي اﻣﻨﻴﺖ ﻧﺮم اﻓﺰارﻫﺎي ﺗﺤﺖ وب اﺳﺖ‪.‬‬

‫» ﺟﻤﻌﻴﺖ ‪ 6‬ﻣﻴﻠﻴﺎردي ﺟﻬﺎن ﺑﻪ دو ﮔﺮوه ﺗﻘﺴﻴﻢ ﻣﻲ ﺷﻮﻧﺪ‪ :‬ﮔﺮوه اول‪ ،‬ﻛﺴﺎﻧﻲ ﻛﻪ از ﻋﻠﺖ ارﺳـﺎل ﻣﺤـﺼﻮﻻت ﻫﻤـﺮاه ﺑـﺎ ﺣﻔـﺮه ﻫـﺎ‬ ‫)‪ (Bug‬ﺗﻮﺳﻂ ﺷﺮﻛﺖ ﻫﺎي ﻧﺮم اﻓﺰاري اﻃﻼع دارﻧﺪ؛ و ﮔﺮوه دوم‪ ،‬ﻛﺴﺎﻧﻲ ﻛﻪ اﻃﻼع ﻧﺪارﻧﺪ‪ .‬ﮔﺮوه اول ﺗﻤﺎﻳﻞ دارﻧﺪ ﺗﺎ ﻓﺮاﻣﻮش ﻛﻨﻨﺪ‬ ‫ﻛﻪ زﻧﺪﮔﻲ ﻣﻲ ﺗﻮاﻧﺴﺖ ﺷﺒﻴﻪ روﻳﺎﻫﺎي ﺟﻮاﻧﻲ ﺑﺎﺷﺪ‪ ،‬ﻗﺒﻞ از اﻳﻨﻜﻪ ﺑﺎ واﻗﻴﺖ زﻧﺪﮔﻲ از ﺑﻴﻦ ﺑﺮود‪ .‬ﻏﺎﻟﺒـﺎ ﻣـﺎ ﺑـﺎ اﻓـﺮادي در ﮔـﺮوه دوم‬ ‫ﻣﻮاﺟﻪ ﻫﺴﺘﻴﻢ‪ ...‬ﻛﻪ ﻫﻤﻴﺸﻪ از اﻳﻨﻜﻪ ﺷﺮﻛﺖ ﻫﺎي ﻧﺮم اﻓﺰاري ﻣﺤـﺼﻮﻻت را ﻗﺒـﻞ از رﻓـﻊ ﺣﻔـﺮه ﻫـﺎ وارد ﺑـﺎزار ﻣـﻲ ﻛﻨﻨـﺪ‪ ،‬ﺷـﻮﻛﻪ‬ ‫ﻣﻲ ﺷﻮﻧﺪ‪«.‬‬ ‫اِرﻳﻚ ﺳﻴﻨﻚ‪ ،‬روزﻧﺎﻣﻪ ﮔﺎردﻳﻦ‪ 25 ،‬ﻣﻲ ‪2006‬‬ ‫اﻛﺜﺮ ﻛﺎرﺑﺮان و ﻣﺸﺘﺮﻳﺎن در ﮔﺮوه دوم ﺟﺎي ﻣﻲ ﮔﻴﺮﻧﺪ‪ .‬ﺑﺎ اﺳﺘﻔﺎده از اﻳﻦ ﻓﺮﺻﺖ ﻣﻲ ﺗﻮاﻧﻴﺪ ﺑﺮاي اﺻﻼح ﺑﺮﻧﺎﻣﻪ و ﺑﻪ ﻃﻮر ﻛﻠﻲ ﻛﻴﻔﻴﺖ‬ ‫اﻣﻨﻴﺖ ﻧﺮم اﻓﺰار ﺗﺤﺖ وب اﻗﺪام ﻛﻨﻴﺪ‪ .‬ﻫﺮ ﺳﺎﻟﻪ ﻣﻴﻠﻴﺎردﻫﺎ دﻻر ﻣﻔﻘﻮد ﻣﻲ ﺷﻮد و ﻣﻴﻠﻴﻮﻧﻬﺎ ﻧﻔﺮ از ﻃﺮﻳﻖ آﺳﻴﺐ ﭘﺬﻳﺮي ﻫﺎﻳﻲ ﻛﻪ در اﻳﻦ‬ ‫راﻫﻨﻤﺎ ﺑﻪ آن ﭘﺮداﺧﺘﻪ ﺷﺪ‪ ،‬از ﺳﺮﻗﺖ ﻫﻮﻳﺘﺸﺎن زﻳﺎن دﻳﺪه و ﻓﺮﻳﺐ ﻣﻲ ﺧﻮرﻧﺪ‪.‬‬

‫ﭘﻴﺸﻨﻬﺎداﺗﻲ ﺑﺮاي ﻃﺮاﺣﺎن ﻧﺮم اﻓﺰار‬ ‫ﺑﺮاي اﻳﻨﻜﻪ ﺑﺘﻮاﻧﻴﺪ از ﻧﺮم اﻓﺰار ﺑﺪرﺳﺘﻲ ﻣﺤﺎﻓﻈﺖ ﻛﻨﻴﺪ‪ ،‬ﺑﺎﻳﺪ ﺑﺪاﻧﻴﺪ ﻛﻪ از ﭼﻪ ﭼﻴـﺰي ﻣﺤﺎﻓﻈـﺖ ﻣـﻲ ﻛﻨﻴـﺪ )ﻃﺒﻘـﻪ ﺑﻨـﺪي دارﻳﻴﻬـﺎ(‪،‬‬ ‫ﺗﻬﺪﻳﺪات و ﻣﺨﺎﻃﺮاتِ ﻋﺪم ﻣﺤﺎﻓﻈﺖ را ﺑﺸﻨﺎﺳﻴﺪ و اﻳﻦ ﻣﻮارد را در ﻳﻚ ﺳﺎﺧﺘﺎر ﻧﺸﺎن دﻫﻴﺪ‪ .‬ﻃﺮاﺣـﻲ ﻧـﺮم اﻓـﺰار ﻫـﺎي ﺑـﺰرگ ﺑـﻪ‬ ‫درﻧﻈﺮﮔﺮﻓﺘﻦ ﺳﻬﻢ ﻋﻤﺪه اي از اﻣﻨﻴﺖ ﻧﻴﺎز دارﻧﺪ‪.‬‬

‫ƒ‬

‫از ﺑﻜﺎرﺑﺮدن ﻣﺤﺎﻓﻈﺖ »ﻛﺎﻓﻲ« ﺑﺮاﺳﺎس ﻣﺪل ﺳﺎزي ﻣﺨﺎﻃﺮه ﺗﻬﺪﻳﺪ و ﻃﺒﻘﻪ ﺑﻨﺪي داراﻳﻲ ﻫﺎ اﻃﻤﻴﻨﺎن ﺣﺎﺻﻞ ﻛﻨﻴﺪ‪ .‬اﮔـﺮ ﭼـﻪ‬ ‫رﻋﺎﻳﺖ ﻗﻮاﻧﻴﻦ )‪ Basel ، HIPAA ، SOX‬و ﻏﻴﺮه( ﺑﺎر ﻣﺴﺌﻮﻟﻴﺖ را اﻓﺰاﻳﺶ ﻣﻲ دﻫـﺪ‪) ،‬ﺑـﻪ وﻳـﮋه اﮔـﺮ ﺑﻬﺘـﺮﻳﻦ روش‬ ‫ﺷﻨﺎﺧﺘﻪ ﺷﺪه و ﺑﻄﻮر ﻗﺎﺑﻞ ﻣﻼﺣﻈﻪ اي ﺳﺨﺖ ﺗﺮ از ﺳﺎﻳﺮ ﻗﻮاﻧﻴﻦ ﺑﺎﺷﺪ‪ (.‬اﻣﺎ ﺻﺮف زﻣﺎن و ﻣﻨﺎﺑﻊ ﺑﻴﺸﺘﺮ‪ ،‬ﻧـﺴﺒﺖ ﺑـﻪ ﺑـﺴﻨﺪه‬ ‫ﻛﺮدن ﺑﻪ ﺣﺪاﻗﻞ اﻣﻜﺎﻧﺎت اﻣﺮوزي‪ ،‬ﻣﻨﺎﺳﺐ ﺗﺮ ﺑﻪ ﻧﻈﺮ ﻣﻲ رﺳﺪ‪.‬‬

‫ƒ‬

‫ﻧﻴﺎزﻫﺎي ﺗﺠﺎري ﺑﻮﻳﮋه ﻧﻴﺎزﻫﺎي ﻏﻴﺮﻋﻤﻠﻴﺎﺗﻲ و ﻧﺎﭘﻴﺪا را درﺧﻮاﺳﺖ ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫ﺑﺎ ﻣﺸﺘﺮي از ﻃﺮﻳﻖ ﺿﻤﻴﻤﻪ ﻗﺮارداد ﻣﺤﺎﻓﻈﺖ ﻧﺮم اﻓﺰار ‪ OWASP‬ﻫﻤﻜﺎري ﻛﻨﻴﺪ‪.‬‬

‫‪٤٦‬‬

‫‪OWASP Top 10 2007‬‬

‫ƒ‬

‫ﻃﺮاﺣﻲ ﻣﺤﺎﻓﻈﺖ ﻛﻨﻨﺪه ﺷﺎﻣﻞ دﻓﺎع در ﻋﻤﻖ )‪ (defense in depth‬و ﺳﺎده ﺳﺎزي ﺳﺎﺧﺘﺎرﻫﺎ ﺑﺎ اﺳﺘﻔﺎده از ﻣـﺪل ﺳـﺎزي‬ ‫ﺗﻬﺪﻳﺪ را ﺗﻘﻮﻳﺖ ﻛﻨﻴﺪ‪) .‬ﭼﮕﻮﻧﮕﻲ آن را در ﻣﻨﺎﺑﻊ ﺑﻴﺎﺑﻴﺪ‪(.‬‬

‫ƒ‬

‫از ﺗﻮﺟﻪ ﻛﺎﻓﻲ ﺑﻪ ﻣﺤﺮﻣﺎﻧﮕﻲ‪ ،‬ﻳﮕﭙﺎرﭼﮕﻲ‪ ،‬دﺳﺘﺮس ﭘﺬﻳﺮي و ﻋﺪم اﻧﻜﺎر اﻃﻤﻴﻨﺎن ﺣﺎﺻﻞ ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫ﺳﻴﺎﺳﺖ ﻫﺎ و اﺳﺘﺎﻧﺪاردﻫﺎي اﻣﻨﻴﺘﻲ ﻣﺎﻧﻨﺪ ‪ PCI DSS 1.1‬ﻳﺎ ‪ COBIT‬را در ﻃﺮاﺣﻲ ﻫﺎ در ﻧﻈﺮ ﺑﮕﻴﺮﻳﺪ‪.‬‬

‫ﭘﻴﺸﻨﻬﺎداﺗﻲ ﺑﺮاي ﻃﺮاﺣﺎن ﻧﺮم اﻓﺰار‬ ‫ﻣﺘﻦ ﺑﺎز ﭼﺎﻟﺶ ﺑﺰرﮔﻲ ﺑﺮاي اﻣﻨﻴﺖ ﻧﺮم اﻓﺰارﻫﺎي ﺗﺤﺖ وب اﺳﺖ‪ .‬ﻣﻴﻠﻴﻮﻧﻬﺎ ﭘﺮوژه ﻣﺘﻦ ﺑﺎز از ﭘﺮوژه ﻫـﺎي ﺑﺮﻧﺎﻣـﻪ ﻧﻮﻳـﺴﺎن ﺷﺨـﺼﻲ‬ ‫ﮔﺮﻓﺘﻪ ﺗﺎ ﭘﺮوژه ﻫﺎي ﺑﺰرگ ﻣﺎﻧﻨﺪ ‪ Apache, Tomcat‬و ﻧﺮم اﻓﺰارﻫﺎي ﺗﺤﺖ وب ﺑﺰرگ ﻣﻘﻴﺎس ﻣﺎﻧﻨﺪ ‪. PostNuke‬‬

‫ƒ‬

‫ﺑﺨﺶ ‪ joining OWASP‬را ﺑﺎزدﻳﺪ و در ﻫﻤﺎﻳﺶ ﻫﺎي ‪ local chapter‬ﺷﺮﻛﺖ ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫اﮔﺮ در ﭘﺮوژه ﺑﻴﺶ از ‪ 4‬ﻧﻔﺮ ﺑﺮﻧﺎﻣﻪ ﻧﻮﻳﺲ ﺳﻬﻴﻢ ﻫﺴﺘﻨﺪ‪ ،‬ﺗﻌﺪاد آﻧﻬﺎ را ﺑﻪ ﺣﺪاﻗﻞ ﻳﻚ ﺑﺮﻧﺎﻣﻪ ﻧﻮﻳﺲ ﻣﺴﻠﻂ ﺑﻪ اﻣﻨﻴﺖ ﻛـﺎﻫﺶ‬ ‫دﻫﻴﺪ‪.‬‬

‫ƒ‬

‫ﺧﺼﻮﺻﻴﺎت ﻧﺮم اﻓﺰار را ﺑﻪ ﺻﻮرت ﻛﺎﻣﻼ اﻣﻦ ﻃﺮاﺣﻲ و دﻓﺎع در ﻋﻤﻖ و ﺳﺎدﮔﻲ در ﻃﺮاﺣﻲ را ﻟﺤﺎظ ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫از اﺳﺘﺎﻧﺪاردﻫﺎي ﺑﺮﻧﺎﻣﻪ ﻧﻮﻳﺴﻲ ﻛﻪ ﺗﻘﻮﻳﺖ ﻛﻨﻨﺪه ﺳﺎﺧﺘﺎرﻫﺎي ﻣﺤﺎﻓﻈﺘﻲ ﺑﺮﻧﺎﻣﻪ ﻫﺴﺘﻨﺪ‪ ،‬اﺳﺘﻔﺎده ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫ﺑﺮاي اﻃﻤﻴﻨﺎن از ﻣﺪﻳﺮﻳﺖ ﺻﺤﻴﺢ ﻧﻘﺺ ﻫﺎي اﻣﻨﻴﺘﻲ‪ ،‬از ﺳﻴﺎﺳﺖ آﺷﻜﺎرﺳﺎزي اﺳﺘﻔﺎده ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫ﻣﻨﺎﺑﻊ را ﺑﺮرﺳﻲ و در ﺻﻮرت اﺟﺮاﻳﻲ و ﻣﺘﻨﺎﺳﺐ ﺑﻮدن ﺑﺎ ﻣﺤﻴﻂ آﻧﻬﺎ را ﺑﻜﺎر ﮔﻴﺮﻳﺪ‪.‬‬

‫ﭘﻴﺸﻨﻬﺎداﺗﻲ ﺑﺮاي ﺻﺎﺣﺒﺎن ﻧﺮم اﻓﺰار‬ ‫ﺻﺎﺣﺒﺎن ﻧﺮم اﻓﺰار ﺑﺮاي در ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﺗﻨﻈﻴﻤﺎت ﺗﺠﺎري در زﻣﺎن و ﻣﻨﺎﺑﻊ داراي ﻣﺤﺪودﻳﺖ ﻫﺴﺘﻨﺪ‪ .‬ﺻﺎﺣﺒﺎن ﻧﺮم اﻓـﺰار ﺑﺎﻳـﺪ ﻣـﻮارد‬ ‫ذﻳﻞ را در ﻧﻈﺮ ﺑﮕﻴﺮﻧﺪ‪:‬‬

‫ƒ‬

‫ﺑﺎ ﺗﻮﻟﻴﺪﻛﻨﻨﺪﮔﺎن ﻧﺮم اﻓﺰار از ﻃﺮﻳﻖ ﺿﻤﻴﻤﻪ ﻗﺮارداد ﻣﺤﺎﻓﻈﺘﻲ ﻧﺮم اﻓﺰار ‪ OWASP‬ﻫﻤﻜﺎري ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫اﻃﻤﻴﻨﺎن ﺣﺎﺻﻞ ﻛﻨﻴﺪ ﻛﻪ ﻧﻴﺎزﻫﺎي ﺗﺠﺎري ﺑﺮﻧﺎﻣﻪ ﺷﺎﻣﻞ ﻧﻴﺎزﻫﺎي ﻏﻴﺮﻋﻤﻠﻴﺎﺗﻲ )‪ (NFR‬ﻫﺎ ﻣﺎﻧﻨﺪ ﻧﻴﺎزﻫﺎي اﻣﻨﻴﺘﻲ ﺑﺎﺷﻨﺪ‪.‬‬

‫ƒ‬

‫ﺑﺮﻧﺎﻣﻪ ﻧﻮﻳﺴﺎﻧﻲ ﻛﻪ داراي ﺳﺎﺑﻘﻪ ﺧﻮﺑﻲ در ﺣﻮزه اﻣﻨﻴﺖ ﻫﺴﺘﻨﺪ را آﻣﻮزش داده ﻳﺎ اﺳﺘﺨﺪام ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫آزﻣﺎﻳﺶ ﻧﻘﺺ ﻫﺎي اﻣﻨﻴﺘﻲ را در ﺗﻤﺎم ﻣﺮاﺣﻞ ﭘﺮوژه اﻋﻢ از ﻃﺮاﺣﻲ‪ ،‬ﺳﺎﺧﺖ‪ ،‬آزﻣﺎﻳﺶ و اﺟﺮا ﺑﻜﺎرﮔﻴﺮﻳﺪ‪.‬‬

‫ƒ‬

‫ﺑﺮاي ﺣﺼﻮل ﻧﺘﻴﺠﻪ ﺑﻬﺘﺮ در ﺑﺮﻧﺎﻣﻪ ﭘﺮوژه‪ ،‬ﺻﺮف ﻣﻨﺎﺑﻊ ‪ ،‬ﺑﻮدﺟﻪ و زﻣﺎن ﻻزم را در ﻧﻈﺮ ﺑﮕﻴﺮﻳﺪ‪.‬‬

‫‪٤٧‬‬

‫ﭘﻴﺸﻨﻬﺎداﺗﻲ ﺑﺮاي ﻣﺠﺮﻳﺎن ﺳﻄﻮح ﭘﺎﻳﻴﻦ ﺗﺮ‬ ‫ﺳﺎزﻣﺎن ﺑﺎﻳﺪ داراي ﭼﺮﺧﻪ ﺣﻴﺎت ﺗﻮﺳﻌﻪ اﻣﻦ )‪ (SDLC‬ﺑﻪ ﺟﺎ و ﻣﻨﺎﺳﺐ ﺑﺎ ﺳﺎزﻣﺎن ﺑﺎﺷﺪ‪ .‬آﺳﻴﺐ ﭘﺬﻳﺮي ﻫﺎ آﻧﻘﺪر ﻧﺎﭼﻴﺰ ﻫﺴﺘﻨﺪ ﻛـﻪ‬ ‫ﺗﺮﺟﻴﺢ ﻣﻲ دﻫﻴﻢ آﻧﻬﺎ را ﺑﻌﺪ از اراﻳﻪ ﻣﺤﺼﻮل در ﺑﺎزار رﻓﻊ ﻛﻨﻴﻢ ﺗﺎ در زﻣﺎن ﺗﻮﻟﻴﺪ آن‪ SDLC .‬ﻗﺎﺑﻞ ﻗﺒﻮل ﻧﻪ ﺗﻨﻬـﺎ ﺷـﺎﻣﻞ ﻣﺮاﺣـﻞ‬ ‫آزﻣﺎﻳﺸﻲ ‪ TOP 10‬ﺑﻠﻜﻪ ﺷﺎﻣﻞ ﻣﺮاﺣﻞ زﻳﺮ ﻣﻲ ﺑﺎﺷﺪ‪:‬‬

‫ƒ‬

‫ﺑﺮاي ﻧﺮم اﻓﺰار اﺳﺘﺎﻧﺪارد‪ ،‬از اﻳﻨﻜﻪ ﺳﻴﺎﺳﺖ ﻫﺎ و ﻗﺮاردادﻫﺎﻳﻲ ﻛﻪ داراي ﻣﻠﺰوﻣﺎت اﻣﻨﻴﺘﻲ ﻫﺴﺘﻨﺪ اﻃﻤﻴﻨﺎن ﺣﺎﺻﻞ ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫در ﺑﺮﻧﺎﻣﻪ ﻧﻮﻳﺴﻲ ﺳﻔﺎرﺷﻲ‪ ،‬اﺻﻮل ﺑﺮﻧﺎﻣﻪ ﻧﻮﻳﺴﻲ ﻣﺤﺎﻓﻈﺘﻲ را در ﺳﻴﺎﺳﺖ ﻫﺎ و اﺳﺘﺎﻧﺪاردﻫﺎ رﻋﺎﻳﺖ ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫ﺑﺮﻧﺎﻣﻪ ﻧﻮﻳﺴﺎن را ﺑﺎ ﻣﻬﺎرت ﻫﺎي ﺑﺮﻧﺎﻣﻪ ﻧﻮﻳﺴﻲ اﻣﻦ آﻣﻮزش داده و از ﺑﻪ روز ﺑﻮدن ﻣﻬﺎرت ﻫﺎﻳﺸﺎن اﻃﻤﻴﻨﺎن ﺣﺎﺻﻞ ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫اﺑﺰارﻫﺎي اﻣﻨﻴﺘﻲ ﺗﺤﻠﻴﻞ ﻛﺪ را در ﺑﻮدﺟﻪ ﺑﺮﻧﺎﻣﻪ در ﻧﻈﺮ ﺑﮕﻴﺮﻳﺪ‪.‬‬

‫ƒ‬

‫اﻫﻤﻴﺖ ﺑﻜﺎرﮔﻴﺮي اﻣﻨﻴﺖ در ﺣﺼﻮل ﻧﺘﻴﺠﻪ ﻧﻬﺎﻳﻲ را ﺑﺮاي ﺗﻮﻟﻴﺪﻛﻨﻨﺪﮔﺎن ﻧﺮم اﻓﺰار روﺷﻦ ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫اﺻﻮل اﻣﻨﻴﺘﻲ ﻧﺮم اﻓﺰار ﺗﺤﺖ وب را ﺑﻪ ﻣﻌﻤﺎران‪ ،‬ﻃﺮاﺣﺎن و ﺑﺎزرﮔﺎﻧﺎن آﻣﻮزش دﻫﻴﺪ‪.‬‬

‫ƒ‬

‫از ﺗﺤﻠﻴﻞ ﮔﺮان ﺑﺮﻧﺎﻣﻪ ﻛﻪ داراي ﺗﺸﺨﻴﺺ ﻣﺴﺘﻘﻞ ﻫﺴﺘﻨﺪ اﺳﺘﻔﺎده ﻛﻨﻴﺪ‪.‬‬

‫ƒ‬

‫ﺷﻴﻮه ﻫﺎي ﭘﺎﺳﺨﮕﻮﻳﻲ و آﺷﻜﺎرﺳﺎزي را ﺑﻜﺎرﮔﺮﻓﺘﻪ و روﻧﺪي را ﺑﺮاي ﭘﺎﺳﺨﮕﻮﻳﻲ ﻣﻨﺎﺳﺐ ﺑـﻪ ﮔﺰارﺷـﺎت آﺳـﻴﺐ ﭘـﺬﻳﺮي‬ ‫ﺑﺮاي ﻣﺤﺼﻮﻻت اﻳﺠﺎد ﻛﻨﻴﺪ‪.‬‬

‫‪٤٨‬‬

‫‪OWASP Top 10 2007‬‬

‫ﻣﻨﺎﺑﻊ‬ ‫ﭘﺮوژه ﻫﺎي ‪OWASP‬‬ ‫‪ OWASP‬ﻧﺨﺴﺘﻴﻦ ﺳﺎﻳﺖ در زﻣﻴﻨﻪ اﻣﻨﻴﺖ ﻧﺮم اﻓﺰارﻫﺎي ﺗﺤﺖ وب اﺳـﺖ‪ .‬ﺳـﺎﻳﺖ ‪ OWASP‬ﻣﻴﺰﺑـﺎن ﺑـﺴﻴﺎري از ﭘـﺮوژه ﻫـﺎ‪،‬‬ ‫اﻧﺠﻤﻦ ﻫﺎي ﮔﻔﺘﮕﻮ‪ ،‬ﺑﻼگ ﻫﺎ‪ ،‬اراﻳﻪ ﻣﻄﺎﻟﺐ‪ ،‬اﺑﺰارﻫﺎ و ﻣﻘﺎﻻت اﺳﺖ‪ OWASP .‬در ﺳﺎل ﻣﻴﺰﺑﺎن دو ﻛﻨﻔـﺮاﻧﺲ ﺑـﺰرگ اﻣﻨﻴﺘـﻲ ﻧـﺮم‬ ‫اﻓﺰار ﺗﺤﺖ وب و داراي ﺑﻴﺶ از ‪ 80‬ﺷﻌﺒﻪ ﻣﺤﻠﻲ اﺳﺖ‪.‬‬ ‫ﭘﺮوژه ﻫﺎي ﻣﻌﺮﻓﻲ ذﻳﻞ از ﭘﺮوژه ﻫﺎي ﺳﻮدﻣﻨﺪ ‪ OWASP‬ﻫﺴﺘﻨﺪ‪:‬‬

‫ƒ‬

‫راﻫﻨﻤﺎي ‪ OWASP‬ﺑﺮاي ﺳﺎﺧﺖ ﻧﺮم اﻓﺰار اﻣﻦ ﺗﺤﺖ وب‬

‫ƒ‬

‫راﻫﻨﻤﺎي آزﻣﺎﻳﺶ ‪OWASP‬‬

‫ƒ‬

‫ﭘﺮوژه ﻣﺮور ﻛﺪ ‪) OWASP‬در دﺳﺖ اﻗﺪام(‬

‫ƒ‬

‫ﭘﺮوژه ‪ PHP‬ي ‪) OWASP‬در دﺳﺖ اﻗﺪام(‬

‫ƒ‬

‫ﭘﺮوژه ‪ Java‬ي ‪OWASP‬‬

‫ƒ‬

‫ﭘﺮوژه ‪ .NET‬ي ‪OWASP‬‬

‫ﻛﺘﺎﺑﻬﺎ‬ ‫ﻓﻬﺮﺳﺖ زﻳﺮ ﻟﺰوﻣﺎ ﻓﻬﺮﺳﺘﻲ ﺟﺎﻣﻊ ﻧﺨﻮاﻫﺪ ﺑﻮد‪ .‬از ﻣﻨﺎﺑﻊ زﻳﺮ ﻣﻲ ﺗﻮاﻧﻴﺪ ﺑﺮاي ﻳﺎﻓﺘﻦ زﻣﻴﻨـﻪ ﻣﻨﺎﺳـﺐ در اﻧﺘﺨـﺎب ﻋﻨـﺎوﻳﻦ ﻣـﻮرد ﻧﻴـﺎز‬ ‫اﺳﺘﻔﺎده ﻛﻨﻴﺪ‪:‬‬ ‫‪[ALS1] Alshanetsky, I. “php|architect's Guide to PHP Security”, ISBN 0973862106‬‬

‫ƒ‬

‫‪*BAI1+ Baier, D., “Developing more secure ASP.NET 2.0 Applications”, ISBN 978-0‬‬‫‪7356-2331-6‬‬

‫ƒ‬

‫‪[GAL1] Gallagher T., Landauer L., Jeffries B., "Hunting Security Bugs", Microsoft‬‬ ‫‪Press, ISBN 073562187X‬‬

‫ƒ‬

‫‪[GRO1] Fogie, Grossman, Hansen, Rager, “Cross Site Scripting Attacks: XSS Exploits‬‬ ‫‪and Defense”, ISBN 1597491543‬‬

‫ƒ‬

‫‪[HOW1] Howard M., Lipner S., "The Security Development Lifecycle", Microsoft Press,‬‬ ‫‪ISBN 0735622140‬‬

‫ƒ‬

‫‪٤٩‬‬

ƒ

[SCH1] Schneier B., "Practical Cryptography", Wiley, ISBN 047122894X

ƒ

*SHI1+ Shiflett, C., “Essential PHP Security”, ISBN 059600656X

ƒ

[WYS1] Wysopal et al, The Art of Software Security Testing: Identifying Software Security Flaws, ISBN 0321304861

‫وب ﺳﺎﻳﺖ ﻫﺎ‬ http://www.owasp.org ، OWASP ،‫ ﺷﻤﺎرﻧﺪه ﺿﻌﻒ ﻫﺎي راﻳﺞ– آﻟﻮدﮔﻴﻬﺎي ﻧﺎﺷﻲ از آﺳﻴﺐ ﭘﺬﻳﺮي‬، MITRE http://cwe.mitre.org/documents/vuln-trends.html http://www.webappsec.org/ ، ‫ﻛﻨﺴﺮﺳﻴﻮم اﻣﻨﻴﺘﻲ ﻧﺮم اﻓﺰارﻫﺎي ﺗﺤﺖ وب‬ http://www.sans.org/top20/ ، SANS TOP 20 ‫ واﺑﺴﺘﻪ ﺑﻪ ﻛﻠﻴﻪ ﺳﺎزﻣﺎن ﻫﺎﻳﻲ ﻛﻪ اﻃﻼﻋﺎت ﻛﺎرﺗﻬﺎي اﻋﺘﺒـﺎري‬، PCI ‫ ﻧﺎﺷﺮ اﺳﺘﺎﻧﺪاردﻫﺎي‬، PCI ‫اﻧﺠﻤﻦ اﻣﻨﻴﺘﻲ اﺳﺘﺎﻧﺪاردﻫﺎ‬

ƒ ƒ ƒ ƒ ƒ

https://www.pcisecuritystandards.org/ ،‫را ﭘﺮدازش و ﻧﮕﻬﺪاري ﻣﻲ ﻛﻨﻨﺪ‬ https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf ، PCI DSS v1.1 https://buildsecurityin.us-cert.gov/daisy/bsi/home.html ،US CERT ‫ﺑﻨﻴﺎد اﻣﻨﻴﺖ‬

٥٠

ƒ ƒ