फ़ाइल अपलोड बाइपास + स्टोर्ड XSS PoC लैब

एक जानबूझकर कमजोर वेब एप्लिकेशन जो दर्शाता है कि कैसे फ़ाइल अपलोड बाइपास स्टोर्ड XSS के साथ मिलकर बैकडोर एडमिन खाते बनाता है, भले ही CSP, CORS और CSRF सुरक्षाएँ मौजूद हों।

पूरा ब्लॉग पोस्ट: KurtiseBear ब्लॉग

यह एक शैक्षणिक लैब है जो रक्षात्मक सुरक्षा प्रशिक्षण के लिए है। इसे कहीं भी सार्वजनिक रूप से सुलभ न रखें।

यह क्या प्रदर्शित करता है

एप्लिकेशन में वास्तविक सुरक्षा नियंत्रण हैं:

• सामग्री सुरक्षा नीति (CSP) जो स्क्रिप्ट स्रोतों को 'self' तक सीमित करती है (लेकिन 'unsafe-inline' और 'unsafe-eval' के साथ)
• कोई CORS हेडर नहीं भेजे जाते, इसलिए क्रॉस-ऑरिजिन अनुरोध ब्राउज़र द्वारा अवरुद्ध हो जाते हैं
• सभी फॉर्म सबमिशन (संदेश, फ़ाइल अपलोड) पर CSRF टोकन
• मानक सुरक्षा हेडर (X-Content-Type-Options, X-Frame-Options, Referrer-Policy)

निम्न-विशेषाधिकार उपयोगकर्ता खाते वाला हमलावर दो कमजोरियों को जोड़कर इन सभी को बायपास करता है:

1. फ़ाइल अपलोड बाइपास -- अपलोड फ़ॉर्म accept विशेषता के माध्यम से केवल .pdf तक सीमित करता है, लेकिन सर्वर शून्य फ़ाइल प्रकार सत्यापन करता है। हमलावर JavaScript युक्त .js फ़ाइल अपलोड करता है। डाउनलोड एंडपॉइंट इसे समान उत्पत्ति से प्रस्तुत करता है, इसलिए CSP और CORS इसे अवरुद्ध नहीं करते।

2. संदेश विषय के माध्यम से स्टोर्ड XSS -- मैसेजिंग सुविधा स्वच्छता के बिना उपयोगकर्ता इनपुट संग्रहीत करती है। एडमिन इनबॉक्स संदेश विषय को कच्चे HTML के रूप में प्रस्तुत करता है। XSS पेलोड एक `` हैंडलर का उपयोग करके अपलोड की गई स्क्रिप्ट को लाता है और eval() करता है। CSP इसकी अनुमति देता है क्योंकि 'unsafe-inline' और 'unsafe-eval' की अनुमति है।

3. API एंडपॉइंट पर CSRF की कमी -- उपयोगकर्ता प्रबंधन API (/api/manage-user.php) CSRF टोकन सत्यापित नहीं करता, भले ही फॉर्म एंडपॉइंट करते हैं। XSS पेलोड एडमिन के समान-उत्पत्ति सत्र का उपयोग करके इस API को कॉल करता है। यदि CSRF मौजूद भी होता, तो समान-उत्पत्ति JavaScript DOM से टोकन पढ़ सकती थी।

परिणाम: जब कोई एडमिन अपना इनबॉक्स खोलता है, तो XSS फायर होता है, JavaScript एडमिन के सत्र का उपयोग करके एक बैकडोर एडमिन खाता बनाती है। हर सुरक्षा मौजूद और कार्य कर रही है। श्रृंखला काम करती है क्योंकि यह कभी उत्पत्ति नहीं छोड़ती।

आवश्यक शर्तें

• Docker
• Docker Compose

सेटअप

docker-compose up -d

MySQL को इनिशियलाइज़ होने के लिए 10-15 सेकंड प्रतीक्षा करें, फिर http://localhost:8080 पर जाएँ

क्रेडेंशियल्स

हमले की वॉकथ्रू

चरण 1: सामान्य उपयोगकर्ता के रूप में लॉगिन करें

http://localhost:8080 पर जाएँ और [email protected] / user से लॉगिन करें।

चरण 2: पेलोड अपलोड करें

फ़ाइलें अपलोड करें पर जाएँ। फ़ॉर्म कहता है "केवल PDF" लेकिन इसे केवल क्लाइंट-साइड लागू करता है। या तो:

• फ़ाइल इनपुट से accept=".pdf" विशेषता हटाने के लिए ब्राउज़र डेव टूल का उपयोग करें, या
• सीधे अपलोड करने के लिए curl/Burp का उपयोग करें (आपको फ़ॉर्म से CSRF टोकन शामिल करना होगा)

दी गई payload.js (या अपनी खुद की) अपलोड करें। लौटाई गई फ़ाइल ID नोट करें (जैसे, 1)।

