क्या मुझे is_email () फ़ंक्शन को पास करने से पहले एक ईमेल पते को पवित्र करना चाहिए?

13

is_email()यदि उपयोगकर्ता द्वारा प्रदान किया गया ईमेल पता मान्य है, तो मैं जाँच कर रहा हूँ । उदाहरण के लिए:

$email = $_POST['email'];
if ( is_email( $email ) )
    // Do something.

मेरे ज्ञान का सबसे अच्छा करने के लिए, इस समारोह में कुछ भी डेटाबेस के लिए जानकारी नहीं लिखता है। $emailइससे पहले कि मैं इसे समारोह में पास करूं, क्या मुझे सफाई देनी चाहिए ?

sanitization

— henrywright
स्रोत

कैसर, संपादन के लिए धन्यवाद। यह वास्तव में मेरे लिए स्वच्छता है लेकिन मुझे यकीन है कि यहां अधिकांश पाठक एक z का उपयोग करेंगे :)

— henrywright

5

is_email()Trac पर कार्यक्षमता को देखते हुए , ऐसा लगता है कि आपको sanatizie की आवश्यकता नहीं है क्योंकि यह सिर्फ स्ट्रिंग परीक्षण है। मैं यहां तक कहूंगा कि यदि यह फ़ंक्शन सही है, तो डेटाबेस में भेजने से पहले आपको इसे साफ करने की आवश्यकता नहीं होगी।

— Howdy_McGee
स्रोत

स्ट्रिंग परीक्षण के बारे में मेरे विचार। मुझे लगता है कि मैं अभी भी db को भेजने से पहले स्वच्छता करूंगा, आप शायद सही हैं कि यह आवश्यक नहीं है, लेकिन जब मैं इन चीजों की बात करता हूं तो मैं घबरा जाता हूं :)

— henrywright

सही है, सॉरी से बेहतर सुरक्षित है और उपरीकरण पूरी तरह से ध्यान देने योग्य नहीं है।

— Howdy_McGee

18

वर्डप्रेस और PHP कोर

is_email()समारोह ^{स्रोत} एक विशिष्ट वर्डप्रेस कार्यान्वयन है और क्या साथ पूरी तरह से काम नहीं करता है आरएफसी 6531 अनुमति देता है। एक कारण यह हो सकता है, कि इंटरनेट इंजीनियरिंग टास्क फोर्स (IETF®) के दिशानिर्देशों के अनुसार डिफ़ॉल्ट PHP FILTER_VALIDATE_EMAILस्थिरांक filter_var()कुछ बेहतर करने के लिए बेहतर नहीं है ।

मानक

बिंदु यह है कि RFC 6531 "ASCII रेंज से परे यूनिकोड वर्ण" की अनुमति देता है । अर्थात् वे (स्थानीय भाग के लिए @) से पहले हैं :

अपरकेस और अंग्रेजी अक्षरों को कम करना (a-z, A-Z) (ASCII: 65-90, 97-122)

अंक 0के लिए 9(ASCII: 48-57)

ये खास पात्र: ! # $ % & ' * + - / = ? ^ _ ` { | } ~

चरित्र .(डॉट, अवधि, पूर्ण विराम) (ASCII: 46) बशर्ते कि यह पहला या अंतिम चरित्र नहीं है, और यह भी प्रदान किया जाता है कि यह लगातार दिखाई John..Doe@example.comनहीं देता है (उदाहरण की अनुमति नहीं है)।

प्रतिबंधों के साथ विशेष पात्रों की अनुमति है। वो हैं:

अंतरिक्ष और "(),:;<>@[\](ASCII: 32, 34, 40, 41, 44, 58, 59, 60, 62, 64, 91-93)

विशेष वर्णों के लिए प्रतिबंध यह है कि उनका उपयोग केवल उद्धरण चिह्नों के बीच होने पर ही किया जाना चाहिए, और उनमें से 2 (बैकस्लैश \ _ और उद्धरण चिह्न "(ASCII: 92, 34)) भी बैकस्लैश \(जैसे "\\"और "\"") से पहले होना चाहिए ।

स्थानीय भाग के किसी भी छोर पर कोष्ठक के साथ टिप्पणियों की अनुमति है; जैसे john.smith(comment)@example.comऔर (comment)john.smith@example.comदोनों समान हैं "john.smith@example.com", लेकिन john.(comment)smith@example.comअमान्य होगा।

उपरोक्त अंतर्राष्ट्रीय वर्ण U+007F, UTF-8 के रूप में एन्कोडेड हैं, RFC 6531 द्वारा अनुमति दी जाती है, हालांकि मेल सिस्टम स्थानीय वर्णों को निर्दिष्ट करते समय किन वर्णों का उपयोग करने के लिए प्रतिबंधित कर सकता है।

और वैश्विक / डोमेन भाग के लिए:

ईमेल पते के डोमेन नाम के हिस्से को सख्त दिशानिर्देशों के अनुरूप होना चाहिए: यह एक होस्टनाम के लिए आवश्यकताओं से मेल खाना चाहिए, जिसमें अक्षर, अंक, हाइफ़न और डॉट्स शामिल हैं। इसके अलावा, डोमेन भाग एक आईपी पता शाब्दिक, जैसे वर्ग कोष्ठकों से घिरा हुआ हो सकता है jsmith@[192.168.2.1]या jsmith@[IPv6:2001:db8::1][...]

^{स्रोत: विकिपीडिया}

क्या वैध है?

इससे निम्नलिखित जैसे अजीब, लेकिन मान्य ई-मेल पते हो सकते हैं:

localpart.ending.with.dot.@example.com

(comment)localpart@example.com

