पर्लसेक - क्लाउड में ऑनलाइन

कार्यक्रम:

नाम

पर्लसेक - पर्ल सुरक्षा

वर्णन

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

सुरक्षा भेद्यता संपर्क（CONTACT） जानकारी

यदि आपको लगता है कि आपको पर्ल में कोई सुरक्षा भेद्यता मिली है, तो कृपया ईमेल करें
[ईमेल संरक्षित] विवरण के साथ. यह एक बंद सदस्यता की ओर इशारा करता है,
अनारक्षित मेलिंग सूची. कृपया इस पते का उपयोग केवल पर्ल में सुरक्षा समस्याओं के लिए करें
कोर, सीपीएएन पर स्वतंत्र रूप से वितरित मॉड्यूल के लिए नहीं।

सुरक्षा तंत्र और चिंताओं

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

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

आप अपने प्रोग्राम के बाहर से प्राप्त डेटा का उपयोग किसी अन्य चीज़ को प्रभावित करने के लिए नहीं कर सकते
आपका कार्यक्रम--कम से कम, संयोगवश नहीं। सभी कमांड लाइन तर्क, पर्यावरण
चर, स्थानीय जानकारी (परलोकेल देखें), कुछ सिस्टम कॉल के परिणाम
("readdir()", "readlink()", "shmread()" का वेरिएबल, द्वारा लौटाए गए संदेश
"msgrcv()", पासवर्ड, gcos और शेल फ़ील्ड्स "getpwxxx()" कॉल द्वारा लौटाए गए), और
सभी फ़ाइल इनपुट को "दागी" के रूप में चिह्नित किया गया है। दूषित डेटा का सीधे तौर पर उपयोग नहीं किया जा सकता है
अप्रत्यक्ष रूप से किसी भी कमांड में जो उप-शेल को आमंत्रित करता है, न ही किसी कमांड में जो संशोधित करता है
फ़ाइलें, निर्देशिकाएँ, या प्रक्रियाएँ, साथ में la निम्नलिखित अपवाद:

· "प्रिंट" और "सिसराइट" के तर्क हैं नहीं दागीपन के लिए जाँच की गई।

· प्रतीकात्मक तरीके

$obj->$विधि (@args);

और प्रतीकात्मक उप संदर्भ

&{$foo}@args);
$foo->@args);

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

· हैश कुंजियाँ हैं कभी नहीँ दागी.

दक्षता कारणों से, पर्ल इस बात पर रूढ़िवादी दृष्टिकोण रखता है कि क्या डेटा दूषित है। यदि एक
अभिव्यक्ति में दूषित डेटा शामिल है, किसी भी उपअभिव्यक्ति को दूषित माना जा सकता है, भले ही
उपअभिव्यक्ति का मूल्य स्वयं दूषित डेटा से प्रभावित नहीं होता है।

क्योंकि दाग प्रत्येक अदिश मान, किसी सरणी के कुछ तत्वों या के साथ जुड़ा हुआ है
हैश दूषित हो सकता है और अन्य नहीं। हैश की कुंजी हैं कभी नहीँ दागी.

उदाहरण के लिए:

$arg = शिफ्ट; # $arg दागी है
$hid = $arg। 'छड़'; # $hid भी दागदार है
$लाइन = <>; #दागदार
$लाइन = ; #दागदार भी
FOO खोलें, "/home/me/bar" या $ मरें!;
$लाइन = ; #अभी भी दागदार
$पथ = $ENV{'पथ'}; # दागी, लेकिन नीचे देखें
$डेटा = 'एबीसी'; # दागदार नहीं

सिस्टम "इको $arg"; # असुरक्षित
प्रणाली "/बिन/गूंज", $arg; # असुरक्षित माना जाता है
# (पर्ल को इसके बारे में नहीं पता /बिन/गूंज)
सिस्टम "इको $hid"; # असुरक्षित
सिस्टम "इको $डेटा"; # PATH सेट होने तक असुरक्षित