अपलोड की गई फ़ाइल अब समान उत्पत्ति पर /api/download.php?file_id=1 से प्रस्तुत की जाती है। CSP इस एंडपॉइंट पर फ़ेच को ब्लॉक नहीं करेगा क्योंकि यह 'self' है।

चरण 3: XSS संदेश तैयार करें

संदेश भेजें पर जाएँ। विषय फ़ील्ड में, दर्ज करें:

r.blob()).then(b=>b.text()).then(eval)">

(चरण 2 से वास्तविक फ़ाइल ID के साथ 1 बदलें।)

बॉडी में कुछ भी डालें। यदि आप चाहते हैं कि यह इनबॉक्स के शीर्ष पर हो तो प्राथमिकता चेक करें। भेजें।

onerror हैंडलर काम करता है क्योंकि CSP 'unsafe-inline' की अनुमति देता है। eval() काम करता है क्योंकि CSP 'unsafe-eval' की अनुमति देता है। डाउनलोड एंडपॉइंट पर फ़ेच काम करता है क्योंकि यह समान-उत्पत्ति है।

चरण 4: एडमिन द्वारा इनबॉक्स जाँचने की प्रतीक्षा करें

लॉग आउट करें। [email protected] / admin के रूप में लॉगिन करें। इनबॉक्स पर जाएँ।

संदेश विषय कच्चे HTML के रूप में प्रस्तुत होता है। `` टैग लोड करने में विफल रहता है, onerror हैंडलर फायर होता है, अपलोड किए गए पेलोड को लाता है, और eval() इसे निष्पादित करता है। पेलोड एडमिन के सत्र कुकी का उपयोग करके /api/manage-user.php पर POST करता है (समान-उत्पत्ति अनुरोधों के लिए स्वचालित रूप से संलग्न)। CSRF टोकन की आवश्यकता नहीं है क्योंकि API एंडपॉइंट इसकी जाँच नहीं करता।

चरण 5: बैकडोर सत्यापित करें

उपयोगकर्ता पर जाएँ। आपको एक नया उपयोगकर्ता दिखना चाहिए: BackdoorAdmin भूमिका admin और ईमेल [email protected] के साथ।

लॉग आउट करें और [email protected] / Compromised1! से लॉगिन करके पुष्टि करें।

सुरक्षाएँ क्यों विफल हुईं

CSP blocks external scripts
  --> But the payload is hosted on the same origin via file upload
  --> And unsafe-inline/unsafe-eval allow the onerror handler and eval()

CORS blocks cross-origin requests
  --> But every request in the chain is same-origin

CSRF tokens protect form submissions
  --> But the API endpoint doesn't validate them
  --> And even if it did, same-origin JS can read tokens from the DOM

Session cookies have standard protections
  --> But same-origin requests carry them automatically

सुरक्षाएँ सभी सही ढंग से काम कर रही हैं। वे क्रॉस-ऑरिजिन हमलों को रोकने के लिए डिज़ाइन की गई हैं। यह श्रृंखला कभी उत्पत्ति नहीं छोड़ती।

रक्षात्मक उपाय

ये चीज़ें वास्तव में इस श्रृंखला को तोड़ेंगी:

1. सर्वर-साइड फ़ाइल प्रकार सत्यापन -- MIME प्रकार, फ़ाइल एक्सटेंशन और मैजिक बाइट्स जाँचें। क्लाइंट पर भरोसा न करें। यह हमलावर को आपकी उत्पत्ति पर पेलोड होस्ट करने से रोकता है।
2. आउटपुट एन्कोडिंग -- सभी उपयोगकर्ता-नियंत्रित आउटपुट पर htmlspecialchars() का उपयोग करें। इनबॉक्स $row['subject'] को कच्चा प्रस्तुत करता है। यह XSS को पूरी तरह से समाप्त कर देता है।
3. सख्त CSP -- 'unsafe-inline' और 'unsafe-eval' हटाएँ। वैध इनलाइन स्क्रिप्ट के लिए नॉन्स या हैश का उपयोग करें। यह onerror हैंडलर और eval() को ब्लॉक करता है।
4. Content-Disposition: attachment -- उपयोगकर्ता द्वारा अपलोड की गई फ़ाइलों के लिए इनलाइन रेंडरिंग के बजाय डाउनलोड बाध्य करें। यह ब्राउज़र को अपलोड की गई सामग्री की व्याख्या करने से रोकता है।
5. सभी स्थिति-बदलने वाले एंडपॉइंट पर CSRF -- केवल फॉर्म ही नहीं, API एंडपॉइंट भी शामिल करें।
6. अपलोड पर पहुँच नियंत्रण -- डाउनलोड API किसी भी प्रमाणित उपयोगकर्ता को कोई भी फ़ाइल प्रस्तुत करता है। फ़ाइलों को उनके स्वामी तक सीमित किया जाना चाहिए।

सफाई

docker-compose down -v

अस्वीकरण

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