"this is v@lid!"@example.com

"much.more unusual"@example.com

postbox@com

admin@mailserver1

"()<>[]:,;\\@\"\\\\!#$%&\'*+-/=?^_`{}| ~.a"@example.org

" "@example.org

^{स्रोत: php.net / लेखक gt@kani.hu - इस पोस्ट के लेखक द्वारा निर्धारित उदाहरण}

सीमाएं

स्थानीय और डोमेन लंबाई सीमाएँ भी हैं:

ईमेल पतों का प्रारूप वह स्थान है local-part@domainजहाँ स्थानीय-भाग 64 वर्णों तक लंबा हो सकता है और डोमेन नाम में अधिकतम 253 वर्ण हो सकते हैं - लेकिन आगे या पीछे के मार्ग की अधिकतम 256-वर्ण लंबाई संपूर्ण ईमेल पते को प्रतिबंधित करती है हो कोई और अधिक से अधिक 254 वर्ण लंबा । [2] औपचारिक परिभाषा RFC 5322 में हैं (वर्गों 3.2.3 और 3.4.1) और आरएफसी 5321 - सूचना के आरएफसी 3696 [3] और संबद्ध शुद्धिपत्र में दी गई एक और अधिक पठनीय रूप के साथ ।

^{स्रोत: विकिपीडिया}

वर्डप्रेस प्रतिबंध

और यही वर्डप्रेस चेक के लिए है:

ईमेल की न्यूनतम लंबाई के लिए टेस्ट हो सकता है: strlen( $email ) < 3
पहली स्थिति के बाद एक @ चरित्र के लिए परीक्षण करें: strpos( $email, '@', 1 ) === false
अमान्य वर्णों का परीक्षण: !preg_match( '/^[a-zA-Z0-9!#$%&\'*+\/=?^_`{|}~\.-]+$/', $local )
अवधि के अनुक्रम के लिए टेस्ट: preg_match( '/\.{2,}/', $domain )
अग्रणी और अनुगामी अवधि और व्हाट्सएप के लिए टेस्ट: trim( $domain, " \t\n\r\0\x0B." ) !== $domain
मान लें कि डोमेन में कम से कम दो उप-होंगे: $subs = explode( '.', $domain );और फिर
- 2 > count( $subs )
- trim( $sub, " \t\n\r\0\x0B-" ) !== $sub
- !preg_match('/^[a-z0-9-]+$/i', $sub )

^{स्रोत: WP कोर v4.0}

फिल्टर और कस्टम सत्यापन

उपर्युक्त सभी मामले is_email()झूठे वापस करने के लिए ट्रिगर होंगे । परिणाम फ़िल्टर-सक्षम (एक कॉलबैक संलग्न किया जा सकता है) और फ़िल्टर में तीन तर्क होंगे, जहां अंतिम तर्क कारण है। उदाहरण:

return apply_filters( 'is_email', false, $email, 'sub_hyphen_limits' );

जिसका अर्थ है कि आप विशिष्ट चेक द्वारा लौटे परिणामों को ओवरराइड कर सकते हैं।

यह आपको विशेष चेक जोड़ने की अनुमति देता है, उदाहरण के लिए, उमलौट-डोमेन, टीएलडी-ओनली डोमेन पार्ट्स, आदि की अनुमति देने के लिए।

निष्कर्ष

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

संपादित करें

मजेदार साइडफैक्ट: अंदर दो संबंधित कार्य हैं ~/wp-includes/formatting: is_email()और sanitize_email()। वे व्यावहारिक रूप से एक ही कार्य हैं। मुझे नहीं पता कि किसी ने यह क्यों तय किया कि फ़ंक्शन सामग्री को एक से दूसरे में कॉपी करने के बजाय केवल एक को दूसरे को कॉलबैक के रूप में जोड़ने के बजाय दूसरे प्रदान करता है। के रूप में ^{v0.71 के बाद से} और ^{v1.5 के बाद से} ही कर रहे हैं, मैं व्यक्तिगत रूप से बाद में उपयोग के रूप में आप एक साफ स्ट्रिंग मिलेगा। ध्यान दें कि यहां तक कि यह भी कहा जाता है कि यह RFC अनुरूप नहीं हैis_email() sanitize_email() is_email()

— कैसर
स्रोत

तो आप कह रहे हैं, सिद्धांत रूप में, वहाँ ईमेल पते होंगे जो RFC 6531 के अनुसार पूरी तरह से मान्य हैं लेकिन इन्हें वर्डप्रेस द्वारा अमान्य माना जाएगा?

— हेनरीराइट

कुछ हाँ। उदाहरण के लिए TLD-only डोमेन, umlaut डोमेन, आदि। जैसा कि आप उत्तर में निष्कर्ष से पहले अंतिम पैराग्राफ में पढ़ सकते हैं। कृपया जवाब फिर से पढ़ें। मुझे पता है कि अपने सिर को चारों ओर लपेटना बहुत है, लेकिन यह इसके लायक है।

— केसर

1

मैं वास्तव में पहले से ही इसे दो बार पढ़ चुका हूं क्योंकि यह कुछ ऐसा है जो समझने लायक है! इस तरह के एक विस्तृत जवाब के लिए धन्यवाद :)

— henrywright

2

सभी चीजों को पवित्र करें!

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

— JesseM
स्रोत

मुझे लगता है कि आपने सिर पर कील ठोक दी थी जब आपने कहा था कि आपको कभी नहीं पता होगा कि कार्यान्वयन बदल जाएगा। अब स्वच्छता नहीं करना ठीक हो सकता है, लेकिन कौन जानता है कि बाद की तारीख में बदल जाएगा?

— हेनरीराइट