इनपुट वैलिडेशन, सैनिटाइज़ेशन और इंजेक्शन अटैक से बचाव

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

ड्राफ़्ट

जब हमलावर किसी फ़ॉर्म को निशाना बनाते हैं, तो वे उसे सामान्य तरीके से नहीं भरते। वे ऐसा कोड भेजते हैं जो आपके सिस्टम में घुसने या डेटा चुराने के लिए बनाया गया हो। वे विज़िटर के ब्राउज़र में चलने वाला JavaScript, आपका डेटाबेस तोड़ने वाले SQL कमांड, या नुकसान पहुंचाने वाला कंटेंट सबमिट कर सकते हैं। इनपुट वैलिडेशन और सैनिटाइज़ेशन वे सुरक्षा उपाय हैं जो इन हमलों को रोकते हैं।

आप क्या सीखेंगे: इनपुट वैलिडेशन और सैनिटाइज़ेशन क्या हैं, इनमें क्या फ़र्क है, इंजेक्शन अटैक कैसे काम करते हैं, अलग-अलग तरह के डेटा के लिए कौन-सी सुरक्षा काम करती है, और अपने फ़ॉर्म पर इन्हें कैसे लागू करें।

इनपुट वैलिडेशन क्या है?

इनपुट वैलिडेशन यह जांचने की प्रक्रिया है कि आपके फ़ॉर्म में सबमिट किया गया डेटा आपकी उम्मीद के फ़ॉर्मेट में है और आपकी शर्तें पूरी करता है। यह गलत इनपुट के खिलाफ़ सुरक्षा की पहली लाइन है।

वैलिडेशन ऐसे सवालों के जवाब देता है: क्या यह ईमेल एड्रेस है या कोई भी टेक्स्ट, क्या यह नंबर है या शब्द, क्या यह फ़ील्ड खाली है जबकि उसे खाली नहीं होना चाहिए, और क्या विज़िटर ने इस फ़ील्ड के लिए सही चीज़ लिखी है या कुछ संदिग्ध।

वैलिडेशन क्या जांचता है, इसके उदाहरण:

  • ईमेल फ़ील्ड में @ चिह्न और डोमेन होना चाहिए
  • फ़ोन नंबर फ़ील्ड में सिर्फ़ अंक और हाइफ़न होने चाहिए
  • नंबर फ़ील्ड में अक्षर नहीं होने चाहिए
  • ज़रूरी फ़ील्ड खाली नहीं होनी चाहिए
  • पासवर्ड फ़ील्ड में न्यूनतम लंबाई की शर्त पूरी होनी चाहिए

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

इनपुट सैनिटाइज़ेशन क्या है?

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

सैनिटाइज़ेशन क्या करता है, इसके उदाहरण:

  • टेक्स्ट फ़ील्ड से `<script>` और `<img>` जैसे HTML टैग हटाता है
  • डेटाबेस में घुसने के लिए इस्तेमाल हो सकने वाले SQL के खास कैरेक्टर हटाता है
  • खास कैरेक्टर को एस्केप करता है ताकि उन्हें कोड नहीं, टेक्स्ट माना जाए
  • बफ़र ओवरफ़्लो अटैक रोकने के लिए इनपुट की लंबाई सीमित करता है

वैलिडेशन और सैनिटाइज़ेशन साथ काम करते हैं, लेकिन उनके मकसद अलग हैं। वैलिडेशन जांचता है कि डेटा सही फ़ॉर्मेट में है। सैनिटाइज़ेशन फ़ॉर्मेट सही होने पर भी हर खतरनाक चीज़ हटा देता है।

इंजेक्शन अटैक कैसे काम करते हैं

SQL इंजेक्शन

SQL इंजेक्शन अटैक तब होता है जब हमलावर फ़ॉर्म फ़ील्ड में SQL कोड डाल देता है। अगर आपका फ़ॉर्म कोड इस इनपुट को सैनिटाइज़ नहीं करता, तो वह SQL कोड आपके डेटाबेस पर चल जाता है।

उदाहरण: लॉगिन फ़ॉर्म ईमेल एड्रेस मांगता है। अपना ईमेल देने की जगह हमलावर यह सबमिट करता है:

' OR '1'='1

अगर आपका फ़ॉर्म इसे सैनिटाइज़ नहीं करता, तो आपका कोड कुछ ऐसी SQL क्वेरी चला सकता है:

