JWT हस्ताक्षर सत्यापन सफल होने पर भी हमलावर दूसरे की जगह कैसे ले सकता है?

इस प्रश्न में JWT प्रबंधन लाइब्रेरी ने JWT हेडर के alg को हमलावर द्वारा निर्दिष्ट रूप में ही स्वीकार किया, और alg=none वाले JWT को बिना किसी हस्ताक्षर के वैध माना। इसलिए पेलोड का उपयोगकर्ता ID फिर से लिखने पर भी सत्यापन पास हो जाता है। परीक्षा का उत्तर है JWT हेडर के alg की जाँच करना और पुष्टि करना कि उसका मान NONE नहीं है। व्यवहार में, केवल NONE अस्वीकार करना पर्याप्त नहीं। सर्वर-साइड कॉन्फ़िगरेशन में उपयोग के लिए अनुमत एल्गोरिद्म — उदाहरण के लिए RS256 — तय करें, ताकि टोकन जो एल्गोरिद्म घोषित करे उसे चुनाव के लिए सीधे न लिया जाए। उपयोग के अनुसार issuer, audience, समाप्ति, subject आदि भी सत्यापित करें।

JWT के अंदर उपयोगकर्ता ID की तुलना अनुरोध के mid से करना प्राधिकरण उपाय के रूप में काफी है?

इस परीक्षा के उत्तर के लिए काफी है। साझा मॉड्यूल P के अंदर यह सत्यापित करना कि JWT में निहित उपयोगकर्ता ID mid से मेल खाता है, किसी और का mid निर्दिष्ट करने वाले हमले को रोकता है। लेकिन जो API केवल कॉलर की अपनी जानकारी सँभालता है, व्यवहार में क्लाइंट से mid बिल्कुल न लेना, और सत्यापित JWT के subject से उपयोगकर्ता ID तय करना अधिक सुरक्षित है। GET /users/me या PUT /users/me जैसे पथ तुलना-तर्क के छूट जाने को कठिन बनाते हैं। जिस API पर व्यवस्थापक दूसरे उपयोगकर्ता पर काम करे, उसे अलग एंडपॉइंट और अपनी प्राधिकरण नीति में बाँटें।

सामान्य इनपुट सत्यापन अकेले status जोड़ने वाले हमले को क्यों नहीं रोक सकता?

क्योंकि name की लंबाई या age की सीमा जाँचने से कुछ नहीं होता यदि status — एक फ़ील्ड जिसे पहले स्थान पर स्वीकार ही नहीं करना चाहिए था — स्वतः बाउंड होकर आंतरिक ऑब्जेक्ट तक चला जाता है। समस्या मान का प्रारूप नहीं; गुण-स्तर प्राधिकरण है, यानी उपयोगकर्ता को वह गुण बदलने की अनुमति है भी या नहीं। अद्यतन इनपुट प्रकार में केवल name और age परिभाषित करें, और अज्ञात गुण अस्वीकार करें। बिलिंग स्थिति केवल सर्वर-विश्वसनीय घटनाओं से बदले, जैसे भुगतान सेवा का सफल परिणाम।

चार-अंकीय प्रमाणीकरण कोड 10 मिनट में समाप्त होता है — फिर भी खतरनाक क्यों है?

क्योंकि 0000 से 9999 तक केवल 10,000 उम्मीदवार हैं, और प्रति सेकंड 10 प्रयासों पर हमलावर औसत 5,000 प्रयासों — 500 सेकंड — बाद सफल होता है। 10 मिनट की वैधता 600 सेकंड है, इसलिए बिना दोहराव के क्रम से कोशिश करने पर उस खिड़की में 6,000 जाँचे जा सकते हैं। समाप्ति समय अकेले ब्रूट-फोर्स नहीं रोकता। उम्मीदवार-स्थान, प्रयास गति, और प्रयास-संख्या सीमा साथ डिज़ाइन करने पड़ते हैं।

परीक्षा का उपाय खाता लॉक है — क्या व्यवहार में तुरंत लॉक अकेले काफी है?

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

WAF को अवरोध के बजाय पहचान पर सेट करने का मतलब क्या है?

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

क्या इस प्रश्न की लाइब्रेरी H Log4j है?

प्रश्न उत्पाद नाम छिपाता है, पर हमले का क्रम — JNDI Lookup, LDAP सर्वर, HTTP सर्वर से क्लास प्राप्ति, HTTP हेडर में एम्बेड स्ट्रिंग, और उच्च CVSS v3.1 बेस स्कोर — स्वाभाविक रूप से CVE-2021-44228 का अमूर्तन पढ़ता है, जिसे Log4Shell कहते हैं। यह लेख वह संगति समझाता है, पर परीक्षा विशिष्ट उत्पाद नाम बताने की माँग नहीं करती। दिए गए हमला-प्रक्रिया और WAF विनिर्देश से ही उत्तर निकलता है।

इस प्रश्न से व्यवहार में क्या लेकर जाएँ?

यह कि प्रमाणीकरण सफल होना, JWT छेड़छाड़-रहित होना, लक्ष्य ऑब्जेक्ट तक पहुँच की अनुमति, और लक्ष्य गुण बदलने की अनुमति — सब अलग जाँचें हैं। इसके ऊपर छोटे प्रमाणीकरण कोड को प्रयास-दर सीमा चाहिए, और गंभीर लाइब्रेरी भेद्यता पर प्रभाव-पुष्टि, अंतरिम रक्षा, और मूल सुधार समानांतर चलते हैं। व्यावहारिक सार: प्राधिकरण साझा घटकों में समेटें, इनपुट स्कीमा अनुमति-सूची बनाएँ, JWT सत्यापन शर्तें सर्वर-साइड तय करें, और निर्भर लाइब्रेरी का हिसाब रखें ताकि अद्यतन हो सकें।

पंजीकृत सूचना सुरक्षा विशेषज्ञ परीक्षा, वसंत 2024 (रेइवा 6) PM प्रश्न 1 व्याख्या — JWT alg=none, API प्राधिकरण, और अंतरिम WAF न्यूनीकरण

6 Aug 2026 10:00 · Go Komura · पंजीकृत सूचना सुरक्षा विशेषज्ञ, पंजीकृत सुरक्षा विशेषज्ञ, API, API सुरक्षा, JWT, प्रमाणीकरण, प्राधिकरण, WAF, Log4Shell, सूचना सुरक्षा, भेद्यता, IPA

“हम JWT के हस्ताक्षर सत्यापित करते हैं, इसलिए उपयोगकर्ता ID पर भरोसा किया जा सकता है।”

वह कथन केवल आधा सही है।

पंजीकृत सूचना सुरक्षा विशेषज्ञ परीक्षा, वसंत 2024 (रेइवा 6) के PM (अपराह्न) सत्र का प्रश्न 1 एक स्मार्टफ़ोन ऐप से बुलाए जाने वाले API के इर्द-गिर्द बना है।¹ सफल प्रमाणीकरण पर JWT जारी होता है, और वह JWT उपयोगकर्ता जानकारी लाने और अद्यतन करने वाले API की कॉलों से जुड़ता है। पहली नज़र में यह पूरी तरह साधारण व्यवस्था है।

पर आकलन में निम्नलिखित चार समस्याएँ निकलती हैं।

JWT हेडर का alg none करने से बिना हस्ताक्षर वाला JWT पास हो जाता है।
वैध JWT रखते हुए mid किसी और उपयोगकर्ता ID में बदलने से दूसरे की जानकारी पढ़ी या अद्यतन की जा सकती है।
अदस्तावेज़ीकृत status=paid जोड़ने से निःशुल्क-स्तर उपयोगकर्ता भुगतान करने वाला बन जाता है।
ईमेल से आने वाला चार-अंकीय प्रमाणीकरण कोड बिना प्रयास-सीमा के ब्रूट-फोर्स किया जा सकता है।

चारों “प्रमाणीकरण-आसन्न भेद्यताएँ” लगती हैं, पर कारण एक नहीं। टूट रही हैं अलग सीमाएँ: टोकन अखंडता, ऑब्जेक्ट-स्तर प्राधिकरण, गुण-स्तर प्राधिकरण, और प्रयास-दर सीमा।

प्रश्न के उत्तरार्ध में एक और विषय जुड़ता है। व्यापक रूप से प्रयुक्त ओपन-सोर्स लाइब्रेरी में गंभीर भेद्यता प्रकट होती है, जिससे हमलावर JNDI Lookup का दुरुपयोग कर दूर से कोड चला सकता है। न सुधार है, न तैयार WAF नियम। इस बीच प्रश्न पूछता है कि प्रभाव कैसे पुष्टि करें, WAF कहाँ देखे, और प्रारंभिक WAF मोड “अवरोध” के बजाय “पहचान” क्यों हो।

यह लेख आधिकारिक मॉडल उत्तरों² और मूल्यांकन टिप्पणी³ को आधार बनाता है, और प्रत्येक प्रश्न के उत्तर के साथ वह उत्तर क्यों है, और व्यवहार में उसे कितनी सख़्ती से डिज़ाइन करना चाहिए भी निकालता है।

flowchart TB
    accTitle: प्रश्न का अवलोकन
    accDescr: हर चरण पर टूटी विश्वास-सीमा दिखाता है - प्रमाणीकरण कोड, JWT, API प्राधिकरण, और लाइब्रेरी भेद्यता
    user["उपयोगकर्ता ऐप"]
    auth["4-अंकीय प्रमाणीकरण कोड"]
    jwt["JWT जारी करना"]
    api["उपयोगकर्ता API"]
    log["लॉग आउटपुट"]
    vuln["भेद्य लाइब्रेरी"]
    ext["दूरस्थ कोड निष्पादन"]
    user --> auth
    auth -->|प्रयास सीमा नहीं| jwt
    jwt -->|alg=none अनुमति| api
    api -->|mid पर भरोसा| db1["दूसरे उपयोगकर्ता का डेटा पढ़ें/अद्यतन"]
    api -->|status=paid| db2["बिलिंग स्थिति बदलें"]
    api --> log
    log --> vuln
    vuln -->|JNDI/LDAP/HTTP| ext

चित्र 1: प्रश्न का अवलोकन। हर चरण पर अलग विश्वास-सीमा टूटती है।

1. निष्कर्ष पहले

