LIKE के साथ SQL क्वेरीज़ का संकलन करते समय तार्किक कमजोरियाँ

जब उपयोगकर्ता डेटा LIKE ऑपरेटर के अंतर्गत क्वेरी में आता है, तो आपको बेहद सावधान रहना चाहिए।
तथ्य यह है कि mysql_real_escape_string और यहां तक ​​कि तैयार किए गए बयानों सहित एक भी फ़िल्टरिंग फ़ंक्शन वाइल्डकार्ड वर्णों से जुड़ी तार्किक त्रुटियों से रक्षा नहीं करेगा।

वेब अनुप्रयोगों के ऑडिटिंग के हमारे अभ्यास में, यह त्रुटि लगभग हर पांचवें वेब एप्लिकेशन में SQL इंजेक्शन (19.3%) के लिए असुरक्षित होती है।

LIKE ऑपरेटर का उपयोग स्ट्रिंग प्रकारों के गलत मान द्वारा खोज करने के लिए किया जाता है।
ऑपरेटर सिंटैक्स वाइल्डकार्ड शब्दार्थ के उपयोग की अनुमति देता है, जहां
% क्लासिक * की जगह - किसी भी वर्ण का एक क्रम
_ क्लासिक की जगह? - कोई एकल चरित्र

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

एक सामान्य गलत धारणा यह भी है कि एक भेद्यता को न्यूनतम लंबी स्ट्रिंग द्वारा रोका जाए।
SQL क्वेरी
SELECT asd FROM t1 WHERE name LIKE '%%%%%%%%%%%%%%%%%%%%%%%%%%%'
जैसे काम करता है
SELECT asd FROM t1 WHERE name LIKE '%%'

लेकिन यहां तक ​​कि अगर डिजाइन में कोई तर्क त्रुटि नहीं है, तो आपको वाइल्डकार्ड को नहीं छोड़ना चाहिए जहां यह स्पष्ट रूप से आवश्यक नहीं है। आखिरकार, हर कोई जानता है कि LIKE के साथ अनुरोधों को कैसे धीमा किया जाए, और LIKE में एक पूर्ण वाइल्डकार्ड के साथ वे अधिक धीमा कर देते हैं।
इसका उपयोग DoS, DDoS के लिए किया जा सकता है, या त्रुटि संदेश भड़काने के द्वारा सर्वर से जानकारी प्राप्त कर सकता है (जैसे max_execution_time की समाप्ति)