SELECT * FROM users WHERE email = '' OR '1'='1'

`OR '1'='1'` वाला हिस्सा शर्त को हमेशा सही बना देता है, इसलिए क्वेरी उस ईमेल वाले एक यूज़र की जगह सारे यूज़र लौटा देती है। अब हमलावर ने लॉगिन सिस्टम को बायपास कर दिया है।

क्रॉस-साइट स्क्रिप्टिंग (XSS)

XSS अटैक तब होता है जब हमलावर फ़ॉर्म फ़ील्ड में JavaScript कोड सबमिट करता है। अगर फ़ॉर्म इस कोड को सैनिटाइज़ नहीं करता और स्टोर कर लेता है, तो बाद में जो भी वह डेटा देखता है, उसके ब्राउज़र में वह JavaScript चल जाता है।

उदाहरण: एक कमेंट फ़ॉर्म यूज़र के कमेंट लेता है। हमलावर यह सबमिट करता है:

<script>alert('hacked')</script>

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

कमांड इंजेक्शन

अगर आपके फ़ॉर्म का डेटा सिस्टम कमांड में इस्तेमाल होता है (कुछ बैकएंड सिस्टम में ऐसा होता है), तो हमलावर ऑपरेटिंग सिस्टम के कमांड इंजेक्ट कर सकता है।

उदाहरण: एक फ़ॉर्म फ़ील्ड ऐसे कमांड में इस्तेमाल होती है:

ffmpeg -i $filename output.mp4

अगर `$filename` सैनिटाइज़ नहीं है और हमलावर `;rm -rf /` सबमिट कर दे, तो कमांड बन जाता है:

ffmpeg -i ;rm -rf / output.mp4

`rm -rf /` कमांड चलता है और सिस्टम की फ़ाइलें डिलीट कर देता है। इसीलिए सिस्टम कमांड को कभी भी बिना सैनिटाइज़ किया हुआ यूज़र इनपुट नहीं मिलना चाहिए।

अलग-अलग तरह के डेटा के लिए वैलिडेशन और सैनिटाइज़ेशन

ईमेल एड्रेस

वैलिडेशन: जांचें कि इनपुट ईमेल पैटर्न से मेल खाता है (कुछ ऐसा: text@domain.extension)। पक्का करें कि उसमें सिर्फ़ मान्य कैरेक्टर हैं।

सैनिटाइज़ेशन: कोई भी HTML टैग या खास कैरेक्टर हटा दें। सिर्फ़ अक्षर-अंक, डॉट, हाइफ़न और @ चिह्न रखें।

फ़ोन नंबर

वैलिडेशन: जांचें कि उसमें सिर्फ़ अंक, हाइफ़न, कोष्ठक और स्पेस हैं। देखें कि लंबाई उस देश के हिसाब से सही है जिसकी उम्मीद है।

सैनिटाइज़ेशन: हाइफ़न और कोष्ठक को छोड़कर बाकी सारे गैर-अंक कैरेक्टर हटा दें। ज़रूरत हो तो शुरुआती ज़ीरो या स्पेस हटा दें।

टेक्स्ट फ़ील्ड (कमेंट, नाम, पते)

वैलिडेशन: जांचें कि फ़ील्ड खाली नहीं है और लंबाई वाजिब है (लाखों कैरेक्टर नहीं)।

सैनिटाइज़ेशन: HTML टैग, JavaScript और SQL के खास कैरेक्टर हटाएं या एस्केप करें। सिर्फ़ सादा टेक्स्ट और बुनियादी विराम चिह्न रखें।

नंबर और रकम

वैलिडेशन: जांचें कि इनपुट एक नंबर है। कीमत या मात्रा के लिए जांचें कि वह धनात्मक नंबर है।

सैनिटाइज़ेशन: कोई भी गैर-अंक कैरेक्टर हटा दें। ज़रूरत हो तो सही दशमलव स्थानों तक राउंड करें।

पासवर्ड

वैलिडेशन: न्यूनतम लंबाई जांचें (कम से कम 8 कैरेक्टर), और चाहें तो अपरकेस, लोअरकेस, नंबर और सिंबल का मिश्रण ज़रूरी करें।

सैनिटाइज़ेशन: पासवर्ड से कैरेक्टर न हटाएं और न उसे बदलें। उन्हें ठीक उसी रूप में स्टोर करें (हैश करके, कभी सादे टेक्स्ट में नहीं)। अगर आप पासवर्ड से कैरेक्टर हटा देंगे, तो यूज़र लॉग इन नहीं कर पाएंगे।

