अगर मुझे ड्रॉपडाउन का उपयोग करना पड़ता है, तो क्या मुझे एसक्यूएल इंजेक्शन से बचाव करना होगा?

Question

मैं समझता हूं कि आपको एक फॉर्म से उपयोगकर्ता इनपुट पर भरोसा करना चाहिए, मुख्यतः SQL इंजेक्शन की संभावना के कारण।

हालाँकि, क्या यह ऐसे फॉर्म पर भी लागू होता है, जहां एकमात्र इनपुट ड्रॉपडाउन (एस) से है (नीचे देखें)?

मैं $_POST['size']एक सत्र के लिए बचत कर रहा हूं, जो तब विभिन्न डेटाबेस (एक mysqliचुनिंदा क्वेरी के साथ) को क्वेरी करने के लिए साइट पर उपयोग किया जाता है और किसी भी SQL इंजेक्शन निश्चित रूप से उन्हें नुकसान पहुंचाएगा (संभवतः ड्रॉप)।

डेटाबेस क्वेरी करने के लिए टाइप किए गए उपयोगकर्ता इनपुट के लिए कोई क्षेत्र नहीं है, केवल ड्रॉपडाउन (एस)।

<form action="welcome.php" method="post">
<select name="size">
  <option value="All">Select Size</option> 
  <option value="Large">Large</option>
  <option value="Medium">Medium</option>
  <option value="Small">Small</option>
</select>
<input type="submit">
</form>

Comments

हाँ। कुछ भी हमलावर को आपके <select>इनपुट में जो भी मान चाहिए, उन्हें सबमिट करने से रोकता है । वास्तव में भी थोड़ा तकनीकी उपयोगकर्ता ब्राउज़र कंसोल का उपयोग करके अतिरिक्त विकल्प जोड़ सकता है। यदि आप उपलब्ध मूल्यों की एक सरणी श्वेत सूची रखते हैं और इसके खिलाफ इनपुट की तुलना करते हैं, तो आप इसे कम कर सकते हैं (और आपको चाहिए क्योंकि यह अवांछित मूल्यों को रोकता है)

— माइकल बेरकोव्स्की

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

— Royal Bg

@YourCommonSense क्योंकि यह एक अच्छा सवाल है। हर किसी को एहसास नहीं है कि एक ग्राहक कितना छेड़छाड़ करता है। यह इस साइट के लिए बहुत मूल्यवान उत्तर देगा।

— क्रंचर

@ क्रंचर मैं देख रहा हूं। एक औसत स्टैकओवरफ़्लोयनियन के लिए यह एक रॉकेट साइंस है जिसे उन्होंने पहले सुना था। यहां तक ​​कि PHP टैग के तहत सबसे अपवित्र सवाल के बावजूद।

— आपका कॉमन सेंस

"मैं समझता हूं कि आपको उपयोगकर्ता इनपुट पर भरोसा नहीं करना चाहिए"। कोई अपवाद नहीं।

— प्रिंज़ोर्न

Answer 1

आप निम्नलिखित उदाहरण के रूप में सरल कुछ कर सकते हैं यह सुनिश्चित करने के लिए कि पोस्ट किए गए आकार में आप क्या उम्मीद करते हैं।

$possibleOptions = array('All', 'Large', 'Medium', 'Small');

if(in_array($_POST['size'], $possibleOptions)) {
    // Expected
} else {
    // Not Expected
}

तब mysqli_ * का उपयोग करें यदि आप php का एक संस्करण का उपयोग कर रहे हैं = = 5.3.0 जो आपको होना चाहिए, ताकि आप अपना परिणाम बचा सकें। यदि इसे सही तरीके से उपयोग किया जाता है तो यह sql इंजेक्शन के साथ मदद करेगा।

Comments

क्या यह 'श्वेतसूची' ऑलिवरबीएस का शॉर्टहैंड संस्करण है?

— टाटर्स

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

— ओलिवर बेयस-शेल्टन

बहरहाल, आपको तैयार स्टेटमेंट (अनुशंसित) या का उपयोग करना चाहिए mysqli_real_escape_string। मानों को आउटपुट करते समय भी ठीक से बच सकते हैं (जैसे HTML डॉक्यूमेंट में htmlspecialchars () का उपयोग करें)।

