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 को नहीं रोकता।
प्राथमिक
संबंधित
CVE रिकॉर्ड में प्राथमिक कमजोरी CWE-79 के रूप में वर्गीकृत है। मूल कारण स्तर पर CWE-116 अधिक व्याख्यात्मक है: तीनों बिंदुओं का कारण आउटपुट एस्केप का या तो बिल्कुल लागू न होना या गलत क्रम में लागू होना है।
यह ध्यान देने योग्य है कि इस उत्पाद में स्क्रिप्ट निष्पादित नहीं होती — उत्पाद द्वारा स्वयं भेजी गई नॉन्स-आधारित script-src पॉलिसी इसकी अनुमति नहीं देती और नॉन्स मान क्रॉस-ओरिजिन पढ़ा नहीं जा सकता। वास्तविक प्रभाव स्क्रिप्ट निष्पादन नहीं, बल्कि HTML इंजेक्शन और लॉगिन फॉर्म पर कब्ज़ा है। CAPEC-148 (Content Spoofing) मैपिंग भी इसी कारण की गई है।
CWE-174, विशेष रूप से बिंदु नंबर 2 के लिए प्रासंगिक है — एस्केप के बाद उसी डेटा का दूसरी बार डिकोड होना।
मध्यम — CVSS 3.1 बेस स्कोर 6.1 (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N)
हमलावर को किसी भी अधिकार की आवश्यकता नहीं होती; पीड़ित को तैयार लिंक खोलना आवश्यक होने के कारण उपयोगकर्ता इंटरैक्शन आवश्यक है। Scope, इंजेक्ट की गई सामग्री के ब्राउज़र के सुरक्षा संदर्भ में संसाधित होने के कारण Changed लिया गया है।
तीनों बिंदु एक ही स्कोर के अनुरूप हैं। प्रभाव की दृष्टि से सबसे गंभीर बिंदु नंबर 1 है: इंजेक्शन सीधे प्रमाणीकरण फॉर्म के अपने टैग में होने के कारण फॉर्म action लक्ष्य पर कब्ज़ा और क्रेडेंशियल चोरी संभव हो जाती है।
योर्डम लाइब्रेरी ऑटोमेशन सिस्टम
प्रभावित : v22.1 और पहले
दूर किया गया : v22.2
सत्यापन v22.1 पर किया गया। कमजोरियाँ संस्थान-विशिष्ट कॉन्फ़िगरेशन त्रुटि नहीं, बल्कि उत्पाद के सामान्य इंटरफ़ेस घटकों से उत्पन्न होती हैं; यह उसी संस्करण परिवार के सभी इंस्टॉलेशन को प्रभावित करती हैं। पुराने संस्करणों की स्थिति का मूल्यांकन निर्माता को करना आवश्यक है।
इंस्टॉलेशन ऑन-प्रिमाइसेस होने के कारण, निर्माता द्वारा सुधार प्रकाशित करने के बाद भी जिन इंस्टॉलेशन ने अपडेट लागू नहीं किया है, वे प्रभावित रहते हैं।
| # | एंडपॉइंट | आउटपुट बिंदु |
|---|---|---|
| 1 | GET /yordam/?p=2&dil=<n>&devam=<hex> | लॉगिन फॉर्म का data-url एट्रिब्यूट |
| 2 | GET /yordam/?p=1&…&<पैरामीटर>=<पेलोड> | छिपे हुए फॉर्म फ़ील्ड का value एट्रिब्यूट |
| 3 | GET /yordam/?p=1&…&<पेलोड>=1 | छिपे हुए फॉर्म फ़ील्ड का name एट्रिब्यूट |
बिंदु नंबर 2 और 3 एक ही छिपे हुए फ़ील्ड उत्पादक ब्लॉक से उत्पन्न होते हैं; ब्लॉक dilForm, adetForm, siralaForm, tkForm, ekForm और tmForm फॉर्म में दोहराया जाता है।
कमजोरियों को निर्माता द्वारा दूर कर दिया गया है। एप्लिकेशन को v22.2 या उससे ऊपर के संस्करण में अपग्रेड किया जाना चाहिए।
| CVE आईडी | CVE-2026-77818 |
| असाइनर (CNA) | TR-CERT (USOM) — T.C. साइबर सुरक्षा प्रेसीडेंसी |
| स्थिति | PUBLISHED |
| आरक्षित | 2026-08-21 |
| प्रकाशन | 2026-09-04 |
| सुरक्षा अधिसूचना | TR-26-1011 |
| CVE रिकॉर्ड शीर्षक | Reflected HTML Injection via Form Hijacking in Yordam Informatics's Library Automation System |
| CAPEC | CAPEC-148 — Content Spoofing |
निर्माता: योर्डम सूचना प्रौद्योगिकी परामर्श शिक्षा और इलेक्ट्रॉनिक सिस्टम उद्योग और व्यापार A.Ş.
अल्किम कोश्कुन – Netlore Security
| तिथि | घटना |
|---|---|
| 2026-08-20 | कमजोरियाँ खोजी गईं और सत्यापित की गईं |
| 2026-08-21 | साइबर सुरक्षा प्रेसीडेंसी को सूचित किया गया; CVE आईडी आरक्षित की गई |
| 2026-09-04 | CVE-2026-77818 प्रकाशित हुआ, सुरक्षा अधिसूचना TR-26-1011 घोषित की गई |