htmlentities बनाम addslashes mysqli_real_escape_string

मैं PHP अनुप्रयोगों हासिल करने पर कुछ पढ़ने कर रहा हूँ, और मुझे लगता है कि mysqli_real_escape_string क्योंकि addslashes कुछ अजीब चीजें एक के लिए होने के लिए पैदा कर सकता है जब MySQL तालिकाओं में डेटा डालने का उपयोग करने के लिए सही कार्य है बनाम स्मार्ट हमलावर सही?htmlentities बनाम addslashes mysqli_real_escape_string

हालांकि, एक बात है जो मुझे भ्रमित कर रही है। मुझे याद है कि addslasheshtmlentities से बेहतर है जब उपयोगकर्ता द्वारा दर्ज डेटा को अपने डेटा की सुरक्षा के लिए उपयोगकर्ताओं को वापस प्रतिबिंबित करते समय बेहतर लगता है, लेकिन ऐसा लगता है कि addslashes भेद्यता वाला एक है। क्या यह सच है, या मैं गलत तरीके से याद कर रहा हूँ?

स्रोत

2010-02-06 waiwai933

आपके डेटा के लिए अलग-अलग संदर्भ हैं। डेटाबेस में डेटा डालने का संदर्भ एचटीएमएल/एक्सएमएल या यहां तक कि एक ईमेल संदेश प्रस्तुत करने के संदर्भ से अलग से बचने की जरूरत है।

डीबी में जाने वाले डेटा से बचने के लिए तैयार कथन के पक्ष में सभी नए कोड में बहिष्कृत किया जाना चाहिए। कोई भी जो आपको अन्यथा बताता है वह आपको एक बड़ी अक्षमता कर रहा है।

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

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

स्रोत

2010-02-06 18:55:49

स्पीडवाइव, तैयार कथन केवल तभी बेहतर होते हैं जब आप एकल स्क्रिप्ट में कई बार तैयार क्वेरी का उपयोग कर रहे हों। अन्यथा, आप सर्वर पर दो राउंड ट्रिप कर रहे हैं, एक बार तैयार करने के लिए, और एक बार निष्पादित करने के लिए। यदि आप पहले से ही कोड का उपयोग कर रहे हैं जो स्वचालित रूप से इनपुट सत्यापन सुनिश्चित करता है, तो मुझे नहीं पता कि तैयार कथन बेहतर क्यों हैं। mysql दस्तावेज़ इसमें शामिल हैं। http://dev.mysql.com/tech-resources/articles/4.1/prepared-statements.html अगर मैं गलत हूं (यह संभव है और संभव है), कृपया मुझे बताएं क्यों। –

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

मैं बिल्कुल सहमत हूं। मैं अपने लिए प्रदर्शन के बारे में पूछ रहा था क्योंकि मुझे जवाब का यकीन नहीं है। मैंने यह स्पष्ट नहीं किया। –

आप PDO libs का भी उपयोग कर सकते हैं जो आपके लिए भागने में से अधिकांश है, यदि आप सर्वर पर PHP5 का उपयोग कर सकते हैं।

वापस गूंज मैं व्यक्तिगत रूप से htmlspecialchars पसंद करते हैं, उस पर है, लेकिन मुझे

स्रोत

2010-02-06 18:45:08 tDo

वे विभिन्न प्रयोजनों के लिए विभिन्न उपकरण हैं को दूर कर सकते हैं।

mysqli_real_escape_string MySQL में डालने के लिए डेटा सुरक्षित बनाता है (लेकिन parametrized क्वेरी बेहतर हैं)।

htmlentities एक HTML दस्तावेज़ में outputting

addslashes के लिए डेटा को सुरक्षित बनाता है कुछ अन्य परिस्थितियों के लिए सुरक्षित डेटा करता है, लेकिन MySQL

के लिए अपर्याप्त है

स्रोत

2010-02-06 18:49:02 Quentin

आपको ऐसे मामले को पोस्ट करना चाहिए जहां addlashes() विफल हो और mysql_real_escape_string() इसे रोक देता है। मुझे नहीं लगता कि आप कर सकते हैं, लेकिन यहां एक प्रश्न है जहां वे दोनों विफल हो जाते हैं: mysql_query ("उपयोगकर्ता से चुनें * आईडी =" $ _ प्राप्त करें [आईडी]); – rook

जोड़ों का मानना है कि सबकुछ 8 बिट है। mysql_real_escape_string अपने एन्कोडिंग करते समय वर्ण एन्कोडिंग को ध्यान में रखता है। सबूत: http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string –