फ़ाइल अपलोड

वैलिडेशन: जांचें कि फ़ाइल का टाइप वही है जिसकी उम्मीद है (जैसे सिर्फ़ PDF फ़ाइलें, सिर्फ़ इमेज)। जांचें कि फ़ाइल का साइज़ बहुत बड़ा नहीं है।

सैनिटाइज़ेशन: फ़ाइल का नाम बदल दें ताकि हमलावर खास फ़ाइल नामों का फ़ायदा न उठा सकें। फ़ाइल को मैलवेयर के लिए स्कैन करें। उसे वेब रूट के बाहर स्टोर करें ताकि वह कोड की तरह चलाई न जा सके।

वैलिडेशन और सैनिटाइज़ेशन कैसे लागू करें

क्लाइंट-साइड (ब्राउज़र में)

विज़िटर को तुरंत फ़ीडबैक देने के लिए HTML5 इनपुट वैलिडेशन एट्रिब्यूट इस्तेमाल करें:

<input type="email" name="email" required> <input type="tel" name="phone" pattern="[0-9]{10}"> <input type="number" name="age" min="0" max="120">

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

सर्वर-साइड (आपके सर्वर पर)

असली सुरक्षा यहीं होती है। आपके बैकएंड कोड को हर डेटा का वैलिडेशन और सैनिटाइज़ेशन करना होगा:

// Pseudo-code example if (email does not match email pattern) { reject the submission } // Remove HTML tags sanitized_comment = remove_html_tags(comment_text) // Escape special characters for database safe_name = escape_sql_characters(user_name) // Only then store the data store_in_database(safe_name, sanitized_comment)

डेटाबेस के लिए पैरामीटराइज़्ड क्वेरी इस्तेमाल करें

SQL इंजेक्शन के खिलाफ़ सबसे अच्छा बचाव पैरामीटराइज़्ड क्वेरी (प्रिपेयर्ड स्टेटमेंट) हैं। यूज़र इनपुट को सीधे SQL क्वेरी में डालने की जगह आप प्लेसहोल्डर इस्तेमाल करते हैं और डेटा अलग से भेजते हैं:

// Bad (vulnerable): query = "SELECT * FROM users WHERE email = '" + email + "'" // Good (safe): query = "SELECT * FROM users WHERE email = ?" execute(query, [email])

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

लाइब्रेरी और फ़्रेमवर्क इस्तेमाल करें

सैनिटाइज़ेशन का कोड शुरू से खुद न लिखें। इसी काम के लिए बनी, जानी-मानी लाइब्रेरी इस्तेमाल करें। PHP में htmlspecialchars() या HTML Purifier जैसी लाइब्रेरी इस्तेमाल करें। Python में `html` मॉड्यूल या bleach जैसी लाइब्रेरी इस्तेमाल करें। Node.js में `express-validator` या उसी जैसी कोई लाइब्रेरी इस्तेमाल करें। इन लाइब्रेरी को टेस्ट किया गया है और नए तरह के हमलों से निपटने के लिए इन्हें अपडेट किया जाता है।

वैलिडेशन और सैनिटाइज़ेशन की आम गलतियां

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

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

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

दिखाए जाने वाले डेटा को सैनिटाइज़ करना भूल जाना। डेटा सुरक्षित तरीके से स्टोर हो, तब भी अगर आप उसे वेब पेज पर HTML एस्केप किए बिना दिखाते हैं, तो हमलावर ऐसा कोड डाल सकते हैं जो वह डेटा देखने वाले विज़िटर के ब्राउज़र में चल जाए।

गलत क्रम में सैनिटाइज़ करना। पहले वैलिडेट करें (क्या यह सही फ़ॉर्मेट है?), फिर सैनिटाइज़ करें (क्या यह सुरक्षित है?)। अगर आप पहले सैनिटाइज़ करके फिर वैलिडेट करेंगे, तो हो सकता है आप ऐसा डेटा रिजेक्ट कर दें जो असल में सुरक्षित था।

अपने फ़ॉर्म में इनपुट वैलिडेशन

