एसक्यूएल इंजेक्शन हमलों को रोकने के लिए बयान तैयार किए जाएंगे?

Question

एक काल्पनिक मामले पर विचार करें, जहां मैं नीचे

private String getpassword(String username) { 

PreparedStatement statement = null; 
ResultSet resultSet = null; 
Connection conn = null; 

final String selectQuery = "SELECT password FROM " + "users WHERE username=?"; 
try { 
    conn = dataSource.getConnection(); 
    statement = conn.prepareStatement(selectQuery); 
    statement.setString(1, username); 
    resultSet = statement.executeQuery(); 
    if (resultSet.next()) { 
     } 

} catch (SQLException e) { 
// log it 
} 
//return 
} 

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

उदाहरण के लिए: मैं उपयोगकर्ता नाम = 'या 1 = 1 प्रदान कर सकता हूं और यह एक वैध SQL कथन होगा। लेकिन यदि ड्राइवर उपयोगकर्ता इनपुट से उद्धरण से बच निकलता है, तो वे एसक्यूएल इंजेक्शन को रोक देंगे।

इसकी सामान्य समझ क्या है?

Answer 1

इस के अनुसार, हाँ: http://en.wikipedia.org/wiki/SQL_injection

उस मामले में बयान पहले से ही संकलित और इंजेक्शन फिर कोड व्याख्या नहीं की जाएगी (और इस प्रकार निष्पादित नहीं किया) है।

Answer 2

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

Answer 3

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

से वापस आता है उदाहरण के लिए, यदि आपका वेब पेज प्रदर्शित करता है :

Hello, ${username} 

यदि उपयोगकर्ता नाम है

<script>alert('I could have been more malicious')</script> 

XSS या CSRF दौरे का कारण बन सकता है।

एनबी।

Hello, ${fn:escapeXml(username)} 

सुरक्षित (जेएसपी कोड) होगा।

एक अच्छा संदर्भ है:

• http://www.sans.org/top25-software-errors/