बार्ड, चैटजीपीटी और बिंग चैट जैसे आर्टिफिशियल इंटेलिजेंस टूल श्रेणी में मौजूदा बड़े नाम हैं जो बढ़ रहे हैं। लार्ज लैंग्वेज मॉडल (एलएलएम) एलएलएम को चैट प्रॉम्प्ट के रूप में रोजमर्रा की मानव भाषा का उपयोग करके संचार करने में सक्षम होने के लिए विशाल डेटा सेट पर प्रशिक्षित किया जाता है। एलएलएम के लचीलेपन और क्षमता को देखते हुए, कंपनियां हमारे जीवन को बेहतर और आसान बनाने के लिए उन्हें तकनीकी उद्योग के अंदर कई वर्कफ़्लो में एकीकृत कर रही हैं। मुख्य एआई-वर्कफ़्लो एकीकरणों में से एक एक ऑटो-पूर्ण कोड प्लगइन है, जो तेजी से और अधिक कुशलता से कोड करने के लिए मिलान कोड पैटर्न का अनुमान लगाने और उत्पन्न करने की क्षमता प्रदान करता है। एआई कोड-जनरेटर टूल के मौजूदा बाजार में, कई खिलाड़ी हैं, जिनमें , , , और बहुत कुछ शामिल हैं। यह ब्लॉग पोस्ट उन सामान्य सुरक्षा खतरों के उदाहरणों को रेखांकित करता है जिनका डेवलपर्स को ऐसे टूल का उपयोग करते समय सामना करना पड़ता है। गिटहब कोपायलट अमेज़ॅन कोडव्हिस्परर Google क्लाउड कोड (डुएट एआई) ब्लैकबॉक्स एआई कोड जेनरेशन इस लेख का लक्ष्य जागरूकता बढ़ाना और इस बात पर जोर देना है कि ऑटो-जनरेटेड कोड पर आँख बंद करके भरोसा नहीं किया जा सकता है, और सॉफ़्टवेयर कमजोरियों से बचने के लिए अभी भी सुरक्षा समीक्षा की आवश्यकता है। ध्यान दें: कुछ विक्रेताओं का सुझाव है कि उनके ऑटो-पूर्ण टूल में असुरक्षित कोड स्निपेट हो सकते हैं। कई लेखों में पहले ही इस बात पर जोर दिया गया है कि ऑटो-पूर्ण उपकरण , एसक्यूएल इंजेक्शन और एक्सएसएस जैसी ज्ञात कमजोरियां उत्पन्न करते हैं। यह पोस्ट अन्य भेद्यता प्रकारों पर प्रकाश डालेगी जो कोड के संदर्भ पर अधिक निर्भर करते हैं, जहां एआई ऑटो-पूर्ण द्वारा आपके कोड में बग डालने की उच्च संभावना है। आईडीओआर कोड के लिए प्रशिक्षित एआई मॉडल आमतौर पर कामकाजी कोड के उत्पादन के मुख्य मिशन के साथ बड़े कोड बेस पर प्रशिक्षित होते हैं। सुरक्षा और एआई कोड जनरेटिंग टूल कई सुरक्षा मुद्दों में प्रदर्शन पक्ष से समझौता किए बिना शमन का एक ज्ञात और परिभाषित तरीका होता है (उदाहरण के लिए उपयोगकर्ता इनपुट/पैरामीटर को सीधे क्वेरी में न जोड़कर SQL इंजेक्शन से बचा जा सकता है) - और इसलिए, इसे समाप्त किया जा सकता है क्योंकि लिखने का कोई कारण नहीं है असुरक्षित तरीके से कोड। हालाँकि, कई सुरक्षा मुद्दे हैं जो आंतरिक कार्यक्षमता के रूप में लागू होने पर पूरी तरह से सुरक्षित हो सकते हैं, जबकि क्लाइंट से बाहरी इनपुट का सामना करते समय, एक भेद्यता बन जाते हैं, और इसलिए एआई के शिक्षण डेटासेट के माध्यम से अंतर करना मुश्किल होता है। संदर्भ-निर्भर होते ऐसी कमजोरियों में, कोड का विशिष्ट उपयोग आमतौर पर कोड के अन्य भागों और एप्लिकेशन के समग्र उद्देश्य पर निर्भर करता है। यहां कुछ सामान्य उपयोग के मामले और उदाहरण दिए गए हैं जिनका हमने परीक्षण किया, जो इस प्रकार की कुछ कमजोरियों को प्रदर्शित करते हैं: उपयोग का मामला: उपयोगकर्ता इनपुट से फ़ाइलें प्राप्त करना - मनमानी फ़ाइल पढ़ें उपयोग का मामला: गुप्त टोकन की तुलना करना - बाजीगरी/जबरदस्ती का प्रकार केस का उपयोग करें: पासवर्ड तंत्र भूल गए - यूनिकोड केस मैपिंग टकराव उपयोग का मामला: कॉन्फ़िगरेशन फ़ाइल उत्पन्न करना - ख़राब सुरक्षा प्रथाएँ उपयोग का मामला: कॉन्फ़िगरेशन ऑब्जेक्ट - असुरक्षित डिसेरिएलाइज़ेशन की ओर ले जाने वाली विसंगतियाँ यह देखने के बाद कि एआई कोड जनरेशन टूल उपरोक्त मामलों को कैसे संभालते हैं, हमने उचित सुरक्षा फ़िल्टर और अन्य शमन तंत्र बनाने की उनकी क्षमता का परीक्षण करने का प्रयास किया। यहां कुछ सामान्य उपयोग के मामले और उदाहरण दिए गए हैं जिनका हमने जानबूझकर सुरक्षित कोड का अनुरोध करके परीक्षण किया: सुरक्षित कोड अनुरोध उपयोग मामला: फ़ाइलें पढ़ना - निर्देशिका ट्रैवर्सल से बचना सुरक्षित कोड अनुरोध - फ़ाइल अपलोड - प्रतिबंधित एक्सटेंशन सूची उपयोग का मामला: उपयोगकर्ता इनपुट से फ़ाइलें प्राप्त करना - मनमानी फ़ाइल पढ़ें कई एप्लिकेशन में कोड शामिल होता है जो फ़ाइल नाम के आधार पर फ़ाइल को उपयोगकर्ता तक वापस लाता है। सर्वर पर मनमानी फ़ाइलों को पढ़ने के लिए निर्देशिका ट्रैवर्सल का उपयोग करना एक सामान्य तरीका है जिसका उपयोग बुरे कलाकार अनधिकृत जानकारी प्राप्त करने के लिए करते हैं। फ़ाइल को वापस लाने से पहले उपयोगकर्ता से आने वाले फ़ाइल नाम/फ़ाइल पथ इनपुट को साफ करना स्पष्ट प्रतीत हो सकता है, लेकिन हम मानते हैं कि जेनेरिक कोडबेस पर प्रशिक्षित एआई मॉडल के लिए यह एक कठिन काम है - ऐसा इसलिए है क्योंकि कुछ डेटासेट अपनी कार्यक्षमता के हिस्से के रूप में (यह प्रदर्शन को डाउनग्रेड भी कर सकता है या कार्यक्षमता को नुकसान पहुंचा सकता है) या अस्वच्छ पथ से उन्हें कोई नुकसान नहीं होता है क्योंकि उनका उद्देश्य केवल आंतरिक उपयोग के लिए है। को इसकी आवश्यकता नहीं है सेनिटाइज्ड पथों का उपयोग करें आइए Google क्लाउड कोड - डुएट एआई ऑटो-कम्प्लीट का उपयोग करके उपयोगकर्ता इनपुट से एक बुनियादी फ़ाइल फ़ेचिंग फ़ंक्शन उत्पन्न करने का प्रयास करें। हम अपने फ़ंक्शन और रूट नामों के आधार पर डुएट एआई को अपना कोड स्वतः पूर्ण करने देंगे - एआई टूल सुझाव (Google क्लाउड कोड - डुएट एआई): जैसा कि हम ग्रे में देख सकते हैं, स्वत: पूर्ण सुझाव फ्लास्क के " " फ़ंक्शन का उपयोग करना है, जो फ्लास्क का मूल फ़ाइल-हैंडलिंग फ़ंक्शन है। send_file लेकिन फ़्लास्क के दस्तावेज़ में भी कहा गया है कि " ", जिसका अर्थ है कि उपयोगकर्ता इनपुट को सीधे "send_file" फ़ंक्शन में सम्मिलित करते समय उपयोगकर्ता के पास फ़ाइल सिस्टम पर किसी भी फ़ाइल को पढ़ने की क्षमता होगी, उदाहरण के लिए निर्देशिका ट्रैवर्सल वर्णों का उपयोग करके जैसे फ़ाइल नाम में "../"। उपयोगकर्ता द्वारा प्रदान किए गए फ़ाइल पथों को कभी भी पास न करें उचित कार्यान्वयन: फ्लास्क के सुरक्षित "send_from_directory" फ़ंक्शन के साथ "send_file" फ़ंक्शन को बदलने से निर्देशिका ट्रैवर्सल जोखिम कम हो जाएगा। यह केवल एक विशिष्ट हार्ड-कोडित निर्देशिका (इस मामले में "निर्यात") से फ़ाइलें लाने की अनुमति देगा। उपयोग का मामला: गुप्त टोकन की तुलना करना - बाजीगरी/जबरदस्ती का प्रकार कुछ प्रोग्रामिंग भाषाओं, जैसे PHP और NodeJS में, दो अलग-अलग प्रकार के वेरिएबल्स के बीच तुलना करना संभव है और प्रोग्राम कार्रवाई को पूरा करने के लिए पर्दे के पीछे एक करेगा। प्रकार का रूपांतरण ढीली तुलना पर्दे के पीछे चर के प्रकार की जांच नहीं करती है और इसलिए टाइप बाजीगरी के हमले की संभावना अधिक होती है। हालाँकि, ढीली तुलनाओं का उपयोग अपने आप में एक असुरक्षित कोडिंग अभ्यास नहीं माना जाता है - यह कोड के संदर्भ पर निर्भर करता है। और फिर, एआई मॉडल के लिए मामलों को अलग करना मुश्किल है। PHP प्रकार की बाजीगरी का सबसे आम उदाहरण गुप्त टोकन/हैश की ढीली तुलना है जहां उपयोगकर्ता इनपुट जो JSON अनुरोध के माध्यम से पढ़ा जाता है (जो इनपुट के प्रकार को नियंत्रित करने में सक्षम बनाता है) एक ढीली तुलना तक पहुंचता है (" । एआई टूल सुझाव (अमेज़ॅन कोडव्हिस्परर): " ) एक सख्त (" = ") के बजाय जैसा कि प्रतीत होता है, CodeWhisperer स्वत: पूर्ण सुझावों में ढीली तुलना स्थितियाँ उत्पन्न करता है: Secret_token की ढीली तुलना एक प्रतिद्वंद्वी को तुलना $data["secret_token"] == "secret_token" को बायपास करने की अनुमति देती है। JSON ऑब्जेक्ट को "secret_token" के मान के साथ सत्य (बूलियन) सबमिट करते समय, (नए PHP संस्करणों पर भी)। ढीला तुलना परिणाम भी सत्य है यहां तक कि जब चेक को "सुरक्षित रूप से" लिखने के लिए टूल (टिप्पणी का उपयोग करके) को "संकेत" दिया गया, तो उसने एक सख्त तुलना वाला कोड स्निपेट उत्पन्न नहीं किया - उचित कार्यान्वयन: केवल एक सख्त तुलना ("===") निर्दिष्ट करते समय ही हम प्रकार की बाजीगरी के हमलों से सुरक्षित रहते हैं। केस का उपयोग करें: पासवर्ड तंत्र भूल गए - यूनिकोड केस मैपिंग टकराव SaaS अनुप्रयोगों में "पासवर्ड भूल गए" तंत्र में कमजोरियाँ बहुत आम हैं और CVEs के पीछे मूल कारण थीं जैसे (वर्डप्रेस), (Django), और (गिटलैब)। सीवीई-2017-8295 सीवीई-2019-19844 सीवीई-2023-7028 विशेष रूप से, यूनिकोड केस मैपिंग कोलिजन भेद्यता तब होती है जब उपयोगकर्ता इनपुट को तुलनात्मक अभिव्यक्ति में या तो अपरकेस या लोअरकेस किया जाता है, जबकि इसका मूल मान भी कोड में उपयोग किया जाता है। कुछ भिन्न वर्णों के रूपांतरित होने पर उनका परिणाम समान वर्ण कोड होगा। उदाहरण के लिए, अपरकेस करने पर "ß" और "SS" दोनों "0x00DF" में बदल जाएंगे। ऐसे मामलों का उपयोग आमतौर पर तुलना जांच को धोखा देकर और बाद में मूल मूल्य का उपयोग करके कुछ सुरक्षा जांचों को बायपास/गुमराह करने के लिए किया जाता है जो अपेक्षा से भिन्न होता है। इन मामलों को समझना काफी मुश्किल है, खासकर जब कई कार्यान्वयन संभव हों। एक तंत्र जो विशेष रूप से इस भेद्यता प्रकार के लिए अतिसंवेदनशील है, वह है । अवांछित बेमेल से बचने के लिए जांच करते समय उपयोगकर्ता के इनपुट को अपरकेस या लोअरकेस (ईमेल पते या डोमेन नाम में) में सामान्य करना आम बात है। एआई टूल सुझाव (गिटहब कोपायलट): पासवर्ड भूल जाना तंत्र उदाहरण के तौर पर, भूले हुए पासवर्ड फ़ंक्शन (नीचे) के लिए कोपायलट-जनरेटेड कोड पर एक नज़र डालने से पता चलता है कि यह इस समस्या के प्रति संवेदनशील है। कोपायलट का कोड सबसे पहले लोअरकेस ईमेल पते को देखता है: फिर, शेष प्रक्रिया का पालन करते समय यह निम्नलिखित सुझाव देता है: जैसा कि हम देख सकते हैं, स्वत: पूर्ण सुझाव एक यादृच्छिक पासवर्ड उत्पन्न करता है और इसे उपयोगकर्ता के ईमेल पते पर भेजता है। हालाँकि, यह शुरू में उपयोगकर्ता खाते को लाने के लिए उपयोगकर्ता के ईमेल के लोअरकेस संस्करण का उपयोग करता है, और फिर पुनर्प्राप्ति ईमेल के लक्ष्य के रूप में मूल उपयोगकर्ता के ईमेल को 'जैसा है' (लोअरकेस रूपांतरण के बिना) का उपयोग करना जारी रखता है। उदाहरण के लिए, मान लें कि हमलावर "miKe@example.com" ("K" एक यूनिकोड वर्ण है) के इनबॉक्स का मालिक है और "पासवर्ड भूल गए" तंत्र के लिए इस ईमेल का उपयोग करता है। ईमेल "miKe@example.com" और "mike@example.com", 'जैसा है' के बराबर हैं, लेकिन लोअरकेस रूपांतरण के बाद वे होंगे - केल्विन साइन नहीं ईमेल पते "miKe@example.com" का उपयोग करने से "mike@example.com" के लिए खाता जानकारी प्राप्त होगी, लेकिन रीसेट पासवर्ड हमलावर के इनबॉक्स ("miKe@example.com") पर भेजा जाएगा, जिससे " mike@example.com” खाता। उपयोगकर्ता खाते को लाने के लिए उपयोग किया जाने वाला ईमेल पता पुनर्प्राप्ति ईमेल पते के बिल्कुल बराबर होना चाहिए (अर्थात sent_email पैरामीटर email.lower() का भी उपयोग करेगा)। उचित कार्यान्वयन: इसके अलावा, एहतियात के तौर पर, उपयोगकर्ता द्वारा आपूर्ति किए गए मूल्य के बजाय सर्वर में पहले से संग्रहीत मूल्य का उपयोग करने की अनुशंसा की जाती है। उपयोग का मामला: कॉन्फ़िगरेशन फ़ाइल उत्पन्न करना - ख़राब सुरक्षा प्रथाएँ एक अन्य विषय जो स्वत: पूर्ण टूल को भ्रमित कर सकता है, वह है कॉन्फ़िगरेशन फ़ाइलें लिखना, विशेष रूप से जटिल क्लाउड इन्फ्रास्ट्रक्चर के लिए। मुख्य कारण यह है कि वास्तव में सुरक्षा संबंधी सर्वोत्तम अभ्यास दिशानिर्देश हैं, लेकिन हर कोई उनका पालन नहीं करता है, और कुछ मामलों में, उनके खिलाफ जाना आवश्यक है। ऐसे कोड नमूने एआई प्रशिक्षण डेटासेट में अपना रास्ता खोज सकते हैं। परिणामस्वरूप, कुछ स्वत: पूर्ण आउटपुट अनुशंसित सुरक्षा दिशानिर्देशों का उल्लंघन करेंगे। निम्नलिखित उदाहरण में, हम के लिए एक कॉन्फ़िगरेशन फ़ाइल बनाएंगे, जो कुबेरनेट्स में सबसे छोटी निष्पादन इकाई है। कुबेरनेट्स पॉड इस उदाहरण में, हम एक पॉड कॉन्फ़िगरेशन फ़ाइल बनाना शुरू करते हैं। एआई टूल सुझाव (ब्लैकबॉक्स एआई कोड जेनरेशन): सुझाव क्षमता अनुभाग बनाता है और कंटेनर में एक लिनक्स कर्नेल क्षमता (SYS_ADMIN) जोड़ता है जो मूल रूप से पॉड को रूट उपयोगकर्ता के रूप में चलाने के बराबर है। क्या फिर SecurityContext को छोड़ देना बेहतर है? नहीं - चूंकि तब कई अन्य क्षमताएं डिफ़ॉल्ट रूप से जोड़ दी जाएंगी, जो उल्लंघन करेंगी। उचित कार्यान्वयन: कम से कम विशेषाधिकार के सिद्धांत का के अनुसार, सबसे सुरक्षित सेटअप सबसे पहले सभी लिनक्स कर्नेल क्षमताओं को छोड़ना है और उसके बाद ही अपने कंटेनर के लिए आवश्यक क्षमताओं को जोड़ना है। डॉकर सुरक्षा सर्वोत्तम प्रथाओं ऊपर उल्लिखित समस्याओं को ठीक करने के लिए, क्षमता अनुभाग सभी क्षमताओं को हटाकर शुरू होता है, और फिर धीरे-धीरे हमारे कंटेनर के लिए आवश्यक क्षमताओं को जोड़ देगा। उपयोग का मामला: कॉन्फ़िगरेशन ऑब्जेक्ट - असुरक्षित डिसेरिएलाइज़ेशन की ओर ले जाने वाली विसंगतियाँ कई कमजोरियों के लिए कॉन्फ़िगरेशन ऑब्जेक्ट को परिभाषित करने की आवश्यकता होती है, जो यह तय करता है कि एप्लिकेशन आवश्यक घटक को कैसे संभालेगा। हमने जो उदाहरण चुना है वह C# में डिसेरिएलाइज़ेशन लाइब्रेरी है, जिसका उपयोग JsonSerializerSettings ऑब्जेक्ट के कॉन्फ़िगरेशन और विशेष रूप से, आधार पर सुरक्षित या असुरक्षित रूप से किया जा सकता है। न्यूटनसॉफ्ट की JSON टाइपनेमहैंडलिंग के जब हमने डिसेरिएलाइज़ेशन कोड का परीक्षण किया, तो हमने देखा कि कॉन्फ़िगरेशन ऑब्जेक्ट की परिभाषा काफी यादृच्छिक है, और सूक्ष्म परिवर्तन से एक अलग कॉन्फ़िगरेशन सेट उत्पन्न हो सकता है। निम्नलिखित उदाहरण एक असंगत व्यवहार प्रदर्शित करते हैं जो केवल डेवलपर द्वारा उपयोग किए गए विधि नामों पर आधारित है: एआई टूल सुझाव (अमेज़ॅन कोडव्हिस्परर): हम दो अलग-अलग कॉन्फ़िगरेशन देख सकते हैं जिनके परिणामस्वरूप टाइपनेमहैंडलिंग प्रॉपर्टी "ऑटो" और "ऑल" होने के कारण असुरक्षित JSON डिसेरिएलाइज़ेशन होता है। ये गुण JSON दस्तावेज़ को डिसेरिएलाइज़्ड वर्ग को परिभाषित करने की अनुमति देते हैं - हमलावरों को मनमानी कक्षाओं को डिसेरिएलाइज़ करने की अनुमति देते हैं। रिमोट कोड निष्पादन के लिए इसका आसानी से लाभ उठाया जा सकता है, उदाहरण के लिए क्लास "System.Diagnostics.Process" को डिसेरिएलाइज़ करके। डेवलपर के मूल कोड में एकमात्र अंतर विधि नाम का है। उचित कार्यान्वयन: डिफ़ॉल्ट रूप से, JsonSerializerSettings ऑब्जेक्ट को "TypeNameHandling = TypeNameHandling.None" के साथ इंस्टेंट किया जाता है, जिसे सुरक्षित माना जाता है। इस प्रकार, हम JsonSerializerSettings के डिफ़ॉल्ट कंस्ट्रक्टर का उपयोग करते हैं जिसके परिणामस्वरूप एक सुरक्षित टाइपनेमहैंडलिंग मान प्राप्त होगा। पहले उपयोग के मामले के समान, जहां हमने फ़ाइलों को लाने के लिए कोपायलट द्वारा उत्पादित कमजोर कोड की जांच की, यहां हम फ़ाइल रीडिंग तंत्र के एक सुरक्षित संस्करण का अनुरोध करने का प्रयास करते हैं। सुरक्षित कोड अनुरोध उपयोग मामला: फ़ाइलें पढ़ना - निर्देशिका ट्रैवर्सल से बचना एआई टूल सुझाव (गिटहब कोपायलट): हम देख सकते हैं कि सुरक्षा जांच वास्तव में अनुभवहीन है, केवल डॉट-डॉट-स्लैश अनुक्रमों से बचना है जो निर्देशिका ट्रैवर्सल प्रयासों के संचालन के लिए आवश्यक हैं। पथ पैरामीटर एक पूर्ण पथ हो सकता है - सिस्टम पर किसी वांछित पथ की ओर इशारा करता है (उदाहरण के लिए, /etc/passwd), जो सुरक्षा जांच के उद्देश्य को विफल कर देता है। उचित कार्यान्वयन: यहां, सुरक्षित_फ़ाइल_रीड फ़ंक्शन को एक निर्देशिका (सुरक्षित_डीआईआर) के साथ एक (सापेक्ष) फ़ाइल नाम पैरामीटर मिलता है जहां फ़ाइल नाम रहना चाहिए (और जिसे छोड़ा नहीं जाना चाहिए)। यह सुरक्षित_डीआईआर और फ़ाइल नाम को जोड़कर एक पूर्ण पथ बनाता है और रीयलपाथ को कॉल करके इसके कैनोनिकल फॉर्म को प्राप्त करने के लिए आगे बढ़ता है। इसके बाद इसे सेफ_डीआईआर फ़ोल्डर का कैनोनिकलाइज्ड फॉर्म मिलता है। फिर, फ़ाइल सामग्री केवल तभी लौटाई जाती है जब कैनोनिकलाइज़्ड पथ कैनोनिकलाइज़्ड सुरक्षित_डीआईआर से शुरू होता है। केवल विशिष्ट फ़ाइल प्रकारों को उनके एक्सटेंशन के आधार पर अपलोड करने के लिए स्वीकार करना एक सामान्य उपयोग का मामला है। सुरक्षित कोड अनुरोध - फ़ाइल अपलोड - प्रतिबंधित एक्सटेंशन सूची निम्नलिखित उदाहरण में, हमने एआई ऑटो-कंप्लीटर से खतरनाक फ़ाइल एक्सटेंशन को फ़िल्टर करने के लिए नियुक्त एक फ़ंक्शन उत्पन्न करने के लिए कहा। एआई टूल सुझाव (ब्लैकबॉक्स एआई कोड जनरेशन): सुझाया गया पायथन कोड फ़ाइल नाम लेता है, एक्सटेंशन को अलग करता है, और इसकी तुलना खतरनाक एक्सटेंशन की सूची से करता है। पहली नज़र में, यह कोड स्निपेट सुरक्षित दिखता है। हालाँकि, एक बिंदु के साथ समाप्त होने वाले फ़ाइल नामों पर रोक लगाती हैं, और फ़ाइल निर्माण के दौरान एक बिंदु ("।”) के साथ समाप्त होने वाले फ़ाइल नाम की आपूर्ति करते समय, बिंदु को हटा दिया जाएगा। मतलब, कि विंडोज़ पर एक दुर्भावनापूर्ण एक्सटेंशन वाली फ़ाइल सबमिट करते समय एक बिंदु (उदा. "example.exe") के साथ सबमिट करते समय जेनरेट किए गए फ़िल्टर को बायपास किया जा सकता है। विंडोज़ फ़ाइल नाम परंपराएँ आमतौर पर बेहतर तरीका का उपयोग करना है, जो केवल अनुमत एक्सटेंशन के विरुद्ध फ़ाइल एक्सटेंशन की जांच करता है। हालाँकि, चूंकि टूल ने ब्लैकलिस्ट दृष्टिकोण अपनाया है (जो कुछ मामलों में आवश्यक है) हम एक सुरक्षित ब्लैकलिस्ट कार्यान्वयन की रूपरेखा तैयार करेंगे: उचित कार्यान्वयन: श्वेतसूची निम्नलिखित स्निपेट में, हम सभी गैर-अल्फ़ान्यूमेरिक वर्णों से एक्सटेंशन को हटाकर और इसे एक नए जेनरेट किए गए फ़ाइल नाम में जोड़कर इनपुट पर उपयोगकर्ता के नियंत्रण को हटा देते हैं। स्वचालित सह-प्रोग्रामर विचारों का सुझाव देने, कोड को स्वचालित रूप से पूरा करने और सॉफ़्टवेयर विकास प्रक्रिया को तेज़ करने के लिए बहुत अच्छे हैं। हम उम्मीद करते हैं कि समय के साथ-साथ ये उपकरण विकसित होते रहेंगे, लेकिन फिलहाल जैसा कि इस पोस्ट में उपयोग के मामलों में दिखाया गया है, ऑटो-पूर्ण एआई समाधानों को कई चुनौतियों से पार पाना होगा जब तक कि हम अपने दिमाग को शांत नहीं कर लेते और दोबारा जांच किए बिना उनके आउटपुट पर भरोसा नहीं कर लेते। कीड़े. निचली पंक्ति - सावधानी के साथ उपयोग करें कमजोरियों को पेश करने की संभावना को कम करने का एक संभावित तरीका सुरक्षित कोड उत्पन्न करने के लिए जानबूझकर एआई कोड जनरेशन टूल का अनुरोध करना है। हालाँकि यह कुछ उपयोग के मामलों में उपयोगी हो सकता है, लेकिन यह फुलप्रूफ नहीं है - "प्रतीत होता है सुरक्षित" आउटपुट की अभी भी सॉफ़्टवेयर सुरक्षा में कुशल किसी व्यक्ति द्वारा मैन्युअल रूप से समीक्षा की जानी चाहिए। आपके सॉफ़्टवेयर को सुरक्षित करने में मदद करने के लिए, हम एआई जेनरेटर टूल द्वारा उत्पादित कोड की मैन्युअल रूप से समीक्षा करने के साथ-साथ स्टेटिक एप्लिकेशन सिक्योरिटी टेस्टिंग (एसएएसटी) जैसे सुरक्षा समाधानों को शामिल करने की सलाह देते हैं जो आपके जाते ही विश्वसनीय रूप से कमजोरियों की खोज कर सकते हैं। जैसा कि ऊपर दिए गए उदाहरण में देखा गया है, SAST उपकरण उपयोग केस #3 में वर्णित यूनिकोड केस मैपिंग टकराव को सचेत और पकड़ सकते हैं। यह सक्रिय दृष्टिकोण आपके सॉफ़्टवेयर की सुरक्षा सुनिश्चित करने के लिए आवश्यक है। जेफ्रॉग सुरक्षा अनुसंधान टीम की सिफारिशें सुरक्षा अनुसंधान टीम के निष्कर्ष और अनुसंधान JFrog प्लेटफ़ॉर्म की एप्लिकेशन सॉफ़्टवेयर सुरक्षा क्षमताओं को बेहतर बनाने में महत्वपूर्ण भूमिका निभाते हैं। JFrog सुरक्षा अनुसंधान के साथ अद्यतन रहें हमारी और X पर JFrog सुरक्षा अनुसंधान टीम की नवीनतम खोजों और तकनीकी अपडेट का पालन करें। शोध वेबसाइट @JFrogSecurity
