🐕 🍰 💪 सुरक्षित वेब संसाधन की ओर। भाग 2

मुझे सुरक्षित वेब संसाधन और वेब एप्लिकेशन बनाने और पहले भाग से स्थानांतरित होने के दृष्टिकोण पर अपने विचार बताना जारी रखने की कृपा है, जिसमें परियोजना के लिए बुनियादी ढाँचा बनाने के लिए कुछ आम तौर पर उपयोगी सुरक्षा निर्देश हैं, और दूसरा, एप्लिकेशन को स्वयं विकसित करना।

सुरक्षा छेद को ठीक नहीं किया गया है, क्योंकि उत्पाद प्रबंधक एक नई सुविधा चाहते हैं

प्रोग्रामर

उनके साथ, उनके ज्ञान और अनुभव के साथ शुरू करना तर्कसंगत है। कर्मचारी का दोष यह है कि उसके पास सुरक्षा विकास के बारे में पर्याप्त ज्ञान नहीं है। प्राथमिक जिम्मेदारी नेतृत्व, मानव संसाधन और किसी और पर है। भर्ती चरण के दौरान समस्या उत्पन्न होती है। आइए एक विशिष्ट साक्षात्कार पर विचार करें, यहां तक कि उन मार्गदर्शकों के आधार पर जो कि हेबे पर यहां रखी गई थीं:

PHP डेवलपर साक्षात्कार - रैंक 54
"पीएचपी विशेषज्ञ" की घोषित स्थिति और तर्क पर सवाल - रेटिंग 46 के साथ उम्मीदवार , एक साक्षात्कार योजना भी है
साक्षात्कार। आज - रेटिंग 68
एकदम सही जॉब इंटरव्यू? - रेटिंग 71, "सही" साक्षात्कार की चर्चा

कहीं भी किसी ने भी (टिप्पणियों में अंतिम लेख सहित) कभी भी सुरक्षा पहलुओं का उल्लेख नहीं किया है। "मछली सिर से घूमती है" और यह एक तथ्य है। मैं क्या सुझाव दूं? कर्मचारियों की भर्ती करते समय, सबसे पहले, अपने आप को यह पता लगाने के लिए कि प्रोग्रामिंग के मूल क्षणों में, झुकाव। सुरक्षा परिप्रेक्ष्य और उनके बारे में सवाल पूछना। और मैं निम्नलिखित प्रश्नों का प्रस्ताव करता हूं, जिनके उत्तर (और सबसे महत्वपूर्ण रूप से - स्पष्टीकरण का विस्तार) सुरक्षा के क्षेत्र में डेवलपर के ज्ञान की कम से कम कुछ तस्वीर देंगे। हम उनमें कुछ विशिष्ट निर्माणों और कमजोरियों का चयन करेंगे:

XSS

<?php $name = $_GET['name']; echo "Hello, <b>$name</b>!"; ?>

हम राय मांगते हैं। इससे कोई फर्क नहीं पड़ता है कि यदि समर्थक यह जानता है कि यह संग्रहीत है या DOM XSS। मुख्य बात यह है कि वह समझता है कि इस तरह के निर्माण अस्वीकार्य हैं (और यह शांत होगा यदि वह ऐसे निर्माणों के परिणामों को जानता है। और यहां तक कि कूलर भी समाधान है)। जेएस के माध्यम से डेटा के प्रतिस्थापन के साथ कार्य को जटिल किया जा सकता है।

SQLi

 <?php $value = "id = ".$_GET['id']; $select->where($value); ?>

यह मेरे पिछले लेखों में से एक का संदर्भ है (समस्या का समाधान नहीं किया गया था, लेकिन अभ्यास से लिया गया था)। और इसलिए, हम Zend में एक विशेषज्ञ की तलाश कर रहे हैं, वह अचानक सभी सवालों के जवाब देता है, लेकिन ... इस तरह के डिजाइनों के लिए यह बिल्कुल सामान्य है। या जहाँ GST / POST से आया सरणी निहित है, वहां प्रतिस्थापित करता है।

