2008-09-16 19 views
12

यदि किसी SQL क्वेरी से मैं सभी 'वर्णों को हटा देता हूं, तो क्या डेटाबेस पर SQL इंजेक्शन हमला करने का कोई अन्य तरीका है?क्या 'अक्षर हटा दिया गया है, भले ही SQL को इंजेक्ट करने का कोई तरीका है?

यह कैसे किया जा सकता है? क्या कोई मुझे उदाहरण दे सकता है?

उत्तर

23

हाँ, वहां है। से Wikipedia

"SELECT * FROM data WHERE id = " + a_variable + ";"

यह इस बयान है कि लेखक एक नंबर "आईडी" क्षेत्र के लिए सम्बंधित होने के लिए a_variable इरादा से स्पष्ट है एक अंश। हालांकि, अगर यह वास्तव में एक स्ट्रिंग है तो अंतिम उपयोगकर्ता कथन में हेरफेर कर सकता है जैसा कि वे चुनते हैं, जिससे बचने वाले पात्रों की आवश्यकता को छोड़ दिया जाता है। उदाहरण के लिए,

1;DROP TABLE users

को a_variable की स्थापना, डेटाबेस से छोड़ देंगे (हटाना) "उन" तालिका के बाद से एसक्यूएल प्रदान की जा देंगी:

SELECT * FROM DATA WHERE id=1;DROP TABLE users;

एसक्यूएल इंजेक्शन है लड़ने के लिए एक साधारण हमला नहीं है। अगर मैं आप थे तो मैं बहुत सावधान अनुसंधान करूंगा।

+0

यह ध्यान दिया जाना चाहिए कि केवल तब होता है जब आपका सिस्टम आपको एक साथ कई SQL क्वेरी निष्पादित करने की अनुमति देता है। PHP का 'mysql_query' नहीं है। – DisgruntledGoat

15

हां, आप जिस कथन का उपयोग कर रहे हैं उसके आधार पर। आप संग्रहीत प्रक्रियाओं, या कम से कम पैरामीटर किए गए प्रश्नों का उपयोग कर स्वयं को सुरक्षित रखने से बेहतर हैं।

रोकथाम नमूनों के लिए WikiPedia देखें।

+0

यदि मैं आपको 1 क्वाड्रिलियन बार संशोधित कर सकता हूं, तो मैं चाहता हूं। जब तक आप पैरामीटर को प्रदान करने वाले ड्राइवर/लाइब्रेरी को लिख नहीं रहे हैं, तो मैं SQL इंजेक्शन से सुरक्षा के लिए कुछ और भी विचार करने के लिए _any_ कारण के बारे में नहीं सोच सकता। –

2

। । । उह 50000000 के बारे में अन्य तरीकों

शायद 5; drop table employees; --

एसक्यूएल जिसके परिणामस्वरूप तरह somthing कुछ की तरह हो सकता है: select * from somewhere where number = 5; drop table employees; -- and sadfsf

0

यह कैसे आप एक साथ क्वेरी डाल पर निर्भर करता है (-- एक टिप्पणी शुरू होता है), लेकिन संक्षेप में हाँ।

उदाहरण के लिए, जावा में आप इस (जानबूझ कर प्रबल उदाहरण) करने के लिए थे:

String query = "SELECT name_ from Customer WHERE ID = " + request.getParameter("id"); 

फिर वहाँ एक अच्छा मौका है आप अपने आप को एक इंजेक्शन हमले करने के लिए खोल रहे हैं है।

जावा के पास कुछ उपयोगी उपकरण हैं, जैसे कि प्रीपेडस्टेटमेंट्स (जहां आप एक स्ट्रिंग में पास करते हैं जैसे "ग्राहक कहां आईडी से चयन करें_?" और जेडीबीसी परत हैंडल आपके लिए टोकन को बदलते समय भागते हैं) लेकिन कुछ अन्य भाषाएं इसके लिए बहुत उपयोगी नहीं हैं।

1

हाँ, बिल्कुल: अपने एसक्यूएल बोली और इस तरह के आधार पर, वहाँ इंजेक्शन कि apostrophe का उपयोग नहीं करते प्राप्त करने के लिए कई तरीके हैं।

