AI के साथ सुरक्षित कोड समीक्षा
AI कुछ ही सेकंड में सुरक्षा समस्याओं के लिए pull requests की समीक्षा कर सकता है। जानें कि यह क्या पकड़ता है, क्या छोड़ देता है, और यह कैसे जांचें कि कोई समाधान (fix) वाकई काम करता है या नहीं।
60 सेकंड में
AI के साथ सुरक्षित कोड समीक्षा
AI कुछ ही सेकंड में सुरक्षा समस्याओं के लिए pull requests की समीक्षा कर सकता है। जानें कि यह क्या पकड़ता है, क्या छोड़ देता है, और यह कैसे जांचें कि कोई समाधान (fix) वाकई काम करता…
AI आमतौर पर क्या पकड़ता है, और क्या छोड़ देता है
- साफ़-साफ़ दिखने वाले injection पैटर्न (स्ट्रिंग्स को जोड़कर बनाई गई SQL)
- कोड में सीधे पेस्ट किए गए secrets
- बदली गई लाइनों में छूटी हुई इनपुट जाँच (input checks)
- खतरनाक फ़ंक्शन और पुरानी क्रिप्टोग्राफी (crypto)
- Authorisation से जुड़े बग जिनके लिए बिज़नेस नियमों की समझ ज़रूरी होती है
- ऐसी समस्याएँ जो कई फ़ाइलों या सेवाओं में फैली हों
- ऐसे कोड में समस्याएँ जो उसे दिखाई ही नहीं गईं
- क्या कोई समाधान वाकई चलने पर सही काम करता है
एक कमज़ोर (vulnerable) और एक सुधरा हुआ उदाहरण
def get_user(conn, username):
cur = conn.cursor()
# BAD: user input is joined into the SQL text
query = "SELECT id, email FROM users WHERE name = '" + username + "'"
cur.execute(query)
return cur.fetchone()def get_user(conn, username):
cur = conn.cursor()
# GOOD: the value is passed separately; the database treats it as data
cur.execute("SELECT id, email FROM users WHERE name = ?", (username,))
return cur.fetchone()' OR '1'='1 जैसा यूज़रनेम SQL का मतलब ही बदल देता है। सुधरे हुए वर्शन में, डेटाबेस ड्राइवर इस वैल्यू को अलग से भेजता है, इसलिए यह कभी भी कमांड का हिस्सा नहीं बन सकती। प्लेसहोल्डर का स्टाइल ड्राइवर पर निर्भर करता है: sqlite3 ? का उपयोग करता है, कुछ अन्य Python ड्राइवर %s का उपयोग करते हैं।सुरक्षा समीक्षा के लिए एक चेकलिस्ट
| पहलू | पूछे जाने वाले सवाल (आप और AI दोनों के लिए) |
|---|---|
| Injection | क्या कोई इनपुट बिना सुरक्षित हैंडलिंग के SQL, शेल कमांड, फ़ाइल पाथ या टेम्पलेट्स तक पहुँच रहा है? |
| Authorisation | क्या हर रूट यह जाँचता है कि इस यूज़र को इस ऑब्जेक्ट पर यह काम करने की अनुमति है या नहीं? |
| Authentication | क्या सेशन्स, टोकन्स और पासवर्ड हैंडलिंग का काम स्टैंडर्ड लाइब्रेरीज़ से किया जा रहा है? |
| Secrets | क्या कोड या कॉन्फ़िग फ़ाइलों में कोई keys, पासवर्ड या टोकन्स मौजूद हैं? |
| डेटा का उजागर होना (Data exposure) | क्या किसी रिस्पॉन्स या लॉग में ज़रूरत से ज़्यादा पर्सनल डेटा शामिल है? |
| Dependencies | क्या नई लाइब्रेरीज़ वाकई ज़रूरी हैं, सही तरह से मेंटेन की जा रही हैं और भरोसेमंद स्रोत से हैं? |
समाधान की पुष्टि करें (Verify the fix)
- 1
एक टेस्ट लिखें
एक ऐसा टेस्ट जोड़ें जो हमले वाला इनपुट भेजे और सुरक्षित व्यवहार की उम्मीद करे। - 2
इसे फ़ेल होते देखें
इसे पुराने कोड पर चलाएँ; इसे फ़ेल होना चाहिए (या बग दिखाना चाहिए)। - 3
इसे पास होते देखें
इसे सुधरे हुए कोड पर चलाएँ; इसे पास होना चाहिए। - 4
मिलती-जुलती कमियाँ खोजें
पूरे कोडबेस में दूसरी जगहों पर भी इसी पैटर्न की तलाश करें।
और देखें और पढ़ें
लैब
एक छोटे से काल्पनिक फ़ंक्शन की AI-सहायता प्राप्त समीक्षा, एक जाँचे-परखे समाधान और टेस्ट के साथ।
समस्या
केवल अपनी मशीन पर काम करें। शुरुआती कोड (काल्पनिक) का उपयोग करें।
- इस पाठ में दी गई चेकलिस्ट का उपयोग करके किसी AI से सुरक्षा समस्याओं के लिए कोड की समीक्षा करने को कहें।
- उसने जो भी समस्याएँ खोजी हैं उनकी सूची बनाएँ, और मार्क करें कि क्या आप सहमत हैं। कोई ऐसी समस्या भी जोड़ें जो उससे छूट गई हो।
- एक सुधरा हुआ वर्शन लिखें।
- एक छोटा टेस्ट (या एक स्पष्ट मैन्युअल टेस्ट प्लान) लिखें जो दिखाए कि injection अब काम नहीं करता है और यूज़र्स दूसरे यूज़र्स के नोट्स नहीं पढ़ सकते हैं।
प्रैक्टिस लैब
कोड में बदलाव करें और इसे रन करें। Python आपके ब्राउज़र में चलता है — हमारे सर्वर पर कुछ नहीं भेजा जाता।
कोई आउटपुट नहीं। वैल्यूज़ देखने के लिए print(...) जोड़ें।
आपका काम तब पूरा होगा जब
कठिन सवाल
उत्तर देखने से पहले ख़ुद जवाब देने की कोशिश करें। अगर आप इनके जवाब दे सकते हैं, तो आप पाठ समझ गए हैं।
Q1note_id यूआरएल से आता है और इसे str() से बदला गया है। क्या यह इसे सुरक्षित बनाता है?दिखाएं
नहीं। str() बस किसी भी वैल्यू को टेक्स्ट में बदल देता है; यह यह नहीं जाँचता कि वैल्यू कोई संख्या है या नहीं। यदि कॉल करने वाला कोई चालाकी से तैयार की गई स्ट्रिंग भेजता है, तो वह सीधे SQL में चली जाती है। int() से बदलने पर गैर-संख्याएँ खारिज हो जाएँगी, लेकिन फिर भी parameterised queries ही सही समाधान हैं।
Q2AI समीक्षक के लिए ओनरशिप की छूटी हुई जाँच को छोड़ देना आसान क्यों होता है, भले ही पैरामीटर वहीं सामने मौजूद हो?दिखाएं
फ़ंक्शन काम करता है और इसमें कोई साफ़ तौर पर खतरनाक कॉल नहीं है। बग को पकड़ने के लिए एक ऐसे नियम की ज़रूरत होती है जो कोड में लिखा नहीं है: यूज़र्स केवल अपने खुद के नोट्स पढ़ सकते हैं। एक संकेत मदद करता है (अप्रयुक्त current_user_id), लेकिन समीक्षकों को यह सोचना ही होगा कि किसे क्या करने की अनुमति है, यही कारण है कि authorisation से जुड़े सवाल वाली चेकलिस्ट इंसानों और AI दोनों की मदद करती है।
अक्सर पूछे जाने वाले सवाल
क्या कोई AI समीक्षक किसी इंसानी सुरक्षा समीक्षा की जगह ले सकता है?
नहीं। यह एक उपयोगी पहली जाँच है जो कई आम गलतियों को तेज़ी से पकड़ लेती है। इंसानी समीक्षक बिज़नेस नियमों, डिज़ाइन और खतरों की समझ साथ लाते हैं, और यहीं पर कई गंभीर बग छिपे होते हैं।
क्या अपने कोड को किसी AI समीक्षक के पास भेजना सुरक्षित है?
केवल तभी जब वह टूल आपके कोड के लिए स्वीकृत (approved) हो। कोड में secrets और बिज़नेस लॉजिक हो सकते हैं। जाँचें कि कोड कहाँ भेजा जा रहा है, क्या उसे स्टोर किया जा रहा है, और क्या उसका उपयोग ट्रेनिंग के लिए किया जा रहा है।
Authorisation बग्स को पकड़ना AI के लिए मुश्किल क्यों होता है?
कोड देखने में बिल्कुल सामान्य लग सकता है। बग यह होता है कि कोई यूज़र किसी दूसरे की चीज़ देख सकता है या बदल सकता है, और केवल वही व्यक्ति जिसे नियम पता हैं ("एक ग्राहक केवल अपने खुद के ऑर्डर देख सकता है") यह बता सकता है कि कोई जाँच छूट गई है।
अगर AI समीक्षक बहुत ज़्यादा टिप्पणियाँ करने लगे तो क्या करें?
इसे सुरक्षा से जुड़े मुद्दों पर ध्यान केंद्रित करने के लिए ट्यून करें, और ट्रैक करें कि डेवलपर्स किन टिप्पणियों को स्वीकार करते हैं। अगर ज़्यादातर टिप्पणियों को नज़रअंदाज़ कर दिया जाता है, तो लोग उन्हें पढ़ना बंद कर देते हैं, और असली समस्याएँ छूट जाती हैं।
पाठ का टेस्ट
5 सवाल। पास होने और इस पाठ को पूरा करने के लिए 3 सही होने चाहिए (60%)।