$पथ = $ENV{'पथ'}; # $पथ अब दूषित है

$ENV{'पथ'} = '/ bin:/ Usr / bin';
@ENV{'IFS', 'CDPATH', 'ENV', 'BASH_ENV'} हटाएं;

$पथ = $ENV{'पथ'}; # $पथ अब दागी नहीं है
सिस्टम "इको $डेटा"; #अब सुरक्षित है!

खुला(FOO, "<$arg"); # ठीक - केवल पढ़ने योग्य फ़ाइल
खुला(FOO, "> $arg"); # ठीक नहीं - लिखने का प्रयास कर रहा हूँ

खुला(FOO,'echo $arg|'); # ठीक नहीं है
खुला(FOO,"-|")
या 'इको' निष्पादित करें, $arg; # ठीक भी नहीं

$चिल्लाना = `प्रतिध्वनि $arg`; # असुरक्षित, $चिल्लाओ अब दागी

$डेटा, $arg को अनलिंक करें; # असुरक्षित
उमास्क $arg; # असुरक्षित

निष्पादन "इको $arg"; # असुरक्षित
निष्पादन "प्रतिध्वनि", $arg; # असुरक्षित
निष्पादन "श", '-सी', $arg; #बहुत असुरक्षित!

@फ़ाइलें = <*.c>; # असुरक्षित (readdir() या समान का उपयोग करता है)
@फ़ाइलें = ग्लोब('*.c'); # असुरक्षित (readdir() या समान का उपयोग करता है)

# किसी भी स्थिति में, ग्लोब के परिणाम दागी हैं, क्योंकि सूची
# फ़ाइलनाम प्रोग्राम के बाहर से आते हैं.

$बुरा = ($arg, 23); #$बुरा दागदार होगा
$arg, `सत्य`; #असुरक्षित (हालाँकि यह वास्तव में नहीं है)

यदि आप कुछ असुरक्षित करने का प्रयास करते हैं, तो आपको कुछ ऐसा कहते हुए एक घातक त्रुटि प्राप्त होगी
"असुरक्षित निर्भरता" या "असुरक्षित $ENV{PATH}"।

"एक दूषित मूल्य पूरी अभिव्यक्ति को कलंकित कर देता है" के सिद्धांत का अपवाद है
टर्नरी सशर्त ऑपरेटर "?:"। एक टर्नरी सशर्त के साथ कोड के बाद से

$परिणाम = $दागी_मान? "बेदाग" : "बेदाग भी";

प्रभावी ढंग से है

अगर ($ दागी_मूल्य) {
$परिणाम = "बेदाग";
और} {
$परिणाम = "यह भी बेदाग";
}

$result के ख़राब होने का कोई मतलब नहीं है।

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

उप दागी है {
स्थानीय $@; #कॉल करने वाले के मान को प्रदूषित न करें.
वापस करना ! eval { eval("#" .substr(join("", @_), 0, 0)); 1 };
}

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

लेकिन दागीपन का परीक्षण आपको अभी तक ही मिलता है। कभी-कभी आपको बस अपना साफ़ करना होता है
डेटा का दागी होना. हैश में कुंजी के रूप में उपयोग करके मूल्यों को बेदाग किया जा सकता है; अन्यथा
टैनिंग तंत्र को बायपास करने का एकमात्र तरीका नियमित रूप से उपपैटर्न को संदर्भित करना है
अभिव्यक्ति मिलान. पर्ल का मानना ​​है कि यदि आप $1, $2, आदि का उपयोग करके किसी सबस्ट्रिंग का संदर्भ देते हैं
गैर-कलंककारी पैटर्न, कि आप जानते थे कि आप क्या कर रहे थे जब आपने वह पैटर्न लिखा था। वह
इसका अर्थ है थोड़ी सी सोच-विचार का उपयोग करना--किसी भी चीज़ को आँख मूँद कर अनदेखा न करें, अन्यथा आप हार जायेंगे
संपूर्ण तंत्र. यह सत्यापित करना बेहतर है कि वेरिएबल में केवल अच्छे अक्षर हैं (के लिए)।
"अच्छे" के कुछ मान) को जाँचने के बजाय कि इसमें कोई ख़राब लक्षण हैं या नहीं। वह है
क्योंकि उन बुरे चरित्रों को छोड़ना बहुत आसान है जिनके बारे में आपने कभी नहीं सोचा था।

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

