2008-09-24 19 views
32

बिल्ला के server.xml में संसाधन परिभाषा कुछ इस तरह दिखता ...डेटा स्रोत के tomcat की server.xml संसाधन परिभाषा के लिए स्पष्ट में पासवर्ड संग्रहीत करने से कैसे बचें?

<Resource 
    name="jdbc/tox" 
    scope="Shareable" 
    type="javax.sql.DataSource" 
    url="jdbc:oracle:thin:@yourDBserver.yourCompany.com:1521:yourDBsid" 
    driverClassName="oracle.jdbc.pool.OracleDataSource" 
    username="tox" 
    password="toxbaby" 
    maxIdle="3" 
    maxActive="10" 
    removeAbandoned="true" 
    removeAbandonedTimeout="60" 
    testOnBorrow="true" 
    validationQuery="select * from dual" 
    logAbandoned="true" 
    debug="99"/> 

पासवर्ड स्पष्ट है। इससे कैसे बचें?

उत्तर

-8

हम का उपयोग सी # के SHA1CryptoServiceProvider

print(SHA1CryptoServiceProvider sHA1Hasher = new SHA1CryptoServiceProvider(); 
     ASCIIEncoding enc = new ASCIIEncoding(); 

     byte[] arrbytHashValue = sHA1Hasher.ComputeHash(enc.GetBytes(clearTextPW)); 
     string HashData = System.BitConverter.ToString(arrbytHashValue); 
     HashData = HashData.Replace("-", ""); 
     if (HashData == databaseHashedPassWO) 
     { 
      return true; 
     } 
     else 
     { 
      return false; 
     }); 

)

+2

सुनिश्चित नहीं हैं कि इस बिल्ला config फ़ाइलों के साथ क्या करना है क्या। – dacracot

3

बिलाव पता करने के लिए डेटाबेस से कनेक्ट करने के लिए कैसे की जरूरत है, तो यह सादा पाठ पासवर्ड के लिए उपयोग की जरूरत है। अगर एन्क्रिप्टेड पासवर्ड में, टोमकैट को यह जानने की जरूरत है कि इसे कैसे डिक्रिप्ट करना है, तो आप केवल समस्या को कहीं और ले जा रहे हैं।

असली समस्या यह है: टॉमकैट को छोड़कर server.xml तक कौन पहुंच सकता है? एक समाधान server.xml पर केवल रूट उपयोगकर्ता को पढ़ने की पहुंच देना है, यह आवश्यक है कि टॉमकैट रूट विशेषाधिकारों के साथ शुरू हो: यदि किसी दुर्भावनापूर्ण उपयोगकर्ता को सिस्टम पर रूट विशेषाधिकार प्राप्त होते हैं, तो डेटाबेस पासवर्ड खोना शायद एक मामूली चिंता है।

अन्यथा आपको प्रत्येक स्टार्टअप पर मैन्युअल रूप से पासवर्ड टाइप करना चाहिए, लेकिन यह शायद ही कभी एक व्यवहार्य विकल्प है।

+1

मैं अब तक एक सुरक्षा विशेषज्ञ नहीं हूं, लेकिन ऐसा लगता है कि टॉमकैट खुद ही हमले के लिए प्रवेश द्वार के द्वारों में से एक है (टॉमकैट की भेद्यता शोषण या ऐप द्वारा उपयोग की जाने वाली librairies में से एक, जैसे कि Struts 2 के साथ हाल की समस्याएं) और इस तरह के रूट विशेषाधिकार नहीं दिया जाना चाहिए! –

+0

मैं सहमत हूं। मैं अब टॉमकैट का उपयोग नहीं कर रहा हूं, लेकिन मैं रूट विशेषाधिकारों के बिना इसे चलाने का सुझाव दूंगा। वैसे भी, जो टोमकैट निर्देशिका पढ़ सकता है, डीबी पासवर्ड पढ़ सकता है। जहां तक ​​मुझे पता है, यह आपके द्वारा उपयोग की जा रही किसी भी भाषा/ढांचे के साथ एक अपरिहार्य समस्या है। – gameame

