Registered Information Security Specialist exam, Spring 2024 (Reiwa 6) PM Question 1 व्याख्या — JWT alg=none, API authorization, और interim WAF mitigation

“हम JWT के signatures verify करते हैं, इसलिए user ID पर भरोसा किया जा सकता है।”

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

Registered Information Security Specialist exam, Spring 2024 (Reiwa 6) के PM (afternoon) session का Question 1 एक smartphone ऐप से बुलाए जाने वाले API के इर्द-गिर्द बना है।¹ सफल authentication पर JWT जारी होता है, और वह JWT user जानकारी लाने और update करने वाले API की calls से जुड़ता है। पहली नज़र में यह पूरी तरह साधारण व्यवस्था है।

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

1. JWT header का alg none करने से बिना signature वाला JWT pass हो जाता है।
2. Valid JWT रखते हुए mid किसी और user ID में बदलने से दूसरे की जानकारी पढ़ी या update की जा सकती है।
3. Undocumented status=paid जोड़ने से free-tier user भुगतान करने वाला बन जाता है।
4. Email से आने वाला चार-digit authentication code बिना attempt-limit के brute-force किया जा सकता है।

चारों “authentication-आसन्न vulnerabilities” लगती हैं, पर कारण एक नहीं। टूट रही हैं अलग boundaries: token integrity, object-level authorization, property-level authorization, और attempt-rate limit।

प्रश्न के उत्तरार्ध में एक और विषय जुड़ता है। व्यापक रूप से प्रयुक्त open-source library में गंभीर vulnerability प्रकट होती है, जिससे attacker JNDI Lookup का दुरुपयोग कर remote code चला सकता है। न fix है, न तैयार WAF नियम। इस बीच प्रश्न पूछता है कि impact कैसे पुष्टि करें, WAF कहाँ देखे, और प्रारंभिक WAF mode “block” के बजाय “detect” क्यों हो।

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

flowchart TB
    accTitle: प्रश्न का अवलोकन
    accDescr: हर चरण पर टूटी trust-boundary दिखाता है - authentication code, JWT, API authorization, और library vulnerability
    user["User ऐप"]
    auth["4-digit authentication code"]
    jwt["JWT जारी करना"]
    api["User API"]
    log["Log output"]
    vuln["Vulnerable library"]
    ext["Remote code execution"]
    user --> auth
    auth -->|Attempt limit नहीं| jwt
    jwt -->|alg=none अनुमति| api
    api -->|mid पर भरोसा| db1["दूसरे user का data पढ़ें/update"]
    api -->|status=paid| db2["Billing status बदलें"]
    api --> log
    log --> vuln
    vuln -->|JNDI/LDAP/HTTP| ext

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

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

• RESTful API का session-state न रखने का गुण statelessness कहलाता है। इसका मतलब यह नहीं कि server कोई database या user state बिल्कुल नहीं रखता
• चार-digit authentication code के 10,000 संभव मान हैं। प्रति सेकंड 10 प्रयासों पर attacker औसत 5,000 प्रयासों बाद सफल होता है, यानी 500 सेकंड — 10 मिनट की validity से छोटा, इसलिए expiry अकेले नहीं रोकती
• alg=none के विरुद्ध न्यूनतम उपाय यह पुष्टि करना है कि JWT header का alg NONE नहीं है। व्यवहार में, फिर भी, allowed algorithms का set server-side तय करें
• Valid JWT होने पर भी request का mid भरोसे योग्य नहीं। JWT के अंदर user ID का mid से मिलान करें, या अधिक सुरक्षित रूप से client से mid लें ही नहीं और लक्ष्य JWT से तय करें
• status=paid जोड़ना Mass Assignment समस्या है, जहाँ specification से बाहर properties सीधे internal object पर bound हो जाते हैं। Update DTO को allowlist बनाएँ, और user को billing status न बदलने दें
• Brute-force उपाय का model answer है वह logic जो लगातार failures की संख्या limit पार होते ही account lock करे। व्यवहार में staged delay और per-source control भी layer करें
• नई प्रकट गंभीर vulnerability का impact पुष्टि करने के लिए destructive command के बजाय test server के index.html तक पहुँच दर्ज करें, ताकि remote code execution वास्तव में पहुँचे यह पुष्टि हो
• Attack-string HTTP header में आती है, इसलिए WAF का inspection target Header है। Case-swap सँभालने वाले regular expression के रूप में \W[jJ][nN][dD][iI]\W जैसा कुछ प्रयोग करें
• WAF को “detect” mode में शुरू करने का लाभ है कि यह valid business traffic को false positives से blocked होने से बचाता है। Alert आए तो जाँचें कि वास्तविक हमला है या नहीं, फिर नियम tune होने के बाद block mode पर जाएँ
• WAF केवल interim उपाय है; मूल fix है affected library को patched version पर update करना

2. Scenario questions से कैसे जुड़ता है

Scenario company G पर है, जो नई स्वास्थ्य सेवा शुरू कर रही है। Users smartphone ऐप से भोजन और शरीर-भार जैसे data दर्ज करते हैं और स्वास्थ्य-जोखिम assessment तथा आहार सलाह पाते हैं। सिस्टम cloud पर बना है, API gateway, event-driven processing, और managed database मिलाकर।

Question paper विशिष्ट product और service नाम abstract करता है। यह लेख भी IPA के आरेख या पाठ नहीं दोहराता, बल्कि प्रश्नों को समझने के लिए आवश्यक structure ही paraphrase करता है।

