परियोजना

Question

में java.sql.Statement के उपयोग को रोकने के लिए एक तरीका तलाश रहे हैं हमारी टीम ओडब्ल्यूएएसपी दिशानिर्देशों के साथ बेहतर अनुपालन करने की तलाश में है, और कार्यों में से एक एसक्यूएल इंजेक्शन हमलों की रोकथाम है। इसे सुविधाजनक बनाने के लिए, मैं अपने कोडबेस में java.sql.Statement के उपयोग को स्वचालित रूप से जांचने का एक तरीका ढूंढ रहा था, इसलिए इसे ध्वजांकित किया जा सकता है और PreparedStatement का उपयोग करने के लिए बदला जा सकता है।

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

विकास/निर्माण पथ के साथ कोई भी स्थान काम करेगा। अगर इंटेलिज में कुछ ऐसा था जो इसे ध्वजांकित करेगा, मेवेन निर्माण प्रक्रिया में कुछ, या सोनार में इसे ध्वजांकित करने का एक अलग तरीका, इनमें से कोई भी ठीक होगा।

धन्यवाद !!

Answer 1

मैं सोनार के भीतर creating an architectural constraint का सुझाव दूंगा।

उदाहरण * java.sql। ** कक्षाओं के उपयोग पर प्रतिबंध लगाने वाला नियम दिखाता है।

Answer 2

मैंने इसका उपयोग नहीं किया है, लेकिन PMD ऐसा लगता है कि यह इसके लिए एक अच्छा उपकरण हो सकता है।

Answer 3

कक्षा के उपयोग का पता लगाने के बजाय, क्या आप अपनी पीढ़ी को java.sql.Connection प्रॉक्सी के साथ पहचान सकते हैं? जब आप कारखाने से अपना कनेक्शन प्राप्त करते हैं, तो आप इसे अपने प्रॉक्सी में लपेट लेंगे। आपकी प्रॉक्सी का उपयोग विधि कॉल, लॉग क्वेरी स्ट्रिंग, और/या स्टैक निशान पर रिपोर्ट करने के लिए किया जा सकता है जब लोग createStatement() या अन्य ऑफ़-सीमा कॉल का उपयोग कर रहे हों।

public class ProxyConnection implements Connection { 
    private Connection realConnection; 

    public ProxyConnection(Connection realConnection) { 
     this.realConnection = realConnection; 
    } 

    public Statement createStatement() throws SQLException { 
     // could the offenders 
     createCounter.incrementAndGet(); 
     // log the callers -- expensive so maybe every 100th or every 10 secs 
     logger.info("call to createStatment", new Exception("createStatement")); 
     // maybe just throw 
     if (throwOnBadCall) { 
      throw new SQLException("calls to createStatement aren't allowed")); 
     } 
     return realConnection.createStatement(); 
    } 

आप उत्पादन में बहुत भारी मिलता तो आप हमेशा उन्हें गिनती सकता है और ध्वज का एक volatile boolean logBadCall प्रकार केवल समय की अवधि के लिए समस्या की तलाश में नमूने के लिए के लिए जाँच करने के लिए सक्षम करने के लिए नहीं करना चाहते हैं। हो सकता है कि शुरुआत में आप कुछ नमूनाकरण करते हैं, 80% स्थानों पर हमला करते हैं और फिर जब आप अपने आवेदन के उच्च क्वेरी लोड भागों का ख्याल रखते हैं तो केवल स्थायी रूप से पता लगाना पड़ता है।

यदि आपके पास कनेक्शन लपेटने के लिए केंद्रीय स्थान नहीं है तो आपको कनेक्शन पूल या फैक्ट्री को थोड़ा सा लपेटना पड़ सकता है।

उम्मीद है कि इससे मदद मिलती है।