सुरक्षित कोडिंग और बैकएंड के लिए OWASP के शीर्ष 10 · पाठ

उन्नत एसक्यूएलआई और NoSQLi तकनीकें

अधिक जटिल एसक्यूएल और NoSQL इंजेक्शन परिदृश्यों का परीक्षण कीजिए और उनसे प्रभावी ढंग से निपटने के लिए उन्नत रक्षात्मक कोडिंग पैटर्न सीखिए।

पाठ 1, कुल 4 में से12 चरण

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

SQLi का गहन अध्ययन

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

इस पाठ में हम इन 'उन्नत' SQLi तकनीकों, जैसे ब्लाइंड और द्वितीय-क्रम इंजेक्शन, का अध्ययन करेंगे और फिर NoSQL इंजेक्शन की कमज़ोरियों पर ध्यान केंद्रित करेंगे। सबसे महत्वपूर्ण बात यह है कि हम इनसे प्रभावी ढंग से बचाव करना सीखेंगे!

ब्लाइंड SQL इंजेक्शन क्या है?

ब्लाइंड SQL इंजेक्शन (Blind SQLi) तब होता है जब कोई अनुप्रयोग SQLi के प्रति असुरक्षित हो, लेकिन उसकी HTTP प्रतिक्रियाएँ SQL प्रश्न के परिणाम या किसी त्रुटि संदेश को सीधे प्रदर्शित न करें।

इसके बजाय, हमलावर को अनुप्रयोग के व्यवहार या प्रतिक्रिया समय का निरीक्षण करके जानकारी का अनुमान लगाना पड़ता है। ब्लाइंड SQLi के दो मुख्य प्रकार हैं:

बूलियन-आधारित ब्लाइंड SQLi: हमलावर डाले गए कथनों की सही/गलत स्थितियों के आधार पर पृष्ठ की सामग्री में होने वाले बदलावों का निरीक्षण करता है (जैसे, कोई विशेष संदेश दिखाई देना या गायब हो जाना)।
समय-आधारित ब्लाइंड SQLi: हमलावर डाले गए डेटाबेस फ़ंक्शन के कारण सर्वर की प्रतिक्रिया में होने वाली देरी देखकर डेटा का अनुमान लगाता है।

समय-आधारित ब्लाइंड SQLi का प्रदर्शन

हमलावर ऐसे डेटाबेस फ़ंक्शन का उपयोग कर सकते हैं जो निष्पादन में देरी करते हैं, जैसे SLEEP() (MySQL) या PG_SLEEP() (PostgreSQL), ताकि डेटा का अनुमान लगाया जा सके। यदि उनके द्वारा डाली गई शर्त सही हो, तो देरी होती है; गलत होने पर नहीं होती।

उदाहरण के लिए, पहले अक्षर का 'a' होना जाँचने के लिए किसी *असुरक्षित* प्रश्न का दुरुपयोग किया जा सकता है:

SELECT * FROM users WHERE username = 'admin' AND IF(SUBSTRING(password, 1, 1) = 'a', SLEEP(5), 0);

सुरक्षित तरीका हमेशा पैरामीटरयुक्त प्रश्नों का उपयोग करता है और सभी उपयोगकर्ता इनपुट को कोड के बजाय डेटा मानता है। सुरक्षित उदाहरण चलाकर देखें:

import sqlite3
import time

def get_user_data_secure(username):
    conn = sqlite3.connect(':memory:')
    cursor = conn.cursor()
    cursor.execute('''
        CREATE TABLE IF NOT EXISTS users (
            id INTEGER PRIMARY KEY,
            username TEXT NOT NULL,
            password TEXT NOT NULL
        )
    ''')
    cursor.execute("INSERT INTO users (username, password) VALUES (?, ?)", ('admin', 'securepassword'))
    conn.commit()

    # Secure query using parameterized statement
    query = "SELECT username FROM users WHERE username = ?"
    start_time = time.time()
    cursor.execute(query, (username,))
    result = cursor.fetchone()
    end_time = time.time()

    print(f"Query for '{username}' took {end_time - start_time:.4f} seconds.")
    if result:
        print(f"Found user: {result[0]}")
    else:
        print("User not found or query failed.")

    conn.close()

if __name__ == "__main__":
    print("--- Secure Query Example ---")
    get_user_data_secure("admin")
    get_user_data_secure("nonexistent")

ब्लाइंड SQLi से बचाव

ब्लाइंड SQLi से बचाव का सर्वोत्तम तरीका सामान्य SQLi जैसा ही है: पैरामीटरयुक्त प्रश्न या तैयार कथन। ये विधियाँ सुनिश्चित करती हैं कि SQL कोड उपयोगकर्ता इनपुट से पूरी तरह अलग रहे।