एसक्यूएल इंजेक्शन हमलों के खिलाफ केवल विश्वसनीय रक्षा पैरामिट्रीकृत SQL विवरण समर्थन अपने डेटाबेस इंटरफ़ेस द्वारा की पेशकश का उपयोग कर रहा है।

0

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

\;.*--\ 

एक अर्द्ध समय से पहले ही वास्तविक बयान समाप्त करने के लिए प्रयोग किया जाता है पेट, कुछ इंजेक्शन एक डबल हाइफन के बाद एसक्यूएल मूल वास्तविक बयान से पीछे एसक्यूएल बाहर टिप्पणी करने के लिए: क्या आप देख रहे हैं की तरह एक regex पैटर्न है। हमले में हाइफ़न छोड़े जा सकते हैं।

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

1

इसके बजाय यह पता लगाने की कोशिश कर रहा है कि कौन से पात्रों को फ़िल्टर करना है, मैं इसके बजाय parametrized प्रश्नों के साथ चिपके रहूंगा, और समस्या को पूरी तरह से हटा दूंगा।

6

हां, यह निश्चित रूप से संभव है।

आप एक रूप है जहाँ आप एक पूर्णांक अपने अगले SELECT कथन करने की अपेक्षा है, तो आप समान कुछ भी लिख सकते हैं:

चुनें * thingy से कहां attributeID =

  • 5 (अच्छा जवाब है, कोई समस्या नहीं)
  • 5; डीआरओपी तालिका users; (बुरा, बुरा, बुरा ...)

निम्नलिखित वेबसाइट का विवरण शास्त्रीय एसक्यूएल इंजेक्शन टेक्निक्स: SQL Injection cheat sheet है।

पैरामीट्रिज्ड प्रश्नों या संग्रहीत प्रक्रियाओं का उपयोग करना बेहतर नहीं है। ये पास पैरामीटर का उपयोग कर पूर्व-निर्मित प्रश्न हैं, जो इंजेक्शन का स्रोत भी हो सकते हैं। यह इस पृष्ठ पर भी वर्णित है: Attacking Stored Procedures in SQL

अब, अगर आप सरल बोली को दबाने, आप का दौरा पड़ने से केवल एक सेट को रोकने के। पर उनमें से सभी नहीं।

हमेशा के रूप में, बाहर से आने वाले डेटा पर भरोसा न करें। उन्हें इन 3 स्तरों पर फ़िल्टर करें:

  • स्पष्ट सामान के लिए इंटरफ़ेस स्तर (एक बूंद नीचे चयन सूची एक नि: शुल्क पाठ क्षेत्र से बेहतर है) डेटा प्रकृति से संबंधित जांच के लिए
  • तार्किक स्तर (पूर्णांक, स्ट्रिंग, लंबाई) , अनुमतियाँ (डेटा के इस प्रकार इस पेज पर इस उपयोगकर्ता द्वारा इस्तेमाल किया जा सकता) ...
  • डाटाबेस पहुँच स्तर (भागने सरल बोली ...)।

मज़े और भूलने के जवाब के लिए WikiPedia जाँच करने के लिए नहीं है।

/सर्वेक्षण

+0

सिर्फ एक नोट है कि डोमेन "एसक्यूएल में हमले की गई प्रक्रियाओं पर हमला" लेख होस्ट करने वाला डोमेन अब निष्क्रिय हो रहा है। – Funka

2

Also- आपको केवल apostrophe के लिए लग रहे हो, तो आप उसे नहीं निकालना चाहते हैं। आप से बचने के लिए चाहते हैं। आप दो एस्ट्रोफ़ेस के साथ प्रत्येक एस्ट्रोफ़ेस को बदलकर ऐसा करते हैं।

लेकिन पैरामिट्रीकृत प्रश्नों के लिए/संग्रहित प्रक्रियाओं इतना बेहतर हैं।

3

Parameterized इनलाइन एसक्यूएल या पैरामिट्रीकृत संग्रहित प्रक्रियाओं अपनी सुरक्षा करने का सबसे अच्छा तरीका है।जैसा कि अन्य ने इंगित किया है, केवल एकल उद्धरण चरित्र को अलग करना/भागना पर्याप्त नहीं है।

