मैंने पढ़ा है कि एसक्यूएल इंजेक्शन को रोकने के लिए किसी को प्रीपेयरस्टेटमेंट का उपयोग करना होगा।
क्या इसका मतलब यह है कि यदि मैं perparedStatement का उपयोग कर रहा हूं तो कोई भी मेरे किसी भी पृष्ठ में SQL इंजेक्शन नहीं कर सकता है? क्या यह एसक्यूएल इंजेक्शन के खिलाफ मूर्खतापूर्ण है? यदि नहीं तो कृपया इसे प्रदर्शित करने के लिए कुछ उदाहरण दें।क्या तैयार स्टेटमेंट का मतलब है कि कोई एसक्यूएल इंजेक्शन नहीं होगा?
जब तक आप वास्तव में तैयार कथन की पैरामीटर प्रतिस्थापन सुविधा का उपयोग कर रहे हैं (उन्हें दुरुपयोग करना संभव है और उस सुविधा का उपयोग न करें), और बशर्ते तैयार कथन लाइब्रेरी में कोई बग न हो , तो आप कच्चे एसक्यूएल इंजेक्शन के खिलाफ ठीक होना चाहिए। इसका मतलब यह नहीं है कि आपको जो कुछ भी उपयोगकर्ता आपको संदेह के साथ देता है, उसका इलाज नहीं करना चाहिए। :-)
हालांकि तैयार वक्तव्य एसक्यूएल इंजेक्शन के खिलाफ बचाव में मदद करता है, तैयार वक्तव्य के अनुचित उपयोग के माध्यम से एसक्यूएल इंजेक्शन हमलों की संभावनाएं हैं।
नीचे दिया गया उदाहरण ऐसे परिदृश्य को बताता है जहां इनपुट चर सीधे तैयार वक्तव्य में पारित होते हैं और इस प्रकार एसक्यूएल इंजेक्शन हमलों के लिए रास्ता तय करते हैं।
String strUserName = request.getParameter("Txt_UserName");
PreparedStatement prepStmt = con.prepareStatement("SELECT * FROM user WHERE userId = '+strUserName+'");
तैयार बयान एसक्यूएल इंजेक्शन के लिए असुरक्षित हो सकता है अगर यह ठीक से नहीं किया गया है।
प्रदान की गई भाषा की तैयार कथन सुविधा का उपयोग करना मतलब है कि आप समस्या के लिए एक परीक्षण और परीक्षण समाधान का उपयोग कर रहे हैं - इसका मतलब यह नहीं है कि SQL इंजेक्शन संभावनाओं के लिए कभी भी कोई भी बग या गुंजाइश नहीं है, लेकिन इसका क्या अर्थ है क्या आप कार्यान्वयन का उपयोग कर एकमात्र व्यक्ति नहीं हैं। कुछ लोगों के लिए एक ही कार्यान्वयन का उपयोग करने वाले अधिकतर लोगों का मतलब है कि बग्स को ढूंढने और समाप्त करने की संभावना अधिक होती है - यदि आप अपने स्वयं के कार्यान्वयन का उपयोग करते हैं तो केवल आप ही बग ढूंढ और ठीक कर सकते हैं।
तो नकारात्मक रेटिंग क्यों? मेरे उत्तर के बारे में क्या झूठी या भ्रामक है?ढांचे का उपयोग करने के बारे में संपूर्ण बिंदु यह है कि इसका व्यापक रूप से उपयोग किया जाता है - मुद्दों को ढूंढने और तय करने के लिए अधिक संभावनाएं, अधिक संभावना है कि आप ढांचे के माध्यम से जो कोड ले रहे हैं, वह साबित हुआ है। आपका स्वयं का कोड केवल स्वयं ही साबित हो सकता है, और इस प्रकार अन्य कार्यान्वयन की तुलना में आप नुकसान पहुंचा सकते हैं। तो मेरे रुख के साथ क्या गलत है? – Moo
तैयार वक्तव्य क्वेरी के गैर-डेटा भागों - पहचानकर्ताओं और ऑपरेटरों को शामिल नहीं करते हैं।
इस प्रकार, यदि उनमें से कुछ परिवर्तनीय हैं और सीधे क्वेरी में जोड़ा जा रहा है, तो इंजेक्शन संभव है।
सीमित विकल्पों की सीमित संख्या के लिए धन्यवाद, सभी परिवर्तनीय पहचानकर्ताओं को उपयोगकर्ता इनपुट के आधार पर पूर्व-लिखित रूपों से चुना जाना चाहिए। ऑपरेटरों के लिए भी वही।
कोई उपयोगकर्ता इनपुट सीधे क्वेरी में जोड़ा जाना चाहिए।
संक्षिप्त उत्तर: हाँ, अगर सही तरीके से उपयोग किया जाता है।
हालांकि, इसका मतलब यह नहीं है कि जेडीबीसी ड्राइवर में बग्स नहीं हो सकते हैं, जो एसक्यूएल इंजेक्शन के लिए खुलता है। जब मैंने उस कंपनी के लिए देखा जिस पर मैंने काम किया, मैंने पाया कि वास्तव में एक जेडीबीसी ड्राइवरों में से एक में एक एसक्यूएल इंजेक्शन बग था जिसे हमने (PostgreSQL) इस्तेमाल किया था। यह कुछ साल पहले है, और बग तय किया गया था।
हालांकि मुझे विशिष्टताओं को याद नहीं है, मुझे याद है कि जेडीबीसी कार्यान्वयन के लिए स्रोत कोड को देखते हुए, और यह देखते हुए कि इसे स्ट्रिंग कॉन्सटेनेशन के साथ लागू किया गया था।
मैं अपेक्षा करता हूं कि यह दुर्लभ हो, हालांकि, और मेरी सलाह कार्यान्वयन पर भरोसा करना और तैयार किए गए स्तरों का सही ढंग से उपयोग करना होगा।
मैं इसे तैयार करने के रूप में नहीं मानूंगा, भले ही यह con.preparedStatement कहता है। –
@ राकेश: हाँ, लेकिन आप आश्चर्यचकित होंगे ... :-) –