हम ताकत के लिए PHP इंजन की जांच करते हैं

सभी को नमस्कार, मुझे हाल ही में अपनी आवश्यकताओं के लिए एक PHP इंजन लिखने का विचार मिला, इसलिए बोलने के लिए, स्तर बढ़ाने और कुछ उपयोगी पाने के लिए। लगभग तुरंत, मैंने सोचा कि यह दरार करना कितना आसान होगा। यह कोई रहस्य नहीं है कि आप कुछ भी हैक कर सकते हैं, लेकिन सवाल यह है कि यह कितना समस्याग्रस्त होगा और क्या हर हैकर ऐसा करने में सक्षम होगा?

आकार

किसी भी परियोजना में शायद सबसे आम भेद्यता है, यह एक टिप्पणी के रूप में, या एक लॉगिन रूप हो। अच्छी जाँच के बिना, यह बात बेकार है।
एक सामान्य गलती यह है कि आपको जो कुछ भी मिला है उसे बचाना है:

foreach( $_POST as $item ){} 

डिबगर के माध्यम से कोई भी अपनी बात जोड़ सकता है, भले ही यह एक बड़ी हैक न दे, लेकिन बात बेहद अप्रिय है।

फ़ाइल सबमिशन फ़ॉर्म

मैं इस निष्कर्ष पर पहुंचा:

आप अपने इंजन की सुरक्षा तभी कर सकते हैं, जब आपके पास फ़ाइलों को अपलोड करने के लिए एक ही रूप नहीं है, या यदि वे मौजूद हैं और उनका अच्छी तरह से परीक्षण किया गया है

मैं पहले पर विचार करता हूं, यह सबसे विश्वसनीय है, लेकिन अगर उनके बिना कहीं नहीं है, तो कई सिफारिशें हैं।

• एक एकल जाँच कभी पर्याप्त नहीं होती है!
• सभी सामग्री के बारे में जानें।

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

1. उपयोगकर्ता JS अक्षम हो सकता है
2. उपयोगकर्ता जेएस को डिबगर में बदल सकता है

फाइलों की जांच, आकार, प्रकार पर अधिक ध्यान दें, यदि यह एक तस्वीर है, तो चौड़ाई, ऊंचाई। अक्सर, जब कोई चित्र प्रदर्शित करते हैं, तो वे केवल एक तरफ, चौड़ाई या ऊंचाई में जांच करते हैं, और अब कल्पना करते हैं कि किसी बुद्धिमान व्यक्ति ने 20000x50px या इसके विपरीत के साथ चित्र को बाढ़ दिया, दृष्टि सुखद नहीं होगी।

पासवर्ड भंडारण

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

एसक्यूएल इंजेक्शन (एसक्यूएल इंजेक्शन)

टैंक में रहने वालों के लिए, यह एक साधारण उपयोगकर्ता का SQL कोड है, एड्रेस बार के माध्यम से या उसी फॉर्म के माध्यम से।
एक नियम है:

" कभी भरोसा न करें कि उपयोगकर्ता ने आपको क्या भेजा है "

यदि आप उसे लगातार याद करते हैं, तो आप भविष्य में खुद को कई समस्याओं से बचा सकते हैं।

जाँचें कि उपयोगकर्ता ने आपको क्या भेजा है, यदि पासवर्ड फ़ील्ड में वह "lol 'या (1 = 1) #" इंगित करता है, तो यह आपको किसी भी तरह से प्रभावित नहीं करेगा।
इससे छुटकारा पाने का सबसे आसान तरीका mysql_real_escape_string का उपयोग करना है, यह फ़ंक्शन SQL में सभी विशेष वर्णों से बच जाता है, और स्ट्राइकस्लैश फ़ंक्शन का उपयोग करके सभी स्लैश को भी हटाता है।

व्यवस्थापक

कई साइटों पर, व्यवस्थापक पैनल पर जाने के लिए, बस पता दर्ज करें / [admin | admin.php | एडमिनिस्ट्रेटर | और इसी तरह]। कई विकल्प नहीं हैं, इसलिए आप सही खोज सकते हैं, लेकिन अगर आप जेनरेट किए गए प्रतीकों के साथ व्यवस्थापक पैनल का उपयोग करते हैं, तो आपको चिंता करने की ज़रूरत नहीं है (उदाहरण: 7NVmE10SaJ.php), यह कुछ के लिए असंगत लग सकता है, लेकिन मुझे लगता है कि बहुत अधिक सुरक्षा नहीं है। यदि कोई उपयोगकर्ता व्यवस्थापक के उपयोगकर्ता नाम और पासवर्ड के लिए लॉगिन पृष्ठ पर लैंड करता है, तो यह साइट के बैक-एंड भाग के सभी रहस्यों को प्रकट करने के लिए उसे एक कदम करीब लाता है।

पासवर्ड

किसी भी खाते के नुकसान से बचने के लिए, उपयोगकर्ताओं को पासवर्ड स्वयं बनाने न दें, लेकिन यदि आप देते हैं, तो इसे पासवर्ड को यथासंभव कठिन बनाने के लिए बाध्य करने का प्रयास करें। हाल के समय से, मैंने md5 पासवर्ड ($ secret_key। $ Password। $ Salt) बनाने के लिए इस बंडल का उपयोग करना शुरू किया;
मेरी राय में, यह एक अच्छा बचाव है। Md5 हैश गुप्त कुंजी से बनाया गया है जो उपयोगकर्ता पासवर्ड और नमक से इंजन कॉन्फिगर (कोड में कहीं स्थित) में सीवन किया जाता है, जो डेटाबेस में संग्रहीत होता है, उपयोगकर्ता पासवर्ड के md5 हैश के बगल में, और प्रत्येक उपयोगकर्ता का अपना नमक होता है। यह हमें क्या देता है? यदि कोई हमसे कोई गुप्त कुंजी के बिना डेटाबेस चुराता है, तो उसे एक पासवर्ड प्राप्त नहीं होता है, भले ही वह डेटाबेस और इंजन दोनों प्राप्त करता है, तो वह भी पासवर्ड के बिना बेकार हो जाएगा, केवल टेराबाइट इंद्रधनुष तालिकाओं का उपयोग करें।

phpmyadmin

यहां सब कुछ व्यवस्थापक पैनल के समान है, आप केवल पते / [phpmyadmin | myadmin | pma | और इतने पर] दर्ज करके phpmyadmin में आने का अवसर नहीं दे सकते। खैर, निश्चित रूप से, रूट का उपयोग करना। 123 लॉगिन भी निषिद्ध है।

अधिवेशन

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

कुकीज़ (कुकी)

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

आर्किटेक्चर

आपको अपनी परियोजना की वास्तुकला पर सही ढंग से सोचने की ज़रूरत है, यदि आप पूरी परियोजना को बैसाखी, और साइकिल के साथ बनाते हैं, तो इससे कुछ भी अच्छा नहीं होगा, केवल छेद। MVC का उपयोग करने का प्रयास करें, यह आपके कोड को तार्किक घटकों में अंतर करने में मदद करेगा।

ऑपरेटिंग सिस्टम

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

आप अभी भी ट्रैफ़िक विश्लेषण के बारे में लिख सकते हैं, लेकिन मैंने ऐसा नहीं किया, इसलिए मुझे नहीं पता कि इसके लिए विशेषज्ञ हैं।

निष्कर्ष

पूर्वगामी से, निम्नलिखित निष्कर्ष निकाले जा सकते हैं:

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

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

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