RESTful API का सत्र-स्थिति न रखने का गुण स्टेटलेसनेस कहलाता है। इसका मतलब यह नहीं कि सर्वर कोई डेटाबेस या उपयोगकर्ता स्थिति बिल्कुल नहीं रखता
चार-अंकीय प्रमाणीकरण कोड के 10,000 संभव मान हैं। प्रति सेकंड 10 प्रयासों पर हमलावर औसत 5,000 प्रयासों बाद सफल होता है, यानी 500 सेकंड — 10 मिनट की वैधता से छोटा, इसलिए समाप्ति अकेले नहीं रोकती
alg=none के विरुद्ध न्यूनतम उपाय यह पुष्टि करना है कि JWT हेडर का alg NONE नहीं है। व्यवहार में, फिर भी, अनुमत एल्गोरिद्म का सेट सर्वर-साइड तय करें
वैध JWT होने पर भी अनुरोध का mid भरोसे योग्य नहीं। JWT के अंदर उपयोगकर्ता ID का mid से मिलान करें, या अधिक सुरक्षित रूप से क्लाइंट से mid लें ही नहीं और लक्ष्य JWT से तय करें
status=paid जोड़ना Mass Assignment समस्या है, जहाँ विनिर्देश से बाहर गुण सीधे आंतरिक ऑब्जेक्ट पर बाउंड हो जाते हैं। अद्यतन DTO को अनुमति-सूची बनाएँ, और उपयोगकर्ता को बिलिंग स्थिति न बदलने दें
ब्रूट-फोर्स उपाय का मॉडल उत्तर है वह तर्क जो लगातार विफलताओं की संख्या सीमा पार होते ही खाता लॉक करे। व्यवहार में चरणबद्ध विलंब और प्रति-स्रोत नियंत्रण भी परत करें
नई प्रकट गंभीर भेद्यता का प्रभाव पुष्टि करने के लिए विनाशकारी आदेश के बजाय परीक्षण सर्वर के index.html तक पहुँच दर्ज करें, ताकि दूरस्थ कोड निष्पादन वास्तव में पहुँचे यह पुष्टि हो
हमला-स्ट्रिंग HTTP हेडर में आती है, इसलिए WAF का निरीक्षण लक्ष्य Header है। केस-स्वैप सँभालने वाले रेगुलर एक्सप्रेशन के रूप में \W[jJ][nN][dD][iI]\W जैसा कुछ प्रयोग करें
WAF को “पहचान” मोड में शुरू करने का लाभ है कि यह वैध व्यावसायिक ट्रैफ़िक को मिथ्या सकारात्मक से अवरुद्ध होने से बचाता है। अलर्ट आए तो जाँचें कि वास्तविक हमला है या नहीं, फिर नियम ट्यून होने के बाद अवरोध मोड पर जाएँ
WAF केवल अंतरिम उपाय है; मूल सुधार है प्रभावित लाइब्रेरी को पैच किए संस्करण पर अद्यतन करना

2. परिदृश्य प्रश्नों से कैसे जुड़ता है

परिदृश्य कंपनी G पर है, जो नई स्वास्थ्य सेवा शुरू कर रही है। उपयोगकर्ता स्मार्टफ़ोन ऐप से भोजन और शरीर-भार जैसे डेटा दर्ज करते हैं और स्वास्थ्य-जोखिम आकलन तथा आहार सलाह पाते हैं। सिस्टम क्लाउड पर बना है, API गेटवे, घटना-चालित प्रसंस्करण, और प्रबंधित डेटाबेस मिलाकर।

प्रश्न-पत्र विशिष्ट उत्पाद और सेवा नाम अमूर्त करता है। यह लेख भी IPA के आरेख या पाठ नहीं दोहराता, बल्कि प्रश्नों को समझने के लिए आवश्यक संरचना ही पैराफ़्रेज़ करता है।

प्रश्न	विषय	इस लेख का अध्याय
प्रश्न 1	RESTful API का स्वभाव	अध्याय 4
प्रश्न 2(1)	4-अंकीय कोड ब्रूट-फोर्स का समय	अध्याय 5
प्रश्न 2(2)	JWT `alg=none`	अध्याय 6
प्रश्न 2(3)	`mid` से दूसरे उपयोगकर्ता तक पहुँच	अध्याय 7
प्रश्न 2(4)	विनिर्देश-बाहर `status` स्वीकार करने की कमी	अध्याय 8
प्रश्न 2(5)	ब्रूट-फोर्स उपाय	अध्याय 9
प्रश्न 3(1)	भेद्यता का सुरक्षित अस्तित्व-पुष्टि	अध्याय 11
प्रश्न 3(2)(3)	WAF कहाँ देखता है, और रेगुलर एक्सप्रेशन	अध्याय 12
प्रश्न 3(4)	पहचान मोड का लाभ और संचालन	अध्याय 13

मूल्यांकन टिप्पणी कहती है कि समग्र सही-उत्तर दर औसत के आसपास थी। पर यह भी बताती है कि प्रश्न 2(2) के JWT-छेड़छाड़ उपाय और प्रश्न 3(1) में सत्यापन सर्वर पर आवश्यक तंत्र की सही-उत्तर दर कुछ कम थी। दोनों शब्दावली अकेले से हल नहीं होते। आपको यह ट्रेस करना पड़ता है कि हमलावर ने कौन सा मान बदला, वह किस प्रक्रिया में गया, और अंत में कहाँ भरोसा किया गया।

3. यह केवल एक “प्रमाणीकरण समस्या” नहीं

पूरे प्रश्न को विश्वास-सीमा के अनुसार रखने पर निम्नलिखित मिलता है।

[उपयोगकर्ता ID / पासवर्ड]
          |
          v
[4-अंकीय कोड जाँच] ---- प्रयास सीमा नहीं ----> ब्रूट-फोर्स
          |
          v
[JWT जारी करें]
          |
          v
[JWT लाइब्रेरी] ------- alg=none अनुमति ------> उपयोगकर्ता ID छेड़छाड़
          |
          v
[उपयोगकर्ता API]
    |             |
    |             +-- status पूरा आगे भेजता है ----> गुण-स्तर प्राधिकरण दोष
    |
    +-- mid पर भरोसा -----------------------> ऑब्जेक्ट-स्तर प्राधिकरण दोष

[बाहरी इनपुट लॉग]
          |
          v
[भेद्य लाइब्रेरी] ---- JNDI/LDAP/HTTP ------> दूरस्थ कोड निष्पादन

यहाँ सबसे महत्वपूर्ण भेद निम्नलिखित है।

जाँच	जो प्रश्न पूछती है	इस परिदृश्य में टूटा उदाहरण
प्रमाणीकरण	आप कौन हैं	4-अंकीय कोड का ब्रूट-फोर्स
टोकन सत्यापन	क्या वह पहचान-सूचना छेड़ी गई	`alg=none`
ऑब्जेक्ट-स्तर प्राधिकरण	क्या यह उपयोगकर्ता इस उपयोगकर्ता का डेटा देख सकता है	`mid` बदलना
गुण-स्तर प्राधिकरण	क्या यह फ़ील्ड बदला जा सकता है	`status=paid`
इनपुट-से-निष्पादन सीमा	क्या बाहरी इनपुट आदेश के रूप में व्याख्या हो रहा है	JNDI Lookup

एक जाँच पास करना अगली छोड़ने का कारण कभी नहीं। वैध JWT वाला उपयोगकर्ता किसी और का डेटा पढ़ने का अधिकारी नहीं होता। अपने डेटा अद्यतन करने का अधिकारी उपयोगकर्ता बिलिंग स्थिति भी बदलने का अधिकारी नहीं होता।

इन चरणों को अलग कर पाने पर प्रत्येक प्रश्न का उत्तर रटना नहीं रह जाता।

flowchart LR
    accTitle: प्रमाणीकरण और प्राधिकरण का अंतर
    accDescr: प्रमाणीकरण विषय की पुष्टि करता है, प्राधिकरण पुष्टि करता है कि उस विषय को क्या करने की अनुमति है
    auth["प्रमाणीकरण<br/>आप कौन हैं"]
    authz["प्राधिकरण<br/>आप क्या कर सकते हैं"]
    auth --> authz

चित्र 2: प्रमाणीकरण और प्राधिकरण का अंतर। प्रमाणीकरण पहले आता है; प्राधिकरण अलग जाँच है।

4. प्रश्न 1 — “स्टेटलेस” का अर्थ क्या है

प्रश्न 1 RESTful API के डिज़ाइन सिद्धांतों में से एक पूछता है: सत्र प्रबंधन न करने का गुण।

उत्तर है स्टेटलेस।

स्टेटलेस का मतलब है सर्वर को पिछली रिक्वेस्ट की वार्तालाप-स्थिति याद रखने की ज़रूरत नहीं, क्योंकि प्रत्येक अनुरोध स्वयं प्रसंस्करण के लिए आवश्यक सब कुछ लाता है। इस प्रश्न में स्मार्टफ़ोन ऐप हर अनुरोध पर Authorization हेडर में JWT लगाता है। सर्वर उस JWT को सत्यापित करता है और उसी से उस अनुरोध का उपयोगकर्ता पहचानता है।

एक आम गलत पढ़त है “स्टेटलेस” को “सर्वर कोई स्थिति बिल्कुल नहीं रखता” मानना। वास्तव में वह आमतौर पर निम्नलिखित स्थिति रखता है।

उपयोगकर्ता जानकारी और स्वास्थ्य डेटा संग्रहीत करने वाला डेटाबेस
बिलिंग स्थिति
प्रमाणीकरण कोड का मान, समाप्ति, और विफलता गिनती
JWT हस्ताक्षर कुंजी
निरसन जानकारी, उन डिज़ाइनों में जो निरसन सूची उपयोग करते हैं
लॉग और ऑडिट रिकॉर्ड

जो वह नहीं रखता वह है केवल वार्तालाप जारी रखने के लिए सर्वर-साइड सत्र स्थिति, जिसे प्रत्येक API कॉल की पूर्व शर्त बनाया जाए।

स्टेटलेस होना सुरक्षा स्वतः बेहतर नहीं करता। हर अनुरोध पर JWT भेजना क्षैतिज स्केलिंग आसान करता है, पर JWT सत्यापन गलत हो तो वह त्रुटि हर नोड पर समान रूप से फैलती है। वास्तु गुण और सुरक्षा-सहीपन दो अलग चीज़ें हैं।

5. प्रश्न 2(1) — चार-अंकीय कोड औसत 500 सेकंड में टूटता है

प्रमाणीकरण API उपयोगकर्ता ID और पासवर्ड मिलते ही ईमेल से चार-अंकीय संख्या भेजता है। फिर उपयोगकर्ता ID और चार-अंकीय कोड मिलते ही JWT जारी करता है। कोड निर्माण से 10 मिनट वैध रहता है।

आकलन में प्रति सेकंड 10 प्रयास संभव थे। प्रश्न पूछता है कि तोड़ने में औसत कितने सेकंड लगते हैं।

गणना है “उम्मीदवार-स्थान का आधा”

चार-अंकीय संख्या, अग्रणी शून्य सहित, निम्नलिखित 10,000 संभावनाएँ रखती है।

0000, 0001, 0002, ... , 9999

यदि सही उत्तर एकसमान यादृच्छिक चुना गया हो, बिना दोहराव क्रम से कोशिश करने वाला हमलावर औसत में उम्मीदवार-स्थान के आधे बाद सही तक पहुँचता है।

औसत प्रयास संख्या = 10,000 / 2 = 5,000
औसत समय           = 5,000 / 10 प्रयास प्रति सेकंड = 500 सेकंड

इसलिए रिक्त b है 500।

सबसे खराब स्थिति में 1,000 सेकंड तक लग सकते हैं, पर प्रश्न औसत पूछता है। और कोड की वैधता अवधि 600 सेकंड है — औसत तोड़-समय 500 सेकंड से लंबी। इसीलिए “टूटने की संभावना” माना गया।

flowchart LR
    accTitle: 4-अंकीय प्रमाणीकरण कोड का पैमाना
    accDescr: 10,000 उम्मीदवार 10 प्रति सेकंड पर औसत 5,000 प्रयास और 500 सेकंड, जो 600-सेकंड वैधता से कम है
    A["10,000 उम्मीदवार"] -->|औसत 10,000 / 2 = 5,000 प्रयास| B["औसत तोड़-समय 500 सेकंड"]
    C["वैधता अवधि 600 सेकंड"] -->|500 सेकंड 600 से कम| D["वैधता अवधि में तोड़ा जा सकता है"]

चित्र 9: चार-अंकीय प्रमाणीकरण कोड का पैमाना। औसत में उम्मीदवार-स्थान का आधा आज़माने से वैधता अवधि में टूटता है।

