क्या संशोधित डेटा सहेजते समय केकपीएचपी स्वचालित रूप से बड़े पैमाने पर असाइनमेंट भेद्यता से निपटता है?

संपादित करें:क्या संशोधित डेटा सहेजते समय केकपीएचपी स्वचालित रूप से बड़े पैमाने पर असाइनमेंट भेद्यता से निपटता है?

DCoder से अधिक जानकारी प्राप्त करने के बाद, वाक्यांश मैं यहाँ के लिए खोज रहा था एक "बड़े पैमाने पर काम जोखिम है।" इसका मतलब यह है कि, उन सभी तरीकों की सुविधा का लाभ उठाना जो सभी मान्य फ़ील्ड को डेटाबेस में सहेजते हैं, भले ही प्रारंभिक रूप में उनकी उपस्थिति न हो (उन्हें उन लोगों के मुकाबले अधिक संभवतः अधिक संभावित [संभवतः अधिक महत्वपूर्ण] फ़ील्ड वाले पीओएसटी डेटा में छेड़छाड़ करने के लिए कमजोर बना दिया जाता है।)।

दो सामान्य प्रतिक्रियाओं को उचित रूप से श्वेतसूची और ब्लैकलिस्टिंग नाम दिया जाता है; संशोधित करने के लिए लक्षित श्वेतसूची वाले फ़ील्ड, या उन क्षेत्रों को ब्लैकलिस्ट करना जिन्हें संशोधित नहीं किया जाना चाहिए।

मेरा प्रश्न तब निम्नानुसार है: क्या केकपीएचपी स्वचालित रूप से सबमिट करने वाले फॉर्म में केवल उन फ़ील्ड को श्वेतसूची में लाता है, या यह मेरे लिए आवश्यक है (और अन्य केक प्रशंसकों) यह सावधान रहना चाहिए कि हम श्वेतसूची या उचित रूप से ब्लैकलिस्ट कर रहे हैं?

मूल प्रश्न:

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

मान लें कि मैं अपने उपयोगकर्ताओं को उनके संपादन को अनुमति देता हूं प्रोफ़ाइल। मैं एक फॉर्म बनाता हूं जिसमें उपयोगकर्ता नाम, ई-मेल और पासवर्ड के लिए क्षेत्र edit के तहत फ़ील्ड हैं।

एक चतुर उपयोगकर्ता में आते हैं और false से true करने के लिए अपने is_admin क्षेत्र बदलना चाहता है, तो वे edit कार्रवाई है, जो true के क्षेत्र is_admin सेट शामिल करने के लिए कस्टम पोस्ट डेटा सबमिट करने फ़ायरबग जैसे ऐप्लिकेशन का उपयोग करें।

सवाल यह है कि क्या केक अपने स्वयं के is_admin मूल रूप में नहीं था, या क्या मुझे केवल उन फ़ील्ड को स्पष्ट रूप से निर्दिष्ट करने के लिए सावधान रहने की आवश्यकता है जो किसी दिए गए क्रिया को संशोधित कर सकते हैं? क्या कोई आसान तरीका है?

धन्यवाद!

जेम्स

स्रोत

2012-05-05 xtraorange

