Security+ Academy · पाठ

टूटा हुआ प्रमाणीकरण और असुरक्षित डीसीरियलाइज़ेशन

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

पाठ 3, कुल 4 में से13 चरण

टूटा हुआ प्रमाणीकरण और असुरक्षित डीसीरियलाइज़ेशन, CoddyKit पर Security+ Academy का एक निःशुल्क पाठ है। यह 4 में से 3वाँ पाठ है। इस अध्ययन पथ के 3 तक कोई भी पाठ पूरा पढ़ना निःशुल्क है — इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ व्यावहारिक अभ्यास भी उपलब्ध कराता है। यह Security+ Academy सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। Security+ Academy पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

Broken Authentication क्या है

Broken authentication उस स्थिति को कहते हैं जब किसी अनुप्रयोग द्वारा user की पहचान Verify करने और sessions manage करने के तरीके में कमजोरियाँ हों। Authentication के broken होने पर Attackers Passwords, keys या session tokens से समझौता करके अन्य users की पहचान अपना सकते हैं। यह OWASP Top 10 category कई प्रकार की खामियों को शामिल करती है: कमजोर credentials, खराब session management, Missing MFA और असुरक्षित credential storage।

Credential Stuffing और Password Spraying

Credential stuffing पिछले data breach से प्राप्त leaked username/password pairs की बड़ी सूचियों का उपयोग करता है और Password reuse का शोषण करते हुए उन्हें अन्य sites पर आज़माता है। Password spraying इसका उलटा तरीका अपनाता है: account lockout thresholds से बचने के लिए common Passwords (जैसे Password1!) के छोटे set को अनेक accounts पर आज़माना। दोनों हमले कमजोर Password policies और MFA की अनुपस्थिति के कारण सफल होते हैं।

# Password spraying concept (defensive awareness)
# Attacker tries 'Password1!' against 10,000 accounts
# rather than trying 10,000 passwords against 1 account
# This avoids triggering lockout policies (e.g., 5 attempts/account)

# Defense: MFA + adaptive authentication + rate limiting

कमजोर Session Management

Sessions authenticated users को उनके application state से जोड़ते हैं। Weak session management की खामियों में predictable session token values (क्रमिक IDs जिन्हें Attackers guess कर सकते हैं), ऐसे tokens जो कभी expire नहीं होते, HTTPS के बजाय HTTP पर transmit किए गए tokens और Logout पर tokens को invalidate न करना शामिल हैं। Valid session token प्राप्त करने वाला Attacker Password जाने बिना user का रूप धारण कर सकता है।

# Signs of weak session management:
# /login response sets:
# Set-Cookie: session=1042  (predictable, sequential)
# Missing: Secure; HttpOnly; SameSite flags
# Missing: session expiry / Max-Age
# Logout does NOT invalidate server-side session

Session Fixation और Hijacking

Session fixation पीड़ित को Attacker द्वारा चुने गए session ID का उपयोग करने के लिए बाध्य करता है। उदाहरण के लिए, Attacker पहले से Set session cookie वाला link भेजता है; पीड़ित के authenticate करने के बाद Attacker उसी session ID से account access करता है। Session hijacking XSS, network sniffing (unencrypted connections पर) या चुराई गई cookies के माध्यम से मौजूदा session token चुरा लेता है। समाधान: login के बाद session IDs को फिर से generate करें और हर जगह HTTPS का उपयोग करें।

असुरक्षित Password Storage

Passwords को plaintext में या कमजोर hashing (MD5, SHA-1) के साथ store करना authentication की गंभीर विफलता है। Database breach होने पर plaintext Passwords और कमजोर hashes तुरंत उपयोग किए जा सकते हैं। Secure password storage के लिए Passwords के लिए बनाया गया adaptive hashing algorithm आवश्यक है: bcrypt, Argon2 या random per-user salt के साथ PBKDF2। ये algorithms जानबूझकर धीमे होते हैं, जिससे offline cracking computationally महँगी हो जाती है।