अगर ($डेटा =~ /^([-\@\w.]+)$/) {
$डेटा = $1; # $डेटा अब बेदाग है
और} {
मरो "'$डेटा' में ख़राब डेटा"; # इसे कहीं लॉग इन करें
}

यह काफी सुरक्षित है क्योंकि "/\w+/" सामान्यतः शेल मेटाकैरेक्टर्स से मेल नहीं खाता है, न ही मेल खाता है
डॉट, डैश, या शैल के लिए कुछ विशेष मतलब होने जा रहा है। का उपयोग "/.+/" होगा
सिद्धांत रूप में यह असुरक्षित है क्योंकि यह सब कुछ होने देता है, लेकिन पर्ल इसकी जाँच नहीं करता है
वह। सबक यह है कि बेदाग होने पर आपको अपने प्रति अत्यधिक सावधान रहना चाहिए
पैटर्न. रेगुलर एक्सप्रेशन का उपयोग करके डेटा को लॉन्डर करना है केवल निष्कासन के लिए तंत्र
गंदा डेटा, जब तक कि आप कम पैसे वाले बच्चे से शुल्क लेने के लिए नीचे दी गई विस्तृत रणनीति का उपयोग न करें
विशेषाधिकार।

यदि "स्थान का उपयोग करें" प्रभाव में है, तो उदाहरण $ डेटा को दागदार नहीं करता है, क्योंकि वर्ण
"\w" से मिलान स्थान द्वारा निर्धारित किया जाता है। पर्ल का मानना ​​है कि स्थानीय परिभाषाएँ हैं
अविश्वसनीय क्योंकि उनमें प्रोग्राम के बाहर का डेटा होता है। यदि आप लिख रहे हैं
स्थानीय-जागरूक प्रोग्राम, और "\w" वाले नियमित अभिव्यक्ति के साथ डेटा को लॉन्डर करना चाहते हैं,
उसी ब्लॉक में अभिव्यक्ति के आगे "कोई स्थान नहीं" रखें। परलोकेल में "सुरक्षा" देखें
आगे की चर्चा और उदाहरणों के लिए।

स्विच On la "#!" लाइन
जब आप किसी स्क्रिप्ट को निष्पादन योग्य बनाते हैं, तो उसे कमांड के रूप में प्रयोग करने योग्य बनाने के लिए, सिस्टम
स्क्रिप्ट के # से पर्ल पर स्विच पास करेगा! रेखा। पर्ल किसी भी कमांड लाइन की जाँच करता है
सेटुइड (या सेटगिड) स्क्रिप्ट को दिए गए स्विच वास्तव में # पर सेट किए गए स्विच से मेल खाते हैं! रेखा।
कुछ यूनिक्स और यूनिक्स जैसे वातावरण # पर एक-स्विच सीमा लगाते हैं! लाइन, तो आप कर सकते हैं
ऐसी प्रणालियों के तहत "-w -U" के बजाय "-wU" जैसी किसी चीज़ का उपयोग करने की आवश्यकता है। (यह मुद्दा
केवल यूनिक्स या यूनिक्स जैसे वातावरण में उत्पन्न होना चाहिए जो # का समर्थन करते हैं! और सेतुइड या सेटगिड
स्क्रिप्ट.)

