इंजेक्शन रोकने के लिए इनपुट मान्य करें

क्लाइंट द्वारा भेजी गई हर वैल्यू हानिकारक हो सकती है। सभी इनपुट को अविश्वसनीय मानना वह दृष्टिकोण है जो अधिकांश हमलों को रोकता है।

इंजेक्शन तब होता है जब उपयोगकर्ता के इनपुट को कोड या कमांड समझ लिया जाता है। हमलावर किसी क्वेरी या शेल में निर्देश छिपा देता है।

इनपुट को सीधे SQL में चिपकाना सामान्य गलती है। किसी विशेष रूप से बनाए गए मान से आपकी क्वेरी बदली जा सकती है और पूरी तालिका निकाली जा सकती है।

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

SQLAlchemy के साथ आप filter_by और बंधे हुए मानों का उपयोग करते हैं, इसलिए क्वेरी डिफ़ॉल्ट रूप से पैरामीटरयुक्त होती हैं और इंजेक्शन बहुत कठिन हो जाता है।

उपयोग करने से पहले जाँचें कि इनपुट आपकी अपेक्षा के अनुरूप है। प्रकार और सीमा की पुष्टि करें, ताकि जहाँ संख्या चाहिए वहाँ स्ट्रिंग न आ जाए।

हर गलत मान का पीछा करने के बजाय स्वीकार किए जाने वाले कुछ मानों की सूची बनाना बेहतर है। अनुमति-सूची उन सभी चीज़ों को अस्वीकार करती है जिन्हें आपने स्पष्ट रूप से अनुमति नहीं दी।

Marshmallow जैसी स्कीमा लाइब्रेरी फ़ील्ड की जाँच आपके लिए करती है। जब पेलोड का आकार गलत होता है, तो यह ValidationError उत्पन्न करती है।

इंजेक्शन HTML में भी पहुँच सकता है। Jinja2 का autoescaping उपयोगकर्ता के पाठ को सुरक्षित वर्णों में बदल देता है, ताकि पृष्ठ पर स्क्रिप्ट न चल सकें।

सामग्री को safe फ़िल्टर से चिह्नित करने पर एस्केपिंग बंद हो जाती है। ऐसा केवल उस पाठ के लिए करें जिस पर आपको पूरा भरोसा हो, कच्चे उपयोगकर्ता इनपुट के लिए कभी नहीं।

डेटा आते ही, आपके तर्क तक पहुँचने से पहले उसका सत्यापन करें। 400 के साथ fast विफलता खराब इनपुट को फैलने से रोकती है।

आपने इनपुट पर अविश्वास करना, पैरामीटरयुक्त क्वेरी से SQL इंजेक्शन रोकना, स्कीमा से सत्यापन करना, मानों के लिए अनुमति-सूची बनाना और आउटपुट एस्केप करना सीखा। सुरक्षा का ठोस काम!