आप देखेंगे कि मैं विशेष रूप से संग्रहीत प्रक्रियाओं के "पैरामीटर" के बारे में बात करता हूं। बस एक संग्रहीत प्रक्रिया का उपयोग करना पर्याप्त नहीं है या तो यदि आप प्रक्रिया के पारित पैरामीटर को एकसाथ जोड़ने के लिए वापस आते हैं। दूसरे शब्दों में, एक संग्रहीत प्रक्रिया में सटीक वही कमजोर SQL कथन लपेटने से यह कोई सुरक्षित नहीं होता है। आपको अपनी संग्रहीत प्रक्रिया में पैरामीटर का उपयोग करने की आवश्यकता है जैसे आप इनलाइन एसक्यूएल के साथ करेंगे।

0

मैं केवल दोहरा सकता हूं जो दूसरों ने कहा है। Parametrized एसक्यूएल जाने का रास्ता है। निश्चित रूप से, यह बट कोडिंग में थोड़ा दर्द है - लेकिन एक बार जब आप इसे एक बार कर लेंगे, तो उस कोड को काटकर चिपकाना मुश्किल नहीं है, और आपको आवश्यक संशोधन करना मुश्किल नहीं है। हमारे पास बहुत सारे .NET अनुप्रयोग हैं जो वेब साइट आगंतुकों को खोज मानदंडों की पूरी श्रृंखला निर्दिष्ट करने की अनुमति देते हैं, और कोड फ्लाई पर SQL चयन कथन बनाता है - लेकिन उपयोगकर्ता द्वारा दर्ज की जा सकने वाली प्रत्येक चीज़ पैरामीटर में जाती है।

6

मेरा सुझाव है कि आप चर के रूप में चर को पास करें, और अपना स्वयं का एसक्यूएल बनाएं। अन्यथा ऐसे तरीकों से एसक्यूएल इंजेक्शन करने का एक तरीका होगा, जो हम वर्तमान में अनजान हैं। आप एक 'उस में साथ मेरे जैसे एक नाम है, तो

' Not Tested 
var sql = "SELECT * FROM data WHERE id = @id"; 
var cmd = new SqlCommand(sql, myConnection); 
cmd.Parameters.AddWithValue("@id", request.getParameter("id")); 

:

कोड आपके द्वारा बनाए गए तो कुछ इस तरह है। यह बहुत परेशान है कि सभी '-characters को हटा दिया गया है या अमान्य के रूप में चिह्नित किया गया है।

आप भी यह Stackoverflow question about SQL Injections देख सकते हैं।

+0

यह निश्चित रूप से एक सर्वोत्तम अभ्यास है –

0

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

यदि आपको आईडी = 1044 की उम्मीद होने पर आईडी = "हैलो" प्राप्त होता है, तो डेटाबेस को एक त्रुटि लौटने की बजाय उपयोगकर्ता को उपयोगी त्रुटि वापस करना हमेशा बेहतर होता है।

2

चूंकि यह अपेक्षाकृत पुराना सवाल है, इसलिए मैं एक पूर्ण और व्यापक उत्तर लिखने से परेशान नहीं हूं, क्योंकि उस उत्तर के अधिकांश पहलुओं का वर्णन एक पोस्टर या किसी अन्य द्वारा किया गया है।
मुझे यह आवश्यक लगता है कि, हालांकि, किसी अन्य मुद्दे को लाने के लिए जो यहां किसी को भी स्पर्श नहीं किया गया - एसक्यूएल स्मगलिंग। कुछ स्थितियों में, यदि आप को निकालने का प्रयास करते हैं, तो भी आपकी क्वेरी में उद्धरण चरित्र को "धुंधला" करना संभव है। वास्तव में, यह संभव हो सकता है भले ही आपने उचित आदेश, पैरामीटर, संग्रहीत प्रक्रियाओं आदि का उपयोग किया हो।

http://www.comsecglobal.com/FrameWork/Upload/SQL_Smuggling.pdf पर पूरा शोध पत्र देखें (प्रकटीकरण, मैं इस पर प्राथमिक शोधकर्ता था) या बस Google "एसक्यूएल स्मगलिंग "।

संबंधित मुद्दे

 संबंधित मुद्दे