कलंक मोड और @आईएनसी
जब दाग मोड ("-टी") प्रभावी होता है, तो "।" निर्देशिका को @INC से हटा दिया गया है, और
पर्यावरण चर "PERL5LIB" और "PERLLIB" को पर्ल द्वारा अनदेखा किया जाता है। आप अभी भी समायोजित कर सकते हैं
जैसा कि इसमें बताया गया है, "-I" कमांड लाइन विकल्प का उपयोग करके प्रोग्राम के बाहर से @INC करें
perlrun. दो पर्यावरण चर को नजरअंदाज कर दिया जाता है क्योंकि वे अस्पष्ट हैं, और एक उपयोगकर्ता
किसी प्रोग्राम को चलाने से यह पता नहीं चल पाता कि वे सेट हैं, जबकि "-I" विकल्प स्पष्ट रूप से है
दृश्यमान और इसलिए अनुमति है।

प्रोग्राम को संशोधित किए बिना @INC को संशोधित करने का दूसरा तरीका "lib" प्राग्मा का उपयोग करना है,
उदाहरण के लिए:

perl -Mlib=/foo प्रोग्राम

"-I/foo" के स्थान पर "-Mlib=/foo" का उपयोग करने का लाभ यह है कि पहला स्वचालित रूप से काम करेगा
किसी भी डुप्लिकेट निर्देशिका को हटा दें, जबकि बाद वाली नहीं हटाई जाएंगी।

ध्यान दें कि यदि @INC में एक दूषित स्ट्रिंग जोड़ी जाती है, तो निम्न समस्या रिपोर्ट की जाएगी:

-T स्विच के साथ चलते समय असुरक्षित निर्भरता की आवश्यकता होती है

सफाई Up आपका पथ
"असुरक्षित $ENV{PATH}" संदेशों के लिए, आपको $ENV{'PATH'} को एक ज्ञात मान पर सेट करना होगा, और
पथ में प्रत्येक निर्देशिका उसके स्वामी के अलावा अन्य लोगों द्वारा पूर्ण और गैर-लिखने योग्य होनी चाहिए
समूह। आप यह संदेश पाकर आश्चर्यचकित हो सकते हैं, भले ही आपके निष्पादन योग्य का पथनाम
पूर्णतः योग्य है. यह है नहीं उत्पन्न हुआ क्योंकि आपने पूर्ण पथ प्रदान नहीं किया
कार्यक्रम; इसके बजाय, यह उत्पन्न होता है क्योंकि आपने अपना PATH पर्यावरण चर कभी सेट नहीं किया है, या
आपने इसे किसी ऐसी चीज़ पर सेट नहीं किया जो सुरक्षित हो। क्योंकि पर्ल इसकी गारंटी नहीं दे सकता
प्रश्न में निष्पादन योग्य स्वयं घूमने और किसी अन्य प्रोग्राम को निष्पादित करने वाला नहीं है
यह आपके PATH पर निर्भर है, यह सुनिश्चित करता है कि आपने PATH सेट किया है।

PATH एकमात्र पर्यावरण चर नहीं है जो समस्याएँ पैदा कर सकता है। क्योंकि कुछ
शेल्स IFS, CDPATH, ENV, और BASH_ENV वेरिएबल्स का उपयोग कर सकते हैं, पर्ल जाँच करता है कि वे हैं
उपप्रक्रियाएँ प्रारंभ करते समय या तो खाली या बेदाग। आप ऐसा कुछ जोड़ना चाह सकते हैं
यह आपकी सेटिड और दाग-जांच स्क्रिप्ट के लिए है।

@ENV{qw(IFS CDPATH ENV BASH_ENV)} हटाएं; # %ENV को सुरक्षित बनायें

