‫ﻧﻔﻮﺫ ﺩﺭ ﺳﺮﻭﺭﻫﺎﻱ ﻭﺏ‬

‫» ﺑﺨﺶ ﺍﻭﻝ «‬

‫ﻧﻔﻮﺫ ﺩﺭ ﺳﺮﻭﺭ ‪Apache‬‬

‫‪info@websecuritymgz.com‬‬ ‫ﺗﻬﻴﻪ ﻛﻨﻨﺪﻩ ‪ :‬ﺍﻣﻴﺮ ﺣﺴﻴﻦ ﺷﺮﻳﻔﻲ‬

‫ﺗﺎﺭﻳﺦ ‪ 23 :‬ﺩﻱ ﻣﺎﻩ ﺳﺎﻝ ‪1382‬‬
‫ﻣﻨﺎﺑﻊ‪:‬‬
‫‪Hacking Exposed, Web Application -1‬‬
‫‪www.SRCO.ir -2‬‬
 ‫ﻧﻔﻮﺫ ﺩﺭ ﺳﺮﻭﺭﻫﺎﻱ ﻭﺏ‬

‫ﻣﻘﺪﻣﻪ‬

‫ﺍﻭﻟﻴﻦ ﭼﻴﺰﻱ ﻛﻪ ﻣﻤﻜﻦ ﺍﺳﺖ ﺍﺯ ﻃﺮﻳﻖ ﺁﻥ ﺑﺮﻧﺎﻣﻪ ﻫﺎﻱ ﻛﺎﺭﺑﺮﺩﻱ ﻣﻮﺭﺩ ﺣﻤﻠﻪ ﻭﺍﻗﻊ ﺷﻮﻧﺪ ‪،‬‬
‫ﺳﺮﻭﺭﻫﺎﻱ ﻭﺑﻲ ﻣﻲ ﺑﺎﺷﻨﺪ ﻛﻪ ﺍﻳﻨﮕﻮﻧﻪ ﺑﺮﻧﺎﻣﻪ ﻫﺎ ﺭﻭﻱ ﺁﻧﻬﺎ ﺍﺟﺮﺍ ﺷﺪﻩ ﺍﻧﺪ‪ .‬ﻫﻴﭻ ﺑﺮﻧﺎﻣﻪ ﻛﺎﺭﺑﺮﺩﻱ ﻭﺏ‬
‫‪ ،‬ﻫﺮﭼﻨﺪ ﻛﻪ ﺧﻴﻠﻲ ﻣﺴﺘﺤﻜﻢ ﻭ ﺍﻣﻦ ﻫﻢ ﺑﺎﺷﺪ ‪ ،‬ﻧﻤﻲ ﺗﻮﺍﻧﺪ ﻣﺪﺕ ﺯﻳﺎﺩﻱ ﺭﻭﻱ ﻳﻚ ﺳﺮﻭﺭ ﻧﺎ ﺍﻣﻦ ﻭ‬
‫ﺁﺳﻴﺐ ﭘﺬﻳﺮ ﺩﻭﺍﻡ ﺑﻴﺎﻭﺭﺩ‪.‬‬
‫ﺩﺭ ﺍﻳﻨﺠﺎ ﻗﺼﺪ ﺑﺮ ﺍﻳﻦ ﺍﺳﺖ ﻛﻪ ﺭﻭﻱ ﺳﺮﻭﺭﻫﺎﻱ ﻭﺏ ﻣﻌﺮﻭﻓﻲ ﻫﻤﭽﻮﻥ ‪ IIS ، Apache‬ﻭ‬
‫‪ Netscape‬ﺑﺤﺚ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻴﻢ‪ .‬ﻫﻤﭽﻨﻴﻦ ﺩﺭﺑﺎﺭﻩ ﺁﺳﻴﺐ ﭘﺬﻳﺮﻳﻬﺎﻱ ﺍﺑﺘﺪﺍﻳﻲ ﻭ ﻣﻌﻤﻮﻟﻲ ﺁﻧﻬﺎ ﻭ ﺳﭙﺲ‬
‫ﻣﻌﺮﻓﻲ ﻭ ﻛﺎﺭ ﺑﺎ ﭼﻨﺪﻳﻦ ﭘﻮﻳﻨﺪﻩ ﺁﺳﻴﺐ ﭘﺬﻳﺮﻱ ﺭﺍ ﺑﺮﺍﻱ ﺷﻤﺎ ﺑﺎﺯﮔﻮ ﻛﻨﻴﻢ‪ .‬ﺍﮔﺮ ﻋﻤﺮﻱ ﺑﺎﻗﻲ ﻣﺎﻧﺪ ﻫﻢ ﺑﺮ‬
‫ﻳﻚ ﺳﺮﻱ ﻫﻢ ﺑﻪ ﺣﻤﻼﺕ ‪ 1 DOS‬ﻭ ﺗﺤﻠﻴﻞ ﭼﮕﻮﻧﮕﻲ ﺍﻧﺠﺎﻡ ﺍﻳﻨﮕﻮﻧﻪ ﺣﻤﻼﺕ ﻣﻲ ﺯﻧﻴﻢ‪.‬‬
‫ﺧﻴﻠﻲ ﺻﺎﻑ ﻭ ﺳﺎﺩﻩ ﺑﺎﻳﺪ ﺑﮕﻮﻳﻢ ﻛﻪ ﺍﮔﺮ ﺷﻤﺎ ﺍﻳﻦ ﺑﺨﺶ ﺭﺍ ﻣﻄﺎﻟﻌﻪ ﻛﻨﻴﺪ ﺩﺭ ﺣﺎﻝ ﺣﺎﺿﺮ ﺧﻴﻠﻲ ﺭﺍﺣﺖ‬
‫ﻣﻲ ﺗﻮﺍﻧﻴﺪ ﺑﻪ ﺩﻧﺒﺎﻝ ﺷﻜﺎﺭﻫﺎﻳﻲ ﺭﻭﻱ ﺍﻳﻨﺘﺮﻧﺖ ﺑﺎﺷﻴﺪ! ﺍﻣﺎ ﻫﻤﻴﺸﻪ ﻳﻚ ﻛﻼﻩ ﺳﻔﻴﺪ ﺑﺎﺷﻴﺪ ‪ ،‬ﻳﺎ ﺑﻪ ﻗﻮﻝ‬
‫ﻳﻜﻲ ﺍﺯ ﺩﻭﺳﺘﺎﻥ ‪ ،‬ﻣﺎﻧﻨﺪ ﻳﻚ ﺳﺮﺧﭙﻮﺳﺖ ﺍﺯ ﻗﺒﻴﻠﻪ ﺳﻮﻭ ﻭﻓﺎﺩﺍﺭ ﺑﻪ ﺳﻨﺖ ﻫﺎ ﺑﺎﺷﻴﺪ!!‬

‫ﺁﺳﻴﺐ ﭘﺬﻳﺮﻳﻬﺎﻱ ﻣﺘﻌﺎﺭﻑ‬

‫ﺳﺎﻟﻬﺎ ﻗﺒﻞ ﺍﺯ ﺍﻳﻨﻜﻪ ﺍﻣﻨﻴﺖ ﺳﺮﻭﺭﻫﺎﻱ ﻭﺏ ﺗﺠﺰﻳﻪ ﻭ ﺗﺤﻠﻴﻞ ﺷﻮﺩ ‪ ،‬ﻣﺎ ﻓﻜﺮ ﻣﻲ ﻛﺮﺩﻳﻢ ﻛﻪ ﺑﺎ ﺍﻧﺘﺨﺎﺏ‬
‫ﻳﻚ ﺳﺮﻭﺭ ﺧﻮﺏ ﻫﻴﭽﮕﺎﻩ ﺑﺎ ﻣﺸﻜﻞ ﺁﺳﻴﺐ ﭘﺬﻳﺮﻳﻬﺎﻱ ﺑﺤﺮﺍﻧﻲ ﺩﺭ ﭼﺮﺧﻪ ﺣﻴﺎﺕ ﺑﺮﻧﺎﻣﻪ ﻛﺎﺭﺑﺮﺩﻱ ﺧﻮﺩ‬
‫ﻣﻮﺍﺟﻬﻪ ﻧﺨﻮﺍﻫﻴﻢ ﺷﺪ‪ .‬ﺍﻣﺎ ﺩﺭ ﺍﻣﺮﻭﺯﻩ ﺷﻤﺎ ﺑﺎﻳﺪ ﺳﺮﻭﺭﻫﺎﻱ ﻭﺏ ﺧﻮﺩ ﺭﺍ ﺑﻪ ﺻﻮﺭﺕ ﻣﺤﺘﺎﻃﺎﻧﻪ ﺍﻱ‬
‫ﭘﻴﻜﺮ ﺑﻨﺪﻱ ﻛﻨﻴﺪ ﻭ ﻫﻤﻴﺸﻪ ﺁﺧﺮﻳﻦ ‪ Patch‬ﻫﺎﻱ ﺁﻥ ﺭﺍ ﺧﺮﻳﺪﺍﺭﻱ ﻭ ﻧﮕﻬﺪﺍﺭﻱ ﻛﻨﻴﺪ ﻭ ﺑﻌﺪ ﺍﺯ ﻧﺼﺐ ﺁﻧﻬﺎ‬
‫ﻫﻨﻮﺯ ﻫﻢ ﻧﻤﻲ ﺗﻮﺍﻥ ﺧﻴﻠﻲ ﻣﻄﻤﺌﻦ ﺑﻮﺩ ﻛﻪ ﻫﻤﻪ ﭼﻴﺰ !‪ OK‬ﺍﺳﺖ‪ .‬ﺩﺭ ﺍﻳﻨﺠﺎ ﻓﻘﻂ ﺗﻌﺪﺍﺩ ﺑﺴﻴﺎﺭ ﻣﺤﺪﻭﺩﻱ‬
‫ﺍﺯ ﺿﻌﻔﻬﺎﻱ ﺍﻣﻨﻴﺘﻲ ﺳﺮﻭﺭﻫﺎ ﺑﻴﺎﻥ ﻣﻲ ﺷﻮﺩ ﻭ ﻧﺤﻮﻩ ﻣﻘﺎﺑﻠﻪ ﺑﺎ ﺁﻧﻬﺎ ﻧﻴﺰ ﮔﻔﺘﻪ ﻣﻲ ﺷﻮﺩ ‪ ،‬ﻭﻟﻴﻜﻦ ﺑﺮﺍﻱ‬
‫ﺍﻃﻼﻋﺎﺕ ﺑﻴﺸﺘﺮ ﺩﻭﺳﺘﺎﻥ ﺑﺎﻳﺪ ﺑﻪ ﻣﻨﺎﺑﻌﻲ ﻛﻪ ﺩﺭ ﺍﻧﺘﻬﺎﻱ ﺍﻳﻦ ﺩﺳﺘﻪ ﻣﻘﺎﻻﺕ ﺫﻛﺮ ﻣﻲ ﺷﻮﺩ ﻣﺮﺍﺟﻪ‬
‫ﻓﺮﻣﺎﻳﻨﺪ‪.‬‬

‫‪1 - Denial Of Service‬‬

‫‪2‬‬ ‫‪www.WebsecurityMgz.com‬‬
 ‫ﻧﻔﻮﺫ ﺩﺭ ﺳﺮﻭﺭﻫﺎﻱ ﻭﺏ‬

‫ﻧﻔﻮﺫ ﺩﺭ ﺳﺮﻭﺭ ‪Apache‬‬

