एक ब्राउज़र गेम को हैक करने का इतिहास। नियंत्रण वापस करें

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

प्रस्तावना

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

प्रारंभिक निरीक्षण

खेल प्रशासन बलों मेजबान के साथ डेबियन चल रहा एक VPS पर आधारित है। उत्तरार्द्ध, सर्वर पर ही के अलावा, अधिक नियंत्रण कक्ष दिया गया था, phpMyAdmin।
आंतरिक सॉफ्टवेयर के विन्यास बहुत खुर के लिए अनुकूल। पीएचपी सेटिंग्स आप कनेक्ट करने के लिए और का उपयोग और बाहरी फ़ाइलें (allow_url_fopen / शामिल) है, जबकि खेल या तो एक या दूसरे के लिए आवश्यक नहीं है अनुमति देते हैं। सुरक्षित मोड (सेफ_मोड) बंद कर दिया गया, open_basedir सेट नहीं है। सिस्टम जैसे कार्य (), निष्पादन (), और अन्य जो सिस्टम कमांड के निष्पादन को सुनिश्चित करते हैं, को विकलांगता_फंक्शंस का उपयोग करके निषिद्ध नहीं किया गया है। त्रुटि उत्पादन सक्षम किया गया था, और उनके प्रवेश भी उल्लेख नहीं किया गया था।
वेब सर्वर (अपाचे) के रूप में, खेल से संबंधित कई उप-डोमेन इसके नियंत्रण में घूम रहे थे - एक मंच, एक परीक्षण स्थल, और बहुत कुछ। PHP के साथ वेब सर्वर FastCGI मोड में चल रहा था, लेकिन सुरक्षा के मामले में मुख्य ट्रम्प कार्ड - उनके मालिकों के अधिकारों के साथ स्क्रिप्ट चलाना - एक साधारण कारक द्वारा nullified था - वही उपयोगकर्ता सभी उप डोमेन की सामग्री का स्वामी था। इस बिंदु पर यह स्पष्ट हो गया है कि जोखिम जरूरी खेल का इंजन, वे परिधीय डोमेन पर हो सकता है हो सकता है की जरूरत नहीं है।
MySQL में, स्थिति समान था। उप डोमेन में से प्रत्येक के लिए यह अपने आप ही डेटाबेस था, और उनमें से काम स्क्रिप्ट एक ही उपयोगकर्ता के माध्यम से चला गया।
बाहर से सर्वर तक पहुँच SSH और FTP का उपयोग करके किया गया। और अगर मैं पहले के बारे में कुछ बुरा नहीं कह सकता, तो एफ़टीपी के साथ स्थिति पूरी तरह से अलग थी। एफ़टीपी पर एक बार, उपयोगकर्ता को तुरंत सभी उप डोमेन की सामग्री तक पहुंच प्राप्त हुई। इसके अलावा, एफ़टीपी रूट फ़ोल्डर में यहाँ डेटाबेस बैकअप के साथ देते हैं। वे उपयोगकर्ताओं के पासवर्ड को सब था। इसके तत्काल बाद वहाँ लॉग और अभिलेखागार एफ़टीपी के लिए गए थे। इस सब की माफी, जैसा कि कई लोगों ने शायद अनुमान लगाया है, यह था कि लॉगिन और पासवर्ड एसएसएच, एफटीपी और मायएसक्यूएल पर समान थे।
बाद करीब परीक्षा जारी एक और एक अच्छा समय नहीं है। खेल इंजन एक संस्करण नियंत्रण प्रणाली के उपयोग के बिना विकसित किया गया था। सब कुछ "लाइव" सही कर दिया गया था, और यदि फ़ाइल की एक बैकअप प्रतिलिपि बनाने के लिए आवश्यक था, तो उन्होंने इसे सीधे FTP_ जैसे script_name111111111.php पर कॉल किया, जिसके बाद उन्होंने ताजा script_name.php डाउनलोड किया। इंजन पर काम काफी लंबे समय के लिए किया गया था, और इस तरह के "रपट" फ़ाइलों के दर्जनों थे। उनकी उपस्थिति के साथ, वे बहुत एक वेब गोले और अन्य backdoors कि स्ट्राइकर लोड कर सकता है के लिए खोज को मुश्किल। एक स्रोत कोड विश्लेषण, उस में कमजोरियों की उपस्थिति निर्धारित करने के लिए, संभव नहीं हो गया। सामान्य तौर पर, यह स्थिति में सुधार करने जरूरी था।