@Eric, जिसे ठीक किया गया है। पूरी तरह से पैच किए गए सिस्टम पर अपना शोषण आज़माएं, यह असफल हो जाएगा। – rook

हाँ, सभी उपयोगकर्ता पर mysqli_real_escape_string या पीडीओ की तरह एक पुस्तकालय का उपयोग इनपुट। वापस प्रतिबिंबित करते समय, मैं दूसरे पैरामीटर के रूप में ENT_QUOTES के साथ htmlentities का उपयोग करता हूं, क्योंकि यह उद्धरण समेत सभी लागू वर्णों को उनके HTML इकाइयों से बचता है।

स्रोत

2010-02-06 18:49:30

नोट: यूटीएफ -8 एन्कोडेड दस्तावेज़ में htmlentities() का उपयोग टालना चाहिए।देखें:

वेतन ध्यान (phpwact.org से उद्धृत) करने के लिए:

आधुनिक वेब ब्राउज़र और UTF-8, आप डॉन के लिए 'widespead समर्थन के साथ
टी htmlentities की आवश्यकता है क्योंकि इन सभी वर्णों का प्रतिनिधित्व सीधेयूटीएफ -8 में। सबसे महत्वपूर्ण बात यह है कि सामान्य में, केवल ब्राउज़र ही HTML के विशेष वर्णों का समर्थन करते हैं - एक सामान्य पाठ संपादक, उदाहरण के लिए, HTML इकाइयों से अनजान है। पर निर्भर करते हुए, आप एचटीएमएलटीटी का उपयोग कर पर अपनी सामग्री को "उपभोग" करने की क्षमता को कम कर सकते हैं।

इसके अलावा (पुष्टि की लेकिन लगता है उचित नहीं - anon टिप्पणी यहाँ से), चरित्र संस्थाओं (सामान »या जैसे -) जब एक दस्तावेज आवेदन के रूप में परोसा जाता है/xml + एक्सएचटीएमएल (जब तक आप को परिभाषित काम नहीं करते उन्हें)। आप अभी भी संख्यात्मक रूप के साथ दूर जा सकते हैं। http://www.php.net/manual/en/book.filter.php

यह आप को मान्य और उपयोगकर्ता इनपुट को साफ़ करने में अनुमति देता है:

स्रोत

2010-02-06 19:13:18 Dor

'htmlentities()' का सामान्य उपयोग "अजीब" वर्णों को प्रतिपादित नहीं कर रहा है बल्कि मार्कअप के रूप में संभावित रूप से खतरनाक पाठ को पार्स करने के लिए नहीं है, और इसका एन्कोडिंग के साथ कुछ लेना देना नहीं है। –

संभावित खतरनाक पाठ से बचने के लिए htmlspecialchars() के साथ हासिल किया जा सकता है। htmlentities() में 'सुरक्षित' वर्णों को बदलने का ओवरहेड है और यह अतिरिक्त समस्याओं को प्रस्तुत करता है जिनका मैंने पहले उल्लेख किया था। – Dor

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

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

स्रोत

2010-02-06 19:24:30

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

$host=htmlspecialchars($_GET[host],ENT_QUOTES); 
$name=htmlspecialchars($_GET[name],ENT_QUOTES); 
mysql_query("select * from user where Host='$host' and Name='$name' ");

शोषण:: -% 201

mysql के लिए सबसे अच्छा भागने समारोह mysqli_real_escape_string है http://localhost/sqli_test.php?host= \ & नाम =% 20sleep (20)

उदाहरण के लिए इस क्वेरी एसक्यूएल इंजेक्शन के लिए असुरक्षित है(), लेकिन यह असफल हो सकता है:

mysql_query("select * from user where id=".mysqli_real_escape_string($_GET[id]));

शोषण: http://localhost/sqli_test.php?id=1%20or%20sleep(20)

वास्तव में एसक्यूएल इंजेक्शन की देखभाल करने का सबसे अच्छा तरीका एसक्यूएल इंजेक्शन के लिए एडीओडीबी की पैरामीट्रिज्ड क्वायर का उपयोग करके बचने का काम नहीं कर रहा है। XSS के लिए htmlspecialcahrs ($ var, ENT_QUTOES) का उपयोग करें।OWASP top 10 पढ़ें क्योंकि वेब एप्लिकेशन सुरक्षा के साथ गलत हो सकता है।

स्रोत

2010-02-06 21:27:17 rook

उत्तर

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