केवल समाप्ति छोटा करने से हार होती है यदि उम्मीदवार-स्थान छोटा हो

प्रमाणीकरण कोड की शक्ति न केवल अंक-संख्या से तय होती है, न केवल वैधता अवधि से।

वैधता अवधि में संभव प्रयासों की संख्या
= प्रति सेकंड प्रयास x वैधता अवधि
= 10 x 600
= 6,000 प्रयास

बिना दोहराव क्रम से मान आज़माने पर हमलावर वैधता अवधि में 10,000 संभावनाओं का 60% जाँच सकता है। समाप्ति समय अकेला पर्याप्त नहीं यदि प्रयासों की संख्या सीमित न हो।

वर्तमान NIST SP 800-63B आउट-ऑफ-बैंड प्रमाणीकरण में प्रयुक्त अल्पकालिक रहस्यों के लिए कम से कम छह अंक माँगता है, और जब रहस्य में 64 बिट से कम एन्ट्रॉपी हो तो प्रयास-दर सीमा अनिवार्य करता है। यह ईमेल को आउट-ऑफ-बैंड प्रमाणीकरण के लिए न उपयोग करने को भी कहता है।⁴ परीक्षा का उत्तर दिए गए चार-अंकीय, ईमेल-भेजे विनिर्देश के भीतर काम करता है, पर व्यवहार में नए डिज़ाइन के लिए वह आधार स्वयं पुनर्विचार योग्य है।

6. प्रश्न 2(2) — `alg=none` “हमलावर को सत्यापन विधि चुनने देना” की समस्या है

इस प्रश्न का JWT तीन भागों से बना है: हेडर, पेलोड, और हस्ताक्षर।

base64url(header).base64url(payload).base64url(signature)

हेडर ने हस्ताक्षर के लिए प्रयुक्त एल्गोरिद्म के रूप में RS256 दर्ज किया। पेलोड में उपयोगकर्ता ID, जारी समय, और समाप्ति है।

आकलक ने निम्नलिखित दो चीज़ें बदलीं।

हेडर का alg RS256 से NONE करें।
पेलोड का उपयोगकर्ता ID किसी और उपयोगकर्ता में बदलें।

वह JWT भेजने पर सत्यापन सफल हुआ और आकलक दूसरे की जगह ले सका।

flowchart LR
    accTitle: JWT alg=none हमले का प्रवाह
    accDescr: वैध JWT में alg को none कर उपयोगकर्ता ID फिर लिखने से अनुरोध पास हो जाता है
    A["वैध JWT<br/>alg=RS256<br/>user=user01"] -->|हेडर alg none करें| B["छेड़ा JWT<br/>alg=none<br/>user=user02"]
    B -->|हस्ताक्षर सत्यापन छोड़ता| C["सर्वर इसे<br/>user02 मानकर स्वीकार करता"]

चित्र 3: JWT alg=none हमले का प्रवाह। हमलावर सत्यापन एल्गोरिद्म चुनता है।

`none` टाइपो नहीं है

RFC 7519 “Unsecured JWT” परिभाषित करता है — बिना हस्ताक्षर और बिना एन्क्रिप्शन का JWT, जिसका alg none है।⁵ इसलिए मान none ऐसा नहीं जो विनिर्देश में बस मौजूद ही न हो।

समस्या यह है कि जो API केवल हस्ताक्षरित JWT स्वीकार करे, उसने हमलावर-निर्दिष्ट none स्वीकार कर लिया।

संकल्पनात्मक रूप से लिखा, भेद्य प्रक्रिया ऐसी दिखती है।

JWT हेडर पढ़ें।
हेडर में लिखा alg देखें, और सत्यापन विधि चुनें।
यदि alg none है, हस्ताक्षर सत्यापित न करें।
पेलोड के उपयोगकर्ता ID पर भरोसा करें।

सुरक्षा की शक्ति स्वयं हमलावर-नियंत्रित इनपुट से चुनी जा रही है।

परीक्षा का उत्तर

प्रश्न पूछता है, प्रत्येक 20 वर्ण या उससे कम में, कि ठीक की गई लाइब्रेरी Q को कौन सा डेटा सत्यापित करना चाहिए, और वह सत्यापन क्या जाँचे।

मॉडल उत्तर निम्नलिखित है।

मद	उत्तर का सार
सत्यापित करने योग्य डेटा	JWT हेडर के `alg` में निर्दिष्ट मान
क्या सत्यापित करें	कि वह `NONE` नहीं है

प्रश्न में वर्णित भेद्यता के सीधे सुधार के रूप में यह सही है।

व्यवहार में “NONE के अलावा कुछ भी” पर न रुकें

यहाँ परीक्षा उत्तर और व्यावहारिक सिफ़ारिश अलग करनी है।

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

खराब दृष्टिकोण:
  स्वीकार करें यदि token.header.alg != "none"

अच्छा दृष्टिकोण:
  केवल तभी स्वीकार करें जब serverConfig.allowedAlgorithms में हो
  उदा. allowedAlgorithms = ["RS256"]

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

JWT सत्यापन को एल्गोरिद्म के अलावा, उपयोग के अनुसार, कम से कम निम्नलिखित भी पुष्टि करनी चाहिए।

मद	क्या पुष्टि करें
हस्ताक्षर	अपेक्षित कुंजी और एल्गोरिद्म से सत्यापित हो सकता है
`iss`	विश्वसनीय जारीकर्ता है
`aud`	टोकन इस API के लिए जारी हुआ
`exp`	वैधता अवधि के भीतर है
`nbf`	“इससे पहले वैध नहीं” समय से पहले नहीं
`sub` या उपयोगकर्ता ID	अनुप्रयोग में वैध विषय है
टोकन प्रकार	ID टोकन को एक्सेस टोकन आदि से उलझा तो नहीं

इस प्रश्न में पेलोड की कुंजी का नाम user है, पर व्यवहार में मानक sub उपयोग करें या कस्टम दावे का अर्थ स्पष्ट परिभाषित करें।

flowchart TB
    accTitle: सुरक्षित बनाम असुरक्षित JWT सत्यापन
    accDescr: असुरक्षित सत्यापन alg पर निर्भर, सुरक्षित सत्यापन सर्वर-साइड अनुमति-सूची उपयोग करता है
    subgraph "असुरक्षित सत्यापन"
        D1["JWT हेडर से alg पढ़ें"]
        D2["alg none हो तो स्वीकार"]
        D1 --> D2
    end
    subgraph "सुरक्षित सत्यापन"
        S1["सर्वर-कॉन्फ़िगर अनुमत एल्गोरिद्म<br/>उदा. RS256"]
        S2["पुष्टि करें JWT हेडर का alg<br/>अनुमति-सूची में है"]
        S3["हस्ताक्षर, iss, aud, exp सत्यापित करें"]
        S1 --> S2 --> S3
    end

चित्र 4: सुरक्षित बनाम असुरक्षित सत्यापन। व्यवहार में अनुमत एल्गोरिद्म का संकीर्ण सेट तय करें।

Base64url एन्क्रिप्शन नहीं है

JWT के बारे में एक और आम ग़लतफ़हमी है। हेडर और पेलोड base64url में निरूपित हैं, पर वह एन्क्रिप्शन नहीं। कोई भी डिकोड कर पढ़ सकता है।

हस्ताक्षर जो गारंटी देता है, और केवल जब सत्यापन सही हो, वह यह है कि जारी होने के बाद सामग्री छेड़ी नहीं गई। इसका मतलब यह नहीं कि गुप्त रखने योग्य व्यक्तिगत जानकारी हस्ताक्षरित JWT के पेलोड में रखी जा सकती है।

7. प्रश्न 2(3) — वैध JWT होने पर भी `mid` बदलने से दूसरे का डेटा पढ़ा गया

अगला हमला JWT स्वयं नहीं छेड़ता।

उपयोगकर्ता API GET या PUT पर mid नामक उपयोगकर्ता ID लेता है। साझा मॉड्यूल P डेटाबेस में उस mid से जुड़ी उपयोगकर्ता जानकारी लाता या अद्यतन करता है।

हमले की संरचना सरल है।

JWT के अंदर उपयोगकर्ता ID: user01    <- सही हस्ताक्षरित JWT
अनुरोध का mid:            user02   <- हमलावर ने बदला

JWT का हस्ताक्षर वैध है, इसलिए प्रमाणीकरण सफल होता है। पर API mid=user02 को दिए अनुसार भरोसा करता है, और user02 की जानकारी लौटाता है।

यह OWASP API Security Top 10 2023 जिस Broken Object Level Authorization (BOLA) को कहता है उसका पाठ्यपुस्तक मामला है। जब भी उपयोगकर्ता-निर्दिष्ट ऑब्जेक्ट ID से डेटा तक पहुँचा जाए, उस विशिष्ट ऑब्जेक्ट का प्राधिकरण हर बार जाँचना चाहिए।⁷

flowchart LR
    accTitle: BOLA हमला
    accDescr: वैध JWT रखते हुए अनुरोध का mid दूसरे उपयोगकर्ता ID में बदलना
    A["हमलावर"] -->|JWT user01<br/>mid user02| B["उपयोगकर्ता API"]
    B -->|mid पर भरोसा| C["DB से user02 का डेटा लौटाता"]

चित्र 5: BOLA हमला। प्रमाणीकरण पास होता है, पर प्राधिकरण कभी जाँचा नहीं गया।

प्रश्न का उत्तर

तालिका 5 की रेखांकन 2, 40 वर्ण या उससे कम में, साझा मॉड्यूल P की कॉल में जोड़ने योग्य प्रसंस्करण पूछती है।

मॉडल उत्तर है:

वह तर्क जो सत्यापित करे कि JWT में निहित उपयोगकर्ता ID mid के मान से मेल खाता है

साझा मॉड्यूल P के अंदर सत्यापन का लाभ यह है कि वही प्राधिकरण जाँच GET और PUT दोनों पर, और भविष्य के किसी API पर जो P उपयोग करे, आसानी से लागू होती है। वही तुलना प्रत्येक स्क्रीन या एंडपॉइंट में अलग कॉपी करने का मतलब है कहीं छूट जाएगी।

अधिक सुरक्षित डिज़ाइन है `mid` लेना ही नहीं

जो API केवल कॉलर की अपनी जानकारी लाता या अद्यतन करता है, उसे क्लाइंट से उपयोगकर्ता ID लेने की ज़रूरत नहीं।

GET /users/me
Authorization: Bearer <JWT>

सर्वर-साइड, विषय सत्यापित JWT से निकाला जाता है।

principal = validateJwt(request.authorization)
userId = principal.subject
return repository.getUser(userId)

अद्यतन पर भी यही लागू।

principal = validateJwt(request.authorization)
input = validateProfileUpdate(request.body)
repository.updateProfile(
    userId = principal.subject,
    name = input.name,
    age = input.age
)

तुलना-जाँच लिखने पर बचाती है। पर जो डिज़ाइन लक्ष्य ID बाहर से लेता ही नहीं उस बग-वर्ग का अस्तित्व ही घटाता है जिसमें तुलना लिखना भूल जाते हैं।

यदि व्यवस्थापक को दूसरे उपयोगकर्ता की जानकारी पर काम करना हो, तो इस तरह बाँटें।

PUT /users/me                  सामान्य उपयोगकर्ताओं के लिए
PUT /admin/users/{userId}      व्यवस्थापकों के लिए