Grading commentary कहती है कि समग्र correct-answer rate औसत के आसपास थी। पर यह भी बताती है कि प्रश्न 2(2) के JWT-tamper उपाय और प्रश्न 3(1) में verification server पर आवश्यक mechanism की correct-answer rate कुछ कम थी। दोनों शब्दावली अकेले से हल नहीं होते। आपको यह trace करना पड़ता है कि attacker ने कौन सा मान बदला, वह किस प्रक्रिया में गया, और अंत में कहाँ भरोसा किया गया।

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

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

[User ID / password]
          |
          v
[4-digit code check] ---- attempt limit नहीं ----> brute-force
          |
          v
[JWT जारी करें]
          |
          v
[JWT library] ------- alg=none अनुमति ------> user ID tamper
          |
          v
[User API]
    |             |
    |             +-- status पूरा आगे भेजता है ----> property-level authorization दोष
    |
    +-- mid पर भरोसा -----------------------> object-level authorization दोष

[बाहरी input log]
          |
          v
[Vulnerable library] ---- JNDI/LDAP/HTTP ------> remote code execution

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

एक check pass करना अगली छोड़ने का कारण कभी नहीं। Valid JWT वाला user किसी और का data पढ़ने का अधिकारी नहीं होता। अपने data update करने का अधिकारी user billing status भी बदलने का अधिकारी नहीं होता।

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

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

चित्र 2: Authentication और authorization का अंतर। Authentication पहले आता है; authorization अलग check है।

4. प्रश्न 1 — “Stateless” का अर्थ क्या है

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

उत्तर है stateless।

Stateless का मतलब है server को पिछली request की conversation-state याद रखने की ज़रूरत नहीं, क्योंकि प्रत्येक request स्वयं processing के लिए आवश्यक सब कुछ लाता है। इस प्रश्न में smartphone ऐप हर request पर Authorization header में JWT लगाता है। Server उस JWT को verify करता है और उसी से उस request का user पहचानता है।

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

• User जानकारी और स्वास्थ्य data संग्रहीत करने वाला database
• Billing status
• Authentication code का मान, expiry, और failure count
• JWT signing key
• Revocation जानकारी, उन डिज़ाइनों में जो revocation list उपयोग करते हैं
• Logs और audit records

जो वह नहीं रखता वह है केवल conversation जारी रखने के लिए server-side session state, जिसे प्रत्येक API call की पूर्व शर्त बनाया जाए।

Stateless होना security स्वतः बेहतर नहीं करता। हर request पर JWT भेजना horizontal scaling आसान करता है, पर JWT validation गलत हो तो वह error हर node पर समान रूप से फैलती है। Architectural property और security-correctness दो अलग चीज़ें हैं।

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

Authentication API user ID और password मिलते ही email से चार-digit संख्या भेजता है। फिर user ID और चार-digit code मिलते ही JWT जारी करता है। Code निर्माण से 10 मिनट valid रहता है।

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

गणना है “candidate space का आधा”

चार-digit संख्या, leading zeros सहित, निम्नलिखित 10,000 संभावनाएँ रखती है।

0000, 0001, 0002, ... , 9999

यदि सही उत्तर uniformly random चुना गया हो, बिना duplication क्रम से कोशिश करने वाला attacker औसत में candidate space के आधे बाद सही तक पहुँचता है।

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

इसलिए blank b है 500।

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

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

चित्र 9: चार-digit authentication code का पैमाना। औसत में candidate space का आधा आज़माने से validity अवधि में टूटता है।

केवल expiry छोटा करने से हार होती है यदि candidate space छोटा हो

Authentication code की शक्ति न केवल अंक-संख्या से तय होती है, न केवल validity अवधि से।

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

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

वर्तमान NIST SP 800-63B out-of-band authentication में प्रयुक्त short-lived secrets के लिए कम से कम छह digits माँगता है, और जब secret में 64 bits से कम entropy हो तो attempt-rate limit अनिवार्य करता है। यह email को out-of-band authentication के लिए न उपयोग करने को भी कहता है।⁴ Exam का उत्तर दिए गए चार-digit, email-भेजे specification के भीतर काम करता है, पर व्यवहार में नए डिज़ाइन के लिए वह आधार स्वयं पुनर्विचार योग्य है।

6. प्रश्न 2(2) — alg=none “attacker को verification method चुनने देना” की समस्या है

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

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

Header ने signature के लिए प्रयुक्त algorithm के रूप में RS256 दर्ज किया। Payload में user ID, issued time, और expiry है।

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

1. Header का alg RS256 से NONE करें।
2. Payload का user ID किसी और user में बदलें।

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

flowchart LR
    accTitle: JWT alg=none हमले का प्रवाह
    accDescr: Valid JWT में alg को none कर user ID फिर लिखने से request pass हो जाता है
    A["Valid JWT<br/>alg=RS256<br/>user=user01"] -->|Header alg none करें| B["Tampered JWT<br/>alg=none<br/>user=user02"]
    B -->|Signature verification छोड़ता| C["Server इसे<br/>user02 मानकर स्वीकार करता"]

चित्र 3: JWT alg=none हमले का प्रवाह। Attacker verification algorithm चुनता है।

none typo नहीं है

RFC 7519 “Unsecured JWT” define करता है — बिना signature और बिना encryption का JWT, जिसका alg none है।⁵ इसलिए मान none ऐसा नहीं जो specification में बस मौजूद ही न हो।

समस्या यह है कि जो API केवल signed JWT स्वीकार करे, उसने attacker-specified none स्वीकार कर लिया।

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

1. JWT header पढ़ें।
2. Header में लिखा alg देखें, और verification method चुनें।
3. यदि alg none है, signature verify न करें।
4. Payload के user ID पर भरोसा करें।

