مفاهيم وأساسيات إختبار إختراق تطبيقات الويب
عادةً تكون أصعب الخطوات هي البداية، ومن هذا المنطلق، في هذا المقال
سنستعرض أكثر الأساسيات أهمية للبدأ في مجال اختبار اختراق الويب أو ما
يسمى بالإنجليزية (Web Hacking).
في هذا المقال، سنناقش أساسيات من المحتم أن تعرفها للبدأ في مجال اختبار اختراق الويب! لن نتحدث عن أي أدوات في هذا المقال!! إذن، عن ماذا سنتحدث!؟
في هذا المقال سنتحدث عن الآتي:
* ما تحتاج أن تعرفه عن بروتوكول HTTP.
* أهم المنهجيات المتبعة.
* أكثر ثغرات الويب انتشارًا.
في الماضي، كان التركيز الأكبر على مهاجمة الـWeb Servers فهي كانت أمرًا منتشرًا، ولكن بظهور الكثير من طرق الحماية مثل الـFirewalls والـIDS أصبح من الصعب تنفيذ أيًا من الهجمات على الـWeb Servers وبالتالي تغير التوجه إلى مهاجمة تطبيقات الويب وهو ما يطلق عليه Web Application Hacking.
إذن، ما هو ما يسمى بتطبيق الويب (Web Application)!؟
في الحقيقة من الصعب الوصول لتعريف ثابت عن تطبيقات الويب، وذلك لعدة أسباب أهمها أنها أصبحت موجودة في معظم المواقع المنتشرة على الشبكة العنكبوتية، فلا ترى موقع إلا وتجده يستخدمها، لذلك هناك الكثيرين الذين يعتبرون أن تطبيق الويب هو الموقع نفسه، وعندما تخبرهم ما هو تعريفكم لتطبيق الويب يخبرونكم بسرعة هو الموقع الإلكتروني، فهل هذا هو المعنى الصحيح!؟
في الحقيقة انتشار تطبيقات الويب جعل بالفعل من الصعب تعريف تطبيقات الويب بشكل واضح، ولكن التعريف الأكثر انتشارًا هي أن تطبيقات الويب هي آليات التعامل مع الويب سيرفر، بمعنى أن تطبيقات الويب هي عبارة عن وسيط بين المستخدم والويب سيرفر ليستطيع التعامل مع الآليات التي يوفرها الويب سيرفر.
إذن، ما هي الثغرات التي تجدها في تطبيقات الويب!؟
عادةً ما تكون ثغرات تطبيقات الويب هي عبارة عن أخطاء يقع فيها المبرمجون أثناء برمجة تطبيقات الويب!
هل من السهل إصلاح هذه الأخطاء!؟
في الحقيقة، الكثيرين من اللذين ليست لديهم دراية كافية بهذه الأمور يعتقدون أن من السهل إصلاح هذه الأخطاء، ولكن هذا الأمر معاكس تمامًا لاعتقادهم، فإصلاحها صعب جدًا وذلك لأنها في بعض الأحيان تكون جزء أساسي من طريقة عمل التطبيق نفسه وستجد أن هناك أجزاء كثيرة في الموقع تعتمد عليها بشكل مباشر أو غير مباشر. ولذلك يكون من الصعب إصلاح هذه الأخطاء!
ما هي الـWeb Servers!؟
كمثال عليها في الويندوز، مثل IIS وهي اختصار لـInternet Information Services وستجدها على سيرفرات الويندوز، أما بالنسبة للينكس، مثل Apache Hypertext Transfer Protocol وستجدها على السيرفرات التي تستخدم اللينكس.
بالطبع طريقة إدارتها مختلفة، ولكن إن كنت تستخدم أنظمة ويندوز العادية أو أنظمة اللينكس العادية فسيظل المهم هو المهم، عادة ما ستجد أن تطبيقات الويب في أنظمة اللينكس تعمل في هذا المسار /var/www/ ولكن هناك بعض المسارات الأخرى التي تعتبر مهمة لأي تطبيق ويب أو كنظام لينكس بشكل عام، مثل:
1. /etc/shadow : وهي التي تجد بها الهاشات الخاصة بكلمات مرور المستخدمين.
2. /usr/lib : ستجد في هذا المجلد كل البيانات التي تعتمد عليها تطبيقات الويب في العمل، وذلك على الرغم من أنه لا يوجد بهذا المسار أي ملفات من المفترض أن تعمل بتدخل المستخدم نفسه.
3. /var/* : وهو المسار الذي ستجد به الملفات الخاصة بقواعد البيانات، وسجلات النظام، وبالطبع الـSource Code الخاص بتطبيق الويب نفسه.
4. /bin : هذا المسار يحتوي على برامج يحتاجها النظام للعمل، فكلمة bin هي اختصار لـBinary، وستجد بها بعد البرامج الضرورية مثل ls وgrep.
ملحوظة: لمهاجمة الـWeb Servers ستتعامل معه كأنك تقوم بتنفيذ Network Hacking. فكما قلنا ما هي إلا أنظمة مثل الأنظمة التي تجدها في العديد من الشبكات .
كيف يعمل الاتصال بيني وبين الويب سيرفر!؟
هذا سؤال مهم، دعنا نجيب عليه، كلنا سمعنا عن ما يسمى بالـHTTP، بل أننا نراه دائمًا في بداية أي رابط نحاول الدخول إليه من خلال المتصفح، فعندما نحاول الدخول لمدونة iSecur1ty، نجد أننا ندخله في المتصفح بهذه الطريقة “isecur1ty.org” ولكن إن نظرنا إلى المتصفح، سنجد أن الرابط أضيف عليه أجزاء أخرى ليصبح “http://isecur1ty.org” أو في أحيانًا أخرى “http://www.isecur1ty.org”، أما إذا حاولنا الدخول إلى موقع مثل الـFacebook مثلاً، سنجد أننا حتى لو أدخلنا الرابط بهذا الشكل “facebook.com” سنجد أنه تحول في المتصفح إلى “https://facebook.com”، مهلاً!!!! لما هي https وليس http كما نرى في مدونة iSecur1ty!!!! سأجيب على هذه الجزئية في الجزء القادم، ولكن الآن دعنا نتحدث أكثر عن بروتوكول HTTP، هذه الكلمة اختصار إلى جملة “Hypertext Transfer Protocol”، هذا البروتوكول يستخدم كالبروتوكول الأساسي في تواصل البيانات على الشبكة العنكبوتية منذ عام 1990.
هذا البروتوكول من نوع “Stateless” وهذا يعني أن كل “Request” يرسله المتصفح إلى الموقع أو التطبيق، وكل “Response” يكون بدون مستقل عن أي طلبات أو ردود أخرى.
في الحقيقة، إصدار HTTP رقم 1.0 يستخدم اتصال جديد مع كل “طلب” وكل “رد” أي أنه يصنع اتصال جديد فيرسل الطلب من المتصفح، وعندما يستجيب الموقع أو السيرفر ويرسل “رد” ففي هذه الحالة الاتصال ينتهي، ولكن في الإصدار رقم 1.1 أصبح بإمكانه استخدام اتصال واحد ليقوم بإرسال واستقبال أكثر من طلب وأكثر من رد.
حسنٌ، أنتَ أخبرتنا أن هذا البروتوكول من نوع “Stateless” أي أنه لا يكون لديه معرفة بأي Request أو Response سابق، في هذه الحالة، عند دخولي مثلاً لموقع لشراء المنتجات بشكل أونلاين، فسأحتاج إلى أن أقوم بتسجيل دخولي بعد كل عملية، أي أنني عند إضافتي لمنتج في عربة الشراء الخاصة بي سأحتاج إلى تسجيل دخولي، وأثناء إكمالي لعملية الشراء سأحتاج لإعادة تسجيل دخولي وهكذا.. وكل ذلك لأن البروتوكول من نوع “Stateless”!! الحل لهذه الجزئية أن البروتوكول يستخدم ما يسمى بالـ”Cookies”، ماذا تعني بهذا المصطلح!؟ فإن حاولت ترجمته بشكل حرفي سيكون المعنى مضحكًا وليس له علاقة بالموضوع الذي نتحدث عنه. في الحقيقة هذا المصطلح هو الذي يجعلنا نستطيع المتابعة بدون تسجيل دخولنا في كل مرة، وذلك باستخدام ما يسمى بالـSessions، فهو يتتبع كل الطلبات “Requests” التي تقوم بإرسالها للتطبيق أو للموقع وذلك من أجل المحافظة على اتصالك بدون أن تضطر إلى تسجيل دخولك أثناء كل عملية تقوم بها. ولكن على الرغم من أن أهمية هذه الجزئية إلا أنها توفر طريق كثيرة للهجوم على التطبيق.
إذن، وعدتني أن تخبرني بماهية الـ”s” التي أضيفت إلى “http” أثناء دخولنا لموقع الـFacebook، حسنٌ، للأسف بروتوكول الـhttp يستخدم النصوص العادية، أو ما يسمى بـ”Plaintext”، وهذا يعني أنه لا وجود للحماية على الإطلاق، فكان ظهور ما يسمى بـSSL/TLS وهي اختصار لـSecure Socket Layer/Transport Layer Security وهي ما يشار إليها بـ”s” أثناء دخولك لأي موقع فهي تضاف بعد كلمة “http”. إذن، ما هي فائدتها!؟ فائدتها أنها تقوم بتشفير الاتصال بحيث أنه يصبح من الصعب تنفيذ هجمات على الاتصال مثل هجمات Man-in-the-Middle أو Eavesdropping أو ما يسمى بهجمات التنصت، ولكن صحيح أنها تقوم بتشفير الاتصال إلا أنها لا تفيد كثيرًا في معظم الهجمات التي تستهدف تطبيقات الويب حاليًا.
فهمت الآن طبيعة عمل هذه البروتوكول، ولكنك قلت أنني المتصفح الخاص بي يرسل ما يسمى بالـRequest وأن السيرفر أو الموقع يرد عليّ بإرسال ما يسمى بـResponse، فما هي طبيعة هذه الطلبات والردود أو الاستجابات!؟
كل طلب أو استجابة يحتوي على ما يسمى بالـMessage وهي ما تحتوي على ما يسمى بالـHeaders:
مثال على الطلب الذي يرسله المتصفح الخاص بك أثناء طلب صفحة ما:
أهم الـHeaders التي تجدها في رسالة الـRequest هي:
Referrer: هذا الـHeaders يقوم بتوضح الصفحة التي كان بها المستخدم قبل طلبه لهذا الطلب، بمعنى أنها توضح من أين قمت بتنفيذ هذا الطلب. أهميتها بالنسبة لنا في سهولة تغييرها، فإن كان التطبيق يعتمد عليها في أي نوع من أنواع الحماية فمن السهل تغييرها بقيمة مزيفة.
Cookie: يقوم بإعادة إرسال الـCookie إلى السيرفر من أجل إبقاء الـSession مفتوحة لكي لا تقوم بإعادة التسجيل في كل مرة تقوم بتنفيذ عملية ما، وبالطبع هذه القيمة يجب أن تساوي قيمة الـCookie التي يستقبلها المتصفح من السيرفر. أهمية هذا الـHeader تكون أنه من الممكن أن يوفر Valid Session ويمكن من خلالها اختراق المستخدمين الأخرين اللذين يقومون باستخدام التطبيق.
ملحوظة: الـCookie هي ما يطلق عليها Session Identifier.
أما عن مثال عن الاستجابة أو الرد الذي يتلقاه المتصفح من السيرفر:
أهم الـHeaders التي تجدها في رسالة الـResponse هي:
Set-Cookie: تقوم بتزويد المتصفح بالـCookie لتظل الـSession الخاصة بالمستخدم مفتوحة. تكون خطورة هذا الـHeader في إن قام الهاكر بسرقته يمكنه انتحال هوية صاحب الـCookie للاتصال بالموقع.
Content-Length: هنا يتم توضيح طول الـResponse Body في هيئة Bytes. يكون هذا الـHeader مفيد للهاكر إن قام بتنفيذ عملية Brute Force فيمكنه مراقبة تغير هذه القيمة.
Location: هذا الـHeader يستخدم عندما يقوم التطبيق بتحويل المستخدم إلى صفحة جديدة. أهميته تكون في أنه يساعد في التعرف على الصفحات التي لا يمكن الانتقال إليها إلى بعد عملية التحقق من الهوية “Authenticating”.
بما إننا تحدثنا عن محتويات الـHeaders دعنا الآن نناقش ما هي حالة الرد، فكل استجابة أو رد يصل إلى المتصفح يصاحبه كود يوضح حالته، مثال:
هناك 50 رقم يوضح حالة الـResponse وهي مقسمة إلى خمسة مجموعات وفهم حالة الاستجابة التي تصلك يسهل عليك فهم ما حدث للطلب الخاص بك، المجموعات كالتالي:
100s: نادرًا ما تراها، وهي معلوماتية بشكل بحت، عادةً ما تشير إلى أن هناك المزيد من الردود القادمة من السيرفر.
200s: هي تشير إلى أن الطلب المرسل من المتصفح تم قبوله بنجاح وأنه تم إعادة إرسال الرد إلى المتصفح، ويعتبر كود الحالة 200 OK من أكثر الأكواد شيوعًا.
300s: هذه الردود عادةً ما تشير إلى إعادة التوجيه، أكثرها شيوعًا هي 302 Redirect وهي التي عادةً تصلك بعد عملية تحقق من الهوية تمت بنجاح ويتم الآن إرسالك إلى الصفحة ما بعد التحقق وعادة يتم إرسال رد أخر بعد هذا ويكون كود الحالة الخاص به 200 OK بما يوضح أن عملية التحقق من الهوية تمت بنجاح.
400s: تظهر في حالات ظهور أخطاء من خلالك، فهي تشير إلى أنك ارتكبت خطأ أثناء إرسالك للطلب، وأكثر الأكواد شيوعًا في هذا الشأن هي: 401 Unauthorized وهي التي تشير إلى أنك لا تملك الصلاحيات لطلب هذه الصفحة ولكنها عادةً ما تظهر بعد عملية تحقق من الهوية غير ناجحة أو أنك لم تقم باستخدام ما يؤكد هويتك بعد، 403 Forbidden، وهي مشابهة إلى 401 إلا أن السيرفر في هذه الحالة يرفض طلبك لأنك لا تملك الصلاحيات للدخول فعلاً إلى هذه الصفحة، 404 Not Found، لم يتم إجاد الصفحة التي قمت بطلبها مع إمكانية توفرها في المستقبل.
500s: توضح أن هناك خطأ في السيرفر نفسه، وليس خطأ في الطلب، ففي هذه الحالة يكون الخطأ في الرد الخاص بالسيرفر، وأكثرها شيوعًا هي: 500 Internal Server Error، بالإضافة إلى 503 Service Unavailable.
أعتقد أننا تحدثنا عن الأساسيات بما يكفي في هذا المقال، بالطبع هناك الكثير مما يجب أن تعرفه كأساسيات قبل دخولك لهذا المسار ولكن فـ لنوفر ذلك لمقالات مستقبلية، دعنا الآن نتحدث عن المنهجية التي يجب أن تتبعها في عملية اختبار اختراق تطبيقات الويب.
يمكنك تقسيم المنهجية التي يجب أن تتبعها إلى أربعة أقسام وهي كالتالي:
1. Reconnaissance: وهي المرحلة التي تقوم بجمع أكبر قدر من المعلومات عن الهدف الخاص بك وهي عادةً تكون المرحلة الأقل تقنية.
2. Scanning: وهي المرحلة التي تقوم فيها بعمل عملية فحص للهدف من أجل العثور على البورتات المفتوحة والخدمات وإصدارات الخدمات التي تعمل هذه البورتات أيضًا.
3. Exploitation: هي المرحلة التي تستغل فيها كل ما جمعته من معلومات في عملية الاستغلال.
4. Fix: هي المرحلة التي تقوم فيها بالوصول إلى حل لإصلاح الأخطاء التي أدت إلى عملية الاستغلال.
بالطبع مع العلم إن هذه المنهجية تختلف من شخص إلى أخر ويمكن تقسيمها إلى أكثر من أربع مراحل، ولكنها عادةً ما تنقسم إلى ما بين أربعة مراحل إلى سبعة مراحل.
عملية اختبار اختراق الويب يمكن تصنيف أجزائها إلى ثلاثة أجزاء:
Web Server: وهي التي تستهدف فيها الويب سيرفر، وتقوم في هذا الجزء بتنفيذ هجمات خاصة بالشبكات وذكرت السبب في بداية المقال.
Web Application: وهي العملية التي ستقوم فيها باستكشاف التطبيق من أجل الوصول إلى هجمات وتتم فيها مهاجمة التطبيق نفسه من أجل استكشاف ثغرات موجودة به.
Web User: تقوم فيها باستهداف مستخدم الويب نفسه، مستخدم التطبيق، وأما أن يكون مستخدم داخلي كمدير نظام للتطبيق، أو مستخدم خارجي كمستخدم عادي يستخدم التطبيق. وفي هذا الجزء يكثر استغلال ثغرات كـXSS وهي اختصار لـCross-Site Scripting وثغرات كـCSRF وهي اختصار لـCSRF.
حسنٌ، لنتحدث الآن عن الأدوات التي يمكن استخدامها في كل جزء من الأجزاء السابقة:
Web Server: كما قلت في هذه المرحلة أن تتعامل معها بهجمات الشبكات وبالتالي ستستخدم أدوات عادةً ما تستخدم مع الشبكات مثل: Nmap، Nessus، Nikto، Metasploit. بالطبع يمكن استخدام هذه الأدوات مع تطبيقات الويب أيضًا..
Web Application: ستستخدم في هذا الجزء الأدوات التي تقوم بعملية فحص للتطبيق نفسه وليس السيرفر، وأدوات تقوم بفهم آلية عمل التطبيق، مثل: Burp Suite وهو يعتبر أكثر الأدوات التي تتعامل مع تطبيقات الويب، ZAP وهو من الأدوات المفضلة بالنسبة لي وهو إحدى مشاريع مؤسسة OWASP وهو مشابه لأداة Burp Suite مع اختلاف أنها مجانية تمامًا ويتاح لك استخدام آلية الفحص بشكل مجاني.
Web User: في هذا الجزء ولأننا نستهدف المستخدم نفسه، فالتركيز يكون على أدوات مثل SET.
بالطبع هناك العديد من الأدوات التي تستخدمها ولها أهميتها الخاصة مثل: SQLMap وJohn The Ripper وبعد الأدوات الأخرى.
للتعرف على المنهجيات أكثر يمكنك الاطلاع على ما يسمى بالتالي:
1. PTES: وهي اختصار لـ Penetration Testing Execution Standard، وهي تعتبر أجدد المنهجيات وتعتبر أفضلها في رأيي الشخصي.
2. OSSTM: وهي اختصار لـOpen-Source Security Testing Methodology.
3. OWASP: وهي منقسمة إلى 12 قسم، وهي أكثر المنهجيات المتخصصة في تطبيقات الويب.
فهم هذه المنهجيات يساعدك على فهم ماهية اختبار تطبيقات الويب بشكل أكبر، وأنها ليست مجرد عملية تستخدم فيها الأدوات لتنفيذ الهجمات.
أما عن أكثر الهجمات شيوعًا وبدون الدخول في تفاصيل عنها لأنها ستأخد ساعات طويلة إن قمنا بالتحدث عنها فهي:
1. Injection.
2. Cross-Site Scripting (XSS).
3. Broken Authentication and Session Management.
4. Cross-Site Request Forgery (CSRF).
أتمنى أنني لم أنسَ شيئًا مما كنت أريد التحدث عنه :/
بالتوفيق وإن شاء الله نلتقي في مقالات أخرى.
حقوق النشر محفوظة لـ
( عمر احمد ) isecur1ty
في هذا المقال، سنناقش أساسيات من المحتم أن تعرفها للبدأ في مجال اختبار اختراق الويب! لن نتحدث عن أي أدوات في هذا المقال!! إذن، عن ماذا سنتحدث!؟
في هذا المقال سنتحدث عن الآتي:
* ما تحتاج أن تعرفه عن بروتوكول HTTP.
* أهم المنهجيات المتبعة.
* أكثر ثغرات الويب انتشارًا.
في الماضي، كان التركيز الأكبر على مهاجمة الـWeb Servers فهي كانت أمرًا منتشرًا، ولكن بظهور الكثير من طرق الحماية مثل الـFirewalls والـIDS أصبح من الصعب تنفيذ أيًا من الهجمات على الـWeb Servers وبالتالي تغير التوجه إلى مهاجمة تطبيقات الويب وهو ما يطلق عليه Web Application Hacking.
إذن، ما هو ما يسمى بتطبيق الويب (Web Application)!؟
في الحقيقة من الصعب الوصول لتعريف ثابت عن تطبيقات الويب، وذلك لعدة أسباب أهمها أنها أصبحت موجودة في معظم المواقع المنتشرة على الشبكة العنكبوتية، فلا ترى موقع إلا وتجده يستخدمها، لذلك هناك الكثيرين الذين يعتبرون أن تطبيق الويب هو الموقع نفسه، وعندما تخبرهم ما هو تعريفكم لتطبيق الويب يخبرونكم بسرعة هو الموقع الإلكتروني، فهل هذا هو المعنى الصحيح!؟
في الحقيقة انتشار تطبيقات الويب جعل بالفعل من الصعب تعريف تطبيقات الويب بشكل واضح، ولكن التعريف الأكثر انتشارًا هي أن تطبيقات الويب هي آليات التعامل مع الويب سيرفر، بمعنى أن تطبيقات الويب هي عبارة عن وسيط بين المستخدم والويب سيرفر ليستطيع التعامل مع الآليات التي يوفرها الويب سيرفر.
إذن، ما هي الثغرات التي تجدها في تطبيقات الويب!؟
عادةً ما تكون ثغرات تطبيقات الويب هي عبارة عن أخطاء يقع فيها المبرمجون أثناء برمجة تطبيقات الويب!
هل من السهل إصلاح هذه الأخطاء!؟
في الحقيقة، الكثيرين من اللذين ليست لديهم دراية كافية بهذه الأمور يعتقدون أن من السهل إصلاح هذه الأخطاء، ولكن هذا الأمر معاكس تمامًا لاعتقادهم، فإصلاحها صعب جدًا وذلك لأنها في بعض الأحيان تكون جزء أساسي من طريقة عمل التطبيق نفسه وستجد أن هناك أجزاء كثيرة في الموقع تعتمد عليها بشكل مباشر أو غير مباشر. ولذلك يكون من الصعب إصلاح هذه الأخطاء!
ما هي الـWeb Servers!؟
كمثال عليها في الويندوز، مثل IIS وهي اختصار لـInternet Information Services وستجدها على سيرفرات الويندوز، أما بالنسبة للينكس، مثل Apache Hypertext Transfer Protocol وستجدها على السيرفرات التي تستخدم اللينكس.
بالطبع طريقة إدارتها مختلفة، ولكن إن كنت تستخدم أنظمة ويندوز العادية أو أنظمة اللينكس العادية فسيظل المهم هو المهم، عادة ما ستجد أن تطبيقات الويب في أنظمة اللينكس تعمل في هذا المسار /var/www/ ولكن هناك بعض المسارات الأخرى التي تعتبر مهمة لأي تطبيق ويب أو كنظام لينكس بشكل عام، مثل:
1. /etc/shadow : وهي التي تجد بها الهاشات الخاصة بكلمات مرور المستخدمين.
2. /usr/lib : ستجد في هذا المجلد كل البيانات التي تعتمد عليها تطبيقات الويب في العمل، وذلك على الرغم من أنه لا يوجد بهذا المسار أي ملفات من المفترض أن تعمل بتدخل المستخدم نفسه.
3. /var/* : وهو المسار الذي ستجد به الملفات الخاصة بقواعد البيانات، وسجلات النظام، وبالطبع الـSource Code الخاص بتطبيق الويب نفسه.
4. /bin : هذا المسار يحتوي على برامج يحتاجها النظام للعمل، فكلمة bin هي اختصار لـBinary، وستجد بها بعد البرامج الضرورية مثل ls وgrep.
ملحوظة: لمهاجمة الـWeb Servers ستتعامل معه كأنك تقوم بتنفيذ Network Hacking. فكما قلنا ما هي إلا أنظمة مثل الأنظمة التي تجدها في العديد من الشبكات .
كيف يعمل الاتصال بيني وبين الويب سيرفر!؟
هذا سؤال مهم، دعنا نجيب عليه، كلنا سمعنا عن ما يسمى بالـHTTP، بل أننا نراه دائمًا في بداية أي رابط نحاول الدخول إليه من خلال المتصفح، فعندما نحاول الدخول لمدونة iSecur1ty، نجد أننا ندخله في المتصفح بهذه الطريقة “isecur1ty.org” ولكن إن نظرنا إلى المتصفح، سنجد أن الرابط أضيف عليه أجزاء أخرى ليصبح “http://isecur1ty.org” أو في أحيانًا أخرى “http://www.isecur1ty.org”، أما إذا حاولنا الدخول إلى موقع مثل الـFacebook مثلاً، سنجد أننا حتى لو أدخلنا الرابط بهذا الشكل “facebook.com” سنجد أنه تحول في المتصفح إلى “https://facebook.com”، مهلاً!!!! لما هي https وليس http كما نرى في مدونة iSecur1ty!!!! سأجيب على هذه الجزئية في الجزء القادم، ولكن الآن دعنا نتحدث أكثر عن بروتوكول HTTP، هذه الكلمة اختصار إلى جملة “Hypertext Transfer Protocol”، هذا البروتوكول يستخدم كالبروتوكول الأساسي في تواصل البيانات على الشبكة العنكبوتية منذ عام 1990.
هذا البروتوكول من نوع “Stateless” وهذا يعني أن كل “Request” يرسله المتصفح إلى الموقع أو التطبيق، وكل “Response” يكون بدون مستقل عن أي طلبات أو ردود أخرى.
في الحقيقة، إصدار HTTP رقم 1.0 يستخدم اتصال جديد مع كل “طلب” وكل “رد” أي أنه يصنع اتصال جديد فيرسل الطلب من المتصفح، وعندما يستجيب الموقع أو السيرفر ويرسل “رد” ففي هذه الحالة الاتصال ينتهي، ولكن في الإصدار رقم 1.1 أصبح بإمكانه استخدام اتصال واحد ليقوم بإرسال واستقبال أكثر من طلب وأكثر من رد.
حسنٌ، أنتَ أخبرتنا أن هذا البروتوكول من نوع “Stateless” أي أنه لا يكون لديه معرفة بأي Request أو Response سابق، في هذه الحالة، عند دخولي مثلاً لموقع لشراء المنتجات بشكل أونلاين، فسأحتاج إلى أن أقوم بتسجيل دخولي بعد كل عملية، أي أنني عند إضافتي لمنتج في عربة الشراء الخاصة بي سأحتاج إلى تسجيل دخولي، وأثناء إكمالي لعملية الشراء سأحتاج لإعادة تسجيل دخولي وهكذا.. وكل ذلك لأن البروتوكول من نوع “Stateless”!! الحل لهذه الجزئية أن البروتوكول يستخدم ما يسمى بالـ”Cookies”، ماذا تعني بهذا المصطلح!؟ فإن حاولت ترجمته بشكل حرفي سيكون المعنى مضحكًا وليس له علاقة بالموضوع الذي نتحدث عنه. في الحقيقة هذا المصطلح هو الذي يجعلنا نستطيع المتابعة بدون تسجيل دخولنا في كل مرة، وذلك باستخدام ما يسمى بالـSessions، فهو يتتبع كل الطلبات “Requests” التي تقوم بإرسالها للتطبيق أو للموقع وذلك من أجل المحافظة على اتصالك بدون أن تضطر إلى تسجيل دخولك أثناء كل عملية تقوم بها. ولكن على الرغم من أن أهمية هذه الجزئية إلا أنها توفر طريق كثيرة للهجوم على التطبيق.
إذن، وعدتني أن تخبرني بماهية الـ”s” التي أضيفت إلى “http” أثناء دخولنا لموقع الـFacebook، حسنٌ، للأسف بروتوكول الـhttp يستخدم النصوص العادية، أو ما يسمى بـ”Plaintext”، وهذا يعني أنه لا وجود للحماية على الإطلاق، فكان ظهور ما يسمى بـSSL/TLS وهي اختصار لـSecure Socket Layer/Transport Layer Security وهي ما يشار إليها بـ”s” أثناء دخولك لأي موقع فهي تضاف بعد كلمة “http”. إذن، ما هي فائدتها!؟ فائدتها أنها تقوم بتشفير الاتصال بحيث أنه يصبح من الصعب تنفيذ هجمات على الاتصال مثل هجمات Man-in-the-Middle أو Eavesdropping أو ما يسمى بهجمات التنصت، ولكن صحيح أنها تقوم بتشفير الاتصال إلا أنها لا تفيد كثيرًا في معظم الهجمات التي تستهدف تطبيقات الويب حاليًا.
فهمت الآن طبيعة عمل هذه البروتوكول، ولكنك قلت أنني المتصفح الخاص بي يرسل ما يسمى بالـRequest وأن السيرفر أو الموقع يرد عليّ بإرسال ما يسمى بـResponse، فما هي طبيعة هذه الطلبات والردود أو الاستجابات!؟
كل طلب أو استجابة يحتوي على ما يسمى بالـMessage وهي ما تحتوي على ما يسمى بالـHeaders:
مثال على الطلب الذي يرسله المتصفح الخاص بك أثناء طلب صفحة ما:
أهم الـHeaders التي تجدها في رسالة الـRequest هي:
Referrer: هذا الـHeaders يقوم بتوضح الصفحة التي كان بها المستخدم قبل طلبه لهذا الطلب، بمعنى أنها توضح من أين قمت بتنفيذ هذا الطلب. أهميتها بالنسبة لنا في سهولة تغييرها، فإن كان التطبيق يعتمد عليها في أي نوع من أنواع الحماية فمن السهل تغييرها بقيمة مزيفة.
Cookie: يقوم بإعادة إرسال الـCookie إلى السيرفر من أجل إبقاء الـSession مفتوحة لكي لا تقوم بإعادة التسجيل في كل مرة تقوم بتنفيذ عملية ما، وبالطبع هذه القيمة يجب أن تساوي قيمة الـCookie التي يستقبلها المتصفح من السيرفر. أهمية هذا الـHeader تكون أنه من الممكن أن يوفر Valid Session ويمكن من خلالها اختراق المستخدمين الأخرين اللذين يقومون باستخدام التطبيق.
ملحوظة: الـCookie هي ما يطلق عليها Session Identifier.
أما عن مثال عن الاستجابة أو الرد الذي يتلقاه المتصفح من السيرفر:
أهم الـHeaders التي تجدها في رسالة الـResponse هي:
Set-Cookie: تقوم بتزويد المتصفح بالـCookie لتظل الـSession الخاصة بالمستخدم مفتوحة. تكون خطورة هذا الـHeader في إن قام الهاكر بسرقته يمكنه انتحال هوية صاحب الـCookie للاتصال بالموقع.
Content-Length: هنا يتم توضيح طول الـResponse Body في هيئة Bytes. يكون هذا الـHeader مفيد للهاكر إن قام بتنفيذ عملية Brute Force فيمكنه مراقبة تغير هذه القيمة.
Location: هذا الـHeader يستخدم عندما يقوم التطبيق بتحويل المستخدم إلى صفحة جديدة. أهميته تكون في أنه يساعد في التعرف على الصفحات التي لا يمكن الانتقال إليها إلى بعد عملية التحقق من الهوية “Authenticating”.
بما إننا تحدثنا عن محتويات الـHeaders دعنا الآن نناقش ما هي حالة الرد، فكل استجابة أو رد يصل إلى المتصفح يصاحبه كود يوضح حالته، مثال:
هناك 50 رقم يوضح حالة الـResponse وهي مقسمة إلى خمسة مجموعات وفهم حالة الاستجابة التي تصلك يسهل عليك فهم ما حدث للطلب الخاص بك، المجموعات كالتالي:
100s: نادرًا ما تراها، وهي معلوماتية بشكل بحت، عادةً ما تشير إلى أن هناك المزيد من الردود القادمة من السيرفر.
200s: هي تشير إلى أن الطلب المرسل من المتصفح تم قبوله بنجاح وأنه تم إعادة إرسال الرد إلى المتصفح، ويعتبر كود الحالة 200 OK من أكثر الأكواد شيوعًا.
300s: هذه الردود عادةً ما تشير إلى إعادة التوجيه، أكثرها شيوعًا هي 302 Redirect وهي التي عادةً تصلك بعد عملية تحقق من الهوية تمت بنجاح ويتم الآن إرسالك إلى الصفحة ما بعد التحقق وعادة يتم إرسال رد أخر بعد هذا ويكون كود الحالة الخاص به 200 OK بما يوضح أن عملية التحقق من الهوية تمت بنجاح.
400s: تظهر في حالات ظهور أخطاء من خلالك، فهي تشير إلى أنك ارتكبت خطأ أثناء إرسالك للطلب، وأكثر الأكواد شيوعًا في هذا الشأن هي: 401 Unauthorized وهي التي تشير إلى أنك لا تملك الصلاحيات لطلب هذه الصفحة ولكنها عادةً ما تظهر بعد عملية تحقق من الهوية غير ناجحة أو أنك لم تقم باستخدام ما يؤكد هويتك بعد، 403 Forbidden، وهي مشابهة إلى 401 إلا أن السيرفر في هذه الحالة يرفض طلبك لأنك لا تملك الصلاحيات للدخول فعلاً إلى هذه الصفحة، 404 Not Found، لم يتم إجاد الصفحة التي قمت بطلبها مع إمكانية توفرها في المستقبل.
500s: توضح أن هناك خطأ في السيرفر نفسه، وليس خطأ في الطلب، ففي هذه الحالة يكون الخطأ في الرد الخاص بالسيرفر، وأكثرها شيوعًا هي: 500 Internal Server Error، بالإضافة إلى 503 Service Unavailable.
أعتقد أننا تحدثنا عن الأساسيات بما يكفي في هذا المقال، بالطبع هناك الكثير مما يجب أن تعرفه كأساسيات قبل دخولك لهذا المسار ولكن فـ لنوفر ذلك لمقالات مستقبلية، دعنا الآن نتحدث عن المنهجية التي يجب أن تتبعها في عملية اختبار اختراق تطبيقات الويب.
يمكنك تقسيم المنهجية التي يجب أن تتبعها إلى أربعة أقسام وهي كالتالي:
1. Reconnaissance: وهي المرحلة التي تقوم بجمع أكبر قدر من المعلومات عن الهدف الخاص بك وهي عادةً تكون المرحلة الأقل تقنية.
2. Scanning: وهي المرحلة التي تقوم فيها بعمل عملية فحص للهدف من أجل العثور على البورتات المفتوحة والخدمات وإصدارات الخدمات التي تعمل هذه البورتات أيضًا.
3. Exploitation: هي المرحلة التي تستغل فيها كل ما جمعته من معلومات في عملية الاستغلال.
4. Fix: هي المرحلة التي تقوم فيها بالوصول إلى حل لإصلاح الأخطاء التي أدت إلى عملية الاستغلال.
بالطبع مع العلم إن هذه المنهجية تختلف من شخص إلى أخر ويمكن تقسيمها إلى أكثر من أربع مراحل، ولكنها عادةً ما تنقسم إلى ما بين أربعة مراحل إلى سبعة مراحل.
عملية اختبار اختراق الويب يمكن تصنيف أجزائها إلى ثلاثة أجزاء:
Web Server: وهي التي تستهدف فيها الويب سيرفر، وتقوم في هذا الجزء بتنفيذ هجمات خاصة بالشبكات وذكرت السبب في بداية المقال.
Web Application: وهي العملية التي ستقوم فيها باستكشاف التطبيق من أجل الوصول إلى هجمات وتتم فيها مهاجمة التطبيق نفسه من أجل استكشاف ثغرات موجودة به.
Web User: تقوم فيها باستهداف مستخدم الويب نفسه، مستخدم التطبيق، وأما أن يكون مستخدم داخلي كمدير نظام للتطبيق، أو مستخدم خارجي كمستخدم عادي يستخدم التطبيق. وفي هذا الجزء يكثر استغلال ثغرات كـXSS وهي اختصار لـCross-Site Scripting وثغرات كـCSRF وهي اختصار لـCSRF.
حسنٌ، لنتحدث الآن عن الأدوات التي يمكن استخدامها في كل جزء من الأجزاء السابقة:
Web Server: كما قلت في هذه المرحلة أن تتعامل معها بهجمات الشبكات وبالتالي ستستخدم أدوات عادةً ما تستخدم مع الشبكات مثل: Nmap، Nessus، Nikto، Metasploit. بالطبع يمكن استخدام هذه الأدوات مع تطبيقات الويب أيضًا..
Web Application: ستستخدم في هذا الجزء الأدوات التي تقوم بعملية فحص للتطبيق نفسه وليس السيرفر، وأدوات تقوم بفهم آلية عمل التطبيق، مثل: Burp Suite وهو يعتبر أكثر الأدوات التي تتعامل مع تطبيقات الويب، ZAP وهو من الأدوات المفضلة بالنسبة لي وهو إحدى مشاريع مؤسسة OWASP وهو مشابه لأداة Burp Suite مع اختلاف أنها مجانية تمامًا ويتاح لك استخدام آلية الفحص بشكل مجاني.
Web User: في هذا الجزء ولأننا نستهدف المستخدم نفسه، فالتركيز يكون على أدوات مثل SET.
بالطبع هناك العديد من الأدوات التي تستخدمها ولها أهميتها الخاصة مثل: SQLMap وJohn The Ripper وبعد الأدوات الأخرى.
للتعرف على المنهجيات أكثر يمكنك الاطلاع على ما يسمى بالتالي:
1. PTES: وهي اختصار لـ Penetration Testing Execution Standard، وهي تعتبر أجدد المنهجيات وتعتبر أفضلها في رأيي الشخصي.
2. OSSTM: وهي اختصار لـOpen-Source Security Testing Methodology.
3. OWASP: وهي منقسمة إلى 12 قسم، وهي أكثر المنهجيات المتخصصة في تطبيقات الويب.
فهم هذه المنهجيات يساعدك على فهم ماهية اختبار تطبيقات الويب بشكل أكبر، وأنها ليست مجرد عملية تستخدم فيها الأدوات لتنفيذ الهجمات.
أما عن أكثر الهجمات شيوعًا وبدون الدخول في تفاصيل عنها لأنها ستأخد ساعات طويلة إن قمنا بالتحدث عنها فهي:
1. Injection.
2. Cross-Site Scripting (XSS).
3. Broken Authentication and Session Management.
4. Cross-Site Request Forgery (CSRF).
أتمنى أنني لم أنسَ شيئًا مما كنت أريد التحدث عنه :/
بالتوفيق وإن شاء الله نلتقي في مقالات أخرى.
حقوق النشر محفوظة لـ
( عمر احمد ) isecur1ty