व्यवस्थापक मार्ग पर अलग अनुमति, ऑडिट लॉग, और यदि चाहिए तो पुनः-प्रमाणीकरण माँगें। यह प्राधिकरण नीति की सीमाएँ “सामान्य-उपयोगकर्ता API में केवल व्यवस्थापकों के लिए अपवाद जोड़ें” से कहीं अधिक दिखती हैं।

flowchart LR
    accTitle: BOLA कैसे रोकें
    accDescr: अनुरोध के mid के बजाय JWT के subject से लक्ष्य तय या जाँचें
    A["उपयोगकर्ता"] -->|GET /users/me + JWT| B["API"]
    B -->|JWT से sub लें| C{"यदि mid हो<br/>तो sub से मेल?"}
    C -->|मेल| D["अपना डेटा लौटाएँ"]
    C -->|मेल नहीं| E["403 अस्वीकार"]
    B -->|mid नहीं| F["JWT sub से DB खोज"]

चित्र 6: BOLA कैसे रोकें। mid लें ही नहीं, या JWT के subject से जाँचें।

एक वाक्य में प्रमाणीकरण और प्राधिकरण का भेद

परीक्षा और व्यवहार दोनों में निम्नलिखित वाक्य मदद करता है।

प्रमाणीकरण: आप कौन हैं
प्राधिकरण: वह व्यक्ति क्या कर सकता है

सफल JWT हस्ताक्षर सत्यापन केवल यहाँ तक ले जाता है कि “इस टोकन द्वारा दर्शाया विषय भरोसे योग्य है”। “वह विषय user02 पढ़ सकता है” अलग पुष्टि करनी पड़ती है।

8. प्रश्न 2(4) — `status=paid` गुण-स्तर प्राधिकरण दोष है

उपयोगकर्ता API का विनिर्देश अद्यतन पैरामीटर के रूप में निम्नलिखित परिभाषित करता है।

mid   उपयोगकर्ता ID
name  नाम
age   आयु

पर आकलक ने निम्नलिखित मान जोड़ा, जो विनिर्देश में नहीं है।

status=paid

तब निःशुल्क-स्तर उपयोगकर्ता की स्थिति भुगतान करने वाले की हो गई।

प्रश्न के अनुसार सेवा L ने प्राप्त पैरामीटर सत्यापित नहीं किए; उसने सब सीधे साझा मॉड्यूल P को दे दिए, जो डेटाबेस सीधे अद्यतन कर सके ऐसा बना था।

रिक्त c का उत्तर है साझा मॉड्यूल P।

flowchart TB
    accTitle: Mass Assignment
    accDescr: विनिर्देश-बाहर status=paid जोड़ा जाता है और आंतरिक ऑब्जेक्ट पर पूरा लागू होता है
    A["API विनिर्देश<br/>mid / name / age"] -->|हमलावर status=paid जोड़ता| B["अनुरोध बॉडी"]
    B -->|स्वतः बाउंड| C["साझा मॉड्यूल P"]
    C -->|DB में सहेजा| D["बिलिंग स्थिति paid हुई"]

चित्र 7: Mass Assignment। विनिर्देश-बाहर गुण आंतरिक ऑब्जेक्ट पर पूरा लागू होता है।

BOLA से अंतर

पिछले अध्याय का mid बदलना और यह status जोड़ना समान लगते हैं, पर सुरक्षित की जा रही बारीकी अलग है।

भेद्यता	हमलावर क्या बदलता है	वास्तव में क्या जाँचना चाहिए
`mid` बदलना	लक्ष्य ऑब्जेक्ट	क्या यह उपयोगकर्ता इस उपयोगकर्ता रिकॉर्ड तक पहुँच सकता है
`status` जोड़ना	ऑब्जेक्ट के अंदर गुण	क्या यह उपयोगकर्ता यह फ़ील्ड बदल सकता है

OWASP API Security Top 10 2023 बाद वाले को Broken Object Property Level Authorization मानता है, और जिसे पहले Mass Assignment कहते थे उसे इस श्रेणी में समेटता है।⁸

“JSON को सीधे एंटिटी में डालना” खतरनाक है

भेद्य कार्यान्वयन, संकल्पनात्मक रूप से, ऐसा दिखता है।

entity = repository.find(body.mid)
bindAllProperties(entity, body)
repository.save(entity)

भले स्क्रीन पर केवल name और age के इनपुट हों, हमलावर HTTP अनुरोध सीधे गढ़ सकता है। UI में फ़ील्ड का अभाव सुरक्षा सीमा नहीं है।

सुरक्षित कार्यान्वयन अद्यतन योग्य फ़ील्ड स्पष्ट करता है।

input = parseExactSchema(body, fields = ["name", "age"])

entity = repository.find(authenticatedUserId)
entity.name = input.name
entity.age  = input.age
repository.save(entity)

यहाँ दो बातें मायने रखती हैं।

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

अज्ञात फ़ील्ड चुपचाप नज़रअंदाज़ करना हमले की विफलता छिपाता है, पर क्लाइंट कार्यान्वयन गलतियाँ और हमले के संकेत भी छुपा देता है। जब तक संगतता कारण न हो, सख़्त स्कीमा से अस्वीकार जाँच आसान बनाता है।

flowchart TB
    accTitle: गुण-स्तर प्राधिकरण
    accDescr: अद्यतन DTO केवल अनुमति-सूची रखता है, और अज्ञात गुण अस्वीकृत होते हैं
    subgraph "अद्यतन DTO - अनुमति-सूची"
        D1["name"]
        D2["age"]
    end
    A["अनुरोध बॉडी"] -->|स्कीमा सत्यापन| B{"केवल अनुमत<br/>फ़ील्ड मौजूद"}
    B -->|हाँ| C["एंटिटी name/age अद्यतन"]
    B -->|नहीं| D["त्रुटि लौटाएँ"]
    E["भुगतान सेवा<br/>सत्यापित सूचना"] -->|समर्पित पथ| F["status=paid अद्यतन"]

चित्र 8: गुण-स्तर प्राधिकरण। अद्यतन योग्य फ़ील्ड अनुमति-सूची से सीमित करें, और बिलिंग स्थिति केवल अलग पथ से बदलें।

`status` केवल भुगतान परिणाम से बदले

status=paid उपयोगकर्ता प्रोफ़ाइल का भाग नहीं। यह सर्वर-साइड तथ्य से निकली स्थिति है: कि भुगतान सफल हुआ।

उपयोगकर्ता प्रोफ़ाइल अद्यतन
  -> केवल name / age बदले जा सकते हैं

भुगतान सेवा से सत्यापित सूचना
  -> paymentId मिलाएँ
  -> दोहरी प्रसंस्करण रोकें
  -> status को paid करें

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

9. प्रश्न 2(5) — ब्रूट-फोर्स उपाय विफलता गिनती को स्थिति के रूप में रखते हैं

चार-अंकीय कोड के ब्रूट-फोर्स के लिए तालिका 5 का रिक्त d, 30 वर्ण या उससे कम में, वहाँ का प्रसंस्करण पूछता है। सीमा 10 है।

मॉडल उत्तर है:

वह तर्क जो लगातार विफलताओं की संख्या सीमा पार होते ही खाता लॉक करे

यह प्रश्न 1 के स्टेटलेसनेस से नहीं टकराता। API कॉल की वार्तालाप-स्थिति को सर्वर सत्र के रूप में न रखना, और सुरक्षा निर्णय के लिए आवश्यक विफलता गिनती को स्थायी रखना, दो अलग बातें हैं।

flowchart LR
    accTitle: प्रयास-दर सीमा के साथ और बिना
    accDescr: बिना सीमा कोड औसत 500 सेकंड में टूटता है, पर विफलता-गिनती सीमा हमला बहुत धीमा करती है
    subgraph "बिना सीमा"
        A1["प्रति सेकंड 10 प्रयास"] -->|लगभग 500 सेकंड| B1["प्रमाणीकरण सफल"]
    end
    subgraph "सीमा के साथ"
        A2["10 विफलता पर लॉक"] -->|हमला गति ढहती| B2["खाता लॉक"]
        C2["चरणबद्ध विलंब"] --> B2
    end

चित्र 10: प्रयास-दर सीमा के साथ और बिना। विफलता-गिनती सीमा व्यावहारिक रूप से ब्रूट-फोर्स रोक सकती है।

व्यवहार में केवल स्थायी लॉक पर निर्भर न रहें

प्रति-खाता प्रयास सीमा आवश्यक है, पर यदि हमलावर किसी और का उपयोगकर्ता ID जानता हो, तो वह जान-बूझकर 10 बार विफल होकर वैध उपयोगकर्ता को बाहर कर सकता है। इसलिए व्यवहार में निम्नलिखित मिलाएँ।

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

इसके अलावा, कोड पुनः भेजने पर विफलता गिनती शून्य पर नहीं लौटनी चाहिए — नहीं तो हमलावर पुनः-भेज API हर बार बुलाकर प्रयास-बजट भर सकता है। वर्तमान NIST SP 800-63B भी माँगता है कि नया प्रमाणीकरण रहस्य बनने पर भी विफलता गिनती रीसेट न हो।⁴

प्रमाणीकरण कोड एकबारगी बनाएँ

प्रश्न समाप्ति समय पर केंद्रित है, पर व्यवहार में निम्नलिखित भी चाहिए।

सफल कोड तुरंत अमान्य करें।
उसी कोड का पुनः उपयोग अस्वीकार करें।
कोड स्वयं लॉग में न छोड़ें।
प्रतिक्रिया ऐसी रखें कि कोड-जाँच की सफलता या विफलता से उपयोगकर्ता के अस्तित्व का अनुमान न लगे।
कोड-भेजने वाले API पर भी प्रयास सीमा लगाएँ।

जब तक छोटा रहस्य उपयोग हो, सुरक्षा केवल यादृच्छिक निर्माण पर नहीं छोड़ी जा सकती।

flowchart TB
    accTitle: प्रमाणीकरण कोड के उपाय
    accDescr: अंक-संख्या और समाप्ति से परे प्रयास सीमा, पुनः-उपयोग अस्वीकृति, सूचना आदि से रक्षा
    A["प्रमाणीकरण कोड"] --> B["अंक बढ़ाएँ"]
    A --> C["समाप्ति छोटी करें"]
    A --> D["प्रयास-दर सीमा"]
    A --> E["सफलता के बाद अमान्य"]
    A --> F["पुनः भेजने पर विफलता गिनती रीसेट न करें"]
    A --> G["कोड लॉग में न छोड़ें"]
    A --> H["प्रति-स्रोत नियंत्रण"]

चित्र 11: प्रमाणीकरण कोड के उपाय। अंक-संख्या और समाप्ति को प्रयास नियंत्रण तथा संचालन प्रथाओं से मिलाएँ।

10. प्रश्न 2 के चार भाग एक पृष्ठ पर अलग करें

प्रश्न 2 में आसानी से उलझने वाले बिंदु, हमलावर-नियंत्रित मान के अनुसार।

