GUID को टालने के दौरान मैं अपने HTML को शोषक होने से कैसे रोकूं?

Question

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

अब जब मैं सत्र स्थिति या अतिरिक्त ऑथ चेक का उपयोग कर यूआरएल समस्याओं को आसानी से ठीक कर सकता हूं, तो मुझे उस डेटाबेस आईडी के बारे में कम यकीन है जो एचटीएमएल में एम्बेडेड हो जाता है जिस पर साइट थूकती है (यानी मैं उन्हें एक बूंद देता हूं भरने)। जब ids एक पोस्ट में वापस आते हैं तो मैं कैसे सुनिश्चित कर सकता हूं कि मैंने उन्हें वैध विकल्प के रूप में रखा है? इस समस्या को हल करने के संदर्भ में "सर्वोत्तम अभ्यास" क्या माना जाता है?

जबकि मुझे सराहना है कि मैं बस इसे "ग़लत कर सकता हूं" मुझे ऐसा करने में संकोच नहीं है क्योंकि मुझे डिबगिंग डेटाबेस के साथ काम करने के लिए गधे में दर्द होता है।

क्या मेरे पास कोई विकल्प है? क्या मुझे आईडी के आसान अनुमान को रोकने के लिए ग्रिड करना चाहिए या क्या किसी प्रकार का डीआरवाई तंत्र है जिसका उपयोग मैं आईडी में उपयोग के रूप में साइट पर वापस आने के लिए कर सकता हूं?

अद्यतन: एक टिप्पणीकर्ता ने उन शोषणों के बारे में पूछा जिन्हें मैं उम्मीद कर रहा हूं। आइए कहें कि मैं उन सभी स्थानों की एक ड्रॉप डाउन सूची के साथ एक HTML फॉर्म थूकता हूं जो कोई "खजाना" आयात कर सकता है। उन स्थानों की आईडी जो उपयोगकर्ता के पास हैं 1,2 और 3, ये HTML में उपलब्ध कराई गई हैं। लेकिन उपयोगकर्ता एचटीएमएल की जांच करता है, इसके साथ झुकाव करता है और 4 चयनित आईडी की आईडी के साथ एक पोस्ट डालने का फैसला करता है। 4 उसका स्थान नहीं है, यह किसी और का है।

Answer 1

उपयोगकर्ता द्वारा संशोधित आईडी के विरुद्ध पारित आईडी को मान्य करें।

यह कठिन लग सकता है, लेकिन यह सुनिश्चित करने का एकमात्र तरीका है कि उपयोगकर्ता को उस संशोधित करने का एकमात्र तरीका है जिसे वे संशोधित करने का प्रयास कर रहे हैं। प्रमाणीकरण के बिना GUID का उपयोग अस्पष्टता से सुरक्षा है: निश्चित रूप से उनका अनुमान लगाना कठिन है, लेकिन आप संभावित रूप से पर्याप्त संसाधनों का अनुमान लगा सकते हैं।

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

Answer 2

मुद्दा आप का वर्णन के रूप में जाना जाता है "असुरक्षित प्रत्यक्ष वस्तु संदर्भ," और OWASP समूह दो इस मुद्दे से निपटने के लिए नीतियों की सिफारिश की:

1. सत्र-आधारित अप्रत्यक्ष वस्तु संदर्भों का उपयोग, और मान्य सभी ऑब्जेक्ट संदर्भों तक पहुंचता है।

सुझाव # 1 का एक उदाहरण यह होगा कि ड्रॉपडाउन विकल्प 1, 2, और 3 होने के बजाय, आप प्रत्येक विकल्प को GUID जो उपयोगकर्ता के सत्र में किसी मानचित्र में मूल आईडी से जुड़े होते हैं। जब आप उस उपयोगकर्ता से POST प्राप्त करते हैं, तो आप यह देखने के लिए जांचते हैं कि दी गई आईडी को किस वस्तु से बंधना था। ओडब्ल्यूएएसपी के ईएसएपीआई में विभिन्न भाषाओं में इसकी मदद करने के लिए कुछ पुस्तकालय हैं।

लेकिन कई मामलों में सुझाव # 1 वास्तव में प्रतिकूल है। उदाहरण के लिए, कई मामलों में आप ऐसे यूआरएल रखना चाहते हैं जिन्हें एक उपयोगकर्ता से दूसरे उपयोगकर्ता में प्रतिलिपि/चिपकाया जा सके। प्रक्रिया # 2 को आम तौर पर इस मुद्दे को हल करने का सबसे मूर्ख तरीका माना जाता है।

Answer 3

आप असुरक्षित आईडी के साथ Broken Access Control का वर्णन कर रहे हैं। एक बार जब आप खतरे की पहचान कर लें और तय करें कि कौन से आईडी कुछ उपयोगकर्ताओं के स्वामित्व में हैं, तो सुनिश्चित करें कि इस सर्वर के पक्ष में चेक मौजूद हैं।