फ़ाइल अपलोड करें

 <?php if ($_FILES["file"]["type"] == "image/gif") || $_FILES["file"]["type"] == "image/jpeg" || $_FILES["file"]["type"] == "image/png") { // Uploaded file is image, all ok move_uploaded_file ... } ?>

छवि डाउनलोड करें। कम से कम कुछ अनुभव वाले लोग तुरंत कहेंगे कि कोई भी इस तरह से नहीं लिखता है। $ _FILES ["फ़ाइल"] ["प्रकार"] को HTTP से एक मान दिया गया है, जो आसानी से "नकली" है। ठीक है, ठीक है, उम्मीदवार का कहना है कि हम बस "फ़ाइल - आईबी" में बदल जाते हैं या इसके लिए PEAR / Zend का उपयोग करते हैं और अंत के साथ सौदा करते हैं (एक ही समय में, यह स्टैकओवरफ़्लो को संदर्भित करता है)। लेकिन यहां वह गलत होगा (लेकिन पहले से बेहतर)। छवि हेडर होने पर, php कोड वाली एक बुराई .php फ़ाइल बनाना काफी आसान है। तो यहां आपको पहले से ही स्वीकार की गई फ़ाइल (उदाहरण के लिए, फ़ाइल, PEAR या Zend के माध्यम से) के हेडर की जांच करने की आवश्यकता है, और माइम-प्रकार परिभाषित के आधार पर एक्सटेंशन सेट करें।

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

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

और इसलिए, हम मानव कारक से तकनीकी एक की ओर बढ़ रहे हैं।

अनुक्रम

मैं निर्देशिका संरचना के साथ शुरू करूँगा। यह कई लोगों द्वारा प्रचलित है:

 example.com ├── app │  ├── config.ini │  ├── framework │  └── src │  ├── controller │  ├── model │  └── view ├── crontab │  ├── daily_flush_stat.php │  └── weekly_remove_cache.sh └── htdocs ├── css ├── img ├── index.php └── js

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

ऐप - एप्लिकेशन, जिसे htdocs के रूप में प्रस्तुत किया गया है, यह मॉड्यूल फ़ाइलों में ऐसे निर्माणों को अनावश्यक रूप से समाप्त करता है:

 if (!defined('IN_SITE')) die ("Hack attempt!");

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

config.ini भी वेब से सुलभ नहीं है, इसलिए, इसे सीधे पहुंच के द्वारा सादे-पाठ में नहीं दिया जाएगा।

क्रोन लिपियों (या जेनकींस के लिए स्क्रिप्ट) को भी आसानी से उस निर्देशिका में संग्रहीत किया जाता है जिसकी हमें आवश्यकता है।

आवेदन कोड

हम डिजाइन पैटर्न - एमवीसी का उपयोग करने के लिए सबसे लोकप्रिय योजना का विश्लेषण करेंगे और तय करेंगे कि हमारे पास कहां है और क्या होगा।

आदर्श

मान्यकरण। बहुत कुछ इस बात पर निर्भर करता है कि आपकी टीम में क्या स्वीकार किया जाता है। आमतौर पर, फिर भी, मॉडल सत्यापन शुरू होने पर डेटा सत्यापन यहां लिया जाता है। लेकिन यह कहीं और सफलतापूर्वक किया जा सकता है (उदाहरण के रूप में सेवा)।

राय

यहां मैं शाश्वत प्रश्न पर विचार करूंगा - HTML विशेष वर्णों को कहां बदलना है? उदाहरण के लिए, phpbb डेटाबेस में डेटा लिखते समय ऐसा करता है, और परिणामस्वरूप, डेटा एक बड़ा स्थान लेता है। संदेश

 WOW >>> "NEW NEW NEW"

यह 42 बाइट्स (UTF8 में) नहीं लेगा, लेकिन 82, जैसा कि यह दिखेगा

 WOW &gt;&gt;&gt; &quot;NEW NEW NEW&quot;

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

नियंत्रक

मुख्य भेद्यताएं अक्सर डेटा हेरफेर वाले स्थानों में पाई जाती हैं। यहां मैं अपने पहले लेखों में जो कुछ भी लिखा था, उसके बारे में दोहराना चाहता हूं, और निम्नलिखित निर्माण का उपयोग करने का सुझाव देता हूं:

 try { // try something } catch (Exception $e) { echo ",   .         !" errorLog($e->getMessage()); }

जहां ErrorLog () - डेटाबेस में एक त्रुटि रिकॉर्ड जोड़ देगा, वह dev@example.com या कुछ और को एक ईमेल भेजें। परियोजना पर होने वाली सभी समस्याओं से आप हमेशा अवगत रहेंगे। इसके अलावा, यदि हम न्यू रेलिक का उपयोग करते हैं (जिसका उल्लेख लेख के पहले भाग में किया गया था), तो हमें एक समान सुंदर निगरानी मिलती है:

एक त्रुटि लॉगिंग के उदाहरण के साथ स्क्रीन जब किसी ने phpmyadmin पते को लेने की कोशिश की, उदाहरण के लिए, निकटो का उपयोग करके

समय, लॉग, और इस त्रुटि की घटना की मात्रा। आधुनिक संस्करण में error.log।

पुनरावृत्तियों

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

फ्रेमवर्क, सीएमएस / सीएमएफ

फ्रेमवर्क पर उत्पाद विकास सुरक्षा के लिए रामबाण नहीं है (RoR ने विशेष रूप से वर्ष की शुरुआत से ही इसकी पुष्टि की है)। सबसे लोकप्रिय इंजनों का उपयोग करना और मॉड्यूल विकसित करते समय उनके एपीआई का पूर्ण उपयोग करना भी एक रामबाण नहीं है ( वर्डप्रेस => 3.5 XMLRPC पिंगबैक अतिरिक्त मुद्दे )।

निष्कर्ष?

मेरी राय एक ही है, कि पहले से ही सुरक्षा में अनुभव होने पर, (और हैकिंग / पेन्टेस्ट में बेहतर है) स्क्रैच से सभी कोड लिखना बेहतर है। लेकिन, निश्चित रूप से, यह आधुनिक दुनिया में व्यावहारिक रूप से अनुचित है, क्योंकि इसमें व्यवसाय के लिए बहुत अधिक अतिरिक्त लागतों की आवश्यकता होती है (और एक ही बार में इतने सारे विशेषज्ञों को ढूंढना काफी कठिन है)।
वैसे, मेरे पास इस विषय पर एक उत्कृष्ट कार्यक्रम है (जो मैंने सूचना संरक्षण से एलेक्सी बेबेंको से सीखा है, जो बदले में, सुरक्षा पर विदेशी इंटर्नशिप में से एक में उसके बारे में पता चला)

न्यूनतम लागत पर इष्टतम सुरक्षा। चित्र यहाँ पाया गया

जिससे हम यह निष्कर्ष निकाल सकते हैं कि प्रारंभिक निवेश सुरक्षा में एक त्वरित और तेज उछाल देते हैं। लेकिन जितना बड़ा निवेश होगा, जोखिम उतना ही कम होगा।

श्रृंखला:
सुरक्षित वेब संसाधन की ओर। भाग 1 - सर्वर सॉफ्टवेयर
सुरक्षित वेब संसाधन की ओर। भाग 2 - विकास
सुरक्षित (वेब) संसाधन बनाने के रास्ते पर। भाग 3 - कार्यालय, कर्मचारी

सुरक्षित वेब संसाधन की ओर। भाग 2 - विकास