+5

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

35

पासवर्ड एन्क्रिप्ट करने से पहले कहा गया है कि कहीं और समस्या को हल कर रहा है।

वैसे भी, यह काफी आसान है। बस अपनी गुप्त कुंजी के लिए स्थिर फ़ील्ड के साथ एक वर्ग लिखें और इसी तरह, और अपने पासवर्ड को डिक्रिप्ट करने के लिए स्थैतिक विधियां। इस कक्षा का उपयोग करते हुए टॉमकैट की कॉन्फ़िगरेशन फ़ाइल (server.xml या yourapp.xml ...) में अपना पासवर्ड एन्क्रिप्ट करें।

और टोमकैट में "फ्लाई पर" पासवर्ड डिक्रिप्ट करने के लिए, डीबीसीपी के BasicDataSourceFactory का विस्तार करें और इस कारखाने का उपयोग अपने संसाधन में करें।

<Resource 
     name="jdbc/myDataSource" 
     auth="Container" 
     type="javax.sql.DataSource" 
     username="user" 
     password="encryptedpassword" 
     driverClassName="driverClass" 
     factory="mypackage.MyCustomBasicDataSourceFactory" 
     url="jdbc:blabla://..."/> 

और कस्टम कारखाने के लिए:

यह कैसा दिखेगा

package mypackage; 

.... 

public class MyCustomBasicDataSourceFactory extends org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory { 

@Override 
public Object getObjectInstance(Object obj, Name name, Context nameCtx, Hashtable environment) throws Exception { 
    Object o = super.getObjectInstance(obj, name, nameCtx, environment); 
    if (o != null) { 
     BasicDataSource ds = (BasicDataSource) o; 
     if (ds.getPassword() != null && ds.getPassword().length() > 0) { 
      String pwd = MyPasswordUtilClass.unscramblePassword(ds.getPassword()); 
      ds.setPassword(pwd); 
     } 
     return ds; 
    } else { 
     return null; 
    } 
} 

आशा इस मदद करता है।

+6

मेरे लिए, यह कोई सुरक्षा नहीं जोड़ता है, क्योंकि हमलावर हमेशा आपके फ़ाइल को प्राप्त करने के लिए अपने जार को डीकंपाइल कर सकता है जिसे आपने कक्षा फ़ाइल में हार्डकोड किया है ... – dmansfield

+5

आईएमओ यह स्पष्ट रूप से पासवर्ड रखने से बेहतर है जहां हर गूंगा स्क्रिप्ट किड्डी इसे देखने के लिए जानती है। यह कुछ बार उठाता है, है ना? –

+1

@dmansfield - क्या मुझे कुछ याद आ रही है? मैं नहीं देखता कि उपर्युक्त दृष्टिकोण में किसी भी वर्ग फ़ाइल में पासवर्ड को हार्ड-कोड किया जाएगा? –

5

टोमकैट a Password FAQ है जो विशेष रूप से आपके प्रश्न को संबोधित करता है। संक्षेप में: पासवर्ड को अपने सर्वर को स्पष्ट और उचित रूप से लॉक-डाउन रखें।

यह पृष्ठ ऑडिटर की चेकलिस्ट को पास करने के लिए सुरक्षा-दर-अस्पष्टता का उपयोग कैसे किया जा सकता है इसके बारे में कुछ सुझाव भी प्रदान करता है।

3

जैसा कि @Ryan का उल्लेख है, कृपया इस समाधान को लागू करने से पहले टॉमकैट के Tomcat Password FAQ पढ़ें। आप केवल अस्पष्टता को सुरक्षा नहीं जोड़ रहे हैं।

@ जेरोम डेलट्रे का उत्तर सरल जेडीबीसी डेटा स्रोतों के लिए काम करेगा, लेकिन डेटासेट निर्माण (जैसे oracle.jdbc.xa.client.OracleXADataSource) के हिस्से के रूप में कनेक्ट होने वाले अधिक जटिल लोगों के लिए नहीं।

यह वैकल्पिक दृष्टिकोण है जो मौजूदा कारखाने को कॉल करने से पहले पासवर्ड को संशोधित करता है। नीचे मूलभूत डेटासोर्स के लिए एक कारखाने का एक उदाहरण है और एक परमाणु जेटीए संगत एक्सए डेटासोर्स के लिए एक है।

बुनियादी उदाहरण:

public class MyEncryptedPasswordFactory extends BasicDataSourceFactory { 