यह "बड़े पैमाने पर काम" के रूप में जाना जाता है और हाल ही में यह सुर्खियों में जब यह किया गया है [ गिटहब "हैक" करने के लिए प्रयोग किया जाता है] (http://arstechnica.com/business/news/2012/03/hacker-commandeers-github-to-prove-vuln-in-ruby.ars)। आम तौर पर इसका समाधान *** whitelisting ** फ़ील्ड जो बड़े पैमाने पर असाइन किया जा सकता है *। – DCoder

@ डीकोडर, धन्यवाद, वास्तविक नाम होने से बहुत मदद मिलती है। मैं उस जानकारी को दर्शाने के लिए प्रश्न को संशोधित करूंगा। – xtraorange

आप अपने नियंत्रक (रों) में SecurityComponent लोड करने के लिए और CakePHP प्रपत्र आप के लिए छेड़छाड़ नहीं कर पाएगा, यह देखने http://book.cakephp.org/2.0/en/core-libraries/components/security-component.html#form-tampering-prevention

स्रोत

2012-05-05 05:26:11 dhofstet

मैं आपको http://www.dereuromark.de/2010/09/21/saving-model- पढ़ने के लिए भी सलाह देता हूं (xtraorange) डेटा-एंड-सुरक्षा/ – mark

यह बहुत उपयोगी है (आप दोनों)। @mark - मैंने लेख के माध्यम से पढ़ा और पाया कि मैंने उन सभी मुद्दों को संबोधित किया है जिन पर मैं सोच रहा हूं (और जिसे मैंने नहीं माना था)। मैंने देखा कि लेख थोड़ा दिनांकित था और मुझे यकीन नहीं है कि आपने इसे अंतिम बार अपडेट किया था: इस बिंदु पर सुरक्षा घटक पर आप क्या महसूस कर रहे हैं? अगर मैं इसका इस्तेमाल करना चाहता था, तो मुझे अभी भी देखने की क्या ज़रूरत होगी? – xtraorange

तो AppController में सुरक्षा घटक सहित किसी भी रूप को छेड़छाड़ से बचाएगा? क्या आप इस से प्रदर्शन को प्रभावित करते हैं? – Leo

-2

CakePHP सत्यापन उपलब्ध विकल्प में निर्माण किया है। फ़ॉर्म स्वचालित रूप से फ़ील्ड जेनरेट करता है और मॉडल में उल्लिखित सत्यापन मानदंडों के आधार पर सत्यापन करता है। सहेजने से पहले यह सत्यापन स्वचालित रूप से कॉल किया जाएगा।

यदि आप कुछ कस्टम सत्यापन जोड़ना चाहते हैं, तो आप इसे मॉडल में जोड़ सकते हैं।

अपनी विशिष्ट क्वेरी के साथ आप संपादन फॉर्म से is_admin फ़ील्ड को हटा सकते हैं ताकि यह उपयोगकर्ता के लिए संपादन योग्य नहीं होगा। यदि आप अधिक सुरक्षा जोड़ना चाहते हैं और सुनिश्चित करें कि is_admin फ़ील्ड में गलत मान है तो आप नियंत्रक संपादन विधि में अपना मान संपादित कर सकते हैं।

संपादन विधि में आप सहेजें कार्रवाई को कॉल करने से पहले निम्नलिखित कोड जोड़ सकते हैं।
$this->request->data['ModelName']['is_admin] = false;

स्रोत

2012-05-05 04:13:23 Saanch

ठीक है, मैं सत्यापन का संदर्भ नहीं दे रहा हूं। मैं केक सत्यापन को समझता हूं, लेकिन मुझे नहीं लगता कि यह यहां लागू होता है। जहां तक 'is_admin' है, यह वास्तव में सिर्फ एक उदाहरण है। मुद्दा यह है कि मैं सोच रहा हूं कि कोई उपयोगकर्ता चाहे जो भी चाहे उसे बदलना चाहे, चाहे मैं इसे बदलने योग्य बनाना चाहता हूं, किसी भी मॉडल के लिए कि उनके पास कुछ भी संशोधित करने की क्षमता है। तो मैं इसे कैसे रोकूं? – xtraorange

आप क्या कर सकते हैं फ़ील्ड को संपादन पृष्ठ में अक्षम कर दिया गया है जिसे आप नहीं चाहते कि उपयोगकर्ता इसे संपादित कर सके। यहां तक कि आपको लगता है कि उपयोगकर्ता फ़ायरबग का उपयोग कर डेटा को छेड़छाड़ कर सकता है, आप नियंत्रक संपादन कार्रवाई में सहेजें विधि से पहले मूल डेटा को फिर से लिख सकते हैं। '$ this-> अनुरोध-> डेटा ['मॉडल नाम'] ['is_admin] = false;' – Saanch

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

क्या संशोधित डेटा सहेजते समय केकपीएचपी स्वचालित रूप से बड़े पैमाने पर असाइनमेंट भेद्यता से निपटता है?

उत्तर

संबंधित मुद्दे