Security की शक्ति स्वयं attacker-controlled input से चुनी जा रही है।

Exam का उत्तर

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

Model answer निम्नलिखित है।

प्रश्न में वर्णित vulnerability के सीधे fix के रूप में यह सही है।

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

यहाँ exam उत्तर और व्यावहारिक recommendation अलग करनी है।

RFC 8725 कहता है कि JWT library को caller को allowed algorithms का set specify करने देना चाहिए, और उस set से बाहर कुछ भी प्रयोग न हो।⁶ दूसरे शब्दों में, विचार यह है।

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

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

केवल none reject करने पर भी अन्य कमज़ोर algorithms रह सकते हैं, या algorithm-confusion जहाँ public-key scheme को symmetric-key समझ लिया जाए। सिद्धांत है acceptance के लिए negative शर्तें बढ़ाना नहीं, बल्कि जो allowed है उसका संकीर्ण, positive set तय करना।

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

इस प्रश्न में payload की key का नाम user है, पर व्यवहार में मानक sub उपयोग करें या custom claim का अर्थ स्पष्ट define करें।

flowchart TB
    accTitle: Secure बनाम insecure JWT validation
    accDescr: Insecure validation alg पर निर्भर, secure validation server-side allowlist उपयोग करता है
    subgraph "Insecure validation"
        D1["JWT header से alg पढ़ें"]
        D2["alg none हो तो स्वीकार"]
        D1 --> D2
    end
    subgraph "Secure validation"
        S1["Server-configured allowed algorithms<br/>उदा. RS256"]
        S2["पुष्टि करें JWT header का alg<br/>allowlist में है"]
        S3["Signature, iss, aud, exp verify करें"]
        S1 --> S2 --> S3
    end

चित्र 4: Secure बनाम insecure validation। व्यवहार में allowed algorithms का संकीर्ण set तय करें।

Base64url encryption नहीं है

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

Signature जो guarantee देता है, और केवल जब verification सही हो, वह यह है कि issued होने के बाद सामग्री tampered नहीं गई। इसका मतलब यह नहीं कि गुप्त रखने योग्य व्यक्तिगत जानकारी signed JWT के payload में रखी जा सकती है।

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

अगला हमला JWT स्वयं नहीं tamper करता।

User API GET या PUT पर mid नामक user ID लेता है। Shared module P database में उस mid से जुड़ी user जानकारी लाता या update करता है।

हमले की structure सरल है।

JWT के अंदर user ID: user01    <- सही signed JWT
Request का mid:            user02   <- attacker ने बदला

JWT का signature valid है, इसलिए authentication सफल होता है। पर API mid=user02 को दिए अनुसार भरोसा करता है, और user02 की जानकारी लौटाता है।

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

flowchart LR
    accTitle: BOLA हमला
    accDescr: Valid JWT रखते हुए request का mid दूसरे user ID में बदलना
    A["Attacker"] -->|JWT user01<br/>mid user02| B["User API"]
    B -->|mid पर भरोसा| C["DB से user02 का data लौटाता"]

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

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

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

Model answer है:

वह logic जो verify करे कि JWT में निहित user ID mid के मान से मेल खाता है

Shared module P के अंदर verification का लाभ यह है कि वही authorization check GET और PUT दोनों पर, और भविष्य के किसी API पर जो P उपयोग करे, आसानी से लागू होती है। वही तुलना प्रत्येक स्क्रीन या endpoint में अलग copy करने का मतलब है कहीं छूट जाएगी।

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

जो API केवल caller की अपनी जानकारी लाता या update करता है, उसे client से user ID लेने की ज़रूरत नहीं।

GET /users/me
Authorization: Bearer <JWT>

Server-side, subject verified JWT से निकाला जाता है।

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

Update पर भी यही लागू।

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

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

यदि admin को दूसरे user की जानकारी पर काम करना हो, तो इस तरह बाँटें।

PUT /users/me                  सामान्य users के लिए
PUT /admin/users/{userId}      admins के लिए

Admin मार्ग पर अलग permission, audit log, और यदि चाहिए तो re-authentication माँगें। यह authorization policy की सीमाएँ “सामान्य-user API में केवल admins के लिए exception जोड़ें” से कहीं अधिक दिखती हैं।

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

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

एक वाक्य में authentication और authorization का भेद

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

• Authentication: आप कौन हैं
• Authorization: वह व्यक्ति क्या कर सकता है

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

8. प्रश्न 2(4) — status=paid property-level authorization दोष है

User API का specification update parameters के रूप में निम्नलिखित define करता है।

mid   user ID
name  नाम
age   आयु

पर examiner ने निम्नलिखित मान जोड़ा, जो specification में नहीं है।

status=paid

तब free-tier user की स्थिति भुगतान करने वाले की हो गई।

प्रश्न के अनुसार service L ने प्राप्त parameters validate नहीं किए; उसने सब सीधे shared module P को दे दिए, जो database सीधे update कर सके ऐसा बना था।

Blank c का उत्तर है shared module P।

flowchart TB
    accTitle: Mass Assignment
    accDescr: Specification-बाहर status=paid जोड़ा जाता है और internal object पर पूरा लागू होता है
    A["API specification<br/>mid / name / age"] -->|Attacker status=paid जोड़ता| B["Request body"]
    B -->|Auto-bound| C["Shared module P"]
    C -->|DB में सहेजा| D["Billing status paid हुई"]

चित्र 7: Mass Assignment। Specification-बाहर properties internal object पर पूरा लागू होता है।

BOLA से अंतर

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

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

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

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

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