नंबर एक की कोशिश

एक बाधा का उल्लेख करना आवश्यक है, अगर मैं ऐसा कह सकता हूं, जिसने हमारे लिए काम किया। समय तक डेवलपर्स मेरे लिए संबोधित किया है, खेल विकास लगभग गिर गया, खिलाड़ियों की संख्या को हटा दिया और हमलावर खुद को उस में बैठने के लिए ऊब गया था। वह दिन में एक बार आता था, लगभग एक घंटे सभी तरह के पत्राचार करता था और छोड़ देता था। उन्होंने तभी सक्रिय रूप से व्यवहार करना शुरू किया, जब डेवलपर्स ने कार्य करना शुरू किया - कुछ ऐड-ऑन शुरू किए, उनके खाते को अवरुद्ध किया, आदि, यह कहना सुरक्षित था कि जब तक हम ध्यान देने योग्य बनाने शुरू नहीं करते, उसके लिए, सर्वर सॉफ़्टवेयर में परिवर्तन और खेल, पटाखा ही स्थानांतरित करने के लिए शुरू होता है।
इसके आधार पर यह इतना कार्य करने के लिए किसी भी तरह से संरक्षण से संबंधित परिवर्तन, साकार करने के बाद हमलावर को प्रभावित है कि उन्हें नाकाम रही है जरूरी हो गया था। इसलिए, सबसे पहले, हमने इसके प्रभाव के क्षेत्र में अधिकतम कटौती की।
सबसे पहले, आईपी पते के माध्यम से सभी महत्वपूर्ण सेवाओं (वीपीएस, पीएमए, एसएसएच, एफ़टीपी, माईएसक्यूएल) के लिए बाहरी पहुंच को प्रतिबंधित करने का निर्णय लिया गया था। इसके बाद, प्रणाली उपयोगकर्ताओं प्रत्येक उप डोमेन के लिए बनाया गया है, और उनके सभी सामग्री इसी घर निर्देशिका करने के लिए ले जाया गया है। इसी तरह, हम डाटाबेस के साथ प्राप्त किया। अब हमलावर इस तरह के अन्य लोगों पर प्रभाव के रूप में, एक ही साइट का नियंत्रण रखने नहीं कर सका।
मैं लगभग भूल गया था। राइट्स 777, हम सब निर्देशिका है कि वे था निकाल दिया है। ब्लॉग पूरी तरह से एक दूसरे से अलग हो जाते हैं।
फिर हम PHP विन्यास ठीक कर दिया। समारोह OS कमांड, साथ ही यूआरएल और फ़ाइलों के पढ़ने के लिए कनेक्ट करने की क्षमता शुरू मना किया हो जाते हैं। त्रुटि आउटपुट बंद, एक साथ फ़ाइल (error_log) में अपने रिकॉर्ड को चालू करने से। दुर्भाग्य से, इंजन की विशेषताओं से संबंधित कारणों से सिर्फ सुरक्षित मोड (सेफ_मोड) पर बारी काम नहीं किया, या कम से कम सेट open_basedir पर। आगे इसलिए मैं उनकी मदद के बिना काम करने के लिए किया था।
अजीब तरह से, हमारे सभी कार्यों ने किसी भी तरह से हमलावर का ध्यान आकर्षित नहीं किया।
जाहिर है वह सर्वर पर लज़ान्या के अंत में ऊब गया और खेल के अलावा वह हस्ताक्षर नहीं होंगे। इससे कुछ और समय मिल गया। बस इस बिंदु पर डेवलपर्स बैकअप स्क्रिप्ट के सभी को हटा दिया है और वेब अनुप्रयोगों के विश्लेषण शुरू करने के लिए इस्तेमाल किया जा सकता।
इसके तत्काल बाद यह एक बहुत ही लोकप्रिय समस्या मिला था - पुस्तकालयों, विन्यास फाइल, आदि के बाहर पहुँच खोल दिया गया है साथ निर्देशिका की सामग्री .. बेशक, यह एक महत्वपूर्ण दोष नहीं है (समान कॉन्फ़िगरेशन फ़ाइलें php स्क्रिप्ट थीं और उन तक सीधे पहुंच ने कुछ भी नहीं दिया था), लेकिन अगर उनकी सामग्री बाहर से पहुंच योग्य है, तो वे दुर्भावनापूर्ण कोड स्टोर करने के लिए एक अच्छी जगह का प्रतिनिधित्व करते हैं। जब पहुँच इस तरह के एक फ़ोल्डर में बंद कर दिया है, स्थानों की संख्या "उपहार" के लिए खोज करने के लिए हमलावर से काफी कम है। खेल इंजन के मामले में, उपचार के बाहर की संभावना हम स्क्रिप्ट और अधिक जे एस-फ़ाइलें, शैली और छवियों के साथ साथ एक ही निर्देशिका में छोड़ दिया है। अतीत में बस स्क्रिप्ट के निष्पादन पर प्रतिबंध लगा दिया। इस प्रकार, केवल एक फ़ोल्डर था जहां PHP कोड का निष्पादन बाहरी उपयोगकर्ता के कारण हो सकता है। मूल रूप से, एक हमलावर कुछ आंतरिक लिपि में खतरनाक परिवर्तन करें, और उपयोग करने के लिए अपने कोड सार्वजनिक डोमेन लिपियों में पहले से ही है की कोशिश कर सकते। लेकिन हमने इस समस्या को हल किया, हालांकि तुरंत (उस नीचे अधिक) नहीं।
खेल का स्रोत कोड केवल अंधा SQL इंजेक्शन के साथ भर गया था। कई दर्जन के हमारे सहयोग के दौरान पाया गया है। उस व्यक्ति ने उन्हें समाप्त करने के लिए काम पर रखा है, जिसका मैंने पहले ही लेख की शुरुआत में उल्लेख किया था, trivially ने अनुरोध में आने वाले प्रत्येक चर के लिए mysql_real_escape_string () फ़ंक्शन के उपयोग को जिम्मेदार ठहराया। लेकिन किसी कारण से, उन्होंने इस तथ्य को ध्यान में नहीं रखा कि डेवलपर्स को इन चर में संख्यात्मक मूल्यों की उपस्थिति की उम्मीद थी, इसलिए एसक्यूएल प्रश्नों में उनके शामिल किए जाने के स्थानों को उद्धरण द्वारा तैयार नहीं किया गया था। इसलिए, mysql_real_escape_string () का उपयोग करने से बचने के बावजूद, इंजेक्शन का उपयोग किया जा सकता है, मुख्य बात यह है कि विशेष को खतरनाक प्रश्नों में शामिल नहीं करना है। अक्षर।
दिलचस्प बात है, उस समय किसी भी डोमेन विभिन्न दुर्भावनापूर्ण स्क्रिप्ट नहीं पाए गए है, हालांकि हम कम से कम एक में पड़ सकती है। बाद में, यह पता लगाना संभव था कि सभी हैकर ने पीएमए के माध्यम से अपने कार्यों को अंजाम दिया।
अंतिम स्पर्श के रूप में, हमने PHP को सभी आवक अनुरोधों (क्रमबद्ध GET / POST / SERVER / COOKIE / SESSION सरणियों की रिकॉर्डिंग) के बारे में जानकारी का एक लकड़हारा कनेक्ट करने का फैसला किया, जो auto_prepend_file विकल्प का उपयोग करते हुए, और हमलावर को एक और प्रतिबंध के साथ उत्तेजित करता है। लकड़हारे को तुरंत समस्या हुई। हालांकि उस समय औसत ऑनलाइन महान नहीं था, खिलाड़ियों अनुरोध ताकि लकड़हारा कई गुना की हार्ड डिस्क स्थान खा लिया बना दिया। एक समाधान दर्ज आंकड़ों gzip`om के संपीड़न का उपयोग करने की कोशिश की है। इससे मदद मिली। खाते में रिजर्व में 1GB + अपनी हार्ड ड्राइव पर मुक्त अंतरिक्ष लेते हुए लकड़हारा 17 घंटे के बारे में काम कर सकते हैं। इस संबंध में, प्रत्येक घंटे के लिए अलग से एक लॉग लिखने का निर्णय लिया गया, और दिन के मध्य में सभी उपलब्ध लॉग फ़ाइलों को स्थानीय कंप्यूटर में मर्ज कर दिया, साथ ही साथ उनके मूल को मिटा दिया। के बाद से प्रतिबंध के बाद हमलावर 24 घंटे की एक अधिकतम संचालित करने के लिए शुरू कर दिया है (यह खेल हर दिन प्रदर्शित हुए थे), तो यह लॉग पंप करने के लिए केवल 2-3 बार आवश्यक हो जाता। और इसलिए यह हुआ।

नंबर दो का प्रयास

नियत समय पर, हमने लकड़हारे को चालू किया, जाँच की कि क्या डेटा सामान्य रूप से रिकॉर्ड किया जा रहा है, सभी पुराने पासवर्ड बदल दिए गए और हमलावर पर प्रतिबंध लगा दिया। इंतजार करने का समय है। लगभग 12 घंटे बाद, वह एक प्रभाव पड़ा है। हमारे आश्चर्य करने के लिए हमलावर फिर से अपने प्रतिबंध हटा दिया और खेलना जारी रखा।
इसके ठीक बाद, हमने यह समझने के लिए कि हमने क्या मिस किया, सभी उपायों की चर्चा शुरू की। और उन्होंने जल्दी से एक गलती खोज निकाली। वह सरल और साधारण था - सभी प्रबंधित सेवाओं पर पासवर्ड बदल दिया है, लेकिन व्यवस्थापक पैनल के बारे में भूल गया था। वहां पासवर्ड पुराने ही रहे।
तब मैं एक बार फिर से खेल के स्रोत कोड की ओर ध्यान आकर्षित करने का निर्णय लिया। आपको कभी नहीं पता कि हाल ही में उकसाने के बाद एक हमलावर द्वारा वहां क्या डाउनलोड किया जा सकता था। मैं हार्ड ड्राइव पर अभी पिछले काम कर संस्करण था। मैं एक प्रति स्थानीय स्तर पर तुलना करने के लिए एफ़टीपी इंजन से डाउनलोड करने शुरू कर दिया। एक भी फ़ाइल नहीं बदली गई थी, लेकिन एक नई स्क्रिप्ट दिखाई दी (लकड़हारा रिकॉर्ड का विश्लेषण, जिसे बाद में किया गया था, इस तक पहुंच दिखाई गई)। यह एक वेब शेल था। इसके निर्माण की तिथि, मैं तुरंत एहसास हुआ कि क्या हो रहा था। स्रोत कोड की जाँच करते हुए, मैं फ़ोल्डर द्वारा फ़ोल्डर के माध्यम से चला गया, डेवलपर्स को कमजोरियों को सौंपने और संदिग्ध लिपियों की तलाश में। जब कुल मात्रा का लगभग आधा अध्ययन किया गया था, तो हमलावर ने वेब शेल को एक निर्देशिका में अपलोड किया था, जिसकी सामग्री मैंने बहुत शुरुआत में जाँची थी। तदनुसार, इस में से कोई भी तुरंत नहीं मिला है। एक स्ट्राइकर इसका इस्तेमाल करने के प्रतिबंध को हटाने के लिए सक्षम था। तो यह पहले से ही स्पष्ट है कि हम किसी भी तरह फ़ाइल संरचना अखंडता नियंत्रण के इंजन के साथ समस्या को हल करने के लिए है कि था। चूंकि संस्करण नियंत्रण प्रणाली अभी तक उपयोग नहीं की जाने लगी थी (इसे बाद में पेश किया गया था), मुझे हर 10 मिनट में ताज द्वारा चलाई जाने वाली बैश स्क्रिप्ट के साथ बाहर निकलना था, और नई / हटाई गई फ़ाइलों की जांच करनी थी, और मूल रकम के साथ स्क्रिप्ट की जांच भी करनी थी। मैंने अपने एक लेख में इसके प्रोटोटाइप का वर्णन किया है - anton-kuzmin.blogspot.com/2011/01/blog-post.html ।
अब जब कि खोल हटा दिया गया है, (इस समय) फिर से पासवर्ड बदल गया है, और पार्टी-स्क्रिप्ट चल रही है, समय एक और प्रतिबंध लगाने के लिए आ गया है।

निष्कर्ष

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

पुनश्च

इस लेख के अंत में मैं डेवलपर्स और वेब अनुप्रयोगों के प्रशासकों के लिए कुछ महत्वपूर्ण नियम को उजागर करना चाहते हैं। कुछ के लिए, वे सामान्य प्रतीत होंगे, लेकिन मुझे यकीन है कि कुछ काम आ सकते हैं।
1) अधिकतम सीमा पीएचपी के अनुसार। निषेध कार्यों सुरक्षित मोड, निकालें मॉड्यूल आप का उपयोग नहीं करते सहित प्रदर्शन ओएस आदेश। त्रुटि दुभाषिया लॉग इन, उत्पादन सर्वरों के लिए अपने उत्पादन में डिस्कनेक्ट कर दें।
2) बैकअप बनाते समय, उनमें से कोई भी संवेदनशील जानकारी, जैसे उपयोगकर्ता पासवर्ड, गुप्त प्रश्नों के उत्तर, डेटाबेस से जुड़ने का विवरण आदि को हटा दें।
3) जब हैशिंग डेटा हो, तो सिंगल कॉल जैसे md5 () या sha1 () के लिए गैर-साधारण स्कीमों का उपयोग करें। इस्तेमाल किया और निर्णय लोकप्रिय वेब इंजन से लिया नहीं होना चाहिए। व्यवस्थित करें अपने प्रतिलिपि कार्यक्रमों की सबसे हो सकता है हैश के साथ काम कर शामिल किया गया। आप () एक पंक्ति में एक अद्वितीय योजना का उपयोग करते हैं, भले ही वह 7 md5 फोन करेगा, हमलावर सबसे अधिक संभावना समझने के लिए कुछ भी करने में सक्षम नहीं होगा। सब के बाद, आप योजना का उपयोग कर रहे हैं, यदि कोई हो जाने-माने कार्यक्रम में नहीं है, वह या तो पैसे के लिए उसे बुक करने के लिए अपने घटना के लिए विशेष रूप से एक अलग इकाई लिखने के लिए है या होगा। विचार करें कि साइबर अपराधियों की कुल संख्या का कितने प्रतिशत ऐसा करेगा? जटिल पासवर्ड के बारे में मत भूलना।
4) आवेदन प्रशासनिक और साधारण खातों के बीच एक कठोर विभाजन का उपयोग करता है। यही कारण है कि इतने ही खेल में, व्यवस्थापक व्यवस्थापक पैनल के विवरण का उपयोग करके प्रवेश करने में सक्षम नहीं है, और इसके विपरीत है।
5) आप आवेदन कोड में सीधे कोई भी पासवर्ड का फैसला करते हैं, अपने स्वयं के नहीं रखने के लिए, और उनके हैश।
6) पासवर्ड विशेषाधिकार प्राप्त उपयोगकर्ता अपने आवेदन करने के लिए अद्वितीय होना चाहिए। नहीं बहुत अच्छा परिणाम एक स्थिति है जहाँ, उदाहरण के लिए, मुख्य आवेदन में प्रवेश करने के मॉडरेटर पासवर्ड है और मंच से एक ही का उपयोग करने की वर्तनी सकता है।
7) काम करने के लिए उपयोग जैसे नाशपाती :: MDB2 पुस्तकालय तैयार के रूप में डेटाबेस के साथ। वे सुविधा अनुरोध में गिरने स्क्रीनिंग डेटा स्वचालित रूप से समस्याओं का एक बहुत कुछ को रोकने के लिए शुरू हो जाती है। इसी तरह, यह चौखटे के साथ है। यदि आपको पहले से ही SQL क्वेरी में सीधे कोड में डेटा डालना है (उदाहरण के लिए, mysql_query () का उपयोग करें), तो क्वेरी के साथ रखे गए प्रत्येक मूल्य को उद्धरण के साथ उद्धृत करें और mysql_real_escape_bring () के बारे में मत भूलना।
8) एक वेब अनुप्रयोग निर्देशिका पर से बचें जारी करने के अधिकार 777। यह सब हालांकि स्थिति पर निर्भर करता है। कभी-कभी इसके बिना किसी भी तरह से।
9) निर्देशिकाओं में लिपियों के निष्पादन को प्रतिबंधित करें जो बाहर से सुलभ हैं और स्वयं के अंदर कोई स्क्रिप्ट नहीं है। यह जे एस-फ़ाइलें, सीएसएस शैलियों, फोंट, चित्रों के साथ एक फ़ोल्डर हो सकता है, और इतने पर। डी और निर्देशिका (और उनकी सामग्री) है कि उपयोगकर्ताओं को पहुँच नहीं, आम तौर पर करीब पहुँच चाहिए करने के लिए। यदि संभव हो, यह वेब निर्देशिका परे सहना बेहतर है।
10) एक सामान्य कॉन्फ़िगरेशन फ़ाइल (httpd.conf) में वेब सर्वर से जुड़े सभी प्रतिबंधों और सेटिंग्स को संग्रहीत करना बहुत ही उचित है, और "ऑन-साइट" सेटिंग्स (.htaccess साधनों का उपयोग करके) को अक्षम करें। यह कॉन्फ़िगरेशन का केंद्रीकृत भंडारण प्रदान करेगा, और उस व्यक्ति को भी अनुमति नहीं देगा, जिसके पास अपनी विशिष्ट निर्देशिकाओं के संबंध में कुछ भी बदलने के लिए साइट तक पहुंच है। यदि यह संभव नहीं है, और आप, उदाहरण के लिए, .htaccess का उपयोग करें, तो इसे ऐसे अधिकारों और स्वामी के साथ सेट करने का प्रयास करें, ताकि वेब सर्वर की ओर से वहां परिवर्तन करना असंभव हो।
11) महत्वपूर्ण सेवाओं तक पहुंच और आईपी पतों पर नियंत्रण कक्ष को प्रतिबंधित करने के।
12) एक संस्करण नियंत्रण प्रणाली का उपयोग करें।
13) डोमेन और डेटाबेस रखें, आवेदन उन्हें कर रहे हैं, ताकि वे एक दूसरे पर कोई असर नहीं पड़ा। एक हमलावर के लिए, एक ही साइट खुर दूसरे पर के माध्यम से नहीं मिल सका।
14) विरोधी हैकर स्क्रिप्ट और समान मॉड्यूल के सभी प्रकार डाल मत करो, पहले उन्हें अच्छी तरह से परीक्षण किया। विशेष रूप से अच्छी तरह से उनका अध्ययन करें यदि आप 2-3 ऐसी स्क्रिप्ट एक साथ रखने जा रहे हैं। अक्सर, बड़ी समस्याओं को यह सुराग।
15) यदि किसी परावर्तित हमले के बाद अचानक कोई हमलावर आपसे संपर्क करता है और आपको विश्वास दिलाना शुरू कर देता है कि आपकी हरकतें बेकार हैं, तो जो कुछ भी आप बताते हैं, उसे ध्यान से देखें। शायद वह सिर्फ झांसा दे रहा है।
16) किसी भी घटना की स्थिति में, अगर पता लगाया भेद्यता संभव नहीं है, सभी डेटा अनुरोधों वेब सर्वर लॉग के सभी उपयोगकर्ताओं के लॉग ऑन करने का प्रयास करें। यह samopisnyh स्क्रिप्ट और व्यक्तिगत मॉड्यूल वेब सर्वर द्वारा दोनों किया जा सकता है।

और दो अलग-अलग नियमों ऑनलाइन गेम में नियंत्रण उन है, जो करने के लिए मैं इस मामले पर काम कर रहा करने की प्रक्रिया में आ गए हैं करने के लिए संबंधित:
1) स्वचालित खेलने पैसे की संख्या की गणना (प्राप्त खर्च) और अनुभव उन्हें दैनिक आँकड़ों ले जाते हैं। एक दिन में एक बार इन आंकड़ों को इकट्ठा करने और पिछले दिन के साथ तुलना करने के लिए। आप तो खेल के सामान्य कोर्स में 24 घंटे की कुल वृद्धि का औसत प्रतिशत निर्धारित करने के लिए एक सप्ताह की है। जैसे ही एक बेईमान खिलाड़ी दिखाई देता है, जो, उदाहरण के लिए, अपने आप को बड़ी मात्रा में खेल मुद्रा चार्ज करने में कामयाब रहा है, आपको तुरंत इसके बारे में पता चल जाएगा।
2) सभी आपरेशनों खेल चीजों के साथ प्रवेश किया है। जब राक्षस को मारने बात बनाया गया था, बात पारित कर दिया, बात बेचा - रिकॉर्ड सब कुछ करने के लिए। पिछले बिंदु के समान, आप एक निश्चित समय अंतराल के साथ जब तक एक खिलाड़ी कोई इतिहास है आधार चीजों से चयन करने के लिए कर सकते हैं। है, वहाँ लगभग कहीं से थे। संयोग से, एक ही तंत्र चोरी वस्तुओं के मालिकों वापस जाने के लिए मदद मिलेगी, और जल्दी से धोखेबाज को पकड़ने।

मुझे उम्मीद है कि इस लेख को पढ़ने के दौरान आपने कुछ नया सीखा और यह आपके लिए उपयोगी था। मुझे आपके प्रश्नों के किसी भी जवाब देने के लिए खुशी होगी।