मैं SQL इंजेक्शन के लिए असुरक्षित कोड लिखने को रोकने के लिए प्रोग्रामर कैसे प्राप्त कर सकता हूं?


11

कभी-कभी आप व्यस्त हो जाते हैं और छोटे कार्य जूनियर प्रोग्रामरों को सौंप देते हैं। लेकिन अगर आप पर्याप्त ध्यान नहीं देते हैं तो आप अपने आप को उत्पादन में इस तरह के कोड के साथ पाते हैं:

class DivtoggleController extends Zend_Controller_Action {

    public function closeAction() {
        /* ... code removed for brevity ... */

        $req = $this->getRequest();
        $formData = $req->getPost();

        $d = $formData['div'];
        $i = $formData['id'];

        $dm = new Model_DivtoggleManager();
        $rs = $dm->setDivToggleById($d, $i);

    }

}


class Model_DivtoggleManager extends Zend_Db_Table {

    public function setDivToggleById($div, $id) {
        $result = $this->getAdapter()->query(
           "update div_toggle set " . $div . "=1 where id=" . $id
        );
    }

}

इसलिए, यह देखते हुए कि मैंने संक्षिप्तता के लिए प्रमाणीकरण / सत्र प्रबंधन तर्क को हटा दिया है, जो मुझे बता सकता है कि इस नमूने के साथ क्या संभावित समस्या हो सकती है?


इसे एक साधारण कुकी में क्यों नहीं संग्रहीत किया जाता है?
अंधेरी

1
@ रात, आप मान रहे हैं कि कुकी को स्टोर करने के लिए एक सत्र है। बड़ा सुरक्षा मुद्दा अप्रासंगिक है या नहीं।
रोजर हैलिबर्टन

जवाबों:


24

आप उन्हें सिखा सकते हैं। हर कोई शुरुआत में ऐसा करता है, यहां तक ​​कि आप भी। यदि इस प्रकार का कोड इसे उत्पादन में बनाता है, तो यह वरिष्ठ लोगों की गलती है; जूनियर नहीं।

संपादित करें:

मेरे द्वारा की गई चीजों में से एक यह है कि मैंने व्यक्तिगत रूप से सक्रिय रूप से लोगों को एक रिलीज से पहले मेरे कोड (जूनियर्स सहित) की समीक्षा करने के लिए कहा है। कोड की समीक्षा हो जाती है, जूनियर लोग इसे सीखने के अनुभव के रूप में देखते हैं, लोग सजा के रूप में कोड की समीक्षा का डर खो देते हैं, और वे वही काम करना शुरू कर देते हैं।


2
+1 करने के लिए सहमत होना होगा। आप एक (संभवतः) जूनियर प्रोग्रामर को दोष नहीं दे सकते क्योंकि आपने ज्ञान का एक स्तर ग्रहण किया है जो उनके पास नहीं हो सकता है। (जैसा कि कहा गया है, तो आप चाहते हैं की तरह इस तरह के मुद्दों को अच्छी तरह इस दिन और उम्र में जाना जाता है सोचने के लिए तो फिर, मैं हूँ। पसंद को लगता है कि मैं प्रतिभाशाली और अच्छी लग रही है, आदि था) :-)
जॉन पार्कर

एक निष्पक्ष पर्याप्त बयान। मुझे लगता है कि मुझे एक अनुवर्ती सवाल पूछना चाहिए कि प्रबंधन उत्पादन में कोड लॉन्च करने पर जोर क्यों देगा जो वरिष्ठ प्रोग्रामर द्वारा अनुमोदित नहीं किया गया है। क्या मैं मामूली सुरक्षा के मुद्दे पर अपनी नौकरी को जोखिम में डाल सकता हूं?
रोजर हैलिबर्टन

1
@ रोगर हैलिबर्टन: ठीक है, अगर उस सुरक्षा मुद्दे का किसी तरह शोषण होता है, तो सबसे बुरा क्या हो सकता है? और क्यों सुरक्षा समस्याओं की ओर इशारा करते हुए आपको अपनी नौकरी खर्च करनी चाहिए? क्या प्रबंधन इससे निपटना नहीं चाहता है?
FrustratedWithFormsDesigner

1
@ रॉगर - जब तक आप हैक नहीं हो जाते तब तक यह केवल मामूली है। :) मुझे लगता है कि एक समीक्षा के बिना उत्पादन में कोड डालना (कोई फर्क नहीं पड़ता कि डेवलपर का स्तर) एक विफलता है। दुर्भाग्य से, बहुत सारी कंपनियों में यह एक बहुत ही आम बात है; और, ime, यह आमतौर पर एक प्रमुख ओह लेता है - $ 4! टी से पहले प्रबंधन कोड समीक्षा जैसी चीजों को महत्व देता है।
जॉन क्राफ्ट

1
@ रेंजर: सभी कोड की समीक्षा की जानी चाहिए, न कि केवल "जूनियर" प्रोग्रामर द्वारा लिखे गए कोड। यहां तक ​​कि वरिष्ठ प्रोग्रामर भी गलतियां करते हैं।
डीन हार्डिंग

20

उनकी आंखों के सामने उनके कोड को हैक करें फिर उन्हें दिखाएं कि इसे कैसे ठीक किया जाए। जब तक वे समझते हैं तब तक।