अन्य परिचालनों में परेशानी आना भी संभव है, जिनकी उन्हें कोई परवाह नहीं है
दूषित मूल्यों का प्रयोग करें. किसी भी उपयोगकर्ता से निपटने में फ़ाइल परीक्षणों का विवेकपूर्ण उपयोग करें-
प्रदत्त फ़ाइल नाम. जब संभव हो, ओपन वगैरह करें बाद किसी विशेष को ठीक से छोड़ना
उपयोगकर्ता (या समूह!) विशेषाधिकार। पर्ल आपको दूषित फ़ाइल नाम खोलने से नहीं रोकता है
पढ़ रहे हैं, इसलिए सावधान रहें कि आप क्या प्रिंट कर रहे हैं। दागी तंत्र का उद्देश्य रोकथाम करना है
मूर्खतापूर्ण गलतियाँ, विचार की आवश्यकता को दूर करने के लिए नहीं।

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

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

यहां यथोचित सुरक्षित रूप से बैकटिक्स करने का एक तरीका दिया गया है। ध्यान दें कि कैसे "कार्यकारी" को नहीं बुलाया जाता है
एक स्ट्रिंग जिसका खोल विस्तार कर सकता है। किसी चीज़ को कॉल करने का यह अब तक का सबसे अच्छा तरीका है
शेल एस्केप का शिकार हो सकते हैं: शेल को कभी भी कॉल न करें।

अंग्रेजी का उपयोग करो;
मरो "कांटा नहीं कर सकते: $!" जब तक परिभाषित न किया जाए ($pid = open(KID, "-|"));
यदि ($pid) { # अभिभावक
जबकि ( ) {
# कुछ करो
}
बच्चे को बंद करें;
और} {
मेरा @temp = ($EUID, $EGID);
मेरा $orig_uid = $UID;
मेरा $orig_gid = $GID;
$ईयूआईडी = $यूआईडी;
$ईजीआईडी ​​= $जीआईडी;
# विशेषाधिकार छोड़ें
$यूआईडी = $orig_uid;
$GID = $orig_gid;
#सुनिश्चित करें कि निजी वस्तुएँ वास्तव में समाप्त हो गई हैं
($ ईयूआईडी, $ ईजीआईडी) = @temp;
मरो "विशेषाधिकार नहीं छोड़ सकते"
जब तक $UID == $EUID && $GID eq $EGID;
$ENV{PATH} = "/ bin:/ Usr / bin"; # न्यूनतम पथ.
#पर्यावरण को और भी अधिक स्वच्छ बनाने पर विचार करें.
कार्यकारी 'myprog', 'arg1', 'arg2'
या मरो "myprog निष्पादित नहीं कर सकता: $!";
}

एक समान रणनीति "ग्लोब" के माध्यम से वाइल्डकार्ड विस्तार के लिए काम करेगी, हालांकि आप इसका उपयोग कर सकते हैं
इसके बजाय "readdir"।

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

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

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

सौभाग्य से, कभी-कभी इस कर्नेल "सुविधा" को अक्षम किया जा सकता है। दुर्भाग्य से, वहाँ हैं
इसे निष्क्रिय करने के दो तरीके. सिस्टम किसी भी सेट-आईडी बिट सेट वाली स्क्रिप्ट को गैरकानूनी घोषित कर सकता है,
जो ज्यादा मदद नहीं करता. वैकल्पिक रूप से, यह स्क्रिप्ट पर सेट-आईडी बिट्स को आसानी से अनदेखा कर सकता है।

हालाँकि, यदि कर्नेल सेट-आईडी स्क्रिप्ट सुविधा अक्षम नहीं है, तो पर्ल ज़ोर से शिकायत करेगा
कि आपकी सेट-आईडी स्क्रिप्ट असुरक्षित है। आपको या तो कर्नेल सेट-आईडी को अक्षम करना होगा
स्क्रिप्ट सुविधा, या स्क्रिप्ट के चारों ओर C रैपर लगाएं। एसी रैपर सिर्फ एक संकलित है
प्रोग्राम जो आपके पर्ल प्रोग्राम को कॉल करने के अलावा कुछ नहीं करता है। संकलित कार्यक्रम नहीं हैं
कर्नेल बग के अधीन जो सेट-आईडी स्क्रिप्ट को प्रभावित करता है। यहां एक साधारण रैपर लिखा हुआ है
सी में:

#वास्तविक_पथ को परिभाषित करें "/पथ/से/स्क्रिप्ट"
मुख्य(एसी, एवी)
चार**एवी;
{
execv(REAL_PATH, av);
}

इस रैपर को बाइनरी एक्ज़ीक्यूटेबल में संकलित करें और फिर बनाएं it आपकी स्क्रिप्ट के बजाय
सेतुइड या सेटगिड.

हाल के वर्षों में, विक्रेताओं ने इस अंतर्निहित सुरक्षा बग से मुक्त सिस्टम की आपूर्ति शुरू कर दी है।
ऐसे सिस्टम पर, जब कर्नेल खोलने के लिए सेट-आईडी स्क्रिप्ट का नाम पास करता है
दुभाषिया, हस्तक्षेप के अधीन पथनाम का उपयोग करने के बजाय, इसे पारित कर देता है
/देव/एफडी/3. यह स्क्रिप्ट पर पहले से ही खोली गई एक विशेष फ़ाइल है, ताकि कोई भी न हो
दुष्ट लिपियों के शोषण हेतु दौड़ की स्थिति। इन प्रणालियों पर, पर्ल को संकलित किया जाना चाहिए
"-DSETUID_SCRIPTS_ARE_SECURE_NOW" के साथ। कॉन्फ़िगर प्रोग्राम जो पर्ल बनाता है वह प्रयास करता है
इसे स्वयं ही समझ लें, इसलिए आपको कभी भी इसे स्वयं निर्दिष्ट नहीं करना पड़ेगा। अधिकांश
SysVr4 और BSD 4.4 के आधुनिक रिलीज़ कर्नेल रेस से बचने के लिए इस दृष्टिकोण का उपयोग करते हैं
शर्त।

रक्षा आपका प्रोग्राम्स
आपके पर्ल प्रोग्राम के स्रोत को अलग-अलग स्तरों पर छिपाने के कई तरीके हैं
"सुरक्षा" का.

हालाँकि, सबसे पहले, आप नहीं कर सकते हैं पढ़ने की अनुमति हटा दें, क्योंकि स्रोत कोड को ऐसा करना होगा
संकलित और व्याख्या किए जाने के लिए पठनीय होना चाहिए। (इसका मतलब यह नहीं है कि सीजीआई
हालाँकि, स्क्रिप्ट का स्रोत वेब पर लोगों द्वारा पढ़ने योग्य है।) इसलिए आपको इसे छोड़ना होगा
सामाजिक रूप से अनुकूल 0755 स्तर पर अनुमतियाँ। इससे लोगों को आपके स्थानीय सिस्टम पर मदद मिलती है
केवल अपना स्रोत देखें.

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

आप स्रोत फ़िल्टर (सीपीएएन से फ़िल्टर::*, या) के माध्यम से एन्क्रिप्शन का उपयोग करने का प्रयास कर सकते हैं
फ़िल्टर::उपयोग::कॉल और फ़िल्टर::पर्ल 5.8 के बाद से सरल)। लेकिन पटाखे सक्षम हो सकते हैं
इसे डिक्रिप्ट करें. आप नीचे वर्णित बाइट कोड कंपाइलर और दुभाषिया का उपयोग करने का प्रयास कर सकते हैं, लेकिन
पटाखे इसे डी-कंपाइल करने में सक्षम हो सकते हैं। आप नेटिव-कोड कंपाइलर का उपयोग करने का प्रयास कर सकते हैं
नीचे वर्णित है, लेकिन पटाखे इसे अलग करने में सक्षम हो सकते हैं। ये अलग-अलग डिग्री की मुद्रा बनाते हैं
आपके कोड तक पहुंचने के इच्छुक लोगों के लिए कठिनाई है, लेकिन कोई भी इसे निश्चित रूप से छिपा नहीं सकता है
(यह सिर्फ पर्ल ही नहीं, हर भाषा के लिए सच है)।

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

