seanpesce/cve-2024-22243स्प्रिंग फ्रेमवर्क को प्रभावित करने वाले CVE-2024-22243 के शोषण योग्य परिदृश्यों के उदाहरण (open redirect और SSRF)।
लेखक: Sean Pesce
यह प्रोजेक्ट एक उदाहरण वेब एप्लिकेशन शामिल करता है जो CVE-2024-22243 के लिए शोषण योग्य परिदृश्यों का प्रदर्शन करता है, जो Java Spring Framework में एक URL-पार्सिंग भेद्यता है (आधिकारिक प्रकटीकरण यहाँ).
Spring के प्रभावित संस्करण URLs के "userinfo" खंड को एक अद्वितीय तरीके से पार्स करते हैं, जिसके परिणामस्वरूप संभावित रूप से एक होस्ट नाम खंड निकाला जा सकता है जो कई अन्य सामान्य लाइब्रेरियों से भिन्न होता है।
असामान्य व्यवहार निम्नलिखित नियमित अभिव्यक्ति (regex) के कारण है
UriComponentsBuilder
वर्ग में (जो इस कमिट द्वारा 2014 में जोड़ा गया):
private static final String USERINFO_PATTERN = "([^@\\[/?#]*)";
यह regex उपयोगकर्ता जानकारी खंड में 'बायाँ ब्रैकेट' वर्ण ([) की अनुमति नहीं देता है। हालांकि, Spring इस व्यवहार में एक बाहरी प्रतीत होता है, इसलिए
ऑब्जेक्ट पर को कॉल करना,
जो
या
का उपयोग करके बनाया गया है, अप्रत्याशित व्यवहार का परिणाम दे सकता है।
,
,
और
वर्ग भी प्रभावित हैं क्योंकि वे आंतरिक रूप से का उपयोग करते हैं; इसलिए, कार्यान्वयन के सीधे उपयोग के बिना भी असुरक्षित हो सकते हैं।
getHost()UriComponentsBuilderUriComponentsBuilderविशेष रूप से तैयार किए गए इनपुट के लिए, Spring एक होस्ट नाम मान लौटाएगा जो निम्नलिखित सभी से भिन्न होता है:
java.net.URI (कथित तौर पर केवल विशिष्ट Java संस्करणों के लिए; अन्य संस्करण URISyntaxException उत्पन्न करते हैं)java.net.URLcurlandroid.net.Uriokhttp3.HttpUrlurllib.parse.urlparse(ध्यान दें कि यह सूची गैर-व्यापक है।)
यह व्यवहार संभावित रूप से Spring-आधारित वेब एप्लिकेशन को ओपन रिडायरेक्ट और सर्वर-साइड रिक्वेस्ट फोर्जरी (SSRF) के प्रति असुरक्षित बना सकता है यदि निर्भर कार्यान्वयन प्राधिकरण या अन्य सुरक्षा-प्रासंगिक तंत्रों के लिए विश्वसनीय होस्ट नामों का उपयोग करता है।
उदाहरण वेब एप्लिकेशन में दो असुरक्षित एंडपॉइंट हैं।
पहला एंडपॉइंट, /redirect, दिखाता है कि कैसे Spring का असामान्य URL पार्सिंग एक ओपन रिडायरेक्ट का परिणाम दे सकता है। इसका शोषण निम्नलिखित जैसे URL का उपयोग करके किया जा सकता है:
https://127.0.0.1[@evil.com
दूसरा एंडपॉइंट, /health-check, प्रदर्शित करता है कि कैसे Spring और Java मानक लाइब्रेरी URL वर्ग के बीच URL पार्सिंग में बेमेल सर्वर-साइड रिक्वेस्ट फोर्जरी (SSRF) का परिणाम दे सकता है। इसका शोषण निम्नलिखित जैसे URL का उपयोग करके किया जा सकता है:
https://evil.com[@127.0.0.1
Maven के साथ इस प्रोजेक्ट को बनाने के लिए, निम्नलिखित कमांड चलाएं (OpenJDK 17 के साथ परीक्षण किया गया):
mvn clean package
फिर, निम्नलिखित जैसे कमांड के साथ वेब ऐप शुरू करें:
java -jar seanpesce-cve-2024-22243.jar 9999
वेब ऐप http://127.0.0.1:9999/ पर सुलभ होगा।
डॉकर इमेज बनाने के लिए, निम्नलिखित कमांड चलाएं:
docker build -t seanpesce-cve-2024-22243:latest .
फिर, निम्नलिखित जैसे कमांड के साथ वेब ऐप शुरू करें:
docker run -i -e PORT=9999 -p 9999:9999 seanpesce-cve-2024-22243:latest
वेब ऐप डॉकर होस्ट पर http://127.0.0.1:9999/ पर सुलभ होगा।
इस रिपॉजिटरी में संभावित रूप से असुरक्षित कोड पथों की स्कैनिंग में सहायता के लिए semgrep नियम भी शामिल हैं।
spring-cve-2024-22243_loose.yaml
कमजोर APIs के किसी भी उपयोग के लिए naive स्कैन करता है; इस प्रकार, यह अक्सर बड़ी संख्या में गलत सकारात्मक परिणाम लौटाएगा।
spring-cve-2024-22243_strict.yaml
सख्त तर्क और टैंट विश्लेषण का उपयोग करने का प्रयास करता है; हालांकि, इसका पूरी तरह से परीक्षण नहीं किया गया है और इसमें कुछ कमजोर कार्यान्वयनों को याद करने की उच्च संभावना है (विशेषकर जब Semgrep Pro का उपयोग नहीं कर रहे हैं, जो क्रॉस-फ़ाइल विश्लेषण के लिए आवश्यक है)।