हमला	हमलावर ने जो मान बदला	जिस पर भरोसा नहीं होना चाहिए था	मूल सुधार
JWT छेड़छाड़	JWT हेडर का `alg`, पेलोड का उपयोगकर्ता ID	टोकन स्वयं द्वारा घोषित सत्यापन एल्गोरिद्म	अनुमत एल्गोरिद्म सर्वर-साइड तय करें
दूसरे उपयोगकर्ता की जानकारी पढ़ना	अनुरोध का `mid`	क्लाइंट-निर्दिष्ट लक्ष्य ID	JWT के subject से मिलाएँ, या लक्ष्य ID JWT से तय करें
भुगतान उपयोगकर्ता में उन्नयन	विनिर्देश-बाहर `status`	सभी स्वतः-बाउंड गुण	अद्यतन योग्य गुण अनुमति-सूची बनाएँ
4-अंकीय कोड तोड़ना	`otp` के उम्मीदवार	असीमित प्रमाणीकरण प्रयास	प्रयास-दर सीमा, विलंब, और जोखिम निर्णय जोड़ें

यह सब “इनपुट सत्यापित करें” में न समेटना महत्वपूर्ण है।

alg क्रिप्टोग्राफ़िक नीति है।
mid ऑब्जेक्ट-स्तर प्राधिकरण है।
status गुण-स्तर प्राधिकरण है।
otp ऑनलाइन अनुमान के विरुद्ध प्रतिरोध है।

एक ही HTTP अनुरोध के अंदर भी प्रत्येक की रक्षा का कारण अलग है।

11. प्रश्न 3(1) — नुकसान किए बिना दूरस्थ कोड निष्पादन पुष्टि करना

सेवा शुरू होने के बाद व्यापक रूप से प्रयुक्त ओपन-सोर्स लाइब्रेरी H में गंभीर भेद्यता V प्रकट होती है। प्रश्न की घटना-क्रम निम्नलिखित है।

हमलावर JNDI Lookup वाली स्ट्रिंग HTTP हेडर में रखकर भेजता है।
लक्ष्य सर्वर उस मान को लॉग करता है।
भेद्य लाइब्रेरी JNDI Lookup का मूल्यांकन कर हमलावर के LDAP सर्वर से पूछती है।
LDAP प्रतिक्रिया हमलावर के HTTP सर्वर का URL लौटाती है।
लक्ष्य सर्वर क्लास फ़ाइल लाता है और आदेश चलाता है।

विशिष्ट उत्पाद नाम छिपा होने पर यह Log4Shell (CVE-2021-44228) प्रकार के हमले के रूप में पढ़ता है। Apache का अपना वर्णन भी भेद्यता को ऐसे बताता है कि यदि हमलावर लॉग संदेश या पैरामीटर नियंत्रित करे, तो LDAP सर्वर से लोड किया गया मनमाना कोड चला सकता है।⁹

flowchart LR
    accTitle: Log4Shell-प्रकार भेद्यता की पुष्टि प्रवाह
    accDescr: अहानिकर कॉलबैक से पुष्टि करें कि JNDI से दूरस्थ कोड निष्पादन तक श्रृंखला वास्तव में चलती है
    A["हमलावर"] -->|jndi/ldap पेलोड<br/>x-api-version में डालें| B["भेद्य सर्वर"]
    B --> C["लॉग प्रसंस्करण"]
    C -->|JNDI Lookup| D["दुर्भावनापूर्ण LDAP सर्वर"]
    D -->|HTTP URL प्रतिक्रिया| E["दुर्भावनापूर्ण HTTP सर्वर<br/>index.html"]
    E -->|GET दर्ज करें| F["परीक्षण सर्वर<br/>एक्सेस लॉग"]
    F -->|पहुँच पुष्टि| G["भेद्यता पुष्ट"]

चित्र 12: Log4Shell-प्रकार भेद्यता की पुष्टि प्रवाह। पहुँच विनाशकारी आदेश से नहीं, HTTP पहुँच दर्ज कर पुष्ट होती है।

सत्यापन कोड केवल अहानिकर HTTP पहुँच चालू करता है

कंपनी G सिस्टम पर प्रभाव न डालने वाला सत्यापन कोड चलाती है, यह पुष्टि करने के लिए कि भेद्यता V बाहर से शोषित हो सकती है। सत्यापन कोड जो एकमात्र आदेश जारी करता है वह परीक्षण सर्वर का index.html लाना है।

प्रश्न 3(1) पूछता है कि आदेश चला यह पुष्टि करने के लिए परीक्षण सर्वर पर क्या लागू करना होगा।

मॉडल उत्तर है:

वह तंत्र जो परीक्षण सर्वर के index.html तक पहुँच दर्ज करे और पुष्टि करने दे

यदि वेब सर्वर के एक्सेस लॉग में लक्ष्य सर्वर से GET दर्ज हो, तो कम से कम निम्नलिखित श्रृंखला चली यह पुष्टि होती है।

बाहरी HTTP अनुरोध
  -> लॉग प्रसंस्करण
  -> JNDI Lookup
  -> LDAP प्रतिक्रिया
  -> क्लास प्राप्ति
  -> सत्यापन आदेश निष्पादन
  -> परीक्षण सर्वर तक HTTP पहुँच

“स्क्रीन पर पाठ दिखाना” पर्याप्त क्यों नहीं

हमले का लक्ष्य सर्वर है। उपयोगकर्ता के ब्राउज़र स्क्रीन पर कुछ बदले इसकी गारंटी नहीं। साथ ही, भेद्यता मौजूद होने पर भी बीच की आउटबाउंड संचार फ़ायरवॉल से रुक सकती है।

परीक्षण सर्वर पक्ष पर पहुँच दर्ज करना यह देखने योग्य साक्ष्य देता है कि लक्ष्य सर्वर वास्तव में बाहर पहुँचा।

व्यवहार में इस प्रकार का सत्यापन करते समय हमेशा निम्नलिखित पालें।

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

“मनमाना कोड निष्पादन संभव है यह पुष्टि करना” और “मनमाना खतरनाक कोड चलाना” एक नहीं। दुष्प्रभाव लक्ष्य पूरा करने के लिए आवश्यक न्यूनतम रखें।

12. प्रश्न 3(2)(3) — WAF HTTP हेडर निरीक्षित करता है

सेवा N का WAF निरीक्षण लक्ष्य के रूप में GET, POST, PUT, ANY, Header, COOKIE, या Multipart चुनने देता है।

हमला-कोड x-api-version नामक HTTP हेडर के मान में जाता है। इसलिए तालिका 6 के रिक्त e और f दोनों Header हैं।

पाठ में दिया स्थान सीधे WAF के निरीक्षण लक्ष्य से मिलाएँ

यह सामान्य ज्ञान से कम और प्रश्न-पाठ के डेटा प्रवाह पढ़ने से अधिक है।

हमला-स्ट्रिंग कहाँ रखी गई:
  x-api-version हेडर
          |
          v
WAF का निरीक्षण लक्ष्य:
  Header

यह न GET पैरामीटर है, न POST बॉडी। WAF की सुविधा-सूची देखकर “हमला जैसा लगता है इसलिए ANY” चुनने के बजाय उस स्थान से उत्तर दें जहाँ प्रश्न-पाठ कहता है हमलावर ने मान रखा।

केस-स्वैप सँभालना

पहला प्रस्ताव, संकल्पनात्मक रूप से, निम्नलिखित नियम था।

Header  \Wjndi\W  अवरोध
Header  \Wldap\W  अवरोध

पर jNdI जैसा केस बदलना केवल छोटे अक्षरों से मेल खाने वाले पैटर्न से बच जाता है।

प्रश्न 3(3) का मॉडल उत्तर निम्नलिखित में से कोई एक है।

\W[jJ][nN][dD][iI]\W

\W(j|J)(n|N)(d|D)(i|I)\W

