EraDev
Ghoster-Xفي ظل تطور التقنيات هل فعلاً أصبحت هجمات CSRF من الماضي؟
ما هي ثغرة الـ CSRF؟
كانت إحدى الثغرات في قائمة OWASP Top 10 للعام 2013 ولكن تمت إزالتها من القائمة في العام 2017، وهي نوع من الهجمات حيث تعتمد بالأساس على خداع الضحية لإرسال طلب ضار للخادم، للاستيلاء على هوية الضحية وتغيير بياناته مثل البريد الإلكتروني أو كلمة المرور.
تتضمن طلبات المتصفح تلقائياً أي بيانات تتعلق بهوية المستخدم المرتبطة بالموقع، مثل session cookie وIP Address وبعض البيانات الأخرى، فإذا كان المستخدم قام بتسجيل دخوله على تطبيق الويب، فإن الخادم قد لا يملك الوسيلة للتمييز ما إذا كان هذا الطلب قد تم بعلم المستخدم أم لا.
ما هو تأثير ثغرة الـ CSRF؟
تستهدف هجمات CSRF بشكل أساسي على تغيير البيانات التي تتعلق بهوية المستخدم، مثل تغيير عنوان البريد الإلكتروني أو كلمة المرور للضحية، حيث يعتمد الهجوم على سبيل المثال على أن يقوم المهاجم بإنشاء طلب للخادم بتغيير كلمة المرور، ويقوم المهاجم بإرسال ذلك الطلب للضحية وخداعه لتقوم فقط الضحية بإرسال هذا الطلب إلى الخادم مما يؤدي إلى تغيير كلمة المرور التي قام المهاجم باختيارها.
كيف تعمل ثغرة الـ CSRF؟
لنفترض أننا سنقوم بالتطبيق على سيناريو تغيير كلمة المرور لذا سيكون عندنا نموذج لتغيير كلمة المرور مشابها لهذا المثال:
<form action="https://example.com/change-password/" method="post">
<label for="new-password">New Password</label>
<input type="password" id="new-password" name="new-password" required>
<label for="confirm-new-password">Confirm New Password</label>
<input type="password" id="confirm-new-password" name="confirm-new-password" required>
<input type="submit" value="Save Password">
</form>
ليكون الطلب المرسل للخادم إذا تم إرسال هذا النموذج على سبيل المثال بهذا الشكل:
POST / change-password/ HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Cookie: session=UserSessionValue
new-password=Root-X&confirm-new-password=Root-X
حسناً، الآن فقط ينقصنا إنشاء هذا الطلب على هيئة ملف HTML ليحتوي على نفس النموذج ولكن مع إضافة قيمة (Value) لكلمة المرور وتأكيد كلمة المرور مع إضافة كود Js بسيط ليقوم بعمل Submit بمجرد فتح الضحية لملف الـ HTML.
<html>
<body>
<form action="https://example.com/change-password/" method="POST">
<input type="hidden" id="new-password" name="new-password" value="Root-X">
<input type="hidden" id="confirm-new-password" name="confirm-new-password" value="Root-X">
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>
الآن إذا قامت الضحية بفتح الملف سيحدث الآتي:
- سيتم إرسال طلب إلى تطبيق الويب example.com/change-password
- إذا كانت الضحية قد قامت بتسجيل الدخول من قبل على تطبيق الويب example.com سيقوم المتصفح تلقائياً بتضمين الـ Session Cookie الخاص بالضحية في الطلب الموجه للخادم (ذلك بشرط أن لا يتم استخدام ال Session Cookie بناء على SameSite)
- سيقوم الخادم بتنفيذ الطلب بشكل عادي كما وأنه قد تم توجيه بالفعل من طرف الضحية بالطريقة العادية وتغيير كلمة المرور إلى Root-X
طرق الحماية من ثغرة الـ CSRF
يوجد العديد من طرق الوقاية والحماية من الـ CSRF ولكن سنذكر أكثرها فاعلية:
CSRF Tokens
رمز CSRF هو قيمة فريدة وسرية وغير قابلة للتنبؤ يتم إنشاؤها من قبل تطبيق الخادم ومشاركتها مع العميل، عند محاولة أداء إجراء حساس مثل تقديم نموذج، يجب على العميل تضمين رمز CSRF الصحيح في الطلب، وهذا يجعل من الصعب جدًا على المهاجم إنشاء طلب صالح نيابة عن الضحية.
<form action="https://example.com/change-password/" method="post">
<input type="hidden" name="csrf_token" value="csrf_token_random_value">
<label for="new-password">New Password</label>
<input type="password" id="new-password" name="new-password" required>
<label for="confirm-new-password">Confirm New Password</label>
<input type="password" id="confirm-new-password" name="confirm-new-password" required>
<input type="submit" value="Save Password">
</form>
SameSite Cookies
هو آلية أمان في متصفح الويب تحدد متى يتم تضمين ال Session Cookie لتطبيق الويب، حيث يتطلب إرسال طلبات للخادم للقيام على سبيل المثال كما ذكرت تغيير كلمة المرور الـ Session Cookie، حيث قد تمنع القيود الصحيحة لـ SameSite المهاجم من تنشيط هذه الإجراءات عبر تطبيق الويب.
يتم تعيين SameSite إلى قيمة من ثلاث قيم ممكنة:
Strict
في هذه الحالة، لا يُرسل الـ Cookie مع أي طلب يأتي من موقع خارجي، حتى لو كانت الصفحة تحتوي على رابط إلى هذا الموقع الخارجي.
Set-Cookie: key= UserSessionValue; SameSite=Strict;
Lax
في هذه الحالة، يتم إرسال الـ Cookie مع الطلبات ال GET العادية التي تأتي من موقع خارجي (مثل الفتح من عنوان URL)، ولكن لا يتم إرسالها مع الطلبات ال POST من مصادر خارجية.
Set-Cookie: key= UserSessionValue; SameSite=Lax;
None
يتم إرسال الـ Cookie مع كافة الطلبات، بغض النظر عن الموقع الذي يأتي منه الطلب، ويتطلب استخدام هذه القيمة إضافة تأمين مثل الاتصال بـ HTTPS.
Set-Cookie: key= UserSessionValue; SameSite=None; Secure;
المتصفحات التي تقوم بدعم SameSite:
Google Chrome
بدأ الدعم من الإصدار 51 حتى الإصدار 60 بشكل جزئي، ومن الإصدار 61 بدأ الدعم بالكامل.
Mozilla Firefox
بدأ الدعم من الإصدار 60 بشكل كامل.
Opera
بدأ الدعم من الإصدار 39 بشكل كامل.
Safari
بدأ الدعم من الإصدار 12 بشكل كامل.
Microsoft Edge
بدأ الدعم من الإصدار 16 بشكل كامل.
Internet Explorer
بدأ الدعم من الإصدار 11 بشكل جزئي.
Referer & Origin
تقوم بعض التطبيقات بإرسال HTTP Referer عند إرسال طلب للخادم وذلك للدفاع ضد هجمات CSRF، وعادةً عن طريق التحقق من أن الطلب يأتي من نطاق تطبيق الويب نفسه، ولكم بشكل عام يكون هذا أقل فعالية من التحقق بواسطة CSRF Tokens وSameSite.
POST / change-password/ HTTP/1.1
Host: example.com
Origin: example.com
Referer: example.com/account/
Content-Type: application/x-www-form-urlencoded
Cookie: session=UserSessionValue
new-password =Root-X&confirm-new-password=Root-X
الخاتمة
يظهر أن ثغرة CSRF تمثل تهديدًا جادًا لأمان التطبيقات عبر الويب، حيث يمكن للمهاجمين استغلال ثقة المواقع في هوية المستخدمين لتنفيذ أوامر عن طريق خداع المستخدم، ولحماية التطبيقات من هذا النوع من الهجمات، يجب اتخاذ تدابير أمان فعّالة واستخدام الـ Anti-CSRF Headers.
بالإضافة إلى ذلك، ينبغي على المطورين أن يكونوا على دراية بأحدث التقنيات والممارسات لتعزيز أمان التطبيقات وحماية المستخدمين من الهجمات الإلكترونية، فالتوعية والاهتمام بقضايا الأمان يلعبان دورًا حاسمًا في بناء بيئة رقمية آمنة وموثوقة.