यूनिकोड
यूनिकोड एक नई और जटिल तकनीक है और कोई भी कुछ सुरक्षा को आसानी से नजरअंदाज कर सकता है
ख़तरे सिंहावलोकन के लिए perluniintro और विवरण के लिए perlunicode और "सुरक्षा" देखें
विशेष रूप से सुरक्षा निहितार्थों के लिए पर्लुनिकोड में यूनिकोड के निहितार्थ।

एल्गोरिथम जटिलता आक्रमण
पर्ल के कार्यान्वयन में प्रयुक्त कुछ आंतरिक एल्गोरिदम पर चुनकर हमला किया जा सकता है
बड़ी मात्रा में समय या स्थान या दोनों का उपभोग करने के लिए इनपुट सावधानी से करें। ये हो सकता है
तथाकथित में नेतृत्व करें इनकार of सर्विस (DoS) आक्रमण करता है।

· हैश एल्गोरिदम - पर्ल में उपयोग किए जाने वाले हैश एल्गोरिदम सर्वविदित हैं
उनके हैश फ़ंक्शन पर टकराव के हमलों का खतरा है। ऐसे हमलों में शामिल हैं
चाबियों का एक सेट बनाना जो एक ही बाल्टी में टकराता है, अकुशल उत्पादन करता है
व्यवहार। ऐसे हमले अक्सर इस्तेमाल किए गए हैश फ़ंक्शन के बीज की खोज पर निर्भर करते हैं
बाल्टियों की चाबियाँ मैप करने के लिए। फिर उस बीज का उपयोग एक कुंजी सेट को बलपूर्वक करने के लिए किया जाता है जो कर सकता है
सेवा हमले से इनकार करने के लिए इस्तेमाल किया जा सकता है। पर्ल 5.8.1 में परिवर्तन प्रस्तुत किये गये
पर्ल को ऐसे हमलों के लिए कठोर बनाना, और फिर बाद में पर्ल 5.18.0 में ये विशेषताएं थीं
उन्नत और अतिरिक्त सुरक्षा जोड़ी गई।

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

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

हैश ट्रैवर्सल रैंडमाइजेशन
हैश फ़ंक्शन में किस बीज का उपयोग किया जाता है, इससे स्वतंत्र, "कुंजियाँ", "मान", और
"प्रत्येक" प्रति-हैश यादृच्छिक क्रम में आइटम लौटाता है। सम्मिलन द्वारा हैश को संशोधित करना
उस हैश के पुनरावृत्ति क्रम को बदल देगा। इस व्यवहार को ओवरराइड किया जा सकता है
Hash::Util से "hash_traversal_mask()" का उपयोग करके या PERL_PERTURB_KEYS का उपयोग करके
पर्यावरण चर, perlrun में "PERL_PERTURB_KEYS" देखें। ध्यान दें कि यह सुविधा
कुंजियों के "दृश्यमान" क्रम को नियंत्रित करता है, न कि उनके संग्रहीत वास्तविक क्रम को
अंदर

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

नया डिफ़ॉल्ट हैश फ़ंक्शन
डिफ़ॉल्ट हैश फ़ंक्शन को कठिन बनाने के इरादे से संशोधित किया गया है
हैश बीज का अनुमान लगाने के लिए.

वैकल्पिक हैश फ़ंक्शंस
स्रोत कोड में चुनने के लिए कई हैश एल्गोरिदम शामिल हैं। हालांकि हम
विश्वास है कि डिफ़ॉल्ट पर्ल हैश हमला करने के लिए मजबूत है, हमने हैश को शामिल कर लिया है
सिफ़ाश को फ़ॉल-बैक विकल्प के रूप में कार्य करें। पर्ल 5.18.0 के रिलीज़ के समय
माना जाता है कि सिफाश क्रिप्टोग्राफ़िक ताकत वाला होता है। यह डिफ़ॉल्ट नहीं है
यह डिफ़ॉल्ट हैश से बहुत धीमा है।

