SQL इंजेक्शन से बचाव का एकमात्र तरीका पैराट्राइज्ड प्रश्नों पर निर्भरता है?

Question

मैंने SQL इंजेक्शन के हमलों पर देखा है कि ऐसा लगता है कि पैरामीरिज्ड क्वेरीज़, विशेष रूप से संग्रहीत प्रक्रियाओं में शामिल हैं, ऐसे हमलों से बचाव का एकमात्र तरीका है। जब मैं काम कर रहा था (अंधेरे युग में वापस) संग्रहीत प्रक्रियाओं को खराब अभ्यास के रूप में देखा गया था, मुख्यतः क्योंकि उन्हें कम रखरखाव के रूप में देखा गया था; कम परीक्षण योग्य; अत्यधिक युग्मित; और एक सिस्टम को एक विक्रेता में बंद कर दिया; ( यह प्रश्न कुछ अन्य कारणों को शामिल करता है)।

यद्यपि जब मैं काम कर रहा था, तो परियोजनाएं इस तरह के हमलों की संभावना से लगभग अनजान थीं; विभिन्न प्रकार के भ्रष्टाचार के खिलाफ डेटाबेस को सुरक्षित करने के लिए विभिन्न नियमों को अपनाया गया। इन नियमों को संक्षेप में प्रस्तुत किया जा सकता है:

1. किसी भी क्लाइंट / एप्लिकेशन को डेटाबेस टेबलों तक सीधी पहुंच नहीं थी।
2. सभी तालिकाओं तक सभी पहुंच विचारों के माध्यम से थी (और आधार तालिकाओं के सभी अद्यतन ट्रिगर के माध्यम से किए गए थे)।
3. सभी डेटा आइटम में एक डोमेन निर्दिष्ट था।
4. किसी भी डेटा आइटम को अशक्त होने की अनुमति नहीं दी गई थी - इसका यह अर्थ था कि DBA के अवसर पर उनके दांत पीस रहे थे; लेकिन लागू किया गया था।
5. उदाहरण के लिए, भूमिकाओं और अनुमतियों को उचित रूप से स्थापित किया गया था - डेटा को बदलने का अधिकार केवल विचारों को देने के लिए एक प्रतिबंधित भूमिका।

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

संपादित करें

आरंभिक प्रतिक्रियाओं के प्रकाश में, प्रश्न का जोर थोड़ा बदल गया। आधार प्रश्न अपरिवर्तित है।

EDIT2

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

मेरे प्रश्न में निहित दृष्टिकोण डेटाबेस को "आर्मरिंग" पर आधारित था और मुझे पता नहीं था कि क्या यह एक व्यवहार्य विकल्प था। आगे के शोध ने सुझाव दिया है कि ऐसे दृष्टिकोण हैं। मुझे निम्नलिखित स्रोत मिले हैं जो इस प्रकार के दृष्टिकोण को कुछ संकेत प्रदान करते हैं:

http://database-programmer.blogspot.com

http://thehelsinkideclaration.blogspot.com

इन स्रोतों से मैंने जो सिद्धांत सुविधाएँ ली हैं, वे हैं:

1. एक व्यापक डेटा शब्दकोश, एक व्यापक सुरक्षा डेटा शब्दकोश के साथ संयुक्त
2. डेटा डिक्शनरी से ट्रिगर्स, प्रश्नों और बाधाओं की उत्पत्ति
3. कोड को कम करें और डेटा को अधिकतम करें

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

Comments

मैं संग्रहीत प्रक्रियाओं के विरुद्ध तर्क नहीं खरीदता। वे बस सच नहीं हैं।

— कोनराड रुडोल्फ

नो-नल्स आवश्यकता के साथ क्या हो रहा है?

— मार्क कैनलस

@Konrad Rudolph - यदि आप MySQL पर अपना आवेदन लिखते हैं और फिर DB2 पर माइग्रेट करने का निर्णय लेते हैं, तो क्या आपको वास्तव में लगता है कि संग्रहीत कार्यविधियाँ संगत होंगी? इसी तरह अगर आप SQLLite में माइग्रेट करना चाहते हैं? इसके अलावा, मान लें कि आप अपने OS को अपग्रेड करते हैं - यदि आपकी संग्रहीत प्रक्रियाएँ C (जो वे DB2 में हैं) में संकलित की जाती हैं, तो उन्हें संभवतः सभी की पुन: स्थापना की आवश्यकता होगी। ये उचित तर्क हैं - निरपेक्ष नहीं, बल्कि उचित हैं।