    @Override 
    public Object getObjectInstance(Object obj, Name name, Context context, Hashtable<?, ?> environment) 
      throws Exception { 
     if (obj instanceof Reference) { 
      Reference ref = (Reference) obj; 
      DecryptPasswordUtil.replacePasswordWithDecrypted(ref, "password"); 
      return super.getObjectInstance(obj, name, context, environment); 
     } else { 
      throw new IllegalArgumentException(
        "Expecting javax.naming.Reference as object type not " + obj.getClass().getName()); 
     } 
    } 
} 

Atomikos उदाहरण:

public class MyEncryptedAtomikosPasswordFactory extends EnhancedTomcatAtomikosBeanFactory { 
    @Override 
    public Object getObjectInstance(Object obj, Name name, Context context, Hashtable<?, ?> environment) 
      throws NamingException { 
     if (obj instanceof Reference) { 
      Reference ref = (Reference) obj; 
      DecryptPasswordUtil.replacePasswordWithDecrypted(ref, "xaProperties.password"); 
      return super.getObjectInstance(obj, name, context, environment); 
     } else { 
      throw new IllegalArgumentException(
        "Expecting javax.naming.Reference as object type not " + obj.getClass().getName()); 
     } 
    } 
} 

संदर्भ में अद्यतन कर रहा है पासवर्ड मूल्य:

public class DecryptPasswordUtil { 