# Python example — secure password hashing with bcrypt
import bcrypt

# Hash a password (includes random salt automatically)
password = b'UserSuperSecret123'
hashed = bcrypt.hashpw(password, bcrypt.gensalt(rounds=12))

# Verify
bcrypt.checkpw(password, hashed)  # returns True

Insecure Deserialization क्या है

Serialization किसी object की state को storage या transmission के लिए किसी format (JSON, XML, binary) में बदलता है। Deserialization उस format से object को फिर से बनाता है। Insecure deserialization तब होती है जब कोई अनुप्रयोग Attacker-नियंत्रित data को बिना validation के deserialize करता है—जिससे Attackers serialized objects में बदलाव करके application logic को manipulate, privileges को escalate या Server पर arbitrary code execute कर सकते हैं।

Deserialization हमले का उदाहरण

एक आम attack pattern में cookies या API parameters के माध्यम से भेजे गए serialized objects शामिल होते हैं। उदाहरण के लिए, untrusted data पर ObjectInputStream.readObject() का उपयोग करने वाला Java अनुप्रयोग लोकप्रिय libraries (Apache Commons Collections) में gadget chains के माध्यम से Remote Code Execution (RCE) trigger कर सकता है। Attacker एक Malicious serialized payload तैयार करके उसे अनुप्रयोग को भेजता है और deserialization के दौरान code execute हो जाता है—अक्सर किसी भी authentication check के चलने से पहले।

# Insecure deserializing pattern (Python pickle — dangerous)
import pickle

# Attacker-controlled payload
class Exploit:
    def __reduce__(self):
        import os
        return (os.system, ('id',))  # executes 'id' on server

payload = pickle.dumps(Exploit())
pickle.loads(payload)  # RCE! Never deserialize untrusted data with pickle

Insecure Deserialization को रोकना

Insecure deserialization के विरुद्ध Defense में शामिल हैं: Java native serialization या Python pickle जैसे खतरनाक formats के साथ untrusted data को कभी deserialize न करें। Binary serialization के बजाय data-only formats (JSON, XML) को प्राथमिकता दें। यदि deserialization आवश्यक हो, तो integrity checks लागू करें (serialized object पर HMAC से signing करें), किन classes को deserialize किया जा सकता है इसे सीमित करने के लिए allow-lists का उपयोग करें और deserialization code को isolated, low-privilege environments में चलाएँ।

# Safe approach: sign serialized data before transmitting
import hmac, hashlib, json

def serialize_safe(data, secret):
    payload = json.dumps(data)  # use JSON, not pickle
    sig = hmac.new(secret.encode(), payload.encode(), hashlib.sha256).hexdigest()
    return payload + '.' + sig

एक नियंत्रण के रूप में Multi-Factor Authentication

Multi-Factor Authentication (MFA) broken authentication के विरुद्ध सबसे प्रभावशाली एकल control है। Phishing, credential stuffing या database breach के माध्यम से credentials compromise हो जाने पर भी second factor के बिना Attacker authenticate नहीं कर सकता। Microsoft की report के अनुसार MFA automated account compromise attacks के 99.9% से अधिक को block करता है। Privileged accounts के लिए MFA अनिवार्य होना चाहिए और सभी users को इसके उपयोग के लिए प्रोत्साहित किया जाना चाहिए।

Account Lockout और दर सीमित करना

Account Lockout नीतियाँ विफल लॉगिन प्रयासों की निर्धारित संख्या के बाद किसी Account को अस्थायी रूप से अक्षम कर देती हैं, जिससे brute-force हमले धीमे हो जाते हैं। हालांकि, Lockout वैध Users के विरुद्ध सेवा से इनकार को संभव बना सकते हैं — Attacker जानबूझकर Lockout सक्रिय करके पहुँच रोक देते हैं। दर सीमित करना (बार-बार विफलताओं के बाद exponential backoff का उपयोग करके प्रतिक्रियाओं को धीमा करना) और CAPTCHA चुनौतियाँ DoS के कम जोखिम के साथ brute force को कम करती हैं।

