एक्सएमएल इंजेक्शन से बचने के लिए कैसे करें

Question

मेरे पास इनपुट फ़ील्ड मान है जिसका उपयोग XPath क्वेरी बनाने के लिए किया जाता है। एक्सएमएल इंजेक्शन की संभावना को कम करने के लिए इनपुट स्ट्रिंग में कौन से प्रतीकों को जांचना चाहिए?

Answer 1

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

Answer 2

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

एक बुनियादी स्तर पर आपके सवाल का आप xpath अक्ष ऑपरेशन (उदा //, /, ::) और एक न्यूनतम के रूप में वाइल्डकार्ड (@*, *) के लिए देखने की जरूरत है जवाब देने के लिए। लेकिन मेरी भावना यह है कि सीधे xpath बनाने के लिए उपयोगकर्ता इनपुट का उपयोग करना इष्टतम समाधान नहीं हो सकता है। हो सकता है कि यदि आप हमें प्राप्त करने की कोशिश कर रहे हैं, तो हम आपको अधिक संदर्भ देते हैं, हम वैकल्पिक दृष्टिकोण सुझा सकते हैं?

Answer 3

यह document विस्तार से "अंधेरे XPath इंजेक्शन" की अवधारणा का वर्णन करता है।

यह XPath इंजेक्शन के ठोस उदाहरण प्रदान करता है और इस तरह को रोकने के तरीकों पर चर्चा करता है।

अनुभाग "XPath इंजेक्शन के खिलाफ बचाव" में यह कहा गया है:

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

के रूप में अन्य लोगों ने कहा, एक भी ध्यान कुल्हाड़ियों और // संक्षिप्त नाम का उपयोग करने के लिए भुगतान करना चाहिए। अगर XPath 2.0 इस्तेमाल किया जा रहा है, तो doc() समारोह, नहीं अनुमति दी जानी चाहिए के रूप में यह ज्ञात यूआरआई (या फ़ाइल का नाम) के साथ किसी भी दस्तावेज़ तक पहुँच देता है।

किसी API जो एक XPath अभिव्यक्ति precompiles लेकिन संभावना है कि यह गतिशील रूप में परिभाषित किया गया मानकों के साथ काम करता है पत्ते का प्रयोग उचित है या चर। फिर उपयोगकर्ता इनपुट इन पैरामीटर की सामग्री को परिभाषित करेगा और पहले से ही संकलित अभिव्यक्ति के संशोधन के रूप में कभी नहीं माना जाएगा।

Answer 4

अपनी रणनीति को उल्टा करें।

अस्वीकार्य वर्ण को फिल्टर करने की कोशिश न करें - की नीति

इसके बजाय "जब तक मैं जानता हूँ कि यह बुरा है मान लें यह ठीक है", स्वीकार्य अक्षरों में फिल्टर - की नीति "यह सामान ठीक है, मैं मानता हूं कि सबकुछ खराब है "।

सुरक्षा शर्तों में, "डिफ़ॉल्ट स्वीकृति" के बजाय "डिफ़ॉल्ट अस्वीकार" की नीति अपनाएं।

उदाहरण के लिए ...

... यदि आप एक खोज पद के लिए किसी को पूछ रहे हैं, कहते हैं कि एक व्यक्तियों प्रथम नाम, केवल वे वर्ण जो आप के नाम में पाने की उम्मीद करने के लिए इनपुट की सीमा।

एक तरीका ए-जेड तक सीमित होना होगा और फिर सुनिश्चित करें कि आपकी खोज तकनीक उच्चारण है (उदाहरण के लिए i = ì = í = î = ï और इसी तरह), हालांकि यह गैर-यूरोपीय नामकरण पर पड़ती है।

... यदि आप किसी संख्या के लिए पूछ रहे हैं, तो केवल अंकों तक सीमित करें और बाकी सब कुछ अस्वीकार करें।

Answer 5

इस भेद्यता को बंद करना सिर्फ एक हॉटफिक्स है। इसलिए नीति लागू करना "डिफ़ॉल्ट अस्वीकार" अब बहुत खतरनाक है। मैं निम्नलिखित प्रतीक [के लिए इनपुट की जाँच करने का फैसला किया, ", ', *, =, {, \,।, अंतरिक्ष। मुझे लगता है कि यह सबसे आम हमलों को रोकने सकता है आप सभी उत्तर के लिए धन्यवाद!

Answer 6

का सत्यापन इनपुट स्ट्रिंग उपयोगी हो सकती है, हो सकता है कि नियमित अभिव्यक्ति (कुछ इस तरह \^+) की तरह कुछ उपयोग करें, उस पर आधारित कोई विशेष वर्णों की अनुमति नहीं दी जाएगी।