अपने फ़ॉर्म में सिर्फ़ वही जानकारी मांगें जिसकी आपको ज़रूरत है, हर फ़ील्ड का टाइप सोच-समझकर चुनें, और ऊपर बताए वैलिडेशन और सैनिटाइज़ेशन सर्वर पर लागू करें।

WEMASY के प्लान और कीमतों के लिए प्राइसिंग पेज देखें।

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

क्या मैं वैलिडेशन की जगह WAF (वेब एप्लिकेशन फ़ायरवॉल) इस्तेमाल कर सकता हूं?
WAF कुछ इंजेक्शन अटैक को आपके फ़ॉर्म तक पहुंचने से पहले पकड़ सकता है, जो मददगार है। लेकिन यह वैलिडेशन और सैनिटाइज़ेशन का विकल्प नहीं है। WAF सुरक्षा की दूसरी लाइन है। आपके फ़ॉर्म कोड को फिर भी खुद डेटा वैलिडेट और सैनिटाइज़ करना होगा। WAF और इनपुट वैलिडेशन दोनों इस्तेमाल करने से आपको सुरक्षा की कई परतें मिलती हैं।
अगर किसी विज़िटर को सही वजह से खास कैरेक्टर सबमिट करने पड़ें तो?
एपॉस्ट्रोफ़ी, हाइफ़न और एम्परसेंड जैसे खास कैरेक्टर तब सुरक्षित हैं जब आप सही तरह से सैनिटाइज़ करें। उदाहरण के लिए, किसी का नाम "O'Brien" या "Mary-Jane" हो सकता है। इन्हें स्वीकार करना सुरक्षित है, अगर आप इन्हें अपने डेटाबेस के लिए सही तरह से एस्केप करें (पैरामीटराइज़्ड क्वेरी से) और दिखाते समय भी (HTML एस्केपिंग से)। असली बात सही सैनिटाइज़ेशन है, कैरेक्टर को ब्लॉक करना नहीं।
क्या मुझे क्लाइंट और सर्वर दोनों पर वैलिडेट करना चाहिए?
हां। क्लाइंट-साइड वैलिडेशन विज़िटर को तुरंत फ़ीडबैक देता है और अनुभव बेहतर करता है (सबमिट करने से पहले ही उन्हें अपनी टाइपिंग की गलती पता चल जाती है)। हमलावरों से असली सुरक्षा सर्वर-साइड वैलिडेशन देता है। दोनों परतें इस्तेमाल करें। क्लाइंट-साइड UX के लिए है। सर्वर-साइड सुरक्षा के लिए है।
एस्केपिंग और सैनिटाइज़ेशन में क्या फ़र्क है?
एस्केपिंग खतरनाक कैरेक्टर को ऐसे बदल देती है कि उन्हें सादा टेक्स्ट माना जाए (जैसे < को < में बदलना)। सैनिटाइज़ेशन खतरनाक कंटेंट को पूरी तरह हटा देता है (जैसे सारे HTML टैग निकाल देना)। एस्केपिंग डेटा रखती है, सैनिटाइज़ेशन खतरे को हटाता है। ज़्यादातर फ़ॉर्म डेटा के लिए सैनिटाइज़ेशन (टैग पूरी तरह हटाना) एस्केपिंग (उन्हें बदलना) से ज़्यादा सुरक्षित है।
क्या रीड-ओनली फ़ॉर्म पर इंजेक्शन अटैक की चिंता करनी चाहिए?
अगर कोई फ़ॉर्म सिर्फ़ जानकारी दिखाता है (कुछ सबमिट नहीं करता), तो उसमें इंजेक्शन की कमज़ोरी नहीं होती। लेकिन अगर वह फ़ॉर्म कभी यूज़र का सबमिट किया हुआ डेटा दिखाता है, तो आपको फिर भी सैनिटाइज़ करना होगा। हो सकता है हमलावर ने पहले कोई खराब कोड सबमिट किया हो, और जब आप उसे दिखाएंगे तो वह कोड चल जाएगा। फ़ॉर्म का टाइप कोई भी हो, यूज़र का सबमिट किया हुआ कोई भी डेटा दिखाने से पहले उसे हमेशा सैनिटाइज़ करें।
यह भी पढ़ें

और पढ़ें: फ़ॉर्म के बारे में सब कुछ

इसे अभी आज़माएँ
अपनी खुद की वेबसाइट पर।

WEMASY के साथ मुफ़्त शुरू करें और कुछ ही मिनटों में अपनी साइट बनाएँ।