भले स्क्रीन पर केवल name और age के inputs हों, attacker HTTP request सीधे गढ़ सकता है। UI में field का अभाव security boundary नहीं है।

Secure implementation updatable fields स्पष्ट करता है।

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

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

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

1. Update input type में केवल वे fields हों जिन्हें user बदल सकता है।
2. Unknown, specification-बाहर fields चुपचाप नज़रअंदाज़ करने के बजाय यदि संभव हो तो error के रूप में reject करें।

Unknown fields चुपचाप नज़रअंदाज़ करना हमले की failure छिपाता है, पर client implementation गलतियाँ और हमले के संकेत भी छुपा देता है। जब तक compatibility कारण न हो, सख़्त schema से reject investigation आसान बनाता है।

flowchart TB
    accTitle: Property-level authorization
    accDescr: Update DTO केवल allowlist रखता है, और unknown properties rejected होते हैं
    subgraph "Update DTO - allowlist"
        D1["name"]
        D2["age"]
    end
    A["Request body"] -->|Schema validation| B{"केवल allowed<br/>fields मौजूद"}
    B -->|हाँ| C["Entity name/age update"]
    B -->|नहीं| D["Error लौटाएँ"]
    E["Payment service<br/>verified notification"] -->|Dedicated पथ| F["status=paid update"]

चित्र 8: Property-level authorization। Updatable fields allowlist से सीमित करें, और billing status केवल अलग पथ से बदलें।

status केवल payment परिणाम से बदले

status=paid user profile का भाग नहीं। यह server-side तथ्य से निकली स्थिति है: कि payment सफल हुआ।

User profile update
  -> केवल name / age बदले जा सकते हैं

Payment service से verified notification
  -> paymentId मिलाएँ
  -> duplicate processing रोकें
  -> status को paid करें

एक ही database column में संग्रहीत होने पर भी उसे बदलने का अधिकार और बदलने का पथ अलग चीज़ें हैं। Internal entity को सीधे बाहरी API के input type के रूप में उपयोग वह सीमा मिटा देता है।

9. प्रश्न 2(5) — Brute-force उपाय failure count को state के रूप में रखते हैं

चार-digit code के brute-force के लिए तालिका 5 का blank d, 30 वर्ण या उससे कम में, वहाँ का processing पूछता है। Limit 10 है।

Model answer है:

वह logic जो लगातार failures की संख्या limit पार होते ही account lock करे

यह प्रश्न 1 के statelessness से नहीं टकराता। API call की conversation-state को server session के रूप में न रखना, और security निर्णय के लिए आवश्यक failure count को स्थायी रखना, दो अलग बातें हैं।

flowchart LR
    accTitle: Attempt-rate limit के साथ और बिना
    accDescr: बिना limit code औसत 500 सेकंड में टूटता है, पर failure-count limit हमला बहुत धीमा करती है
    subgraph "बिना limit"
        A1["प्रति सेकंड 10 प्रयास"] -->|लगभग 500 सेकंड| B1["Authentication सफल"]
    end
    subgraph "Limit के साथ"
        A2["10 failure पर lock"] -->|हमला गति ढहती| B2["Account lock"]
        C2["Staged delay"] --> B2
    end

चित्र 10: Attempt-rate limit के साथ और बिना। Failure-count limit व्यावहारिक रूप से brute-force रोक सकती है।

व्यवहार में केवल permanent lock पर निर्भर न रहें

Per-account attempt limit आवश्यक है, पर यदि attacker किसी और का user ID जानता हो, तो वह जान-बूझकर 10 बार fail होकर valid user को बाहर कर सकता है। इसलिए व्यवहार में निम्नलिखित मिलाएँ।

इसके अलावा, code पुनः भेजने पर failure count शून्य पर नहीं लौटनी चाहिए — नहीं तो attacker re-send API हर बार बुलाकर attempt-budget भर सकता है। वर्तमान NIST SP 800-63B भी माँगता है कि नया authentication secret बनने पर भी failure count reset न हो।⁴

Authentication code one-time बनाएँ

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

• सफल code तुरंत invalidate करें।
• उसी code का reuse reject करें।
• Code स्वयं log में न छोड़ें।
• Response ऐसी रखें कि code-check की सफलता या failure से user के अस्तित्व का अनुमान न लगे।
• Code-भेजने वाले API पर भी attempt limit लगाएँ।

जब तक छोटा secret उपयोग हो, security केवल random generation पर नहीं छोड़ी जा सकती।

flowchart TB
    accTitle: Authentication code के उपाय
    accDescr: अंक-संख्या और expiry से परे attempt limit, reuse rejection, notification आदि से रक्षा
    A["Authentication code"] --> B["अंक बढ़ाएँ"]
    A --> C["Expiry छोटी करें"]
    A --> D["Attempt-rate limit"]
    A --> E["सफलता के बाद invalidate"]
    A --> F["पुनः भेजने पर failure count reset न करें"]
    A --> G["Code log में न छोड़ें"]
    A --> H["Per-source control"]

चित्र 11: Authentication code के उपाय। अंक-संख्या और expiry को attempt control तथा संचालन प्रथाओं से मिलाएँ।

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

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

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

• alg cryptographic policy है।
• mid object-level authorization है।
• status property-level authorization है।
• otp online guessing के विरुद्ध resistance है।

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

11. प्रश्न 3(1) — नुकसान किए बिना remote code execution पुष्टि करना

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

1. Attacker JNDI Lookup वाली string HTTP header में रखकर भेजता है।
2. लक्ष्य server उस मान को log करता है।
3. Vulnerable library JNDI Lookup का evaluation कर attacker के LDAP server से पूछती है।
4. LDAP response attacker के HTTP server का URL लौटाती है।
5. लक्ष्य server class file लाता है और command चलाता है।