एक विशेष पर्ल को संकलित किए बिना, बिल्कुल वैसा ही व्यवहार प्राप्त करने का कोई तरीका नहीं है
पर्ल 5.18.0 से पहले का कोई भी संस्करण। सेटिंग से ही निकटतम व्यक्ति प्राप्त किया जा सकता है
PERL_PERTURB_KEYS को 0 पर रखें और PERL_HASH_SEED को ज्ञात मान पर सेट करें। हम नहीं करते
उपरोक्त सुरक्षा कारणों से उन सेटिंग्स को उत्पादन में उपयोग के लिए सलाह दें।

पर्ल है कभी नहीँ गारंटी कोई आदेश of la हैश Instagram पर , और ऑर्डर पहले ही दिया जा चुका है
पर्ल 5 के जीवनकाल के दौरान कई बार बदला गया। इसके अलावा, हैश कुंजियों का क्रम भी बदला गया
सम्मिलन आदेश और इतिहास से हमेशा प्रभावित रहा है और जारी रहेगा
अपने जीवनकाल में हैश में किए गए परिवर्तनों का।

यह भी ध्यान दें कि हैश तत्वों का क्रम यादृच्छिक हो सकता है, यह "छद्म-
ऑर्डर करना" चाहिए नहीं किसी सूची को बेतरतीब ढंग से फेरबदल करने जैसे अनुप्रयोगों के लिए उपयोग किया जा सकता है (उपयोग करें)।
"सूची::उपयोग::शफ़ल()" उसके लिए, सूची::उपयोग देखें, पर्ल के बाद से एक मानक कोर मॉड्यूल
5.8.0; या सीपीएएन मॉड्यूल "एल्गोरिदम::न्यूमेरिकल::शफल"), या उत्पन्न करने के लिए
क्रमपरिवर्तन (उदाहरण के लिए CPAN मॉड्यूल "एल्गोरिदम::परम्यूट" या का उपयोग करें
"एल्गोरिदम::फ़ास्टपरम्यूट"), या किसी क्रिप्टोग्राफ़िक अनुप्रयोगों के लिए।

बंधे हुए हैश के अपने स्वयं के ऑर्डरिंग और एल्गोरिथम जटिलता हमले हो सकते हैं।

· रेगुलर एक्सप्रेशन - पर्ल के रेगुलर एक्सप्रेशन इंजन को एनएफए (नॉन-) कहा जाता है
नियतात्मक परिमित ऑटोमेटन), जिसका अन्य बातों के अलावा यह अर्थ है कि यह बल्कि हो सकता है
यदि नियमित अभिव्यक्ति हो तो आसानी से समय और स्थान दोनों की बड़ी मात्रा का उपभोग कर सकते हैं
कई तरह से मेल खाते हैं. नियमित अभिव्यक्तियों को सावधानीपूर्वक तैयार करने से काफी मदद मिल सकती है
अक्सर ऐसा होता है कि कोई वास्तव में बहुत कुछ नहीं कर सकता (पुस्तक "मास्टरिंग रेगुलर एक्सप्रेशंस" है
आवश्यक पढ़ना, perlfaq2 देखें)। अंतरिक्ष की कमी पर्ल द्वारा प्रकट होती है
स्मृति ख़त्म हो रही है.

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

देखोhttp://www.cs.rice.edu/~scrosby/hash/> अधिक जानकारी और किसी भी कंप्यूटर विज्ञान के लिए
एल्गोरिथम जटिलता पर पाठ्यपुस्तक।

onworks.net सेवाओं का उपयोग करके ऑनलाइन पर्लसेक का उपयोग करें