— कॉमफरिक

मैं के तीसरे पैरामीटर सुझाव देंगे in_arrayकरने के लिए trueसख्त तुलना के लिए। मुझे यकीन नहीं है कि क्या गलत हो सकता है, लेकिन तुलना की सुंदर विचित्रता।

— ब्रिलियनड

@OliverBS $ _POST मान भी सरणियाँ हो सकती हैं। संख्यात्मक तार संख्याओं के रूप में तुलना करते हैं ('5' == '05')। मुझे नहीं लगता कि आपके विशिष्ट उदाहरण में आपके पास एक सुरक्षा छेद है, लेकिन नियम जटिल हैं, और छेद उन कारणों से खुल सकते हैं जिन्हें मैं भी नहीं समझता। सख्त तुलना करना आसान है, और इसलिए सुरक्षित रूप से उपयोग करना आसान है।

— Brilliand

Answer 2

हां आपको इससे बचाव करने की जरूरत है।

फ़ायरफ़ॉक्स के डेवलपर कंसोल का उपयोग करके मुझे यह दिखाने दें कि:

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

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

यदि आपने इसे अपने पृष्ठ पर व्यवहार का उपयोग करके इसे प्रतिबंधित करने का प्रयास किया है, तो मेरे विकल्पों में उस व्यवहार को अक्षम करना, या बस अपने सर्वर पर एक कस्टम HTTP अनुरोध लिखना है जो इस फ़ॉर्म को किसी भी तरह से सबमिट करता है। वहाँ एक उपकरण है जिसे कर्ल कहा जाता है, ठीक उसी के लिए इस्तेमाल किया जाता है, और मुझे लगता है कि इस एसक्यूएल इंजेक्शन को जमा करने की कमान वैसे भी कुछ इस तरह दिखाई देगी:

curl --data "size=%27%29%3B%20DROP%20TABLE%20*%3B%20--"  http://www.example.com/profile/save

(यह पूरी तरह से मान्य कर्ल कमांड नहीं हो सकता है, लेकिन फिर से, मुझे आशा है कि मैंने अपनी बात पूरी कर दी है।)

तो, मैं दोहराऊंगा:

कभी भी उपयोगकर्ता इनपुट पर भरोसा न करें। हमेशा खुद की रक्षा करें।

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

Comments

कस्टम पेलोड के साथ क्राफ्टिंग का उल्लेख नहीं करना curl। हमेशा इनपुट सर्वर-साइड को पवित्र करें !

— recursion.ninja

एक छवि एक हजार शब्दों से अधिक कहती है।

— दविदकोनराड

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

— रेट्रोकेकर

कितना प्यार है! यह थोड़ा बॉबी टेबल्स है!

— आभा

Answer 3

जैसा कि इस सवाल के साथ टैग किया गया था एसक्यूएल इंजेक्षन, यहाँ इस विशेष प्रकार के हमले के बारे में एक उत्तर दिया गया है:

जैसा कि आपको टिप्पणियों में बताया गया है, आपको बिना किसी अपवाद के , किसी भी चर डेटा को शामिल करने वाली प्रत्येक क्वेरी के लिए तैयार कथनों का उपयोग करना होगा ।

किसी भी HTML सामान के बावजूद!
यह समझना आवश्यक है कि SQL प्रश्नों को किसी भी बाहरी कारक की परवाह किए बिना ठीक से स्वरूपित किया जाना चाहिए , चाहे वह HTML इनपुट हो या कुछ और।

यद्यपि आप इनपुट सत्यापन उद्देश्य के लिए अन्य उत्तरों में सुझाई गई श्वेत-सूची का उपयोग कर सकते हैं, यह किसी भी एसक्यूएल से संबंधित कार्यों को प्रभावित नहीं करना चाहिए - उन्हें वही रहना पड़ता है, भले ही आपने HTML इनपुट को मान्य किया हो या नहीं। इसका मतलब है कि आपको अभी भी क्वेरी में किसी भी चर को जोड़ते समय तैयार किए गए कथनों का उपयोग करना होगा।