    public static void replacePasswordWithDecrypted(Reference reference, String passwordKey) { 
     if(reference == null) { 
      throw new IllegalArgumentException("Reference object must not be null"); 
     } 

     // Search for password addr and replace with decrypted 
     for (int i = 0; i < reference.size(); i++) { 
      RefAddr addr = reference.get(i); 
      if (passwordKey.equals(addr.getType())) { 
       if (addr.getContent() == null) { 
        throw new IllegalArgumentException("Password must not be null for key " + passwordKey); 
       } 
       String decrypted = yourDecryptionMethod(addr.getContent().toString()); 
       reference.remove(i); 
       reference.add(i, new StringRefAddr(passwordKey, decrypted)); 
       break; 
      } 
     } 
    } 
} 

एक बार .jar इन कक्षाओं युक्त फ़ाइल बिलाव के classpath में कर रहे हैं आप उनका उपयोग करने के लिए अपने server.xml अद्यतन कर सकते हैं।

<Resource factory="com.mycompany.MyEncryptedPasswordFactory" username="user" password="encryptedPassword" ...other options... /> 

<Resource factory="com.mycompany.MyEncryptedAtomikosPasswordFactory" type="com.atomikos.jdbc.AtomikosDataSourceBean" xaProperties.user="user" xaProperties.password="encryptedPassword" ...other options... /> 
+0

धन्यवाद, यह मेरे लिए काम करता है, जबकि जेरोम द्वारा पहले सुझाए गए दृष्टिकोण ने नहीं किया (यह "super.getObjectInstance" पर एक अपवाद फेंक दिया, जो कि गैर-डिक्रिप्ट किए गए पासवर्ड का उपयोग कर डेटा स्रोत तक पहुंचने का प्रयास कर रहा था)। छोटे जोड़े, हम एक सत्र डीबी के साथ ही एक आवेदन डीबी का उपयोग कर रहे हैं; मैंने पाया कि सत्र डीबी डेटा स्रोत के लिए पासवर्ड एन्क्रिप्शन की अनुमति देने के लिए, हमें कस्टम क्लास युक्त जार को टॉमकैट/lib निर्देशिका में शामिल करना था, साथ ही उन्हें वेब ऐप्स में भी शामिल करना था, अन्यथा वे टॉमकैट सत्र तक पहुंच योग्य नहीं थे प्रबंधक। –

+0

सही। आप ड्राइवर फ़ाइलों को उस निर्देशिका में डाल सकते हैं जिसे हमने catalina.properties फ़ाइल का उपयोग करके टोमकैट के संपर्क में लाया है। – JustinKSU

-1

पूर्वगामी के सभी कहा गया है, अगर आप अभी भी सादा पाठ पासवर्ड, आपको SHA-256 या (अधिमानतः) SHA-512 के रूप में एक हैशिंग एल्गोरिथ्म का उपयोग कर सकते बचना चाहते हैं। जब कोई पासवर्ड बनाया जाता है, तो हैश वैल्यू प्राप्त करें और उसे पासवर्ड के बजाय स्टोर करें। जब कोई उपयोगकर्ता लॉग इन करता है, तो पासवर्ड हैश और संग्रहीत हैश किए गए पासवर्ड से मेल खाता है। हैशिंग एल्गोरिदम एक छोटी स्ट्रिंग (या संख्या) स्थान से एक वर्ण स्ट्रिंग (या संख्या) को एक बड़े तरीके से ले जाते हैं जो कि विपरीत है।

+2

जो डेटाबेस कनेक्शन – spy

0

Here एक चरण-दर-चरण मार्गदर्शिका है, मूल रूप से आपको डेटासेट स्रोत शुरू करते समय अपना डेटासेट कारखाना लिखना होगा और डेटाबेस प्रमाण-पत्रों को डिक्रिप्ट करना होगा, उम्मीद है कि लिंक मदद करता है।

+1

के लिए पूरी तरह से बेकार है, उस लिंक में सामग्री को संक्षेप में शामिल करना बेहतर होगा यदि लिंक भविष्य में काम नहीं करेगा। – xhg

+0

धन्यवाद मैंने इसका पालन किया और यह बहुत उपयोगी है। – Hasan

+0

@ हसन, मुझे यह बताने के लिए धन्यवाद कि मेरी पोस्ट सहायक है। – junjun

1

काम के 4 घंटे बाद, प्रश्न और उत्तर खोजें मुझे समाधान मिला। @ जेरोम डेलैटर द्वारा दिए गए उत्तर के आधार पर यहां पूरा कोड है (जेएनडीआई डेटा स्रोत कॉन्फ़िगरेशन के साथ)।

Context.xml

<Resource 
    name="jdbc/myDataSource" 
    auth="Container" 
    type="javax.sql.DataSource" 
    username="user" 
    password="encryptedpassword" 
    driverClassName="driverClass" 
    factory="mypackage.MyCustomBasicDataSourceFactory" 
    url="jdbc:blabla://..."/> 

कस्टम डेटा स्रोत फैक्टरी:

package mypackage; 

public class MyCustomBasicDataSourceFactory extends org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory { 
    @Override 
    public Object getObjectInstance(Object obj, Name name, Context nameCtx, Hashtable environment) throws Exception { 
     Object o = super.getObjectInstance(obj, name, nameCtx, environment); 
     if (o != null) { 
      BasicDataSource ds = (BasicDataSource) o; 
      if (ds.getPassword() != null && ds.getPassword().length() > 0) { 
       String pwd = MyPasswordUtilClass.unscramblePassword(ds.getPassword()); 
       ds.setPassword(pwd); 
      } 
      return ds; 
     } else { 
      return null; 
     } 
    } 
} 

डेटा स्रोत सेम:

@Bean 
public DataSource dataSource() { 
    DataSource ds = null; 
    JndiTemplate jndi = new JndiTemplate(); 
    try { 
     ds = jndi.lookup("java:comp/env/jdbc/myDataSource", DataSource.class); 
    } catch (NamingException e) { 
     log.error("NamingException for java:comp/env/jdbc/myDataSource", e); 
    } 
    return ds; 
} 
+0

क्या यह एकमात्र तरीका है? क्या यह संभव है कि यह डीबी विक्रेता पर निर्भर हो? –

 संबंधित मुद्दे

  • कोई संबंधित समस्या नहीं^_^