4
उन्हें हर सुबह ईमेल करें: "वैसे, मैंने आपके डेटाबेस को कल रात एक और SQL इंजेक्शन भेद्यता के माध्यम से आपके कोड में छोड़ दिया। मुझे पता है कि आप डेटाबेस बैकअप को बहाल करना कितना पसंद करते हैं!: D"
Ant

2
@Ant: अच्छा बनो। निर्धारित बैकअप के तुरंत बाद करें, कुछ समय पहले नहीं।
डोनल फैलो

@ जोनल: बैकअप के तुरंत बाद इसे करें, फिर उन्हें बताएं कि बैकअप विफल हो गया और रात भर बैकअप को बहाल करने से पहले उन्हें बाकी दिन के लिए पसीना आने दें।
jwenting

8

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

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

यदि आपके पास संसाधन हैं, तो टीम के अधिक वरिष्ठ सदस्यों को सुनिश्चित करने से पहले यह सुनिश्चित करना उपयोगी हो सकता है कि इससे पहले कि वे अलग-अलग हों।

ज्ञान ही शक्ति है!


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

मैं आम तौर पर सहमत हूँ, लेकिन एक बहुत ही स्मार्ट और महत्वाकांक्षी कनिष्ठ किराया "अनुभव के एन वर्षों के साथ PHP डेवलपर" की तुलना में बहुत सस्ता है, जो इतना बेहतर होने की गारंटी नहीं है। स्मार्ट जूनियर देव इस सामान को वास्तव में जल्दी से उठा सकते हैं और काफी संपत्ति हो सकते हैं।
यान

3

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

इसका एक तरीका यह है:

  1. एक वर्ग लिखें जो सभी POST / GET डेटा प्राप्त करता है और इसे वैसे ही लिखता है जैसा कि 'insecure_data' नामक एक सिंगलटन वर्ग को है। फिर POST / GET सरणियों को साफ़ करें।
  2. डेवलपर्स को 'insecure_data' सरणी से POST / GET डेटा प्राप्त करना है, POST / GET सरणियाँ नहीं।

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


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

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

ओह समझा। लेकिन आप केवल मानव प्रकृति से लड़ रहे हैं, यदि आप किसी को बताते हैं "यह वस्तु असुरक्षित है जब तक कि इसे सुरक्षित रूप से चिह्नित नहीं किया जाता है" और वे इसे किसी चीज़ के लिए उपयोग करने का प्रयास करते हैं, अधिकांश समय वे इसे वास्तव में जाँच के बिना सुरक्षित रूप से चिह्नित करेंगे। खैर, प्रतिष्ठा बढ़ाने का आनंद लें।
रोजर हॉलिबर्टन

कनिष्ठ विकासकर्ता के दृष्टिकोण से, केवल $ insecure_data देखने से एक झंडा इस तरह से उठता है कि बस $ postdata (या जो कुछ भी) नहीं दिखता है। यह विचार जोएल स्पोल्स्की के "गलत कोड को गलत देखो" से आता है । यदि आपके डेवलपर्स की मानव प्रकृति उस लाल झंडे को नजरअंदाज करने के लिए है, तो आपको या तो बहुत प्रशिक्षण देने की आवश्यकता है या कुछ नए डेवलपर्स प्राप्त करने की आवश्यकता है।
डैन ब्लो्स

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

1

वेब सुरक्षा पर मैंने जो सबसे अच्छा गाइड पढ़ा है, वह है रूबी ऑन रेल गाइड। हालांकि यह रूबी ऑन रेल्स है, बहुत सारी अवधारणाएं किसी भी वेब विकास पर लागू होती हैं। मैं किसी भी नए को उस गाइड को पढ़ने के लिए प्रोत्साहित करूंगा।


2
हर कोई जानता है कि रूबी सुरक्षित नहीं है।
रोजर हॉलिबर्टन

5
@रोगर: "हर कोई जानता है" सभी प्रकार की चीजें जो सच हो सकती हैं या नहीं। मैं प्रोग्रामिंग के लिए एक वास्तविकता-आधारित दृष्टिकोण की वकालत करता हूं, न कि हार्दिक-आधारित।
डोनल फैलो

0

आपके द्वारा ऊपर जोड़ा गया कोड SQL इंजेक्शन के हमले के लिए अतिसंवेदनशील है, क्योंकि आपके द्वारा क्वेरी में उपयोग किए जा रहे HTTP इनपुटों को mysql_real_escape_stringकिसी अन्य माध्यम से साफ नहीं किया गया है।


1
ओह, मुझे लगा कि हम इसका जवाब एक परीक्षण प्रश्न की तरह दे रहे हैं:]
रायन

डाउनवोट थोड़ा लंगड़ा कर रहे हैं, क्योंकि प्रश्न का शब्द पूर्व पोस्ट बदल गया था: पी
रयान

0

आपके (संभवतया ओवरराइडिंग) के संदर्भ में "मैं प्रोग्रामर को यह कैसे करना बंद कर सकता हूं" सवाल, मैं कहूंगा कि उन्हें नियमित रूप से सलाह देना, सवाल में समस्या को ध्यान से समझा (और संभावित गिरावट, आदि) और जोर देना कोड भेद्यता का महत्व (SQL इंजेक्शन और क्रॉस साइट स्क्रिप्टिंग, आदि के संदर्भ में दोनों) शायद सबसे समझदार समाधान है।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.