— मैथ्यू फ्लिन

@ मट्टू दुह। मैं वास्तव में "पैराडाइज़्ड क्वेरीज़" के बारे में सोच रहा था जब वह पढ़ रहा था और इसके बारे में टिप्पणी कर रहा था। संग्रहित प्रक्रिया = पूरी story नॉट स्टोरी ’।

— कोनराड रुडोल्फ

Answer 1

संग्रहीत procs इंजेक्शन के खिलाफ स्वचालित रूप से रक्षा नहीं करते हैं। इस बारे में क्या

CREATE PROC proc
  @id VARCHAR(5)
AS
BEGIN
  EXEC("SELECT * FROM Client WHERE ClientId = " + @id);
END

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

Comments

Procs के बजाय पैरामीटर किए गए प्रश्नों पर ध्यान केंद्रित करने के लिए धन्यवाद। हालाँकि, मैं यह पूछ रहा हूं कि क्या डेटाबेस को ऐसे प्रश्नों के अलावा अन्य विधियों द्वारा संरक्षित किया जा सकता है - विशेष विधियों में जो केवल डेटाबेस परत तक ही सीमित हैं।

— क्रिस वाल्टन

+1 इसके अलावा, मैं यह बताना चाहता हूं कि संग्रहित procs को अधिकांशतः सुरक्षित माना जाता है क्योंकि यह उपयोगकर्ताओं को सीधे डेटा एक्सेस करने के तरीके को बनाए रखते हुए सीधे टेबल तक पहुँचने से रोकने का एकमात्र तरीका है। यह पंक्ति-आधारित और स्तंभ-आधारित विशेषाधिकारों को सुनिश्चित करने का एकमात्र तरीका है जब उपयोगकर्ता को अपने क्लाइंट के बीच सीधे डेटाबेस का उपयोग करने की आवश्यकता होती है।

— फाल्कन

@ क्रिस - मुझे लगता है कि क्रेग यहाँ क्या कह रहा है कि आप यह नहीं मान सकते हैं कि प्रॉक्स वास्तव में आपकी रक्षा करते हैं। यह शायद एक पूर्ण उत्तर नहीं है, शीर्षक में धारणा का अधिक सुधार।

— जॉन हॉपकिंस

@ जॉन - मैंने क्रेग सुधार के प्रकाश में, सवाल के शीर्षक को बदल दिया है, और प्रश्न के कुछ संपादन किए हैं। जब तक मुझे जवाब मिलना शुरू नहीं हुआ, मुझे इस सवाल का पता नहीं था।

— क्रिस वाल्टन

क्या क्रेग ऊपर लिखते को सुदृढ़ करने के लिए, को देखने के databasesecurity.com/dbsec/lateral-sql-injection.pdf : "Oracle में भेद्यता का एक नया वर्ग पार्श्व SQL इंजेक्शन"

— ब्रूस Ediger

Answer 2

तो क्या इस तरह के (लागू) नियमों का एक सेट SQL इंजेक्शन हमलों को रोकने में संग्रहीत प्रक्रियाओं के लिए एक उपयुक्त विकल्प है? यदि नहीं, तो क्यों नहीं?

नहीं, क्योंकि वे डेवलपर्स पर भारी जुर्माना लगाते हैं। प्रति-आइटम ब्रेकडाउन:

1. किसी भी क्लाइंट / एप्लिकेशन को डेटाबेस टेबल तक सीधी पहुंच नहीं थी।

भूमिकाओं का उपयोग करें। ग्राहकों को केवल एक सीमित भूमिका के माध्यम से DB को एक्सेस करने में सक्षम होना चाहिए, जिसमें केवल SELECT, INSERT, UPDATE और DELETE का उपयोग उन तालिकाओं (और पंक्तियों, जहाँ संभव हो) तक पहुँच हो, जिनके लिए इसकी पहुँच आवश्यक है। यदि आप यह सुनिश्चित करना चाहते हैं कि कोई भी ग्राहक सभी प्रविष्टियों को स्पैम या हटा नहीं सकता है, तो डेटा संशोधन के लिए एपीआई का उपयोग करें।