‫ﺁﭘﺎﭼﯽ ) ‪ (Apache‬ﻳﮑﯽ ﺍﺯ ﻣﺘﺪﺍﻭﻟﺘﺮﻳﻦ ﺳﺮﻭﻳﺲ ﺩﻫﻨﺪﮔﺎﻥ ﻭﺏ ﺑﺮ ﺭﻭﯼ ﺍﻳﻨﺘﺮﻧﺖ ﺍﺳﺖ ‪ .‬ﺩﺭ ﻣﻘﺎﻳﺴﻪ‬
‫ﺑﺎ ﺳﺮﻭﻳﺲ ﺩﻫﻨﺪﻩ ﻭﺏ ﻣﺎﻳﮑﺮﻭﺳﺎﻓﺖ ) ‪ ، ( IIS‬ﺁﭘﺎﭼﯽ ﻣﺴﺎﺋﻞ ﻭ ﻣﺸﮑﻼﺕ ﺍﻣﻨﻴﺘﯽ ﮐﻤﺘﺮﯼ ﺭﺍ ﺩﺍﺷﺘﻪ‬
‫ﻭﻟﯽ ﻫﻤﭽﻨﺎﻥ ﺩﺍﺭﺍﯼ ﺁﺳﻴﺐ ﭘﺬﻳﺮﯼ ﺧﺎﺹ ﺧﻮﺩ ﺍﺳﺖ ‪.‬‬

‫ﻋﻼﻭﻩ ﺑﺮ ﻭﺟﻮﺩ ﻧﻘﺎﻁ ﺁﺳﻴﺐ ﭘﺬﻳﺮ ﺩﺭ ﻣﺎﮊﻭﻝ ﻫﺎ ﻭ ﮐﺪ ﺁﭘﺎﭼﯽ ) ‪ CA-2002-27‬ﻭ ‪( CA-2002-17‬‬

‫‪ ،‬ﺗﮑﻨﻮﻟﻮﮊﯼ ﻫﺎﯼ ‪ CGI‬ﻭ ‪ PHP‬ﻧﻴﺰ ﺩﺍﺭﺍﯼ ﻧﻘﺎﻁ ﺁﺳﻴﺐ ﭘﺬﻳﺮﯼ ﺧﺎﺹ ﺧﻮﺩ ﺑﻮﺩﻩ ﮐﻪ ﺿﻌﻒ ﻫﺎﯼ‬
‫ﺍﻣﻨﻴﺘﯽ ﺁﻧﺎﻥ ﺑﻪ ﺳﺮﻭﻳﺲ ﺩﻫﻨﺪﻩ ﻭﺏ ﻧﻴﺰ ﺳﺮﺍﻳﺖ ﻛﺮﺩﻩ ﺍﺳﺖ‪ .‬ﺩﺭ ﺻﻮﺭﺕ ﻭﺟﻮﺩ ﻧﻘﺎﻁ ﺁﺳﻴﺐ ﭘﺬﻳﺮ‬
‫ﺩﺭ ﺳﺮﻭﻳﺲ ﺩﻫﻨﺪﻩ ﺁﭘﺎﭼﯽ ﻭ ﻳﺎ ﻋﻨﺎﺻﺮ ﻣﺮﺗﺒﻂ ﺑﻪ ﺁﻥ ‪ ،‬ﺯﻣﻴﻨﻪ ﺗﻬﺪﻳﺪﺍﺕ ﺯﻳﺮ ﻓﺮﺍﻫﻢ ﻣﯽ ﮔﺮﺩﺩ ‪:‬‬

‫• ﻏﻴﺮ ﻓﻌﺎﻝ ﻧﻤﻮﺩﻥ ﺳﺮﻭﻳﺲ ) ‪( DoS‬‬

‫• ﻧﻤﺎﻳﺶ ﻭ ﺑﻪ ﻣﺨﺎﻃﺮﻩ ﺍﻧﺪﺍﺧﺘﻦ ﻓﺎﻳﻞ ﻫﺎ ﻭ ﺩﺍﺩﻩ ﻫﺎﯼ ﺣﺴﺎﺱ‬
‫• ﺩﺳﺘﻴﺎﺑﯽ ﺑﻪ ﺳﺮﻭﻳﺲ ﺩﻫﻨﺪﻩ ﺍﺯ ﺭﺍﻩ ﺩﻭﺭ‬
‫• ﺑﻪ ﻣﺨﺎﻃﺮﻩ ﺍﻓﺘﺎﺩﻥ ﺳﺮﻭﻳﺲ ﺩﻫﻨﺪﻩ ) ﺩﺳﺘﮑﺎﺭﯼ ﻭ ﺧﺮﺍﺑﯽ ﺳﺎﻳﺖ (‬

‫ﺗﻤﺎﻣﯽ ﺳﻴﺴﺘﻢ ﻫﺎﯼ ﻳﻮﻧﻴﮑﺲ ﻗﺎﺩﺭ ﺑﻪ ﺍﺟﺮﺍﺀ ﺁﭘﺎﭼﯽ ﻣﯽ ﺑﺎﺷﻨﺪ ‪ .‬ﺁﭘﺎﭼﯽ ﺑﺼﻮﺭﺕ ﭘﻴﺶ ﻓﺮﺽ ﺑﺮ‬
‫ﺭﻭﯼ ﺗﻌﺪﺍﺩ ﺯﻳﺎﺩﯼ ﺍﺯ ﻧﺴﺨﻪ ﻫﺎﯼ ﻳﻮﻧﻴﮑﺲ ﻭ ﻟﻴﻨﻮﮐﺲ ‪ ،‬ﻧﺼﺐ ﻣﯽ ﮔﺮﺩﺩ ‪.‬ﻋﻼﻭﻩ ﺑﺮ ﺍﻣﮑﺎﻥ ﻓﻮﻕ ‪،‬‬
‫ﺁﭘﺎﭼﯽ ﺭﺍ ﻣﯽ ﺗﻮﺍﻥ ﺑﺮ ﺭﻭﯼ ﻣﻴﺰﺑﺎﻧﯽ ﺩﻳﮕﺮ ﮐﻪ ﺍﺯ ﺳﻴﺴﺘﻢ ﻋﺎﻣﻠﯽ ﻣﺨﺘﻠﻒ ﻧﻈﻴﺮ ﻭﻳﻨﺪﻭﺯ ﺍﺳﺘﻔﺎﺩﻩ ﻣﯽ‬
‫ﻧﻤﺎﻳﺪ ﻧﻴﺰ ﻧﺼﺐ ﻧﻤﻮﺩ‪ .‬ﺍﻳﻦ ﻧﻮﻉ ﺍﺯ ﻧﺴﺨﻪ ﻫﺎﯼ ﺁﭘﺎﭼﯽ ﻧﻴﺰ ﻣﯽ ﺗﻮﺍﻧﺪ ﺩﺍﺭﺍﯼ ﻧﻘﺎﻁ ﺁﺳﻴﺐ ﭘﺬﻳﺮ ﺧﺎﺹ‬
‫ﺧﻮﺩ ﺑﺎﺷﺪ ‪.‬‬
‫ﺳﺎﻳﺘﻬﺎﻱ ﺗﺠﺎﺭﺕ ﺍﻟﻜﺘﺮﻭﻧﻴﻚ ﻓﺮﺽ ﺭﺍ ﺑﺮ ﺍﻳﻦ ﮔﺬﺍﺷﺘﻪ ﺍﻧﺪ ﻛﻪ ﺻﻔﺤﺎﺕ ﻭﺏ ﺧﻮﺩ ﺭﺍ ﺑﻪ ﺻﻮﺭﺕ‬
‫ﺩﻟﺨﻮﺍﻩ ﺑﺮﺍﻱ ﻣﺸﺘﺮﻳﻬﺎﻱ ﺧﻮﺩ ﺍﻳﺠﺎﺩ ﻛﻨﻨﺪ ﻭ ﻗﺎﻟﺐ ﺗﻮﺟﻪ ﺧﻮﺩ ﺭﺍ ﺭﻭﻱ ﻣﺸﺘﺮﻱ ﻣﺪﺍﺭﻱ ﻗﺮﺍﺭ ﺩﺍﺩﻩ ﺍﻧﺪ‬
‫ﺗﺎ ﺑﺘﻮﺍﻧﻨﺪ ﻣﺸﺘﺮﻳﻬﺎ ﺭﺍ ﺑﻪ ﺳﺎﻳﺖ ﺧﻮﺩ ﺟﺬﺏ ﻛﻨﻨﺪ ﺑﻪ ﻃﻮﺭﻱ ﻛﻪ ﻫﺮ ﻣﺸﺘﺮﻱ ﺑﺮ ﺍﺳﺎﺱ ﻋﻼﻗﻪ ﻣﻨﺪﻱ‬
‫ﺧﻮﺩ ﺻﻔﺤﺎﺕ ﻭ ﻣﻮﺿﻮﻋﺎﺗﻲ ﺩﻟﺨﻮﺍﻩ ﺭﺍ ﺩﺭ ﺳﺎﻳﺖ ﻣﺸﺎﻫﺪﻩ ﻛﻨﺪ ﻭ ﻳﺎ ﻓﻼﻥ ﺻﻔﺤﻪ ﺭﺍ ﺑﺎ ﻓﻼﻥ ﺭﻧﮓ‬
‫ﻣﺸﺎﻫﺪﻩ ﻛﻨﺪ‪ .‬ﺑﺮﺍﻱ ﺍﻳﻦ ﻣﻨﻈﻮﺭ ‪ Apache‬ﻧﻴﺎﺯ ﺑﻪ ﻣﺎﮊﻭﻟﻬﺎﻳﻲ ﺩﺍﺭﺩ ﺗﺎ ﺗﻮﺍﻧﺎﻳﻲ ﺁﻥ ﺭﺍ ﺑﺮﺍﻱ ﻃﺮﺍﺣﻲ ﻭ‬
‫ﻧﻤﺎﻳﺶ ﺻﻔﺤﺎﺕ ﺩﻳﻨﺎﻣﻴﻚ ﺑﺎﻻ ﺑﺒﺮﺩ ﻭ ﻫﻤﻴﻦ ﻣﺎﮊﻭﻟﻬﺎ ﻣﻲ ﺑﺎﺷﻨﺪ ﻛﻪ ‪ Apache‬ﺭﺍ ﺩﺭ ﻣﻌﺮﺽ ﺧﻄﺮ‬
‫ﻗﺮﺍﺭ ﻣﻲ ﺩﻫﺪ‪ .‬ﺑﺮﺍﻱ ﺍﻳﻨﻜﻪ ﺑﻬﺘﺮ ﺑﻪ ﺍﻳﻦ ﻣﻮﺿﻮﻉ ﭘﻲ ﺑﺒﺮﻳﺪ ﺍﺟﺎﺯﻩ ﺑﺪﻫﻴﺪ ﭼﻨﺪ ﻣﺜﺎﻝ ﻭ ﻧﻤﻮﻧﻪ ﺭﺍ ﺑﺎ ﻫﻢ‬
‫ﻣﺮﻭﺭ ﻛﻨﻴﻢ‪.‬‬

‫‪3‬‬ ‫‪www.WebsecurityMgz.com‬‬
 ‫ﻧﻔﻮﺫ ﺩﺭ ﺳﺮﻭﺭﻫﺎﻱ ﻭﺏ‬

‫ﻟﻴﺴﺖ ﻛﺮﺩﻥ ﺩﺍﻳﺮﻛﺘﻮﺭﻫﺎ ﺑﻪ ﻭﺳﻴﻠﻪ ‪ Slash‬ﻫﺎﻱ ﻃﻮﻻﻧﻲ‬

‫ﻣﺎﮊﻭﻟﻬﺎﻱ ‪ mod_dir ، mod_negotiate‬ﻭ‬ ‫‪ URL‬ﻫﺎﻱ ﻃﻮﻻﻧﻲ ﺍﺯ ﻣﻴﺎﻥ‬ ‫ﺗﺮﺟﻤﻪ‬

‫‪ mod_autoindex‬ﺑﺎﻋﺚ ﻣﻲ ﺷﻮﺩ ﻛﻪ ‪ Apache‬ﻣﺤﺘﻮﺍﻱ ﺩﺍﻳﺮﻛﺘﻮﺭﻳﻬﺎﻱ ﺭﺍ ﻧﻤﺎﻳﺶ ﺩﻫﺪ‪ .‬ﺍﻳﻦ ﺁﺳﻴﺐ‬
‫ﭘﺬﻳﺮﻱ ﻫﻤﺎﻥ ﺯﻣﺎﻧﻲ ﻛﻪ ‪ Martin Kreamer‬ﻧﺴﺨﻪ ‪ Apache 1.3.19‬ﺭﺍ ﺩﺭ ﻣﺎﺭﺱ ‪ 2001‬ﻣﻨﺘﺸﺮ‬
‫ﻛﺮﺩ ‪ ،‬ﻧﻤﺎﻳﺎﻥ ﺑﻮﺩ‪ .‬ﻣﻔﻬﻮﻣﺶ ﺧﻴﻠﻲ ﺳﺎﺩﻩ ﻭ ﭘﻴﺶ ﭘﺎ ﺍﻓﺘﺎﺩﻩ ﺍﺳﺖ ﻭﻟﻲ ﺑﺎ ﻛﻤﻲ ﺗﻘﻼ ﻭ ﺗﻼﺵ ﻣﻲ ﺗﻮﺍﻥ‬
‫ﺑﻪ ﻭﺳﻴﻠﻪ ﺁﻥ ﺑﺮ ﺳﺮﻭﺭ ﻭﺏ ﻏﻠﺒﻪ ﭘﻴﺪﺍ ﻛﺮﺩ‪ .‬ﻳﻚ ‪ URL‬ﺑﺎ ﺗﻌﺪﺍﺩ ﺯﻳﺎﺩﻱ ﺍﺯ ﺍﺳﻠﺶ ﻫﺎﻱ ﺩﻧﺒﺎﻟﻪ ﺩﺍﺭ ‪ ،‬ﺑﻪ‬
‫ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ ‪:‬‬

‫‪/cgi-bin//////////////////////////////////////////////////////‬‬

‫ﻣﻤﻜﻦ ﺍﺳﺖ ﻟﻴﺴﺖ ﺩﺍﻳﺮﻛﺘﻮﺭﻳﻬﺎﻱ ﺩﺭﺍﻳﻮﻫﺎﻱ ﺍﺻﻠﻲ ﺳﻴﺴﺘﻢ ﺭﺍ ﻧﻤﺎﻳﺶ ﺩﻫﺪ‪ .‬ﺗﻌﺪﺍﺩ ﻭﺍﻗﻌﻲ ﺍﺳﻠﺶ ﻫﺎ‬
‫ﻣﺘﻔﺎﻭﺕ ﻣﻲ ﺑﺎﺷﺪ ﻭﻟﻲ ﻣﻲ ﺗﻮﺍﻥ ﺑﺎ ﻧﻮﺷﺘﻦ ﻳﻚ ﺍﺳﻜﺮﻳﭙﺖ ‪ Perl‬ﺧﻴﻠﻲ ﺳﺎﺩﻩ ﺍﻳﻦ ﺣﻤﻠﻪ ﺭﺍ ﭘﻴﺎﺩﻩ‬
‫ﺳﺎﺯﻱ ﻛﺮﺩ‪ .‬ﻧﻜﺘﻪ ﺍﻱ ﻛﻪ ﺩﺭ ﺍﻳﻨﺠﺎ ﺑﺎﻳﺪ ﮔﻔﺘﻪ ﺷﻮﺩ ﺍﻳﻦ ﺍﺳﺖ ﻛﻪ ﺑﻴﺸﺘﺮ ﺳﺮﻭﺭﻫﺎﻱ ‪ Apache‬ﻧﻤﻲ‬
‫ﺗﻮﺍﻧﻨﺪ ﻳﻚ ‪ URL‬ﺑﺰﺭﮔﺘﺮ ﺍﺯ ‪ 8000‬ﻛﺎﺭﺍﻛﺘﺮ ﺭﺍ ﭘﺮﺩﺍﺯﺵ ﻛﻨﻨﺪ‪.‬‬

‫ﺍﻗﺪﺍﻡ ﻣﺘﻘﺎﺑﻞ ﺩﺭ ﺑﺮﺍﺑﺮ ﺍﺳﻠﺸﻬﺎﻱ ﻃﻮﻻﻧﻲ‬

‫ﺍﻳﻦ ﺍﻳﺮﺍﺩ ﺩﺭ ‪ Apache 1.3.19‬ﺭﻓﻊ ﺷﺪ ‪ .‬ﺍﮔﺮ ﭼﻪ ﺍﻳﻦ ﻣﺸﻜﻞ ﻣﻲ ﺗﻮﺍﻧﺴﺖ ﺑﻪ ﻭﺳﻴﻠﻪ ﭘﻴﻜﺮﺑﻨﺪﻱ ﺑﻬﺘﺮ‬
‫ﻭ ﻛﺎﻣﻠﺘﺮ ‪ Apache‬ﻧﻴﺰ ﺭﻓﻊ ﺷﻮﺩ‪ .‬ﻣﺎﮊﻭﻟﻬﺎﻱ ‪ mod_dir‬ﻭ ‪ mod_autoindex‬ﺑﻪ ﺻﻮﺭﺕ ﭘﻴﺶ‬
‫ﻓﺮﺽ ﺭﻭﻱ ﺳﺮﻭﺭ ‪ Apache‬ﻗﺮﺍﺭ ﺩﺍﺭﻧﺪ‪ .‬ﺍﻳﻦ ﻣﺎﮊﻭﻟﻬﺎ ﻛﻪ ﻫﺮ ﻛﺪﺍﻡ ﻣﻲ ﺗﻮﺍﻧﻨﺪ ﻟﻴﺴﺖ ﺩﺍﻳﺮﻛﺘﻮﺭﻳﻬﺎ ﺭﺍ‬
‫ﻧﻤﺎﻳﺶ ﺑﺪﻫﻨﺪ ﺑﻪ ﺧﺎﻃﺮ ﺍﻳﻨﻜﻪ ‪ Apache‬ﻛﺎﺭﺑﺮ ﭘﺴﻨﺪ ﺑﺎﺷﺪ ‪ ،‬ﺭﻭﻱ ﺳﺮﻭﺭ ﻗﺮﺍﺭ ﮔﺮﻓﺘﻪ ﺍﻧﺪ ‪ ،‬ﻭ ﺑﺎﻳﺪ ﺩﺭ‬
‫ﺯﻣﺎﻥ ﻛﺎﻣﭙﺎﻳﻞ ﻛﺮﺩﻥ ‪ Apache‬ﺁﻧﻬﺎ ﺭﺍ ﺣﺬﻑ ﻛﺮﺩ‪ .‬ﻫﻴﭻ ﺩﻟﻴﻠﻲ ﻭﺟﻮﺩ ﻧﺪﺍﺭﺩ ﻛﻪ ﻣﺤﺘﻮﺍﻱ‬
‫ﺩﺍﻳﺮﻛﺘﻮﺭﻳﻬﺎﻱ ﺳﺮﻭﺭ ﻭﺏ ﺧﻮﺩ ﺭﺍ ﺑﺮﺍﻱ ﻛﺎﺭﺑﺮ ﻧﻬﺎﻳﻲ ﻧﻤﺎﻳﺶ ﺩﻫﻴﺪ‪ .‬ﺍﺳﻜﺮﻳﭙﺘﻲ ﻛﻪ ﺑﺮﺍﻱ ﺣﻞ ﺍﻳﻦ‬
‫ﻣﺴﺎﻟﻪ ﻭ ﺣﺬﻑ ﺍﻳﻨﮕﻮﻧﻪ ﻣﺎﮊﻭﻟﻬﺎ ﻣﻲ ﺗﻮﺍﻧﻴﺪ ﺍﺳﺘﻔﺎﺩﻩ ﻛﻨﻴﺪ ﺩﺭ ﺯﻳﺮ ﺁﻣﺪﻩ ﺍﺳﺖ‪.‬‬

‫‪[rohan apache]$ ./configure –disable-module=dir –disable-module=autoindex‬‬

‫ﺗﻮﺟﻪ ﺑﻪ ﺍﻳﻦ ﻧﻜﺘﻪ ﺿﺮﻭﺭﻱ ﻣﻲ ﺑﺎﺷﺪ ﻛﻪ ﺑﺎ ﺣﺬﻑ ﻣﺎﮊﻭﻝ ‪ mod-dir‬ﺩﺭ ‪ Apache‬ﺩﺭ ﺗﻤﺎﻡ‬
‫ﺩﺭﺧﻮﺍﺳﺘﻬﺎﻱ ﻭﺏ ﻛﺎﺭﺍﻛﺘﺮ ﺍﺳﻠﺸﻬﺎﻱ ﭘﺸﺖ ﺳﺮ ﻫﻢ ﺍﺯ ﻗﻠﻢ ﺧﻮﺍﻫﻨﺪ ﺍﻓﺘﺎﺩ‪ .‬ﻫﺮ ﭼﻨﺪ ﻛﻪ ﺍﻳﻦ ﻣﻮﺿﻮﻉ‬
‫ﺗﺎﺛﻴﺮ ﭼﻨﺪﺍﻧﻲ ﺭﻭﻱ ﺑﺮﻧﺎﻣﻪ ﻛﺎﺭﺑﺮﺩﻱ ﻧﺪﺍﺭﺩ‪.‬‬

‫‪4‬‬ ‫‪www.WebsecurityMgz.com‬‬
 ‫ﻧﻔﻮﺫ ﺩﺭ ﺳﺮﻭﺭﻫﺎﻱ ﻭﺏ‬

‫ﺩﺍﻳﺮﻛﺘﻮﺭﻱ ﻟﻴﺴﺖ ﺷﺪﻩ ‪Multiview‬‬

‫‪ Apache‬ﺑﺪﻭﻥ ﺍﺟﺎﺯﻩ ﻣﺪﻳﺮ ﺳﺮﻭﺭ ‪ ،‬ﺑﺎ ﻫﺮ ﺗﻼﺷﻲ ﻛﻪ ﺑﺨﻮﺍﻫﺪ ﺑﻪ ﻟﻴﺴﺖ ﺩﺍﻳﺮﻛﺘﻮﺭﻱ ﻫﺎ ﺩﺳﺖ ﭘﻴﺪﺍ‬
‫ﻛﻨﺪ ‪ ،‬ﻣﺨﺎﻟﻔﺖ ﻣﻲ ﻛﻨﺪ‪ .‬ﻣﺘﺎﺳﻔﺎﻧﻪ ‪ ،‬ﻳﻜﻲ ﺍﺯ ﺟﺪﻳﺪ ﺗﺮﻳﻦ ﻗﺎﺑﻠﻴﺖ ﻫﺎﻱ ‪ ، Multiviews ، Apache‬ﻛﻪ‬
‫ﺁﺳﻴﺐ ﭘﺬﻳﺮﻱ ﺑﺮﺍﻱ ﻧﺸﺎﻥ ﺩﺍﺩﻥ ﻟﻴﺴﺖ ﺩﺍﻳﺮﻛﺘﻮﺭﻳﻬﺎ ﻣﻲ ﺑﺎﺷﺪ ﺗﻮﺳﻂ ‪ Kevin‬ﺍﺯ ﺳﺎﻳﺖ‬
‫‪ brasscannon.net‬ﺩﺭ ﺟﻮﻻﻱ ‪ 2001‬ﺑﻪ ‪ Bugtraq‬ﮔﺰﺍﺭﺵ ﺷﺪ‪ .‬ﺍﻳﻦ ﺣﻤﻠﻪ ﻣﻲ ﺗﻮﺍﻧﺪ ﺑﻪ ﺑﻪ ﻭﺳﻴﻠﻪ‬
‫ﻣﺮﻭﺭﮔﺮ ﻭ ﻳﺎ ﺍﺯ ﻃﺮﻳﻖ ﺩﺳﺘﻮﺭ ﻣﺴﺘﻘﻴﻢ ﺑﺮﻧﺎﻣﻪ ‪ netcat‬ﻟﻴﺴﺖ ﺩﺍﻳﺮﻛﺘﻮﺭﻱ ﻫﺎ ﺭﺍ ﻧﻤﺎﻳﺶ ﺩﻫﺪ‪:‬‬

‫\ | ”‪[rohan]$ echo –e “GET /some_directory?M=D HTTP/1.0\n\n‬‬

‫‪>nc 192.168.42.17 80‬‬

‫>”‪<!DOCUMENT HTML PUBLIC “-//W#C//DTD HTML 3.2 Final//EN‬‬

‫>‪<HTML‬‬
‫>‪<HEAD‬‬
‫>‪<TITLE> Index of /some_directory </TITLE‬‬
‫>‪</HEAD‬‬
‫>‪<BODY‬‬
‫>‪<H1>Index os /some_directory</H1‬‬
‫>‪<PRE><IMG SRC=”/icons/blank.gif” ALT=” “><A HREF=”?N=A”>Name</A‬‬
‫>‪<A HREF=”?M=A”>Last modified</A‬‬
‫>‪<A HREF=”?S=A”>Size</A‬‬
‫>‪<A HREF=”?D=A”>Description</A‬‬
‫>‪<HR‬‬
‫‪<A HREF=”/”>Parent Directory</A> 20-Oct-1998 08:45‬‬
‫>‪<A HREF=”cgi-bin/”>cgi-bin</A‬‬ ‫‪20-Oct-1998 03:37‬‬
‫‪<A HREF=”messages/”>messages</A> 28-Oct-1998 01:36‬‬
‫>‪<A HREF=”wwwboard.html”>wwwboard.html</A‬‬ ‫‪16-Apr-1998 19:44‬‬
‫‪<A HREF=”password.txt”>password.txt</A> 19-Apr-1998 12:01‬‬
‫>‪<A HREF=”data.txt”>data.txt</A‬‬ ‫‪16-Apr-1998 02:53‬‬
‫>‪<A HREF=”faq.html”>faq.html</A‬‬ ‫‪19-Apr-1998 04:09‬‬
‫>‪</PRE><HR‬‬
‫>‪</BODY></HTML‬‬

‫ﺍﻟﺒﺘﻪ ﺧﺮﻭﺟﻲ ﺍﻳﻦ ﺩﺳﺘﻮﺭ ‪ ،‬ﻣﻘﺪﺍﺭﻱ ﻋﻮﺽ ﺷﺪﻩ ﺍﺳﺖ ﺗﺎ ﺧﻮﺍﻧﺎ ﺗﺮ ﺑﺎﺷﺪ‪ .‬ﺍﻣﺎ ﺍﻳﻦ ﻳﻚ ﻣﺜﺎﻟﻲ ﺍﺯ ﺩﺍﺩﻩ‬
‫ﻫﺎﻳﻲ ﻣﻲ ﺑﺎﺷﺪ ﻛﻪ ﺩﺭ ﻳﻚ ﺩﺍﻳﺮﻛﺘﻮﺭﻱ ‪ Apache‬ﻣﻲ ﺗﻮﺍﻥ ﻳﺎﻓﺖ‪ .‬ﺍﻟﺒﺘﻪ ﻣﺎ ﺩﺭ ﺁﻳﻨﺪﻩ ﺩﺭﺑﺎﺭﻩ ﻓﺎﻳﻠﻬﺎﻱ‬
‫ﻣﻬﻢ ﺍﻳﻦ ﻧﻮﻉ ﺳﺮﻭﺭ ﻫﺎ ﺻﺤﺒﺖ ﺧﻮﺍﻫﻴﻢ ﻛﺮﺩ‪ .‬ﺑﺮﺍﻱ ﺣﺎﻻ ﻫﻤﺎﻥ ﻓﺎﻳﻞ ‪ Password.txt‬ﻛﺎﻓﻲ ﻣﻲ‬
‫ﺑﺎﺷﺪ‪ .‬ﺍﻳﻦ ﺁﺳﻴﺐ ﭘﺬﻳﺮﻱ ﺑﺴﻴﺎﺭ ﻣﻔﻴﺪ ﺍﺳﺖ ﺯﻳﺮﺍ ﻟﻴﺴﺖ ﻛﺎﻣﻠﻲ ﺍﺯ ﺩﺍﻳﺮﻛﺘﻮﺭﻳﻬﺎﻱ ﺳﺎﻳﺖ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲ‬
‫ﺩﻫﺪ‪.‬‬

‫ﺭﺍﻩ ﻣﻘﺎﺑﻠﻪ ﺑﺎ ‪Multiview‬‬

‫ﺍﻭﻟﻴﻦ ﺩﻓﺎﻉ ﺍﻳﻦ ﺍﺳﺖ ﻛﻪ ﺍﺳﻨﺎﺩ ﺩﺭﻭﻥ ﺩﺍﻳﺮﻛﺘﻮﺭﻱ ﺭﻳﺸﻪ ﺭﺍ ﭘﺎﻙ ﻛﻨﻴﺪ‪ .‬ﻓﺎﻳﻠﻬﺎﻱ ﻏﻴﺮ ﺿﺮﻭﺭﻱ ﻧﺒﺎﻳﺪ‬
‫ﺩﺭ ﻫﺮ ﺩﺍﻳﺮﻛﺘﻮﺭﻱ ﺫﺧﻴﺮﻩ ﺷﻮﺩ‪ .‬ﻳﻜﻪ ﻧﻜﺘﻪ ﺑﺮﺍﻱ ﺗﻮﺳﻌﻪ ﺩﻫﻨﺪﮔﺎﻥ ﻭﺏ ﺍﻳﻦ ﺍﺳﺖ ﻛﻪ ﻫﻴﭽﮕﺎﻩ ﺩﺍﺩﻩ‬

‫‪5‬‬ ‫‪www.WebsecurityMgz.com‬‬
 ‫ﻧﻔﻮﺫ ﺩﺭ ﺳﺮﻭﺭﻫﺎﻱ ﻭﺏ‬

‫ﻫﺎﻱ ﻗﺪﻳﻤﻲ ‪ ،‬ﻧﺴﺨﻪ ﭘﺸﺘﻴﺒﺎﻥ ﺳﺎﻳﺖ ‪ ،‬ﻭ ﻫﺮ ﻓﺎﻳﻠﻲ ﻛﻪ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﺑﺮﻧﺎﻣﻪ ﻛﺎﺭﺑﺮﺩﻱ ﻧﻤﻲ ﺑﺎﺷﺪ ‪ ،‬ﻧﺒﺎﻳﺪ‬
‫ﺑﻪ ﻭﺳﻴﻠﻪ ﻣﺮﻭﺭ ﮔﺮ ﻗﺎﺑﻞ ﺩﺳﺘﺮﺳﻲ ﺑﺎﺷﺪ‪ .‬ﺁﺳﻴﺐ ﭘﺬﻳﺮﻱ ﻟﻴﺴﺖ ﻛﺮﺩﻥ ﺩﺍﻳﺮﻛﺘﻮﺭﻱ ﻫﺎ ﻭﻗﺘﻲ ﻣﺎ ﺭﺍ‬
‫ﺗﻬﺪﻳﺪ ﻣﻲ ﻛﻨﺪ ﻛﻪ ﺩﺍﺩﻩ ﻫﺎﻱ ﺣﺴﺎﺱ ﺩﺭﻭﻥ ﺁﻧﻬﺎ ﻭﺟﻮﺩ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪.‬‬

‫ﺗﺰﺭﻳﻖ ‪mod_auth_*sql‬‬

‫ﺩﺭ ﺁﮔﻮﺳﺖ ‪ RUS-CERT ، 2001‬ﺍﺯ ﺩﺍﻧﺸﮕﺎﻩ ‪ Stuttgart‬ﺭﻭﺷﻲ ﺭﺍ ﻣﻨﺘﺸﺮ ﻛﺮﺩ ﻛﻪ ﭼﮕﻮﻧﮕﻲ‬

‫ﺍﺣﺮﺍﺯ ﻫﻮﻳﺖ ﺭﺍ ﺑﺮ ﭘﺎﻳﻪ ﻣﺎﮊﻭﻟﻬﺎﻱ ‪ SQL‬ﺗﻮﺿﻴﺢ ﻣﻲ ﺩﺍﺩ‪ .‬ﺗﻴﻚ )‘ ( ﻣﻲ ﺗﻮﺍﻧﺴﺖ ﺩﺭﻭﻥ‬
‫ﺩﺭﺧﻮﺍﺳﺘﻬﺎﻱ ﻭﺏ ﺟﺎﮔﺬﺍﺭﻱ ﺷﻮﺩ ﻭ ﻫﻤﻴﻦ ﺑﻪ ﻛﺎﺭﺑﺮﺍﻥ ﺍﺟﺎﺯﻩ ﻣﻲ ﺩﺍﺩ ﻛﻪ ﺑﺘﻮﺍﻧﻨﺪ ﺩﺳﺘﻮﺭﺍﺕ ‪ SQL‬ﺭﺍ‬
‫ﺷﺒﻴﻪ ﺳﺎﺯﻱ ﻛﻨﻨﺪ ﻛﻪ ﺳﺎﺩﻩ ﺗﺮﻳﻦ ﺁﻥ ﺍﺣﺮﺍﺯ ﻫﻮﻳﺖ ﺩﺭ ﻳﻚ ﺳﺎﻳﺖ ﻣﻲ ﺑﺎﺷﺪ‪ .‬ﺍﻟﺒﺘﻪ ﺍﻳﻦ ﻣﻮﺿﻮﻉ ﺭﺍ ﻣﺎ‬
‫ﺩﺭ ﺁﻳﻨﺪﻩ ﺑﻪ ﻃﻮﺭ ﻣﻔﺼﻞ ﺑﺤﺚ ﺧﻮﺍﻫﻴﻢ ﻛﺮﺩ‪.‬‬

‫ﺭﺍﻩ ﻣﻘﺎﺑﻠﻪ ﺑﺎ ‪mod_auth_*sql‬‬

‫ﺑﺴﺘﻪ ‪ mod_auth_*sql‬ﻛﻪ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲ ﻛﻨﻴﺪ ﺭﺍ ﺑﻪ ﺭﻭﺯ ﺭﺳﺎﻧﻲ ﻛﻨﻴﺪ‪ .‬ﺍﻟﺒﺘﻪ ﻻﺯﻡ ﺑﻪ ﺫﻛﺮ ﺍﺳﺖ ﻛﻪ‬
‫ﭘﺲ ﺍﺯ ﺍﻳﻦ ﻛﺎﺭ ﺑﺎﻳﺪ ‪ Apache‬ﺭﺍ ﺩﻭﺑﺎﺭﻩ ﺭﺍﻩ ﺍﻧﺪﺍﺯﻱ ﻛﻨﻴﺪ‪.‬‬

‫ﻧﺤﻮﻩ ﺗﺸﺨﻴﺺ ﺁﺳﻴﺐ ﭘﺬﻳﺮﻳﻬﺎﻱ ﺳﻴﺴﺘﻢ‬

‫ﺑﻤﻨﻈﻮﺭ ﺁﮔﺎﻫﯽ ﻭ ﮐﺴﺐ ﺍﻃﻼﻋﺎﺕ ﻻﺯﻡ ﺩﺭ ﺧﺼﻮﺹ ﻧﺤﻮﻩ ﺗﺸﺨﻴﺺ ﺁﺳﻴﺐ ﭘﺬﻳﺮﯼ ﺳﺮﻭﻳﺲ‬
‫ﺩﻫﻨﺪﻩ ﻭﺏ ﺁﭘﺎﭼﯽ ‪ ،‬ﻣﯽ ﺗﻮﺍﻥ ﺍﺯ ﺁﺩﺭﺱ ﻫﺎﯼ ﺯﻳﺮ ﺍﺳﺘﻔﺎﺩﻩ ﻧﻤﻮﺩ ‪:‬‬

‫ﺩﺭ ﺭﺍﺑﻄﻪ ﺑﺎ ‪ Apache 1.3.x‬ﺭﺍ ﻣﯽ ﺗﻮﺍﻥ ﺍﺯ ﺁﺩﺭﺱ‬ ‫•‬

‫‪http://www.apacheweek.com/features/security-13‬‬

‫ﺑﺮﺍﯼ ‪ Apache 2.0.x‬ﻣﯽ ﺗﻮﺍﻥ ﺍﺯ ﺁﺩﺭﺱ‬ ‫•‬

‫‪http://www.apacheweek.com/features/security-20‬‬

‫ﺁﺩﺭﺱ ﻫﺎﯼ ﺍﺷﺎﺭﻩ ﺷﺪﻩ ‪ ،‬ﺩﺍﺭﺍﯼ ﺍﻃﻼﻋﺎﺕ ﻓﻨﯽ ﻻﺯﻡ ﺑﻤﻨﻈﻮﺭ ﻧﺤﻮﻩ ﺗﺸﺨﻴﺺ ﺁﺳﻴﺐ ﭘﺬﻳﺮﯼ ﺳﻴﺴﺘﻢ‬
‫ﻭ ﭘﻴﺸﻨﻬﺎﺩﺍﺕ ﻻﺯﻡ ﺩﺭ ﺧﺼﻮﺹ ﺍﺭﺗﻘﺎﺀ ﻭﺿﻌﻴﺖ ﺍﻣﻨﻴﺘﯽ ﻣﯽ ﺑﺎﺷﻨﺪ ‪ .‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺁﺩﺭﺱ‪:‬‬
‫‪ http://httpd.apache.org/‬ﻧﻴﺰ ﺩﺭ ﺍﻳﻦ ﺯﻣﻴﻨﻪ ﻣﻔﻴﺪ ﺍﺳﺖ ‪.‬‬

‫‪6‬‬ ‫‪www.WebsecurityMgz.com‬‬
 ‫ﻧﻔﻮﺫ ﺩﺭ ﺳﺮﻭﺭﻫﺎﻱ ﻭﺏ‬

‫ﺭﻭﺷﻬﺎﻱ ﻛﻠﻲ ﺣﻔﺎﻇﺖ ﺍﺯ ﺳﺮﻭﻳﺲ ﺩﻫﻨﺪﻩ ﻭﺏ ‪Apache‬‬

‫ﺑﻤﻨﻈﻮﺭ ﺣﻔﺎﻇﺖ ﻳﮏ ﺳﺮﻭﻳﺲ ﺩﻫﻨﺪﻩ ﻭﺏ ﺁﭘﺎﭼﯽ ‪ ،‬ﭘﻴﺸﻨﻬﺎﺩﺍﺕ ﺯﻳﺮ ﺍﺭﺍﺋﻪ ﻣﯽ ﮔﺮﺩﺩ ‪:‬‬

‫‪ -1‬ﺍﻃﻤﻴﻨﺎﻥ ﺍﺯ ﻧﺼﺐ ﺁﺧﺮﻳﻦ ‪ patch‬ﺍﺭﺍﺋﻪ ﺷﺪﻩ‬

‫ﺑﻤﻨﻈﻮﺭ ﺁﮔﺎﻫﯽ ﺍﺯ ﺁﺧﺮﻳﻦ‬ ‫‪ -‬ﺩﺭ ﺍﻳﻦ ﺭﺍﺑﻄﻪ ﻣﯽ ﺗﻮﺍﻥ ﺍﺯ ﺁﺩﺭﺱ ‪http://httpd.apache.org/‬‬

‫ﻭﺿﻌﻴﺖ ﻧﺴﺨﻪ ﻫﺎ ﻭ ‪ levels Patch‬ﺍﺳﺘﻔﺎﺩﻩ ﻧﻤﻮﺩ‪.‬‬

‫‪ -‬ﺑﻤﻨﻈﻮﺭ ﺩﺳﺘﻴﺎﺑﯽ ﺑﻪ ‪ code Source‬ﺍﮐﺜﺮ ﻧﺴﺨﻪ ﻫﺎﯼ ﺁﭘﺎﭼﯽ‪ ،‬ﻣﯽ ﺗﻮﺍﻥ ﺍﺯ ﺁﺩﺭﺱ‬
‫‪ http://httpd.apache.org/download.cgi‬ﺍﺳﺘﻔﺎﺩﻩ ﻧﻤﻮﺩ‪.‬‬

‫‪ -‬ﺑﻤﻨﻈﻮﺭ ﺁﮔﺎﻫﯽ ﻭ ﺩﺭﻳﺎﻓﺖ ﺁﺧﺮﻳﻦ ‪ Patch‬ﻫﺎﯼ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﻣﯽ ﺗﻮﺍﻥ ﺍﺯ ﺁﺩﺭﺱ‬

‫‪ http://www.apache.org/dist/httpd/patches/‬ﺍﺳﺘﻔﺎﺩﻩ ﻧﻤﻮﺩ‪.‬‬

‫‪ -2‬ﺍﻃﻤﻴﻨﺎﻥ ﺍﺯ ‪ patching‬ﻋﻨﺎﺻﺮ ﮐﻠﻴﺪﯼ ﺳﻴﺴﺘﻢ ﻋﺎﻣﻞ ﮐﻪ ﺁﭘﺎﭼﯽ ﺑﻌﻨﻮﺍﻥ ﻣﺮﺟﻊ ﺍﺯ ﺁﻧﺎﻥ ﺍﺳﺘﻔﺎﺩﻩ‬
‫ﻣﯽ ﻧﻤﺎﻳﺪ ‪.‬ﺩﺭ ﺍﻳﻦ ﺭﺍﺑﻄﻪ ﻻﺯﻡ ﺍﺳﺖ ﮐﻪ ﺻﺮﻓﺎ" ﻣﺎﮊﻭﻝ ﻫﺎﯼ ﺿﺮﻭﺭﯼ ﺑﻤﻨﻈﻮﺭ ﺻﺤﺖ ﻋﻤﻠﮑﺮﺩ‬
‫ﺳﺮﻭﻳﺲ ﺩﻫﻨﺪﻩ ‪ ،‬ﺩﺭ ﺁﭘﺎﭼﯽ ﮐﻤﭙﺎﻳﻞ ﮔﺮﺩﻧﺪ ‪.‬ﻻﺯﻡ ﺍﺳﺖ ﺑﻪ ﺍﻳﻦ ﻧﮑﺘﻪ ﺍﺷﺎﺭﻩ ﮔﺮﺩﺩ ﮐﻪ ﮐﺮﻡ ‪mod_ssl‬‬
‫)‪ ( CA-2002-27‬ﻧﻤﻮﻧﻪ ﺍﯼ ﮐﺎﻣﻞ ﺩﺭ ﺍﻳﻦ ﺯﻣﻴﻨﻪ ﺑﻮﺩﻩ ﮐﻪ ﺍﺯ ﻧﻘﺎﻁ ﺁﺳﻴﺐ ﭘﺬﻳﺮ ﺩﺭ ‪) OpenSSL‬‬
‫‪ ( CA-2002-23‬ﺍﺳﺘﻔﺎﺩﻩ ﻧﻤﻮﺩﻩ ﺍﺳﺖ ‪.‬‬

‫‪ -3‬ﺍﺯ ﺍﺟﺮﺍﯼ ﺁﭘﺎﭼﯽ ﺑﻌﻨﻮﺍﻥ ﺭﻳﺸﻪ ‪ ،‬ﺍﺟﺘﻨﺎﺏ ﻛﻨﻴﺪ ﻭ ﻣﯽ ﺑﺎﻳﺴﺖ ﺑﺪﻳﻦ ﻣﻨﻈﻮﺭ ‪ ،‬ﮐﺎﺭﺑﺮ ﻭ ﻳﺎ ﮔﺮﻭﻫﯽ‬
‫ﺧﺎﺹ ﺑﺎ ﺣﺪﺍﻗﻞ ﻣﺠﻮﺯ ﺍﻳﺠﺎﺩ ﮔﺮﺩﺩ‪ .‬ﺳﺎﻳﺮ ﭘﺮﺩﺍﺯﻩ ﻫﺎﯼ ﺳﻴﺴﺘﻢ ﺿﺮﻭﺭﺗﯽ ﺑﻪ ﺍﺟﺮﺍﺀ ﺗﺤﺖ ﮐﺎﺭﺑﺮ ﻭ ﻳﺎ‬
‫ﮔﺮﻭﻩ ﻓﻮﻕ ﺭﺍ ﻧﺨﻮﺍﻫﻨﺪ ﺩﺍﺷﺖ ‪.‬‬

‫‪ ، Chroot -4‬ﭘﺘﺎﻧﺴﻴﻠﯽ ﺍﺳﺖ ﮐﻪ ﺑﺎﻋﺚ ﺗﻌﺮﻳﻒ ﻣﺠﺪﺩ ﻣﺤﺪﻭﺩﻩ ﻳﮏ ﺑﺮﻧﺎﻣﻪ ﻣﯽ ﮔﺮﺩﺩ ‪ .‬ﺩﺭ ﺣﻘﻴﻘﺖ‬
‫‪ ، chroot‬ﺑﺎﻋﺚ ﺗﻌﺮﻳﻒ ﻣﺠﺪﺩ ﺩﺍﻳﺮﮐﺘﻮﺭﯼ ‪ "ROOT‬ﻭ ﻳﺎ "‪ "/‬ﺑﺮﺍﯼ ﻳﮏ ﺑﺮﻧﺎﻣﻪ ﻭ ﻳﺎ ﻳﮏ ‪Login‬‬
‫‪ session‬ﻣﯽ ﮔﺮﺩﺩ ‪ chroot.‬ﻣﯽ ﺗﻮﺍﻧﺪ ﺑﻌﻨﻮﺍﻥ ﻳﮏ ﻻﻳﻪ ﺗﺪﺍﻓﻌﯽ ﺍﺳﺘﻔﺎﺩﻩ ﮔﺮﺩﺩ ‪ .‬ﻣﺜﻼ" ﺩﺭ ﺻﻮﺭﺗﻴﮑﻪ‬
‫ﻓﺮﺩﯼ ﺑﻪ ﮐﺎﻣﭙﻴﻮﺗﺮ ﺷﻤﺎ ﺩﺳﺘﻴﺎﺑﯽ ﭘﻴﺪﺍ ﻧﻤﺎﻳﺪ ‪ ،‬ﻗﺎﺩﺭ ﺑﻪ ﻣﺸﺎﻫﺪﻩ ﺗﻤﺎﻣﯽ ﻓﺎﻳﻞ ﻫﺎﯼ ﻣﻮﺟﻮﺩ ﺑﺮ ﺭﻭﯼ‬
‫ﺳﻴﺴﺘﻢ ﻧﺨﻮﺍﻫﺪ ﺑﻮﺩ ‪ .‬ﻋﻼﻭﻩ ﺑﺮ ﻣﺤﺪﻭﺩﻳﺖ ﻓﻮﻕ ‪ ،‬ﻣﺤﺪﻭﺩﻳﺖ ﻫﺎﺋﯽ ﺩﺭ ﺧﺼﻮﺹ ﺍﺟﺮﺍﯼ ﺑﺮﺧﯽ ﺍﺯ‬
‫ﺩﺳﺘﻮﺭﺍﺕ ﻧﻴﺰ ﺑﻮﺟﻮﺩ ﻣﯽ ﺁﻳﺪ‪ .‬ﺩﺭ ﺍﻳﻦ ﺭﺍﺑﻄﻪ ﻳﮏ ﺩﺍﻳﺮﮐﺘﻮﺭﯼ ﺑﺎ ﻧﺎﻡ ‪ ، /chroot‬ﺍﻳﺠﺎﺩ ﻣﻲ ﺷﻮﺩ ﻭ‬
‫ﺗﻤﺎﻣﯽ ﺳﺮﻭﻳﺲ ﻫﺎﯼ ﻣﻮﺭﺩ ﻧﻄﺮ ﺑﺎ ﻳﮏ ﺍﻧﻀﺒﺎﻁ ﺧﺎﺹ ﺩﺭ ﺁﻥ ﻣﺴﺘﻘﺮ ﻣﯽ ﮔﺮﺩﻧﺪ ‪ .‬ﻣﺜﻼ" ﺳﺮﻭﻳﺲ‬
‫ﺩﻫﻨﺪﻩ ﺁﭘﺎﭼﯽ ﺩﺭ ‪ / chroot/httpd‬ﻗﺮﺍﺭ ﻣﯽ ﮔﻴﺮﺩ‪ .‬ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻣﻮﺍﺭﺩ ﻓﻮﻕ ‪ ،‬ﻣﯽ ﺑﺎﻳﺴﺖ ﺁﭘﺎﭼﯽ ﺭﺍ ﺩﺭ‬

‫‪7‬‬ ‫‪www.WebsecurityMgz.com‬‬
 ‫ﻧﻔﻮﺫ ﺩﺭ ﺳﺮﻭﺭﻫﺎﻱ ﻭﺏ‬

‫ﻳﮏ ﻣﺤﻴﻂ ‪ chroot‬ﺍﺟﺮﺍﺀ ﻧﻤﻮﺩ ‪ .‬ﺩﺭﺻﻮﺭﺗﻴﮑﻪ ﺁﭘﺎﭼﯽ ﺑﺼﻮﺭﺕ ‪ chrooted‬ﺍﺟﺮﺍﺀ ﻭ ﻓﻌﺎﻟﻴﺖ ﺧﻮﺩ ﺭﺍ‬
‫ﺁﻏﺎﺯ ﻧﻤﺎﻳﺪ ‪ ،‬ﺍﻣﮑﺎﻥ ﺩﺳﺘﻴﺎﺑﯽ ﺁﻥ ﺑﻪ ﺳﺎﻳﺮ ﺑﺨﺶ ﻫﺎﯼ ﻣﻮﺟﻮﺩ ﺩﺭ ﺳﺎﺧﺘﺎﺭ ﺩﺍﻳﺮﮐﺘﻮﺭﯼ ﺳﻴﺴﺘﻢ ﻋﺎﻣﻞ‬
‫ﻭ ﺧﺎﺭﺝ ﺍﺯ ‪ chroot‬ﻭﺟﻮﺩ ﻧﺨﻮﺍﻫﺪ ﺩﺍﺷﺖ ‪ .‬ﺑﺪﻳﻦ ﺗﺮﺗﻴﺐ ﻳﮏ ﻻﻳﻪ ﺗﺪﺍﻓﻌﯽ ﻣﻨﺎﺳﺐ ﺩﺭ ﺧﺼﻮﺹ ﺳﻮﺀ‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﻫﺎﯼ ﺍﺣﺘﻤﺎﻟﯽ ﺍﻳﺠﺎﺩ ﻣﯽ ﮔﺮﺩﺩ‪ .‬ﺑﻌﻨﻮﺍﻥ ﻧﻤﻮﻧﻪ ‪ ،‬ﻣﻤﮑﻦ ﺍﺳﺖ ﻳﮏ ‪ shell‬ﻓﺮﺍﺧﻮﺍﻧﺪﻩ ﺷﺪﻩ ﻭ ﺑﺎ‬
‫ﺗﻮﺟﻪ ﺑﻪ ﺍﻳﻨﮑﻪ ‪ / bin/sky‬ﺩﺭ ‪ chroot‬ﻗﺮﺍﺭ ﻧﺪﺍﺭﺩ ‪ ،‬ﻣﯽ ﺗﻮﺍﻧﺪ ﺯﻣﻴﻨﻪ ﺳﻮﺀ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺣﺘﻤﺎﻟﯽ ﺭﺍ ﻓﺮﺍﻫﻢ‬
‫ﻧﻤﺎﻳﺪ‪ .‬ﻻﺯﻡ ﺍﺳﺖ ﺑﻪ ﺍﻳﻦ ﻧﮑﺘﻪ ﻣﻬﻢ ﻧﻴﺰ ﺍﺷﺎﺭﻩ ﮔﺮﺩﺩ ﮐﻪ ‪ Chrooting‬ﺁﭘﺎﭼﯽ ﻣﯽ ﺗﻮﺍﻧﺪ ﺍﺛﺮﺍﺕ ﺟﺎﻧﺒﯽ‬
‫ﻧﺎﻣﻄﻠﻮﺑﯽ ﺭﺍ ﺩﺭ ﺍﺭﺗﺒﺎﻁ ﺑﺎ ‪ ، CGI,PHP‬ﺑﺎﻧﮏ ﻫﺎﯼ ﺍﻃﻼﻋﺎﺗﯽ ﻭ ﺳﺎﻳﺮ ﻣﺎﮊﻭﻝ ﻫﺎ ﻭ ﻳﺎ ﺍﺭﺗﺒﺎﻃﺎﺗﯽ ﮐﻪ‬
‫ﻣﺤﻴﻂ ﺳﺮﻭﻳﺲ ﺩﻫﻨﺪﻩ ﻭﺏ ﺑﻤﻨﻈﻮﺭ ﺳﺮﻭﻳﺲ ﺩﻫﯽ ﺑﻪ ﺁﻧﺎﻥ ﻧﻴﺎﺯﻣﻨﺪ ﺩﺳﺘﻴﺎﺑﯽ ﺑﻪ ﺗﻮﺍﺑﻊ ﮐﺘﺎﺑﺨﺎﻧﻪ ﺍﯼ‬
‫ﺧﺎﺭﺟﯽ ﺍﺳﺖ ﺭﺍ ﺑﺪﻧﺒﺎﻝ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ ‪.‬ﺭﻭﺵ ﻫﺎﯼ ﻣﺘﻌﺪﺩﯼ ﺑﻤﻨﻈﻮﺭ ‪ chrooting‬ﻭﺟﻮﺩ ﺩﺍﺷﺘﻪ ﻭ ﻣﯽ‬
‫ﺑﺎﻳﺴﺖ ﺍﺯ ﻣﺴﺘﻨﺪﺍﺕ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﻣﻮﺭﺩ ﻧﻈﺮ ‪ ،‬ﺑﻌﻨﻮﺍﻥ ﻳﮏ ﻣﻨﺒﻊ ﺍﻃﻼﻋﺎﺗﯽ ﻣﻨﺎﺳﺐ ﺩﺭ ﺧﺼﻮﺹ ﺍﺭﺍﺋﻪ‬
‫ﺭﺍﻫﮑﺎﺭﻫﺎﯼ ﻣﺮﺑﻮﻃﻪ ‪ ،‬ﺍﺳﺘﻔﺎﺩﻩ ﮔﺮﺩﺩ‬

‫‪ -5‬ﺑﻤﻨﻈﻮﺭ ﻣﺪﻳﺮﻳﺖ ﻳﮏ ﺳﺮﻭﻳﺲ ﺩﻫﻨﺪﻩ ﻭﺏ ‪ ،‬ﻻﺯﻡ ﺍﺳﺖ ﻓﻴﺪﺑﮏ ﻫﺎﯼ ﻻﺯﻡ ﺩﺭ ﺧﺼﻮﺹ ﻓﻌﺎﻟﻴﺖ ﻭ‬
‫ﮐﺎﺭﺁﺋﯽ ﺳﺮﻭﻳﺲ ﺩﻫﻨﺪﻩ ﻭ ﺳﺎﻳﺮ ﻣﺴﺎﺋﻠﯽ ﮐﻪ ﻣﻤﮑﻦ ﺍﺳﺖ ﻳﮏ ﺳﺮﻭﻳﺲ ﺩﻫﻨﺪﻩ ﺑﺎ ﺁﻧﺎﻥ ﺑﺮﺧﻮﺭﺩ ﻧﻤﺎﻳﺪ‬
‫ﺭﺍ ﺍﺧﺬ ﻛﺮﺩ ﻭ ﺩﺭ ﺍﺩﺍﻣﻪ ﺑﺎ ﺁﻧﺎﻟﻴﺰ ﺁﻧﺎﻥ ﺗﻤﻬِﻴﺪﺍﺕ ﻻﺯﻡ ﺩﺭ ﺧﺼﻮﺹ ﻣﺴﺎﺋﻞ ﻣﻮﺟﻮﺩ ﺭﺍ ﺑﮑﺎﺭ ﮔﺮﻓﺖ ‪.‬‬
‫ﺳﺮﻭﻳﺲ ﺩﻫﻨﺪﻩ ﺁﭘﺎﭼﯽ ‪ ،‬ﻗﺎﺑﻠﻴﺖ ﻫﺎ ﻭ ﭘﺘﺎﻧﺴﻴﻞ ﻫﺎﯼ ﺍﻧﻌﻄﺎﻑ ﭘﺬﻳﺮﯼ ﺭﺍ ﺩﺭ ﺧﺼﻮﺹ ‪ logging‬ﺍﺭﺍﺋﻪ‬
‫ﻣﯽ ﻧﻤﺎﻳﺪ ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ ﻻﺯﻡ ﺍﺳﺖ ﻋﻤﻠﻴﺎﺕ ‪ logging‬ﺑﺎ ﺩﻗﺖ ﻧﻈﺮ ﺑﺎﻻ ﺑﺼﻮﺭﺕ ﻣﻮﺛﺮ ﻭ ﻣﻮﺷﮑﺎﻓﺎﻧﻪ‬
‫ﺍﻧﺠﺎﻡ ﮔﻴﺮﺩ ﺗﺎ ﺍﻣﮑﺎﻥ ﺭﺩﻳﺎﺑﯽ ﻫﺮ ﻧﻮﻉ ﻓﻌﺎﻟﻴﺖ ﺍﻣﻨﻴﺘﯽ ﻏﻴﺮ ﻣﺠﺎﺯ ﻭ ﻳﺎ ﺭﻓﺘﺎﺭ ﻏﻴﺮ ﻣﻨﻄﻘﯽ ﺳﺮﻭﻳﺲ‬
‫ﺩﻫﻨﺪﻩ ‪ ،‬ﻓﺮﺍﻫﻢ ﮔﺮﺩﺩ ‪.‬ﭘﻴﺸﻨﻬﺎﺩ ﻣﯽ ﮔﺮﺩﺩ ﮐﻪ ﺑﺎ ﻳﮏ ﻧﻈﻢ ﺧﺎﺹ ﺍﺯ ﺍﻃﻼﻋﺎﺕ ﻣﻮﺟﻮﺩ ﺩﺭ ﻓﺎﻳﻞ ﻫﺎﯼ ﻻﮒ‬
‫‪ ،‬ﺁﺭﺷﻴﻮ ﺗﻬﻴﻪ ﺷﻮﺩ ‪ .‬ﺑﺪﻳﻦ ﺗﺮﺗﻴﺐ ‪ ،‬ﺍﻣﮑﺎﻥ ﻣﺪﻳﺮﻳﺖ ﻓﺎﻳﻞ ﻫﺎﯼ ﻻﮒ ﻭ ﺑﺮﺭﺳﯽ ﺁﻧﺎﻥ ﻓﺮﺍﻫﻢ ﺧﻮﺍﻫﺪ ﺷﺪ‪.‬‬
‫ﺑﻤﻨﻈﻮﺭ ﺁﺷﻨﺎﺋﯽ ﺑﺎ ﻓﺮﻣﺖ ﻫﺎﯼ ﻣﺘﻔﺎﻭﺕ ﻻﮒ ﻣﯽ ﺗﻮﺍﻧﺪ ﺍﺯ ﻣﻨﺎﺑﻊ ﺯﻳﺮ ﺍﺳﺘﻔﺎﺩﻩ ﻧﻤﻮﺩ ‪:‬‬

‫ﺍﺳﺘﻔﺎﺩﻩ‬ ‫‪ -‬ﺑﺮﺍﯼ ‪ Apache 1.3.x‬ﺍﺯ ﺁﺩﺭﺱ ‪http://httpd.apache.org/docs/logs.html‬‬

‫ﺷﻮﺩ ‪.‬‬

‫‪ -‬ﺑﺮﺍﯼ ‪ Apache 2.0.x‬ﺍﺯ ﺁﺩﺭﺱ ‪ http://httpd.apache.org/docs-2.0/logs.html‬ﺍﺳﺘﻔﺎﺩﻩ‬

‫ﺷﻮﺩ ‪.‬‬

‫ﺩﺭ ﻣﻮﺍﺭﺩ ﻣﺘﻔﺎﻭﺗﯽ ﻭ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺷﺮﺍﻳﻂ ﭘﻴﺶ ﺁﻣﺪﻩ ﻣﻤﮑﻦ ﺍﺳﺖ ﻣﺤﺘﻮﯼ ﻓﺎﻳﻞ ﻫﺎﯼ ﻻﮒ ﺑﺘﻨﻬﺎﺋﯽ‬
‫ﮐﺎﻓﯽ ﻧﺒﺎﺷﺪ ‪ .‬ﻭﺿﻌﻴﺖ ﻓﻮﻕ ﺩﺭ ﻣﻮﺍﺭﺩﻳﮑﻪ ﺍﺯ ‪ CGI ، PHP‬ﻭ ﻳﺎ ﺳﺎﻳﺮ ﺗﮑﻨﻮﻟﻮﮊﯼ ﻫﺎﯼ ﻣﺒﺘﻨﯽ ﺑﺮ‬
‫ﺍﺳﮑﺮﻳﭙﺖ ﺍﺳﺘﻔﺎﺩﻩ ﻣﯽ ﮔﺮﺩﺩ ‪ ،‬ﺗﺸﺪﻳﺪ ﻣﻲ ﮔﺮﺩﺩ ﻭ ﻣﯽ ﺗﻮﺍﻥ ﺑﻤﻨﻈﻮﺭ ﺍﻓﺰﺍﻳﺶ ﺗﻮﺍﻥ ﺁﻧﺎﻟﻴﺰ ﻳﮏ ﺗﻬﺎﺟﻢ ﻭ‬
‫ﺳﻮﺀﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻳﮏ ﺿﻌﻒ ﺍﻣﻨﻴﺘﯽ ‪ ،‬ﺍﻗﺪﺍﻡ ﺑﻪ ﺛﺒﺖ ﻻﮒ ﻫﺎﯼ ﻣﺮﺑﻮﻁ ﺑﻪ ‪ GET‬ﻭ ‪ POST‬ﻧﻤﻮﺩ‪ .‬ﻻﮒ‬
‫ﻧﻤﻮﺩﻥ ﻋﻤﻠﻴﺎﺕ ﻣﺮﺗﺒﻂ ﺑﻪ ‪ GET‬ﻭ ‪ POST‬ﻣﯽ ﺗﻮﺍﻧﺪ ﺍﺯ ﻃﺮﻳﻖ ‪ mod_Security‬ﺻﻮﺭﺕ ﭘﺬﻳﺮﺩ‪.‬‬

‫‪8‬‬ ‫‪www.WebsecurityMgz.com‬‬
 ‫ﻧﻔﻮﺫ ﺩﺭ ﺳﺮﻭﺭﻫﺎﻱ ﻭﺏ‬

‫‪ ModSecurity‬ﻳﮏ ﺳﻴﺴﺘﻢ ﺗﺸﺨﻴﺺ ﻣﺰﺍﺣﻤﻴﻦ ) ‪ ( detection Intruder‬ﻣﻲ ﺑﺎﺷﺪ ﻭ ﭘﻴﺸﮕﻴﺮﯼ‬

‫ﻫﺎﯼ ﻻﺯﻡ ﺩﺭ ﺧﺼﻮﺹ ﻳﮏ ﺑﺮﻧﺎﻣﻪ ﻭﺏ ﺭﺍ ﺍﺭﺍﺋﻪ ﻣﯽ ﻧﻤﺎﻳﺪ ‪ .‬ﺳﻴﺴﺘﻢ ﻓﻮﻕ ﺑﻪ ﻫﻤﺮﺍﻩ ﺳﺮﻭﻳﺲ ﺩﻫﻨﺪﻩ‬
‫ﻭﺏ ﻣﺴﺘﻘﺮ ﻣﻲ ﺷﻮﺩ ﻭ ﻳﮏ ﭘﻮﺷﺶ ﺍﻣﻨﻴﺘﯽ ﻣﻨﺎﺳﺐ ﺭﺍ ﺩﺭ ﺟﻬﺖ ﭘﻴﺸﮕﻴﺮﯼ ﺍﺯ ﻳﮏ ﺗﻬﺎﺟﻢ ﺩﺭ ﺍﺭﺗﺒﺎﻁ‬
‫ﺑﺎ ﺑﺮﻧﺎﻣﻪ ﻫﺎﯼ ﻭﺏ ﻓﺮﺍﻫﻢ ﻣﯽ ﻧﻤﺎﻳﺪ ‪ ، ModSecurity .‬ﺍﺯ ﺳﺮﻭﻳﺲ ﺩﻫﻨﺪﻩ ﺁﭘﺎﭼﯽ ﺣﻤﺎﻳﺖ ﻣﯽ‬
‫ﻧﻤﺎﻳﺪ ‪.‬‬

‫‪-‬‬ ‫‪http://www.modsecurity.org/‬‬
‫‪-‬‬ ‫‪http://www.securityfocus.com/infocus/17064.152.44.126%20152.44.126‬‬

‫‪ SSI،CGI ، PHP -6‬ﻭ ﺳﺎﻳﺮ ﺍﺳﮑﺮﻳﭙﺖ ﻫﺎ‬

‫ﺩﺭ ﺍﻳﻦ ﺭﺍﺑﻄﻪ ﻣﻮﺍﺭﺩ ﺯﻳﺮ ﭘﻴﺸﻨﻬﺎﺩ ﻣﯽ ﮔﺮﺩﺩ ‪:‬‬

‫‪ PHP,CGI,SSI -‬ﻭ ﺳﺎﻳﺮ ﺯﺑﺎﻥ ﻫﺎﯼ ﺍﺳﮑﺮﻳﭙﺖ ﺭﺍ ﻏﻴﺮ ﻓﻌﺎﻝ ﻧﻤﺎﺋﻴﺪ ) ﻣﮕﺮ ﺍﻳﻨﮑﻪ ﺿﺮﻭﺭﺗﯽ‬
‫ﺟﺪﯼ ﺩﺭ ﺭﺍﺑﻄﻪ ﺑﺎ ﺁﻧﺎﻥ ﻭﺟﻮﺩ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ (‪.‬‬
‫‪ SSI‬ﻳﺎ ‪ Server Side Includes‬ﺭﺍ ﮐﻪ ﻣﯽ ﺗﻮﺍﻧﺪ ﺯﻣﻴﻨﻪ ﻣﺴﺎﻋﺪﯼ ﺑﻪ ﻣﻨﻈﻮﺭ ﺳﻮﺀ‬ ‫‪-‬‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺮﻭﻳﺲ ﺩﻫﻨﺪﻩ ﻓﺮﺍﻫﻢ ﻛﻨﺪ ﻭ ﺑﺎﻋﺚ ﺍﺟﺮﺍﻱ ﻛﺪﻫﺎﻱ ﻧﺎﺧﻮﺍﺳﺘﻪ ﮔﺮﺩﺩ ﺭﺍ ﻏﻴﺮ‬
‫ﻓﻌﺎﻝ ﻧﻤﺎﺋﻴﺪ ‪.‬‬
‫ﺩﺭ ﺻﻮﺭﺗﻴﮑﻪ ﺿﺮﻭﺭﯼ ﺍﺳﺖ ﮐﻪ ﺍﺯ ‪ PHP,CGI,SSI‬ﻭ ﻳﺎ ﺳﺎﻳﺮ ﺯﺑﺎﻥ ﻫﺎﯼ ﺍﺳﮑﺮﻳﭙﺖ‬ ‫‪-‬‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﮔﺮﺩﺩ ‪ ،‬ﻣﯽ ﺑﺎﻳﺴﺖ ﺍﺯ ‪ SuEXEC‬ﺍﺳﺘﻔﺎﺩﻩ ﺷﻮﺩ‪ ، suEXEC .‬ﺍﻣﮑﺎﻥ ﺍﺟﺮﺍﯼ‬
‫ﺍﺳﮑﺮﻳﭙﺖ ﻫﺎ ﺗﺤﺖ ﺁﭘﺎﭼﯽ ﺑﻬﻤﺮﺍﻩ ﻳﮏ ‪ User Id‬ﺩﺭ ﻣﻘﺎﺑﻞ ﻳﮏ ‪ Apache User Id‬ﺭﺍ ﻓﺮﺍﻫﻢ‬
‫ﻣﯽ ﻧﻤﺎﻳﺪ ﺩﺭ ﺣﻘﻴﻘﺖ ‪ suEXEC‬ﺍﻳﻦ ﺍﻣﮑﺎﻥ ﺭﺍ ﺑﺮﺍﯼ ﮐﺎﺭﺑﺮﺍﻥ ﺁﭘﺎﭼﯽ ﻓﺮﺍﻫﻢ ﻣﯽ ﻧﻤﺎﻳﺪ ﮐﻪ‬
‫ﻗﺎﺩﺭ ﺑﻪ ﺍﺟﺮﺍﯼ ﺑﺮﻧﺎﻣﻪ ﻫﺎﯼ ‪ SSI‬ﻭ ‪ CGI‬ﺗﺤﺖ ﻳﮏ ‪ User Id‬ﻣﺘﻔﺎﻭﺕ ﻧﺴﺒﺖ ﺑﻪ ‪User Id‬‬
‫ﻣﺮﺑﻮﻁ ﺑﻪ ﻓﺮﺍﺧﻮﺍﻧﯽ ﺳﺮﻭﻳﺲ ﺩﻫﻨﺪﻩ ﻭﺏ ﺑﺎﺷﻨﺪ‪.‬ﺑﺪﻳﻦ ﺗﺮﺗﻴﺐ ﺗﻬﺪﻳﺪﺍﺕ ﺍﻣﻨﻴـﺘﯽ ﮐﺎﻫﺶ ﻭ‬
‫ﺍﻣﮑﺎﻥ ﻧﻮﺷﺘﻦ ﻭ ﺍﺟﺮﺍﯼ ﺑﺮﻧﺎﻣﻪ ﻫﺎﯼ ‪ SSI‬ﻭ ‪ CGI‬ﺍﺧﺘﺼﺎﺻﯽ ﻧﻮﺷﺘﻪ ﺷﺪﻩ ﺗﻮﺳﻂ‬
‫ﻣﻬﺎﺟﻤﺎﻥ ‪ ،‬ﺣﺬﻑ ﺧﻮﺍﻫﺪ ﺷﺪ ‪ .‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ‪، suEXEC‬ﻣﯽ ﺑﺎﻳﺴﺖ ﺗﻮﺍﻡ ﺑﺎ ﺁﮔﺎﻫﯽ ﻭ ﺩﺍﻧﺶ‬
‫ﻻﺯﻡ ﺑﺎﺷﺪ ﭼﺮﺍﮐﻪ ﺩﺭ ﺻﻮﺭﺕ ﺍﺳﺘﻔﺎﺩﻩ ﻧﺎﺩﺭﺳﺖ ﻭ ﻳﺎ ﻋﺪﻡ ﭘﻴﮑﺮﺑﻨﺪﯼ ﻣﻨﺎﺳﺐ ﻭ ﺷﻨﺎﺧﺖ‬
‫ﻧﺴﺒﺖ ﺑﻪ ﻣﺪﻳﺮﻳﺖ ‪ ، setupid Root‬ﺧﻮﺩ ﺑﺎﻋﺚ ﺑﺮﻭﺯ ﺣﻔﺮﻩ ﻫﺎﯼ ﺍﻣﻨﻴﺘﯽ ﺩﻳﮕﺮ ﺧﻮﺍﻫﺪ ﺷﺪ‪..‬‬
‫ﺩﺭ ﺍﻳﻦ ﺭﺍﺑﻄﻪ ﻭ ﺑﻤﻨﻈﻮﺭ ﺁﺷﻨﺎﺋﯽ ﺑﺎ ﻧﺤﻮﻩ ﻋﻤﻠﮑﺮﺩ ﻭ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ‪ suEXEC‬ﻣﯽ ﺗﻮﺍﻥ ﺍﺯ‬
‫ﺁﺩﺭﺱ ﻫﺎﯼ ﺯﻳﺮ ﺍﺳﺘﻔﺎﺩﻩ ﻧﻤﻮﺩ‪:‬‬

‫‪ -‬ﺑﺮﺍﯼ ‪ Apache 1.3.x‬ﺍﺯ ﺁﺩﺭﺱ ﺯﻳﺮ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲ ﺷﻮﺩ ‪:‬‬

‫‪9‬‬ ‫‪www.WebsecurityMgz.com‬‬
 ‫ﻧﻔﻮﺫ ﺩﺭ ﺳﺮﻭﺭﻫﺎﻱ ﻭﺏ‬

‫‪http://httpd.apache.org/docs/suexec.html‬‬

‫‪ --‬ﺑﺮﺍﯼ ‪ Apache 2.0.x‬ﺍﺯ ﺁﺩﺭﺱ ﺯﻳﺮ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲ ﺷﻮﺩ‪:‬‬

‫‪http://httpd.apache.org/docs-2.0/suexec.html‬‬

‫‪ -‬ﺑﺮﺭﺳﯽ ﻻﺯﻡ ﺩﺭ ﺧﺼﻮﺹ ﻣﺤﺘﻮﯼ ﺩﺍﻳﺮﮐﺘﻮﺭﯼ ‪ cgi-bin‬ﻭ ﺳﺎﻳﺮ ﺩﺍﻳﺮﮐﺘﻮﺭﯼ ﻫﺎﯼ ﺷﺎﻣﻞ‬
‫ﺍﺳﮑﺮﻳﭙﺖ ﻫﺎ ﺍﻧﺠﺎﻡ ﻭ ﻻﺯﻡ ﺍﺳﺖ ﺗﻤﺎﻣﯽ ﺍﺳﮑﺮﻳﭙﺖ ﻫﺎﯼ ﭘﻴﺶ ﻓﺮﺽ ﻧﻤﻮﻧﻪ ‪ ،‬ﺣﺬﻑ ﮔﺮﺩﻧﺪ‪.‬‬

‫ﺍﻳﻤﻦ ﺳﺎﺯﯼ ‪PHP‬‬

‫ﭘﺮﺩﺍﺧﺘﻦ ﺑﻪ ﻣﻮﺿﻮﻉ ﻓﻮﻕ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﮔﺴﺘﺮﺩﮔﯽ ﻣﻄﺎﻟﺐ ﺍﺯ ﺣﻮﺻﻠﻪ ﺍﻳﻦ ﻣﻘﺎﻟﻪ ﺧﺎﺭﺝ ﺑﻮﺩﻩ ﻭ ﺻﺮﻓﺎ"‬
‫ﺑﻪ ﺩﻭ ﻧﻤﻮﻧﻪ ﻣﻬﻢ ﺩﺭ ﺍﻳﻨﺨﺼﻮﺹ ﺍﺷﺎﺭﻩ ﻣﯽ ﮔﺮﺩﺩ ‪:‬‬

‫‪ -‬ﻏﻴﺮ ﻓﻌﺎﻝ ﻧﻤﻮﺩﻥ ﭘﺎﺭﺍﻣﺘﺮﻫﺎﺋﯽ ﮐﻪ ﺑﺎﻋﺚ ﺍﺭﺍﺋﻪ ﺍﻃﻼﻋﺎﺕ ﺩﺭ ‪ HTTP header‬ﻣﯽ ﮔﺮﺩﺩ ‪.‬‬
‫ﺣﺼﻮﻝ ﺍﻃﻤﻴﻨﺎﻥ ﺍﺯ ﺍﺟﺮﺍﯼ ‪ PHP‬ﺩﺭ ﺣﺎﻟﺖ ‪safe‬‬ ‫‪-‬‬

‫ﺁﺩﺭﺱ‬ ‫ﺍﺯ‬ ‫ﺗﻮﺍﻥ‬ ‫ﻣﯽ‬ ‫ﺧﺼﻮﺹ‬ ‫ﺩﺭﺍﻳﻦ‬ ‫ﺗﮑﻤﻴﻠﯽ‬ ‫ﺍﻃﻼﻋﺎﺕ‬ ‫ﺩﺭﻳﺎﻓﺖ‬ ‫ﺑﺮﺍﯼ‬
‫‪ http://www.securityfocus.com/printable/infocus/1706‬ﺍﺳﺘﻔﺎﺩﻩ ﻧﻤﻮﺩ ‪.‬‬

‫‪ -‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﺎﮊﻭﻟﻬﺎﯼ ﺍﺿﺎﻓﻪ ﺑﻤﻨﻈﻮﺭﺑﻬﺒﻮﺩ ﻭﺿﻌﻴﺖ ﺍﻣﻨﻴﺘﯽ‪ .‬ﻣﺜﻼ"ﻣﺎﮊﻭﻝ ‪mod_Security‬‬

‫ﻣﯽ ﺗﻮﺍﻧﺪ ﺑﺎﻋﺚ ﺣﻔﺎﻇﺖ ﺩﺭ ﻣﻘﺎﺑﻞ ‪ ، XSS :Cross Site Scripting‬ﺷﻮﺩ ‪ .‬ﺑﺮﺍﯼ‬
‫ﺁﺷﻨﺎﺋﯽ ﻭ ﻣﺸﺎﻫﺪﻩ ﺍﻃﻼﻋﺎﺕ ﺗﮑﻤﻴﻠﯽ ﺩﺭ ﺍﻳﻦ ﺧﺼﻮﺹ ﻣﯽ ﺗﻮﺍﻥ ﺍﺯ ﺁﺩﺭﺱ‬
‫‪ http://www.modsecurity.org/‬ﺍﺳﺘﻔﺎﺩﻩ ﻧﻤﻮﺩ‪.‬‬
‫ﻣﻤﻴﺰﯼ ﻭ ﺑﺮﺭﺳﯽ ﺍﺳﮑﺮﻳﭙﺖ ﻫﺎ ﺑﺮﺍﯼ ﻧﻘﺎﻁ ﺁﺳﻴﺐ ﭘﺬﻳﺮ ﺷﺎﻣﻞ ‪SQL Injection & XSS‬‬ ‫‪-‬‬
‫ﻧﻴﺰ ﺣﺎﺋﺰ ﺍﻫﻤﻴﺖ ﺍﺳﺖ ‪ .‬ﺩﺭ ﺍﻳﻦ ﺭﺍﺑﻄﻪ ﻣﯽ ﺗﻮﺍﻥ ﺍﺯ ﺍﺑﺰﺍﺭﻫﺎﯼ ﻣﺘﻌﺪﺩﯼ ﺍﺳﺘﻔﺎﺩﻩ ﻧﻤﻮﺩ‪ .‬ﻧﺮﻡ‬
‫ﺍﻓﺰﺍﺭ ‪ ) Nikto‬ﻗﺎﺑﻞ ﺩﺳﺘﺮﺱ ﺩﺭ ﺁﺩﺭﺱ ‪http://www.cirt.net/code/nikto.shtml‬‬
‫( ﻳﮑﯽ ﺍﺯ ﻣﻨﺎﺳﺒﺘﺮﻳﻦ ﺍﺑﺰﺍﺭﻫﺎﯼ ﭘﻮﻳﺶ ﻭ ﺑﺮﺭﺳﯽ ‪ CGI‬ﺍﺳﺖ ‪.‬‬

‫‪10‬‬ ‫‪www.WebsecurityMgz.com‬‬