विशिष्ट product नाम छिपा होने पर यह Log4Shell (CVE-2021-44228) प्रकार के हमले के रूप में पढ़ता है। Apache का अपना वर्णन भी vulnerability को ऐसे बताता है कि यदि attacker log message या parameter नियंत्रित करे, तो LDAP server से load किया गया arbitrary code चला सकता है।⁹

flowchart LR
    accTitle: Log4Shell-प्रकार vulnerability की पुष्टि प्रवाह
    accDescr: Harmless callback से पुष्टि करें कि JNDI से remote code execution तक श्रृंखला वास्तव में चलती है
    A["Attacker"] -->|jndi/ldap payload<br/>x-api-version में डालें| B["Vulnerable server"]
    B --> C["Log processing"]
    C -->|JNDI Lookup| D["Malicious LDAP server"]
    D -->|HTTP URL response| E["Malicious HTTP server<br/>index.html"]
    E -->|GET दर्ज करें| F["Test server<br/>access log"]
    F -->|पहुँच पुष्टि| G["Vulnerability पुष्ट"]

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

Verification code केवल harmless HTTP पहुँच चालू करता है

Company G सिस्टम पर impact न डालने वाला verification code चलाती है, यह पुष्टि करने के लिए कि vulnerability V बाहर से exploit हो सकती है। Verification code जो एकमात्र command जारी करता है वह test server का index.html लाना है।

प्रश्न 3(1) पूछता है कि command चला यह पुष्टि करने के लिए test server पर क्या लागू करना होगा।

Model answer है:

वह mechanism जो test server के index.html तक पहुँच दर्ज करे और पुष्टि करने दे

यदि web server के access log में लक्ष्य server से GET दर्ज हो, तो कम से कम निम्नलिखित श्रृंखला चली यह पुष्टि होती है।

बाहरी HTTP request
  -> log processing
  -> JNDI Lookup
  -> LDAP response
  -> class प्राप्ति
  -> verification command execution
  -> test server तक HTTP पहुँच

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

हमले का लक्ष्य server है। User के browser स्क्रीन पर कुछ बदले इसकी guarantee नहीं। साथ ही, vulnerability मौजूद होने पर भी बीच की outbound communication firewall से रुक सकती है।

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

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

• लक्ष्य सिस्टम के मालिक से स्पष्ट अनुमति लें।
• ऐसी verification method उपयोग करें जिसका production पर impact न हो, या स्वीकार्य रूप से छोटा हो।
• लेखन, हटाने, या configuration परिवर्तन जैसे destructive commands न चलाएँ।
• Verification domain और server स्वयं प्रबंधित करें।
• Verification समय, स्रोत, लक्ष्य, और अपेक्षित callback दर्ज करें।
• Verification के बाद अस्थायी LDAP या HTTP server और credentials हटा दें।

“Arbitrary code execution संभव है यह पुष्टि करना” और “arbitrary खतरनाक code चलाना” एक नहीं। Side effects लक्ष्य पूरा करने के लिए आवश्यक न्यूनतम रखें।

12. प्रश्न 3(2)(3) — WAF HTTP header inspect करता है

Service N का WAF inspection target के रूप में GET, POST, PUT, ANY, Header, COOKIE, या Multipart चुनने देता है।

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

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

यह सामान्य ज्ञान से कम और question-text के data प्रवाह पढ़ने से अधिक है।

Attack-string कहाँ रखी गई:
  x-api-version header
          |
          v
WAF का inspection target:
  Header

यह न GET parameter है, न POST body। WAF की feature-list देखकर “हमला जैसा लगता है इसलिए ANY” चुनने के बजाय उस स्थान से उत्तर दें जहाँ question-text कहता है attacker ने मान रखा।

Case-swap सँभालना

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

Header  \Wjndi\W  block
Header  \Wldap\W  block

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

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

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

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

