‫ﻣﺘﺮﺟﻢ ﻣﻦ ﺍﻹﻧﺠﻠﻴﺰﻳﺔ ﺇﻟﻰ ﺍﻟﻌﺮﺑﻴﺔ ‪www.onlinedoctranslator.

com -‬‬

‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺩﺱ‪-‬ﻣﻬﺎﺟﻤﺔ ﺍﻟﻤﺼﺎﺩﻗﺔ‬ ‫‪190‬‬

‫ﺟﺮﺑﻬﺎ!‬

‫‪/178/ http://mdsec.net/auth/182/‬‬
‫‪http://mdsec.net/auth‬‬

‫ﻣﻠﺤﻮﻇﺔﻓﻲ ﺑﻌﺾ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﻟﺘﻲ ﻳﺘﻐﻴﺮ ﻓﻴﻬﺎ ﺃﺣﺪ ﻣﻜﻮﻧﺎﺕ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﻋﺸﻮﺍﺉﻴﺎً‪ ،‬ﻳﺠﻤﻊ‬
‫ﺍﻟﺘﻄﺒﻴﻖﺟﻤﻴﻊ ﺑﻴﺎﻧﺎﺕ ﺍﻋﺘﻤﺎﺩ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻓﻲ ﻣﺮﺣﻠﺔ ﻭﺍﺣﺪﺓ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﻗﺪ ﺗﻌﺮﺽ ﺻﻔﺤﺔ‬
‫ﺗﺴﺠﻴﻞﺍﻟﺪﺧﻮﻝ ﺍﻟﺮﺉﻴﺴﻴﺔ ﻧﻤﻮﺫﺟﺎً ﻳﺤﺘﻮﻱ ﻋﻠﻰ ﺣﻘﻮﻝ ﻻﺳﻢ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻭﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ ﻭﺃﺣﺪ‬
‫ﺍﻷﺳﺉﻠﺔﺍﻟﺴﺮﻳﺔ ﺍﻟﻤﺘﻨﻮﻋﺔ‪ .‬ﻓﻲ ﻛﻞ ﻣﺮﺓ ﻳﺘﻢ ﻓﻴﻬﺎ ﺗﺤﻤﻴﻞ ﺻﻔﺤﺔ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ‪ ،‬ﻳﺘﻐﻴﺮ ﺍﻟﺴﺆﺍﻝ‬
‫ﺍﻟﺴﺮﻱ‪.‬ﻓﻲ ﻫﺬﻩ ﺍﻟﺤﺎﻟﺔ‪ ،‬ﻻ ﺗﻤﻨﻊ ﻋﺸﻮﺍﺉﻴﺔ ﺍﻟﺴﺆﺍﻝ ﺍﻟﺴﺮﻱ ﺍﻟﻤﻬﺎﺟﻢ ﻣﻦ ﺇﻋﺎﺩﺓ ﺗﺸﻐﻴﻞ ﻃﻠﺐ‬
‫ﺗﺴﺠﻴﻞﺩﺧﻮﻝ ﺻﺎﻟﺢ ﺑﻌﺪ ﺍﻟﺘﻘﺎﻁ ﻣﺪﺧﻼﺕ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻓﻲ ﻣﻨﺎﺳﺒﺔ ﻭﺍﺣﺪﺓ‪ .‬ﻻ ﻳﻤﻜﻦ ﺗﻌﺪﻳﻞ ﻋﻤﻠﻴﺔ‬
‫ﺗﺴﺠﻴﻞﺍﻟﺪﺧﻮﻝ ﻟﻠﻘﻴﺎﻡ ﺑﺬﻟﻚ ﻓﻲ ﺷﻜﻠﻬﺎ ﺍﻟﺤﺎﻟﻲ‪ ،‬ﻷﻧﻪ ﻳﻤﻜﻦ ﻟﻠﻤﻬﺎﺟﻢ ﺑﺒﺴﺎﻃﺔ ﺇﻋﺎﺩﺓ ﺗﺤﻤﻴﻞ‬
‫ﺍﻟﺼﻔﺤﺔﺣﺘﻰ ﻳﺘﻠﻘﻰ ﺍﻟﺴﺆﺍﻝ ﺍﻟﻤﺘﻐﻴﺮ ﺍﻟﺬﻱ ﻳﻌﺮﻑ ﺇﺟﺎﺑﺘﻪ‪ .‬ﻓﻲ ﺗﻨﻮﻳﻌﺔ ﻋﻠﻰ ﻫﺬﺍ ﺍﻟﺴﻴﻨﺎﺭﻳﻮ‪ ،‬ﻗﺪ ﻳﻘﻮﻡ‬
‫ﺍﻟﺘﻄﺒﻴﻖﺑﺘﻌﻴﻴﻦ ﻣﻠﻒ ﺗﻌﺮﻳﻒ ﺍﺭﺗﺒﺎﻁ ﺩﺍﺉﻢ "ﻟﻀﻤﺎﻥ" ﻋﺮﺽ ﻧﻔﺲ ﺍﻟﺴﺆﺍﻝ ﺍﻟﻤﺘﻐﻴﺮ ﻷﻱ ﻣﺴﺘﺨﺪﻡ‬
‫ﻣﻌﻴﻦﺣﺘﻰ ﻳﺠﻴﺐ ﻋﻠﻴﻪ ﺑﺸﻜﻞ ﺻﺤﻴﺢ‪ .‬ﺑﺎﻟﻄﺒﻊ‪ ،‬ﻳﻤﻜﻦ ﺍﻟﺘﺤﺎﻳﻞ ﻋﻠﻰ ﻫﺬﺍ ﺍﻹﺟﺮﺍء ﺑﺴﻬﻮﻟﺔ ﻋﻦ ﻃﺮﻳﻖ‬
‫ﺗﻌﺪﻳﻞﻣﻠﻒ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﺃﻭ ﺣﺬﻓﻪ‪.‬‬

‫ﺍﻟﺘﺨﺰﻳﻦﻏﻴﺮ ﺍﻵﻣﻦ ﻟﺒﻴﺎﻧﺎﺕ ﺍﻻﻋﺘﻤﺎﺩ‬

‫ﺇﺫﺍﻗﺎﻡ ﺃﺣﺪ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺑﺘﺨﺰﻳﻦ ﺑﻴﺎﻧﺎﺕ ﺍﻋﺘﻤﺎﺩ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﺑﺸﻜﻞ ﻏﻴﺮ ﺁﻣﻦ‪ ،‬ﻓﺴﻴﺘﻢ ﺗﻘﻮﻳﺾ‬
‫ﺃﻣﺎﻥﺁﻟﻴﺔ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ‪ ،‬ﺣﺘﻰ ﻟﻮ ﻟﻢ ﻳﻜﻦ ﻫﻨﺎﻙ ﺧﻠﻞ ﺟﻮﻫﺮﻱ ﻓﻲ ﻋﻤﻠﻴﺔ ﺍﻟﻤﺼﺎﺩﻗﺔ ﻧﻔﺴﻬﺎ‪.‬‬

‫ﻣﻦﺍﻟﺸﺎﺉﻊ ﻣﻮﺍﺟﻬﺔ ﺗﻄﺒﻴﻘﺎﺕ ﻭﻳﺐ ﺗﺨُﺰﻥَّ ﻓﻴﻬﺎ ﺑﻴﺎﻧﺎﺕ ﺍﻋﺘﻤﺎﺩ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺑﺸﻜﻞ ﻏﻴﺮ ﺁﻣﻦ‬
‫ﺩﺍﺧﻞﻗﺎﻋﺪﺓ ﺍﻟﺒﻴﺎﻧﺎﺕ‪ .‬ﻗﺪ ﻳﺸﻤﻞ ﺫﻟﻚ ﺗﺨﺰﻳﻦ ﻛﻠﻤﺎﺕ ﺍﻟﻤﺮﻭﺭ ﺑﻨﺺ ﻋﺎﺩﻱ‪ .‬ﻭﻟﻜﻦ ﺇﺫﺍ ﻛﺎﻧﺖ ﻛﻠﻤﺎﺕ‬
‫ﺍﻟﻤﺮﻭﺭﺗﺠُﺰﺃَّ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺧﻮﺍﺭﺯﻣﻴﺔ ﻗﻴﺎﺳﻴﺔ ﻣﺜﻞ ‪ MD5‬ﺃﻭ ‪ ،SHA-1‬ﻓﺈﻥ ﻫﺬﺍ ﻳﺴﻤﺢ ﻟﻠﻤﻬﺎﺟﻢ ﺑﺎﻟﺒﺤﺚ‬
‫ﺑﺒﺴﺎﻃﺔﻋﻦ ﻗﻴﻢ ﺍﻟﺘﺠﺰﺉﺔ ﺍﻟﻤﻼُﺣﻈﺔ ﻓﻲ ﻗﺎﻋﺪﺓ ﺑﻴﺎﻧﺎﺕ ﻣﺤُﺴﻮﺑﺔ ﻣﺴﺒﻘﺎً ﻟﻘﻴﻢ ﺍﻟﺘﺠﺰﺉﺔ‪ .‬ﻭﻷﻥ‬
‫ﺣﺴﺎﺏﻗﺎﻋﺪﺓ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺍﻟﺬﻱ ﻳﺴﺘﺨﺪﻣﻪ ﺍﻟﺘﻄﺒﻴﻖ ﻳﺠﺐ ﺃﻥ ﻳﺘﻤﺘﻊ ﺑﺼﻼﺣﻴﺔ ﻗﺮﺍءﺓ‪/‬ﻛﺘﺎﺑﺔ ﻛﺎﻣﻠﺔ ﻟﻬﺬﻩ‬
‫ﺍﻟﺒﻴﺎﻧﺎﺕ‪،‬ﻓﻘﺪ ﺗﻜﻮﻥ ﺍﻟﻌﺪﻳﺪ ﻣﻦ ﺍﻟﺜﻐﺮﺍﺕ ﺍﻷﻣﻨﻴﺔ ﺍﻷﺧﺮﻯ ﺩﺍﺧﻞ ﺍﻟﺘﻄﺒﻴﻖ ﻗﺎﺑﻠﺔ ﻟﻼﺳﺘﻐﻼﻝ ﻟﺘﻤﻜﻴﻨﻚ‬
‫ﻣﻦﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﻫﺬﻩ ﺍﻟﺒﻴﺎﻧﺎﺕ‪ ،‬ﻣﺜﻞ ﻋﻴﻮﺏ ﺍﻷﻭﺍﻣﺮ ﺃﻭ ﺣﻘﻦ ‪) SQL‬ﺍﻧﻈﺮ ﺍﻟﻔﺼﻞ ‪ (9‬ﻭﻧﻘﺎﻁ ﺿﻌﻒ‬
‫ﺍﻟﺘﺤﻜﻢﻓﻲ ﺍﻟﻮﺻﻮﻝ )ﺍﻧﻈﺮ ﺍﻟﻔﺼﻞ ‪.(8‬‬

‫ﺗﺘﻮﻓﺮﻫﻨﺎ ﺑﻌﺾ ﻗﻮﺍﻋﺪ ﺍﻟﺒﻴﺎﻧﺎﺕ ﻋﺒﺮ ﺍﻹﻧﺘﺮﻧﺖ ﻟﻮﻇﺎﺉﻒ ﺍﻟﺘﺠﺰﺉﺔ ﺍﻟﺸﺎﺉﻌﺔ‪:‬‬ ‫ﻧﺼﻴﺤﺔ‬

‫‪http://passcracking.com/index.php‬‬
‫‪/decrypter-dechiffrer-cracker-hash-md5/ script-hash-md5.php‬‬
‫‪http://authsecu.com‬‬
‫‪191‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺩﺱ‪-‬ﻣﻬﺎﺟﻤﺔ ﺍﻟﻤﺼﺎﺩﻗﺔ‬

‫ﺧﻄﻮﺍﺕﺍﻻﺧﺘﺮﺍﻕ‬

‫‪.1‬ﺭﺍﺟﻊ ﺟﻤﻴﻊ ﻭﻇﺎﺉﻒ ﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﻤﺘﻌﻠﻘﺔ ﺑﺎﻟﻤﺼﺎﺩﻗﺔ‪ ،‬ﺑﺎﻹﺿﺎﻓﺔ ﺇﻟﻰ ﺃﻱ ﻭﻇﺎﺉﻒ ﺗﺘﻌﻠﻖ ﺑﺼﻴﺎﻧﺔ‬
‫ﺍﻟﻤﺴﺘﺨﺪﻡ‪.‬ﺇﺫﺍ ﻻﺣﻈﺖ َﺃﻱ ﺣﺎﻻﺕ ﺗﺮُﺳﻞَ ﻓﻴﻬﺎ ﻛﻠﻤﺔ ﻣﺮﻭﺭ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺇﻟﻰ ﺍﻟﻌﻤﻴﻞ‪ ،‬ﻓﻬﺬﺍ‬
‫ﻳﺸُﻴﺮﺇﻟﻰ ﺃﻥ ﻛﻠﻤﺎﺕ ﺍﻟﻤﺮﻭﺭ ﻣﺨُﺰﻧَّﺔ ﺑﺸﻜﻞ ﻏﻴﺮ ﺁﻣﻦ‪ ،‬ﺇﻣﺎ ﺑﻨﺺ ﻋﺎﺩﻱ ﺃﻭ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺗﺸﻔﻴﺮ‬
‫ﻋﻜﺴﻲ‪.‬‬

‫‪.2‬ﺇﺫﺍ ﺗﻢ ﺗﺤﺪﻳﺪ ﺃﻱ ﻧﻮﻉ ﻣﻦ ﺍﻟﺜﻐﺮﺍﺕ ﺍﻷﻣﻨﻴﺔ ﺍﻟﻤﺘﻌﻠﻘﺔ ﺑﺘﻨﻔﻴﺬ ﺍﻷﻭﺍﻣﺮ ﺃﻭ ﺍﻻﺳﺘﻌﻼﻣﺎﺕ‬

‫ﺍﻟﺘﻌﺴﻔﻴﺔﺩﺍﺧﻞ ﺍﻟﺘﻄﺒﻴﻖ‪ ،‬ﻓﺤﺎﻭﻝ ﺍﻟﻌﺜﻮﺭ ﻋﻠﻰ ﺍﻟﻤﻮﻗﻊ ﺩﺍﺧﻞ ﻗﺎﻋﺪﺓ ﺑﻴﺎﻧﺎﺕ ﺍﻟﺘﻄﺒﻴﻖ ﺃﻭ‬
‫ﻧﻈﺎﻡﺍﻟﻤﻠﻔﺎﺕ ﺣﻴﺚ ﻳﺘﻢ ﺗﺨﺰﻳﻦ ﺑﻴﺎﻧﺎﺕ ﺍﻋﺘﻤﺎﺩ ﺍﻟﻤﺴﺘﺨﺪﻡ‪:‬‬
‫ﺃ‪.‬ﺍﺳﺘﻔﺴﺮ ﻋﻦ ﻫﺬﻩ ﺍﻟﻤﻌﻠﻮﻣﺎﺕ ﻟﺘﺤﺪﻳﺪ ﻣﺎ ﺇﺫﺍ ﻛﺎﻧﺖ ﻛﻠﻤﺎﺕ ﺍﻟﻤﺮﻭﺭ ﻣﺨﺰﻧﺔ ﻓﻲ ﺷﻜﻞ‬
‫ﻏﻴﺮﻣﺸﻔﺮ‪.‬‬
‫ﺏ‪.‬ﺇﺫﺍ ﺗﻢ ﺗﺨﺰﻳﻦ ﻛﻠﻤﺎﺕ ﺍﻟﻤﺮﻭﺭ ﻓﻲ ﺷﻜﻞ ﻣﺠُﺰﺃ‪ ،‬ﻓﺘﺤﻘﻖ ﻣﻦ ﺍﻟﻘﻴﻢ ﻏﻴﺮ ﺍﻟﻔﺮﻳﺪﺓ‪ ،‬ﻣﻤﺎ‬
‫ﻳﺸﻴﺮﺇﻟﻰ ﺃﻥ ﺍﻟﺤﺴﺎﺏ ﻟﺪﻳﻪ ﻛﻠﻤﺔ ﻣﺮﻭﺭ ﻣﺸﺘﺮﻛﺔ ﺃﻭ ﺍﻓﺘﺮﺍﺿﻴﺔ ﻣﻌﻴﻨﺔ‪ ،‬ﻭﺃﻥ‬
‫ﺍﻟﺘﺠﺰﺉﺎﺕﻻ ﻳﺘﻢ ﺗﻤﻠﻴﺤﻬﺎ‪.‬‬
‫ﺝ‪.‬ﺇﺫﺍ ﺗﻢ ﺗﺸﻔﻴﺮ ﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺧﻮﺍﺭﺯﻣﻴﺔ ﻗﻴﺎﺳﻴﺔ ﻓﻲ ﺷﻜﻞ ﻏﻴﺮ ﻣﻤﻠﺢ‪ ،‬ﻓﺎﺳﺘﻔﺴﺮ‬
‫ﻋﻦﻗﻮﺍﻋﺪ ﺑﻴﺎﻧﺎﺕ ﺍﻟﺘﺠﺰﺉﺔ ﻋﺒﺮ ﺍﻹﻧﺘﺮﻧﺖ ﻟﺘﺤﺪﻳﺪ ﻗﻴﻤﺔ ﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ ﺍﻟﻨﺼﻴﺔ ﺍﻟﻮﺍﺿﺤﺔ‬
‫ﺍﻟﻤﻘﺎﺑﻠﺔ‪.‬‬

‫ﺗﺄﻣﻴﻦﺍﻟﻤﺼﺎﺩﻗﺔ‬

‫ﻳﺘﻀﻤﻦﺗﻄﺒﻴﻖ ﺣﻠﻮﻝ ﻣﺼﺎﺩﻗﺔ ﺁﻣﻨﺔ ﺍﻟﺴﻌﻲ ﻟﺘﺤﻘﻴﻖ ﻋﺪﺓ ﺃﻫﺪﺍﻑ ﺃﻣﻨﻴﺔ ﺭﺉﻴﺴﻴﺔ ﻓﻲ ﺁﻥ ٍﻭﺍﺣﺪ‪،‬‬
‫ﻭﻓﻲﻛﺜﻴﺮ ﻣﻦ ﺍﻟﺤﺎﻻﺕ‪ ،‬ﻳﺘﻌﺎﺭﺽ ﺫﻟﻚ ﻣﻊ ﺃﻫﺪﺍﻑ ﺃﺧﺮﻯ‪ ،‬ﻣﺜﻞ ﺍﻷﺩﺍء ﺍﻟﻮﻇﻴﻔﻲ ﻭﺳﻬﻮﻟﺔ ﺍﻻﺳﺘﺨﺪﺍﻡ‬
‫ﻭﺍﻟﺘﻜﻠﻔﺔﺍﻹﺟﻤﺎﻟﻴﺔ‪ .‬ﻓﻲ ﺑﻌﺾ ﺍﻟﺤﺎﻻﺕ‪ ،‬ﻗﺪ ﻳﺆﺩﻱ "ﺯﻳﺎﺩﺓ" ﺍﻷﻣﺎﻥ ﺇﻟﻰ ﻧﺘﺎﺉﺞ ﻋﻜﺴﻴﺔ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ‬
‫ﺍﻟﻤﺜﺎﻝ‪،‬ﻳﺆﺩﻱ ﺇﺟﺒﺎﺭ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﻋﻠﻰ ﺗﻌﻴﻴﻦ ﻛﻠﻤﺎﺕ ﻣﺮﻭﺭ ﻃﻮﻳﻠﺔ ﺟﺪﺍً ﻭﺗﻐﻴﻴﺮﻫﺎ ﺑﺸﻜﻞ ﻣﺘﻜﺮﺭ ﺇﻟﻰ‬
‫ﺗﺪﻭﻳﻦﻛﻠﻤﺎﺕ ﺍﻟﻤﺮﻭﺭ ﺍﻟﺨﺎﺻﺔ ﺑﻬﻢ‪.‬‬

‫ﻧﻈﺮﺍًﻟﻠﺘﻨﻮﻉ ﺍﻟﻬﺎﺉﻞ ﻓﻲ ﺛﻐﺮﺍﺕ ﺍﻟﻤﺼﺎﺩﻗﺔ ﺍﻟﻤﺤﺘﻤﻠﺔ‪ ،‬ﻭﺍﻟﺪﻓﺎﻋﺎﺕ ﺍﻟﻤﻌﻘﺪﺓ ﺍﻟﺘﻲ ﻗﺪ ﻳﺤﺘﺎﺝ‬

‫ﺍﻟﺘﻄﺒﻴﻖﺇﻟﻰ ﻧﺸﺮﻫﺎ ﻟﻠﺘﺨﻔﻴﻒ ﻣﻦ ﺣﺪﺗﻬﺎ‪ ،‬ﻳﺨﺘﺎﺭ ﺍﻟﻌﺪﻳﺪ ﻣﻦ ﻣﺼﻤﻤﻲ ﻭﻣﻄﻮﺭﻱ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﻗﺒﻮﻝ‬
‫ﺑﻌﺾﺍﻟﺘﻬﺪﻳﺪﺍﺕ ﻛﺄﻣﺮ ﻣﺴﻠﻢ ﺑﻪ‪ ،‬ﻭﺍﻟﺘﺮﻛﻴﺰ ﻋﻠﻰ ﻣﻨﻊ ﺃﺧﻄﺮ ﺍﻟﻬﺠﻤﺎﺕ‪ .‬ﻓﻴﻤﺎ ﻳﻠﻲ ﺑﻌﺾ ﺍﻟﻌﻮﺍﻣﻞ ﺍﻟﺘﻲ‬
‫ﻳﺠﺐﻣﺮﺍﻋﺎﺗﻬﺎ ﻟﺘﺤﻘﻴﻖ ﺍﻟﺘﻮﺍﺯﻥ ﺍﻟﻤﻨﺎﺳﺐ‪:‬‬

‫ﺃﻫﻤﻴﺔﺍﻷﻣﻦ ﺑﺎﻟﻨﻈﺮ ﺇﻟﻰ ﺍﻟﻮﻇﺎﺉﻒ ﺍﻟﺘﻲ ﻳﻘﺪﻣﻬﺎ ﺍﻟﺘﻄﺒﻴﻖ‬ ‫‪-‬‬

‫ﻣﺪﻯﻗﺪﺭﺓ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﻋﻠﻰ ﺗﺤﻤﻞ ﺃﻧﻮﺍﻉ ﻣﺨﺘﻠﻔﺔ ﻣﻦ ﻋﻨﺎﺻﺮ ﺍﻟﺘﺤﻜﻢ ﻓﻲ ﺍﻟﻤﺼﺎﺩﻗﺔ‬ ‫‪-‬‬

‫ﻭﺍﻟﻌﻤﻞﻣﻌﻬﺎ‬
‫ﺗﻜﻠﻔﺔﺩﻋﻢ ﻧﻈﺎﻡ ﺃﻗﻞ ﺳﻬﻮﻟﺔ ﻓﻲ ﺍﻻﺳﺘﺨﺪﺍﻡ‬ ‫‪-‬‬

‫ﺍﻟﺘﻜﻠﻔﺔﺍﻟﻤﺎﻟﻴﺔ ﻟﻠﺒﺪﺍﺉﻞ ﺍﻟﻤﺘﻨﺎﻓﺴﺔ ﻓﻴﻤﺎ ﻳﺘﻌﻠﻖ ﺑﺎﻹﻳﺮﺍﺩﺍﺕ ﺍﻟﺘﻲ ﻣﻦ ﺍﻟﻤﺤﺘﻤﻞ ﺃﻥ ﺗﻮﻟﺪﻫﺎ‬ ‫‪-‬‬

‫ﺍﻟﺘﻄﺒﻴﻘﺎﺕﺃﻭ ﻗﻴﻤﺔ ﺍﻷﺻﻮﻝ ﺍﻟﺘﻲ ﺗﺤﻤﻴﻬﺎ‬

 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺩﺱ‪-‬ﻣﻬﺎﺟﻤﺔ ﺍﻟﻤﺼﺎﺩﻗﺔ‬ ‫‪192‬‬

‫ﻳﺼﻒﻫﺬﺍ ﺍﻟﻘﺴﻢ ﺃﻛﺜﺮ ﺍﻟﻄﺮﻕ ﻓﻌﺎﻟﻴﺔ ًﻹﺣﺒﺎﻁ ﻣﺨﺘﻠﻒ ﺍﻟﻬﺠﻤﺎﺕ ﻋﻠﻰ ﺁﻟﻴﺎﺕ ﺍﻟﻤﺼﺎﺩﻗﺔ‪.‬‬
‫ﻭﺳﻨﺘﺮﻙﻟﻜﻢ ﺍﺧﺘﻴﺎﺭ ﺃﻧﻮﺍﻉ ﺍﻟﺪﻓﺎﻋﺎﺕ ﺍﻷﻧﺴﺐ ﻟﻜﻞ ﺣﺎﻟﺔ‪.‬‬

‫ﺍﺳﺘﺨﺪﻡﺑﻴﺎﻧﺎﺕ ﺍﻋﺘﻤﺎﺩ ﻗﻮﻳﺔ‬

‫ﻳﺠﺐﺗﻄﺒﻴﻖ ﻣﺘﻄﻠﺒﺎﺕ ﺟﻮﺩﺓ ﻛﻠﻤﺎﺕ ﺍﻟﻤﺮﻭﺭ ﺍﻟﺪﻧﻴﺎ ﺍﻟﻤﻨﺎﺳﺒﺔ‪ .‬ﻗﺪ ﺗﺸﻤﻞ ﻫﺬﻩ ﺍﻟﻤﺘﻄﻠﺒﺎﺕ‬ ‫‪-‬‬

‫ﻗﻮﺍﻋﺪﺗﺘﻌﻠﻖ ﺑﺎﻟﺤﺪ ﺍﻷﺩﻧﻰ ﻟﻠﻄﻮﻝ‪ ،‬ﻭﻇﻬﻮﺭ ﺍﻷﺣﺮﻑ ﺍﻷﺑﺠﺪﻳﺔ ﻭﺍﻟﺮﻗﻤﻴﺔ ﻭﺍﻟﻄﺒﺎﻋﻴﺔ‪ ،‬ﻭﻇﻬﻮﺭ‬
‫ﺍﻷﺣﺮﻑﺍﻟﻜﺒﻴﺮﺓ ﻭﺍﻟﺼﻐﻴﺮﺓ‪ ،‬ﻭﺗﺠﻨﺐ ﺍﺳﺘﺨﺪﺍﻡ ﻛﻠﻤﺎﺕ ﺍﻟﻤﺮﻭﺭ ﺍﻟﺸﺎﺉﻌﺔ ﻣﺜﻞ ﺍﻟﻜﻠﻤﺎﺕ‬
‫ﺍﻟﻤﻌﺠﻤﻴﺔﻭﺍﻷﺳﻤﺎء‪ ،‬ﻭﻣﻨﻊ ﺗﻌﻴﻴﻦ ﻛﻠﻤﺔ ﻣﺮﻭﺭ ﺑﺎﺳﻢ ﺍﻟﻤﺴﺘﺨﺪﻡ‪ ،‬ﻭﻣﻨﻊ ﺍﻟﺘﺸﺎﺑﻪ ﺃﻭ ﺍﻟﺘﻄﺎﺑﻖ‬
‫ﻣﻊﻛﻠﻤﺎﺕ ﺍﻟﻤﺮﻭﺭ ﺍﻟﻤﺤُﺪﺩﺓ ﺳﺎﺑﻘﺎً‪ .‬ﻭﻛﻤﺎ ﻫﻮ ﺍﻟﺤﺎﻝ ﻣﻊ ﻣﻌﻈﻢ ﺇﺟﺮﺍءﺍﺕ ﺍﻷﻣﺎﻥ‪ ،‬ﻗﺪ ﺗﺨﺘﻠﻒ‬
‫ﻣﺘﻄﻠﺒﺎﺕﺟﻮﺩﺓ ﻛﻠﻤﺎﺕ ﺍﻟﻤﺮﻭﺭ ﺑﺎﺧﺘﻼﻑ ﻓﺉﺎﺕ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ‪.‬‬

‫ﻳﻨﺒﻐﻲﺃﻥ ﺗﻜﻮﻥ ﺃﺳﻤﺎء ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﻓﺮﻳﺪﺓ‪.‬‬ ‫‪-‬‬

‫ﻳﺠﺐﺇﻧﺸﺎء ﺃﻱ ﺃﺳﻤﺎء ﻣﺴﺘﺨﺪﻣﻴﻦ ﻭﻛﻠﻤﺎﺕ ﻣﺮﻭﺭ ﻳﺘﻢ ﺇﻧﺸﺎﺅﻫﺎ ﺑﻮﺍﺳﻄﺔ ﺍﻟﻨﻈﺎﻡ ﺑﻘﺪﺭ ﻛﺎﻑ ٍ‬ ‫‪-‬‬

‫ﻣﻦﺍﻹﻧﺘﺮﻭﺑﻴﺎ ﺑﺤﻴﺚ ﻻ ﻳﻤﻜﻦ ﺗﺴﻠﺴﻠﻬﺎ ﺃﻭ ﺍﻟﺘﻨﺒﺆ ﺑﻬﺎ ﺑﺸﻜﻞ ﻋﻤﻠﻲ ‪ -‬ﺣﺘﻰ ﻣﻦ ﻗﺒﻞ ﺍﻟﻤﻬﺎﺟﻢ‬
‫ﺍﻟﺬﻱﻳﺤﺼﻞ ﻋﻠﻰ ﺣﻖ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﻋﻴﻨﺔ ﻛﺒﻴﺮﺓ ﻣﻦ ﺍﻟﺤﺎﻻﺕ ﺍﻟﺘﻲ ﺗﻢ ﺇﻧﺸﺎﺅﻫﺎ ﻋﻠﻰ ﺍﻟﺘﻮﺍﻟﻲ‪.‬‬

‫ﻳﻨﺒﻐﻲﺍﻟﺴﻤﺎﺡ ﻟﻠﻤﺴﺘﺨﺪﻣﻴﻦ ﺑﺎﺧﺘﻴﺎﺭ ﻛﻠﻤﺎﺕ ﻣﺮﻭﺭ ﻗﻮﻳﺔ ﺑﻤﺎ ﻳﻜﻔﻲ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪،‬‬ ‫‪-‬‬

‫ﻳﻨﺒﻐﻲﺍﻟﺴﻤﺎﺡ ﺑﺎﺳﺘﺨﺪﺍﻡ ﻛﻠﻤﺎﺕ ﻣﺮﻭﺭ ﻃﻮﻳﻠﺔ ﻭﻭﺍﺳﻌﺔ ﺍﻟﻨﻄﺎﻕ‪.‬‬

‫ﺍﻟﺘﻌﺎﻣﻞﻣﻊ ﺑﻴﺎﻧﺎﺕ ﺍﻻﻋﺘﻤﺎﺩ ﺑﺴﺮﻳﺔ‬

‫ﻳﻨﺒﻐﻲﺇﻧﺸﺎء ﺟﻤﻴﻊ ﺑﻴﺎﻧﺎﺕ ﺍﻻﻋﺘﻤﺎﺩ ﻭﺗﺨﺰﻳﻨﻬﺎ ﻭﻧﻘﻠﻬﺎ ﺑﻄﺮﻳﻘﺔ ﻻ ﺗﺆﺩﻱ ﺇﻟﻰ ﺍﻟﻜﺸﻒ ﻏﻴﺮ‬ ‫‪-‬‬

‫ﺍﻟﻤﺼﺮﺡﺑﻪ‪.‬‬
‫ﻳﺠﺐﺣﻤﺎﻳﺔ ﺟﻤﻴﻊ ﺍﺗﺼﺎﻻﺕ ﺍﻟﻌﻤﻴﻞ ﻭﺍﻟﺨﺎﺩﻡ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺗﻘﻨﻴﺔ ﺗﺸﻔﻴﺮ ﺭﺍﺳﺨﺔ‪ ،‬ﻣﺜﻞ ‪.SSL‬‬ ‫‪-‬‬

‫ﺍﻟﺤﻠﻮﻝﺍﻟﻤﺨﺼﺼﺔ ﻟﺤﻤﺎﻳﺔ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺃﺛﻨﺎء ﺍﻟﻨﻘﻞ ﻏﻴﺮ ﺿﺮﻭﺭﻳﺔ ﻭﻻ ﻣﺮﻏﻮﺑﺔ‪.‬‬

‫ﺇﺫﺍﻛﺎﻥ ﻣﻦ ﺍﻷﻓﻀﻞ ﺍﺳﺘﺨﺪﺍﻡ ‪ HTTP‬ﻟﻠﻤﻨﺎﻃﻖ ﻏﻴﺮ ﺍﻟﻤﺼﺎﺩﻕ ﻋﻠﻴﻬﺎ ﻓﻲ ﺍﻟﺘﻄﺒﻴﻖ‪ ،‬ﻓﺘﺄﻛﺪ‬ ‫‪-‬‬

‫ﻣﻦﺗﺤﻤﻴﻞ ﻧﻤﻮﺫﺝ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﻧﻔﺴﻪ ﺑﺎﺳﺘﺨﺪﺍﻡ ‪ ،HTTPS‬ﺑﺪﻻ ًﻣﻦ ﺍﻟﺘﺒﺪﻳﻞ ﺇﻟﻰ ‪HTTPS‬‬
‫ﻋﻨﺪﻧﻘﻄﺔ ﺇﺭﺳﺎﻝ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ‪.‬‬
‫ﻓﻘﻂﺑﺮﻳﺪﻳﺠﺐ ﺍﺳﺘﺨﺪﺍﻡ ﺍﻟﻄﻠﺒﺎﺕ ﻹﺭﺳﺎﻝ ﺑﻴﺎﻧﺎﺕ ﺍﻻﻋﺘﻤﺎﺩ ﺇﻟﻰ ﺍﻟﺨﺎﺩﻡ‪ .‬ﻳﺠﺐ ﻋﺪﻡ ﻭﺿﻊ‬ ‫‪-‬‬

‫ﺑﻴﺎﻧﺎﺕﺍﻻﻋﺘﻤﺎﺩ ﻓﻲ ﻣﻌﻠﻤﺎﺕ ﻋﻨﺎﻭﻳﻦ ‪ URL‬ﺃﻭ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ )ﺣﺘﻰ ﺍﻟﻤﺆﻗﺘﺔ ﻣﻨﻬﺎ(‪.‬‬
‫ﻳﺠﺐﻋﺪﻡ ﺇﺭﺳﺎﻝ ﺑﻴﺎﻧﺎﺕ ﺍﻻﻋﺘﻤﺎﺩ ﻣﺮﺓ ﺃﺧﺮﻯ ﺇﻟﻰ ﺍﻟﻌﻤﻴﻞ‪ ،‬ﺣﺘﻰ ﻓﻲ ﻣﻌﻠﻤﺎﺕ ﺇﻋﺎﺩﺓ ﺍﻟﺘﻮﺟﻴﻪ‪.‬‬

‫ﻳﺠﺐﻋﻠﻰ ﺟﻤﻴﻊ ﻣﻜﻮﻧﺎﺕ ﺗﻄﺒﻴﻖ ﺟﺎﻧﺐ ﺍﻟﺨﺎﺩﻡ ﺗﺨﺰﻳﻦ ﺑﻴﺎﻧﺎﺕ ﺍﻻﻋﺘﻤﺎﺩ ﺑﻄﺮﻳﻘﺔ ﻻ ﺗﺴﻤﺢ‬ ‫‪-‬‬

‫ﺑﺎﺳﺘﻌﺎﺩﺓﻗﻴﻤﻬﺎ ﺍﻷﺻﻠﻴﺔ ﺑﺴﻬﻮﻟﺔ‪ ،‬ﺣﺘﻰ ﻣﻦ ﻗﺒﻞ ﺍﻟﻤﻬﺎﺟﻢ ﺍﻟﺬﻱ ﻳﺤﺼﻞ ﻋﻠﻰ ﺣﻖ ﺍﻟﻮﺻﻮﻝ‬
‫ﺍﻟﻜﺎﻣﻞﺇﻟﻰ ﺟﻤﻴﻊ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺫﺍﺕ ﺍﻟﺼﻠﺔ ﺩﺍﺧﻞ‬
‫‪193‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺩﺱ‪-‬ﻣﻬﺎﺟﻤﺔ ﺍﻟﻤﺼﺎﺩﻗﺔ‬

‫ﻗﺎﻋﺪﺓﺑﻴﺎﻧﺎﺕ ﺍﻟﺘﻄﺒﻴﻖ‪ .‬ﺍﻟﻄﺮﻳﻘﺔ ﺍﻟﻤﻌﺘﺎﺩﺓ ﻟﺘﺤﻘﻴﻖ ﻫﺬﺍ ﺍﻟﻬﺪﻑ ﻫﻲ ﺍﺳﺘﺨﺪﺍﻡ ﺩﺍﻟﺔ ﺗﺠﺰﺉﺔ‬
‫ﻗﻮﻳﺔ)ﻣﺜﻞ ‪ SHA-256‬ﻭﻗﺖ ﻛﺘﺎﺑﺔ ﻫﺬﻩ ﺍﻟﺴﻄﻮﺭ(‪ ،‬ﻣﻤُﻠﺤّﺔ ﺑﺸﻜﻞ ﻣﻨﺎﺳﺐ ﻟﺘﻘﻠﻴﻞ ﻓﻌﺎﻟﻴﺔ‬
‫ﺍﻟﻬﺠﻤﺎﺕﻏﻴﺮ ﺍﻟﻤﺘﺼﻠﺔ ﺑﺎﻹﻧﺘﺮﻧﺖ ﻭﺍﻟﻤﺤُﺴﻮﺑﺔ ﻣﺴﺒﻘﺎً‪ .‬ﻳﺠﺐ ﺃﻥ ﺗﻜﻮﻥ ﻗﻴﻤﺔ ﺍﻟﻤﻤُﻠﺤّﺔ ﺧﺎﺻﺔ‬
‫ﺑﺎﻟﺤﺴﺎﺏﺻﺎﺣﺐ ﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ‪ ،‬ﺑﺤﻴﺚ ﻻ ﻳﺘﻤﻜﻦ ﺍﻟﻤﻬﺎﺟﻢ ﻣﻦ ﺇﻋﺎﺩﺓ ﺗﺸﻐﻴﻞ ﻗﻴﻢ ﺍﻟﺘﺠﺰﺉﺔ‬
‫ﺃﻭﺍﺳﺘﺒﺪﺍﻟﻬﺎ‪.‬‬
‫ﻳﻨﺒﻐﻲﺃﻥ ﺗﻘﺘﺼﺮ ﻭﻇﻴﻔﺔ "ﺗﺬﻛﺮﻧﻲ" ﻣﻦ ﺟﺎﻧﺐ ﺍﻟﻌﻤﻴﻞ ﻋﻠﻰ ﺗﺬﻛﺮ ﺍﻟﻌﻨﺎﺻﺮ ﻏﻴﺮ ﺍﻟﺴﺮﻳﺔ ﻓﻘﻂ‪،‬‬ ‫‪-‬‬

‫ﻣﺜﻞﺃﺳﻤﺎء ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ‪ .‬ﻓﻲ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﻷﻗﻞ ﺃﻫﻤﻴﺔ ﻣﻦ ﺍﻟﻨﺎﺣﻴﺔ ﺍﻷﻣﻨﻴﺔ‪ ،‬ﻗﺪ ﻳﻜﻮﻥ ﻣﻦ‬
‫ﺍﻟﻤﻨﺎﺳﺐﺍﻟﺴﻤﺎﺡ ﻟﻠﻤﺴﺘﺨﺪﻣﻴﻦ ﺑﺎﺧﺘﻴﺎﺭ ﺧﻴﺎﺭ ﺗﺬﻛﺮ ﻛﻠﻤﺎﺕ ﺍﻟﻤﺮﻭﺭ‪ .‬ﻓﻲ ﻫﺬﻩ ﺍﻟﺤﺎﻟﺔ‪ ،‬ﻻ‬
‫ﻳﻨﺒﻐﻲﺗﺨﺰﻳﻦ ﺑﻴﺎﻧﺎﺕ ﺍﻋﺘﻤﺎﺩ ﻧﺼﻴﺔ ﻭﺍﺿﺤﺔ ﻋﻠﻰ ﺟﻬﺎﺯ ﺍﻟﻌﻤﻴﻞ )ﻳﺠﺐ ﺗﺨﺰﻳﻦ ﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ‬
‫ﻣﺸﻔﺮﺓﺑﺸﻜﻞ ﻋﻜﺴﻲ ﺑﺎﺳﺘﺨﺪﺍﻡ ﻣﻔﺘﺎﺡ ﻣﻌﺮﻭﻑ ﻓﻘﻂ ﻟﻠﺨﺎﺩﻡ(‪ .‬ﻛﻤﺎ ﻳﻨﺒﻐﻲ ﺗﺤﺬﻳﺮ‬
‫ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦﻣﻦ ﻣﺨﺎﻃﺮ ﺃﻱ ﻣﻬﺎﺟﻢ ﻟﺪﻳﻪ ﻭﺻﻮﻝ ﻓﻌﻠﻲ ﺇﻟﻰ ﺃﺟﻬﺰﺓ ﺍﻟﻜﻤﺒﻴﻮﺗﺮ ﺍﻟﺨﺎﺻﺔ ﺑﻬﻢ ﺃﻭ‬
‫ﻣﻦﻳﺨﺘﺮﻗﻬﺎ ﻋﻦ ﺑﻌُﺪ‪ .‬ﻳﺠﺐ ﺇﻳﻼء ﺍﻫﺘﻤﺎﻡ ﺧﺎﺹ ﻟﻠﻘﻀﺎء ﻋﻠﻰ ﺛﻐﺮﺍﺕ ﺑﺮﻣﺠﺔ ﺍﻟﻤﻮﺍﻗﻊ‬
‫ﺍﻟﻤﺘﻘﺎﻃﻌﺔﺩﺍﺧﻞ ﺍﻟﺘﻄﺒﻴﻖ‪ ،‬ﻭﺍﻟﺘﻲ ﻗﺪ ﺗﺴُﺘﺨﺪﻡ ﻟﺴﺮﻗﺔ ﺑﻴﺎﻧﺎﺕ ﺍﻻﻋﺘﻤﺎﺩ ﺍﻟﻤﺨﺰﻧﺔ )ﺍﻧﻈﺮ‬
‫ﺍﻟﻔﺼﻞ‪.(12‬‬

‫ﻳﺠﺐﺗﻨﻔﻴﺬ ﻣﻴﺰﺓ ﺗﻐﻴﻴﺮ ﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ )ﺭﺍﺟﻊ ﻗﺴﻢ "ﻣﻨﻊ ﺇﺳﺎءﺓ ﺍﺳﺘﺨﺪﺍﻡ ﻭﻇﻴﻔﺔ ﺗﻐﻴﻴﺮ ﻛﻠﻤﺔ‬ ‫‪-‬‬

‫ﺍﻟﻤﺮﻭﺭ"(‪ ،‬ﻭﻳﺠﺐ ﺃﻥ ﻳﻄُﻠﺐ ﻣﻦ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺗﻐﻴﻴﺮ ﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ ﺍﻟﺨﺎﺻﺔ ﺑﻬﻢ ﺑﺸﻜﻞ ﺩﻭﺭﻱ‪.‬‬

‫ﻋﻨﺪﺗﻮﺯﻳﻊ ﺑﻴﺎﻧﺎﺕ ﺍﻋﺘﻤﺎﺩ ﺍﻟﺤﺴﺎﺑﺎﺕ ﺍﻟﺠﺪﻳﺪﺓ ﻋﻠﻰ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺧﺎﺭﺝ ﻧﻄﺎﻕ ﺍﻟﺘﻐﻄﻴﺔ‪،‬‬ ‫‪-‬‬

‫ﻳﺠﺐﺇﺭﺳﺎﻟﻬﺎ ﺑﺄﻣﺎﻥ ﻗﺪﺭ ﺍﻹﻣﻜﺎﻥ‪ ،‬ﻭﺃﻥ ﺗﻜﻮﻥ ﻣﺤﺪﻭﺩﺓ ﺍﻟﻤﺪﺓ‪ .‬ﻳﻄُﻠﺐ ﻣﻦ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺗﻐﻴﻴﺮﻫﺎ‬
‫ﻋﻨﺪﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﺍﻷﻭﻝ‪ ،‬ﻭﻳﻄُﻠﺐ ﻣﻨﻪ ﺣﺬﻓﻬﺎ ﺑﻌﺪ ﺃﻭﻝ ﺍﺳﺘﺨﺪﺍﻡ‪.‬‬

‫ﻋﻨﺪﺍﻻﻗﺘﻀﺎء‪ ،‬ﻓﻜﺮّ ﻓﻲ ﺍﻟﺘﻘﺎﻁ ﺑﻌﺾ ﻣﻌﻠﻮﻣﺎﺕ ﺗﺴﺠﻴﻞ ﺩﺧﻮﻝ ﺍﻟﻤﺴﺘﺨﺪﻡ )ﻣﺜﻼ‪ ً،‬ﺃﺣﺮﻑ‬ ‫‪-‬‬

‫ﻣﻔﺮﺩﺓﻣﻦ ﻛﻠﻤﺔ ﺳﻬﻠﺔ ﺍﻟﺤﻔﻆ( ﺑﺎﺳﺘﺨﺪﺍﻡ ﺍﻟﻘﻮﺍﺉﻢ ﺍﻟﻤﻨﺴﺪﻟﺔ ﺑﺪﻻ ًﻣﻦ ﺣﻘﻮﻝ ﺍﻟﻨﺼﻮﺹ‪.‬‬
‫ﺳﻴﻤﻨﻊﻫﺬﺍ ﺃﻱ ﺑﺮﺍﻣﺞ ﺗﺴﺠﻴﻞ ﻣﻔﺎﺗﻴﺢ ﻣﺜﺒﺘﺔ ﻋﻠﻰ ﺟﻬﺎﺯ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻣﻦ ﺍﻟﺘﻘﺎﻁ ﺟﻤﻴﻊ‬
‫ﺍﻟﺒﻴﺎﻧﺎﺕﺍﻟﺘﻲ ﻳﺮﺳﻠﻬﺎ‪) .‬ﻣﻊ ﺫﻟﻚ‪ ،‬ﺗﺠﺪﺭ ﺍﻹﺷﺎﺭﺓ ﺇﻟﻰ ﺃﻥ ﺑﺮﻧﺎﻣﺞ ﺗﺴﺠﻴﻞ ﻣﻔﺎﺗﻴﺢ ﺑﺴﻴﻂ ﻫﻮ‬
‫ﺇﺣﺪﻯﺍﻟﻮﺳﺎﺉﻞ ﺍﻟﺘﻲ ﻳﻤﻜﻦ ﻟﻠﻤﻬﺎﺟﻢ ﻣﻦ ﺧﻼﻟﻬﺎ ﺍﻟﺘﻘﺎﻁ ﻣﺪﺧﻼﺕ ﺍﻟﻤﺴﺘﺨﺪﻡ‪ .‬ﺇﺫﺍ ﺍﺧﺘﺮﻕ‬
‫ﺍﻟﻤﻬﺎﺟﻢﺟﻬﺎﺯ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺑﺎﻟﻔﻌﻞ‪ ،‬ﻓﻴﻤﻜﻨﻪ ﻣﺒﺪﺉﻴﺎً ﺗﺴﺠﻴﻞ ﺟﻤﻴﻊ ﺃﻧﻮﺍﻉ ﺍﻷﺣﺪﺍﺙ‪ ،‬ﺑﻤﺎ ﻓﻲ‬
‫ﺫﻟﻚﺣﺮﻛﺎﺕ ﺍﻟﻤﺎﻭﺱ‪ ،‬ﻭﺇﺭﺳﺎﻝ ﺍﻟﻨﻤﺎﺫﺝ ﻋﺒﺮ ‪ ،HTTPS‬ﻭﻟﻘﻄﺎﺕ ﺍﻟﺸﺎﺷﺔ(‪.‬‬

‫ﺍﻟﺘﺤﻘﻖﻣﻦ ﺻﺤﺔ ﺑﻴﺎﻧﺎﺕ ﺍﻻﻋﺘﻤﺎﺩ ﺑﺸﻜﻞ ﺻﺤﻴﺢ‬

‫ﻳﻨﺒﻐﻲﺍﻟﺘﺤﻘﻖ ﻣﻦ ﺻﺤﺔ ﻛﻠﻤﺎﺕ ﺍﻟﻤﺮﻭﺭ ﺑﺸﻜﻞ ﻛﺎﻣﻞ ‪ -‬ﺃﻱ ﺑﻄﺮﻳﻘﺔ ﺣﺴﺎﺳﺔ ﻟﺤﺎﻟﺔ ﺍﻷﺣﺮﻑ‪،‬‬ ‫‪-‬‬

‫ﺩﻭﻥﺗﺼﻔﻴﺔ ﺃﻭ ﺗﻌﺪﻳﻞ ﺃﻱ ﺃﺣﺮﻑ‪ ،‬ﻭﺩﻭﻥ ﻗﻄﻊ ﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ‪.‬‬

‫ﻳﺠﺐﺃﻥ ﻳﻜﻮﻥ ﺍﻟﺘﻄﺒﻴﻖ ﻓﻌﺎّﻻ ًﻓﻲ ﺍﻟﺪﻓﺎﻉ ﻋﻦ ﻧﻔﺴﻪ ﺿﺪ ﺍﻷﺣﺪﺍﺙ ﻏﻴﺮ ﺍﻟﻤﺘﻮﻗﻌﺔ ﺍﻟﺘﻲ ﺗﺤﺪﺙ‬ ‫‪-‬‬

‫ﺃﺛﻨﺎءﻣﻌﺎﻟﺠﺔ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﺑﻨﺎء ًﻋﻠﻰ ﻟﻐﺔ ﺍﻟﺘﻄﻮﻳﺮ ﺍﻟﻤﺴﺘﺨﺪﻣﺔ‪ ،‬ﻳﺠﺐ ﺃﻥ‬
‫ﻳﺴﺘﺨﺪﻡﺍﻟﺘﻄﺒﻴﻖ ﻣﻌﺎﻟﺠﺎﺕ ﺍﺳﺘﺜﻨﺎءﺍﺕ ﺷﺎﻣﻠﺔ ﻟﺠﻤﻴﻊ ﺍﺳﺘﺪﻋﺎءﺍﺕ ﻭﺍﺟﻬﺔ ﺑﺮﻣﺠﺔ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ‪.‬‬
‫ﻳﺠﺐﺃﻥ ﺗﺤﺬﻑ ﻫﺬﻩ ﺍﻟﻤﻌﺎﻟﺠﺎﺕ ﺟﻤﻴﻊ ﺍﻻﺳﺘﺜﻨﺎءﺍﺕ ﺑﺸﻜﻞ ﺻﺮﻳﺢ‪.‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺩﺱ‪-‬ﻣﻬﺎﺟﻤﺔ ﺍﻟﻤﺼﺎﺩﻗﺔ‬ ‫‪194‬‬

‫ﺑﻴﺎﻧﺎﺕﺍﻟﺠﻠﺴﺔ ﻭﺍﻟﻄﺮﻳﻘﺔ ﺍﻟﻤﺤﻠﻴﺔ ﺍﻟﻤﺴﺘﺨﺪﻣﺔ ﻟﻠﺘﺤﻜﻢ ﻓﻲ ﺣﺎﻟﺔ ﻣﻌﺎﻟﺠﺔ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ‬

‫ﻭﻳﺠﺐﺇﺑﻄﺎﻝ ﺍﻟﺠﻠﺴﺔ ﺍﻟﺤﺎﻟﻴﺔ ﺻﺮﺍﺣﺔ‪ ً،‬ﻣﻤﺎ ﻳﺘﺴﺒﺐ ﻓﻲ ﺗﺴﺠﻴﻞ ﺧﺮﻭﺝ ﻗﺴﺮﻱ ﺑﻮﺍﺳﻄﺔ‬
‫ﺍﻟﺨﺎﺩﻡﺣﺘﻰ ﺇﺫﺍ ﺗﻢ ﺗﺠﺎﻭﺯ ﺍﻟﻤﺼﺎﺩﻗﺔ ﺑﻄﺮﻳﻘﺔ ﺃﻭ ﺑﺄﺧﺮﻯ‪.‬‬

‫ﻳﺠﺐﻣﺮﺍﺟﻌﺔ ﺟﻤﻴﻊ ﺭﻣﻮﺯ ﻣﻨﻄﻖ ﺍﻟﻤﺼﺎﺩﻗﺔ ﻋﻦ ﻛﺜﺐ‪ ،‬ﺳﻮﺍء ﻛﺮﻣﺰ ﺯﺍﺉﻒ ﺃﻭ ﻛﺮﻣﺰ ﻣﺼﺪﺭ‬ ‫‪-‬‬

‫ﻟﻠﺘﻄﺒﻴﻖﺍﻟﻔﻌﻠﻲ‪ ،‬ﻟﺘﺤﺪﻳﺪ ﺍﻷﺧﻄﺎء ﺍﻟﻤﻨﻄﻘﻴﺔ ﻣﺜﻞ ﺷﺮﻭﻁ ﺍﻟﻔﺸﻞ ﺍﻟﻤﻔﺘﻮﺡ‪.‬‬

‫ﻓﻲﺣﺎﻝ ﺗﻄﺒﻴﻖ ﻭﻇﻴﻔﺔ ﺗﺪﻋﻢ ﺍﻧﺘﺤﺎﻝ ﺷﺨﺼﻴﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ‪ ،‬ﻳﺠﺐ ﻣﺮﺍﻗﺒﺘﻬﺎ ﺑﺪﻗﺔ ﻟﻀﻤﺎﻥ‬ ‫‪-‬‬

‫ﻋﺪﻡﺇﺳﺎءﺓ ﺍﺳﺘﺨﺪﺍﻣﻬﺎ ﻟﻠﺤﺼﻮﻝ ﻋﻠﻰ ﻭﺻﻮﻝ ﻏﻴﺮ ﻣﺼﺮﺡ ﺑﻪ‪ .‬ﻭﻧﻈﺮﺍً ﻷﻫﻤﻴﺔ ﻫﺬﻩ ﺍﻟﻮﻇﻴﻔﺔ‪،‬‬
‫ﻏﺎﻟﺒﺎًﻣﺎ ﻳﻨُﺼﺢ ﺑﺤﺬﻓﻬﺎ ﻣﻦ ﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﻌﺎﻡ ﻭﺗﻄﺒﻴﻘﻬﺎ ﻓﻘﻂ ﻋﻠﻰ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺍﻹﺩﺍﺭﻳﻴﻦ‬
‫ﺍﻟﺪﺍﺧﻠﻴﻴﻦ‪،‬ﺣﻴﺚ ﻳﺠﺐ ﻣﺮﺍﻗﺒﺔ ﺍﺳﺘﺨﺪﺍﻣﻬﻢ ﻻﻧﺘﺤﺎﻝ ﺍﻟﺸﺨﺼﻴﺔ ﻭﻣﺮﺍﺟﻌﺘﻪ ﺑﺪﻗﺔ‪.‬‬

‫ﻳﺠﺐﺍﻟﺘﺤﻜﻢ ﺑﺸﻜﻞ ﺻﺎﺭﻡ ﻓﻲ ﻋﻤﻠﻴﺎﺕ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﻣﺘﻌﺪﺩﺓ ﺍﻟﻤﺮﺍﺣﻞ ﻟﻤﻨﻊ ﺍﻟﻤﻬﺎﺟﻢ‬ ‫‪-‬‬

‫ﻣﻦﺍﻟﺘﺪﺧﻞ ﻓﻲ ﺍﻟﺘﺤﻮﻻﺕ ﻭﺍﻟﻌﻼﻗﺎﺕ ﺑﻴﻦ ﺍﻟﻤﺮﺍﺣﻞ‪:‬‬

‫ﻳﺠﺐﺣﻔﻆ ﻛﺎﻓﺔ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺍﻟﻤﺘﻌﻠﻘﺔ ﺑﺎﻟﺘﻘﺪﻡ ﺧﻼﻝ ﺍﻟﻤﺮﺍﺣﻞ ﻭﻧﺘﺎﺉﺞ ﻣﻬﺎﻡ ﺍﻟﺘﺤﻘﻖ‬ ‫‪-‬‬

‫ﺍﻟﺴﺎﺑﻘﺔﻓﻲ ﻛﺎﺉﻦ ﺟﻠﺴﺔ ﺟﺎﻧﺐ ﺍﻟﺨﺎﺩﻡ ﻭﻳﺠﺐ ﻋﺪﻡ ﺇﺭﺳﺎﻟﻬﺎ ﺇﻟﻰ ﺍﻟﻌﻤﻴﻞ ﺃﻭ ﻗﺮﺍءﺗﻬﺎ ﻣﻨﻪ‬
‫ﻣﻄﻠﻘﺎً‪.‬‬
‫ﻻﻳﺠﻮﺯ ﻟﻠﻤﺴﺘﺨﺪﻡ ﺇﺭﺳﺎﻝ ﺃﻱ ﻣﻌﻠﻮﻣﺎﺕ ﺃﻛﺜﺮ ﻣﻦ ﻣﺮﺓ‪ ،‬ﻭﻳﺠﺐ ﺃﻻ ﺗﺘُﺎﺡ ﻟﻪ ﺃﻱ ﻭﺳﻴﻠﺔ‬ ‫‪-‬‬

‫ﻟﺘﻌﺪﻳﻞﺍﻟﺒﻴﺎﻧﺎﺕ ﺍﻟﺘﻲ ﺟﻤُﻌﺖ ﺃﻭ ﺗﺤﻘﻘﺖ ﻣﻦ ﺻﺤﺘﻬﺎ‪ .‬ﻓﻲ ﺣﺎﻝ ﺍﺳﺘﺨﺪﺍﻡ ﺑﻴﺎﻧﺎﺕ‪ ،‬ﻛﺎﺳﻢ‬
‫ﺍﻟﻤﺴﺘﺨﺪﻡﻣﺜﻼ‪ ً،‬ﻓﻲ ﻣﺮﺍﺣﻞ ﻣﺘﻌﺪﺩﺓ‪ ،‬ﻳﺠﺐ ﺗﺨﺰﻳﻨﻬﺎ ﻓﻲ ﻣﺘﻐﻴﺮ ﺟﻠﺴﺔ ﻋﻨﺪ ﺟﻤﻌﻬﺎ ﻷﻭﻝ‬
‫ﻣﺮﺓ‪،‬ﻭﺍﻟﺮﺟﻮﻉ ﺇﻟﻴﻬﺎ ﻻﺣﻘﺎً‪.‬‬

‫ﺃﻭﻝﻣﺎ ﻳﺠﺐ ﻓﻌﻠﻪ ﻓﻲ ﻛﻞ ﻣﺮﺣﻠﺔ ﻫﻮ ﺍﻟﺘﺄﻛﺪ ﻣﻦ ﺇﺗﻤﺎﻡ ﺟﻤﻴﻊ ﺍﻟﻤﺮﺍﺣﻞ ﺍﻟﺴﺎﺑﻘﺔ ﺑﺸﻜﻞ‬ ‫‪-‬‬

‫ﺻﺤﻴﺢ‪.‬ﺇﺫﺍ ﻟﻢ ﻳﻜﻦ ﺍﻷﻣﺮ ﻛﺬﻟﻚ‪ ،‬ﻓﻴﺠﺐ ﻭﺿﻊ ﻋﻼﻣﺔ "ﺧﺎﻃﺉﺔ" ﻋﻠﻰ ﻣﺤﺎﻭﻟﺔ ﺍﻟﻤﺼﺎﺩﻗﺔ‬
‫ﻓﻮﺭﺍً‪.‬‬
‫ﻟﻤﻨﻊﺗﺴﺮﻳﺐ ﺍﻟﻤﻌﻠﻮﻣﺎﺕ ﺣﻮﻝ ﻣﺮﺣﻠﺔ ﻓﺸﻞ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ )ﻣﻤﺎ ﻳﻤُﻜﻦّ ﺍﻟﻤﻬﺎﺟﻢ ﻣﻦ‬ ‫‪-‬‬

‫ﺍﺳﺘﻬﺪﺍﻑﻛﻞ ﻣﺮﺣﻠﺔ ﻋﻠﻰ ﺣﺪﺓ(‪ ،‬ﻳﻨﺒﻐﻲ ﻋﻠﻰ ﺍﻟﺘﻄﺒﻴﻖ ﺇﻛﻤﺎﻝ ﺟﻤﻴﻊ ﻣﺮﺍﺣﻞ ﺗﺴﺠﻴﻞ‬
‫ﺍﻟﺪﺧﻮﻝ‪،‬ﺣﺘﻰ ﻟﻮ ﻟﻢ ﻳﻜُﻤﻞ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺍﻟﻤﺮﺍﺣﻞ ﺍﻟﺴﺎﺑﻘﺔ ﺑﺸﻜﻞ ﺻﺤﻴﺢ‪ ،‬ﻭﺣﺘﻰ ﻟﻮ ﻛﺎﻥ‬
‫ﺍﺳﻢﺍﻟﻤﺴﺘﺨﺪﻡ ﺍﻷﺻﻠﻲ ﻏﻴﺮ ﺻﺎﻟﺢ‪ .‬ﺑﻌﺪ ﺇﻛﻤﺎﻝ ﺟﻤﻴﻊ ﺍﻟﻤﺮﺍﺣﻞ‪ ،‬ﻳﻨﺒﻐﻲ ﻋﻠﻰ ﺍﻟﺘﻄﺒﻴﻖ‬
‫ﻋﺮﺽﺭﺳﺎﻟﺔ ﻋﺎﻣﺔ ﺗﻔُﻴﺪ ﺑـ "ﻓﺸﻞ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ" ﻓﻲ ﻧﻬﺎﻳﺔ ﺍﻟﻤﺮﺣﻠﺔ ﺍﻷﺧﻴﺮﺓ‪ ،‬ﺩﻭﻥ‬
‫ﺗﻘﺪﻳﻢﺃﻱ ﻣﻌﻠﻮﻣﺎﺕ ﺣﻮﻝ ﻣﻜﺎﻥ ﺣﺪﻭﺙ ﺍﻟﻔﺸﻞ‪.‬‬

‫ﻋﻨﺪﻣﺎﺗﺘﻀﻤﻦ ﻋﻤﻠﻴﺔ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﺳﺆﺍﻻ ًﻣﺘﻐﻴﺮﺍً ﻋﺸﻮﺍﺉﻴﺎً‪ ،‬ﺗﺄﻛﺪ ﻣﻦ ﻋﺪﻡ ﺗﻤﻜﻦ‬ ‫‪-‬‬

‫ﺍﻟﻤﻬﺎﺟﻢﻣﻦ ﺍﺧﺘﻴﺎﺭ ﺳﺆﺍﻟﻪ ﺍﻟﺨﺎﺹ ﺑﻔﻌﺎﻟﻴﺔ‪:‬‬

‫ﺍﺳﺘﺨﺪﻡﺩﺍﺉﻤﺎً ﻋﻤﻠﻴﺔ ﻣﺘﻌﺪﺩﺓ ﺍﻟﻤﺮﺍﺣﻞ ﺣﻴﺚ ﻳﻘﻮﻡ ﺍﻟﻤﺴﺘﺨﺪﻣﻮﻥ ﺑﺘﺤﺪﻳﺪ ﻫﻮﻳﺘﻬﻢ ﻓﻲ‬ ‫‪-‬‬

‫ﺍﻟﻤﺮﺣﻠﺔﺍﻷﻭﻟﻴﺔ ﻭﻳﺘﻢ ﺗﻘﺪﻳﻢ ﺍﻟﺴﺆﺍﻝ ﺍﻟﻤﺘﻐﻴﺮ ﻋﺸﻮﺍﺉﻴﺎً ﻟﻬﻢ ﻓﻲ ﻣﺮﺣﻠﺔ ﻻﺣﻘﺔ‪.‬‬

‫‪195‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺩﺱ‪-‬ﻣﻬﺎﺟﻤﺔ ﺍﻟﻤﺼﺎﺩﻗﺔ‬

‫ﻋﻨﺪﻣﺎﻳﺘﻢ ﺗﻘﺪﻳﻢ ﺳﺆﺍﻝ ﻣﺘﻐﻴﺮ ﻣﻌﻴﻦ ﻟﻤﺴﺘﺨﺪﻡ ﻣﻌﻴﻦ‪ ،‬ﻗﻢ ﺑﺘﺨﺰﻳﻦ ﻫﺬﺍ ﺍﻟﺴﺆﺍﻝ ﺩﺍﺧﻞ‬ ‫‪-‬‬

‫ﻣﻠﻔﻪﺍﻟﺸﺨﺼﻲ ﺍﻟﺪﺍﺉﻢ‪ ،‬ﻭﺗﺄﻛﺪ ﻣﻦ ﺗﻘﺪﻳﻢ ﻧﻔﺲ ﺍﻟﺴﺆﺍﻝ ﻟﻨﻔﺲ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻓﻲ ﻛﻞ‬

‫ﻣﺤﺎﻭﻟﺔﺗﺴﺠﻴﻞ ﺩﺧﻮﻝ ﺣﺘﻰ ﻳﺠﻴﺐ ﻋﻠﻴﻪ ﺑﻨﺠﺎﺡ‪.‬‬

‫ﻋﻨﺪﺗﻘﺪﻳﻢ ﺗﺤﺪﻱ ﻣﺘﻐﻴﺮ ﻋﺸﻮﺍﺉﻴﺎً ﻟﻠﻤﺴﺘﺨﺪﻡ‪ ،‬ﻗﻢ ﺑﺘﺨﺰﻳﻦ ﺍﻟﺴﺆﺍﻝ ﺍﻟﺬﻱ ﺗﻢ ﻃﺮﺣﻪ ﻓﻲ‬ ‫‪-‬‬

‫ﻣﺘﻐﻴﺮﺟﻠﺴﺔ ﻋﻠﻰ ﺟﺎﻧﺐ ﺍﻟﺨﺎﺩﻡ‪ ،‬ﺑﺪﻻ ًﻣﻦ ﺣﻘﻞ ﻣﺨﻔﻲ ﻓﻲ ﻧﻤﻮﺫﺝ ‪ ،HTML‬ﺛﻢ ﻗﻢ‬
‫ﺑﺎﻟﺘﺤﻘﻖﻣﻦ ﺻﺤﺔ ﺍﻹﺟﺎﺑﺔ ﺍﻟﻼﺣﻘﺔ ﻣﻘﺎﺑﻞ ﻫﺬﺍ ﺍﻟﺴﺆﺍﻝ ﺍﻟﻤﺤﻔﻮﻅ‪.‬‬

‫ﻣﻠﺤﻮﻇﺔﺗﻜﻤﻦ ﺩﻗﺔ ﺍﺑﺘﻜﺎﺭ ﺁﻟﻴﺔ ﻣﺼﺎﺩﻗﺔ ﺁﻣﻨﺔ ﻓﻲ ﻫﺬﺍ ﺍﻟﺠﺎﻧﺐ‪ .‬ﻓﺈﺫﺍ ﻟﻢ ﻳﺮُﺍﻉ َﺍﻟﺤﺬﺭ ﻋﻨﺪ ﻃﺮﺡ‬
‫ﺃﺳﺉﻠﺔﻣﺘﻐﻴﺮﺓ ﻋﺸﻮﺍﺉﻴﺎً‪ ،‬ﻓﻘﺪ ﻳﺘُﻴﺢ ﺫﻟﻚ ﻓﺮﺻﺎً ﺟﺪﻳﺪﺓ ﻟﺘﻌﺪﺍﺩ ﺃﺳﻤﺎء ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ‬
‫ﺍﻟﻤﺜﺎﻝ‪،‬ﻟﻤﻨﻊ ﺍﻟﻤﻬﺎﺟﻢ ﻣﻦ ﺍﺧﺘﻴﺎﺭ ﺳﺆﺍﻟﻪ ﺍﻟﺨﺎﺹ‪ ،‬ﻗﺪ ﻳﺨُﺰﻥّ ﺗﻄﺒﻴﻖ ٌﺁﺧﺮ ﺳﺆﺍﻝ ﻃﺮُﺡ ﻋﻠﻴﻪ ﺩﺍﺧﻞ ﻣﻠﻒ‬
‫ﺗﻌﺮﻳﻒﻛﻞ ﻣﺴﺘﺨﺪﻡ‪ ،‬ﻭﻳﺴﺘﻤﺮ ﻓﻲ ﻋﺮﺿﻪ ﺣﺘﻰ ﻳﺠُﻴﺐ ﻋﻠﻴﻪ ﺑﺸﻜﻞ ﺻﺤﻴﺢ‪ .‬ﺳﻴﻮُﺍﺟﻪَ ﺍﻟﻤﻬﺎﺟﻢ ﺍﻟﺬﻱ‬
‫ﻳﺠُﺮﻱﻋﺪﺓ ﻋﻤﻠﻴﺎﺕ ﺗﺴﺠﻴﻞ ﺩﺧﻮﻝ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺍﺳﻢ ﻣﺴﺘﺨﺪﻡ ﻣﻌﻴﻦ ﺑﻨﻔﺲ ﺍﻟﺴﺆﺍﻝ‪ .‬ﻭﻣﻊ ﺫﻟﻚ‪ ،‬ﺇﺫﺍ‬
‫ﻧﻔﺬّﺍﻟﻤﻬﺎﺟﻢ ﺍﻟﻌﻤﻠﻴﺔ ﻧﻔﺴﻬﺎ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺍﺳﻢ ﻣﺴﺘﺨﺪﻡ ﻏﻴﺮ ﺻﺎﻟﺢ‪ ،‬ﻓﻘﺪ ﻳﺘﺼﺮﻑ ﺍﻟﺘﻄﺒﻴﻖ ﺑﺸﻜﻞ‬
‫ﻣﺨﺘﻠﻒ‪:‬ﻧﻈﺮﺍً ﻟﻌﺪﻡ ﻭﺟﻮﺩ ﻣﻠﻒ ﺗﻌﺮﻳﻒ ﻣﺮﺗﺒﻂ ﺑﺎﺳﻢ ﻣﺴﺘﺨﺪﻡ ﻏﻴﺮ ﺻﺎﻟﺢ‪ ،‬ﻓﻠﻦ ﻳﺨُﺰﻥّ ﺃﻱ ﺳﺆﺍﻝ‪،‬‬
‫ﻭﺑﺎﻟﺘﺎﻟﻲﺳﻴﻌُﺮﺽ ﺳﺆﺍﻝ ﻣﺘﻐﻴﺮ‪ .‬ﻳﻤﻜﻦ ﻟﻠﻤﻬﺎﺟﻢ ﺍﺳﺘﻐﻼﻝ ﻫﺬﺍ ﺍﻻﺧﺘﻼﻑ ﻓﻲ ﺍﻟﺴﻠﻮﻙ‪ ،‬ﺍﻟﺬﻱ ﻳﺘﺠﻠﻰ‬
‫ﻋﺒﺮﻋﺪﺓ ﻣﺤﺎﻭﻻﺕ ﺗﺴﺠﻴﻞ ﺩﺧﻮﻝ‪ ،‬ﻻﺳﺘﻨﺘﺎﺝ ﺻﺤﺔ ﺍﺳﻢ ﻣﺴﺘﺨﺪﻡ ﻣﺤُﺪﺩ‪ .‬ﻓﻲ ﻫﺠﻮﻡ ﻣﺒُﺮﻣﺞ‪،‬‬
‫ﺳﻴﺘﻤﻜﻦﻣﻦ ﺟﻤﻊ ﺍﻟﻌﺪﻳﺪ ﻣﻦ ﺃﺳﻤﺎء ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺑﺴﺮﻋﺔ‪.‬‬

‫ﺇﺫﺍﺃﺭﺍﺩ ﺗﻄﺒﻴﻖ ٌﻣﺎ ﺣﻤﺎﻳﺔ ﻧﻔﺴﻪ ﻣﻦ ﻫﺬﺍ ﺍﻻﺣﺘﻤﺎﻝ‪ ،‬ﻓﻌﻠﻴﻪ ﺑﺬﻝ ﺟﻬﻮﺩ ٍﻣﻀﻨﻴﺔ‪ .‬ﻋﻨﺪ ﺑﺪء ﻣﺤﺎﻭﻟﺔ‬
‫ﺗﺴﺠﻴﻞﺩﺧﻮﻝ ﺑﺎﺳﻢ ﻣﺴﺘﺨﺪﻡ ﻏﻴﺮ ﺻﺎﻟﺢ‪ ،‬ﻳﺠﺐ ﻋﻠﻰ ﺍﻟﺘﻄﺒﻴﻖ ﺗﺴﺠﻴﻞ ﺍﻟﺴﺆﺍﻝ ﺍﻟﻌﺸﻮﺍﺉﻲ ﺍﻟﺬﻱ‬
‫ﻃﺮﺣﻪﻟﻬﺬﺍ ﺍﻻﺳﻢ ﻏﻴﺮ ﺍﻟﺼﺎﻟﺢ‪ ،‬ﻭﺍﻟﺘﺄﻛﺪ ﻣﻦ ﺃﻥ ﻣﺤﺎﻭﻻﺕ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﺍﻟﻼﺣﻘﺔ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺍﺳﻢ‬
‫ﺍﻟﻤﺴﺘﺨﺪﻡﻧﻔﺴﻪ ﺗﻘُﺎﺑﻞ ﺑﻨﻔﺲ ﺍﻟﺴﺆﺍﻝ‪ .‬ﺑﻞ ﻭﺃﻛﺜﺮ ﻣﻦ ﺫﻟﻚ‪ ،‬ﻳﻤﻜﻦ ﻟﻠﺘﻄﺒﻴﻖ ﺍﻟﺘﺒﺪﻳﻞ ﺇﻟﻰ ﺳﺆﺍﻝ‬
‫ﻣﺨﺘﻠﻒﺩﻭﺭﻳﺎً ﻟﻤﺤﺎﻛﺎﺓ ﺗﺴﺠﻴﻞ ﺩﺧﻮﻝ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺍﻟﻮﻫﻤﻲ ﻛﺎﻟﻤﻌﺘﺎﺩ‪ ،‬ﻣﻤﺎ ﻳﺆﺩﻱ ﺇﻟﻰ ﺗﻐﻴﻴﺮ ﺍﻟﺴﺆﺍﻝ‬
‫ﺍﻟﺘﺎﻟﻲ!ﻭﻣﻊ ﺫﻟﻚ‪ ،‬ﻓﻲ ﻣﺮﺣﻠﺔ ٍﻣﺎ‪ ،‬ﻳﺠﺐ ﻋﻠﻰ ﻣﺼﻤﻢ ﺍﻟﺘﻄﺒﻴﻖ ﺃﻥ ﻳﻀﻊ ﺣﺪﺍً ﺃﺩﻧﻰ ﻭﻳﻘﺮ ّﺑﺎﺳﺘﺤﺎﻟﺔ‬
‫ﺗﺤﻘﻴﻖﺍﻧﺘﺼﺎﺭ ٍﻛﺎﻣﻞ ﻋﻠﻰ ﻫﺬﺍ ﺍﻟﻤﻬﺎﺟﻢ ﺍﻟﻤﺼُﻤﻢّ‪.‬‬

‫ﻣﻨﻊﺗﺴﺮﺏ ﺍﻟﻤﻌﻠﻮﻣﺎﺕ‬

‫ﻳﺠﺐﺃﻻ ﺗﻜﺸﻒ ﺁﻟﻴﺎﺕ ﺍﻟﻤﺼﺎﺩﻗﺔ ﺍﻟﻤﺨﺘﻠﻔﺔ ﺍﻟﺘﻲ ﻳﺴﺘﺨﺪﻣﻬﺎ ﺍﻟﺘﻄﺒﻴﻖ ﻋﻦ ﺃﻱ ﻣﻌﻠﻮﻣﺎﺕ‬ ‫‪-‬‬

‫ﺗﺘﻌﻠﻖﺑﻤﻌﻠﻤﺎﺕ ﺍﻟﻤﺼﺎﺩﻗﺔ‪ ،‬ﺳﻮﺍء ًﻣﻦ ﺧﻼﻝ ﺭﺳﺎﺉﻞ ﺻﺮﻳﺤﺔ ﺃﻭ ﺍﺳﺘﻨﺘﺎﺟﺎﺕ ﻣﻦ ﺟﻮﺍﻧﺐ‬

‫ﺃﺧﺮﻯﻣﻦ ﺳﻠﻮﻙ ﺍﻟﺘﻄﺒﻴﻖ‪ .‬ﻳﺠﺐ ﺃﻻ ﻳﺘﻤﻜﻦ ﺍﻟﻤﻬﺎﺟﻢ ﻣﻦ ﺗﺤﺪﻳﺪ ﺃﻱ ﻋﻨﺼﺮ ﻣﻦ ﺍﻟﻌﻨﺎﺻﺮ‬
‫ﺍﻟﻤﺨﺘﻠﻔﺔﺍﻟﻤﺮُﺳﻠﺔ ﺗﺴﺒﺐ ﻓﻲ ﺍﻟﻤﺸﻜﻠﺔ‪.‬‬

‫ﻳﺠﺐﺃﻥ ﻳﻜﻮﻥ ﻣﻜُﻮﻥِّ ﺑﺮﻣﺠﻲ ﻭﺍﺣﺪ ﻣﺴﺆﻭﻻ ًﻋﻦ ﺍﻻﺳﺘﺠﺎﺑﺔ ﻟﺠﻤﻴﻊ ﻣﺤﺎﻭﻻﺕ ﺗﺴﺠﻴﻞ‬ ‫‪-‬‬

‫ﺍﻟﺪﺧﻮﻝﺍﻟﻔﺎﺷﻠﺔ ﺑﺮﺳﺎﻟﺔ ﻋﺎﻣﺔ‪ .‬ﻫﺬﺍ ﻳﺠُﻨﺐِّ ﺛﻐﺮﺓ ﺃﻣﻨﻴﺔ ﺧﻔﻴﺔ‪.‬‬

 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺩﺱ‪-‬ﻣﻬﺎﺟﻤﺔ ﺍﻟﻤﺼﺎﺩﻗﺔ‬ ‫‪196‬‬

‫ﻳﻤﻜﻦﺃﻥ ﻳﺤﺪﺙ ﺫﻟﻚ ﻋﻨﺪﻣﺎ ﻳﺘﻤﻜﻦ ﺍﻟﻤﻬﺎﺟﻢ ﻣﻦ ﺍﻛﺘﺸﺎﻑ ﺭﺳﺎﻟﺔ ﻏﻴﺮ ﻣﻔﻴﺪﺓ ﺗﻢ ﺇﺭﺟﺎﻋﻬﺎ‬
‫ﻣﻦﻣﺴﺎﺭﺍﺕ ﻛﻮﺩ ﻣﺨﺘﻠﻔﺔ ﺑﺴﺒﺐ ﺍﻻﺧﺘﻼﻓﺎﺕ ﺍﻟﻤﻄﺒﻌﻴﺔ ﻓﻲ ﺍﻟﺮﺳﺎﻟﺔ‪ ،‬ﺃﻭ ﺭﻣﻮﺯ ﺣﺎﻟﺔ ‪HTTP‬‬
‫ﺍﻟﻤﺨﺘﻠﻔﺔ‪،‬ﺃﻭ ﻣﻌﻠﻮﻣﺎﺕ ﺃﺧﺮﻯ ﻣﺨﻔﻴﺔ ﻓﻲ ‪ ،HTML‬ﻭﻣﺎ ﺷﺎﺑﻪ ﺫﻟﻚ‪.‬‬

‫ﺇﺫﺍﻓﺮﺽ ﺍﻟﺘﻄﺒﻴﻖ ﻧﻮﻋﺎً ﻣﻦ ﻗﻔﻞ ﺍﻟﺤﺴﺎﺏ ﻟﻤﻨﻊ ﻫﺠﻤﺎﺕ ﺍﻟﻘﻮﺓ ﺍﻟﻐﺎﺷﻤﺔ )ﻛﻤﺎ ﻫﻮ ﻣﻮﺿﺢ‬ ‫‪-‬‬

‫ﻓﻲﺍﻟﻘﺴﻢ ﺍﻟﺘﺎﻟﻲ(‪ ،‬ﻓﺎﺣﺮﺹ ﻋﻠﻰ ﻋﺪﻡ ﺍﻟﺴﻤﺎﺡ ﻟﻬﺬﺍ ﺍﻷﻣﺮ ﺑﺘﺴﺮﻳﺐ ﺃﻱ ﻣﻌﻠﻮﻣﺎﺕ‪ .‬ﻋﻠﻰ‬
‫ﺳﺒﻴﻞﺍﻟﻤﺜﺎﻝ‪ ،‬ﺇﺫﺍ ﻛﺸﻒ ﺗﻄﺒﻴﻖ ﻋﻦ ﺗﻌﻠﻴﻖ ﺣﺴﺎﺏ ﻣﻌﻴﻦ ﻟﻤﺪﺓﺇﻛﺲﺩﻗﺎﺉﻖ ﺑﺴﺒﺐﻱﻓﻲ‬
‫ﺣﺎﻻﺕﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﺍﻟﻔﺎﺷﻠﺔ‪ ،‬ﻳﻤُﻜﻦ ﺍﺳﺘﺨﺪﺍﻡ ﻫﺬﺍ ﺍﻟﺴﻠﻮﻙ ﺑﺴﻬﻮﻟﺔ ﻟﺤﺼﺮ ﺃﺳﻤﺎء‬
‫ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦﺍﻟﺼﺤﻴﺤﺔ‪ .‬ﺑﺎﻹﺿﺎﻓﺔ ﺇﻟﻰ ﺫﻟﻚ‪ ،‬ﻳﻤُﻜﻦّ ﺍﻟﻜﺸﻒ ﻋﻦ ﺍﻟﻤﻘﺎﻳﻴﺲ ﺍﻟﺪﻗﻴﻘﺔ‬
‫ﻟﺴﻴﺎﺳﺔﺍﻟﻘﻔﻞ ﺍﻟﻤﻬﺎﺟﻢ ﻣﻦ ﺗﺤﺴﻴﻦ ﺃﻱ ﻣﺤﺎﻭﻟﺔ ﻟﺘﺨﻤﻴﻦ ﻛﻠﻤﺎﺕ ﺍﻟﻤﺮﻭﺭ ﻋﻠﻰ ﺍﻟﺮﻏﻢ ﻣﻦ‬
‫ﺍﻟﺴﻴﺎﺳﺔ‪.‬ﻟﺘﺠﻨﺐ ﺣﺼﺮ ﺃﺳﻤﺎء ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ‪ ،‬ﻳﺠﺐ ﺃﻥ ﻳﺴﺘﺠﻴﺐ ﺍﻟﺘﻄﺒﻴﻖ ﻟـﺃﻱﺳﻠﺴﻠﺔ‬
‫ﻣﻦﻣﺤﺎﻭﻻﺕ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﺍﻟﻔﺎﺷﻠﺔ ﻣﻦ ﺍﻟﻤﺘﺼﻔﺢ ﻧﻔﺴﻪ‪ ،‬ﻣﻊ ﺭﺳﺎﻟﺔ ﻋﺎﻣﺔ ﺗﻨُﺒﻪ ﺑﺘﻌﻠﻴﻖ‬
‫ﺍﻟﺤﺴﺎﺑﺎﺕﻓﻲ ﺣﺎﻝ ﺗﻜﺮﺍﺭ ﺍﻟﻤﺤﺎﻭﻻﺕ ﺍﻟﻔﺎﺷﻠﺔ‪ ،‬ﻭﺗﺤﺚ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻋﻠﻰ ﺍﻟﻤﺤﺎﻭﻟﺔ ﻣﺮﺓ ﺃﺧﺮﻯ‬
‫ﻻﺣﻘﺎً‪.‬ﻳﻤﻜﻦ ﺗﺤﻘﻴﻖ ﺫﻟﻚ ﺑﺎﺳﺘﺨﺪﺍﻡ ﻣﻠﻒ ﺗﻌﺮﻳﻒ ﺍﺭﺗﺒﺎﻁ ﺃﻭ ﺣﻘﻞ ﻣﺨﻔﻲ ﻟﺘﺘﺒﻊ ﺣﺎﻻﺕ‬
‫ﺍﻟﻔﺸﻞﺍﻟﻤﺘﻜﺮﺭﺓ ﺍﻟﻨﺎﺗﺠﺔ ﻋﻦ ﺍﻟﻤﺘﺼﻔﺢ ﻧﻔﺴﻪ‪) .‬ﺑﺎﻟﻄﺒﻊ‪ ،‬ﻻ ﻳﻨﺒﻐﻲ ﺍﺳﺘﺨﺪﺍﻡ ﻫﺬﻩ ﺍﻵﻟﻴﺔ‬
‫ﻟﻔﺮﺽﺃﻱ ﺿﻮﺍﺑﻂ ﺃﻣﻨﻴﺔ ﻓﻌﻠﻴﺔ‪ ،‬ﺑﻞ ﻟﺘﻘﺪﻳﻢ ﺭﺳﺎﻟﺔ ﻣﻔﻴﺪﺓ ﻟﻠﻤﺴﺘﺨﺪﻣﻴﻦ ﺍﻟﻌﺎﺩﻳﻴﻦ ﺍﻟﺬﻳﻦ‬
‫ﻳﺠﺪﻭﻥﺻﻌﻮﺑﺔ ﻓﻲ ﺗﺬﻛﺮ ﺑﻴﺎﻧﺎﺕ ﺍﻋﺘﻤﺎﺩﻫﻢ(‪.‬‬

‫ﺇﺫﺍﻛﺎﻥ ﺍﻟﺘﻄﺒﻴﻖ ﻳﺪﻋﻢ ﺍﻟﺘﺴﺠﻴﻞ ﺍﻟﺬﺍﺗﻲ‪ ،‬ﻓﻴﻤﻜﻨﻪ ﻣﻨﻊ ﺍﺳﺘﺨﺪﺍﻡ ﻫﺬﻩ ﺍﻟﻮﻇﻴﻔﺔ ﻹﺣﺼﺎء‬ ‫‪-‬‬

‫ﺃﺳﻤﺎءﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺍﻟﻤﻮﺟﻮﺩﺓ ﺑﻄﺮﻳﻘﺘﻴﻦ‪:‬‬

‫ﺑﺪﻻ ًﻣﻦ ﺍﻟﺴﻤﺎﺡ ﺑﺎﻻﺧﺘﻴﺎﺭ ﺍﻟﺬﺍﺗﻲ ﻷﺳﻤﺎء ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ‪ ،‬ﻳﻤﻜﻦ ﻟﻠﺘﻄﺒﻴﻖ ﺇﻧﺸﺎء ﺍﺳﻢ‬ ‫‪-‬‬

‫ﻣﺴﺘﺨﺪﻡﻓﺮﻳﺪ )ﻭﻏﻴﺮ ﻣﺘﻮﻗﻊ( ﻟﻜﻞ ﻣﺴﺘﺨﺪﻡ ﺟﺪﻳﺪ‪ ،‬ﻭﺑﺎﻟﺘﺎﻟﻲ ﺗﺠﻨﺐ ﺍﻟﺤﺎﺟﺔ ﺇﻟﻰ ﺍﻟﻜﺸﻒ‬
‫ﻋﻦﻭﺟﻮﺩ ﺍﺳﻢ ﻣﺴﺘﺨﺪﻡ ﻣﺤﺪﺩ ﺑﺎﻟﻔﻌﻞ‪.‬‬
‫ﻳﻤﻜﻦﻟﻠﺘﻄﺒﻴﻖ ﺍﺳﺘﺨﺪﺍﻡ ﻋﻨﺎﻭﻳﻦ ﺍﻟﺒﺮﻳﺪ ﺍﻹﻟﻜﺘﺮﻭﻧﻲ ﻛﺄﺳﻤﺎء ﻣﺴﺘﺨﺪﻣﻴﻦ‪ .‬ﻓﻲ ﺍﻟﻤﺮﺣﻠﺔ‬ ‫‪-‬‬

‫ﺍﻷﻭﻟﻰﻣﻦ ﻋﻤﻠﻴﺔ ﺍﻟﺘﺴﺠﻴﻞ‪ ،‬ﻳﻄُﻠﺐ ﻣﻦ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺇﺩﺧﺎﻝ ﻋﻨﻮﺍﻥ ﺑﺮﻳﺪﻩ ﺍﻹﻟﻜﺘﺮﻭﻧﻲ‪ ،‬ﺛﻢ‬
‫ﻳﻄُﻠﺐﻣﻨﻪ ﺑﺒﺴﺎﻃﺔ ﺍﻧﺘﻈﺎﺭ ﺭﺳﺎﻟﺔ ﺑﺮﻳﺪ ﺇﻟﻜﺘﺮﻭﻧﻲ ﻭﺍﺗﺒﺎﻉ ﺍﻟﺘﻌﻠﻴﻤﺎﺕ ﺍﻟﻮﺍﺭﺩﺓ ﻓﻴﻬﺎ‪ .‬ﺇﺫﺍ ﻛﺎﻥ‬
‫ﻋﻨﻮﺍﻥﺍﻟﺒﺮﻳﺪ ﺍﻹﻟﻜﺘﺮﻭﻧﻲ ﻣﺴُﺠﻼ ًﺑﺎﻟﻔﻌﻞ‪ ،‬ﻓﺴﻴﺘﻢ ﺇﻋﻼﻡ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺑﺬﻟﻚ ﻓﻲ ﺍﻟﺮﺳﺎﻟﺔ‪ .‬ﺃﻣﺎ‬
‫ﺇﺫﺍﻟﻢ ﻳﻜﻦ ﻣﺴُﺠﻼ ًﺑﺎﻟﻔﻌﻞ‪ ،‬ﻓﺴﻴﺘﻢ ﺗﺰﻭﻳﺪﻩ ﺑﻌﻨﻮﺍﻥ ‪ URL‬ﻓﺮﻳﺪ ﻭﺳﻬﻞ ﺍﻟﺘﺨﻤﻴﻦ ﻟﺰﻳﺎﺭﺗﻪ‬
‫ﻟﻤﻮﺍﺻﻠﺔﻋﻤﻠﻴﺔ ﺍﻟﺘﺴﺠﻴﻞ‪ .‬ﻫﺬﺍ ﻳﻤﻨﻊ ﺍﻟﻤﻬﺎﺟﻢ ﻣﻦ ﺣﺼﺮ ﺃﺳﻤﺎء ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺍﻟﺼﺤﻴﺤﺔ‬
‫)ﺇﻻ ﺇﺫﺍ ﻛﺎﻥ ﻗﺪ ﺍﺧﺘﺮﻕ ﻋﺪﺩﺍً ﻛﺒﻴﺮﺍً ﻣﻦ ﺣﺴﺎﺑﺎﺕ ﺍﻟﺒﺮﻳﺪ ﺍﻹﻟﻜﺘﺮﻭﻧﻲ(‪.‬‬

‫ﻣﻨﻊﻫﺠﻤﺎﺕ ﺍﻟﻘﻮﺓ ﺍﻟﻐﺎﺷﻤﺔ‬

‫ﻳﺠﺐﺗﻄﺒﻴﻖ ﺇﺟﺮﺍءﺍﺕ ﺻﺎﺭﻣﺔ ﻋﻠﻰ ﺟﻤﻴﻊ ﺍﻟﺘﺤﺪﻳﺎﺕ ﺍﻟﻤﺨﺘﻠﻔﺔ ﺍﻟﺘﻲ ﺗﻨُﻔﺬّﻫﺎ ﻭﻇﻴﻔﺔ‬ ‫‪-‬‬

‫ﺍﻟﻤﺼﺎﺩﻗﺔﻟﻤﻨﻊ ﺍﻟﻬﺠﻤﺎﺕ ﺍﻟﺘﻲ ﺗﺤﺎﻭﻝ ﻣﻮﺍﺟﻬﺔ ﺗﻠﻚ ﺍﻟﺘﺤﺪﻳﺎﺕ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺍﻷﺗﻤﺘﺔ‪ .‬ﻭﻳﺸﻤﻞ‬
‫ﺫﻟﻚﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﻧﻔﺴﻪ‪.‬‬
‫‪197‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺩﺱ‪-‬ﻣﻬﺎﺟﻤﺔ ﺍﻟﻤﺼﺎﺩﻗﺔ‬

‫ﺑﺎﻹﺿﺎﻓﺔﺇﻟﻰ ﻭﻇﺎﺉﻒ ﺗﻐﻴﻴﺮ ﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ‪ ،‬ﻭﺍﻟﺘﻌﺎﻓﻲ ﻣﻦ ﺣﺎﻟﺔ ﻧﺴﻴﺎﻥ ﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ‪ ،‬ﻭﻣﺎ ﺇﻟﻰ‬
‫ﺫﻟﻚ‪.‬‬
‫ﺇﻥﺍﺳﺘﺨﺪﺍﻡ ﺃﺳﻤﺎء ﻣﺴﺘﺨﺪﻣﻴﻦ ﻏﻴﺮ ﻣﺘﻮﻗﻌﺔ ﻭﻣﻨﻊ ﺣﺼﺮﻫﺎ ﻳﻤﺜﻞ ﻋﻘﺒﺔ ﻛﺒﻴﺮﺓ ﺃﻣﺎﻡ ﻫﺠﻤﺎﺕ‬ ‫‪-‬‬

‫ﺍﻟﻘﻮﺓﺍﻟﻐﺎﺷﻤﺔ ﺍﻟﻌﻤﻴﺎء ﺗﻤﺎﻣﺎً ﻭﻳﺘﻄﻠﺐ ﻣﻦ ﺍﻟﻤﻬﺎﺟﻢ ﺍﻛﺘﺸﺎﻑ ﺍﺳﻢ ﻣﺴﺘﺨﺪﻡ ﻭﺍﺣﺪ ﺃﻭ ﺃﻛﺜﺮ‬
‫ﻣﺤﺪﺩﺍًﺑﻄﺮﻳﻘﺔ ﻣﺎ ﻗﺒﻞ ﺷﻦ ﻫﺠﻮﻡ‪.‬‬

‫ﺑﻌﺾﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﻟﺤﺴﺎﺳﺔ ﺃﻣﻨﻴﺎً )ﻣﺜﻞ ﺍﻟﺒﻨﻮﻙ ﺍﻹﻟﻜﺘﺮﻭﻧﻴﺔ( ﺗﻌُﻄﻞّ ﺍﻟﺤﺴﺎﺏ ﺑﺒﺴﺎﻃﺔ ﺑﻌﺪ‬ ‫‪-‬‬

‫ﻋﺪﺩﻗﻠﻴﻞ ﻣﻦ ﻣﺤﺎﻭﻻﺕ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﺍﻟﻔﺎﺷﻠﺔ )ﻣﺜﻞ ﺛﻼﺙ ﻣﺤﺎﻭﻻﺕ(‪ .‬ﻛﻤﺎ ﺗﺘﻄﻠﺐ ﻣﻦ‬
‫ﺻﺎﺣﺐﺍﻟﺤﺴﺎﺏ ﺍﺗﺨﺎﺫ ﺧﻄﻮﺍﺕ ﻣﺘﻌﺪﺩﺓ ﺧﺎﺭﺝ ﻧﻄﺎﻕ ﺍﻟﺘﻐﻄﻴﺔ ﻹﻋﺎﺩﺓ ﺗﻨﺸﻴﻂ ﺍﻟﺤﺴﺎﺏ‪،‬‬
‫ﻣﺜﻞﺍﻻﺗﺼﺎﻝ ﺑﺪﻋﻢ ﺍﻟﻌﻤﻼء ﻭﺍﻹﺟﺎﺑﺔ ﻋﻠﻰ ﺳﻠﺴﻠﺔ ﻣﻦ ﺃﺳﺉﻠﺔ ﺍﻷﻣﺎﻥ‪ .‬ﻣﻦ ﻋﻴﻮﺏ ﻫﺬﻩ‬
‫ﺍﻟﺴﻴﺎﺳﺔﺃﻧﻬﺎ ﺗﺴﻤﺢ ﻟﻠﻤﻬﺎﺟﻢ ﺑﺮﻓﺾ ﺍﻟﺨﺪﻣﺔ ﻋﻦ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺍﻟﺸﺮﻋﻴﻴﻦ ﻣﻦ ﺧﻼﻝ‬
‫ﺗﻌﻄﻴﻞﺣﺴﺎﺑﺎﺗﻬﻢ ﺑﺸﻜﻞ ﻣﺘﻜﺮﺭ‪ ،‬ﺑﺎﻹﺿﺎﻓﺔ ﺇﻟﻰ ﺗﻜﻠﻔﺔ ﺗﻮﻓﻴﺮ ﺧﺪﻣﺔ ﺍﺳﺘﺮﺩﺍﺩ ﺍﻟﺤﺴﺎﺏ‪ .‬ﺃﻣﺎ‬
‫ﺍﻟﺴﻴﺎﺳﺔﺍﻷﻛﺜﺮ ﺗﻮﺍﺯﻧﺎً‪ ،‬ﻭﺍﻟﻤﻨﺎﺳﺒﺔ ﻟﻤﻌﻈﻢ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﻟﺘﻲ ﺗﻮﻟﻲ ﺍﻫﺘﻤﺎﻣﺎً ﺃﻣﻨﻴﺎً‪ ،‬ﻓﻬﻲ ﺗﻌﻠﻴﻖ‬
‫ﺍﻟﺤﺴﺎﺑﺎﺕﻟﻔﺘﺮﺓ ﻗﺼﻴﺮﺓ )ﻣﺜﻞ ‪ 30‬ﺩﻗﻴﻘﺔ( ﺑﻌﺪ ﻋﺪﺩ ﻗﻠﻴﻞ ﻣﻦ ﻣﺤﺎﻭﻻﺕ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ‬
‫ﺍﻟﻔﺎﺷﻠﺔ)ﻣﺜﻞ ﺛﻼﺙ ﻣﺤﺎﻭﻻﺕ(‪ .‬ﻳﺒُﻄﺊ ﻫﺬﺍ ﺑﺸﻜﻞ ﻛﺒﻴﺮ ﺃﻱ ﻫﺠﻮﻡ ﺗﺨﻤﻴﻦ ﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ‪ ،‬ﻣﻊ‬
‫ﺍﻟﺘﺨﻔﻴﻒﻣﻦ ﺧﻄﺮ ﻫﺠﻤﺎﺕ ﺭﻓﺾ ﺍﻟﺨﺪﻣﺔ‪ ،‬ﻭﻛﺬﻟﻚ ﺗﻘﻠﻴﻞ ﻋﻤﻞ ﻣﺮﻛﺰ ﺍﻻﺗﺼﺎﻝ‪.‬‬

‫ﺇﺫﺍﺗﻢ ﺗﻨﻔﻴﺬ ﺳﻴﺎﺳﺔ ﺗﻌﻠﻴﻖ ﺍﻟﺤﺴﺎﺏ ﺍﻟﻤﺆﻗﺖ‪ ،‬ﻓﻴﺠﺐ ﺍﻟﺤﺮﺹ ﻋﻠﻰ ﺿﻤﺎﻥ ﻓﻌﺎﻟﻴﺘﻬﺎ‪:‬‬ ‫‪-‬‬

‫ﻟﻤﻨﻊﺗﺴﺮﺏ ﺍﻟﻤﻌﻠﻮﻣﺎﺕ ﺍﻟﺬﻱ ﻗﺪ ﻳﺆﺩﻱ ﺇﻟﻰ ﻋﺪ ّﺃﺳﻤﺎء ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ‪ ،‬ﻳﺠﺐ ﺃﻻ ﻳﺸُﻴﺮ‬ ‫‪-‬‬

‫ﺍﻟﺘﻄﺒﻴﻖﻣﻄﻠﻘﺎً ﺇﻟﻰ ﺗﻌﻠﻴﻖ ﺃﻱ ﺣﺴﺎﺏ‪ .‬ﺑﻞ ﻳﺠﺐ ﺃﻥ ﻳﺴﺘﺠﻴﺐ ﻷﻱ ﺳﻠﺴﻠﺔ ﻣﻦ‬

‫ﻣﺤﺎﻭﻻﺕﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﺍﻟﻔﺎﺷﻠﺔ‪ ،‬ﺣﺘﻰ ﺗﻠﻚ ﺍﻟﺘﻲ ﺗﺴﺘﺨﺪﻡ ﺍﺳﻢ ﻣﺴﺘﺨﺪﻡ ﻏﻴﺮ ﺻﺎﻟﺢ‪،‬‬
‫ﺑﺮﺳﺎﻟﺔﺗﻨُﺒﻪ ﺇﻟﻰ ﺗﻌﻠﻴﻖ ﺍﻟﺤﺴﺎﺑﺎﺕ ﻓﻲ ﺣﺎﻝ ﺗﻜﺮﺍﺭ ﻣﺤﺎﻭﻻﺕ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﺍﻟﻔﺎﺷﻠﺔ‪،‬‬
‫ﻭﺃﻥﻋﻠﻰ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺍﻟﻤﺤﺎﻭﻟﺔ ﻣﺮﺓ ﺃﺧﺮﻯ ﻻﺣﻘﺎً )ﻛﻤﺎ ﺫﻛﺮﻧﺎ ﺳﺎﺑﻘﺎً(‪.‬‬

‫ﻻﻳﻨﺒﻐﻲ ﺍﻹﻓﺼﺎﺡ ﻋﻦ ﻣﻘﺎﻳﻴﺲ ﺍﻟﺴﻴﺎﺳﺔ ﻟﻠﻤﺴﺘﺨﺪﻣﻴﻦ‪ .‬ﻓﻤﺠﺮﺩ ﺇﺧﺒﺎﺭ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ‬ ‫‪-‬‬

‫ﺍﻟﺸﺮﻋﻴﻴﻦ"ﺑﺎﻟﻤﺤﺎﻭﻟﺔ ﻻﺣﻘﺎً" ﻻ ﻳﻀُﻌﻒ ﺟﻮﺩﺓ ﺧﺪﻣﺘﻬﻢ ﺑﺸﻜﻞ ﻛﺒﻴﺮ‪ .‬ﻟﻜﻦ ﺇﻋﻼﻡ ﺍﻟﻤﻬﺎﺟﻢ‬
‫ﺑﺪﻗﺔﺑﻌﺪﺩ ﺍﻟﻤﺤﺎﻭﻻﺕ ﺍﻟﻔﺎﺷﻠﺔ ﺍﻟﻤﺴﻤﻮﺡ ﺑﻬﺎ ﻭﻣﺪﺓ ﺗﻌﻠﻴﻘﻬﺎ‪ ،‬ﻳﻤُﻜﻨّﻪ ﻣﻦ ﺗﺤﺴﻴﻦ ﺃﻱ‬
‫ﻣﺤﺎﻭﻟﺔﻟﻤﻮﺍﺻﻠﺔ ﺗﺨﻤﻴﻦ ﻛﻠﻤﺎﺕ ﺍﻟﻤﺮﻭﺭ ﻋﻠﻰ ﺍﻟﺮﻏﻢ ﻣﻦ ﺍﻟﺴﻴﺎﺳﺔ‪.‬‬

‫ﻓﻲﺣﺎﻝ ﺗﻌﻠﻴﻖ ﺍﻟﺤﺴﺎﺏ‪ ،‬ﻳﺠﺐ ﺭﻓﺾ ﻣﺤﺎﻭﻻﺕ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﺩﻭﻥ ﺍﻟﺘﺤﻘﻖ ﻣﻦ‬ ‫‪-‬‬

‫ﺑﻴﺎﻧﺎﺕﺍﻻﻋﺘﻤﺎﺩ‪ .‬ﺑﻌﺾ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﻟﺘﻲ ﻃﺒﻘّﺖ ﺳﻴﺎﺳﺔ ﺗﻌﻠﻴﻖ ﺗﻈﻞ ﻋﺮﺿﺔ ﻟﻠﻬﺠﻮﻡ‬
‫ﺑﺎﻟﻘﻮﺓﺍﻟﻐﺎﺷﻤﺔ‪ ،‬ﺇﺫ ﺗﺴﺘﻤﺮ ﻓﻲ ﻣﻌﺎﻟﺠﺔ ﻣﺤﺎﻭﻻﺕ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﺑﺎﻟﻜﺎﻣﻞ ﺧﻼﻝ ﻓﺘﺮﺓ‬
‫ﺍﻟﺘﻌﻠﻴﻖ‪،‬ﻭﺗﻌُﻴﺪ ﺭﺳﺎﻟﺔ ﻣﺨﺘﻠﻔﺔ ﺑﺸﻜﻞ ﻃﻔﻴﻒ )ﺃﻭ ﻏﻴﺮ ﺧﻔﻲ( ﻋﻨﺪ ﺗﻘﺪﻳﻢ ﺑﻴﺎﻧﺎﺕ ﺍﻋﺘﻤﺎﺩ‬
‫ﺻﺎﻟﺤﺔ‪.‬ﻳﻤُﻜﻦّ ﻫﺬﺍ ﺍﻟﺴﻠﻮﻙ ﻫﺠﻮﻣﺎً ﻓﻌﺎﻻً ﺑﺎﻟﻘﻮﺓ ﺍﻟﻐﺎﺷﻤﺔ ﻣﻦ ﺍﻟﻤﻀﻲ ﻗﺪﻣﺎً ﺑﺄﻗﺼﻰ‬
‫ﺳﺮﻋﺔﺑﻐﺾ ﺍﻟﻨﻈﺮ ﻋﻦ ﺳﻴﺎﺳﺔ ﺍﻟﺘﻌﻠﻴﻖ‪.‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺩﺱ‪-‬ﻣﻬﺎﺟﻤﺔ ﺍﻟﻤﺼﺎﺩﻗﺔ‬ ‫‪198‬‬

‫ﻻﺗﺴﺎﻋﺪ ﺍﻟﺘﺪﺍﺑﻴﺮ ﺍﻟﻤﻀﺎﺩﺓ ﻟﻜﻞ ﺣﺴﺎﺏ ﻣﺜﻞ ﻗﻔﻞ ﺍﻟﺤﺴﺎﺏ ﻓﻲ ﺍﻟﺤﻤﺎﻳﺔ ﻣﻦ ﻧﻮﻉ ﻭﺍﺣﺪ ﻣﻦ‬ ‫‪-‬‬

‫ﻫﺠﻤﺎﺕﺍﻟﻘﻮﺓ ﺍﻟﻐﺎﺷﻤﺔ ﺍﻟﺘﻲ ﻏﺎﻟﺒﺎً ﻣﺎ ﺗﻜﻮﻥ ﻓﻌﺎﻟﺔ ﻟﻠﻐﺎﻳﺔ ‪ -‬ﺍﻟﺘﻜﺮﺍﺭ ﻣﻦ ﺧﻼﻝ ﻗﺎﺉﻤﺔ ﻃﻮﻳﻠﺔ‬
‫ﻣﻦﺃﺳﻤﺎء ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺍﻟﻤﺬﻛﻮﺭﺓ‪ ،‬ﻭﺍﻟﺘﺤﻘﻖ ﻣﻦ ﻛﻠﻤﺔ ﻣﺮﻭﺭ ﺿﻌﻴﻔﺔ ﻭﺍﺣﺪﺓ‪ ،‬ﻣﺜﻞﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ‪.‬‬
‫ﻋﻠﻰﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﺇﺫﺍ ﺃﺩﺕ ﺧﻤﺲ ﻣﺤﺎﻭﻻﺕ ﻓﺎﺷﻠﺔ ﺇﻟﻰ ﺗﻌﻠﻴﻖ ﺍﻟﺤﺴﺎﺏ‪ ،‬ﻓﻬﺬﺍ ﻳﻌﻨﻲ ﺃﻥ‬
‫ﺍﻟﻤﻬﺎﺟﻢﻳﺴﺘﻄﻴﻊ ﺗﺠﺮﺑﺔ ﺃﺭﺑﻊ ﻛﻠﻤﺎﺕ ﻣﺮﻭﺭ ﻣﺨﺘﻠﻔﺔ ﻋﻠﻰ ﻛﻞ ﺣﺴﺎﺏ ﺩﻭﻥ ﺍﻟﺘﺴﺒﺐ ﺑﺄﻱ‬
‫ﺇﺯﻋﺎﺝﻟﻠﻤﺴﺘﺨﺪﻣﻴﻦ‪ .‬ﻓﻲ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﻟﻨﻤﻮﺫﺟﻴﺔ ﺍﻟﺘﻲ ﺗﺤﺘﻮﻱ ﻋﻠﻰ ﺍﻟﻌﺪﻳﺪ ﻣﻦ ﻛﻠﻤﺎﺕ‬
‫ﺍﻟﻤﺮﻭﺭﺍﻟﻀﻌﻴﻔﺔ‪ ،‬ﻣﻦ ﺍﻟﻤﺮﺟﺢ ﺃﻥ ﻳﺨُﺘﺮﻕ ﺍﻟﻌﺪﻳﺪ ﻣﻦ ﺍﻟﺤﺴﺎﺑﺎﺕ‪.‬‬

‫ﺑﺎﻟﻄﺒﻊ‪،‬ﺳﺘﻨﺨﻔﺾ ﻓﻌﺎﻟﻴﺔ ﻫﺬﺍ ﺍﻟﻨﻮﻉ ﻣﻦ ﺍﻟﻬﺠﻤﺎﺕ ﺑﺸﻜﻞ ﻛﺒﻴﺮ ﺇﺫﺍ ﺻﻤُﻤﺖ ﺟﻮﺍﻧﺐ ﺃﺧﺮﻯ‬
‫ﻣﻦﺁﻟﻴﺔ ﺍﻟﻤﺼﺎﺩﻗﺔ ﺑﺸﻜﻞ ﺁﻣﻦ‪ .‬ﺇﺫﺍ ﺗﻌﺬﺭّ ﺇﺣﺼﺎء ﺃﺳﻤﺎء ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺃﻭ ﺍﻟﺘﻨﺒﺆ ﺑﻬﺎ ﺑﺸﻜﻞ‬
‫ﻣﻮﺛﻮﻕ‪،‬ﻓﺴﻴﺘﺒﺎﻃﺄ ﺍﻟﻤﻬﺎﺟﻢ ﺑﺴﺒﺐ ﺍﻟﺤﺎﺟﺔ ﺇﻟﻰ ﺇﺟﺮﺍء ﺍﺧﺘﺒﺎﺭ ﻗﻮﺓ ﻏﺎﺷﻤﺔ ﻟﺘﺨﻤﻴﻦ ﺃﺳﻤﺎء‬
‫ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ‪.‬ﻭﺇﺫﺍ ﻭﺿُﻌﺖ ﻣﺘﻄﻠﺒﺎﺕ ﺻﺎﺭﻣﺔ ﻟﺠﻮﺩﺓ ﻛﻠﻤﺎﺕ ﺍﻟﻤﺮﻭﺭ‪ ،‬ﻓﺴﻴﻜﻮﻥ ﻣﻦ ﻏﻴﺮ‬
‫ﺍﻟﻤﺮﺟﺢﺃﻥ ﻳﺨﺘﺎﺭ ﺍﻟﻤﻬﺎﺟﻢ ﻛﻠﻤﺔ ﻣﺮﻭﺭ ﻟﻼﺧﺘﺒﺎﺭ ﺍﺧﺘﺎﺭﻫﺎ ﺣﺘﻰ ﻣﺴﺘﺨﺪﻡ ﻭﺍﺣﺪ ﻟﻠﺘﻄﺒﻴﻖ‪.‬‬

‫ﺑﺎﻹﺿﺎﻓﺔﺇﻟﻰ ﻫﺬﻩ ﺍﻟﻀﻮﺍﺑﻂ‪ ،‬ﻳﻤﻜﻦ ﻟﻠﺘﻄﺒﻴﻖ ﺣﻤﺎﻳﺔ ﻧﻔﺴﻪ ﺑﺸﻜﻞ ﺧﺎﺹ ﻣﻦ ﻫﺬﺍ ﺍﻟﻨﻮﻉ‬
‫ﻣﻦﺍﻟﻬﺠﻤﺎﺕ ﻣﻦ ﺧﻼﻝ ﺍﺳﺘﺨﺪﺍﻡ ﺗﺤﺪﻳﺎﺕ ‪) CAPTCHA‬ﺍﺧﺘﺒﺎﺭ ﺗﻮﺭﻳﻨﺞ ﺍﻟﻌﺎﻡ ﺍﻵﻟﻲ ﺑﺎﻟﻜﺎﻣﻞ‬
‫ﻟﻠﺘﻤﻴﻴﺰﺑﻴﻦ ﺃﺟﻬﺰﺓ ﺍﻟﻜﻤﺒﻴﻮﺗﺮ ﻭﺍﻟﺒﺸﺮ( ﻋﻠﻰ ﻛﻞ ﺻﻔﺤﺔ ﻗﺪ ﺗﻜﻮﻥ ﻫﺪﻓﺎً ﻟﻬﺠﻤﺎﺕ ﺍﻟﻘﻮﺓ‬
‫ﺍﻟﻐﺎﺷﻤﺔ)ﺍﻧﻈﺮ ﺍﻟﺸﻜﻞ ‪ .(9-6‬ﺇﺫﺍ ﻛﺎﻥ ﻫﺬﺍ ﺍﻹﺟﺮﺍء ﻓﻌﺎﻻ‪ ً،‬ﻓﻴﻤﻜﻨﻪ ﻣﻨﻊ ﺃﻱ ﺇﺭﺳﺎﻝ ﺗﻠﻘﺎﺉﻲ‬
‫ﻟﻠﺒﻴﺎﻧﺎﺕﺇﻟﻰ ﺃﻱ ﺻﻔﺤﺔ ﺗﻄﺒﻴﻖ‪ ،‬ﻭﺑﺎﻟﺘﺎﻟﻲ ﻣﻨﻊ ﺟﻤﻴﻊ ﺃﻧﻮﺍﻉ ﻫﺠﻤﺎﺕ ﺗﺨﻤﻴﻦ ﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ ﻣﻦ‬
‫ﺍﻟﺘﻨﻔﻴﺬﻳﺪﻭﻳﺎً‪ .‬ﺗﺠﺪﺭ ﺍﻹﺷﺎﺭﺓ ﺇﻟﻰ ﺃﻧﻪ ﺗﻢ ﺇﺟﺮﺍء ﺍﻟﻜﺜﻴﺮ ﻣﻦ ﺍﻷﺑﺤﺎﺙ ﺣﻮﻝ ﺗﻘﻨﻴﺎﺕ ‪،CAPTCHA‬‬
‫ﻭﻛﺎﻧﺖﺍﻟﻬﺠﻤﺎﺕ ﺍﻵﻟﻴﺔ ﺿﺪﻫﺎ ﻣﻮﺛﻮﻗﺔ ﻓﻲ ﺑﻌﺾ ﺍﻟﺤﺎﻻﺕ‪ .‬ﻋﻼﻭﺓ ﻋﻠﻰ ﺫﻟﻚ‪ ،‬ﻣﻦ ﺍﻟﻤﻌﺮﻭﻑ‬
‫ﺃﻥﺑﻌﺾ ﺍﻟﻤﻬﺎﺟﻤﻴﻦ ﻳﺒﺘﻜﺮﻭﻥ ﻣﺴﺎﺑﻘﺎﺕ ﻟﺤﻞ ‪ ،CAPTCHA‬ﺣﻴﺚ ﻳﺘﻢ ﺍﻻﺳﺘﻔﺎﺩﺓ ﻣﻦ ﺃﻓﺮﺍﺩ‬
‫ﺍﻟﺠﻤﻬﻮﺭﻏﻴﺮ ﺍﻟﻤﺪﺭﻛﻴﻦ ﻛﻄﺎﺉﺮﺍﺕ ﺑﺪﻭﻥ ﻃﻴﺎﺭ ﻟﻤﺴﺎﻋﺪﺓ ﺍﻟﻤﻬﺎﺟﻢ‪ .‬ﻭﻣﻊ ﺫﻟﻚ‪ ،‬ﺣﺘﻰ‬

‫ﺇﻥﺍﻟﺘﺤﺪﻱ ﻟﻴﺲ ﻓﻌﺎﻻ ًﺗﻤﺎﻣﺎً‪ ،‬ﺑﻞ ﻳﺠﺐ‬

‫ﺇﻳﺠﺎﺩﺗﻄﺒﻴﻖ ﻟﻪ‪.‬‬ ‫ﺳﻮﻑﺗﺴﺘﻤﺮ ﻓﻲ ﺍﻟﻘﻴﺎﺩﺓ‬

‫ﻻﻳﺸﻐﻞ‬

‫ﺍﻟﺸﻜﻞ‪:9-6‬ﻋﻨﺼﺮ ﺗﺤﻜﻢ ‪ CAPTCHA‬ﻣﺼﻤﻢ‬

‫ﻟﻤﻨﻊﺍﻟﻬﺠﻤﺎﺕ ﺍﻵﻟﻴﺔ‬

‫ﻧﺼﻴﺤﺔﺇﺫﺍ ﻛﻨﺖ ﺗﻬﺎﺟﻢ ﺗﻄﺒﻴﻘﺎً ﻳﺴﺘﺨﺪﻡ ﻋﻨﺎﺻﺮ ﺗﺤﻜﻢ ‪ CAPTCHA‬ﻟﻌﺮﻗﻠﺔ ﺍﻷﺗﻤﺘﺔ‪ ،‬ﻓﺮﺍﺟﻊ ﺩﺍﺉﻤﺎً‬
‫ﻣﺼﺪﺭ‪ HTML‬ﻟﻠﺼﻔﺤﺔ ﺍﻟﺘﻲ ﺗﻈﻬﺮ ﻓﻴﻬﺎ ﺍﻟﺼﻮﺭﺓ ﺑﺪﻗﺔ‪ .‬ﻭﺍﺟﻪ ﺍﻟﻤﺆﻟﻔﻮﻥ ﺣﺎﻻﺕ ﺣﻴﺚ ﻛﺎﻥ ﺍﻟﺤﻞ‬
‫‪199‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺩﺱ‪-‬ﻣﻬﺎﺟﻤﺔ ﺍﻟﻤﺼﺎﺩﻗﺔ‬

‫ﻳﻈﻬﺮﺍﻟﻠﻐﺰ ﻓﻲ ﺷﻜﻞ ﺣﺮﻓﻲ ﺩﺍﺧﻞﺑﺪﻳﻞﺳﻤﺔ ﻣﻦ ﺳﻤﺎﺕ ﻋﻼﻣﺔ ﺍﻟﺼﻮﺭﺓ‪ ،‬ﺃﻭ ﺩﺍﺧﻞ ﺣﻘﻞ ﻧﻤﻮﺫﺝ‬
‫ﻣﺨﻔﻲ‪،‬ﻣﻤﺎ ﻳﺘﻴﺢ ﻟﻬﺠﻮﻡ ﻧﺼﻲ ﺃﻥ ﻳﻬﺰﻡ ﺍﻟﺤﻤﺎﻳﺔ ﺩﻭﻥ ﺣﻞ ﺍﻟﻠﻐﺰ ﻧﻔﺴﻪ ﻓﻌﻠﻴﺎً‪.‬‬

‫ﻣﻨﻊﺇﺳﺎءﺓ ﺍﺳﺘﺨﺪﺍﻡ ﻭﻇﻴﻔﺔ ﺗﻐﻴﻴﺮ ﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ‬

‫ﻳﻨﺒﻐﻲﺩﺍﺉﻤﺎً ﺗﻔﻌﻴﻞ ﺧﺎﺻﻴﺔ ﺗﻐﻴﻴﺮ ﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ‪ ،‬ﻟﻠﺴﻤﺎﺡ ﺑﺎﻧﺘﻬﺎء ﺻﻼﺣﻴﺘﻬﺎ ﺑﺸﻜﻞ ﺩﻭﺭﻱ )‬ ‫‪-‬‬

‫ﻋﻨﺪﺍﻟﺤﺎﺟﺔ(‪ ،‬ﻭﺗﻤﻜﻴﻦ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﻣﻦ ﺗﻐﻴﻴﺮ ﻛﻠﻤﺎﺕ ﺍﻟﻤﺮﻭﺭ ﻷﻱ ﺳﺒﺐ‪ .‬ﻭﺑﺎﻋﺘﺒﺎﺭﻫﺎ ﺁﻟﻴﺔ‬

‫ﺃﻣﺎﻥﺃﺳﺎﺳﻴﺔ‪ ،‬ﻳﺠﺐ ﺣﻤﺎﻳﺔ ﻫﺬﻩ ﺍﻟﺨﺎﺻﻴﺔ ﺟﻴﺪﺍً ﻣﻦ ﺳﻮء ﺍﻻﺳﺘﺨﺪﺍﻡ‪.‬‬

‫ﻳﺠﺐﺃﻥ ﺗﻜﻮﻥ ﺍﻟﻮﻇﻴﻔﺔ ﻣﺘﺎﺣﺔ ﻓﻘﻂ ﻣﻦ ﺩﺍﺧﻞ ﺟﻠﺴﺔ ﻣﻌﺘﻤﺪﺓ‪.‬‬ ‫‪-‬‬

‫ﻻﻳﻨﺒﻐﻲ ﺇﺗﺎﺣﺔ ﺇﻣﻜﺎﻧﻴﺔ ﺇﺩﺧﺎﻝ ﺍﺳﻢ ﻣﺴﺘﺨﺪﻡ‪ ،‬ﺳﻮﺍء ًﺻﺮﺍﺣﺔ ًﺃﻭ ﻋﺒﺮ ﺣﻘﻞ ﻧﻤﻮﺫﺝ ﻣﺨﻔﻲ ﺃﻭ‬ ‫‪-‬‬

‫ﻣﻠﻒﺗﻌﺮﻳﻒ ﺍﺭﺗﺒﺎﻁ‪ .‬ﻭﻻ ﺣﺎﺟﺔ ﻣﺸﺮﻭﻋﺔ ﻟﻠﻤﺴﺘﺨﺪﻣﻴﻦ ﻟﺘﻐﻴﻴﺮ ﻛﻠﻤﺎﺕ ﻣﺮﻭﺭ ﺍﻵﺧﺮﻳﻦ‪.‬‬

‫ﻛﺈﺟﺮﺍءﺩﻓﺎﻋﻲ ﻣﺘﻌﻤﻖ‪ ،‬ﻳﺠﺐ ﺣﻤﺎﻳﺔ ﺍﻟﻮﻇﻴﻔﺔ ﻣﻦ ﺍﻟﻮﺻﻮﻝ ﻏﻴﺮ ﺍﻟﻤﺼﺮﺡ ﺑﻪ ﺍﻟﻨﺎﺗﺞ ﻋﻦ ﺧﻠﻞ‬ ‫‪-‬‬

‫ﺃﻣﻨﻲﺁﺧﺮ ﻓﻲ ﺍﻟﺘﻄﺒﻴﻖ ‪ -‬ﻣﺜﻞ ﺛﻐﺮﺓ ﺍﺧﺘﻄﺎﻑ ﺍﻟﺠﻠﺴﺔ‪ ،‬ﺃﻭ ﺑﺮﻣﺠﻴﺔ ﻧﺼﻴﺔ ﻋﺒﺮ ﺍﻟﻤﻮﺍﻗﻊ‪ ،‬ﺃﻭ ﺣﺘﻰ‬
‫ﻣﺤﻄﺔﻃﺮﻓﻴﺔ ﻏﻴﺮ ﻣﺮﺍﻗﺒﺔ‪ .‬ﻭﻟﺘﺤﻘﻴﻖ ﺫﻟﻚ‪ ،‬ﻳﻄُﻠﺐ ﻣﻦ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺇﻋﺎﺩﺓ ﺇﺩﺧﺎﻝ ﻛﻠﻤﺔ‬
‫ﻣﺮﻭﺭﻫﻢﺍﻟﺤﺎﻟﻴﺔ‪.‬‬

‫ﻳﺠﺐﺇﺩﺧﺎﻝ ﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ ﺍﻟﺠﺪﻳﺪﺓ ﻣﺮﺗﻴﻦ ﻟﺘﺠﻨﺐ ﺍﻷﺧﻄﺎء‪ .‬ﺳﻴﻘُﺎﺭﻥ ﺍﻟﺘﻄﺒﻴﻖ ﺣﻘﻠﻲ "ﻛﻠﻤﺔ‬ ‫‪-‬‬

‫ﺍﻟﻤﺮﻭﺭﺍﻟﺠﺪﻳﺪﺓ" ﻭ"ﺗﺄﻛﻴﺪ ﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ ﺍﻟﺠﺪﻳﺪﺓ" ﻛﺨﻄﻮﺓ ﺃﻭﻟﻰ‪ ،‬ﻭﻳﻈُﻬﺮ ﺧﻄﺄ ًﻓﻲ ﺣﺎﻝ ﻋﺪﻡ‬
‫ﺗﻄﺎﺑﻘﻬﻤﺎ‪.‬‬
‫ﻳﺠﺐﺃﻥ ﺗﻤﻨﻊ ﻫﺬﻩ ﺍﻟﻮﻇﻴﻔﺔ ﺍﻟﻬﺠﻤﺎﺕ ﺍﻟﻤﺨﺘﻠﻔﺔ ﺍﻟﺘﻲ ﻗﺪ ﺗﺸُﻦ ﻋﻠﻰ ﺁﻟﻴﺔ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ‬ ‫‪-‬‬

‫ﺍﻟﺮﺉﻴﺴﻴﺔ‪.‬ﻳﺠﺐ ﺍﺳﺘﺨﺪﺍﻡ ﺭﺳﺎﻟﺔ ﺧﻄﺄ ﻋﺎﻣﺔ ﻭﺍﺣﺪﺓ ﻹﺧﻄﺎﺭ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺑﺄﻱ ﺧﻄﺄ ﻓﻲ‬
‫ﺑﻴﺎﻧﺎﺕﺍﻻﻋﺘﻤﺎﺩ ﺍﻟﺤﺎﻟﻴﺔ‪ ،‬ﻭﻳﺠﺐ ﺗﻌﻠﻴﻖ ﺍﻟﻮﻇﻴﻔﺔ ﻣﺆﻗﺘﺎً ﺑﻌﺪ ﻋﺪﺩ ﻗﻠﻴﻞ ﻣﻦ ﺍﻟﻤﺤﺎﻭﻻﺕ‬
‫ﺍﻟﻔﺎﺷﻠﺔﻟﺘﻐﻴﻴﺮ ﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ‪.‬‬

‫ﻳﺠﺐﺇﺧﻄﺎﺭ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺧﺎﺭﺝ ﺍﻟﻨﻄﺎﻕ )ﻣﺜﻞ ﺍﻟﺒﺮﻳﺪ ﺍﻹﻟﻜﺘﺮﻭﻧﻲ( ﺑﺄﻥ ﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ ﺍﻟﺨﺎﺻﺔ‬ ‫‪-‬‬

‫ﺑﻬﻢﻗﺪ ﺗﻢ ﺗﻐﻴﻴﺮﻫﺎ‪ ،‬ﻭﻟﻜﻦ ﻻ ﻳﻨﺒﻐﻲ ﺃﻥ ﺗﺤﺘﻮﻱ ﺍﻟﺮﺳﺎﻟﺔ ﻋﻠﻰ ﺑﻴﺎﻧﺎﺕ ﺍﻋﺘﻤﺎﺩﻫﻢ ﺍﻟﻘﺪﻳﻤﺔ ﺃﻭ‬
‫ﺍﻟﺠﺪﻳﺪﺓ‪.‬‬

‫ﻣﻨﻊﺇﺳﺎءﺓ ﺍﺳﺘﺨﺪﺍﻡ ﻭﻇﻴﻔﺔ ﺍﺳﺘﺮﺩﺍﺩ ﺍﻟﺤﺴﺎﺏ‬

‫ﻓﻲﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﻷﻛﺜﺮ ﺃﻫﻤﻴﺔ ًﺃﻣﻨﻴﺎً‪ ،‬ﻣﺜﻞ ﺍﻟﺨﺪﻣﺎﺕ ﺍﻟﻤﺼﺮﻓﻴﺔ ﻋﺒﺮ ﺍﻹﻧﺘﺮﻧﺖ‪ ،‬ﺗﺪُﺍﺭ ﻋﻤﻠﻴﺔ‬ ‫‪-‬‬

‫ﺍﺳﺘﺮﺩﺍﺩﺍﻟﺤﺴﺎﺏ ﻓﻲ ﺣﺎﻝ ﻧﺴﻴﺎﻥ ﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ ﺧﺎﺭﺝ ﻧﻄﺎﻕ ﺍﻟﺘﻐﻄﻴﺔ‪ .‬ﻳﺠﺐ ﻋﻠﻰ ﺍﻟﻤﺴﺘﺨﺪﻡ‬
‫ﺇﺟﺮﺍءﻣﻜﺎﻟﻤﺔ ﻫﺎﺗﻔﻴﺔ ﻭﺍﻹﺟﺎﺑﺔ ﻋﻠﻰ ﺳﻠﺴﻠﺔ ﻣﻦ ﺃﺳﺉﻠﺔ ﺍﻷﻣﺎﻥ‪ ،‬ﻛﻤﺎ ﺗﺮُﺳﻞ ﺑﻴﺎﻧﺎﺕ ﺍﻋﺘﻤﺎﺩ‬
‫ﺟﺪﻳﺪﺓﺃﻭ ﺭﻣﺰ ﺇﻋﺎﺩﺓ ﺗﻔﻌﻴﻞ ﺧﺎﺭﺝ ﻧﻄﺎﻕ ﺍﻟﺘﻐﻄﻴﺔ )ﻋﺒﺮ ﺍﻟﺒﺮﻳﺪ ﺍﻟﺘﻘﻠﻴﺪﻱ( ﺇﻟﻰ ﻋﻨﻮﺍﻥ ﻣﻨﺰﻟﻪ‬
‫ﺍﻟﻤﺴﺠﻞ‪.‬ﻻ ﺗﺮﻏﺐ ﻣﻌﻈﻢ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺃﻭ ﻻ ﺗﺤﺘﺎﺝ ﺇﻟﻰ ﻫﺬﺍ ﺍﻟﻤﺴﺘﻮﻯ ﻣﻦ ﺍﻷﻣﺎﻥ‪ ،‬ﻟﺬﺍ ﻗﺪ‬
‫ﺗﻜﻮﻥﻭﻇﻴﻔﺔ ﺍﻻﺳﺘﺮﺩﺍﺩ ﺍﻟﺘﻠﻘﺎﺉﻲ ﻣﻨﺎﺳﺒﺔ‪.‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺩﺱ‪-‬ﻣﻬﺎﺟﻤﺔ ﺍﻟﻤﺼﺎﺩﻗﺔ‬ ‫‪200‬‬

‫ﻳﺠﺐﺃﻥ ﺗﻌﻤﻞ ﺁﻟﻴﺔ ﺍﺳﺘﺮﺩﺍﺩ ﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ ﺍﻟﻤﺼﻤﻤﺔ ﺟﻴﺪﺍً ﻋﻠﻰ ﻣﻨﻊ ﺗﻌﺮﺽ ﺍﻟﺤﺴﺎﺑﺎﺕ‬ ‫‪-‬‬

‫ﻟﻼﺧﺘﺮﺍﻕﻣﻦ ﻗﺒﻞ ﻃﺮﻑ ﻏﻴﺮ ﻣﺼﺮﺡ ﻟﻪ ﻭﺗﻘﻠﻴﻞ ﺃﻱ ﺇﺯﻋﺎﺝ ﻟﻠﻤﺴﺘﺨﺪﻣﻴﻦ ﺍﻟﺸﺮﻋﻴﻴﻦ‪.‬‬

‫ﻻﻳﻨﺒﻐﻲ ﺃﺑﺪﺍً ﺍﺳﺘﺨﺪﺍﻡ ﻣﻴﺰﺍﺕ ﻣﺜﻞ "ﺗﻠﻤﻴﺤﺎﺕ" ﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ‪ ،‬ﻷﻧﻬﺎ ﺗﺴﺎﻋﺪ ﺍﻟﻤﻬﺎﺟﻢ ﺑﺸﻜﻞ‬ ‫‪-‬‬

‫ﺃﺳﺎﺳﻲﻓﻲ ﺍﻟﺒﺤﺚ ﻋﻦ ﺍﻟﺤﺴﺎﺑﺎﺕ ﺍﻟﺘﻲ ﺗﺤﺘﻮﻱ ﻋﻠﻰ ﺗﻠﻤﻴﺤﺎﺕ ﻭﺍﺿﺤﺔ‪.‬‬

‫ﺃﻓﻀﻞﺣﻞ ﺁﻟﻲ ﻟﺘﻤﻜﻴﻦ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﻣﻦ ﺍﺳﺘﻌﺎﺩﺓ ﺍﻟﺘﺤﻜﻢ ﻓﻲ ﺣﺴﺎﺑﺎﺗﻬﻢ ﻫﻮ ﺇﺭﺳﺎﻝ ﺭﺍﺑﻂ‬ ‫‪-‬‬

‫ﺍﺳﺘﺮﺩﺍﺩﻓﺮﻳﺪ‪ ،‬ﻣﺤﺪﻭﺩ ﺍﻟﻤﺪﺓ‪ ،‬ﺳﻬﻞ ﺍﻟﺘﺨﻤﻴﻦ‪ ،‬ﻟﻼﺳﺘﺨﺪﺍﻡ ﻣﺮﺓ ﻭﺍﺣﺪﺓ ﻋﺒﺮ ﺍﻟﺒﺮﻳﺪ ﺍﻹﻟﻜﺘﺮﻭﻧﻲ‪.‬‬
‫ﻳﺠﺐﺇﺭﺳﺎﻝ ﻫﺬﺍ ﺍﻟﺒﺮﻳﺪ ﺍﻹﻟﻜﺘﺮﻭﻧﻲ ﺇﻟﻰ ﺍﻟﻌﻨﻮﺍﻥ ﺍﻟﺬﻱ ﺃﺩﺧﻠﻪ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺃﺛﻨﺎء ﺍﻟﺘﺴﺠﻴﻞ‪ .‬ﺗﺘﻴﺢ‬
‫ﺯﻳﺎﺭﺓﻫﺬﺍ ﺍﻟﺮﺍﺑﻂ ﻟﻠﻤﺴﺘﺨﺪﻡ ﺗﻌﻴﻴﻦ ﻛﻠﻤﺔ ﻣﺮﻭﺭ ﺟﺪﻳﺪﺓ‪ .‬ﺑﻌﺪ ﺫﻟﻚ‪ ،‬ﻳﺠﺐ ﺇﺭﺳﺎﻝ ﺑﺮﻳﺪ ﺇﻟﻜﺘﺮﻭﻧﻲ‬
‫ﺛﺎﻥ ٍﻳﺸُﻴﺮ ﺇﻟﻰ ﺗﻐﻴﻴﺮ ﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ‪ .‬ﻟﻤﻨﻊ ﺍﻟﻤﻬﺎﺟﻢ ﻣﻦ ﺭﻓﺾ ﺍﻟﺨﺪﻣﺔ ﻋﻦ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﻣﻦ‬
‫ﺧﻼﻝﻃﻠﺐ ﺭﺳﺎﺉﻞ ﺑﺮﻳﺪ ﺇﻟﻜﺘﺮﻭﻧﻲ ﻣﺘﻜﺮﺭﺓ ﻹﻋﺎﺩﺓ ﺗﻨﺸﻴﻂ ﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ‪ ،‬ﻳﺠﺐ ﺃﻥ ﺗﻈﻞ‬
‫ﺑﻴﺎﻧﺎﺕﺍﻋﺘﻤﺎﺩ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺍﻟﺤﺎﻟﻴﺔ ﺻﺎﻟﺤﺔ ﺣﺘﻰ ﻳﺘﻢ ﺗﻐﻴﻴﺮﻫﺎ‪.‬‬

‫ﻟﻤﺰﻳﺪﻣﻦ ﺍﻟﺤﻤﺎﻳﺔ ﻣﻦ ﺍﻟﻮﺻﻮﻝ ﻏﻴﺮ ﺍﻟﻤﺼﺮﺡ ﺑﻪ‪ ،‬ﻗﺪ ﺗﻘُﺪﻡّ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﻟﻠﻤﺴﺘﺨﺪﻣﻴﻦ ﺗﺤﺪﻳﺎً‬ ‫‪-‬‬

‫ﺛﺎﻧﻮﻳﺎًﻳﺠﺐ ﻋﻠﻴﻬﻢ ﺇﻛﻤﺎﻟﻪ ﻗﺒﻞ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﻭﻇﻴﻔﺔ ﺇﻋﺎﺩﺓ ﺗﻌﻴﻴﻦ ﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ‪ .‬ﺗﺄﻛﺪ ﻣﻦ ﺃﻥ‬
‫ﺗﺼﻤﻴﻢﻫﺬﺍ ﺍﻟﺘﺤﺪﻱ ﻻ ﻳﻨُﺸﺊ ﺛﻐﺮﺍﺕ ﺃﻣﻨﻴﺔ ﺟﺪﻳﺪﺓ‪:‬‬

‫ﻳﺠﺐﺃﻥ ﻳﺘﻀﻤﻦ ﺍﻟﺘﺤﺪﻱ ﻧﻔﺲ ﺍﻟﺴﺆﺍﻝ ﺃﻭ ﻣﺠﻤﻮﻋﺔ ﺍﻷﺳﺉﻠﺔ ﻟﻠﺠﻤﻴﻊ‪ ،‬ﻭﻓﻘﺎً ﻟﻤﺎ ﻳﻨﺺ‬ ‫‪-‬‬

‫ﻋﻠﻴﻪﺍﻟﺘﻄﺒﻴﻖ ﺃﺛﻨﺎء ﺍﻟﺘﺴﺠﻴﻞ‪.‬‬

‫ﺇﺫﺍﻗﺪﻡ ﺍﻟﻤﺴﺘﺨﺪﻣﻮﻥ ﺗﺤﺪﻳﻬﻢ ﺍﻟﺨﺎﺹ‪ ،‬ﻓﻤﻦ ﺍﻟﻤﺤﺘﻤﻞ ﺃﻥ ﻳﻜﻮﻥ ﺑﻌﺾ ﻫﺬﻩ ﺍﻟﺘﺤﺪﻳﺎﺕ‬
‫ﺿﻌﻴﻔﺎً‪،‬ﻭﻫﺬﺍ ﻳﻤﻜﻦّ ﺍﻟﻤﻬﺎﺟﻢ ﺃﻳﻀﺎً ﻣﻦ ﺗﻌﺪﺍﺩ ﺍﻟﺤﺴﺎﺑﺎﺕ ﺍﻟﺼﺎﻟﺤﺔ ﻣﻦ ﺧﻼﻝ ﺗﺤﺪﻳﺪ ﺗﻠﻚ‬
‫ﺍﻟﺘﻲﺗﻢ ﺗﻌﻴﻴﻦ ﻣﺠﻤﻮﻋﺔ ﻣﻦ ﺍﻟﺘﺤﺪﻳﺎﺕ ﻟﻬﺎ‪.‬‬
‫ﻳﺠﺐﺃﻥ ﺗﺤﺘﻮﻱ ﺇﺟﺎﺑﺎﺕ ﺍﻟﺘﺤﺪﻱ ﻋﻠﻰ ﻗﺪﺭ ﻛﺎﻑ ٍﻣﻦ ﺍﻹﻧﺘﺮﻭﺑﻴﺎ ﺑﺤﻴﺚ ﻳﺼﻌﺐ ﺗﺨﻤﻴﻨﻬﺎ‪.‬‬ ‫‪-‬‬

‫ﻋﻠﻰﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﻳﻔُﻀﻞّ ﺳﺆﺍﻝ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻋﻦ ﺍﺳﻢ ﻣﺪﺭﺳﺘﻪ ﺍﻷﻭﻟﻰ ﺑﺪﻻً ﻣﻦ ﺳﺆﺍﻟﻪ‬
‫ﻋﻦﻟﻮﻧﻪ ﺍﻟﻤﻔﻀﻞ‪.‬‬
‫ﻳﺠﺐﺗﻌﻠﻴﻖ ﺍﻟﺤﺴﺎﺑﺎﺕ ﻣﺆﻗﺘﺎً ﺑﻌﺪ ﻋﺪﺩ ﻣﻦ ﺍﻟﻤﺤﺎﻭﻻﺕ ﺍﻟﻔﺎﺷﻠﺔ ﻹﻛﻤﺎﻝ ﺍﻟﺘﺤﺪﻱ‪ ،‬ﻟﻤﻨﻊ‬ ‫‪-‬‬

‫ﻫﺠﻤﺎﺕﺍﻟﻘﻮﺓ ﺍﻟﻐﺎﺷﻤﺔ‪.‬‬
‫ﻻﻳﻨﺒﻐﻲ ﻟﻠﺘﻄﺒﻴﻖ ﺃﻥ ﻳﺴﺮﺏ ﺃﻱ ﻣﻌﻠﻮﻣﺎﺕ ﻓﻲ ﺣﺎﻟﺔ ﻋﺪﻡ ﺍﻟﺮﺩ ﻋﻠﻰ ﺍﻟﺘﺤﺪﻱ ‪ -‬ﻓﻴﻤﺎ‬ ‫‪-‬‬

‫ﻳﺘﻌﻠﻖﺑﺼﺤﺔ ﺍﺳﻢ ﺍﻟﻤﺴﺘﺨﺪﻡ‪ ،‬ﺃﻭ ﺗﻌﻠﻴﻖ ﺍﻟﺤﺴﺎﺏ‪ ،‬ﻭﻣﺎ ﺇﻟﻰ ﺫﻟﻚ‪.‬‬

‫ﺑﻌﺪﺇﺗﻤﺎﻡ ﺍﻟﺘﺤﺪﻱ ﺑﻨﺠﺎﺡ‪ ،‬ﻳﺠﺐ ﺍﺗﺒﺎﻉ ﺍﻟﻌﻤﻠﻴﺔ ﺍﻟﻤﻮﺿﺤﺔ ﺳﺎﺑﻘﺎً‪ ،‬ﺣﻴﺚ ﺗﺮُﺳﻞ ﺭﺳﺎﻟﺔ ﺇﻟﻰ‬ ‫‪-‬‬

‫ﻋﻨﻮﺍﻥﺍﻟﺒﺮﻳﺪ ﺍﻹﻟﻜﺘﺮﻭﻧﻲ ﺍﻟﻤﺴﺠﻞ ﻟﻠﻤﺴﺘﺨﺪﻡ ﺗﺤﺘﻮﻱ ﻋﻠﻰ ﺭﺍﺑﻂ ﺇﻋﺎﺩﺓ ﺍﻟﺘﻨﺸﻴﻂ‪ .‬ﻻ‬
‫ﻳﻨﺒﻐﻲﻟﻠﺘﻄﺒﻴﻖ‪ ،‬ﺗﺤﺖ ﺃﻱ ﻇﺮﻑ ﻣﻦ ﺍﻟﻈﺮﻭﻑ‪ ،‬ﺍﻟﻜﺸﻒ ﻋﻦ ﻛﻠﻤﺔ ﻣﺮﻭﺭ ﺍﻟﻤﺴﺘﺨﺪﻡ‬
‫ﺍﻟﻤﻨﺴﻴﺔﺃﻭ ﺑﺒﺴﺎﻃﺔ ﺇﺩﺧﺎﻟﻪ ﻓﻲ ﺟﻠﺴﺔ ﻣﺼُﺎﺩﻕ ﻋﻠﻴﻬﺎ‪ .‬ﺣﺘﻰ ﺍﻻﻧﺘﻘﺎﻝ ﻣﺒﺎﺷﺮﺓ ًﺇﻟﻰ ﻭﻇﻴﻔﺔ‬
‫ﺇﻋﺎﺩﺓﺗﻌﻴﻴﻦ ﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ ﻏﻴﺮ ﻣﺮﻏﻮﺏ ﻓﻴﻪ‪ .‬ﻋﺎﺩﺓ ًﻣﺎ ﻳﻜﻮﻥ ﺗﺨﻤﻴﻦ ﺍﺳﺘﺠﺎﺑﺔ ﺗﺤﺪﻱ‬
‫ﺍﺳﺘﻌﺎﺩﺓﺍﻟﺤﺴﺎﺏ ﺃﺳﻬﻞ ﻋﻠﻰ ﺍﻟﻤﻬﺎﺟﻢ ﻣﻦ ﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ ﺍﻷﺻﻠﻴﺔ‪ ،‬ﻟﺬﺍ ﻻ ﻳﻨﺒﻐﻲ ﺍﻻﻋﺘﻤﺎﺩ‬
‫ﻋﻠﻴﻬﺎﻭﺣﺪﻫﺎ ﻟﻤﺼﺎﺩﻗﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ‪.‬‬
‫‪201‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺩﺱ‪-‬ﻣﻬﺎﺟﻤﺔ ﺍﻟﻤﺼﺎﺩﻗﺔ‬

‫ﺳﺠﻞ‪،‬ﺭﺍﻗﺐ‪ ،‬ﻭﺃﺧﻄﺮ‬

‫ﻳﺠﺐﺃﻥ ﻳﺴُﺠﻞِّ ﺍﻟﺘﻄﺒﻴﻖ ﺟﻤﻴﻊ ﺃﺣﺪﺍﺙ ﺍﻟﻤﺼﺎﺩﻗﺔ‪ ،‬ﺑﻤﺎ ﻓﻲ ﺫﻟﻚ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ‪،‬‬ ‫‪-‬‬

‫ﻭﺗﺴﺠﻴﻞﺍﻟﺨﺮﻭﺝ‪ ،‬ﻭﺗﻐﻴﻴﺮ ﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ‪ ،‬ﻭﺇﻋﺎﺩﺓ ﺿﺒﻄﻬﺎ‪ ،‬ﻭﺗﻌﻠﻴﻖ ﺍﻟﺤﺴﺎﺏ‪ ،‬ﻭﺍﺳﺘﺮﺩﺍﺩﻩ‪.‬‬

‫ﻭﻳﺠﺐﺗﺴﺠﻴﻞ ﻛﻞ ٍّﻣﻦ ﺍﻟﻤﺤﺎﻭﻻﺕ ﺍﻟﻔﺎﺷﻠﺔ ﻭﺍﻟﻨﺎﺟﺤﺔ‪ ،‬ﻋﻨﺪ ﺍﻻﻗﺘﻀﺎء‪ .‬ﻳﺠﺐ ﺃﻥ ﺗﺘﻀﻤﻦ‬
‫ﺍﻟﺴﺠﻼﺕﺟﻤﻴﻊ ﺍﻟﺘﻔﺎﺻﻴﻞ ﺫﺍﺕ ﺍﻟﺼﻠﺔ )ﻣﺜﻞ ﺍﺳﻢ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻭﻋﻨﻮﺍﻥ ‪ ،(IP‬ﻭﻟﻜﻦ ﺩﻭﻥ ﺃﻱ‬
‫ﺃﺳﺮﺍﺭﺃﻣﻨﻴﺔ )ﻣﺜﻞ ﻛﻠﻤﺎﺕ ﺍﻟﻤﺮﻭﺭ(‪ .‬ﻳﺠﺐ ﺣﻤﺎﻳﺔ ﺍﻟﺴﺠﻼﺕ ﺑﺸﺪﺓ ﻣﻦ ﺍﻟﻮﺻﻮﻝ ﻏﻴﺮ ﺍﻟﻤﺼﺮﺡ‬
‫ﺑﻪ‪،‬ﻷﻧﻬﺎ ﺗﺸُﻜﻞِّ ﻣﺼﺪﺭﺍً ﺭﺉﻴﺴﻴﺎً ﻟﺘﺴﺮﻳﺐ ﺍﻟﻤﻌﻠﻮﻣﺎﺕ‪.‬‬

‫ﻳﺠﺐﻣﻌﺎﻟﺠﺔ ﺃﻱ ﺷﺬﻭﺫ ﻓﻲ ﺃﺣﺪﺍﺙ ﺍﻟﻤﺼﺎﺩﻗﺔ ﻣﻦ ﺧﻼﻝ ﺧﺎﺻﻴﺔ ﺍﻟﺘﻨﺒﻴﻪ ﺍﻟﻔﻮﺭﻱ ﻭﻣﻨﻊ‬ ‫‪-‬‬

‫ﺍﻟﺘﻄﻔﻞﻓﻲ ﺍﻟﺘﻄﺒﻴﻖ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﻳﺠﺐ ﺗﻮﻋﻴﺔ ﻣﺴﺆﻭﻟﻲ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺑﺎﻷﻧﻤﺎﻁ ﺍﻟﺘﻲ‬
‫ﺗﺸﻴﺮﺇﻟﻰ ﻫﺠﻤﺎﺕ ﺍﻟﻘﻮﺓ ﺍﻟﻐﺎﺷﻤﺔ ﻻﺗﺨﺎﺫ ﺍﻟﺘﺪﺍﺑﻴﺮ ﺍﻟﺪﻓﺎﻋﻴﺔ ﻭﺍﻟﻬﺠﻮﻣﻴﺔ ﺍﻟﻤﻨﺎﺳﺒﺔ‪.‬‬

‫ﻳﺠﺐﺇﺧﻄﺎﺭ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺧﺎﺭﺝ ﻧﻄﺎﻕ ﺍﻟﺘﻐﻄﻴﺔ ﺑﺄﻱ ﺃﺣﺪﺍﺙ ﺃﻣﻨﻴﺔ ﺣﺮﺟﺔ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ‬ ‫‪-‬‬

‫ﺍﻟﻤﺜﺎﻝ‪،‬ﻳﺠﺐ ﻋﻠﻰ ﺍﻟﺘﻄﺒﻴﻖ ﺇﺭﺳﺎﻝ ﺭﺳﺎﻟﺔ ﺇﻟﻰ ﻋﻨﻮﺍﻥ ﺍﻟﺒﺮﻳﺪ ﺍﻹﻟﻜﺘﺮﻭﻧﻲ ﺍﻟﻤﺴﺠﻞ ﻟﻠﻤﺴﺘﺨﺪﻡ‬
‫ﻋﻨﺪﺗﻐﻴﻴﺮ ﻛﻠﻤﺔ ﻣﺮﻭﺭﻩ‪.‬‬
‫ﻳﺠﺐﺇﺧﻄﺎﺭ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺿﻤﻦ ﺍﻟﻨﻄﺎﻕ ﺑﺎﻷﺣﺪﺍﺙ ﺍﻷﻣﻨﻴﺔ ﺍﻟﻤﺘﻜﺮﺭﺓ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪،‬‬ ‫‪-‬‬

‫ﺑﻌﺪﺗﺴﺠﻴﻞ ﺩﺧﻮﻝ ﻧﺎﺟﺢ‪ ،‬ﻳﺠﺐ ﻋﻠﻰ ﺍﻟﺘﻄﺒﻴﻖ ﺇﺑﻼﻍ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺑﻮﻗﺖ ﻭﻋﻨﻮﺍﻥ ‪/IP‬‬
‫ﺍﻟﻨﻄﺎﻕﺍﻟﻤﺼﺪﺭ ﻵﺧﺮ ﺗﺴﺠﻴﻞ ﺩﺧﻮﻝ‪ ،‬ﻭﻋﺪﺩ ﻣﺤﺎﻭﻻﺕ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﻏﻴﺮ ﺍﻟﺼﺤﻴﺤﺔ ﺍﻟﺘﻲ‬
‫ﺗﻤﺖﻣﻨﺬ ﺫﻟﻚ ﺍﻟﺤﻴﻦ‪ .‬ﺇﺫﺍ ﻋﻠﻢ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺃﻥ ﺣﺴﺎﺑﻪ ﻳﺘﻌﺮﺽ ﻟﻬﺠﻮﻡ ﺗﺨﻤﻴﻦ ﻛﻠﻤﺔ ﻣﺮﻭﺭ‪،‬‬
‫ﻓﻤﻦﺍﻟﻤﺮﺟﺢ ﺃﻥ ﻳﻐﻴﺮ ﻛﻠﻤﺔ ﻣﺮﻭﺭﻩ ﺑﺸﻜﻞ ﻣﺘﻜﺮﺭ ﻭﻳﻀﺒﻄﻬﺎ ﻋﻠﻰ ﻗﻴﻤﺔ ﻗﻮﻳﺔ‪.‬‬

‫ﻣﻠﺨﺺ‬
‫ﺭﺑﻤﺎﺗﻜﻮﻥ ﻭﻇﺎﺉﻒ ﺍﻟﻤﺼﺎﺩﻗﺔ ﺍﻟﻬﺪﻑ ﺍﻷﺑﺮﺯ ﻓﻲ ﺃﻱ ﺗﻄﺒﻴﻖ ﻧﻤﻮﺫﺟﻲ ﻟﻠﻬﺠﻮﻡ‪ .‬ﻓﺒﺤﻜﻢ ﺍﻟﺘﻌﺮﻳﻒ‪،‬‬
‫ﻳﻤُﻜﻦﺍﻟﻮﺻﻮﻝ ﺇﻟﻴﻬﺎ ﻣﻦ ﻗﺒِﻞ ﻣﺴﺘﺨﺪﻣﻴﻦ ﻣﺠﻬﻮﻟﻴﻦ ﻭﻏﻴﺮ ﻣﺨﻮﻟﻴﻦ‪ .‬ﻭﻓﻲ ﺣﺎﻝ ﺗﻌﻄﻠﻬﺎ‪ ،‬ﺗﺘُﻴﺢ‬
‫ﺍﻟﻮﺻﻮﻝﺇﻟﻰ ﻭﻇﺎﺉﻒ ﻣﺤﻤﻴﺔ ﻭﺑﻴﺎﻧﺎﺕ ﺣﺴﺎﺳﺔ‪ .‬ﻭﻫﻲ ﺗﺸُﻜﻞ ﺟﻮﻫﺮ ﺁﻟﻴﺎﺕ ﺍﻷﻣﺎﻥ ﺍﻟﺘﻲ ﻳﺴﺘﺨﺪﻣﻬﺎ‬
‫ﺍﻟﺘﻄﺒﻴﻖﻟﻠﺪﻓﺎﻉ ﻋﻦ ﻧﻔﺴﻪ‪ ،‬ﻭﺗﻤُﺜﻞ ﺧﻂ ﺍﻟﺪﻓﺎﻉ ﺍﻷﻭﻝ ﺿﺪ ﺍﻟﻮﺻﻮﻝ ﻏﻴﺮ ﺍﻟﻤﺼﺮﺡ ﺑﻪ‪.‬‬

‫ﺗﺤﺘﻮﻱﺁﻟﻴﺎﺕ ﺍﻟﻤﺼﺎﺩﻗﺔ ﺍﻟﻔﻌﻠﻴﺔ ﻋﻠﻰ ﺍﻟﻌﺪﻳﺪ ﻣﻦ ﻋﻴﻮﺏ ﺍﻟﺘﺼﻤﻴﻢ ﻭﺍﻟﺘﻨﻔﻴﺬ‪ .‬ﻳﺘﻄﻠﺐ ﺍﻟﺘﺼﺪﻱ‬
‫ﺍﻟﻔﻌﺎﻝﻟﻬﺎ ﺍﺗﺒﺎﻉ ﻣﻨﻬﺠﻴﺔ ﻣﻨﻈﻤﺔ‪ ،‬ﺑﺎﺳﺘﺨﺪﺍﻡ ﻣﻨﻬﺠﻴﺔ ﻣﻨﻈﻤﺔ ﻟﺘﺠﺎﻭﺯ ﺟﻤﻴﻊ ﺳﺒﻞ ﺍﻟﻬﺠﻮﻡ ﺍﻟﻤﻤﻜﻨﺔ‪.‬‬
‫ﻓﻲﻛﺜﻴﺮ ﻣﻦ ﺍﻟﺤﺎﻻﺕ‪ ،‬ﺗﻈﻬﺮ ﺃﻫﺪﺍﻑ ﻭﺍﺿﺤﺔ ‪ -‬ﻛﻠﻤﺎﺕ ﻣﺮﻭﺭ ﺧﺎﻃﺉﺔ‪ ،‬ﻭﻃﺮﻕ ﻟﻤﻌﺮﻓﺔ ﺃﺳﻤﺎء‬
‫ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ‪،‬ﻭﻗﺎﺑﻠﻴﺔ ﻟﻠﺘﻌﺮﺽ ﻟﻬﺠﻤﺎﺕ ﺍﻟﻘﻮﺓ ﺍﻟﻐﺎﺷﻤﺔ‪ .‬ﻣﻦ ﻧﺎﺣﻴﺔ ﺃﺧﺮﻯ‪ ،‬ﻗﺪ ﻳﻜﻮﻥ ﻣﻦ ﺍﻟﺼﻌﺐ‬
‫ﺟﺪﺍًﺍﻛﺘﺸﺎﻑ ﺍﻟﻌﻴﻮﺏ‪ .‬ﻭﻗﺪ ﺗﺘﻄﻠﺐ ﻓﺤﺼﺎً ﺩﻗﻴﻘﺎً ﻟﻌﻤﻠﻴﺔ ﺗﺴﺠﻴﻞ ﺩﺧﻮﻝ ﻣﻌﻘﺪﺓ ﻟﺘﺤﺪﻳﺪ‬
‫ﺍﻻﻓﺘﺮﺍﺿﺎﺕﺍﻟﺘﻲ‪...‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺩﺱ‪-‬ﻣﻬﺎﺟﻤﺔ ﺍﻟﻤﺼﺎﺩﻗﺔ‬ ‫‪202‬‬

‫ﺗﻢﺗﺼﻤﻴﻢ ﻫﺬﺍ ﺍﻟﺪﻟﻴﻞ ﻟﻤﺴﺎﻋﺪﺗﻚ ﻓﻲ ﺍﻛﺘﺸﺎﻑ ﺍﻟﺨﻠﻞ ﺍﻟﻤﻨﻄﻘﻲ ﺍﻟﺪﻗﻴﻖ ﺍﻟﺬﻱ ﻳﻤﻜﻦ ﺍﺳﺘﻐﻼﻟﻪ‬
‫ﻟﻠﺪﺧﻮﻝﻣﺒﺎﺷﺮﺓ ﻋﺒﺮ ﺍﻟﺒﺎﺏ‪.‬‬
‫ﺃﻫﻢﺩﺭﺱ ﻋﻨﺪ ﻣﻬﺎﺟﻤﺔ ﻭﻇﻴﻔﺔ ﺍﻟﻤﺼﺎﺩﻗﺔ ﻫﻮ ﺍﻟﺒﺤﺚ ﻓﻲ ﻛﻞ ﻣﻜﺎﻥ‪ .‬ﻓﺒﺎﻹﺿﺎﻓﺔ ﺇﻟﻰ ﻧﻤﻮﺫﺝ‬
‫ﺗﺴﺠﻴﻞﺍﻟﺪﺧﻮﻝ ﺍﻟﺮﺉﻴﺴﻲ‪ ،‬ﻗﺪ ﺗﻮﺟﺪ ﻭﻇﺎﺉﻒ ﻟﺘﺴﺠﻴﻞ ﺣﺴﺎﺑﺎﺕ ﺟﺪﻳﺪﺓ‪ ،‬ﻭﺗﻐﻴﻴﺮ ﻛﻠﻤﺎﺕ ﺍﻟﻤﺮﻭﺭ‪،‬‬
‫ﻭﺗﺬﻛﺮﻫﺎ‪،‬ﻭﺍﺳﺘﻌﺎﺩﺓ ﻛﻠﻤﺎﺕ ﺍﻟﻤﺮﻭﺭ ﺍﻟﻤﻨﺴﻴﺔ‪ ،‬ﻭﺍﻧﺘﺤﺎﻝ ﻫﻮﻳﺔ ﻣﺴﺘﺨﺪﻣﻴﻦ ﺁﺧﺮﻳﻦ‪ .‬ﻛﻞ ٌّﻣﻨﻬﺎ ﻳﻤُﺜﻞ‬
‫ﻫﺪﻓﺎًﻏﻨﻴﺎً ﺑﺎﻟﻌﻴﻮﺏ ﺍﻟﻤﺤﺘﻤﻠﺔ‪ ،‬ﻭﺍﻟﻤﺸﺎﻛﻞ ﺍﻟﺘﻲ ﺗﻢ ﺍﻟﺘﺨﻠﺺ ﻣﻨﻬﺎ ﻋﻤﺪﺍً ﻓﻲ ﻭﻇﻴﻔﺔ ﻭﺍﺣﺪﺓ ﻏﺎﻟﺒﺎً ﻣﺎ‬
‫ﺗﻈﻬﺮﻓﻲ ﻭﻇﺎﺉﻒ ﺃﺧﺮﻯ‪ .‬ﺍﺳﺘﺜﻤﺮ ﻭﻗﺘﺎً ﻓﻲ ﺍﻟﺘﺪﻗﻴﻖ ﻭﺍﻟﺒﺤﺚ ﻓﻲ ﻛﻞ ﺷﺒﺮ ﻣﻦ ﻧﻘﺎﻁ ﺍﻟﻀﻌﻒ ﺍﻟﺘﻲ‬
‫ﺗﺠﺪﻫﺎ‪،‬ﻭﻗﺪ ﺗﻜﻮﻥ ﻣﻜﺎﻓﺂﺗﻚ ﻛﺒﻴﺮﺓ‪.‬‬

‫ﺃﺳﺉﻠﺔ‬

‫ﻳﻤﻜﻦﺍﻟﻌﺜﻮﺭ ﻋﻠﻰ ﺍﻹﺟﺎﺑﺎﺕ ﻓﻲ‪http://mdsec.net/wahh.‬‬

‫‪.1‬ﺃﺛﻨﺎء ﺍﺧﺘﺒﺎﺭ ﺗﻄﺒﻴﻖ ﻭﻳﺐ‪ ،‬ﻳﻤﻜﻨﻚ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺑﻴﺎﻧﺎﺕ ﺍﻻﻋﺘﻤﺎﺩ ﺍﻟﺨﺎﺻﺔ ﺑﻚﺟﻮ‬
‫ﻭﻳﻤﺮ‪.‬ﺃﺛﻨﺎء ﻋﻤﻠﻴﺔ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ‪ ،‬ﺳﺘﺮﻯ ﻃﻠﺒﺎً ﻟﻌﻨﻮﺍﻥ ‪ URL‬ﺍﻟﺘﺎﻟﻲ ﻳﻈﻬﺮ ﻓﻲ ﺍﻟﻮﻛﻴﻞ‬
‫ﺍﻟﻤﻌﺘﺮﺽﺍﻟﺨﺎﺹ ﺑﻚ‪:‬‬
‫‪http://www.wahh-app.com/app?action=login&uname=joe&password=pass‬‬

‫ﻣﺎﻫﻲ ﻧﻘﺎﻁ ﺍﻟﻀﻌﻒ ﺍﻟﺜﻼﺛﺔ ﺍﻟﺘﻲ ﻳﻤﻜﻨﻚ ﺗﺸﺨﻴﺼﻬﺎ ﺩﻭﻥ ﺇﺟﺮﺍء ﺃﻱ ﻓﺤﺺ ﺇﺿﺎﻓﻲ؟‬
‫‪.٢‬ﻛﻴﻒ ﻳﻤُﻜﻦ ﺃﻥ ﺗﺴُﺒﺐ ﻭﻇﺎﺉﻒ ﺍﻟﺘﺴﺠﻴﻞ ﺍﻟﺬﺍﺗﻲ ﺛﻐﺮﺍﺕ ٍﻓﻲ ﺗﻌﺪﺍﺩ ﺃﺳﻤﺎء ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ؟‬
‫ﻭﻛﻴﻒﻳﻤُﻜﻦ ﺗﺠﻨﺐّ ﻫﺬﻩ ﺍﻟﺜﻐﺮﺍﺕ؟‬
‫‪.3‬ﺗﺘﻀﻤﻦ ﺁﻟﻴﺔ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﺍﻟﺨﻄﻮﺍﺕ ﺍﻟﺘﺎﻟﻴﺔ‪:‬‬

‫)ﺃ( ﻳﻄﻠﺐ ﺍﻟﺘﻄﺒﻴﻖ ﺍﺳﻢ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻭﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ ﺍﻟﺨﺎﺻﺔ ﺑﺎﻟﻤﺴﺘﺨﺪﻡ‪.‬‬

‫)ﺏ( ﻳﻄﻠﺐ ﺍﻟﺘﻄﺒﻴﻖ ﺣﺮﻓﻴﻦ ﻳﺘﻢ ﺍﺧﺘﻴﺎﺭﻫﻤﺎ ﻋﺸﻮﺍﺉﻴﺎً ﻣﻦ ﺍﻟﻜﻠﻤﺔ ﺍﻟﺘﻲ ﻳﺘﺬﻛﺮﻫﺎ ﺍﻟﻤﺴﺘﺨﺪﻡ‪.‬‬

‫ﻟﻤﺎﺫﺍﺗﻄُﻠﺐ ﺍﻟﻤﻌﻠﻮﻣﺎﺕ ﺍﻟﻤﻄﻠﻮﺑﺔ ﻋﻠﻰ ﺧﻄﻮﺗﻴﻦ ﻣﻨﻔﺼﻠﺘﻴﻦ؟ ﻣﺎ ﺍﻟﻌﻴﺐ ﺍﻟﺬﻱ ﻗﺪ ﻳﺸﻮﺏ‬

‫ﺍﻵﻟﻴﺔﻟﻮ ﻟﻢ ﻳﻜﻦ ﺍﻷﻣﺮ ﻛﺬﻟﻚ؟‬
‫‪.٤‬ﺗﻄﻠﺐ ﺁﻟﻴﺔ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﻣﺘﻌﺪﺩﺓ ﺍﻟﻤﺮﺍﺣﻞ ﺍﺳﻢ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺃﻭﻻ‪ ً،‬ﺛﻢ ﻋﻨﺎﺻﺮ ﺃﺧﺮﻯ ﻣﺨﺘﻠﻔﺔ‬
‫ﻋﺒﺮﻣﺮﺍﺣﻞ ﻣﺘﺘﺎﻟﻴﺔ‪ .‬ﺇﺫﺍ ﻛﺎﻥ ﺃﻱ ﻋﻨﺼﺮ ﻣﺪُﺧﻞ ﻏﻴﺮ ﺻﺎﻟﺢ‪ ،‬ﻳﻌُﺎﺩ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻓﻮﺭﺍً ﺇﻟﻰ ﺍﻟﻤﺮﺣﻠﺔ‬
‫ﺍﻷﻭﻟﻰ‪.‬‬
‫ﻣﺎﻫﻮ ﺍﻟﺨﻄﺄ ﻓﻲ ﻫﺬﻩ ﺍﻵﻟﻴﺔ‪ ،‬ﻭﻛﻴﻒ ﻳﻤﻜﻦ ﺗﺼﺤﻴﺢ ﻫﺬﻩ ﺍﻟﺜﻐﺮﺓ؟‬

‫‪.٥‬ﻳﺪُﻣﺞ ﺗﻄﺒﻴﻖ ٌﺁﻟﻴﺔ ًﻟﻤﻜﺎﻓﺤﺔ ﺍﻟﺘﺼﻴﺪ ﺍﻻﺣﺘﻴﺎﻟﻲ ﻓﻲ ﺧﺎﺻﻴﺔ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ‪ .‬ﺃﺛﻨﺎء ﺍﻟﺘﺴﺠﻴﻞ‪،‬‬
‫ﻳﺨﺘﺎﺭﻛﻞ ﻣﺴﺘﺨﺪﻡ ﺻﻮﺭﺓ ًﻣﺤُﺪﺩﺓ ًﻣﻦ ﻣﺠﻤﻮﻋﺔ ٍﻛﺒﻴﺮﺓ ٍﻣﻦ ﺍﻟﺼﻮﺭ ﺍﻟﺘﻲ ﻳﻘُﺪﻣّﻬﺎ ﺍﻟﺘﻄﺒﻴﻖ‪.‬‬
‫ﺗﺘﻀﻤﻦﺧﺎﺻﻴﺔ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﺍﻟﺨﻄﻮﺍﺕ ﺍﻟﺘﺎﻟﻴﺔ‪:‬‬

‫)ﺃ( ﻳﻘﻮﻡ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺑﺈﺩﺧﺎﻝ ﺍﺳﻢ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻭﺗﺎﺭﻳﺦ ﻣﻴﻼﺩﻩ‪.‬‬

‫‪203‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺩﺱ‪-‬ﻣﻬﺎﺟﻤﺔ ﺍﻟﻤﺼﺎﺩﻗﺔ‬

‫)ﺏ( ﺇﺫﺍ ﻛﺎﻧﺖ ﻫﺬﻩ ﺍﻟﺘﻔﺎﺻﻴﻞ ﺻﺤﻴﺤﺔ‪ ،‬ﻳﻌﺮﺽ ﺍﻟﺘﻄﺒﻴﻖ ﻟﻠﻤﺴﺘﺨﺪﻡ ﺍﻟﺼﻮﺭﺓ ﺍﻟﺘﻲ ﺍﺧﺘﺎﺭﻫﺎ؛‬
‫ﻭﺇﻻ‪،‬ﻳﺘﻢ ﻋﺮﺽ ﺻﻮﺭﺓ ﻋﺸﻮﺍﺉﻴﺔ‪.‬‬
‫)ﺝ( ﻳﺘﺤﻘﻖ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻣﻦ ﻋﺮﺽ ﺍﻟﺼﻮﺭﺓ ﺍﻟﺼﺤﻴﺤﺔ‪ .‬ﻓﻲ ﺣﺎﻝ ﻇﻬﻮﺭﻫﺎ‪ ،‬ﻳﺪُﺧﻞ ﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ‪.‬‬

‫ﺍﻟﻔﻜﺮﺓﻭﺭﺍء ﺁﻟﻴﺔ ﻣﻜﺎﻓﺤﺔ ﺍﻟﺘﺼﻴﺪ ﻫﺬﻩ ﻫﻲ ﺃﻧﻬﺎ ﺗﻤﻜﻦ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻣﻦ ﺍﻟﺘﺄﻛﺪ ﻣﻦ ﺃﻧﻪ ﻳﺘﻌﺎﻣﻞ‬
‫ﻣﻊﺍﻟﺘﻄﺒﻴﻖ ﺍﻷﺻﻠﻲ‪ ،‬ﻭﻟﻴﺲ ﻧﺴﺨﺔ ﻃﺒﻖ ﺍﻷﺻﻞ‪ ،‬ﻷﻥ ﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﺤﻘﻴﻘﻲ ﻓﻘﻂ ﻳﻌﺮﻑ‬
‫ﺍﻟﺼﻮﺭﺓﺍﻟﺼﺤﻴﺤﺔ ﺍﻟﺘﻲ ﻳﺠﺐ ﻋﺮﺿﻬﺎ ﻟﻠﻤﺴﺘﺨﺪﻡ‪.‬‬

‫ﻣﺎﻫﻲ ﺍﻟﺜﻐﺮﺓ ﺍﻟﺘﻲ ﺗﺪُﺧﻠﻬﺎ ﺁﻟﻴﺔ ﻣﻜﺎﻓﺤﺔ ﺍﻟﺘﺼﻴﺪ ﺍﻻﺣﺘﻴﺎﻟﻲ ﻫﺬﻩ ﻓﻲ ﻭﻇﻴﻔﺔ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ؟‬
‫ﻫﻞﻫﺬﻩ ﺍﻵﻟﻴﺔ ﻓﻌﺎّﻟﺔ ﻓﻲ ﻣﻨﻊ ﺍﻟﺘﺼﻴﺪ ﺍﻻﺣﺘﻴﺎﻟﻲ؟‬
 ‫ﺑﺘﺮ‬ ‫‪7‬‬ ‫ﺗﺸﺎ‬

‫ﺇﺩﺍﺭﺓ‬ ‫ﻫﺠﻮﻡﺟﻠﺴﺔ ﻣﺎﻧﺎ‬

‫ﺗﻌُﺪﺁﻟﻴﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ ﻋﻨﺼﺮﺍً ﺃﻣﻨﻴﺎً ﺃﺳﺎﺳﻴﺎً ﻓﻲ ﻣﻌﻈﻢ ﺗﻄﺒﻴﻘﺎﺕ ﺍﻟﻮﻳﺐ‪ .‬ﻓﻬﻲ ﺍﻟﺘﻲ ﺗﻤُﻜﻦّ ﺍﻟﺘﻄﺒﻴﻖ‬
‫ﻣﻦﺗﺤﺪﻳﺪ ﻫﻮﻳﺔ ﻣﺴﺘﺨﺪﻡ ﻣﻌﻴﻦ ﺑﺸﻜﻞ ﻓﺮﻳﺪ ﻋﺒﺮ ﻋﺪﺩ ﻣﻦ ﺍﻟﻄﻠﺒﺎﺕ ﺍﻟﻤﺨﺘﻠﻔﺔ‪ ،‬ﻭﻣﻌﺎﻟﺠﺔ ﺍﻟﺒﻴﺎﻧﺎﺕ‬
‫ﺍﻟﺘﻲﻳﺠﻤﻌﻬﺎ ﺣﻮﻝ ﺣﺎﻟﺔ ﺗﻔﺎﻋﻠﻪ ﻣﻊ ﺍﻟﺘﻄﺒﻴﻖ‪ .‬ﻋﻨﺪ ﺗﻄﺒﻴﻖ ﺧﺎﺻﻴﺔ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ‪ ،‬ﺗﻜﺘﺴﺐ ﺇﺩﺍﺭﺓ‬
‫ﺍﻟﺠﻠﺴﺔﺃﻫﻤﻴﺔ ﺧﺎﺻﺔ‪ ،‬ﻷﻧﻬﺎ ﺗﻤُﻜﻦّ ﺍﻟﺘﻄﺒﻴﻖ ﻣﻦ ﺍﻟﺤﻔﺎﻅ ﻋﻠﻰ ﺗﺄﻛﻴﺪﻩ ﻟﻬﻮﻳﺔ ﺃﻱ ﻣﺴﺘﺨﺪﻡ ﺑﻌﺪ‬
‫ﺍﻟﻄﻠﺐﺍﻟﺬﻱ ﻳﻘُﺪﻡ ﻓﻴﻪ ﺑﻴﺎﻧﺎﺕ ﺍﻋﺘﻤﺎﺩﻩ‪.‬‬

‫ﻧﻈﺮﺍ ًﻟﻠﺪﻭﺭ ﺍﻟﻤﺤﻮﺭﻱ ﺍﻟﺬﻱ ﺗﻠﻌﺒﻪ ﺁﻟﻴﺎﺕ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺎﺕ‪ ،‬ﻓﻬﻲ ﺗﻌُﺪ ّﻫﺪﻓﺎ ًﺭﺉﻴﺴﻴﺎ ًﻟﻠﻬﺠﻤﺎﺕ‬
‫ﺍﻟﺨﺒﻴﺜﺔﻋﻠﻰ ﺍﻟﺘﻄﺒﻴﻖ‪ .‬ﺇﺫﺍ ﺗﻤﻜﻦ ﻣﻬﺎﺟﻢ ﻣﻦ ﺍﺧﺘﺮﺍﻕ ﺇﺩﺍﺭﺓ ﺟﻠﺴﺎﺕ ﺍﻟﺘﻄﺒﻴﻖ‪ ،‬ﻓﺴﻴﺘﻤﻜﻦ ﻣﻦ ﺗﺠﺎﻭﺯ‬
‫ﺿﻮﺍﺑﻂﺍﻟﻤﺼﺎﺩﻗﺔ ﻭﺍﻟﺘﻨﻜﺮ ﻛﻤﺴﺘﺨﺪﻣﻲ ﺗﻄﺒﻴﻖ ﺁﺧﺮﻳﻦ ﺩﻭﻥ ﻣﻌﺮﻓﺔ ﺑﻴﺎﻧﺎﺕ ﺍﻋﺘﻤﺎﺩﻫﻢ‪ .‬ﺇﺫﺍ ﺍﺧﺘﺮﻕ‬
‫ﻣﻬﺎﺟﻢﻣﺴﺘﺨﺪﻣﺎ ًﺇﺩﺍﺭﻳﺎ ًﺑﻬﺬﻩ ﺍﻟﻄﺮﻳﻘﺔ‪ ،‬ﻓﺴﻴﺘﻤﻜﻦ ﻣﻦ ﺍﻣﺘﻼﻙ ﺍﻟﺘﻄﺒﻴﻖ ﺑﺄﻛﻤﻠﻪ‪.‬‬

‫ﻛﻤﺎﻫﻮ ﺍﻟﺤﺎﻝ ﻣﻊ ﺁﻟﻴﺎﺕ ﺍﻟﻤﺼﺎﺩﻗﺔ‪ ،‬ﻏﺎﻟﺒﺎً ﻣﺎ ﺗﻮﺟﺪ ﻋﻴﻮﺏ ﻣﺘﻨﻮﻋﺔ ﻓﻲ ﻭﻇﺎﺉﻒ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺎﺕ‪.‬‬
‫ﻓﻲﺍﻟﺤﺎﻻﺕ ﺍﻷﻛﺜﺮ ﺿﻌﻔﺎً‪ ،‬ﻳﻜﻔﻲ ﺍﻟﻤﻬﺎﺟﻢ ﺯﻳﺎﺩﺓ ﻗﻴﻤﺔ ﺍﻟﺮﻣﺰ ﺍﻟﺬﻱ ﺃﺻﺪﺭﻩ ﻟﻪ ﺍﻟﺘﻄﺒﻴﻖ ﻟﺘﻐﻴﻴﺮ ﺳﻴﺎﻗﻪ‬
‫ﺇﻟﻰﺳﻴﺎﻕ ﻣﺴﺘﺨﺪﻡ ﺁﺧﺮ‪ .‬ﻓﻲ ﻫﺬﻩ ﺍﻟﺤﺎﻟﺔ‪ ،‬ﻳﻜﻮﻥ ﺍﻟﺘﻄﺒﻴﻖ ﻣﻔﺘﻮﺣﺎً ﻟﻠﺠﻤﻴﻊ ﻟﻠﻮﺻﻮﻝ ﺇﻟﻰ ﺟﻤﻴﻊ‬
‫ﺟﻮﺍﻧﺒﻪ‪.‬ﻓﻲ ﺍﻟﻤﻘﺎﺑﻞ‪ ،‬ﻗﺪ ﻳﻀﻄﺮ ﺍﻟﻤﻬﺎﺟﻢ ﺇﻟﻰ ﺑﺬﻝ ﺟﻬﺪ ﻛﺒﻴﺮ‪ ،‬ﻭﻓﻚ ّﺗﺸﻔﻴﺮ ﻃﺒﻘﺎﺕ ﻣﺘﻌﺪﺩﺓ ﻣﻦ‬
‫ﺍﻟﺘﻌﺘﻴﻢ‪،‬ﻭﺗﺼﻤﻴﻢ ﻫﺠﻮﻡ ﺁﻟﻲ ﻣﺘﻄﻮﺭ‪ ،‬ﻗﺒﻞ ﺃﻥ ﻳﺠﺪ ﺛﻐﺮﺓ ﻓﻲ ﺩﺭﻉ ﺍﻟﺘﻄﺒﻴﻖ‪.‬‬

‫‪205‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬ ‫‪206‬‬

‫ﻳﺘﻨﺎﻭﻝﻫﺬﺍ ﺍﻟﻔﺼﻞ ﺟﻤﻴﻊ ﺃﻧﻮﺍﻉ ﻧﻘﺎﻁ ﺍﻟﻀﻌﻒ ﺍﻟﺘﻲ ﻭﺍﺟﻬﻬﺎ ﺍﻟﻤﺆﻟﻔﻮﻥ ﻓﻲ ﺗﻄﺒﻴﻘﺎﺕ ﺍﻟﻮﻳﺐ‬
‫ﺍﻟﻌﻤﻠﻴﺔ‪.‬ﻭﻳﻮﺿﺢ ﺑﺎﻟﺘﻔﺼﻴﻞ ﺍﻟﺨﻄﻮﺍﺕ ﺍﻟﻌﻤﻠﻴﺔ ﺍﻟﻼﺯﻣﺔ ﻻﻛﺘﺸﺎﻑ ﻫﺬﻩ ﺍﻟﻌﻴﻮﺏ ﻭﺍﺳﺘﻐﻼﻟﻬﺎ‪ .‬ﻭﺃﺧﻴﺮﺍً‪،‬‬
‫ﻳﺼﻒﺍﻟﺘﺪﺍﺑﻴﺮ ﺍﻟﺪﻓﺎﻋﻴﺔ ﺍﻟﺘﻲ ﻳﻨﺒﻐﻲ ﻟﻠﺘﻄﺒﻴﻘﺎﺕ ﺍﺗﺨﺎﺫﻫﺎ ﻟﺤﻤﺎﻳﺔ ﻧﻔﺴﻬﺎ ﻣﻦ ﻫﺬﻩ ﺍﻟﻬﺠﻤﺎﺕ‪.‬‬

‫ﺃﺳﻄﻮﺭﺓﺷﺎﺉﻌﺔ‬

‫"ﻧﺤﻦ ﻧﺴﺘﺨﺪﻡ ﺍﻟﺒﻄﺎﻗﺎﺕ ﺍﻟﺬﻛﻴﺔ ﻟﻠﻤﺼﺎﺩﻗﺔ‪ ،‬ﻭﻻ ﻳﻤﻜﻦ ﺍﺧﺘﺮﺍﻕ ﺟﻠﺴﺎﺕ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺑﺪﻭﻧﻬﺎ‪".‬‬

‫ﻣﻬﻤﺎﻛﺎﻧﺖ ﺁﻟﻴﺔ ﻣﺼﺎﺩﻗﺔ ﺍﻟﺘﻄﺒﻴﻖ ﻗﻮﻳﺔ‪ ،‬ﻓﺈﻥ ﻃﻠﺒﺎﺕ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺍﻟﻼﺣﻘﺔ ﻻ ﺗﺮﺗﺒﻂ ﺑﺘﻠﻚ‬
‫ﺍﻟﻤﺼﺎﺩﻗﺔﺇﻻ ﻋﺒﺮ ﺍﻟﺠﻠﺴﺔ ﺍﻟﻨﺎﺗﺠﺔ‪ .‬ﺇﺫﺍ ﻛﺎﻧﺖ ﺇﺩﺍﺭﺓ ﺟﻠﺴﺔ ﺍﻟﺘﻄﺒﻴﻖ ﺿﻌﻴﻔﺔ‪ ،‬ﻳﻤﻜﻦ ﻟﻠﻤﻬﺎﺟﻢ ﺗﺠﺎﻭﺯ‬
‫ﺍﻟﻤﺼﺎﺩﻗﺔﺍﻟﻘﻮﻳﺔ‪ ،‬ﻭﻣﻊ ﺫﻟﻚ‪ ،‬ﻳﻌُﺮﺽّ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﻟﻠﺨﻄﺮ‪.‬‬

‫ﺍﻟﺤﺎﺟﺔﺇﻟﻰ ﺍﻟﺪﻭﻟﺔ‬

‫ﺑﺮﻭﺗﻮﻛﻮﻝ‪ HTTP‬ﻋﺪﻳﻢ ﺍﻟﺠﻨﺴﻴﺔ ﺃﺳﺎﺳﺎً‪ .‬ﻓﻬﻮ ﻳﻌﺘﻤﺪ ﻋﻠﻰ ﻧﻤﻮﺫﺝ ﺑﺴﻴﻂ ﻟﻄﻠﺐ‪-‬ﺍﺳﺘﺠﺎﺑﺔ‪ ،‬ﺣﻴﺚ‬
‫ﻳﻤﺜﻞﻛﻞ ﺯﻭﺝ ﻣﻦ ﺍﻟﺮﺳﺎﺉﻞ ﻣﻌﺎﻣﻠﺔ ﻣﺴﺘﻘﻠﺔ‪ .‬ﻻ ﻳﺤﺘﻮﻱ ﺍﻟﺒﺮﻭﺗﻮﻛﻮﻝ ﻧﻔﺴﻪ ﻋﻠﻰ ﺁﻟﻴﺔ ﻟﺮﺑﻂ ﺳﻠﺴﻠﺔ‬
‫ﺍﻟﻄﻠﺒﺎﺕﺍﻟﺘﻲ ﻳﻘﺪﻣﻬﺎ ﻣﺴﺘﺨﺪﻡ ﻣﻌﻴﻦ ﻭﺗﻤﻴﻴﺰﻫﺎ ﻋﻦ ﺟﻤﻴﻊ ﺍﻟﻄﻠﺒﺎﺕ ﺍﻷﺧﺮﻯ ﺍﻟﺘﻲ ﻳﺘﻠﻘﺎﻫﺎ ﺧﺎﺩﻡ‬
‫ﺍﻟﻮﻳﺐ‪.‬ﻓﻲ ﺑﺪﺍﻳﺎﺕ ﺍﻹﻧﺘﺮﻧﺖ‪ ،‬ﻟﻢ ﺗﻜﻦ ﻫﻨﺎﻙ ﺣﺎﺟﺔ ﻟﻤﺜﻞ ﻫﺬﻩ ﺍﻵﻟﻴﺔ‪ :‬ﻛﺎﻧﺖ ﻣﻮﺍﻗﻊ ﺍﻟﻮﻳﺐ ﺗﺴُﺘﺨﺪﻡ‬
‫ﻟﻨﺸﺮﺻﻔﺤﺎﺕ ‪ HTML‬ﺛﺎﺑﺘﺔ ﻟﻴﺘﻤﻜﻦ ﺃﻱ ﺷﺨﺺ ﻣﻦ ﻣﺸﺎﻫﺪﺗﻬﺎ‪ .‬ﺃﻣﺎ ﺍﻟﻴﻮﻡ‪ ،‬ﻓﺎﻷﻣﺮ ﻣﺨﺘﻠﻒ ﺗﻤﺎﻣﺎً‪.‬‬

‫ﻣﻌﻈﻢﻣﻮﺍﻗﻊ ﺍﻟﻮﻳﺐ ﻫﻲ ﻓﻲ ﺍﻟﻮﺍﻗﻊ ﺗﻄﺒﻴﻘﺎﺕ ﻭﻳﺐ‪ .‬ﺗﺘﻴﺢ ﻟﻚ ﺍﻟﺘﺴﺠﻴﻞ ﻭﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ‪،‬‬

‫ﻭﺷﺮﺍءﻭﺑﻴﻊ ﺍﻟﺴﻠﻊ‪ ،‬ﻭﺣﻔﻆ ﺗﻔﻀﻴﻼﺗﻚ ﻋﻨﺪ ﺯﻳﺎﺭﺗﻚ ﺍﻟﻘﺎﺩﻣﺔ‪ .‬ﻛﻤﺎ ﺗﻘﺪﻡ ﺗﺠﺎﺭﺏ ﻭﺳﺎﺉﻂ ﻣﺘﻌﺪﺩﺓ‬
‫ﻏﻨﻴﺔﺑﻤﺤﺘﻮﻯ ﻣﻨُﺸﺄ ﺩﻳﻨﺎﻣﻴﻜﻴﺎً ﺑﻨﺎء ًﻋﻠﻰ ﻣﺎ ﺗﻨﻘﺮ ﻋﻠﻴﻪ ﻭﺗﻜﺘﺒﻪ‪ .‬ﻟﺘﻨﻔﻴﺬ ﺃﻱ ٍّﻣﻦ ﻫﺬﻩ ﺍﻟﻮﻇﺎﺉﻒ‪،‬‬
‫ﺗﺤﺘﺎﺝﺗﻄﺒﻴﻘﺎﺕ ﺍﻟﻮﻳﺐ ﺇﻟﻰ ﺍﺳﺘﺨﺪﺍﻡ ﻣﻔﻬﻮﻡ‪...‬ﺣﺼﺔ‪.‬‬

‫ﺍﻻﺳﺘﺨﺪﺍﻡﺍﻷﻛﺜﺮ ﻭﺿﻮﺣﺎً ﻟﻠﺠﻠﺴﺎﺕ ﻫﻮ ﻓﻲ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﻟﺘﻲ ﺗﺪﻋﻢ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ‪ .‬ﺑﻌﺪ ﺇﺩﺧﺎﻝ‬
‫ﺍﺳﻢﺍﻟﻤﺴﺘﺨﺪﻡ ﻭﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ‪ ،‬ﻳﻤﻜﻨﻚ ﺍﺳﺘﺨﺪﺍﻡ ﺍﻟﺘﻄﺒﻴﻖ ﺑﺎﺳﻢ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺍﻟﺬﻱ ﺃﺩﺧﻠﺖ ﺑﻴﺎﻧﺎﺕ‬
‫ﺍﻋﺘﻤﺎﺩﻩ‪،‬ﺣﺘﻰ ﺗﺴﺠﻴﻞ ﺍﻟﺨﺮﻭﺝ ﺃﻭ ﺍﻧﺘﻬﺎء ﺻﻼﺣﻴﺔ ﺍﻟﺠﻠﺴﺔ ﺑﺴﺒﺐ ﻋﺪﻡ ﺍﻟﻨﺸﺎﻁ‪ .‬ﺑﺪﻭﻥ ﺟﻠﺴﺔ‪،‬‬
‫ﺳﻴﻀﻄﺮﺍﻟﻤﺴﺘﺨﺪﻡ ﺇﻟﻰ ﺇﻋﺎﺩﺓ ﺇﺩﺧﺎﻝ ﻛﻠﻤﺔ ﻣﺮﻭﺭﻩ ﻓﻲ ﻛﻞ ﺻﻔﺤﺔ ﻣﻦ ﺻﻔﺤﺎﺕ ﺍﻟﺘﻄﺒﻴﻖ‪ .‬ﻟﺬﻟﻚ‪،‬‬
‫ﺑﻌﺪﻣﺼﺎﺩﻗﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻣﺮﺓ ﻭﺍﺣﺪﺓ‪ ،‬ﻳﻨُﺸﺊ ﺍﻟﺘﻄﺒﻴﻖ ﺟﻠﺴﺔ ﻟﻪ ﻭﻳﺘﻌﺎﻣﻞ ﻣﻊ ﺟﻤﻴﻊ ﺍﻟﻄﻠﺒﺎﺕ‬
‫ﺍﻟﻤﺘﻌﻠﻘﺔﺑﺘﻠﻚ ﺍﻟﺠﻠﺴﺔ ﻋﻠﻰ ﺃﻧﻬﺎ ﺻﺎﺩﺭﺓ ﻣﻨﻪ‪.‬‬

‫ﻋﺎﺩﺓ ًﻣﺎ ﺗﺤﺘﺎﺝ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﻟﺘﻲ ﻻ ﺗﺤﺘﻮﻱ ﻋﻠﻰ ﺧﺎﺻﻴﺔ ﺗﺴﺠﻴﻞ ﺩﺧﻮﻝ ﺇﻟﻰ ﺍﺳﺘﺨﺪﺍﻡ ﺍﻟﺠﻠﺴﺎﺕ‪.‬‬
‫ﺍﻟﻌﺪﻳﺪﻣﻦ ﻣﻮﺍﻗﻊ ﺑﻴﻊ ﺍﻟﺒﻀﺎﺉﻊ ﻻ ﺗﺸﺘﺮﻁ ﻋﻠﻰ ﺍﻟﻌﻤﻼء ﺇﻧﺸﺎء ﺣﺴﺎﺑﺎﺕ‪ .‬ﻣﻊ ﺫﻟﻚ‪ ،‬ﺗﺘﻴﺢ‬
‫ﻟﻠﻤﺴﺘﺨﺪﻣﻴﻦﺗﺼﻔﺢ ﺍﻟﻜﺘﺎﻟﻮﺝ‪ ،‬ﻭﺇﺿﺎﻓﺔ ﺍﻟﻤﻨﺘﺠﺎﺕ ﺇﻟﻰ ﺳﻠﺔ ﺍﻟﺘﺴﻮﻕ‪ ،‬ﻭﺗﻘﺪﻳﻢ ﺗﻔﺎﺻﻴﻞ ﺍﻟﺘﻮﺻﻴﻞ‪،‬‬
‫ﻭﺍﻟﺪﻓﻊ‪.‬ﻓﻲ ﻫﺬﻩ ﺍﻟﺤﺎﻟﺔ‪ ،‬ﻻ ﺣﺎﺟﺔ ﻟﻠﺘﺤﻘﻖ ﻣﻦ ﻫﻮﻳﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ‪ :‬ﻓﻔﻲ ﻣﻌﻈﻢ ﺯﻳﺎﺭﺍﺗﻪ‪ ،‬ﻻ ﻳﻌﺮﻑ‬
‫ﺍﻟﺘﻄﺒﻴﻖﻫﻮﻳﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻭﻻ ﻳﻬﺘﻢ ﺑﻬﺎ‪ .‬ﻭﻟﻜﻦ ﻟﻠﺘﻌﺎﻣﻞ ﻣﻌﻪ‪ ،‬ﻳﺤﺘﺎﺝ ﺇﻟﻰ ﻣﻌﺮﻓﺔ ﺳﻠﺴﻠﺔ ﺍﻟﻄﻠﺒﺎﺕ‬
‫ﺍﻟﺘﻲﻳﺘﻠﻘﺎﻫﺎ ﻭﺍﻟﺼﺎﺩﺭﺓ ﻣﻦ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻧﻔﺴﻪ‪.‬‬
‫‪207‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬

‫ﺃﺑﺴﻂﻭﺃﻛﺜﺮ ﺍﻟﻄﺮﻕ ﺷﻴﻮﻋﺎً ﻟﺘﻨﻔﻴﺬ ﺍﻟﺠﻠﺴﺎﺕ ﻫﻲ ﻣﻨﺢ ﻛﻞ ﻣﺴﺘﺨﺪﻡ ﺭﻣﺰ ﺟﻠﺴﺔ ﻓﺮﻳﺪﺍً ﺃﻭ ﻣﻌُﺮﻓّﺎً‪.‬‬
‫ﻓﻲﻛﻞ ﻃﻠﺐ ﻻﺣﻖ ﻟﻠﺘﻄﺒﻴﻖ‪ ،‬ﻳﻌُﻴﺪ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺇﺭﺳﺎﻝ ﻫﺬﺍ ﺍﻟﺮﻣﺰ‪ ،‬ﻣﻤﺎ ﻳﻤُﻜﻦّ ﺍﻟﺘﻄﺒﻴﻖ ﻣﻦ ﺗﺤﺪﻳﺪ‬
‫ﺗﺴﻠﺴﻞﺍﻟﻄﻠﺒﺎﺕ ﺍﻟﺴﺎﺑﻘﺔ ﺍﻟﺬﻱ ﻳﺘﻌﻠﻖ ﺑﻪ ﺍﻟﻄﻠﺐ ﺍﻟﺤﺎﻟﻲ‪.‬‬

‫ﻓﻲﻣﻌﻈﻢ ﺍﻟﺤﺎﻻﺕ‪ ،‬ﺗﺴﺘﺨﺪﻡ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﺭﺗﺒﺎﻁ ‪ HTTP‬ﻛﺂﻟﻴﺔ ﻧﻘﻞ ﻟﺘﻤﺮﻳﺮ ﺭﻣﻮﺯ‬
‫ﺍﻟﺠﻠﺴﺔﻫﺬﻩ ﺑﻴﻦ ﺍﻟﺨﺎﺩﻡ ﻭﺍﻟﻌﻤﻴﻞ‪ .‬ﺗﺤﺘﻮﻱ ﺍﺳﺘﺠﺎﺑﺔ ﺍﻟﺨﺎﺩﻡ ﺍﻷﻭﻟﻰ ﻟﻠﻌﻤﻴﻞ ﺍﻟﺠﺪﻳﺪ ﻋﻠﻰ ﺭﺃﺱ ‪HTTP‬‬
‫ﻛﻤﺎﻳﻠﻲ‪:‬‬
‫ﻣﺠﻤﻮﻋﺔﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ‪ASP.NET_SessionId=mza2ji454s04cwbgwb2ttj55 :‬‬

‫ﻭﺍﻟﻄﻠﺒﺎﺕﺍﻟﻼﺣﻘﺔ ﻣﻦ ﺍﻟﻌﻤﻴﻞ ﺗﺤﺘﻮﻱ ﻋﻠﻰ ﻫﺬﺍ ﺍﻟﻌﻨﻮﺍﻥ‪:‬‬

‫ﻣﻠﻒﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ‪ASP.NET_SessionId=mza2ji454s04cwbgwb2ttj55 :‬‬

‫ﺁﻟﻴﺔﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺎﺕ ﺍﻟﻘﻴﺎﺳﻴﺔ ﻫﺬﻩ ﺑﻄﺒﻴﻌﺘﻬﺎ ﻋﺮﺿﺔ ﻷﻧﻮﺍﻉ ﻣﺨﺘﻠﻔﺔ ﻣﻦ ﺍﻟﻬﺠﻤﺎﺕ‪ .‬ﺍﻟﻬﺪﻑ‬
‫ﺍﻟﺮﺉﻴﺴﻲﻟﻠﻤﻬﺎﺟﻢ ﻣﻦ ﺍﺳﺘﻬﺪﺍﻑ ﻫﺬﻩ ﺍﻵﻟﻴﺔ ﻫﻮ ﺍﺧﺘﺮﺍﻕ ﺟﻠﺴﺔ ﻣﺴﺘﺨﺪﻡ ﺷﺮﻋﻲ ﺑﻄﺮﻳﻘﺔ ﻣﺎ‪ ،‬ﻭﻣﻦ‬
‫ﺛﻢﺍﻧﺘﺤﺎﻝ ﺻﻔﺔ ﻫﺬﺍ ﺍﻟﻤﺴﺘﺨﺪﻡ‪ .‬ﺇﺫﺍ ﺗﻢ ﻣﺼﺎﺩﻗﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻋﻠﻰ ﺍﻟﺘﻄﺒﻴﻖ‪ ،‬ﻓﻘﺪ ﻳﺘﻤﻜﻦ ﺍﻟﻤﻬﺎﺟﻢ‬
‫ﻣﻦﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﺑﻴﺎﻧﺎﺗﻪ ﺍﻟﺨﺎﺻﺔ ﺃﻭ ﺗﻨﻔﻴﺬ ﺇﺟﺮﺍءﺍﺕ ﻏﻴﺮ ﻣﺼﺮﺡ ﺑﻬﺎ ﻧﻴﺎﺑﺔ ًﻋﻨﻪ‪ .‬ﺃﻣﺎ ﺇﺫﺍ ﻟﻢ ﻳﺘﻢ ﻣﺼﺎﺩﻗﺔ‬
‫ﺍﻟﻤﺴﺘﺨﺪﻡ‪،‬ﻓﻘﺪ ﻳﻈﻞ ﺍﻟﻤﻬﺎﺟﻢ ﻗﺎﺩﺭﺍً ﻋﻠﻰ ﺍﻻﻃﻼﻉ ﻋﻠﻰ ﺍﻟﻤﻌﻠﻮﻣﺎﺕ ﺍﻟﺤﺴﺎﺳﺔ ﺍﻟﺘﻲ ﺃﺭﺳﻠﻬﺎ‬
‫ﺍﻟﻤﺴﺘﺨﺪﻡﺃﺛﻨﺎء ﺟﻠﺴﺘﻪ‪.‬‬

‫ﻛﻤﺎﻓﻲ ﺍﻟﻤﺜﺎﻝ ﺍﻟﺴﺎﺑﻖ ﻟﺨﺎﺩﻡ ‪ Microsoft IIS‬ﻳﻌﻤﻞ ﺑﻨﻈﺎﻡ ‪ ،ASP.NET‬ﺗﻄُﺒﻖّ ﻣﻌﻈﻢ ﺧﻮﺍﺩﻡ‬
‫ﺍﻟﻮﻳﺐﺍﻟﺘﺠﺎﺭﻳﺔ ﻭﻣﻨﺼﺎﺕ ﺗﻄﺒﻴﻘﺎﺕ ﺍﻟﻮﻳﺐ ﺣﻠﻮﻻ ًﺟﺎﻫﺰﺓ ﻹﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺎﺕ ﺗﻌﺘﻤﺪ ﻋﻠﻰ ﻣﻠﻔﺎﺕ‬
‫ﺗﻌﺮﻳﻒﺍﺭﺗﺒﺎﻁ ‪ .HTTP‬ﻭﺗﻮﻓﺮ ﻫﺬﻩ ﺍﻟﺤﻠﻮﻝ ﻭﺍﺟﻬﺎﺕ ﺑﺮﻣﺠﺔ ﺗﻄﺒﻴﻘﺎﺕ )‪ (APIs‬ﻳﻤُﻜﻦ ﻟﻤﻄﻮﺭﻱ‬
‫ﺗﻄﺒﻴﻘﺎﺕﺍﻟﻮﻳﺐ ﺍﺳﺘﺨﺪﺍﻣﻬﺎ ﻟﺪﻣﺞ ﻭﻇﺎﺉﻔﻬﻢ ﺍﻟﺨﺎﺻﺔ ﺍﻟﻤﺮﺗﺒﻄﺔ ﺑﺎﻟﺠﻠﺴﺎﺕ ﻣﻊ ﻫﺬﺍ ﺍﻟﺤﻞ‪.‬‬

‫ﻭﺟُﺪﺃﻥ ﺑﻌﺾ ﺗﻄﺒﻴﻘﺎﺕ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺎﺕ ﺍﻟﺠﺎﻫﺰﺓ ﻋﺮﺿﺔ ﻟﻬﺠﻤﺎﺕ ﻣﺘﻨﻮﻋﺔ‪ ،‬ﻣﻤﺎ ﻳﺆﺩﻱ ﺇﻟﻰ‬
‫ﺍﺧﺘﺮﺍﻕﺟﻠﺴﺎﺕ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ )ﺳﻴﺘﻢ ﻣﻨﺎﻗﺸﺔ ﺫﻟﻚ ﻻﺣﻘﺎً ﻓﻲ ﻫﺬﺍ ﺍﻟﻔﺼﻞ(‪ .‬ﺇﺿﺎﻓﺔ ًﺇﻟﻰ ﺫﻟﻚ‪ ،‬ﻳﺮﻯ‬
‫ﺑﻌﺾﺍﻟﻤﻄﻮﺭﻳﻦ ﺃﻧﻬﻢ ﺑﺤﺎﺟﺔ ﺇﻟﻰ ﺗﺤﻜﻢ ﺃﺩﻕ ﻓﻲ ﺳﻠﻮﻙ ﺍﻟﺠﻠﺴﺎﺕ ﻣﻘﺎﺭﻧﺔ ًﺑﺎﻟﺤﻠﻮﻝ ﺍﻟﻤﺪﻣﺠﺔ‪ ،‬ﺃﻭ‬
‫ﻳﺮﻏﺒﻮﻥﻓﻲ ﺗﺠﻨﺐ ﺑﻌﺾ ﺍﻟﺜﻐﺮﺍﺕ ﺍﻷﻣﻨﻴﺔ ﺍﻟﻜﺎﻣﻨﺔ ﻓﻲ ﺍﻟﺤﻠﻮﻝ ﺍﻟﻘﺎﺉﻤﺔ ﻋﻠﻰ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ‬
‫ﺍﻻﺭﺗﺒﺎﻁ‪.‬ﻟﻬﺬﻩ ﺍﻷﺳﺒﺎﺏ‪ ،‬ﻣﻦ ﺍﻟﺸﺎﺉﻊ ﺍﺳﺘﺨﺪﺍﻡ ﺁﻟﻴﺎﺕ ﺇﺩﺍﺭﺓ ﺟﻠﺴﺎﺕ ﻣﺼﻤﻤﺔ ﺧﺼﻴﺼﺎً ﻭ‪/‬ﺃﻭ ﻏﻴﺮ‬
‫ﻗﺎﺉﻤﺔﻋﻠﻰ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﻓﻲ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺫﺍﺕ ﺍﻷﻫﻤﻴﺔ ﺍﻷﻣﻨﻴﺔ‪ ،‬ﻣﺜﻞ ﺍﻟﺨﺪﻣﺎﺕ‬
‫ﺍﻟﻤﺼﺮﻓﻴﺔﻋﺒﺮ ﺍﻹﻧﺘﺮﻧﺖ‪.‬‬

‫ﺗﻨﻘﺴﻢﺍﻟﺜﻐﺮﺍﺕ ﺍﻷﻣﻨﻴﺔ ﺍﻟﻤﻮﺟﻮﺩﺓ ﻓﻲ ﺁﻟﻴﺎﺕ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ ﺇﻟﻰ ﻓﺉﺘﻴﻦ ﺇﻟﻰ ﺣﺪ ﻛﺒﻴﺮ‪:‬‬

‫ﻧﻘﺎﻁﺍﻟﻀﻌﻒ ﻓﻲ ﺗﻮﻟﻴﺪ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ‬ ‫‪-‬‬

‫ﻧﻘﺎﻁﺍﻟﻀﻌﻒ ﻓﻲ ﺍﻟﺘﻌﺎﻣﻞ ﻣﻊ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ ﻃﻮﺍﻝ ﺩﻭﺭﺓ ﺣﻴﺎﺗﻬﺎ‬ ‫‪-‬‬

‫ﺳﻨﺘﻨﺎﻭﻝﻛﻼً ﻣﻦ ﻫﺬﻩ ﺍﻟﻤﺠﺎﻻﺕ ﻋﻠﻰ ﺣﺪﺓ‪ ،‬ﻭﺍﺻﻔﻴﻦ ﺃﻧﻮﺍﻉ ﺍﻟﻌﻴﻮﺏ ﺍﻟﺸﺎﺉﻌﺔ ﻓﻲ ﺁﻟﻴﺎﺕ ﺇﺩﺍﺭﺓ‬
‫ﺍﻟﺠﻠﺴﺎﺕﺍﻟﻌﻤﻠﻴﺔ‪ ،‬ﻭﺍﻟﺘﻘﻨﻴﺎﺕ ﺍﻟﻌﻤﻠﻴﺔ ﻻﻛﺘﺸﺎﻓﻬﺎ ﻭﺍﺳﺘﻐﻼﻟﻬﺎ‪ .‬ﻭﺃﺧﻴﺮﺍً‪ ،‬ﺳﻨﺼﻒ ﺍﻟﺘﺪﺍﺑﻴﺮ ﺍﻟﺘﻲ ﻳﻤﻜﻦ‬
‫ﻟﻠﺘﻄﺒﻴﻘﺎﺕﺍﺗﺨﺎﺫﻫﺎ ﻟﻠﺪﻓﺎﻉ ﻋﻦ ﻧﻔﺴﻬﺎ ﺿﺪ ﻫﺬﻩ ﺍﻟﻬﺠﻤﺎﺕ‪.‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬ ‫‪208‬‬

‫ﺧﻄﻮﺍﺕﺍﻻﺧﺘﺮﺍﻕ‬

‫ﻓﻲﺍﻟﻌﺪﻳﺪ ﻣﻦ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﻟﺘﻲ ﺗﺴﺘﺨﺪﻡ ﺁﻟﻴﺔ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﺍﻟﻘﻴﺎﺳﻴﺔ ﻟﻨﻘﻞ ﺭﻣﻮﺯ‬
‫ﺍﻟﺠﻠﺴﺔ‪،‬ﻳﺴﻬﻞ ﺗﺤﺪﻳﺪ ﻋﻨﺼﺮ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺍﻟﺬﻱ ﻳﺤﺘﻮﻱ ﻋﻠﻰ ﺍﻟﺮﻣﺰ‪ .‬ﻭﻣﻊ ﺫﻟﻚ‪ ،‬ﻗﺪ ﻳﺘﻄﻠﺐ ﻫﺬﺍ‬
‫ﺑﻌﺾﺍﻟﺘﺪﻗﻴﻖ ﻓﻲ ﺣﺎﻻﺕ ﺃﺧﺮﻯ‪.‬‬
‫‪.١‬ﻗﺪ ﻳﺴﺘﺨﺪﻡ ﺍﻟﺘﻄﺒﻴﻖ ﻓﻲ ﻛﺜﻴﺮ ﻣﻦ ﺍﻷﺣﻴﺎﻥ ﻋﺪﺓ ﻋﻨﺎﺻﺮ ﺑﻴﺎﻧﺎﺕ ﻣﺨﺘﻠﻔﺔ ﻛﺮﻣﺰ‪ ،‬ﺑﻤﺎ ﻓﻲ ﺫﻟﻚ‬
‫ﻣﻠﻔﺎﺕﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ‪ ،‬ﻭﻣﻌﻠﻤﺎﺕ ﻋﻨﺎﻭﻳﻦ ‪ ،URL‬ﻭﺣﻘﻮﻝ ﺍﻟﻨﻤﺎﺫﺝ ﺍﻟﻤﺨﻔﻴﺔ‪ .‬ﻗﺪ ﺗﺴُﺘﺨﺪﻡ‬
‫ﺑﻌﺾﻫﺬﻩ ﺍﻟﻌﻨﺎﺻﺮ ﻟﻠﺤﻔﺎﻅ ﻋﻠﻰ ﺣﺎﻟﺔ ﺍﻟﺠﻠﺴﺔ ﻋﻠﻰ ﻣﻜﻮﻧﺎﺕ ﺧﻠﻔﻴﺔ ﻣﺨﺘﻠﻔﺔ‪ .‬ﻻ ﺗﻔﺘﺮﺽ ﺃﻥ‬
‫ﻣﻌﻠﻤﺔﻣﻌﻴﻨﺔ ﻫﻲ ﺭﻣﺰ ﺍﻟﺠﻠﺴﺔ ﺩﻭﻥ ﺇﺛﺒﺎﺕ ﺫﻟﻚ‪ ،‬ﺃﻭ ﺃﻥ ﺍﻟﺠﻠﺴﺎﺕ ﺗﺘُﺒﻊّ ﺑﺎﺳﺘﺨﺪﺍﻡ ﻋﻨﺼﺮ‬
‫ﻭﺍﺣﺪﻓﻘﻂ‪.‬‬

‫‪.٢‬ﻓﻲ ﺑﻌﺾ ﺍﻷﺣﻴﺎﻥ‪ ،‬ﻗﺪ ﻻ ﺗﻜﻮﻥ ﺍﻟﻌﻨﺎﺻﺮ ﺍﻟﺘﻲ ﺗﺒﺪﻭ ﻭﻛﺄﻧﻬﺎ ﺭﻣﺰ ﺟﻠﺴﺔ ﺍﻟﺘﻄﺒﻴﻖ ﻣﻮﺟﻮﺩﺓ‪ .‬ﻋﻠﻰ‬
‫ﻭﺟﻪﺍﻟﺨﺼﻮﺹ‪ ،‬ﻗﺪ ﻳﻜﻮﻥ ﻣﻠﻒ ﺗﻌﺮﻳﻒ ﺍﺭﺗﺒﺎﻁ ﺍﻟﺠﻠﺴﺔ ﺍﻟﻘﻴﺎﺳﻲ ﺍﻟﺬﻱ ﻳﻨُﺸﺉﻪ ﺧﺎﺩﻡ ﺍﻟﻮﻳﺐ‬
‫ﺃﻭﻣﻨﺼﺔ ﺍﻟﺘﻄﺒﻴﻖ ﻣﻮﺟﻮﺩﺍً‪ ،‬ﻭﻟﻜﻨﻪ ﻻ ﻳﺴﺘﺨﺪﻣﻪ ﺍﻟﺘﻄﺒﻴﻖ ﻓﻌﻠﻴﺎً‪.‬‬

‫‪.٣‬ﻻﺣﻆ ﺍﻟﻌﻨﺎﺻﺮ ﺍﻟﺠﺪﻳﺪﺓ ﺍﻟﺘﻲ ﺗﻤُﺮﺭَّ ﺇﻟﻰ ﺍﻟﻤﺘﺼﻔﺢ ﺑﻌﺪ ﺍﻟﻤﺼﺎﺩﻗﺔ‪ .‬ﻏﺎﻟﺒﺎً ﻣﺎ ﺗﻨُﺸﺄ ﺭﻣﻮﺯ ﺟﻠﺴﺔ‬
‫ﺟﺪﻳﺪﺓﺑﻌﺪ ﻣﺼﺎﺩﻗﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ‪.‬‬
‫‪.٤‬ﻟﻠﺘﺤﻘﻖ ﻣﻦ ﺍﻟﻌﻨﺎﺻﺮ ﺍﻟﻤﺴﺘﺨﺪﻣﺔ ﻛﺮﻣﻮﺯ‪ ،‬ﺍﺑﺤﺚ ﻋﻦ ﺻﻔﺤﺔ ﺗﻌﺘﻤﺪ ﻋﻠﻰ ﺍﻟﺠﻠﺴﺔ )ﻣﺜﻞ ﺻﻔﺤﺔ "‬
‫ﺑﻴﺎﻧﺎﺗﻲ" ﺍﻟﺨﺎﺻﺔ ﺑﺎﻟﻤﺴﺘﺨﺪﻡ(‪ .‬ﺍﻃﻠﺒﻬﺎ ﻋﺪﺓ ﻣﺮﺍﺕ‪ ،‬ﻣﻊ ﺇﺯﺍﻟﺔ ﻛﻞ ﻋﻨﺼﺮ ﺗﺸﻚ ﻓﻲ ﺍﺳﺘﺨﺪﺍﻣﻪ‬
‫ﻛﺮﻣﺰﺑﺸﻜﻞ ﻣﻨﻬﺠﻲ‪ .‬ﺇﺫﺍ ﺃﺩﻯ ﺣﺬﻑ ﻋﻨﺼﺮ ﺇﻟﻰ ﻋﺪﻡ ﻋﻮﺩﺓ ﺍﻟﺼﻔﺤﺔ ﺍﻟﻤﻌﺘﻤﺪﺓ ﻋﻠﻰ ﺍﻟﺠﻠﺴﺔ‪،‬‬
‫ﻓﻬﺬﺍﻳﻤﻜﻦﺗﺄﻛﺪ ﻣﻦ ﺃﻥ ﺍﻟﻌﻨﺼﺮ ﺭﻣﺰ ﺟﻠﺴﺔ‪ .‬ﻳﻌُﺪ ‪ Burp Repeater‬ﺃﺩﺍﺓ ﻣﻔﻴﺪﺓ ﻹﺟﺮﺍء ﻫﺬﻩ‬
‫ﺍﻻﺧﺘﺒﺎﺭﺍﺕ‪.‬‬

‫ﺑﺪﺍﺉﻞﻟﻠﺠﻠﺴﺎﺕ‬
‫ﻻﺗﺴﺘﺨﺪﻡ ﺟﻤﻴﻊ ﺗﻄﺒﻴﻘﺎﺕ ﺍﻟﻮﻳﺐ ﺍﻟﺠﻠﺴﺎﺕ‪ ،‬ﻭﺑﻌﺾ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺫﺍﺕ ﺍﻷﻫﻤﻴﺔ ﺍﻷﻣﻨﻴﺔ‪ ،‬ﻭﺍﻟﺘﻲ‬
‫ﺗﺤﺘﻮﻱﻋﻠﻰ ﺁﻟﻴﺎﺕ ﻣﺼﺎﺩﻗﺔ ﻭﻭﻇﺎﺉﻒ ﻣﻌﻘﺪﺓ‪ ،‬ﺗﺨﺘﺎﺭ ﺍﺳﺘﺨﺪﺍﻡ ﺗﻘﻨﻴﺎﺕ ﺃﺧﺮﻯ ﻹﺩﺍﺭﺓ ﺍﻟﺤﺎﻟﺔ‪ .‬ﻣﻦ‬
‫ﺍﻟﻤﺮﺟﺢﺃﻥ ﺗﺠﺪ ﺧﻴﺎﺭﻳﻦ‪:‬‬

‫ﻣﺼﺎﺩﻗﺔ‪—HTTP‬ﺃﺣﻴﺎﻧﺎً ﻣﺎ ﺗﺘﺠﻨﺐ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﻟﺘﻲ ﺗﺴﺘﺨﺪﻡ ﺗﻘﻨﻴﺎﺕ ﺍﻟﻤﺼﺎﺩﻗﺔ‬ ‫‪-‬‬

‫ﺍﻟﻤﺨﺘﻠﻔﺔﺍﻟﻘﺎﺉﻤﺔ ﻋﻠﻰ ‪) HTTP‬ﺍﻷﺳﺎﺳﻴﺔ‪ ،‬ﻭﺍﻟﻤﺨﺘﺼﺮﺓ‪ ،‬ﻭ‪ (NTLM‬ﺍﻟﺤﺎﺟﺔ ﺇﻟﻰ ﺍﺳﺘﺨﺪﺍﻡ‬

‫ﺍﻟﺠﻠﺴﺎﺕ‪.‬ﺑﺎﺳﺘﺨﺪﺍﻡ ﻣﺼﺎﺩﻗﺔ ‪ ،HTTP‬ﻳﺘﻔﺎﻋﻞ ﻣﻜُﻮﻥّ ﺍﻟﻌﻤﻴﻞ ﻣﻊ ﺁﻟﻴﺔ ﺍﻟﻤﺼﺎﺩﻗﺔ ﻣﺒﺎﺷﺮﺓ ً‬
‫ﻋﺒﺮﺍﻟﻤﺘﺼﻔﺢ‪ ،‬ﺑﺎﺳﺘﺨﺪﺍﻡ ﺭﺅﻭﺱ ‪ ،HTTP‬ﻭﻟﻴﺲ ﻋﺒﺮ ﺷﻴﻔﺮﺓ ﺧﺎﺻﺔ ﺑﺎﻟﺘﻄﺒﻴﻖ ﻣﻮﺟﻮﺩﺓ ﻓﻲ‬
‫ﺃﻱﺻﻔﺤﺔ‪ .‬ﺑﻌﺪ ﺃﻥ ﻳﺪُﺧﻞ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺑﻴﺎﻧﺎﺕ ﺍﻋﺘﻤﺎﺩﻩ ﻓﻲ ﻧﺎﻓﺬﺓ ﺍﻟﻤﺘﺼﻔﺢ‪ ،‬ﻳﻌُﻴﺪ ﺍﻟﻤﺘﺼﻔﺢ‬
‫ﺇﺭﺳﺎﻝﻫﺬﻩ ﺍﻟﺒﻴﺎﻧﺎﺕ )ﺃﻭ ﻳﻌُﻴﺪ ﺃﻱ ﻣﺼﺎﻓﺤﺔ ﻣﻄﻠﻮﺑﺔ( ﻣﻊ ﻛﻞ ﻃﻠﺐ ﻻﺣﻖ ﺇﻟﻰ ﺍﻟﺨﺎﺩﻡ ﻧﻔﺴﻪ‪.‬‬
‫ﻳﻌُﺎﺩﻝﻫﺬﺍ ﺗﻄﺒﻴﻘﺎً ﻳﺴﺘﺨﺪﻡ ﻣﺼﺎﺩﻗﺔ ﻗﺎﺉﻤﺔ ﻋﻠﻰ ﻧﻤﺎﺫﺝ ‪ HTML‬ﻭﻳﻀﻊ ﻧﻤﻮﺫﺝ ﺗﺴﺠﻴﻞ‬
‫ﺩﺧﻮﻝﻋﻠﻰ ﻛﻞ ﺻﻔﺤﺔ ﺗﻄﺒﻴﻖ‪ ،‬ﻣﻤﺎ ﻳﻠُﺰﻡ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺑﺈﻋﺎﺩﺓ ﻣﺼﺎﺩﻗﺔ ﺃﻧﻔﺴﻬﻢ ﻣﻊ ﻛﻞ‬
‫ﺇﺟﺮﺍءﻳﻘﻮﻣﻮﻥ ﺑﻪ‪ .‬ﻭﺑﺎﻟﺘﺎﻟﻲ‪ ،‬ﻋﻨﺪ ﺍﺳﺘﺨﺪﺍﻡ ﻣﺼﺎﺩﻗﺔ ‪ ،HTTP‬ﻣﻦ ﺍﻟﻤﻤﻜﻦ‬
‫‪209‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬

‫ﻟﻜﻲﻳﺘﻤﻜﻦ ﺍﻟﺘﻄﺒﻴﻖ ﻣﻦ ﺇﻋﺎﺩﺓ ﺗﻌﺮﻳﻒ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻋﺒﺮ ﻃﻠﺒﺎﺕ ﻣﺘﻌﺪﺩﺓ ﺩﻭﻥ ﺍﻟﺤﺎﺟﺔ ﺇﻟﻰ‬
‫ﺟﻠﺴﺎﺕ‪.‬ﻭﻣﻊ ﺫﻟﻚ‪ ،‬ﻧﺎﺩﺭﺍً ﻣﺎ ﻳﺴُﺘﺨﺪﻡ ﻣﺼﺎﺩﻗﺔ ‪ HTTP‬ﻓﻲ ﺗﻄﺒﻴﻘﺎﺕ ﺍﻹﻧﺘﺮﻧﺖ ﺍﻟﻤﻌﻘﺪﺓ‪،‬‬
‫ﻭﺍﻟﻤﺰﺍﻳﺎﺍﻟﻤﺘﻌﺪﺩﺓ ﺍﻷﺧﺮﻯ ﺍﻟﺘﻲ ﺗﻮﻓﺮﻫﺎ ﺁﻟﻴﺎﺕ ﺍﻟﺠﻠﺴﺎﺕ ﺍﻟﻤﺘﻜﺎﻣﻠﺔ ﺗﻌﻨﻲ ﺃﻥ ﺟﻤﻴﻊ ﺗﻄﺒﻴﻘﺎﺕ‬
‫ﺍﻟﻮﻳﺐﺗﻘﺮﻳﺒﺎً ﺗﺴﺘﺨﺪﻡ ﻫﺬﻩ ﺍﻵﻟﻴﺎﺕ‪.‬‬

‫ﺁﻟﻴﺎﺕﺍﻟﺤﺎﻟﺔ ﺑﺪﻭﻥ ﺟﻠﺴﺔ—ﺑﻌﺾ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﻻ ﺗﺼُﺪﺭ ﺭﻣﻮﺯ ﺟﻠﺴﺔ ﻹﺩﺍﺭﺓ ﺣﺎﻟﺔ ﺗﻔﺎﻋﻞ‬ ‫‪-‬‬

‫ﺍﻟﻤﺴﺘﺨﺪﻡﻣﻊ ﺍﻟﺘﻄﺒﻴﻖ‪ .‬ﺑﻞ ﺗﻨﻘﻞ ﺟﻤﻴﻊ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺍﻟﻼﺯﻣﺔ ﻹﺩﺍﺭﺓ ﺗﻠﻚ ﺍﻟﺤﺎﻟﺔ ﻋﺒﺮ ﺍﻟﻌﻤﻴﻞ‪،‬‬
‫ﻋﺎﺩﺓ ًﻓﻲ ﻣﻠﻒ ﺗﻌﺮﻳﻒ ﺍﺭﺗﺒﺎﻁ ﺃﻭ ﺣﻘﻞ ﻧﻤﻮﺫﺝ ﻣﺨﻔﻲ‪ .‬ﻓﻲ ﺍﻟﻮﺍﻗﻊ‪ ،‬ﺗﺴﺘﺨﺪﻡ ﻫﺬﻩ ﺍﻵﻟﻴﺔ ﺣﺎﻟﺔ‬
‫ﻋﺪﻡﺍﻟﺠﻠﺴﺔ‪ ،‬ﺗﻤﺎﻣﺎً ﻣﺜﻞ ‪.ASP.NET‬ﺣﺎﻟﺔ ﺍﻟﻌﺮﺽﻳﻔﻌﻞ‪ .‬ﻟﻀﻤﺎﻥ ﺃﻣﺎﻥ ﻫﺬﺍ ﺍﻟﻨﻮﻉ ﻣﻦ ﺍﻵﻟﻴﺎﺕ‪،‬‬
‫ﻳﺠﺐﺣﻤﺎﻳﺔ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺍﻟﻤﺮﺳﻠﺔ ﻋﺒﺮ ﺍﻟﻌﻤﻴﻞ ﺑﺸﻜﻞ ﺻﺤﻴﺢ‪ .‬ﻳﺘﻀﻤﻦ ﺫﻟﻚ ﻋﺎﺩﺓ ًﺇﻧﺸﺎء ﻛﺎﺉﻦ‬
‫ﺛﻨﺎﺉﻲﻳﺤﺘﻮﻱ ﻋﻠﻰ ﺟﻤﻴﻊ ﻣﻌﻠﻮﻣﺎﺕ ﺍﻟﺤﺎﻟﺔ‪ ،‬ﻭﺗﺸﻔﻴﺮﻩ ﺃﻭ ﺗﻮﻗﻴﻌﻪ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺧﻮﺍﺭﺯﻣﻴﺔ‬
‫ﻣﻌُﺘﺮﻑﺑﻬﺎ‪ .‬ﻳﺠﺐ ﺗﻀﻤﻴﻦ ﺳﻴﺎﻕ ﻛﺎﻑ ٍﺩﺍﺧﻞ ﺍﻟﺒﻴﺎﻧﺎﺕ ﻟﻤﻨﻊ ﺃﻱ ﻣﻬُﺎﺟﻢ ﻣﻦ ﺟﻤﻊ ﻛﺎﺉﻦ‬
‫ﺣﺎﻟﺔﻓﻲ ﻣﻮﻗﻊ ﻣﺎ ﺩﺍﺧﻞ ﺍﻟﺘﻄﺒﻴﻖ ﻭﺇﺭﺳﺎﻟﻪ ﺇﻟﻰ ﻣﻮﻗﻊ ﺁﺧﺮ ﻣﺴُﺒﺒﺎً ﺳﻠﻮﻛﺎً ﻏﻴﺮ ﻣﺮﻏﻮﺏ ﻓﻴﻪ‪ .‬ﻗﺪ‬
‫ﻳﻀُﻴﻒﺍﻟﺘﻄﺒﻴﻖ ﺃﻳﻀﺎً ﻭﻗﺖ ﺍﻧﺘﻬﺎء ﺻﻼﺣﻴﺔ ﺿﻤﻦ ﺑﻴﺎﻧﺎﺕ ﺍﻟﻜﺎﺉﻦ ﻟﺘﻨﻔﻴﺬ ﻣﺎ ﻳﻌُﺎﺩﻝ ﻣﻬﻠﺔ‬
‫ﺍﻧﺘﻬﺎءﺍﻟﺠﻠﺴﺔ‪ .‬ﻳﺼﻒ ﺍﻟﻔﺼﻞ ﺍﻟﺨﺎﻣﺲ ﺑﻤﺰﻳﺪ ﻣﻦ ﺍﻟﺘﻔﺼﻴﻞ ﺁﻟﻴﺎﺕ ﺍﻷﻣﺎﻥ ﻟﻨﻘﻞ ﺍﻟﺒﻴﺎﻧﺎﺕ‬
‫ﻋﺒﺮﺍﻟﻌﻤﻴﻞ‪.‬‬

‫ﺧﻄﻮﺍﺕﺍﻻﺧﺘﺮﺍﻕ‬

‫‪.١‬ﻓﻲ ﺣﺎﻝ ﺍﺳﺘﺨﺪﺍﻡ ﻣﺼﺎﺩﻗﺔ ‪ ،HTTP‬ﻣﻦ ﺍﻟﻤﺤﺘﻤﻞ ﻋﺪﻡ ﻭﺟﻮﺩ ﺁﻟﻴﺔ ﻹﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‪ .‬ﺍﺳﺘﺨﺪﻡ‬
‫ﺍﻟﻄﺮﻕﺍﻟﻤﻮﺿﺤﺔ ﺳﺎﺑﻘﺎً ﻟﻔﺤﺺ ﺩﻭﺭ ﻋﻨﺎﺻﺮ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺍﻟﺸﺒﻴﻬﺔ ﺑﺎﻟﺮﻣﻮﺯ‪.‬‬

‫‪.2‬ﺇﺫﺍ ﻛﺎﻥ ﺍﻟﺘﻄﺒﻴﻖ ﻳﺴﺘﺨﺪﻡ ﺁﻟﻴﺔ ﺣﺎﻟﺔ ﺑﺪﻭﻥ ﺟﻠﺴﺔ‪ ،‬ﻭﻧﻘﻞ ﺟﻤﻴﻊ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺍﻟﻤﻄﻠﻮﺑﺔ ﻟﻠﺤﻔﺎﻅ‬
‫ﻋﻠﻰﺍﻟﺤﺎﻟﺔ ﻋﺒﺮ ﺍﻟﻌﻤﻴﻞ‪ ،‬ﻓﻘﺪ ﻳﻜﻮﻥ ﻣﻦ ﺍﻟﺼﻌﺐ ﻓﻲ ﺑﻌﺾ ﺍﻷﺣﻴﺎﻥ ﺍﻛﺘﺸﺎﻑ ﺫﻟﻚ ﻋﻠﻰ‬
‫ﻭﺟﻪﺍﻟﻴﻘﻴﻦ‪ ،‬ﻭﻟﻜﻦ ﺍﻟﻤﺆﺷﺮﺍﺕ ﺍﻟﺘﺎﻟﻴﺔ ﻗﻮﻳﺔ ﻋﻠﻰ ﺍﺳﺘﺨﺪﺍﻡ ﻫﺬﺍ ﺍﻟﻨﻮﻉ ﻣﻦ ﺍﻵﻟﻴﺔ‪:‬‬

‫ﺗﻌﺘﺒﺮﻋﻨﺎﺻﺮ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺍﻟﺸﺒﻴﻬﺔ ﺑﺎﻟﺮﻣﻮﺯ ﺍﻟﺼﺎﺩﺭﺓ ﻟﻠﻌﻤﻴﻞ ﻃﻮﻳﻠﺔ ﺇﻟﻰ ﺣﺪ ﻣﺎ )‪ 100‬ﺑﺎﻳﺖ ﺃﻭ ﺃﻛﺜﺮ(‪.‬‬ ‫‪-‬‬

‫ﻳﺼﺪﺭﺍﻟﺘﻄﺒﻴﻖ ﻋﻨﺼﺮﺍً ﺟﺪﻳﺪﺍً ﻳﺸﺒﻪ ﺍﻟﺮﻣﺰ ﺍﻟﻤﻤﻴﺰ ﺭﺩﺍً ﻋﻠﻰ ﻛﻞ ﻃﻠﺐ‪.‬‬ ‫‪-‬‬

‫ﻳﺒﺪﻭﺃﻥ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺍﻟﻤﻮﺟﻮﺩﺓ ﻓﻲ ﺍﻟﻌﻨﺼﺮ ﻣﺸﻔﺮﺓ )ﻭﺑﺎﻟﺘﺎﻟﻲ ﻟﻴﺲ ﻟﻬﺎ ﺑﻨﻴﺔ ﻭﺍﺿﺤﺔ( ﺃﻭ‬ ‫‪-‬‬

‫ﻣﻮﻗﻌﺔ)ﻭﺑﺎﻟﺘﺎﻟﻲ ﻟﻬﺎ ﺑﻨﻴﺔ ﺫﺍﺕ ﻣﻌﻨﻰ ﻣﺼﺤﻮﺑﺔ ﺑﺒﻀﻌﺔ ﺑﺎﻳﺘﺎﺕ ﻣﻦ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺍﻟﺜﻨﺎﺉﻴﺔ ﺍﻟﺘﻲ‬
‫ﻻﻣﻌﻨﻰ ﻟﻬﺎ(‪.‬‬
‫ﻳﺠﻮﺯﻟﻠﺘﻄﺒﻴﻖ ﺭﻓﺾ ﻣﺤﺎﻭﻻﺕ ﺗﻘﺪﻳﻢ ﻧﻔﺲ ﺍﻟﻌﻨﺼﺮ ﺑﺄﻛﺜﺮ ﻣﻦ ﻃﻠﺐ‪.‬‬ ‫‪-‬‬

‫‪.٣‬ﺇﺫﺍ ﻛﺎﻧﺖ ﺍﻷﺩﻟﺔ ﺗﺸﻴﺮ ﺑﻘﻮﺓ ﺇﻟﻰ ﺃﻥ ﺍﻟﺘﻄﺒﻴﻖ ﻻ ﻳﺴﺘﺨﺪﻡ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ ﻹﺩﺍﺭﺓ ﺍﻟﺤﺎﻟﺔ‪ ،‬ﻓﻤﻦ ﻏﻴﺮ‬
‫ﺍﻟﻤﺮﺟﺢﺃﻥ ﺗﺤُﻘﻖ ﺃﻱ ٌّﻣﻦ ﺍﻟﻬﺠﻤﺎﺕ ﺍﻟﻤﻮﺻﻮﻓﺔ ﻓﻲ ﻫﺬﺍ ﺍﻟﻔﺼﻞ ﺃﻱ َّﻧﺘﻴﺠﺔ‪ .‬ﻣﻦ ﺍﻷﻓﻀﻞ ﺃﻥ‬
‫ﺗﺒﺤﺚﻋﻦ ﻣﺸﺎﻛﻞ ﺧﻄﻴﺮﺓ ﺃﺧﺮﻯ‪ ،‬ﻣﺜﻞ ﺧﻠﻞ ﻓﻲ ﺿﻮﺍﺑﻂ ﺍﻟﻮﺻﻮﻝ ﺃﻭ ﺣﻘﻦ ﺍﻟﺸﻴﻔﺮﺓ‪.‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬ ‫‪210‬‬

‫ﻧﻘﺎﻁﺍﻟﻀﻌﻒ ﻓﻲ ﺗﻮﻟﻴﺪ ﺍﻟﺮﻣﻮﺯ‬

‫ﻏﺎﻟﺒﺎًﻣﺎ ﺗﻜﻮﻥ ﺁﻟﻴﺎﺕ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ ﻋﺮﺿﺔ ﻟﻠﻬﺠﻮﻡ ﻷﻥ ﺍﻟﺮﻣﻮﺯ ﻳﺘﻢ ﺇﻧﺸﺎﺅﻫﺎ ﺑﻄﺮﻳﻘﺔ ﻏﻴﺮ ﺁﻣﻨﺔ ﺗﻤﻜﻦ‬
‫ﺍﻟﻤﻬﺎﺟﻢﻣﻦ ﺗﺤﺪﻳﺪ ﻗﻴﻢ ﺍﻟﺮﻣﻮﺯ ﺍﻟﺘﻲ ﺗﻢ ﺇﺻﺪﺍﺭﻫﺎ ﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺁﺧﺮﻳﻦ‪.‬‬

‫ﻣﻠﺤﻮﻇﺔﻫﻨﺎﻙ ﺍﻟﻌﺪﻳﺪ ﻣﻦ ﺍﻟﻤﻮﺍﻗﻊ ﺍﻟﺘﻲ ﻳﻌﺘﻤﺪ ﻓﻴﻬﺎ ﺃﻣﺎﻥ ﺍﻟﺘﻄﺒﻴﻖ ﻋﻠﻰ ﻋﺪﻡ ﺍﻟﻘﺪﺭﺓ‬
‫ﻋﻠﻰﺍﻟﺘﻨﺒﺆ ﺑﺎﻟﺮﻣﻮﺯ ﺍﻟﺘﻲ ﻳﻨُﺸﺉﻬﺎ‪ .‬ﺇﻟﻴﻚ ﺑﻌﺾ ﺍﻷﻣﺜﻠﺔ‪:‬‬

‫ﺭﻣﻮﺯﺍﺳﺘﺮﺩﺍﺩ ﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ ﺍﻟﻤﺮﺳﻠﺔ ﺇﻟﻰ ﻋﻨﻮﺍﻥ ﺍﻟﺒﺮﻳﺪ ﺍﻹﻟﻜﺘﺮﻭﻧﻲ ﺍﻟﻤﺴﺠﻞ ﻟﻠﻤﺴﺘﺨﺪﻡ‬ ‫‪-‬‬
‫ﺍﻟﺮﻣﻮﺯﺍﻟﻤﻮﺿﻮﻋﺔ ﻓﻲ ﺣﻘﻮﻝ ﺍﻟﻨﻤﺎﺫﺝ ﺍﻟﻤﺨﻔﻴﺔ ﻟﻤﻨﻊ ﻫﺠﻤﺎﺕ ﺗﺰﻭﻳﺮ ﺍﻟﻄﻠﺒﺎﺕ ﻋﺒﺮ ﺍﻟﻤﻮﺍﻗﻊ )‬ ‫‪-‬‬
‫ﺍﻧﻈﺮﺍﻟﻔﺼﻞ ‪(13‬‬
‫ﺍﻟﺮﻣﻮﺯﺍﻟﻤﺴﺘﺨﺪﻣﺔ ﻟﻤﻨﺢ ﺣﻖ ﺍﻟﻮﺻﻮﻝ ﻟﻤﺮﺓ ﻭﺍﺣﺪﺓ ﺇﻟﻰ ﺍﻟﻤﻮﺍﺭﺩ ﺍﻟﻤﺤﻤﻴﺔ‬ ‫‪-‬‬
‫ﺍﻟﺮﻣﻮﺯﺍﻟﺪﺍﺉﻤﺔ ﺍﻟﻤﺴﺘﺨﺪﻣﺔ ﻓﻲ ﻭﻇﺎﺉﻒ "ﺗﺬﻛﺮﻧﻲ"‬ ‫‪-‬‬
‫ﺍﻟﺮﻣﻮﺯﺍﻟﺘﻲ ﺗﺴﻤﺢ ﻟﻌﻤﻼء ﺗﻄﺒﻴﻖ ﺍﻟﺘﺴﻮﻕ ﺍﻟﺬﻱ ﻻ ﻳﺴﺘﺨﺪﻡ ﺍﻟﻤﺼﺎﺩﻗﺔ ﺑﺎﺳﺘﺮﺩﺍﺩ ﺍﻟﺤﺎﻟﺔ‬ ‫‪-‬‬
‫ﺍﻟﺤﺎﻟﻴﺔﻟﻄﻠﺐ ﻣﻮﺟﻮﺩ‬

‫ﺗﻨﻄﺒﻖﺍﻻﻋﺘﺒﺎﺭﺍﺕ ﺍﻟﻮﺍﺭﺩﺓ ﻓﻲ ﻫﺬﺍ ﺍﻟﻔﺼﻞ ﻭﺍﻟﻤﺘﻌﻠﻘﺔ ﺑﻨﻘﺎﻁ ﺍﻟﻀﻌﻒ ﻓﻲ ﺗﻮﻟﻴﺪ ﺍﻟﺮﻣﻮﺯ ﻋﻠﻰ ﺟﻤﻴﻊ‬
‫ﻫﺬﻩﺍﻟﺤﺎﻻﺕ‪ .‬ﻓﻲ ﺍﻟﻮﺍﻗﻊ‪ ،‬ﻧﻈﺮﺍً ﻻﻋﺘﻤﺎﺩ ﺍﻟﻌﺪﻳﺪ ﻣﻦ ﺗﻄﺒﻴﻘﺎﺕ ﺍﻟﻴﻮﻡ ﻋﻠﻰ ﺁﻟﻴﺎﺕ ﻣﻨﺼﺎﺕ ﻣﺘﻄﻮﺭﺓ‬
‫ﻟﺘﻮﻟﻴﺪﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ‪ ،‬ﻏﺎﻟﺒﺎً ﻣﺎ ﺗﻜُﺘﺸﻒ ﻧﻘﺎﻁ ﺿﻌﻒ ﻗﺎﺑﻠﺔ ﻟﻼﺳﺘﻐﻼﻝ ﻓﻲ ﺗﻮﻟﻴﺪ ﺍﻟﺮﻣﻮﺯ ﻓﻲ ﻫﺬﻩ‬
‫ﺍﻟﻤﺠﺎﻻﺕﺍﻟﻮﻇﻴﻔﻴﺔ ﺍﻷﺧﺮﻯ‪.‬‬

‫ﺭﻣﻮﺯﺫﺍﺕ ﻣﻌﻨﻰ‬
‫ﺗﻨُﺸﺄﺑﻌﺾ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺗﺤﻮﻳﻞ ﺍﺳﻢ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺃﻭ ﻋﻨﻮﺍﻥ ﺑﺮﻳﺪﻩ ﺍﻹﻟﻜﺘﺮﻭﻧﻲ‪ ،‬ﺃﻭ ﺃﻱ‬
‫ﻣﻌﻠﻮﻣﺎﺕﺃﺧﺮﻯ ﻣﺮﺗﺒﻄﺔ ﺑﻪ‪ .‬ﻗﺪ ﺗﺸُﻔﺮَّ ﻫﺬﻩ ﺍﻟﻤﻌﻠﻮﻣﺎﺕ ﺃﻭ ﺗﺤُﺠﺐ ﺑﻄﺮﻳﻘﺔ ﻣﺎ‪ ،‬ﻭﻗﺪ ﺗﺪُﻣﺞ ﻣﻊ ﺑﻴﺎﻧﺎﺕ‬
‫ﺃﺧﺮﻯ‪.‬‬

‫ﻋﻠﻰﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﻗﺪ ﻳﺒﺪﻭ ﺍﻟﺮﻣﺰ ﺍﻟﺘﺎﻟﻲ ﻓﻲ ﺍﻟﺒﺪﺍﻳﺔ ﻭﻛﺄﻧﻪ ﺳﻠﺴﻠﺔ ﻋﺸﻮﺍﺉﻴﺔ ﻃﻮﻳﻠﺔ‪:‬‬

‫‪757365723d6461663b6170703d61646d696e3b646174653d30312f31322f3131‬‬

‫ﻣﻊﺫﻟﻚ‪ ،‬ﻋﻨﺪ ﺍﻟﺘﺪﻗﻴﻖ‪ ،‬ﺳﺘﺠﺪ ﺃﻧﻪ ﻳﺤﺘﻮﻱ ﻓﻘﻂ ﻋﻠﻰ ﺃﺣﺮﻑ ﺳﺪﺍﺳﻴﺔ ﻋﺸﺮﻳﺔ‪ .‬ﺑﺎﻓﺘﺮﺍﺽ ﺃﻥ‬
‫ﺍﻟﺴﻠﺴﻠﺔﻗﺪ ﺗﻜﻮﻥ ﻓﻲ ﺍﻟﻮﺍﻗﻊ ﺗﺮﻣﻴﺰﺍً ﺳﺪﺍﺳﻲ ﻋﺸﺮﻳﺎً ﻟﺴﻠﺴﻠﺔ ﻣﻦ ﺃﺣﺮﻑ ‪ ،ASCII‬ﻳﻤﻜﻨﻚ ﺗﺸﻐﻴﻠﻬﺎ‬
‫ﻋﻠﻰﺟﻬﺎﺯ ﻓﻚ ﺍﻟﺘﺸﻔﻴﺮ ﻟﻠﻜﺸﻒ ﻋﻦ ﺍﻟﺘﺎﻟﻲ‪:‬‬
‫ﺍﻟﻤﺴﺘﺨﺪﻡ=‪daf‬؛ ﺍﻟﺘﻄﺒﻴﻖ=‪admin‬؛ ﺍﻟﺘﺎﺭﻳﺦ=‪10/09/11‬‬
‫‪211‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬

‫ﻳﻤﻜﻦﻟﻠﻤﻬﺎﺟﻤﻴﻦ ﺍﺳﺘﻐﻼﻝ ﻣﻌﻨﻰ ﺭﻣﺰ ﺍﻟﺠﻠﺴﺔ ﻫﺬﺍ ﻟﻤﺤﺎﻭﻟﺔ ﺗﺨﻤﻴﻦ ﺍﻟﺠﻠﺴﺎﺕ ﺍﻟﺤﺎﻟﻴﺔ‬
‫ﻟﻤﺴﺘﺨﺪﻣﻴﻦﺁﺧﺮﻳﻦ ﻓﻲ ﺍﻟﺘﻄﺒﻴﻖ‪ .‬ﺑﺎﺳﺘﺨﺪﺍﻡ ﻗﺎﺉﻤﺔ ﺑﺄﺳﻤﺎء ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺍﻟﻤﻌُﺪﺩّﺓ ﺃﻭ ﺍﻟﺸﺎﺉﻌﺔ‪،‬‬
‫ﻳﻤﻜﻨﻬﻢﺇﻧﺸﺎء ﺃﻋﺪﺍﺩ ﻛﺒﻴﺮﺓ ﻣﻦ ﺍﻟﺮﻣﻮﺯ ﺍﻟﺼﺎﻟﺤﺔ ﺍﻟﻤﺤﺘﻤﻠﺔ ﺑﺴﺮﻋﺔ ﻭﺍﺧﺘﺒﺎﺭﻫﺎ ﻟﻠﺘﺄﻛﺪ ﻣﻦ ﺻﺤﺘﻬﺎ‪.‬‬

‫ﻏﺎﻟﺒﺎًﻣﺎ ﺗﻈُﻬﺮ ﺍﻟﺮﻣﻮﺯ ﺍﻟﺘﻲ ﺗﺤﺘﻮﻱ ﻋﻠﻰ ﺑﻴﺎﻧﺎﺕ ﺫﺍﺕ ﻣﻌﻨﻰ ﺑﻨﻴﺔ ًﻣﺤُﺪﺩﺓ‪ .‬ﺑﻤﻌﻨﻰ ﺁﺧﺮ‪ ،‬ﺗﺤﺘﻮﻱ ﻋﻠﻰ‬
‫ﻋﺪﺓﻣﻜﻮﻧﺎﺕ‪ ،‬ﻏﺎﻟﺒﺎً ﻣﺎ ﻳﻔﺼﻞ ﺑﻴﻨﻬﺎ ﻓﺎﺻﻞ‪ ،‬ﻭﻳﻤﻜﻦ ﺍﺳﺘﺨﺮﺍﺟﻬﺎ ﻭﺗﺤﻠﻴﻠﻬﺎ ﺑﺸﻜﻞ ﻣﻨﻔﺼﻞ ﻟﺘﻤﻜﻴﻦ‬
‫ﺍﻟﻤﻬﺎﺟﻢﻣﻦ ﻓﻬﻢ ﻭﻇﻴﻔﺘﻬﺎ ﻭﻃﺮﻳﻘﺔ ﺗﻮﻟﻴﺪﻫﺎ‪ .‬ﺇﻟﻴﻚ ﺑﻌﺾ ﺍﻟﻤﻜﻮﻧﺎﺕ ﺍﻟﺘﻲ ﻗﺪ ﺗﻈﻬﺮ ﻓﻲ ﺍﻟﺮﻣﻮﺯ‬
‫ﺍﻟﻤﻬُﻴﻜﻠﺔ‪:‬‬

‫ﺍﺳﻢﻣﺴﺘﺨﺪﻡ ﺍﻟﺤﺴﺎﺏ‬ ‫‪-‬‬

‫ﺍﻟﻤﻌﺮﻑﺍﻟﺮﻗﻤﻲ ﺍﻟﺬﻱ ﻳﺴﺘﺨﺪﻣﻪ ﺍﻟﺘﻄﺒﻴﻖ ﻟﻠﺘﻤﻴﻴﺰ ﺑﻴﻦ ﺍﻟﺤﺴﺎﺑﺎﺕ‬ ‫‪-‬‬

‫ﺍﻻﺳﻢﺍﻷﻭﻝ ﻭﺍﻷﺧﻴﺮ ﻟﻠﻤﺴﺘﺨﺪﻡ‬ ‫‪-‬‬

‫ﻋﻨﻮﺍﻥﺍﻟﺒﺮﻳﺪ ﺍﻹﻟﻜﺘﺮﻭﻧﻲ ﻟﻠﻤﺴﺘﺨﺪﻡ‬ ‫‪-‬‬

‫ﻣﺠﻤﻮﻋﺔﺍﻟﻤﺴﺘﺨﺪﻡ ﺃﻭ ﺩﻭﺭﻩ ﺩﺍﺧﻞ ﺍﻟﺘﻄﺒﻴﻖ‬ ‫‪-‬‬

‫ﻃﺎﺑﻊﺍﻟﺘﺎﺭﻳﺦ‪/‬ﺍﻟﻮﻗﺖ‬ ‫‪-‬‬

‫ﺭﻗﻢﻣﺘﺰﺍﻳﺪ ﺃﻭ ﻣﺘﻮﻗﻊ‬ ‫‪-‬‬

‫ﻋﻨﻮﺍﻥ‪ IP‬ﺍﻟﺨﺎﺹ ﺑﺎﻟﻌﻤﻴﻞ‬ ‫‪-‬‬

‫ﻳﻤﻜﻦﺗﺮﻣﻴﺰ ﻛﻞ ﻣﻜﻮﻥ ﻣﻦ ﻣﻜﻮﻧﺎﺕ ﺍﻟﺮﻣﺰ ﺍﻟﻤﻬﻴﻜﻞ‪ ،‬ﺃﻭ ﺍﻟﺮﻣﺰ ﺑﺄﻛﻤﻠﻪ‪ ،‬ﺑﻄﺮﻕ ﻣﺨﺘﻠﻔﺔ‪ .‬ﻗﺪ ﻳﻜﻮﻥ‬
‫ﻫﺬﺍﺇﺟﺮﺍء ًﻣﻘﺼﻮﺩﺍً ﻹﺧﻔﺎء ﻣﺤﺘﻮﺍﻩ‪ ،‬ﺃﻭ ﺑﺒﺴﺎﻃﺔ ﻟﻀﻤﺎﻥ ﺍﻟﻨﻘﻞ ﺍﻵﻣﻦ ﻟﻠﺒﻴﺎﻧﺎﺕ ﺍﻟﺜﻨﺎﺉﻴﺔ ﻋﺒﺮ ‪.HTTP‬‬
‫ﺗﺸﻤﻞﺃﻧﻈﻤﺔ ﺍﻟﺘﺮﻣﻴﺰ ﺍﻟﺸﺎﺉﻌﺔ ‪ XOR‬ﻭ‪ Base64‬ﻭﺍﻟﺘﻤﺜﻴﻞ ﺍﻟﺴﺪﺍﺳﻲ ﻋﺸﺮﻱ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺃﺣﺮﻑ‬
‫‪) ASCII‬ﺍﻧﻈﺮ ﺍﻟﻔﺼﻞ ‪ .(3‬ﻗﺪ ﻳﻜﻮﻥ ﻣﻦ ﺍﻟﻀﺮﻭﺭﻱ ﺍﺧﺘﺒﺎﺭ ﻓﻚ ﺗﺸﻔﻴﺮ ﻣﺨﺘﻠﻒ ﻟﻜﻞ ﻣﻜﻮﻥ ﻣﻦ‬
‫ﻣﻜﻮﻧﺎﺕﺍﻟﺮﻣﺰ ﺍﻟﻤﻬﻴﻜﻞ ﻟﻔﻚ ﺿﻐﻄﻪ ﺇﻟﻰ ﺷﻜﻠﻪ ﺍﻷﺻﻠﻲ‪.‬‬

‫ﻣﻠﺤﻮﻇﺔﻋﻨﺪﻣﺎ ﻳﺘﻌﺎﻣﻞ ﺗﻄﺒﻴﻖ ﻣﻊ ﻃﻠﺐ ﻳﺤﺘﻮﻱ ﻋﻠﻰ ﺭﻣﺰ ﻣﻬُﻴﻜﻞ‪ ،‬ﻓﻘﺪ ﻻ ﻳﻌُﺎﻟﺞ ﻓﻌﻠﻴﺎً ﺟﻤﻴﻊ‬
‫ﺍﻟﻤﻜﻮﻧﺎﺕﺍﻟﺘﻲ ﺗﺤﺘﻮﻱ ﻋﻠﻰ ﺍﻟﺮﻣﺰ ﺃﻭ ﺟﻤﻴﻊ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺍﻟﻤﻮﺟﻮﺩﺓ ﻓﻴﻪ‪ .‬ﻓﻲ ﺍﻟﻤﺜﺎﻝ ﺍﻟﺴﺎﺑﻖ‪ ،‬ﻗﺪ ﻳﻔُﻜﻚ‬
‫ﺍﻟﺘﻄﺒﻴﻖﺍﻟﺮﻣﺰ ﺑﺎﺳﺘﺨﺪﺍﻡ ‪ ،Base64‬ﺛﻢ ﻳﻌُﺎﻟﺞ ﻣﻜﻮﻧﻲ "ﺍﻟﻤﺴﺘﺨﺪﻡ" ﻭ"ﺍﻟﺘﺎﺭﻳﺦ" ﻓﻘﻂ‪ .‬ﻓﻲ ﺍﻟﺤﺎﻻﺕ‬
‫ﺍﻟﺘﻲﻳﺤﺘﻮﻱ ﻓﻴﻬﺎ ﺍﻟﺮﻣﺰ ﻋﻠﻰ ﻛﺘﻠﺔ ﺑﻴﺎﻧﺎﺕ ﺛﻨﺎﺉﻴﺔ‪ ،‬ﻗﺪ ﻳﻜﻮﻥ ﺟﺰء ﻛﺒﻴﺮ ﻣﻦ ﻫﺬﻩ ﺍﻟﺒﻴﺎﻧﺎﺕ ﻣﻀُﺎﻓﺎً‪ .‬ﻗﺪ‬
‫ﻳﻜﻮﻥﺟﺰء ﺻﻐﻴﺮ ﻓﻘﻂ ﻣﻨﻬﺎ ﺫﺍ ﺻﻠﺔ ﺑﺎﻟﺘﺤﻘﻖ ﺍﻟﺬﻱ ﻳﺠُﺮﻳﻪ ﺍﻟﺨﺎﺩﻡ ﻋﻠﻰ ﺍﻟﺮﻣﺰ‪ .‬ﻏﺎﻟﺒﺎً ﻣﺎ ﻳﻘُﻠﻞ ﺗﻀﻴﻴﻖ‬
‫ﻧﻄﺎﻕﺍﻷﺟﺰﺍء ﺍﻟﻔﺮﻋﻴﺔ ﺍﻟﻤﻄﻠﻮﺑﺔ ﻣﻦ ﺍﻟﺮﻣﺰ ﺑﺸﻜﻞ ﻛﺒﻴﺮ ﻣﻦ ﻣﻘﺪﺍﺭ ﺍﻹﻧﺘﺮﻭﺑﻴﺎ ﺍﻟﻈﺎﻫﺮﻳﺔ ﻭﺍﻟﺘﻌﻘﻴﺪ ﺍﻟﺬﻱ‬
‫ﻳﺤﺘﻮﻳﻪﺍﻟﺮﻣﺰ‪.‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬ ‫‪212‬‬

‫ﺧﻄﻮﺍﺕﺍﻻﺧﺘﺮﺍﻕ‬

‫‪.1‬ﺍﺣﺼﻞ ﻋﻠﻰ ﺭﻣﺰ ﻭﺍﺣﺪ ﻣﻦ ﺍﻟﺘﻄﺒﻴﻖ‪ ،‬ﻭﻋﺪﻟّﻪ ﺑﺸﻜﻞ ﻣﻨﻬﺠﻲ ﻟﺘﺤﺪﻳﺪ ﻣﺎ ﺇﺫﺍ ﻛﺎﻥ ﺍﻟﺮﻣﺰ ﺑﺄﻛﻤﻠﻪ‬
‫ﻣﻔُﻌﻼّ ًﺃﻡ ﺃﻥ ﺑﻌﺾ ﻣﻜﻮﻧﺎﺗﻪ ﺍﻟﻔﺮﻋﻴﺔ ﻗﺪ ﺗﻢ ﺗﺠﺎﻫﻠﻬﺎ‪ .‬ﺟﺮﺏّ ﺗﻐﻴﻴﺮ ﻗﻴﻤﺔ ﺍﻟﺮﻣﺰ ﺑﺎﻳﺘﺎً ﻭﺍﺣﺪﺍً ﻓﻲ‬
‫ﻛﻞﻣﺮﺓ )ﺃﻭ ﺣﺘﻰ ﺑﺘﺎً ﻭﺍﺣﺪﺍً ﻓﻲ ﻛﻞ ﻣﺮﺓ(‪ ،‬ﺛﻢ ﺃﻋﺪ ﺇﺭﺳﺎﻝ ﺍﻟﺮﻣﺰ ﺍﻟﻤﻌﺪﻝّ ﺇﻟﻰ ﺍﻟﺘﻄﺒﻴﻖ ﻟﺘﺤﺪﻳﺪ ﻣﺎ‬
‫ﺇﺫﺍﻛﺎﻥ ﻻ ﻳﺰﺍﻝ ﻣﻘﺒﻮﻻ‪ ً.‬ﺇﺫﺍ ﻭﺟﺪﺕ ﺃﻥ ﺃﺟﺰﺍء ًﻣﻌﻴﻨﺔ ﻣﻦ ﺍﻟﺮﻣﺰ ﻏﻴﺮ ﻣﻠُﺰﻣﺔ ﺑﺄﻥ ﺗﻜﻮﻥ ﺻﺤﻴﺤﺔ‪،‬‬
‫ﻳﻤﻜﻨﻚﺍﺳﺘﺒﻌﺎﺩﻫﺎ ﻣﻦ ﺃﻱ ﺗﺤﻠﻴﻞ ﺇﺿﺎﻓﻲ‪ ،‬ﻣﻤﺎ ﻗﺪ ﻳﻘُﻠﻞ ﻣﻦ ﺣﺠﻢ ﺍﻟﻌﻤﻞ ﺍﻟﻤﻄﻠﻮﺏ‪ .‬ﻳﻤﻜﻨﻚ‬
‫ﺍﺳﺘﺨﺪﺍﻡﻧﻮﻉ ﺍﻟﺤﻤﻮﻟﺔ "‪ "char frobber‬ﻓﻲ ‪ Burp Intruder‬ﻟﺘﻌﺪﻳﻞ ﻗﻴﻤﺔ ﺍﻟﺮﻣﺰ ﻓﻲ‬
‫ﻣﻮﺿﻊﺣﺮﻑ ﻭﺍﺣﺪ ﻓﻲ ﻛﻞ ﻣﺮﺓ‪ ،‬ﻟﻠﻤﺴﺎﻋﺪﺓ ﻓﻲ ﻫﺬﻩ ﺍﻟﻤﻬﻤﺔ‪.‬‬

‫‪.٢‬ﺳﺠﻞّ ﺍﻟﺪﺧﻮﻝ ﺑﺄﺳﻤﺎء ﻣﺴﺘﺨﺪﻣﻴﻦ ﻣﺨﺘﻠﻔﻴﻦ ﻓﻲ ﺃﻭﻗﺎﺕ ﻣﺨﺘﻠﻔﺔ‪ ،‬ﻭﺳﺠﻞّ ﺍﻟﺮﻣﻮﺯ ﺍﻟﻤﺴﺘﻠﻤﺔ‬
‫ﻣﻦﺍﻟﺨﺎﺩﻡ‪ .‬ﺇﺫﺍ ﻛﺎﻥ ﺍﻟﺘﺴﺠﻴﻞ ﺍﻟﺬﺍﺗﻲ ﻣﺘﺎﺣﺎً ﻭﻳﻤﻜﻨﻚ ﺍﺧﺘﻴﺎﺭ ﺍﺳﻢ ﺍﻟﻤﺴﺘﺨﺪﻡ‪ ،‬ﻓﺴﺠﻞّ ﺍﻟﺪﺧﻮﻝ‬
‫ﺑﺄﺳﻤﺎءﻣﺴﺘﺨﺪﻣﻴﻦ ﻣﺘﺸﺎﺑﻬﺔ ﺗﺤﺘﻮﻱ ﻋﻠﻰ ﺍﺧﺘﻼﻓﺎﺕ ﺑﺴﻴﻄﺔ ﺑﻴﻨﻬﺎ‪ ،‬ﻣﺜﻞ ‪، AAAC، AABA‬‬
‫‪ ،A، AA، AAA، AAAA، AAAB‬ﻭﻫﻜﺬﺍ‪ .‬ﺇﺫﺍ ﺗﻢ ﺇﺭﺳﺎﻝ ﺑﻴﺎﻧﺎﺕ ﺃﺧﺮﻯ ﺧﺎﺻﺔ ﺑﺎﻟﻤﺴﺘﺨﺪﻡ ﻋﻨﺪ‬
‫ﺗﺴﺠﻴﻞﺍﻟﺪﺧﻮﻝ ﺃﻭ ﺗﺨﺰﻳﻨﻬﺎ ﻓﻲ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ )ﻣﺜﻞ ﻋﻨﻮﺍﻥ ﺍﻟﺒﺮﻳﺪ ﺍﻹﻟﻜﺘﺮﻭﻧﻲ(‬
‫‪،‬ﻓﻘﻢ ﺑﺈﺟﺮﺍء ﻣﻤﺎﺛﻞ ﻟﺘﻌﺪﻳﻞ ﺗﻠﻚ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺑﺎﻧﺘﻈﺎﻡ‪ ،‬ﻭﺳﺠﻞّ ﺍﻟﺮﻣﻮﺯ ﺍﻟﻤﺴﺘﻠﻤﺔ ﺑﻌﺪ ﺗﺴﺠﻴﻞ‬
‫ﺍﻟﺪﺧﻮﻝ‪.‬‬
‫‪.3‬ﻗﻢ ﺑﺘﺤﻠﻴﻞ ﺍﻟﺮﻣﻮﺯ ﺑﺤﺜﺎً ﻋﻦ ﺃﻱ ﺍﺭﺗﺒﺎﻃﺎﺕ ﻳﺒﺪﻭ ﺃﻧﻬﺎ ﻣﺮﺗﺒﻄﺔ ﺑﺎﺳﻢ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻭﺍﻟﺒﻴﺎﻧﺎﺕ‬
‫ﺍﻷﺧﺮﻯﺍﻟﺘﻲ ﻳﻤﻜﻦ ﻟﻠﻤﺴﺘﺨﺪﻡ ﺍﻟﺘﺤﻜﻢ ﻓﻴﻬﺎ‪.‬‬
‫‪.٤‬ﺣﻠﻞ ﺍﻟﺮﻣﻮﺯ ﺑﺤﺜﺎً ﻋﻦ ﺃﻱ ﺗﺮﻣﻴﺰ ﺃﻭ ﺗﺸﻮﻳﺶ ﻗﺎﺑﻞ ﻟﻠﻜﺸﻒ‪ .‬ﺇﺫﺍ ﺍﺣﺘﻮﻯ ﺍﺳﻢ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻋﻠﻰ‬
‫ﺗﺴﻠﺴﻞﻣﻦ ﻧﻔﺲ ﺍﻟﺤﺮﻑ‪ ،‬ﻓﺎﺑﺤﺚ ﻋﻦ ﺗﺴﻠﺴﻞ ﺃﺣﺮﻑ ﻣﻤﺎﺛﻞ ﻓﻲ ﺍﻟﺮﻣﺰ‪ ،‬ﻓﻘﺪ ﻳﺸﻴﺮ ﺫﻟﻚ‬
‫ﺇﻟﻰﺍﺳﺘﺨﺪﺍﻡ ﺗﺸﻮﻳﺶ ‪ .XOR‬ﺍﺑﺤﺚ ﻋﻦ ﺗﺴﻠﺴﻼﺕ ﻓﻲ ﺍﻟﺮﻣﺰ ﺗﺤﺘﻮﻱ ﻓﻘﻂ ﻋﻠﻰ ﺃﺣﺮﻑ‬
‫ﺳﺪﺍﺳﻴﺔﻋﺸﺮﻳﺔ‪ ،‬ﻣﻤﺎ ﻗﺪ ﻳﺸﻴﺮ ﺇﻟﻰ ﺗﺮﻣﻴﺰ ﺳﺪﺍﺳﻲ ﻋﺸﺮﻱ ﻟﺴﻠﺴﻠﺔ ‪ ASCII‬ﺃﻭ ﻣﻌﻠﻮﻣﺎﺕ‬
‫ﺃﺧﺮﻯ‪.‬ﺍﺑﺤﺚ ﻋﻦ ﺍﻟﺘﺴﻠﺴﻼﺕ ﺍﻟﺘﻲ ﺗﻨﺘﻬﻲ ﺑﻌﻼﻣﺔ ﻳﺴﺎﻭﻱ ﻭ‪/‬ﺃﻭ ﺍﻟﺘﻲ ﺗﺤﺘﻮﻱ ﻓﻘﻂ ﻋﻠﻰ ﺃﺣﺮﻑ‬
‫‪ Base64‬ﺍﻷﺧﺮﻯ ﺍﻟﺼﺎﻟﺤﺔ‪ :‬ﻣﻦ ‪ a‬ﺇﻟﻰ ‪ ،z‬ﻣﻦ ‪ A‬ﺇﻟﻰ ‪ ،Z‬ﻣﻦ ‪ 0‬ﺇﻟﻰ ‪ ،+ ،9‬ﻭ‪./‬‬

‫‪.٥‬ﺇﺫﺍ ﻛﺎﻥ ﻣﻦ ﺍﻟﻤﻤﻜﻦ ﺇﺟﺮﺍء ﻫﻨﺪﺳﺔ ﻋﻜﺴﻴﺔ ﻷﻱ ﻣﻌﻨﻰ ﻣﻦ ﻋﻴﻨﺔ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ‪ ،‬ﻓﻔﻜﺮ ﻓﻴﻤﺎ ﺇﺫﺍ‬
‫ﻛﺎﻧﺖﻟﺪﻳﻚ ﻣﻌﻠﻮﻣﺎﺕ ﻛﺎﻓﻴﺔ ﻟﻤﺤﺎﻭﻟﺔ ﺗﺨﻤﻴﻦ ﺍﻟﺮﻣﻮﺯ ﺍﻟﺼﺎﺩﺭﺓ ﻣﺆﺧﺮﺍً ﻟﻤﺴﺘﺨﺪﻣﻲ ﺍﻟﺘﻄﺒﻴﻖ‬
‫ﺍﻵﺧﺮﻳﻦ‪.‬ﺍﺑﺤﺚ ﻋﻦ ﺻﻔﺤﺔ ﻓﻲ ﺍﻟﺘﻄﺒﻴﻖ ﺗﻌﺘﻤﺪ ﻋﻠﻰ ﺍﻟﺠﻠﺴﺔ‪ ،‬ﻣﺜﻞ ﺻﻔﺤﺔ ﺗﻌﺮﺽ ﺭﺳﺎﻟﺔ‬
‫ﺧﻄﺄﺃﻭ ﺇﻋﺎﺩﺓ ﺗﻮﺟﻴﻪ ﺇﻟﻰ ﻣﻜﺎﻥ ﺁﺧﺮ ﺇﺫﺍ ﺗﻢ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻴﻬﺎ ﺑﺪﻭﻥ ﺟﻠﺴﺔ ﺻﺎﻟﺤﺔ‪ .‬ﺛﻢ ﺍﺳﺘﺨﺪﻡ‬
‫ﺃﺩﺍﺓﻣﺜﻞ ‪ Burp Intruder‬ﻹﺭﺳﺎﻝ ﻋﺪﺩ ﻛﺒﻴﺮ ﻣﻦ ﺍﻟﻄﻠﺒﺎﺕ ﺇﻟﻰ ﻫﺬﻩ ﺍﻟﺼﻔﺤﺔ ﺑﺎﺳﺘﺨﺪﺍﻡ‬
‫ﺭﻣﻮﺯﻣﺨُﻤﻨَّﺔ‪ .‬ﺭﺍﻗﺐ ﺍﻟﻨﺘﺎﺉﺞ ﺑﺤﺜﺎً ﻋﻦ ﺃﻱ ﺣﺎﻻﺕ ﻳﺘﻢ ﻓﻴﻬﺎ ﺗﺤﻤﻴﻞ ﺍﻟﺼﻔﺤﺔ ﺑﺸﻜﻞ ﺻﺤﻴﺢ‪،‬‬
‫ﻣﻤﺎﻳﺸﻴﺮ ﺇﻟﻰ ﺭﻣﺰ ﺟﻠﺴﺔ ﺻﺎﻟﺢ‪.‬‬

‫ﺟﺮﺑﻬﺎ!‬

‫‪/329/ http://mdsec.net/auth/331/‬‬
‫‪/auth/321/ http://mdsec.net/auth‬‬
‫‪http://mdsec.net‬‬
‫‪213‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬

‫ﺍﻟﺮﻣﻮﺯﺍﻟﻘﺎﺑﻠﺔ ﻟﻠﺘﻨﺒﺆ‬
‫ﺑﻌﺾﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ ﻻ ﺗﺤﺘﻮﻱ ﻋﻠﻰ ﺃﻱ ﺑﻴﺎﻧﺎﺕ ﺫﺍﺕ ﻣﻌﻨﻰ ﺗﺮﺑﻄﻬﺎ ﺑﻤﺴﺘﺨﺪﻡ ﻣﻌﻴﻦ‪ .‬ﻭﻣﻊ ﺫﻟﻚ‪،‬‬
‫ﻳﻤُﻜﻦﺗﺨﻤﻴﻨﻬﺎ ﻻﺣﺘﻮﺍﺉﻬﺎ ﻋﻠﻰ ﺗﺴﻠﺴﻼﺕ ﺃﻭ ﺃﻧﻤﺎﻁ ﺗﻤُﻜﻦّ ﺍﻟﻤﻬﺎﺟﻢ ﻣﻦ ﺍﺳﺘﻘﺮﺍء ﻋﻴﻨﺔ ﻣﻦ ﺍﻟﺮﻣﻮﺯ‬
‫ﻟﻠﻌﺜﻮﺭﻋﻠﻰ ﺭﻣﻮﺯ ﺻﺎﻟﺤﺔ ﺃﺧﺮﻯ ﺃﺻﺪﺭﻫﺎ ﺍﻟﺘﻄﺒﻴﻖ ﻣﺆﺧﺮﺍً‪ .‬ﺣﺘﻰ ﻟﻮ ﺗﻀﻤﻦ ﺍﻻﺳﺘﻘﺮﺍء ﺑﻌﺾ ﺍﻟﺘﺠﺮﺑﺔ‬
‫ﻭﺍﻟﺨﻄﺄ)ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﺗﺨﻤﻴﻨﺎً ﺻﺤﻴﺤﺎً ﻭﺍﺣﺪﺍً ﻟﻜﻞ ‪ 1000‬ﻣﺤﺎﻭﻟﺔ(‪ ،‬ﻓﺴﻴﻈﻞ ﻫﺬﺍ ﻳﻤُﻜﻦّ‬
‫ﺍﻟﻬﺠﻮﻡﺍﻵﻟﻲ ﻣﻦ ﺗﺤﺪﻳﺪ ﺃﻋﺪﺍﺩ ﻛﺒﻴﺮﺓ ﻣﻦ ﺍﻟﺮﻣﻮﺯ ﺍﻟﺼﺎﻟﺤﺔ ﻓﻲ ﻓﺘﺮﺓ ﺯﻣﻨﻴﺔ ﻗﺼﻴﺮﺓ ﻧﺴﺒﻴﺎً‪.‬‬

‫ﻗﺪﻳﻜﻮﻥ ﺍﻛﺘﺸﺎﻑ ﺍﻟﺜﻐﺮﺍﺕ ﺍﻷﻣﻨﻴﺔ ﺍﻟﻤﺘﻌﻠﻘﺔ ﺑﺘﻮﻟﻴﺪ ﺍﻟﺮﻣﻮﺯ ﺍﻟﻘﺎﺑﻠﺔ ﻟﻠﺘﻨﺒﺆ ﺃﺳﻬﻞ ﺑﻜﺜﻴﺮ ﻓﻲ‬
‫ﺍﻟﺘﻄﺒﻴﻘﺎﺕﺍﻟﺘﺠﺎﺭﻳﺔ ﻹﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺎﺕ‪ ،‬ﻣﺜﻞ ﺧﻮﺍﺩﻡ ﺍﻟﻮﻳﺐ ﺃﻭ ﻣﻨﺼﺎﺕ ﺗﻄﺒﻴﻘﺎﺕ ﺍﻟﻮﻳﺐ‪ ،‬ﻣﻘﺎﺭﻧﺔ ً‬
‫ﺑﺎﻟﺘﻄﺒﻴﻘﺎﺕﺍﻟﻤﺼﻤﻤﺔ ﺧﺼﻴﺼﺎً‪ .‬ﻋﻨﺪ ﺍﺳﺘﻬﺪﺍﻑ ﺁﻟﻴﺔ ﺇﺩﺍﺭﺓ ﺟﻠﺴﺎﺕ ﻣﺼﻤﻤﺔ ﺧﺼﻴﺼﺎً ﻋﻦ ﺑﻌُﺪ‪ ،‬ﻗﺪ‬
‫ﺗﻜﻮﻥﻋﻴﻨﺔ ﺍﻟﺮﻣﻮﺯ ﺍﻟﺼﺎﺩﺭﺓ ﻣﺤﺪﻭﺩﺓ ﺑﺴﻌﺔ ﺍﻟﺨﺎﺩﻡ‪ ،‬ﻭﻧﺸﺎﻁ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺍﻵﺧﺮﻳﻦ‪ ،‬ﻭﻋﺮﺽ ﺍﻟﻨﻄﺎﻕ‬
‫ﺍﻟﺘﺮﺩﺩﻱ‪،‬ﻭﺯﻣﻦ ﻭﺻﻮﻝ ﺍﻟﺸﺒﻜﺔ‪ ،‬ﻭﻣﺎ ﺇﻟﻰ ﺫﻟﻚ‪ .‬ﺃﻣﺎ ﻓﻲ ﺑﻴﺉﺔ ﺍﻟﻤﺨﺘﺒﺮ‪ ،‬ﻓﻴﻤﻜﻨﻚ ﺇﻧﺸﺎء ﻣﻼﻳﻴﻦ ﻣﻦ‬
‫ﻋﻴﻨﺎﺕﺍﻟﺮﻣﻮﺯ ﺑﺴﺮﻋﺔ‪ ،‬ﻣﺘﺴﻠﺴﻠﺔ ﺑﺪﻗﺔ ﻭﻣﺆﺭﺧﺔ ﺯﻣﻨﻴﺎً‪ ،‬ﻭﻳﻤﻜﻨﻚ ﺍﻟﺘﺨﻠﺺ ﻣﻦ ﺍﻟﺘﺪﺍﺧﻞ ﺍﻟﺬﻱ ﻳﺴﺒﺒﻪ‬
‫ﺍﻟﻤﺴﺘﺨﺪﻣﻮﻥﺍﻵﺧﺮﻭﻥ‪.‬‬

‫ﻓﻲﺃﺑﺴﻂ ﺍﻟﺤﺎﻻﺕ ﻭﺃﻛﺜﺮﻫﺎ ﻋﺮﺿﺔ ﻟﻠﺨﻄﺮ‪ ،‬ﻗﺪ ﻳﺴﺘﺨﺪﻡ ﺍﻟﺘﻄﺒﻴﻖ ﺭﻗﻤﺎً ﺗﺴﻠﺴﻠﻴﺎً ﺑﺴﻴﻄﺎً ﻛﺮﻣﺰ‬
‫ﻟﻠﺠﻠﺴﺔ‪.‬ﻓﻲ ﻫﺬﻩ ﺍﻟﺤﺎﻟﺔ‪ ،‬ﻣﺎ ﻋﻠﻴﻚ ﺳﻮﻯ ﺍﻟﺤﺼﻮﻝ ﻋﻠﻰ ﻋﻴﻨﺔ ﻣﻦ ﺭﻣﺰﻳﻦ ﺃﻭ ﺛﻼﺛﺔ ﻗﺒﻞ ﺷﻦ ﻫﺠﻮﻡ‬
‫ﻳﻠﺘﻘﻂﺑﺴﺮﻋﺔ ‪ %100‬ﻣﻦ ﺍﻟﺠﻠﺴﺎﺕ ﺍﻟﺼﺎﻟﺤﺔ ﺣﺎﻟﻴﺎً‪.‬‬

‫ﻳﻮﺿﺢﺍﻟﺸﻜﻞ ‪ 1-7‬ﺍﺳﺘﺨﺪﺍﻡ ﺃﺩﺍﺓ ‪ Burp Intruder‬ﻟﺘﺪﻭﻳﺮ ﺁﺧﺮ ﺭﻗﻤﻴﻦ ﻣﻦ ﺭﻣﺰ ﺟﻠﺴﺔ ﻣﺘﺴﻠﺴﻠﺔ‬
‫ﻟﻠﻌﺜﻮﺭﻋﻠﻰ ﻗﻴﻢ ﻻ ﺗﺰﺍﻝ ﺍﻟﺠﻠﺴﺔ ﻧﺸﻄﺔ ﻓﻴﻬﺎ ﻭﻗﺎﺑﻠﺔ ﻟﻼﺧﺘﺮﺍﻕ‪ .‬ﻓﻲ ﻫﺬﻩ ﺍﻟﺤﺎﻟﺔ‪ ،‬ﻳﻌُﺪ ﻃﻮﻝ ﺍﺳﺘﺠﺎﺑﺔ‬
‫ﺍﻟﺨﺎﺩﻡﻣﺆﺷﺮﺍً ﻣﻮﺛﻮﻗﺎً ﻋﻠﻰ ﻭﺟﻮﺩ ﺟﻠﺴﺔ ﺻﺎﻟﺤﺔ‪ .‬ﻛﻤﺎ ﺍﺳﺘﺨُﺪﻣﺖ ﻣﻴﺰﺓ ‪ Extract grep‬ﻟﻌﺮﺽ ﺍﺳﻢ‬
‫ﺍﻟﻤﺴﺘﺨﺪﻡﺍﻟﻤﺴُﺠﻞ ﺍﻟﺪﺧﻮﻝ ﻟﻜﻞ ﺟﻠﺴﺔ‪.‬‬

‫ﻓﻲﺣﺎﻻﺕ ﺃﺧﺮﻯ‪ ،‬ﻗﺪ ﺗﺤﺘﻮﻱ ﺭﻣﻮﺯ ﺍﻟﺘﻄﺒﻴﻖ ﻋﻠﻰ ﺗﺴﻠﺴﻼﺕ ﺃﻛﺜﺮ ﺗﻔﺼﻴﻼً ﺗﺘﻄﻠﺐ ﺟﻬﺪﺍً‬
‫ﻻﻛﺘﺸﺎﻓﻬﺎ‪.‬ﺃﻧﻮﺍﻉ ﺍﻻﺧﺘﻼﻓﺎﺕ ﺍﻟﻤﺤﺘﻤﻠﺔ ﺍﻟﺘﻲ ﻗﺪ ﺗﻮﺍﺟﻬﻬﺎ ﻫﻨﺎ ﻣﻔﺘﻮﺣﺔ‪ ،‬ﻟﻜﻦ ﺧﺒﺮﺓ ﺍﻟﻤﺆﻟﻔﻴﻦ ﻓﻲ ﻫﺬﺍ‬
‫ﺍﻟﻤﺠﺎﻝﺗﺸﻴﺮ ﺇﻟﻰ ﺃﻥ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ ﺍﻟﻤﺘﻮﻗﻌﺔ ﺗﻨﺸﺄ ﻋﺎﺩﺓ ًﻣﻦ ﺛﻼﺛﺔ ﻣﺼﺎﺩﺭ ﻣﺨﺘﻠﻔﺔ‪:‬‬

‫ﺍﻟﺘﺴﻠﺴﻼﺕﺍﻟﻤﺨﻔﻴﺔ‬ ‫‪-‬‬

‫ﺍﻻﻋﺘﻤﺎﺩﻋﻠﻰ ﺍﻟﻮﻗﺖ‬ ‫‪-‬‬

‫ﺗﻮﻟﻴﺪﺃﺭﻗﺎﻡ ﻋﺸﻮﺍﺉﻴﺔ ﺿﻌﻴﻔﺔ‬ ‫‪-‬‬

‫ﻭﺳﻨﻨﻈﺮﺇﻟﻰ ﻛﻞ ﻣﻦ ﻫﺬﻩ ﺍﻟﻤﺠﺎﻻﺕ ﻋﻠﻰ ﺣﺪﺓ‪.‬‬

‫ﺍﻟﺘﺴﻠﺴﻼﺕﺍﻟﻤﺨﻔﻴﺔ‬
‫ﻣﻦﺍﻟﺸﺎﺉﻊ ﻣﻮﺍﺟﻬﺔ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ ﺍﻟﺘﻲ ﻻ ﻳﻤﻜﻦ ﺍﻟﺘﻨﺒﺆ ﺑﻬﺎ ﺑﺴﻬﻮﻟﺔ ﻋﻨﺪ ﺗﺤﻠﻴﻠﻬﺎ ﻓﻲ ﺷﻜﻠﻬﺎ ﺍﻟﺨﺎﻡ‬
‫ﻭﻟﻜﻨﻬﺎﺗﺤﺘﻮﻱ ﻋﻠﻰ ﺗﺴﻠﺴﻼﺕ ﺗﻜﺸﻒ ﻋﻦ ﻧﻔﺴﻬﺎ ﻋﻨﺪﻣﺎ ﻳﺘﻢ ﻓﻚ ﺗﺸﻔﻴﺮ ﺍﻟﺮﻣﻮﺯ ﺃﻭ ﺗﻔﺮﻳﻐﻬﺎ ﺑﺸﻜﻞ‬
‫ﻣﻨﺎﺳﺐ‪.‬‬
 ‫‪-‬‬‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‬ ‫‪214‬‬

‫ﺍﻟﺸﻜﻞ‪:1-7‬ﻫﺠﻮﻡ ﻻﻛﺘﺸﺎﻑ ﺍﻟﺠﻠﺴﺎﺕ ﺍﻟﺼﺎﻟﺤﺔ ﺣﻴﺚ ﻳﻜﻮﻥ ﺭﻣﺰ ﺍﻟﺠﻠﺴﺔ ﻗﺎﺑﻼ ًﻟﻠﺘﻨﺒﺆ‬

‫ﺧﺬﺑﻌﻴﻦ ﺍﻻﻋﺘﺒﺎﺭ ﺳﻠﺴﻠﺔ ﺍﻟﻘﻴﻢ ﺍﻟﺘﺎﻟﻴﺔ‪ ،‬ﻭﺍﻟﺘﻲ ﺗﺸﻜﻞ ﺃﺣﺪ ﻣﻜﻮﻧﺎﺕ ﺭﻣﺰ ﺍﻟﺠﻠﺴﺔ ﺍﻟﻤﻨﻈﻤﺔ‪:‬‬

‫ﻟﻮﺟﻴﻪﻓﻴﺠﺎ‬
‫‪Ls3Ajg‬‬
‫‪xpKr+A‬‬
‫‪XleXYg‬‬
‫‪9hyCzA‬‬
‫ﺟﻴﻔﻮﻧﺞ‬
‫ﺟﺎﺯﻭﺍ‬

‫ﻻﻳﻼُﺣﻆ ﺃﻱ ﻧﻤﻂ ﻭﺍﺿﺢ؛ ﻭﻣﻊ ﺫﻟﻚ‪ ،‬ﻳﺸُﻴﺮ ﻓﺤﺺ ﺳﺮﻳﻊ ﺇﻟﻰ ﺃﻥ ﺍﻟﺮﻣﻮﺯ ﻗﺪ ﺗﺤﺘﻮﻱ ﻋﻠﻰ ﺑﻴﺎﻧﺎﺕ‬
‫ﻣﺮُﻣﺰَّﺓﺑﺘﻘﻨﻴﺔ ‪ .Base64‬ﺑﺎﻹﺿﺎﻓﺔ ﺇﻟﻰ ﺍﻷﺣﺮﻑ ﺍﻷﺑﺠﺪﻳﺔ ﻭﺍﻟﺮﻗﻤﻴﺔ ﺍﻟﻤﺨﺘﻠﻄﺔ‪ ،‬ﻳﻮﺟﺪ ﺭﻣﺰ ‪ ،+‬ﻭﻫﻮ‬
‫ﺻﺎﻟﺢﺃﻳﻀﺎً ﻓﻲ ﺳﻠﺴﻠﺔ ﻧﺼﻴﺔ ﻣﺮُﻣﺰَّﺓ ﺑﺘﻘﻨﻴﺔ ‪ .Base64‬ﻳﻜﺸﻒ ﻓﺤﺺ ﺍﻟﺮﻣﻮﺯ ﻋﺒﺮ ﻣﻔُﻜﻚِّ ﺗﺸﻔﻴﺮ‬
‫‪ Base64‬ﻋﻦ ﻣﺎ ﻳﻠﻲ‪:‬‬

‫‪ --‬ﺩﻭﻻﺭ‬
‫‪ .‬ﺇﻱ‬
‫‪Æ'»ø‬‬
‫^ﻭ ﺏ‬
‫ﺃﻭﻩ‬
‫؟ﺍﻥ‪6‬‬
‫‪%¦Y‬‬
‫‪215‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬

‫ﺗﺒﺪﻭﻫﺬﻩ ﺍﻟﺴﻼﺳﻞ ﻏﻴﺮ ﻣﻔﻬﻮﻣﺔ‪ ،‬ﻭﺗﺤﺘﻮﻱ ﺃﻳﻀﺎً ﻋﻠﻰ ﺃﺣﺮﻑ ﻏﻴﺮ ﻗﺎﺑﻠﺔ ﻟﻠﻄﺒﺎﻋﺔ‪ .‬ﻳﺸﻴﺮ ﻫﺬﺍ ﻋﺎﺩﺓ ًﺇﻟﻰ‬
‫ﺃﻧﻚﺗﺘﻌﺎﻣﻞ ﻣﻊ ﺑﻴﺎﻧﺎﺕ ﺛﻨﺎﺉﻴﺔ ﻭﻟﻴﺲ ﻧﺼﺎً ﺑﺘﻨﺴﻴﻖ ‪ .ASCII‬ﻳﺆﺩﻱ ﺗﺤﻮﻳﻞ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺍﻟﻤﻔُﻜﻜﺔ ﺇﻟﻰ‬
‫ﺃﺭﻗﺎﻡﺳﺪﺍﺳﻴﺔ ﻋﺸﺮﻳﺔ ﺇﻟﻰ ﻣﺎ ﻳﻠﻲ‪:‬‬

‫‪9708D524‬‬
‫‪2ECDC08E‬‬
‫‪C692ABF8‬‬
‫‪5E579762‬‬
‫‪F61C82CC‬‬
‫‪8DE16E36‬‬
‫‪25A659A0‬‬

‫ﻻﻳﻮﺟﺪ ﻧﻤﻂ ﻭﺍﺿﺢ ﺣﺘﻰ ﺍﻵﻥ‪ .‬ﻭﻣﻊ ﺫﻟﻚ‪ ،‬ﺇﺫﺍ ﻃﺮﺣﺖ َﻛﻞ ﺭﻗﻢ ﻣﻦ ﺍﻟﺮﻗﻢ ﺍﻟﺴﺎﺑﻖ‪ ،‬ﻓﺴﺘﺤﺼﻞ ﻋﻠﻰ‬
‫ﺍﻟﻨﺘﻴﺠﺔﺍﻟﺘﺎﻟﻴﺔ‪:‬‬

‫‪FF97C4EB6A‬‬
‫‪97C4EB6A‬‬
‫‪FF97C4EB6A‬‬
‫‪97C4EB6A‬‬
‫‪FF97C4EB6A‬‬
‫‪FF97C4EB6A‬‬

‫ﻳﻜﺸﻒﻫﺬﺍ ﻓﻮﺭﺍً ﻋﻦ ﺍﻟﻨﻤﻂ ﺍﻟﻤﺨﻔﻲ‪ .‬ﺗﻀﻴﻒ ﺍﻟﺨﻮﺍﺭﺯﻣﻴﺔ ﺍﻟﻤﺴﺘﺨﺪﻣﺔ ﻟﺘﻮﻟﻴﺪ ﺍﻟﺮﻣﻮﺯ ‪x97C4EB6A‬‬
‫‪0‬ﺇﻟﻰ ﺍﻟﻘﻴﻤﺔ ﺍﻟﺴﺎﺑﻘﺔ‪ ،‬ﻭﺗﺨﺘﺼﺮ ﺍﻟﻨﺘﻴﺠﺔ ﺇﻟﻰ ﺭﻗﻢ ‪ 32‬ﺑﺖ‪ ،‬ﺛﻢ ﺗﺸُﻔﺮّ ﻫﺬﻩ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺍﻟﺜﻨﺎﺉﻴﺔ‬
‫ﺑﺎﺳﺘﺨﺪﺍﻡ‪ Base64‬ﻟﻠﺴﻤﺎﺡ ﺑﻨﻘﻠﻬﺎ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺑﺮﻭﺗﻮﻛﻮﻝ ‪ HTTP‬ﺍﻟﻨﺼﻲ‪ .‬ﺑﺎﺳﺘﺨﺪﺍﻡ ﻫﺬﻩ ﺍﻟﻤﻌﺮﻓﺔ‪،‬‬
‫ﻳﻤﻜﻨﻚﺑﺴﻬﻮﻟﺔ ﻛﺘﺎﺑﺔ ﻧﺺ ﺑﺮﻣﺠﻲ ﻹﻧﺘﺎﺝ ﺳﻠﺴﻠﺔ ﺍﻟﺮﻣﻮﺯ ﺍﻟﺘﻲ ﺳﻴﻨُﺘﺠﻬﺎ ﺍﻟﺨﺎﺩﻡ ﻻﺣﻘﺎً‪ ،‬ﻭﺍﻟﺴﻠﺴﻠﺔ‬
‫ﺍﻟﺘﻲﺃﻧﺘﺠﻬﺎ ﻗﺒﻞ ﺍﻟﻌﻴﻨﺔ ﺍﻟﻤﻠﺘﻘﻄﺔ‪.‬‬

‫ﺍﻻﻋﺘﻤﺎﺩﻋﻠﻰ ﺍﻟﻮﻗﺖ‬
‫ﺗﺴﺘﺨﺪﻡﺑﻌﺾ ﺧﻮﺍﺩﻡ ﺍﻟﻮﻳﺐ ﻭﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺧﻮﺍﺭﺯﻣﻴﺎﺕ ﻟﺘﻮﻟﻴﺪ ﺭﻣﻮﺯ ﺟﻠﺴﺎﺕ‪ ،‬ﺣﻴﺚ ﺗﻌﺘﻤﺪ ﻋﻠﻰ‬
‫ﻭﻗﺖﺍﻟﺘﻮﻟﻴﺪ ﻛﻤﺪﺧﻞ ﻟﻘﻴﻤﺔ ﺍﻟﺮﻣﺰ‪ .‬ﺇﺫﺍ ﻟﻢ ﺗﺪُﻣﺞ ﺇﻧﺘﺮﻭﺑﻴﺎ ﺃﺧﺮﻯ ﻛﺎﻓﻴﺔ ﻓﻲ ﺍﻟﺨﻮﺍﺭﺯﻣﻴﺔ‪ ،‬ﻓﻘﺪ ﺗﺘﻤﻜﻦ‬
‫ﻣﻦﺍﻟﺘﻨﺒﺆ ﺑﺮﻣﻮﺯ ﻣﺴﺘﺨﺪﻣﻴﻦ ﺁﺧﺮﻳﻦ‪ .‬ﻣﻊ ﺃﻥ ﺃﻱ ﺗﺴﻠﺴﻞ ﻣﻌﻴﻦ ﻣﻦ ﺍﻟﺮﻣﻮﺯ ﻗﺪ ﻳﺒﺪﻭ ﻋﺸﻮﺍﺉﻴﺎً‬
‫ﺑﻤﻔﺮﺩﻩ‪،‬ﺇﻻ ﺃﻥ ﺍﻟﺘﺴﻠﺴﻞ ﻧﻔﺴﻪ‪ ،‬ﻣﻘﺘﺮﻧﺎً ﺑﻤﻌﻠﻮﻣﺎﺕ ﺣﻮﻝ ﻭﻗﺖ ﺗﻮﻟﻴﺪ ﻛﻞ ﺭﻣﺰ‪ ،‬ﻗﺪ ﻳﺤﺘﻮﻱ ﻋﻠﻰ ﻧﻤﻂ‬
‫ﻭﺍﺿﺢ‪.‬ﻓﻲ ﺗﻄﺒﻴﻖ ﻣﺰﺩﺣﻢ ﻳﻨُﺸﺊ ﻋﺪﺩﺍً ﻛﺒﻴﺮﺍً ﻣﻦ ﺍﻟﺠﻠﺴﺎﺕ ﻛﻞ ﺛﺎﻧﻴﺔ‪ ،‬ﻗﺪ ﻳﻨﺠﺢ ﻫﺠﻮﻡ ﻣﺒُﺮﻣﺞ ﻓﻲ‬
‫ﺗﺤﺪﻳﺪﻋﺪﺩ ﻛﺒﻴﺮ ﻣﻦ ﺭﻣﻮﺯ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺍﻵﺧﺮﻳﻦ‪.‬‬

‫ﻋﻨﺪﺍﺧﺘﺒﺎﺭ ﺗﻄﺒﻴﻖ ﺍﻟﻮﻳﺐ ﺍﻟﺨﺎﺹ ﺑﺒﺎﺉﻊ ﺍﻟﺘﺠﺰﺉﺔ ﻋﺒﺮ ﺍﻹﻧﺘﺮﻧﺖ‪ ،‬ﻭﺍﺟﻪ ﺍﻟﻤﺆﻟﻔﻮﻥ ﺍﻟﺘﺴﻠﺴﻞ‬
‫ﺍﻟﺘﺎﻟﻲﻣﻦ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ‪:‬‬

‫‪3124538-1172764258718‬‬
‫‪3124539-1172764259062‬‬
‫‪3124540-1172764259281‬‬
‫‪3124541-1172764259734‬‬
‫‪3124542-1172764260046‬‬
‫‪3124543-1172764260156‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬ ‫‪216‬‬

‫‪3124544-1172764260296‬‬
‫‪3124545-1172764260421‬‬
‫‪3124546-1172764260812‬‬
‫‪3124547-1172764260890‬‬

‫ﻳﺘﻜﻮﻥﻛﻞ ﺭﻣﺰ ﺑﻮﺿﻮﺡ ﻣﻦ ﻣﻜﻮﻧﻴﻦ ﺭﻗﻤﻴﻴﻦ ﻣﻨﻔﺼﻠﻴﻦ‪ .‬ﻳﺘﺒﻊ ﺍﻟﺮﻗﻢ ﺍﻷﻭﻝ ﺗﺴﻠﺴﻼً ﺗﺰﺍﻳﺪﻳﺎً ﺑﺴﻴﻄﺎً‬
‫ﻭﻳﺴﻬﻞﺍﻟﺘﻨﺒﺆ ﺑﻪ‪ .‬ﺃﻣﺎ ﺍﻟﺮﻗﻢ ﺍﻟﺜﺎﻧﻲ ﻓﻴﺰﺩﺍﺩ ﺑﻤﻘﺪﺍﺭ ﻣﺘﻔﺎﻭﺕ ﻓﻲ ﻛﻞ ﻣﺮﺓ‪ .‬ﻳﻜﺸﻒ ﺣﺴﺎﺏ ﺍﻟﻔﺮﻭﻕ‬
‫ﺑﻴﻦﻗﻴﻤﺘﻪ ﻓﻲ ﻛﻞ ﺭﻣﺰ ﻣﺘﺘﺎﻟﻲ ﻋﻦ ﺍﻟﺘﺎﻟﻲ‪:‬‬

‫‪344‬‬
‫‪219‬‬
‫‪453‬‬
‫‪312‬‬
‫‪110‬‬
‫‪140‬‬
‫‪125‬‬
‫‪391‬‬
‫‪78‬‬

‫ﻻﻳﺒﺪﻭ ﺃﻥ ﺍﻟﺘﺴﻠﺴﻞ ﻳﺤﺘﻮﻱ ﻋﻠﻰ ﻧﻤﻂ ﻳﻤﻜﻦ ﺍﻟﺘﻨﺒﺆ ﺑﻪ ﺑﺸﻜﻞ ﻣﻮﺛﻮﻕ‪ .‬ﻭﻣﻊ ﺫﻟﻚ‪ ،‬ﻣﻦ ﺍﻟﻤﻤﻜﻦ‬
‫ﺑﻮﺿﻮﺡﺍﺧﺘﺮﺍﻕ ﻧﻄﺎﻕ ﺍﻷﺭﻗﺎﻡ ﺫﻱ ﺍﻟﺼﻠﺔ ﺑﺎﺳﺘﺨﺪﺍﻡ ﻫﺠﻮﻡ ﺁﻟﻲ ﻻﻛﺘﺸﺎﻑ ﺍﻟﻘﻴﻢ ﺍﻟﺼﺤﻴﺤﺔ ﻓﻲ‬
‫ﺍﻟﺘﺴﻠﺴﻞ‪.‬ﻗﺒﻞ ﻣﺤﺎﻭﻟﺔ ﻫﺬﺍ ﺍﻟﻬﺠﻮﻡ‪ ،‬ﻧﻨﺘﻈﺮ ﺑﻀﻊ ﺩﻗﺎﺉﻖ ﻭﻧﺠﻤﻊ ﺳﻠﺴﻠﺔ ﺃﺧﺮﻯ ﻣﻦ ﺍﻟﺮﻣﻮﺯ‪:‬‬

‫‪3124553-1172764800468‬‬
‫‪3124554-1172764800609‬‬
‫‪3124555-1172764801109‬‬
‫‪3124556-1172764801406‬‬
‫‪3124557-1172764801703‬‬
‫‪3124558-1172764802125‬‬
‫‪3124559-1172764802500‬‬
‫‪3124560-1172764802656‬‬
‫‪3124561-1172764803125‬‬
‫‪3124562-1172764803562‬‬

‫ﻋﻨﺪﻣﻘﺎﺭﻧﺔ ﺍﻟﺘﺴﻠﺴﻞ ﺍﻟﺜﺎﻧﻲ ﻣﻦ ﺍﻟﺮﻣﻮﺯ ﺑﺎﻟﺘﺴﻠﺴﻞ ﺍﻷﻭﻝ‪ ،‬ﻫﻨﺎﻙ ﻧﻘﻄﺘﺎﻥ ﻭﺍﺿﺤﺘﺎﻥ ﻋﻠﻰ ﺍﻟﻔﻮﺭ‪:‬‬

‫ﻳﺴﺘﻤﺮﺍﻟﺘﺴﻠﺴﻞ ﺍﻟﺮﻗﻤﻲ ﺍﻷﻭﻝ ﻓﻲ ﺍﻟﺘﻘﺪﻡ ﺗﺪﺭﻳﺠﻴﺎً؛ ﻭﻣﻊ ﺫﻟﻚ‪ ،‬ﺗﻢ ﺗﺨﻄﻲ ﺧﻤﺲ ﻗﻴﻢ ﻣﻨﺬ‬ ‫‪-‬‬

‫ﻧﻬﺎﻳﺔﺍﻟﺘﺴﻠﺴﻞ ﺍﻷﻭﻝ‪ .‬ﻳﻔُﺘﺮﺽ ﺃﻥ ﻫﺬﺍ ﻳﺮﺟﻊ ﺇﻟﻰ ﺇﺭﺳﺎﻝ ﺍﻟﻘﻴﻢ ﺍﻟﻤﻔﻘﻮﺩﺓ ﺇﻟﻰ ﻣﺴﺘﺨﺪﻣﻴﻦ‬
‫ﺁﺧﺮﻳﻦﺳﺠﻠﻮﺍ ﺩﺧﻮﻟﻬﻢ ﺇﻟﻰ ﺍﻟﺘﻄﺒﻴﻖ ﻓﻲ ﺍﻟﻔﺘﺮﺓ ﺍﻟﻔﺎﺻﻠﺔ ﺑﻴﻦ ﺍﻻﺧﺘﺒﺎﺭﻳﻦ‪.‬‬

‫ﻳﺴﺘﻤﺮﺍﻟﺘﺴﻠﺴﻞ ﺍﻟﺮﻗﻤﻲ ﺍﻟﺜﺎﻧﻲ ﻓﻲ ﺍﻟﺘﻘﺪﻡ ﺑﻔﻮﺍﺻﻞ ﺯﻣﻨﻴﺔ ﻣﻤﺎﺛﻠﺔ ﻛﻤﺎ ﻓﻲ ﺍﻟﺴﺎﺑﻖ؛ ﻭﻣﻊ‬ ‫‪-‬‬

‫ﺫﻟﻚ‪،‬ﻓﺈﻥ ﺍﻟﻘﻴﻤﺔ ﺍﻷﻭﻟﻰ ﺍﻟﺘﻲ ﻧﺤﺼﻞ ﻋﻠﻴﻬﺎ ﺃﻛﺒﺮ ﺑﻤﻘﺪﺍﺭ ‪ 539,578‬ﻣﻦ ﺍﻟﻘﻴﻤﺔ ﺍﻟﺴﺎﺑﻘﺔ‪.‬‬
‫‪217‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬

‫ﻫﺬﻩﺍﻟﻤﻼﺣﻈﺔ ﺍﻟﺜﺎﻧﻴﺔ ﺗﻨُﺒﻬﻨﺎ ﻓﻮﺭﺍً ﺇﻟﻰ ﺩﻭﺭ ﺍﻟﻮﻗﺖ ﻓﻲ ﺗﻮﻟﻴﺪ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ‪ .‬ﻳﺒﺪﻭ ﺃﻧﻪ ﻟﻢ ﻳﺼُﺪﺭ‬
‫ﺳﻮﻯﺧﻤﺴﺔ ﺭﻣﻮﺯ ﺑﻴﻦ ﻋﻤﻠﻴﺘﻲ ﺟﻤﻊ ﺍﻟﺮﻣﻮﺯ‪ .‬ﻭﻣﻊ ﺫﻟﻚ‪ ،‬ﻓﻘﺪ ﺍﻧﻘﻀﺖ ﻓﺘﺮﺓ ﺯﻣﻨﻴﺔ ﺗﻘُﺎﺭﺏ ﻋﺸﺮ‬
‫ﺩﻗﺎﺉﻖ‪.‬ﺍﻟﺘﻔﺴﻴﺮ ﺍﻷﺭﺟﺢ ﻫﻮ ﺃﻥ ﺍﻟﺮﻗﻢ ﺍﻟﺜﺎﻧﻲ ﻣﺮﺗﺒﻂ ﺑﺎﻟﻮﻗﺖ‪ ،‬ﻭﺭﺑﻤﺎ ﻳﻜﻮﻥ ﻣﺠﺮﺩ ﻋﺪﺩ ﻣﻦ ﺍﻟﻤﻠﻠﻲ‬
‫ﺛﺎﻧﻴﺔ‪.‬‬

‫ﺑﺎﻟﻔﻌﻞ‪،‬ﺣﺪﺳﻨﺎ ﺻﺤﻴﺢ‪ .‬ﻓﻲ ﻣﺮﺣﻠﺔ ﻻﺣﻘﺔ ﻣﻦ ﺍﻻﺧﺘﺒﺎﺭ‪ ،‬ﺃﺟﺮﻳﻨﺎ ﻣﺮﺍﺟﻌﺔ ًﻟﻠﻜﻮﺩ‪ ،‬ﻭﺍﻟﺘﻲ ﻛﺸﻔﺖ ﻋﻦ‬
‫ﺧﻮﺍﺭﺯﻣﻴﺔﺗﻮﻟﻴﺪ ﺍﻟﺮﻣﻮﺯ ﺍﻟﺘﺎﻟﻴﺔ‪:‬‬

‫ﺳﻠﺴﻠﺔ (‪+ sessId = Integer.toString)s_SessionIndex++‬‬

‫"‪+ "-‬‬
‫ﺍﻟﻨﻈﺎﻡ‪.‬ﺍﻟﻮﻗﺖﺍﻟﺤﺎﻟﻲ ﻣﻴﻠﻲ ﺛﺎﻧﻴﺔ)(;‬

‫ﺑﺎﻟﻨﻈﺮﺇﻟﻰ ﺗﺤﻠﻴﻠﻨﺎ ﻟﻜﻴﻔﻴﺔ ﺇﻧﺸﺎء ﺍﻟﺮﻣﻮﺯ‪ ،‬ﻓﻤﻦ ﺍﻟﺴﻬﻞ ﺇﻧﺸﺎء ﻫﺠﻮﻡ ﻧﺼﻲ ﻟﺠﻤﻊ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ‬
‫ﺍﻟﺘﻲﻳﺼﺪﺭﻫﺎ ﺍﻟﺘﻄﺒﻴﻖ ﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺁﺧﺮﻳﻦ‪:‬‬

‫ﻧﺴﺘﻤﺮﻓﻲ ﺍﺳﺘﻄﻼﻉ ﺍﻟﺨﺎﺩﻡ ﻟﻠﺤﺼﻮﻝ ﻋﻠﻰ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ ﺍﻟﺠﺪﻳﺪﺓ ﻓﻲ ﺗﺘﺎﺑﻊ ﺳﺮﻳﻊ‪.‬‬ ‫‪-‬‬

‫ﻧﺮﺍﻗﺐﺍﻟﺰﻳﺎﺩﺍﺕ ﻓﻲ ﺍﻟﺮﻗﻢ ﺍﻷﻭﻝ‪ .‬ﻋﻨﺪﻣﺎ ﻳﺰﻳﺪ ﻫﺬﺍ ﺍﻟﺮﻗﻢ ﻋﻦ ‪ ،١‬ﻧﻌﻠﻢ ﺃﻧﻪ ﺗﻢ ﺇﺻﺪﺍﺭ ﺭﻣﺰ ﻣﻤﻴﺰ‬ ‫‪-‬‬

‫ﻟﻤﺴﺘﺨﺪﻡﺁﺧﺮ‪.‬‬
‫ﻋﻨﺪﺇﺻﺪﺍﺭ ﺭﻣﺰ ﻣﻤﻴﺰ ﻟﻤﺴﺘﺨﺪﻡ ﺁﺧﺮ‪ ،‬ﻧﻌﺮﻑ ﺍﻟﺤﺪﻳﻦ ﺍﻷﻋﻠﻰ ﻭﺍﻷﺩﻧﻰ ﻟﻠﺮﻗﻢ ﺍﻟﺜﺎﻧﻲ ﺍﻟﺬﻱ ﺻﺪﺭ‬ ‫‪-‬‬

‫ﻟﻪ‪،‬ﻷﻧﻨﺎ ﻧﻤﺘﻠﻚ ﺍﻟﺮﻣﻮﺯ ﺍﻟﺘﻲ ﺻﺪﺭﺕ ﻗﺒﻠﻪ ﻭﺑﻌﺪﻩ ﻣﺒﺎﺷﺮﺓ‪ ً.‬ﻭﻷﻧﻨﺎ ﻧﺤﺼﻞ ﻋﻠﻰ ﺭﻣﻮﺯ ﺟﻠﺴﺎﺕ‬
‫ﺟﺪﻳﺪﺓﺑﺸﻜﻞ ﻣﺘﻜﺮﺭ‪ ،‬ﻓﺈﻥ ﺍﻟﻨﻄﺎﻕ ﺑﻴﻦ ﻫﺬﻳﻦ ﺍﻟﺤﺪﻳﻦ ﻋﺎﺩﺓ ًﻣﺎ ﻳﻘﺘﺼﺮ ﻋﻠﻰ ﺑﻀﻊ ﻣﺉﺎﺕ ﻣﻦ‬
‫ﺍﻟﻘﻴﻢ‪.‬‬

‫ﻓﻲﻛﻞ ﻣﺮﺓ ﻳﺼُﺪﺭ ﻓﻴﻬﺎ ﺭﻣﺰ ﻟﻤﺴﺘﺨﺪﻡ ﺁﺧﺮ‪ ،‬ﻧﻄُﻠﻖ ﻫﺠﻮﻣﺎً ﺑﺎﻟﻘﻮﺓ ﺍﻟﻐﺎﺷﻤﺔ ﻟﺘﻜﺮﺍﺭ ﻛﻞ ﺭﻗﻢ‬ ‫‪-‬‬

‫ﻓﻲﺍﻟﻨﻄﺎﻕ‪ ،‬ﻣﻊ ﺇﺿﺎﻓﺔ ﻫﺬﺍ ﺍﻟﺮﻗﻢ ﺇﻟﻰ ﺍﻟﺮﻗﻢ ﺍﻟﺘﺰﺍﻳﺪﻱ ﺍﻟﻨﺎﻗﺺ ﺍﻟﺬﻱ ﻧﻌﻠﻢ ﺃﻧﻪ ﻣﺼُﺪﺭ‬
‫ﻟﻠﻤﺴﺘﺨﺪﻡﺍﻵﺧﺮ‪ .‬ﻧﺤﺎﻭﻝ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﺻﻔﺤﺔ ﻣﺤﻤﻴﺔ ﺑﺎﺳﺘﺨﺪﺍﻡ ﻛﻞ ﺭﻣﺰ ﻧﻨُﺸﺉﻪ‪ ،‬ﺣﺘﻰ‬
‫ﺗﻨﺠﺢﺍﻟﻤﺤﺎﻭﻟﺔ ﻭﻧﺨُﺘﺮﻕ ﺟﻠﺴﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ‪.‬‬

‫ﺳﻴﻤُﻜﻨّﻨﺎﺗﺸﻐﻴﻞ ﻫﺬﺍ ﺍﻟﻬﺠﻮﻡ ﺍﻟﻨﺼﻲ ﺑﺎﺳﺘﻤﺮﺍﺭ ﻣﻦ ﺍﻟﺘﻘﺎﻁ ﺭﻣﺰ ﺟﻠﺴﺔ ﺟﻤﻴﻊ ﻣﺴﺘﺨﺪﻣﻲ‬ ‫‪-‬‬

‫ﺍﻟﺘﻄﺒﻴﻖﺍﻵﺧﺮﻳﻦ‪ .‬ﻋﻨﺪ ﺗﺴﺠﻴﻞ ﺩﺧﻮﻝ ﻣﺴﺘﺨﺪﻡ ﺇﺩﺍﺭﻱ‪ ،‬ﺳﻨﻌُﺮﺽّ ﺍﻟﺘﻄﺒﻴﻖ ﺑﺄﻛﻤﻠﻪ ﻟﻠﺨﻄﺮ‪.‬‬

‫ﺟﺮﺑﻬﺎ!‬

‫‪/347/ http://mdsec.net/auth/351/‬‬
‫‪/auth/340/ http://mdsec.net/auth‬‬
‫‪/auth/339/ http://mdsec.net‬‬
‫‪http://mdsec.net‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬ ‫‪218‬‬

‫ﺗﻮﻟﻴﺪﺃﺭﻗﺎﻡ ﻋﺸﻮﺍﺉﻴﺔ ﺿﻌﻴﻔﺔ‬

‫ﻧﺎﺩﺭﺍًﻣﺎ ﻳﺤﺪﺙ ﺩﺍﺧﻞ ﺍﻟﺤﺎﺳﻮﺏ ﻋﺸﻮﺍﺉﻴﺎً‪ .‬ﻟﺬﻟﻚ‪ ،‬ﻋﻨﺪ ﺍﻟﺤﺎﺟﺔ ﺇﻟﻰ ﺍﻟﻌﺸﻮﺍﺉﻴﺔ ﻟﻐﺮﺽ ﻣﺎ‪ ،‬ﻳﺴﺘﺨﺪﻡ‬
‫ﺍﻟﺒﺮﻧﺎﻣﺞﺗﻘﻨﻴﺎﺕ ﻣﺘﻨﻮﻋﺔ ﻟﺘﻮﻟﻴﺪ ﺃﺭﻗﺎﻡ ﺷﺒﻪ ﻋﺸﻮﺍﺉﻴﺔ‪ .‬ﺑﻌﺾ ﺍﻟﺨﻮﺍﺭﺯﻣﻴﺎﺕ ﺍﻟﻤﺴﺘﺨﺪﻣﺔ ﺗﻨُﺘﺞ‬
‫ﺗﺴﻠﺴﻼﺕﺗﺒﺪﻭ ﻋﺸﻮﺍﺉﻴﺔ‪ ،‬ﻭﺗﻈُﻬﺮ ﺗﻮﺯﻳﻌﺎً ﻣﺘﺴﺎﻭﻳﺎً ﻋﺒﺮ ﻧﻄﺎﻕ ﺍﻟﻘﻴﻢ ﺍﻟﻤﻤﻜﻨﺔ‪ .‬ﻭﻣﻊ ﺫﻟﻚ‪ ،‬ﻳﻤُﻜﻦ ﻷﻱ‬
‫ﺷﺨﺺﺍﺳﺘﻘﺮﺍءﻫﺎ ﺗﺼﺎﻋﺪﻳﺎً ﺃﻭ ﺗﻨﺎﺯﻟﻴﺎً ﺑﺪﻗﺔ ﻣﺘﻨﺎﻫﻴﺔ‪ ،‬ﻭﺫﻟﻚ ﻣﻦ ﺧﻼﻝ ﺍﻟﺤﺼﻮﻝ ﻋﻠﻰ ﻋﻴﻨﺔ ﺻﻐﻴﺮﺓ‬
‫ﻣﻦﺍﻟﻘﻴﻢ‪.‬‬

‫ﻋﻨﺪﻣﺎﻳﺘﻢ ﺍﺳﺘﺨﺪﺍﻡ ﻣﻮﻟﺪ ﺃﺭﻗﺎﻡ ﻋﺸﻮﺍﺉﻴﺔ ﻳﻤﻜﻦ ﺍﻟﺘﻨﺒﺆ ﺑﻪ ﻹﻧﺘﺎﺝ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ‪ ،‬ﺗﻜﻮﻥ ﺍﻟﺮﻣﻮﺯ‬
‫ﺍﻟﻨﺎﺗﺠﺔﻋﺮﺿﺔ ﻟﻠﺘﺴﻠﺴﻞ ﻣﻦ ﻗﺒﻞ ﺍﻟﻤﻬﺎﺟﻢ‪.‬‬
‫ﺟﻴﺘﻲﻫﻮ ﺧﺎﺩﻡ ﻭﻳﺐ ﺷﺎﺉﻊ ﻣﻜﺘﻮﺏ ﺑﻠﻐﺔ ﺟﺎﻓﺎ ‪ ،%100‬ﻭﻳﻮﻓﺮ ﺁﻟﻴﺔ ﻹﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺎﺕ ﺗﺴﺘﺨﺪﻣﻬﺎ‬
‫ﺍﻟﺘﻄﺒﻴﻘﺎﺕﺍﻟﺘﻲ ﺗﻌﻤﻞ ﻋﻠﻴﻪ‪ .‬ﻓﻲ ﻋﺎﻡ ‪ ،2006‬ﺍﻛﺘﺸﻒ ﻛﺮﻳﺲ ﺃﻧﻠﻲ ﻣﻦ ﺷﺮﻛﺔ ‪ NGSSoftware‬ﺃﻥ‬
‫ﺍﻵﻟﻴﺔﻣﻌﺮﺿﺔ ﻟﻬﺠﻮﻡ ﺗﻨﺒﺆ ﺑﺮﻣﺰ ﺍﻟﺠﻠﺴﺔ‪ .‬ﺍﺳﺘﺨﺪﻡ ﺍﻟﺨﺎﺩﻡ ﻭﺍﺟﻬﺔ ﺑﺮﻣﺠﺔ ﺗﻄﺒﻴﻘﺎﺕ ﺟﺎﻓﺎ‪.‬ﻋﺸﻮﺍﺉﻲ‬
‫‪java.util.‬‬
‫ﻟﺘﻮﻟﻴﺪﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ‪ .‬ﻳﻨُﻔﺬِّ ﻫﺬﺍ "ﻣﻮﻟﺪﺍً ﺧﻄﻴﺎً ﻣﺘﻄﺎﺑﻘﺎً"‪ ،‬ﻭﺍﻟﺬﻱ ﻳﻮُﻟﺪِّ ﺍﻟﺮﻗﻢ ﺍﻟﺘﺎﻟﻲ ﻓﻲ ﺍﻟﺘﺴﻠﺴﻞ ﻛﻤﺎ‬
‫ﻳﻠﻲ‪:‬‬

‫ﻣﺘﺰﺍﻣﻨﺔﻣﺤﻤﻴﺔ (‪} int next)int bits‬‬

‫ﺍﻟﺒﺬﺭﺓ= )ﺍﻟﺒﺬﺭﺓ * ‪(1 - (1L >> 48)) & (0x5DEECE66DL + 0xBL‬؛ ﺇﺭﺟﺎﻉ )‪) (int‬ﺍﻟﺒﺬﺭﺓ <<< )‬
‫‪ -48‬ﺑﺖ((;‬
‫{‬

‫ﺗﺄﺧﺬﻫﺬﻩ ﺍﻟﺨﻮﺍﺭﺯﻣﻴﺔ ﺁﺧﺮ ﺭﻗﻢ ﻣﻮُﻟﺪَّ‪ ،‬ﻭﺗﻀﺮﺑﻪ ﺑﺜﺎﺑﺖ‪ ،‬ﺛﻢ ﺗﻀﻴﻒ ﺛﺎﺑﺘﺎً ﺁﺧﺮ ﻟﻠﺤﺼﻮﻝ ﻋﻠﻰ ﺍﻟﺮﻗﻢ‬
‫ﺍﻟﺘﺎﻟﻲ‪.‬ﻳﺨُﺘﺰﻝ ﺍﻟﺮﻗﻢ ﺇﻟﻰ ‪ 48‬ﺑﺘﺎً‪ ،‬ﺛﻢ ﺗﺤُﻮﻝّ ﺍﻟﺨﻮﺍﺭﺯﻣﻴﺔ ﺍﻟﻨﺘﻴﺠﺔ ﻹﺭﺟﺎﻉ ﻋﺪﺩ ﺍﻟﺒﺘﺎﺕ ﺍﻟﻤﻄﻠﻮﺏ ﻣﻦ‬
‫ﻗﺒِﻞﺍﻟﻤﺴُﺘﺪﻋﻲ‪.‬‬

‫ﺑﻤﻌﺮﻓﺔﻫﺬﻩ ﺍﻟﺨﻮﺍﺭﺯﻣﻴﺔ ﻭﺍﻟﺮﻗﻢ ﺍﻟﻤﻮُﻟﺪّ ﻣﻨﻬﺎ‪ ،‬ﻳﻤُﻜﻨﻨﺎ ﺑﺴﻬﻮﻟﺔ ﺍﺳﺘﻨﺘﺎﺝ ﺗﺴﻠﺴﻞ ﺍﻷﺭﻗﺎﻡ ﺍﻟﺘﻲ‬
‫ﺳﺘﻮُﻟﺪّﻫﺎﺍﻟﺨﻮﺍﺭﺯﻣﻴﺔ ﻻﺣﻘﺎً‪ .‬ﻭﺑﺎﺳﺘﺨﺪﺍﻡ ﻧﻈﺮﻳﺔ ﺍﻷﻋﺪﺍﺩ ﺍﻟﺒﺴﻴﻄﺔ‪ ،‬ﻳﻤُﻜﻨﻨﺎ ﺃﻳﻀﺎً ﺍﺳﺘﻨﺘﺎﺝ ﺍﻟﺘﺴﻠﺴﻞ‬
‫ﺍﻟﺬﻱﻭﻟﺪّﺗﻪ ﺳﺎﺑﻘﺎً‪ .‬ﻫﺬﺍ ﻳﻌﻨﻲ ﺃﻥ ﺍﻟﻤﻬُﺎﺟﻢ ﺍﻟﺬﻱ ﻳﺤﺼﻞ ﻋﻠﻰ ﺭﻣﺰ ﺟﻠﺴﺔ ﻭﺍﺣﺪ ﻣﻦ ﺍﻟﺨﺎﺩﻡ ﻳﻤُﻜﻨﻪ‬
‫ﺍﻟﺤﺼﻮﻝﻋﻠﻰ ﺭﻣﻮﺯ ﺟﻤﻴﻊ ﺍﻟﺠﻠﺴﺎﺕ ﺍﻟﺤﺎﻟﻴﺔ ﻭﺍﻟﻤﺴﺘﻘﺒﻠﻴﺔ‪.‬‬

‫ﻣﻠﺤﻮﻇﺔﺃﺣﻴﺎﻧﺎً‪ ،‬ﻋﻨﺪ ﺇﻧﺸﺎء ﺍﻟﺮﻣﻮﺯ ﺑﻨﺎء ًﻋﻠﻰ ﻣﺨﺮﺟﺎﺕ ﻣﻮُﻟﺪّ ﺃﺭﻗﺎﻡ ﺷﺒﻪ ﻋﺸﻮﺍﺉﻴﺔ‪ ،‬ﻳﻘُﺮﺭ ﺍﻟﻤﻄﻮﺭﻭﻥ‬
‫ﺑﻨﺎءﻛﻞ ﺭﻣﺰ ﺑﺮﺑﻂ ﻋﺪﺓ ﻣﺨﺮﺟﺎﺕ ﻣﺘﺴﻠﺴﻠﺔ ﻣﻦ ﺍﻟﻤﻮُﻟﺪّ‪ .‬ﻭﻳﻌُﺘﻘﺪ ﺃﻥ ﻫﺬﺍ ﻳﻨُﺸﺊ ﺭﻣﺰﺍً ﺃﻃﻮﻝ‪ ،‬ﻭﺑﺎﻟﺘﺎﻟﻲ "‬
‫ﺃﻗﻮﻯ"‪ .‬ﺇﻻ ﺃﻥ ﻫﺬﺍ ﺍﻷﺳﻠﻮﺏ ﻏﺎﻟﺒﺎً ﻣﺎ ﻳﻜﻮﻥ ﺧﺎﻃﺉﺎً‪ .‬ﻓﺈﺫﺍ ﺍﺳﺘﻄﺎﻉ ﺍﻟﻤﻬُﺎﺟﻢ ﺍﻟﺤﺼﻮﻝ ﻋﻠﻰ ﻋﺪﺓ‬
‫ﻣﺨﺮﺟﺎﺕﻣﺘﺘﺎﻟﻴﺔ ﻣﻦ ﺍﻟﻤﻮُﻟﺪّ‪ ،‬ﻓﻘﺪ ﻳﻤُﻜﻨّﻪ ﺫﻟﻚ ﻣﻦ ﺍﺳﺘﻨﺘﺎﺝ ﺑﻌﺾ ﺍﻟﻤﻌﻠﻮﻣﺎﺕ ﺣﻮﻝ ﺣﺎﻟﺘﻪ ﺍﻟﺪﺍﺧﻠﻴﺔ‪.‬‬
‫ﻓﻲﺍﻟﻮﺍﻗﻊ‪ ،‬ﻗﺪ ﻳﻜﻮﻥ ﻣﻦ ﺍﻷﺳﻬﻞ ﻋﻠﻰ ﺍﻟﻤﻬُﺎﺟﻢ ﺍﺳﺘﻘﺮﺍء ﺗﺴﻠﺴﻞ ﻣﺨﺮﺟﺎﺕ ﺍﻟﻤﻮُﻟﺪّ‪ ،‬ﺇﻣﺎ ﻟﻸﻣﺎﻡ ﺃﻭ‬
‫ﻟﻠﺨﻠﻒ‪.‬‬

‫ﺗﺴﺘﺨﺪﻡﺃﻃﺮ ﻋﻤﻞ ﺗﻄﺒﻴﻘﺎﺕ ﺟﺎﻫﺰﺓ ﺃﺧﺮﻯ ﻣﺼﺎﺩﺭ ﺍﻧﺘﺮﻭﺑﻴﺔ ﺑﺴﻴﻄﺔ ﺃﻭ ﻣﺘﻮﻗﻌﺔ ﺑﺸﻜﻞ ﻣﺪﻫﺶ‬
‫ﻓﻲﺗﻮﻟﻴﺪ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ‪ ،‬ﻭﻣﻌﻈﻤﻬﺎ ﺣﺘﻤﻲ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﻓﻲ ﺃﻃﺮ ﻋﻤﻞ ‪PHP 5.3.2‬‬
‫ﻭﺍﻹﺻﺪﺍﺭﺍﺕﺍﻷﻗﺪﻡ‪ ،‬ﻳﺘﻢ ﺗﻮﻟﻴﺪ ﺭﻣﺰ ﺍﻟﺠﻠﺴﺔ‪.‬‬
‫‪219‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬

‫ﺑﻨﺎء ًﻋﻠﻰ ﻋﻨﻮﺍﻥ ‪ IP‬ﺍﻟﺨﺎﺹ ﺑﺎﻟﻌﻤﻴﻞ‪ ،‬ﻭﻭﻗﺖ ﺇﻧﺸﺎء ﺍﻟﺮﻣﺰ‪ ،‬ﻭﺍﻟﻤﺎﻳﻜﺮﻭﺛﺎﻧﻴﺔ ﻋﻨﺪ ﺇﻧﺸﺎﺉﻪ‪ ،‬ﻭﻣﻮﻟﺪ‬
‫ﻣﺘﻄﺎﺑﻖﺧﻄﻲ‪ .‬ﻋﻠﻰ ﺍﻟﺮﻏﻢ ﻣﻦ ﻭﺟﻮﺩ ﺍﻟﻌﺪﻳﺪ ﻣﻦ ﺍﻟﻘﻴﻢ ﻏﻴﺮ ﺍﻟﻤﻌﺮﻭﻓﺔ ﻫﻨﺎ‪ ،‬ﺇﻻ ﺃﻥ ﺑﻌﺾ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ‬
‫ﻗﺪﺗﻜﺸﻒ ﻋﻦ ﻣﻌﻠﻮﻣﺎﺕ ﺗﺴﻤﺢ ﺑﺎﺳﺘﻨﺘﺎﺟﻬﺎ‪ .‬ﻗﺪ ﻳﻜﺸﻒ ﻣﻮﻗﻊ ﺗﻮﺍﺻﻞ ﺍﺟﺘﻤﺎﻋﻲ ﻋﻦ ﻭﻗﺖ‬
‫ﺗﺴﺠﻴﻞﺍﻟﺪﺧﻮﻝ ﻭﻋﻨﺎﻭﻳﻦ ‪ IP‬ﻟﻤﺴﺘﺨﺪﻣﻲ ﺍﻟﻤﻮﻗﻊ‪ .‬ﺑﺎﻹﺿﺎﻓﺔ ﺇﻟﻰ ﺫﻟﻚ‪ ،‬ﻓﺈﻥ ﺍﻟﺒﺬﺭﺓ ﺍﻟﻤﺴﺘﺨﺪﻣﺔ ﻓﻲ‬
‫ﻫﺬﺍﺍﻟﻤﻮﻟﺪ ﻫﻲ ﻭﻗﺖ ﺑﺪء ﻋﻤﻠﻴﺔ ‪ ،PHP‬ﻭﺍﻟﺬﻱ ﻳﻤﻜﻦ ﺗﺤﺪﻳﺪﻩ ﺿﻤﻦ ﻧﻄﺎﻕ ﻗﻴﻢ ﺻﻐﻴﺮ ﺇﺫﺍ ﻛﺎﻥ‬
‫ﺍﻟﻤﻬﺎﺟﻢﻳﺮﺍﻗﺐ ﺍﻟﺨﺎﺩﻡ‪.‬‬

‫ﻣﻠﺤﻮﻇﺔﻫﺬﺍ ﻣﺠﺎﻝ ﺑﺤﺜﻲ ﻣﺘﻄﻮﺭ‪ .‬ﺃﺷُﻴﺮ ﺇﻟﻰ ﻧﻘﺎﻁ ﺿﻌﻒ ﺗﻮﻟﻴﺪ ﺭﻣﻮﺯ ﺟﻠﺴﺔ ‪ PHP‬ﻋﺒﺮ ﻗﺎﺉﻤﺔ "‬
‫ﺍﻹﻓﺼﺎﺡﺍﻟﻜﺎﻣﻞ" ﺍﻟﺒﺮﻳﺪﻳﺔ ﻋﺎﻡ ‪ ،٢٠٠١‬ﻭﻟﻜﻦ ﻟﻢ ﻳﺜُﺒﺖ ﺍﺳﺘﻐﻼﻟﻬﺎ ﻋﻤﻠﻴﺎً‪ .‬ﻭﻗﺪ ﻃﺒﻖّ ﺳﺎﻣﻲ ﻛﺎﻣﻜﺎﺭ‬
‫ﻧﻈﺮﻳﺔﻋﺎﻡ ‪ ٢٠٠١‬ﺃﺧﻴﺮﺍً ﺑﺎﺳﺘﺨﺪﺍﻡ ﺃﺩﺍﺓ ‪ phpwn‬ﻋﺎﻡ ‪.٢٠١٠‬‬

‫ﺍﺧﺘﺒﺎﺭﺟﻮﺩﺓ ﺍﻟﻌﺸﻮﺍﺉﻴﺔ‬
‫ﻓﻲﺑﻌﺾ ﺍﻟﺤﺎﻻﺕ‪ ،‬ﻳﻤُﻜﻦ ﺗﺤﺪﻳﺪ ﺃﻧﻤﺎﻁ ﻓﻲ ﺳﻠﺴﻠﺔ ﻣﻦ ﺍﻟﺮﻣﻮﺯ ﺑﻤﺠﺮﺩ ﺍﻟﻔﺤﺺ ﺍﻟﺒﺼﺮﻱ‪ ،‬ﺃﻭ ﻣﻦ‬
‫ﺧﻼﻝﺗﺤﻠﻴﻞ ﻳﺪﻭﻱ ﺑﺴﻴﻂ‪ .‬ﻣﻊ ﺫﻟﻚ‪ ،‬ﺑﺸﻜﻞ ﻋﺎﻡ‪ ،‬ﻳﻠﺰﻡ ﺍﺗﺒﺎﻉ ﻧﻬﺞ ﺃﻛﺜﺮ ﺩﻗﺔ ﻻﺧﺘﺒﺎﺭ ﺟﻮﺩﺓ ﺍﻟﻌﺸﻮﺍﺉﻴﺔ‬
‫ﺩﺍﺧﻞﺭﻣﻮﺯ ﺍﻟﺘﻄﺒﻴﻖ‪.‬‬

‫ﺍﻟﻨﻬﺞﺍﻟﻘﻴﺎﺳﻲ ﻟﻬﺬﻩ ﺍﻟﻤﻬﻤﺔ ﻳﻄﺒﻖ ﻣﺒﺎﺩﺉ ﺍﺧﺘﺒﺎﺭ ﺍﻟﻔﺮﺿﻴﺎﺕ ﺍﻹﺣﺼﺎﺉﻴﺔ‪ ،‬ﻭﻳﺴﺘﺨﺪﻡ ﺍﺧﺘﺒﺎﺭﺍﺕ‬
‫ﻣﻮﺛﻘﺔﺟﻴﺪﺍً ﻣﺘﻨﻮﻋﺔ ﺗﺒﺤﺚ ﻋﻦ ﺃﺩﻟﺔ ﻋﻠﻰ ﻋﺪﻡ ﺍﻟﻌﺸﻮﺍﺉﻴﺔ ﻓﻲ ﻋﻴﻨﺔ ﻣﻦ ﺍﻟﺮﻣﻮﺯ‪ .‬ﺍﻟﺨﻄﻮﺍﺕ‬
‫ﺍﻟﺮﺉﻴﺴﻴﺔﻓﻲ ﻫﺬﻩ ﺍﻟﻌﻤﻠﻴﺔ ﻫﻲ ﻛﻤﺎ ﻳﻠﻲ‪:‬‬

‫‪.1‬ﺍﺑﺪﺃ ﺑﺎﻟﻔﺮﺿﻴﺔ ﺍﻟﻘﺎﺉﻠﺔ ﺑﺄﻥ ﺍﻟﺮﻣﻮﺯ ﻳﺘﻢ ﺇﻧﺸﺎﺅﻫﺎ ﻋﺸﻮﺍﺉﻴﺎً‪.‬‬

‫‪.2‬ﻗﻢ ﺑﺘﻄﺒﻴﻖ ﺳﻠﺴﻠﺔ ﻣﻦ ﺍﻻﺧﺘﺒﺎﺭﺍﺕ‪ ،‬ﺣﻴﺚ ﻳﻼﺣﻆ ﻛﻞ ﻣﻨﻬﺎ ﺧﺼﺎﺉﺺ ﻣﺤﺪﺩﺓ ﻟﻠﻌﻴﻨﺔ ﻭﺍﻟﺘﻲ‬
‫ﻣﻦﺍﻟﻤﺤﺘﻤﻞ ﺃﻥ ﻳﻜﻮﻥ ﻟﻬﺎ ﺧﺼﺎﺉﺺ ﻣﻌﻴﻨﺔ ﺇﺫﺍ ﺗﻢ ﺇﻧﺸﺎء ﺍﻟﺮﻣﻮﺯ ﺑﺸﻜﻞ ﻋﺸﻮﺍﺉﻲ‪.‬‬

‫‪.3‬ﺑﺎﻟﻨﺴﺒﺔ ﻟﻜﻞ ﺍﺧﺘﺒﺎﺭ‪ ،‬ﺍﺣﺴﺐ ﺍﺣﺘﻤﺎﻝ ﺣﺪﻭﺙ ﺍﻟﺨﺼﺎﺉﺺ ﺍﻟﻤﻼﺣﻈﺔ‪ ،‬ﻣﻊ ﺍﻟﻌﻤﻞ ﻋﻠﻰ‬
‫ﺍﻓﺘﺮﺍﺽﺃﻥ ﺍﻟﻔﺮﺿﻴﺔ ﺻﺤﻴﺤﺔ‪.‬‬
‫‪.4‬ﺇﺫﺍ ﺍﻧﺨﻔﺾ ﻫﺬﺍ ﺍﻻﺣﺘﻤﺎﻝ ﺇﻟﻰ ﻣﺎ ﺩﻭﻥ ﻣﺴﺘﻮﻯ ﻣﻌﻴﻦ )ﻣﺴﺘﻮﻯ ﺍﻷﻫﻤﻴﺔ(‪ ،‬ﺍﺭﻓﺾ ﺍﻟﻔﺮﺿﻴﺔ‬
‫ﻭﺍﺳﺘﻨﺘﺞﺃﻥ ﺍﻟﺮﻣﻮﺯ ﻻ ﻳﺘﻢ ﺇﻧﺸﺎﺅﻫﺎ ﻋﺸﻮﺍﺉﻴﺎً‪.‬‬
‫ﺍﻟﺨﺒﺮﺍﻟﺴﺎﺭ ﻫﻮ ﺃﻧﻚ ﻟﺴﺖ َﻣﻀﻄﺮﺍً ﻟﻠﻘﻴﺎﻡ ﺑﺄﻱ ٍّﻣﻦ ﻫﺬﺍ ﻳﺪﻭﻳﺎً! ﺃﻓﻀﻞ ﺃﺩﺍﺓ ﻣﺘﺎﺣﺔ ﺣﺎﻟﻴﺎً ﻻﺧﺘﺒﺎﺭ‬
‫ﻋﺸﻮﺍﺉﻴﺔﺭﻣﻮﺯ ﺗﻄﺒﻴﻘﺎﺕ ﺍﻟﻮﻳﺐ ﻫﻲ ‪ .Burp Sequencer‬ﺗﻄُﺒﻖّ ﻫﺬﻩ ﺍﻷﺩﺍﺓ ﺍﻟﻌﺪﻳﺪ ﻣﻦ‬
‫ﺍﻻﺧﺘﺒﺎﺭﺍﺕﺍﻟﻘﻴﺎﺳﻴﺔ ﺑﻄﺮﻳﻘﺔ ﻣﺮﻧﺔ‪ ،‬ﻭﺗﻌُﻄﻴﻚ ﻧﺘﺎﺉﺞ ﻭﺍﺿﺤﺔ ﻭﺳﻬﻠﺔ ﺍﻟﺘﻔﺴﻴﺮ‪.‬‬

‫ﻻﺳﺘﺨﺪﺍﻡﻣﺴُﻠﺴﻞِ ‪ ،Burp‬ﻋﻠﻴﻚ ﺇﻳﺠﺎﺩ ﺍﺳﺘﺠﺎﺑﺔ ﻣﻦ ﺍﻟﺘﻄﺒﻴﻖ ﺗﺼُﺪﺭ ﺍﻟﺮﻣﺰ ﺍﻟﺬﻱ ﺗﺮﻳﺪ ﺍﺧﺘﺒﺎﺭﻩ‪،‬‬
‫ﻣﺜﻞﺍﺳﺘﺠﺎﺑﺔ ﻟﻄﻠﺐ ﺗﺴﺠﻴﻞ ﺩﺧﻮﻝ ﻳﺼُﺪﺭ ﻣﻠﻒ ﺗﻌﺮﻳﻒ ﺍﺭﺗﺒﺎﻁ ﺟﺪﻳﺪ ﻳﺤﺘﻮﻱ ﻋﻠﻰ ﺭﻣﺰ ﺟﻠﺴﺔ‪ .‬ﺍﺧﺘﺮ‬
‫ﺧﻴﺎﺭ"ﺇﺭﺳﺎﻝ ﺇﻟﻰ ﺍﻟﻤﺴُﻠﺴﻞِ" ﻣﻦ ﻗﺎﺉﻤﺔ ﺳﻴﺎﻕ ‪ ،Burp‬ﻭﻓﻲ ﺇﻋﺪﺍﺩﺍﺕ ﺍﻟﻤﺴُﻠﺴﻞِ‪ ،‬ﻋﻴﻦّ ﻣﻮﻗﻊ ﺍﻟﺮﻣﺰ‬
‫ﺩﺍﺧﻞﺍﻻﺳﺘﺠﺎﺑﺔ‪ ،‬ﻛﻤﺎ ﻫﻮ ﻣﻮﺿﺢ ﻓﻲ ﺍﻟﺸﻜﻞ ‪ .2-7‬ﻳﻤﻜﻨﻚ ﺃﻳﻀﺎً‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬ ‫‪220‬‬

‫ﻗﻢﺑﺘﻜﻮﻳﻦ ﺧﻴﺎﺭﺍﺕ ﻣﺘﻨﻮﻋﺔ ﺗﺆﺛﺮ ﻋﻠﻰ ﻛﻴﻔﻴﺔ ﺟﻤﻊ ﺍﻟﺮﻣﻮﺯ‪ ،‬ﺛﻢ ﺍﻧﻘﺮ ﻋﻠﻰ ﺯﺭ ﺑﺪء ﺍﻻﻟﺘﻘﺎﻁ ﻟﺒﺪء ﺍﻟﺘﻘﺎﻁ‬
‫ﺍﻟﺮﻣﻮﺯ‪.‬ﺇﺫﺍ ﻛﻨﺖ ﻗﺪ ﺣﺼﻠﺖ ﺑﺎﻟﻔﻌﻞ ﻋﻠﻰ ﺭﻣﺰ ﻣﻨﺎﺳﺐ‪،‬‬

‫ﻧﺘﺎﺉﺞﺏ‬
‫ﺍﻟﺘﻘﺎﻁ‬

‫ﺍﻟﺸﻜﻞ‪:2-7‬ﺗﻜﻮﻳﻦ ‪ Burp Sequencer‬ﻻﺧﺘﺒﺎﺭ ﻋﺸﻮﺍﺉﻴﺔ ﺭﻣﺰ ﺍﻟﺠﻠﺴﺔ‬

‫ﻋﻨﺪﺍﻟﺤﺼﻮﻝ ﻋﻠﻰ ﻋﻴﻨﺔ ﻣﻨﺎﺳﺒﺔ ﻣﻦ ﺍﻟﺮﻣﻮﺯ‪ ،‬ﻳﻤﻜﻨﻚ ﺇﺟﺮﺍء ﺍﻟﺘﺤﻠﻴﻞ ﺍﻹﺣﺼﺎﺉﻲ ﻋﻠﻰ ﺍﻟﻌﻴﻨﺔ‪.‬‬
‫ﻳﻤﻜﻨﻚﺃﻳﻀﺎً ﺇﺟﺮﺍء ﺗﺤﻠﻴﻼﺕ ﻣﺆﻗﺘﺔ ﺃﺛﻨﺎء ﺍﻟﺘﻘﺎﻁ ﺍﻟﻌﻴﻨﺔ‪ .‬ﺑﺸﻜﻞ ﻋﺎﻡ‪ ،‬ﻓﺈﻥ ﺍﻟﺤﺼﻮﻝ ﻋﻠﻰ ﻋﻴﻨﺔ ﺃﻛﺒﺮ‬
‫ﻳﺤﺴﻦﻣﻦ ﻣﻮﺛﻮﻗﻴﺔ ﺍﻟﺘﺤﻠﻴﻞ‪ .‬ﺍﻟﺤﺪ ﺍﻷﺩﻧﻰ ﻟﺤﺠﻢ ﺍﻟﻌﻴﻨﺔ ﺍﻟﺬﻱ ﻳﺘﻄﻠﺒﻪ ‪ Burp‬ﻫﻮ ‪ 100‬ﺭﻣﺰ‪ ،‬ﻭﻟﻜﻦ‬
‫ﻣﻦﺍﻷﻓﻀﻞ ﺍﻟﺤﺼﻮﻝ ﻋﻠﻰ ﻋﻴﻨﺔ ﺃﻛﺒﺮ ﻣﻦ ﺫﻟﻚ ﺑﻜﺜﻴﺮ‪ .‬ﺇﺫﺍ ﺃﻇﻬﺮ ﺗﺤﻠﻴﻞ ﺑﻀﻊ ﻣﺉﺎﺕ ﻣﻦ ﺍﻟﺮﻣﻮﺯ‬
‫ﺑﺸﻜﻞﻗﺎﻃﻊ ﺃﻥ ﺍﻟﺮﻣﻮﺯ ﺗﻔﺸﻞ ﻓﻲ ﺍﺧﺘﺒﺎﺭﺍﺕ ﺍﻟﻌﺸﻮﺍﺉﻴﺔ‪ ،‬ﻓﻘﺪ ﺗﻘﺮﺭ ﺑﺸﻜﻞ ﻣﻌﻘﻮﻝ ﺃﻧﻪ ﻣﻦ ﻏﻴﺮ‬
‫ﺍﻟﻀﺮﻭﺭﻱﺍﻟﺘﻘﺎﻁ ﺍﻟﻤﺰﻳﺪ ﻣﻦ ﺍﻟﺮﻣﻮﺯ‪ .‬ﺑﺨﻼﻑ ﺫﻟﻚ‪ ،‬ﻳﺠﺐ ﻋﻠﻴﻚ ﺍﻻﺳﺘﻤﺮﺍﺭ ﻓﻲ ﺍﻟﺘﻘﺎﻁ ﺍﻟﺮﻣﻮﺯ ﻭﺇﻋﺎﺩﺓ‬
‫ﺇﺟﺮﺍءﺍﻟﺘﺤﻠﻴﻞ ﺑﺸﻜﻞ ﺩﻭﺭﻱ‪ .‬ﺇﺫﺍ ﺍﻟﺘﻘﻄﺖ ‪ 5000‬ﺭﻣﺰ ﺃﺛﺒﺘﺖ ﺍﺟﺘﻴﺎﺯﻫﺎ ﻻﺧﺘﺒﺎﺭﺍﺕ ﺍﻟﻌﺸﻮﺍﺉﻴﺔ‪ ،‬ﻓﻘﺪ‬
‫ﺗﻘﺮﺭﺃﻥ ﻫﺬﺍ ﻛﺎﻑ‪ ٍ.‬ﻭﻣﻊ ﺫﻟﻚ‪ ،‬ﻟﺘﺤﻘﻴﻖ ﺍﻻﻣﺘﺜﺎﻝ ﻻﺧﺘﺒﺎﺭﺍﺕ ‪ FIPS‬ﺍﻟﺮﺳﻤﻴﺔ ﻟﻠﻌﺸﻮﺍﺉﻴﺔ‪ ،‬ﺗﺤﺘﺎﺝ ﺇﻟﻰ‬
‫ﺍﻟﺤﺼﻮﻝﻋﻠﻰ ﻋﻴﻨﺔ ﻣﻦ ‪ 20000‬ﺭﻣﺰ‪ .‬ﻫﺬﺍ ﻫﻮ ﺃﻛﺒﺮ ﺣﺠﻢ ﻋﻴﻨﺔ ﻳﺪﻋﻤﻪ ‪.Burp‬‬

‫ﻳﺠُﺮﻱﻣﺴُﻠﺴﻞِ ﺍﻟﺘﺠﺸﺆ ﺍﻻﺧﺘﺒﺎﺭﺍﺕ ﺍﻹﺣﺼﺎﺉﻴﺔ ﻋﻠﻰ ﻣﺴﺘﻮﻯ ﺍﻷﺣﺮﻑ ﻭﺍﻟﺒﺘﺎﺕ‪ .‬ﺗﺠُﻤﻊَّ ﻧﺘﺎﺉﺞ‬
‫ﺟﻤﻴﻊﺍﻻﺧﺘﺒﺎﺭﺍﺕ ﻹﻋﻄﺎء ﺗﻘﺪﻳﺮ ﺇﺟﻤﺎﻟﻲ ﻟﻌﺪﺩ‬
‫‪221‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬

‫ﻣﻦﺑﺘﺎﺕ ﺍﻹﻧﺘﺮﻭﺑﻴﺎ ﺍﻟﻔﻌﺎﻟﺔ ﺩﺍﺧﻞ ﺍﻟﺮﻣﺰ؛ ﻫﺬﻩ ﻫﻲ ﺍﻟﻨﺘﻴﺠﺔ ﺍﻟﺮﺉﻴﺴﻴﺔ ﺍﻟﺘﻲ ﻳﺠﺐ ﻣﺮﺍﻋﺎﺗﻬﺎ‪ .‬ﻭﻣﻊ‬
‫ﺫﻟﻚ‪،‬ﻳﻤﻜﻨﻚ ﺃﻳﻀﺎً ﺍﻟﺘﻌﻤﻖ ﻓﻲ ﻧﺘﺎﺉﺞ ﻛﻞ ﺍﺧﺘﺒﺎﺭ ﻟﻔﻬﻢ ﻛﻴﻔﻴﺔ‬

‫ﻛﻤﺎﻫﻮ ﻣﻮﺿﺢ ﻓﻲ ﺍﻟﺸﻜﻞ‬

‫ﺗﺤﺖ‬

‫ﺍﻟﺸﻜﻞ‪:3-7‬ﺗﺤﻠﻴﻞ ﻧﺘﺎﺉﺞ ‪ Burp Sequencer‬ﻟﻔﻬﻢ ﺧﺼﺎﺉﺺ ﺍﻟﺮﻣﻮﺯ ﺍﻟﺘﻲ ﺗﻢ ﺍﺧﺘﺒﺎﺭﻫﺎ‬

‫ﻻﺣﻆﺃﻥ ‪ Burp‬ﻳﺠُﺮﻱ ﺟﻤﻴﻊ ﺍﻻﺧﺘﺒﺎﺭﺍﺕ ﺑﺸﻜﻞ ﻓﺮﺩﻱ ﻋﻠﻰ ﻛﻞ ﺣﺮﻑ ﻭﺑﺖ ﻣﻦ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺩﺍﺧﻞ‬
‫ﺍﻟﺮﻣﺰ‪.‬ﻓﻲ ﻛﺜﻴﺮ ﻣﻦ ﺍﻟﺤﺎﻻﺕ‪ ،‬ﺳﺘﺠﺪ ﺃﻥ ﺃﺟﺰﺍء ًﻛﺒﻴﺮﺓ ﻣﻦ ﺍﻟﺮﻣﺰ ﺍﻟﻤﻬُﻴﻜﻞ ﻟﻴﺴﺖ ﻋﺸﻮﺍﺉﻴﺔ؛ ﻭﻫﺬﺍ ﻓﻲ‬
‫ﺣﺪﺫﺍﺗﻪ ﻗﺪ ﻻ ﻳﻤُﺜﻞ ﺃﻱ ﺿﻌﻒ‪ .‬ﺍﻟﻤﻬﻢ ﻫﻮ ﺃﻥ ﻳﺤﺘﻮﻱ ﺍﻟﺮﻣﺰ ﻋﻠﻰ ﻋﺪﺩ ﻛﺎﻑ ٍﻣﻦ ﺍﻟﺒﺘﺎﺕ ﺍﻟﺘﻲ ﺗﺠﺘﺎﺯ‬
‫ﺍﺧﺘﺒﺎﺭﺍﺕﺍﻟﻌﺸﻮﺍﺉﻴﺔ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﺇﺫﺍ ﺍﺣﺘﻮﻯ ﺭﻣﺰ ﻛﺒﻴﺮ ﻋﻠﻰ ‪ 1000‬ﺑﺖ ﻣﻦ ﺍﻟﻤﻌﻠﻮﻣﺎﺕ‪،‬‬
‫ﻭﺍﺟﺘﺎﺯ‪ 50‬ﺑﺖ ﻓﻘﻂ ﻣﻨﻬﺎ ﺍﺧﺘﺒﺎﺭﺍﺕ ﺍﻟﻌﺸﻮﺍﺉﻴﺔ‪ ،‬ﻓﺈﻥ ﺍﻟﺮﻣﺰ ﻛﻜﻞ ﻻ ﻳﻘﻞ ﻣﺘﺎﻧﺔ ﻋﻦ ﺭﻣﺰ ‪ 50‬ﺑﺖ‬
‫ﺍﻟﺬﻱﺍﺟﺘﺎﺯ ﺍﻻﺧﺘﺒﺎﺭﺍﺕ ﺑﺎﻟﻜﺎﻣﻞ‪.‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬ ‫‪222‬‬

‫ﻣﻠﺤﻮﻇﺔﺗﺬﻛﺮّ ﺗﺤﺬﻳﺮﻳﻦ ﻣﻬﻤﻴﻦ ﻋﻨﺪ ﺇﺟﺮﺍء ﺍﺧﺘﺒﺎﺭﺍﺕ ﺇﺣﺼﺎﺉﻴﺔ ﻟﻠﻌﺸﻮﺍﺉﻴﺔ‪ .‬ﻳﺆﺛﺮ ﻫﺬﺍﻥ‬
‫ﺍﻟﺘﺤﺬﻳﺮﺍﻥﻋﻠﻰ ﺍﻟﺘﻔﺴﻴﺮ ﺍﻟﺼﺤﻴﺢ ﻟﻨﺘﺎﺉﺞ ﺍﻻﺧﺘﺒﺎﺭ ﻭﺗﺒﻌﺎﺗﻬﺎ ﻋﻠﻰ ﺍﻟﻮﺿﻊ ﺍﻷﻣﻨﻲ ﻟﻠﺘﻄﺒﻴﻖ‪ .‬ﺃﻭﻻً‪ ،‬ﻗﺪ‬
‫ﺗﺠﺘﺎﺯﺍﻟﺮﻣﻮﺯ ﺍﻟﻤﻮُﻟﺪّﺓ ﺑﻄﺮﻳﻘﺔ ﺣﺘﻤﻴﺔ ﺗﻤﺎﻣﺎً ﺍﻻﺧﺘﺒﺎﺭﺍﺕ ﺍﻹﺣﺼﺎﺉﻴﺔ ﻟﻠﻌﺸﻮﺍﺉﻴﺔ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ‬
‫ﺍﻟﻤﺜﺎﻝ‪،‬ﻗﺪ ﻳﻨُﺘﺞ ﻣﻮُﻟﺪّ ﺃﺭﻗﺎﻡ ﺷﺒﻪ ﻋﺸﻮﺍﺉﻴﺔ ﺧﻄﻴﺔ ﻣﺘﻄﺎﺑﻘﺔ‪ ،‬ﺃﻭ ﺧﻮﺍﺭﺯﻣﻴﺔ ﺗﺤﺴﺐ ﺗﺠﺰﺉﺔ ﺭﻗﻢ‬
‫ﻣﺘﺴﻠﺴﻞ‪،‬ﻣﺨُﺮﺟﺎﺕ ﺗﺠﺘﺎﺯ ﺍﻻﺧﺘﺒﺎﺭﺍﺕ‪ .‬ﻭﻣﻊ ﺫﻟﻚ‪ ،‬ﻳﻤُﻜﻦ ﻟﻠﻤﻬﺎﺟﻢ ﺍﻟﺬﻱ ﻳﻌﺮﻑ ﺍﻟﺨﻮﺍﺭﺯﻣﻴﺔ ﻭﺍﻟﺤﺎﻟﺔ‬
‫ﺍﻟﺪﺍﺧﻠﻴﺔﻟﻠﻤﻮُﻟﺪّ ﺍﺳﺘﻘﺮﺍء ﻣﺨُﺮﺟﺎﺗﻪ ﺑﻤﻮﺛﻮﻗﻴﺔ ﻛﺎﻣﻠﺔ ﻓﻲ ﻛﻼ ﺍﻻﺗﺠﺎﻫﻴﻦ ﺍﻷﻣﺎﻣﻲ ﻭﺍﻟﺨﻠﻔﻲ‪.‬‬

‫ﺛﺎﻧﻴﺎً‪،‬ﻗﺪ ﻻ ﺗﻜﻮﻥ ﺍﻟﺮﻣﻮﺯ ﺍﻟﺘﻲ ﺗﻔﺸﻞ ﻓﻲ ﺍﺟﺘﻴﺎﺯ ﺍﻻﺧﺘﺒﺎﺭﺍﺕ ﺍﻹﺣﺼﺎﺉﻴﺔ ﻟﻠﻌﺸﻮﺍﺉﻴﺔ ﻗﺎﺑﻠﺔ ﻟﻠﺘﻨﺒﺆ ﺑﻬﺎ‬
‫ﻋﻤﻠﻴﺎًﻓﻲ ﺃﻱ ﺣﺎﻟﺔ ﻋﻤﻠﻴﺔ‪ .‬ﺇﺫﺍ ﻓﺸﻞ ﺑﺖ ﻣﻌﻴﻦ ﻣﻦ ﺍﻟﺮﻣﺰ ﻓﻲ ﺍﻻﺧﺘﺒﺎﺭﺍﺕ‪ ،‬ﻓﻬﺬﺍ ﻳﻌﻨﻲ ﻓﻘﻂ ﺃﻥ‬
‫ﺗﺴﻠﺴﻞﺍﻟﺒﺘﺎﺕ ﺍﻟﻤﺮﺻﻮﺩﺓ ﻓﻲ ﺫﻟﻚ ﺍﻟﻤﻮﺿﻊ ﻳﺤﺘﻮﻱ ﻋﻠﻰ ﺧﺼﺎﺉﺺ ﻣﻦ ﻏﻴﺮ ﺍﻟﻤﺮﺟﺢ ﺃﻥ ﺗﻈﻬﺮ ﻓﻲ‬
‫ﺭﻣﺰﻋﺸﻮﺍﺉﻲ ﺣﻘﻴﻘﻲ‪ .‬ﻟﻜﻦ ﻣﺤﺎﻭﻟﺔ ﺍﻟﺘﻨﺒﺆ ﺑﻘﻴﻤﺔ ﺫﻟﻚ ﺍﻟﺒﺖ ﻓﻲ ﺍﻟﺮﻣﺰ ﺍﻟﺘﺎﻟﻲ‪ ،‬ﺑﻨﺎء ًﻋﻠﻰ ﺍﻟﺨﺼﺎﺉﺺ‬
‫ﺍﻟﻤﺮﺻﻮﺩﺓ‪،‬ﻗﺪ ﺗﻜﻮﻥ ﺃﻛﺜﺮ ﻣﻮﺛﻮﻗﻴﺔ ﺑﻘﻠﻴﻞ ﻣﻦ ﺍﻟﺘﺨﻤﻴﻦ ﺍﻷﻋﻤﻰ‪ .‬ﺇﻥ ﻣﻀﺎﻋﻔﺔ ﻫﺬﺍ ﺍﻟﺘﻔﺎﻭﺕ ﻓﻲ‬
‫ﺍﻟﻤﻮﺛﻮﻗﻴﺔﻋﺒﺮ ﻋﺪﺩ ﻛﺒﻴﺮ ﻣﻦ ﺍﻟﺒﺘﺎﺕ ﺍﻟﻤﻄﻠﻮﺏ ﺍﻟﺘﻨﺒﺆ ﺑﻬﺎ ﻓﻲ ﻭﻗﺖ ﻭﺍﺣﺪ ﻗﺪ ﻳﻌﻨﻲ ﺃﻥ ﺍﺣﺘﻤﺎﻟﻴﺔ‬
‫ﺍﻟﺘﻮﺻﻞﺇﻟﻰ ﺗﻨﺒﺆ ﺻﺤﻴﺢ ﻣﻨﺨﻔﻀﺔ ﻟﻠﻐﺎﻳﺔ‪.‬‬

‫ﺧﻄﻮﺍﺕﺍﻻﺧﺘﺮﺍﻕ‬

‫‪.١‬ﺣﺪﺩ ﻣﺘﻰ ﻭﻛﻴﻒ ﺗﺼُﺪﺭ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ ﻣﻦ ﺧﻼﻝ ﺍﺳﺘﻌﺮﺍﺽ ﺍﻟﺘﻄﺒﻴﻖ ﻣﻦ ﺻﻔﺤﺘﻪ ﺍﻷﻭﻟﻰ‬
‫ﻭﻭﻇﺎﺉﻒﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ‪ .‬ﻫﻨﺎﻙ ﺳﻠﻮﻛﺎﻥ ﺷﺎﺉﻌﺎﻥ‪:‬‬

‫ﻳﻘﻮﻡﺍﻟﺘﻄﺒﻴﻖ ﺑﺈﻧﺸﺎء ﺟﻠﺴﺔ ﺟﺪﻳﺪﺓ ﻓﻲ ﺃﻱ ﻭﻗﺖ ﻳﺘﻢ ﻓﻴﻪ ﺗﻠﻘﻲ ﻃﻠﺐ ﻻ ﻳﺮﺳﻞ ﺭﻣﺰﺍً‪.‬‬ ‫‪-‬‬

‫ﻳﻘﻮﻡﺍﻟﺘﻄﺒﻴﻖ ﺑﺈﻧﺸﺎء ﺟﻠﺴﺔ ﺟﺪﻳﺪﺓ ﺑﻌﺪ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﺍﻟﻨﺎﺟﺢ‪.‬‬ ‫‪-‬‬

‫ﻟﺤﺼﺎﺩﺃﻋﺪﺍﺩ ﻛﺒﻴﺮﺓ ﻣﻦ ﺍﻟﺮﻣﻮﺯ ﺑﻄﺮﻳﻘﺔ ﺁﻟﻴﺔ‪ ،‬ﻣﻦ ﺍﻷﻓﻀﻞ ﺗﺤﺪﻳﺪ ﻃﻠﺐ ﻭﺍﺣﺪ )ﻋﺎﺩﺓ ًﺇﻣﺎﻳﺤﺼﻞ‬
‫‪/‬ﺃﻭ ﺇﺭﺳﺎﻝ ﺗﺴﺠﻴﻞ ﺩﺧﻮﻝ( ﻣﻤﺎ ﻳﺆﺩﻱ ﺇﻟﻰ ﺇﺻﺪﺍﺭ ﺭﻣﺰ ﺟﺪﻳﺪ‪.‬‬

‫‪.٢‬ﻓﻲ ‪ ،Burp Suite‬ﺃﺭﺳﻞ ﻃﻠﺐ ﺇﻧﺸﺎء ﺟﻠﺴﺔ ﺟﺪﻳﺪﺓ ﺇﻟﻰ ‪ ،Burp Sequencer‬ﻭﺣﺪﺩ ﻣﻮﻗﻊ‬
‫ﺍﻟﺮﻣﺰ‪.‬ﺛﻢ ﺍﺑﺪﺃ ﻋﻤﻠﻴﺔ ﺍﻟﺘﻘﺎﻁ ﻣﺒﺎﺷﺮ ﻟﺠﻤﻊ ﺃﻛﺒﺮ ﻋﺪﺩ ﻣﻤﻜﻦ ﻣﻦ ﺍﻟﺮﻣﻮﺯ‪ .‬ﺇﺫﺍ ﻛﺎﻧﺖ ﺁﻟﻴﺔ ﺇﺩﺍﺭﺓ‬
‫ﺍﻟﺠﻠﺴﺔﻣﺨﺼﺼﺔ ﻗﻴﺪ ﺍﻻﺳﺘﺨﺪﺍﻡ‪ ،‬ﻭﻟﺪﻳﻚ ﻭﺻﻮﻝ ﻋﻦ ﺑﻌُﺪ ﻓﻘﻂ ﺇﻟﻰ ﺍﻟﺘﻄﺒﻴﻖ‪ ،‬ﻓﺎﺟﻤﻊ ﺍﻟﺮﻣﻮﺯ‬
‫ﺑﺄﺳﺮﻉﻣﺎ ﻳﻤﻜﻦ ﻟﺘﻘﻠﻴﻞ ﻓﻘﺪﺍﻥ ﺍﻟﺮﻣﻮﺯ ﺍﻟﻤﺼُﺪﺭﺓ ﻟﻠﻤﺴﺘﺨﺪﻣﻴﻦ ﺍﻵﺧﺮﻳﻦ ﻭﺗﻘﻠﻴﻞ ﺗﺄﺛﻴﺮ ﺃﻱ‬
‫ﺍﻋﺘﻤﺎﺩﻋﻠﻰ ﺍﻟﻮﻗﺖ‪.‬‬

‫‪.3‬ﺇﺫﺍ ﻛﺎﻧﺖ ﺁﻟﻴﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ ﺍﻟﺘﺠﺎﺭﻳﺔ ﻗﻴﺪ ﺍﻻﺳﺘﺨﺪﺍﻡ ﻭ‪/‬ﺃﻭ ﻛﺎﻥ ﻟﺪﻳﻚ ﻭﺻﻮﻝ ﻣﺤﻠﻲ ﺇﻟﻰ‬
‫ﺍﻟﺘﻄﺒﻴﻖ‪،‬ﻓﻴﻤﻜﻨﻚ ﺍﻟﺤﺼﻮﻝ ﻋﻠﻰ ﺗﺴﻠﺴﻼﺕ ﻛﺒﻴﺮﺓ ﺇﻟﻰ ﺃﺟﻞ ﻏﻴﺮ ﻣﺴﻤﻰ ﻣﻦ ﺭﻣﻮﺯ‬
‫ﺍﻟﺠﻠﺴﺔﻓﻲ ﻇﺮﻭﻑ ﺧﺎﺿﻌﺔ ﻟﻠﺮﻗﺎﺑﺔ‪.‬‬
‫‪223‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬

‫‪.٤‬ﺃﺛﻨﺎء ﻗﻴﺎﻡ ‪ Burp Sequencer‬ﺑﺠﻤﻊ ﺍﻟﺮﻣﻮﺯ‪ ،‬ﻓﻌﻞّ ﺇﻋﺪﺍﺩ "ﺍﻟﺘﺤﻠﻴﻞ ﺍﻟﺘﻠﻘﺎﺉﻲ" ﻟﻴﻘﻮﻡ ‪Burp‬‬
‫ﺑﺈﺟﺮﺍءﺍﻟﺘﺤﻠﻴﻞ ﺍﻹﺣﺼﺎﺉﻲ ﺗﻠﻘﺎﺉﻴﺎً ﻭﺑﺸﻜﻞ ﺩﻭﺭﻱ‪ .‬ﺍﺟﻤﻊ ‪ ٥٠٠‬ﺭﻣﺰ ﻋﻠﻰ ﺍﻷﻗﻞ ﻗﺒﻞ ﻣﺮﺍﺟﻌﺔ‬
‫ﺍﻟﻨﺘﺎﺉﺞﺑﺎﻟﺘﻔﺼﻴﻞ‪.‬‬
‫ﺇﺫﺍﻧﺠﺢ ﻋﺪﺩ ﻛﺎﻑ ٍﻣﻦ ﺍﻟﺒﺘﺎﺕ ﺩﺍﺧﻞ ﺍﻟﺮﻣﺰ ﻓﻲ ﺍﺟﺘﻴﺎﺯ ﺍﻻﺧﺘﺒﺎﺭﺍﺕ‪ ،‬ﻓﺎﺳﺘﻤﺮ ﻓﻲ ﺟﻤﻊ ﺍﻟﺮﻣﻮﺯ‬
‫ﻷﻃﻮﻝﻓﺘﺮﺓ ﻣﻤﻜﻨﺔ‪ ،‬ﻭﻣﺮﺍﺟﻌﺔ ﻧﺘﺎﺉﺞ ﺍﻟﺘﺤﻠﻴﻞ ﻣﻊ ﺍﻟﺘﻘﺎﻁ ﺍﻟﻤﺰﻳﺪ ﻣﻦ ﺍﻟﺮﻣﻮﺯ‪.‬‬

‫‪.٥‬ﺇﺫﺍ ﻓﺸﻠﺖ ﺍﻟﺮﻣﻮﺯ ﻓﻲ ﺍﺧﺘﺒﺎﺭﺍﺕ ﺍﻟﻌﺸﻮﺍﺉﻴﺔ ﻭﺗﺒﻴﻦ ﺃﻧﻬﺎ ﺗﺤﺘﻮﻱ ﻋﻠﻰ ﺃﻧﻤﺎﻁ ﻳﻤﻜﻦ ﺍﺳﺘﻐﻼﻟﻬﺎ‬
‫ﻟﻠﺘﻨﺒﺆﺑﺎﻟﺮﻣﻮﺯ ﺍﻟﻤﺴﺘﻘﺒﻠﻴﺔ‪ ،‬ﻓﺄﻋﺪ ﺇﺟﺮﺍء ﺍﻟﺘﻤﺮﻳﻦ ﻣﻦ ﻋﻨﻮﺍﻥ ‪ IP‬ﻣﺨﺘﻠﻒ ﻭﺍﺳﻢ ﻣﺴﺘﺨﺪﻡ‬
‫ﻣﺨﺘﻠﻒ)ﺇﻥ ﻭﺟﺪ(‪ .‬ﺳﻴﺴﺎﻋﺪﻙ ﻫﺬﺍ ﻋﻠﻰ ﺗﺤﺪﻳﺪ ﻣﺎ ﺇﺫﺍ ﻛﺎﻥ ﻗﺪ ﺗﻢ ﺭﺻﺪ ﺍﻟﻨﻤﻂ ﻧﻔﺴﻪ‪ ،‬ﻭﻣﺎ‬
‫ﺇﺫﺍﻛﺎﻥ ﻣﻦ ﺍﻟﻤﻤﻜﻦ ﺍﺳﺘﻘﺮﺍء ﺍﻟﺮﻣﻮﺯ ﺍﻟﻤﺴﺘﻠﻤﺔ ﻓﻲ ﺍﻟﺘﻤﺮﻳﻦ ﺍﻷﻭﻝ ﻟﺘﺤﺪﻳﺪ ﺍﻟﺮﻣﻮﺯ‬
‫ﺍﻟﻤﺴﺘﻠﻤﺔﻓﻲ ﺍﻟﺘﻤﺮﻳﻦ ﺍﻟﺜﺎﻧﻲ‪ .‬ﺃﺣﻴﺎﻧﺎً‪ ،‬ﻳﻈُﻬﺮ ﺗﺴﻠﺴﻞ ﺍﻟﺮﻣﻮﺯ ﺍﻟﺘﻲ ﻳﻠﺘﻘﻄﻬﺎ ﻣﺴﺘﺨﺪﻡ ﻭﺍﺣﺪ‬
‫ﻧﻤﻄﺎً‪.‬ﻟﻜﻦ ﻫﺬﺍ ﻟﻦ ﻳﺴﻤﺢ ﺑﺎﺳﺘﻘﺮﺍء ﺍﻟﺮﻣﻮﺯ ﺍﻟﺼﺎﺩﺭﺓ ﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺁﺧﺮﻳﻦ ﺑﺸﻜﻞ ﻣﺒﺎﺷﺮ‪،‬‬
‫ﻷﻥﻣﻌﻠﻮﻣﺎﺕ ﻣﺜﻞ ﻋﻨﻮﺍﻥ ‪ IP‬ﺍﻟﻤﺼﺪﺭ ﺗﺴُﺘﺨﺪﻡ ﻛﻤﺼﺪﺭ ﻟﻼﻧﺘﺮﻭﺑﻴﺎ )ﻣﺜﻞ ﺑﺬﺭﺓ ﻟﻤﻮﻟﺪ ﺃﺭﻗﺎﻡ‬
‫ﻋﺸﻮﺍﺉﻴﺔ(‪.‬‬

‫‪.6‬ﺇﺫﺍ ﻛﻨﺖ ﺗﻌﺘﻘﺪ ﺃﻥ ﻟﺪﻳﻚ ﻣﺎ ﻳﻜﻔﻲ ﻣﻦ ﺍﻟﻤﻌﺮﻓﺔ ﺑﺨﻮﺍﺭﺯﻣﻴﺔ ﺇﻧﺸﺎء ﺍﻟﺮﻣﺰ ﻟﺸﻦ ﻫﺠﻮﻡ ﺁﻟﻲ‬
‫ﺿﺪﺟﻠﺴﺎﺕ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺍﻵﺧﺮﻳﻦ‪ ،‬ﻓﻤﻦ ﺍﻟﻤﺮﺟﺢ ﺃﻥ ﺗﻜﻮﻥ ﺃﻓﻀﻞ ﻭﺳﻴﻠﺔ ﻟﺘﺤﻘﻴﻖ ﺫﻟﻚ‬
‫ﻣﻦﺧﻼﻝ ﺑﺮﻧﺎﻣﺞ ﻧﺼﻲ ﻣﺨﺼﺺ‪.‬‬
‫ﻳﻤﻜﻦﻟﻬﺬﺍ ﺇﻧﺸﺎء ﺭﻣﻮﺯ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺍﻷﻧﻤﺎﻁ ﺍﻟﻤﺤﺪﺩﺓ ﺍﻟﺘﻲ ﻻﺣﻈﺘﻬﺎ‪ ،‬ﻭﺗﻄﺒﻴﻖ ﺃﻱ ﺗﺮﻣﻴﺰ‬
‫ﺿﺮﻭﺭﻱ‪.‬ﺭﺍﺟﻊ ﺍﻟﻔﺼﻞ ‪ 14‬ﻟﻼﻃﻼﻉ ﻋﻠﻰ ﺑﻌﺾ ﺍﻟﺘﻘﻨﻴﺎﺕ ﺍﻟﻌﺎﻣﺔ ﻟﺘﻄﺒﻴﻖ ﺍﻷﺗﻤﺘﺔ ﻋﻠﻰ ﻫﺬﺍ‬
‫ﺍﻟﻨﻮﻉﻣﻦ ﺍﻟﻤﺸﺎﻛﻞ‪.‬‬
‫‪.٧‬ﺇﺫﺍ ﻛﺎﻥ ﺍﻟﻜﻮﺩ ﺍﻟﻤﺼﺪﺭﻱ ﻣﺘﺎﺣﺎً‪ ،‬ﻓﺮﺍﺟﻊ ﺍﻟﻜﻮﺩ ﺍﻟﻤﺴﺆﻭﻝ ﻋﻦ ﺗﻮﻟﻴﺪ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ ﺑﺪﻗﺔ ﻟﻔﻬﻢ‬
‫ﺍﻵﻟﻴﺔﺍﻟﻤﺴﺘﺨﺪﻣﺔ ﻭﺗﺤﺪﻳﺪ ﻣﺎ ﺇﺫﺍ ﻛﺎﻥ ﻗﺎﺑﻼً ﻟﻠﺘﻨﺒﺆ‪ .‬ﺇﺫﺍ ﺗﻢ ﺍﺳﺘﺨﻼﺹ ﺍﻹﻧﺘﺮﻭﺑﻴﺎ ﻣﻦ ﺑﻴﺎﻧﺎﺕ‬
‫ﻳﻤﻜﻦﺗﺤﺪﻳﺪﻫﺎ ﺩﺍﺧﻞ ﺍﻟﺘﻄﺒﻴﻖ ﺿﻤﻦ ﻧﻄﺎﻕ ﺍﻻﺧﺘﺮﺍﻕ ﺑﺎﻟﻘﻮﺓ ﺍﻟﻐﺎﺷﻤﺔ‪ ،‬ﻓﻔﻜﺮ ﻓﻲ ﺍﻟﻌﺪﺩ‬
‫ﺍﻟﻌﻤﻠﻲﻟﻠﻄﻠﺒﺎﺕ ﺍﻟﻼﺯﻣﺔ ﻻﺧﺘﺮﺍﻕ ﺭﻣﺰ ﺗﻄﺒﻴﻖ ﺑﺎﻟﻘﻮﺓ ﺍﻟﻐﺎﺷﻤﺔ‪.‬‬

‫ﺟﺮﺑﻬﺎ!‬

‫‪http://mdsec.net/auth/361/‬‬

‫ﺍﻟﺮﻣﻮﺯﺍﻟﻤﺸﻔﺮﺓ‬
‫ﺗﺴﺘﺨﺪﻡﺑﻌﺾ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺭﻣﻮﺯﺍً ﺗﺤﺘﻮﻱ ﻋﻠﻰ ﻣﻌﻠﻮﻣﺎﺕ ﻗﻴﻤّﺔ ﻋﻦ ﺍﻟﻤﺴﺘﺨﺪﻡ‪ ،‬ﻭﺗﺴﻌﻰ ﻟﺘﺠﻨﺐ‬
‫ﺍﻟﻤﺸﺎﻛﻞﺍﻟﻮﺍﺿﺤﺔ ﺍﻟﺘﻲ ﻗﺪ ﺗﻨﺠﻢ ﻋﻦ ﺫﻟﻚ ﻣﻦ ﺧﻼﻝ ﺗﺸﻔﻴﺮﻫﺎ ﻗﺒﻞ ﺇﺻﺪﺍﺭﻫﺎ ﻟﻠﻤﺴﺘﺨﺪﻣﻴﻦ‪ .‬ﻭﺑﻤﺎ‬
‫ﺃﻥﻫﺬﻩ ﺍﻟﺮﻣﻮﺯ ﻣﺸﻔﺮﺓ ﺑﺎﺳﺘﺨﺪﺍﻡ ﻣﻔﺘﺎﺡ ﺳﺮﻱ ﻏﻴﺮ ﻣﻌﺮﻭﻑ ﻟﻠﻤﺴﺘﺨﺪﻣﻴﻦ‪ ،‬ﻳﺒﺪﻭ ﻫﺬﺍ ﺍﻟﻨﻬﺞ ﻓﻌﺎﻻً‪،‬‬
‫ﺇﺫﻟﻦ ﻳﺘﻤﻜﻦ ﺍﻟﻤﺴﺘﺨﺪﻣﻮﻥ ﻣﻦ ﻓﻚ ﺗﺸﻔﻴﺮﻫﺎ ﻭﺍﻟﺘﻼﻋﺐ ﺑﻤﺤﺘﻮﻳﺎﺗﻬﺎ‪.‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬ ‫‪224‬‬

‫ﻣﻊﺫﻟﻚ‪ ،‬ﻓﻲ ﺑﻌﺾ ﺍﻟﺤﺎﻻﺕ‪ ،‬ﻭﺣﺴﺐ ﺧﻮﺍﺭﺯﻣﻴﺔ ﺍﻟﺘﺸﻔﻴﺮ ﺍﻟﻤﺴﺘﺨﺪﻣﺔ ﻭﻃﺮﻳﻘﺔ ﻣﻌﺎﻟﺠﺔ ﺍﻟﺘﻄﺒﻴﻖ‬
‫ﻟﻠﺮﻣﻮﺯ‪،‬ﻗﺪ ﻳﺘﻤﻜﻦ ﺍﻟﻤﺴﺘﺨﺪﻣﻮﻥ ﻣﻦ ﺍﻟﺘﻼﻋﺐ ﺑﻤﺤﺘﻮﻳﺎﺗﻬﺎ ﺍﻟﻤﻬﻤﺔ ﺩﻭﻥ ﻓﻚ ﺗﺸﻔﻴﺮﻫﺎ ﻓﻌﻠﻴﺎً‪ .‬ﻗﺪ‬
‫ﻳﺒﺪﻭﺍﻷﻣﺮ ﻏﺮﻳﺒﺎً‪ ،‬ﺇﻻ ﺃﻥ ﻫﺬﻩ ﺍﻟﻬﺠﻤﺎﺕ ﻓﻌﺎّﻟﺔ ﻭﺳﻬﻠﺔ ﺍﻟﺘﻨﻔﻴﺬ ﺃﺣﻴﺎﻧﺎً‪ ،‬ﻭﻗﺪ ﺃﺛﺒﺘﺖ ﺍﻟﻌﺪﻳﺪ ﻣﻦ‬
‫ﺍﻟﺘﻄﺒﻴﻘﺎﺕﺍﻟﻌﻤﻠﻴﺔ ﺿﻌﻔﻬﺎ‪ .‬ﺗﻌﺘﻤﺪ ﺃﻧﻮﺍﻉ ﺍﻟﻬﺠﻤﺎﺕ ﺍﻟﻘﺎﺑﻠﺔ ﻟﻠﺘﻄﺒﻴﻖ ﻋﻠﻰ ﺧﻮﺍﺭﺯﻣﻴﺔ ﺍﻟﺘﺸﻔﻴﺮ‬
‫ﺍﻟﻤﺴﺘﺨﺪﻣﺔ‪.‬‬

‫ﺷﻔﺮﺍﺕﺍﻟﺒﻨﻚ ﺍﻟﻤﺮﻛﺰﻱ ﺍﻷﻭﺭﻭﺑﻲ‬

‫ﺗﺴﺘﺨﺪﻡﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﻟﺘﻲ ﺗﺴﺘﺨﺪﻡ ﺍﻟﺮﻣﻮﺯ ﺍﻟﻤﺸﻔﺮﺓ ﺧﻮﺍﺭﺯﻣﻴﺔ ﺗﺸﻔﻴﺮ ﻣﺘﻤﺎﺛﻠﺔ‪ ،‬ﺑﺤﻴﺚ ﻳﻤﻜﻦ ﻓﻚ‬
‫ﺗﺸﻔﻴﺮﺍﻟﺮﻣﻮﺯ ﺍﻟﻤﺴﺘﻠﻤﺔ ﻣﻦ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﻻﺳﺘﻌﺎﺩﺓ ﻣﺤﺘﻮﻳﺎﺗﻬﺎ ﺫﺍﺕ ﺍﻟﻤﻌﻨﻰ‪ .‬ﺗﺴﺘﺨﺪﻡ ﺑﻌﺾ‬
‫ﺧﻮﺍﺭﺯﻣﻴﺎﺕﺍﻟﺘﺸﻔﻴﺮ ﺍﻟﻤﺘﻤﺎﺛﻠﺔ ﺷﻔﺮﺓ "ﺩﻓﺘﺮ ﺍﻟﺮﻣﻮﺯ ﺍﻹﻟﻜﺘﺮﻭﻧﻲ" )‪ .(ECB‬ﻳﻘﺴﻢ ﻫﺬﺍ ﺍﻟﻨﻮﻉ ﻣﻦ‬
‫ﺍﻟﺘﺸﻔﻴﺮﺍﻟﻨﺺ ﺍﻟﻌﺎﺩﻱ ﺇﻟﻰ ﻛﺘﻞ ﻣﺘﺴﺎﻭﻳﺔ ﺍﻟﺤﺠﻢ )ﻣﺜﻞ ‪ 8‬ﺑﺎﻳﺘﺎﺕ ﻟﻜﻞ ﻛﺘﻠﺔ(‪ ،‬ﻭﻳﺸُﻔﺮّ ﻛﻞ ﻛﺘﻠﺔ‬
‫ﺑﺎﺳﺘﺨﺪﺍﻡﺍﻟﻤﻔﺘﺎﺡ ﺍﻟﺴﺮﻱ‪ .‬ﺃﺛﻨﺎء ﻓﻚ ﺍﻟﺘﺸﻔﻴﺮ‪ ،‬ﺗﻔُﻚ ﺗﺸﻔﻴﺮ ﻛﻞ ﻛﺘﻠﺔ ﻣﻦ ﺍﻟﻨﺺ ﺍﻟﻤﺸﻔﺮ ﺑﺎﺳﺘﺨﺪﺍﻡ‬
‫ﺍﻟﻤﻔﺘﺎﺡﻧﻔﺴﻪ ﻻﺳﺘﻌﺎﺩﺓ ﺍﻟﻜﺘﻠﺔ ﺍﻷﺻﻠﻴﺔ ﻣﻦ ﺍﻟﻨﺺ ﺍﻟﻌﺎﺩﻱ‪ .‬ﻣﻦ ﻣﻴﺰﺍﺕ ﻫﺬﻩ ﺍﻟﻄﺮﻳﻘﺔ ﺃﻥ ﺍﻷﻧﻤﺎﻁ‬
‫ﺩﺍﺧﻞﺍﻟﻨﺺ ﺍﻟﻌﺎﺩﻱ ﻳﻤﻜﻦ ﺃﻥ ﺗﻨُﺘﺞ ﺃﻧﻤﺎﻃﺎً ﺩﺍﺧﻞ ﺍﻟﻨﺺ ﺍﻟﻤﺸﻔﺮ‪ ،‬ﻷﻥ ﺍﻟﻜﺘﻞ ﺍﻟﻤﺘﻄﺎﺑﻘﺔ ﻣﻦ ﺍﻟﻨﺺ‬
‫ﺍﻟﻌﺎﺩﻱﺳﺘﺆﺩﻱ ﺇﻟﻰ‪...‬‬
‫ﻧﺺﻣﺸﻔﺮ ‪ .f‬ﻟﺒﻌﺾ ﺍﻷﻧﻮﺍﻉ‪،‬‬
‫ﻣﻌﻠﻮﻣﺎﺕﺫﺍﺕ ﻣﻌﻨﻰ ﻣﻦ ‪ ،t‬ﻛﻤﺎ‬ ‫ﻣﻦﺍﻟﺒﻴﺎﻧﺎﺕ‪ ،‬ﻣﺜﻞ‬
‫ﻫﻮﻣﻮﺿﺢ ﻓﻲ ﺍﻟﺸﻜﻞ ‪.4-7‬‬ ‫ﺍﻟﻨﺺﺍﻟﻌﺎﺩﻱ‬

‫ﺍﻟﺸﻜﻞ‪:4-7‬ﻗﺪ ﺗﻜﻮﻥ ﺍﻷﻧﻤﺎﻁ ﺍﻟﻤﻮﺟﻮﺩﺓ ﻓﻲ ﺍﻟﻨﺺ‬

‫ﺍﻟﻌﺎﺩﻱﺍﻟﻤﺸﻔﺮ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺗﺸﻔﻴﺮ ‪ ECB‬ﻣﺮﺉﻴﺔ ﺩﺍﺧﻞ‬
‫ﺍﻟﻨﺺﺍﻟﻤﺸﻔﺮ ﺍﻟﻨﺎﺗﺞ‪.‬‬

‫ﻋﻠﻰﺍﻟﺮﻏﻢ ﻣﻦ ﻫﺬﺍ ﺍﻟﻌﻴﺐ ﻓﻲ ﺗﺸﻔﻴﺮ ‪ ،ECB‬ﺗﺴُﺘﺨﺪﻡ ﻫﺬﻩ ﺍﻟﺘﺸﻔﻴﺮﺍﺕ ﻏﺎﻟﺒﺎً ﻟﺘﺸﻔﻴﺮ‬

‫ﺍﻟﻤﻌﻠﻮﻣﺎﺕﺩﺍﺧﻞ ﺗﻄﺒﻴﻘﺎﺕ ﺍﻟﻮﻳﺐ‪ .‬ﺣﺘﻰ ﻓﻲ ﺍﻟﺤﺎﻻﺕ ﺍﻟﺘﻲ ﻻ ﺗﻈﻬﺮ ﻓﻴﻬﺎ ﻣﺸﻜﻠﺔ ﺍﻷﻧﻤﺎﻁ ﻓﻲ‬
‫ﺍﻟﻨﺺﺍﻟﻌﺎﺩﻱ‪ ،‬ﻗﺪ ﺗﻈﻞ ﺍﻟﺜﻐﺮﺍﺕ ﻣﻮﺟﻮﺩﺓ‪ .‬ﻭﻳﻌﻮﺩ ﺫﻟﻚ ﺇﻟﻰ ﺳﻠﻮﻙ ﺍﻟﺘﺸﻔﻴﺮ ﻓﻲ ﺗﺸﻔﻴﺮ ﻛﺘﻞ ﺍﻟﻨﺺ‬
‫ﺍﻟﻌﺎﺩﻱﺍﻟﻤﺘﻄﺎﺑﻘﺔ ﺩﺍﺧﻞ ﻛﺘﻞ ﻧﺺ ﻣﺸﻔﺮ ﻣﺘﻄﺎﺑﻘﺔ‪.‬‬

‫ﺧﺬﺑﻌﻴﻦ ﺍﻻﻋﺘﺒﺎﺭ ﺗﻄﺒﻴﻘﺎً ﺗﺤﺘﻮﻱ ﺭﻣﻮﺯﻩ ﻋﻠﻰ ﻋﺪﺓ ﻣﻜﻮﻧﺎﺕ ﺫﺍﺕ ﻣﻌﻨﻰ ﻣﺨﺘﻠﻒ‪ ،‬ﺑﻤﺎ ﻓﻲ ﺫﻟﻚ‬
‫ﻣﻌﺮﻑﻣﺴﺘﺨﺪﻡ ﺭﻗﻤﻲ‪:‬‬

‫؛ﺍﻟﻮﻗﺖ=‪000 634430423694715‬؛‪=dafydd‬؛ ﻣﻌﺮﻑ ﺍﻟﻤﺴﺘﺨﺪﻡ=‪218‬؛ ﺍﺳﻢ ﺍﻟﻤﺴﺘﺨﺪﻡ‪=iTradeEUR_1‬؛ ﺍﻟﺘﻄﺒﻴﻖ‬

‫‪rnd=2458992‬‬
‫‪225‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬

‫ﻋﻨﺪﻣﺎﻳﺘﻢ ﺗﺸﻔﻴﺮ ﻫﺬﻩ ﺍﻟﺮﻣﺰ‪ ،‬ﻓﻤﻦ ﺍﻟﻮﺍﺿﺢ ﺃﻧﻬﺎ ﻻ ﻣﻌﻨﻰ ﻟﻬﺎ ﻭﻣﻦ ﺍﻟﻤﺮﺟﺢ ﺃﻥ ﺗﺠﺘﺎﺯ ﺟﻤﻴﻊ‬
‫ﺍﻻﺧﺘﺒﺎﺭﺍﺕﺍﻹﺣﺼﺎﺉﻴﺔ ﺍﻟﻘﻴﺎﺳﻴﺔ ﻟﻠﻌﺸﻮﺍﺉﻴﺔ‪:‬‬

‫‪885A5C8131E4210F‬‬
‫‪329140AABD223F003A8309DDB6B970C47BA2E249A0670592D74BCD07D51A3E150EFC2E69‬‬
‫‪68BAC980742B9EF80A27CBBBC0618E3876FF3D6C6E6A7B9CB8FCA486F9E11922776F0307‬‬

‫ﺗﻌﻤﻞﺷﻔﺮﺓ ‪ ECB‬ﺍﻟﻤﺴﺘﺨﺪﻣﺔ ﻋﻠﻰ ﻛﺘﻞ ﺑﻴﺎﻧﺎﺕ ﻣﻜﻮﻧﺔ ﻣﻦ ‪ 8‬ﺑﺎﻳﺘﺎﺕ‪ ،‬ﻭﻳﺘﻢ ﺭﺑﻂ ﻛﺘﻞ ﺍﻟﻨﺺ‬
‫ﺍﻟﻌﺎﺩﻱﺑﺎﻟﻜﺘﻞ ﺍﻟﻤﻘﺎﺑﻠﺔ ﻣﻦ ﺍﻟﻨﺺ ﺍﻟﻤﺸﻔﺮ ﻋﻠﻰ ﺍﻟﻨﺤﻮ ﺍﻟﺘﺎﻟﻲ‪:‬‬

‫‪68BAC980742B9EF8‬‬ ‫‪rnd=2458‬‬
‫‪0A27CBBBC0618E38‬‬ ‫‪992‬؛ﺍﻟﺘﻄﺒﻴﻖ =‬
‫‪76FF3D6C6E6A7B9C‬‬ ‫ﺍﻱﺗﺮﻳﺪ ﻳﻮ‬
‫‪B8FCA486F9E11922‬‬ ‫=‪uid‬؛‪R_1‬‬
‫‪776F0307329140AA‬‬ ‫‪;218‬ﻣﺴﺘﺨﺪﻡ‬
‫‪BD223F003A8309DD‬‬ ‫ﺍﻻﺳﻢ=ﺩﺍﻑ‬
‫‪B6B970C47BA2E249‬‬ ‫ﻳﺎﺭﺩﺓ؛ﺍﻟﻮﻗﺖ‬
‫‪A0670592D74BCD07‬‬ ‫=‪6344304‬‬
‫‪D51A3E150EFC2E69‬‬ ‫‪23694715‬‬
‫‪885A5C8131E4210F‬‬ ‫‪000‬؛‬

‫ﺑﻤﺎﺃﻥ ﻛﻞ ﻛﺘﻠﺔ ﻧﺺ ﻣﺸﻔﺮ ﺳﺘﻔُﻚ ّﺗﺸﻔﻴﺮﻫﺎ ﺩﺍﺉﻤﺎً ﺇﻟﻰ ﻧﻔﺲ ﻛﺘﻠﺔ ﺍﻟﻨﺺ ﺍﻟﻌﺎﺩﻱ‪ ،‬ﻓﻤﻦ‬
‫ﺍﻟﻤﻤﻜﻦﻟﻠﻤﻬﺎﺟﻢ ﺍﻟﺘﻼﻋﺐ ﺑﺘﺴﻠﺴﻞ ﻛﺘﻞ ﺍﻟﻨﺺ ﺍﻟﻤﺸﻔﺮ ﻟﺘﻌﺪﻳﻞ ﺍﻟﻨﺺ ﺍﻟﻌﺎﺩﻱ ﺍﻟﻤﻘﺎﺑﻞ ﺑﻄﺮﻕ‬
‫ﻣﻔﻴﺪﺓ‪.‬ﻭﺣﺴﺐ ﺩﻗﺔ ﻣﻌﺎﻟﺠﺔ ﺍﻟﺘﻄﺒﻴﻖ ﻟﻠﺮﻣﺰ ﺍﻟﻨﺎﺗﺞ ﺑﻌﺪ ﻓﻚ ﺍﻟﺘﺸﻔﻴﺮ‪ ،‬ﻗﺪ ﻳﻤُﻜﻦّ ﻫﺬﺍ ﺍﻟﻤﻬﺎﺟﻢ ﻣﻦ‬
‫ﺍﻻﻧﺘﻘﺎﻝﺇﻟﻰ ﻣﺴﺘﺨﺪﻡ ﺁﺧﺮ ﺃﻭ ﺭﻓﻊ ﺻﻼﺣﻴﺎﺗﻪ‪.‬‬

‫ﻋﻠﻰﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﺇﺫﺍ ﺗﻢ ﺗﻜﺮﺍﺭ ﺍﻟﻜﺘﻠﺔ ﺍﻟﺜﺎﻧﻴﺔ ﺑﻌﺪ ﺍﻟﻜﺘﻠﺔ ﺍﻟﺮﺍﺑﻌﺔ‪ ،‬ﻓﺴﻴﻜﻮﻥ ﺗﺴﻠﺴﻞ ﺍﻟﻜﺘﻞ ﻛﻤﺎ‬
‫ﻳﻠﻲ‪:‬‬

‫‪68BAC980742B9EF8‬‬ ‫‪rnd=2458‬‬
‫‪0A27CBBBC0618E38‬‬ ‫‪992‬؛ﺍﻟﺘﻄﺒﻴﻖ =‬
‫‪76FF3D6C6E6A7B9C‬‬ ‫ﺍﻱﺗﺮﻳﺪ ﻳﻮ‬
‫‪B8FCA486F9E11922‬‬ ‫=‪uid‬؛‪R_1‬‬
‫‪0A27CBBBC0618E38‬‬ ‫‪992‬؛ﺍﻟﺘﻄﺒﻴﻖ =‬

‫‪776F0307329140AA‬‬ ‫‪;218‬ﻣﺴﺘﺨﺪﻡ‬
‫‪BD223F003A8309DD‬‬ ‫ﺍﻻﺳﻢ=ﺩﺍﻑ‬
‫‪B6B970C47BA2E249‬‬ ‫ﻳﺎﺭﺩﺓ؛ﺍﻟﻮﻗﺖ‬
‫‪A0670592D74BCD07‬‬ ‫=‪6344304‬‬
‫‪D51A3E150EFC2E69‬‬ ‫‪23694715‬‬
‫‪885A5C8131E4210F‬‬ ‫‪000‬؛‬

‫ﺍﻟﺮﻣﺰﺍﻟﺬﻱ ﺗﻢ ﻓﻚ ﺗﺸﻔﻴﺮﻩ ﺍﻵﻥ ﻳﺤﺘﻮﻱ ﻋﻠﻰ ﺭﻣﺰ ﻣﻌﺪﻝﻣﻌﺮﻑ ﺍﻟﻤﺴﺘﺨﺪﻡﺍﻟﻘﻴﻤﺔ‪ ،‬ﻭﺃﻳﻀﺎ ﻣﻜﺮﺭﺓ‬
‫ﺑﺮﻧﺎﻣﺞﺍﻟﻘﻴﻤﺔ‪ .‬ﻳﻌﺘﻤﺪ ﻣﺎ ﻳﺤﺪﺙ ﺑﺎﻟﻀﺒﻂ ﻋﻠﻰ ﻛﻴﻔﻴﺔ ﻣﻌﺎﻟﺠﺔ ﺍﻟﺘﻄﺒﻴﻖ ﻟﻠﺮﻣﺰ ﺍﻟﻤﻔُﻜﻚَّ‪ .‬ﻏﺎﻟﺒﺎً ﻣﺎ‬
‫ﺗﻔﺤﺺﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﻟﺘﻲ ﺗﺴﺘﺨﺪﻡ ﺍﻟﺮﻣﻮﺯ ﺑﻬﺬﻩ ﺍﻟﻄﺮﻳﻘﺔ ﺃﺟﺰﺍء ًﻣﻌﻴﻨﺔ ﻓﻘﻂ ﻣﻦ ﺍﻟﺮﻣﺰ ﺍﻟﻤﻔُﻜﻚَّ‪ ،‬ﻣﺜﻞ‬
‫ﻣﻌُﺮﻑِّﺍﻟﻤﺴﺘﺨﺪﻡ‪ .‬ﺇﺫﺍ ﺗﺼﺮﻑ ﺍﻟﺘﻄﺒﻴﻖ ﺑﻬﺬﻩ ﺍﻟﻄﺮﻳﻘﺔ‪ ،‬ﻓﺴﻴﻌُﺎﻟﺞ ﺍﻟﻄﻠﺐ ﻓﻲ ﺳﻴﺎﻕ ﺍﻟﻤﺴﺘﺨﺪﻡ‬
‫ﺍﻟﺬﻱﻟﺪﻳﻪﻣﻌﺮﻑ ﺍﻟﻤﺴﺘﺨﺪﻡﻣﻦ ‪ ،992‬ﺑﺪﻻ ًﻣﻦ ‪ 218‬ﺍﻷﺻﻠﻴﺔ‪.‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬ ‫‪226‬‬

‫ﻳﻌﺘﻤﺪﺍﻟﻬﺠﻮﻡ ﺍﻟﻤﻮﺻﻮﻑ ﻟﻠﺘﻮ ﻋﻠﻰ ﺇﺻﺪﺍﺭ ﺗﺼﺮﻳﺢ ﻣﻨﺎﺳﺐﺭﻧﺪ‬

‫ﺍﻟﻘﻴﻤﺔﺍﻟﺘﻲ ﺗﺘﻮﺍﻓﻖ ﻣﻊ ﻗﻴﻤﺔ ﺻﺎﻟﺤﺔﻣﻌﺮﻑ ﺍﻟﻤﺴﺘﺨﺪﻡﺍﻟﻘﻴﻤﺔ ﻋﻨﺪ ﺍﻟﺘﻼﻋﺐ ﺑﺎﻟﻜﺘﻞ‪ .‬ﻫﻨﺎﻙ ﻃﺮﻳﻘﺔ‬
‫ﺑﺪﻳﻠﺔﻭﺃﻛﺜﺮ ﻣﻮﺛﻮﻗﻴﺔ ﺗﺘﻤﺜﻞ ﻓﻲ ﺗﺴﺠﻴﻞ ﺍﺳﻢ ﻣﺴﺘﺨﺪﻡ ﻳﺤﺘﻮﻱ ﻋﻠﻰ ﻗﻴﻤﺔ ﺭﻗﻤﻴﺔ ﻋﻨﺪ ﺍﻹﺯﺍﺣﺔ‬
‫ﺍﻟﻤﻨﺎﺳﺒﺔ‪،‬ﻭﺗﻜﺮﺍﺭ ﻫﺬﻩ ﺍﻟﻜﺘﻠﺔ ﻻﺳﺘﺒﺪﺍﻝ ﺍﻟﻜﺘﻠﺔ ﺍﻟﺤﺎﻟﻴﺔ‪.‬ﻣﻌﺮﻑ ﺍﻟﻤﺴﺘﺨﺪﻡﺍﻟﻘﻴﻤﺔ‪ .‬ﺍﻓﺘﺮﺽ ﺃﻧﻚ ﻗﻤﺖ‬
‫ﺑﺘﺴﺠﻴﻞﺍﺳﻢ ﺍﻟﻤﺴﺘﺨﺪﻡﺩﺍﻑ‪،1‬ﻭﻳﺘﻢ ﺇﺻﺪﺍﺭﻫﺎ ﺑﺎﻟﺮﻣﺰ ﺍﻟﺘﺎﻟﻲ‪:‬‬

‫‪ADEBC07FFE87819D‬‬
‫‪73B38C14BD223F003A8309DDF29A5A6F0DC06C53905B5366F5F4684C0D2BBBB08BD834BB‬‬
‫‪9A5A47BF9B3B6603708F9DEAD67C7F4C76FF3D6C6E6A7B9CB8FCA486F9E11922A5BC430A‬‬

‫ﻛﺘﻞﺍﻟﻨﺺ ﺍﻟﻌﺎﺩﻱ ﻭﺍﻟﻨﺺ ﺍﻟﻤﺸﻔﺮ ﻟﻬﺬﻩ ﺍﻟﺮﻣﺰ ﻫﻲ ﻛﻤﺎ ﻳﻠﻲ‪:‬‬

‫‪9A5A47BF9B3B6603‬‬ ‫‪rnd=9224‬‬
‫‪708F9DEAD67C7F4C‬‬ ‫‪856‬؛ﺍﻟﺘﻄﺒﻴﻖ =‬
‫‪76FF3D6C6E6A7B9C‬‬ ‫ﺍﻱﺗﺮﻳﺪ ﻳﻮ‬
‫‪B8FCA486F9E11922‬‬ ‫=‪uid‬؛‪R_1‬‬
‫‪A5BC430A73B38C14‬‬ ‫‪;219‬ﻣﺴﺘﺨﺪﻡ‬
‫‪BD223F003A8309DD‬‬ ‫ﺍﻻﺳﻢ=ﺩﺍﻑ‬
‫‪F29A5A6F0DC06C53‬‬ ‫‪1‬؛ﺍﻟﻮﻗﺖ = ‪6‬‬
‫‪905B5366F5F4684C‬‬ ‫‪34430503‬‬
‫‪0D2BBBB08BD834BB‬‬ ‫‪61065250‬‬
‫‪ADEBC07FFE87819D‬‬ ‫‪;0‬‬

‫ﺇﺫﺍﻗﻤﺖ ﺑﻌﺪ ﺫﻟﻚ ﺑﻤﻀﺎﻋﻔﺔ ﺍﻟﻜﺘﻠﺔ ﺍﻟﺴﺎﺑﻌﺔ ﺑﻌﺪ ﺍﻟﻜﺘﻠﺔ ﺍﻟﺮﺍﺑﻌﺔ‪ ،‬ﻓﺴﻮﻑ ﺗﺤﺘﻮﻱ ﺍﻟﺮﻣﺰ ﺍﻟﺬﻱ ﺗﻢ‬
‫ﻓﻚﺗﺸﻔﻴﺮﻩ ﻋﻠﻰﻣﻌﺮﻑ ﺍﻟﻤﺴﺘﺨﺪﻡﻗﻴﻤﺔ ‪:1‬‬

‫‪9A5A47BF9B3B6603‬‬ ‫‪rnd=9224‬‬
‫‪708F9DEAD67C7F4C‬‬ ‫‪856‬؛ﺍﻟﺘﻄﺒﻴﻖ =‬
‫‪76FF3D6C6E6A7B9C‬‬ ‫ﺍﻱﺗﺮﻳﺪ ﻳﻮ‬
‫‪B8FCA486F9E11922‬‬ ‫=‪uid‬؛‪R_1‬‬
‫‪F29A5A6F0DC06C53‬‬ ‫‪1‬؛ﺍﻟﻮﻗﺖ = ‪6‬‬
‫‪A5BC430A73B38C14‬‬ ‫‪;219‬ﻣﺴﺘﺨﺪﻡ‬
‫‪BD223F003A8309DD‬‬ ‫ﺍﻻﺳﻢ=ﺩﺍﻑ‬
‫‪F29A5A6F0DC06C53‬‬ ‫‪1‬؛ﺍﻟﻮﻗﺖ = ‪6‬‬
‫‪905B5366F5F4684C‬‬ ‫‪34430503‬‬
‫‪0D2BBBB08BD834BB‬‬ ‫‪61065250‬‬
‫‪ADEBC07FFE87819D‬‬ ‫‪;0‬‬

‫ﻣﻦﺧﻼﻝ ﺗﺴﺠﻴﻞ ﻧﻄﺎﻕ ﻣﻨﺎﺳﺐ ﻣﻦ ﺃﺳﻤﺎء ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﻭﺇﻋﺎﺩﺓ ﺗﻨﻔﻴﺬ ﻫﺬﺍ ﺍﻟﻬﺠﻮﻡ‪ ،‬ﻗﺪ‬
‫ﺗﺘﻤﻜﻦﻣﻦ ﺍﻟﺘﻨﻘﻞ ﻋﺒﺮ ﺍﻟﻨﻄﺎﻕ ﺍﻟﻜﺎﻣﻞ ﻟﻸﺳﻤﺎء ﺍﻟﺼﺎﻟﺤﺔﻣﻌﺮﻑ ﺍﻟﻤﺴﺘﺨﺪﻡﺍﻟﻘﻴﻢ‪ ،‬ﻭﺑﺎﻟﺘﺎﻟﻲ ﻳﺘﻨﻜﺮﻭﻥ‬
‫ﻓﻲﻫﻴﺉﺔ ﻛﻞ ﻣﺴﺘﺨﺪﻡ ﻟﻠﺘﻄﺒﻴﻖ‪.‬‬

‫ﺟﺮﺑﻬﺎ!‬

‫‪http://mdsec.net/auth/363/‬‬
‫‪227‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬

‫ﺷﻔﺮﺍﺕ‪CBC‬‬
‫ﺃﺩﺕﻋﻴﻮﺏ ﺗﺸﻔﻴﺮ ‪ ECB‬ﺇﻟﻰ ﺗﻄﻮﻳﺮ ﺗﺸﻔﻴﺮﺍﺕ ﺗﺴﻠﺴﻞ ﻛﺘﻞ ﺍﻟﺘﺸﻔﻴﺮ )‪ .(CBC‬ﻓﻲ ﺗﺸﻔﻴﺮ ‪،CBC‬‬
‫ﻗﺒﻞﺗﺸﻔﻴﺮ ﻛﻞ ﻛﺘﻠﺔ ﻧﺺ ﻋﺎﺩﻱ‪ ،‬ﺗﺠُﺮﻯ ﻋﻤﻠﻴﺔ ‪ XOR‬ﻣﻊ ﻛﺘﻠﺔ ﺍﻟﻨﺺ ﺍﻟﻤﺸﻔﺮ ﺍﻟﺴﺎﺑﻘﺔ‪ ،‬ﻛﻤﺎ ﻫﻮ‬
‫ﻣﻮﺿﺢﻓﻲ ﺍﻟﺸﻜﻞ ‪ .5-7‬ﻫﺬﺍ ﻳﻤﻨﻊ ﺗﺸﻔﻴﺮ ﻛﺘﻞ ﺍﻟﻨﺺ ﺍﻟﻌﺎﺩﻱ ﺍﻟﻤﺘﻄﺎﺑﻘﺔ ﻓﻲ ﻛﺘﻞ ﻧﺺ ﻣﺸﻔﺮ‬
‫ﻣﺘﻄﺎﺑﻘﺔ‪.‬ﺃﺛﻨﺎء ﻓﻚ ﺍﻟﺘﺸﻔﻴﺮ‪ ،‬ﺗﻄُﺒﻖ ﻋﻤﻠﻴﺔ ‪ XOR‬ﺑﺸﻜﻞ ﻣﻌﻜﻮﺱ‪ ،‬ﻭﺗﺠُﺮﻯ ﻋﻤﻠﻴﺔ ‪ XOR‬ﻣﻊ ﻛﻞ ﻛﺘﻠﺔ‬
‫ﻣﻔﻜﻮﻛﺔﺍﻟﺘﺸﻔﻴﺮ ﻣﻊ ﻛﺘﻠﺔ ﺍﻟﻨﺺ ﺍﻟﻤﺸﻔﺮ ﺍﻟﺴﺎﺑﻘﺔ ﻻﺳﺘﻌﺎﺩﺓ ﺍﻟﻨﺺ ﺍﻟﻌﺎﺩﻱ ﺍﻷﺻﻠﻲ‪.‬‬

‫ﻧﺺﻋﺎﺩﻱ‬ ‫ﻧﺺﻋﺎﺩﻱ‬ ‫ﻧﺺﻋﺎﺩﻱ‬

‫ﻣﺘﺠﻪﺍﻟﺘﻬﻴﺉﺔ )‪(IV‬‬

‫ﺍﻟﺘﺸﻔﻴﺮﺍﻟﻜﺘﻠﻲ‬ ‫ﺍﻟﺘﺸﻔﻴﺮﺍﻟﻜﺘﻠﻲ‬ ‫ﺍﻟﺘﺸﻔﻴﺮﺍﻟﻜﺘﻠﻲ‬

‫ﻣﻔﺘﺎﺡ‬ ‫ﻣﻔﺘﺎﺡ‬ ‫ﻣﻔﺘﺎﺡ‬
‫ﺍﻟﺘﺸﻔﻴﺮ‬ ‫ﺍﻟﺘﺸﻔﻴﺮ‬ ‫ﺍﻟﺘﺸﻔﻴﺮ‬

‫ﺍﻟﻨﺺﺍﻟﻤﺸﻔﺮ‬ ‫ﺍﻟﻨﺺﺍﻟﻤﺸﻔﺮ‬ ‫ﺍﻟﻨﺺﺍﻟﻤﺸﻔﺮ‬

‫ﺍﻟﺸﻜﻞ‪:5-7‬ﻓﻲ ﺗﺸﻔﻴﺮ ‪ ،CBC‬ﻳﺘﻢ ﺇﺟﺮﺍء ﻋﻤﻠﻴﺔ ‪ XOR‬ﻟﻜﻞ ﻛﺘﻠﺔ ﻣﻦ ﺍﻟﻨﺺ ﺍﻟﻌﺎﺩﻱ ﻣﻘﺎﺑﻞ ﻛﺘﻠﺔ ﺍﻟﻨﺺ‬
‫ﺍﻟﻤﺸﻔﺮﺍﻟﺴﺎﺑﻘﺔ ﻗﺒﻞ ﺗﺸﻔﻴﺮﻫﺎ‪.‬‬

‫ﻷﻥﺗﺸﻔﻴﺮ ‪ CBC‬ﻳﺘﺠﻨﺐ ﺑﻌﺾ ﻣﺸﺎﻛﻞ ﺗﺸﻔﻴﺮ ‪ ،ECB‬ﺗﺴُﺘﺨﺪﻡ ﺧﻮﺍﺭﺯﻣﻴﺎﺕ ﺍﻟﺘﺸﻔﻴﺮ ﺍﻟﻤﺘﻤﺎﺛﻞ‬

‫ﺍﻟﻘﻴﺎﺳﻴﺔ‪،‬ﻣﺜﻞ ‪ DES‬ﻭ‪ ،AES‬ﺑﺸﻜﻞ ﻣﺘﻜﺮﺭ ﻓﻲ ﻭﺿﻊ ‪ .CBC‬ﻣﻊ ﺫﻟﻚ‪ ،‬ﻓﺈﻥ ﺍﻟﻄﺮﻳﻘﺔ ﺍﻟﺘﻲ ﺗﺴُﺘﺨﺪﻡ‬
‫ﺑﻬﺎﺭﻣﻮﺯ ‪ CBC‬ﺍﻟﻤﺸﻔﺮﺓ ﻓﻲ ﺗﻄﺒﻴﻘﺎﺕ ﺍﻟﻮﻳﺐ ﻏﺎﻟﺒﺎً ﺗﻌﻨﻲ ﺃﻥ ﺍﻟﻤﻬﺎﺟﻢ ﻗﺪ ﻳﺘﻤﻜﻦ ﻣﻦ ﺍﻟﺘﻼﻋﺐ‬
‫ﺑﺄﺟﺰﺍءﻣﻦ ﺍﻟﺮﻣﻮﺯ ﺍﻟﻤﻔﻜﻮﻛﺔ ﺩﻭﻥ ﻣﻌﺮﻓﺔ ﺍﻟﻤﻔﺘﺎﺡ ﺍﻟﺴﺮﻱ‪.‬‬

‫ﺧﺬﺑﻌﻴﻦ ﺍﻻﻋﺘﺒﺎﺭ ﺃﺣﺪ ﺍﻻﺧﺘﻼﻓﺎﺕ ﻓﻲ ﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﺴﺎﺑﻖ ﺍﻟﺬﻱ ﺗﺤﺘﻮﻱ ﺭﻣﻮﺯﻩ ﻋﻠﻰ ﻋﺪﺓ ﻣﻜﻮﻧﺎﺕ‬
‫ﺫﺍﺕﻣﻌﻨﻰ ﻣﺨﺘﻠﻒ‪ ،‬ﺑﻤﺎ ﻓﻲ ﺫﻟﻚ ﻣﻌﺮﻑ ﻣﺴﺘﺨﺪﻡ ﺭﻗﻤﻲ‪:‬‬
‫؛ﻣﻌﺮﻑ ﺍﻟﻤﺴﺘﺨﺪﻡ=‪216‬؛ ﺍﻟﻮﻗﺖ=‪6343303‬؛‪=eBankProdTC‬؛ ﺍﻟﺘﻄﺒﻴﻖ‪rnd=191432758301‬‬

‫ﻛﻤﺎﻛﺎﻥ ﻣﻦ ﻗﺒﻞ‪ ،‬ﻋﻨﺪﻣﺎ ﻳﺘﻢ ﺗﺸﻔﻴﺮ ﻫﺬﻩ ﺍﻟﻤﻌﻠﻮﻣﺎﺕ‪ ،‬ﻓﺈﻧﻬﺎ ﺗﺆﺩﻱ ﺇﻟﻰ ﺭﻣﺰ ﻻ ﻣﻌﻨﻰ ﻟﻪ ﻋﻠﻰ ﻣﺎ ﻳﺒﺪﻭ‪:‬‬

‫‪6E459A93635636F45D7B1A43163201477‬‬
‫‪0FB1F1AFB4C874E695AAFC9AA4C2269D3E8E66BBA9B2829B173F255D447C51321586257C‬‬

‫ﻷﻥﻫﺬﺍ ﺍﻟﺮﻣﺰ ﻣﺸُﻔﺮّ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺗﺸﻔﻴﺮ ‪ ،CBC‬ﻓﻌﻨﺪ ﻓﻚ ﺗﺸﻔﻴﺮﻩ‪ ،‬ﺗﺠُﺮﻯ ﻋﻤﻠﻴﺔ ‪ XOR‬ﻟﻜﻞ ﻛﺘﻠﺔ ﻣﻦ‬
‫ﺍﻟﻨﺺﺍﻟﻤﺸﻔﺮ ﻋﻠﻰ ﺍﻟﻜﺘﻠﺔ ﺍﻟﺘﺎﻟﻴﺔ ﻣﻦ ﺍﻟﻨﺺ ﺍﻟﻤﻔﻜﻮﻙ ﻟﻠﺤﺼﻮﻝ ﻋﻠﻰ ﺍﻟﻨﺺ ﺍﻟﻌﺎﺩﻱ‪ .‬ﺍﻵﻥ‪ ،‬ﺇﺫﺍ ﻋﺪﻝّ‬
‫ﺍﻟﻤﻬﺎﺟﻢﺃﺟﺰﺍء ًﻣﻦ ﺍﻟﻨﺺ ﺍﻟﻤﺸﻔﺮ )ﺍﻟﺮﻣﺰ ﺍﻟﺬﻱ ﺍﺳﺘﻠﻤﻪ(‪ ،‬ﻓﺈﻥ ﻫﺬﺍ ﻳﺆُﺩﻱ ﺇﻟﻰ ﻓﻚ ﺗﺸﻔﻴﺮ ﺗﻠﻚ ﺍﻟﻜﺘﻠﺔ‬
‫ﺗﺤﺪﻳﺪﺍًﻭﺗﺤﻮﻳﻠﻬﺎ ﺇﻟﻰ ﺑﻴﺎﻧﺎﺕ ﻏﻴﺮ ﻫﺎﻣﺔ‪ .‬ﻭﻣﻊ ﺫﻟﻚ‪ ،‬ﻓﺈﻧﻪ ﻳﺆُﺩﻱ ﺃﻳﻀﺎً ﺇﻟﻰ ﺇﺟﺮﺍء ﻋﻤﻠﻴﺔ ‪ XOR‬ﻟﻠﻜﺘﻠﺔ‬
‫ﺍﻟﺘﺎﻟﻴﺔﻣﻦ ﺍﻟﻨﺺ ﺍﻟﻤﻔﻜﻮﻙ ﻋﻠﻰ ﻛﺘﻠﺔ ﻣﺨﺘﻠﻔﺔ‪.‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬ ‫‪228‬‬

‫ﻗﻴﻤﺔ‪،‬ﻣﻤﺎ ﻳﻨﺘﺞ ﻋﻨﻪ ﻧﺺ ﻋﺎﺩﻱ ﻣﻌﺪﻝّ ﻭﻟﻜﻨﻪ ﻻ ﻳﺰﺍﻝ ﺫﺍ ﻣﻌﻨﻰ‪ .‬ﺑﻤﻌﻨﻰ ﺁﺧﺮ‪ ،‬ﻣﻦ ﺧﻼﻝ ﺍﻟﺘﻼﻋﺐ‬
‫ﺑﻜﺘﻠﺔﻭﺍﺣﺪﺓ ﻣﻦ ﺍﻟﺮﻣﺰ‪ ،‬ﻳﻤﻜﻦ ﻟﻠﻤﻬﺎﺟﻢ ﺗﻌﺪﻳﻞ ﻣﺤﺘﻮﻳﺎﺕ ﺍﻟﻜﺘﻠﺔ ﺍﻟﺘﻲ ﺗﻠﻴﻬﺎ ﺑﺸﻜﻞ ﻣﻨﻬﺠﻲ‪ .‬ﻭﺑﻨﺎء ً‬
‫ﻋﻠﻰﻛﻴﻔﻴﺔ ﻣﻌﺎﻟﺠﺔ ﺍﻟﺘﻄﺒﻴﻖ ﻟﻠﺮﻣﺰ ﺍﻟﻨﺎﺗﺞ ﺑﻌﺪ ﻓﻚ ﺗﺸﻔﻴﺮﻩ‪ ،‬ﻗﺪ ﻳﻤُﻜﻦّ ﻫﺬﺍ ﺍﻟﻤﻬﺎﺟﻢ ﻣﻦ ﺍﻟﺘﺒﺪﻳﻞ ﺇﻟﻰ‬
‫ﻣﺴﺘﺨﺪﻡﺁﺧﺮ ﺃﻭ ﺗﺼﻌﻴﺪ ﺻﻼﺣﻴﺎﺗﻪ‪.‬‬

‫ﻟﻨﺮ َﻛﻴﻒ‪ .‬ﻓﻲ ﺍﻟﻤﺜﺎﻝ ﺍﻟﻤﻮﺿﺢ‪ ،‬ﻳﻌﻤﻞ ﺍﻟﻤﻬﺎﺟﻢ ﻋﺒﺮ ﺍﻟﺮﻣﺰ ﺍﻟﻤﺸﻔﺮ‪ ،‬ﻣﻐُﻴﺮّﺍً ﺣﺮﻓﺎً ﻭﺍﺣﺪﺍً ﻓﻲ ﻛﻞ‬
‫ﻣﺮﺓﺑﻄﺮﻕ ﻋﺸﻮﺍﺉﻴﺔ‪ ،‬ﻭﻣﺮُﺳﻼً ﻛﻞ ﺭﻣﺰ ﻣﻌُﺪﻝّ ﺇﻟﻰ ﺍﻟﺘﻄﺒﻴﻖ‪ .‬ﻳﺘﻀﻤﻦ ﻫﺬﺍ ﻋﺪﺩﺍً ﻛﺒﻴﺮﺍً ﻣﻦ ﺍﻟﻄﻠﺒﺎﺕ‪.‬‬
‫ﻓﻴﻤﺎﻳﻠﻲ ﻣﺠﻤﻮﻋﺔ ﻣﺨﺘﺎﺭﺓ ﻣﻦ ﺍﻟﻘﻴﻢ ﺍﻟﻨﺎﺗﺠﺔ ﻋﻦ ﻓﻚ ﺗﺸﻔﻴﺮ ﺍﻟﺘﻄﺒﻴﻖ ﻟﻜﻞ ﺭﻣﺰ ﻣﻌُﺪﻝّ‪:‬‬

‫?????????‪58301832‬؛ ﺍﻟﺘﻄﺒﻴﻖ=‪eBankProdTC‬؛ ﻣﻌﺮﻑ ﺍﻟﻤﺴﺘﺨﺪﻡ=‪216‬؛ ﺍﻟﻮﻗﺖ=‪6343303‬؛‬

‫????????‪12327583‬؛ ﺍﻟﺘﻄﺒﻴﻖ = ‪eBankProdTC‬؛ ‪uid = 216‬؛ ﺍﻟﻮﻗﺖ = ‪6343303‬؛ ‪= 1914‬‬
‫‪?????????rnd‬؛ ﺃﺱ‪=e‬؛ﺍﻟﺘﻄﺒﻴﻖ?????????‪rnd=1914‬؛ﺍﻟﻮﻗﺖ=‪6343303‬؛‪uid=216‬؛‬
‫‪p=eBankProdTC‬ﺃ‪ rnd=191432758301?????????nkP‬؛ﺍﻟﻮﻗﺖ=‪6343303‬؛‪uid=216‬؛‬
‫‪ankProdTC‬ﺱ‪ rnd=191432758301?????????nkProd‬؛ﺍﻟﻮﻗﺖ=‪6343303‬؛‪uid=216‬؛‬
‫‪odTC‬ﻳﻮ‪C;uid=216;time=6343303;rnd=191432758301;app=eBa?????????;ui‬ﻫـ=‬
‫‪216‬؛ﺍﻟﻮﻗﺖ = ‪6343303‬؛ ‪rnd = 191432758301‬؛ ﺍﻟﺘﻄﺒﻴﻖ = ‪?????????eBa‬؛ ﻣﻌﺮﻑ‬
‫ﺍﻟﻤﺴﺘﺨﺪﻡ= ‪622‬؛ ﺍﻟﻮﻗﺖ = ‪6343303‬؛ ‪rnd = 191432758301‬؛ ﺍﻟﺘﻄﺒﻴﻖ =‬
‫‪?????????eBankProdTC‬؛ ﺍﻟﻮﻗﺖﺩ=‪6343303‬؛ ‪rnd=191432758301‬؛ ﺍﻟﺘﻄﺒﻴﻖ‬
‫=‪????????eBankProdTC‬؛ ﺍﻟﻮﻗﺖ=‪0356343‬؛‬

‫ﻓﻲﻛﻞ ﺣﺎﻟﺔ‪ ،‬ﺗﻔُﻚ ﺗﺸﻔﻴﺮ ﺍﻟﻜﺘﻠﺔ ﺍﻟﺘﻲ ﻋﺪﻟّﻬﺎ ﺍﻟﻤﻬﺎﺟﻢ ﺇﻟﻰ ﺑﻴﺎﻧﺎﺕ ﻏﻴﺮ ﻣﺮﻏﻮﺏ ﻓﻴﻬﺎ‪ ،‬ﻛﻤﺎ ﻫﻮ ﻣﺘﻮﻗﻊ )‬
‫ﻳﺸُﺎﺭﺇﻟﻴﻪ ﺑـ ?????????(‪ .‬ﺃﻣﺎ ﺍﻟﻜﺘﻠﺔ ﺍﻟﺘﺎﻟﻴﺔ‪ ،‬ﻓﺘﻔُﻚ ﺗﺸﻔﻴﺮﻫﺎ ﺇﻟﻰ ﻧﺺ ﺫﻱ ﻣﻌﻨﻰ ﻳﺨﺘﻠﻒ ﻗﻠﻴﻼ ًﻋﻦ‬
‫ﺍﻟﺮﻣﺰﺍﻷﺻﻠﻲ‪ .‬ﻭﻛﻤﺎ ﻫﻮ ﻣﻮﺿﺢ ﺳﺎﺑﻘﺎً‪ ،‬ﻳﺤﺪﺙ ﻫﺬﺍ ﺍﻻﺧﺘﻼﻑ ﻷﻥ ﺍﻟﻨﺺ ﺍﻟﻤﻔُﻜﻚ ﻳﺠُﺮﻯ ﻋﻠﻴﻪ ﻋﻤﻠﻴﺔ‬
‫‪ XOR‬ﻣﻊ ﻛﺘﻠﺔ ﺍﻟﻨﺺ ﺍﻟﻤﺸﻔﺮ ﺍﻟﺴﺎﺑﻘﺔ‪ ،‬ﺍﻟﺘﻲ ﻋﺪﻟّﻬﺎ ﺍﻟﻤﻬﺎﺟﻢ ﻗﻠﻴﻼ‪ً.‬‬

‫ﻋﻠﻰﺍﻟﺮﻏﻢ ﻣﻦ ﺃﻥ ﺍﻟﻤﻬﺎﺟﻢ ﻻ ﻳﺮﻯ ﺍﻟﻘﻴﻢ ﺍﻟﻤﻔُﻜﻜﺔ‪ ،‬ﺇﻻ ﺃﻥ ﺍﻟﺘﻄﺒﻴﻖ ﻳﺤﺎﻭﻝ ﻣﻌﺎﻟﺠﺘﻬﺎ‪ ،‬ﻭﻳﺮﻯ‬
‫ﺍﻟﻤﻬﺎﺟﻢﺍﻟﻨﺘﺎﺉﺞ ﻓﻲ ﺍﺳﺘﺠﺎﺑﺎﺕ ﺍﻟﺘﻄﺒﻴﻖ‪ .‬ﻳﻌﺘﻤﺪ ﻣﺎ ﻳﺤﺪﺙ ﺑﺎﻟﻀﺒﻂ ﻋﻠﻰ ﻛﻴﻔﻴﺔ ﺗﻌﺎﻣﻞ ﺍﻟﺘﻄﺒﻴﻖ‬
‫ﻣﻊﺍﻟﺠﺰء ﺍﻟﺘﺎﻟﻒ ﻣﻦ ﺍﻟﺮﻣﺰ ﺍﻟﻤﻔُﻜﻚ‪ .‬ﺇﺫﺍ ﺭﻓﺾ ﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﺮﻣﻮﺯ ﺍﻟﺘﻲ ﺗﺤﺘﻮﻱ ﻋﻠﻰ ﺃﻱ ﺑﻴﺎﻧﺎﺕ ﻏﻴﺮ‬
‫ﺻﺎﻟﺤﺔ‪،‬ﻳﻔﺸﻞ ﺍﻟﻬﺠﻮﻡ‪ .‬ﻭﻣﻊ ﺫﻟﻚ‪ ،‬ﻏﺎﻟﺒﺎً ﻣﺎ ﺗﻔﺤﺺ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﻟﺘﻲ ﺗﺴﺘﺨﺪﻡ ﺍﻟﺮﻣﻮﺯ ﺑﻬﺬﻩ ﺍﻟﻄﺮﻳﻘﺔ‬
‫ﺃﺟﺰﺍء ًﻣﻌﻴﻨﺔ ﻓﻘﻂ ﻣﻦ ﺍﻟﺮﻣﺰ ﺍﻟﻤﻔُﻜﻚ‪ ،‬ﻣﺜﻞ ﻣﻌُﺮﻑّ ﺍﻟﻤﺴﺘﺨﺪﻡ‪ .‬ﺇﺫﺍ ﺗﺼﺮﻑ ﺍﻟﺘﻄﺒﻴﻖ ﻋﻠﻰ ﻫﺬﺍ‬
‫ﺍﻟﻨﺤﻮ‪،‬ﻓﺈﻥ ﺍﻟﻤﺜﺎﻝ ﺍﻟﺜﺎﻣﻦ ﺍﻟﻤﻮﺿﺢ ﻓﻲ ﺍﻟﻘﺎﺉﻤﺔ ﺍﻟﺴﺎﺑﻘﺔ ﻳﻨﺠﺢ‪ ،‬ﻭﻳﻌﺎﻟﺞ ﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﻄﻠﺐ ﻓﻲ ﺳﻴﺎﻕ‬
‫ﺍﻟﻤﺴﺘﺨﺪﻡﺍﻟﺬﻱ ﻟﺪﻳﻪ‪...‬ﻣﻌﺮﻑ ﺍﻟﻤﺴﺘﺨﺪﻡﻣﻦ ‪ ،226‬ﺑﺪﻻ ًﻣﻦ ‪ 216‬ﺍﻷﺻﻠﻴﺔ‪.‬‬

‫ﻳﻤﻜﻨﻚﺑﺴﻬﻮﻟﺔ ﺍﺧﺘﺒﺎﺭ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺑﺤﺜﺎً ﻋﻦ ﻫﺬﻩ ﺍﻟﺜﻐﺮﺓ ﺑﺎﺳﺘﺨﺪﺍﻡ ﻧﻮﻉ ﺍﻟﺤﻤﻮﻟﺔ "‪"bit flipper‬‬
‫ﻓﻲﺑﺮﻧﺎﻣﺞ ‪ .Burp Intruder‬ﺃﻭﻻً‪ ،‬ﻋﻠﻴﻚ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﺇﻟﻰ ﺍﻟﺘﻄﺒﻴﻖ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺣﺴﺎﺑﻚ‬
‫ﺍﻟﺨﺎﺹ‪.‬ﺑﻌﺪ ﺫﻟﻚ‪ ،‬ﺳﺘﺠﺪ ﺻﻔﺤﺔ ﻟﻠﺘﻄﺒﻴﻖ ﺗﻌﺘﻤﺪ ﻋﻠﻰ ﺟﻠﺴﺔ ﺗﺴﺠﻴﻞ ﺩﺧﻮﻝ‪ ،‬ﻭﺗﻌﺮﺽ ﻫﻮﻳﺔ‬
‫ﺍﻟﻤﺴﺘﺨﺪﻡﺍﻟﻤﺴﺠﻞ ﺩﺧﻮﻟﻪ ﺿﻤﻦ ﺍﻻﺳﺘﺠﺎﺑﺔ‪ .‬ﻋﺎﺩﺓ‪ ً،‬ﺗﺴُﺘﺨﺪﻡ ﺻﻔﺤﺔ ﺍﻟﻮﺻﻮﻝ ﺍﻟﺮﺉﻴﺴﻴﺔ‬
‫ﻟﻠﻤﺴﺘﺨﺪﻡﺃﻭ ﺻﻔﺤﺔ ﺗﻔﺎﺻﻴﻞ ﺣﺴﺎﺑﻪ ﻟﻬﺬﺍ ﺍﻟﻐﺮﺽ‪ .‬ﻳﻮﺿﺢ ﺍﻟﺸﻜﻞ ‪ 6-7‬ﺑﺮﻧﺎﻣﺞ ‪Burp Intruder‬‬
‫ﻣﻌُﺪﺍًّﻻﺳﺘﻬﺪﺍﻑ ﺍﻟﺼﻔﺤﺔ ﺍﻟﺮﺉﻴﺴﻴﺔ ﻟﻠﻤﺴﺘﺨﺪﻡ‪ ،‬ﻣﻊ ﺗﺤﺪﻳﺪ ﺭﻣﺰ ﺍﻟﺠﻠﺴﺔ ﺍﻟﻤﺸﻔﺮ ﻛﻤﻮﺿﻊ ﺣﻤﻮﻟﺔ‪.‬‬
‫‪9‬‬

‫ﺍﻟﺸﻜﻞ‪:6-7‬ﺗﻜﻮﻳﻦ ‪ Burp Intruder‬ﻟﺘﻌﺪﻳﻞ ﺭﻣﺰ ﺟﻠﺴﺔ ﻣﺸﻔﺮ‬

‫ﻳﻮﺿﺢﺍﻟﺸﻜﻞ ‪ 7-7‬ﺗﻜﻮﻳﻦ ﺍﻟﺤﻤﻮﻟﺔ ﺍﻟﻤﻄﻠﻮﺑﺔ‪ .‬ﻳﻮُﺟﻪّ ﻫﺬﺍ ﺍﻟﺘﻜﻮﻳﻦ ﺑﺮﻧﺎﻣﺞ ‪ Burp‬ﻟﻠﻌﻤﻞ ﻋﻠﻰ‬
‫ﺍﻟﻘﻴﻤﺔﺍﻷﺻﻠﻴﺔ ﻟﻠﺮﻣﺰ‪ ،‬ﻭﻣﻌﺎﻣﻠﺘﻬﺎ ﻛﺮﻣﺰ ﺳﺪﺍﺳﻲ ﻋﺸﺮﻱ ﻣﺮُﻣﺰّ ﺑﻨﻈﺎﻡ ‪ ،ASCII‬ﻭﻗﻠﺐ ﻛﻞ ﺑﺖ ﻋﻨﺪ‬
‫ﻛﻞﻣﻮﺿﻊ ﺣﺮﻑ‪ .‬ﻳﻌُﺪ ّﻫﺬﺍ ﺍﻟﻨﻬﺞ ﻣﺜﺎﻟﻴﺎً ﻷﻧﻪ ﻳﺘﻄﻠﺐ ﻋﺪﺩﺍً ﺻﻐﻴﺮﺍً ﻧﺴﺒﻴﺎً ﻣﻦ ﺍﻟﻄﻠﺒﺎﺕ )ﺛﻤﺎﻧﻴﺔ‬
‫ﻃﻠﺒﺎﺕﻟﻜﻞ ﺑﺎﻳﺖ ﻣﻦ ﺑﻴﺎﻧﺎﺕ ﺍﻟﺮﻣﺰ(‪ ،‬ﻭﻳﺤُﺪﺩّ ﺩﺍﺉﻤﺎً ﺗﻘﺮﻳﺒﺎً ﻣﺎ ﺇﺫﺍ ﻛﺎﻥ ﺍﻟﺘﻄﺒﻴﻖ ﻣﻌُﺮﺿّﺎً ﻟﻠﺨﻄﺮ‪.‬‬
‫ﻳﺴﻤﺢﻟﻚ ﻫﺬﺍ ﺑﺎﺳﺘﺨﺪﺍﻡ ﻫﺠﻮﻡ ﺃﻛﺜﺮ ﺗﺮﻛﻴﺰﺍً ﻟﺘﻨﻔﻴﺬ ﻋﻤﻠﻴﺔ ﺍﺳﺘﻐﻼﻝ ﻓﻌﻠﻲ‪.‬‬

‫ﻋﻨﺪﺗﻨﻔﻴﺬ ﺍﻟﻬﺠﻮﻡ‪ ،‬ﻻ ﺗﺤُﺪﺙ ﺍﻟﻄﻠﺒﺎﺕ ﺍﻷﻭﻟﻴﺔ ﺃﻱ ﺗﻐﻴﻴﺮ ﻣﻠﺤﻮﻅ ﻓﻲ ﺍﺳﺘﺠﺎﺑﺎﺕ ﺍﻟﺘﻄﺒﻴﻖ‪ ،‬ﻭﺗﻈﻞ‬
‫ﺟﻠﺴﺔﺍﻟﻤﺴﺘﺨﺪﻡ ﺳﻠﻴﻤﺔ‪ .‬ﻭﻫﺬﺍ ﺃﻣﺮ ﻣﺜﻴﺮ ﻟﻼﻫﺘﻤﺎﻡ ﻓﻲ ﺣﺪ ﺫﺍﺗﻪ‪ ،‬ﻷﻧﻪ ﻳﺸُﻴﺮ ﺇﻟﻰ ﺃﻥ ﺍﻟﺠﺰء ﺍﻷﻭﻝ ﻣﻦ‬
‫ﺍﻟﺮﻣﺰﻻ ﻳﺴُﺘﺨﺪﻡ ﻟﺘﺤﺪﻳﺪ ﻫﻮﻳﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺍﻟﻤﺴُﺠﻞَّ ﺩﺧﻮﻟﻪ‪ .‬ﺗﺆُﺩﻱ ﺍﻟﻌﺪﻳﺪ ﻣﻦ ﺍﻟﻄﻠﺒﺎﺕ ﺍﻟﻼﺣﻘﺔ‬
‫ﻟﻠﻬﺠﻮﻡﺇﻟﻰ ﺇﻋﺎﺩﺓ ﺍﻟﺘﻮﺟﻴﻪ ﺇﻟﻰ ﺻﻔﺤﺔ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ‪ ،‬ﻣﻤﺎ ﻳﺸُﻴﺮ ﺇﻟﻰ ﺃﻥ ﺍﻟﺘﻌﺪﻳﻞ ﻗﺪ ﺃﺑﻄﻞ ﺍﻟﺮﻣﺰ‬
‫ﺑﻄﺮﻳﻘﺔﻣﺎ‪ .‬ﻭﺍﻷﻫﻢ ﻣﻦ ﺫﻟﻚ‪ ،‬ﻭﺟﻮﺩ ﺳﻠﺴﻠﺔ ﻣﻦ ﺍﻟﻄﻠﺒﺎﺕ ﺍﻟﺘﻲ ﺗﺒﺪﻭ ﻓﻴﻬﺎ ﺍﻻﺳﺘﺠﺎﺑﺔ ﺟﺰءﺍً ﻣﻦ ﺟﻠﺴﺔ‬
‫ﺻﺎﻟﺤﺔﻭﻟﻜﻨﻬﺎ ﻏﻴﺮ ﻣﺮﺗﺒﻄﺔ ﺑﻬﻮﻳﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺍﻷﺻﻠﻴﺔ‪ .‬ﻭﻫﺬﺍ ﻳﻄُﺎﺑﻖ ﻛﺘﻠﺔ ﺍﻟﺮﻣﺰ ﺍﻟﺘﻲ ﺗﺤﺘﻮﻱ ﻋﻠﻰ‬
‫ﻣﻌﺮﻑﺍﻟﻤﺴﺘﺨﺪﻡﺍﻟﻘﻴﻤﺔ‪ .‬ﻓﻲ ﺑﻌﺾ ﺍﻟﺤﺎﻻﺕ‪ ،‬ﻳﻌﺮﺽ ﺍﻟﺘﻄﺒﻴﻖ ﺑﺒﺴﺎﻃﺔ "ﻣﺴﺘﺨﺪﻡ ﻏﻴﺮ ﻣﻌﺮﻭﻑ"‪ ،‬ﻣﻤﺎ‬
‫ﻳﺸﻴﺮﺇﻟﻰ ﺃﻥ ﻣﻌﺮﻑ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺍﻟﻤﻌُﺪﻝَّ ﻻ ﻳﺘﻮﺍﻓﻖ ﻣﻊ ﻣﺴﺘﺨﺪﻡ ﻓﻌﻠﻲ‪ ،‬ﻭﺑﺎﻟﺘﺎﻟﻲ ﻓﺸﻞ ﺍﻟﻬﺠﻮﻡ‪ .‬ﻓﻲ‬
‫ﺣﺎﻻﺕﺃﺧﺮﻯ‪ ،‬ﻳﻈُﻬﺮ ﺍﺳﻢ ﻣﺴﺘﺨﺪﻡ ﻣﺴﺠﻞ ﺁﺧﺮ ﻟﻠﺘﻄﺒﻴﻖ‪ ،‬ﻣﻤﺎ ﻳﺜُﺒﺖ ﺑﺸﻜﻞ ﻗﺎﻃﻊ ﻧﺠﺎﺡ ﺍﻟﻬﺠﻮﻡ‪.‬‬
‫ﻳﻮﺿﺢﺍﻟﺸﻜﻞ ‪ 8-7‬ﻧﺘﺎﺉﺞ ﺍﻟﻬﺠﻮﻡ‪ .‬ﻫﻨﺎ‪ ،‬ﺣﺪﺩﻧﺎ ﻋﻤﻮﺩ ﺍﺳﺘﺨﺮﺍﺝ ‪ grep‬ﻟﻌﺮﺽ ﻫﻮﻳﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ‬
‫ﺍﻟﻤﺴُﺠﻞَّﺍﻟﺪﺧﻮﻝ‪ ،‬ﻭﺿﺒﻄﻨﺎ ﻣﺮُﺷﺤِّﺎً ﻹﺧﻔﺎء ﺍﻻﺳﺘﺠﺎﺑﺎﺕ ﺍﻟﺘﻲ ﺗﻌُﻴﺪ ﺍﻟﺘﻮﺟﻴﻪ ﺇﻟﻰ ﺻﻔﺤﺔ ﺗﺴﺠﻴﻞ‬
‫ﺍﻟﺪﺧﻮﻝ‪.‬‬
 ‫‪-‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‬ ‫‪230‬‬

‫ﺍﻟﺸﻜﻞ‪:7-7‬ﺝ‬

‫ﺍﻟﺸﻜﻞ‪:8-7‬ﻫﺠﻮﻡ ﻗﻠﺐ ﺍﻟﺒﺖ ﺍﻟﻨﺎﺟﺢ ﺿﺪ ﺭﻣﺰ ﻣﺸﻔﺮ‬

‫‪231‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬

‫ﺑﻌﺪﺗﺤﺪﻳﺪ ﺍﻟﺜﻐﺮﺓ‪ ،‬ﻳﻤﻜﻨﻚ ﺍﺳﺘﻐﻼﻟﻬﺎ ﺑﻬﺠﻮﻡ ﺃﻛﺜﺮ ﺗﺮﻛﻴﺰﺍً‪ .‬ﻟﻠﻘﻴﺎﻡ ﺑﺬﻟﻚ‪ ،‬ﺳﺘﺤﺪﺩ ﻣﻦ ﺍﻟﻨﺘﺎﺉﺞ ﺃﻱ‬
‫ﻛﺘﻠﺔﻣﻦ ﺍﻟﺮﻣﺰ ﺍﻟﻤﺸﻔﺮ ﻳﺘﻢ ﺍﻟﺘﻼﻋﺐ ﺑﻬﺎ ﻋﻨﺪ ﺗﻐﻴﻴﺮ ﺳﻴﺎﻕ ﺍﻟﻤﺴﺘﺨﺪﻡ‪ .‬ﺛﻢ ﺳﺘﺸﻦ ﻫﺠﻮﻣﺎً ﻳﺨﺘﺒﺮ‬
‫ﻗﻴﻤﺎًﺇﺿﺎﻓﻴﺔ ﻋﺪﻳﺪﺓ ﺩﺍﺧﻞ ﻫﺬﻩ ﺍﻟﻜﺘﻠﺔ‪ .‬ﻳﻤﻜﻨﻚ ﺍﺳﺘﺨﺪﺍﻡ ﻧﻮﻉ ﺣﻤﻮﻟﺔ ﺍﻷﺭﻗﺎﻡ ﻓﻲ ‪Burp Intruder‬‬
‫ﻟﻠﻘﻴﺎﻡﺑﺬﻟﻚ‪.‬‬

‫ﺟﺮﺑﻬﺎ!‬

‫‪http://mdsec.net/auth/365/‬‬

‫ﻣﻠﺤﻮﻇﺔﺗﺴﺘﺨﺪﻡ ﺑﻌﺾ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺗﻘﻨﻴﺔ ﺗﺸﻔﻴﺮ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺍﻟﻤﻬﻤﺔ ﺿﻤﻦ ﻣﻌﻠﻤﺎﺕ ﺍﻟﻄﻠﺐ‬
‫ﺑﺸﻜﻞﻋﺎﻡ‪ ،‬ﻓﻲ ﻣﺤﺎﻭﻟﺔ ﻟﻤﻨﻊ ﺍﻟﺘﻼﻋﺐ ﺑﻬﺎ‪ ،‬ﻣﺜﻞ ﺃﺳﻌﺎﺭ ﺳﻠﻊ ﺍﻟﺘﺴﻮﻕ‪ .‬ﻓﻲ ﺃﻱ ﻣﻜﺎﻥ ﺗﺮﻯ ﻓﻴﻪ‬
‫ﺑﻴﺎﻧﺎﺕﻣﺸﻔﺮﺓ ﻇﺎﻫﺮﻳﺎً ﺗﻠﻌﺐ ﺩﻭﺭﺍً ﺭﺉﻴﺴﻴﺎً ﻓﻲ ﻭﻇﺎﺉﻒ ﺍﻟﺘﻄﺒﻴﻖ‪ ،‬ﻳﻨُﺼﺢ ﺑﺘﺠﺮﺑﺔ ﺗﻘﻨﻴﺔ ﻗﻠﺐ‬
‫ﺍﻟﺒﺘﺎﺕﻟﻤﻌﺮﻓﺔ ﻣﺎ ﺇﺫﺍ ﻛﺎﻥ ﺑﺈﻣﻜﺎﻧﻚ ﺍﻟﺘﻼﻋﺐ ﺑﺎﻟﻤﻌﻠﻮﻣﺎﺕ ﺍﻟﻤﺸﻔﺮﺓ ﺑﻄﺮﻳﻘﺔ ﻓﻌﺎﻟﺔ ﻟﻠﺘﺪﺧﻞ ﻓﻲ‬
‫ﻣﻨﻄﻖﺍﻟﺘﻄﺒﻴﻖ‪.‬‬

‫ﻋﻨﺪﻣﺤﺎﻭﻟﺔ ﺍﺳﺘﻐﻼﻝ ﺍﻟﺜﻐﺮﺓ ﺍﻷﻣﻨﻴﺔ ﺍﻟﻤﻮﺿﺤﺔ ﻓﻲ ﻫﺬﺍ ﺍﻟﻘﺴﻢ‪ ،‬ﺳﻴﻜﻮﻥ ﻫﺪﻓﻚ ﺑﺎﻟﻄﺒﻊ ﻫﻮ ﺍﻟﺘﻨﻜﺮ‬
‫ﻛﻤﺴﺘﺨﺪﻣﻲﺗﻄﺒﻴﻖ ﻣﺨﺘﻠﻔﻴﻦ ‪ -‬ﻭﻳﻔﻀﻞ ﺃﻥ ﻳﻜﻮﻥ ﺫﻟﻚ ﻣﺴﺘﺨﺪﻣﺎً ﺇﺩﺍﺭﻳﺎً ﺑﺼﻼﺣﻴﺎﺕ ﺃﻋﻠﻰ‪ .‬ﺇﺫﺍ‬
‫ﻛﻨﺖﻣﻘﻴﺪﺍً ﺑﺎﻟﺘﻼﻋﺐ ﺍﻟﻌﺸﻮﺍﺉﻲ ﺑﺄﺟﺰﺍء ﻣﻦ ﺭﻣﺰ ﻣﺸﻔﺮ‪ ،‬ﻓﻘﺪ ﻳﺘﻄﻠﺐ ﻫﺬﺍ ﺑﻌﺾ ﺍﻟﺤﻆ‪ .‬ﻭﻣﻊ ﺫﻟﻚ‪،‬‬
‫ﻓﻲﺑﻌﺾ ﺍﻟﺤﺎﻻﺕ‪ ،‬ﻗﺪ ﻳﻘﺪﻡ ﻟﻚ ﺍﻟﺘﻄﺒﻴﻖ ﻣﺴﺎﻋﺪﺓ ﺃﻛﺒﺮ‪ .‬ﻋﻨﺪﻣﺎ ﻳﺴﺘﺨﺪﻡ ﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﺘﺸﻔﻴﺮ‬
‫ﺍﻟﻤﺘﻤﺎﺛﻞﻟﺤﻤﺎﻳﺔ ﺍﻟﺒﻴﺎﻧﺎﺕ ﻣﻦ ﺍﻟﺘﻼﻋﺐ ﻣﻦ ﻗﺒِﻞ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ‪ ،‬ﻣﻦ ﺍﻟﺸﺎﺉﻊ ﺍﺳﺘﺨﺪﺍﻡ ﺧﻮﺍﺭﺯﻣﻴﺔ‬
‫ﺍﻟﺘﺸﻔﻴﺮﻭﻣﻔﺘﺎﺡ ﺍﻟﺘﺸﻔﻴﺮ ﻧﻔﺴﻬﻤﺎ ﻓﻲ ﺟﻤﻴﻊ ﺃﻧﺤﺎء ﺍﻟﺘﻄﺒﻴﻖ‪ .‬ﻓﻲ ﻫﺬﻩ ﺍﻟﺤﺎﻟﺔ‪ ،‬ﺇﺫﺍ ﻛﺸﻔﺖ ﺃﻱ‬
‫ﻭﻇﻴﻔﺔﻓﻲ ﺍﻟﺘﻄﺒﻴﻖ ﻟﻠﻤﺴﺘﺨﺪﻡ ﻋﻦ ﺍﻟﻘﻴﻤﺔ ﺍﻟﻤﻔﻜﻮﻛﺔ ﻟﺴﻠﺴﻠﺔ ﻣﺸﻔﺮﺓ ﻋﺸﻮﺍﺉﻴﺔ‪ ،‬ﻓﻴﻤﻜﻦ‬
‫ﺍﻻﺳﺘﻔﺎﺩﺓﻣﻦ ﺫﻟﻚ ﻟﻔﻚ ﺗﺸﻔﻴﺮ ﺃﻱ ﻋﻨﺼﺮ ﻣﻦ ﺍﻟﻤﻌﻠﻮﻣﺎﺕ ﺍﻟﻤﺤﻤﻴﺔ ﺑﺎﻟﻜﺎﻣﻞ‪.‬‬

‫ﺍﺣﺘﻮﻯﺃﺣﺪ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﻟﺘﻲ ﻻﺣﻈﻬﺎ ﺍﻟﺒﺎﺣﺜﻮﻥ ﻋﻠﻰ ﻭﻇﻴﻔﺔ ﺗﺤﻤﻴﻞ‪/‬ﺗﻨﺰﻳﻞ ﻣﻠﻒ‪ .‬ﺑﻌﺪ ﺗﺤﻤﻴﻞ‬
‫ﺍﻟﻤﻠﻒ‪،‬ﻳﻤُﻨﺢ ﺍﻟﻤﺴﺘﺨﺪﻣﻮﻥ ﺭﺍﺑﻂ ﺗﻨﺰﻳﻞ ﻳﺤﺘﻮﻱ ﻋﻠﻰ ﻣﻌُﺎﻣﻞ ﺍﺳﻢ ﺍﻟﻤﻠﻒ‪ .‬ﻭﻟﻤﻨﻊ ﺍﻟﻬﺠﻤﺎﺕ‬
‫ﺍﻟﻤﺨﺘﻠﻔﺔﺍﻟﺘﻲ ﺗﺘﻼﻋﺐ ﺑﻤﺴﺎﺭﺍﺕ ﺍﻟﻤﻠﻔﺎﺕ‪ ،‬ﻳﺸُﻔﺮّ ﺍﻟﺘﻄﺒﻴﻖ ﺍﺳﻢ ﺍﻟﻤﻠﻒ ﺿﻤﻦ ﻫﺬﺍ ﺍﻟﻤﻌُﺎﻣﻞ‪ .‬ﻭﻣﻊ‬
‫ﺫﻟﻚ‪،‬ﺇﺫﺍ ﻃﻠﺐ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻣﻠﻔﺎً ﻣﺤﺬﻭﻓﺎً‪ ،‬ﻳﻌﺮﺽ ﺍﻟﺘﻄﺒﻴﻖ ﺭﺳﺎﻟﺔ ﺧﻄﺄ ﺗﻈُﻬﺮ‪...‬ﻓﻚ ﺍﻟﺘﺸﻔﻴﺮﺍﺳﻢ‬
‫ﺍﻟﻤﻠﻒﺍﻟﻤﻄﻠﻮﺏ‪ .‬ﻳﻤﻜﻦ ﺍﻻﺳﺘﻔﺎﺩﺓ ﻣﻦ ﻫﺬﺍ ﺍﻟﺴﻠﻮﻙ ﻟﻠﻌﺜﻮﺭ ﻋﻠﻰ ﻗﻴﻤﺔ ﺍﻟﻨﺺ ﺍﻟﻌﺎﺩﻱ ﻷﻱ ﺳﻠﺴﻠﺔ‬
‫ﻣﺸﻔﺮﺓﻣﺴﺘﺨﺪﻣﺔ ﺩﺍﺧﻞ ﺍﻟﺘﻄﺒﻴﻖ‪ ،‬ﺑﻤﺎ ﻓﻲ ﺫﻟﻚ ﻗﻴﻢ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ‪ .‬ﻭﺟُﺪ ﺃﻥ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ ﺗﺤﺘﻮﻱ‬
‫ﻋﻠﻰﻗﻴﻢ ﻣﺨﺘﻠﻔﺔ ﺫﺍﺕ ﻣﻌﻨﻰ ﺑﺘﻨﺴﻴﻖ ﻣﻨﻈﻢ‪ ،‬ﻣﻤﺎ ﻳﺠﻌﻠﻬﺎ ﻋﺮﺿﺔ ﻟﻨﻮﻉ ﺍﻟﻬﺠﻮﻡ ﺍﻟﻤﻮﺻﻮﻑ ﻓﻲ ﻫﺬﺍ‬
‫ﺍﻟﻘﺴﻢ‪.‬ﻭﻷﻥ ﻫﺬﻩ ﺍﻟﻘﻴﻢ ﺗﻀﻤﻨﺖ ﺃﺳﻤﺎء ﻣﺴﺘﺨﺪﻣﻴﻦ ﻭﺃﺩﻭﺍﺭ ﺗﻄﺒﻴﻖ ﻧﺼﻴﺔ‪ ،‬ﺑﺪﻻ ًﻣﻦ ﻣﻌﺮﻓﺎﺕ‬
‫ﺭﻗﻤﻴﺔ‪،‬ﻛﺎﻥ ﻣﻦ ﺍﻟﺼﻌﺐ ﻟﻠﻐﺎﻳﺔ ﺗﻨﻔﻴﺬ ﻋﻤﻠﻴﺔ ﺍﺳﺘﻐﻼﻝ ﻧﺎﺟﺤﺔ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺗﻘﻨﻴﺔ ﻗﻠﺐ ﺍﻟﺒﺘﺎﺕ ﺍﻟﻌﻤﻴﺎء‬
‫ﻓﻘﻂ‪.‬ﻭﻣﻊ ﺫﻟﻚ‪ ،‬ﺑﺎﺳﺘﺨﺪﺍﻡ ﺩﺍﻟﺔ ﻓﻚ ﺗﺸﻔﻴﺮ ﺍﺳﻢ ﺍﻟﻤﻠﻒ‪ ،‬ﺃﺻﺒﺢ ﻣﻦ ﺍﻟﻤﻤﻜﻦ ﺍﻟﺘﻼﻋﺐ ﺑﺒﺘﺎﺕ ﺍﻟﺮﻣﺰ‬
‫ﺑﺸﻜﻞﻣﻨﻬﺠﻲ ﺃﺛﻨﺎء ﻋﺮﺽ ﺍﻟﻨﺘﺎﺉﺞ‪.‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬ ‫‪232‬‬

‫ﺳﻤﺢﻫﺬﺍ ﺑﺈﻧﺸﺎء ﺭﻣﺰ ﻣﻤﻴﺰ‪ ،‬ﻋﻨﺪ ﻓﻚ ﺗﺸﻔﻴﺮﻩ‪ ،‬ﻳﺤﺪﺩ ﻣﺴﺘﺨﺪﻣﺎً ﺻﺎﻟﺤﺎً ﻭﺩﻭﺭﺍً ﺇﺩﺍﺭﻳﺎً‪ ،‬ﻣﻤﺎ ﻳﺘﻴﺢ‬
‫ﺍﻟﺘﺤﻜﻢﺍﻟﻜﺎﻣﻞ ﻓﻲ ﺍﻟﺘﻄﺒﻴﻖ‪.‬‬

‫ﻣﻠﺤﻮﻇﺔﻗﺪ ﺗﺴﻤﺢ ﻟﻚ ﺗﻘﻨﻴﺎﺕ ﺃﺧﺮﻯ ﺑﻔﻚ ﺗﺸﻔﻴﺮ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺍﻟﻤﺸﻔﺮﺓ ﺍﻟﺘﻲ ﻳﺴﺘﺨﺪﻣﻬﺎ‬
‫ﺍﻟﺘﻄﺒﻴﻖ‪.‬ﻳﻤﻜﻦ ﺇﺳﺎءﺓ ﺍﺳﺘﺨﺪﺍﻡ ﺃﻭﺭﺍﻛﻞ ﺗﺸﻔﻴﺮ "ﺍﻟﻜﺸﻒ" ﻟﻠﺤﺼﻮﻝ ﻋﻠﻰ ﻗﻴﻤﺔ ﺍﻟﻨﺺ ﺍﻟﻌﺎﺩﻱ‬
‫ﻟﺮﻣﺰﻣﺸﻔﺮ‪ .‬ﻋﻠﻰ ﺍﻟﺮﻏﻢ ﻣﻦ ﺃﻥ ﻫﺬﺍ ﻗﺪ ﻳﻤُﺜﻞ ﺛﻐﺮﺓ ﺃﻣﻨﻴﺔ ﻛﺒﻴﺮﺓ ﻋﻨﺪ ﻓﻚ ﺗﺸﻔﻴﺮ ﻛﻠﻤﺔ ﻣﺮﻭﺭ‪ ،‬ﺇﻻ‬
‫ﺃﻥﻓﻚ ﺗﺸﻔﻴﺮ ﺭﻣﺰ ﺟﻠﺴﺔ ﻻ ﻳﻮﻓﺮ ﻭﺳﻴﻠﺔ ﻓﻮﺭﻳﺔ ﻻﺧﺘﺮﺍﻕ ﺟﻠﺴﺎﺕ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺍﻵﺧﺮﻳﻦ‪ .‬ﻣﻊ‬
‫ﺫﻟﻚ‪،‬ﻳﻮﻓﺮ ﺍﻟﺮﻣﺰ ﺍﻟﺬﻱ ﺗﻢ ﻓﻚ ﺗﺸﻔﻴﺮﻩ ﻓﻬﻤﺎً ﻣﻔﻴﺪﺍً ﻟﺒﻨﻴﺔ ﺍﻟﻨﺺ ﺍﻟﻌﺎﺩﻱ‪ ،‬ﻣﻤﺎ ﻳﻔُﻴﺪ ﻓﻲ ﺗﻨﻔﻴﺬ‬
‫ﻫﺠﻮﻡﻗﻠﺐ ﺑﺖ ﻣﺴُﺘﻬﺪﻑ‪ .‬ﺭﺍﺟﻊ ﺍﻟﻔﺼﻞ ‪ 11‬ﻟﻤﺰﻳﺪ ﻣﻦ ﺍﻟﺘﻔﺎﺻﻴﻞ ﺣﻮﻝ ﻫﺠﻤﺎﺕ ﺃﻭﺭﺍﻛﻞ ﺗﺸﻔﻴﺮ "‬
‫ﺍﻟﻜﺸﻒ"‪.‬‬

‫ﻗﺪﺗﺴُﺘﺨﺪﻡ ﻫﺠﻤﺎﺕ ﺍﻟﻘﻨﻮﺍﺕ ﺍﻟﺠﺎﻧﺒﻴﺔ ﺿﺪ ﺃﻭﺭﺍﻛﻞ ﺍﻟﺤﺸﻮ ﻻﺧﺘﺮﺍﻕ ﺍﻟﺮﻣﻮﺯ ﺍﻟﻤﺸﻔﺮﺓ‪ .‬ﺭﺍﺟﻊ‬
‫ﺍﻟﻔﺼﻞ‪ 18‬ﻟﻤﺰﻳﺪ ﻣﻦ ﺍﻟﺘﻔﺎﺻﻴﻞ‪.‬‬

‫ﺧﻄﻮﺍﺕﺍﻻﺧﺘﺮﺍﻕ‬

‫ﻓﻲﺍﻟﻌﺪﻳﺪ ﻣﻦ ﺍﻟﺤﺎﻻﺕ ﺍﻟﺘﻲ ﺗﺴُﺘﺨﺪﻡ ﻓﻴﻬﺎ ﺍﻟﺮﻣﻮﺯ ﺍﻟﻤﺸﻔﺮﺓ‪ ،‬ﻗﺪ ﺗﻌﺘﻤﺪ ﻗﺎﺑﻠﻴﺔ ﺍﻻﺳﺘﻐﻼﻝ ﺍﻟﻔﻌﻠﻴﺔ‬
‫ﻋﻠﻰﻋﻮﺍﻣﻞ ﻣﺨﺘﻠﻔﺔ‪ ،‬ﻣﻨﻬﺎ ﺇﺯﺍﺣﺎﺕ ﺣﺪﻭﺩ ﺍﻟﻜﺘﻞ ﺑﺎﻟﻨﺴﺒﺔ ﻟﻠﺒﻴﺎﻧﺎﺕ ﺍﻟﻤﺮﺍﺩ ﻣﻬﺎﺟﻤﺘﻬﺎ‪ ،‬ﻭﻣﺪﻯ ﺗﺤﻤﻞّ‬
‫ﺍﻟﺘﻄﺒﻴﻖﻟﻠﺘﻐﻴﻴﺮﺍﺕ ﺍﻟﺘﻲ ﺗﺤُﺪﺛﻬﺎ ﻓﻲ ﺑﻨﻴﺔ ﺍﻟﻨﺺ ﺍﻟﻌﺎﺩﻱ ﺍﻟﻤﺤﻴﻄﺔ‪ .‬ﻗﺪ ﻳﺒﺪﻭ ﻣﻦ ﺍﻟﺼﻌﺐ ﺑﻨﺎء ﻫﺠﻮﻡ‬
‫ﻓﻌﺎﻝ‪،‬ﻭﻟﻜﻦ ﻓﻲ ﻛﺜﻴﺮ ﻣﻦ ﺍﻟﺤﺎﻻﺕ‪ ،‬ﻳﻜﻮﻥ ﺫﻟﻚ ﻣﻤﻜﻨﺎً‪.‬‬

‫‪.١‬ﻣﺎ ﻟﻢ ﻳﻜﻦ ﺭﻣﺰ ﺍﻟﺠﻠﺴﺔ ﺫﺍ ﻣﻌﻨﻰ ﺃﻭ ﺗﺴﻠﺴﻞ ﻭﺍﺿﺢ ﻓﻲ ﺣﺪ ﺫﺍﺗﻪ‪ ،‬ﻓﻜﺮّ ﺩﺍﺉﻤﺎً ﻓﻲ ﺍﺣﺘﻤﺎﻟﻴﺔ‬
‫ﺗﺸﻔﻴﺮﻩ‪.‬ﻳﻤﻜﻨﻚ ﻏﺎﻟﺒﺎً ﺗﺤﺪﻳﺪ ﺍﺳﺘﺨﺪﺍﻡ ﺗﺸﻔﻴﺮ ﻗﺎﺉﻢ ﻋﻠﻰ ﺍﻟﻜﺘﻞ ﻣﻦ ﺧﻼﻝ ﺗﺴﺠﻴﻞ ﻋﺪﺓ‬
‫ﺃﺳﻤﺎءﻣﺴﺘﺨﺪﻣﻴﻦ ﻣﺨﺘﻠﻔﺔ ﻭﺇﺿﺎﻓﺔ ﺣﺮﻑ ﻭﺍﺣﺪ ﻓﻲ ﻛﻞ ﻣﺮﺓ‪ .‬ﺇﺫﺍ ﻻﺣﻈﺖ ﺃﻥ ﺇﺿﺎﻓﺔ ﺣﺮﻑ‬
‫ﻭﺍﺣﺪﺗﺆﺩﻱ ﺇﻟﻰ ﺯﻳﺎﺩﺓ ﻃﻮﻝ ﺭﻣﺰ ﺍﻟﺠﻠﺴﺔ ﺑﻤﻘﺪﺍﺭ ‪ ٨‬ﺃﻭ ‪ ١٦‬ﺑﺎﻳﺖ‪ ،‬ﻓﻤﻦ ﺍﻟﻤﺮﺟﺢ ﺃﻥ ﻳﻜﻮﻥ‬
‫ﺍﻟﺘﺸﻔﻴﺮﻗﻴﺪ ﺍﻻﺳﺘﺨﺪﺍﻡ‪ .‬ﻳﻤﻜﻨﻚ ﺍﻟﺘﺄﻛﺪ ﻣﻦ ﺫﻟﻚ ﻣﻦ ﺧﻼﻝ ﺍﻻﺳﺘﻤﺮﺍﺭ ﻓﻲ ﺇﺿﺎﻓﺔ ﺑﺎﻳﺘﺎﺕ ﺇﻟﻰ‬
‫ﺍﺳﻢﺍﻟﻤﺴﺘﺨﺪﻡ‪ ،‬ﻭﺍﻟﺒﺤﺚ ﻋﻦ ﻧﻔﺲ ﺍﻟﺰﻳﺎﺩﺓ ﺍﻟﺘﻲ ﺗﺤﺪﺙ ﺑﻌﺪ ‪ ٨‬ﺃﻭ ‪ ١٦‬ﺑﺎﻳﺖ‪.‬‬

‫‪.٢‬ﻋﺎﺩﺓ ًﻣﺎ ﻳﺼﻌﺐ ﺗﺤﺪﻳﺪ ﺛﻐﺮﺍﺕ ﺍﻟﺘﻼﻋﺐ ﺑﺘﺸﻔﻴﺮ ‪ ECB‬ﻭﺍﺳﺘﻐﻼﻟﻬﺎ ﻓﻲ ﺳﻴﺎﻕ ٍﻣﻐُﻠﻖ ﺗﻤﺎﻣﺎً‪.‬‬
‫ﻳﻤﻜﻨﻚﻣﺤﺎﻭﻟﺔ ﻧﺴﺦ ﻭﻧﻘﻞ ﻛﺘﻞ ﺍﻟﻨﺺ ﺍﻟﻤﺸﻔﺮ ﺩﺍﺧﻞ ﺭﻣﺰﻙ ﺩﻭﻥ ﻭﻋﻲ‪ ،‬ﻭﻣﺮﺍﺟﻌﺔ ﻣﺎ ﺇﺫﺍ‬
‫ﻛﻨﺖﺳﺘﺒﻘﻰ ﻣﺴُﺠﻼ ًﺍﻟﺪﺧﻮﻝ ﺇﻟﻰ ﺍﻟﺘﻄﺒﻴﻖ ﺿﻤﻦ ﺳﻴﺎﻕ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺍﻟﺨﺎﺹ ﺑﻚ‪ ،‬ﺃﻭ‬
‫ﺳﻴﺎﻕﻣﺴﺘﺨﺪﻡ ﺁﺧﺮ‪ ،‬ﺃﻭ ﻋﺪﻡ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﻋﻠﻰ ﺍﻹﻃﻼﻕ‪.‬‬

‫‪.٣‬ﻳﻤﻜﻨﻚ ﺍﺧﺘﺒﺎﺭ ﺛﻐﺮﺍﺕ ﺍﻟﺘﻼﻋﺐ ﺑﺘﺸﻔﻴﺮ ‪ CBC‬ﺑﺘﻨﻔﻴﺬ ﻫﺠﻮﻡ ‪ Burp Intruder‬ﻋﻠﻰ ﺍﻟﺮﻣﺰ ﺑﺄﻛﻤﻠﻪ‪،‬‬
‫ﺑﺎﺳﺘﺨﺪﺍﻡﻣﺼﺪﺭ ﺣﻤﻮﻟﺔ "ﻗﻠﺐ ﺍﻟﺒﺖ"‪ .‬ﺇﺫﺍ ﺣﺪﺩ ﻫﺠﻮﻡ ﻗﻠﺐ ﺍﻟﺒﺖ ﻗﺴﻤﺎً ﺩﺍﺧﻞ ﺍﻟﺮﻣﺰ‪ ،‬ﻭﺍﻟﺬﻱ‬
‫ﻳﺆﺩﻱﺗﻼﻋﺒﻪ ﺇﻟﻰ ﺑﻘﺎﺉﻚ ﻓﻲ ﺟﻠﺴﺔ ﺻﺎﻟﺤﺔ‪ ،‬ﻭﻟﻜﻦ ﻛﻤﺴﺘﺨﺪﻡ ﻣﺨﺘﻠﻒ ﺃﻭ ﻏﻴﺮ ﻣﻮﺟﻮﺩ‪ ،‬ﻓﻘﻢ‬
‫ﺑﺘﻨﻔﻴﺬﻫﺠﻮﻡ ﺃﻛﺜﺮ ﺗﺮﻛﻴﺰﺍً ﻋﻠﻰ ﻫﺬﺍ ﺍﻟﻘﺴﻢ ﻓﻘﻂ‪ ،‬ﻣﻊ ﺗﺠﺮﺑﺔ ﻧﻄﺎﻕ ﺃﻭﺳﻊ ﻣﻦ ﺍﻟﻘﻴﻢ ﻓﻲ ﻛﻞ‬
‫ﻣﻮﺿﻊ‪.‬‬
‫‪233‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬

‫‪.4‬ﺃﺛﻨﺎء ﻛﻼ ﺍﻟﻬﺠﻮﻣﻴﻦ‪ ،‬ﺭﺍﻗﺐ ﺍﺳﺘﺠﺎﺑﺎﺕ ﺍﻟﺘﻄﺒﻴﻖ ﻟﺘﺤﺪﻳﺪ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺍﻟﻤﺮﺗﺒﻂ ﺑﺠﻠﺴﺔ ﺍﻟﻌﻤﻞ‬
‫ﺍﻟﺨﺎﺻﺔﺑﻚ ﺑﻌﺪ ﻛﻞ ﻃﻠﺐ‪ ،‬ﻭﺣﺎﻭﻝ ﺍﺳﺘﻐﻼﻝ ﺃﻱ ﻓﺮﺹ ﻟﺘﺼﻌﻴﺪ ﺍﻻﻣﺘﻴﺎﺯﺍﺕ ﺍﻟﺘﻲ ﻗﺪ ﺗﻨﺘﺞ‬
‫ﻋﻦﺫﻟﻚ‪.‬‬
‫‪.٥‬ﺇﺫﺍ ﻟﻢ ﺗﻨﺠﺢ ﻫﺠﻤﺎﺗﻚ‪ ،‬ﻭﻟﻜﻦ ﺍﺗﻀﺢ ﻣﻦ ﺍﻟﺨﻄﻮﺓ ‪ ١‬ﺃﻥ ﻣﺪُﺧﻼﺕ ﺍﻟﻄﻮﻝ ﺍﻟﻤﺘﻐﻴﺮ ﺍﻟﺘﻲ ﺗﺘﺤﻜﻢ ﺑﻬﺎ‬
‫ﻣﺪُﻣﺠﺔﻓﻲ ﺍﻟﺮﻣﺰ‪ ،‬ﻓﺤﺎﻭﻝ ﺇﻧﺸﺎء ﺳﻠﺴﻠﺔ ﻣﻦ ﺍﻟﺮﻣﻮﺯ ﺑﺈﺿﺎﻓﺔ ﺣﺮﻑ ﻭﺍﺣﺪ ﻓﻲ ﻛﻞ ﻣﺮﺓ‪ ،‬ﻋﻠﻰ‬
‫ﺍﻷﻗﻞﺣﺘﻰ ﺣﺠﻢ ﺍﻟﻜﺘﻞ ﺍﻟﻤﺴﺘﺨﺪﻣﺔ‪ .‬ﻟﻜﻞ ﺭﻣﺰ ﻧﺎﺗﺞ‪ ،‬ﺃﻋﺪ ﺗﻨﻔﻴﺬ ﺍﻟﺨﻄﻮﺗﻴﻦ ‪ ٢‬ﻭ‪ .٣‬ﺳﻴﺰﻳﺪ ﻫﺬﺍ‬
‫ﻣﻦﻓﺮﺻﺔ ﺗﻮﺍﻓﻖ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺍﻟﺘﻲ ﺗﺤﺘﺎﺝ ﺇﻟﻰ ﺗﻌﺪﻳﻠﻬﺎ ﻣﻊ ﺣﺪﻭﺩ ﺍﻟﻜﺘﻞ ﻟﻨﺠﺎﺡ ﻫﺠﻮﻣﻚ‪.‬‬

‫ﻧﻘﺎﻁﺍﻟﻀﻌﻒ ﻓﻲ ﺍﻟﺘﻌﺎﻣﻞ ﻣﻊ ﺭﻣﺰ ﺍﻟﺠﻠﺴﺔ‬

‫ﻣﻬﻤﺎﺑﻠﻐﺖ ﻓﻌﺎﻟﻴﺔ ﺍﻟﺘﻄﺒﻴﻖ ﻓﻲ ﺿﻤﺎﻥ ﺧﻠﻮ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ ﺍﻟﺘﻲ ﻳﻮُﻟﺪّﻫﺎ ﻣﻦ ﺃﻱ ﻣﻌﻠﻮﻣﺎﺕ ﻣﻔﻴﺪﺓ‬
‫ﻭﻋﺪﻡﻗﺎﺑﻠﻴﺘﻬﺎ ﻟﻠﺘﺤﻠﻴﻞ ﺃﻭ ﺍﻟﺘﻨﺒﺆ‪ ،‬ﻓﺈﻥ ﺁﻟﻴﺔ ﺍﻟﺠﻠﺴﺔ ﺍﻟﺨﺎﺻﺔ ﺑﻪ ﺳﺘﻜﻮﻥ ﻋﺮﺿﺔ ﻟﻠﻬﺠﻮﻡ ﺇﺫﺍ ﻟﻢ ﺗﻌُﺎﻣﻞ‬
‫ﻫﺬﻩﺍﻟﺮﻣﻮﺯ ﺑﻌﻨﺎﻳﺔ ﺑﻌﺪ ﺇﻧﺸﺎﺉﻬﺎ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﺇﺫﺍ ﺗﻢ ﺍﻟﻜﺸﻒ ﻋﻦ ﺍﻟﺮﻣﻮﺯ ﻟﻤﻬﺎﺟﻢ ﻋﺒﺮ ﺃﻱ‬
‫ﻭﺳﻴﻠﺔ‪،‬ﻓﻴﻤﻜﻨﻪ ﺍﺧﺘﺮﺍﻕ ﺟﻠﺴﺎﺕ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺣﺘﻰ ﻟﻮ ﻛﺎﻥ ﺍﻟﺘﻨﺒﺆ ﺑﻬﺎ ﻣﺴﺘﺤﻴﻼ‪ً.‬‬

‫ﺇﻥﺍﻟﺘﻌﺎﻣﻞ ﻏﻴﺮ ﺍﻵﻣﻦ ﻣﻊ ﺍﻟﺮﻣﻮﺯ ﺑﻮﺍﺳﻄﺔ ﺍﻟﺘﻄﺒﻴﻖ ﻗﺪ ﻳﺠﻌﻠﻪ ﻋﺮﺿﺔ ﻟﻠﻬﺠﻮﻡ ﺑﻌﺪﺓ ﻃﺮﻕ‪.‬‬

‫ﺃﺳﻄﻮﺭﺓﺷﺎﺉﻌﺔ‬

‫"ﺭﻣﺰﻧﺎ ﺁﻣﻦ ﻣﻦ ﺍﻟﻜﺸﻒ ﻋﻨﻪ ﻷﻃﺮﺍﻑ ﺛﺎﻟﺜﺔ ﻷﻧﻨﺎ ﻧﺴﺘﺨﺪﻡ ‪".SSL‬‬

‫ﺍﻻﺳﺘﺨﺪﺍﻡﺍﻟﺴﻠﻴﻢ ﻟﺒﺮﻭﺗﻮﻛﻮﻝ ‪ SSL‬ﻳﺴُﺎﻋﺪ ﺑﺎﻟﺘﺄﻛﻴﺪ ﻋﻠﻰ ﺣﻤﺎﻳﺔ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ ﻣﻦ ﺍﻻﻟﺘﻘﺎﻁ‪.‬‬
‫ﻭﻟﻜﻦﻗﺪ ﺗﺆﺩﻱ ﺃﺧﻄﺎء ٌﻣﺨُﺘﻠﻔﺔ ﺇﻟﻰ ﺇﺭﺳﺎﻝ ﺍﻟﺮﻣﻮﺯ ﺑﻨﺺ ٍّﻋﺎﺩﻱ ﺣﺘﻰ ﻣﻊ ﺗﻔﻌﻴﻞ ﺑﺮﻭﺗﻮﻛﻮﻝ ‪.SSL‬‬
‫ﻛﻤﺎﻳﻤُﻜﻦ ﺍﺳﺘﺨﺪﺍﻡ ﻫﺠﻤﺎﺕ ٍﻣﺒُﺎﺷﺮﺓ ٍﻣﺨُﺘﻠﻔﺔ ٍﺿﺪ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺍﻟﻨﻬﺎﺉﻴﻴﻦ ﻟﻠﺤﺼﻮﻝ ﻋﻠﻰ‬
‫ﺭﻣﻮﺯﻫﻢ‪.‬‬

‫ﺃﺳﻄﻮﺭﺓﺷﺎﺉﻌﺔ‬

‫"ﻳﺘﻢ ﺇﻧﺸﺎء ﺭﻣﺰﻧﺎ ﺑﻮﺍﺳﻄﺔ ﺍﻟﻤﻨﺼﺔ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺗﻘﻨﻴﺎﺕ ﻧﺎﺿﺠﺔ ﻭﺳﻠﻴﻤﺔ ﻣﻦ ﺍﻟﻨﺎﺣﻴﺔ‬
‫ﺍﻟﺘﺸﻔﻴﺮﻳﺔ‪،‬ﻭﺑﺎﻟﺘﺎﻟﻲ ﻓﻬﻮ ﻏﻴﺮ ﻋﺮﺿﺔ ﻟﻠﺨﻄﺮ‪".‬‬
‫ﻏﺎﻟﺒﺎًﻣﺎ ﻳﻜﻮﻥ ﺍﻟﺴﻠﻮﻙ ﺍﻻﻓﺘﺮﺍﺿﻲ ﻟﺨﺎﺩﻡ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﻫﻮ ﺇﻧﺸﺎء ﻣﻠﻒ ﺗﻌﺮﻳﻒ ﺍﺭﺗﺒﺎﻁ ﻟﻠﺠﻠﺴﺔ‬
‫ﻋﻨﺪﺃﻭﻝ ﺯﻳﺎﺭﺓ ﻟﻠﻤﺴﺘﺨﺪﻡ ﻟﻠﻤﻮﻗﻊ‪ ،‬ﻭﺇﺑﻘﺎﺉﻪ ﻣﺘﺎﺣﺎً ﻃﻮﺍﻝ ﻓﺘﺮﺓ ﺗﻔﺎﻋﻠﻪ ﻣﻌﻪ‪ .‬ﻭﻛﻤﺎ ﻫﻮ ﻣﻮﺿﺢ ﻓﻲ‬
‫ﺍﻷﻗﺴﺎﻡﺍﻟﺘﺎﻟﻴﺔ‪ ،‬ﻗﺪ ﻳﺆﺩﻱ ﻫﺬﺍ ﺇﻟﻰ ﺛﻐﺮﺍﺕ ﺃﻣﻨﻴﺔ ﻣﺨﺘﻠﻔﺔ ﻓﻲ ﻛﻴﻔﻴﺔ ﺍﻟﺘﻌﺎﻣﻞ ﻣﻊ ﺍﻟﺮﻣﺰ ﺍﻟﻤﻤﻴﺰ‪.‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬ ‫‪234‬‬

‫ﺍﻹﻓﺼﺎﺡﻋﻦ ﺍﻟﺮﻣﻮﺯ ﻋﻠﻰ ﺍﻟﺸﺒﻜﺔ‬

‫ﺗﻨﺸﺄﻫﺬﻩ ﺍﻟﻨﻘﻄﺔ ﻣﻦ ﺍﻟﻀﻌﻒ ﻋﻨﺪ ﻧﻘﻞ ﺭﻣﺰ ﺍﻟﺠﻠﺴﺔ ﻋﺒﺮ ﺍﻟﺸﺒﻜﺔ ﺑﺸﻜﻞ ﻏﻴﺮ ﻣﺸﻔﺮ‪ ،‬ﻣﻤﺎ ﻳﻤُﻜ ّ‬
‫ﻦ‬
‫ﻣﺘُﻨﺼﺘﺎًﻓﻲ ﻣﻮﻗﻊ ﻣﻨﺎﺳﺐ ﻣﻦ ﺍﻟﺤﺼﻮﻝ ﻋﻠﻰ ﺍﻟﺮﻣﺰ‪ ،‬ﻭﺑﺎﻟﺘﺎﻟﻲ ﺍﻧﺘﺤﺎﻝ ﺷﺨﺼﻴﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺍﻟﺸﺮﻋﻲ‪.‬‬
‫ﺗﺸﻤﻞﺍﻟﻤﻮﺍﻗﻊ ﺍﻟﻤﻨﺎﺳﺒﺔ ﻟﻠﺘﻨﺼﺖ ﺍﻟﺸﺒﻜﺔ ﺍﻟﻤﺤﻠﻴﺔ ﻟﻠﻤﺴﺘﺨﺪﻡ‪ ،‬ﻭﻗﺴﻢ ﺗﻜﻨﻮﻟﻮﺟﻴﺎ ﺍﻟﻤﻌﻠﻮﻣﺎﺕ‬
‫ﺍﻟﺨﺎﺹﺑﻪ‪ ،‬ﻭﻣﺰﻭﺩ ﺧﺪﻣﺔ ﺍﻹﻧﺘﺮﻧﺖ ﺍﻟﺨﺎﺹ ﺑﻪ‪ ،‬ﻭﺍﻟﺸﺒﻜﺔ ﺍﻷﺳﺎﺳﻴﺔ ﻟﻺﻧﺘﺮﻧﺖ‪ ،‬ﻭﻣﺰﻭﺩ ﺧﺪﻣﺔ‬
‫ﺍﻹﻧﺘﺮﻧﺖﺍﻟﺨﺎﺹ ﺑﺎﻟﺘﻄﺒﻴﻖ‪ ،‬ﻭﻗﺴﻢ ﺗﻜﻨﻮﻟﻮﺟﻴﺎ ﺍﻟﻤﻌﻠﻮﻣﺎﺕ ﻓﻲ ﺍﻟﻤﺆﺳﺴﺔ ﺍﻟﻤﻀُﻴﻔﺔ ﻟﻠﺘﻄﺒﻴﻖ‪ .‬ﻓﻲ‬
‫ﻛﻞﺣﺎﻟﺔ‪ ،‬ﻳﺸﻤﻞ ﺫﻟﻚ ﻛﻼ ًﻣﻦ ﺍﻟﻤﻮﻇﻔﻴﻦ ﺍﻟﻤﺼُﺮﺡّ ﻟﻬﻢ ﻓﻲ ﺍﻟﻤﺆﺳﺴﺔ ﺍﻟﻤﻌﻨﻴﺔ ﻭﺃﻱ ﻣﻬُﺎﺟﻤﻴﻦ‬
‫ﺧﺎﺭﺟﻴﻴﻦﺍﺧﺘﺮﻗﻮﺍ ﺍﻟﺒﻨﻴﺔ ﺍﻟﺘﺤﺘﻴﺔ ﺍﻟﻤﻌﻨﻴﺔ‪.‬‬

‫ﻓﻲﺃﺑﺴﻂ ﺍﻟﺤﺎﻻﺕ‪ ،‬ﻋﻨﺪﻣﺎ ﻳﺴﺘﺨﺪﻡ ﺗﻄﺒﻴﻖ ﺍﺗﺼﺎﻝ ‪ HTTP‬ﻏﻴﺮ ﻣﺸﻔﺮ ﻟﻼﺗﺼﺎﻻﺕ‪ ،‬ﻳﻤﻜﻦ‬
‫ﻟﻠﻤﻬﺎﺟﻢﺍﻟﺘﻘﺎﻁ ﺟﻤﻴﻊ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺍﻟﻤﻨﻘﻮﻟﺔ ﺑﻴﻦ ﺍﻟﻌﻤﻴﻞ ﻭﺍﻟﺨﺎﺩﻡ‪ ،‬ﺑﻤﺎ ﻓﻲ ﺫﻟﻚ ﺑﻴﺎﻧﺎﺕ ﺍﻋﺘﻤﺎﺩ ﺗﺴﺠﻴﻞ‬
‫ﺍﻟﺪﺧﻮﻝ‪،‬ﻭﺍﻟﻤﻌﻠﻮﻣﺎﺕ ﺍﻟﺸﺨﺼﻴﺔ‪ ،‬ﻭﺗﻔﺎﺻﻴﻞ ﺍﻟﺪﻓﻊ‪ ،‬ﻭﻣﺎ ﺇﻟﻰ ﺫﻟﻚ‪ .‬ﻓﻲ ﻫﺬﻩ ﺍﻟﺤﺎﻟﺔ‪ ،‬ﻏﺎﻟﺒﺎً ﻣﺎ ﻳﻜﻮﻥ‬
‫ﺍﻟﻬﺠﻮﻡﻋﻠﻰ ﺟﻠﺴﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻏﻴﺮ ﺿﺮﻭﺭﻱ‪ ،‬ﺇﺫ ﻳﺴﺘﻄﻴﻊ ﺍﻟﻤﻬﺎﺟﻢ ﺑﺎﻟﻔﻌﻞ ﺍﻻﻃﻼﻉ ﻋﻠﻰ ﻣﻌﻠﻮﻣﺎﺕ‬
‫ﺳﺮﻳﺔ‪،‬ﻭﻳﻤﻜﻨﻪ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺑﻴﺎﻧﺎﺕ ﺍﻋﺘﻤﺎﺩ ﺗﻢ ﺍﻟﺘﻘﺎﻃﻬﺎ ﻟﺘﻨﻔﻴﺬ ﻋﻤﻠﻴﺎﺕ ﺿﺎﺭﺓ ﺃﺧﺮﻯ‪.‬‬
‫ﻭﻣﻊﺫﻟﻚ‪ ،‬ﻗﺪ ﺗﻜﻮﻥ ﺟﻠﺴﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻫﻲ ﺍﻟﻬﺪﻑ ﺍﻟﺮﺉﻴﺴﻲ ﻓﻲ ﺑﻌﺾ ﺍﻟﺤﺎﻻﺕ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ‬
‫ﺍﻟﻤﺜﺎﻝ‪،‬ﺇﺫﺍ ﻛﺎﻧﺖ ﺑﻴﺎﻧﺎﺕ ﺍﻻﻋﺘﻤﺎﺩ ﺍﻟﺘﻲ ﺗﻢ ﺍﻟﺘﻘﺎﻃﻬﺎ ﻏﻴﺮ ﻛﺎﻓﻴﺔ ﻹﺟﺮﺍء ﺗﺴﺠﻴﻞ ﺩﺧﻮﻝ ﺛﺎﻥ ٍ)ﻋﻠﻰ‬
‫ﺳﺒﻴﻞﺍﻟﻤﺜﺎﻝ‪ ،‬ﻓﻲ ﺗﻄﺒﻴﻖ ﻣﺼﺮﻓﻲ‪ ،‬ﻗﺪ ﺗﺘﻀﻤﻦ ﺭﻗﻤﺎً ﻣﻌﺮﻭﺿﺎً ﻋﻠﻰ ﺭﻣﺰ ﻣﺎﺩﻱ ﻣﺘﻐﻴﺮ‪ ،‬ﺃﻭ ﺃﺭﻗﺎﻣﺎً‬
‫ﻣﺤﺪﺩﺓﻣﻦ ﺭﻗﻢ ﺍﻟﺘﻌﺮﻳﻒ ﺍﻟﺸﺨﺼﻲ ﻟﻠﻤﺴﺘﺨﺪﻡ(‪ ،‬ﻓﻘﺪ ﻳﺤﺘﺎﺝ ﺍﻟﻤﻬﺎﺟﻢ ﺇﻟﻰ ﺍﺧﺘﺮﺍﻕ ﺍﻟﺠﻠﺴﺔ ﺍﻟﺘﻲ ﺗﻢ‬
‫ﺍﻟﺘﻨﺼﺖﻋﻠﻴﻬﺎ ﻟﺘﻨﻔﻴﺬ ﻋﻤﻠﻴﺎﺕ ﻋﺸﻮﺍﺉﻴﺔ‪ .‬ﺃﻭ ﺇﺫﺍ ﺧﻀﻌﺖ ﻋﻤﻠﻴﺎﺕ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﻟﺘﺪﻗﻴﻖ‬
‫ﺩﻗﻴﻖ‪،‬ﻭﺗﻢ ﺇﺧﻄﺎﺭ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺑﻜﻞ ﺗﺴﺠﻴﻞ ﺩﺧﻮﻝ ﻧﺎﺟﺢ‪ ،‬ﻓﻘﺪ ﻳﺮﻏﺐ ﺍﻟﻤﻬﺎﺟﻢ ﻓﻲ ﺗﺠﻨﺐ ﺗﺴﺠﻴﻞ‬
‫ﺩﺧﻮﻟﻪﺍﻟﺨﺎﺹ ﻟﻴﻜﻮﻥ ﺃﻛﺜﺮ ﺳﺮﻳﺔ ًﻗﺪﺭ ﺍﻹﻣﻜﺎﻥ‪.‬‬

‫ﻓﻲﺣﺎﻻﺕ ﺃﺧﺮﻯ‪ ،‬ﻗﺪ ﻳﺴﺘﺨﺪﻡ ﺗﻄﺒﻴﻖ ﻣﺎ ﺑﺮﻭﺗﻮﻛﻮﻝ ‪ HTTPS‬ﻟﺤﻤﺎﻳﺔ ﺍﻻﺗﺼﺎﻻﺕ ﺍﻟﺮﺉﻴﺴﻴﺔ ﺑﻴﻦ‬
‫ﺍﻟﻌﻤﻴﻞﻭﺍﻟﺨﺎﺩﻡ‪ ،‬ﻭﻟﻜﻨﻪ ﻗﺪ ﻳﻈﻞ ﻋﺮﺿﺔ ﻻﻋﺘﺮﺍﺽ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ ﻋﻠﻰ ﺍﻟﺸﺒﻜﺔ‪ .‬ﻗﺪ ﻳﻈﻬﺮ ﻫﺬﺍ ﺍﻟﻀﻌﻒ‬
‫ﺑﻄﺮﻕﻣﺨﺘﻠﻔﺔ‪ ،‬ﻭﻛﺜﻴﺮ ﻣﻨﻬﺎ ﻳﻨﺸﺄ ﺗﺤﺪﻳﺪﺍً ﻋﻨﺪ ﺍﺳﺘﺨﺪﺍﻡ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﺭﺗﺒﺎﻁ ‪ HTTP‬ﻛﺂﻟﻴﺔ ﻧﻘﻞ‬
‫ﻟﺮﻣﻮﺯﺍﻟﺠﻠﺴﺔ‪:‬‬

‫ﺗﺨﺘﺎﺭﺑﻌﺾ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﺳﺘﺨﺪﺍﻡ ‪ HTTPS‬ﻟﺤﻤﺎﻳﺔ ﺑﻴﺎﻧﺎﺕ ﺍﻋﺘﻤﺎﺩ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺃﺛﻨﺎء ﺗﺴﺠﻴﻞ‬ ‫‪-‬‬

‫ﺍﻟﺪﺧﻮﻝ‪،‬ﺛﻢ ﺗﻌﻮﺩ ﺇﻟﻰ ‪ HTTP‬ﺧﻼﻝ ﺑﻘﻴﺔ ﺟﻠﺴﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ‪ .‬ﺗﺘﺼﺮﻑ ﺍﻟﻌﺪﻳﺪ ﻣﻦ ﺗﻄﺒﻴﻘﺎﺕ‬
‫ﺑﺮﻳﺪﺍﻟﻮﻳﺐ ﺑﻬﺬﻩ ﺍﻟﻄﺮﻳﻘﺔ‪ .‬ﻓﻲ ﻫﺬﻩ ﺍﻟﺤﺎﻟﺔ‪ ،‬ﻻ ﻳﺴﺘﻄﻴﻊ ﺍﻟﻤﺘﻨﺼﺖ ﺍﻋﺘﺮﺍﺽ ﺑﻴﺎﻧﺎﺕ ﺍﻋﺘﻤﺎﺩ‬
‫ﺍﻟﻤﺴﺘﺨﺪﻡ‪،‬ﻭﻟﻜﻨﻪ ﻗﺪ ﻳﺘﻤﻜﻦ ﻣﻦ ﺍﻟﺘﻘﺎﻁ ﺭﻣﺰ ﺍﻟﺠﻠﺴﺔ‪ .‬ﺗﺴُﻬﻞّ ﺃﺩﺍﺓ ‪ ،Firesheep‬ﺍﻟﻤﺘُﺎﺣﺔ‬
‫ﻛﻤﻜُﻮﻥّﺇﺿﺎﻓﻲ ﻟﻤﺘﺼﻔﺢ ‪ ،Firefox‬ﻫﺬﻩ ﺍﻟﻌﻤﻠﻴﺔ‪.‬‬

‫ﺗﺴﺘﺨﺪﻡﺑﻌﺾ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺑﺮﻭﺗﻮﻛﻮﻝ ‪ HTTP‬ﻟﻠﻤﻨﺎﻃﻖ ﺍﻟﻤﺼُﺎﺩﻕ ﻋﻠﻴﻬﺎ ﻣﺴﺒﻘﺎً ﻓﻲ ﺍﻟﻤﻮﻗﻊ‪،‬‬ ‫‪-‬‬

‫ﻣﺜﻞﺍﻟﺼﻔﺤﺔ ﺍﻟﺮﺉﻴﺴﻴﺔ‪ ،‬ﻭﻟﻜﻨﻬﺎ ﺗﻨﺘﻘﻞ ﺇﻟﻰ ‪ HTTPS‬ﺑﺪءﺍً ﻣﻦ ﺻﻔﺤﺔ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ‪ .‬ﻣﻊ‬
‫ﺫﻟﻚ‪،‬ﻓﻲ ﻛﺜﻴﺮ ﻣﻦ ﺍﻟﺤﺎﻻﺕ‪ ،‬ﻳﺼُﺪﺭ ﻟﻠﻤﺴﺘﺨﺪﻡ ﺭﻣﺰ ﺟﻠﺴﺔ ﻓﻲ ﺍﻟﺼﻔﺤﺔ ﺍﻷﻭﻟﻰ ﺍﻟﺘﻲ ﻳﺰﻭﺭﻫﺎ‪،‬‬
‫ﻭﻻﻳﻌُﺪﻝّ ﻫﺬﺍ ﺍﻟﺮﻣﺰ ﻋﻨﺪ ﺗﺴﺠﻴﻞ ﺩﺧﻮﻟﻪ‪ .‬ﺗﺮُﻓﻊ ﺟﻠﺴﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ‪ ،‬ﺍﻟﺘﻲ ﻟﻢ ﺗﺘﻢ ﻣﺼﺎﺩﻗﺘﻬﺎ‬
‫ﻓﻲﺍﻷﺻﻞ‪ ،‬ﺇﻟﻰ ﺟﻠﺴﺔ ﻣﺼُﺎﺩﻕ ﻋﻠﻴﻬﺎ ﺑﻌﺪ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ‪ .‬ﻓﻲ ﻫﺬﻩ ﺍﻟﺤﺎﻟﺔ‪ ،‬ﻳﻤﻜﻦ‬
‫ﻟﻠﻤﺘﻨﺼﺖﺍﻋﺘﺮﺍﺽ ﺭﻣﺰ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻗﺒﻞ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ‪ ،‬ﻭﺍﻧﺘﻈﺎﺭ ﺗﺤﻮﻳﻞ ﺍﺗﺼﺎﻻﺗﻪ ﺇﻟﻰ‪...‬‬
‫‪235‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬

‫‪.‬ﻣﻤﺎﻳﺸﻴﺮ ﺇﻟﻰ ﺃﻥ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻳﻘﻮﻡ ﺑﺘﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ‪ ،‬ﺛﻢ ﻣﺤﺎﻭﻟﺔ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﺻﻔﺤﺔ‬
‫ﻣﺤﻤﻴﺔ)ﻣﺜﻞ ﺣﺴﺎﺑﻲ( ﺑﺎﺳﺘﺨﺪﺍﻡ ﻫﺬﺍ ﺍﻟﺮﻣﺰ ‪HTTPS،‬‬
‫ﺣﺘﻰﺇﺫﺍ ﺃﺻﺪﺭ ﺍﻟﺘﻄﺒﻴﻖ ﺭﻣﺰﺍً ﺟﺪﻳﺪﺍً ﺑﻌﺪ ﺗﺴﺠﻴﻞ ﺩﺧﻮﻝ ﻧﺎﺟﺢ‪ ،‬ﻭﺍﺳﺘﺨﺪﻡ ‪ HTTPS‬ﻣﻦ‬ ‫‪-‬‬

‫ﺻﻔﺤﺔﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﻓﺼﺎﻋﺪﺍً‪ ،‬ﻓﻘﺪ ﻳﻈﻞ ﺭﻣﺰ ﺟﻠﺴﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺍﻟﻤﺼُﺎﺩﻕ ﻋﻠﻴﻬﺎ‬
‫ﻣﻜﺸﻮﻓﺎً‪.‬ﻗﺪ ﻳﺤﺪﺙ ﻫﺬﺍ ﺇﺫﺍ ﺃﻋﺎﺩ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺯﻳﺎﺭﺓ ﺻﻔﺤﺔ ﻣﺎ ﻗﺒﻞ ﺍﻟﻤﺼﺎﺩﻗﺔ )ﻣﺜﻞ "‬
‫ﺍﻟﻤﺴﺎﻋﺪﺓ" ﺃﻭ "ﺣﻮﻝ"(‪ ،‬ﺇﻣﺎ ﺑﺎﺗﺒﺎﻉ ﺍﻟﺮﻭﺍﺑﻂ ﻓﻲ ﻣﻨﻄﻘﺔ ﺍﻟﻤﺼﺎﺩﻗﺔ‪ ،‬ﺃﻭ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺯﺭ ﺍﻟﺮﺟﻮﻉ‪،‬‬
‫ﺃﻭﺑﻜﺘﺎﺑﺔ ﻋﻨﻮﺍﻥ ‪ URL‬ﻣﺒﺎﺷﺮﺓ‪ً.‬‬

‫ﻓﻲﺗﻨﻮﻳﻌﺔ ﻋﻠﻰ ﺍﻟﺤﺎﻟﺔ ﺍﻟﺴﺎﺑﻘﺔ‪ ،‬ﻗﺪ ﻳﺤﺎﻭﻝ ﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﺘﺒﺪﻳﻞ ﺇﻟﻰ ‪ HTTPS‬ﻋﻨﺪ ﻧﻘﺮ‬ ‫‪-‬‬

‫ﺍﻟﻤﺴﺘﺨﺪﻡﻋﻠﻰ ﺭﺍﺑﻂ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ‪ .‬ﻭﻣﻊ ﺫﻟﻚ‪ ،‬ﻗﺪ ﻳﻘﺒﻞ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﻋﺒﺮ ‪ HTTP‬ﺇﺫﺍ‬
‫ﻋﺪﻝّﺍﻟﻤﺴﺘﺨﺪﻡ ﻋﻨﻮﺍﻥ ‪ URL‬ﻭﻓﻘﺎً ﻟﺬﻟﻚ‪ .‬ﻓﻲ ﻫﺬﻩ ﺍﻟﺤﺎﻟﺔ‪ ،‬ﻳﻤﻜﻦ ﻟﻠﻤﻬﺎﺟﻢ‪ ،‬ﻓﻲ ﻣﻮﻗﻊ‬
‫ﻣﻨﺎﺳﺐ‪،‬ﺗﻌﺪﻳﻞ ﺍﻟﺼﻔﺤﺎﺕ ﺍﻟﻤﻌﺮﻭﺿﺔ ﻓﻲ ﺍﻟﻤﻨﺎﻃﻖ ﺍﻟﻤﺼُﺎﺩﻕ ﻋﻠﻴﻬﺎ ﻣﺴﺒﻘﺎً ﻣﻦ ﺍﻟﻤﻮﻗﻊ‬
‫ﺑﺤﻴﺚﻳﺸُﻴﺮ ﺭﺍﺑﻂ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﺇﻟﻰ ﺻﻔﺤﺔ ‪ .HTTP‬ﺣﺘﻰ ﺇﺫﺍ ﺃﺻﺪﺭ ﺍﻟﺘﻄﺒﻴﻖ ﺭﻣﺰ ﺟﻠﺴﺔ‬
‫ﺟﺪﻳﺪﺑﻌﺪ ﺗﺴﺠﻴﻞ ﺩﺧﻮﻝ ﻧﺎﺟﺢ‪ ،‬ﻓﺴﻴﻈﻞ ﺑﺈﻣﻜﺎﻥ ﺍﻟﻤﻬﺎﺟﻢ ﺍﻋﺘﺮﺍﺽ ﻫﺬﺍ ﺍﻟﺮﻣﺰ ﺇﺫﺍ ﻧﺠﺢ ﻓﻲ‬
‫ﺗﺨﻔﻴﺾﻣﺴﺘﻮﻯ ﺍﺗﺼﺎﻝ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺇﻟﻰ ‪.HTTP‬‬

‫ﺗﺴﺘﺨﺪﻡﺑﻌﺾ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺑﺮﻭﺗﻮﻛﻮﻝ ‪ HTTP‬ﻟﺠﻤﻴﻊ ﺍﻟﻤﺤﺘﻮﻳﺎﺕ ﺍﻟﺜﺎﺑﺘﺔ ﺩﺍﺧﻞ ﺍﻟﺘﻄﺒﻴﻖ‪،‬‬ ‫‪-‬‬

‫ﻣﺜﻞﺍﻟﺼﻮﺭ ﻭﺍﻟﺒﺮﺍﻣﺞ ﺍﻟﻨﺼﻴﺔ ﻭﺃﻭﺭﺍﻕ ﺍﻷﻧﻤﺎﻁ ﻭﻗﻮﺍﻟﺐ ﺍﻟﺼﻔﺤﺎﺕ‪ .‬ﻏﺎﻟﺒﺎً ﻣﺎ ﻳﺸُﺎﺭ ﺇﻟﻰ ﻫﺬﺍ‬
‫ﺍﻟﺴﻠﻮﻙﺑﺘﺤﺬﻳﺮ ﺩﺍﺧﻞ ﻣﺘﺼﻔﺢ ﺍﻟﻤﺴﺘﺨﺪﻡ‪ ،‬ﻛﻤﺎ ﻫﻮ ﻣﻮﺿﺢ ﻓﻲ ﺍﻟﺸﻜﻞ ‪ .9-7‬ﻋﻨﺪﻣﺎ ﻳﻈُﻬﺮ‬
‫ﺍﻟﻤﺘﺼﻔﺢﻫﺬﺍ ﺍﻟﺘﺤﺬﻳﺮ‪ ،‬ﻳﻜﻮﻥ ﻗﺪ ﺍﺳﺘﻌﺎﺩ ﺍﻟﻌﻨﺼﺮ ﺫﻱ ﺍﻟﺼﻠﺔ ﻋﺒﺮ ‪ ،HTTP‬ﻭﺑﺎﻟﺘﺎﻟﻲ ﻳﻜﻮﻥ ﺭﻣﺰ‬
‫ﺍﻟﺠﻠﺴﺔﻗﺪ ﺗﻢ ﺇﺭﺳﺎﻟﻪ ﺑﺎﻟﻔﻌﻞ‪ .‬ﺍﻟﻐﺮﺽ ﻣﻦ ﺗﺤﺬﻳﺮ ﺍﻟﻤﺘﺼﻔﺢ ﻫﻮ ﺍﻟﺴﻤﺎﺡ ﻟﻠﻤﺴﺘﺨﺪﻡ ﺑﺮﻓﺾ‬
‫ﻣﻌﺎﻟﺠﺔﺑﻴﺎﻧﺎﺕ ﺍﻻﺳﺘﺠﺎﺑﺔ ﺍﻟﺘﻲ ﺗﻢ ﺍﺳﺘﻼﻣﻬﺎ ﻋﺒﺮ ‪ HTTP‬ﻭﺍﻟﺘﻲ ﻗﺪ ﺗﻜﻮﻥ ﻣﻠﻮﺛﺔ‪.‬‬

‫ﻗﺒﻮﻝﺍﻟﻤﺴﺘﺨﺪﻡ‬
‫ﻋﺒﺮ‪ HTTP‬ﻭ‬ ‫ﺭﻣﺰﺍﻟﺠﻠﺴﺔ‬
‫ﺍﻟﻤﻮﻗﻊﻋﺒﺮ ‪.HTTPS‬‬ ‫ﺍﺳﺘﺨﺪﻡﻫﺬﺍ ﺍﻟﺨﺘﻢ‬

‫ﺍﻟﺸﻜﻞ‪:9-7‬ﻳﻌﺮﺽ ﺍﻟﻤﺘﺼﻔﺢ ﺗﺤﺬﻳﺮﺍً ﻋﻨﺪﻣﺎ ﺗﺤﺘﻮﻱ ﺍﻟﺼﻔﺤﺔ ﺍﻟﺘﻲ ﺗﻢ‬

‫ﺍﻟﻮﺻﻮﻝﺇﻟﻴﻬﺎ ﻋﺒﺮ ‪ HTTPS‬ﻋﻠﻰ ﻋﻨﺎﺻﺮ ﺗﻢ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻴﻬﺎ ﻋﺒﺮ ‪.HTTP‬‬

‫ﺣﺘﻰﻟﻮ ﺍﺳﺘﺨﺪﻡ ﺍﻟﺘﻄﺒﻴﻖ ‪ HTTPS‬ﻟﻜﻞ ﺻﻔﺤﺔ‪ ،‬ﺑﻤﺎ ﻓﻲ ﺫﻟﻚ ﺍﻟﻤﻨﺎﻃﻖ ﻏﻴﺮ ﺍﻟﻤﺼﺎﺩﻕ ﻋﻠﻴﻬﺎ‬ ‫‪-‬‬

‫ﻣﻦﺍﻟﻤﻮﻗﻊ ﻭﺍﻟﻤﺤﺘﻮﻯ ﺍﻟﺜﺎﺑﺖ‪ ،‬ﻓﻘﺪ ﺗﻈﻞ ﻫﻨﺎﻙ ﻇﺮﻭﻑ ﺗﻨُﻘﻞ ﻓﻴﻬﺎ ﺭﻣﻮﺯ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﻋﺒﺮ‬
‫‪ .HTTP‬ﺇﺫﺍ ﺗﻤﻜﻦ ﻣﻬﺎﺟﻢ ﺑﻄﺮﻳﻘﺔ ﻣﺎ ﻣﻦ ﺣﺚ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻋﻠﻰ ﺗﻘﺪﻳﻢ ﻃﻠﺐ ﻋﺒﺮ ‪) HTTP‬ﺇﻣﺎ‬
‫ﺇﻟﻰ‪(HTTPS‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬ ‫‪236‬‬

‫ﺍﻟﺨﺪﻣﺔﻋﻠﻰ ﻧﻔﺲ ﺍﻟﺨﺎﺩﻡ ﺇﺫﺍ ﻛﺎﻥ ﺃﺣﺪﻫﻤﺎ ﻗﻴﺪ ﺍﻟﺘﺸﻐﻴﻞ ﺃﻭ‪http://server:443/‬‬

‫ﺑﺨﻼﻑﺫﻟﻚ‪ ،‬ﻗﺪ ﻳﺘﻢ ﺇﺭﺳﺎﻝ ﺭﻣﺰﻩ‪ .‬ﺗﺸﻤﻞ ﺍﻟﻮﺳﺎﺉﻞ ﺍﻟﺘﻲ ﻗﺪ ﻳﺤﺎﻭﻝ ﺍﻟﻤﻬﺎﺟﻢ ﻣﻦ ﺧﻼﻟﻬﺎ‬
‫ﺫﻟﻚﺇﺭﺳﺎﻝ ﻋﻨﻮﺍﻥ ‪ URL‬ﻟﻠﻤﺴﺘﺨﺪﻡ ﻋﺒﺮ ﺑﺮﻳﺪ ﺇﻟﻜﺘﺮﻭﻧﻲ ﺃﻭ ﺭﺳﺎﻟﺔ ﻓﻮﺭﻳﺔ‪ ،‬ﺃﻭ ﻭﺿﻊ ﺭﻭﺍﺑﻂ‬
‫ﺗﺤﻤﻴﻞﺗﻠﻘﺎﺉﻲ ﻋﻠﻰ ﻣﻮﻗﻊ ﻭﻳﺐ ﻳﺘﺤﻜﻢ ﺑﻪ ﺍﻟﻤﻬﺎﺟﻢ‪ ،‬ﺃﻭ ﺍﺳﺘﺨﺪﺍﻡ ﻻﻓﺘﺎﺕ ﺇﻋﻼﻧﻴﺔ ﻗﺎﺑﻠﺔ‬
‫ﻟﻠﻨﻘﺮ‪).‬ﺍﻧﻈﺮ ﺍﻟﻔﺼﻠﻴﻦ ‪ 12‬ﻭ‪ 13‬ﻟﻤﺰﻳﺪ ﻣﻦ ﺍﻟﺘﻔﺎﺻﻴﻞ ﺣﻮﻝ ﺗﻘﻨﻴﺎﺕ ﻣﻦ ﻫﺬﺍ ﺍﻟﻨﻮﻉ ﻟﺸﻦ‬
‫ﻫﺠﻤﺎﺕﻋﻠﻰ ﻣﺴﺘﺨﺪﻣﻴﻦ ﺁﺧﺮﻳﻦ(‪.‬‬

‫ﺧﻄﻮﺍﺕﺍﻻﺧﺘﺮﺍﻕ‬

‫‪.١‬ﺗﻔَﺤَﺺَّ ﺍﻟﺘﻄﺒﻴﻖ ﺑﺎﻟﻄﺮﻳﻘﺔ ﺍﻻﻋﺘﻴﺎﺩﻳﺔ‪ ،‬ﺑﺪءﺍً ﻣﻦ ﺃﻭﻝ ﻭﺻﻮﻝ )ﺭﺍﺑﻂ "ﺍﻟﺒﺪء"(‪ ،‬ﻣﺮﻭﺭﺍً ﺑﻌﻤﻠﻴﺔ‬
‫ﺗﺴﺠﻴﻞﺍﻟﺪﺧﻮﻝ‪ ،‬ﺛﻢ ﺟﻤﻴﻊ ﻭﻇﺎﺉﻒ ﺍﻟﺘﻄﺒﻴﻖ‪ .‬ﺳﺠﻞّ ﻛﻞ ﺭﺍﺑﻂ ﺯﺭﺗﻪ‪ ،‬ﻭﺩﻭﻥِّ ﻛﻞ ﻣﺮﺓ ﻳﺘﻢ ﻓﻴﻬﺎ‬
‫ﺍﺳﺘﻼﻡﺭﻣﺰ ﺟﻠﺴﺔ ﺟﺪﻳﺪ‪ .‬ﺍﻧﺘﺒﻪ ﺟﻴﺪﺍً ﻟﻮﻇﺎﺉﻒ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﻭﺍﻻﻧﺘﻘﺎﻻﺕ ﺑﻴﻦ ﺑﺮﻭﺗﻮﻛﻮﻟﻲ‬
‫‪ HTTP‬ﻭ‪.HTTPS‬‬

‫ﻣﺜﻞﺍﻷﺳﻼﻙ‬
‫ﺍﻋﺘﺮﺍﺽ‬

‫ﺍﻟﺸﻜﻞ‪:10-7‬ﺍﻟﺘﺠﻮﻝ ﻋﺒﺮ ﺍﻟﺘﻄﺒﻴﻖ ﻟﺘﺤﺪﻳﺪ ﺍﻟﻤﻮﺍﻗﻊ ﺍﻟﺘﻲ ﻳﺘﻢ ﻓﻴﻬﺎ ﺗﻠﻘﻲ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ ﺍﻟﺠﺪﻳﺪﺓ‪.‬‬

‫‪.2‬ﺇﺫﺍ ﺗﻢ ﺍﺳﺘﺨﺪﺍﻡ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ‪ HTTP‬ﻛﺂﻟﻴﺔ ﺇﺭﺳﺎﻝ ﻟﺮﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ‪ ،‬ﻓﺘﺄﻛﺪ ﻣﻤﺎ ﺇﺫﺍ‬
‫ﻛﺎﻧﺖﻳﺆﻣﻦﺗﻢ ﺗﻌﻴﻴﻦ ﺍﻟﻌﻠﻢ‪ ،‬ﻣﻤﺎ ﻳﻤﻨﻊ ﻧﻘﻠﻬﺎ ﺃﺑﺪﺍً ﻋﺒﺮ ﺍﺗﺼﺎﻻﺕ ﻏﻴﺮ ﻣﺸﻔﺮﺓ‪.‬‬

‫‪.٣‬ﺗﺄﻛﺪ ﻣﻤﺎ ﺇﺫﺍ ﻛﺎﻧﺖ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ ﺗﻨُﻘﻞ ﻋﺒﺮ ﺍﺗﺼﺎﻝ ﻏﻴﺮ ﻣﺸﻔﺮ ﺃﺛﻨﺎء ﺍﻻﺳﺘﺨﺪﺍﻡ ﺍﻟﻌﺎﺩﻱ‬
‫ﻟﻠﺘﻄﺒﻴﻖ‪.‬ﺇﺫﺍ ﻛﺎﻥ ﺍﻷﻣﺮ ﻛﺬﻟﻚ‪ ،‬ﻓﻴﻨﺒﻐﻲ ﺍﻋﺘﺒﺎﺭﻫﺎ ﻋﺮﺿﺔ ﻟﻼﻋﺘﺮﺍﺽ‪.‬‬

‫‪.٤‬ﺇﺫﺍ ﻛﺎﻧﺖ ﺻﻔﺤﺔ ﺍﻟﺒﺪء ﺗﺴﺘﺨﺪﻡ ‪ ،HTTP‬ﻭﺍﻧﺘﻘﻞ ﺍﻟﺘﻄﺒﻴﻖ ﺇﻟﻰ ‪ HTTPS‬ﻟﺘﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ‬
‫ﻭﺍﻟﻤﻨﺎﻃﻖﺍﻟﻤﺼُﺎﺩﻕ ﻋﻠﻴﻬﺎ ﻓﻲ ﺍﻟﻤﻮﻗﻊ‪ ،‬ﻓﺘﺄﻛﺪ ﻣﻦ ﺇﺻﺪﺍﺭ ﺭﻣﺰ ﺟﺪﻳﺪ ﺑﻌﺪ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ‪ ،‬ﺃﻭ‬
‫ﻣﺎﺇﺫﺍ ﻛﺎﻥ ﺍﻟﺮﻣﺰ ﺍﻟﻤﺮُﺳﻞ ﺃﺛﻨﺎء ﻣﺮﺣﻠﺔ ‪ HTTP‬ﻻ ﻳﺰﺍﻝ ﻳﺴُﺘﺨﺪﻡ ﻟﺘﺘﺒﻊ ﺟﻠﺴﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ‬
‫ﺍﻟﻤﺼُﺎﺩﻕﻋﻠﻴﻬﺎ‪ .‬ﺗﺄﻛﺪ ﺃﻳﻀﺎً ﻣﻦ ﻗﺒﻮﻝ ﺍﻟﺘﻄﺒﻴﻖ ﻟﺘﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﻋﺒﺮ ‪ HTTP‬ﺇﺫﺍ ﺗﻢ ﺗﻌﺪﻳﻞ‬
‫ﻋﻨﻮﺍﻥ‪ URL‬ﻟﺘﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﻭﻓﻘﺎً ﻟﺬﻟﻚ‪.‬‬
‫‪237‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬

‫‪.٥‬ﺣﺘﻰ ﻟﻮ ﻛﺎﻥ ﺍﻟﺘﻄﺒﻴﻖ ﻳﺴﺘﺨﺪﻡ ‪ HTTPS‬ﻟﻜﻞ ﺻﻔﺤﺔ‪ ،‬ﻓﺘﺄﻛﺪ ﻣﻦ ﺃﻥ ﺍﻟﺨﺎﺩﻡ ﻳﺴﺘﻤﻊ ﺃﻳﻀﺎً‬
‫ﻋﻠﻰﺍﻟﻤﻨﻔﺬ ‪ ،٨٠‬ﻭﻳﺸُﻐﻞّ ﺃﻱ ﺧﺪﻣﺔ ﺃﻭ ﻣﺤﺘﻮﻯ‪ .‬ﻓﻲ ﻫﺬﻩ ﺍﻟﺤﺎﻟﺔ‪ ،‬ﻗﻢ ﺑﺰﻳﺎﺭﺓ ﺃﻱ ﻋﻨﻮﺍﻥ ‪HTTP‬‬
‫‪ URL‬ﻣﺒﺎﺷﺮﺓ ًﻣﻦ ﺩﺍﺧﻞ ﺟﻠﺴﺔ ﻣﺼُﺎﺩﻕ ﻋﻠﻴﻬﺎ‪ ،‬ﻭﺗﺤﻘﻖ ﻣﻦ ﺇﺭﺳﺎﻝ ﺭﻣﺰ ﺍﻟﺠﻠﺴﺔ‪.‬‬

‫‪.6‬ﻓﻲ ﺍﻟﺤﺎﻻﺕ ﺍﻟﺘﻲ ﻳﺘﻢ ﻓﻴﻬﺎ ﺇﺭﺳﺎﻝ ﺭﻣﺰ ﻟﺠﻠﺴﺔ ﻣﺼﺎﺩﻕ ﻋﻠﻴﻬﺎ ﺇﻟﻰ ﺍﻟﺨﺎﺩﻡ ﻋﺒﺮ ‪ ،HTTP‬ﺗﺤﻘﻖ‬
‫ﻣﻤﺎﺇﺫﺍ ﻛﺎﻥ ﻫﺬﺍ ﺍﻟﺮﻣﺰ ﻻ ﻳﺰﺍﻝ ﺻﺎﻟﺤﺎً ﺃﻡ ﻳﺘﻢ ﺇﻧﻬﺎﺅﻩ ﻓﻮﺭﺍً ﺑﻮﺍﺳﻄﺔ ﺍﻟﺨﺎﺩﻡ‪.‬‬

‫ﺟﺮﺑﻬﺎ!‬

‫‪/372/ http://mdsec.net/auth/374/‬‬
‫‪/auth/369/ http://mdsec.net/auth‬‬
‫‪http://mdsec.net‬‬

‫ﺍﻹﻓﺼﺎﺡﻋﻦ ﺍﻟﺮﻣﻮﺯ ﻓﻲ ﺍﻟﺴﺠﻼﺕ‬

‫ﺇﻟﻰﺟﺎﻧﺐ ﻧﻘﻞ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ ﺑﻨﺺ ﻭﺍﺿﺢ ﻓﻲ ﺍﺗﺼﺎﻻﺕ ﺍﻟﺸﺒﻜﺔ‪ ،‬ﻓﺈﻥ ﺃﻛﺜﺮ ﺍﻷﻣﺎﻛﻦ ﺷﻴﻮﻋﺎً ﻟﻠﻜﺸﻒ‬
‫ﻋﻦﺍﻟﺮﻣﻮﺯ ﻟﻌﺮﺿﻬﺎ ﺩﻭﻥ ﺗﺼﺮﻳﺢ ﻫﻮ ﺳﺠﻼﺕ ﺍﻟﻨﻈﺎﻡ ﺑﻤﺨﺘﻠﻒ ﺃﻧﻮﺍﻋﻬﺎ‪ .‬ﻭﺭﻏﻢ ﻧﺪﺭﺓ ﺣﺪﻭﺙ ﺫﻟﻚ‪ ،‬ﺇﻻ‬
‫ﺃﻥﻋﻮﺍﻗﺐ ﻫﺬﺍ ﺍﻟﻨﻮﻉ ﻣﻦ ﺍﻟﻜﺸﻒ ﻋﺎﺩﺓ ًﻣﺎ ﺗﻜﻮﻥ ﺃﺷﺪ ﺧﻄﻮﺭﺓ‪ .‬ﺇﺫ ﻳﻤﻜﻦ ﺍﻻﻃﻼﻉ ﻋﻠﻰ ﻫﺬﻩ ﺍﻟﺴﺠﻼﺕ‬
‫ﻣﻦﻗﺒِﻞ ﻣﺠﻤﻮﻋﺔ ﺃﻭﺳﻊ ﺑﻜﺜﻴﺮ ﻣﻦ ﺍﻟﻤﻬﺎﺟﻤﻴﻦ ﺍﻟﻤﺤﺘﻤﻠﻴﻦ‪ ،‬ﻭﻟﻴﺲ ﻓﻘﻂ ﻣﻦ ﻗﺒِﻞ ﺷﺨﺺ ﻣﺆﻫﻞ‬
‫ﻟﻠﺘﻨﺼﺖﻋﻠﻰ ﺍﻟﺸﺒﻜﺔ‪.‬‬

‫ﺗﻮﻓﺮﺍﻟﻌﺪﻳﺪ ﻣﻦ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﻭﻇﺎﺉﻒ ﻟﻠﻤﺴﺆﻭﻟﻴﻦ ﻭﻣﻮﻇﻔﻲ ﺍﻟﺪﻋﻢ ﺍﻵﺧﺮﻳﻦ ﻟﻤﺮﺍﻗﺒﺔ ﺟﻮﺍﻧﺐ ﺣﺎﻟﺔ‬
‫ﺗﺸﻐﻴﻞﺍﻟﺘﻄﺒﻴﻖ ﻭﺍﻟﺘﺤﻜﻢ ﻓﻴﻬﺎ‪ ،‬ﺑﻤﺎ ﻓﻲ ﺫﻟﻚ ﺟﻠﺴﺎﺕ ﺍﻟﻤﺴﺘﺨﺪﻡ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﻗﺪ ﻳﻄﻠﺐ‬
‫ﻣﻮﻇﻒﺍﻟﺪﻋﻢ ﺍﻟﻔﻨﻲ ﺍﻟﺬﻱ ﻳﺴﺎﻋﺪ ﻣﺴﺘﺨﺪﻣﺎً ﻳﻮﺍﺟﻪ ﻣﺸﺎﻛﻞ ﺍﺳﻢ ﺍﻟﻤﺴﺘﺨﺪﻡ‪ ،‬ﻭﺗﺤﺪﻳﺪ ﺟﻠﺴﺘﻪ‬
‫ﺍﻟﺤﺎﻟﻴﺔﻋﺒﺮ ﻗﺎﺉﻤﺔ ﺃﻭ ﻭﻇﻴﻔﺔ ﺑﺤﺚ‪ ،‬ﻭﻋﺮﺽ ﺗﻔﺎﺻﻴﻞ ﺫﺍﺕ ﺻﻠﺔ ﺑﺎﻟﺠﻠﺴﺔ‪ .‬ﺃﻭ ﻗﺪ ﻳﻄﻠﻊ ﺍﻟﻤﺴﺆﻭﻝ‬
‫ﻋﻠﻰﺳﺠﻞ ﺍﻟﺠﻠﺴﺎﺕ ﺍﻷﺧﻴﺮﺓ ﺃﺛﻨﺎء ﺍﻟﺘﺤﻘﻴﻖ ﻓﻲ ﺧﺮﻕ ﺃﻣﻨﻲ‪ .‬ﻏﺎﻟﺒﺎً ﻣﺎ ﻳﻜﺸﻒ ﻫﺬﺍ ﺍﻟﻨﻮﻉ ﻣﻦ‬
‫ﻭﻇﺎﺉﻒﺍﻟﻤﺮﺍﻗﺒﺔ ﻭﺍﻟﺘﺤﻜﻢ ﻋﻦ ﺭﻣﺰ ﺍﻟﺠﻠﺴﺔ ﺍﻟﻔﻌﻠﻲ ﺍﻟﻤﺮﺗﺒﻂ ﺑﻜﻞ ﺟﻠﺴﺔ‪ .‬ﻭﻏﺎﻟﺒﺎً ﻣﺎ ﺗﻜﻮﻥ ﻫﺬﻩ‬
‫ﺍﻟﻮﻇﻴﻔﺔﺿﻌﻴﻔﺔ ﺍﻟﺤﻤﺎﻳﺔ‪ ،‬ﻣﻤﺎ ﻳﺴﻤﺢ ﻟﻠﻤﺴﺘﺨﺪﻣﻴﻦ ﻏﻴﺮ ﺍﻟﻤﺼﺮﺡ ﻟﻬﻢ ﺑﺎﻟﻮﺻﻮﻝ ﺇﻟﻰ ﻗﺎﺉﻤﺔ ﺭﻣﻮﺯ‬
‫ﺍﻟﺠﻠﺴﺔﺍﻟﺤﺎﻟﻴﺔ‪ ،‬ﻭﺑﺎﻟﺘﺎﻟﻲ ﺍﺧﺘﺮﺍﻕ ﺟﻠﺴﺎﺕ ﺟﻤﻴﻊ ﻣﺴﺘﺨﺪﻣﻲ ﺍﻟﺘﻄﺒﻴﻖ‪.‬‬

‫ﺍﻟﺴﺒﺐﺍﻟﺮﺉﻴﺴﻲ ﺍﻵﺧﺮ ﻟﻈﻬﻮﺭ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ ﻓﻲ ﺳﺠﻼﺕ ﺍﻟﻨﻈﺎﻡ ﻫﻮ ﻋﻨﺪﻣﺎ ﻳﺴﺘﺨﺪﻡ ﺍﻟﺘﻄﺒﻴﻖ‬
‫ﺳﻠﺴﻠﺔﺍﺳﺘﻌﻼﻡ ‪ URL‬ﻛﺂﻟﻴﺔ ﻟﻨﻘﻞ ﺍﻟﺮﻣﻮﺯ‪ ،‬ﺑﺪﻻ ًﻣﻦ ﺍﺳﺘﺨﺪﺍﻡ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ‪ HTTP‬ﺃﻭ ﻧﺺ‬
‫ﺑﺮﻳﺪﺍﻟﻄﻠﺒﺎﺕ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﺍﻟﺒﺤﺚ ﻓﻲ ﺟﻮﺟﻞﻋﻨﻮﺍﻥ ‪URL:jsessionid‬ﻳﺤﺪﺩ ﺁﻻﻑ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ‬
‫ﺍﻟﺘﻲﺗﻨﻘﻞ ﺭﻣﺰ ﺟﻠﺴﺔ ﻣﻨﺼﺔ ‪) Java‬ﺍﻟﻤﺴﻤﻰﻣﻌﺮﻑ ﺍﻟﺠﻠﺴﺔﺿﻤﻦ ﻋﻨﻮﺍﻥ ‪:URL‬‬

‫‪/do/Navigation;jsessionid=F27ED2A6AAE4C6DA409A3044E79B8B48?category=327‬‬
‫‪http://www.webjunction.org‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬ ‫‪238‬‬

‫ﻋﻨﺪﻣﺎﺗﺮﺳﻞ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ ﺍﻟﺨﺎﺻﺔ ﺑﻬﺎ ﺑﻬﺬﻩ ﺍﻟﻄﺮﻳﻘﺔ‪ ،‬ﻓﻤﻦ ﺍﻟﻤﺤﺘﻤﻞ ﺃﻥ ﺗﻈﻬﺮ ﺭﻣﻮﺯ‬
‫ﺍﻟﺠﻠﺴﺔﺍﻟﺨﺎﺻﺔ ﺑﻬﺎ ﻓﻲ ﺳﺠﻼﺕ ﺍﻟﻨﻈﺎﻡ ﺍﻟﻤﺨﺘﻠﻔﺔ ﺍﻟﺘﻲ ﻗﺪ ﻳﺘﻤﻜﻦ ﺃﻃﺮﺍﻑ ﻏﻴﺮ ﻣﺼﺮﺡ ﻟﻬﻢ ﻣﻦ‬
‫ﺍﻟﻮﺻﻮﻝﺇﻟﻴﻬﺎ‪:‬‬
‫ﺳﺠﻼﺕﻣﺘﺼﻔﺢ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ‬ ‫‪-‬‬

‫ﺳﺠﻼﺕﺧﺎﺩﻡ ﺍﻟﻮﻳﺐ‬ ‫‪-‬‬

‫ﺳﺠﻼﺕﺧﻮﺍﺩﻡ ﺍﻟﺒﺮﻭﻛﺴﻲ ﺍﻟﺨﺎﺻﺔ ﺑﺎﻟﺸﺮﻛﺎﺕ ﺃﻭ ﻣﺰﻭﺩﻱ ﺧﺪﻣﺔ ﺍﻹﻧﺘﺮﻧﺖ‬ ‫‪-‬‬

‫ﺳﺠﻼﺕﺃﻱ ﻭﻛﻼء ﻋﻜﺴﻴﻴﻦ ﻣﺴﺘﺨﺪﻣﻴﻦ ﺩﺍﺧﻞ ﺑﻴﺉﺔ ﺍﺳﺘﻀﺎﻓﺔ ﺍﻟﺘﻄﺒﻴﻖ‬ ‫‪-‬‬

‫ﺳﺠﻼﺕﺍﻟﻤﺮﺟﻊ ﻷﻱ ﺧﻮﺍﺩﻡ ﻳﺰﻭﺭﻫﺎ ﻣﺴﺘﺨﺪﻣﻮ ﺍﻟﺘﻄﺒﻴﻖ ﻣﻦ ﺧﻼﻝ ﺍﺗﺒﺎﻉ ﺍﻟﺮﻭﺍﺑﻂ ﺧﺎﺭﺝ‬ ‫‪-‬‬

‫ﺍﻟﻤﻮﻗﻊ‪،‬ﻛﻤﺎ ﻫﻮ ﻣﻮﺿﺢ ﻓﻲ ﺍﻟﺸﻜﻞ ‪11-7‬‬

‫ﺑﻌﺾﻣﻦ ﺕ‬
‫ﻃﻠﺐ‪.‬‬

‫ﺍﻟﺸﻜﻞ‪:11-7‬ﻋﻨﺪﻣﺎ ﺗﻈﻬﺮ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ ﻓﻲ ﻋﻨﺎﻭﻳﻦ ‪ ،URL‬ﻳﺘﻢ ﻧﻘﻠﻬﺎ ﻓﻲ ﺭﺃﺱ ﺍﻟﻤﺮﺟﻊ ﻋﻨﺪﻣﺎ ﻳﺘﺒﻊ‬
‫ﺍﻟﻤﺴﺘﺨﺪﻣﻮﻥﺭﺍﺑﻄﺎً ﺧﺎﺭﺝ ﺍﻟﻤﻮﻗﻊ ﺃﻭ ﻋﻨﺪﻣﺎ ﻳﻘﻮﻡ ﻣﺘﺼﻔﺤﻬﻢ ﺑﺘﺤﻤﻴﻞ ﻣﻮﺭﺩ ﺧﺎﺭﺝ ﺍﻟﻤﻮﻗﻊ‪.‬‬

‫ﺍﻟﺤﺎﻟﺔﺍﻷﺧﻴﺮﺓ ﺍﻟﺘﻲ ﻭﺻﻔﻨﺎﻫﺎ ﻟﻠﺘﻮ ﺗﻘُﺪﻡّ ﻟﻠﻤﻬﺎﺟﻢ ﻭﺳﻴﻠﺔ ﻓﻌﺎّﻟﺔ ﻟﻠﻐﺎﻳﺔ ﻻﻟﺘﻘﺎﻁ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ ﻓﻲ‬
‫ﺑﻌﺾﺍﻟﺘﻄﺒﻴﻘﺎﺕ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﺇﺫﺍ ﺃﺭﺳﻞ ﺗﻄﺒﻴﻖ ﺑﺮﻳﺪ ﺇﻟﻜﺘﺮﻭﻧﻲ ﺭﻣﻮﺯ ﺟﻠﺴﺔ ﺿﻤﻦ ﻋﻨﻮﺍﻥ‬
‫‪ ،URL‬ﻳﻤُﻜﻦ ﻟﻠﻤﻬﺎﺟﻢ ﺇﺭﺳﺎﻝ ﺭﺳﺎﺉﻞ ﺑﺮﻳﺪ ﺇﻟﻜﺘﺮﻭﻧﻲ ﺇﻟﻰ ﻣﺴﺘﺨﺪﻣﻲ ﺍﻟﺘﻄﺒﻴﻖ ﺗﺤﺘﻮﻱ ﻋﻠﻰ ﺭﺍﺑﻂ‬
‫ﺇﻟﻰﺧﺎﺩﻡ ﻭﻳﺐ ﻳﺘﺤﻜﻢ ﻓﻴﻪ‪ .‬ﺇﺫﺍ ﻗﺎﻡ ﺃﻱ ﻣﺴﺘﺨﺪﻡ ﺑﺎﻟﻮﺻﻮﻝ ﺇﻟﻰ ﺍﻟﺮﺍﺑﻂ )ﺑﺴﺒﺐ ﻧﻘﺮﻩ ﻋﻠﻴﻪ‪ ،‬ﺃﻭ ﻷﻥ‬
‫ﻣﺘﺼﻔﺤﻪﻳﺤُﻤﻞّ ﺻﻮﺭﺍً ﻣﻀُﻤﻨﺔ ﻓﻲ ﺑﺮﻳﺪ ﺇﻟﻜﺘﺮﻭﻧﻲ ﺑﺘﻨﺴﻴﻖ ‪ ،(HTML‬ﻳﺘﻠﻘﻰ ﺍﻟﻤﻬﺎﺟﻢ‪ ،‬ﻓﻲ ﺍﻟﻮﻗﺖ‬
‫ﺍﻟﻔﻌﻠﻲ‪،‬ﺭﻣﺰ ﺟﻠﺴﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ‪ .‬ﻳﻤُﻜﻦ ﻟﻠﻤﻬﺎﺟﻢ ﺗﺸﻐﻴﻞ ﺑﺮﻧﺎﻣﺞ ﻧﺼﻲ ﺑﺴﻴﻂ ﻋﻠﻰ ﺧﺎﺩﻣﻪ ﻻﺧﺘﻄﺎﻑ‬
‫ﺟﻠﺴﺔﻛﻞ ﺭﻣﺰ ﻣﺴُﺘﻠﻢ‪.‬‬
‫‪239‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬

‫ﺗﻨﻔﻴﺬﺑﻌﺾ ﺍﻹﺟﺮﺍءﺍﺕ ﺍﻟﻀﺎﺭﺓ‪ ،‬ﻣﺜﻞ ﺇﺭﺳﺎﻝ ﺭﺳﺎﺉﻞ ﺍﻟﺒﺮﻳﺪ ﺍﻹﻟﻜﺘﺮﻭﻧﻲ ﻏﻴﺮ ﺍﻟﻤﺮﻏﻮﺏ ﻓﻴﻬﺎ‪ ،‬ﺃﻭ ﺟﻤﻊ‬
‫ﺍﻟﻤﻌﻠﻮﻣﺎﺕﺍﻟﺸﺨﺼﻴﺔ‪ ،‬ﺃﻭ ﺗﻐﻴﻴﺮ ﻛﻠﻤﺎﺕ ﺍﻟﻤﺮﻭﺭ‪.‬‬

‫ﻣﻠﺤﻮﻇﺔﻻ ﺗﺘﻀﻤﻦ ﺍﻹﺻﺪﺍﺭﺍﺕ ﺍﻟﺤﺎﻟﻴﺔ ﻣﻦ ﻣﺘﺼﻔﺢ ﺇﻧﺘﺮﻧﺖ ﺇﻛﺴﺒﻠﻮﺭﺭ ﺭﺃﺱ "ﺍﻟﻤﺮﺟﻊ" ﻋﻨﺪ‬
‫ﻣﺘﺎﺑﻌﺔﺭﻭﺍﺑﻂ ﺧﺎﺭﺟﻴﺔ ﻣﻀﻤﻨﺔ ﻓﻲ ﺻﻔﺤﺔ ﺗﻢ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻴﻬﺎ ﻋﺒﺮ ‪ .HTTPS‬ﻓﻲ ﻫﺬﻩ ﺍﻟﺤﺎﻟﺔ‪ ،‬ﻳﺘﻀﻤﻦ‬
‫ﻓﺎﻳﺮﻓﻮﻛﺲﺭﺃﺱ "ﺍﻟﻤﺮﺟﻊ" ﺑﺸﺮﻁ ﺃﻥ ﻳﺘﻢ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﺍﻟﺮﺍﺑﻂ ﺍﻟﺨﺎﺭﺟﻲ ﻋﺒﺮ ‪ HTTPS‬ﺃﻳﻀﺎً‪ ،‬ﺣﺘﻰ ﻟﻮ‬
‫ﻛﺎﻥﻳﻨﺘﻤﻲ ﺇﻟﻰ ﻧﻄﺎﻕ ﻣﺨﺘﻠﻒ‪ .‬ﻭﺑﺎﻟﺘﺎﻟﻲ‪ ،‬ﺗﻜﻮﻥ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺍﻟﺤﺴﺎﺳﺔ ﺍﻟﻤﺪُﺭﺟﺔ ﻓﻲ ﻋﻨﺎﻭﻳﻦ ‪URL‬‬
‫ﻋﺮﺿﺔﻟﻠﺘﺴﺮﻳﺐ ﻓﻲ ﺳﺠﻼﺕ "ﺍﻟﻤﺮﺟﻊ" ﺣﺘﻰ ﻋﻨﺪ ﺍﺳﺘﺨﺪﺍﻡ ‪.SSL‬‬

‫ﺧﻄﻮﺍﺕﺍﻻﺧﺘﺮﺍﻕ‬

‫‪.1‬ﺣﺪﺩ ﺟﻤﻴﻊ ﻭﻇﺎﺉﻒ ﺍﻟﺘﻄﺒﻴﻖ‪ ،‬ﻭﺣﺪﺩ ﺃﻱ ﻭﻇﺎﺉﻒ ﺗﺴﺠﻴﻞ ﺃﻭ ﻣﺮﺍﻗﺒﺔ ﻳﻤُﻜﻦ ﻣﻦ ﺧﻼﻟﻬﺎ ﻋﺮﺽ‬
‫ﺭﻣﻮﺯﺍﻟﺠﻠﺴﺔ‪ .‬ﺗﺤﻘﻖ ﻣﻦ ﻫﻮﻳﺔ ﻣﻦ ﻳﻤﻜﻨﻪ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﻫﺬﻩ ﺍﻟﻮﻇﻴﻔﺔ ‪ -‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪،‬‬
‫ﺍﻟﻤﺴﺆﻭﻟﻮﻥ‪،‬ﺃﻭ ﺃﻱ ﻣﺴﺘﺨﺪﻡ ﻣﺼُﺎﺩﻕ ﻋﻠﻴﻪ‪ ،‬ﺃﻭ ﺃﻱ ﻣﺴﺘﺨﺪﻡ ﻣﺠﻬﻮﻝ‪ .‬ﺭﺍﺟﻊ ﺍﻟﻔﺼﻞ ‪4‬‬
‫ﻟﻼﻃﻼﻉﻋﻠﻰ ﺗﻘﻨﻴﺎﺕ ﺍﻛﺘﺸﺎﻑ ﺍﻟﻤﺤﺘﻮﻯ ﺍﻟﻤﺨﻔﻲ ﻏﻴﺮ ﺍﻟﻤﺮﺗﺒﻂ ﻣﺒﺎﺷﺮﺓ ًﺑﺎﻟﺘﻄﺒﻴﻖ ﺍﻟﺮﺉﻴﺴﻲ‪.‬‬

‫‪.2‬ﺣﺪﺩ ﺃﻱ ﺣﺎﻻﺕ ﺩﺍﺧﻞ ﺍﻟﺘﻄﺒﻴﻖ ﺗﻨُﻘﻞ ﻓﻴﻬﺎ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ ﻋﺒﺮ ﻋﻨﻮﺍﻥ ‪ .URL‬ﻗﺪ ﺗﻜﻮﻥ ﺍﻟﺮﻣﻮﺯ‬
‫ﻋﺎﺩﺓ ًﺃﻛﺜﺮ ﺃﻣﺎﻧﺎً‪ ،‬ﻭﻟﻜﻦ ﺍﻟﻤﻄﻮﺭﻳﻦ ﺍﺳﺘﺨﺪﻣﻮﺍ ﻋﻨﻮﺍﻥ ‪ URL‬ﻓﻲ ﺣﺎﻻﺕ ﻣﺤﺪﺩﺓ ﻟﻠﺘﻐﻠﺐ ﻋﻠﻰ‬
‫ﺻﻌﻮﺑﺎﺕﻣﻌﻴﻨﺔ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﻏﺎﻟﺒﺎً ﻣﺎ ﻳﻼُﺣﻆ ﻫﺬﺍ ﺍﻟﺴﻠﻮﻙ ﻋﻨﺪ ﺗﻔﺎﻋﻞ ﺗﻄﺒﻴﻖ ﻭﻳﺐ‬
‫ﻣﻊﻧﻈﺎﻡ ﺧﺎﺭﺟﻲ‪.‬‬

‫‪.٣‬ﺇﺫﺍ ﻛﺎﻧﺖ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ ﺗﺮُﺳﻞ ﻋﺒﺮ ﻋﻨﺎﻭﻳﻦ ‪ ،URL‬ﻓﺤﺎﻭﻝ ﺍﻟﻌﺜﻮﺭ ﻋﻠﻰ ﺃﻱ ﻭﻇﻴﻔﺔ ﺗﻄﺒﻴﻘﻴﺔ‬
‫ﺗﻤُﻜﻨّﻚﻣﻦ ﺇﺩﺭﺍﺝ ﺭﻭﺍﺑﻂ ﻋﺸﻮﺍﺉﻴﺔ ﻣﻦ ﺧﺎﺭﺝ ﺍﻟﻤﻮﻗﻊ ﻓﻲ ﺍﻟﺼﻔﺤﺎﺕ ﺍﻟﺘﻲ ﻳﺘﺼﻔﺤﻬﺎ‬
‫ﻣﺴﺘﺨﺪﻣﻮﻥﺁﺧﺮﻭﻥ‪ .‬ﻣﻦ ﺍﻷﻣﺜﻠﺔ ﻋﻠﻰ ﺫﻟﻚ ﻭﻇﺎﺉﻒ ﻣﺜﻞ ﻟﻮﺣﺔ ﺍﻟﺮﺳﺎﺉﻞ‪ ،‬ﻭﺭﺩﻭﺩ ﺍﻟﻔﻌﻞ ﻋﻠﻰ‬
‫ﺍﻟﻤﻮﻗﻊ‪،‬ﻭﺍﻷﺳﺉﻠﺔ ﻭﺍﻷﺟﻮﺑﺔ‪ ،‬ﻭﻣﺎ ﺇﻟﻰ ﺫﻟﻚ‪ .‬ﺇﺫﺍ ﻛﺎﻥ ﺍﻷﻣﺮ ﻛﺬﻟﻚ‪ ،‬ﻓﺄﺭﺳﻞ ﺍﻟﺮﻭﺍﺑﻂ ﺇﻟﻰ ﺧﺎﺩﻡ‬
‫ﻭﻳﺐﺗﺘﺤﻜﻢ ﻓﻴﻪ ﻭﺍﻧﺘﻈﺮ ﻟﺘﺮﻯ ﻣﺎ ﺇﺫﺍ ﻛﺎﻧﺖ ﺭﻣﻮﺯ ﺟﻠﺴﺔ ﺃﻱ ﻣﺴﺘﺨﺪﻡ ﻗﺪ ﻭﺻﻠﺖ ﺇﻟﻰ ﺳﺠﻼﺕ‬
‫ﺍﻟﻤﺤُﻴﻞ‪.‬‬
‫‪.٤‬ﻓﻲ ﺣﺎﻝ ﺍﻟﺘﻘﺎﻁ ﺃﻱ ﺭﻣﻮﺯ ﺟﻠﺴﺔ‪ ،‬ﺣﺎﻭﻝ ﺍﺧﺘﺮﺍﻕ ﺟﻠﺴﺎﺕ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺍﻟﺘﻄﺒﻴﻖ‬
‫ﻛﺎﻟﻤﻌﺘﺎﺩ‪،‬ﻣﻊ ﺍﺳﺘﺒﺪﺍﻝ ﺍﻟﺮﻣﺰ ﺍﻟﻤﻠُﺘﻘﻂ ﺑﺮﻣﺰﻙ ﺍﻟﺨﺎﺹ‪ .‬ﻳﻤﻜﻨﻚ ﺍﻟﻘﻴﺎﻡ ﺑﺬﻟﻚ ﻋﻦ ﻃﺮﻳﻖ‬
‫ﺍﻋﺘﺮﺍﺽﺍﻻﺳﺘﺠﺎﺑﺔ ﺍﻟﺘﺎﻟﻴﺔ ﻣﻦ ﺍﻟﺨﺎﺩﻡ ﻭﺇﺿﺎﻓﺔ ﺭﺃﺱ ‪ Set-Cookie‬ﺧﺎﺹ ﺑﻚ ﺑﻘﻴﻤﺔ ﻣﻠﻒ‬
‫ﺗﻌﺮﻳﻒﺍﻻﺭﺗﺒﺎﻁ ﺍﻟﻤﻠُﺘﻘﻂ‪ .‬ﻓﻲ ‪ ،Burp‬ﻳﻤﻜﻨﻚ ﺗﻄﺒﻴﻖ ﺗﻜﻮﻳﻦ ﻭﺍﺣﺪ ﻋﻠﻰ ﻣﺴﺘﻮﻯ ﺍﻟﻤﺠﻤﻮﻋﺔ‬
‫ﻳﻌُﻴﻦّﻣﻠﻒ ﺗﻌﺮﻳﻒ ﺍﺭﺗﺒﺎﻁ ﻣﺤﺪﺩﺍً ﻓﻲ ﺟﻤﻴﻊ ﺍﻟﻄﻠﺒﺎﺕ ﺍﻟﻤﻮُﺟﻬﺔ ﺇﻟﻰ ﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﻤﺴﺘﻬﺪﻑ‪ ،‬ﻣﻤﺎ‬
‫ﻳﺴُﻬﻞّﺍﻟﺘﺒﺪﻳﻞ ﺑﻴﻦ ﺳﻴﺎﻗﺎﺕ ﺍﻟﺠﻠﺴﺔ ﺍﻟﻤﺨﺘﻠﻔﺔ ﺃﺛﻨﺎء ﺍﻻﺧﺘﺒﺎﺭ‪.‬‬

‫‪.6‬ﺇﺫﺍ ﺗﻢ ﺍﻟﺘﻘﺎﻁ ﻋﺪﺩ ﻛﺒﻴﺮ ﻣﻦ ﺍﻟﺮﻣﻮﺯ‪ ،‬ﻭﺳﻤﺢ ﻟﻚ ﺍﺧﺘﻄﺎﻑ ﺍﻟﺠﻠﺴﺔ ﺑﺎﻟﻮﺻﻮﻝ ﺇﻟﻰ ﺑﻴﺎﻧﺎﺕ‬
‫ﺣﺴﺎﺳﺔﻣﺜﻞ ﺍﻟﺘﻔﺎﺻﻴﻞ ﺍﻟﺸﺨﺼﻴﺔ ﻭﻣﻌﻠﻮﻣﺎﺕ ﺍﻟﺪﻓﻊ‪،‬‬
‫ﺃﻭﻛﻠﻤﺎﺕ ﻣﺮﻭﺭ ﺍﻟﻤﺴﺘﺨﺪﻡ‪ ،‬ﻳﻤﻜﻨﻚ ﺍﺳﺘﺨﺪﺍﻡ ﺍﻟﺘﻘﻨﻴﺎﺕ ﺍﻵﻟﻴﺔ ﺍﻟﻤﻮﺿﺤﺔ ﻓﻲ ﺍﻟﻔﺼﻞ ‪14‬‬
‫ﻟﺠﻤﻊﻛﻞ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺍﻟﻤﻄﻠﻮﺑﺔ ﺍﻟﺘﻲ ﺗﻨﺘﻤﻲ ﺇﻟﻰ ﻣﺴﺘﺨﺪﻣﻲ ﺍﻟﺘﻄﺒﻴﻖ ﺍﻵﺧﺮﻳﻦ‪.‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬ ‫‪240‬‬

‫ﺟﺮﺑﻬﺎ!‬

‫‪http://mdsec.net/auth/379/‬‬

‫ﺗﻌﻴﻴﻦﻧﻘﺎﻁ ﺿﻌﻒ ﺍﻟﺮﻣﻮﺯ ﺇﻟﻰ ﺍﻟﺠﻠﺴﺎﺕ‬

‫ﺗﻨﺸﺄﺍﻟﻌﺪﻳﺪ ﻣﻦ ﺍﻟﺜﻐﺮﺍﺕ ﺍﻷﻣﻨﻴﺔ ﺍﻟﺸﺎﺉﻌﺔ ﻓﻲ ﺁﻟﻴﺎﺕ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ ﺑﺴﺒﺐ ﻧﻘﺎﻁ ﺍﻟﻀﻌﻒ ﻓﻲ‬
‫ﻛﻴﻔﻴﺔﻗﻴﺎﻡ ﺍﻟﺘﻄﺒﻴﻖ ﺑﺮﺑﻂ ﻋﻤﻠﻴﺔ ﺇﻧﺸﺎء ﻭﻣﻌﺎﻟﺠﺔ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ ﺑﺠﻠﺴﺎﺕ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺍﻟﻔﺮﺩﻳﻴﻦ‬
‫ﺃﻧﻔﺴﻬﻢ‪.‬‬
‫ﺃﺑﺴﻂﻧﻘﻄﺔ ﺿﻌﻒ ﻫﻲ ﺍﻟﺴﻤﺎﺡ ﺑﺘﻌﻴﻴﻦ ﺭﻣﻮﺯ ﺻﺎﻟﺤﺔ ﻣﺘﻌﺪﺩﺓ ﻓﻲ ﻭﻗﺖ ﻭﺍﺣﺪ ﻟﺤﺴﺎﺏ‬
‫ﺍﻟﻤﺴﺘﺨﺪﻡﻧﻔﺴﻪ‪ .‬ﻓﻲ ﻛﻞ ﺗﻄﺒﻴﻖ ﺗﻘﺮﻳﺒﺎً‪ ،‬ﻻ ﻳﻮﺟﺪ ﺳﺒﺐ ﻣﺸﺮﻭﻉ ﻟﺘﻨﺸﻴﻂ ﺃﻛﺜﺮ ﻣﻦ ﺟﻠﺴﺔ ﻭﺍﺣﺪﺓ‬
‫ﻷﻱﻣﺴﺘﺨﺪﻡ ﻓﻲ ﻭﻗﺖ ﻭﺍﺣﺪ‪ .‬ﺑﺎﻟﻄﺒﻊ‪ ،‬ﻣﻦ ﺍﻟﺸﺎﺉﻊ ﺃﻥ ﻳﺘﺮﻙ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺟﻠﺴﺔ ﻧﺸﻄﺔ ﻭﻳﺒﺪﺃ ﺟﻠﺴﺔ‬
‫ﺟﺪﻳﺪﺓ‪ -‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﻷﻧﻪ ﻳﻐﻠﻖ ﻧﺎﻓﺬﺓ ﻣﺘﺼﻔﺢ ﺃﻭ ﻳﻨﺘﻘﻞ ﺇﻟﻰ ﺟﻬﺎﺯ ﻛﻤﺒﻴﻮﺗﺮ ﻣﺨﺘﻠﻒ‪ .‬ﻭﻟﻜﻦ‬
‫ﺇﺫﺍﺑﺪﺍ ﺃﻥ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻳﺴﺘﺨﺪﻡ ﺟﻠﺴﺘﻴﻦ ﻣﺨﺘﻠﻔﺘﻴﻦ ﻓﻲ ﻭﻗﺖ ﻭﺍﺣﺪ‪ ،‬ﻓﻬﺬﺍ ﻳﺸﻴﺮ ﻋﺎﺩﺓ ًﺇﻟﻰ ﺣﺪﻭﺙ‬
‫ﺍﺧﺘﺮﺍﻕﺃﻣﻨﻲ‪ :‬ﺇﻣﺎ ﺃﻥ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻗﺪ ﻛﺸﻒ ﻋﻦ ﺑﻴﺎﻧﺎﺕ ﺍﻋﺘﻤﺎﺩﻩ ﻟﺠﻬﺔ ﺃﺧﺮﻯ‪ ،‬ﺃﻭ ﺃﻥ ﻣﻬﺎﺟﻤﺎً ﺣﺼﻞ‬
‫ﻋﻠﻰﺑﻴﺎﻧﺎﺕ ﺍﻋﺘﻤﺎﺩﻩ ﺑﻮﺳﻴﻠﺔ ﺃﺧﺮﻯ‪ .‬ﻓﻲ ﻛﻠﺘﺎ ﺍﻟﺤﺎﻟﺘﻴﻦ‪ ،‬ﻳﻌُﺪ ﺍﻟﺴﻤﺎﺡ ﺑﺎﻟﺠﻠﺴﺎﺕ ﺍﻟﻤﺘﺰﺍﻣﻨﺔ ﺃﻣﺮﺍً ﻏﻴﺮ‬
‫ﻣﺮﻏﻮﺏﻓﻴﻪ‪ ،‬ﻷﻧﻪ ﻳﺴﻤﺢ ﻟﻠﻤﺴﺘﺨﺪﻣﻴﻦ ﺑﺎﻻﺳﺘﻤﺮﺍﺭ ﻓﻲ ﻣﻤﺎﺭﺳﺎﺕ ﻏﻴﺮ ﻣﺮﻏﻮﺏ ﻓﻴﻬﺎ ﺩﻭﻥ ﺃﻱ ﺇﺯﻋﺎﺝ‬
‫ﻭﻷﻧﻪﻳﺴﻤﺢ ﻟﻠﻤﻬﺎﺟﻢ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺑﻴﺎﻧﺎﺕ ﺍﻻﻋﺘﻤﺎﺩ ﺍﻟﻤﻠﺘﻘﻄﺔ ﺩﻭﻥ ﺧﻄﺮ ﺍﻟﻜﺸﻒ‪.‬‬

‫ﻣﻦﻧﻘﺎﻁ ﺍﻟﻀﻌﻒ ﺫﺍﺕ ﺍﻟﺼﻠﺔ‪ ،‬ﻭﺇﻥ ﻛﺎﻧﺖ ﻭﺍﺿﺤﺔ‪ ،‬ﺍﺳﺘﺨﺪﺍﻡ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﻟﺮﻣﻮﺯ "ﺛﺎﺑﺘﺔ"‪ .‬ﺗﺒﺪﻭ‬
‫ﻫﺬﻩﺍﻟﺮﻣﻮﺯ ﻛﺮﻣﻮﺯ ﺟﻠﺴﺔ‪ ،‬ﻭﻗﺪ ﺗﺒﺪﻭ ﻟﻠﻮﻫﻠﺔ ﺍﻷﻭﻟﻰ ﻭﻛﺄﻧﻬﺎ ﺗﻌﻤﻞ ﻣﺜﻠﻬﺎ‪ ،‬ﻟﻜﻨﻬﺎ ﻓﻲ ﺍﻟﻮﺍﻗﻊ ﻟﻴﺴﺖ‬
‫ﻛﺬﻟﻚ‪.‬ﻓﻲ ﻫﺬﻩ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ‪ ،‬ﻳﺨُﺼﺺ ﻟﻜﻞ ﻣﺴﺘﺨﺪﻡ ﺭﻣﺰ‪ ،‬ﻭﻳﻌُﺎﺩ ﺇﺻﺪﺍﺭﻩ ﻟﻪ ﻓﻲ ﻛﻞ ﻣﺮﺓ ﻳﺴُﺠﻞ‬
‫ﻓﻴﻬﺎﺩﺧﻮﻟﻪ‪ .‬ﻳﻘﺒﻞ ﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﺮﻣﺰ ﺩﺍﺉﻤﺎً ﻋﻠﻰ ﺃﻧﻪ ﺻﺎﻟﺢ‪ ،‬ﺳﻮﺍء ًﺳﺠﻞ ﺩﺧﻮﻟﻪ ﻣﺆﺧﺮﺍً ﺃﻡ ﻻ‪ .‬ﺗﻨﻄﻮﻱ‬
‫ﺗﻄﺒﻴﻘﺎﺕﻛﻬﺬﻩ ﻋﻠﻰ ﺳﻮء ﻓﻬﻢ ﻟﻤﻔﻬﻮﻡ ﺍﻟﺠﻠﺴﺔ‪ ،‬ﻭﻓﻮﺍﺉﺪﻫﺎ ﻓﻲ ﺇﺩﺍﺭﺓ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﺍﻟﺘﻄﺒﻴﻖ‬
‫ﻭﺍﻟﺘﺤﻜﻢﻓﻴﻪ‪ .‬ﺃﺣﻴﺎﻧﺎً‪ ،‬ﺗﻌﻤﻞ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺑﻬﺬﻩ ﺍﻟﻄﺮﻳﻘﺔ ﻛﻮﺳﻴﻠﺔ ﻟﺘﻄﺒﻴﻖ ﻭﻇﻴﻔﺔ "ﺗﺬﻛﺮﻧﻲ" ﺳﻴﺉﺔ‬
‫ﺍﻟﺘﺼﻤﻴﻢ‪،‬ﻭﺑﺎﻟﺘﺎﻟﻲ ﻳﺨُﺰﻥ ﺍﻟﺮﻣﺰ ﺍﻟﺜﺎﺑﺖ ﻓﻲ ﻣﻠﻒ ﺗﻌﺮﻳﻒ ﺍﺭﺗﺒﺎﻁ ﺩﺍﺉﻢ )ﺍﻧﻈﺮ ﺍﻟﻔﺼﻞ ‪ .(6‬ﺃﺣﻴﺎﻧﺎً‬
‫ﺗﻜﻮﻥﺍﻟﺮﻣﻮﺯ ﻧﻔﺴﻬﺎ ﻋﺮﺿﺔ ﻟﻬﺠﻤﺎﺕ ﺍﻟﺘﻨﺒﺆ‪ ،‬ﻣﻤﺎ ﻳﺰﻳﺪ ﻣﻦ ﺧﻄﻮﺭﺓ ﻫﺬﻩ ﺍﻟﺜﻐﺮﺓ‪ .‬ﻓﺒﺪﻻً ﻣﻦ ﺍﺧﺘﺮﺍﻕ‬
‫ﺟﻠﺴﺎﺕﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺍﻟﻤﺴﺠﻠﻴﻦ ﺣﺎﻟﻴﺎً‪ ،‬ﻳﺨُﺘﺮﻕ ﺍﻟﻬﺠﻮﻡ ﺍﻟﻨﺎﺟﺢ‪ ،‬ﺑﺸﻜﻞ ﺩﺍﺉﻢ‪ ،‬ﺣﺴﺎﺑﺎﺕ ﺟﻤﻴﻊ‬
‫ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦﺍﻟﻤﺴﺠﻠﻴﻦ‪.‬‬

‫ﻳﻼُﺣﻆﺃﺣﻴﺎﻧﺎً ﺃﻳﻀﺎً ﺳﻠﻮﻛﻴﺎﺕ ﻏﺮﻳﺒﺔ ﺃﺧﺮﻯ ﻓﻲ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺗﻈُﻬﺮ ﺧﻠﻼً ﺟﻮﻫﺮﻳﺎً ﻓﻲ ﺍﻟﻌﻼﻗﺔ ﺑﻴﻦ‬
‫ﺍﻟﺮﻣﻮﺯﻭﺍﻟﺠﻠﺴﺎﺕ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﻋﻨﺪﻣﺎ ﻳﺒُﻨﻰ ﺭﻣﺰ ﺫﻭ ﻣﻌﻨﻰ ﺑﻨﺎء ًﻋﻠﻰ ﺍﺳﻢ ﻣﺴﺘﺨﺪﻡ ﻭﻣﻜﻮﻥّ‬
‫ﻋﺸﻮﺍﺉﻲ‪.‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﻟﻨﻨﻈﺮ ﺇﻟﻰ ﺍﻟﺮﻣﺰ‪:‬‬

‫=‪dXNlcj1kYWY7cjE9MTMwOTQxODEyMTM0NTkwMTI‬‬

‫ﺍﻟﺬﻱﻳﻔﻚ ﺗﺸﻔﻴﺮ ‪ Base64‬ﺇﻟﻰ‪:‬‬

‫ﺍﻟﻤﺴﺘﺨﺪﻡ=‪daf‬؛‪r1=13094181213459012‬‬
‫‪241‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬

‫ﺑﻌﺪﺗﺤﻠﻴﻞ ﻭﺍﺳﻊ ﺍﻟﻨﻄﺎﻕ ﻟـﺭ‪1‬ﻗﺪ ﻧﺴﺘﻨﺘﺞ ﺃﻧﻪ ﻻ ﻳﻤﻜﻦ ﺍﻟﺘﻨﺒﺆ ﺑﺬﻟﻚ ﺑﻨﺎء ًﻋﻠﻰ ﻋﻴﻨﺔ ﻣﻦ ﺍﻟﻘﻴﻢ‪ .‬ﻭﻣﻊ‬
‫ﺫﻟﻚ‪،‬ﺇﺫﺍ ﻛﺎﻥ ﻣﻨﻄﻖ ﻣﻌﺎﻟﺠﺔ ﺟﻠﺴﺔ ﺍﻟﺘﻄﺒﻴﻖ ﺧﺎﻃﺉﺎً‪ ،‬ﻓﻘﺪ ﻳﺤﺘﺎﺝ ﺍﻟﻤﻬﺎﺟﻢ ﺑﺒﺴﺎﻃﺔ ﺇﻟﻰ ﺇﺭﺳﺎﻝﺃﻱ‬
‫ﻗﻴﻤﺔﺻﺎﻟﺤﺔ ﻛـﺭ‪1‬ﻭﺃﻱﻗﻴﻤﺔ ﺻﺎﻟﺤﺔ ﻛـﻣﺴﺘﺨﺪﻡﻟﻠﻮﺻﻮﻝ ﺇﻟﻰ ﺟﻠﺴﺔ ﺿﻤﻦ ﺳﻴﺎﻕ ﺃﻣﺎﻥ ﺍﻟﻤﺴﺘﺨﺪﻡ‬
‫ﺍﻟﻤﺤﺪﺩ‪.‬ﻫﺬﻩ ﺛﻐﺮﺓ ﺃﻣﻨﻴﺔ ﻓﻲ ﺍﻟﺘﺤﻜﻢ ﺑﺎﻟﻮﺻﻮﻝ‪ ،‬ﻷﻥ ﻗﺮﺍﺭﺍﺕ ﺍﻟﻮﺻﻮﻝ ﺗﺘُﺨﺬ ﺑﻨﺎء ًﻋﻠﻰ ﺑﻴﺎﻧﺎﺕ ﻳﻘﺪﻣﻬﺎ‬
‫ﺍﻟﻤﺴﺘﺨﺪﻡﺧﺎﺭﺝ ﺍﻟﺠﻠﺴﺔ )ﺍﻧﻈﺮ ﺍﻟﻔﺼﻞ ‪ .(8‬ﺗﻨﺸﺄ ﻫﺬﻩ ﺍﻟﺜﻐﺮﺓ ﻷﻥ ﺍﻟﺘﻄﺒﻴﻖ ﻳﺴﺘﺨﺪﻡ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ‬
‫ﺑﻔﻌﺎﻟﻴﺔﻟﻺﺷﺎﺭﺓ ﺇﻟﻰ ﺃﻥ ﻣﻘﺪﻡ ﺍﻟﻄﻠﺐ ﻗﺪ ﺃﻧﺸﺄﺑﻌﺾ ﺟﻠﺴﺔ ﺻﺎﻟﺤﺔ ﻣﻊ ﺍﻟﺘﻄﺒﻴﻖ‪ .‬ﻣﻊ ﺫﻟﻚ‪ ،‬ﻓﺈﻥ‬
‫ﺳﻴﺎﻕﺍﻟﻤﺴﺘﺨﺪﻡ ﺍﻟﺬﻱ ﺗﻌُﺎﻟﺞَ ﻓﻴﻪ ﺍﻟﺠﻠﺴﺔ ﻟﻴﺲ ﺟﺰءﺍً ﻻ ﻳﺘﺠﺰﺃ ﻣﻦ ﺍﻟﺠﻠﺴﺔ ﻧﻔﺴﻬﺎ‪ ،‬ﺑﻞ ﻳﺤُﺪﺩَّ ﻟﻜﻞ‬
‫ﻃﻠﺐﻣﻦ ﺧﻼﻝ ﻭﺳﻴﻠﺔ ﺃﺧﺮﻯ‪ .‬ﻓﻲ ﻫﺬﻩ ﺍﻟﺤﺎﻟﺔ‪ ،‬ﻳﻤﻜﻦ ﻟﻤﻘُﺪﻡِّ ﺍﻟﻄﻠﺐ ﺍﻟﺘﺤﻜﻢ ﻓﻲ ﻫﺬﻩ ﺍﻟﻮﺳﻴﻠﺔ‬
‫ﻣﺒﺎﺷﺮﺓ‪ً.‬‬

‫ﺧﻄﻮﺍﺕﺍﻻﺧﺘﺮﺍﻕ‬

‫‪.1‬ﺳﺠﻞّ ﺩﺧﻮﻟﻚ ﺇﻟﻰ ﺍﻟﺘﻄﺒﻴﻖ ﻣﺮﺗﻴﻦ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺣﺴﺎﺏ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻧﻔﺴﻪ‪ ،‬ﺇﻣﺎ ﻣﻦ ﻣﺘﺼﻔﺢ‬
‫ﻣﺨﺘﻠﻒﺃﻭ ﻣﻦ ﺟﻬﺎﺯﻱ ﻛﻤﺒﻴﻮﺗﺮ ﻣﺨﺘﻠﻔﻴﻦ‪ .‬ﺗﺄﻛﺪ ﻣﻦ ﺃﻥ ﺍﻟﺠﻠﺴﺘﻴﻦ ﻻ ﺗﺰﺍﻻﻥ ﻧﺸﻄﺘﻴﻦ ﻓﻲ ﺁﻥ‬
‫ﻭﺍﺣﺪ‪.‬ﻓﻲ ﻫﺬﻩ ﺍﻟﺤﺎﻟﺔ‪ ،‬ﻳﺪﻋﻢ ﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﺠﻠﺴﺎﺕ ﺍﻟﻤﺘﺰﺍﻣﻨﺔ‪ ،‬ﻣﻤﺎ ﻳﻤُﻜﻦّ ﺍﻟﻤﻬﺎﺟﻢ ﺍﻟﺬﻱ ﺍﺧﺘﺮﻕ‬
‫ﺑﻴﺎﻧﺎﺕﺍﻋﺘﻤﺎﺩ ﻣﺴﺘﺨﺪﻡ ﺁﺧﺮ ﻣﻦ ﺍﺳﺘﺨﺪﺍﻣﻬﺎ ﺩﻭﻥ ﺧﻄﺮ ﺍﻟﻜﺸﻒ‪.‬‬

‫‪.2‬ﺳﺠﻞّ ﺍﻟﺪﺧﻮﻝ ﻭﺍﻟﺨﺮﻭﺝ ﻋﺪﺓ ﻣﺮﺍﺕ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺣﺴﺎﺏ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻧﻔﺴﻪ‪ ،‬ﺳﻮﺍء ًﻣﻦ‬
‫ﻣﺘﺼﻔﺤﺎﺕﻣﺨﺘﻠﻔﺔ ﺃﻭ ﺃﺟﻬﺰﺓ ﻛﻤﺒﻴﻮﺗﺮ ﻣﺨﺘﻠﻔﺔ‪ .‬ﺣﺪﺩّ ﻣﺎ ﺇﺫﺍ ﻛﺎﻥ ﻳﺘﻢ ﺇﺻﺪﺍﺭ ﺭﻣﺰ ﺟﻠﺴﺔ ﺟﺪﻳﺪ‬
‫ﻓﻲﻛﻞ ﻣﺮﺓ‪ ،‬ﺃﻭ ﻣﺎ ﺇﺫﺍ ﻛﺎﻥ ﻳﺘﻢ ﺇﺻﺪﺍﺭ ﺍﻟﺮﻣﺰ ﻧﻔﺴﻪ ﻓﻲ ﻛﻞ ﻣﺮﺓ ﺗﺴُﺠﻞّ ﻓﻴﻬﺎ ﺍﻟﺪﺧﻮﻝ‪ .‬ﻓﻲ ﻫﺬﻩ‬
‫ﺍﻟﺤﺎﻟﺔ‪،‬ﻻ ﻳﺴﺘﺨﺪﻡ ﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﺠﻠﺴﺎﺕ ﺑﺸﻜﻞ ﺻﺤﻴﺢ‪.‬‬

‫‪.٣‬ﺇﺫﺍ ﺑﺪﺕ ﺍﻟﺮﻣﻮﺯ ﺗﺤﺘﻮﻱ ﻋﻠﻰ ﺃﻱ ﺑﻨﻴﺔ ﺃﻭ ﻣﻌﻨﻰ‪ ،‬ﻓﺤﺎﻭﻝ ﻓﺼﻞ ﺍﻟﻤﻜﻮﻧﺎﺕ ﺍﻟﺘﻲ ﻗﺪ ﺗﻌُﺮﻑّ‬
‫ﺍﻟﻤﺴﺘﺨﺪﻡﻋﻦ ﺗﻠﻚ ﺍﻟﺘﻲ ﺗﺒﺪﻭ ﻏﺎﻣﻀﺔ‪ .‬ﺣﺎﻭﻝ ﺗﻌﺪﻳﻞ ﺃﻱ ﻣﻜﻮﻧﺎﺕ ﻣﺘﻌﻠﻘﺔ ﺑﺎﻟﻤﺴﺘﺨﺪﻡ ﻓﻲ‬
‫ﺍﻟﺮﻣﺰﺑﺤﻴﺚ ﺗﺸﻴﺮ ﺇﻟﻰ ﻣﺴﺘﺨﺪﻣﻴﻦ ﺁﺧﺮﻳﻦ ﻣﻌﺮﻭﻓﻴﻦ ﻟﻠﺘﻄﺒﻴﻖ‪ ،‬ﻭﺗﺤﻘﻖ ﻣﻤﺎ ﺇﺫﺍ ﻛﺎﻥ ﺍﻟﺮﻣﺰ‬
‫ﺍﻟﻨﺎﺗﺞﻣﻘﺒﻮﻻ ًﻣﻦ ﻗﺒِﻞ ﺍﻟﺘﻄﺒﻴﻖ ﻭﻳﻤُﻜﻨّﻚ ﻣﻦ ﺍﻧﺘﺤﺎﻝ ﺷﺨﺼﻴﺔ ﺫﻟﻚ ﺍﻟﻤﺴﺘﺨﺪﻡ‪.‬‬

‫ﺟﺮﺑﻬﺎ!‬

‫‪/382/ http://mdsec.net/auth/385/‬‬
‫‪http://mdsec.net/auth‬‬

‫ﺇﻧﻬﺎءﺍﻟﺠﻠﺴﺔ ﺍﻟﻤﻌﺮﺿﺔ ﻟﻠﺨﻄﺮ‬

‫ﺇﻧﻬﺎءﺍﻟﺠﻠﺴﺎﺕ ﺑﺸﻜﻞ ﺻﺤﻴﺢ ﻣﻬﻢ ﻟﺴﺒﺒﻴﻦ‪ .‬ﺃﻭﻻ‪ ً،‬ﻳﻘُﻠﻞ ﺗﻘﺼﻴﺮ ﻣﺪﺓ ﺍﻟﺠﻠﺴﺔ ﻗﺪﺭ ﺍﻹﻣﻜﺎﻥ ﻣﻦ‬
‫ﻓﺮﺻﺔﺣﺼﻮﻝ ﺍﻟﻤﻬﺎﺟﻢ ﻋﻠﻰ ﺭﻣﺰ ﺟﻠﺴﺔ ﺻﺎﻟﺢ ﺃﻭ ﺗﺨﻤﻴﻨﻪ ﺃﻭ ﺇﺳﺎءﺓ ﺍﺳﺘﺨﺪﺍﻣﻪ‪.‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬ ‫‪242‬‬

‫ﺛﺎﻧﻴﺎً‪،‬ﻳﺘُﻴﺢ ﻟﻠﻤﺴﺘﺨﺪﻣﻴﻦ ﻭﺳﻴﻠﺔ ًﻹﺑﻄﺎﻝ ﺟﻠﺴﺔ ﺣﺎﻟﻴﺔ ﻋﻨﺪ ﻋﺪﻡ ﺍﻟﺤﺎﺟﺔ ﺇﻟﻴﻬﺎ‪ .‬ﻫﺬﺍ ﻳﻤُﻜﻨّﻬﻢ ﻣﻦ‬
‫ﺗﻘﻠﻴﻞﻫﺬﻩ ﺍﻟﻔﺘﺮﺓ ﺍﻟﺰﻣﻨﻴﺔ ﺑﺸﻜﻞ ﺃﻛﺒﺮ‪ ،‬ﻭﺗﺤﻤﻞّ ﻣﺴﺆﻭﻟﻴﺔ ﺗﺄﻣﻴﻦ ﺟﻠﺴﺎﺗﻬﻢ ﻓﻲ ﺑﻴﺉﺔ ﺣﻮﺳﺒﺔ‬
‫ﻣﺸﺘﺮﻛﺔ‪.‬ﺗﻜﻤﻦ ﻧﻘﺎﻁ ﺍﻟﻀﻌﻒ ﺍﻟﺮﺉﻴﺴﻴﺔ ﻓﻲ ﻭﻇﺎﺉﻒ ﺇﻧﻬﺎء ﺍﻟﺠﻠﺴﺔ ﻓﻲ ﻋﺪﻡ ﺗﺤﻘﻴﻖ ﻫﺬﻳﻦ‬
‫ﺍﻟﻬﺪﻓﻴﻦﺍﻟﺮﺉﻴﺴﻴﻴﻦ‪.‬‬

‫ﺑﻌﺾﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﻻ ﺗﻠُﺰﻡ ﺑﺈﻧﻬﺎء ﺻﻼﺣﻴﺔ ﺍﻟﺠﻠﺴﺔ‪ .‬ﺑﻤﺠﺮﺩ ﺇﻧﺸﺎﺉﻬﺎ‪ ،‬ﻗﺪ ﺗﺒﻘﻰ ﺍﻟﺠﻠﺴﺔ ﺻﺎﻟﺤﺔ‬
‫ﻟﻌﺪﺓﺃﻳﺎﻡ ﺑﻌﺪ ﺍﺳﺘﻼﻡ ﺁﺧﺮ ﻃﻠﺐ‪ ،‬ﻗﺒﻞ ﺃﻥ ﻳﻨُﻬﻴﻬﺎ ﺍﻟﺨﺎﺩﻡ ﻓﻲ ﺍﻟﻨﻬﺎﻳﺔ‪ .‬ﺇﺫﺍ ﻛﺎﻧﺖ ﺍﻟﺮﻣﻮﺯ ﻋﺮﺿﺔ ﻟﺨﻠﻞ‬
‫ﺗﺴﻠﺴﻠﻲﻳﺼﻌﺐ ﺍﺳﺘﻐﻼﻟﻪ )ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ 100,000 ،‬ﺗﺨﻤﻴﻦ ﻟﻜﻞ ﺭﻣﺰ ﺻﺎﻟﺢ ﻣﺤُﺪﺩ(‪ ،‬ﻓﻘﺪ‬
‫ﻳﻈﻞﺍﻟﻤﻬﺎﺟﻢ ﻗﺎﺩﺭﺍً ﻋﻠﻰ ﺍﻟﺤﺼﻮﻝ ﻋﻠﻰ ﺭﻣﻮﺯ ﻛﻞ ﻣﺴﺘﺨﺪﻡ ﺩﺧﻞ ﺇﻟﻰ ﺍﻟﺘﻄﺒﻴﻖ ﻣﺆﺧﺮﺍً‪.‬‬

‫ﺑﻌﺾﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﻻ ﺗﻮﻓﺮ ﻭﻇﻴﻔﺔ ﺗﺴﺠﻴﻞ ﺍﻟﺨﺮﻭﺝ ﺍﻟﻔﻌﺎﻟﺔ‪:‬‬

‫ﻓﻲﺑﻌﺾ ﺍﻟﺤﺎﻻﺕ‪ ،‬ﻻ ﺗﻄُﺒﻖّ ﻭﻇﻴﻔﺔ ﺗﺴﺠﻴﻞ ﺍﻟﺨﺮﻭﺝ‪ .‬ﻻ ﻳﻤﻠﻚ ﺍﻟﻤﺴﺘﺨﺪﻣﻮﻥ ﺃﻱ ﻭﺳﻴﻠﺔ‬ ‫‪-‬‬

‫ﻹﺟﺒﺎﺭﺍﻟﺘﻄﺒﻴﻖ ﻋﻠﻰ ﺇﻟﻐﺎء ﺟﻠﺴﺘﻬﻢ‪.‬‬

‫ﻓﻲﺑﻌﺾ ﺍﻟﺤﺎﻻﺕ‪ ،‬ﻻ ﺗﺆﺩﻱ ﻭﻇﻴﻔﺔ ﺗﺴﺠﻴﻞ ﺍﻟﺨﺮﻭﺝ ﻓﻌﻠﻴﺎً ﺇﻟﻰ ﺇﺑﻄﺎﻝ ﺍﻟﺨﺎﺩﻡ ﻟﻠﺠﻠﺴﺔ‪ .‬ﻳﻘﻮﻡ‬ ‫‪-‬‬

‫ﺍﻟﺨﺎﺩﻡﺑﺈﺯﺍﻟﺔ ﺍﻟﺮﻣﺰ ﻣﻦ ﻣﺘﺼﻔﺢ ﺍﻟﻤﺴﺘﺨﺪﻡ )ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﻋﻦ ﻃﺮﻳﻖ ﺇﺻﺪﺍﺭ ﺃﻣﺮ‬
‫ﻣﺠﻤﻮﻋﺔﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁﻭﻣﻊ ﺫﻟﻚ‪ ،‬ﺇﺫﺍ ﺍﺳﺘﻤﺮ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻓﻲ ﺇﺭﺳﺎﻝ ﺍﻟﺮﻣﺰ‪ ،‬ﻓﺴﻴﻈﻞ‬
‫ﺍﻟﺨﺎﺩﻡﻳﻘﺒﻠﻪ‪.‬‬

‫ﻓﻲﺃﺳﻮﺃ ﺍﻟﺤﺎﻻﺕ‪ ،‬ﻋﻨﺪﻣﺎ ﻳﻨﻘﺮ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻋﻠﻰ "ﺗﺴﺠﻴﻞ ﺍﻟﺨﺮﻭﺝ"‪ ،‬ﻻ ﻳﺒُﻠﻎّ ﺍﻟﺨﺎﺩﻡ ﺑﺬﻟﻚ‪ ،‬ﻓﻼ‬ ‫‪-‬‬

‫ﻳﻘﻮﻡﺑﺄﻱ ﺇﺟﺮﺍء‪ .‬ﺑﻞ ﻳﻨُﻔﺬّ ﺑﺮﻧﺎﻣﺞ ﻧﺼﻲ ﻣﻦ ﺟﻬﺔ ﺍﻟﻌﻤﻴﻞ ﻳﻠُﻐﻲ ﻣﻠﻒ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﺍﻟﺨﺎﺹ‬
‫ﺑﺎﻟﻤﺴﺘﺨﺪﻡ‪،‬ﻣﺎ ﻳﻌﻨﻲ ﺃﻥ ﺍﻟﻄﻠﺒﺎﺕ ﺍﻟﻼﺣﻘﺔ ﺗﻌُﻴﺪﻩ ﺇﻟﻰ ﺻﻔﺤﺔ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ‪ .‬ﻳﻤﻜﻦ‬
‫ﻟﻠﻤﻬﺎﺟﻢﺍﻟﺬﻱ ﻳﺤﺼﻞ ﻋﻠﻰ ﻣﻠﻒ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﻫﺬﺍ ﺍﺳﺘﺨﺪﺍﻡ ﺍﻟﺠﻠﺴﺔ ﻛﻤﺎ ﻟﻮ ﺃﻥ‬
‫ﺍﻟﻤﺴﺘﺨﺪﻡﻟﻢ ﻳﺴُﺠﻞّ ﺧﺮﻭﺟﻪ ﺃﺑﺪﺍً‪.‬‬
‫ﺑﻌﺾﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﻟﺘﻲ ﻻ ﺗﺴﺘﺨﺪﻡ ﺍﻟﻤﺼﺎﺩﻗﺔ ﻻ ﺗﺰﺍﻝ ﺗﺤﺘﻮﻱ ﻋﻠﻰ ﻭﻇﺎﺉﻒ ﺗﻤُﻜﻦّ‬
‫ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦﻣﻦ ﺟﻤﻊ ﺑﻴﺎﻧﺎﺕ ﺣﺴﺎﺳﺔ ﺿﻤﻦ ﺟﻠﺴﺎﺗﻬﻢ )ﻣﺜﻞ ﺗﻄﺒﻴﻖ ﺍﻟﺘﺴﻮﻕ(‪ .‬ﻭﻣﻊ ﺫﻟﻚ‪ ،‬ﻋﺎﺩﺓ ًﻻ‬
‫ﺗﻮُﻓﺮّﻫﺬﻩ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﻣﺎ ﻳﻌُﺎﺩﻝ ﻭﻇﻴﻔﺔ ﺗﺴﺠﻴﻞ ﺍﻟﺨﺮﻭﺝ ﻟﺘﻤﻜﻴﻦ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﻣﻦ ﺇﻧﻬﺎء ﺟﻠﺴﺎﺗﻬﻢ‪.‬‬

‫ﺧﻄﻮﺍﺕﺍﻻﺧﺘﺮﺍﻕ‬

‫‪.1‬ﻻ ﺗﻘﻊ ﻓﻲ ﻓﺦ ﻓﺤﺺ ﺍﻹﺟﺮﺍءﺍﺕ ﺍﻟﺘﻲ ﻳﻘﻮﻡ ﺑﻬﺎ ﺍﻟﺘﻄﺒﻴﻖ ﻋﻠﻰ ﺭﻣﺰ ﺟﺎﻧﺐ ﺍﻟﻌﻤﻴﻞ )ﻣﺜﻞ ﺇﺑﻄﺎﻝ‬
‫ﻣﻠﻔﺎﺕﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﻋﺒﺮ ﺭﻣﺰ ﺟﺪﻳﺪ( ﻣﺠﻤﻮﻋﺔ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ)ﺗﻌﻠﻴﻤﺎﺕ‪ ،‬ﺃﻭ ﻧﺺ‬
‫ﺑﺮﻣﺠﻲﻣﻦ ﺟﺎﻧﺐ ﺍﻟﻌﻤﻴﻞ‪ ،‬ﺃﻭ ﺳﻤﺔ ﻭﻗﺖ ﺍﻧﺘﻬﺎء ﺍﻟﺼﻼﺣﻴﺔ(‪ .‬ﻓﻴﻤﺎ ﻳﺘﻌﻠﻖ ﺑﺈﻧﻬﺎء ﺍﻟﺠﻠﺴﺔ‪ ،‬ﻻ‬
‫ﻳﻌﺘﻤﺪﺍﻷﻣﺮ ﻛﺜﻴﺮﺍً ﻋﻠﻰ ﻣﺎ ﻳﺤﺪﺙ ﻟﻠﺮﻣﺰ ﺩﺍﺧﻞ ﻣﺘﺼﻔﺢ ﺍﻟﻌﻤﻴﻞ‪ .‬ﺑﺪﻻ ًﻣﻦ ﺫﻟﻚ‪ ،‬ﺗﺤﻘﻖ ﻣﻤﺎ ﺇﺫﺍ‬
‫ﻛﺎﻥﺍﻧﺘﻬﺎء ﺻﻼﺣﻴﺔ ﺍﻟﺠﻠﺴﺔ ﻣﻄُﺒﻘّﺎً ﻋﻠﻰ ﺟﺎﻧﺐ ﺍﻟﺨﺎﺩﻡ‪:‬‬

‫ﺃ‪.‬ﻗﻢ ﺑﺘﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﺇﻟﻰ ﺍﻟﺘﻄﺒﻴﻖ ﻟﻠﺤﺼﻮﻝ ﻋﻠﻰ ﺭﻣﺰ ﺟﻠﺴﺔ ﺻﺎﻟﺢ‪.‬‬
‫ﺏ‪.‬ﺍﻧﺘﻈﺮ ﻓﺘﺮﺓ ًﺩﻭﻥ ﺍﺳﺘﺨﺪﺍﻡ ﻫﺬﺍ ﺍﻟﺮﻣﺰ‪ ،‬ﺛﻢ ﻗﺪﻡّ ﻃﻠﺒﺎً ﻟﻠﺤﺼﻮﻝ ﻋﻠﻰ ﺻﻔﺤﺔ ﻣﺤﻤﻴﺔ )ﻣﺜﻞ "‬
‫ﺑﻴﺎﻧﺎﺗﻲ"( ﺑﺎﺳﺘﺨﺪﺍﻡ ﺍﻟﺮﻣﺰ‪.‬‬
‫‪243‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬

‫ﺝ‪.‬ﺇﺫﺍ ﺗﻢ ﻋﺮﺽ ﺍﻟﺼﻔﺤﺔ ﺑﺸﻜﻞ ﻃﺒﻴﻌﻲ‪ ،‬ﻓﺈﻥ ﺍﻟﺮﻣﺰ ﻻ ﻳﺰﺍﻝ ﻧﺸﻄﺎً‪.‬‬

‫ﺩ‪.‬ﺍﺳﺘﺨﺪﻡ ﺃﺳﻠﻮﺏ ﺍﻟﺘﺠﺮﺑﺔ ﻭﺍﻟﺨﻄﺄ ﻟﺘﺤﺪﻳﺪ ﻣﺪﺓ ﺍﻧﺘﻬﺎء ﺻﻼﺣﻴﺔ ﺃﻱ ﺟﻠﺴﺔ‪ ،‬ﺃﻭ ﻣﺎ ﺇﺫﺍ ﻛﺎﻥ‬
‫ﺍﻟﺮﻣﺰﻻ ﻳﺰﺍﻝ ﺻﺎﻟﺤﺎً ﻟﻼﺳﺘﺨﺪﺍﻡ ﺑﻌﺪ ﺃﻳﺎﻡ ﻣﻦ ﺁﺧﺮ ﻃﻠﺐ‪ .‬ﻳﻤﻜﻦ ﺗﻬﻴﺉﺔ ‪Burp Intruder‬‬
‫ﻟﺰﻳﺎﺩﺓﺍﻟﻔﺎﺻﻞ ﺍﻟﺰﻣﻨﻲ ﺑﻴﻦ ﺍﻟﻄﻠﺒﺎﺕ ﺍﻟﻤﺘﺘﺎﻟﻴﺔ ﻷﺗﻤﺘﺔ ﻫﺬﻩ ﺍﻟﻤﻬﻤﺔ‪.‬‬

‫‪.٢‬ﺗﺄﻛﺪ ﻣﻦ ﻭﺟﻮﺩ ﺧﺎﺻﻴﺔ ﺗﺴﺠﻴﻞ ﺍﻟﺨﺮﻭﺝ ﻭﺇﺗﺎﺣﺘﻬﺎ ﻟﻠﻤﺴﺘﺨﺪﻣﻴﻦ ﺑﺸﻜﻞ ﻭﺍﺿﺢ‪ .‬ﺇﺫﺍ ﻟﻢ ﺗﻜﻦ‬
‫ﻛﺬﻟﻚ‪،‬ﻓﺴﻴﻜﻮﻥ ﺍﻟﻤﺴﺘﺨﺪﻣﻮﻥ ﺃﻛﺜﺮ ﻋﺮﺿﺔ ﻟﻠﺨﻄﺮ‪ ،‬ﻟﻌﺪﻡ ﻗﺪﺭﺗﻬﻢ ﻋﻠﻰ ﺟﻌﻞ ﺍﻟﺘﻄﺒﻴﻖ ﻳﺒﻄﻞ‬
‫ﺟﻠﺴﺘﻬﻢ‪.‬‬
‫‪.٣‬ﻋﻨﺪ ﺗﻮﻓﺮ ﺧﺎﺻﻴﺔ ﺗﺴﺠﻴﻞ ﺍﻟﺨﺮﻭﺝ‪ ،‬ﺍﺧﺘﺒﺮ ﻓﻌﺎﻟﻴﺘﻬﺎ‪ .‬ﺑﻌﺪ ﺗﺴﺠﻴﻞ ﺍﻟﺨﺮﻭﺝ‪ ،‬ﺣﺎﻭﻝ ﺇﻋﺎﺩﺓ ﺍﺳﺘﺨﺪﺍﻡ‬
‫ﺍﻟﺮﻣﺰﺍﻟﻘﺪﻳﻢ ﻭﺗﺄﻛﺪ ﻣﻦ ﺻﻼﺣﻴﺘﻪ‪ .‬ﻓﻲ ﻫﺬﻩ ﺍﻟﺤﺎﻟﺔ‪ ،‬ﺳﻴﻈﻞ ﺍﻟﻤﺴﺘﺨﺪﻣﻮﻥ ﻋﺮﺿﺔ ﻟﻬﺠﻤﺎﺕ‬
‫ﺍﺧﺘﻄﺎﻑﺍﻟﺠﻠﺴﺎﺕ ﺣﺘﻰ ﺑﻌﺪ ﺗﺴﺠﻴﻞ ﺧﺮﻭﺟﻬﻢ‪ .‬ﻳﻤﻜﻨﻚ ﺍﺳﺘﺨﺪﺍﻡ ‪ Burp Suite‬ﻻﺧﺘﺒﺎﺭ ﺫﻟﻚ‪،‬‬
‫ﺑﺎﺧﺘﻴﺎﺭﻃﻠﺐ ﺣﺪﻳﺚ ﻣﺮﺗﺒﻂ ﺑﺎﻟﺠﻠﺴﺔ ﻣﻦ ﺳﺠﻞ ﺍﻟﻮﻛﻴﻞ ﻭﺇﺭﺳﺎﻟﻪ ﺇﻟﻰ ‪Burp Repeater‬‬
‫ﻹﻋﺎﺩﺓﺇﺻﺪﺍﺭﻩ ﺑﻌﺪ ﺗﺴﺠﻴﻞ ﺧﺮﻭﺟﻚ ﻣﻦ ﺍﻟﺘﻄﺒﻴﻖ‪.‬‬

‫ﺟﺮﺑﻬﺎ!‬

‫‪/452/ http://mdsec.net/auth/457/‬‬
‫‪/auth/447/ http://mdsec.net/auth‬‬
‫‪/auth/439/ http://mdsec.net‬‬
‫‪/auth/423/ http://mdsec.net‬‬
‫‪http://mdsec.net‬‬

‫ﺗﻌﺮﺽﺍﻟﻌﻤﻴﻞ ﻻﺧﺘﻄﺎﻑ ﺍﻟﺮﻣﺰ ﺍﻟﻤﻤﻴﺰ‬

‫ﻳﻤﻜﻦﻟﻠﻤﻬﺎﺟﻢ ﺍﺳﺘﻬﺪﺍﻑ ﻣﺴﺘﺨﺪﻣﻴﻦ ﺁﺧﺮﻳﻦ ﻟﻠﺘﻄﺒﻴﻖ ﻓﻲ ﻣﺤﺎﻭﻟﺔ ﻻﻟﺘﻘﺎﻁ ﺭﻣﺰ ﺟﻠﺴﺔ ﺍﻟﻀﺤﻴﺔ ﺃﻭ‬
‫ﺇﺳﺎءﺓﺍﺳﺘﺨﺪﺍﻣﻪ ﺑﻌﺪﺓ ﻃﺮﻕ‪:‬‬
‫ﻣﻦﺍﻟﻮﺍﺿﺢ ﺃﻥ ﻫﺠﻤﺎﺕ ﺍﻟﺒﺮﻣﺠﺔ ﺍﻟﻨﺼﻴﺔ ﻋﺒﺮ ﺍﻟﻤﻮﺍﻗﻊ ﺍﻹﻟﻜﺘﺮﻭﻧﻴﺔ ﺗﺘﻄﻠﺐ ﺍﺳﺘﻌﻼﻣﺎً ﻣﻦ‬ ‫‪-‬‬

‫ﻣﻠﻔﺎﺕﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﺍﻟﺨﺎﺻﺔ ﺑﺎﻟﻤﺴﺘﺨﺪﻡ ﻟﻠﺤﺼﻮﻝ ﻋﻠﻰ ﺭﻣﺰ ﺟﻠﺴﺘﻪ‪ ،‬ﻭﺍﻟﺬﻱ ﻳﻤﻜﻦ ﺑﻌﺪ‬
‫ﺫﻟﻚﺇﺭﺳﺎﻟﻪ ﺇﻟﻰ ﺧﺎﺩﻡ ﻋﺸﻮﺍﺉﻲ ﻳﺘﺤﻜﻢ ﻓﻴﻪ ﺍﻟﻤﻬﺎﺟﻢ‪ .‬ﺟﻤﻴﻊ ﺍﻟﺘﺒﺎﺩﻳﻞ ﺍﻟﻤﺨﺘﻠﻔﺔ ﻟﻬﺬﺍ ﺍﻟﻬﺠﻮﻡ‬
‫ﻣﻮﺻﻮﻓﺔﺑﺎﻟﺘﻔﺼﻴﻞ ﻓﻲ ﺍﻟﻔﺼﻞ ﺍﻟﺜﺎﻧﻲ ﻋﺸﺮ‪.‬‬
‫ﻳﻤﻜﻦﺍﺳﺘﺨﺪﺍﻡ ﻫﺠﻤﺎﺕ ﺃﺧﺮﻯ ﻣﺘﻨﻮﻋﺔ ﺿﺪ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﻻﺧﺘﺮﺍﻕ ﺟﻠﺴﺎﺗﻬﻢ ﺑﻄﺮﻕ‬ ‫‪-‬‬

‫ﻣﺨﺘﻠﻔﺔ‪.‬ﻓﻔﻲ ﺛﻐﺮﺍﺕ ﺗﺜﺒﻴﺖ ﺍﻟﺠﻠﺴﺔ‪ ،‬ﻳﺮُﺳﻞ ﺍﻟﻤﻬﺎﺟﻢ ﺭﻣﺰ ﺟﻠﺴﺔ ﻣﻌﺮﻭﻓﺎً ﻟﻠﻤﺴﺘﺨﺪﻡ‪،‬‬
‫ﻭﻳﻨﺘﻈﺮﺗﺴﺠﻴﻞ ﺩﺧﻮﻟﻪ‪ ،‬ﺛﻢ ﻳﺨﺘﺮﻕ ﺟﻠﺴﺘﻪ‪ .‬ﺃﻣﺎ ﻓﻲ ﻫﺠﻤﺎﺕ ﺗﺰﻭﻳﺮ ﻃﻠﺒﺎﺕ ﺍﻟﻤﻮﺍﻗﻊ‪ ،‬ﻓﻴﺮُﺳﻞ‬
‫ﺍﻟﻤﻬﺎﺟﻢﻃﻠﺒﺎً ﻣﻌُﺪﺍًّ ﻣﺴﺒﻘﺎً ﺇﻟﻰ ﺗﻄﺒﻴﻖ ﻣﻦ ﻣﻮﻗﻊ ﻭﻳﺐ ﻳﺴُﻴﻄﺮ ﻋﻠﻴﻪ‪ ،‬ﻣﺴﺘﻐﻼً ﺇﺭﺳﺎﻝ‬
‫ﻣﺘﺼﻔﺢﺍﻟﻤﺴﺘﺨﺪﻡ ﺗﻠﻘﺎﺉﻴﺎً ﻟﻤﻠﻒ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﺍﻟﺤﺎﻟﻲ ﻣﻊ ﻫﺬﺍ ﺍﻟﻄﻠﺐ‪ .‬ﻳﺸُﺮﺡ ﻫﺬﺍ‬
‫ﺍﻟﻨﻮﻉﻣﻦ ﺍﻟﻬﺠﻤﺎﺕ ﻓﻲ ﺍﻟﻔﺼﻞ ‪.12‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬ ‫‪244‬‬

‫ﺧﻄﻮﺍﺕﺍﻻﺧﺘﺮﺍﻕ‬

‫‪.1‬ﺣﺪﺩ ﺃﻱ ﺛﻐﺮﺍﺕ ﺃﻣﻨﻴﺔ ﻓﻲ ﺑﺮﻣﺠﺔ ﺍﻟﻤﻮﺍﻗﻊ ﺍﻟﻤﺘﻘﺎﻃﻌﺔ ﺩﺍﺧﻞ ﺍﻟﺘﻄﺒﻴﻖ‪ ،‬ﻭﺣﺪﺩ ﻣﺎ ﺇﺫﺍ ﻛﺎﻥ ﻣﻦ‬
‫ﺍﻟﻤﻤﻜﻦﺍﺳﺘﻐﻼﻟﻬﺎ ﻻﻟﺘﻘﺎﻁ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ ﻟﻠﻤﺴﺘﺨﺪﻣﻴﻦ ﺍﻵﺧﺮﻳﻦ )ﺍﻧﻈﺮ ﺍﻟﻔﺼﻞ ‪.(12‬‬

‫‪.٢‬ﺇﺫﺍ ﺃﺻﺪﺭ ﺍﻟﺘﻄﺒﻴﻖ ﺭﻣﻮﺯ ﺟﻠﺴﺔ ﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﻏﻴﺮ ﻣﺼﺎﺩﻕ ﻋﻠﻴﻬﻢ‪ ،‬ﻓﺎﺣﺼﻞ ﻋﻠﻰ ﺭﻣﺰ ﻭﻗﻢ‬
‫ﺑﺘﺴﺠﻴﻞﺍﻟﺪﺧﻮﻝ‪ .‬ﺇﺫﺍ ﻟﻢ ﻳﺼُﺪﺭ ﺍﻟﺘﻄﺒﻴﻖ ﺭﻣﺰﺍً ﺟﺪﻳﺪﺍً ﺍﻟﺘﺎﻟﻲﻓﻲ ﺣﺎﻟﺔ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﺑﻨﺠﺎﺡ‪،‬‬
‫ﻓﺈﻧﻪﻳﻜﻮﻥ ﻋﺮﺿﺔ ﻟﺘﺜﺒﻴﺖ ﺍﻟﺠﻠﺴﺔ‪.‬‬
‫‪.٣‬ﺣﺘﻰ ﻟﻮ ﻟﻢ ﻳﺼُﺪﺭ ﺍﻟﺘﻄﺒﻴﻖ ﺭﻣﻮﺯ ﺟﻠﺴﺔ ﻟﻠﻤﺴﺘﺨﺪﻣﻴﻦ ﻏﻴﺮ ﺍﻟﻤﺼُﺎﺩﻕ ﻋﻠﻴﻬﻢ‪ ،‬ﺍﺣﺼﻞ ﻋﻠﻰ ﺭﻣﺰ‬
‫ﺑﺘﺴﺠﻴﻞﺍﻟﺪﺧﻮﻝ‪ ،‬ﺛﻢ ﻋﺪُ ﺇﻟﻰ ﺻﻔﺤﺔ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ‪ .‬ﺇﺫﺍ ﻛﺎﻥ ﺍﻟﺘﻄﺒﻴﻖ ﻋﻠﻰ ﺍﺳﺘﻌﺪﺍﺩ‬
‫ﻟﻠﻌﻮﺩﺓﺇﻟﻰ ﻫﺬﻩ ﺍﻟﺼﻔﺤﺔ ﺣﺘﻰ ﻟﻮ ﻛﻨﺖ ﻣﺼُﺎﺩﻗﺎً ﺑﺎﻟﻔﻌﻞ‪ ،‬ﻓﺄﺭﺳﻞ ﺗﺴﺠﻴﻞ ﺩﺧﻮﻝ ﺁﺧﺮ‬
‫ﻛﻤﺴﺘﺨﺪﻡﻣﺨﺘﻠﻒ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺍﻟﺮﻣﺰ ﻧﻔﺴﻪ‪ .‬ﺇﺫﺍ ﻟﻢ ﻳﺼُﺪﺭ ﺍﻟﺘﻄﺒﻴﻖ ﺭﻣﺰﺍً ﺟﺪﻳﺪﺍً ﺑﻌﺪ ﺗﺴﺠﻴﻞ‬
‫ﺍﻟﺪﺧﻮﻝﺍﻟﺜﺎﻧﻲ‪ ،‬ﻓﺴﻴﻜﻮﻥ ﻋﺮُﺿﺔ ﻟﺘﺜﺒﻴﺖ ﺍﻟﺠﻠﺴﺔ‪.‬‬

‫‪.٤‬ﺣﺪﺩ ﺻﻴﻐﺔ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ ﺍﻟﺘﻲ ﻳﺴﺘﺨﺪﻣﻬﺎ ﺍﻟﺘﻄﺒﻴﻖ‪ .‬ﻋﺪﻝّ ﺭﻣﺰﻙ ﺇﻟﻰ ﻗﻴﻤﺔ ﻣﺒُﺘﻜﺮﺓ ﺻﺤﻴﺤﺔ‪،‬‬
‫ﻭﺣﺎﻭﻝﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ‪.‬‬
‫ﺇﺫﺍﻛﺎﻥ ﺍﻟﺘﻄﺒﻴﻖ ﻳﺴﻤﺢ ﻟﻚ ﺑﺈﻧﺸﺎء ﺟﻠﺴﺔ ﻣﺼﺎﺩﻗﺔ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺭﻣﺰ ﻣﺨﺘﺮﻉ‪ ،‬ﻓﻬﻮ ﻋﺮﺿﺔ‬
‫ﻟﺘﺜﺒﻴﺖﺍﻟﺠﻠﺴﺔ‪.‬‬
‫‪.٥‬ﺇﺫﺍ ﻛﺎﻥ ﺍﻟﺘﻄﺒﻴﻖ ﻻ ﻳﺪﻋﻢ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ‪ ،‬ﻭﻟﻜﻨﻪ ﻳﻌﺎﻟﺞ ﻣﻌﻠﻮﻣﺎﺕ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺍﻟﺤﺴﺎﺳﺔ )ﻣﺜﻞ‬
‫ﺍﻟﺒﻴﺎﻧﺎﺕﺍﻟﺸﺨﺼﻴﺔ ﻭﺑﻴﺎﻧﺎﺕ ﺍﻟﺪﻓﻊ(‪ ،‬ﻭﻳﺴﻤﺢ ﺑﻌﺮﺿﻬﺎ ﺑﻌﺪ ﺍﻹﺭﺳﺎﻝ )ﻣﺜﻼ ًﻓﻲ ﺻﻔﺤﺔ "‬
‫ﺍﻟﺘﺤﻘﻖﻣﻦ ﻃﻠﺒﻲ"(‪ ،‬ﻓﻘﻢ ﺑﺈﺟﺮﺍء ﺍﻻﺧﺘﺒﺎﺭﺍﺕ ﺍﻟﺜﻼﺛﺔ ﺍﻟﺴﺎﺑﻘﺔ ﻋﻠﻰ ﺍﻟﺼﻔﺤﺎﺕ ﺍﻟﺘﻲ ﺗﻌﺮﺽ‬
‫ﺍﻟﺒﻴﺎﻧﺎﺕﺍﻟﺤﺴﺎﺳﺔ‪ .‬ﺇﺫﺍ ﺃﻣﻜﻦ ﺍﺳﺘﺨﺪﺍﻡ ﺭﻣﺰ ﻣﻤﻴﺰ ﺗﻢ ﺿﺒﻄﻪ ﺃﺛﻨﺎء ﺍﻻﺳﺘﺨﺪﺍﻡ ﺍﻟﻤﺠﻬﻮﻝ‬
‫ﻟﻠﺘﻄﺒﻴﻖﻻﺣﻘﺎً ﻻﺳﺘﺮﺟﺎﻉ ﻣﻌﻠﻮﻣﺎﺕ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺍﻟﺤﺴﺎﺳﺔ‪ ،‬ﻓﺴﻴﻜﻮﻥ ﺍﻟﺘﻄﺒﻴﻖ ﻋﺮﺿﺔ‬
‫ﻟﺘﺜﺒﻴﺖﺍﻟﺠﻠﺴﺔ‪.‬‬

‫‪.٦‬ﺇﺫﺍ ﻛﺎﻥ ﺍﻟﺘﻄﺒﻴﻖ ﻳﺴﺘﺨﺪﻡ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﺭﺗﺒﺎﻁ ‪ HTTP‬ﻟﻨﻘﻞ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ‪ ،‬ﻓﻘﺪ ﻳﻜﻮﻥ ﻋﺮﺿﺔ‬
‫ﻟﺘﺰﻭﻳﺮﻃﻠﺒﺎﺕ ﺍﻟﻤﻮﺍﻗﻊ ﺍﻟﻤﺘﻌﺪﺩﺓ )‪ .(XSRF‬ﺃﻭﻻً‪ ،‬ﺳﺠﻞّ ﺍﻟﺪﺧﻮﻝ ﺇﻟﻰ ﺍﻟﺘﻄﺒﻴﻖ‪ .‬ﺛﻢ ﺗﺄﻛﺪ ﻣﻦ ﺃﻥ‬
‫ﺍﻟﻄﻠﺐﺍﻟﻤﺮُﺳﻞ ﺇﻟﻰ ﺍﻟﺘﻄﺒﻴﻖ‪ ،‬ﻭﺍﻟﺬﻱ ﻳﻨﺒﻌﺚ ﻣﻦ ﺻﻔﺤﺔ ﺗﻄﺒﻴﻖ ﻣﺨﺘﻠﻒ‪ ،‬ﻳﺆﺩﻱ ﺇﻟﻰ ﺇﺭﺳﺎﻝ‬
‫ﺭﻣﺰﺍﻟﻤﺴﺘﺨﺪﻡ‪) .‬ﻳﺠﺐ ﺃﻥ ﻳﺘﻢ ﻫﺬﺍ ﺍﻹﺭﺳﺎﻝ ﻣﻦ ﻧﺎﻓﺬﺓ ﻋﻤﻠﻴﺔ ﺍﻟﻤﺘﺼﻔﺢ ﻧﻔﺴﻬﺎ ﺍﻟﺘﻲ‬
‫ﺍﺳﺘﺨُﺪﻣﺖﻟﺘﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﺇﻟﻰ ﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﻤﺴﺘﻬﺪﻑ(‪ .‬ﺣﺎﻭﻝ ﺗﺤﺪﻳﺪ ﺃﻱ ﻭﻇﺎﺉﻒ ﺣﺴﺎﺳﺔ‬
‫ﻓﻲﺍﻟﺘﻄﺒﻴﻖ ﻳﻤﻜﻦ ﻟﻠﻤﻬﺎﺟﻢ ﺗﺤﺪﻳﺪ ﻣﻌﻠﻤﺎﺗﻬﺎ ﻣﺴﺒﻘﺎً‪ ،‬ﻭﺍﺳﺘﻐﻞ ﺫﻟﻚ ﻟﺘﻨﻔﻴﺬ ﺇﺟﺮﺍءﺍﺕ ﻏﻴﺮ‬
‫ﻣﺼﺮﺡﺑﻬﺎ ﺿﻤﻦ ﺳﻴﺎﻕ ﺃﻣﺎﻥ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺍﻟﻤﺴﺘﻬﺪﻑ‪ .‬ﺭﺍﺟﻊ ﺍﻟﻔﺼﻞ ‪ ١٣‬ﻟﻤﺰﻳﺪ ﻣﻦ ﺍﻟﺘﻔﺎﺻﻴﻞ‬
‫ﺣﻮﻝﻛﻴﻔﻴﺔ ﺗﻨﻔﻴﺬ ﻫﺠﻤﺎﺕ ‪.XSRF‬‬

‫ﻧﻄﺎﻕﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﺍﻟﻠﻴﺒﺮﺍﻟﻴﺔ‬

‫ﺍﻟﻤﻠﺨﺺﺍﻟﺒﺴﻴﻂ ﺍﻟﻤﻌﺘﺎﺩ ﻟﻜﻴﻔﻴﺔ ﻋﻤﻞ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﻫﻮ ﺃﻥ ﺍﻟﺨﺎﺩﻡ ﻳﺼﺪﺭ ﻣﻠﻒ ﺗﻌﺮﻳﻒ‬
‫ﺍﺭﺗﺒﺎﻁﺑﺎﺳﺘﺨﺪﺍﻡ ﺭﺃﺱ ﺍﺳﺘﺠﺎﺑﺔ ‪HTTP‬ﻣﺠﻤﻮﻋﺔ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ‪،‬ﺛﻢ ﻳﻘﻮﻡ ﺍﻟﻤﺘﺼﻔﺢ ﺑﺈﻋﺎﺩﺓ‬
‫ﺇﺭﺳﺎﻝﻣﻠﻒ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﻫﺬﺍ ﻓﻲ ﺍﻟﻄﻠﺒﺎﺕ ﺍﻟﻼﺣﻘﺔ ﺇﻟﻰ ﻧﻔﺲ ﺍﻟﺨﺎﺩﻡ ﺑﺎﺳﺘﺨﺪﺍﻡﻛﻮﻛﻴﺰﻓﻲ ﺍﻟﻮﺍﻗﻊ‪،‬‬
‫ﺍﻷﻣﻮﺭﺃﻛﺜﺮ ﺩﻗﺔ ﻣﻦ ﺫﻟﻚ‪.‬‬
‫‪245‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬

‫ﺗﺴﻤﺢﺁﻟﻴﺔ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﻟﻠﺨﺎﺩﻡ ﺑﺘﺤﺪﻳﺪ ﻛﻞ ٍّﻣﻦ ﺍﻟﻨﻄﺎﻕ ﻭﻣﺴﺎﺭ ﻋﻨﻮﺍﻥ ‪ URL‬ﺍﻟﺬﻱ‬
‫ﺳﻴﻌُﺎﺩﺇﺭﺳﺎﻝ ﻛﻞ ﻣﻠﻒ ﺗﻌﺮﻳﻒ ﺍﺭﺗﺒﺎﻁ ﺇﻟﻴﻪ‪ .‬ﻟﻠﻘﻴﺎﻡ ﺑﺬﻟﻚ‪ ،‬ﻳﺴﺘﺨﺪﻡﺍﺧِﺘﺼِﺎﺹ‬
‫ﻭﻃﺮﻳﻖﺍﻟﺴﻤﺎﺕ ﺍﻟﺘﻲ ﻳﻤﻜﻦ ﺗﻀﻤﻴﻨﻬﺎ ﻓﻲﻣﺠﻤﻮﻋﺔ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁﺗﻌﻠﻴﻤﺎﺕ‪.‬‬

‫ﻗﻴﻮﺩﻧﻄﺎﻕ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ‬

‫ﻋﻨﺪﻣﺎﻳﻜﻮﻥ ﺍﻟﺘﻄﺒﻴﻖ ﻣﻮﺟﻮﺩﺍً ﻓﻲ‪foo.wahh-app.com‬ﻳﻘﻮﻡ ﺍﻟﻤﺘﺼﻔﺢ ﺑﺸﻜﻞ ﺍﻓﺘﺮﺍﺿﻲ ﺑﺈﻋﺎﺩﺓ‬
‫ﺇﺭﺳﺎﻝﻣﻠﻒ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﻓﻲ ﺟﻤﻴﻊ ﺍﻟﻄﻠﺒﺎﺕ ﺍﻟﻼﺣﻘﺔ ﺇﻟﻰ‪foo.wahh-app . com،‬ﻭﺃﻳﻀﺎً ﺇﻟﻰ ﺃﻱ‬
‫ﻧﻄﺎﻗﺎﺕﻓﺮﻋﻴﺔ‪ ،‬ﻣﺜﻞ‪admin.foo.wahh-app.com.‬ﻻ ﻳﺮﺳﻞ ﻣﻠﻒ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﺇﻟﻰ ﺃﻱ ﻧﻄﺎﻗﺎﺕ‬
‫ﺃﺧﺮﻯ‪،‬ﺑﻤﺎ ﻓﻲ ﺫﻟﻚ ﺍﻟﻨﻄﺎﻕ ﺍﻟﺮﺉﻴﺴﻲ‬
‫‪wahh-app.com‬ﻭﺃﻱ ﻧﻄﺎﻗﺎﺕ ﻓﺮﻋﻴﺔ ﺃﺧﺮﻯ ﻟﻠﻮﺍﻟﺪ‪ ،‬ﻣﺜﻞ‪bar.wahh-app.com.‬‬
‫ﻳﻤﻜﻦﻟﻠﺨﺎﺩﻡ ﺗﺠﺎﻭﺯ ﻫﺬﺍ ﺍﻟﺴﻠﻮﻙ ﺍﻻﻓﺘﺮﺍﺿﻲ ﻋﻦ ﻃﺮﻳﻖ ﺗﻀﻤﻴﻦﺍﺧِﺘﺼِﺎﺹﺍﻟﺴﻤﺔ ﻓﻲﻣﺠﻤﻮﻋﺔ‬
‫ﻣﻠﻔﺎﺕﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁﺍﻟﺘﻌﻠﻴﻤﺎﺕ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﺍﻓﺘﺮﺽ ﺃﻥ ﺍﻟﺘﻄﺒﻴﻖ ﻓﻲ‪foo .wahh-app.com‬‬
‫ﻳﺮﺟﻊﺭﺃﺱ ‪ HTTP‬ﺍﻟﺘﺎﻟﻲ‪:‬‬
‫ﻣﺠﻤﻮﻋﺔﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ‪sessionId=19284710 :‬؛ ﺍﻟﻤﺠﺎﻝ=‪wahh-app.com‬؛‬

‫ﻟـ‪wahh-app.com،‬‬ ‫ﺛﻢﻳﻘﻮﻡ ﺍﻟﻤﺘﺼﻔﺢ ﺑﺈﻋﺎﺩﺓ ﺇﺭﺳﺎﻝ ﻣﻠﻒ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﻫﺬﺍ ﺇﻟﻰ ﺟﻤﻴﻊ ﺍﻟﻨﻄﺎﻗﺎﺕ ﺍﻟﻔﺮﻋﻴﺔ‬
‫ﻣﺸﺘﻤﻞ‪bar.wahh-app.com.‬‬

‫ﻣﻠﺤﻮﻇﺔﻻ ﻳﻤﻜﻦ ﻟﻠﺨﺎﺩﻡ ﺗﺤﺪﻳﺪ ﺃﻱ ﻧﻄﺎﻕ ﺑﺎﺳﺘﺨﺪﺍﻡ ﻫﺬﻩ ﺍﻟﺨﺎﺻﻴﺔ‪ .‬ﺃﻭﻻ‪ ً،‬ﻳﺠﺐ ﺃﻥ ﻳﻜﻮﻥ ﺍﻟﻨﻄﺎﻕ‬
‫ﺍﻟﻤﺤﺪﺩﻫﻮ ﻧﻔﺴﻪ ﺍﻟﻨﻄﺎﻕ ﺍﻟﺬﻱ ﻳﻌﻤﻞ ﻋﻠﻴﻪ ﺍﻟﺘﻄﺒﻴﻖ ﺃﻭ ﻧﻄﺎﻗﺎً ﺭﺉﻴﺴﻴﺎً ﻟﻪ )ﺳﻮﺍء ًﻣﺒﺎﺷﺮﺓ ًﺃﻭ ﺑﻌﺪ‬
‫ﻓﺘﺮﺓ(‪ .‬ﺛﺎﻧﻴﺎً‪ ،‬ﻻ ﻳﻤﻜﻦ ﺃﻥ ﻳﻜﻮﻥ ﺍﻟﻨﻄﺎﻕ ﺍﻟﻤﺤﺪﺩ ﻧﻄﺎﻗﺎً ﻣﻦ ﺍﻟﻤﺴﺘﻮﻯ ﺍﻷﻋﻠﻰ ﻣﺜﻞ ‪.‬ﻛﻮﻡﺃﻭ‬

‫‪.co.uk،‬ﻷﻥ ﻫﺬﺍ ﻳﻤُﻜﻦّ ﺧﺎﺩﻣﺎً ﺿﺎﺭﺍً ﻣﻦ ﺗﺜﺒﻴﺖ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﺭﺗﺒﺎﻁ ﻋﺸﻮﺍﺉﻴﺔ ﻋﻠﻰ ﺃﻱ ﻧﻄﺎﻕ‬
‫ﺁﺧﺮ‪.‬ﺇﺫﺍ ﺍﻧﺘﻬﻚ ﺍﻟﺨﺎﺩﻡ ﺇﺣﺪﻯ ﻫﺬﻩ ﺍﻟﻘﻮﺍﻋﺪ‪ ،‬ﻓﺴﻴﺘﺠﺎﻫﻞ ﺍﻟﻤﺘﺼﻔﺢ ﺑﺒﺴﺎﻃﺔﻣﺠﻤﻮﻋﺔ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ‬
‫ﺍﻻﺭﺗﺒﺎﻁﺗﻌﻠﻴﻤﺎﺕ‪.‬‬

‫ﺇﺫﺍﻗﺎﻡ ﺃﺣﺪ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺑﺘﻌﻴﻴﻦ ﻧﻄﺎﻕ ﻧﻄﺎﻕ ﻣﻠﻒ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﻋﻠﻰ ﺃﻧﻪ ﻣﺘﺤﺮﺭ ﺑﺸﻜﻞ ﻏﻴﺮ‬
‫ﻣﻼﺉﻢ‪،‬ﻓﻘﺪ ﻳﺆﺩﻱ ﻫﺬﺍ ﺇﻟﻰ ﺗﻌﺮﻳﺾ ﺍﻟﺘﻄﺒﻴﻖ ﻟﺜﻐﺮﺍﺕ ﺃﻣﻨﻴﺔ ﻣﺨﺘﻠﻔﺔ‪.‬‬
‫ﻋﻠﻰﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﻟﻨﻔﺘﺮﺽ ﻭﺟﻮﺩ ﺗﻄﺒﻴﻖ ﺗﺪﻭﻳﻦ ﻳﺴﻤﺢ ﻟﻠﻤﺴﺘﺨﺪﻣﻴﻦ ﺑﺎﻟﺘﺴﺠﻴﻞ ﻭﺗﺴﺠﻴﻞ‬
‫ﺍﻟﺪﺧﻮﻝﻭﻛﺘﺎﺑﺔ ﻣﻨﺸﻮﺭﺍﺕ ﺍﻟﻤﺪﻭﻧﺔ ﻭﻗﺮﺍءﺓ ﻣﺪﻭﻧﺎﺕ ﺍﻵﺧﺮﻳﻦ‪ .‬ﻳﻘﻊ ﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﺮﺉﻴﺴﻲ ﻓﻲ ﺍﻟﻨﻄﺎﻕ‬
‫‪wahh-blogs.com.‬ﻋﻨﺪ ﺗﺴﺠﻴﻞ ﺩﺧﻮﻝ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺇﻟﻰ ﺍﻟﺘﻄﺒﻴﻖ‪ ،‬ﻳﺘﻠﻘﻮﻥ ﺭﻣﺰ ﺟﻠﺴﺔ ﻓﻲ ﻣﻠﻒ‬
‫ﺗﻌﺮﻳﻒﺍﺭﺗﺒﺎﻁ ﻣﺨُﺼﺺ ﻟﻬﺬﺍ ﺍﻟﻨﻄﺎﻕ‪ .‬ﻳﻤﻜﻦ ﻟﻜﻞ ﻣﺴﺘﺨﺪﻡ ﺇﻧﺸﺎء ﻣﺪﻭﻧﺎﺕ ﻳﻤﻜﻦ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻴﻬﺎ‬
‫ﻋﺒﺮﻧﻄﺎﻕ ﻓﺮﻋﻲ ﺟﺪﻳﺪ ﻳﺴﺒﻘﻪ ﺍﺳﻢ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺍﻟﺨﺎﺹ ﺑﻪ‪:‬‬

‫‪herman.wahh-blogs.com‬‬
‫‪solero.wahh-blogs.com‬‬

‫ﻷﻥﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﺗﻌُﺎﺩ ﺇﺭﺳﺎﻟﻬﺎ ﺗﻠﻘﺎﺉﻴﺎً ﺇﻟﻰ ﻛﻞ ﻧﻄﺎﻕ ﻓﺮﻋﻲ ﺿﻤﻦ ﻧﻄﺎﻗﻬﺎ‪ ،‬ﻓﻌﻨﺪﻣﺎ‬
‫ﻳﺘﺼﻔﺢﻣﺴﺘﺨﺪﻡ ﻣﺴﺠﻞ ﺍﻟﺪﺧﻮﻝ ﻣﺪﻭﻧﺎﺕ ﻣﺴﺘﺨﺪﻣﻴﻦ ﺁﺧﺮﻳﻦ‪ ،‬ﻳﺮُﺳﻞ ﺭﻣﺰ ﺟﻠﺴﺘﻪ ﻣﻊ ﻃﻠﺒﺎﺗﻪ‪ .‬ﺇﺫﺍ‬
‫ﺳﻤُﺢﻟﻤﺆﻟﻔﻲ ﺍﻟﻤﺪﻭﻧﺎﺕ ﺑﻮﺿﻊ ﺟﺎﻓﺎ ﺳﻜﺮﻳﺒﺖ ﻋﺸﻮﺍﺉﻴﺎً ﺩﺍﺧﻞ ﻣﺪﻭﻧﺎﺗﻬﻢ )ﻛﻤﺎ ﻫﻮ ﺍﻟﺤﺎﻝ ﻋﺎﺩﺓ ًﻓﻲ‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬ ‫‪246‬‬

‫ﻓﻲﺗﻄﺒﻴﻘﺎﺕ ﺍﻟﻤﺪﻭﻧﺎﺕ ﻓﻲ ﺍﻟﻌﺎﻟﻢ ﺍﻟﺤﻘﻴﻘﻲ‪ ،‬ﻳﻤﻜﻦ ﻟﻠﻤﺪﻭﻥ ﺍﻟﺨﺒﻴﺚ ﺃﻥ ﻳﺴﺮﻕ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ‬
‫ﻟﻠﻤﺴﺘﺨﺪﻣﻴﻦﺍﻵﺧﺮﻳﻦ ﺑﻨﻔﺲ ﺍﻟﻄﺮﻳﻘﺔ ﺍﻟﺘﻲ ﺗﺘﻢ ﻓﻲ ﻫﺠﻮﻡ ﺑﺮﻣﺠﺔ ﻧﺼﻴﺔ ﻋﺒﺮ ﺍﻟﻤﻮﺍﻗﻊ ﺍﻟﻤﺨﺰﻧﺔ )ﺍﻧﻈﺮ‬
‫ﺍﻟﻔﺼﻞ‪.(12‬‬
‫ﺗﻨﺸﺄﺍﻟﻤﺸﻜﻠﺔ ﻷﻥ ﺍﻟﻤﺪﻭﻧﺎﺕ ﺍﻟﺘﻲ ﻳﻜﺘﺒﻬﺎ ﺍﻟﻤﺴﺘﺨﺪﻣﻮﻥ ﺗﻨُﺸﺄ ﻛﻨﻄﺎﻗﺎﺕ ﻓﺮﻋﻴﺔ ﻟﻠﺘﻄﺒﻴﻖ‬
‫ﺍﻟﺮﺉﻴﺴﻲﺍﻟﺬﻱ ﻳﺘﻮﻟﻰ ﺍﻟﻤﺼﺎﺩﻗﺔ ﻭﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺎﺕ‪ .‬ﻻ ﺗﻮﺟﺪ ﻣﻴﺰﺓ ﺩﺍﺧﻞ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﺭﺗﺒﺎﻁ‬
‫‪ HTTP‬ﻟﻠﺘﻄﺒﻴﻖ ﻟﻤﻨﻊ ﺇﻋﺎﺩﺓ ﺇﺭﺳﺎﻝ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﺍﻟﺼﺎﺩﺭﺓ ﻋﻦ ﺍﻟﻨﻄﺎﻕ ﺍﻟﺮﺉﻴﺴﻲ ﺇﻟﻰ‬
‫ﻧﻄﺎﻗﺎﺗﻪﺍﻟﻔﺮﻋﻴﺔ‪.‬‬
‫ﺍﻟﺤﻞﻫﻮ ﺍﺳﺘﺨﺪﺍﻡ ﺍﺳﻢ ﻧﻄﺎﻕ ﻣﺨﺘﻠﻒ ﻟﻠﺘﻄﺒﻴﻖ ﺍﻟﺮﺉﻴﺴﻲ )ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪-blogs.com(،‬‬
‫‪)www.wahh‬ﻭﻟﺘﺤﺪﻳﺪ ﻧﻄﺎﻕ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﺭﺗﺒﺎﻁ ﺭﻣﺰ ﺍﻟﺠﻠﺴﺔ ﺍﻟﺨﺎﺻﺔ ﺑﻪ ﺇﻟﻰ ﻫﺬﺍ ﺍﻻﺳﻢ ﺍﻟﻤﺆﻫﻞ‬
‫ﺑﺎﻟﻜﺎﻣﻞ‪.‬ﻟﻦ ﻳﺮُﺳﻞ ﻣﻠﻒ ﺗﻌﺮﻳﻒ ﺍﺭﺗﺒﺎﻁ ﺍﻟﺠﻠﺴﺔ ﻋﻨﺪ ﺗﺼﻔﺢ ﻣﺴﺘﺨﺪﻡ ﻣﺴﺠﻞ ﺍﻟﺪﺧﻮﻝ ﻣﺪﻭﻧﺎﺕ‬
‫ﻣﺴﺘﺨﺪﻣﻴﻦﺁﺧﺮﻳﻦ‪.‬‬
‫ﺗﻈﻬﺮﻧﺴﺨﺔ ﻣﺨﺘﻠﻔﺔ ﻣﻦ ﻫﺬﻩ ﺍﻟﺜﻐﺮﺓ ﺍﻷﻣﻨﻴﺔ ﻋﻨﺪﻣﺎ ﻳﻌُﻴﻦّ ﺗﻄﺒﻴﻖ ٌﻣﺎ ﻧﻄﺎﻕ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ‬
‫ﺍﻻﺭﺗﺒﺎﻁﺍﻟﺨﺎﺻﺔ ﺑﻪ ﺻﺮﺍﺣﺔ ًﺇﻟﻰ ﻧﻄﺎﻕ ﺭﺉﻴﺴﻲ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﻟﻨﻔﺘﺮﺽ ﺃﻥ ﺗﻄﺒﻴﻘﺎً ﺃﻣﻨﻴﺎً ﺑﺎﻟﻎ‬
‫ﺍﻷﻫﻤﻴﺔﻳﻘﻊ ﻓﻲ ﺍﻟﻨﻄﺎﻕ ﺍﻟﺮﺉﻴﺴﻲ‪sensitiveapp . wahh-organization.com..‬ﻋﻨﺪﻣﺎ ﻳﺘﻢ ﺗﻌﻴﻴﻦ‬
‫ﻣﻠﻔﺎﺕﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ‪ ،‬ﻓﺈﻧﻪ ﻳﺤﺮﺭ ﻧﻄﺎﻕ ﻧﻄﺎﻗﻬﺎ ﺑﺸﻜﻞ ﺻﺮﻳﺢ‪ ،‬ﻋﻠﻰ ﺍﻟﻨﺤﻮ ﺍﻟﺘﺎﻟﻲ‪:‬‬

‫ﻣﺠﻤﻮﻋﺔﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ‪sessionId=12df098ad809a5219 :‬؛ ﺍﻟﻤﺠﺎﻝ=‪wahh-organization.com‬‬

‫ﺍﻟﻨﺘﻴﺠﺔﺍﻟﻤﺘﺮﺗﺒﺔ ﻋﻠﻰ ﺫﻟﻚ ﻫﻲ ﺃﻥ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﺍﻟﺨﺎﺻﺔ ﺑﺮﻣﺰ ﺟﻠﺴﺔ ﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﺤﺴﺎﺱ‬
‫ﺳﻴﺘﻢﺇﺭﺳﺎﻟﻬﺎ ﻋﻨﺪﻣﺎ ﻳﻘﻮﻡ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺑﺰﻳﺎﺭﺓﻛﻞﺍﻟﻤﺠﺎﻝ ﺍﻟﻔﺮﻋﻲ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺑﻮﺍﺳﻄﺔﻣﻨﻈﻤﺔ ﻭﺍﻩ‪-‬ﻛﻮﻡ‪،‬‬
‫ﻣﺸﺘﻤﻞ‪:‬‬

‫‪testapp.wahh-organization.com‬‬
‫‪www.wahh-organization.com‬‬

‫ﻋﻠﻰﺍﻟﺮﻏﻢ ﻣﻦ ﺃﻥ ﻫﺬﻩ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﻷﺧﺮﻯ ﻗﺪ ﺗﻨﺘﻤﻲ ﺟﻤﻴﻌﻬﺎ ﺇﻟﻰ ﻧﻔﺲ ﺍﻟﻤﻨﻈﻤﺔ ﺍﻟﺘﻲ ﻳﻨﺘﻤﻲ‬
‫ﺇﻟﻴﻬﺎﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﺤﺴﺎﺱ‪ ،‬ﻓﻤﻦ ﻏﻴﺮ ﺍﻟﻤﺮﻏﻮﺏ ﻓﻴﻪ ﺇﺭﺳﺎﻝ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﺍﻟﺨﺎﺻﺔ ﺑﺎﻟﺘﻄﺒﻴﻖ‬
‫ﺍﻟﺤﺴﺎﺱﺇﻟﻰ ﺗﻄﺒﻴﻘﺎﺕ ﺃﺧﺮﻯ‪ ،‬ﻭﺫﻟﻚ ﻟﻌﺪﺓ ﺃﺳﺒﺎﺏ‪:‬‬
‫ﻗﺪﻳﻜﻮﻥ ﻟﺪﻯ ﺍﻟﻤﻮﻇﻔﻴﻦ ﺍﻟﻤﺴﺆﻭﻟﻴﻦ ﻋﻦ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﻷﺧﺮﻯ ﻣﺴﺘﻮﻯ ﺛﻘﺔ ﻣﺨﺘﻠﻒ ﻋﻦ‬ ‫‪-‬‬

‫ﺍﻟﻤﺴﺆﻭﻟﻴﻦﻋﻦ ﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﺤﺴﺎﺱ‪.‬‬

‫ﻗﺪﺗﺤﺘﻮﻱ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﻷﺧﺮﻯ ﻋﻠﻰ ﻭﻇﺎﺉﻒ ﺗﺴﻤﺢ ﻷﻃﺮﺍﻑ ﺛﺎﻟﺜﺔ ﺑﺎﻟﺤﺼﻮﻝ ﻋﻠﻰ ﻗﻴﻤﺔ‬ ‫‪-‬‬

‫ﻣﻠﻔﺎﺕﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﺍﻟﻤﺮﺳﻠﺔ ﺇﻟﻰ ﺍﻟﺘﻄﺒﻴﻖ‪ ،‬ﻛﻤﺎ ﻓﻲ ﻣﺜﺎﻝ ﺍﻟﺘﺪﻭﻳﻦ ﺍﻟﺴﺎﺑﻖ‪.‬‬

‫ﻗﺪﻻ ﺗﻜﻮﻥ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﻷﺧﺮﻯ ﻗﺪ ﺧﻀﻌﺖ ﻟﻨﻔﺲ ﻣﻌﺎﻳﻴﺮ ﺍﻷﻣﺎﻥ ﺃﻭ ﺍﻻﺧﺘﺒﺎﺭﺍﺕ ﺍﻟﺘﻲ ﺧﻀﻊ‬ ‫‪-‬‬

‫ﻟﻬﺎﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﺤﺴﺎﺱ )ﻷﻧﻬﺎ ﺃﻗﻞ ﺃﻫﻤﻴﺔ‪ ،‬ﺃﻭ ﻻ ﺗﺘﻌﺎﻣﻞ ﻣﻊ ﺑﻴﺎﻧﺎﺕ ﺣﺴﺎﺳﺔ‪ ،‬ﺃﻭ ﺃﻧُﺸﺉﺖ‬
‫ﻷﻏﺮﺍﺽﺍﻻﺧﺘﺒﺎﺭ ﻓﻘﻂ(‪ .‬ﻗﺪ ﺗﻜﻮﻥ ﺍﻟﻌﺪﻳﺪ ﻣﻦ ﺃﻧﻮﺍﻉ ﺍﻟﺜﻐﺮﺍﺕ ﺍﻷﻣﻨﻴﺔ ﺍﻟﺘﻲ ﻗﺪ ﺗﻮﺟﺪ ﻓﻲ ﺗﻠﻚ‬
‫ﺍﻟﺘﻄﺒﻴﻘﺎﺕ)ﻣﺜﻞ ﺛﻐﺮﺍﺕ ﺍﻟﺒﺮﻣﺠﺔ ﺍﻟﻨﺼﻴﺔ ﻋﺒﺮ ﺍﻟﻤﻮﺍﻗﻊ( ﻏﻴﺮ ﺫﺍﺕ ﺻﻠﺔ ﺑﺎﻟﻮﺿﻊ ﺍﻷﻣﻨﻲ‬
‫ﻟﺘﻠﻚﺍﻟﺘﻄﺒﻴﻘﺎﺕ‪ .‬ﻭﻟﻜﻨﻬﺎ ﻗﺪ ﺗﻤُﻜﻦّ ﻣﻬﺎﺟﻤﺎً ﺧﺎﺭﺟﻴﺎً ﻣﻦ ﺍﺳﺘﻐﻼﻝ ﺗﻄﺒﻴﻖ ﻏﻴﺮ ﺁﻣﻦ ﻻﻟﺘﻘﺎﻁ‬
‫ﺭﻣﻮﺯﺍﻟﺠﻠﺴﺔ ﺍﻟﺘﻲ ﺃﻧﺸﺄﻫﺎ ﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﺤﺴﺎﺱ‪.‬‬
‫‪247‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬

‫ﻣﻠﺤﻮﻇﺔﺇﻥ ﻓﺼﻞ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﺑﻨﺎء ًﻋﻠﻰ ﺍﻟﻨﻄﺎﻕ ﻟﻴﺲ ﺑﻨﻔﺲ ﺻﺮﺍﻣﺔ ﺳﻴﺎﺳﺔ "ﻧﻔﺲ‬
‫ﺍﻟﻤﺼﺪﺭ" ﻋﻤﻮﻣﺎً )ﺍﻧﻈﺮ ﺍﻟﻔﺼﻞ ‪ .(3‬ﺑﺎﻹﺿﺎﻓﺔ ﺇﻟﻰ ﺍﻟﻤﺸﻜﻼﺕ ﺍﻟﺘﻲ ﺳﺒﻖ ﺫﻛﺮﻫﺎ ﻓﻲ ﻣﻌﺎﻟﺠﺔ ﺃﺳﻤﺎء‬
‫ﺍﻟﻤﻀﻴﻔﻴﻦ‪،‬ﺗﺘﺠﺎﻫﻞ ﺍﻟﻤﺘﺼﻔﺤﺎﺕ ﻛﻼ ًﻣﻦ ﺍﻟﺒﺮﻭﺗﻮﻛﻮﻝ ﻭﺭﻗﻢ ﺍﻟﻤﻨﻔﺬ ﻋﻨﺪ ﺗﺤﺪﻳﺪ ﻧﻄﺎﻕ ﻣﻠﻔﺎﺕ‬
‫ﺗﻌﺮﻳﻒﺍﻻﺭﺗﺒﺎﻁ‪ .‬ﺇﺫﺍ ﺷﺎﺭﻙ ﺗﻄﺒﻴﻖ ﻣﺎ ﺍﺳﻢ ﻣﻀﻴﻒ ﻣﻊ ﺗﻄﺒﻴﻖ ﻏﻴﺮ ﻣﻮﺛﻮﻕ ﺑﻪ ﻭﺍﻋﺘﻤﺪ ﻋﻠﻰ ﺍﺧﺘﻼﻑ‬
‫ﻓﻲﺍﻟﺒﺮﻭﺗﻮﻛﻮﻝ ﺃﻭ ﺭﻗﻢ ﺍﻟﻤﻨﻔﺬ ﻟﻔﺼﻞ ﻧﻔﺴﻪ‪ ،‬ﻓﺈﻥ ﺍﻟﺘﻌﺎﻣﻞ ﺍﻷﻛﺜﺮ ﻣﺮﻭﻧﺔ ﻣﻊ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ‬
‫ﻗﺪﻳﻀُﻌﻒ ﻫﺬﺍ ﺍﻟﻔﺼﻞ‪ .‬ﺳﺘﻜﻮﻥ ﺃﻱ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﺭﺗﺒﺎﻁ ﺻﺎﺩﺭﺓ ﻋﻦ ﺍﻟﺘﻄﺒﻴﻖ ﻗﺎﺑﻠﺔ ﻟﻠﻮﺻﻮﻝ ﺇﻟﻴﻬﺎ‬
‫ﻣﻦﻗﺒِﻞ ﺍﻟﺘﻄﺒﻴﻖ ﻏﻴﺮ ﺍﻟﻤﻮﺛﻮﻕ ﺑﻪ ﺍﻟﺬﻱ ﻳﺸﺎﺭﻛﻪ ﺍﺳﻢ ﺍﻟﻤﻀﻴﻒ‪.‬‬

‫ﺧﻄﻮﺍﺕﺍﻻﺧﺘﺮﺍﻕ‬

‫ﻗﻢﺑﻤﺮﺍﺟﻌﺔ ﺟﻤﻴﻊ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﺍﻟﺼﺎﺩﺭﺓ ﻋﻦ ﺍﻟﺘﻄﺒﻴﻖ‪ ،‬ﻭﺗﺤﻘﻖ ﻣﻦ ﻭﺟﻮﺩ ﺃﻱ ﻣﻨﻬﺎﺍﺧِﺘﺼِﺎﺹ‬
‫ﺍﻟﺴﻤﺎﺕﺍﻟﻤﺴﺘﺨﺪﻣﺔ ﻟﻠﺘﺤﻜﻢ ﻓﻲ ﻧﻄﺎﻕ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ‪.‬‬

‫‪.1‬ﺇﺫﺍ ﻗﺎﻡ ﺃﺣﺪ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺑﺘﺤﺮﻳﺮ ﻧﻄﺎﻕ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﺍﻟﺨﺎﺻﺔ ﺑﻪ ﺑﺸﻜﻞ ﺻﺮﻳﺢ‬
‫ﺇﻟﻰﻣﺠﺎﻝ ﺭﺉﻴﺴﻲ‪ ،‬ﻓﻘﺪ ﻳﺘﺮﻙ ﻧﻔﺴﻪ ﻋﺮﺿﺔ ﻟﻠﻬﺠﻤﺎﺕ ﻋﺒﺮ ﺗﻄﺒﻴﻘﺎﺕ ﺍﻟﻮﻳﺐ ﺍﻷﺧﺮﻯ‪.‬‬

‫‪.2‬ﺇﺫﺍ ﻗﺎﻡ ﺃﺣﺪ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺑﺘﻌﻴﻴﻦ ﻧﻄﺎﻕ ﻧﻄﺎﻕ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﺍﻟﺨﺎﺻﺔ ﺑﻪ ﺇﻟﻰ ﺍﺳﻢ‬
‫ﻧﻄﺎﻗﻪﺍﻟﺨﺎﺹ )ﺃﻭ ﻟﻢ ﻳﺤﺪﺩ ﺳﻤﺔ ﻧﻄﺎﻕ(‪ ،‬ﻓﻘﺪ ﻳﻈﻞ ﻣﻌﺮﺿﺎً ﻟﻠﺘﻄﺒﻴﻘﺎﺕ ﺃﻭ ﺍﻟﻮﻇﺎﺉﻒ ﺍﻟﺘﻲ‬
‫ﻳﻤﻜﻦﺍﻟﻮﺻﻮﻝ ﺇﻟﻴﻬﺎ ﻋﺒﺮ ﺍﻟﻤﺠﺎﻻﺕ ﺍﻟﻔﺮﻋﻴﺔ‪.‬‬

‫ﺣﺪﺩﺟﻤﻴﻊ ﺃﺳﻤﺎء ﺍﻟﻨﻄﺎﻗﺎﺕ ﺍﻟﻤﺤﺘﻤﻠﺔ ﺍﻟﺘﻲ ﺳﺘﺴﺘﻘﺒﻞ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﺍﻟﺼﺎﺩﺭﺓ ﻋﻦ‬
‫ﺍﻟﺘﻄﺒﻴﻖ‪.‬ﺗﺄﻛﺪ ﻣﻦ ﺇﻣﻜﺎﻧﻴﺔ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﺃﻱ ﺗﻄﺒﻴﻖ ﻭﻳﺐ ﺃﻭ ﻭﻇﻴﻔﺔ ﺃﺧﺮﻯ ﻋﺒﺮ ﺃﺳﻤﺎء ﺍﻟﻨﻄﺎﻗﺎﺕ‬
‫ﻫﺬﻩ‪،‬ﻭﺍﻟﺘﻲ ﻗﺪ ﺗﺘﻤﻜﻦ ﻣﻦ ﺍﺳﺘﺨﺪﺍﻣﻬﺎ ﻟﻠﺤﺼﻮﻝ ﻋﻠﻰ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﺍﻟﺼﺎﺩﺭﺓ ﻟﻤﺴﺘﺨﺪﻣﻲ‬
‫ﺍﻟﺘﻄﺒﻴﻖﺍﻟﻤﺴﺘﻬﺪﻑ‪.‬‬

‫ﻗﻴﻮﺩﻣﺴﺎﺭ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ‬

‫ﻋﻨﺪﻣﺎﻳﻜﻮﻥ ﺍﻟﺘﻄﺒﻴﻖ ﻣﻮﺟﻮﺩﺍً ﻓﻲ ‪/‬ﺍﻟﺘﻄﺒﻴﻘﺎﺕ‪/‬ﺍﻵﻣﻨﺔ‪foo-app/index.jsp/‬ﻳﻘﻮﻡ ﺍﻟﻤﺘﺼﻔﺢ ﺑﺸﻜﻞ‬

‫ﺍﻓﺘﺮﺍﺿﻲﺑﺈﻋﺎﺩﺓ ﺇﺭﺳﺎﻝ ﻣﻠﻒ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﻓﻲ ﺟﻤﻴﻊ ﺍﻟﻄﻠﺒﺎﺕ ﺍﻟﻼﺣﻘﺔ ﺇﻟﻰ ﺍﻟﻤﺴﺎﺭ ‪/‬ﺍﻟﺘﻄﺒﻴﻘﺎﺕ‪/‬‬
‫ﺍﻵﻣﻨﺔ‪/foo-app/‬ﻭﻛﺬﻟﻚ ﺇﻟﻰ ﺃﻱ ﻣﺠﻠﺪﺍﺕ ﻓﺮﻋﻴﺔ‪ .‬ﻻ ﻳﺮُﺳﻞِ ﻣﻠﻒ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﺇﻟﻰ ﺍﻟﻤﺠﻠﺪ‬
‫ﺍﻟﺮﺉﻴﺴﻲﺃﻭ ﺇﻟﻰ ﺃﻱ ﻣﺴﺎﺭﺍﺕ ﻣﺠﻠﺪﺍﺕ ﺃﺧﺮﻯ ﻣﻮﺟﻮﺩﺓ ﻋﻠﻰ ﺍﻟﺨﺎﺩﻡ‪.‬‬

‫ﻛﻤﺎﻫﻮ ﺍﻟﺤﺎﻝ ﻣﻊ ﺍﻟﻘﻴﻮﺩ ﺍﻟﻘﺎﺉﻤﺔ ﻋﻠﻰ ﺍﻟﻤﺠﺎﻝ ﻋﻠﻰ ﻧﻄﺎﻕ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ‪ ،‬ﻳﻤﻜﻦ‬
‫ﻟﻠﺨﺎﺩﻡﺗﺠﺎﻭﺯ ﻫﺬﺍ ﺍﻟﺴﻠﻮﻙ ﺍﻻﻓﺘﺮﺍﺿﻲ ﻣﻦ ﺧﻼﻝ ﺗﻀﻤﻴﻦﻃﺮﻳﻖﺍﻟﺴﻤﺔ ﻓﻲﻣﺠﻤﻮﻋﺔ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ‬
‫ﺍﻻﺭﺗﺒﺎﻁﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﺇﺫﺍ ﺃﻋﺎﺩ ﺍﻟﺘﻄﺒﻴﻖ ﺭﺃﺱ ‪ HTTP‬ﺍﻟﺘﺎﻟﻲ‪:‬‬
‫ﻣﺠﻤﻮﻋﺔﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ‪sessionId=187ab023e09c00a881a :‬؛ ﺍﻟﻤﺴﺎﺭ=‪/apps/‬؛‬

‫ﻳﻘﻮﻡﺍﻟﻤﺘﺼﻔﺢ ﺑﺈﻋﺎﺩﺓ ﺇﺭﺳﺎﻝ ﻣﻠﻒ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﻫﺬﺍ ﺇﻟﻰ ﺟﻤﻴﻊ ﺍﻟﺪﻻﺉﻞ ﺍﻟﻔﺮﻋﻴﺔ ﻟـ ‪/‬ﺍﻟﺘﻄﺒﻴﻘﺎﺕ‪/‬ﻃﺮﻳﻖ‪.‬‬
‫ﻋﻠﻰﻋﻜﺲ ﺗﺤﺪﻳﺪ ﻧﻄﺎﻕ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﺑﻨﺎء ًﻋﻠﻰ ﺍﻟﻨﻄﺎﻕ‪ ،‬ﻓﺈﻥ ﻫﺬﺍ ﺍﻟﺘﻘﻴﻴﺪ ﺍﻟﻘﺎﺉﻢ‬
‫ﻋﻠﻰﺍﻟﻤﺴﺎﺭ ﺃﻛﺜﺮ ﺻﺮﺍﻣﺔ ًﻣﻤﺎ ﺗﻔﺮﺿﻪ ﺳﻴﺎﺳﺔ ﺍﻟﻤﺼﺪﺭ ﻧﻔﺴﻪ‪ .‬ﻭﺑﺎﻟﺘﺎﻟﻲ‪ ،‬ﻓﻬﻮ ﻏﻴﺮ ﻓﻌﺎﻝ ﺗﻤﺎﻣﺎً ﺇﺫﺍ‬
‫ﺍﺳﺘﺨُﺪﻡﻛﺂﻟﻴﺔ ﺃﻣﺎﻥ ﻟﻠﺪﻓﺎﻉ ﺿﺪ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﻏﻴﺮ ﺍﻟﻤﻮﺛﻮﻗﺔ‪.‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬ ‫‪248‬‬

‫ﺍﻟﺘﻄﺒﻴﻘﺎﺕﺍﻟﻤﺴﺘﻀﺎﻓﺔ ﻋﻠﻰ ﺍﻟﻨﻄﺎﻕ ﻧﻔﺴﻪ‪ .‬ﻳﻤﻜﻦ ﻟﻜﻮﺩ ﺍﻟﻌﻤﻴﻞ ﺍﻟﺬﻱ ﻳﻌﻤﻞ ﻋﻠﻰ ﻣﺴﺎﺭ ﻭﺍﺣﺪ ﻓﺘﺢ‬
‫ﻧﺎﻓﺬﺓﺃﻭ ﺇﻃﺎﺭ ﻣﻀﻤﻦّ ﻳﺴﺘﻬﺪﻑ ﻣﺴﺎﺭﺍً ﻣﺨﺘﻠﻔﺎً ﻋﻠﻰ ﺍﻟﻨﻄﺎﻕ ﻧﻔﺴﻪ‪ ،‬ﻭﻳﻤﻜﻨﻪ ﺍﻟﻘﺮﺍءﺓ ﻭﺍﻟﻜﺘﺎﺑﺔ ﺇﻟﻰ‬
‫ﺗﻠﻚﺍﻟﻨﺎﻓﺬﺓ ﺩﻭﻥ ﺃﻱ ﻗﻴﻮﺩ‪ .‬ﻭﺑﺎﻟﺘﺎﻟﻲ‪ ،‬ﻓﺈﻥ ﺍﻟﺤﺼﻮﻝ ﻋﻠﻰ ﻣﻠﻒ ﺗﻌﺮﻳﻒ ﺍﺭﺗﺒﺎﻁ ﻣﺨُﺼﺺّ ﻟﻤﺴﺎﺭ‬
‫ﻣﺨﺘﻠﻒﻋﻠﻰ ﺍﻟﻨﻄﺎﻕ ﻧﻔﺴﻪ ﺃﻣﺮ ﺳﻬﻞ ﻧﺴﺒﻴﺎً‪ .‬ﺭﺍﺟﻊ ﺍﻟﻮﺭﻗﺔ ﺍﻟﺒﺤﺜﻴﺔ ﺍﻟﺘﺎﻟﻴﺔ ﻷﻣﻴﺖ ﻛﻼﻳﻦ ﻟﻤﺰﻳﺪ ﻣﻦ‬
‫ﺍﻟﺘﻔﺎﺻﻴﻞ‪:‬‬

‫‪.html‬ﻣﺎﺭﺱ‪/pipermail/websecurity_lists.webappsec.org/ 2006-000843/‬‬
‫‪http://lists.webappsec.org‬‬

‫ﺗﺄﻣﻴﻦﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬
‫ﺗﺘﻮﺍﻓﻖﺍﻟﺘﺪﺍﺑﻴﺮ ﺍﻟﺪﻓﺎﻋﻴﺔ ﺍﻟﺘﻲ ﻳﺠﺐ ﻋﻠﻰ ﺗﻄﺒﻴﻘﺎﺕ ﺍﻟﻮﻳﺐ ﺍﺗﺨﺎﺫﻫﺎ ﻟﻤﻨﻊ ﺍﻟﻬﺠﻤﺎﺕ ﻋﻠﻰ ﺁﻟﻴﺎﺕ‬
‫ﺇﺩﺍﺭﺓﺟﻠﺴﺎﺗﻬﺎ ﻣﻊ ﻓﺉﺘﻴﻦ ﺭﺉﻴﺴﻴﺘﻴﻦ ﻣﻦ ﺍﻟﺜﻐﺮﺍﺕ ﺍﻟﺘﻲ ﺗﺆﺛﺮ ﻋﻠﻰ ﺗﻠﻚ ﺍﻵﻟﻴﺎﺕ‪ .‬ﻹﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺎﺕ‬
‫ﺑﺸﻜﻞﺁﻣﻦ‪ ،‬ﻳﺠﺐ ﻋﻠﻰ ﺍﻟﺘﻄﺒﻴﻖ ﺇﻧﺸﺎء ﺭﻣﻮﺯﻩ ﺑﻄﺮﻳﻘﺔ ﻓﻌﺎّﻟﺔ ﻭﺣﻤﺎﻳﺘﻬﺎ ﻃﻮﺍﻝ ﺩﻭﺭﺓ ﺣﻴﺎﺗﻬﺎ ﻣﻦ‬
‫ﺇﻧﺸﺎﺉﻬﺎﺇﻟﻰ ﺍﻟﺘﺨﻠﺺ ﻣﻨﻬﺎ‪.‬‬

‫ﺇﻧﺸﺎءﺭﻣﻮﺯ ﻗﻮﻳﺔ‬
‫ﻳﺠﺐﺇﻧﺸﺎء ﺍﻟﺮﻣﻮﺯ ﺍﻟﻤﺴﺘﺨﺪﻣﺔ ﻹﻋﺎﺩﺓ ﺗﺤﺪﻳﺪ ﻫﻮﻳﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺑﻴﻦ ﺍﻟﻄﻠﺒﺎﺕ ﺍﻟﻤﺘﻌﺎﻗﺒﺔ ﺑﻄﺮﻳﻘﺔ ﻻ‬
‫ﺗﻮﻓﺮﺃﻱ ﻣﺠﺎﻝ ﻟﻠﻤﻬﺎﺟﻢ ﺍﻟﺬﻱ ﻳﺤﺼﻞ ﻋﻠﻰ ﻋﻴﻨﺔ ﻛﺒﻴﺮﺓ ﻣﻦ ﺍﻟﺮﻣﻮﺯ ﻣﻦ ﺍﻟﺘﻄﺒﻴﻖ ﺑﺎﻟﻄﺮﻳﻘﺔ ﺍﻟﻤﻌﺘﺎﺩﺓ‬
‫ﻟﻠﺘﻨﺒﺆﺃﻭ ﺍﺳﺘﻘﺮﺍء ﺍﻟﺮﻣﻮﺯ ﺍﻟﺼﺎﺩﺭﺓ ﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺁﺧﺮﻳﻦ‪.‬‬

‫ﺁﻟﻴﺎﺕﺗﻮﻟﻴﺪ ﺍﻟﺮﻣﻮﺯ ﺍﻷﻛﺜﺮ ﻓﻌﺎﻟﻴﺔ ﻫﻲ ﺗﻠﻚ ﺍﻟﺘﻲ‪:‬‬

‫ﺍﺳﺘﺨﺪﻡﻣﺠﻤﻮﻋﺔ ﻛﺒﻴﺮﺓ ﻟﻠﻐﺎﻳﺔ ﻣﻦ ﺍﻟﻘﻴﻢ ﺍﻟﻤﻤﻜﻨﺔ‬ ‫‪-‬‬

‫ﺗﺤﺘﻮﻱﻋﻠﻰ ﻣﺼﺪﺭ ﻗﻮﻱ ﻟﻠﻌﺸﻮﺍﺉﻴﺔ ﺍﻟﺰﺍﺉﻔﺔ‪ ،‬ﻣﻤﺎ ﻳﻀﻤﻦ ﺍﻧﺘﺸﺎﺭﺍً ﻣﺘﺴﺎﻭﻳﺎً ﻭﻏﻴﺮ ﻣﺘﻮﻗﻊ‬ ‫‪-‬‬

‫ﻟﻠﺮﻣﻮﺯﻋﺒﺮ ﻣﺠﻤﻮﻋﺔ ﺍﻟﻘﻴﻢ ﺍﻟﻤﺤﺘﻤﻠﺔ‬

‫ﻣﻦﺣﻴﺚ ﺍﻟﻤﺒﺪﺃ‪ ،‬ﻳﻤُﻜﻦ ﺗﺨﻤﻴﻦ ﺃﻱ ﻋﻨﺼﺮ ﻣﻬﻤﺎ ﻛﺎﻥ ﻃﻮﻟﻪ ﻭﺗﻌﻘﻴﺪﻩ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺍﻟﻘﻮﺓ ﺍﻟﻐﺎﺷﻤﺔ‬
‫ﺇﺫﺍﺗﻮﺍﻓﺮ ﺍﻟﻮﻗﺖ ﻭﺍﻟﻤﻮﺍﺭﺩ ﺍﻟﻜﺎﻓﻴﺔ‪ .‬ﺍﻟﻬﺪﻑ ﻣﻦ ﺗﺼﻤﻴﻢ ﺁﻟﻴﺔ ﻟﺘﻮﻟﻴﺪ ﺭﻣﻮﺯ ﻗﻮﻳﺔ ﻫﻮ ﺃﻥ ﻳﻜﻮﻥ ﻣﻦ‬
‫ﺍﻟﻤﺴﺘﺒﻌﺪﺟﺪﺍً ﺃﻥ ﻳﻨﺠﺢ ﻣﻬﺎﺟﻢ ﻣﺼُﻤﻢ‪ ،‬ﻳﻤﺘﻠﻚ ﻧﻄﺎﻗﺎً ﺗﺮﺩﺩﻳﺎً ﻭﻣﻮﺍﺭﺩ ﻣﻌﺎﻟﺠﺔ ﺿﺨﻤﺔ‪ ،‬ﻓﻲ ﺗﺨﻤﻴﻦ‬
‫ﺭﻣﺰﺻﺎﻟﺢ ﻭﺍﺣﺪ ﺧﻼﻝ ﻓﺘﺮﺓ ﺻﻼﺣﻴﺘﻪ‪.‬‬

‫ﻳﺠﺐﺃﻻ ﺗﺘﻜﻮﻥ ﺍﻟﺮﻣﻮﺯ ﺇﻻ ﻣﻦ ﻣﻌُﺮﻑِّ ﻳﺴﺘﺨﺪﻣﻪ ﺍﻟﺨﺎﺩﻡ ﻟﺘﺤﺪﻳﺪ ﻛﺎﺉﻦ ﺍﻟﺠﻠﺴﺔ ﺫﻱ ﺍﻟﺼﻠﺔ ﺍﻟﻤﺮُﺍﺩ‬
‫ﺍﺳﺘﺨﺪﺍﻣﻪﻟﻤﻌﺎﻟﺠﺔ ﻃﻠﺐ ﺍﻟﻤﺴﺘﺨﺪﻡ‪ .‬ﻳﺠﺐ ﺃﻻ ﻳﺤﺘﻮﻱ ﺍﻟﺮﻣﺰ ﻋﻠﻰ ﺃﻱ ﻣﻌﻨﻰ ﺃﻭ ﺑﻨﻴﺔ‪ ،‬ﺳﻮﺍء ًﻛﺎﻧﺖ‬
‫ﻇﺎﻫﺮﺓﺃﻭ ﻣﻐُﻠﻔَّﺔ ﺑﻄﺒﻘﺎﺕ ﻣﻦ ﺍﻟﺘﺸﻔﻴﺮ ﺃﻭ ﺍﻟﺘﻌﺘﻴﻢ‪ .‬ﻳﺠﺐ ﺗﺨﺰﻳﻦ ﺟﻤﻴﻊ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺍﻟﻤﺘﻌﻠﻘﺔ ﺑﻤﺎﻟﻚ‬
‫ﺍﻟﺠﻠﺴﺔﻭﺣﺎﻟﺘﻬﺎ ﻋﻠﻰ ﺍﻟﺨﺎﺩﻡ ﻓﻲ ﻛﺎﺉﻦ ﺍﻟﺠﻠﺴﺔ ﺍﻟﺬﻱ ﻳﺘﻮﺍﻓﻖ ﻣﻌﻪ ﺭﻣﺰ ﺍﻟﺠﻠﺴﺔ‪.‬‬

‫ﻛﻦﺣﺬﺭﺍً ﻋﻨﺪ ﺍﺧﺘﻴﺎﺭ ﻣﺼﺪﺭ ﺍﻟﻌﺸﻮﺍﺉﻴﺔ‪ .‬ﻳﺠﺐ ﻋﻠﻰ ﺍﻟﻤﻄﻮﺭﻳﻦ ﺃﻥ ﻳﺪﺭﻛﻮﺍ ﺃﻥ ﺍﻟﻤﺼﺎﺩﺭ ﺍﻟﻤﺨﺘﻠﻔﺔ‬
‫ﺍﻟﻤﺘﺎﺣﺔﻟﻬﻢ ﻗﺪ ﺗﺨﺘﻠﻒ ﻓﻲ ﻗﻮﺗﻬﺎ‪.‬‬
‫‪249‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬

‫ﺑﺸﻜﻞﻣﻠﺤﻮﻅ‪ .‬ﺍﻟﺒﻌﺾ‪ ،‬ﻣﺜﻞ‪،‬ﻋﺸﻮﺍﺉﻲ‪java.util.‬ﺗﻌُﺪ ﻫﺬﻩ ﺍﻟﺨﻮﺍﺭﺯﻣﻴﺎﺕ ﻣﻔﻴﺪﺓ ًﻟﻠﻐﺎﻳﺔ ﻷﻏﺮﺍﺽ ٍ‬

‫ﻋﺪﻳﺪﺓﺗﺘﻄﻠﺐ ﻣﺼﺪﺭﺍً ﻟﻠﻤﺪﺧﻼﺕ ﺍﻟﻤﺘﻐﻴﺮﺓ‪ .‬ﻭﻟﻜﻦ ﻳﻤُﻜﻦ ﺍﺳﺘﻘﺮﺍءﻫﺎ ﻓﻲ ﻛﻼ ﺍﻻﺗﺠﺎﻫﻴﻦ ﺍﻷﻣﺎﻣﻲ‬
‫ﻭﺍﻟﺨﻠﻔﻲﺑﻴﻘﻴﻦ ٍﺗﺎﻡ ﺑﻨﺎء ًﻋﻠﻰ ﻣﺨُﺮﺝ ﻭﺍﺣﺪ‪ .‬ﻳﻨﺒﻐﻲ ﻋﻠﻰ ﺍﻟﻤﻄﻮﺭﻳﻦ ﺩﺭﺍﺳﺔ ﺍﻟﺨﺼﺎﺉﺺ ﺍﻟﺮﻳﺎﺿﻴﺔ‬
‫ﻟﻠﺨﻮﺍﺭﺯﻣﻴﺎﺕﺍﻟﻔﻌﻠﻴﺔ ﺍﻟﻤﺴُﺘﺨﺪﻣﺔ ﺿﻤﻦ ﻣﺼﺎﺩﺭ ﻋﺸﻮﺍﺉﻴﺔ ﻣﺨُﺘﻠﻔﺔ ﻣﺘُﺎﺣﺔ‪ ،‬ﻭﻗﺮﺍءﺓ ﺍﻟﻮﺛﺎﺉﻖ ﺫﺍﺕ‬
‫ﺍﻟﺼﻠﺔﺣﻮﻝ ﺍﻻﺳﺘﺨﺪﺍﻣﺎﺕ ﺍﻟﻤﻮُﺻﻰ ﺑﻬﺎ ﻟﻮﺍﺟﻬﺎﺕ ﺑﺮﻣﺠﺔ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ )‪ (APIs‬ﺍﻟﻤﺨُﺘﻠﻔﺔ‪ .‬ﺑﺸﻜﻞ‬
‫ﻋﺎﻡ‪،‬ﺇﺫﺍ ﻟﻢ ﺗﻮُﺻﻒ ﺧﻮﺍﺭﺯﻣﻴﺔ ٌﻣﺎ ﺻﺮﺍﺣﺔ ًﺑﺄﻧﻬﺎ ﺁﻣﻨﺔ ﺗﺸﻔﻴﺮﻳﺎً‪ ،‬ﻓﻴﺠﺐ ﺍﻓﺘﺮﺍﺽ ﺇﻣﻜﺎﻧﻴﺔ ﺍﻟﺘﻨﺒﺆ ﺑﻬﺎ‪.‬‬

‫ﻣﻠﺤﻮﻇﺔﺑﻌﺾ ﻣﺼﺎﺩﺭ ﺍﻟﻌﺸﻮﺍﺉﻴﺔ ﻋﺎﻟﻴﺔ ﺍﻟﻘﻮﺓ ﺗﺴﺘﻐﺮﻕ ﻭﻗﺘﺎً ﻃﻮﻳﻼ ًﻹﺭﺟﺎﻉ ﺍﻟﻘﻴﻤﺔ ﺍﻟﺘﺎﻟﻴﺔ ﻓﻲ‬
‫ﺗﺴﻠﺴﻞﻣﺨﺮﺟﺎﺗﻬﺎ‪ ،‬ﻭﺫﻟﻚ ﺑﺴﺒﺐ ﺍﻟﺨﻄﻮﺍﺕ ﺍﻟﺘﻲ ﺗﺘﺨﺬﻫﺎ ﻟﻠﺤﺼﻮﻝ ﻋﻠﻰ ﺇﻧﺘﺮﻭﺑﻴﺎ ﻛﺎﻓﻴﺔ )ﻣﺜﻞ‬
‫ﺃﺣﺪﺍﺙﺍﻟﻨﻈﺎﻡ(‪ .‬ﻟﺬﻟﻚ‪ ،‬ﻗﺪ ﻻ ﺗﻨُﺘﺞ ﺍﻟﻘﻴﻢ ﺑﺎﻟﺴﺮﻋﺔ ﺍﻟﻜﺎﻓﻴﺔ ﻟﺘﻮﻟﻴﺪ ﺭﻣﻮﺯ ﻟﺒﻌﺾ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﻋﺎﻟﻴﺔ‬
‫ﺍﻟﺤﺠﻢ‪.‬‬

‫ﺑﺎﻹﺿﺎﻓﺔﺇﻟﻰ ﺍﺧﺘﻴﺎﺭ ﺃﻗﻮﻯ ﻣﺼﺪﺭ ﻣﻤﻜﻦ ﻟﻠﻌﺸﻮﺍﺉﻴﺔ‪ ،‬ﻳﻨُﺼﺢ ﺑﺈﺩﺧﺎﻝ ﻣﻌﻠﻮﻣﺎﺕ ﺣﻮﻝ ﺍﻟﻄﻠﺐ‬
‫ﺍﻟﻔﺮﺩﻱﺍﻟﺬﻱ ﻳﻮُﻟﺪّ ﺍﻟﺮﻣﺰ ﻣﻦ ﺃﺟﻠﻪ ﻛﻤﺼﺪﺭ ﻟﻼﻧﺘﺮﻭﺑﻴﺎ‪ .‬ﻗﺪ ﻻ ﺗﻜﻮﻥ ﻫﺬﻩ ﺍﻟﻤﻌﻠﻮﻣﺎﺕ ﺧﺎﺻﺔ ﺑﻬﺬﺍ‬
‫ﺍﻟﻄﻠﺐ‪،‬ﻭﻟﻜﻨﻬﺎ ﻗﺪ ﺗﺴُﻬﻢ ﺑﺸﻜﻞ ﻓﻌﺎّﻝ ﻓﻲ ﻣﻌﺎﻟﺠﺔ ﺃﻱ ﻧﻘﺎﻁ ﺿﻌﻒ ﻓﻲ ﻣﻮُﻟﺪّ ﺍﻷﺭﻗﺎﻡ ﺷﺒﻪ‬
‫ﺍﻟﻌﺸﻮﺍﺉﻴﺔﺍﻷﺳﺎﺳﻲ ﺍﻟﻤﺴُﺘﺨﺪﻡ‪ .‬ﺇﻟﻴﻚ ﺑﻌﺾ ﺍﻷﻣﺜﻠﺔ ﻋﻠﻰ ﺍﻟﻤﻌﻠﻮﻣﺎﺕ ﺍﻟﺘﻲ ﻳﻤُﻜﻦ ﺩﻣﺠﻬﺎ‪:‬‬

‫ﻋﻨﻮﺍﻥ‪ IP‬ﺍﻟﻤﺼﺪﺭ ﻭﺭﻗﻢ ﺍﻟﻤﻨﻔﺬ ﺍﻟﺬﻱ ﺗﻢ ﺍﺳﺘﻼﻡ ﺍﻟﻄﻠﺐ ﻣﻨﻪ‬ ‫‪-‬‬

‫ﺍﻝﻭﻛﻴﻞ ﺍﻟﻤﺴﺘﺨﺪﻡﺭﺃﺱ ﺍﻟﺼﻔﺤﺔ ﻓﻲ ﺍﻟﻄﻠﺐ‬ ‫‪-‬‬

‫ﻭﻗﺖﺍﻟﻄﻠﺐ ﺑﺎﻟﻤﻠﻠﻲ ﺛﺎﻧﻴﺔ‬ ‫‪-‬‬

‫ﺗﺘﻤﺜﻞﺇﺣﺪﻯ ﺍﻟﻄﺮﻕ ﺍﻟﻔﻌﺎﻟﺔ ﻟﻠﻐﺎﻳﺔ ﻟﺪﻣﺞ ﻫﺬﻩ ﺍﻹﻧﺘﺮﻭﺑﻴﺎ ﻓﻲ ﺇﻧﺸﺎء ﺳﻠﺴﻠﺔ ﻧﺼﻴﺔ ﺗﺠﻤﻊ ﺑﻴﻦ ﺭﻗﻢ‬
‫ﺷﺒﻪﻋﺸﻮﺍﺉﻲ‪ ،‬ﻭﻣﺠﻤﻮﻋﺔ ﻣﺘﻨﻮﻋﺔ ﻣﻦ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺍﻟﺨﺎﺻﺔ ﺑﺎﻟﻄﻠﺐ ﻛﻤﺎ ﻫﻮ ﻣﺪُﺭﺝ‪ ،‬ﻭﺳﻠﺴﻠﺔ ﻧﺼﻴﺔ‬
‫ﺳﺮﻳﺔﻻ ﻳﻌﺮﻓﻬﺎ ﺇﻻ ﺍﻟﺨﺎﺩﻡ‪ ،‬ﻭﺗﻮُﻟﺪّ ﻣﻦ ﺟﺪﻳﺪ ﻋﻨﺪ ﻛﻞ ﺇﻋﺎﺩﺓ ﺗﺸﻐﻴﻞ‪ .‬ﺛﻢ ﺗﺆُﺧﺬ ﺗﺠﺰﺉﺔ ﻣﻨﺎﺳﺒﺔ ﻣﻦ‬
‫ﻫﺬﻩﺍﻟﺴﻠﺴﻠﺔ )ﺑﺎﺳﺘﺨﺪﺍﻡ‪ ،‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ SHA-256 ،‬ﻭﻗﺖ ﻛﺘﺎﺑﺔ ﻫﺬﻩ ﺍﻟﺴﻄﻮﺭ( ﻹﻧﺘﺎﺝ ﺳﻠﺴﻠﺔ‬
‫ﻧﺼﻴﺔﺛﺎﺑﺘﺔ ﺍﻟﻄﻮﻝ ﻭﺳﻬﻠﺔ ﺍﻹﺩﺍﺭﺓ‪ ،‬ﻳﻤﻜﻦ ﺍﺳﺘﺨﺪﺍﻣﻬﺎ ﻛﺮﻣﺰ‪) .‬ﻳﺆﺩﻱ ﻭﺿﻊ ﺍﻟﻌﻨﺎﺻﺮ ﺍﻷﻛﺜﺮ ﺗﻨﻮﻋﺎً ﻓﻲ‬
‫ﺑﺪﺍﻳﺔﻣﺪُﺧﻼﺕ ﺍﻟﺘﺠﺰﺉﺔ ﺇﻟﻰ ﺗﻌﻈﻴﻢ ﺗﺄﺛﻴﺮ "ﺍﻻﻧﻬﻴﺎﺭ ﺍﻟﺠﻠﻴﺪﻱ" ﻓﻲ ﺧﻮﺍﺭﺯﻣﻴﺔ ﺍﻟﺘﺠﺰﺉﺔ(‪.‬‬

‫ﻧﺼﻴﺤﺔﺑﻌﺪ ﺍﺧﺘﻴﺎﺭ ﺧﻮﺍﺭﺯﻣﻴﺔ ﻟﺘﻮﻟﻴﺪ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ‪ ،‬ﻳﻤُﻜﻨﻚ ﺗﺠﺮﺑﺔ ﺫﻟﻚ ﺑﺘﺨﻴﻞ ﺃﻥ ﻣﺼﺪﺭ‬
‫ﺍﻟﻌﺸﻮﺍﺉﻴﺔﺍﻟﺰﺍﺉﻔﺔ ﻟﺪﻳﻚ ﻣﻌُﻄﻞّ ﻭﻳﻌُﻴﺪ ﺍﻟﻘﻴﻤﺔ ﻧﻔﺴﻬﺎ ﺩﺍﺉﻤﺎً‪ .‬ﻓﻲ ﻫﺬﻩ ﺍﻟﺤﺎﻟﺔ‪ ،‬ﻫﻞ ﺳﻴﺘﻤﻜﻦ‬
‫ﻣﻬُﺎﺟﻢﻳﺤﺼﻞ ﻋﻠﻰ ﻋﻴﻨﺔ ﻛﺒﻴﺮﺓ ﻣﻦ ﺍﻟﺮﻣﻮﺯ ﻣﻦ ﺍﻟﺘﻄﺒﻴﻖ ﻣﻦ ﺍﺳﺘﻘﺮﺍء ﺍﻟﺮﻣﻮﺯ ﺍﻟﻤﺼُﺪﺭﺓ ﻟﻤﺴﺘﺨﺪﻣﻴﻦ‬
‫ﺁﺧﺮﻳﻦ؟ﺑﺎﺳﺘﺨﺪﺍﻡ ﺍﻟﺼﻴﻐﺔ ﺍﻟﻤﻮﺿﺤﺔ ﻫﻨﺎ‪ ،‬ﻳﺴُﺘﺒﻌﺪ ﺣﺪﻭﺙ ﺫﻟﻚ ﺑﺸﻜﻞ ﻛﺒﻴﺮ‪ ،‬ﺣﺘﻰ ﻣﻊ ﺍﻟﻤﻌﺮﻓﺔ‬
‫ﺍﻟﻜﺎﻣﻠﺔﺑﺎﻟﺨﻮﺍﺭﺯﻣﻴﺔ ﺍﻟﻤﺴُﺘﺨﺪﻣﺔ‪ .‬ﻋﻨﻮﺍﻥ ‪ IP‬ﺍﻟﻤﺼﺪﺭ‪ ،‬ﻭﺭﻗﻢ ﺍﻟﻤﻨﻔﺬ‪،‬ﻭﻛﻴﻞ ﺍﻟﻤﺴﺘﺨﺪﻡﻳﻮُﻟﺪّ ﻛﻞ ٌّﻣﻦ‬
‫ﺭﺃﺱﺍﻟﺼﻔﺤﺔ ﻭﻭﻗﺖ ﺍﻟﻄﻠﺐ ﻣﻌﺎً ﻛﻤﻴﺔ ﻫﺎﺉﻠﺔ ﻣﻦ ﺍﻹﻧﺘﺮﻭﺑﻴﺎ‪ .‬ﻭﺣﺘﻰ ﻣﻊ ﺍﻟﻤﻌﺮﻓﺔ ﺍﻟﺘﺎﻣﺔ ﺑﻬﻤﺎ‪ ،‬ﻟﻦ‬
‫ﻳﺘﻤﻜﻦﺍﻟﻤﻬﺎﺟﻢ ﻣﻦ ﺇﻧﺘﺎﺝ ﺍﻟﺮﻣﺰ ﺍﻟﻤﻘﺎﺑﻞ ﺩﻭﻥ ﻣﻌﺮﻓﺔ ﺍﻟﺴﻠﺴﻠﺔ ﺍﻟﺴﺮﻳﺔ ﺍﻟﺘﻲ ﻳﺴﺘﺨﺪﻣﻬﺎ ﺍﻟﺨﺎﺩﻡ‪.‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬ ‫‪250‬‬

‫ﺣﻤﺎﻳﺔﺍﻟﺮﻣﻮﺯ ﻃﻮﺍﻝ ﺩﻭﺭﺓ ﺣﻴﺎﺗﻬﺎ‬

‫ﺍﻵﻥﺑﻌﺪ ﺃﻥ ﻗﻤﺖ ﺑﺈﻧﺸﺎء ﺭﻣﺰ ﻗﻮﻱ ﻻ ﻳﻤﻜﻦ ﺍﻟﺘﻨﺒﺆ ﺑﻘﻴﻤﺘﻪ‪ ،‬ﻳﺠﺐ ﺣﻤﺎﻳﺔ ﻫﺬﺍ ﺍﻟﺮﻣﺰ ﻃﻮﺍﻝ ﺩﻭﺭﺓ‬
‫ﺣﻴﺎﺗﻪﻣﻦ ﺍﻹﻧﺸﺎء ﺣﺘﻰ ﺍﻟﺘﺨﻠﺺ ﻣﻨﻪ‪ ،‬ﻟﻀﻤﺎﻥ ﻋﺪﻡ ﺍﻟﻜﺸﻒ ﻋﻨﻪ ﻷﻱ ﺷﺨﺺ ﺁﺧﺮ ﻏﻴﺮ ﺍﻟﻤﺴﺘﺨﺪﻡ‬
‫ﺍﻟﺬﻱﺗﻢ ﺇﺻﺪﺍﺭﻩ ﻟﻪ‪:‬‬
‫ﻳﺠﺐﺇﺭﺳﺎﻝ ﺍﻟﺮﻣﺰ ﻋﺒﺮ ‪ HTTPS‬ﻓﻘﻂ‪ .‬ﺃﻱ ﺭﻣﺰ ﻳﺮُﺳﻞ ﺑﻨﺺ ﻋﺎﺩﻱ ﻳﻌُﺘﺒﺮ ﻣﺸُﻮﻫّﺎً‪ ،‬ﺃﻱ ﻻ ﻳﺆُﻛﺪّ‬ ‫‪-‬‬

‫ﻫﻮﻳﺔﺍﻟﻤﺴﺘﺨﺪﻡ‪ .‬ﻓﻲ ﺣﺎﻝ ﺍﺳﺘﺨﺪﺍﻡ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﺭﺗﺒﺎﻁ ‪ HTTP‬ﻹﺭﺳﺎﻝ ﺍﻟﺮﻣﻮﺯ‪ ،‬ﻳﺠﺐ‬
‫ﻭﺿﻊﻋﻼﻣﺔ ﻋﻠﻴﻬﺎ‪.‬ﻳﺆﻣﻦﻟﻤﻨﻊ ﻣﺘﺼﻔﺢ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻣﻦ ﺇﺭﺳﺎﻟﻬﺎ ﻋﺒﺮ ‪ .HTTP‬ﺇﻥ ﺃﻣﻜﻦ‪ ،‬ﻳﺠﺐ‬
‫ﺍﺳﺘﺨﺪﺍﻡ‪ HTTPS‬ﻟﺠﻤﻴﻊ ﺻﻔﺤﺎﺕ ﺍﻟﺘﻄﺒﻴﻖ‪ ،‬ﺑﻤﺎ ﻓﻲ ﺫﻟﻚ ﺍﻟﻤﺤﺘﻮﻯ ﺍﻟﺜﺎﺑﺖ ﻣﺜﻞ ﺻﻔﺤﺎﺕ‬
‫ﺍﻟﻤﺴﺎﻋﺪﺓﻭﺍﻟﺼﻮﺭ ﻭﻣﺎ ﺇﻟﻰ ﺫﻟﻚ‪ .‬ﺇﺫﺍ ﻟﻢ ﻳﻜﻦ ﺫﻟﻚ ﻣﻄﻠﻮﺑﺎً‪ ،‬ﻭﻛﺎﻧﺖ ﺧﺪﻣﺔ ‪ HTTP‬ﻻ ﺗﺰﺍﻝ‬
‫ﻣﻄُﺒﻘّﺔ‪،‬ﻓﻴﺠﺐ ﻋﻠﻰ ﺍﻟﺘﻄﺒﻴﻖ ﺇﻋﺎﺩﺓ ﺗﻮﺟﻴﻪ ﺃﻱ ﻃﻠﺒﺎﺕ ﻟﻤﺤﺘﻮﻯ ﺣﺴﺎﺱ )ﺑﻤﺎ ﻓﻲ ﺫﻟﻚ‬
‫ﺻﻔﺤﺔﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ( ﺇﻟﻰ ﺧﺪﻣﺔ ‪ .HTTPS‬ﻋﺎﺩﺓ ًﻣﺎ ﺗﻜﻮﻥ ﺍﻟﻤﻮﺍﺭﺩ ﺍﻟﺜﺎﺑﺘﺔ‪ ،‬ﻣﺜﻞ ﺻﻔﺤﺎﺕ‬
‫ﺍﻟﻤﺴﺎﻋﺪﺓ‪،‬ﻏﻴﺮ ﺣﺴﺎﺳﺔ‪ ،‬ﻭﻳﻤﻜﻦ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻴﻬﺎ ﺩﻭﻥ ﺍﻟﺤﺎﺟﺔ ﺇﻟﻰ ﺟﻠﺴﺔ ﻣﺼُﺎﺩﻗﺔ‪ .‬ﻟﺬﻟﻚ‪،‬‬
‫ﻳﻤﻜﻦﻋﻤﻞ ﻧﺴﺨﺔ ﺍﺣﺘﻴﺎﻃﻴﺔ ﻻﺳﺘﺨﺪﺍﻡ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﺍﻵﻣﻨﺔ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺗﻌﻠﻴﻤﺎﺕ‬
‫ﻧﻄﺎﻕﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﻟﻤﻨﻊ ﺇﺭﺳﺎﻝ ﺍﻟﺮﻣﻮﺯ ﻓﻲ ﻃﻠﺒﺎﺕ ﻫﺬﻩ ﺍﻟﻤﻮﺍﺭﺩ‪.‬‬

‫ﻳﺠﺐﻋﺪﻡ ﺇﺭﺳﺎﻝ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ ﻋﺒﺮ ﻋﻨﻮﺍﻥ ‪ ،URL‬ﻷﻥ ﺫﻟﻚ ﻳﺴُﻬﻞّ ﻫﺠﻤﺎﺕ ﺗﺜﺒﻴﺖ ﺍﻟﺠﻠﺴﺔ‬ ‫‪-‬‬

‫ﻭﻳﺆﺩﻱﺇﻟﻰ ﻇﻬﻮﺭ ﺍﻟﺮﻣﻮﺯ ﻓﻲ ﺁﻟﻴﺎﺕ ﺗﺴﺠﻴﻞ ﻣﺘﻌﺪﺩﺓ‪ .‬ﻓﻲ ﺑﻌﺾ ﺍﻟﺤﺎﻻﺕ‪ ،‬ﻳﺴﺘﺨﺪﻡ‬
‫ﺍﻟﻤﻄﻮﺭﻭﻥﻫﺬﻩ ﺍﻟﺘﻘﻨﻴﺔ ﻟﺘﻨﻔﻴﺬ ﺍﻟﺠﻠﺴﺎﺕ ﻓﻲ ﺍﻟﻤﺘﺼﻔﺤﺎﺕ ﺍﻟﺘﻲ ﻋﻄﻠّﺖ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ‬
‫ﺍﻻﺭﺗﺒﺎﻁ‪.‬ﻭﻣﻊ ﺫﻟﻚ‪ ،‬ﻓﺈﻥ ﺍﻟﻄﺮﻳﻘﺔ ﺍﻷﻓﻀﻞ ﻟﺘﺤﻘﻴﻖ ﺫﻟﻚ ﻫﻲ ﺍﺳﺘﺨﺪﺍﻡﺑﺮﻳﺪﻃﻠﺒﺎﺕ ﻟﺠﻤﻴﻊ‬
‫ﺭﻣﻮﺯﺍﻟﺘﻨﻘﻞ ﻭﺍﻟﺘﺨﺰﻳﻦ ﻓﻲ ﺣﻘﻞ ﻣﺨﻔﻲ ﻓﻲ ﻧﻤﻮﺫﺝ ‪.HTML‬‬

‫ﻳﺠﺐﺗﻔﻌﻴﻞ ﺧﺎﺻﻴﺔ ﺗﺴﺠﻴﻞ ﺍﻟﺨﺮﻭﺝ‪ .‬ﺳﻴﺆﺩﻱ ﺫﻟﻚ ﺇﻟﻰ ﺣﺬﻑ ﺟﻤﻴﻊ ﻣﻮﺍﺭﺩ ﺍﻟﺠﻠﺴﺔ‬ ‫‪-‬‬

‫ﺍﻟﻤﺨُﺰﻧّﺔﻋﻠﻰ ﺍﻟﺨﺎﺩﻡ ﻭﺇﺑﻄﺎﻝ ﺭﻣﺰ ﺍﻟﺠﻠﺴﺔ‪.‬‬

‫ﻳﺠﺐﺗﻨﻔﻴﺬ ﺍﻧﺘﻬﺎء ﺻﻼﺣﻴﺔ ﺍﻟﺠﻠﺴﺔ ﺑﻌﺪ ﻓﺘﺮﺓ ﻣﻨﺎﺳﺒﺔ ﻣﻦ ﻋﺪﻡ ﺍﻟﻨﺸﺎﻁ )ﻣﺜﻞ ‪ ١٠‬ﺩﻗﺎﺉﻖ(‪.‬‬ ‫‪-‬‬

‫ﺳﻴﺆﺩﻱﻫﺬﺍ ﺇﻟﻰ ﻧﻔﺲ ﺍﻟﻨﺘﻴﺠﺔ ﻛﻤﺎ ﻟﻮ ﺳﺠﻞّ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺧﺮﻭﺟﻪ ﺻﺮﺍﺣﺔ‪ً.‬‬

‫ﻳﺠﺐﻣﻨﻊ ﻋﻤﻠﻴﺎﺕ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﺍﻟﻤﺘﺰﺍﻣﻨﺔ‪ .‬ﻓﻲ ﻛﻞ ﻣﺮﺓ ﻳﺴُﺠﻞّ ﻓﻴﻬﺎ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺩﺧﻮﻟﻪ‪،‬‬ ‫‪-‬‬

‫ﻳﺼُﺪﺭﺭﻣﺰ ﺟﻠﺴﺔ ﻣﺨﺘﻠﻒ‪ ،‬ﻭﻳﺤُﺬﻑ ﺃﻱ ﺟﻠﺴﺔ ﺣﺎﻟﻴﺔ ﺗﺎﺑﻌﺔ ﻟﻪ ﻛﻤﺎ ﻟﻮ ﺃﻧﻪ ﺳﺠﻞّ ﺧﺮﻭﺟﻪ ﻣﻨﻬﺎ‪.‬‬
‫ﻋﻨﺪﺣﺪﻭﺙ ﺫﻟﻚ‪ ،‬ﻗﺪ ﻳﺨُﺰﻥّ ﺍﻟﺮﻣﺰ ﺍﻟﻘﺪﻳﻢ ﻟﻔﺘﺮﺓ ﻣﻦ ﺍﻟﻮﻗﺖ‪ .‬ﻳﺠﺐ ﺃﻥ ﺗﺮُﺳﻞِ ﺃﻱ ﻃﻠﺒﺎﺕ‬
‫ﻻﺣﻘﺔﻣﺴُﺘﻠﻤَﺔ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺍﻟﺮﻣﺰ ﺗﻨﺒﻴﻬﺎً ﺃﻣﻨﻴﺎً ﻟﻠﻤﺴﺘﺨﺪﻡ ﻳﻔُﻴﺪ ﺑﺈﻧﻬﺎء ﺍﻟﺠﻠﺴﺔ ﺑﺴﺒﺐ ﺗﺴﺠﻴﻞ‬
‫ﺩﺧﻮﻟﻪﻣﻦ ﻣﻮﻗﻊ ﻣﺨﺘﻠﻒ‪.‬‬

‫ﺇﺫﺍﻛﺎﻥ ﺍﻟﺘﻄﺒﻴﻖ ﻳﺤﺘﻮﻱ ﻋﻠﻰ ﺃﻱ ﻭﻇﻴﻔﺔ ﺇﺩﺍﺭﻳﺔ ﺃﻭ ﺗﺸﺨﻴﺼﻴﺔ ﺗﻤُﻜﻦّ ﻣﻦ ﻋﺮﺽ ﺭﻣﻮﺯ‬ ‫‪-‬‬

‫ﺍﻟﺠﻠﺴﺔ‪،‬ﻓﻴﺠﺐ ﺣﻤﺎﻳﺔ ﻫﺬﻩ ﺍﻟﻮﻇﻴﻔﺔ ﺑﺸﻜﻞ ﻗﻮﻱ ﻣﻦ ﺍﻟﻮﺻﻮﻝ ﻏﻴﺮ ﺍﻟﻤﺼﺮﺡ ﺑﻪ‪ .‬ﻓﻲ ﻣﻌﻈﻢ‬
‫ﺍﻟﺤﺎﻻﺕ‪،‬ﻻ ﺣﺎﺟﺔ ﻟﻬﺬﻩ ﺍﻟﻮﻇﻴﻔﺔ ﻟﻌﺮﺽ ﺭﻣﺰ ﺍﻟﺠﻠﺴﺔ ﺍﻟﻔﻌﻠﻲ‪ .‬ﺑﻞ ﻳﺠﺐ ﺃﻥ ﺗﺤﺘﻮﻱ ﻋﻠﻰ‬
‫ﺗﻔﺎﺻﻴﻞﻛﺎﻓﻴﺔ ﺣﻮﻝ ﻣﺎﻟﻚ ﺍﻟﺠﻠﺴﺔ ﻷﻱ‪...‬‬
‫‪251‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬

‫ﻣﻬﺎﻡﺍﻟﺪﻋﻢ ﻭﺍﻟﺘﺸﺨﻴﺺ ﺍﻟﺘﻲ ﻳﺠﺐ ﺍﻟﻘﻴﺎﻡ ﺑﻬﺎ‪ ،‬ﺩﻭﻥ ﺍﻟﻜﺸﻒ ﻋﻦ ﺭﻣﺰ ﺍﻟﺠﻠﺴﺔ ﺍﻟﺬﻱ ﻗﺪﻣﻪ‬
‫ﺍﻟﻤﺴﺘﺨﺪﻡﻟﺘﺤﺪﻳﺪ ﺟﻠﺴﺘﻪ‪.‬‬
‫ﻳﺠﺐﺿﺒﻂ ﻧﻄﺎﻕ ﻧﻄﺎﻕ ﻭﻣﺴﺎﺭ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﺭﺗﺒﺎﻁ ﺟﻠﺴﺔ ﺍﻟﺘﻄﺒﻴﻖ ﺑﺄﻗﺼﻰ ﻗﺪﺭ ﻣﻤﻜﻦ‬ ‫‪-‬‬

‫ﻣﻦﺍﻟﺘﻘﻴﻴﺪ‪ .‬ﻏﺎﻟﺒﺎً ﻣﺎ ﺗﻨُﺸﺄ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﺫﺍﺕ ﺍﻟﻨﻄﺎﻕ ﺍﻟﻮﺍﺳﻊ ﺟﺪﺍً ﺑﻮﺍﺳﻄﺔ‬
‫ﻣﻨﺼﺎﺕﺗﻄﺒﻴﻘﺎﺕ ﺍﻟﻮﻳﺐ ﺃﻭ ﺧﻮﺍﺩﻡ ﺍﻟﻮﻳﺐ ﺫﺍﺕ ﺍﻟﺘﻜﻮﻳﻦ ﺍﻟﺴﻴﺊ‪ ،‬ﻭﻟﻴﺲ ﺑﻮﺍﺳﻄﺔ ﻣﻄﻮﺭﻱ‬
‫ﺍﻟﺘﻄﺒﻴﻘﺎﺕﺃﻧﻔﺴﻬﻢ‪ .‬ﻳﺠﺐ ﻋﺪﻡ ﺇﻣﻜﺎﻧﻴﺔ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﺃﻱ ﺗﻄﺒﻴﻘﺎﺕ ﻭﻳﺐ ﺃﺧﺮﻯ ﺃﻭ ﻭﻇﺎﺉﻒ‬
‫ﻏﻴﺮﻣﻮﺛﻮﻗﺔ ﻋﺒﺮ ﺃﺳﻤﺎء ﺍﻟﻨﻄﺎﻗﺎﺕ ﺃﻭ ﻣﺴﺎﺭﺍﺕ ﻋﻨﺎﻭﻳﻦ ‪ URL‬ﺍﻟﻤﻀﻤﻨﺔ ﻓﻲ ﻧﻄﺎﻕ ﻣﻠﻔﺎﺕ‬
‫ﺗﻌﺮﻳﻒﺍﺭﺗﺒﺎﻁ ﺍﻟﺘﻄﺒﻴﻖ‪ .‬ﻳﺠﺐ ﺇﻳﻼء ﺍﻫﺘﻤﺎﻡ ﺧﺎﺹ ﻷﻱ ﻧﻄﺎﻗﺎﺕ ﻓﺮﻋﻴﺔ ﻣﻮﺟﻮﺩﺓ ﻻﺳﻢ‬
‫ﺍﻟﻨﻄﺎﻕﺍﻟﻤﺴﺘﺨﺪﻡ ﻟﻠﻮﺻﻮﻝ ﺇﻟﻰ ﺍﻟﺘﻄﺒﻴﻖ‪ .‬ﻓﻲ ﺑﻌﺾ ﺍﻟﺤﺎﻻﺕ‪ ،‬ﻟﻀﻤﺎﻥ ﻋﺪﻡ ﻇﻬﻮﺭ ﻫﺬﻩ‬
‫ﺍﻟﺜﻐﺮﺓﺍﻷﻣﻨﻴﺔ‪ ،‬ﻗﺪ ﻳﻜﻮﻥ ﻣﻦ ﺍﻟﻀﺮﻭﺭﻱ ﺗﻌﺪﻳﻞ ﻧﻈﺎﻡ ﺗﺴﻤﻴﺔ ﺍﻟﻨﻄﺎﻗﺎﺕ ﻭﺍﻟﻤﺴﺎﺭﺍﺕ‬
‫ﺍﻟﻤﺴﺘﺨﺪﻡﻓﻲ ﻣﺨﺘﻠﻒ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﻟﻤﺴﺘﺨﺪﻣﺔ ﺩﺍﺧﻞ ﺍﻟﻤﺆﺳﺴﺔ‪.‬‬

‫ﻳﻨﺒﻐﻲﺍﺗﺨﺎﺫ ﺗﺪﺍﺑﻴﺮ ﻣﺤﺪﺩﺓ ﻟﻠﺪﻓﺎﻉ ﻋﻦ ﺁﻟﻴﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ ﺿﺪ ﻣﺠﻤﻮﻋﺔ ﻣﺘﻨﻮﻋﺔ ﻣﻦ ﺍﻟﻬﺠﻤﺎﺕ‬
‫ﺍﻟﺘﻲﻗﺪ ﻳﺠﺪ ﻣﺴﺘﺨﺪﻣﻮ ﺍﻟﺘﻄﺒﻴﻖ ﺃﻧﻔﺴﻬﻢ ﺃﻫﺪﺍﻓﺎً ﻟﻬﺎ‪:‬‬

‫ﻳﺠﺐﺗﺪﻗﻴﻖ ﻗﺎﻋﺪﺓ ﺑﻴﺎﻧﺎﺕ ﺍﻟﺘﻄﺒﻴﻖ ﺑﺪﻗﺔ ﻟﺘﺤﺪﻳﺪ ﺃﻱ ﺛﻐﺮﺍﺕ ﺃﻣﻨﻴﺔ ﻓﻲ ﺑﺮﻣﺠﺔ ﺍﻟﻤﻮﺍﻗﻊ‬ ‫‪-‬‬

‫ﺍﻟﻤﺸﺘﺮﻛﺔﻭﺇﺯﺍﻟﺘﻬﺎ )ﺍﻧﻈﺮ ﺍﻟﻔﺼﻞ ‪ .(١٢‬ﻳﻤﻜﻦ ﺍﺳﺘﻐﻼﻝ ﻣﻌﻈﻢ ﻫﺬﻩ ﺍﻟﺜﻐﺮﺍﺕ ﻟﻤﻬﺎﺟﻤﺔ ﺁﻟﻴﺎﺕ‬
‫ﺇﺩﺍﺭﺓﺍﻟﺠﻠﺴﺎﺕ‪.‬‬
‫ﻋﻠﻰﻭﺟﻪ ﺍﻟﺨﺼﻮﺹ‪ ،‬ﻳﺘﻢ ﺗﺨﺰﻳﻨﻬﺎ )ﺃﻭﺛﺎﻧﻴﺔ‪-‬ﻃﻠﺐ( ﻳﻤﻜﻦ ﻋﺎﺩﺓ ًﺍﺳﺘﻐﻼﻝ ﻫﺠﻤﺎﺕ ‪XSS‬‬
‫ﻟﻬﺰﻳﻤﺔﻛﻞ ﺩﻓﺎﻉ ﻳﻤﻜﻦ ﺗﺼﻮﺭﻩ ﺿﺪ ﺇﺳﺎءﺓ ﺍﺳﺘﺨﺪﺍﻡ ﺍﻟﺠﻠﺴﺔ ﻭﺍﻻﺧﺘﻄﺎﻑ‪.‬‬
‫ﻻﻳﻘُﺒﻞ ﺃﻱ ﺭﻣﺰ ﻋﺸﻮﺍﺉﻲ ﻳﺮُﺳﻠﻪ ﻣﺴﺘﺨﺪﻣﻮﻥ ﻻ ﻳﺘﻌﺮﻑ ﻋﻠﻴﻬﻢ ﺍﻟﺨﺎﺩﻡ‪ .‬ﻳﺠﺐ ﺇﻟﻐﺎء ﺍﻟﺮﻣﺰ‬ ‫‪-‬‬

‫ﻓﻮﺭﺍًﻣﻦ ﺍﻟﻤﺘﺼﻔﺢ‪ ،‬ﻭﺇﻋﺎﺩﺓ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺇﻟﻰ ﺻﻔﺤﺔ ﺑﺪء ﺍﻟﺘﻄﺒﻴﻖ‪.‬‬

‫ﻳﻤﻜﻦﺃﻥ ﻳﺼﺒﺢ ﺗﺰﻭﻳﺮ ﻃﻠﺒﺎﺕ ﺍﻟﻤﻮﺍﻗﻊ ﺍﻟﻤﺘﻌﺪﺩﺓ ﻭﺍﻟﻬﺠﻤﺎﺕ ﺍﻷﺧﺮﻯ ﻋﻠﻰ ﺍﻟﺠﻠﺴﺎﺕ ﺃﻛﺜﺮ‬ ‫‪-‬‬

‫ﺻﻌﻮﺑﺔﻣﻦ ﺧﻼﻝ ﻃﻠﺐ ﺗﺄﻛﻴﺪ ﻣﻦ ﺧﻄﻮﺗﻴﻦ ﻭ‪/‬ﺃﻭ ﺇﻋﺎﺩﺓ ﺍﻟﻤﺼﺎﺩﻗﺔ ﻗﺒﻞ ﺗﻨﻔﻴﺬ ﺇﺟﺮﺍءﺍﺕ‬
‫ﺣﺎﺳﻤﺔﻣﺜﻞ ﺗﺤﻮﻳﻞ ﺍﻷﻣﻮﺍﻝ‪.‬‬
‫ﻳﻤﻜﻦﺍﻟﺘﺼﺪﻱ ﻟﻬﺠﻤﺎﺕ ﺗﺰﻭﻳﺮ ﻃﻠﺒﺎﺕ ﺍﻟﻤﻮﺍﻗﻊ ﺍﻟﻤﺸﺘﺮﻛﺔ ﺑﻌﺪﻡ ﺍﻻﻋﺘﻤﺎﺩ ﻛﻠﻴﺎً ﻋﻠﻰ ﻣﻠﻔﺎﺕ‬ ‫‪-‬‬

‫ﺗﻌﺮﻳﻒﺍﺭﺗﺒﺎﻁ ‪ HTTP‬ﻟﻨﻘﻞ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ‪ .‬ﻳﺆُﺩﻱ ﺍﺳﺘﺨﺪﺍﻡ ﺁﻟﻴﺔ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﺇﻟﻰ‬
‫ﻇﻬﻮﺭﻫﺬﻩ ﺍﻟﺜﻐﺮﺓ‪ ،‬ﺣﻴﺚ ﻳﺮُﺳﻞ ﺍﻟﻤﺘﺼﻔﺢ ﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﺗﻠﻘﺎﺉﻴﺎً ﺑﻐﺾ ﺍﻟﻨﻈﺮ ﻋﻦ‬
‫ﺳﺒﺐﺍﻟﻄﻠﺐ‪ .‬ﺇﺫﺍ ﻛﺎﻧﺖ ﺍﻟﺮﻣﻮﺯ ﺗﺮُﺳﻞ ﺩﺍﺉﻤﺎً ﻓﻲ ﺣﻘﻞ ﻣﺨﻔﻲ ﺑﻨﻤﻮﺫﺝ ‪ ،HTML‬ﻓﻠﻦ ﻳﺘﻤﻜﻦ‬
‫ﺍﻟﻤﻬﺎﺟﻢﻣﻦ ﺇﻧﺸﺎء ﻧﻤﻮﺫﺝ ﻳﺆُﺩﻱ ﺇﺭﺳﺎﻟﻪ ﺇﻟﻰ ﺇﺟﺮﺍء ﻏﻴﺮ ﻣﺼﺮﺡ ﺑﻪ ﺇﻻ ﺇﺫﺍ ﻛﺎﻥ ﻳﻌﺮﻑ ﻗﻴﻤﺔ‬
‫ﺍﻟﺮﻣﺰﻣﺴﺒﻘﺎً‪ .‬ﻓﻲ ﻫﺬﻩ ﺍﻟﺤﺎﻟﺔ‪ ،‬ﻳﻤﻜﻨﻪ ﺑﺒﺴﺎﻃﺔ ﺗﻨﻔﻴﺬ ﻫﺠﻮﻡ ﺍﺧﺘﻄﺎﻑ ﺑﺴﻴﻂ‪ .‬ﻛﻤﺎ ﻳﻤُﻜﻦ‬
‫ﻟﻠﺮﻣﻮﺯﻟﻜﻞ ﺻﻔﺤﺔ ﺃﻥ ﺗﺴُﺎﻋﺪ ﻓﻲ ﻣﻨﻊ ﻫﺬﻩ ﺍﻟﻬﺠﻤﺎﺕ )ﺍﻧﻈﺮ ﺍﻟﻘﺴﻢ ﺍﻟﺘﺎﻟﻲ(‪.‬‬

‫ﻳﺠﺐﺩﺍﺉﻤﺎً ﺇﻧﺸﺎء ﺟﻠﺴﺔ ﺟﺪﻳﺪﺓ ﺑﻌﺪ ﻧﺠﺎﺡ ﺍﻟﻤﺼﺎﺩﻗﺔ‪ ،‬ﻭﺫﻟﻚ ﻟﻠﺘﺨﻔﻴﻒ ﻣﻦ ﺁﺛﺎﺭ ﻫﺠﻤﺎﺕ‬ ‫‪-‬‬

‫ﺗﺜﺒﻴﺖﺍﻟﺠﻠﺴﺔ‪ .‬ﻋﻨﺪﻣﺎ ﻻ ﻳﺴﺘﺨﺪﻡ ﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﻤﺼﺎﺩﻗﺔ ﻭﻟﻜﻨﻪ ﻳﺴﻤﺢ ﺑﺈﺭﺳﺎﻝ ﺑﻴﺎﻧﺎﺕ‬

‫ﺣﺴﺎﺳﺔ‪،‬ﻳﺼﺒﺢ ﻣﻦ ﺍﻟﺼﻌﺐ ﻣﻮﺍﺟﻬﺔ ﺍﻟﺘﻬﺪﻳﺪ ﺍﻟﺬﻱ ﺗﺸﻜﻠﻪ ﻫﺠﻤﺎﺕ ﺍﻟﺘﺜﺒﻴﺖ‪ .‬ﺃﺣﺪ ﺍﻟﺤﻠﻮﻝ‬
‫ﺍﻟﻤﻤﻜﻨﺔ‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬ ‫‪252‬‬

‫ﺍﻟﻬﺪﻑﻫﻮ ﺍﻟﺤﻔﺎﻅ ﻋﻠﻰ ﺗﺴﻠﺴﻞ ﺍﻟﺼﻔﺤﺎﺕ ﺍﻟﺘﻲ ﺗﺮُﺳﻞ ﺇﻟﻴﻬﺎ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺍﻟﺤﺴﺎﺳﺔ ﺑﺄﻗﺼﺮ‬
‫ﺷﻜﻞﻣﻤﻜﻦ‪ .‬ﺑﻌﺪ ﺫﻟﻚ‪ ،‬ﻳﻤﻜﻨﻚ ﺇﻧﺸﺎء ﺟﻠﺴﺔ ﺟﺪﻳﺪﺓ ﻓﻲ ﺍﻟﺼﻔﺤﺔ ﺍﻷﻭﻟﻰ ﻣﻦ ﻫﺬﺍ ﺍﻟﺘﺴﻠﺴﻞ‬
‫)ﻋﻨﺪ ﺍﻟﻀﺮﻭﺭﺓ‪ ،‬ﻧﺴﺦ ﺃﻱ ﺑﻴﺎﻧﺎﺕ ﻣﻄﻠﻮﺑﺔ ﻣﻦ ﺍﻟﺠﻠﺴﺔ ﺍﻟﺤﺎﻟﻴﺔ‪ ،‬ﻣﺜﻞ ﻣﺤﺘﻮﻳﺎﺕ ﺳﻠﺔ ﺍﻟﺘﺴﻮﻕ(‬
‫‪.‬ﺃﻭ ﻳﻤﻜﻨﻚ ﺍﺳﺘﺨﺪﺍﻡ ﺭﻣﻮﺯ ﻟﻜﻞ ﺻﻔﺤﺔ )ﻣﻮﺿﺤﺔ ﻓﻲ ﺍﻟﻘﺴﻢ ﺍﻟﺘﺎﻟﻲ( ﻟﻤﻨﻊ ﺃﻱ ﻣﻬﺎﺟﻢ ﻳﻌﺮﻑ‬
‫ﺍﻟﺮﻣﺰﺍﻟﻤﺴﺘﺨﺪﻡ ﻓﻲ ﺍﻟﺼﻔﺤﺔ ﺍﻷﻭﻟﻰ ﻣﻦ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﺍﻟﺼﻔﺤﺎﺕ ﺍﻟﻼﺣﻘﺔ‪ .‬ﺑﺎﺳﺘﺜﻨﺎء‬
‫ﺍﻟﺤﺎﻻﺕﺍﻟﻀﺮﻭﺭﻳﺔ ﻟﻠﻐﺎﻳﺔ‪ ،‬ﻳﺠﺐ ﻋﺪﻡ ﻋﺮﺽ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺍﻟﺸﺨﺼﻴﺔ ﻟﻠﻤﺴﺘﺨﺪﻡ‪ .‬ﺣﺘﻰ ﻋﻨﺪ‬
‫ﺍﻟﺤﺎﺟﺔ)ﻣﺜﻞ ﺻﻔﺤﺔ "ﺗﺄﻛﻴﺪ ﺍﻟﻄﻠﺐ" ﺍﻟﺘﻲ ﺗﻌﺮﺽ ﺍﻟﻌﻨﺎﻭﻳﻦ(‪ ،‬ﻳﺠﺐ ﻋﺮﺽ ﺍﻟﻌﻨﺎﺻﺮ‬
‫ﺍﻟﺤﺴﺎﺳﺔﻣﺜﻞ ﺃﺭﻗﺎﻡ ﺑﻄﺎﻗﺎﺕ ﺍﻻﺉﺘﻤﺎﻥ ﻭﻛﻠﻤﺎﺕ ﺍﻟﻤﺮﻭﺭ‪.‬ﺃﺑﺪﺍًﻳﺠﺐ ﺃﻥ ﻳﺘﻢ ﻋﺮﺿﻬﺎ ﻣﺮﺓ ﺃﺧﺮﻯ‬
‫ﻟﻠﻤﺴﺘﺨﺪﻡﻭﻳﺠﺐ ﺩﺍﺉﻤﺎً ﺇﺧﻔﺎﺅﻫﺎ ﺩﺍﺧﻞ ﻣﺼﺪﺭ ﺍﺳﺘﺠﺎﺑﺔ ﺍﻟﺘﻄﺒﻴﻖ‪.‬‬

‫ﺍﻟﺮﻣﻮﺯﻟﻜﻞ ﺻﻔﺤﺔ‬
‫ﻳﻤﻜﻦﺗﺤﻘﻴﻖ ﺗﺤﻜﻢ ﺃﺩﻕ ﺑﺎﻟﺠﻠﺴﺎﺕ‪ ،‬ﻭﺟﻌﻞ ﺍﻟﻌﺪﻳﺪ ﻣﻦ ﺃﻧﻮﺍﻉ ﻫﺠﻤﺎﺕ ﺍﻟﺠﻠﺴﺎﺕ ﺃﻛﺜﺮ ﺻﻌﻮﺑﺔ ﺃﻭ‬
‫ﻣﺴﺘﺤﻴﻠﺔ‪،‬ﺑﺎﺳﺘﺨﺪﺍﻡ ﺭﻣﻮﺯ ﻟﻜﻞ ﺻﻔﺤﺔ ﺑﺎﻹﺿﺎﻓﺔ ﺇﻟﻰ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ‪ .‬ﻫﻨﺎ‪ ،‬ﻳﻨُﺸﺄ ﺭﻣﺰ ﺻﻔﺤﺔ ﺟﺪﻳﺪ‬
‫ﻓﻲﻛﻞ ﻣﺮﺓ ﻳﻄﻠﺐ ﻓﻴﻬﺎ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺻﻔﺤﺔ ﺗﻄﺒﻴﻖ )ﻋﻠﻰ ﻋﻜﺲ ﺻﻮﺭﺓ ﻣﺜﻼ(ً‪ ،‬ﻭﻳﻤُﺮﺭ ﺇﻟﻰ ﺍﻟﻌﻤﻴﻞ ﻓﻲ‬
‫ﻣﻠﻒﺗﻌﺮﻳﻒ ﺍﺭﺗﺒﺎﻁ ﺃﻭ ﺣﻘﻞ ﻣﺨﻔﻲ ﻓﻲ ﻧﻤﻮﺫﺝ ‪ .HTML‬ﻓﻲ ﻛﻞ ﻣﺮﺓ ﻳﻘُﺪﻡ ﻓﻴﻬﺎ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻃﻠﺒﺎً‪،‬‬
‫ﻳﺘُﺤﻘﻖﻣﻦ ﺻﺤﺔ ﺭﻣﺰ ﺍﻟﺼﻔﺤﺔ ﺑﻨﺎء ًﻋﻠﻰ ﺁﺧﺮ ﻗﻴﻤﺔ ﻣﺼُﺪﺭﺓ‪ ،‬ﺑﺎﻹﺿﺎﻓﺔ ﺇﻟﻰ ﺍﻟﺘﺤﻘﻖ ﺍﻻﻋﺘﻴﺎﺩﻱ ﻣﻦ‬
‫ﺻﺤﺔﺭﻣﺰ ﺍﻟﺠﻠﺴﺔ ﺍﻟﺮﺉﻴﺴﻲ‪ .‬ﻓﻲ ﺣﺎﻟﺔ ﻋﺪﻡ ﺍﻟﺘﻄﺎﺑﻖ‪ ،‬ﺗﻨُﻬﻲ ﺍﻟﺠﻠﺴﺔ ﺑﺄﻛﻤﻠﻬﺎ‪ .‬ﺍﻟﻌﺪﻳﺪ ﻣﻦ ﺗﻄﺒﻴﻘﺎﺕ‬
‫ﺍﻟﻮﻳﺐﺍﻷﻛﺜﺮ ﺃﻫﻤﻴﺔ ﺃﻣﻨﻴﺎً‪...‬‬

‫ﻟﺘﻮﻓﻴﺮﻓﻲ‬
‫ﻛﻤﺎﻫﻮ ﻣﻮﺿﺢ ﻓﻲ ﺍﻟﺸﻜﻞ‬

‫ﺍﻟﺸﻜﻞ‪:12-7‬ﺍﻟﺮﻣﻮﺯ ﻟﻜﻞ ﺻﻔﺤﺔ ﺍﻟﻤﺴﺘﺨﺪﻣﺔ ﻓﻲ ﺗﻄﺒﻴﻖ ﻣﺼﺮﻓﻲ‬

‫ﻳﻔﺮﺽﺍﺳﺘﺨﺪﺍﻡ ﺍﻟﺮﻣﻮﺯ ﻟﻜﻞ ﺻﻔﺤﺔ ﺑﻌﺾ ﺍﻟﻘﻴﻮﺩ ﻋﻠﻰ ﺍﻟﺘﻨﻘﻞ )ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﻋﻠﻰ‬
‫ﺍﺳﺘﺨﺪﺍﻡﺃﺯﺭﺍﺭ ﺍﻟﺮﺟﻮﻉ ﻟﻸﻣﺎﻡ ﻭﺍﻟﺨﻠﻒ ﻭﺍﻟﺘﺼﻔﺢ ﻣﺘﻌﺪﺩ ﺍﻟﻨﻮﺍﻓﺬ(‪.‬‬
‫‪253‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬

‫ﻭﻣﻊﺫﻟﻚ‪ ،‬ﻓﻬﻮ ﻳﻤﻨﻊ ﺑﻔﻌﺎﻟﻴﺔ ﻫﺠﻤﺎﺕ ﺗﺜﺒﻴﺖ ﺍﻟﺠﻠﺴﺔ‪ ،‬ﻭﻳﻀﻤﻦ ﺣﻈﺮ ﺍﻻﺳﺘﺨﺪﺍﻡ ﺍﻟﻤﺘﺰﺍﻣﻦ ﻟﺠﻠﺴﺔ‬
‫ﻣﺨﺘﺮﻗﺔﻣﻦ ﻗﺒِﻞ ﻣﺴﺘﺨﺪﻡ ﺷﺮﻋﻲ ﻭﻣﻬﺎﺟﻢ ﺑﺴﺮﻋﺔ ﺑﻌﺪ ﺃﻥ ﻳﺠُﺮﻱ ﻛﻼﻫﻤﺎ ﻃﻠﺒﺎً ﻭﺍﺣﺪﺍً‪ .‬ﻛﻤﺎ ﻳﻤُﻜﻦ‬
‫ﺍﻻﺳﺘﻔﺎﺩﺓﻣﻦ ﺍﻟﺮﻣﻮﺯ ﻟﻜﻞ ﺻﻔﺤﺔ ﻟﺘﺘﺒﻊ ﻣﻮﻗﻊ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻭﺣﺮﻛﺘﻪ ﻋﺒﺮ ﺍﻟﺘﻄﺒﻴﻖ‪ .‬ﻛﻤﺎ ﻳﻤُﻜﻦ‬
‫ﺍﺳﺘﺨﺪﺍﻣﻬﺎﻟﻠﻜﺸﻒ ﻋﻦ ﻣﺤﺎﻭﻻﺕ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﻭﻇﺎﺉﻒ ﺧﺎﺭﺝ ﺗﺴﻠﺴﻞ ﻣﺤُﺪﺩ‪ ،‬ﻣﻤﺎ ﻳﺴُﺎﻋﺪ ﻓﻲ‬
‫ﺍﻟﺤﻤﺎﻳﺔﻣﻦ ﺑﻌﺾ ﻋﻴﻮﺏ ﺍﻟﺘﺤﻜﻢ ﻓﻲ ﺍﻟﻮﺻﻮﻝ )ﺍﻧﻈﺮ ﺍﻟﻔﺼﻞ ‪.(8‬‬

‫ﺳﺠﻞ‪،‬ﺭﺍﻗﺐ‪ ،‬ﻭﻧﺒﻪ‬
‫ﻳﺠﺐﺩﻣﺞ ﻭﻇﻴﻔﺔ ﺇﺩﺍﺭﺓ ﺟﻠﺴﺔ ﺍﻟﺘﻄﺒﻴﻖ ﺑﺸﻜﻞ ﻭﺛﻴﻖ ﻣﻊ ﺁﻟﻴﺎﺗﻪ ﻟﻠﺘﺴﺠﻴﻞ ﻭﺍﻟﻤﺮﺍﻗﺒﺔ ﻭﺍﻟﺘﻨﺒﻴﻪ ﻟﺘﻮﻓﻴﺮ‬
‫ﺳﺠﻼﺕﻣﻨﺎﺳﺒﺔ ﻟﻠﻨﺸﺎﻁ ﺍﻟﺸﺎﺫ ﻭﺗﻤﻜﻴﻦ ﺍﻟﻤﺴﺆﻭﻟﻴﻦ ﻣﻦ ﺍﺗﺨﺎﺫ ﺇﺟﺮﺍءﺍﺕ ﺩﻓﺎﻋﻴﺔ ﻋﻨﺪ ﺍﻟﻀﺮﻭﺭﺓ‪:‬‬

‫ﻳﺠﺐﻋﻠﻰ ﺍﻟﺘﻄﺒﻴﻖ ﻣﺮﺍﻗﺒﺔ ﺍﻟﻄﻠﺒﺎﺕ ﺍﻟﺘﻲ ﺗﺤﺘﻮﻱ ﻋﻠﻰ ﺭﻣﻮﺯ ﻏﻴﺮ ﺻﺎﻟﺤﺔ‪ .‬ﺑﺎﺳﺘﺜﻨﺎء ﺍﻟﺤﺎﻻﺕ‬ ‫‪-‬‬

‫ﺍﻷﻛﺜﺮﺗﻮﻗﻌﺎً‪ ،‬ﻋﺎﺩﺓ ًﻣﺎ ﻳﺘﻀﻤﻦ ﺍﻟﻬﺠﻮﻡ ﺍﻟﻨﺎﺟﺢ ﺍﻟﺬﻱ ﻳﺤﺎﻭﻝ ﺗﺨﻤﻴﻦ ﺍﻟﺮﻣﻮﺯ ﺍﻟﺼﺎﺩﺭﺓ‬
‫ﻟﻤﺴﺘﺨﺪﻣﻴﻦﺁﺧﺮﻳﻦ ﺇﺻﺪﺍﺭ ﻋﺪﺩ ﻛﺒﻴﺮ ﻣﻦ ﺍﻟﻄﻠﺒﺎﺕ ﺍﻟﺘﻲ ﺗﺤﺘﻮﻱ ﻋﻠﻰ ﺭﻣﻮﺯ ﻏﻴﺮ ﺻﺎﻟﺤﺔ‪ ،‬ﻣﻤﺎ‬
‫ﻳﺘﺮﻙﺃﺛﺮﺍً ﻭﺍﺿﺤﺎً ﻓﻲ ﺳﺠﻼﺕ ﺍﻟﺘﻄﺒﻴﻖ‪.‬‬

‫ﻳﺼﻌﺐﺣﻈﺮ ﻫﺠﻤﺎﺕ ﺍﻟﻘﻮﺓ ﺍﻟﻐﺎﺷﻤﺔ ﺿﺪ ﺭﻣﻮﺯ ﺍﻟﺠﻠﺴﺔ ﺗﻤﺎﻣﺎً‪ ،‬ﻧﻈﺮﺍً ﻟﻌﺪﻡ ﺇﻣﻜﺎﻧﻴﺔ ﺗﻌﻄﻴﻞ‬ ‫‪-‬‬

‫ﺃﻱﺣﺴﺎﺏ ﻣﺴﺘﺨﺪﻡ ﺃﻭ ﺟﻠﺴﺔ ﻣﺤﺪﺩﺓ ﻹﻳﻘﺎﻑ ﺍﻟﻬﺠﻮﻡ‪ .‬ﺃﺣﺪ ﺍﻹﺟﺮﺍءﺍﺕ ﺍﻟﻤﻤﻜﻨﺔ ﻫﻮ ﺣﻈﺮ‬
‫ﻋﻨﺎﻭﻳﻦ‪ IP‬ﺍﻟﻤﺼﺪﺭ ﻟﻔﺘﺮﺓ ﺯﻣﻨﻴﺔ ﻣﺤﺪﺩﺓ ﻋﻨﺪ ﺍﺳﺘﻼﻡ ﻋﺪﺩ ﻣﻦ ﺍﻟﻄﻠﺒﺎﺕ ﺍﻟﺘﻲ ﺗﺤﺘﻮﻱ ﻋﻠﻰ‬
‫ﺭﻣﻮﺯﻏﻴﺮ ﺻﺎﻟﺤﺔ‪ .‬ﻭﻣﻊ ﺫﻟﻚ‪ ،‬ﻗﺪ ﻻ ﻳﻜﻮﻥ ﻫﺬﺍ ﺍﻹﺟﺮﺍء ﻓﻌﺎﻻً ﻋﻨﺪﻣﺎ ﺗﻜﻮﻥ ﻃﻠﺒﺎﺕ ﻣﺴﺘﺨﺪﻡ‬
‫ﻭﺍﺣﺪﺻﺎﺩﺭﺓ ﻣﻦ ﻋﻨﺎﻭﻳﻦ ‪ IP‬ﻣﺘﻌﺪﺩﺓ )ﻣﺜﻞ ﻣﺴﺘﺨﺪﻣﻲ ‪ (AOL‬ﺃﻭ ﻋﻨﺪﻣﺎ ﺗﻜﻮﻥ ﻃﻠﺒﺎﺕ ﻋﺪﺓ‬
‫ﻣﺴﺘﺨﺪﻣﻴﻦﺻﺎﺩﺭﺓ ﻣﻦ ﻋﻨﻮﺍﻥ ‪ IP‬ﻧﻔﺴﻪ )ﻣﺜﻞ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺍﻟﺬﻳﻦ ﻳﺴﺘﺨﺪﻣﻮﻥ ﺧﺎﺩﻡ‬
‫ﻭﻛﻴﻞﺃﻭ ﺟﺪﺍﺭ ﺣﻤﺎﻳﺔ ﻟﺘﺮﺟﻤﺔ ﻋﻨﺎﻭﻳﻦ ﺍﻟﺸﺒﻜﺔ(‪.‬‬

‫ﺣﺘﻰﻟﻮ ﻟﻢ ﻳﻜﻦ ﻣﻦ ﺍﻟﻤﻤﻜﻦ ﻣﻨﻊ ﻫﺠﻤﺎﺕ ﺍﻟﻘﻮﺓ ﺍﻟﻐﺎﺷﻤﺔ ﺿﺪ ﺍﻟﺠﻠﺴﺎﺕ ﺑﺸﻜﻞ ﻓﻌﺎﻝ ﻓﻲ‬ ‫‪-‬‬

‫ﺍﻟﻮﻗﺖﺍﻟﻔﻌﻠﻲ‪ ،‬ﻓﺈﻥ ﺍﻻﺣﺘﻔﺎﻅ ﺑﺴﺠﻼﺕ ﻣﻔﺼﻠﺔ ﻭﺗﻨﺒﻴﻪ ﺍﻟﻤﺴﺆﻭﻟﻴﻦ ﻳﻤﻜﻨّﻬﻢ ﻣﻦ ﺍﻟﺘﺤﻘﻴﻖ‬

‫ﻓﻲﺍﻟﻬﺠﻮﻡ ﻭﺍﺗﺨﺎﺫ ﺍﻹﺟﺮﺍء ﺍﻟﻤﻨﺎﺳﺐ ﺣﻴﺜﻤﺎ ﺃﻣﻜﻨﻬﻢ ﺫﻟﻚ‪.‬‬
‫ﻛﻠﻤﺎﺃﻣﻜﻦ‪ ،‬ﻳﻨﺒﻐﻲ ﺗﻨﺒﻴﻪ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺇﻟﻰ ﺃﻱ ﺃﺣﺪﺍﺙ ﻏﻴﺮ ﻃﺒﻴﻌﻴﺔ ﺗﺘﻌﻠﻖ ﺑﺠﻠﺴﺎﺗﻬﻢ‪ ،‬ﻣﺜﻞ‬ ‫‪-‬‬

‫ﻋﻤﻠﻴﺎﺕﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﺍﻟﻤﺘﺰﺍﻣﻨﺔ ﺃﻭ ﻋﻤﻠﻴﺎﺕ ﺍﻻﺧﺘﺮﺍﻕ ﺍﻟﻈﺎﻫﺮﺓ )ﺍﻟﺘﻲ ﻳﺘﻢ ﺍﻛﺘﺸﺎﻓﻬﺎ‬

‫ﺑﺎﺳﺘﺨﺪﺍﻡﺭﻣﻮﺯ ﻟﻜﻞ ﺻﻔﺤﺔ(‪ .‬ﺣﺘﻰ ﻟﻮ ﻛﺎﻥ ﺍﻻﺧﺘﺮﺍﻕ ﻗﺪ ﺣﺪﺙ ﺑﺎﻟﻔﻌﻞ‪ ،‬ﻓﺈﻥ ﻫﺬﺍ ﻳﻤُﻜﻦّ‬
‫ﺍﻟﻤﺴﺘﺨﺪﻡﻣﻦ ﺍﻟﺘﺤﻘﻖ ﻣﻤﺎ ﺇﺫﺍ ﻛﺎﻧﺖ ﻫﻨﺎﻙ ﺃﻱ ﺇﺟﺮﺍءﺍﺕ ﻏﻴﺮ ﻣﺼﺮﺡ ﺑﻬﺎ‪ ،‬ﻣﺜﻞ ﺗﺤﻮﻳﻼﺕ‬
‫ﺍﻷﻣﻮﺍﻝ‪،‬ﻗﺪ ﺣﺪﺛﺖ‪.‬‬

‫ﺇﻧﻬﺎءﺍﻟﺠﻠﺴﺔ ﺍﻟﺘﻔﺎﻋﻠﻴﺔ‬
‫ﻳﻤﻜﻦﺍﻻﺳﺘﻔﺎﺩﺓ ﻣﻦ ﺁﻟﻴﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ ﻛﻮﺳﻴﻠﺔ ﺩﻓﺎﻉ ﻓﻌﺎﻟﺔ ﻟﻠﻐﺎﻳﺔ ﺿﺪ ﺃﻧﻮﺍﻉ ﻋﺪﻳﺪﺓ ﻣﻦ ﺍﻟﻬﺠﻤﺎﺕ‬
‫ﺍﻷﺧﺮﻯﻋﻠﻰ ﺍﻟﺘﻄﺒﻴﻖ‪ .‬ﺑﻌﺾ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﻟﺤﺴﺎﺳﺔ ﺃﻣﻨﻴﺎً‪ ،‬ﻣﺜﻞ ﺍﻟﺨﺪﻣﺎﺕ ﺍﻟﻤﺼﺮﻓﻴﺔ ﻋﺒﺮ ﺍﻹﻧﺘﺮﻧﺖ‪،‬‬
‫ﺗﻨُﻬﻲﺟﻠﺴﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺑﻘﻮﺓ ﻓﻲ ﻛﻞ ﻣﺮﺓ ﻳﺮُﺳﻞ ﻓﻴﻬﺎ ﻃﻠﺒﺎً ﻏﻴﺮ ﻃﺒﻴﻌﻲ‪.‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬ ‫‪254‬‬

‫ﺗﺘﻀﻤﻦﺍﻷﻣﺜﻠﺔ ﺃﻱ ﻃﻠﺐ ﻳﺤﺘﻮﻱ ﻋﻠﻰ ﺣﻘﻞ ﻧﻤﻮﺫﺝ ‪ HTML‬ﻣﺨﻔﻲ ﻣﻌﺪﻝّ ﺃﻭ ﻣﻌﻠﻤﺔ ﺳﻠﺴﻠﺔ‬
‫ﺍﺳﺘﻌﻼﻡ‪ ،URL‬ﻭﺃﻱ ﻃﻠﺐ ﻳﺤﺘﻮﻱ ﻋﻠﻰ ﺳﻼﺳﻞ ﻣﺮﺗﺒﻄﺔ ﺑﻬﺠﻤﺎﺕ ﺣﻘﻦ ‪ SQL‬ﺃﻭ ﻧﺼﻮﺹ ﺑﺮﻣﺠﻴﺔ‬
‫ﻋﺒﺮﺍﻟﻤﻮﺍﻗﻊ‪ ،‬ﻭﺃﻱ ﺇﺩﺧﺎﻝ ﻣﺴﺘﺨﺪﻡ ﻛﺎﻥ ﻣﻦ ﺍﻟﻤﻤﻜﻦ ﺣﻈﺮﻩ ﻋﺎﺩﺓ ًﺑﻮﺍﺳﻄﺔ ﻓﺤﻮﺻﺎﺕ ﺟﺎﻧﺐ ﺍﻟﻌﻤﻴﻞ‬
‫ﻣﺜﻞﻗﻴﻮﺩ ﺍﻟﻄﻮﻝ‪.‬‬
‫ﺑﺎﻟﻄﺒﻊ‪،‬ﻳﺠﺐ ﻣﻌﺎﻟﺠﺔ ﺃﻱ ﺛﻐﺮﺍﺕ ﺃﻣﻨﻴﺔ ﻗﺪ ﺗﺴُﺘﻐﻞ ﺑﺎﺳﺘﺨﺪﺍﻡ ﻣﺜﻞ ﻫﺬﻩ ﺍﻟﻄﻠﺒﺎﺕ ﻣﻦ ﻣﺼﺪﺭﻫﺎ‪.‬‬
‫ﻟﻜﻦﺇﺟﺒﺎﺭ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﻋﻠﻰ ﺇﻋﺎﺩﺓ ﺍﻟﻤﺼﺎﺩﻗﺔ ﻓﻲ ﻛﻞ ﻣﺮﺓ ﻳﻘﺪﻣﻮﻥ ﻓﻴﻬﺎ ﻃﻠﺒﺎً ﻏﻴﺮ ﺻﺎﻟﺢ ﻗﺪ ﻳﺒُﻄﺊ‬
‫ﻋﻤﻠﻴﺔﻓﺤﺺ ﺍﻟﺘﻄﺒﻴﻖ ﺑﺤﺜﺎً ﻋﻦ ﺍﻟﺜﻐﺮﺍﺕ ﺑﺸﻜﻞ ﻛﺒﻴﺮ‪ ،‬ﺣﺘﻰ ﻣﻊ ﺍﺳﺘﺨﺪﺍﻡ ﺗﻘﻨﻴﺎﺕ ﺁﻟﻴﺔ‪ .‬ﺇﺫﺍ ﻛﺎﻧﺖ‬
‫ﺍﻟﺜﻐﺮﺍﺕﺍﻟﻤﺘﺒﻘﻴﺔ ﻻ ﺗﺰﺍﻝ ﻣﻮﺟﻮﺩﺓ‪ ،‬ﻓﺴﻴﻜﻮﻥ ﺍﻛﺘﺸﺎﻓﻬﺎ ﻣﻦ ﻗﺒِﻞ ﺃﻱ ﺷﺨﺺ ﻓﻲ ﻫﺬﺍ ﺍﻟﻤﺠﺎﻝ ﺃﻗﻞ‬
‫ﺑﻜﺜﻴﺮ‪.‬‬

‫ﻋﻨﺪﺗﻄﺒﻴﻖ ﻫﺬﺍ ﺍﻟﻨﻮﻉ ﻣﻦ ﺍﻟﺪﻓﺎﻉ‪ ،‬ﻳﻨُﺼﺢ ﺃﻳﻀﺎً ﺑﺈﻳﻘﺎﻓﻪ ﺑﺴﻬﻮﻟﺔ ﻷﻏﺮﺍﺽ ﺍﻻﺧﺘﺒﺎﺭ‪ .‬ﺇﺫﺍ ﺗﺒﺎﻃﺄ ﺍﺧﺘﺒﺎﺭ‬
‫ﺍﺧﺘﺮﺍﻕﻣﺸﺮﻭﻉ ﻟﻠﺘﻄﺒﻴﻖ ﺑﻨﻔﺲ ﻃﺮﻳﻘﺔ ﻣﻬﺎﺟﻢ ﺣﻘﻴﻘﻲ‪ ،‬ﻓﺈﻥ ﻓﻌﺎﻟﻴﺘﻪ ﺗﻨﺨﻔﺾ ﺑﺸﻜﻞ ﻛﺒﻴﺮ‪ .‬ﻛﻤﺎ ﺃﻧﻪ‬
‫ﻣﻦﺍﻟﻤﺮﺟﺢ ﺟﺪﺍً ﺃﻥ ﻳﺆﺩﻱ ﻭﺟﻮﺩ ﺍﻵﻟﻴﺔ ﺇﻟﻰ ﺑﻘﺎء ﺍﻟﻤﺰﻳﺪ ﻣﻦ ﺍﻟﺜﻐﺮﺍﺕ ﻓﻲ ﺍﻟﻜﻮﺩ ﺍﻟﻤﺼﺪﺭﻱ ﻣﻘﺎﺭﻧﺔ ً‬
‫ﺑﻐﻴﺎﺑﻬﺎ‪.‬‬

‫ﺧﻄﻮﺍﺕﺍﻻﺧﺘﺮﺍﻕ‬

‫ﺇﺫﺍﻛﺎﻥ ﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﺬﻱ ﺗﻬﺎﺟﻤﻪ ﻳﺴﺘﺨﺪﻡ ﻫﺬﺍ ﺍﻟﻨﻮﻉ ﻣﻦ ﺍﻹﺟﺮﺍءﺍﺕ ﺍﻟﺪﻓﺎﻋﻴﺔ‪ ،‬ﻓﻘﺪ ﺗﺠﺪ ﺃﻥ ﻓﺤﺺ‬
‫ﺍﻟﺘﻄﺒﻴﻖﺑﺤﺜﺎً ﻋﻦ ﺃﻧﻮﺍﻉ ﻋﺪﻳﺪﺓ ﻣﻦ ﺍﻟﺜﻐﺮﺍﺕ ﺍﻷﻣﻨﻴﺔ ﺍﻟﺸﺎﺉﻌﺔ ﻳﺴﺘﻐﺮﻕ ﻭﻗﺘﺎً ﻃﻮﻳﻼً‪ .‬ﻓﺎﻟﺤﺎﺟﺔ‬
‫ﺍﻟﻤﺮُﻫﻘﺔﻟﺘﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﺑﻌﺪ ﻛﻞ ﺍﺧﺘﺒﺎﺭ ﻓﺎﺷﻞ ﻭﺍﻟﻌﻮﺩﺓ ﺇﻟﻰ ﺻﻔﺤﺔ ﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﺬﻱ ﻛﻨﺖ ﺗﺒﺤﺚ ﻋﻨﻪ‬
‫ﺳﺘﺠﻌﻠﻚﺗﺴﺘﺴﻠﻢ ﺳﺮﻳﻌﺎً‪.‬‬

‫ﻓﻲﻫﺬﻩ ﺍﻟﺤﺎﻟﺔ‪ ،‬ﻳﻤﻜﻨﻚ ﻏﺎﻟﺒﺎً ﺍﺳﺘﺨﺪﺍﻡ ﺍﻷﺗﻤﺘﺔ ﻟﻤﻌﺎﻟﺠﺔ ﺍﻟﻤﺸﻜﻠﺔ‪ .‬ﻋﻨﺪ ﺍﺳﺘﺨﺪﺍﻡ ‪Intruder‬‬
‫‪ Burp‬ﻟﺘﻨﻔﻴﺬ ﻫﺠﻮﻡ‪ ،‬ﻳﻤﻜﻨﻚ ﺍﺳﺘﺨﺪﺍﻡ ﻣﻴﺰﺓ "ﺍﻟﺤﺼﻮﻝ ﻋﻠﻰ ﻣﻠﻒ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ" ﻹﺟﺮﺍء ﺗﺴﺠﻴﻞ‬
‫ﺩﺧﻮﻝﺟﺪﻳﺪ ﻗﺒﻞ ﺇﺭﺳﺎﻝ ﻛﻞ ﺣﺎﻟﺔ ﺍﺧﺘﺒﺎﺭ‪ ،‬ﻭﺍﺳﺘﺨﺪﺍﻡ ﺭﻣﺰ ﺍﻟﺠﻠﺴﺔ ﺍﻟﺠﺪﻳﺪ )ﺑﺸﺮﻁ ﺃﻥ ﻳﻜﻮﻥ ﺗﺴﺠﻴﻞ‬
‫ﺍﻟﺪﺧﻮﻝﺃﺣﺎﺩﻱ ﺍﻟﻤﺮﺣﻠﺔ(‪ .‬ﻋﻨﺪ ﺗﺼﻔﺢ ﺍﻟﺘﻄﺒﻴﻖ ﻭﻓﺤﺼﻪ ﻳﺪﻭﻳﺎً‪ ،‬ﻳﻤﻜﻨﻚ ﺍﺳﺘﺨﺪﺍﻡ ﻣﻴﺰﺍﺕ ﻗﺎﺑﻠﻴﺔ‬
‫ﺍﻟﺘﻮﺳﻌﺔﻓﻲ ‪ Burp Proxy‬ﻋﺒﺮﺍﻳﺒﻮﺭﺏ ﺍﻛﺴﺘﻴﻨﺪﺭﻭﺍﺟﻬﺔ‪ .‬ﻳﻤﻜﻨﻚ ﺇﻧﺸﺎء ﻣﻠﺤﻖ ﻳﻜﺘﺸﻒ ﺗﺴﺠﻴﻞ‬
‫ﺍﻟﺨﺮﻭﺝﺍﻟﻘﺴﺮﻱ ﻟﻠﺘﻄﺒﻴﻖ‪ ،‬ﻭﻳﺴﺠﻞ ﺩﺧﻮﻟﻪ ﺗﻠﻘﺎﺉﻴﺎً‪ ،‬ﻭﻳﻌﻴﺪ ﺍﻟﺠﻠﺴﺔ ﻭﺍﻟﺼﻔﺤﺔ ﺍﻟﺠﺪﻳﺪﺓ ﺇﻟﻰ‬
‫ﺍﻟﻤﺘﺼﻔﺢ‪،‬ﻣﻊ ﺇﻣﻜﺎﻧﻴﺔ ﻋﺮﺽ ﺭﺳﺎﻟﺔ ﻣﻨﺒﺜﻘﺔ ﺗﺨُﺒﺮﻙ ﺑﻤﺎ ﺣﺪﺙ‪ .‬ﻣﻊ ﺃﻥ ﻫﺬﺍ ﻻ ﻳﺤُﻞ ﺍﻟﻤﺸﻜﻠﺔ ﺑﺄﻱ ﺣﺎﻝ‬
‫ﻣﻦﺍﻷﺣﻮﺍﻝ‪ ،‬ﺇﻻ ﺃﻧﻪ ﻗﺪ ﻳﺨُﻔﻔﻬﺎ ﺑﺸﻜﻞ ﻛﺒﻴﺮ ﻓﻲ ﺑﻌﺾ ﺍﻟﺤﺎﻻﺕ‪.‬‬

‫ﻣﻠﺨﺺ‬
‫ﺗﻮﻓﺮﺁﻟﻴﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ ﻣﺼﺪﺭﺍً ﻏﻨﻴﺎً ﺑﺎﻟﺜﻐﺮﺍﺕ ﺍﻟﻤﺤﺘﻤﻠﺔ ﺍﻟﺘﻲ ﻳﻤﻜﻨﻚ ﺍﺳﺘﻬﺪﺍﻓﻬﺎ ﻋﻨﺪ ﺻﻴﺎﻏﺔ‬
‫ﻫﺠﻮﻣﻚﻋﻠﻰ ﺗﻄﺒﻴﻖ‪ .‬ﻭﻧﻈﺮﺍً ﻟﺪﻭﺭﻫﺎ ﺍﻷﺳﺎﺳﻲ ﻓﻲ ﺗﻤﻜﻴﻦ ﺍﻟﺘﻄﺒﻴﻖ ﻣﻦ ﺗﺤﺪﻳﺪ ﻫﻮﻳﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ‬
‫ﻧﻔﺴﻪﻋﺒﺮ ﻃﻠﺒﺎﺕ ﻣﺘﻌﺪﺩﺓ‪ ،‬ﻓﺈﻥ ﻭﻇﻴﻔﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ ﺍﻟﻤﻌﻄﻠﺔ ﻋﺎﺩﺓ ًﻣﺎ ﺗﺆﺩﻱ ﺇﻟﻰ‪:‬‬
‫‪255‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬

‫ﻳﻮﻓﺮﻣﻔﺎﺗﻴﺢ ﺍﻟﻤﻤﻠﻜﺔ‪ .‬ﺍﻟﺪﺧﻮﻝ ﺇﻟﻰ ﺟﻠﺴﺎﺕ ﻣﺴﺘﺨﺪﻣﻴﻦ ﺁﺧﺮﻳﻦ ﺃﻣﺮ ﺟﻴﺪ‪ .‬ﺃﻣﺎ ﺍﺧﺘﺮﺍﻕ ﺟﻠﺴﺔ‬
‫ﻣﺴﺆﻭﻝﺍﻟﻨﻈﺎﻡ ﻓﻬﻮ ﺃﻓﻀﻞ؛ ﺇﺫ ﻳﻤُﻜﻨّﻚ ﻋﺎﺩﺓ ًﻣﻦ ﺍﺧﺘﺮﺍﻕ ﺍﻟﺘﻄﺒﻴﻖ ﺑﺄﻛﻤﻠﻪ‪.‬‬

‫ﻣﻦﺍﻟﻤﺘﻮﻗﻊ ﻣﻮﺍﺟﻬﺔ ﻣﺠﻤﻮﻋﺔ ﻭﺍﺳﻌﺔ ﻣﻦ ﺍﻟﻌﻴﻮﺏ ﻓﻲ ﻭﻇﺎﺉﻒ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺎﺕ ﺍﻟﻌﻤﻠﻴﺔ‪ .‬ﻋﻨﺪ‬
‫ﺍﺳﺘﺨﺪﺍﻡﺁﻟﻴﺎﺕ ﻣﺼُﻤﻤﺔ ﺧﺼﻴﺼﺎً‪ ،‬ﻗﺪ ﺗﺒﺪﻭ ﻧﻘﺎﻁ ﺍﻟﻀﻌﻒ ﻭﺳﺒﻞ ﺍﻟﻬﺠﻮﻡ ﺍﻟﻤﺤﺘﻤﻠﺔ ﻻ ﺣﺼﺮ ﻟﻬﺎ‪.‬‬
‫ﺃﻫﻢﺩﺭﺱ ﻳﻤﻜﻦ ﺍﺳﺘﺨﻼﺻﻪ ﻣﻦ ﻫﺬﺍ ﺍﻟﻤﻮﺿﻮﻉ ﻫﻮ ﺍﻟﺘﺤﻠﻲ ﺑﺎﻟﺼﺒﺮ ﻭﺍﻟﻌﺰﻳﻤﺔ‪ .‬ﻗﺪ ﺗﺠﺪ ﺍﻟﻌﺪﻳﺪ ﻣﻦ‬
‫ﺁﻟﻴﺎﺕﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺎﺕ‪ ،‬ﺍﻟﺘﻲ ﺗﺒﺪﻭ ﻗﻮﻳﺔ ﻟﻠﻮﻫﻠﺔ ﺍﻷﻭﻟﻰ‪ ،‬ﻧﺎﻗﺼﺔ ﻋﻨﺪ ﺗﺤﻠﻴﻠﻬﺎ ﺑﺪﻗﺔ‪ .‬ﻗﺪ ﻳﺴﺘﻐﺮﻕ ﻓﻚ‬
‫ﺷﻔﺮﺓﺍﻟﻄﺮﻳﻘﺔ ﺍﻟﺘﻲ ﻳﺴﺘﺨﺪﻣﻬﺎ ﺍﻟﺘﻄﺒﻴﻖ ﻟﺘﻮﻟﻴﺪ ﺳﻠﺴﻠﺔ ﻣﻦ ﺍﻟﺮﻣﻮﺯ ﺍﻟﺘﻲ ﺗﺒﺪﻭ ﻋﺸﻮﺍﺉﻴﺔ ﻭﻗﺘﺎً‬
‫ﻭﺟﻬﺪﺍً‪.‬ﻭﻟﻜﻦ ﺑﺎﻟﻨﻈﺮ ﺇﻟﻰ ﺍﻟﻤﻜﺎﻓﺄﺓ‪ ،‬ﻳﻌُﺪ ﻫﺬﺍ ﺍﺳﺘﺜﻤﺎﺭﺍً ﻳﺴﺘﺤﻖ ﺍﻟﻌﻨﺎء‪.‬‬

‫ﺃﺳﺉﻠﺔ‬

‫ﻳﻤﻜﻦﺍﻟﻌﺜﻮﺭ ﻋﻠﻰ ﺍﻹﺟﺎﺑﺎﺕ ﻓﻲ‪http://mdsec.net/wahh.‬‬

‫‪.1‬ﺗﻘﻮﻡ ﺑﺘﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﺇﻟﻰ ﺃﺣﺪ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ‪ ،‬ﻭﻳﻘﻮﻡ ﺍﻟﺨﺎﺩﻡ ﺑﺘﻌﻴﻴﻦ ﻣﻠﻒ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﺍﻟﺘﺎﻟﻲ‪:‬‬
‫ﻣﺠﻤﻮﻋﺔﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ‪sessid=amltMjM6MTI0MToxMTk0ODcwODYz :‬؛‬

‫ﺑﻌﺪﻣﺮﻭﺭ ﺳﺎﻋﺔ‪ ،‬ﻳﻤﻜﻨﻚ ﺗﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﻣﺮﺓ ﺃﺧﺮﻯ ﻭﺗﻠﻘﻲ ﻣﺎ ﻳﻠﻲ‪:‬‬

‫ﻣﺠﻤﻮﻋﺔﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ‪sessid=amltMjM6MTI0MToxMTk0ODc1MTMy :‬؛‬

‫ﻣﺎﺫﺍﻳﻤﻜﻨﻚ ﺃﻥ ﺗﺴﺘﻨﺘﺞ ﻋﻦ ﻫﺬﻩ ﺍﻟﻜﻮﻛﻴﺰ؟‬

‫‪.٢‬ﻳﺴﺘﺨﺪﻡ ﺃﺣﺪ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺭﻣﻮﺯ ﺟﻠﺴﺔ ﻣﻜﻮﻧﺔ ﻣﻦ ﺳﺘﺔ ﺃﺣﺮﻑ ﺃﺑﺠﺪﻳﺔ ﺭﻗﻤﻴﺔ ﻭﻛﻠﻤﺎﺕ ﻣﺮﻭﺭ‬
‫ﻣﻜﻮﻧﺔﻣﻦ ﺧﻤﺴﺔ ﺃﺣﺮﻑ ﺃﺑﺠﺪﻳﺔ ﺭﻗﻤﻴﺔ‪ .‬ﻳﺘﻢ ﺗﻮﻟﻴﺪ ﻛﻠﻴﻬﻤﺎ ﻋﺸﻮﺍﺉﻴﺎً ﻭﻓﻘﺎً ﻟﺨﻮﺍﺭﺯﻣﻴﺔ ﻏﻴﺮ‬
‫ﻣﺘﻮﻗﻌﺔ‪.‬ﺃﻳﻬﻤﺎ ﻳﺤُﺘﻤﻞ ﺃﻥ ﻳﻜﻮﻥ ﻫﺪﻓﺎً ﺃﻛﺜﺮ ﻓﻌﺎﻟﻴﺔ ﻟﻬﺠﻮﻡ ﺍﻟﺘﺨﻤﻴﻦ ﺑﺎﻟﻘﻮﺓ ﺍﻟﻐﺎﺷﻤﺔ؟ ﺍﺫﻛﺮ‬
‫ﺟﻤﻴﻊﺍﻟﻌﻮﺍﻣﻞ ﺍﻟﻤﺨﺘﻠﻔﺔ ﺍﻟﺘﻲ ﻗﺪ ﺗﺆﺛﺮ ﻋﻠﻰ ﻗﺮﺍﺭﻙ‪.‬‬

‫‪.3‬ﻗﻢ ﺑﺘﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﺇﻟﻰ ﺍﻟﺘﻄﺒﻴﻖ ﻋﻠﻰ ﻋﻨﻮﺍﻥ ‪ URL‬ﺍﻟﺘﺎﻟﻲ‪:‬‬

‫‪https://foo.wahh-app.com/login/home.php‬‬

‫ﻭﻳﻘﻮﻡﺍﻟﺨﺎﺩﻡ ﺑﺘﻌﻴﻴﻦ ﻣﻠﻒ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﺍﻟﺘﺎﻟﻲ‪:‬‬

‫ﻣﺠﻤﻮﻋﺔﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ‪sessionId=1498172056438227 :‬؛ ﺍﻟﻤﺠﺎﻝ‬
‫=‪foo.wahhapp.com‬؛ ﺍﻟﻤﺴﺎﺭ=‪login/‬؛ ‪HttpOnly‬؛‬

‫ﺛﻢﺗﺰﻭﺭ ﻣﺠﻤﻮﻋﺔ ﻣﻦ ﻋﻨﺎﻭﻳﻦ ‪ URL‬ﺍﻷﺧﺮﻯ‪ .‬ﺇﻟﻰ ﺃﻱ ٍّﻣﻦ ﺍﻟﻌﻨﺎﻭﻳﻦ ﺍﻟﺘﺎﻟﻴﺔ ﺳﻴﺮُﺳﻞ ﻣﺘﺼﻔﺤﻚ‬
‫ﺍﻟﺮﺍﺑﻂ؟ﻣﻌﺮﻑ ﺍﻟﺠﻠﺴﺔﻣﻠﻒ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ؟ )ﺣﺪﺩ ﻛﻞ ﻣﺎ ﻳﻨﻄﺒﻖ‪(.‬‬
‫)ﺃ(‪https://foo.wahh-app.com/login/myaccount.php‬‬

‫)ﺏ(‪https://bar.wahh-app.com/login‬‬

‫)ﺝ(‪https://staging.foo.wahh-app.com/login/home.php‬‬

‫)ﺩ(‪http://foo.wahh-app.com/login/myaccount.php‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺴﺎﺑﻊ‪-‬ﻣﻬﺎﺟﻤﺔ ﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺔ‬ ‫‪256‬‬

‫)ﻫـ(‪http://foo.wahh-app.com/logintest/login.php‬‬

‫)ﻭ(‪https://foo.wahh-app.com/logout‬‬

‫)ﺯ(‪https://wahh-app.com/login/‬‬

‫)ﺡ(‪https://xfoo.wahh-app.com/login/myaccount.php‬‬

‫‪.٤‬ﻳﺴﺘﺨﺪﻡ ﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﺬﻱ ﺗﺴﺘﻬﺪﻓﻪ ﺭﻣﻮﺯﺍً ﻟﻜﻞ ﺻﻔﺤﺔ ﺑﺎﻹﺿﺎﻓﺔ ﺇﻟﻰ ﺭﻣﺰ ﺍﻟﺠﻠﺴﺔ ﺍﻟﺮﺉﻴﺴﻲ‪.‬‬
‫ﻓﻲﺣﺎﻝ ﺍﺳﺘﻼﻡ ﺭﻣﺰ ﻟﻜﻞ ﺻﻔﺤﺔ ﺧﺎﺭﺝ ﺍﻟﺘﺴﻠﺴﻞ‪ ،‬ﺗﻠُﻐﻰ ﺍﻟﺠﻠﺴﺔ ﺑﺄﻛﻤﻠﻬﺎ‪ .‬ﻟﻨﻔﺘﺮﺽ ﺃﻧﻚ‬
‫ﺍﻛﺘﺸﻔﺖﺧﻠﻼً ﻳﻤُﻜﻨّﻚ ﻣﻦ ﺗﻮﻗﻊ ﺃﻭ ﺍﻟﺘﻘﺎﻁ ﺍﻟﺮﻣﻮﺯ ﺍﻟﺼﺎﺩﺭﺓ ﻟﻠﻤﺴﺘﺨﺪﻣﻴﻦ ﺍﻵﺧﺮﻳﻦ ﺍﻟﺬﻳﻦ‬
‫ﻳﺴﺘﺨﺪﻣﻮﻥﺍﻟﺘﻄﺒﻴﻖ ﺣﺎﻟﻴﺎً‪ .‬ﻫﻞ ﻳﻤﻜﻨﻚ ﺍﺧﺘﺮﺍﻕ ﺟﻠﺴﺎﺗﻬﻢ؟‬

‫‪.5‬ﺗﻘﻮﻡ ﺑﺘﺴﺠﻴﻞ ﺍﻟﺪﺧﻮﻝ ﺇﻟﻰ ﺃﺣﺪ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ‪ ،‬ﻭﻳﻘﻮﻡ ﺍﻟﺨﺎﺩﻡ ﺑﺘﻌﻴﻴﻦ ﻣﻠﻒ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ ﺍﻟﺘﺎﻟﻲ‪:‬‬
‫ﻣﺠﻤﻮﻋﺔﻣﻠﻔﺎﺕ ﺗﻌﺮﻳﻒ ﺍﻻﺭﺗﺒﺎﻁ‪sess=ab11298f7eg14 :‬؛‬

‫ﻋﻨﺪﺍﻟﻨﻘﺮ ﻓﻮﻕ ﺯﺭ ﺗﺴﺠﻴﻞ ﺍﻟﺨﺮﻭﺝ‪ ،‬ﻳﺆﺩﻱ ﻫﺬﺍ ﺇﻟﻰ ﺗﻨﻔﻴﺬ ﺍﻟﺒﺮﻧﺎﻣﺞ ﺍﻟﻨﺼﻲ ﺍﻟﺘﺎﻟﻲ ﻋﻠﻰ ﺟﺎﻧﺐ‬
‫ﺍﻟﻌﻤﻴﻞ‪:‬‬

‫;”‪document.cookie=”sess=”; document.location=”/‬‬

‫ﻣﺎﻫﻲ ﺍﻟﻨﺘﻴﺠﺔ ﺍﻟﺘﻲ ﺳﺘﺘﻮﺻﻞ ﺇﻟﻴﻬﺎ ﻣﻦ ﻫﺬﺍ ﺍﻟﺴﻠﻮﻙ؟‬

 ‫ﺑﺘﺮ‬ ‫‪8‬‬ ‫ﺗﺸﺎ‬

‫ﻋﻨﺎﺻﺮﺍﻟﺘﺤﻜﻢ‬ ‫ﻣﻬﺎﺟﻤﺔﺍﻟﻮﺻﻮﻝ‬

‫ﺿﻤﻦﺁﻟﻴﺎﺕ ﺍﻷﻣﺎﻥ ﺍﻷﺳﺎﺳﻴﺔ ﻟﻠﺘﻄﺒﻴﻖ‪ ،‬ﺗﺒُﻨﻰ ﺿﻮﺍﺑﻂ ﺍﻟﻮﺻﻮﻝ ﻣﻨﻄﻘﻴﺎً ﻋﻠﻰ ﺍﻟﻤﺼﺎﺩﻗﺔ ﻭﺇﺩﺍﺭﺓ‬
‫ﺍﻟﺠﻠﺴﺎﺕ‪.‬ﺣﺘﻰ ﺍﻵﻥ‪ ،‬ﺭﺃﻳﺘﻢ ﻛﻴﻒ ﻳﻤُﻜﻦ ﻟﻠﺘﻄﺒﻴﻖ ﺍﻟﺘﺤﻘﻖ ﻣﻦ ﻫﻮﻳﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺃﻭﻻً‪ ،‬ﺛﻢ ﺍﻟﺘﺄﻛﺪ ﻣﻦ‬
‫ﺃﻥﺳﻠﺴﻠﺔ ﻣﻌﻴﻨﺔ ﻣﻦ ﺍﻟﻄﻠﺒﺎﺕ ﺍﻟﺘﻲ ﻳﺘﻠﻘﺎﻫﺎ ﺻﺎﺩﺭﺓ ﻣﻦ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻧﻔﺴﻪ‪ .‬ﺍﻟﺴﺒﺐ ﺍﻟﺮﺉﻴﺴﻲ‬
‫ﻟﺤﺎﺟﺔﺍﻟﺘﻄﺒﻴﻖ ﺇﻟﻰ ﺍﻟﻘﻴﺎﻡ ﺑﻬﺬﻩ ﺍﻷﻣﻮﺭ ‪ -‬ﻣﻦ ﺣﻴﺚ ﺍﻷﻣﺎﻥ ﻋﻠﻰ ﺍﻷﻗﻞ ‪ -‬ﻫﻮ ﺣﺎﺟﺘﻪ ﺇﻟﻰ ﻃﺮﻳﻘﺔ‬
‫ﻟﺘﺤﺪﻳﺪﻣﺎ ﺇﺫﺍ ﻛﺎﻥ ﻳﻨﺒﻐﻲ ﻋﻠﻴﻪ ﺍﻟﺴﻤﺎﺡ ﻟﻄﻠﺐ ﻣﻌﻴﻦ ﺑﺘﻨﻔﻴﺬ ﺍﻹﺟﺮﺍء ﺍﻟﺬﻱ ﻳﺤﺎﻭﻝ ﺗﻨﻔﻴﺬﻩ ﺃﻭ ﺍﻟﻮﺻﻮﻝ‬
‫ﺇﻟﻰﺍﻟﻤﻮﺍﺭﺩ ﺍﻟﺘﻲ ﻳﻄﻠﺒﻬﺎ‪ .‬ﺗﻌُﺪ ﺿﻮﺍﺑﻂ ﺍﻟﻮﺻﻮﻝ ﺁﻟﻴﺔ ﺩﻓﺎﻋﻴﺔ ﺑﺎﻟﻐﺔ ﺍﻷﻫﻤﻴﺔ ﺩﺍﺧﻞ ﺍﻟﺘﻄﺒﻴﻖ‪ ،‬ﻷﻧﻬﺎ‬
‫ﻣﺴﺆﻭﻟﺔﻋﻦ ﺍﺗﺨﺎﺫ ﻫﺬﻩ ﺍﻟﻘﺮﺍﺭﺍﺕ ﺍﻟﺮﺉﻴﺴﻴﺔ‪ .‬ﻋﻨﺪﻣﺎ ﺗﻜﻮﻥ ﻣﻌﻴﺒﺔ‪ ،‬ﻳﻤﻜﻦ ﻟﻠﻤﻬﺎﺟﻢ ﻓﻲ ﻛﺜﻴﺮ ﻣﻦ‬
‫ﺍﻷﺣﻴﺎﻥﺍﺧﺘﺮﺍﻕ ﺍﻟﺘﻄﺒﻴﻖ ﺑﺄﻛﻤﻠﻪ‪ ،‬ﻭﺍﻟﺴﻴﻄﺮﺓ ﻋﻠﻰ ﺍﻟﻮﻇﺎﺉﻒ ﺍﻹﺩﺍﺭﻳﺔ ﻭﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﺍﻟﺒﻴﺎﻧﺎﺕ‬
‫ﺍﻟﺤﺴﺎﺳﺔﺍﻟﺨﺎﺻﺔ ﺑﺠﻤﻴﻊ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺍﻵﺧﺮﻳﻦ‪.‬‬

‫ﻛﻤﺎﺫﻛُﺮ ﻓﻲ ﺍﻟﻔﺼﻞ ﺍﻷﻭﻝ‪ ،‬ﺗﻌُﺪ ّﺛﻐﺮﺍﺕ ﺿﻮﺍﺑﻂ ﺍﻟﻮﺻﻮﻝ ﺍﻟﻤﻌﻄﻮﺑﺔ ﻣﻦ ﺃﻛﺜﺮ ﻓﺉﺎﺕ ﺛﻐﺮﺍﺕ‬
‫ﺗﻄﺒﻴﻘﺎﺕﺍﻟﻮﻳﺐ ﺷﻴﻮﻋﺎً‪ ،‬ﺣﻴﺚ ﺗﺆُﺛﺮ ﻋﻠﻰ ‪ %71‬ﻣﻦ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﻟﺘﻲ ﺍﺧﺘﺒﺮﻫﺎ ﺍﻟﻤﺆﻟﻔﻮﻥ ﻣﺆﺧﺮﺍً‪ .‬ﻣﻦ‬
‫ﺍﻟﺸﺎﺉﻊﺟﺪﺍً ﻣﻮﺍﺟﻬﺔ ﺗﻄﺒﻴﻘﺎﺕ ﺗﻜُﻠﻒ ﻧﻔﺴﻬﺎ ﻋﻨﺎء ﺗﻄﺒﻴﻖ ﺁﻟﻴﺎﺕ ﻗﻮﻳﺔ ﻟﻠﻤﺼﺎﺩﻗﺔ ﻭﺇﺩﺍﺭﺓ ﺍﻟﺠﻠﺴﺎﺕ‪،‬‬
‫ﺛﻢﺗﺒُﺪﺩ ﻫﺬﺍ ﺍﻻﺳﺘﺜﻤﺎﺭ ﺑﺈﻫﻤﺎﻝ ﺑﻨﺎء ﺿﻮﺍﺑﻂ ﻭﺻﻮﻝ ﻓﻌﺎّﻟﺔ ﻋﻠﻴﻬﺎ‪ .‬ﺃﺣﺪ ﺃﺳﺒﺎﺏ ﺷﻴﻮﻉ ﻫﺬﻩ ﺍﻟﺜﻐﺮﺍﺕ‬
‫ﻫﻮﺿﺮﻭﺭﺓ ﺇﺟﺮﺍء ﻋﻤﻠﻴﺎﺕ ﻓﺤﺺ ﺿﻮﺍﺑﻂ ﺍﻟﻮﺻﻮﻝ ﻟﻜﻞ ﻃﻠﺐ ﻭﻛﻞ ﻋﻤﻠﻴﺔ ﻋﻠﻰ ﻣﻮﺭﺩ ﻳﺤُﺎﻭﻝ‬
‫ﻣﺴﺘﺨﺪﻡﻣﺤُﺪﺩ ﺗﻨﻔﻴﺬﻫﺎ‪ ،‬ﻓﻲ ﻭﻗﺖ ﻣﺤُﺪﺩ‪ .‬ﻭﻋﻠﻰ ﻋﻜﺲ ﺍﻟﻌﺪﻳﺪ ﻣﻦ ﻓﺉﺎﺕ ﺍﻟﻀﻮﺍﺑﻂ ﺍﻷﺧﺮﻯ‪ ،‬ﻳﻌُﺪ ّ‬
‫ﻫﺬﺍﻗﺮﺍﺭﺍً ﺗﺼﻤﻴﻤﻴﺎً ﻳﺠﺐ ﺃﻥ ﻳﺘﺨﺬﻩ ﺍﻹﻧﺴﺎﻥ؛ ﻭﻻ ﻳﻤُﻜﻦ ﺣﻠﻬّﺎ ﺑﺎﺳﺘﺨﺪﺍﻡ ﺍﻟﺘﻜﻨﻮﻟﻮﺟﻴﺎ‪.‬‬

‫‪257‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺜﺎﻣﻦ‪-‬ﻣﻬﺎﺟﻤﺔ ﻋﻨﺎﺻﺮ ﺍﻟﺘﺤﻜﻢ ﻓﻲ ﺍﻟﻮﺻﻮﻝ‬ ‫‪258‬‬

‫ﺛﻐﺮﺍﺕﺍﻟﺘﺤﻜﻢ ﻓﻲ ﺍﻟﻮﺻﻮﻝ ﺑﺴﻴﻄﺔ ﻣﻦ ﺍﻟﻨﺎﺣﻴﺔ ﺍﻟﻨﻈﺮﻳﺔ‪ :‬ﻳﺘﻴﺢ ﻟﻚ ﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﻘﻴﺎﻡ ﺑﺸﻲء ﻻ‬

‫ﻳﻨﺒﻐﻲﻟﻚ ﺍﻟﻘﻴﺎﻡ ﺑﻪ‪ .‬ﻳﻜﻤﻦ ﺍﻟﻔﺮﻕ ﺑﻴﻦ ﺍﻟﻌﻴﻮﺏ ﺍﻟﻤﺨﺘﻠﻔﺔ ﻓﻲ ﺍﺧﺘﻼﻑ ﻃﺮﻕ ﻇﻬﻮﺭ ﻫﺬﺍ ﺍﻟﻌﻴﺐ‬
‫ﺍﻷﺳﺎﺳﻲﻭﺍﻟﺘﻘﻨﻴﺎﺕ ﺍﻟﻤﺨﺘﻠﻔﺔ ﺍﻟﻼﺯﻣﺔ ﻻﻛﺘﺸﺎﻓﻪ‪ .‬ﻳﺼﻒ ﻫﺬﺍ ﺍﻟﻔﺼﻞ ﺟﻤﻴﻊ ﻫﺬﻩ ﺍﻟﺘﻘﻨﻴﺎﺕ‪ ،‬ﻣﻮﺿﺤﺎً‬
‫ﻛﻴﻔﻴﺔﺍﺳﺘﻐﻼﻝ ﺃﻧﻮﺍﻉ ﻣﺨﺘﻠﻔﺔ ﻣﻦ ﺍﻟﺴﻠﻮﻛﻴﺎﺕ ﺩﺍﺧﻞ ﺍﻟﺘﻄﺒﻴﻖ ﻟﺘﻨﻔﻴﺬ ﺇﺟﺮﺍءﺍﺕ ﻏﻴﺮ ﻣﺼﺮﺡ ﺑﻬﺎ‬
‫ﻭﺍﻟﻮﺻﻮﻝﺇﻟﻰ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺍﻟﻤﺤﻤﻴﺔ‪.‬‬

‫ﻧﻘﺎﻁﺍﻟﻀﻌﻒ ﺍﻟﺸﺎﺉﻌﺔ‬

‫ﻳﻤﻜﻦﺗﻘﺴﻴﻢ ﻋﻨﺎﺻﺮ ﺍﻟﺘﺤﻜﻢ ﻓﻲ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﺛﻼﺙ ﻓﺉﺎﺕ ﻋﺮﻳﻀﺔ‪ :‬ﻋﻤﻮﺩﻳﺔ‪ ،‬ﻭﺃﻓﻘﻴﺔ‪ ،‬ﻭﻣﻌﺘﻤﺪﺓ‬
‫ﻋﻠﻰﺍﻟﺴﻴﺎﻕ‪.‬‬
‫ﺗﺘﻴﺢﺿﻮﺍﺑﻂ ﺍﻟﻮﺻﻮﻝ ﺍﻟﻌﻤﻮﺩﻳﺔ ﻷﻧﻮﺍﻉ ﻣﺨﺘﻠﻔﺔ ﻣﻦ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﺃﺟﺰﺍء ﻣﺨﺘﻠﻔﺔ‬
‫ﻣﻦﻭﻇﺎﺉﻒ ﺍﻟﺘﻄﺒﻴﻖ‪ .‬ﻓﻲ ﺃﺑﺴﻂ ﺍﻟﺤﺎﻻﺕ‪ ،‬ﻳﺘﻀﻤﻦ ﺫﻟﻚ ﻋﺎﺩﺓ ًﺗﻘﺴﻴﻤﺎً ﺑﻴﻦ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ‬
‫ﺍﻟﻌﺎﺩﻳﻴﻦﻭﺍﻟﻤﺴﺆﻭﻟﻴﻦ‪ .‬ﺃﻣﺎ ﻓﻲ ﺍﻟﺤﺎﻻﺕ ﺍﻷﻛﺜﺮ ﺗﻌﻘﻴﺪﺍً‪ ،‬ﻓﻘﺪ ﺗﺘﻀﻤﻦ ﺿﻮﺍﺑﻂ ﺍﻟﻮﺻﻮﻝ ﺍﻟﻌﻤﻮﺩﻳﺔ‬
‫ﺃﺩﻭﺍﺭﺍًﺩﻗﻴﻘﺔ ﻟﻠﻤﺴﺘﺨﺪﻣﻴﻦ ﺗﻤﻨﺤﻬﻢ ﺣﻖ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﻭﻇﺎﺉﻒ ﻣﺤﺪﺩﺓ‪ ،‬ﺣﻴﺚ ﻳﺨُﺼﺺ ﻟﻜﻞ‬
‫ﻣﺴﺘﺨﺪﻡﺩﻭﺭ ﻭﺍﺣﺪ ﺃﻭ ﻣﺠﻤﻮﻋﺔ ﻣﻦ ﺍﻷﺩﻭﺍﺭ ﺍﻟﻤﺨﺘﻠﻔﺔ‪.‬‬

‫ﺗﺘﻴﺢﺿﻮﺍﺑﻂ ﺍﻟﻮﺻﻮﻝ ﺍﻷﻓﻘﻴﺔ ﻟﻠﻤﺴﺘﺨﺪﻣﻴﻦ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﻣﺠﻤﻮﻋﺔ ﻓﺮﻋﻴﺔ ﻣﺤﺪﺩﺓ ﻣﻦ ﻣﺠﻤﻮﻋﺔ‬
‫ﺃﻭﺳﻊﻣﻦ ﺍﻟﻤﻮﺍﺭﺩ ﻣﻦ ﻧﻔﺲ ﺍﻟﻨﻮﻉ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﻗﺪ ﻳﺴﻤﺢ ﻟﻚ ﺗﻄﺒﻴﻖ ﺑﺮﻳﺪ ﺍﻟﻮﻳﺐ ﺑﻘﺮﺍءﺓ‬
‫ﺑﺮﻳﺪﻙﺍﻹﻟﻜﺘﺮﻭﻧﻲ ﺩﻭﻥ ﻗﺮﺍءﺓ ﺭﺳﺎﺉﻞ ﺃﻱ ﺷﺨﺺ ﺁﺧﺮ‪ ،‬ﻭﻗﺪ ﻳﺴﻤﺢ ﻟﻚ ﺍﻟﺒﻨﻚ ﺍﻹﻟﻜﺘﺮﻭﻧﻲ ﺑﺘﺤﻮﻳﻞ‬
‫ﺍﻷﻣﻮﺍﻝﻣﻦ ﺣﺴﺎﺑﻚ ﻓﻘﻂ‪ ،‬ﻭﻗﺪ ﻳﺴﻤﺢ ﻟﻚ ﺗﻄﺒﻴﻖ ﺳﻴﺮ ﺍﻟﻌﻤﻞ ﺑﺘﺤﺪﻳﺚ ﺍﻟﻤﻬﺎﻡ ﺍﻟﻤﻮﻛﻠﺔ ﺇﻟﻴﻚ ﺩﻭﻥ‬
‫ﻗﺮﺍءﺓﺍﻟﻤﻬﺎﻡ ﺍﻟﻤﻮﻛﻠﺔ ﻟﻶﺧﺮﻳﻦ‪.‬‬
‫ﺗﻀﻤﻦﺿﻮﺍﺑﻂ ﺍﻟﻮﺻﻮﻝ ﺍﻟﻤﻌﺘﻤﺪﺓ ﻋﻠﻰ ﺍﻟﺴﻴﺎﻕ ﺗﻘﻴﻴﺪ ﻭﺻﻮﻝ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺑﻤﺎ ﻫﻮ ﻣﺴﻤﻮﺡ ﺑﻪ‬
‫ﻓﻲﻇﻞ ﺣﺎﻟﺔ ﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﺤﺎﻟﻴﺔ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﺇﺫﺍ ﻛﺎﻥ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻳﺘﺎﺑﻊ ﻣﺮﺍﺣﻞ ﻣﺘﻌﺪﺩﺓ ﺿﻤﻦ‬
‫ﻋﻤﻠﻴﺔﻣﺎ‪ ،‬ﻓﻘﺪ ﺗﻤﻨﻌﻪ ﺿﻮﺍﺑﻂ ﺍﻟﻮﺻﻮﻝ ﺍﻟﻤﻌﺘﻤﺪﺓ ﻋﻠﻰ ﺍﻟﺴﻴﺎﻕ ﻣﻦ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﻣﺮﺍﺣﻞ ﺧﺎﺭﺝ‬
‫ﺍﻟﺘﺮﺗﻴﺐﺍﻟﻤﺤﺪﺩ‪.‬‬
‫ﻓﻲﻛﺜﻴﺮ ﻣﻦ ﺍﻟﺤﺎﻻﺕ‪ ،‬ﺗﺘﺪﺍﺧﻞ ﻋﻨﺎﺻﺮ ﺍﻟﺘﺤﻜﻢ ﻓﻲ ﺍﻟﻮﺻﻮﻝ ﺍﻟﺮﺃﺳﻴﺔ ﻭﺍﻷﻓﻘﻴﺔ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ‬
‫ﺍﻟﻤﺜﺎﻝ‪،‬ﻗﺪ ﻳﺴﻤﺢ ﺗﻄﺒﻴﻖ ﺗﺨﻄﻴﻂ ﻣﻮﺍﺭﺩ ﺍﻟﻤﺆﺳﺴﺔ ﻟﻜﻞ ﻣﻮﻇﻒ ﺣﺴﺎﺑﺎﺕ ﺑﺪﻓﻊ ﻓﻮﺍﺗﻴﺮ ﻭﺣﺪﺓ‬
‫ﺗﻨﻈﻴﻤﻴﺔﻣﺤﺪﺩﺓ ﺩﻭﻥ ﻏﻴﺮﻫﺎ‪ .‬ﻣﻦ ﻧﺎﺣﻴﺔ ﺃﺧﺮﻯ‪ ،‬ﻗﺪ ﻳﺴُﻤﺢ ﻟﻤﺪﻳﺮ ﺣﺴﺎﺑﺎﺕ ﺍﻟﺪﻓﻊ ﺑﺪﻓﻊ ﻓﻮﺍﺗﻴﺮ ﺃﻱ‬
‫ﻭﺣﺪﺓ‪.‬ﻭﺑﺎﻟﻤﺜﻞ‪ ،‬ﻗﺪ ﻳﺘﻤﻜﻦ ﺍﻟﻤﻮﻇﻔﻮﻥ ﻣﻦ ﺩﻓﻊ ﻓﻮﺍﺗﻴﺮ ﺑﻤﺒﺎﻟﻎ ﺻﻐﻴﺮﺓ‪ ،‬ﻭﻟﻜﻦ ﻳﺠﺐ ﻋﻠﻰ ﺍﻟﻤﺪﻳﺮ ﺩﻓﻊ‬
‫ﺍﻟﻔﻮﺍﺗﻴﺮﺍﻟﻜﺒﻴﺮﺓ‪ .‬ﻗﺪ ﻳﺘﻤﻜﻦ ﻣﺪﻳﺮ ﺍﻟﻤﺎﻟﻴﺔ ﻣﻦ ﻋﺮﺽ ﻣﺪﻓﻮﻋﺎﺕ ﺍﻟﻔﻮﺍﺗﻴﺮ ﻭﺍﻹﻳﺼﺎﻻﺕ ﻟﻜﻞ ﻭﺣﺪﺓ‬
‫ﺗﻨﻈﻴﻤﻴﺔﻓﻲ ﺍﻟﺸﺮﻛﺔ‪ ،‬ﻭﻟﻜﻦ ﻗﺪ ﻻ ﻳﺴُﻤﺢ ﻟﻪ ﺑﺪﻓﻊ ﺃﻱ ﻓﻮﺍﺗﻴﺮ‪.‬‬

‫ﺗﻌُﻄﻞَّﺿﻮﺍﺑﻂ ﺍﻟﻮﺻﻮﻝ ﺇﺫﺍ ﺗﻤﻜﻦّ ﺃﻱ ﻣﺴﺘﺨﺪﻡ ﻣﻦ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﻭﻇﺎﺉﻒ ﺃﻭ ﻣﻮﺍﺭﺩ ﻏﻴﺮ ﻣﺼُﺮ َ‬
‫ﺡّ‬
‫ﻟﻪﺑﻬﺎ‪ .‬ﻫﻨﺎﻙ ﺛﻼﺛﺔ ﺃﻧﻮﺍﻉ ﺭﺉﻴﺴﻴﺔ ﻣﻦ ﺍﻟﻬﺠﻤﺎﺕ ﻋﻠﻰ ﺿﻮﺍﺑﻂ ﺍﻟﻮﺻﻮﻝ‪ ،‬ﺗﺘﻮﺍﻓﻖ ﻣﻊ ﻓﺉﺎﺕ ﺍﻟﻀﻮﺍﺑﻂ‬
‫ﺍﻟﺜﻼﺙ‪:‬‬
‫ﺗﺼﻌﻴﺪﺍﻻﻣﺘﻴﺎﺯﺍﺕ ﺍﻟﺮﺃﺳﻴﺔﻳﺤﺪﺙ ﺫﻟﻚ ﻋﻨﺪﻣﺎ ﻳﺘﻤﻜﻦ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻣﻦ ﺃﺩﺍء ﻭﻇﺎﺉﻒ ﻻ‬ ‫‪-‬‬

‫ﻳﺴﻤﺢﻟﻪ ﺩﻭﺭﻩ ﺍﻟﻤﺴُﻨﺪ ﺇﻟﻴﻪ ﺑﻬﺎ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﺇﺫﺍ ﻛﺎﻥ ﺑﺈﻣﻜﺎﻥ ﻣﺴﺘﺨﺪﻡ ﻋﺎﺩﻱ ﺃﺩﺍء‬
‫ﻭﻇﺎﺉﻒﺇﺩﺍﺭﻳﺔ‪ ،‬ﺃﻭ ﻛﺎﻥ ﺑﺈﻣﻜﺎﻥ ﻣﻮﻇﻒ ﺩﻓﻊ ﻓﻮﺍﺗﻴﺮ ﻣﻬﻤﺎ ﻛﺎﻥ ﺣﺠﻤﻬﺎ‪ ،‬ﻓﺈﻥ ﺿﻮﺍﺑﻂ‬
‫ﺍﻟﻮﺻﻮﻝﺗﻜﻮﻥ ﻣﻌﻄﻠﺔ‪.‬‬
‫‪259‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺜﺎﻣﻦ‪-‬ﻣﻬﺎﺟﻤﺔ ﻋﻨﺎﺻﺮ ﺍﻟﺘﺤﻜﻢ ﻓﻲ ﺍﻟﻮﺻﻮﻝ‬

‫ﺗﺼﻌﻴﺪﺍﻻﻣﺘﻴﺎﺯﺍﺕ ﺍﻷﻓﻘﻲﻳﺤﺪﺙ ﺫﻟﻚ ﻋﻨﺪﻣﺎ ﻳﺘﻤﻜﻦ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻣﻦ ﻋﺮﺽ ﺃﻭ ﺗﻌﺪﻳﻞ‬ ‫‪-‬‬

‫ﻣﻮﺍﺭﺩﻏﻴﺮ ﻣﺨﻮﻟﺔ ﻟﻪ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﺇﺫﺍ ﻛﺎﻥ ﺑﺈﻣﻜﺎﻧﻚ ﺍﺳﺘﺨﺪﺍﻡ ﺗﻄﺒﻴﻖ ﺑﺮﻳﺪ ﺇﻟﻜﺘﺮﻭﻧﻲ‬
‫ﻟﻘﺮﺍءﺓﺭﺳﺎﺉﻞ ﺑﺮﻳﺪ ﺇﻟﻜﺘﺮﻭﻧﻲ ﻷﺷﺨﺎﺹ ﺁﺧﺮﻳﻦ‪ ،‬ﺃﻭ ﺇﺫﺍ ﻛﺎﻥ ﻣﻮﻇﻒ ﺍﻟﺪﻓﻊ ﻗﺎﺩﺭﺍً ﻋﻠﻰ ﻣﻌﺎﻟﺠﺔ‬
‫ﻓﻮﺍﺗﻴﺮﻭﺣﺪﺓ ﺗﻨﻈﻴﻤﻴﺔ ﻏﻴﺮ ﻭﺣﺪﺗﻪ‪ ،‬ﻓﺈﻥ ﺿﻮﺍﺑﻂ ﺍﻟﻮﺻﻮﻝ ﺗﻜﻮﻥ ﻣﻌﻄﻠﺔ‪.‬‬

‫ﺍﺳﺘﻐﻼﻝﻣﻨﻄﻖ ﺍﻷﻋﻤﺎﻝﻳﺤﺪﺙ ﻫﺬﺍ ﻋﻨﺪﻣﺎ ﻳﺴﺘﻐﻞ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺛﻐﺮﺓ ﻓﻲ ﺁﻟﻴﺔ ﺣﺎﻟﺔ‬ ‫‪-‬‬

‫ﺍﻟﺘﻄﺒﻴﻖﻟﻠﻮﺻﻮﻝ ﺇﻟﻰ ﻣﻮﺭﺩ ﺃﺳﺎﺳﻲ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﻗﺪ ﻳﺘﻤﻜﻦ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻣﻦ ﺗﺠﺎﻭﺯ‬
‫ﺧﻄﻮﺓﺍﻟﺪﻓﻊ ﻓﻲ ﻋﻤﻠﻴﺔ ﺷﺮﺍء‪.‬‬

‫ﻣﻦﺍﻟﺸﺎﺉﻊ ﻭﺟﻮﺩ ﺣﺎﻻﺕ ﺗﺆﺩﻱ ﻓﻴﻬﺎ ﺛﻐﺮﺓ ﻓﻲ ﺍﻟﻔﺼﻞ ﺍﻷﻓﻘﻲ ﻟﻠﺼﻼﺣﻴﺎﺕ ﻓﻲ ﺍﻟﺘﻄﺒﻴﻖ ﺇﻟﻰ‬
‫ﻫﺠﻮﻡﺗﺼﻌﻴﺪ ﻋﻤﻮﺩﻱ ﻓﻮﺭﻱ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﺇﺫﺍ ﻭﺟﺪ ﻣﺴﺘﺨﺪﻡ ﻃﺮﻳﻘﺔ ﻟﺘﻌﻴﻴﻦ ﻛﻠﻤﺔ ﻣﺮﻭﺭ‬
‫ﻣﺴﺘﺨﺪﻡﺁﺧﺮ‪ ،‬ﻓﻴﻤﻜﻨﻪ ﻣﻬﺎﺟﻤﺔ ﺣﺴﺎﺏ ﺇﺩﺍﺭﻱ ﻭﺍﻟﺘﺤﻜﻢ ﻓﻲ ﺍﻟﺘﻄﺒﻴﻖ‪.‬‬

‫ﻓﻲﺍﻟﺤﺎﻻﺕ ﺍﻟﻤﺬﻛﻮﺭﺓ ﺳﺎﺑﻘﺎً‪ ،‬ﺗﻤُﻜﻦّ ﺛﻐﺮﺍﺕ ﺿﻮﺍﺑﻂ ﺍﻟﻮﺻﻮﻝ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺍﻟﺬﻳﻦ ﺳﺠﻠّﻮﺍ‬
‫ﺩﺧﻮﻟﻬﻢﺇﻟﻰ ﺍﻟﺘﻄﺒﻴﻖ ﻓﻲ ﺳﻴﺎﻕ ﻣﺴﺘﺨﺪﻡ ﻣﻌُﻴﻦّ ﻣﻦ ﺗﻨﻔﻴﺬ ﺇﺟﺮﺍءﺍﺕ ﺃﻭ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﺑﻴﺎﻧﺎﺕ ﻻ‬
‫ﻳﺨُﻮﻟّﻬﻢﺫﻟﻚ ﺍﻟﺴﻴﺎﻕ ﺍﻟﻘﻴﺎﻡ ﺑﻬﺎ‪ .‬ﻭﻣﻊ ﺫﻟﻚ‪ ،‬ﻓﻲ ﺃﺧﻄﺮ ﺣﺎﻻﺕ ﺛﻐﺮﺍﺕ ﺿﻮﺍﺑﻂ ﺍﻟﻮﺻﻮﻝ‪ ،‬ﻗﺪ ﻳﺘﻤﻜﻦ‬
‫ﻣﺴﺘﺨﺪﻣﻮﻥﻏﻴﺮ ﻣﺼُﺮﺡّ ﻟﻬﻢ ﺗﻤﺎﻣﺎً ﻣﻦ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﻭﻇﺎﺉﻒ ﺃﻭ ﺑﻴﺎﻧﺎﺕ ﻣﺨُﺼﺼّﺔ ﻓﻘﻂ‬
‫ﻟﻠﻤﺴﺘﺨﺪﻣﻴﻦﺍﻟﻤﺼُﺎﺩﻕ ﻋﻠﻴﻬﻢ ﺍﻟﻤﺨُﺘﺼﻴّﻦ‪.‬‬

‫ﻭﻇﻴﻔﺔﻏﻴﺮ ﻣﺤﻤﻴﺔ ﺗﻤﺎﻣﺎً‬

‫ﻓﻲﻛﺜﻴﺮ ﻣﻦ ﺣﺎﻻﺕ ﺗﻌﻄﻞ ﺿﻮﺍﺑﻂ ﺍﻟﻮﺻﻮﻝ‪ ،‬ﻳﻤُﻜﻦ ﻷﻱ ﺷﺨﺺ ﻳﻌﺮﻑ ﻋﻨﻮﺍﻥ ‪ URL‬ﺫﻱ ﺍﻟﺼﻠﺔ‬
‫ﺍﻟﻮﺻﻮﻝﺇﻟﻰ ﺍﻟﻮﻇﺎﺉﻒ ﻭﺍﻟﻤﻮﺍﺭﺩ ﺍﻟﺤﺴﺎﺳﺔ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﻓﻲ ﺍﻟﻌﺪﻳﺪ ﻣﻦ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ‪ ،‬ﻳﻤُﻜﻦ‬
‫ﻷﻱﺷﺨﺺ ﻳﺰﻭﺭ ﻋﻨﻮﺍﻥ ‪ URL‬ﻣﺤُﺪﺩ ﺍﻻﺳﺘﻔﺎﺩﺓ ﺍﻟﻜﺎﻣﻠﺔ ﻣﻦ ﻭﻇﺎﺉﻔﻪ ﺍﻹﺩﺍﺭﻳﺔ‪:‬‬

‫‪https://wahh-app.com/admin/‬‬

‫ﻓﻲﻫﺬﻩ ﺍﻟﺤﺎﻟﺔ‪ ،‬ﻋﺎﺩﺓ ًﻣﺎ ﻳﻔﺮﺽ ﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﺘﺤﻜﻢ ﻓﻲ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﺍﻟﺤﺪ ﺍﻟﺘﺎﻟﻲ ﻓﻘﻂ‪ :‬ﻳﺮﻯ‬
‫ﺍﻟﻤﺴﺘﺨﺪﻣﻮﻥﺍﻟﺬﻳﻦ ﺳﺠﻠّﻮﺍ ﺩﺧﻮﻟﻬﻢ ﻛﻤﺴﺆﻭﻟﻴﻦ ﺭﺍﺑﻄﺎً ﻟﻬﺬﺍ ﺍﻟﺮﺍﺑﻂ ﻋﻠﻰ ﻭﺍﺟﻬﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺍﻟﺨﺎﺻﺔ‬
‫ﺑﻬﻢ‪،‬ﺑﻴﻨﻤﺎ ﻻ ﻳﺮﺍﻩ ﺍﻟﻤﺴﺘﺨﺪﻣﻮﻥ ﺍﻵﺧﺮﻭﻥ‪ .‬ﻫﺬﺍ ﺍﻻﺧﺘﻼﻑ ﺍﻟﺸﻜﻠﻲ ﻫﻮ ﺍﻵﻟﻴﺔ ﺍﻟﻮﺣﻴﺪﺓ ﺍﻟﻤﺘﺎﺣﺔ "‬
‫ﻟﺤﻤﺎﻳﺔ" ﺍﻟﻮﻇﺎﺉﻒ ﺍﻟﺤﺴﺎﺳﺔ ﻣﻦ ﺍﻻﺳﺘﺨﺪﺍﻡ ﻏﻴﺮ ﺍﻟﻤﺼﺮﺡ ﺑﻪ‪.‬‬

‫ﻓﻲﺑﻌﺾ ﺍﻷﺣﻴﺎﻥ‪ ،‬ﻗﺪ ﻳﻜﻮﻥ ﻣﻦ ﺍﻟﺼﻌﺐ ﺗﺨﻤﻴﻦ ﻋﻨﻮﺍﻥ ‪ URL‬ﺍﻟﺬﻱ ﻳﻤﻨﺢ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ‬
‫ﻭﻇﺎﺉﻒﻗﻮﻳﺔ‪ ،‬ﻭﻗﺪ ﻳﻜﻮﻥ ﻏﺎﻣﻀﺎً ﻟﻠﻐﺎﻳﺔ‪:‬‬

‫‪https://wahh-app.com/menus/secure/ff457/DoAdminMenu2.jsp‬‬

‫ﻫﻨﺎ‪،‬ﻳﺤُﻤﻰ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﺍﻟﻮﻇﺎﺉﻒ ﺍﻹﺩﺍﺭﻳﺔ ﺑﺎﻓﺘﺮﺍﺽ ﺃﻥ ﺍﻟﻤﻬﺎﺟﻢ ﻟﻦ ﻳﻌﺮﻑ ﺃﻭ ﻳﻜﺘﺸﻒ ﻋﻨﻮﺍﻥ‬
‫‪ URL‬ﻫﺬﺍ‪ .‬ﻳﺼﻌﺐ ﻋﻠﻰ ﺃﻱ ﺷﺨﺺ ﺧﺎﺭﺟﻲ ﺍﺧﺘﺮﺍﻕ ﺍﻟﺘﻄﺒﻴﻖ‪ ،‬ﻷﻧﻪ ﺃﻗﻞ ﻗﺪﺭﺓ ﻋﻠﻰ ﺗﺨﻤﻴﻦ ﻋﻨﻮﺍﻥ‬
‫‪ URL‬ﺍﻟﺬﻱ ﻳﻤﻜﻨﻪ ﻣﻦ ﺧﻼﻟﻪ ﺍﺧﺘﺮﺍﻗﻪ‪.‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺜﺎﻣﻦ‪-‬ﻣﻬﺎﺟﻤﺔ ﻋﻨﺎﺻﺮ ﺍﻟﺘﺤﻜﻢ ﻓﻲ ﺍﻟﻮﺻﻮﻝ‬ ‫‪260‬‬

‫ﺃﺳﻄﻮﺭﺓﺷﺎﺉﻌﺔ‬

‫ﻟﻦﻳﻌﺮﻑ ﺃﻱ ﻣﺴﺘﺨﺪﻡ ﺫﻱ ﺻﻼﺣﻴﺎﺕ ﻣﺤﺪﻭﺩﺓ ﻫﺬﺍ ﺍﻟﺮﺍﺑﻂ‪ .‬ﻻ ﻧﺸﻴﺮ ﺇﻟﻴﻪ ﻓﻲ ﺃﻱ ﻣﻜﺎﻥ ﺩﺍﺧﻞ‬
‫ﺍﻟﺘﻄﺒﻴﻖ‪.‬‬

‫ﻻﻳﺰﺍﻝ ﻏﻴﺎﺏ ﺃﻱ ﺗﺤﻜﻢ ﺣﻘﻴﻘﻲ ﻓﻲ ﺍﻟﻮﺻﻮﻝ ﻳﺸُﻜﻞ ﺛﻐﺮﺓ ﺧﻄﻴﺮﺓ‪ ،‬ﺑﻐﺾ ﺍﻟﻨﻈﺮ ﻋﻦ ﺳﻬﻮﻟﺔ ﺗﺨﻤﻴﻦ‬
‫ﻋﻨﻮﺍﻥ‪ .URL‬ﻻ ﺗﺘﻤﺘﻊ ﻋﻨﺎﻭﻳﻦ ‪ URL‬ﺑﺨﺎﺻﻴﺔ ﺍﻟﺴﺮﻳﺔ‪ ،‬ﺳﻮﺍء ﺩﺍﺧﻞ ﺍﻟﺘﻄﺒﻴﻖ ﻧﻔﺴﻪ ﺃﻭ ﻟﺪﻯ‬
‫ﻣﺴﺘﺨﺪﻣﻴﻪ‪.‬ﺗﻌُﺮﺽ ﻋﻠﻰ ﺍﻟﺸﺎﺷﺔ‪ ،‬ﻭﺗﻈﻬﺮ ﻓﻲ ﺳﺠﻼﺕ ﺍﻟﻤﺘﺼﻔﺢ ﻭﺳﺠﻼﺕ ﺧﻮﺍﺩﻡ ﺍﻟﻮﻳﺐ ﻭﺧﻮﺍﺩﻡ‬
‫ﺍﻟﺒﺮﻭﻛﺴﻲ‪.‬ﻳﻤﻜﻦ ﻟﻠﻤﺴﺘﺨﺪﻣﻴﻦ ﺗﺪﻭﻳﻨﻬﺎ‪ ،‬ﺃﻭ ﺣﻔﻈﻬﺎ ﻓﻲ ﺍﻟﻤﻔﻀﻠﺔ‪ ،‬ﺃﻭ ﺇﺭﺳﺎﻟﻬﺎ ﻋﺒﺮ ﺍﻟﺒﺮﻳﺪ ﺍﻹﻟﻜﺘﺮﻭﻧﻲ‪.‬‬
‫ﻻﺗﻐُﻴﺮ ﻋﺎﺩﺓ ًﺑﺸﻜﻞ ﺩﻭﺭﻱ‪ ،‬ﻛﻤﺎ ﻫﻮ ﺍﻟﺤﺎﻝ ﻣﻊ ﻛﻠﻤﺎﺕ ﺍﻟﻤﺮﻭﺭ‪ .‬ﻋﻨﺪﻣﺎ ﻳﻐُﻴﺮ ﺍﻟﻤﺴﺘﺨﺪﻣﻮﻥ ﺃﺩﻭﺍﺭﻫﻢ‬
‫ﺍﻟﻮﻇﻴﻔﻴﺔ‪،‬ﻭﻳﺤﺘﺎﺟﻮﻥ ﺇﻟﻰ ﺳﺤﺐ ﺻﻼﺣﻴﺎﺗﻬﻢ ﺍﻹﺩﺍﺭﻳﺔ‪ ،‬ﻻ ﺗﻮﺟﺪ ﻃﺮﻳﻘﺔ ﻟﺤﺬﻑ ﻣﻌﻠﻮﻣﺎﺗﻬﻢ ﻋﻦ ﻋﻨﻮﺍﻥ‬
‫‪ URL‬ﻣﻌُﻴﻦ‪.‬‬

‫ﻓﻲﺑﻌﺾ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺍﻟﺘﻲ ﺗﺨُﻔﻰ ﻓﻴﻬﺎ ﻭﻇﺎﺉﻒ ﺣﺴﺎﺳﺔ ﺧﻠﻒ ﻋﻨﺎﻭﻳﻦ ‪ URL‬ﻳﺼﻌﺐ ﺗﺨﻤﻴﻨﻬﺎ‪،‬‬
‫ﻗﺪﻳﺘﻤﻜﻦ ﺍﻟﻤﻬﺎﺟﻢ ﻏﺎﻟﺒﺎً ﻣﻦ ﺗﺤﺪﻳﺪﻫﺎ ﻣﻦ ﺧﻼﻝ ﻓﺤﺺ ﺩﻗﻴﻖ ﻟﺸﻔﺮﺓ ﺍﻟﻌﻤﻴﻞ‪ .‬ﺗﺴﺘﺨﺪﻡ ﺍﻟﻌﺪﻳﺪ ﻣﻦ‬
‫ﺍﻟﺘﻄﺒﻴﻘﺎﺕﺟﺎﻓﺎ ﺳﻜﺮﻳﺒﺖ ﻟﺒﻨﺎء ﻭﺍﺟﻬﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺩﻳﻨﺎﻣﻴﻜﻴﺎً ﺩﺍﺧﻞ ﺍﻟﻌﻤﻴﻞ‪ .‬ﻳﻌﻤﻞ ﻫﺬﺍ ﻋﺎﺩﺓ ًﻋﻦ‬
‫ﻃﺮﻳﻖﺗﻌﻴﻴﻦ ﻋﻼﻣﺎﺕ ﻣﺨﺘﻠﻔﺔ ﺗﺘﻌﻠﻖ ﺑﺤﺎﻟﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ‪ ،‬ﺛﻢ ﺇﺿﺎﻓﺔ ﻋﻨﺎﺻﺮ ﻓﺮﺩﻳﺔ ﺇﻟﻰ ﻭﺍﺟﻬﺔ‬
‫ﺍﻟﻤﺴﺘﺨﺪﻡﺑﻨﺎء ًﻋﻠﻰ ﻣﺎ ﻳﻠﻲ‪:‬‬

‫‪ . . .‬؛‪var isAdmin = false‬‬

‫ﺇﺫﺍﻛﺎﻥ )‪(isAdmin‬‬
‫}‬
‫‪adminMenu.addItem)"/menus/secure/ff457/addNewPortalUser2.jsp"،‬‬
‫"ﺇﻧﺸﺎء ﻣﺴﺘﺨﺪﻡ ﺟﺪﻳﺪ"(;‬
‫{‬

‫ﻫﻨﺎ‪،‬ﻳﻤﻜﻦ ﻟﻠﻤﻬﺎﺟﻢ ﺑﺒﺴﺎﻃﺔ ﻣﺮﺍﺟﻌﺔ ﺟﺎﻓﺎ ﺳﻜﺮﻳﺒﺖ ﻟﺘﺤﺪﻳﺪ ﻋﻨﺎﻭﻳﻦ ‪ URL‬ﻟﻠﻮﻇﺎﺉﻒ ﺍﻹﺩﺍﺭﻳﺔ‬
‫ﻭﻣﺤﺎﻭﻟﺔﺍﻟﻮﺻﻮﻝ ﺇﻟﻴﻬﺎ‪ .‬ﻓﻲ ﺣﺎﻻﺕ ﺃﺧﺮﻯ‪ ،‬ﻗﺪ ﺗﺤﺘﻮﻱ ﺗﻌﻠﻴﻘﺎﺕ ‪ HTML‬ﻋﻠﻰ ﺇﺷﺎﺭﺍﺕ ﺃﻭ ﺩﻻﺉﻞ‬
‫ﺣﻮﻝﻋﻨﺎﻭﻳﻦ ‪ URL‬ﻏﻴﺮ ﻣﺮﺗﺒﻄﺔ ﺑﻤﺤﺘﻮﻯ ﻋﻠﻰ ﺍﻟﺸﺎﺷﺔ‪ .‬ﻳﻨﺎﻗﺶ ﺍﻟﻔﺼﻞ ﺍﻟﺮﺍﺑﻊ ﺍﻟﺘﻘﻨﻴﺎﺕ ﺍﻟﻤﺨﺘﻠﻔﺔ‬
‫ﺍﻟﺘﻲﻳﻤﻜﻦ ﻟﻠﻤﻬﺎﺟﻢ ﻣﻦ ﺧﻼﻟﻬﺎ ﺟﻤﻊ ﻣﻌﻠﻮﻣﺎﺕ ﺣﻮﻝ ﺍﻟﻤﺤﺘﻮﻯ ﺍﻟﻤﺨﻔﻲ ﺩﺍﺧﻞ ﺍﻟﺘﻄﺒﻴﻖ‪.‬‬

‫ﺍﻟﻮﺻﻮﻝﺍﻟﻤﺒﺎﺷﺮ ﺇﻟﻰ ﺍﻷﺳﺎﻟﻴﺐ‬

‫ﻗﺪﺗﻨﺸﺄ ﺣﺎﻟﺔ ﻣﺤﺪﺩﺓ ﻣﻦ ﺍﻟﻮﻇﺎﺉﻒ ﻏﻴﺮ ﺍﻟﻤﺤﻤﻴﺔ ﻋﻨﺪﻣﺎ ﺗﻌﺮﺽ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﻋﻨﺎﻭﻳﻦ ‪ URL‬ﺃﻭ‬
‫ﻣﻌﻠﻤﺎﺕﺗﻌُﺪ ّﻓﻲ ﺍﻟﻮﺍﻗﻊ ﺍﺳﺘﺪﻋﺎءﺍﺕ ﻋﻦ ﺑﻌُﺪ ﻷﺳﺎﻟﻴﺐ ﻭﺍﺟﻬﺔ ﺑﺮﻣﺠﺔ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ )‪ ،(API‬ﻭﻋﺎﺩﺓ ًﻣﺎ‬
‫ﺗﻜﻮﻥﺗﻠﻚ ﺍﻟﺘﻲ ﺗﻌﺮﺿﻬﺎ ﻭﺍﺟﻬﺔ ‪ .Java‬ﻳﺤﺪﺙ ﻫﺬﺍ ﻏﺎﻟﺒﺎً ﻋﻨﺪ ﻧﻘﻞ ﺷﻴﻔﺮﺓ ﻣﻦ ﺟﺎﻧﺐ ﺍﻟﺨﺎﺩﻡ ﺇﻟﻰ‬
‫ﻣﻜﻮﻥﻣﻠﺤﻖ ﻟﻠﻤﺘﺼﻔﺢ ﻭﺇﻧﺸﺎء ﺑﻘُﻊ ﻟﻸﺳﺎﻟﻴﺐ ﺑﺤﻴﺚ ﻳﻈﻞ ﺑﺈﻣﻜﺎﻥ ﺍﻟﺸﻴﻔﺮﺓ ﺍﺳﺘﺪﻋﺎء ﺃﺳﺎﻟﻴﺐ‬
‫ﺟﺎﻧﺐﺍﻟﺨﺎﺩﻡ ﺍﻟﺘﻲ ﺗﺤﺘﺎﺟﻬﺎ ﻟﻠﻌﻤﻞ‪ .‬ﺧﺎﺭﺝ ﻫﺬﻩ ﺍﻟﺤﺎﻟﺔ‪ ،‬ﻳﻤﻜﻦ ﺗﺤﺪﻳﺪ ﺑﻌﺾ ﺣﺎﻻﺕ ﺍﻟﻮﺻﻮﻝ ﺍﻟﻤﺒﺎﺷﺮ‬
‫ﺇﻟﻰﺍﻷﺳﺎﻟﻴﺐ ﺣﻴﺚ ﺗﺴﺘﺨﺪﻡ ﻋﻨﺎﻭﻳﻦ ‪ URL‬ﺃﻭ ﺍﻟﻤﻌﻠﻤﺎﺕ ﺍﺻﻄﻼﺣﺎﺕ ﺗﺴﻤﻴﺔ ‪ Java‬ﺍﻟﻘﻴﺎﺳﻴﺔ‪ ،‬ﻣﺜﻞ‬

‫ﺍﻟﺤﺼﻮﻝﻋﻠﻰ ﺍﻟﺘﻮﺍﺯﻥﻭﺍﻧﺘﻬﺖ ﺻﻼﺣﻴﺘﻬﺎ‪.‬‬

‫‪261‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺜﺎﻣﻦ‪-‬ﻣﻬﺎﺟﻤﺔ ﻋﻨﺎﺻﺮ ﺍﻟﺘﺤﻜﻢ ﻓﻲ ﺍﻟﻮﺻﻮﻝ‬

‫ﻣﻦﺣﻴﺚ ﺍﻟﻤﺒﺪﺃ‪ ،‬ﻻ ﻳﻠﺰﻡ ﺃﻥ ﺗﻜﻮﻥ ﺍﻟﻄﻠﺒﺎﺕ ﺍﻟﺘﻲ ﺗﺤﺪﺩ ﻭﺍﺟﻬﺔ ﺑﺮﻣﺠﺔ ﺗﻄﺒﻴﻘﺎﺕ ﻣﻦ ﺟﺎﻧﺐ‬
‫ﺍﻟﺨﺎﺩﻡﺍﻟﻤﺮﺍﺩ ﺗﻨﻔﻴﺬﻫﺎ ﺃﻗﻞ ﺃﻣﺎﻧﺎً ﻣﻦ ﺗﻠﻚ ﺍﻟﺘﻲ ﺗﺤﺪﺩ ﻧﺼﺎً ﺑﺮﻣﺠﻴﺎً ﻣﻦ ﺟﺎﻧﺐ ﺍﻟﺨﺎﺩﻡ ﺃﻭ ﻣﻮﺭﺩﺍً ﺁﺧﺮ‪.‬‬
‫ﻭﻣﻊﺫﻟﻚ‪ ،‬ﻓﻲ ﺍﻟﻤﻤﺎﺭﺳﺔ ﺍﻟﻌﻤﻠﻴﺔ‪ ،‬ﻏﺎﻟﺒﺎً ﻣﺎ ﻳﺤﺘﻮﻱ ﻫﺬﺍ ﺍﻟﻨﻮﻉ ﻣﻦ ﺍﻵﻟﻴﺎﺕ ﻋﻠﻰ ﺛﻐﺮﺍﺕ ﺃﻣﻨﻴﺔ‪ .‬ﻏﺎﻟﺒﺎً‬
‫ﻣﺎﻳﺘﻔﺎﻋﻞ ﺍﻟﻌﻤﻴﻞ ﻣﺒﺎﺷﺮﺓ ًﻣﻊ ﺃﺳﺎﻟﻴﺐ ﻭﺍﺟﻬﺔ ﺑﺮﻣﺠﺔ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﻣﻦ ﺟﺎﻧﺐ ﺍﻟﺨﺎﺩﻡ ﻭﻳﺘﺠﺎﻭﺯ‬
‫ﺿﻮﺍﺑﻂﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﻤﻌﺘﺎﺩﺓ ﻋﻠﻰ ﺍﻟﻮﺻﻮﻝ ﺃﻭ ﻣﺘﺠﻬﺎﺕ ﺍﻹﺩﺧﺎﻝ ﻏﻴﺮ ﺍﻟﻤﺘﻮﻗﻌﺔ‪ .‬ﻫﻨﺎﻙ ﺃﻳﻀﺎً ﺍﺣﺘﻤﺎﻝ‬
‫ﻭﺟﻮﺩﻭﻇﺎﺉﻒ ﺃﺧﺮﻯ ﻳﻤﻜﻦ ﺍﺳﺘﺪﻋﺎﺅﻫﺎ ﺑﻬﺬﻩ ﺍﻟﻄﺮﻳﻘﺔ ﻭﻻ ﺗﻜﻮﻥ ﻣﺤﻤﻴﺔ ﺑﺄﻱ ﺿﻮﺍﺑﻂ‪ ،‬ﻋﻠﻰ ﺍﻓﺘﺮﺍﺽ‬
‫ﺃﻧﻪﻻ ﻳﻤﻜﻦ ﺃﺑﺪﺍً ﺍﺳﺘﺪﻋﺎﺅﻫﺎ ﻣﺒﺎﺷﺮﺓ ًﺑﻮﺍﺳﻄﺔ ﻋﻤﻼء ﺗﻄﺒﻴﻖ ﺍﻟﻮﻳﺐ‪ .‬ﻏﺎﻟﺒﺎً ﻣﺎ ﺗﻜﻮﻥ ﻫﻨﺎﻙ ﺣﺎﺟﺔ ﺇﻟﻰ‬
‫ﻣﻨﺢﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﺣﻖ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﺃﺳﺎﻟﻴﺐ ﻣﺤﺪﺩﺓ ﻣﻌﻴﻨﺔ‪ ،‬ﻭﻟﻜﻦ ﺑﺪﻻ ًﻣﻦ ﺫﻟﻚ ﻳﺘﻢ ﻣﻨﺤﻬﻢ ﺣﻖ‬
‫ﺍﻟﻮﺻﻮﻝﺇﻟﻰ ﺟﻤﻴﻊ ﺍﻷﺳﺎﻟﻴﺐ‪ .‬ﻫﺬﺍ ﺇﻣﺎ ﻷﻥ ﺍﻟﻤﻄﻮﺭ ﻟﻴﺲ ﻋﻠﻰ ﺩﺭﺍﻳﺔ ﻛﺎﻣﻠﺔ ﺑﻤﺠﻤﻮﻋﺔ ﻓﺮﻋﻴﺔ ﻣﻦ‬
‫ﺍﻷﺳﺎﻟﻴﺐﺍﻟﺘﻲ ﻳﺠﺐ ﺗﻮﻛﻴﻠﻬﺎ ﻭﻳﻮﻓﺮ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﺟﻤﻴﻊ ﺍﻷﺳﺎﻟﻴﺐ‪ ،‬ﺃﻭ ﻷﻥ ﻭﺍﺟﻬﺔ ﺑﺮﻣﺠﺔ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ‬
‫ﺍﻟﻤﺴﺘﺨﺪﻣﺔﻟﺮﺑﻄﻬﺎ ﺑﺨﺎﺩﻡ ‪ HTTP‬ﺗﻮﻓﺮ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﺟﻤﻴﻊ ﺍﻷﺳﺎﻟﻴﺐ ﺍﻓﺘﺮﺍﺿﻴﺎً‪.‬‬

‫ﻳﻮﺿﺢﺍﻟﻤﺜﺎﻝ ﺍﻟﺘﺎﻟﻲﺍﻟﺤﺼﻮﻝ ﻋﻠﻰ ﺃﺩﻭﺍﺭ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺍﻟﺤﺎﻟﻴﺔﺍﻟﻄﺮﻳﻘﺔ ﺍﻟﺘﻲ ﻳﺘﻢ ﺍﺳﺘﺪﻋﺎﺅﻫﺎ ﻣﻦ ﺩﺍﺧﻞ‬
‫ﺍﻟﻮﺍﺟﻬﺔﻓﺤﺺ ﺍﻷﻣﺎﻥ‪:‬‬

‫‪http://wahh-app.com/public/securityCheck/getCurrentUserRoles‬‬

‫ﻓﻲﻫﺬﺍ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﺑﺎﻹﺿﺎﻓﺔ ﺇﻟﻰ ﺍﺧﺘﺒﺎﺭ ﻋﻨﺎﺻﺮ ﺍﻟﺘﺤﻜﻢ ﻓﻲ ﺍﻟﻮﺻﻮﻝ ﻋﺒﺮﺍﻟﺤﺼﻮﻝ ﻋﻠﻰ ﺃﺩﻭﺍﺭ ﺍﻟﻤﺴﺘﺨﺪﻡ‬
‫ﺍﻟﺤﺎﻟﻴﺔﺍﻟﻄﺮﻳﻘﺔ‪ ،‬ﻳﺠﺐ ﻋﻠﻴﻚ ﺍﻟﺘﺤﻘﻖ ﻣﻦ ﻭﺟﻮﺩ ﻃﺮﻕ ﺃﺧﺮﻯ ﻣﻤﺎﺛﻠﺔ‬
‫ﻃﺮﻕﻣﺴﻤﺎﺓ ﻣﺜﻞ‪getAllUserRoles، getAllRoles، getAllUsers،‬ﻭ‬
‫ﺍﻟﺤﺼﻮﻝﻋﻠﻰ ﺃﺫﻭﻧﺎﺕ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺍﻟﺤﺎﻟﻴﺔ‪.‬ﻭﺳﻴﺘﻢ ﻭﺻﻒ ﺍﻻﻋﺘﺒﺎﺭﺍﺕ ﺍﻷﺧﺮﻯ ﺍﻟﺨﺎﺻﺔ ﺑﺎﺧﺘﺒﺎﺭ ﺍﻟﻮﺻﻮﻝ‬
‫ﺍﻟﻤﺒﺎﺷﺮﺇﻟﻰ ﺍﻷﺳﺎﻟﻴﺐ ﻻﺣﻘﺎً ﻓﻲ ﻫﺬﺍ ﺍﻟﻔﺼﻞ‪.‬‬

‫ﺍﻟﻮﻇﺎﺉﻒﺍﻟﻘﺎﺉﻤﺔ ﻋﻠﻰ ﺍﻟﻤﻌﺮﻑ‬

‫ﻋﻨﺪﻣﺎﻳﺘﻢ ﺍﺳﺘﺨﺪﺍﻡ ﻭﻇﻴﻔﺔ ﺗﻄﺒﻴﻖ ﻟﻠﻮﺻﻮﻝ ﺇﻟﻰ ﻣﻮﺭﺩ ﻣﻌﻴﻦ‪ ،‬ﻓﻤﻦ ﺍﻟﺸﺎﺉﻊ ﺭﺅﻳﺔ ﻣﻌﺮﻑ ﻟﻠﻤﻮﺭﺩ‬
‫ﺍﻟﻤﻄﻠﻮﺏﻳﺘﻢ ﺗﻤﺮﻳﺮﻩ ﺇﻟﻰ ﺍﻟﺨﺎﺩﻡ ﻓﻲ ﻣﻌﻠﻤﺔ ﻃﻠﺐ‪ ،‬ﺇﻣﺎ ﺩﺍﺧﻞ ﺳﻠﺴﻠﺔ ﺍﺳﺘﻌﻼﻡ ‪ URL‬ﺃﻭ ﻧﺺﺑﺮﻳﺪﻋﻠﻰ‬
‫ﺳﺒﻴﻞﺍﻟﻤﺜﺎﻝ‪ ،‬ﻗﺪ ﻳﺴﺘﺨﺪﻡ ﺗﻄﺒﻴﻖ ﻋﻨﻮﺍﻥ ‪ URL‬ﺍﻟﺘﺎﻟﻲ ﻟﻌﺮﺽ ﻣﺴﺘﻨﺪ ﻣﺤﺪﺩ ﻳﺨﺺ ﻣﺴﺘﺨﺪﻣﺎً‬
‫ﻣﻌﻴﻨﺎً‪:‬‬

‫‪https://wahh-app.com/ViewDocument.php?docid=1280149120‬‬

‫ﻋﻨﺪﺗﺴﺠﻴﻞ ﺩﺧﻮﻝ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻣﺎﻟﻚ ﺍﻟﻤﺴﺘﻨﺪ‪ ،‬ﻳﻌُﺮﺽ ﺭﺍﺑﻂ ﻟﻬﺬﺍ ﺍﻟﺮﺍﺑﻂ ﻓﻲ ﺻﻔﺤﺔ "ﻣﺴﺘﻨﺪﺍﺗﻲ"‪.‬‬
‫ﻻﻳﺮﻯ ﺍﻟﻤﺴﺘﺨﺪﻣﻮﻥ ﺍﻵﺧﺮﻭﻥ ﻫﺬﺍ ﺍﻟﺮﺍﺑﻂ‪ .‬ﻣﻊ ﺫﻟﻚ‪ ،‬ﻓﻲ ﺣﺎﻝ ﺗﻌﻄﻞ ﺿﻮﺍﺑﻂ ﺍﻟﻮﺻﻮﻝ‪ ،‬ﻗﺪ ﻳﺘﻤﻜﻦ‬
‫ﺃﻱﻣﺴﺘﺨﺪﻡ ﻳﻄﻠﺐ ﺍﻟﺮﺍﺑﻂ ﻣﻦ ﻋﺮﺽ ﺍﻟﻤﺴﺘﻨﺪ ﺑﻨﻔﺲ ﻃﺮﻳﻘﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺍﻟﻤﺼُﺮﺡّ ﻟﻪ‪.‬‬

‫ﻧﺼﻴﺤﺔﻏﺎﻟﺒﺎً ﻣﺎ ﻳﻨﺸﺄ ﻫﺬﺍ ﺍﻟﻨﻮﻉ ﻣﻦ ﺍﻟﺜﻐﺮﺍﺕ ﺍﻷﻣﻨﻴﺔ ﻋﻨﺪ ﺗﻔﺎﻋﻞ ﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﺮﺉﻴﺴﻲ ﻣﻊ ﻧﻈﺎﻡ‬
‫ﺧﺎﺭﺟﻲﺃﻭ ﻣﻜﻮﻥ ﺧﻠﻔﻲ‪ .‬ﻗﺪ ﻳﻜﻮﻥ ﻣﻦ ﺍﻟﺼﻌﺐ ﻣﺸﺎﺭﻛﺔ ﻧﻤﻮﺫﺝ ﺃﻣﺎﻥ ﻗﺎﺉﻢ ﻋﻠﻰ ﺍﻟﺠﻠﺴﺔ ﺑﻴﻦ ﺃﻧﻈﻤﺔ‬
‫ﻣﺨﺘﻠﻔﺔﻗﺪ ﺗﻌﺘﻤﺪ ﻋﻠﻰ ﺗﻘﻨﻴﺎﺕ ﻣﺘﻨﻮﻋﺔ‪ .‬ﻓﻲ ﻣﻮﺍﺟﻬﺔ ﻫﺬﻩ ﺍﻟﻤﺸﻜﻠﺔ‪ ،‬ﻳﻠﺠﺄ ﺍﻟﻤﻄﻮﺭﻭﻥ ﻏﺎﻟﺒﺎً ﺇﻟﻰ‬
‫ﺍﺧﺘﺼﺎﺭﺍﻟﻄﺮﻳﻖ ﻭﺍﻟﺘﺨﻠﻲ ﻋﻦ ﻫﺬﺍ ﺍﻟﻨﻤﻮﺫﺝ‪ ،‬ﻣﺴﺘﺨﺪﻣﻴﻦ ﻣﻌﻠﻤﺎﺕ ﻣﻘﺪﻣﺔ ﻣﻦ ﺍﻟﻌﻤﻴﻞ ﻻﺗﺨﺎﺫ ﻗﺮﺍﺭﺍﺕ‬
‫ﺍﻟﺘﺤﻜﻢﻓﻲ ﺍﻟﻮﺻﻮﻝ‪.‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺜﺎﻣﻦ‪-‬ﻣﻬﺎﺟﻤﺔ ﻋﻨﺎﺻﺮ ﺍﻟﺘﺤﻜﻢ ﻓﻲ ﺍﻟﻮﺻﻮﻝ‬ ‫‪262‬‬

‫ﻓﻲﻫﺬﺍ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﻳﺤﺘﺎﺝ ﺍﻟﻤﻬﺎﺟﻢ ﺍﻟﺬﻱ ﻳﺴﻌﻰ ﺇﻟﻰ ﺍﻟﺤﺼﻮﻝ ﻋﻠﻰ ﻭﺻﻮﻝ ﻏﻴﺮ ﻣﺼﺮﺡ ﺑﻪ ﺇﻟﻰ‬
‫ﻣﻌﺮﻓﺔﻟﻴﺲ ﻓﻘﻂ ﺍﺳﻢ ﺻﻔﺤﺔ ﺍﻟﺘﻄﺒﻴﻖ ))ﻋﺮﺽ ﺍﻟﻤﺴﺘﻨﺪ‪(php.‬ﻭﻟﻜﻦ ﺃﻳﻀﺎً ﻣﻌﺮﻑ ﺍﻟﻤﺴﺘﻨﺪ ﺍﻟﺬﻱ ﻳﺮﻳﺪ‬
‫ﻋﺮﺿﻪ‪.‬ﻓﻲ ﺑﻌﺾ ﺍﻷﺣﻴﺎﻥ‪ ،‬ﻳﺘﻢ ﺇﻧﺸﺎء ﻣﻌﺮﻓﺎﺕ ﺍﻟﻤﻮﺍﺭﺩ ﺑﻄﺮﻳﻘﺔ ﻏﻴﺮ ﻣﺘﻮﻗﻌﺔ ﻟﻠﻐﺎﻳﺔ؛ ﻋﻠﻰ ﺳﺒﻴﻞ‬
‫ﺍﻟﻤﺜﺎﻝ‪،‬ﻗﺪ ﺗﻜﻮﻥ ﻣﻌﺮﻓﺎﺕ ‪ GUID‬ﻣﺨﺘﺎﺭﺓ ﻋﺸﻮﺍﺉﻴﺎً‪ .‬ﻓﻲ ﺣﺎﻻﺕ ﺃﺧﺮﻯ‪ ،‬ﻗﺪ ﻳﺴﻬﻞ ﺗﺨﻤﻴﻨﻬﺎ؛ ﻋﻠﻰ‬
‫ﺳﺒﻴﻞﺍﻟﻤﺜﺎﻝ‪ ،‬ﻗﺪ ﺗﻜﻮﻥ ﺃﺭﻗﺎﻣﺎً ﺗﻢ ﺇﻧﺸﺎﺅﻫﺎ ﺑﺸﻜﻞ ﻣﺘﺴﻠﺴﻞ‪ .‬ﻭﻣﻊ ﺫﻟﻚ‪ ،‬ﻳﻜﻮﻥ ﺍﻟﺘﻄﺒﻴﻖ ﺿﻌﻴﻔﺎً ﻓﻲ‬
‫ﻛﻠﺘﺎﺍﻟﺤﺎﻟﺘﻴﻦ‪ .‬ﻛﻤﺎ ﻫﻮ ﻣﻮﺿﺢ ﺳﺎﺑﻘﺎً‪ ،‬ﻻ ﺗﺘﻤﺘﻊ ﻋﻨﺎﻭﻳﻦ ‪ URL‬ﺑﺤﺎﻟﺔ ﺍﻷﺳﺮﺍﺭ‪ ،‬ﻭﻳﻨﻄﺒﻖ ﺍﻟﺸﻲء ﻧﻔﺴﻪ‬
‫ﻋﻠﻰﻣﻌﺮﻓﺎﺕ ﺍﻟﻤﻮﺍﺭﺩ‪ .‬ﻏﺎﻟﺒﺎً ﻣﺎ ﻳﻤﻜﻦ ﻟﻠﻤﻬﺎﺟﻢ ﺍﻟﺬﻱ ﻳﺮﻳﺪ ﺍﻛﺘﺸﺎﻑ ﻣﻌﺮﻓﺎﺕ ﻣﻮﺍﺭﺩ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ‬
‫ﺍﻵﺧﺮﻳﻦﺍﻟﻌﺜﻮﺭ ﻋﻠﻰ ﺑﻌﺾ ﺍﻟﻤﻮﺍﻗﻊ ﺩﺍﺧﻞ ﺍﻟﺘﻄﺒﻴﻖ ﺍﻟﺘﻲ ﺗﻜﺸﻒ ﻋﻦ ﻫﺬﻩ‪ ،‬ﻣﺜﻞ ﺳﺠﻼﺕ ﺍﻟﻮﺻﻮﻝ‪.‬‬
‫ﺣﺘﻰﻋﻨﺪﻣﺎ ﻻ ﻳﻤﻜﻦ ﺗﺨﻤﻴﻦ ﻣﻌﺮﻓﺎﺕ ﻣﻮﺍﺭﺩ ﺍﻟﺘﻄﺒﻴﻖ ﺑﺴﻬﻮﻟﺔ‪ ،‬ﻻ ﻳﺰﺍﻝ ﺍﻟﺘﻄﺒﻴﻖ ﺿﻌﻴﻔﺎً ﺇﺫﺍ ﻓﺸﻞ‬
‫ﻓﻲﺍﻟﺘﺤﻜﻢ ﺑﺸﻜﻞ ﺻﺤﻴﺢ ﻓﻲ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﺗﻠﻚ ﺍﻟﻤﻮﺍﺭﺩ‪ .‬ﻓﻲ ﺍﻟﺤﺎﻻﺕ ﺍﻟﺘﻲ ﻳﺘﻢ ﻓﻴﻬﺎ ﺍﻟﺘﻨﺒﺆ‬
‫ﺑﺎﻟﻤﻌﺮﻓﺎﺕﺑﺴﻬﻮﻟﺔ‪ ،‬ﺗﻜﻮﻥ ﺍﻟﻤﺸﻜﻠﺔ ﺃﻛﺜﺮ ﺧﻄﻮﺭﺓ ﻭﺃﺳﻬﻞ ﺍﺳﺘﻐﻼﻻً‪.‬‬

‫ﻧﺼﻴﺤﺔﻏﺎﻟﺒﺎً ﻣﺎ ﺗﻌُﺪ ّﺳﺠﻼﺕ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﻛﻨﺰﺍً ﺛﻤﻴﻨﺎً ﻟﻠﻤﻌﻠﻮﻣﺎﺕ‪ .‬ﻗﺪ ﺗﺤﺘﻮﻱ ﻋﻠﻰ ﺍﻟﻌﺪﻳﺪ ﻣﻦ‬
‫ﻋﻨﺎﺻﺮﺍﻟﺒﻴﺎﻧﺎﺕ ﺍﻟﺘﻲ ﻳﻤُﻜﻦ ﺍﺳﺘﺨﺪﺍﻣﻬﺎ ﻛﻤﻌُﺮﻓّﺎﺕ ﻟﻠﺘﺤﻘﻖ ﻣﻦ ﺍﻟﻮﻇﺎﺉﻒ ﺍﻟﺘﻲ ﻳﺘﻢ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻴﻬﺎ‬
‫ﺑﻬﺬﻩﺍﻟﻄﺮﻳﻘﺔ‪ .‬ﺗﺸﻤﻞ ﺍﻟﻤﻌُﺮﻓّﺎﺕ ﺍﻟﺸﺎﺉﻌﺔ ﻓﻲ ﺳﺠﻼﺕ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﺃﺳﻤﺎء ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ‪ ،‬ﻭﺃﺭﻗﺎﻡ‬
‫ﻣﻌُﺮﻓّﺎﺕﺍﻟﻤﺴﺘﺨﺪﻡ‪ ،‬ﻭﺃﺭﻗﺎﻡ ﺍﻟﺤﺴﺎﺑﺎﺕ‪ ،‬ﻭﻣﻌﺮﻓﺎﺕ ﺍﻟﻤﺴﺘﻨﺪﺍﺕ‪ ،‬ﻭﻣﺠﻤﻮﻋﺎﺕ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ‬
‫ﻭﺃﺩﻭﺍﺭﻫﻢ‪،‬ﻭﻋﻨﺎﻭﻳﻦ ﺍﻟﺒﺮﻳﺪ ﺍﻹﻟﻜﺘﺮﻭﻧﻲ‪.‬‬

‫ﻣﻠﺤﻮﻇﺔﺑﺎﻹﺿﺎﻓﺔ ﺇﻟﻰ ﺍﺳﺘﺨﺪﺍﻣﻪ ﻛﻤﺮﺍﺟﻊ ﻟﻤﻮﺍﺭﺩ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺩﺍﺧﻞ ﺍﻟﺘﻄﺒﻴﻖ‪ ،‬ﻳﺴُﺘﺨﺪﻡ ﻫﺬﺍ ﺍﻟﻨﻮﻉ ﻣﻦ‬
‫ﺍﻟﻤﻌُﺮﻓِّﺎﺕﻏﺎﻟﺒﺎً ﻟﻺﺷﺎﺭﺓ ﺇﻟﻰ ﻭﻇﺎﺉﻒ ﺍﻟﺘﻄﺒﻴﻖ ﻧﻔﺴﻪ‪ .‬ﻛﻤﺎ ﺭﺃﻳﺘﻢ ﻓﻲ ﺍﻟﻔﺼﻞ ﺍﻟﺮﺍﺑﻊ‪ ،‬ﻗﺪ ﻳﻘُﺪﻡِّ‬
‫ﺍﻟﺘﻄﺒﻴﻖﻭﻇﺎﺉﻒ ﻣﺨﺘﻠﻔﺔ ﻋﺒﺮ ﺻﻔﺤﺔ ﻭﺍﺣﺪﺓ ﺗﻘﺒﻞ ﺍﺳﻢ ﻭﻇﻴﻔﺔ ﺃﻭ ﻣﻌُﺮﻓِّﺎً ﻛﻤﻌﺎﻣﻞ‪ .‬ﻓﻲ ﻫﺬﻩ ﺍﻟﺤﺎﻟﺔ‬
‫ﺃﻳﻀﺎً‪،‬ﻗﺪ ﺗﻘﺘﺼﺮ ﺿﻮﺍﺑﻂ ﺍﻟﻮﺻﻮﻝ ﻋﻠﻰ ﻭﺟﻮﺩ ﺃﻭ ﻋﺪﻡ ﻭﺟﻮﺩ ﻋﻨﺎﻭﻳﻦ ‪ URL‬ﻣﺤُﺪﺩَّﺓ ﺿﻤﻦ ﻭﺍﺟﻬﺎﺕ‬
‫ﺃﻧﻮﺍﻉﻣﺨﺘﻠﻔﺔ ﻣﻦ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ‪ .‬ﺇﺫﺍ ﺗﻤﻜﻦّ ﻣﻬُﺎﺟﻢ ﻣﻦ ﺗﺤﺪﻳﺪ ﻣﻌُﺮﻑِّ ﻭﻇﻴﻔﺔ ﺣﺴﺎﺳﺔ‪ ،‬ﻓﻘﺪ ﻳﺘﻤﻜﻦ‬
‫ﻣﻦﺍﻟﻮﺻﻮﻝ ﺇﻟﻴﻬﺎ ﺑﻨﻔﺲ ﻃﺮﻳﻘﺔ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﻣﺴﺘﺨﺪﻡ ﺫﻱ ﺻﻼﺣﻴﺎﺕ ﺃﻋﻠﻰ‪.‬‬

‫ﻭﻇﺎﺉﻒﻣﺘﻌﺪﺩﺓ ﺍﻟﻤﺮﺍﺣﻞ‬
‫ﻳﺘﻢﺗﻨﻔﻴﺬ ﺍﻟﻌﺪﻳﺪ ﻣﻦ ﺍﻟﻮﻇﺎﺉﻒ ﺩﺍﺧﻞ ﺍﻟﺘﻄﺒﻴﻖ ﻋﺒﺮ ﻋﺪﺓ ﻣﺮﺍﺣﻞ‪ ،‬ﺗﺘﻀﻤﻦ ﺇﺭﺳﺎﻝ ﻃﻠﺒﺎﺕ ﻣﺘﻌﺪﺩﺓ‬
‫ﻣﻦﺍﻟﻌﻤﻴﻞ ﺇﻟﻰ ﺍﻟﺨﺎﺩﻡ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﻗﺪ ﺗﺘﻀﻤﻦ ﻭﻇﻴﻔﺔ ﺇﺿﺎﻓﺔ ﻣﺴﺘﺨﺪﻡ ﺟﺪﻳﺪ ﺍﺧﺘﻴﺎﺭ ﻫﺬﺍ‬
‫ﺍﻟﺨﻴﺎﺭﻣﻦ ﻗﺎﺉﻤﺔ ﺻﻴﺎﻧﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ‪ ،‬ﻭﺍﺧﺘﻴﺎﺭ ﺍﻟﻘﺴﻢ ﻭﺩﻭﺭ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻣﻦ ﺍﻟﻘﻮﺍﺉﻢ ﺍﻟﻤﻨﺴﺪﻟﺔ‪ ،‬ﺛﻢ‬
‫ﺇﺩﺧﺎﻝﺍﺳﻢ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺍﻟﺠﺪﻳﺪ ﻭﻛﻠﻤﺔ ﺍﻟﻤﺮﻭﺭ ﺍﻷﻭﻟﻴﺔ ﻭﻣﻌﻠﻮﻣﺎﺕ ﺃﺧﺮﻯ‪.‬‬

‫ﻣﻦﺍﻟﺸﺎﺉﻊ ﻣﻮﺍﺟﻬﺔ ﺗﻄﺒﻴﻘﺎﺕ ﺗﻢ ﻓﻴﻬﺎ ﺑﺬﻝ ﺟﻬﻮﺩ ﻟﺤﻤﺎﻳﺔ ﻫﺬﺍ ﺍﻟﻨﻮﻉ ﻣﻦ ﺍﻟﻮﻇﺎﺉﻒ ﺍﻟﺤﺴﺎﺳﺔ‬
‫ﻣﻦﺍﻟﻮﺻﻮﻝ ﻏﻴﺮ ﺍﻟﻤﺼﺮﺡ ﺑﻪ ﻭﻟﻜﻦ ﻋﻨﺎﺻﺮ ﺍﻟﺘﺤﻜﻢ ﻓﻲ ﺍﻟﻮﺻﻮﻝ ﺍﻟﻤﺴﺘﺨﺪﻣﺔ ﺗﻜﻮﻥ ﻣﻌﻄﻠﺔ ﺑﺴﺒﺐ‬
‫ﺍﻓﺘﺮﺍﺿﺎﺕﺧﺎﻃﺉﺔ ﺣﻮﻝ ﻛﻴﻔﻴﺔ ﺍﺳﺘﺨﺪﺍﻡ ﺍﻟﻮﻇﻴﻔﺔ‪.‬‬
‫‪263‬‬ ‫ﺍﻟﻔﺼﻞﺍﻟﺜﺎﻣﻦ‪-‬ﻣﻬﺎﺟﻤﺔ ﻋﻨﺎﺻﺮ ﺍﻟﺘﺤﻜﻢ ﻓﻲ ﺍﻟﻮﺻﻮﻝ‬

‫ﻓﻲﺍﻟﻤﺜﺎﻝ ﺍﻟﺴﺎﺑﻖ‪ ،‬ﻋﻨﺪﻣﺎ ﻳﺤﺎﻭﻝ ﻣﺴﺘﺨﺪﻡ ﺗﺤﻤﻴﻞ ﻗﺎﺉﻤﺔ ﺻﻴﺎﻧﺔ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻭﻳﺨﺘﺎﺭ ﺇﺿﺎﻓﺔ‬
‫ﻣﺴﺘﺨﺪﻡﺟﺪﻳﺪ‪ ،‬ﻗﺪ ﻳﺘﺤﻘﻖ ﺍﻟﺘﻄﺒﻴﻖ ﻣﻦ ﺍﻣﺘﻼﻛﻪ ﻟﻠﺼﻼﺣﻴﺎﺕ ﺍﻟﻤﻄﻠﻮﺑﺔ ﻭﻳﻤﻨﻊ ﺍﻟﻮﺻﻮﻝ ﺇﺫﺍ ﻟﻢ ﻳﻜﻦ‬
‫ﻛﺬﻟﻚ‪.‬ﻭﻣﻊ ﺫﻟﻚ‪ ،‬ﺇﺫﺍ ﺍﻧﺘﻘﻞ ﺍﻟﻤﻬﺎﺟﻢ ﻣﺒﺎﺷﺮﺓ ًﺇﻟﻰ ﻣﺮﺣﻠﺔ ﺗﺤﺪﻳﺪ ﻗﺴﻢ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻭﺗﻔﺎﺻﻴﻞ ﺃﺧﺮﻯ‪،‬‬
‫ﻓﻘﺪﻻ ﻳﻜﻮﻥ ﻫﻨﺎﻙ ﺗﺤﻜﻢ ﻓﻌﺎﻝ ﻓﻲ ﺍﻟﻮﺻﻮﻝ‪ .‬ﺍﻓﺘﺮﺽ ﺍﻟﻤﻄﻮﺭﻭﻥ‪ ،‬ﺩﻭﻥ ﻭﻋﻲ‪ ،‬ﺃﻥ ﺃﻱ ﻣﺴﺘﺨﺪﻡ ﻳﺼﻞ‬
‫ﺇﻟﻰﺍﻟﻤﺮﺍﺣﻞ ﺍﻟﻼﺣﻘﺔ ﻣﻦ ﺍﻟﻌﻤﻠﻴﺔ ﻳﺠﺐ ﺃﻥ ﻳﻤﺘﻠﻚ ﺍﻟﺼﻼﺣﻴﺎﺕ ﺍﻟﻼﺯﻣﺔ‪ ،‬ﻷﻧﻪ ﺗﻢ ﺍﻟﺘﺤﻘﻖ ﻣﻦ ﺫﻟﻚ‬
‫ﻓﻲﺍﻟﻤﺮﺍﺣﻞ ﺍﻟﺴﺎﺑﻘﺔ‪ .‬ﻭﺍﻟﻨﺘﻴﺠﺔ ﻫﻲ ﺃﻥ ﺃﻱ ﻣﺴﺘﺨﺪﻡ ﻟﻠﺘﻄﺒﻴﻖ ﻳﻤﻜﻨﻪ ﺇﺿﺎﻓﺔ ﺣﺴﺎﺏ ﻣﺴﺘﺨﺪﻡ‬
‫ﺇﺩﺍﺭﻱﺟﺪﻳﺪ‪ ،‬ﻭﺑﺎﻟﺘﺎﻟﻲ ﺍﻟﺘﺤﻜﻢ ﺍﻟﻜﺎﻣﻞ ﻓﻲ ﺍﻟﺘﻄﺒﻴﻖ‪ ،‬ﻭﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﺍﻟﻌﺪﻳﺪ ﻣﻦ ﺍﻟﻮﻇﺎﺉﻒ ﺍﻷﺧﺮﻯ‬
‫ﺍﻟﺘﻲﻳﺘﻤﻴﺰ ﺍﻟﺘﺤﻜﻢ ﻓﻲ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻴﻬﺎ ﺑﻔﺎﻋﻠﻴﺔ‪.‬‬

‫ﻭﺍﺟﻪﺍﻟﻤﺆﻟﻔﻮﻥ ﻫﺬﺍ ﺍﻟﻨﻮﻉ ﻣﻦ ﺍﻟﺜﻐﺮﺍﺕ ﺍﻷﻣﻨﻴﺔ ﺣﺘﻰ ﻓﻲ ﺃﻛﺜﺮ ﺗﻄﺒﻴﻘﺎﺕ ﺍﻟﻮﻳﺐ ﺃﻫﻤﻴﺔ ﻣﻦ ﺍﻟﻨﺎﺣﻴﺔ‬
‫ﺍﻷﻣﻨﻴﺔ‪ -‬ﺗﻠﻚ ﺍﻟﺘﻲ ﺗﺴﺘﺨﺪﻣﻬﺎ ﺍﻟﺒﻨﻮﻙ ﻋﺒﺮ ﺍﻹﻧﺘﺮﻧﺖ‪ .‬ﻋﺎﺩﺓ ًﻣﺎ ﻳﺘﻀﻤﻦ ﺇﺟﺮﺍء ﺗﺤﻮﻳﻞ ﺍﻷﻣﻮﺍﻝ ﻓﻲ‬
‫ﺗﻄﺒﻴﻖﻣﺼﺮﻓﻲ ﻣﺮﺍﺣﻞ ﻣﺘﻌﺪﺩﺓ‪ ،‬ﻭﺫﻟﻚ ﺟﺰﺉﻴﺎً ﻟﻤﻨﻊ ﺍﻟﻤﺴﺘﺨﺪﻣﻴﻦ ﻣﻦ ﺍﺭﺗﻜﺎﺏ ﺃﺧﻄﺎء ﻏﻴﺮ‬
‫ﻣﻘﺼﻮﺩﺓﻋﻨﺪ ﻃﻠﺐ ﺍﻟﺘﺤﻮﻳﻞ‪ .‬ﺗﺘﻀﻤﻦ ﻫﺬﻩ ﺍﻟﻌﻤﻠﻴﺔ ﻣﺘﻌﺪﺩﺓ ﺍﻟﻤﺮﺍﺣﻞ ﺍﻟﺘﻘﺎﻁ ﻋﻨﺎﺻﺮ ﺑﻴﺎﻧﺎﺕ‬
‫ﻣﺨﺘﻠﻔﺔﻣﻦ ﺍﻟﻤﺴﺘﺨﺪﻡ ﻓﻲ ﻛﻞ ﻣﺮﺣﻠﺔ‪ .‬ﻳﺘﻢ ﻓﺤﺺ ﻫﺬﻩ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺑﺪﻗﺔ ﻋﻨﺪ ﺇﺭﺳﺎﻟﻬﺎ ﻷﻭﻝ ﻣﺮﺓ‪ ،‬ﺛﻢ‬
‫ﻳﺘﻢﺗﻤﺮﻳﺮﻫﺎ ﻋﺎﺩﺓ ًﺇﻟﻰ ﻛﻞ ﻣﺮﺣﻠﺔ ﻻﺣﻘﺔ‪ ،‬ﺑﺎﺳﺘﺨﺪﺍﻡ ﺣﻘﻮﻝ ﻣﺨﻔﻴﺔ ﻓﻲ ﻧﻤﻮﺫﺝ ‪ .HTML‬ﻭﻣﻊ ﺫﻟﻚ‪ ،‬ﺇﺫﺍ‬
‫ﻟﻢﻳﻘﻢ ﺍﻟﺘﻄﺒﻴﻖ ﺑﺈﻋﺎﺩﺓ ﺍﻟﺘﺤﻘﻖ ﻣﻦ ﺻﺤﺔ ﺟﻤﻴﻊ ﻫﺬﻩ ﺍﻟﺒﻴﺎﻧﺎﺕ ﻓﻲ ﺍﻟﻤﺮﺣﻠﺔ ﺍﻟﻨﻬﺎﺉﻴﺔ‪ ،‬ﻓﻘﺪ ﻳﺘﻤﻜﻦ‬
‫ﺍﻟﻤﻬﺎﺟﻢﻣﻦ ﺗﺠﺎﻭﺯ ﻋﻤﻠﻴﺎﺕ ﺍﻟﺘﺤﻘﻖ ﺍﻟﺘﻲ ﻳﺠﺮﻳﻬﺎ ﺍﻟﺨﺎﺩﻡ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﻗﺪ ﻳﺘﺤﻘﻖ ﺍﻟﺘﻄﺒﻴﻖ‬
‫ﻣﻦﺃﻥ ﺍﻟﺤﺴﺎﺏ ﺍﻟﻤﺼﺪﺭ ﺍﻟﻤﺤﺪﺩ ﻟﻠﺘﺤﻮﻳﻞ ﻳﻨﺘﻤﻲ ﺇﻟﻰ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺍﻟﺤﺎﻟﻲ ﺛﻢ ﻳﻄﻠﺐ ﺗﻔﺎﺻﻴﻞ ﺣﻮﻝ‬
‫ﺍﻟﺤﺴﺎﺏﺍﻟﻮﺟﻬﺔ ﻭﻣﺒﻠﻎ ﺍﻟﺘﺤﻮﻳﻞ‪ .‬ﺇﺫﺍ ﺍﻋﺘﺮﺽ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺍﻟﺘﺤﻮﻳﻞ ﺍﻟﻨﻬﺎﺉﻲﺑﺮﻳﺪﻋﻨﺪ ﻃﻠﺐ ﻫﺬﻩ‬
‫ﺍﻟﻌﻤﻠﻴﺔﻭﺗﻌﺪﻳﻞ ﺭﻗﻢ ﺣﺴﺎﺏ ﺍﻟﻤﺼﺪﺭ‪ ،‬ﻳﻤﻜﻨﻬﺎ ﺗﻨﻔﻴﺬ ﺗﺼﻌﻴﺪ ﺍﻻﻣﺘﻴﺎﺯ ﺍﻷﻓﻘﻲ ﻭﺗﺤﻮﻳﻞ ﺍﻷﻣﻮﺍﻝ ﻣﻦ‬
‫ﺣﺴﺎﺏﻳﻨﺘﻤﻲ ﺇﻟﻰ ﻣﺴﺘﺨﺪﻡ ﻣﺨﺘﻠﻒ‪.‬‬

‫ﺍﻟﻤﻠﻔﺎﺕﺍﻟﺜﺎﺑﺘﺔ‬
‫ﻓﻲﺃﻏﻠﺐ ﺍﻟﺤﺎﻻﺕ‪ ،‬ﻳﺤﺼﻞ ﺍﻟﻤﺴﺘﺨﺪﻣﻮﻥ ﻋﻠﻰ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﺍﻟﻮﻇﺎﺉﻒ ﻭﺍﻟﻤﻮﺍﺭﺩ ﺍﻟﻤﺤﻤﻴﺔ ﻋﺒﺮ‬
‫ﺇﺭﺳﺎﻝﻃﻠﺒﺎﺕ ﺇﻟﻰ ﺻﻔﺤﺎﺕ ﺩﻳﻨﺎﻣﻴﻜﻴﺔ ﺗﻨُﻔﺬَّ ﻋﻠﻰ ﺍﻟﺨﺎﺩﻡ‪ .‬ﻭﺗﻘﻊ ﻋﻠﻰ ﻋﺎﺗﻖ ﻛﻞ ﺻﻔﺤﺔ ﻣﻦ ﻫﺬﻩ‬
‫ﺍﻟﺼﻔﺤﺎﺕﻣﺴﺆﻭﻟﻴﺔ ﺇﺟﺮﺍء ﻓﺤﻮﺻﺎﺕ ﻣﻨﺎﺳﺒﺔ ﻟﻠﺘﺤﻜﻢ ﻓﻲ ﺍﻟﻮﺻﻮﻝ‪ ،‬ﻭﺍﻟﺘﺄﻛﺪ ﻣﻦ ﺍﻣﺘﻼﻙ ﺍﻟﻤﺴﺘﺨﺪﻡ‬
‫ﻟﻠﺼﻼﺣﻴﺎﺕﺍﻟﻼﺯﻣﺔ ﻟﺘﻨﻔﻴﺬ ﺍﻹﺟﺮﺍء ﺍﻟﺬﻱ ﻳﺤﺎﻭﻝ ﺗﻨﻔﻴﺬﻩ‪.‬‬
‫ﻣﻊﺫﻟﻚ‪ ،‬ﻓﻲ ﺑﻌﺾ ﺍﻟﺤﺎﻻﺕ‪ ،‬ﺗﻮُﺟﻪَّ ﻃﻠﺒﺎﺕ ﺍﻟﻤﻮﺍﺭﺩ ﺍﻟﻤﺤﻤﻴﺔ ﻣﺒﺎﺷﺮﺓ ًﺇﻟﻰ ﺍﻟﻤﻮﺍﺭﺩ ﺍﻟﺜﺎﺑﺘﺔ ﻧﻔﺴﻬﺎ‪،‬‬
‫ﺍﻟﻤﻮﺟﻮﺩﺓﺿﻤﻦ ﺟﺬﺭ ﺍﻟﻮﻳﺐ ﺍﻟﺨﺎﺹ ﺑﺎﻟﺨﺎﺩﻡ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﻗﺪ ﻳﺴﻤﺢ ﻧﺎﺷﺮ ﺇﻟﻜﺘﺮﻭﻧﻲ‬
‫ﻟﻠﻤﺴﺘﺨﺪﻣﻴﻦﺑﺘﺼﻔﺢ ﻛﺘﺎﻟﻮﺝ ﻛﺘﺒﻪ ﻭﺷﺮﺍء ﻛﺘﺐ ﺇﻟﻜﺘﺮﻭﻧﻴﺔ ﻟﻠﺘﻨﺰﻳﻞ‪ .‬ﺑﻌﺪ ﺍﻟﺪﻓﻊ‪ ،‬ﻳﻮُﺟﻪَّ ﺍﻟﻤﺴﺘﺨﺪﻡ ﺇﻟﻰ‬
‫ﺭﺍﺑﻂﺗﻨﺰﻳﻞ ﻛﻤﺎ ﻳﻠﻲ‪:‬‬

‫‪https://wahh-books.com/download/9780636628104.pdf‬‬

‫ﻷﻥﻫﺬﺍ ﻣﻮﺭﺩ ﺛﺎﺑﺖ ﺗﻤﺎﻣﺎً‪ ،‬ﻓﺈﺫﺍ ﺍﺳﺘﻀُﻴﻒ ﻋﻠﻰ ﺧﺎﺩﻡ ﻭﻳﺐ ﺗﻘﻠﻴﺪﻱ‪ ،‬ﻓﺴﻴﺘﻢ ﺇﺭﺟﺎﻉ ﻣﺤﺘﻮﻳﺎﺗﻪ‬
‫ﻣﺒﺎﺷﺮﺓ ًﻣﻦ ﺍﻟﺨﺎﺩﻡ‪ ،‬ﺩﻭﻥ ﺗﻨﻔﻴﺬ ﺃﻱ ﺷﻴﻔﺮﺓ ﻋﻠﻰ ﻣﺴﺘﻮﻯ ﺍﻟﺘﻄﺒﻴﻖ‪ .‬ﻭﺑﺎﻟﺘﺎﻟﻲ‪ ،‬ﻻ ﻳﻤﻜﻦ ﻟﻠﻤﻮﺭﺩ ﺗﻨﻔﻴﺬ‬
‫ﺃﻱﻣﻨﻄﻖ ﻟﻠﺘﺤﻘﻖ‪.‬‬
 ‫ﺍﻟﻔﺼﻞﺍﻟﺜﺎﻣﻦ‪-‬ﻣﻬﺎﺟﻤﺔ ﻋﻨﺎﺻﺮ ﺍﻟﺘﺤﻜﻢ ﻓﻲ ﺍﻟﻮﺻﻮﻝ‬ ‫‪264‬‬

‫ﺃﻥﺍﻟﻤﺴﺘﺨﺪﻡ ﺍﻟﻄﺎﻟﺐ ﻳﻤﺘﻠﻚ ﺍﻟﺼﻼﺣﻴﺎﺕ ﺍﻟﻤﻄﻠﻮﺑﺔ‪ .‬ﻋﻨﺪ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﺍﻟﻤﻮﺍﺭﺩ ﺍﻟﺜﺎﺑﺘﺔ ﺑﻬﺬﻩ‬
‫ﺍﻟﻄﺮﻳﻘﺔ‪،‬ﻣﻦ ﺍﻟﻤﺮﺟﺢ ﺟﺪﺍً ﻋﺪﻡ ﻭﺟﻮﺩ ﺿﻮﺍﺑﻂ ﻭﺻﻮﻝ ﻓﻌﺎّﻟﺔ ﺗﺤﻤﻴﻬﺎ‪ ،‬ﻭﺃﻥ ﺃﻱ ﺷﺨﺺ ﻳﻌﺮﻑ ﻧﻈﺎﻡ‬
‫ﺗﺴﻤﻴﺔﻋﻨﺎﻭﻳﻦ ‪ URL‬ﻳﻤﻜﻨﻪ ﺍﺳﺘﻐﻼﻝ ﻫﺬﺍ ﻟﻠﻮﺻﻮﻝ ﺇﻟﻰ ﺃﻱ ﻣﻮﺍﺭﺩ ﻳﺮﻳﺪﻫﺎ‪ .‬ﻓﻲ ﻫﺬﻩ ﺍﻟﺤﺎﻟﺔ‪ ،‬ﻳﺒﺪﻭ ﺍﺳﻢ‬
‫ﺍﻟﻤﺴﺘﻨﺪﻣﺸﺎﺑﻬﺎً ﺑﺸﻜﻞ ﻣﺜﻴﺮ ﻟﻠﺮﻳﺒﺔ ﻟﺮﻗﻢ ‪ ،ISBN‬ﻣﻤﺎ ﻳﻤُﻜﻦّ ﺍﻟﻤﻬﺎﺟﻢ ﻣﻦ ﺗﻨﺰﻳﻞ ﺟﻤﻴﻊ ﺍﻟﻜﺘﺐ‬
‫ﺍﻹﻟﻜﺘﺮﻭﻧﻴﺔﺍﻟﺼﺎﺩﺭﺓ ﻋﻦ ﺍﻟﻨﺎﺷﺮ ﺑﺴﺮﻋﺔ!‬

‫ﺑﻌﺾﺃﻧﻮﺍﻉ ﺍﻟﻮﻇﺎﺉﻒ ﻣﻌﺮﺿﺔ ﺑﺸﻜﻞ ﺧﺎﺹ ﻟﻬﺬﺍ ﺍﻟﻨﻮﻉ ﻣﻦ ﺍﻟﻤﺸﺎﻛﻞ‪ ،‬ﺑﻤﺎ ﻓﻲ ﺫﻟﻚ ﺍﻟﻤﻮﺍﻗﻊ‬
‫ﺍﻟﻤﺎﻟﻴﺔﺍﻟﺘﻲ ﺗﻮﻓﺮ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﻣﺴﺘﻨﺪﺍﺕ ﺛﺎﺑﺘﺔ ﺣﻮﻝ ﺍﻟﺸﺮﻛﺎﺕ ﻣﺜﻞ ﺍﻟﺘﻘﺎﺭﻳﺮ ﺍﻟﺴﻨﻮﻳﺔ‪ ،‬ﻭﺑﺎﺉﻌﻲ‬
‫ﺍﻟﺒﺮﺍﻣﺞﺍﻟﺬﻳﻦ ﻳﻮﻓﺮﻭﻥ ﻣﻠﻔﺎﺕ ﺛﻨﺎﺉﻴﺔ ﻗﺎﺑﻠﺔ ﻟﻠﺘﻨﺰﻳﻞ‪ ،‬ﻭﺍﻟﻮﻇﺎﺉﻒ ﺍﻹﺩﺍﺭﻳﺔ ﺍﻟﺘﻲ ﺗﻮﻓﺮ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ‬
‫ﻣﻠﻔﺎﺕﺍﻟﺴﺠﻞ ﺍﻟﺜﺎﺑﺘﺔ ﻭﻏﻴﺮﻫﺎ ﻣﻦ ﺍﻟﺒﻴﺎﻧﺎﺕ ﺍﻟﺤﺴﺎﺳﺔ ﺍﻟﺘﻲ ﺗﻢ ﺟﻤﻌﻬﺎ ﺩﺍﺧﻞ ﺍﻟﺘﻄﺒﻴﻖ‪.‬‬

‫ﺧﻄﺄﻓﻲ ﺗﻜﻮﻳﻦ ﺍﻟﻤﻨﺼﺔ‬

‫ﺗﺴﺘﺨﺪﻡﺑﻌﺾ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﻋﻨﺎﺻﺮ ﺗﺤﻜﻢ ﻋﻠﻰ ﻣﺴﺘﻮﻯ ﺧﺎﺩﻡ ﺍﻟﻮﻳﺐ ﺃﻭ ﻣﻨﺼﺔ ﺍﻟﺘﻄﺒﻴﻖ ﻟﻠﺘﺤﻜﻢ ﻓﻲ‬
‫ﺍﻟﻮﺻﻮﻝ‪.‬ﻋﺎﺩﺓ‪ ً،‬ﻳﻜﻮﻥ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﻣﺴﺎﺭﺍﺕ ﻋﻨﺎﻭﻳﻦ ‪ URL‬ﻣﺤﺪﺩﺓ ﻣﻘﻴﺪﺍً ﺑﻨﺎء ًﻋﻠﻰ ﺩﻭﺭ ﺍﻟﻤﺴﺘﺨﺪﻡ‬
‫ﺩﺍﺧﻞﺍﻟﺘﻄﺒﻴﻖ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ‪/‬ﻣﺴﺆﻝﻗﺪ ﻳﻤُﻨﻊ ﺍﻟﻮﺻﻮﻝ ﺇﻟﻰ ﺍﻟﻤﺴﺎﺭ‬
‫ﻟﻠﻤﺴﺘﺨﺪﻣﻴﻦﻏﻴﺮ ﺍﻟﻤﻨﺘﻤﻴﻦ ﻟﻤﺠﻤﻮﻋﺔ ﺍﻟﻤﺴﺆﻭﻟﻴﻦ‪ .‬ﻣﺒﺪﺉﻴﺎً‪ ،‬ﺗﻌُﺪ ﻫﺬﻩ ﻃﺮﻳﻘﺔ ﻗﺎﻧﻮﻧﻴﺔ ﺗﻤﺎﻣﺎً‬
‫ﻟﻠﺘﺤﻜﻢﻓﻲ ﺍﻟﻮﺻﻮﻝ‪ .‬ﻭﻣﻊ ﺫﻟﻚ‪ ،‬ﻗﺪ ﺗﺆﺩﻱ ﺍﻷﺧﻄﺎء ﻓﻲ ﺗﻜﻮﻳﻦ ﻋﻨﺎﺻﺮ ﺍﻟﺘﺤﻜﻢ ﻋﻠﻰ ﻣﺴﺘﻮﻯ ﺍﻟﻤﻨﺼﺔ‬
‫ﺇﻟﻰﺣﺪﻭﺙ ﻭﺻﻮﻝ ﻏﻴﺮ ﻣﺼﺮﺡ ﺑﻪ‪.‬‬

‫ﻳﺄﺧﺬﺗﻜﻮﻳﻦ ﻣﺴﺘﻮﻯ ﺍﻟﻨﻈﺎﻡ ﺍﻷﺳﺎﺳﻲ ﻋﺎﺩﺓ ًﺷﻜﻞ ﻗﻮﺍﻋﺪ ﺗﺸﺒﻪ ﻗﻮﺍﻋﺪ ﺳﻴﺎﺳﺔ ﺟﺪﺍﺭ ﺍﻟﺤﻤﺎﻳﺔ‪،‬‬
‫ﻭﺍﻟﺘﻲﺗﺴﻤﺢ ﺑﺎﻟﻮﺻﻮﻝ ﺃﻭ ﺗﺮﻓﻀﻪ ﺍﺳﺘﻨﺎﺩﺍً ﺇﻟﻰ ﻣﺎ ﻳﻠﻲ‪:‬‬
‫ﻃﺮﻳﻘﺔﻃﻠﺐ ‪HTTP‬‬ ‫‪-‬‬

‫ﻣﺴﺎﺭﻋﻨﻮﺍﻥ ‪URL‬‬ ‫‪-‬‬

‫ﺩﻭﺭﺍﻟﻤﺴﺘﺨﺪﻡ‬ ‫‪-‬‬

‫ﻛﻤﺎﻫﻮ ﻣﻮﺿﺢ ﻓﻲ ﺍﻟﻔﺼﻞ ‪ ،3‬ﺍﻟﻐﺮﺽ ﺍﻷﺻﻠﻲ ﻣﻦﻳﺤﺼﻞﺍﻟﻄﺮﻳﻘﺔ ﻫﻲ ﺍﺳﺘﺮﺟﺎﻉ ﺍﻟﻤﻌﻠﻮﻣﺎﺕ‪،‬‬

‫ﻭﺍﻟﻐﺮﺽﻣﻦ ﺫﻟﻚ ﻫﻮﺑﺮﻳﺪﺍﻟﻄﺮﻳﻘﺔ ﻫﻲ ﺗﻨﻔﻴﺬ ﺇﺟﺮﺍءﺍﺕ ﺗﺆﺩﻱ ﺇﻟﻰ ﺗﻐﻴﻴﺮ ﺑﻴﺎﻧﺎﺕ ﺍﻟﺘﻄﺒﻴﻖ ﺃﻭ ﺣﺎﻟﺘﻪ‪.‬‬

‫ﺇﺫﺍﻟﻢ ﻳﺮُﺍﻉ َﻭﺿﻊ ﻗﻮﺍﻋﺪ ﺗﺴﻤﺢ ﺑﺎﻟﻮﺻﻮﻝ ﺑﺪﻗﺔ ﺍﺳﺘﻨﺎﺩﺍً ﺇﻟﻰ ﺃﺳﺎﻟﻴﺐ ‪ HTTP‬ﻭﻣﺴﺎﺭﺍﺕ ‪URL‬‬
‫ﺍﻟﺼﺤﻴﺤﺔ‪،‬ﻓﻘﺪ ﻳﺆﺩﻱ ﺫﻟﻚ ﺇﻟﻰ ﻭﺻﻮﻝ ﻏﻴﺮ ﻣﺼﺮﺡ ﺑﻪ‪ .‬ﻋﻠﻰ ﺳﺒﻴﻞ ﺍﻟﻤﺜﺎﻝ‪ ،‬ﺇﺫﺍ ﺍﺳﺘﺨﺪﻣﺖ ﻭﻇﻴﻔﺔ‬
‫ﺇﺩﺍﺭﻳﺔﻹﻧﺸﺎء ﻣﺴﺘﺨﺪﻡ ﺟﺪﻳﺪﺑﺮﻳﺪ‬
‫ﺍﻟﻄﺮﻳﻘﺔ‪،‬ﻗﺪ ﻳﻜﻮﻥ ﻟﺪﻯ ﺍﻟﻤﻨﺼﺔ ﻗﺎﻋﺪﺓ ﺭﻓﺾ ﺗﻤﻨﻊﺑﺮﻳﺪﻭﺗﺴﻤﺢ ﺑﺠﻤﻴﻊ ﺍﻟﻄﺮﻕ ﺍﻷﺧﺮﻯ‪ .‬ﻭﻣﻊ ﺫﻟﻚ‪ ،‬ﺇﺫﺍ‬
‫ﻟﻢﻳﺘﺤﻘﻖ ﻛﻮﺩ ﻣﺴﺘﻮﻯ ﺍﻟﺘﻄﺒﻴﻖ ﻣﻦ ﺃﻥ ﺟﻤﻴﻊ ﻃﻠﺒﺎﺕ ﻫﺬﻩ ﺍﻟﻮﻇﻴﻔﺔ ﺗﺴﺘﺨﺪﻡ ﺑﺎﻟﻔﻌﻞﺑﺮﻳﺪﻣﻦ ﺧﻼﻝ‬
‫ﻫﺬﻩﺍﻟﻄﺮﻳﻘﺔ‪ ،‬ﻗﺪ ﻳﺘﻤﻜﻦ ﺍﻟﻤﻬﺎﺟﻢ ﻣﻦ ﺍﻟﺘﺤﺎﻳﻞ ﻋﻠﻰ ﺍﻟﺘﺤﻜﻢ ﻋﻦ ﻃﺮﻳﻖ ﺇﺭﺳﺎﻝ ﻧﻔﺲ ﺍﻟﻄﻠﺐ‬
‫ﺑﺎﺳﺘﺨﺪﺍﻡﻳﺤﺼﻞﺍﻟﻄﺮﻳﻘﺔ‪ .‬ﻧﻈﺮﺍً ﻷﻥ ﻣﻌﻈﻢ ﻭﺍﺟﻬﺎﺕ ﺑﺮﻣﺠﺔ ﺍﻟﺘﻄﺒﻴﻘﺎﺕ ﻋﻠﻰ ﻣﺴﺘﻮﻯ ﺍﻟﺘﻄﺒﻴﻖ‬
‫ﻻﺳﺘﺮﺟﺎﻉﻣﻌﻠﻤﺎﺕ ﺍﻟﻄﻠﺐ ﻻ ﺗﻌﺘﻤﺪ ﻋﻠﻰ ﻃﺮﻳﻘﺔ ﺍﻟﻄﻠﺐ‪ ،‬ﻳﻤﻜﻦ ﻟﻠﻤﻬﺎﺟﻢ ﺑﺒﺴﺎﻃﺔ ﺗﻮﻓﻴﺮ ﺍﻟﻤﻌﻠﻤﺎﺕ‬
‫ﺍﻟﻤﻄﻠﻮﺑﺔﺩﺍﺧﻞ ﺳﻠﺴﻠﺔ ﺍﺳﺘﻌﻼﻡ ﻋﻨﻮﺍﻥ ‪ URL‬ﻟـﻳﺤﺼﻞﻃﻠﺐ ﺍﻻﺳﺘﺨﺪﺍﻡ ﻏﻴﺮ ﺍﻟﻤﺼﺮﺡ ﺑﻪ ﻟﻠﻮﻇﻴﻔﺔ‪.‬‬