उपयोगकर्ता द्वारा दिए गए सभी डेटा को शाब्दिक मान मानने पर, हमलावर के लिए दुर्भावनापूर्ण आदेश डालना असंभव हो जाता है, चाहे आउटपुट दिखाई दे या नहीं।

उपयोगकर्ता इनपुट का हमेशा कठोरता से सत्यापन और स्वच्छीकरण करें।
दुर्भावनापूर्ण अनुरोधों को फ़िल्टर करने के लिए वेब अनुप्रयोग फ़ायरवॉल (WAF) का उपयोग करें।
असामान्य या असामान्य रूप से लंबे प्रश्न समय के लिए डेटाबेस पहुँच प्रतिरूपों की निगरानी करें।

द्वितीय-क्रम SQL इंजेक्शन

द्वितीय-क्रम SQL इंजेक्शन तब होता है जब दुर्भावनापूर्ण इनपुट को पहले डेटाबेस (या किसी अन्य स्थायी संग्रहण) में संग्रहीत किया जाता है और बाद में उचित पुनः-स्वच्छीकरण के बिना किसी अन्य प्रश्न में पुनः प्राप्त करके उपयोग किया जाता है।

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

इसे विलंबित-प्रभाव वाले बम की तरह समझें—फ्यूज़ अभी जलाई जाती है, लेकिन विस्फोट बाद में होता है!

द्वितीय-क्रम SQLi परिदृश्य

ऐसे परिदृश्य पर विचार करें जहाँ कोई उपयोगकर्ता 'admin'-- जैसे उपयोगकर्ता नाम से पंजीकरण करता है। जब यह उपयोगकर्ता नाम पहली बार संग्रहीत किया जाता है, तो इसे सुरक्षित रूप से संभाला जा सकता है।

हालाँकि, बाद में कोई व्यवस्थापक पैनल संग्रहीत उपयोगकर्ता नाम को जोड़कर बनाए गए प्रश्न का उपयोग करके उपयोगकर्ता का विवरण प्राप्त करता है:

SELECT email FROM users WHERE username = ' . $username_from_db . ';

यदि $username_from_db (जिसमें अब 'admin'-- मौजूद है) को इस दूसरे प्रश्न में उपयोग करने से पहले फिर से स्वच्छ नहीं किया जाता, तो टिप्पणी (--) प्रश्न को छोटा कर सकती है। इससे हमलावर शर्तों को दरकिनार कर सकता है या संवेदनशील डेटा प्रकट कर सकता है, क्योंकि प्रश्न प्रभावी रूप से SELECT email FROM users WHERE username = 'admin' बन जाता है।

NoSQL इंजेक्शन का परिचय

NoSQL डेटाबेस, जैसे MongoDB, Cassandra और Redis, पारंपरिक SQL प्रश्न भाषा का उपयोग नहीं करते। फिर भी, यदि उपयोगकर्ता इनपुट को सही ढंग से संभाला न जाए, तो वे इंजेक्शन हमलों के प्रति असुरक्षित हो सकते हैं।

हमलावर NoSQL प्रश्नों में उपयोग की जाने वाली डेटा संरचनाओं (जैसे, JSON, BSON, XML) में हेरफेर करके:

प्रमाणीकरण को दरकिनार करके अनधिकृत पहुँच प्राप्त कर सकते हैं।
अनधिकृत डेटा तक पहुँच सकते हैं या उसमें बदलाव कर सकते हैं।
जटिल प्रश्न बनाकर सेवा-अस्वीकार हमले कर सकते हैं।

विशिष्ट तकनीकें NoSQL डेटाबेस के प्रकार और उसकी विशिष्ट प्रश्न भाषा या API पर बहुत अधिक निर्भर करती हैं।

MongoDB ऑपरेटर इंजेक्शन

MongoDB में NoSQL इंजेक्शन की एक सामान्य तकनीक में प्रश्न ऑपरेटरों के साथ हेरफेर करना शामिल है। MongoDB प्रश्नों में अक्सर विशेष ऑपरेटरों वाली JSON जैसी वस्तुओं का उपयोग होता है (जैसे, बराबर के लिए $eq, से बड़ा के लिए $gt, बराबर नहीं के लिए $ne)।

यदि कोई बैकएंड बिना सत्यापन के सीधे उपयोगकर्ता इनपुट से MongoDB प्रश्न बनाता है, तो हमलावर इन ऑपरेटरों को डाल सकता है। उदाहरण के लिए, पासवर्ड फ़ील्ड में {"password": {"$ne": null}} डालने से किसी विशिष्ट पासवर्ड के बजाय किसी भी गैर-शून्य पासवर्ड का मिलान करके प्रमाणीकरण को दरकिनार किया जा सकता है।

इससे वे सटीक समानता के बजाय अन्य शर्तों से मेल खाने वाले अभिलेख खोज सकते हैं।

NoSQLi उदाहरण (MongoDB)