OWASP के शीर्ष 10 में टूटी हुई Authentication

OWASP टूटी हुई Authentication को एक गंभीर जोखिम के रूप में सूचीबद्ध करता है, क्योंकि Authentication की खामियाँ आम भी हैं और उनका प्रभाव भी बहुत अधिक होता है। टूटी हुई Authentication के प्रमुख संकेतकों में ये शामिल हैं: credential stuffing जैसे स्वचालित हमलों की अनुमति देना, brute force या अन्य स्वचालित हमलों की अनुमति देना, डिफ़ॉल्ट, कमजोर या व्यापक रूप से ज्ञात Passwords की अनुमति देना, कमजोर credential recovery प्रक्रियाओं का उपयोग करना, plain text या कमजोर रूप से hashed Passwords का उपयोग करना, तथा multi-factor Authentication का न होना या अप्रभावी होना।

त्वरित जाँच

इस पाठ में दिए गए CompTIA Security+ (SY0-701) की अवधारणाओं के बारे में अपनी समझ जाँचें।

पाठ का पुनरावलोकन

इस पाठ में आपने सीखा: टूटी हुई Authentication में कमजोर sessions, credential stuffing और असुरक्षित Password भंडारण शामिल हैं, असुरक्षित deserialization से दुर्भावनापूर्ण serialized objects के माध्यम से Remote Code Execution हो सकता है, और MFA, bcrypt Password hashing, लॉगिन के बाद session regeneration तथा signed serialized data प्रमुख सुरक्षा उपाय हैं। आगे हम सुरक्षित SDLC, SAST और DAST tools का अध्ययन करेंगे।

शुरुआत निःशुल्क

एआई शिक्षक के साथ Security+ Academy सीखें — निःशुल्क

अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।

पाठ्यक्रम
30
पाठ
120

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

क्या “टूटा हुआ प्रमाणीकरण और असुरक्षित डीसीरियलाइज़ेशन” पाठ निःशुल्क है?

हाँ — Security+ Academy अध्ययन पथ के 3 तक कोई भी पाठ, जिसमें “टूटा हुआ प्रमाणीकरण और असुरक्षित डीसीरियलाइज़ेशन” भी शामिल है, यहाँ वेब पर पूरा पढ़ना निःशुल्क है। इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ इंटरैक्टिव अभ्यास भी उपलब्ध कराता है। Security+ Academy पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

“टूटा हुआ प्रमाणीकरण और असुरक्षित डीसीरियलाइज़ेशन” में मैं क्या सीखूँगा?

जानिए कि कमज़ोर सत्र प्रबंधन, क्रेडेंशियल स्टफ़िंग और असुरक्षित डीसीरियलाइज़ेशन की कमज़ोरियाँ हमलावरों को खाते हड़पने और कोड चलाने की अनुमति कैसे देती हैं। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ Security+ Academy का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।

क्या Security+ Academy शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?

पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर Security+ Academy शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 3वाँ पाठ है।

“टूटा हुआ प्रमाणीकरण और असुरक्षित डीसीरियलाइज़ेशन” पाठ पूरा करने में कितना समय लगता है?

CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।

क्या मैं इस Security+ Academy पाठ में कोड लिख और चला सकता हूँ?

हाँ। हर Security+ Academy पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।

इस पाठ्यक्रम के सभी पाठ

  1. SQL इंजेक्शन और कमांड इंजेक्शन
  2. क्रॉस-साइट स्क्रिप्टिंग (XSS) और CSRF
  3. टूटा हुआ प्रमाणीकरण और असुरक्षित डीसीरियलाइज़ेशन
  4. सुरक्षित SDLC, SAST और DAST उपकरण
← Security+ Academy पर वापस जाएँ