shoucheng3/nahsra__antisamy_cve-2022-29577_1-6-6-1مكتبة جافا لتنظيف سريع وقابل للتكوين لـ HTML غير الموثوق لمنع هجمات البرمجة النصية عبر المواقع (XSS). تستخدم فحصًا قائمًا على السياسات لتعقيم ترميز المستخدم.
مكتبة لإجراء تنظيف سريع وقابل للتهيئة لـ HTML الوارد من مصادر غير موثوقة. تدعم Java 7+.
يمكن التعبير عن ذلك بطريقة أخرى: إنها API تساعدك على التأكد من أن العملاء لا يوفّرون حمولة شيفرة خبيثة في HTML الذي يرسلونه لملفاتهم الشخصية أو تعليقاتهم وما إلى ذلك، والذي يُحفظ على الخادم. يُقصد بمصطلح "الشيفرة الخبيثة" في تطبيقات الويب عادةً "JavaScript". وفي أغلب الأحوال، لا تُعتبر أوراق الأنماط المتتالية (CSS) خبيثة إلا عندما تستدعي JavaScript. ومع ذلك، هناك حالات عديدة يمكن فيها استخدام HTML و CSS "عادي" بطريقة خبيثة.
أولاً، أضف التبعية من Maven:
<dependency>
<groupId>org.owasp.antisamy</groupId>
<artifactId>antisamy</artifactId>
<version>LATEST_VERSION</version>
</dependency>
من المرجح أن حالة استخدام موقعك لـ AntiSamy مشابهة تقريبًا لواحد من ملفات السياسات المحددة مسبقًا. يمثل كل منها سيناريو "نموذجيًا" للسماح للمستخدمين بتوفير معلومات تنسيق HTML (وربما CSS). دعنا نلقي نظرة على ملفات السياسات المختلفة:
Slashdot هو موقع أخبار تقني يسمح للمستخدمين بالرد بشكل مجهول على المشاركات الإخبارية مع ترميز HTML محدود للغاية. وSlashdot ليس فقط أحد أروع المواقع، بل هو أيضًا أحد المواقع التي تعرضت للعديد من الهجمات الناجحة. قواعد Slashdot صارمة إلى حد ما: يمكن للمستخدمين إرسال وسوم HTML التالية فقط دون CSS: <b>، ، ، ، .
<u><i><a><blockquote>وفقًا لذلك، بنينا ملف سياسة يتيح وظائف مشابهة إلى حد ما. يُسمح بجميع وسوم تنسيق النصوص التي تعمل مباشرة على الخط أو اللون أو التركيز.
eBay هو موقع المزادات عبر الإنترنت الأكثر شعبية في العالم، على حد علمي. إنه موقع عام لذا يُسمح لأي شخص بنشر قوائم بمحتوى HTML غني. ليس من المستغرب أنه نظرًا لجاذبية eBay كهدف، فقد تعرض لعدد من هجمات XSS المعقدة. يُسمح للقوائم باحتواء محتوى أكثر غنى بكثير من، على سبيل المثال، Slashdot -- لذا فإن سطح الهجوم أكبر considerably.
كان MySpace، وقت إنشاء هذا المشروع، موقع التواصل الاجتماعي الأكثر شعبية. كان يُسمح للمستخدمين بإرسال كل HTML و CSS تقريبًا أرادوه -- طالما أنه لا يحتوي على JavaScript. كان MySpace يستخدم قائمة سوداء للكلمات للتحقق من HTML الخاص بالمستخدمين، ولهذا تعرض لدودة سامي الشهيرة. دودة سامي، التي استخدمت هجمات التجزئة مع كلمة كان يجب أن تكون محظورة (eval) -- كانت مصدر إلهام لهذا المشروع.
لا أعرف حالة استخدام محتملة لملف السياسة هذا. إذا أردت السماح بكل عنصر HTML و CSS صالح (ولكن دون JavaScript أو هجمات تصيّد واضحة مرتبطة بـ CSS)، يمكنك استخدام ملف السياسة هذا. حتى MySpace لم يكن بهذا الجنون. ومع ذلك، فهو بمثابة مرجع جيد لأنه يحتوي على قواعد أساسية لكل عنصر، لذا يمكنك استخدامه كقاعدة معرفية عند تخصيص ملفات السياسات الأخرى.
أثناء العمل على بعض التحسينات على تعريف مخطط XML (XSD) الخاص بـ AntiSamy لملفات سياسات AntiSamy، لاحظنا أن AntiSamy لم يكن في الواقع يطبّق XSD. لذلك، غيّرنا السلوك الافتراضي بدءًا من AntiSamy 1.6.0 لفرض المخطط، وعدم المتابعة إذا كانت سياسة AntiSamy غير صالحة. ومع ذلك ...
ندرك أنه قد لا يكون من الممكن للمطورين إصلاح سياسات AntiSamy الخاصة بهم على الفور إذا كانت غير متوافقة، ومع ذلك قد يرغبون في ترقية AntiSamy للحصول على التحسينات الأمنية وتحسينات الميزات وإصلاحات الأخطاء. على هذا النحو، وفّرنا طريقتين لتعطيل التحقق من المخطط (مؤقتًا!):
عيّن خاصية نظام Java: owasp.validator.validateschema إلى false. يمكن القيام بذلك من سطر الأوامر (مثلًا، -Dowasp.validator.validateschema=false) أو عبر ملف خصائص نظام Java. لا يتطلب أي منهما تغييرًا في الشيفرة.
غيّر الشيفرة التي تستخدم AntiSamy لاستدعاء: Policy.setSchemaValidation(false) قبل تحميل سياسة AntiSamy. هذا استدعاء ثابت، لذا بمجرد تعطيله، يتم تعطيله لجميع مثيلات Policy الجديدة.
لتشجيع مستخدمي AntiSamy على استخدام سياسات متوافقة مع XSD فقط، سيقوم AntiSamy دائمًا بتسجيل نوع من التحذير عند تعطيل التحقق من المخطط. إما أن يحذر من أن السياسة غير متوافقة بحيث يمكن إصلاحها، أو سيحذر من أن السياسة متوافقة، لكن التحقق من المخطط متوقف، لذا يجب إعادة تشغيل التحقق (أي التوقف عن تعطيله). أضفنا أيضًا تسجيلًا على مستوى INFO عند تحميل مخططات AntiSamy والتحقق منها.
إن القدرة على تعطيل ميزة التحقق من المخطط الجديدة مخصصة لتكون مؤقتة، لتسهيل الانتقال إلى ملفات سياسات AntiSamy صالحة بشكل صحيح. نخطط لإزالة هذه الميزة في الإصدار الرئيسي القادم. نقدر أن هذا سيكون في وقت ما في منتصف إلى أواخر 2022، لذا ليس قريبًا. الفكرة هي إعطاء فرق التطوير التي تستخدم AntiSamy مباشرة، أو عبر مكتبات أخرى مثل ESAPI، متسعًا من الوقت لجعل ملفات السياسات متوافقة مع المخطط قبل أن يصبح التحقق من المخطط إلزاميًا.
تم إصلاح ذلك سريعًا في 1.6.1 لاستخدام واجهات slf4j فقط. يتضمن AntiSamy الآن مكتبة slf4j-simple لتسجيله، لكن يمكن لمستخدمي AntiSamy استيراد واستخدام مكتبة تسجيل بديلة متوافقة مع slf4j إذا فضلوا ذلك. ويمكنهم أيضًا استبعاد slf4j-simple إذا أرادوا.
تحذير: استخدام AntiSamy لـ slf4j-simple، دون أي ملف تكوين، يسجل الرسائل بطريقة مخزنة (buffered) إلى المخرجات القياسية. على هذا النحو، قد تُفقد بعض أو كل رسائل السجل هذه إذا تم طرح استثناء، مثل PolicyException. يمكن إصلاح ذلك على الأرجح عن طريق تكوين slf4j-simple للتسجيل إلى الخطأ القياسي بدلاً من ذلك، أو استخدام مسجّل slf4j بديل يفعل ذلك.
قد ترغب في نشر AntiSamy بتهيئة افتراضية، لكن من المحتمل بنفس القدر أن يرغب موقع ما في فرض قواعد صارمة مدفوعة بالأعمال التجارية لما يمكن للمستخدمين السماح به. يجب أن يأخذ النقاش الذي يحدد التخصيص في الاعتبار أيضًا سطح الهجوم - الذي ينمو بنسبة متناسبة مع ملف السياسة.
استخدام AntiSamy سهل. إليك مثال على استدعاء AntiSamy مع ملف سياسة:
import org.owasp.validator.html.*;
Policy policy = Policy.getInstance(POLICY_FILE_LOCATION);
AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policy);
MyUserDAO.storeUserProfile(cr.getCleanHTML()); // some custom function
هناك عدة طرق لإنشاء كائن Policy. يمكن أن تأخذ طريقة getInstance() أيًّا مما يلي:
StringFileInputStreamPolicy بواسطة اسم الملف عبر تمرير وسيط ثانٍ لطريقة AntiSamy#scan() كما توضح الأمثلة التالية:AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, policyFilePath);
أخيرًا، يمكن الإشارة إلى ملفات السياسات أيضًا بواسطة كائنات File مباشرة في الوسيط الثاني:
AntiSamy as = new AntiSamy();
CleanResults cr = as.scan(dirtyInput, new File(policyFilePath));
يوفر كائن CleanResults الكثير من الأشياء المفيدة.
getErrorMessages() - قائمة برسائل الخطأ من نوع String -- إذا أعادت 0 فهذا لا يعني عدم وجود هجمات!getCleanHTML() - مخرجات HTML النظيفة والآمنةgetCleanXMLDocumentFragment() - XMLDocumentFragment النظيف والآمن والذي ينعكس في getCleanHTML()getScanTime() - يعيد وقت الفحص بالثوانيملاحظة مهمة: كان هناك الكثير من الالتباس حول طريقة getErrorMessages(). طريقة getErrorMessages() لا تجيب بدقة على سؤال "هل هذا الإدخال آمن؟" بالإيجاب إذا أعادت قائمة فارغة. يجب عليك دائمًا استخدام الإدخال المنقّى، ولا توجد طريقة للتأكد من أن الإدخال الممرر لم يتعرض لأي هجوم.
إن عملية التسلسل وإلغاء التسلسل الحاسمة لفعالية المنقّي هي خاسرة عمدًا وستقوم بتصفية الهجمات عبر عدد من نواقل الهجوم. لسوء الحظ، أحد المفاضلات لهذه الاستراتيجية هو أننا لا نعرف دائمًا بأثر رجعي أنه تم رؤية هجوم. وبالتالي، فإن واجهة getErrorMessages() موجودة لمساعدة المستخدمين على فهم كيفية توافق إدخالهم حسن النية مع متطلبات النظام، وليس لمساعدة المطور في اكتشاف ما إذا كان الهجوم موجودًا.
وثائق إضافية متاحة على صفحة wiki الخاصة بمشروع Github هذا: https://github.com/nahsra/antisamy/wiki وصفحة مشروع OWASP AntiSamy: https://owasp.org/www-project-antisamy/
إذا وجدت خطأ برمجيًا، فأنشئ مشكلة في مستودع AntiSamy: https://github.com/nahsra/antisamy/issues
إذا وجدت ثغرة أمنية في AntiSamy، فابحث أولاً في قائمة المشكلات (انظر أعلاه) لمعرفة ما إذا تم الإبلاغ عنها بالفعل. إذا لم يتم الإبلاغ عنها، فيرجى الاتصال بـ Dave Wichers (dave.wichers at owasp.org) مباشرة. يرجى عدم الإبلاغ عن الثغرات عبر مشكلات GitHub لأننا نرغب في إبقاء مستخدمينا آمنين أثناء تنفيذ التصحيح ونشره. إذا كنت ترغب في الحصول على اعتراف لوجودك الثغرة، فيرجى اتباع هذه العملية.
مزيد من التفاصيل متاحة في الملف: SECURITY.md.
يمكنك البناء والاختبار من المصدر بسهولة:
$ git clone https://github.com/nahsra/antisamy
$ cd antisamy
$ mvn package
صدر بموجب ترخيص BSD-3-Clause كما هو محدد هنا: LICENSE.