यहां आपको पूरी तरह से स्पष्टीकरण मिल सकता है कि क्यों तैयार किए गए कथन एक जरूरी हैं और उनका सही तरीके से उपयोग कैसे करें और वे कहां लागू नहीं हैं और ऐसे मामले में क्या करना है: हिचहाइकर गाइड टू एसक्यूएल इंजेक्शन सुरक्षा

साथ ही, इस सवाल का टैग लगाया गया था mysqli। ज्यादातर दुर्घटना से, मैं अनुमान लगाता हूं, लेकिन वैसे भी, मुझे आपको चेतावनी देना होगा कि कच्चे mysqli पुराने mysq_ * कार्यों के लिए पर्याप्त प्रतिस्थापन नहीं है । केवल इसलिए कि अगर पुरानी शैली में उपयोग किया जाता है, तो यह बिल्कुल भी सुरक्षा नहीं जोड़ेगा। हालांकि यह तैयार किए गए कथनों के लिए समर्थन दर्दनाक और परेशान करने वाला है, इस बिंदु पर कि औसत PHP उपयोगकर्ता बस उन्हें प्रयास करने में असमर्थ है। इस प्रकार, यदि कोई ORM या किसी प्रकार का अमूर्त पुस्तकालय विकल्प नहीं है, तो PDO आपकी एकमात्र पसंद है।

Comments

i = यादृच्छिक (0, 15); // कुछ क्वेरी का उपयोग करके। क्या मुझे अभी भी यहां तैयार वक्तव्य की आवश्यकता है?

— क्रंचर

का कार्यान्वयन क्या है random?

— 1555 में Slicedpan

@YourCommonSense संकीर्ण-देखी गई? मेरे लिए "हमेशा एक्स करें, और मैं इसके लिए कोई तर्क नहीं दूंगा" संकीर्ण-देखा गया है।

— क्रंचर

@ क्रंचर मैं किसी भी कारण से हमेशा तैयार बयानों का उपयोग नहीं कर सकता , हर बार, हर चीज के लिए, हमेशा। क्या आप मुझे बता सकते हैं?

— वेस्ले मर्च

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

— वेस्ले मर्च

Answer 4

हाँ।

वास्तव में भेजे जाने वाले मूल्यों के लिए कोई भी कुछ भी बिगाड़ सकता है -

एसओ, ड्रॉपडाउन मेनू को मान्य करने के लिए, आप केवल यह सुनिश्चित करने के लिए जांच कर सकते हैं कि आप जिस मूल्य के साथ काम कर रहे हैं, वह ड्रॉपडाउन में था - कुछ इस तरह से सबसे अच्छा (सबसे अधिक पागल) तरीका होगा:

if(in_array($_POST['ddMenu'], $dropDownValues){

    $valueYouUseLaterInPDO = $dropDownValues[array_search("two", $arr)];

} else {

    die("effin h4x0rs! Keep off my LAMP!!"); 

}

Comments

यह उत्तर अधूरा है, इसके अतिरिक्त आपको तैयार किए गए कथनों का उपयोग करना चाहिए, ताकि मान चाहे जो निर्धारित किया जाए, यह इंजेक्शन संभव नहीं है

— Slicedpan

@Slicedpan वास्तव में? ऐसा लगता है कि आप बिना जाने क्यों बैंड-बाजे पर झूम रहे हैं ... अगर मेरे पास एक क्वेरी में संभव इनपुट्स हैं, तो मैं यह सत्यापित कर सकता हूं कि वे सभी ठीक हैं (जो मुझे पता है, क्योंकि मैंने उन्हें बनाया है) तब आप तैयार कथन का उपयोग करने से कोई अतिरिक्त सुरक्षा लाभ नहीं लेते हैं

— क्रंचर

सिवाय इसके कि एक कन्वेंशन के रूप में तैयार किए गए कथनों का उपयोग आपको भविष्य में SQL इंजेक्शन भेद्यताओं को पेश करने से बचाता है।

— स्लीडपैन

@ क्रंचर एक वादा "ड्रॉप-डाउन में सभी मूल्य हमेशा सुरक्षित रहेंगे" बनाने के लिए एक बहुत ही असुरक्षित वादा है। मान बदल दिए गए हैं, कोड आवश्यक रूप से अपडेट नहीं किया गया है। मूल्यों को अपडेट करने वाला शायद यह भी नहीं जानता है कि असुरक्षित मूल्य क्या है! विशेष रूप से वेब प्रोग्रामिंग के दायरे में, जो सभी प्रकार की सुरक्षा चिंताओं से व्याप्त है, कुछ इस तरह से कंजूसी करना, केवल सादा गैर जिम्मेदाराना (और अन्य कम अच्छे शब्द) हैं।

— हाइड

@ क्रंचर यदि आप अपने एसक्यूएल सामान को ठीक से संभालते हैं, तो आप एसक्यूएल के ठीक से काम करने में हस्तक्षेप किए बिना किसी भी इनपुट को स्वीकार कर सकते हैं । एसक्यूएल भाग को तैयार होना चाहिए और किसी भी चीज को स्वीकार करने के लिए तैयार नहीं होना चाहिए जहां से यह आता है। बाकी सब त्रुटि-प्रवण है।

— ग्लोगल

Answer 5

कंसोल का उपयोग करके अपने ड्रॉप डाउन को बदलने वाले उपयोगकर्ताओं के खिलाफ सुरक्षा का एक तरीका केवल उन में पूर्णांक मानों का उपयोग करना है। तब आप पुष्टि कर सकते हैं कि POST मान में एक पूर्णांक होता है, और जरूरत पड़ने पर उस पाठ में परिवर्तित करने के लिए एक सरणी का उपयोग करें। उदाहरण के लिए:

<?php
// No, you don't need to specify the numbers in the array but as we're using them I always find having them visually there helpful.
$sizes = array(0 => 'All', 1 => 'Large', 2 => 'Medium', 3 => 'Small');
$size = filter_input(INPUT_POST, "size", FILTER_VALIDATE_INT);

echo '<select name="size">';
foreach($sizes as $i => $s) {
    echo '<option value="' . $i . '"' . ($i == $size ? ' selected' : '') . '>' . $s . '</option>';
}
echo '</select>';

फिर आप $sizeअपनी क्वेरी में ज्ञान के साथ उपयोग कर सकते हैं कि यह केवल कभी होगा FALSEया पूर्णांक होगा।

Comments

@ ऑलिवरबस क्या है filter_inputअगर सर्वर साइड पर चेक नहीं है? पूर्णांक को छोड़कर कोई भी कुछ भी पोस्ट नहीं कर सकता है।

— स्टाइलफॉन

धन्यवाद स्टाइलफॉन, तो यह ओपी में फॉर्म को बदल देता है? और यह कई ड्रॉपडाउन के साथ बड़े रूपों पर लागू होगा? अगर मैंने 'कलर' कहने के लिए इसमें एक और ड्रॉपडाउन जोड़ा?

— टाटर्स

@SamuelTattersfield हां और हां। आप इसका उपयोग जितनी चाहें उतने ड्रॉपडाउन के लिए कर सकते हैं, जितने चाहें उतने विकल्प। आप बस प्रत्येक ड्रॉपडाउन के लिए एक नई सरणी बनाते हैं और सरणी में ड्रॉपडाउन के सभी विकल्पों में डालते हैं।

— स्टाइलन

अच्छा! मुझें यह पसंद है। मैं इसे एक शॉट दूंगा और देखूंगा कि मुझे परीक्षण में क्या मिला है।

— टेटर्स

@SamuelTattersfield ग्रेट, बस filter_inputभाग को सत्यापन के लिए उपयोग करना सुनिश्चित करें , अन्यथा यह सुरक्षा के लिए चॉकलेट चायदानी के रूप में उपयोगी है।

— स्टाइलन

Answer 6

अन्य उत्तर पहले से ही कवर करते हैं जो आपको जानना आवश्यक है। लेकिन शायद यह कुछ और स्पष्ट करने में मदद करता है:

कर रहे हैं दो बातें आपको बस इतना करना:

1. फॉर्म डेटा को मान्य करें।

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

सत्यापन आमतौर पर एक तरह से किया जाता है जो डेटा को परिवर्तित नहीं करता है, लेकिन यह फिर से फ़ॉर्म दिखाता है, "कृपया सही" "" के रूप में चिह्नित फ़ील्ड के साथ।

अधिकांश चौखटे और सीएमएस में बिल्डरों की मदद होती है जो इस कार्य में आपकी मदद करते हैं। और सिर्फ इतना ही नहीं, वे CSRF (या "XSRF") के खिलाफ भी मदद करते हैं, जो हमले का दूसरा रूप है।

2. SQL स्टेटमेंट्स में सेनिटाइज / एस्केप वेरिएबल ।।

.. या तैयार कथनों को आप के लिए काम करते हैं।

यदि आप किसी भी चर, उपयोगकर्ता द्वारा प्रदत्त या नहीं के साथ (My) SQL स्टेटमेंट बनाते हैं, तो आपको इन चरों से बचने और उद्धृत करने की आवश्यकता है।

आमतौर पर, MySQL स्टेटमेंट में आपके द्वारा डाला गया कोई भी वैरिएबल या तो एक स्ट्रिंग होना चाहिए, या ऐसा कुछ जिसे PHP मज़बूती से एक स्ट्रिंग में बदल सकता है जिसे MySQL डाइजेस्ट कर सकता है। जैसे, संख्या।

स्ट्रिंग्स के लिए, आपको स्ट्रिंग से बचने के लिए कई तरीकों में से एक को चुनना होगा, इसका मतलब है कि किसी भी वर्ण को बदलें जो MySQL में साइड इफेक्ट होगा।

• पुराने स्कूल MySQL + PHP में, mysql_real_escape_string () काम करता है। समस्या यह है कि इसे भूलना बहुत आसान है, इसलिए आपको तैयार बयान या क्वेरी बिल्डरों का बिल्कुल उपयोग करना चाहिए।
• MySQLi में, आप तैयार किए गए कथनों का उपयोग कर सकते हैं।
• अधिकांश चौखटे और सीएमएस क्वेरी बिल्डरों को प्रदान करते हैं जो इस कार्य में आपकी सहायता करते हैं।

यदि आप एक संख्या के साथ काम कर रहे हैं, तो आप भागने और उद्धरण को छोड़ सकते हैं (यही कारण है कि तैयार किए गए कथन एक प्रकार को निर्दिष्ट करने की अनुमति देते हैं)।

यह इंगित करना महत्वपूर्ण है कि आप SQL कथन के लिए चर से बचते हैं , और डेटाबेस के लिए ही नहीं । डेटाबेस मूल स्ट्रिंग को संग्रहीत करेगा, लेकिन वक्तव्य को एक बचा हुआ संस्करण चाहिए।

यदि आप इनमें से किसी एक को छोड़ देते हैं तो क्या होता है?

यदि आप फ़ॉर्म सत्यापन का उपयोग नहीं करते हैं , लेकिन आप अपने SQL इनपुट को साफ करते हैं, तो आपको सभी प्रकार के खराब सामान दिखाई दे सकते हैं, लेकिन आप SQL इंजेक्शन नहीं देखेंगे! (*)

सबसे पहले, यह आपके आवेदन को उस राज्य में ले जा सकता है जिसकी आपने योजना नहीं बनाई थी। उदाहरण के लिए, यदि आप सभी उपयोगकर्ताओं की औसत आयु की गणना करना चाहते हैं, लेकिन एक उपयोगकर्ता ने उम्र के लिए "अल्जकडाफ़र" दिया, तो आपकी गणना विफल हो जाएगी।

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

डेटाबेस के साथ अभी भी समस्याएं हो सकती हैं: जैसे कि यदि कोई फ़ील्ड (डेटाबेस टेबल कॉलम) 255 वर्णों तक सीमित है, और स्ट्रिंग उससे अधिक लंबी है। या यदि फ़ील्ड केवल संख्याओं को स्वीकार करता है, और आप इसके बजाय एक गैर-संख्यात्मक स्ट्रिंग को बचाने का प्रयास करते हैं। लेकिन यह "इंजेक्शन" नहीं है, यह सिर्फ "एप्लिकेशन को क्रैश कर रहा है"।

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

(*) या यह वास्तव में कुछ विदेशी होगा।

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

सबसे पहले, आप जोखिम लेते हैं कि जब आप डेटाबेस में डेटा को सहेजते हैं और इसे फिर से लोड करते हैं, तो यह अब समान डेटा नहीं होगा, "अनुवाद में खो गया"।

दूसरे, यह अमान्य SQL कथनों में परिणाम कर सकता है, और इस तरह आपके एप्लिकेशन को क्रैश कर सकता है। उदाहरण के लिए, यदि किसी भी चर में एक उद्धरण या दोहरा उद्धरण वर्ण है, तो आप किस प्रकार के उद्धरण का उपयोग करते हैं, इसके आधार पर आपको अमान्य MySQL कथन मिलेगा।

तीसरा, यह अभी भी SQL इंजेक्शन का कारण बन सकता है।

यदि प्रपत्रों से आपका उपयोगकर्ता इनपुट पहले से ही फ़िल्टर / मान्य है, तो जानबूझकर SQl इंजेक्शन की संभावना कम हो सकती है, यदि आपका इनपुट विकल्पों की हार्डकोड सूची में कम है, या यदि यह संख्याओं तक सीमित है। लेकिन किसी भी मुफ्त टेक्स्ट इनपुट का उपयोग SQL इंजेक्शन के लिए किया जा सकता है, यदि आप SQL स्टेटमेंट में वेरिएबल्स को ठीक से नहीं छोड़ते हैं।

और यहां तक ​​कि अगर आपके पास कोई फॉर्म इनपुट नहीं है, तो भी आप सभी प्रकार के स्रोतों से तार ले सकते हैं: फाइलसिस्टम से पढ़ें, इंटरनेट से स्क्रैप किया गया है, आदि कोई भी गारंटी नहीं दे सकता है कि ये तार सुरक्षित हैं।

Comments

न तो बहुत लंबा डेटा संख्यात्मक क्षेत्र में एक स्ट्रिंग नहीं है, कुछ भी दुर्घटनाग्रस्त हो जाएगा

— आपका कॉमन सेंस

हम्म, अभी यह कोशिश की, और वास्तव में यह एक त्रुटि के बजाय एक चेतावनी दिखाता है। मुझे लगता है कि यह पीडीओ है जो इसे एक त्रुटि में बदल देता है। मुझे यकीन है कि मैं drupal.org पर एक दर्जन मुद्दों पर चर्चा कर चुका हूं जहां कुछ स्ट्रिंग एक varchar के लिए बहुत लंबा है।

— दान

Answer 7

आपका वेब ब्राउज़र "नहीं जानता" है कि यह php से एक पृष्ठ प्राप्त कर रहा है, यह सब देखता है html है। और http लेयर उससे भी कम जानता है। आपको लगभग किसी भी प्रकार के इनपुट को संभालने में सक्षम होना चाहिए जो http लेयर को पार कर सकता है (सौभाग्य से अधिकांश इनपुट पीएचपी पहले से ही एक त्रुटि देगा)। यदि आप अपने डीबी को खराब करने से होने वाले दुर्भावनापूर्ण अनुरोधों को रोकने की कोशिश कर रहे हैं, तो आपको यह मानने की ज़रूरत है कि दूसरे छोर का आदमी जानता है कि वह क्या कर रहा है, और यह वह नहीं है जो आप सामान्य परिस्थितियों में अपने ब्राउज़र में देख सकते हैं ( यह उल्लेख करने के लिए नहीं कि आप ब्राउज़र के डेवलपर टूल के साथ क्या कर सकते हैं)। तो हां, आपको अपने ड्रॉपडाउन से किसी भी इनपुट को पूरा करने की आवश्यकता है, लेकिन अधिकांश इनपुट के लिए आप एक त्रुटि दे सकते हैं।

Answer 8

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

Answer 9

SQL इंजेक्शन के खिलाफ सुनिश्चित करने के लिए एक पैरामीटर क्वेरी का उपयोग करना सबसे अच्छा है। उस स्थिति में क्वेरी का लुक यह होगा:

SELECT * FROM table WHERE size = ?

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

SELECT * FROM table WHERE size = 'DROP table;'

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

Answer 10

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

जब आप क्लाइंट पर भरोसा करते हैं तो क्या हो सकता है और क्या होगा, इसका उदाहरण ।

Answer 11

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