alkimcoskun/yordam-kutuphane-otomasyonunda-coklu-html-enjeksiyonuCVE-2026-77818 - Yordam Kütüphane Otomasyon Sistemi - तीन अलग-अलग बिंदुओं पर परावर्तित HTML इंजेक्शन, फ़ॉर्म एक्शन अपहरण और क्रेडेंशियल चोरी (CWE-79)
CVE-2026-77818 · CVSS 3.1 6.1 (मध्यम) · साइबर सुरक्षा प्रेसीडेंसी · प्रकाशन 2026-09-04 · TR-26-1011
स्थिति: कमजोरियों को v22.2 संस्करण में दूर कर दिया गया है। प्रभावित इंस्टॉलेशन को v22.2 या उससे ऊपर अपग्रेड करना आवश्यक है।
योर्डम लाइब्रेरी ऑटोमेशन सिस्टम, तुर्की में विश्वविद्यालय, सार्वजनिक और संस्थागत पुस्तकालयों में व्यापक रूप से उपयोग किया जाने वाला एक व्यावसायिक लाइब्रेरी ऑटोमेशन और ऑनलाइन कैटलॉग (OPAC) सॉफ्टवेयर है। इंस्टॉलेशन ऑन-प्रिमाइसेस है; प्रत्येक ग्राहक संस्थान में एक अलग प्रति चलती है।
उत्पाद के v22.1 संस्करण में, एक-दूसरे से स्वतंत्र तीन अलग-अलग बिंदुओं पर रिफ्लेक्टेड HTML इंजेक्शन पाया गया है। तीनों को प्रमाणीकरण की आवश्यकता नहीं होती, तीनों एक ही लिंक से ट्रिगर होते हैं।
| # | बिंदु | मूल कारण |
|---|---|---|
| 1 | लॉगिन पेज, devam पैरामीटर | एस्केप बिल्कुल लागू नहीं किया गया |
| 2 | छिपे हुए फॉर्म फ़ील्ड का value एट्रिब्यूट | एस्केप के बाद दूसरी बार URL डिकोड |
| 3 | छिपे हुए फॉर्म फ़ील्ड का name एट्रिब्यूट | एस्केप केवल मान पर लागू होता है, नाम पर नहीं |
तीनों एक ही उत्पाद के एक ही संस्करण में और एक ही कमजोरी वर्ग में होने के कारण, उन्हें एक ही अधिसूचना के अंतर्गत एकत्र किया गया और एक ही CVE आईडी के अंतर्गत प्रकाशित किया गया। प्रभाव की दृष्टि से सबसे गंभीर बिंदु नंबर 1 है।
devam पैरामीटरयह सबसे महत्वपूर्ण है। इंजेक्शन बिंदु सीधे प्रमाणीकरण फॉर्म के अपने HTML टैग में है।
devam पैरामीटर उस पते को ले जाता है जिस पर उपयोगकर्ता लॉगिन के बाद लौटेगा और हेक्स-एन्कोडेड आता है — 2f796f7264616d2f मान का अर्थ /yordam/ है। एप्लिकेशन इस मान को हेक्स से डिकोड करता है और लॉगिन फॉर्म के शुरुआती टैग में लिखता है। बीच में कोई एस्केप प्रक्रिया नहीं होती:
<form class='girisForm collapse show ikiAdimliGiris' method='post'
action='inc/islem.fm.inc.php'
data-url='<हेक्स डिकोडेड उपयोगकर्ता इनपुट>'
autocomplete="off">
आउटपुट में <, > और उद्धरण वर्ण कच्चे रूप में मौजूद होते हैं। पेलोड को रोकने वाली एकमात्र चीज़ data-url एट्रिब्यूट का सिंगल कोट में लिपटा होना है। इनपुट के अंदर सिंगल कोट डालने पर वह भी समाप्त हो जाता है: एट्रिब्यूट बंद हो जाता है, <form> टैग बंद हो जाता है और हमलावर द्वारा लिखा गया HTML पेज के प्रमाणीकरण फॉर्म की जगह ले लेता है।
फॉर्म एक्शन पर कब्ज़ा हो जाता है। यहाँ कोई नकली फॉर्म नहीं बनाया जाता — एप्लिकेशन का अपना फॉर्म खाली छोड़कर बंद कर दिया जाता है, और तुरंत बाद उसी CSS क्लास वाला एक नया <form> खोला जाता है। पेज पर उपयोगकर्ता नाम, पासवर्ड और सत्यापन कोड फ़ील्ड सभी एप्लिकेशन के मूल HTML होने के कारण इस नए फॉर्म के अंदर रहते हैं। उपयोगकर्ता असली फॉर्म देखता है, असली फॉर्म भरता है; उसके द्वारा दर्ज की गई जानकारी हमलावर के सर्वर पर जाती है। दृश्य रूप से अंतर करने योग्य कोई अंतर नहीं होता।
महत्वपूर्ण बिंदु: इंजेक्शन किसी यादृच्छिक पेज पर नहीं, बल्कि उस पेज पर होता है जहाँ उपयोगकर्ता से पहले से ही पासवर्ड दर्ज करने की अपेक्षा की जाती है। सामान्य रिफ्लेक्टेड इंजेक्शन में हमलावर को पीड़ित को मनाना पड़ता है; यहाँ मनाने का काम एप्लिकेशन का अपना इंटरफ़ेस करता है।
value एट्रिब्यूट — डबल URL डिकोडिंगखोज पेज पर GET पैरामीटर के मान छिपे हुए फॉर्म फ़ील्ड में लिखे जाते हैं। इस बिंदु पर एस्केप लागू होता है — लेकिन गलत क्रम में।
एक ही q मान एक ही प्रतिक्रिया में तीन अलग-अलग संदर्भों में उपयोग होता है, और प्रत्येक की डिकोडिंग गहराई अलग होती है:
| संदर्भ | डिकोडिंग | स्थिति |
|---|---|---|
<script> ब्लॉक में JS स्ट्रिंग | 1 बार | सुरक्षित |
मुख्य खोज बॉक्स <input value="…"> | 1 बार | सुरक्षित |
छिपे हुए फॉर्म फ़ील्ड <input type='hidden' value="…"> | 2 बार | कमजोर |
प्रक्रिया का क्रम इस प्रकार है:
क्लाइंट इनपुट : %2522
↓ $_GET पार्सिंग
PHP वेरिएबल : %22
↓ इनपुट फ़िल्टर → हानिकारक सामग्री नहीं दिखती, बीच में कोई उद्धरण नहीं
↓ htmlspecialchars → एस्केप करने के लिए कोई वर्ण नहीं, कोई बदलाव नहीं
↓ urldecode → %22 डिकोड होता है
पेज पर डाला गया : " ← कच्चा उद्धरण, एट्रिब्यूट से बाहर निकलना
इनपुट फ़िल्टर और एस्केप पहली डिकोडिंग परत पर काम करते हैं, जबकि आउटपुट दूसरी परत से आपूर्ति होता है। एक ही पेलोड के सिंगल और डबल एन्कोडेड रूपों की तुलना करने पर अंतर स्पष्ट दिखता है:
| भेजा गया | प्रतिक्रिया | छिपे हुए फ़ील्ड का आउटपुट |
|---|---|---|
q=foo%22… (सिंगल एन्कोडिंग) | 302 Found | value="foo"…" — फ़िल्टर पकड़ लेता है |
q=foo%2522… (डबल एन्कोडिंग) | 200 OK | value="foo"><…>" — कच्चा HTML |
कमजोरी केवल q पैरामीटर तक सीमित नहीं है। छिपे हुए फ़ील्ड उत्पन्न करने वाला ब्लॉक अनुरोध में मौजूद सभी GET पैरामीटर पर लूप करता है; tip और alan पर भी अलग से सत्यापन किया गया है।
name एट्रिब्यूट — पैरामीटर नाम में इंजेक्शनवही ब्लॉक प्रत्येक GET पैरामीटर के लिए निम्न संरचना उत्पन्न करता है:
<input type='hidden' name="<पैरामीटर नाम>" value="<पैरामीटर मान>"/>
एस्केप केवल value पक्ष पर लागू होता है। name पक्ष पर बिल्कुल लागू नहीं होता। इस बिंदु पर डबल एन्कोडिंग की भी आवश्यकता नहीं होती — सिंगल एन्कोडिंग पर्याप्त है, क्योंकि बीच में एस्केप करने के लिए कोई बाधा ही नहीं है।
एक मनगढ़ंत पैरामीटर नाम सीधे name एट्रिब्यूट में कच्चे रूप में लिखा जाता है और एट्रिब्यूट से बाहर निकला जा सकता है। पैरामीटर नाम हमलावर के नियंत्रण में होने के कारण, एप्लिकेशन द्वारा पहचाने जाने वाले पैरामीटर का होना भी आवश्यक नहीं है।
इन तीन बिंदुओं में से नंबर 2 और 3 एक ही कोड ब्लॉक से उत्पन्न होते हैं और यह ब्लॉक छह अलग-अलग फॉर्म में दोहराया जाता है: dilForm, adetForm, siralaForm, tkForm, ekForm, tmForm। यानी एक ही अनुरोध में इंजेक्शन छह बार होता है।
ब्लॉक के गतिशील होने की पुष्टि दो अनुरोधों के आउटपुट की तुलना करके की गई है:
अनुरोध A: ?p=1&dil=0&alan=&tip=basit&gorunum=liste&q=…
आउटपुट A: name="p" · name="alan" · name="tip" · name="gorunum" · name="q"
अनुरोध B: ?p=2&dil=0&devam=…
आउटपुट B: name="p" · name="devam"
उत्पन्न फ़ील्ड किसी निश्चित सूची से नहीं, बल्कि सीधे अनुरोध में मौजूद पैरामीटर से व्युत्पन्न होते हैं। इसलिए name और value दोनों एट्रिब्यूट में लिखी गई सामग्री हमलावर के नियंत्रण में होती है।
हमलावर को केवल एक ऐसे लिंक की आवश्यकता होती है जिसे पीड़ित खोले। उसे लॉगिन करने या खाता रखने की आवश्यकता नहीं होती।
action लक्ष्य हमलावर की ओर मोड़ दिया जाता है। सत्यापित किया गया।प्रभावित प्लेटफ़ॉर्म पुस्तकालय सदस्यों के क्रेडेंशियल और व्यक्तिगत डेटा संग्रहीत करता है, इसलिए हथियाए गए खातों के माध्यम से सदस्य रिकॉर्ड तक पहुँच संभव हो जाती है।
एप्लिकेशन CSP का उपयोग करता है और script-src तथा object-src नॉन्स-आधारित हैं; यानी क्लासिक स्क्रिप्ट-आधारित XSS इन पेजों पर काम नहीं करता। पहली नज़र में यह निष्कर्ष को "केवल सामग्री हेरफेर" के स्तर तक कम करता हुआ प्रतीत होता है।
पॉलिसी का पूरा विवरण इस प्रकार है:
Content-Security-Policy: script-src 'nonce-...'; object-src 'nonce-...'; frame-ancestors 'self'
form-action नहीं है। default-src भी नहीं है — इसलिए अपरिभाषित डायरेक्टिव के लिए कोई डिफ़ॉल्ट भी नहीं है। परिणाम: फॉर्म का हमलावर के सर्वर पर POST भेजना ब्राउज़र द्वारा किसी भी तरह से अवरुद्ध नहीं होता।
क्रेडेंशियल चुराने के लिए JavaScript चलाना आवश्यक नहीं है। सादा HTML पर्याप्त है, और CSP सादे HTML को नहीं रोकता।
प्राथमिक
संबंधित