ऐसे लॉगिन फ़ंक्शन पर विचार करें जो उपयोगकर्ता नाम और पासवर्ड लेता है। यदि पासवर्ड का उपयोग स्वच्छीकरण के बिना सीधे MongoDB प्रश्न में किया जाता है, तो हमलावर इसे दरकिनार कर सकता है।

यहाँ एक *सिम्युलेटेड* सुरक्षित Python उदाहरण दिया गया है, जो दिखाता है कि उचित संचालन इंजेक्शन को कैसे रोकता है, भले ही हमलावर '{" $ne": None}' जैसी बनाई गई स्ट्रिंग भेजने का प्रयास करे।

def simulate_mongodb_login(username, password):
    # Simulate a collection in memory
    users_db = [
        {"username": "admin", "password": "secure_password123"},
        {"username": "guest", "password": "guestpass"}
    ]

    print(f"Attempting login for '{username}' with password '{password}'")

    # --- VULNERABLE CONCEPT --- 
    # If 'password' was parsed as a JSON object directly into the query:
    # Attacker input: password = {"$ne": None}
    # This would become: {"username": "admin", "password": {"$ne": None}}
    # which means "password not equal to None" and matches any non-null password.

    # --- SECURE APPROACH --- 
    # Always treat user input as a literal string unless explicitly parsed and validated.
    # This ensures 'password' is treated as a literal string, preventing operator injection.
    for user in users_db:
        if user["username"] == username and user["password"] == password:
            print(f"Login SUCCESS for {username} (secure). ")
            return True
    print(f"Login FAILED for {username} (secure).")
    return False

if __name__ == "__main__":
    print("--- NoSQLi Secure Login Example ---")
    simulate_mongodb_login("admin", "secure_password123") # Correct password
    simulate_mongodb_login("admin", "wrong_password")     # Incorrect password
    # Simulate attempted bypass with a crafted password string:
    simulate_mongodb_login("admin", '{"$ne": None}') # Still fails due to secure handling

NoSQL इंजेक्शन की रोकथाम

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

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

त्वरित जाँच: इंजेक्शन के प्रकार

उन्नत इंजेक्शन तकनीकों की अपनी समझ जाँचें।

इंटरैक्टिव पाठ में इसका उत्तर दें

पुनरावलोकन और अगले चरण

हमने उन्नत SQL और NoSQL इंजेक्शन तकनीकों का अध्ययन किया, जो साधारण प्रत्यक्ष हेरफेर से आगे जाती हैं:

ब्लाइंड SQLi (समय-आधारित और बूलियन-आधारित दोनों) डेटाबेस से सीधे आउटपुट मिले बिना डेटा का अनुमान लगाता है।
सेकंड-ऑर्डर SQLi में दुर्भावनापूर्ण इनपुट को संग्रहीत किया जाता है, जिसे बाद में किसी अलग क्वेरी में निष्पादित किया जाता है।
NoSQL इंजेक्शन NoSQL क्वेरी संरचनाओं (जैसे MongoDB ऑपरेटरों) को निशाना बनाकर डेटाबेस संचालन में हेरफेर करता है।

सबसे अच्छे बचाव अब भी मजबूत इनपुट सत्यापन, SQL के लिए पैरामीटरयुक्त क्वेरी और NoSQL के लिए सुरक्षित ड्राइवर API हैं। हमेशा मानकर चलें कि सभी इनपुट दुर्भावनापूर्ण हैं और हर चीज़ का सत्यापन करें!

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

एआई शिक्षक के साथ सुरक्षित कोडिंग और बैकएंड के लिए OWASP के शीर्ष 10 सीखें — निःशुल्क

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

पाठ्यक्रम: 12
पाठ: 48

निःशुल्क सीखना शुरू करें पूरा पाठ्यक्रम देखें

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

क्या “उन्नत एसक्यूएलआई और NoSQLi तकनीकें” पाठ निःशुल्क है?

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

“उन्नत एसक्यूएलआई और NoSQLi तकनीकें” में मैं क्या सीखूँगा?

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

क्या सुरक्षित कोडिंग और बैकएंड के लिए OWASP के शीर्ष 10 शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?

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

“उन्नत एसक्यूएलआई और NoSQLi तकनीकें” पाठ पूरा करने में कितना समय लगता है?

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

क्या मैं इस सुरक्षित कोडिंग और बैकएंड के लिए OWASP के शीर्ष 10 पाठ में कोड लिख और चला सकता हूँ?

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

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

उन्नत एसक्यूएलआई और NoSQLi तकनीकें
व्यापक इनपुट सत्यापन रणनीतियाँ
बैकएंड के लिए कंटेंट सिक्योरिटी पॉलिसी (CSP)
कमांड और LDAP इंजेक्शन की रोकथाम

← सुरक्षित कोडिंग और बैकएंड के लिए OWASP के शीर्ष 10 पर वापस जाएँ