Question booklet में backslash जापानी-locale glyph में yen चिह्न जैसा दिख सकता है, पर regular expression के रूप में वह \W है। \W alphanumeric और underscore के अलावा किसी भी वर्ण से मेल खाता है। JNDI Lookup syntax में jndi के ठीक पहले और बाद ${ और : जैसे non-word characters आते हैं, और पैटर्न उन्हें भी पकड़ने के लिए लिखा है।

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

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

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

Exam उस regular expression की माँग करती है जो question-text में दिखाई बचाव-तकनीक सँभाले। वास्तविक हमलों में string splitting, वैकल्पिक Lookup, encoding, अन्य protocols, और अन्य विविधताएँ हो सकती हैं जिन्हें signature अकेले cover करना कठिन है।

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

1. वर्तमान ज्ञात attack-pattern WAF से interim रूप से block करें।
2. जाँचें कि affected library वास्तव में मौजूद है।
3. Outbound LDAP, RMI, और unnecessary HTTP traffic सीमित करें।
4. Patched version पर update करें।
5. Update के बाद भी logs देखें और जाँचें कि उल्लंघन हुआ या नहीं।

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

flowchart TB
    accTitle: WAF कहाँ बैठता है
    accDescr: WAF interim mitigation layer है, मूल fix library को patched version पर update करना है
    A["गंभीर vulnerability प्रकट"] --> B["Impact पुष्टि"]
    B --> C["Interim mitigation"]
    C -->|WAF नियम<br/>detect/block| D["Attack-pattern अस्थायी रोकें"]
    C -->|Outbound traffic सीमित| E["दुरुपयोग मार्ग बंद करें"]
    D --> F["Patch library पर update"]
    E --> F
    F --> G["पश्चात समीक्षा और रोकथाम"]

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

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

Updated WAF नियम के लिए Z, एक registered security specialist, production में जाने के बाद निश्चित अवधि तक mode “block” के बजाय “detect” रखने की सलाह देता है।

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

Model answer है:

Detect mode “कुछ न करने” का mode नहीं

Detect mode में नियम से मेल खाने वाला traffic फिर भी गुजरता है, पर log होता है और alert उठता है। यदि valid API call के अंदर संयोग से jndi या ldap आए, तो व्यवसाय तुरंत नहीं रुकता।

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

Alert प्राप्त
   |
   v
संबंधित request जाँचें
   |
   +-- Valid traffic -> नियम संकीर्ण करें, exception सोचें
   |
   +-- हमला        -> लक्ष्य अलग करें, logs सुरक्षित करें, impact जाँचें, block पर जाएँ

यदि alert कोई न देखे, detect mode का कोई रक्षा-प्रभाव नहीं। Detect केवल observation और निर्णय वाले operations प्रक्रिया के साथ काम करती है।

Detect से block तक का पथ

एक सामान्य rollout प्रक्रिया निम्नलिखित है।

1. वास्तविक traffic पर detect mode चलाएँ।
2. Hits को false positive या true positive classify करें।
3. लक्ष्य header, path, API, word-boundaries आदि tune करें।
4. पुष्टि करें कि valid traffic पर impact स्वीकार्य है।
5. Block mode पर जाएँ।
6. Block संख्या और business impact monitor करें।

यह, फिर भी, सामान्य समय का सिद्धांत है। जब vulnerability गंभीर हो, सक्रिय रूप से exploit हो, और विकल्प न हो, तो उल्लंघन से रुकावट false positives से बड़ी आँकी जा सकती है, और शुरू से block चुना जाता है। Exam के scenario में detect mode पहले चुना जाता है ताकि पुष्टि हो कि सेवा पहले जैसी चल सकती है।

flowchart LR
    accTitle: WAF detect mode से block mode तक
    accDescr: Detect mode में alerts देखें, false positives tune करें, फिर block mode पर जाएँ
    A["Detect mode"] -->|वास्तविक traffic| B["Alert उठा"]
    B --> C{"हमला या<br/>false positive"}
    C -->|False positive| D["नियम tune करें"]
    D --> A
    C -->|हमला| E["Block mode पर जाएँ"]
    E --> F["Block संख्या और business impact monitor"]

चित्र 14: Detect से block तक। पहले देखें और tune करें, impact स्वीकार्य पुष्टि करें, फिर block पर जाएँ।

14. WAF interim उपाय है; update मूल fix है

प्रश्न में library H की आधिकारिक साइट पर न fix था न interim उपाय, और cloud provider का व्यापक WAF नियम भी 72 घंटे तक ले सकता था। इसलिए company G impact स्वयं पुष्टि करती है और कम से कम पहले से पहचाने पैटर्न अस्थायी रूप से block करती है।

यह क्रम incident-response का मूल आकार है।

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

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

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

• Direct और transitive dependencies की list।
• Artifact में वास्तव में शामिल components और versions।
• वे किन services, containers, और devices पर deployed हैं।
• Dependent library update कर rebuild/redistribute की प्रक्रिया।
• आपात परिवर्तन स्वीकृत करने का संपर्क मार्ग।
• Outbound traffic के allowed destinations, और उन्हें block करने का impact।
• Logs कहाँ संग्रहीत हैं और कैसे खोजें।

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

Update करने के बाद जाँच बंद न करें

Vulnerability प्रकट होने के आसपास आप पहले से हमला झेल चुके हो सकते हैं। Patched version पर update भविष्य का exploitation रोकता है, पर पहले से compromised credentials या पहले से लगा backdoor मिटाता नहीं।

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

• JNDI या LDAP संकेत देने वाली संदिग्ध string वाले HTTP requests।
• Application server से बाहरी LDAP, RMI, या HTTP तक communication।
• असामान्य child process चालू होना।
• संदिग्ध JAR, class, script, या executable बनना।
• Cloud credentials या environment variables तक पहुँच।
• Update के आसपास authentication, permission परिवर्तन, और outbound स्थानांतरण।

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

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

यह प्रश्न knowledge-exam से कम और specification तथा implementation के अंतर पढ़ने का अभ्यास अधिक है।

15.1 तालिकाओं में “specification” और “implementation” अलग करें

status मुद्दे में API specification से अनुपस्थित मान implementation में निकल जाता है।

Specification:
  mid / name / age

Implementation:
  प्राप्त सभी parameters P को भेजें

यह अंतर दिखते ही स्पष्ट होता है कि blank c shared module P है।

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

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

• JWT header का alg
• JWT payload का user ID
• API parameter mid
• Specification-बाहर status
• Authentication API का otp
• HTTP header x-api-version

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

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

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

खराब उदाहरण:

Authorization उचित रूप से करें।

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

Verify करें कि JWT में निहित user ID mid के मान से मेल खाता है।

खराब उदाहरण:

Brute-force उपाय करें।

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

लगातार failures की संख्या limit पार होते ही account lock करें।

Abstract नाम जानना अकेले character-limit में अंक मिलने योग्य उत्तर नहीं देता।

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

WAF का inspection target हमले के type से अनुमान नहीं, attack-string कहाँ रखी गई उससे तय होता है।

x-api-version header में रखा
        ↓
Inspection target Header है

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

16. वास्तविक API reviews की checklist

इस प्रश्न को वास्तविक डिज़ाइन और code review में ले जाने की checklist।

JWT validation

• Allowed signature algorithms server configuration में तय है।
• none और unexpected algorithms rejected हैं।
• Signature, iss, aud, exp, और nbf उपयोग के अनुसार verified होते हैं।
• ID token, access token, और refresh token एक-दूसरे से उलझते नहीं।
• Key rotation और revocation की प्रक्रिया है।
• गोपनीय रहनी चाहिए जानकारी JWT payload में नहीं डाली जाती।

Object-level authorization

• Request के अंदर ID बदलने से दूसरे user के data तक नहीं पहुँचा जा सकता।
• Authorization list, विवरण, update, हटाने, और download सभी पर लागू है।
• Authorization स्क्रीन में नहीं, data तक पहुँचने वाली shared layer में लागू है।
• केवल-स्वयं API के लिए लक्ष्य ID token से निकालने पर विचार किया।
• Admin operations सामान्य-user API से अलग policy उपयोग करते हैं।

Property-level authorization

• बाहरी input type और database entity अलग रखे गए हैं।
• Updatable fields allowlist के रूप में गिने गए हैं।
• Specification-बाहर properties rejected या audit होते हैं।
• Permission, billing, approval, और ownership जैसी स्थिति user input से नहीं बदल सकती।
• Responses भी unnecessary confidential properties छोड़ती हैं।

Authentication attempts

• Per-account failure-count limit है।
• Staged delay और per-source control है।
• Code पुनः जारी करने पर failure count reset नहीं होती।
• Authentication code केवल एक बार उपयोग हो सकता है।
• Authentication code और password log में नहीं रहते।
• Unlock/recovery process स्वयं कमज़ोर authentication मार्ग नहीं है।

Dependent libraries में गंभीर vulnerabilities

• चलती services अपनी dependency-versions से map हो सकती हैं।
• Harmless method से impact verify करने की प्रक्रिया है।
• WAF नियम और outbound सीमा जैसे interim उपाय लागू हो सकते हैं।
• जिम्मेदार व्यक्ति identification alerts समीक्षा करने की operations प्रक्रिया है।
• Patched version पर update का आपात release मार्ग है।
• Update से पहले संभावित exploitation के लिए logs जाँचे जाते हैं।

17. Shared components के दो चेहरे, जैसे इस प्रश्न से दिखते हैं

इस प्रश्न में दो shared components हैं: JWT management library Q और shared module P।

Shared components के बड़े लाभ हैं।

• एक जगह fix हर API तक फैलता है जो उसे उपयोग करे।
• Authorization और validation logic प्रत्येक सुविधा में दोहराने नहीं पड़ते।
• Test लक्ष्य समेटे जा सकते हैं।
• Logs और audit format एक किए जा सकते हैं।

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

• यदि library Q alg=none स्वीकार करे, JWT उपयोग करने वाला हर API vulnerable हो जाता है।
• यदि shared module P arbitrary mid या status स्वीकार करे, GET और PUT दोनों vulnerable हो जाते हैं।
• यदि vulnerable library H आधार में उपयोग हो, HTTP header log करने वाला हर मार्ग attack-surface का भाग बनता है।

इसलिए shared होना चाहिए केवल data access नहीं। Security invariants स्वयं share करने चाहिए, और उस shared component को अलग से कठोर verify करना चाहिए।

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

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

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

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

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

18. सारांश

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

JWT उपयोग करना authentication सुरक्षित होना नहीं है। Attacker को signature algorithm चुनने देना user ID फिर लिखने देता है।

Valid JWT signature authorization सही होना नहीं है। Request के mid पर भरोसा valid user को किसी और की जानकारी तक पहुँचने देता है।

अपना object update कर पाना हर property बदलने की अनुमति नहीं है। status जैसी internal स्थिति auto-bound करना permission या billing status फिर लिखने देता है।

Authentication code पर expiry होना brute-force resistance नहीं है। Candidate space और attempt speed गिननी पड़ती है, और failures की संख्या सीमित करनी पड़ती है।

WAF में नियम डालना vulnerability ठीक होना नहीं है। Detect और block केवल समय खरीदते हैं; impact पुष्टि करते हैं और अंत में library update करते हैं।

flowchart TB
    accTitle: Vulnerabilities का उपायों से map
    accDescr: प्रत्येक vulnerability को उसकी trust-boundary और उपाय से जोड़ता है
    A["JWT tamper"] -->|Token validation| B["Allowed algorithms तय करें"]
    C["mid बदलना"] -->|Object-level authorization| D["JWT subject से मिलाएँ/mid unnecessary"]
    E["status=paid"] -->|Property-level authorization| F["Update DTO allowlist बनाएँ"]
    G["4-digit code brute-force"] -->|Authentication attempt control| H["Failure limit/delay"]
    I["Log4Shell-प्रकार vulnerability"] -->|Input से execution| J["Library update/WAF"]

चित्र 15: Vulnerabilities का उपायों से map। जो boundary टूटी उसी के अनुसार fix अलग करें।

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

पिछली check की सफलता को अगली trust-boundary छोड़ने का कारण कभी न बनने दें।

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

flowchart TB
    accTitle: अंतिम सारांश
    accDescr: दिखाता है कि पिछली check की सफलता अगली trust-boundary छोड़ने का कारण कभी नहीं
    A["Authentication सफल"] --> B["JWT signature verification"]
    B --> C["Object-level authorization"]
    C --> D["Property-level authorization"]
    D --> E["Attempt-rate limit"]
    E --> F["Input-से-execution सीमा"]
    F --> G["WAF/library update"]

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

संदर्भ लिंक

संबंधित लेख

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

संबंधित विषय

ये पृष्ठ विषय को सेवाओं और निर्णयों के व्यापक संदर्भ में रखते हैं।

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

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

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

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

JWT signature verification सफल होने पर भी attacker दूसरे की जगह कैसे ले सकता है?

इस प्रश्न में JWT management library ने JWT header के alg को attacker द्वारा specified रूप में ही स्वीकार किया, और alg=none वाले JWT को बिना किसी signature के valid माना। इसलिए payload का user ID फिर से लिखने पर भी validation pass हो जाता है। Exam का उत्तर है JWT header के alg की जाँच करना और पुष्टि करना कि उसका मान NONE नहीं है। व्यवहार में, केवल NONE reject करना पर्याप्त नहीं। Server-side configuration में उपयोग के लिए allowed algorithms — उदाहरण के लिए RS256 — तय करें, ताकि token जो algorithm declare करे उसे चुनाव के लिए सीधे न लिया जाए। उपयोग के अनुसार issuer, audience, expiry, subject आदि भी verify करें।

JWT के अंदर user ID की तुलना request के mid से करना authorization उपाय के रूप में काफी है?

इस exam के उत्तर के लिए काफी है। Shared module P के अंदर यह verify करना कि JWT में निहित user ID mid से मेल खाता है, किसी और का mid specify करने वाले हमले को रोकता है। लेकिन जो API केवल caller की अपनी जानकारी सँभालता है, व्यवहार में client से mid बिल्कुल न लेना, और verified JWT के subject से user ID तय करना अधिक सुरक्षित है। GET /users/me या PUT /users/me जैसे paths comparison-logic के छूट जाने को कठिन बनाते हैं। जिस API पर admin दूसरे user पर काम करे, उसे अलग endpoint और अपनी authorization policy में बाँटें।

सामान्य input validation अकेले status जोड़ने वाले हमले को क्यों नहीं रोक सकता?

क्योंकि name की लंबाई या age की सीमा जाँचने से कुछ नहीं होता यदि status — एक field जिसे पहले स्थान पर स्वीकार ही नहीं करना चाहिए था — auto-bound होकर internal object तक चला जाता है। समस्या मान का format नहीं; property-level authorization है, यानी user को वह property बदलने की अनुमति है भी या नहीं। Update input type में केवल name और age define करें, और unknown properties reject करें। Billing status केवल server-trusted events से बदले, जैसे payment service का सफल परिणाम।

चार-digit authentication code 10 मिनट में expire होता है — फिर भी खतरनाक क्यों है?

क्योंकि 0000 से 9999 तक केवल 10,000 उम्मीदवार हैं, और प्रति सेकंड 10 प्रयासों पर attacker औसत 5,000 प्रयासों — 500 सेकंड — बाद सफल होता है। 10 मिनट की validity 600 सेकंड है, इसलिए बिना duplication के क्रम से कोशिश करने पर उस window में 6,000 जाँचे जा सकते हैं। Expiry time अकेले brute-force नहीं रोकता। Candidate space, attempt speed, और attempt-count limit साथ डिज़ाइन करने पड़ते हैं।

Exam का उपाय account lock है — क्या व्यवहार में तुरंत lock अकेले काफी है?

नहीं। प्रश्न के blank में वह logic चाहिए जो लगातार failures की संख्या limit पार होते ही account lock करे, पर स्थिर, permanent lock अकेले attacker को जान-बूझकर किसी और का account lock कर denial-of-service करने देता है। व्यवहार में per-account failure count के साथ staged wait, source और device का risk assessment, notifications, और recovery process मिलाएँ। यह भी ज़रूरी है कि नया code जारी करने से failure count शून्य पर वापस न आए।

WAF को block के बजाय detect पर set करने का मतलब क्या है?

इसका मतलब है कि सामान्य string गलती से हमला मानी जाए तो भी valid business traffic नहीं रुकता। Model answer में लाभ यह है कि false positives से होने वाला block रोका जा सकता है, और करना यह है कि alert मिलते ही जाँचें कि हमला है या नहीं। Detect mode अकेला छोड़ने की setting नहीं। यह observation period है जिसमें logs देखते हैं, false positives छानते हैं, नियम tune करते हैं, फिर block पर जाते हैं। आपात में जब ज्ञात गंभीर vulnerability वास्तव में exploit हो रही हो, availability risk के विरुद्ध तौलकर शुरू से block चुनना उचित हो सकता है।

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

प्रश्न product नाम छिपाता है, पर हमले का क्रम — JNDI Lookup, LDAP server, HTTP server से class प्राप्ति, HTTP header में embed string, और उच्च CVSS v3.1 base score — स्वाभाविक रूप से CVE-2021-44228 का abstraction पढ़ता है, जिसे Log4Shell कहते हैं। यह लेख वह संगति समझाता है, पर exam विशिष्ट product नाम बताने की माँग नहीं करती। दिए गए attack-process और WAF specification से ही उत्तर निकलता है।

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

यह कि authentication सफल होना, JWT tamper-free होना, लक्ष्य object तक पहुँच की अनुमति, और लक्ष्य property बदलने की अनुमति — सब अलग checks हैं। इसके ऊपर छोटे authentication code को attempt-rate limit चाहिए, और गंभीर library vulnerability पर impact-पुष्टि, interim defense, और मूल fix parallel चलते हैं। व्यावहारिक सार: authorization shared components में समेटें, input schema allowlist बनाएँ, JWT validation शर्तें server-side तय करें, और dependent libraries का हिसाब रखें ताकि update हो सकें।

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

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

Go Komura

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

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