क्वेरी स्ट्रिंग पैरामीटर मेरे ऐप को जोखिम में डालते हैं?

Question

मैं एक Asp.Net WebForms ऐप लिख रहा हूं जहां मैं URL में क्वेरी स्ट्रिंग पैरामीटर का उपयोग करके संपादित किए जाने वाले रिकॉर्ड के बारे में डेटा में गुजरने वाले एक संपादन पृष्ठ को कॉल कर रहा हूं।

तरह:

http://myapp.path/QuoteItemEdit.aspx?PK=1234&DeviceType=12&Mode=Edit 

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

हालांकि, यह स्पष्ट है कि उपयोगकर्ता अब एक अलग पीके के लिए एक यूआरएल टाइप कर सकता है और उस रिकॉर्ड को संपादित करने के लिए उपयोग प्राप्त कर सकता है। (या, उसके पास मोड = व्यू तक पहुंच हो सकती है, लेकिन मोड = संपादित या मोड = हटाएं नहीं। मूल रूप से, मैं लक्ष्य पृष्ठ पर रिकॉर्ड और एक्सेस अधिकारों को सत्यापित करने से बचने की उम्मीद कर रहा था।

मैंने भी इसका परीक्षण किया है लक्ष्य पृष्ठ को कॉल करने से पहले पीके, डिवाइसटाइप और मोड को स्टोर करने के लिए सत्र चर का उपयोग करके वर्कफ़्लो का उपयोग करें, और फिर उन्हें लक्ष्य पृष्ठ में सत्र से पढ़ना। इसलिए कोई क्वेरी स्ट्रिंग पैरामीटर शामिल नहीं हैं। यह उपयोगकर्ता से नियंत्रण लेगा।

तो, मैं इन दो दृष्टिकोणों पर प्रतिक्रिया की तलाश कर रहा हूं ताकि मैं इससे निपटने का एक स्वीकार्य/मानक तरीका चुन सकूं, क्योंकि यह सीआरयूडी ऐप्स के लिए एक बहुत ही आम ऐप डिज़ाइन पैटर्न जैसा लगता है।

Answer 1

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

उपयोगिता दृष्टिकोण से, यह वही है जो उपयोगकर्ता चाहते हैं (इसे सरल रखता है, उन्हें कुछ पृष्ठों को बुकमार्क करने की अनुमति देता है), और दोनों पृष्ठों पर सुरक्षा यह करने का एकमात्र तरीका है।

Answer 2

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

Answer 3

आपको हमेशा कार्रवाई के वास्तविक निष्पादन से पहले मान्य करना चाहिए, खासकर अगर क्वेरी स्ट्रिंग द्वारा पैरामीटर को पार करना। दूसरे पृष्ठ के लिए जो निष्पादन करता है, आपको उपयोगकर्ता के लिए उतनी प्रतिक्रिया की आवश्यकता नहीं हो सकती है क्योंकि यदि उपयोगकर्ता आपकी सुरक्षा को परिचालित करने का प्रयास करता है तो उसे उपयोगकर्ता के लिए अच्छा नहीं होना चाहिए, इसलिए त्रुटि प्रबंधन बहुत आसान होना चाहिए।

प्रति सत्र चर को पास करना स्वीकार्य है लेकिन imho आपको अभी भी मानों को मान्य करना चाहिए।

Answer 4

आप अपने URL थोड़े और सुरक्षित बनाने के लिए निम्नलिखित कर सकता है:

प्राथमिक कुंजी के लिए प्रयोग GUIDs उपयोगकर्ताओं तो नहीं कर सकते लगता है कि अन्य रिकॉर्ड आईडी

-इस मोड निहित हो couls: GUID = संपादित करें, कोई GUID = नए

और ..

-Server-साइड सत्यापन जाना एकमात्र रास्ता है।

Answer 5

सहमत हैं, आप लक्ष्य पृष्ठ पर अनुमतियां मान्य करना चाहते हैं, यह बिल्कुल सुनिश्चित होने का एकमात्र तरीका है। जब सुरक्षा की बात आती है, तो अनावश्यकता एक बुरी बात नहीं है। अपने डेटाबेस को सुरक्षित करें जैसे कि आप व्यवसाय परत पर भरोसा नहीं करते हैं, अपनी व्यावसायिक परत को सुरक्षित करें जैसे कि आप यूआई पर भरोसा नहीं करते हैं, और UI को भी सुरक्षित करते हैं।

Answer 6

हम हमेशा क्वेरीस्ट्रिंग का उपयोग करते हैं, इसलिए रिकॉर्ड्स को आसानी से बुकमार्क किया जा सकता है, हालांकि यदि आप आसानी से एक्सेस कंट्रोल कोड लिखते हैं तो यह हमेशा मौजूदा कोड का उपयोग करने का मामला होना चाहिए ...

Answer 7

तुम सच में लक्ष्य पृष्ठ पर पहुँच अधिकार की जाँच करने के नहीं करना चाहते हैं:

आप UserID के साथ पी हैश और उसके बाद क्वेरी स्ट्रिंग के लिए हैश मान जोड़ सकते हैं।

string hash = hashFunction(PK.toString() + UserID.toString()); 

फिर आपको यह सुनिश्चित करना होगा कि क्वेरी में हैश पृष्ठ को लोड करने से पहले हैश मान की गणना करता है।

मान लीजिए यह एक आंतरिक संगठन वेब अनुप्रयोग है।