अपनी प्राथमिक कुंजी को उजागर करना (विशेषकर यदि वे अनुमानित हैं) असुरक्षित प्रत्यक्ष वस्तु संदर्भ नामक एक भेद्यता है।
इस तरह एक यूआरएल (या किसी अन्य क्लाइंट द्वारा प्रदत्त परम) होने से:
http://www.domain.com/myaccount?userid=12
आप अपने अंतिम उपयोगकर्ताओं को उन चरों के साथ खिलवाड़ करने और कोई भी डेटा पास करने का अवसर देते हैं जो उन्हें पसंद है। इस भेद्यता को कम करने के लिए काउंटर उपाय इसके बजाय अप्रत्यक्ष वस्तु संदर्भ बनाना है। यह एक बड़े बदलाव की तरह लग सकता है, लेकिन ऐसा होना जरूरी नहीं है। आपको अपने सभी टेबल या किसी भी चीज़ को रीकी करने की ज़रूरत नहीं है, आप इसे केवल एक अप्रत्यक्ष संदर्भ मानचित्र के उपयोग के माध्यम से अपने डेटा के साथ चतुराई से कर सकते हैं।
इस पर विचार करें:आपके पास एक उपयोगकर्ता है जो आपकी साइट पर खरीदारी कर रहा है। और जब भुगतान करने का समय आता है तो उन्हें उनके क्रेडिट कार्ड नंबरों की एक ड्रॉप डाउन के साथ प्रस्तुत किया जाता है जो आपके पास "फाइल पर" हैं। यदि आप ड्रॉप डाउन के कोड को देखते हैं तो आप देखते हैं कि क्रेडिट कार्ड नंबर 8055, 9044 और 10099 कुंजियों से जुड़े हैं।
उपयोगकर्ता इसे देख सकता है और सोच सकता है कि वे ऑटो-इंक्रिमेंटिंग प्राथमिक कुंजी की तरह दिखते हैं (उपयोगकर्ता शायद सही होगा)। इसलिए वह यह देखने के लिए अन्य चाबियों की कोशिश करना शुरू कर देता है कि क्या वह किसी और के कार्ड से भुगतान कर सकता है।
अब तकनीकी रूप से, आपके पास सर्वर-साइड पर कोड होना चाहिए जो यह सुनिश्चित करता है कि चयनित कार्ड उपयोगकर्ता के खाते का हिस्सा है और वे इसका उपयोग कर सकते हैं। यह एक गढ़ा हुआ उदाहरण है। अभी के लिए हम मान लेंगे कि ऐसा नहीं है या यह एक अन्य प्रकार का फॉर्म है जिसमें शायद उस तरह का सर्वर साइड कंट्रोल नहीं है।
तो हम अंतिम उपयोगकर्ता को ऐसी कुंजी चुनने से कैसे रोक सकते हैं जो उन्हें उपलब्ध नहीं होनी चाहिए?
उन्हें डीबी में रिकॉर्ड का सीधा संदर्भ दिखाने के बजाय, उन्हें एक अप्रत्यक्ष संदर्भ दें।
डीबी कुंजियों को ड्रॉपडाउन में डालने के बजाय, हम सर्वर पर एक सरणी बनाएंगे और इसे उपयोगकर्ता के सत्र में भर देंगे।
Array cards = new Array(3);
cards[0] = 8055;
cards[1] = 9044;
cards[2] = 10099;
ड्रॉप डाउन में अब हम उस सरणी के सूचकांक का संदर्भ प्रदान करते हैं जहां कार्ड संग्रहीत है। इसलिए वास्तविक कुंजियों को देखने के बजाय, अंतिम उपयोगकर्ता को 0, 1 और 2 के मान दिखाई देंगे, यदि वे स्रोत देखते हैं।
जब फॉर्म जमा किया जाता है तो उनमें से एक मान पास कर दिया जाएगा। फिर हम उपयोगकर्ता के सत्र से सरणी प्राप्त करते हैं और मूल्य प्राप्त करने के लिए अनुक्रमणिका का उपयोग करते हैं। वास्तविक कुंजी ने सर्वर को कभी नहीं छोड़ा।
और यदि उपयोगकर्ता चाहे तो पूरे दिन अलग-अलग मूल्यों में पास हो सकता है, लेकिन सर्वर-साइड एक्सेस कंट्रोल की जगह के बावजूद, उसे अपने कार्ड के अलावा कभी भी कोई परिणाम नहीं मिलेगा।
ध्यान रखें कि पास-इन इंडेक्स का उपयोग करते समय मूल्य प्राप्त करने के लिए कि यदि उपयोगकर्ता इसके साथ गड़बड़ करता है तो आपको कुछ अपवाद मिल सकते हैं (ArrayOutOfBounds, InvalidIndex, जो भी हो)। तो उस सामान को एक कोशिश/पकड़ में लपेटें ताकि आप उन त्रुटियों को दबा सकें और क्रैकिंग प्रयासों को देखने के लिए विफलताओं को लॉग कर सकें।
आशा है कि यह मदद करता है।
असुरक्षित प्रत्यक्ष वस्तु संदर्भों के बारे में अधिक पढ़ने के लिए, OWASP शीर्ष 10 देखें। यह जोखिम संख्या A4 है। https://www.owasp.org/index.php/Top_10_2010-A4 -Insecure_Direct_Object_References
