में mysql_query को संरचित करने का एक सुरक्षित तरीका है मैंने फ़ायरफ़ॉक्स के बाहर सर्वर को कस्टम क्वेरी करके एक SQL इंजेक्शन प्राप्त करने का प्रयास किया है।क्या यह PHP
PHP के अंदर, सभी चर इस तरह की स्ट्रिंग में क्वेरी में पास हो जाते हैं।
नोट, इस चरण तक, $ _POST को छुआ नहीं गया है।
mysql_query('INSERT INTO users (password, username) VALUES(' . sha1($_POST['password']) . ',' . $_POST['username'] . '));
क्या यह बदलाव करने का एक सुरक्षित तरीका है?
आपको निश्चित रूप से उपयोगकर्ता नाम mysql_real_escape_string से बचाना चाहिए।
बेशक सबसे अच्छा समाधान तैयार बयान का उपयोग करना होगा। इस तरह क्वेरी सिंटैक्स और डेटा को अलग करना MySQL API स्तर पर किया जाता है।
और, जैसा कि अन्य ने बताया, मूल्यों को पूरी तरह से उद्धरणों से घिरा होना चाहिए। खासकर पाठ वाले।
http://php.net/mysqli.real-escape-string पर ध्यान दें, जिसमें सभी इनकमिंग मानों को इसे सुरक्षित बनाने में मदद करनी चाहिए।
आप जो भी कर रहे हैं वह खतरनाक है क्योंकि कोई बुरा उपयोगकर्ता नाम के साथ POST अनुरोध भेज सकता है। आप या तो प्रत्येक पैरामीटर को देख सकते हैं और इसे से बच सकते हैं, इसके अतिरिक्त आप mysqli (http://php.net/manual/en/book.mysqli.php), का उपयोग कर सकते हैं और तैयार + बाइंड का उपयोग करके पैरामीटर को बाध्य कर सकते हैं।
पहला कदम अन्य उपयोगकर्ताओं, पर शोषण से बचने के लिए अच्छा है जबकि दूसरा आपके सर्वर की सुरक्षा के लिए अच्छा है। How do you prevent SQL injection in LAMP applications?
ऐसा क्यों है कि मैं इसे तब नहीं समझ सकता? मैंने सामान्य इंजेक्शन के अनगिनत प्रयासों की कोशिश की है और कोई भी कुछ भी उत्पादित नहीं करता है ... – Supernovah
सुनिश्चित नहीं है कि आपका PHP कॉन्फ़िगर कैसे किया गया है, क्या आपने तारों को मुद्रित करने का प्रयास किया था? यह पहले से ही कुछ जादू कर सकता है। अगर वे आपके द्वारा भेजे गए तारों की तरह प्रतीत नहीं होते हैं, तो आप यह भी सुनिश्चित करना चाहते हैं कि आप उन्हें सही तरीके से भेज रहे हैं, उन्हें क्लाइंट पक्ष पर इस तरह से या किसी अन्य को एन्कोड किया जा सकता है। –
@ सुपर्नोवा '$ _POST [' उपयोगकर्ता नाम '] = "(mysql.user सीमा से पासवर्ड का चयन करें 1)" इस एसक्यूएल इंजेक्शन भेद्यता का उपयोग करने के लिए उद्धरण चिह्नों की आवश्यकता नहीं है – rook
इस जब तक magic_quotes_gpc विन्यास निर्देश चालू है, असुरक्षित है:
भी इस सवाल पर गौर करें।
var_dump(ini_get('magic_quotes_gpc')); या phpinfo(); आप वास्तविक मूल्य दिखा सकते हैं
ध्यान दें कि इस निर्देश गंदा है, तो बहिष्कृत और सभी नफरत करते थे। और कुछ पासवर्ड काम नहीं करेगा।
-1 magic_quotes_gpc बहुत असुरक्षित है और PHP6 में हटाया जा रहा है। सबसे महत्वपूर्ण बात यह है कि यह अभी भी magic_quotes_gpc ** '$ _POST ['username'] के साथ SQL इंजेक्शन है, क्वेरी में उद्धरण चिह्नों से घिरा हुआ नहीं है, इसलिए आप कुछ ऐसा इंजेक्ट कर सकते हैं (mysql.user सीमा 1 से पासवर्ड का चयन करें) ', इस क्वेरी के शोषण के लिए उद्धरण चिह्नों की आवश्यकता नहीं है। – rook
अहहा @ द लेमर मुझे फिर से व्याख्यान करने की कोशिश कर रहा है। जैसे ही एमडी 5 के साथ, आप बस हिंसक रूप से चिल्लाते हुए "बहुत असुरक्षित! बहुत असुरक्षित!" लेकिन वास्तव में आप मूर्खतापूर्ण उदाहरण के साथ "बहुत" और न ही "असुरक्षित" साबित नहीं कर सकते हैं। तो, जो आपने अभी सुना है उसे मत कहो लेकिन कभी समझ में नहीं आता। और किसी ने भी आसपास के उद्धरणों पर आपकी राय नहीं मांगी, क्योंकि वे उदाहरण में उपयोग किए जाते हैं। बेशक यह उद्धरण के बिना काम नहीं करेगा। यह स्पष्ट है –
वाह, यदि आप इसे इंगित करने के बाद इस विशिष्ट एसक्यूएल इंजेक्शन भेद्यता को नहीं देखते हैं तो आपको केवल मेरी तुलना में बड़ी समस्याएं हैं। – rook
अपने कोड की जाँच मैं यह बिल्कुल काम करता है जब आप शाब्दिक आप डालने कर रहे हैं बोली नहीं है हैरान हूँ पर - आप की तरह कोड जनरेट किया जाएगा:
INSERT INTO user (password, username) VALUES (abc1234fg00000, admin);
तो यह एक त्रुटि हर बार दे देंगे । मान लीजिए यह सिर्फ एक टाइपो है ....
MySQL एक्सटेंशन केवल एक प्रश्न प्रति कॉल की अनुमति देकर इंजेक्शन हमलों को करने की आपकी क्षमता को सीमित करता है। इसके अलावा, एक इंसर्ट स्टेटमेंट पर इंजेक्शन हमले के लिए सीमित गुंजाइश है। उस तथ्य को जोड़ें कि सम्मिलन कथन में विभाजित होने से पहले आप एक तटस्थ प्रारूप में प्रतिनिधित्व को बदलते हैं, इसका मतलब है कि यह इस तरह के हमले के लिए संभावित एवेन्यू नहीं है। हालांकि, आपका कोड होना चाहिए यदि कोई उपयोगकर्ता नामक एक उद्धरण वाला उपयोगकर्ता नाम पोस्ट करता है (यदि ऐसा नहीं है तो आपको जादू_क्वाट सक्षम सक्षम किया गया है जिसे बहिष्कृत किया गया है)।
OTOH अगर आप तो खाता मान्य आप विस्तृत इंजेक्शन हमलों के लिए खुले हैं करने के लिए एक ही विधि लागू होते हैं - पर विचार
"SELECT 1
FROM users
WHERE username='" . $_POST['username'] . "'
AND password='" . sha1($_POST['username'] . "';";
हैं $ _POST [ 'उपयोगकर्ता नाम'] "व्यवस्थापक 'या 1" तो आपके सिस्टम में शामिल है समझौता किया गया है
आप हमेशा उपयोग mysql_real_escape_string() जब तक आप डेटा को सुरक्षित एक अलग समारोह का उपयोग कर (जैसे SHA1, bas64_encode .... लेकिन नहीं addslashes) बनाया है
सी
गलत क्वेरी सिंटैक्स पर अच्छा बिंदु –
मैं 'sha1, bas64_encode' सामान से सहमत नहीं हो सकता। इन सभी चीजों के डेटाबेस के साथ कुछ लेना देना नहीं है। आप अपना दिमाग बदल सकते हैं और इन कार्यों का उपयोग छोड़ सकते हैं। लेकिन क्वेरी बिल्डिंग एल्गोरिदम एक जैसा होना चाहिए। इसे अमूर्त बनाने और डेटा मूल्य से स्वतंत्र बनाने के लिए बेहतर है। –
@ कोल। Shrapnel: लेकिन sha1 ($ x) === mysql_real_escape_string (sha1 ($ x)) और base64_encode ($ x) === mysql_real_escape_string (base64_encode ($ x)) चाहे $ x क्या है। नोट मैं यह नहीं कह रहा हूं कि आपको mysql_real_escape_string() का उपयोग नहीं करना चाहिए, बस कुछ मामलों में यह अनावश्यक है। – symcbean
मुझे आश्चर्य है चाहिए कभी-कभी अगर वे मुझे पुराने लोगों के घर में मिल जाएंगे, तो वे नर्सों पर "बाइंड वैरिबल्स" चिल्लाते हुए चिल्लाते हैं।
यह 2010 लोगों BIND चर है, है ना 1995
!
BIND VARIABLES!
आपने कैसे प्रयास किया? सभी उचित सम्मान के साथ –
। आप और मेरे बाद लाखों लोग समझदार हैं। बहुत अधिक दुर्भावनापूर्ण कौन हैं। आपकी साइट को नीचे लाने के लिए आपके पास एक खुला आमंत्रण है। सिर्फ इसलिए कि आप एक उचित एसक्यूएल इंजेक्शन लागू नहीं कर सके, इसका मतलब यह नहीं है कि यह संभव नहीं है। –
यूटीएफ -8 में एन्कोड किए गए टेक्स्ट से जावास्क्रिप्ट में मेरे कस्टम AJAX प्रश्नों का उपयोग करके और कुछ ब्राउज़रों के भीतर (जो मुझे पता है कि डेटा एन्कोड कर सकता है)। परीक्षण करने का कोई अच्छा तरीका है? – Supernovah