प्रश्न पुस्तिका में बैकस्लैश जापानी-लोकेल ग्लिफ़ में येन चिह्न जैसा दिख सकता है, पर रेगुलर एक्सप्रेशन के रूप में वह \W है। \W अक्षरांकीय और अंडरस्कोर के अलावा किसी भी वर्ण से मेल खाता है। JNDI Lookup वाक्यविन्यास में jndi के ठीक पहले और बाद ${ और : जैसे गैर-शब्द वर्ण आते हैं, और पैटर्न उन्हें भी पकड़ने के लिए लिखा है।

वही विचार ldap पक्ष को भी केस-असंवेदनशील बनाने पर लागू हो सकता है।

\W[lL][dD][aA][pP]\W

इस रेगेक्स को “पूर्ण Log4Shell उपाय” न मानें

परीक्षा उस रेगुलर एक्सप्रेशन की माँग करती है जो प्रश्न-पाठ में दिखाई बचाव-तकनीक सँभाले। वास्तविक हमलों में स्ट्रिंग विभाजन, वैकल्पिक Lookup, एन्कोडिंग, अन्य प्रोटोकॉल, और अन्य विविधताएँ हो सकती हैं जिन्हें हस्ताक्षर अकेले कवर करना कठिन है।

इसलिए व्यावहारिक स्थान निम्नलिखित है।

वर्तमान ज्ञात हमला-पैटर्न WAF से अंतरिम रूप से अवरुद्ध करें।
जाँचें कि प्रभावित लाइब्रेरी वास्तव में मौजूद है।
आउटबाउंड LDAP, RMI, और अनावश्यक HTTP ट्रैफ़िक सीमित करें।
पैच किए संस्करण पर अद्यतन करें।
अद्यतन के बाद भी लॉग देखें और जाँचें कि उल्लंघन हुआ या नहीं।

WAF वह परत है जो पैच संस्करण उपलब्ध होने तक समय खरीदती है।

flowchart TB
    accTitle: WAF कहाँ बैठता है
    accDescr: WAF अंतरिम न्यूनीकरण परत है, मूल सुधार लाइब्रेरी को पैच संस्करण पर अद्यतन करना है
    A["गंभीर भेद्यता प्रकट"] --> B["प्रभाव पुष्टि"]
    B --> C["अंतरिम न्यूनीकरण"]
    C -->|WAF नियम<br/>पहचान/अवरोध| D["हमला-पैटर्न अस्थायी रोकें"]
    C -->|आउटबाउंड ट्रैफ़िक सीमित| E["दुरुपयोग मार्ग बंद करें"]
    D --> F["पैच लाइब्रेरी पर अद्यतन"]
    E --> F
    F --> G["पश्चात समीक्षा और रोकथाम"]

चित्र 13: WAF कहाँ बैठता है। WAF केवल पैच आने तक समय खरीदता है; मूल सुधार अद्यतन है।

13. प्रश्न 3(4) — “पहचान” से क्यों शुरू करें

अद्यतन WAF नियम के लिए Z, एक पंजीकृत सुरक्षा विशेषज्ञ, उत्पादन में जाने के बाद निश्चित अवधि तक मोड “अवरोध” के बजाय “पहचान” रखने की सलाह देता है।

प्रश्न पूछता है, प्रत्येक 25 वर्ण या उससे कम में, पहचान मोड का लाभ और क्षति न्यूनतम करने के लिए क्या करना चाहिए।

मॉडल उत्तर है:

मद	उत्तर का सार
लाभ	मिथ्या सकारात्मक से होने वाला अवरोध रोक सकता है
क्या करें	अलर्ट मिलते ही जाँचें कि हमला है या नहीं

पहचान मोड “कुछ न करने” का मोड नहीं

पहचान मोड में नियम से मेल खाने वाला ट्रैफ़िक फिर भी गुजरता है, पर लॉग होता है और अलर्ट उठता है। यदि वैध API कॉल के अंदर संयोग से jndi या ldap आए, तो व्यवसाय तुरंत नहीं रुकता।

बदले में संचालन पक्ष को निम्नलिखित करना होता है।

अलर्ट प्राप्त
   |
   v
संबंधित अनुरोध जाँचें
   |
   +-- वैध ट्रैफ़िक -> नियम संकीर्ण करें, अपवाद सोचें
   |
   +-- हमला        -> लक्ष्य अलग करें, लॉग सुरक्षित करें, प्रभाव जाँचें, अवरोध पर जाएँ

यदि अलर्ट कोई न देखे, पहचान मोड का कोई रक्षा-प्रभाव नहीं। पहचान केवल अवलोकन और निर्णय वाले संचालन प्रक्रिया के साथ काम करती है।

पहचान से अवरोध तक का पथ

एक सामान्य रोलआउट प्रक्रिया निम्नलिखित है।

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

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

flowchart LR
    accTitle: WAF पहचान मोड से अवरोध मोड तक
    accDescr: पहचान मोड में अलर्ट देखें, मिथ्या सकारात्मक ट्यून करें, फिर अवरोध मोड पर जाएँ
    A["पहचान मोड"] -->|वास्तविक ट्रैफ़िक| B["अलर्ट उठा"]
    B --> C{"हमला या<br/>मिथ्या सकारात्मक"}
    C -->|मिथ्या सकारात्मक| D["नियम ट्यून करें"]
    D --> A
    C -->|हमला| E["अवरोध मोड पर जाएँ"]
    E --> F["अवरोध संख्या और व्यावसायिक प्रभाव मॉनिटर"]

चित्र 14: पहचान से अवरोध तक। पहले देखें और ट्यून करें, प्रभाव स्वीकार्य पुष्टि करें, फिर अवरोध पर जाएँ।

14. WAF अंतरिम उपाय है; अद्यतन मूल सुधार है

प्रश्न में लाइब्रेरी H की आधिकारिक साइट पर न सुधार था न अंतरिम उपाय, और क्लाउड प्रदाता का व्यापक WAF नियम भी 72 घंटे तक ले सकता था। इसलिए कंपनी G प्रभाव स्वयं पुष्टि करती है और कम से कम पहले से पहचाने पैटर्न अस्थायी रूप से अवरुद्ध करती है।

यह क्रम घटना-प्रतिक्रिया का मूल आकार है।

चरण	उद्देश्य	इस प्रश्न में प्रतिक्रिया
प्रभाव पुष्टि	निर्णय कि अपना संगठन वास्तव में जोखिम में है	अहानिकर कॉलबैक से बाहर से शोषणीयता पुष्टि
अंतरिम न्यूनीकरण	सुधार आने तक समय खरीदना	WAF नियम, पहचान/अवरोध, आउटबाउंड ट्रैफ़िक सीमा
मूल सुधार	भेद्य कारण हटाना	पैच लाइब्रेरी पर अद्यतन
पश्चात समीक्षा	जाँच कि पहले से शोषित तो नहीं	WAF, अनुप्रयोग, DNS, प्रॉक्सी आदि लॉग जाँच
पुनरावृत्ति रोकथाम	अगला निर्णय तेज़ करना	निर्भरता सूची, SBOM, अद्यतन प्रक्रिया, संपर्क मार्ग

“हम नहीं जानते कि उपयोग करते हैं या नहीं” सबसे बड़ा विलंब-स्रोत है

प्रश्न में, जब कंपनी G कंपनी F से पूछती है कि लाइब्रेरी H उपयोग होती है या नहीं, उत्तर समय लेता है क्योंकि विस्तृत कॉन्फ़िगरेशन विश्लेषण चाहिए।

व्यवहार में, यदि गंभीर भेद्यता प्रकट होने के बाद ही JAR फ़ाइलें खोजना शुरू करें, प्रतिक्रिया देर होती है। शांतिकाल में कम से कम निम्नलिखित होने चाहिए।

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

SBOM स्वयं लक्ष्य नहीं। वह यह उत्तर देने का सूचकांक है, कम समय में, कि “यह भेद्यता किन चलते सिस्टम को प्रभावित करती है”।

अद्यतन करने के बाद जाँच बंद न करें

भेद्यता प्रकट होने के आसपास आप पहले से हमला झेल चुके हो सकते हैं। पैच संस्करण पर अद्यतन भविष्य का शोषण रोकता है, पर पहले से समझौता क्रेडेंशियल या पहले से लगा बैकडोर मिटाता नहीं।

Log4Shell-प्रकार भेद्यता के लिए कम से कम निम्नलिखित कोण जाँचें।

JNDI या LDAP संकेत देने वाली संदिग्ध स्ट्रिंग वाले HTTP अनुरोध।
अनुप्रयोग सर्वर से बाहरी LDAP, RMI, या HTTP तक संचार।
असामान्य चाइल्ड प्रोसेस चालू होना।
संदिग्ध JAR, क्लास, स्क्रिप्ट, या एक्ज़ीक्यूटेबल बनना।
क्लाउड क्रेडेंशियल या पर्यावरण चर तक पहुँच।
अद्यतन के आसपास प्रमाणीकरण, अनुमति परिवर्तन, और आउटबाउंड स्थानांतरण।

केवल WAF लॉग से “हमला नहीं हुआ” निष्कर्ष निकालना महत्वपूर्ण नहीं। आंतरिक पथ हैं जो WAF से कभी नहीं गुजरते, और लॉग जो अतीत में रखे नहीं गए।

15. परीक्षा में अंक आसान बनाने वाली पढ़त

यह प्रश्न ज्ञान-परीक्षा से कम और विनिर्देश तथा कार्यान्वयन के अंतर पढ़ने का अभ्यास अधिक है।

15.1 तालिकाओं में “विनिर्देश” और “कार्यान्वयन” अलग करें

status मुद्दे में API विनिर्देश से अनुपस्थित मान कार्यान्वयन में निकल जाता है।

विनिर्देश:
  mid / name / age

कार्यान्वयन:
  प्राप्त सभी पैरामीटर P को भेजें

यह अंतर दिखते ही स्पष्ट होता है कि रिक्त c साझा मॉड्यूल P है।

15.2 हमलावर द्वारा बदले मान के नीचे रेखा खींचें

प्रत्येक हमले में बदला मान निम्नलिखित है।

JWT हेडर का alg
JWT पेलोड का उपयोगकर्ता ID
API पैरामीटर mid
विनिर्देश-बाहर status
प्रमाणीकरण API का otp
HTTP हेडर x-api-version

लगभग हर प्रश्न पूछता है “वह मान कहाँ सत्यापित होना चाहिए”।

15.3 उत्तर को प्रश्न-पाठ के अपने शब्दों पर लाएँ

व्यवहार में इन्हें “BOLA”, “Mass Assignment”, और “rate limiting” कह सकते हैं। पर प्रश्न जो माँगता है वह प्रश्न-पाठ की संरचना से मेल खाता ठोस प्रसंस्करण है।

खराब उदाहरण:

प्राधिकरण उचित रूप से करें।

अच्छा उदाहरण:

सत्यापित करें कि JWT में निहित उपयोगकर्ता ID mid के मान से मेल खाता है।

खराब उदाहरण:

ब्रूट-फोर्स उपाय करें।

अच्छा उदाहरण:

लगातार विफलताओं की संख्या सीमा पार होते ही खाता लॉक करें।

अमूर्त नाम जानना अकेले वर्ण-सीमा में अंक मिलने योग्य उत्तर नहीं देता।

15.4 WAF के लिए “कहाँ रखा गया” ट्रेस करें

WAF का निरीक्षण लक्ष्य हमले के प्रकार से अनुमान नहीं, हमला-स्ट्रिंग कहाँ रखी गई उससे तय होता है।

x-api-version हेडर में रखा
        ↓
निरीक्षण लक्ष्य Header है

मूल्यांकन टिप्पणी का यह नोट कि प्रश्न 3(1) की सही-उत्तर दर कुछ कम थी, इसलिए भी है कि कई उत्तर चित्र 6 के हमला-प्रवाह से नहीं मिले। हमला-क्रम को तीरों से फिर खींचना ही दिखा देता है कि क्या देखना चाहिए।

16. वास्तविक API समीक्षाओं की जाँच-सूची

इस प्रश्न को वास्तविक डिज़ाइन और कोड समीक्षा में ले जाने की जाँच-सूची।

JWT सत्यापन

अनुमत हस्ताक्षर एल्गोरिद्म सर्वर कॉन्फ़िगरेशन में तय है।
none और अप्रत्याशित एल्गोरिद्म अस्वीकृत हैं।
हस्ताक्षर, iss, aud, exp, और nbf उपयोग के अनुसार सत्यापित होते हैं।
ID टोकन, एक्सेस टोकन, और रिफ़्रेश टोकन एक-दूसरे से उलझते नहीं।
कुंजी घुमाव और निरसन की प्रक्रिया है।
गोपनीय रहनी चाहिए जानकारी JWT पेलोड में नहीं डाली जाती।

ऑब्जेक्ट-स्तर प्राधिकरण

अनुरोध के अंदर ID बदलने से दूसरे उपयोगकर्ता के डेटा तक नहीं पहुँचा जा सकता।
प्राधिकरण सूची, विवरण, अद्यतन, हटाने, और डाउनलोड सभी पर लागू है।
प्राधिकरण स्क्रीन में नहीं, डेटा तक पहुँचने वाली साझा परत में लागू है।
केवल-स्वयं API के लिए लक्ष्य ID टोकन से निकालने पर विचार किया।
व्यवस्थापक संचालन सामान्य-उपयोगकर्ता API से अलग नीति उपयोग करते हैं।

गुण-स्तर प्राधिकरण

बाहरी इनपुट प्रकार और डेटाबेस एंटिटी अलग रखे गए हैं।
अद्यतन योग्य फ़ील्ड अनुमति-सूची के रूप में गिने गए हैं।
विनिर्देश-बाहर गुण अस्वीकृत या ऑडिट होते हैं।
अनुमति, बिलिंग, अनुमोदन, और स्वामित्व जैसी स्थिति उपयोगकर्ता इनपुट से नहीं बदल सकती।
प्रतिक्रियाएँ भी अनावश्यक गोपनीय गुण छोड़ती हैं।

प्रमाणीकरण प्रयास

प्रति-खाता विफलता-गिनती सीमा है।
चरणबद्ध विलंब और प्रति-स्रोत नियंत्रण है।
कोड पुनः जारी करने पर विफलता गिनती रीसेट नहीं होती।
प्रमाणीकरण कोड केवल एक बार उपयोग हो सकता है।
प्रमाणीकरण कोड और पासवर्ड लॉग में नहीं रहते।
अनलॉक/पुनर्प्राप्ति प्रक्रिया स्वयं कमज़ोर प्रमाणीकरण मार्ग नहीं है।

निर्भर लाइब्रेरी में गंभीर भेद्यताएँ

चलती सेवाएँ अपनी निर्भरता-संस्करणों से मैप हो सकती हैं।
अहानिकर विधि से प्रभाव सत्यापित करने की प्रक्रिया है।
WAF नियम और आउटबाउंड सीमा जैसे अंतरिम उपाय लागू हो सकते हैं।
जिम्मेदार व्यक्ति पहचान अलर्ट समीक्षा करने की संचालन प्रक्रिया है।
पैच संस्करण पर अद्यतन का आपात रिलीज़ मार्ग है।
अद्यतन से पहले संभावित शोषण के लिए लॉग जाँचे जाते हैं।

17. साझा घटकों के दो चेहरे, जैसे इस प्रश्न से दिखते हैं

इस प्रश्न में दो साझा घटक हैं: JWT प्रबंधन लाइब्रेरी Q और साझा मॉड्यूल P।

साझा घटकों के बड़े लाभ हैं।

एक जगह सुधार हर API तक फैलता है जो उसे उपयोग करे।
प्राधिकरण और सत्यापन तर्क प्रत्येक सुविधा में दोहराने नहीं पड़ते।
परीक्षण लक्ष्य समेटे जा सकते हैं।
लॉग और ऑडिट प्रारूप एक किए जा सकते हैं।

दूसरी ओर, गलतियाँ भी पूरे सिस्टम में फैलती हैं।

यदि लाइब्रेरी Q alg=none स्वीकार करे, JWT उपयोग करने वाला हर API भेद्य हो जाता है।
यदि साझा मॉड्यूल P मनमाना mid या status स्वीकार करे, GET और PUT दोनों भेद्य हो जाते हैं।
यदि भेद्य लाइब्रेरी H आधार में उपयोग हो, HTTP हेडर लॉग करने वाला हर मार्ग हमला-सतह का भाग बनता है।

इसलिए साझा होना चाहिए केवल डेटा पहुँच नहीं। सुरक्षा इन्वेरिएंट स्वयं साझा करने चाहिए, और उस साझा घटक को अलग से कठोर सत्यापित करना चाहिए।

उदाहरण के लिए, P का अनुबंध इस तरह बनाएँ।

P.getOwnUser(authenticatedSubject)
P.updateOwnProfile(authenticatedSubject, ProfileUpdate{name, age})

निम्नलिखित जैसी निम्न-स्तरीय API सामान्य कॉलर को सीधे न दिखाना अधिक सुरक्षित है।

P.getUser(arbitraryMid)
P.updateUser(arbitraryMap)

बाद वाला केवल सीमित मार्गों को चाहिए, जैसे प्रशासनिक प्रसंस्करण। वह निम्न-स्तरीय स्वतंत्रता हर API को देने से ऐसा डिज़ाइन बनता है जो हर कॉलर के हर बार सही उपयोग पर निर्भर करता है।

18. सारांश

वसंत 2024 (रेइवा 6) PM प्रश्न 1 वह प्रश्न है जो API सुरक्षा के विषयों को एक-एक कर अलग पढ़ता है।

JWT उपयोग करना प्रमाणीकरण सुरक्षित होना नहीं है। हमलावर को हस्ताक्षर एल्गोरिद्म चुनने देना उपयोगकर्ता ID फिर लिखने देता है।

वैध JWT हस्ताक्षर प्राधिकरण सही होना नहीं है। अनुरोध के mid पर भरोसा वैध उपयोगकर्ता को किसी और की जानकारी तक पहुँचने देता है।

अपना ऑब्जेक्ट अद्यतन कर पाना हर गुण बदलने की अनुमति नहीं है। status जैसी आंतरिक स्थिति स्वतः बाउंड करना अनुमति या बिलिंग स्थिति फिर लिखने देता है।

प्रमाणीकरण कोड पर समाप्ति होना ब्रूट-फोर्स प्रतिरोध नहीं है। उम्मीदवार-स्थान और प्रयास गति गिननी पड़ती है, और विफलताओं की संख्या सीमित करनी पड़ती है।

WAF में नियम डालना भेद्यता ठीक होना नहीं है। पहचान और अवरोध केवल समय खरीदते हैं; प्रभाव पुष्टि करते हैं और अंत में लाइब्रेरी अद्यतन करते हैं।

flowchart TB
    accTitle: भेद्यताओं का उपायों से मानचित्र
    accDescr: प्रत्येक भेद्यता को उसकी विश्वास-सीमा और उपाय से जोड़ता है
    A["JWT छेड़छाड़"] -->|टोकन सत्यापन| B["अनुमत एल्गोरिद्म तय करें"]
    C["mid बदलना"] -->|ऑब्जेक्ट-स्तर प्राधिकरण| D["JWT subject से मिलाएँ/mid अनावश्यक"]
    E["status=paid"] -->|गुण-स्तर प्राधिकरण| F["अद्यतन DTO अनुमति-सूची बनाएँ"]
    G["4-अंकीय कोड ब्रूट-फोर्स"] -->|प्रमाणीकरण प्रयास नियंत्रण| H["विफलता सीमा/विलंब"]
    I["Log4Shell-प्रकार भेद्यता"] -->|इनपुट से निष्पादन| J["लाइब्रेरी अद्यतन/WAF"]

चित्र 15: भेद्यताओं का उपायों से मानचित्र। जो सीमा टूटी उसी के अनुसार सुधार अलग करें।

पूरे प्रश्न में एक सिद्धांत चलता है।

पिछली जाँच की सफलता को अगली विश्वास-सीमा छोड़ने का कारण कभी न बनने दें।

इस श्रृंखला के पहले लेख शरद 2023 (रेइवा 5) PM प्रश्न 1 की संग्रहीत XSS भेद्यता और शरद 2023 (रेइवा 5) PM प्रश्न 2 में अतिथि Wi-Fi से डेटा निकालना कवर करते हैं। पूरे वेबसाइट पर क्या जाँचना है, इसके लिए IPA की “How to Secure Your Website” को जाँच-सूची के रूप में उपयोग भी देखें।

flowchart TB
    accTitle: अंतिम सारांश
    accDescr: दिखाता है कि पिछली जाँच की सफलता अगली विश्वास-सीमा छोड़ने का कारण कभी नहीं
    A["प्रमाणीकरण सफल"] --> B["JWT हस्ताक्षर सत्यापन"]
    B --> C["ऑब्जेक्ट-स्तर प्राधिकरण"]
    C --> D["गुण-स्तर प्राधिकरण"]
    D --> E["प्रयास-दर सीमा"]
    E --> F["इनपुट-से-निष्पादन सीमा"]
    F --> G["WAF/लाइब्रेरी अद्यतन"]

चित्र 16: अंतिम सारांश। विश्वास-सीमाएँ चरणों में जाँची जाती हैं, और कोई नहीं छोड़ी जा सकती।

संदर्भ लिंक

IPA, Spring 2024 (Reiwa 6) Registered Information Security Specialist Examination, PM Question Booklet. वह प्रश्न-पाठ जिस पर यह लेख आधारित है। ↩
IPA, Spring 2024 (Reiwa 6) Registered Information Security Specialist Examination, PM Model Answers. प्रत्येक प्रश्न का आधिकारिक मॉडल उत्तर। ↩
IPA, Spring 2024 (Reiwa 6) Registered Information Security Specialist Examination, PM Grading Commentary. सही-उत्तर दरों और आम गलतियों की व्याख्या। ↩
NIST, SP 800-63B: Authentication and Authenticator Management. अल्पकालिक रहस्यों की अंक-संख्या, प्रयास-दर सीमा, पुनः-जारी पर विफलता गिनती, और आउट-ऑफ-बैंड प्रमाणीकरण के लिए ईमेल न उपयोग करना आदि निर्धारित करता है। ↩ ↩²
RFC Editor, RFC 7519: JSON Web Token (JWT). JWT का विनिर्देश, Unsecured JWT और alg=none सहित। ↩
RFC Editor, RFC 8725: JSON Web Token Best Current Practices. वह BCP जो अनुमत एल्गोरिद्म सेट तय करना, तथा जारीकर्ता, विषय, और audience सत्यापित करना आदि प्रथाएँ निर्धारित करता है। ↩
OWASP, API1:2023 Broken Object Level Authorization. उपयोगकर्ता-निर्दिष्ट प्रत्येक ऑब्जेक्ट ID के लिए प्राधिकरण जाँचने की आवश्यकता समझाता है। ↩
OWASP, API3:2023 Broken Object Property Level Authorization. Mass Assignment सहित गुण-स्तर प्राधिकरण दोष और उनके उपाय समझाता है। ↩
Apache Logging Services, Security. CVE-2021-44228 का प्रभाव, JNDI और LDAP से कोड निष्पादन, और ठीक किए संस्करण समझाता है। ↩

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

Windows वर्चुअलाइज़ेशन की गहराई (भाग 3) — सेकंडों में बूट होने वाली वर्चुअल मशीनें: WSL2, Windows Sandbox और कंटेनर इतने हल्के क्यों हैं

WSL2 और Windows Sandbox सेकंडों में शुरू होकर इतने हल्के क्यों लगते हैं? यह लेख डायनामिक बेस इमेज और डायरेक्ट मैप से डायनामिक मेमोरी आवंट...

लेख पढ़ें

Windows वर्चुअलाइज़ेशन की गहराई (भाग 2) — वह मेमोरी जिसे कर्नेल भी नहीं देख सकता: VBS, HVCI और Credential Guard कैसे काम करते हैं

संगत हार्डवेयर पर क्लीन इंस्टॉल पर VBS डिफ़ॉल्ट से सक्षम होता है और हाइपरवाइज़र तथा SLAT से कर्नेल से मज़बूत अलगाव बनाता है। यह लेख VTL, ...

लेख पढ़ें

Windows वर्चुअलाइज़ेशन की गहराई (भाग 1) — आपका Windows वास्तव में कहाँ चल रहा है? हाइपरवाइज़र और पार्टीशन

जब आप Hyper-V सक्षम करते हैं, तो होस्ट Windows स्वयं रूट पार्टीशन के रूप में हाइपरवाइज़र के ऊपर चलता है। यह लेख VT-x, SLAT और VMBus की भू...

लेख पढ़ें

Win32 Thread Pool API — CreateThreadpoolWork से थ्रेड बनाए बिना समवर्तिता

क्या आपके नेटिव कोड में CreateThread कॉल बिखरी पड़ी हैं? यह लेख Vista में पुनर्डिज़ाइन की गई Win32 थ्रेड पूल API — work, timer, wait और i...

लेख पढ़ें

Named Pipes व्यवहार में — डिज़ाइन से सुरक्षा तक, Windows की मानक IPC

Named pipes — Windows की मानक इंटर-प्रोसेस कम्युनिकेशन — की व्यावहारिक मार्गदर्शिका। यह लेख प्राथमिक स्रोतों से बाइट और मैसेज मोड का चुना...

लेख पढ़ें

इस विषय से जुड़ी सेवाएँ

यह लेख निम्नलिखित सेवाओं से सीधे जुड़ा है।

वेबसाइट विकास

क्योंकि सदस्य API और स्मार्टफ़ोन एकीकरण में JWT सत्यापन, ऑब्जेक्ट-स्तर प्राधिकरण, और अद्यतन योग्य गुणों का प्रतिबंध सीधे वेब सिस्टम की सुरक्षा से जुड़ते हैं।

सेवा देखें संपर्क करें

तकनीकी परामर्श और डिज़ाइन समीक्षा

क्योंकि मौजूदा API में प्राधिकरण अंतराल पहचानना, निर्भर लाइब्रेरी का प्रभाव-क्षेत्र आँकना, और डिज़ाइन समीक्षा से अंतरिम WAF नियम निकालना — सब तकनीकी परामर्श के दायरे में आता है।

सेवा देखें संपर्क करें

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

JWT हस्ताक्षर सत्यापन सफल होने पर भी हमलावर दूसरे की जगह कैसे ले सकता है?: इस प्रश्न में JWT प्रबंधन लाइब्रेरी ने JWT हेडर के alg को हमलावर द्वारा निर्दिष्ट रूप में ही स्वीकार किया, और alg=none वाले JWT को बिना किसी हस्ताक्षर के वैध माना। इसलिए पेलोड का उपयोगकर्ता ID फिर से लिखने पर भी सत्यापन पास हो जाता है। परीक्षा का उत्तर है JWT हेडर के alg की जाँच करना और पुष्टि करना कि उसका मान NONE नहीं है। व्यवहार में, केवल NONE अस्वीकार करना पर्याप्त नहीं। सर्वर-साइड कॉन्फ़िगरेशन में उपयोग के लिए अनुमत एल्गोरिद्म — उदाहरण के लिए RS256 — तय करें, ताकि टोकन जो एल्गोरिद्म घोषित करे उसे चुनाव के लिए सीधे न लिया जाए। उपयोग के अनुसार issuer, audience, समाप्ति, subject आदि भी सत्यापित करें।
JWT के अंदर उपयोगकर्ता ID की तुलना अनुरोध के mid से करना प्राधिकरण उपाय के रूप में काफी है?: इस परीक्षा के उत्तर के लिए काफी है। साझा मॉड्यूल P के अंदर यह सत्यापित करना कि JWT में निहित उपयोगकर्ता ID mid से मेल खाता है, किसी और का mid निर्दिष्ट करने वाले हमले को रोकता है। लेकिन जो API केवल कॉलर की अपनी जानकारी सँभालता है, व्यवहार में क्लाइंट से mid बिल्कुल न लेना, और सत्यापित JWT के subject से उपयोगकर्ता ID तय करना अधिक सुरक्षित है। GET /users/me या PUT /users/me जैसे पथ तुलना-तर्क के छूट जाने को कठिन बनाते हैं। जिस API पर व्यवस्थापक दूसरे उपयोगकर्ता पर काम करे, उसे अलग एंडपॉइंट और अपनी प्राधिकरण नीति में बाँटें।
सामान्य इनपुट सत्यापन अकेले status जोड़ने वाले हमले को क्यों नहीं रोक सकता?: क्योंकि name की लंबाई या age की सीमा जाँचने से कुछ नहीं होता यदि status — एक फ़ील्ड जिसे पहले स्थान पर स्वीकार ही नहीं करना चाहिए था — स्वतः बाउंड होकर आंतरिक ऑब्जेक्ट तक चला जाता है। समस्या मान का प्रारूप नहीं; गुण-स्तर प्राधिकरण है, यानी उपयोगकर्ता को वह गुण बदलने की अनुमति है भी या नहीं। अद्यतन इनपुट प्रकार में केवल name और age परिभाषित करें, और अज्ञात गुण अस्वीकार करें। बिलिंग स्थिति केवल सर्वर-विश्वसनीय घटनाओं से बदले, जैसे भुगतान सेवा का सफल परिणाम।
चार-अंकीय प्रमाणीकरण कोड 10 मिनट में समाप्त होता है — फिर भी खतरनाक क्यों है?: क्योंकि 0000 से 9999 तक केवल 10,000 उम्मीदवार हैं, और प्रति सेकंड 10 प्रयासों पर हमलावर औसत 5,000 प्रयासों — 500 सेकंड — बाद सफल होता है। 10 मिनट की वैधता 600 सेकंड है, इसलिए बिना दोहराव के क्रम से कोशिश करने पर उस खिड़की में 6,000 जाँचे जा सकते हैं। समाप्ति समय अकेले ब्रूट-फोर्स नहीं रोकता। उम्मीदवार-स्थान, प्रयास गति, और प्रयास-संख्या सीमा साथ डिज़ाइन करने पड़ते हैं।
परीक्षा का उपाय खाता लॉक है — क्या व्यवहार में तुरंत लॉक अकेले काफी है?: नहीं। प्रश्न के रिक्त में वह तर्क चाहिए जो लगातार विफलताओं की संख्या सीमा पार होते ही खाता लॉक करे, पर स्थिर, स्थायी लॉक अकेले हमलावर को जान-बूझकर किसी और का खाता लॉक कर सेवा-इनकार करने देता है। व्यवहार में प्रति-खाता विफलता गिनती के साथ चरणबद्ध प्रतीक्षा, स्रोत और डिवाइस का जोखिम आकलन, सूचनाएँ, और पुनर्प्राप्ति प्रक्रिया मिलाएँ। यह भी ज़रूरी है कि नया कोड जारी करने से विफलता गिनती शून्य पर वापस न आए।
WAF को अवरोध के बजाय पहचान पर सेट करने का मतलब क्या है?: इसका मतलब है कि सामान्य स्ट्रिंग गलती से हमला मानी जाए तो भी वैध व्यावसायिक ट्रैफ़िक नहीं रुकता। मॉडल उत्तर में लाभ यह है कि मिथ्या सकारात्मक से होने वाला अवरोध रोका जा सकता है, और करना यह है कि अलर्ट मिलते ही जाँचें कि हमला है या नहीं। पहचान मोड अकेला छोड़ने की सेटिंग नहीं। यह अवलोकन अवधि है जिसमें लॉग देखते हैं, मिथ्या सकारात्मक छानते हैं, नियम ट्यून करते हैं, फिर अवरोध पर जाते हैं। आपात में जब ज्ञात गंभीर भेद्यता वास्तव में शोषित हो रही हो, उपलब्धता जोखिम के विरुद्ध तौलकर शुरू से अवरोध चुनना उचित हो सकता है।
क्या इस प्रश्न की लाइब्रेरी H Log4j है?: प्रश्न उत्पाद नाम छिपाता है, पर हमले का क्रम — JNDI Lookup, LDAP सर्वर, HTTP सर्वर से क्लास प्राप्ति, HTTP हेडर में एम्बेड स्ट्रिंग, और उच्च CVSS v3.1 बेस स्कोर — स्वाभाविक रूप से CVE-2021-44228 का अमूर्तन पढ़ता है, जिसे Log4Shell कहते हैं। यह लेख वह संगति समझाता है, पर परीक्षा विशिष्ट उत्पाद नाम बताने की माँग नहीं करती। दिए गए हमला-प्रक्रिया और WAF विनिर्देश से ही उत्तर निकलता है।
इस प्रश्न से व्यवहार में क्या लेकर जाएँ?: यह कि प्रमाणीकरण सफल होना, JWT छेड़छाड़-रहित होना, लक्ष्य ऑब्जेक्ट तक पहुँच की अनुमति, और लक्ष्य गुण बदलने की अनुमति — सब अलग जाँचें हैं। इसके ऊपर छोटे प्रमाणीकरण कोड को प्रयास-दर सीमा चाहिए, और गंभीर लाइब्रेरी भेद्यता पर प्रभाव-पुष्टि, अंतरिम रक्षा, और मूल सुधार समानांतर चलते हैं। व्यावहारिक सार: प्राधिकरण साझा घटकों में समेटें, इनपुट स्कीमा अनुमति-सूची बनाएँ, JWT सत्यापन शर्तें सर्वर-साइड तय करें, और निर्भर लाइब्रेरी का हिसाब रखें ताकि अद्यतन हो सकें।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच में विशेषज्ञ, विशेष रूप से मौजूदा सिस्टम वाली परियोजनाओं और पुनरुत्पादन में कठिन बग में।

प्रोफ़ाइल देखें संपर्क करें

सार्वजनिक लिंक

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

ब्लॉग पर लौटें

1. निष्कर्ष पहले

2. परिदृश्य प्रश्नों से कैसे जुड़ता है

3. यह केवल एक “प्रमाणीकरण समस्या” नहीं

4. प्रश्न 1 — “स्टेटलेस” का अर्थ क्या है

5. प्रश्न 2(1) — चार-अंकीय कोड औसत 500 सेकंड में टूटता है

गणना है “उम्मीदवार-स्थान का आधा”

केवल समाप्ति छोटा करने से हार होती है यदि उम्मीदवार-स्थान छोटा हो

6. प्रश्न 2(2) — alg=none “हमलावर को सत्यापन विधि चुनने देना” की समस्या है

none टाइपो नहीं है

परीक्षा का उत्तर

व्यवहार में “NONE के अलावा कुछ भी” पर न रुकें

Base64url एन्क्रिप्शन नहीं है

7. प्रश्न 2(3) — वैध JWT होने पर भी mid बदलने से दूसरे का डेटा पढ़ा गया

प्रश्न का उत्तर

अधिक सुरक्षित डिज़ाइन है mid लेना ही नहीं

एक वाक्य में प्रमाणीकरण और प्राधिकरण का भेद

8. प्रश्न 2(4) — status=paid गुण-स्तर प्राधिकरण दोष है

BOLA से अंतर

“JSON को सीधे एंटिटी में डालना” खतरनाक है

status केवल भुगतान परिणाम से बदले

9. प्रश्न 2(5) — ब्रूट-फोर्स उपाय विफलता गिनती को स्थिति के रूप में रखते हैं

व्यवहार में केवल स्थायी लॉक पर निर्भर न रहें

प्रमाणीकरण कोड एकबारगी बनाएँ

10. प्रश्न 2 के चार भाग एक पृष्ठ पर अलग करें

11. प्रश्न 3(1) — नुकसान किए बिना दूरस्थ कोड निष्पादन पुष्टि करना

सत्यापन कोड केवल अहानिकर HTTP पहुँच चालू करता है

“स्क्रीन पर पाठ दिखाना” पर्याप्त क्यों नहीं

12. प्रश्न 3(2)(3) — WAF HTTP हेडर निरीक्षित करता है

पाठ में दिया स्थान सीधे WAF के निरीक्षण लक्ष्य से मिलाएँ

केस-स्वैप सँभालना

इस रेगेक्स को “पूर्ण Log4Shell उपाय” न मानें

13. प्रश्न 3(4) — “पहचान” से क्यों शुरू करें

पहचान मोड “कुछ न करने” का मोड नहीं

पहचान से अवरोध तक का पथ

14. WAF अंतरिम उपाय है; अद्यतन मूल सुधार है

“हम नहीं जानते कि उपयोग करते हैं या नहीं” सबसे बड़ा विलंब-स्रोत है

अद्यतन करने के बाद जाँच बंद न करें

15. परीक्षा में अंक आसान बनाने वाली पढ़त

15.1 तालिकाओं में “विनिर्देश” और “कार्यान्वयन” अलग करें

15.2 हमलावर द्वारा बदले मान के नीचे रेखा खींचें

15.3 उत्तर को प्रश्न-पाठ के अपने शब्दों पर लाएँ

15.4 WAF के लिए “कहाँ रखा गया” ट्रेस करें

16. वास्तविक API समीक्षाओं की जाँच-सूची

JWT सत्यापन

ऑब्जेक्ट-स्तर प्राधिकरण

गुण-स्तर प्राधिकरण

प्रमाणीकरण प्रयास

निर्भर लाइब्रेरी में गंभीर भेद्यताएँ

17. साझा घटकों के दो चेहरे, जैसे इस प्रश्न से दिखते हैं

18. सारांश

संदर्भ लिंक

संबंधित लेख

संबंधित विषय

इस विषय से जुड़ी सेवाएँ

अक्सर पूछे जाने वाले प्रश्न

लेखक की प्रोफ़ाइल

Go Komura

6. प्रश्न 2(2) — `alg=none` “हमलावर को सत्यापन विधि चुनने देना” की समस्या है

`none` टाइपो नहीं है

7. प्रश्न 2(3) — वैध JWT होने पर भी `mid` बदलने से दूसरे का डेटा पढ़ा गया

अधिक सुरक्षित डिज़ाइन है `mid` लेना ही नहीं

8. प्रश्न 2(4) — `status=paid` गुण-स्तर प्राधिकरण दोष है

`status` केवल भुगतान परिणाम से बदले