Kotlin सुरक्षा: SQL इंजेक्शन और XSS से बचाव का आसान तरीका

शुरुआती लोगों के लिए ऑनलाइन Python प्रशिक्षक

Python आसानी से सीखें बिना सिद्धांत के बोझ के। स्वचालित जांच के साथ व्यावहारिक कार्य हल करें और ब्राउज़र में सीधे कोड लिखें।

पाठ्यक्रम शुरू करें

आपका कोड निशाने पर: Kotlin में सुरक्षा क्यों ज़रूरी है?

\n\n

सोचिए: आपने एक परफेक्ट ऐप बनाया। खूबसूरत इंटरफ़ेस, तेज़ स्पीड, साफ़ आर्किटेक्चर। लेकिन कोड की एक लाइन में एक 'बैकडोर' छिपा है। हैकर सर्च बॉक्स में ' OR '1'='1 टाइप करता है — और आपका डेटाबेस खुला पड़ा है। जाना-पहचाना लगता है? अगर नहीं, तो अच्छा है। लेकिन प्रोडक्शन में आग बुझाने से पहले तैयार रहना बेहतर है।

\n\n

Kotlin एक शक्तिशाली और आधुनिक भाषा है। लेकिन किसी भी दूसरे टूल की तरह, यह आपके कोड को अपने आप सुरक्षित नहीं बनाती। SQL इंजेक्शन और XSS (Cross-Site Scripting) कई सालों से OWASP Top 10 में टॉप पर हैं। और जो Kotlin डेवलपर सोचते हैं 'मैं ORM इस्तेमाल कर रहा हूँ, मुझे कोई खतरा नहीं', वे अक्सर जोखिम में होते हैं।

\n\n

इस आर्टिकल में हम सीखेंगे कि अपने Kotlin कोड को एक अभेद्य किला कैसे बनाएं। कोई बेकार की बात नहीं — सिर्फ प्रैक्टिकल टिप्स, रियल उदाहरण और ऐसे हैक्स जिन्हें आप आज ही अपना सकते हैं।

\n\n

Kotlin में SQL इंजेक्शन: हमले की पहचान और बचाव के तरीके

\n\n

कमजोरी कैसी दिखती है (और यह खतरनाक क्यों है)

\n\n

SQL इंजेक्शन तब होता है जब यूज़र का इनपुट सीधे SQL क्वेरी में चला जाता है। मान लीजिए, आपके पास ऐसा कोड है (ऐसा कभी न करें!):

\n\n

fun getUserById(id: String): User? {\n    val query = "SELECT * FROM users WHERE id = '$id'"\n    val statement = connection.createStatement()\n    val result = statement.executeQuery(query)\n    // ...\n}

\n\n

अगर हैकर id = "1'; DROP TABLE users; --" भेजता है, तो डेटाबेस यह चलाएगा: SELECT * FROM users WHERE id = '1'; DROP TABLE users; --'। और आपके सारे यूज़र गायब हो जाएंगे। हमेशा के लिए।

\n\n

नियम #1: हमेशा पैरामीटराइज़्ड क्वेरी का इस्तेमाल करें

\n\n

यह सबसे बेसिक नियम है। Kotlin (और Java) में PreparedStatement होता है, जो SQL कोड और डेटा को अलग करता है:

\n\n

fun getUserByIdSafe(id: String): User? {\n    val query = "SELECT * FROM users WHERE id = ?"\n    val preparedStatement = connection.prepareStatement(query)\n    preparedStatement.setString(1, id)\n    val result = preparedStatement.executeQuery()\n    // ...\n}

\n\n

डेटाबेस को क्वेरी का टेम्पलेट और डेटा अलग-अलग मिलता है। भले ही id में खतरनाक कोड हो, वह सिर्फ एक स्ट्रिंग की तरह समझा जाएगा, कमांड की तरह नहीं।

\n\n

नियम #2: Exposed या दूसरे ORM का सही इस्तेमाल करें

\n\n

Exposed लाइब्रेरी Kotlin के लिए एक लोकप्रिय विकल्प है। यह सुरक्षित है, अगर आप इसके API का सही इस्तेमाल करें। गलत उदाहरण (कच्चा कॉन्केटनेशन):

\n\n

// बुरा: कमजोर\nval users = transaction {\n    exec("SELECT * FROM users WHERE name = '$userInput'")\n}

\n\n

सही उदाहरण (Exposed DSL का इस्तेमाल):

\n\n

// अच्छा: एस्केपिंग बिल्ट-इन है\nval users = transaction {\n    Users.select { Users.name eq userInput }\n}

\n\n

Exposed में eq ऑपरेटर अपने आप वैल्यू को एस्केप करता है। लेकिन अगर आप exec के ज़रिए कच्ची SQL क्वेरी लिख रहे हैं — तो सावधान रहें।

\n\n

नियम #3: इनपुट वैलिडेशन — आपकी दूसरी ढाल

\n\n

पैरामीटराइज़्ड क्वेरी के बावजूद, डेटाबेस में सब कुछ नहीं डालना चाहिए। Kotlin के बिल्ट-इन टूल्स से चेक करें:

\n\n

fun validateUserId(id: String): Boolean {\n    // चेक करें कि id UUID है या पूर्णांक\n    return id.matches(Regex("^[a-fA-F0-9-]{36}$")) || \n           id.all { it.isDigit() }\n}

\n\n

याद रखें: किसी भी इनपुट पर भरोसा न करें। भले ही वह आपके अपने फ्रंटएंड से आ रहा हो। खासकर अगर वह आपके अपने फ्रंटएंड से आ रहा हो।

\n\n

XSS अटैक: कैसे JavaScript कोड को अपनी साइट पर कब्ज़ा करने से रोकें

\n\n

XSS क्या है और Kotlin आपको अपने आप क्यों नहीं बचाता

\n\n

XSS (Cross-Site Scripting) तब होता है जब हैकर आपके पेज पर एक स्क्रिप्ट डाल देता है। उदाहरण के लिए, कमेंट बॉक्स में वह लिखता है: <script>alert('आपका डेटा चोरी हो गया')</script>