2. सभी तालिकाओं तक सभी पहुंच विचारों के माध्यम से थी।

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

3. सभी डेटा आइटम में एक डोमेन निर्दिष्ट था।

बनाए रखने के लिए बहुत काम हो सकता है, और शायद एक अलग तालिका में सामान्यीकृत किया जाना चाहिए।

4. किसी भी डेटा आइटम को अशक्त होने की अनुमति नहीं दी गई थी - इसका यह अर्थ था कि इस अवसर पर उनके दांत पीसने वाले डीबीए थे; लेकिन लागू किया गया था।

यह सिर्फ सादा गलत है। यदि डेवलपर्स NULLआपको संभालने में असमर्थ हैं, तो आपको बड़ी समस्याएं हैं।

क्या डेटाबेस (केवल) विशिष्ट उपायों द्वारा ऐसे हमलों के खिलाफ एक डेटाबेस सुरक्षित किया जा सकता है?

आपको संग्रहीत प्रक्रियाओं की आवश्यकता नहीं है, बस एक फ़ंक्शन के साथ पैराड्राइज्ड प्रश्नों का उपयोग करें जो तर्कों से बचता है, जैसे कि pg_query.params । बेशक, यदि आपका डेटाबेस विश्व लेखन योग्य है या क्लाइंट की भूमिका में हर चीज की पूरी पहुंच है, तो आप वैसे भी खराब हैं। किसी को बस साथ आना होगा और महसूस करना होगा कि ग्राहक क्या कर रहा है, और फिर एक ग्राहक को पांच मिनट में पकाएं जो आपके डीबी को नष्ट कर देता है (या खराब, जहर)।

Comments

डोमेन: en.wikipedia.org/wiki/Data_domain

— Dan McGrath

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

— क्रिस वाल्टन

Answer 3

मुझे यकीन नहीं है कि आपके नियम पूरी तरह से आपकी रक्षा करते हैं।

पहली समस्या यह है कि आप कहते हैं कि वे लागू हैं, लेकिन साथ ही, एक महत्वपूर्ण ओवरहेड के साथ आने के बाद, मैंने कभी भी सही प्रवर्तन नहीं देखा है।

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

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

(ट्रिगर्स के माध्यम से किए जा रहे सभी अपडेट के संदर्भ में मैं दो बातें कहने जा रहा हूं: (1) जब मैं इसे पढ़ता हूं तो मेरे मुंह में थोड़ी सी बीमारियां हो जाती हैं और (बी) आपको संग्रहीत प्रक्रियाएं पसंद नहीं हैं क्योंकि वे ' पुन: "कम बनाए रखने योग्य; कम परीक्षण करने योग्य; अत्यधिक युग्मित; और एक सिस्टम को एक विक्रेता में बंद कर दिया" लेकिन आप ट्रिगर्स का उपयोग करते हैं जिसके बारे में वही बातें मूल रूप से कही जा सकती हैं।)

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

यहाँ दूसरी बात यह है कि आप जटिलता भी जोड़ रहे हैं और (साथ ही ओवरहेड जो बनाता है), जटिलता को छेद में ले जाता है जिसका शोषण किया जा सकता है।

मैं यह नहीं कह रहा हूं कि इस तरह के नियमों का एक सेट नहीं बनाया जा सकता है - और अधिक आप क्यों परेशान करेंगे? वे इस तरह के हमले को रोकने के व्यापक रूप से स्वीकृत तरीकों के साथ जाने से अधिक बोझिल और कम विश्वसनीय लगते हैं।

Comments

+1 मेरे निहित, अचेतन मान्यताओं के प्रकाश में मेरी वास्तविक क्वेरी को समझने के लिए, और उचित रूप से इसका जवाब देने के लिए। जैसे कि कोई परेशान क्यों कर सकता है - मैं एक ऐसी परियोजना पर काम कर रहा हूं जहां आर्किटेक्चर के प्रासंगिक विवरण से बहुत सारे कोड उत्पन्न होंगे - और इस आर्किटेक्चर का एक हिस्सा बताता है कि डेटाबेस एक्सेस रूटीन कैसे उत्पन्न किया जाए। यह अभी भी खुला है कि इन उत्पन्न रूटीन को किस आकार में लिया जाएगा।

— क्रिस वाल्टन