diff --git a/1_1_vulns/translations/hi/LLM00_Introduction.md b/1_1_vulns/translations/hi/LLM00_Introduction.md new file mode 100644 index 00000000..983a40e6 --- /dev/null +++ b/1_1_vulns/translations/hi/LLM00_Introduction.md @@ -0,0 +1,92 @@ + +## परिचय + +### सूची की उत्पत्ति +2022 के अंत में बड़े पैमाने पर बाजार में पूर्व-प्रशिक्षित चैटबॉट्स जारी होने के बाद, बड़े भाषा मॉडल (LLM) में दिलचस्पी उल्लेखनीय है। व्यवसाय, LLM की क्षमता के प्रयोक के लिए उत्सुक हैं,वह तेजी से उन्हें अपने संचालन तथा ग्राहक-समाधान वाली पेशकशों में एकीकृत कर रहे हैं। फिर भी, जिस ख़तरनाक गति से डेवेलोपमेंट दल LLM को अपना रहे है, उसने व्यापक सुरक्षा प्रोटोकॉल की संरचना को पीछे छोड़ दिया है, जिससे ऍप्लिकेशन्स क्षेत्र में कई उच्च जोखिम वाले मुद्दों की संवेदनशीलता बढ़ गयी हैं। + +LLM में इन सुरक्षा संबंधी दिक्कतों को संबोधित करने वाले एकीकृत संसाधन का अभाव स्पष्ट है । डेवलपर्स, LLM से जुड़े विशिष्ट जोखिमों को नहीं जानते, उनके पास बिखरे हुए संसाधन है और OWASP का मिशन इस तकनीक को सुरक्षित रूप से अपनाने में मदद करने के लिए बिल्कुल उपयुक्त है । + +### दर्शक कौन हैं? + +हमारे प्राथमिक दर्शक डेवलपर्स, डेटा वैज्ञानिक और सुरक्षा विशेषज्ञ हैं जिन्हें LLM का लाभ उठाने वाले ऍप्लिकेशन्स एवं प्लग-इन का प्रारूप बनाना तथा निर्माण का काम सौंपा गया है। हमारा लक्ष्य इन पेशेवरों को LLM एप्लीकेशन सुरक्षा के जटिल और विकसित होते इलाके में मदद करने के लिए व्यावहारिक, कार्रवाई योग्य और संक्षिप्त सुरक्षित मार्गदर्शन प्रदान करना है। + +### सूची का निर्माण + +“OWASP टॉप 10 फॉर LLMs” सूची का निर्माण एक महत्वपूर्ण प्रयास है, जिसमें लगभग 125 से अधिक सक्रिय योगदानकर्ताओं के साथ लगभग 500 विशेषज्ञों की एक अंतरराष्ट्रीय टीम का सहयोग है। हमारे योगदानकर्ता विविध पृष्ठभूमियों से है, जिनमें AI कंपनियाँ, सुरक्षा कंपनियाँ, ISV, क्लाउड हाइपरस्केलर, हार्डवेयर प्रदाता एवं शिक्षण संस्थान शामिल है। +एक महीने के दौरान, हमने विचार-मंथन किया और संभावित कमजोरियों का प्रस्ताव रखा, जिसमें टीम के सदस्यों ने 43 अलग-अलग खतरों के बारे में लिखा। मतदान के कई दौरों के माध्यम से, हमने इन प्रस्तावों को 10 सबसे महत्वपूर्ण कमजोरियों की एक संक्षिप्त सूची में ढ़ाला गया हैं। प्रत्येक भेद्यता की फिर समर्पित उप-टीमों द्वारा आगे जांच और परिष्कृत की गई और सार्वजनिक समीक्षा के अधीन की गई, जिससे सबसे व्यापक और कार्रवाई योग्य अंतिम सूची सुनिश्चित हुई। +हर एक जोखिम, सामान्य उदाहरणों, रोकथाम सुझावों, हमले के परिदृश्यों और संदर्भों के साथ, उप-टीमों द्वारा और उन्हें सार्वजनिक समीक्षा के अधीन और सबसे संपूर्ण और प्रायोज्य अंतिम सूची के रूप में और भी विचार किए गए थे। + +### अन्य OWASP टॉप 10 सूचियों से संबंध + +हालांकि हमारी सूची में अन्य OWASP टॉप 10 सूचियों में पाई जाने वाली जोखिम प्रकारों के साथ समानता रहती है, हम बस इन जोखिमों को दोहराते नहीं हैं। इसके बजाए, हम उन कमजोरियों पर ध्यान देते हैं, जो LLM वाली ऍप्लिकेशन्स में सामने आती हैं। +हमारा लक्ष्य सामान्य अनुप्रयोग सुरक्षा सिद्धांतों और LLM द्वारा प्रस्तुत विशिष्ट चुनौतियों के बीच की भिन्नता को कम करना है। इसमें शामिल है कि कैसे सांप्रदायिक जोखिमों के भीतर LLMs का उपयोग करने वाले अनुप्रयोगों में विभिन्न खतरे उत्पन्न कर सकते हैं या नई तरीकों से उपयोग किए जा सकते हैं, और कैसे पारंपरिक उपचार रणनीतियों को LLMs का उपयोग करने वाले अनुप्रयोगों के लिए अनुकूलित किया जाना चाहिए। + +### संस्करण के बारे में + +यह पहला संस्करण सूची हमारा आखिरी नहीं होगा। हम उम्मीद करते हैं कि हम इसे नियमित अंतराल पर अपडेट करेंगे ताकि उद्योग की स्थिति के साथ कदम से कदम मिला कर चल सकें। हम विश्वसनीय समुदाय के साथ मिलकर काम करेंगे ताकि तकनीक की दुनिया में नवाचार को बढ़ावा मिल सके, और विभिन्न उपयोगों के लिए और अधिक शैक्षिक सामग्री बना सकें। हम यह भी प्राथमिकता देंगे कि AI सुरक्षा के विषय में मानक संगठनों और सरकारों के साथ सहयोग करें। हम आपका स्वागत करते हैं हमारे समूह में शामिल होने और योगदान करने के लिए। + + + +### Sobre a Versão 1.1 + + +### Steve Wilson +परियोजना का नेतृत्व, OWASP टॉप 10 फॉर LLM एप्लिकेशंस +[https://www.linkedin.com/in/wilsonsd](https://www.linkedin.com/in/wilsonsd/) +Twitter/X: @virtualsteve + +### Ads Dawson +v1.1 ,रिलीज़ एवं कमजोरिया सूचीबद्ध लीड, OWASP टॉप 10 फॉर LLM एप्लिकेशंस +[https://www.linkedin.com/in/adamdawson0](https://www.linkedin.com/in/adamdawson0/) +GitHub：@GangGreenTemperTatum + + +## इस अनुवाद के बारे में +### संस्करण 1.1 हिंदी अनुवाद योगदानकर्ता + +- Rachit Sood +[https://www.linkedin.com/in/sn4kecharmer](https://www.linkedin.com/in/sn4kecharmer/) +- Dhruv Agarwal +[https://in.linkedin.com/in/dhruwen](https://in.linkedin.com/in/dhruwen) +- Rishi Sharma +[https://www.linkedin.com/in/rishisharma064/](https://www.linkedin.com/in/rishisharma064/) + + +एलएलएम के लिए OWASP टॉप 10 फॉर LLM एप्लिकेशंस की असाधारण तकनीकी और महत्वपूर्ण प्रकृति को पहचानते हुए, हमने जानबूझकर इस अनुवाद के निर्माण में केवल मानव अनुवादकों को नियोजित करने के लिए चुना है। ऊपर सूचीबद्ध अनुवादकों के पास न केवल मूल सामग्री की गहरी समझ है, बल्कि आत्मविश्वास के साथ इस अनुवाद को सफल बनाने का प्रवाह भी है। + +Talesh Seeparsan +अनुवाद नेता, OWASP टॉप 10 फॉर LLM एप्लिकेशंस +[https://www.linkedin.com/in/talesh/](https://www.linkedin.com/in/talesh/) + + + +## OWASP टॉप 10 फॉर LLM एप्लिकेशंस +### LLM01: प्रांप्ट इंजेक्शन +इस तकनीक का उपयोग करके एक बड़े भाषा मॉडल (LLM) मे बनावटी इनपुट के माध्यम से हेराफेरी कि जाती है, जिससे कारण LLM अनचाहे काम करता हैं। सीधे इंजेक्शन सिस्टम संकेत को ओवरराइट करते हैं, जबकि अप्रत्यक्ष इंजेक्शन बाहरी स्रोतों से इनपुट्स मे हेराफेरी करते हैं। + +### LLM02: असुरक्षित आउटपुट हैंडलिंग +यह कमजोरी तब उत्पन्न होती है जब LLM के आउटपुट को बिना जांच के स्वीकार कर लिया जाता है, जिससे बैकएंड सिस्टम उजागर हो जाता है। दुरुपयोग के कारण XSS, CSRF, SSRF, विशेषाधिकार वृद्धि, या रिमोट कोड एक्सीक्यूशन जैसे गंभीर परिणाम हो सकते हैं। + +### LLM03: प्रशिक्षण डेटा में विषैलीकरण +ऐसा तब होता है जब LLM प्रशिक्षण डेटा के साथ छेड़छाड़ की जाती है, जिससे कमजोरियां या पूर्वाग्रह पैदा होते हैं जो सुरक्षा, प्रभावशीलता या नैतिक व्यवहार से समझौता करते हैं। स्रोतों में Common Crawl, WebText, OpenWebTex एवं पुस्तकें शामिल हैं। + +### LLM04: मॉडल सेवा की अस्वीकृति +हमलावर LLMs से ज्यादा संसाधन वाले काम करते हैं, जिससे सेवा में गिरावट तथा ज्यादा लागती हो जाती है। LLMs की अधिक संसाधन की प्रकृति और इनपुट्स की अनियमित्ता के कारण कमजोरिया बढ़ जाता है। + +### LLM05: आपूर्ति श्रृंखला की जोखिम +LLM एप्लिकेशन चक्र जीवनचक्र को कमजोर घटकों या सेवाओं द्वारा संक्रमित किया जा सकता है, जिससे सुरक्षा हमले हो सकते हैं। तीसरे पक्ष के डेटासेट, पूर्व-प्रशिक्षित मॉडल और plugins का उपयोग करने से कमजोरिया बढ़ सकती है। + +### LLM06: संवेदनशील जानकारी का व्यक्तिगत होना +LLM अनजाने में अपने जवाबो में गोपनीय डेटा प्रकट कर सकता हैं, जिससे अनाधिकृत डेटा तक पहुंच , गोपनीयता उल्लंघन और सुरक्षा उल्लंघन हो सकते हैं। इसे कम करने के लिए डेटा स्वच्छता और सख्त यूज़र नीतियों को लागू करने की आवशयकता है। + +### LLM07: असुरक्षित plugin डिज़ाइन +LLM plugins में असुरक्षित इनपुट और अपर्याप्त पहुँच नियंत्रण हो सकता है। एप्लिकेशन नियंत्रण की इस कमी के कारण उनका शोषण करना आसान हो जाता है और इसके परिणामस्वरूप रिमोट कोड जैसे परिणाम हो सकते हैं। + +### LLM08: अत्यधिक क्षमता +LLM आधारित सिस्टम अनचाहे परिणामों की ओर ले जाने वाली क्रियाएँ कर सकते हैं। समस्या LLM-आधारित प्रणालियों को दी गई अत्यधिक कार्यक्षमता, अनुमतियाँ या स्वायत्तता से उत्पन्न होती है। + +### LLM09: अत्यधिक निर्भरता +बिना निगरानी के LLMs पर अत्यधिक निर्भर रहने वाले सिस्टम या लोगों को LLMs द्वारा उत्पन्न गलत या अनुचित सामग्री के कारण गलत सूचना, गलत संचार, कानूनी मुद्दों और सुरक्षा कमजोरियों का सामना करना पड़ सकता है। + +### LLM10: मॉडल की चोरी +इसमें मालिकाना LLM मॉडल की अनधिकृत पहुंच, नकल या घुसपैठ शामिल है। इसका प्रभाव आर्थिक हानि, प्रतिस्पर्धी फायदे में कमी और संवेदनशील जानकारी तक हो सकती है। diff --git a/1_1_vulns/translations/hi/LLM01_PromptInjection.md b/1_1_vulns/translations/hi/LLM01_PromptInjection.md new file mode 100644 index 00000000..2b29151b --- /dev/null +++ b/1_1_vulns/translations/hi/LLM01_PromptInjection.md @@ -0,0 +1,55 @@ +## LLM01: प्रॉम्प्ट इंजेक्शन + +### विवरण + +प्रॉम्प्ट इंजेक्शन की कमजोरी तब प्रकट होती है जब कोई हमलावर, तैयार किए गए इनपुट के जरिए किसी बड़े भाषा मॉडल (LLM) में हेरफेर करता है, जिससे LLM अनजाने में ही हमलावर के इरादों को अंजाम दे देता है। यह सीधे सिस्टम प्रॉम्प्ट को “जेलब्रेक” करके या अप्रत्यक्ष रूप से हेरफेर किए गए बाहरी इनपुट के जरिए एक्सफ़िल्ट्रेशन, सोशल इंजीनियरिंग और अन्य समस्याएं उत्पन कर सकता है । + +- प्रत्यक्ष रूप से प्रॉम्प्ट इंजेक्शन को “जेलब्रेकिंग” के नाम से भी जाना जाता है। यह तब होता है ,जब कोई यूजर दुर्भावना से सिस्टम प्रॉम्प्ट को बदल देता है। इससे हमलावर LLM के असुरक्षित फ़ंक्शंस और डेटा स्टोर का प्रयोग करके बैकएंड सिस्टम का फ़ायदा उठा सकते हैं। +- अप्रत्यक्ष रूप से प्रॉम्प्ट इंजेक्शन तब होते हैं जब कोई LLM बाहरी स्रोतों से इनपुट स्वीकार करता है। यह इनपुट्स वेबसाइट या फ़ाइल के रूप मे होते है, जिन्हे हमलावर द्वारा नियंत्रित किया जा सकता है। हमलावर बाहरी सामग्री में एक प्रॉम्प्ट इंजेक्शन डाल सकता है, जिससे बातचीत के संदर्भ पर नियंत्रण किया जा सकता है। इससे LLM एक “भ्रमित सहायक” की तरह, हमलावर को LLM से जुड़े सिस्टम तथा यूजर के साथ हेरफेर करने की सहूलियत देता है। इसके अलावा, जब तक टेक्स्ट को LLM द्वारा पार्स किया जाता है, तब तक अप्रत्यक्ष प्रॉम्प्ट इंजेक्शन का मानव-दृश्य/पठनीय होना ज़रूरी नहीं है। + +एक सफल प्रॉम्प्ट इंजेक्शन हमले के परिणाम बहुत अलग हो सकते हैं - संवेदनशील जानकारी मांगने से लेकर सामान्य ऑपरेशन की आड़ में महत्वपूर्ण निर्णय लेने की प्रक्रियाओं को प्रभावित करने तक। + +विकसित हमलों में, किसी हानिकारक व्यक्तित्व की नकल करने या यूज़र की सेटिंग में मौजूद plugin के साथ इंटरैक्ट करने के लिए LLM में हेरफेर कि जा सकता है। इसकी वजह से संवेदनशील डेटा लीक हो सकता है, plugin का अनाधिकृत इस्तेमाल हो सकता है या सोशल इंजीनियरिंग हो सकती है। ऐसे मामलों में, खराब किया हुआ LLM मानक सुरक्षा उपायों को पार करते हुए हमलावर की मदद करता है और यूज़र को घुसपैठ की जानकारी से अनजान रखता है। इन उदाहरणों में, समझौता किया गया LLM प्रभावी रूप से हमलावर के लिए एक एजेंट के रूप में काम करता है, सामान्य सुरक्षा उपायों को ट्रिगर किए बिना या अंतिम यूज़र को घुसपैठ के बारे में सचेत किए बिना उनके उद्देश्यों को पूरा करता है। + +### कमज़ोरी के सामान्य उदाहरण + +1. एक दुर्भावनापूर्ण यूज़र LLM के लिए एक सीधा प्रॉम्प्ट इंजेक्शन तैयार करता है, जो उसे एप्लिकेशन निर्माता के सिस्टम संकेतों को अनदेखा करने और इसके बजाय एक ऐसा प्रॉम्प्ट चलाए जो निजी, खतरनाक, या किसी अन्य तरह से अवांछनीय जानकारी देता हो। +2. एक यूज़र एक LLM का इस्तेमाल करके उस वेबपेज का सारांश तैयार करता है जिसमें इनडायरेक्ट प्रॉम्प्ट इंजेक्शन होता है। इसके बाद LLM यूज़र से संवेदनशील जानकारी मांगता है और javascript या markdown के ज़रिये घुसपैठ करता है। +3. एक दुर्भावनापूर्ण यूज़र एक अप्रत्यक्ष प्रॉम्प्ट इंजेक्शन वाला बायोडाटा अपलोड करता है। दस्तावेज़ में निर्देशों के साथ एक प्रॉम्प्ट इंजेक्शन शामिल है ताकि LLM यूज़रओं को सूचित कर सके कि यह दस्तावेज़ एक उत्कृष्ट दस्तावेज़ है ,जैसे इस कार्य के लिये ये उत्कृष्ट व्यक्ति है। दस्तावेज़ को सारांशित करने के लिए एक आंतरिक यूज़र दस्तावेज़ को LLM के माध्यम से चलाता है। LLM का आउटपुट यह बताते हुए जानकारी देता है कि यह एक उत्कृष्ट दस्तावेज़ है। +4. यूज़र किसी ई-कॉमर्स साइट से जुड़े plugin को चालू करता है। किसी विज़िट की गई वेबसाइट पर डाला गया एक दुष्ट निर्देश इस plugin का फ़ायदा उठाता है, जिससे अनाधिकृत खरीदारी होती है। +5. किसी विज़िट की गई वेबसाइट पर एक दुष्ट निर्देश और सामग्री डाली जाती है, जो यूज़र को धोखा देने के लिए अन्य plugin का इस्तेमाल करती है। + +### बचाव एवं न्यूनीकरण तरीक़े + +LLM की प्रकृति के कारण प्रोम्प्ट इंजेक्शन की कमजोरियाँ संभव हैं, जो निर्देशों और बाहरी डेटा को एक दूसरे से अलग नहीं करते हैं। चूंकि LLM प्राकृतिक भाषा का इस्तेमाल करते हैं, इसलिए वे दोनों तरह के इनपुट को यूज़र द्वारा प्रदत्त मानते हैं। नतीजतन, LLM में कोई आसान रोकथाम नहीं है, लेकिन निम्नलिखित उपाय शीघ्र इंजेक्शन के प्रभाव को कम कर सकते हैं: + +1. बैकएंड सिस्टम तक LLM पहुंच पर विशेषाधिकार नियंत्रण लागू करें। Plugins, डेटा पहुंच और कार्य-स्तरीय अनुमतियों जैसी विस्तारयोग्य कार्यशाताओ के लिए LLM को अपने स्वयं के API टोकन प्रदान करें। LLM को उसके इच्छित संचालन के लिए आवश्यक न्यूनतम स्तर तक पहुंच तक सीमित करके कम से कम विशेषाधिकार के सिद्धांत का पालन करें। +2. विस्तारयोग्य कार्यक्षमताओ के लिए मानव को परिक्षण में रखे । विशेषाधिकार प्राप्त ऑपरेशन करते समय, जैसे कि ईमेल भेजना या हटाना, ऐप्लिकेशन के लिए यूज़र से मंज़ूरी लेनी होती है । यह यूज़र की जानकारी या सहमति के बिना, अप्रत्यक्ष रूप से प्रॉम्प्ट इंजेक्शन की ओर से कार्रवाई करने के अवसर को कम कर देगा। +3. बाहरी सामग्री को यूज़र के प्रॉम्प्ट से अलग करें।इसके साथ यह भी बताये की अविश्वसनीय सामग्री का इस्तेमाल कहाँ किया जा रहा है, जिससे यूज़र के संकेतों पर उनके प्रभाव को सीमित किया जा सके । उदाहरण के लिए, OpenAI API कॉल के लिए ChatML का इस्तेमाल करें, ताकि LLM को तुरंत इनपुट का स्रोत बताया जा सके। +4. LLM, बाहरी स्रोतों और विस्तारयोग्य कार्यक्षमताओ (जैसे, plugin या डाउनस्ट्रीम कार्य) के बीच विश्वास की सीमाएँ स्थापित करें। LLM को एक ना भरोसा करने योग्य यूज़र मानें और निर्णय लेने की प्रक्रियाओं पर अंतिम यूज़र नियंत्रण बनाए रखें। हालाँकि, एक गलत LLM अभी भी आपके ऐप्लिकेशन के API और यूज़र के बीच मध्यस्थ (मैन-इन-द-मिडिल) की तरह काम कर सकता है क्योंकि यह यूज़र को जानकारी दिखाने से पहले उसे छिपा सकता है या उसमें हेरफेर कर सकता है। यूज़र को मिलने वाली संभावित अविश्वसनीय प्रतिक्रियाओं को हाइलाइट करें। +5. यह जांचने के लिए कि यह अपेक्षा के अनुरूप है, समय-समय पर LLM इनपुट और आउटपुट की मैन्युअल रूप से निगरानी करें। हालांकि कोई शमन नहीं है, यह कमजोरियों का पता लगाने और उन्हें संबोधित करने के लिए आवश्यक डेटा प्रदान कर सकता है। + +### उदाहरण हमले के परिदृश्य + +1. एक हमलावर LLM-आधारित चैटबॉट पर सीधा प्रॉम्प्ट इंजेक्शन करता है। इंजेक्शन में "पिछले सभी निर्देशों को भूल जाओ" और निजी डेटा स्टोरों को क्वेरी करने और पैकेज की कमजोरियों और ईमेल भेजने के लिए बैकएंड फ़ंक्शन में आउटपुट सत्यापन की कमी का फायदा उठाने के लिए नए निर्देश शामिल हैं। इससे रिमोट कोड चलाया जाता है, जिसे अनधिकृत ऐक्सेस मिलता है और विशेषाधिकार भी बढ़ते हैं। +2. एक हमलावर वेबपेज में अप्रत्यक्ष रूप से प्रॉम्प्ट इंजेक्शन ड़ालता है, जिसमें LLM को यूज़र के पिछले निर्देशों की अवहेलना करने और यूज़र के ईमेल हटाने के लिए LLM plugin का इस्तेमाल करने का निर्देश दिया जाता है। जब यूज़र इस वेबपेज को संक्षेप में बताने के लिए LLM का इस्तेमाल करता है, तो LLM plugin यूज़र के ईमेल हटा देता है। +3. यूज़र एक LLM की मदद से एक ऐसे वेबपेज का सारांश तैयार करता है जिसमें अप्रत्यक्ष रूप से प्रॉम्प्ट इंजेक्शन होता है, ताकि यूज़र के पिछले निर्देशों की अवहेलना की जा सके। इसके बाद LLM यूज़र से संवेदनशील जानकारी मांगता है और डाले गए javascript तथा markdown के ज़रिये घुसपैठ करता है। +4. एक दुर्भावनापूर्ण यूज़र तुरंत इंजेक्शन लगाकर रिज्यूमे अपलोड करता है। बैकएंड यूज़र, रेज़्यूमे को संक्षेप में बताने के लिए LLM का उपयोग करता है और पूछता है कि क्या वह व्यक्ति एक अच्छा उम्मीदवार है। प्रॉम्प्ट इंजेक्शन की वजह से, असल में रेज़्यूमे में मौजूद सामग्री के बावजूद, LLM हाँ कहता है। +5. एक हमलावर सिस्टम प्रॉम्प्ट पर निर्भर मॉडल को संदेश भेजता की वह अपने पिछले निर्देशों की उपेक्षा करे और इसके बजाय अपने सिस्टम प्रॉम्प्ट को दोहराये। मॉडल मालिकाना प्रॉम्प्ट आउटपुट करता है,जिससे हमलावर इन निर्देश का कही ओर उपयोग कर सकता है, या और अधिक सूक्ष्म हमलों का निर्माण कर सकता हैं। + +### संदर्भ लिंक + +1. [Prompt injection attacks against GPT-3](https://simonwillison.net/2022/Sep/12/prompt-injection/) Simon Willison +2. [ChatGPT Plugin Vulnerabilities - Chat with Code](https://embracethered.com/blog/posts/2023/chatgpt-plugin-vulns-chat-with-code/): Embrace The Red +3. [ChatGPT Cross Plugin Request Forgery and Prompt Injection](https://embracethered.com/blog/posts/2023/chatgpt-cross-plugin-request-forgery-and-prompt-injection./): Embrace The Red +4. [Not what you’ve signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection](https://arxiv.org/pdf/2302.12173.pdf): Arxiv preprint +5. [Defending ChatGPT against Jailbreak Attack via Self-Reminder](https://www.researchsquare.com/article/rs-2873090/v1): Research Square +6. [Prompt Injection attack against LLM-integrated Applications](https://arxiv.org/abs/2306.05499): Arxiv preprint +7. [Inject My PDF: Prompt Injection for your Resume](https://kai-greshake.de/posts/inject-my-pdf/): Kai Greshake +8. [ChatML for OpenAI API Calls](https://github.com/openai/openai-python/blob/main/chatml.md): OpenAI Github +9. [Threat Modeling LLM Applications](http://aivillage.org/large%20language%20models/threat-modeling-llm/): AI Village +10. [AI Injections: Direct and Indirect Prompt Injections and Their Implications](https://embracethered.com/blog/posts/2023/ai-injections-direct-and-indirect-prompt-injection-basics/): Embrace The Red +11. [Reducing The Impact of Prompt Injection Attacks Through Design](https://research.kudelskisecurity.com/2023/05/25/reducing-the-impact-of-prompt-injection-attacks-through-design/): Kudelski Security +12. [Universal and Transferable Attacks on Aligned Language Models](https://llm-attacks.org/): LLM-Attacks.org +13. [Indirect prompt injection](https://kai-greshake.de/posts/llm-malware/): Kai Greshake +14. [Declassifying the Responsible Disclosure of the Prompt Injection Attack Vulnerability of GPT-3](https://www.preamble.com/prompt-injection-a-critical-vulnerability-in-the-gpt-3-transformer-and-how-we-can-begin-to-solve-it): Preamble; earliest disclosure of Prompt Injection diff --git a/1_1_vulns/translations/hi/LLM02_InsecureOutputHandling.md b/1_1_vulns/translations/hi/LLM02_InsecureOutputHandling.md new file mode 100644 index 00000000..a03c1e78 --- /dev/null +++ b/1_1_vulns/translations/hi/LLM02_InsecureOutputHandling.md @@ -0,0 +1,41 @@ +## LLM02: असुरक्षित आउटपुट हैंडलिंग + +### विवरण + +असुरक्षित तरिके से आउटपुट को संभालना एक ऐसी समस्या है, जो तब उत्पन्न होती है जब एक डाउनस्ट्रीम हिस्सा उचित जांच के बिना बड़े भाषा मॉडल (LLM) के आउटपुट को आँख बंद करके स्वीकार करता है, जैसे कि LLM आउटपुट को सीधे बैकएंड, विशेषाधिकार प्राप्त या क्लाइंट-साइड कार्य में पास करना। + +चूंकि LLM के द्वारा बानी सामग्री को शीघ्र इनपुट द्वारा नियंत्रित किया जा सकता है, यह व्यवहार यूज़रओं को अतिरिक्त कार्यक्षमता तक अप्रत्यक्ष पहुंच प्रदान करने के समान है। + +असुरक्षित आउटपुट हैंडलिंग के सफल शोषण के परिणामस्वरूप वेब ब्राउज़र में XSS और CSRF के साथ-साथ SSRF, विशेषाधिकार वृद्धि, या बैकएंड सिस्टम पर रिमोट कोड चलाना हो सकता है। + +निम्नलिखित स्थितियाँ इस दिक्कत के प्रभाव को बढ़ा सकती हैं: +- एप्लिकेशन अंतिम यूज़रओं के लिए निर्धारित सीमा से परे LLM विशेषाधिकार प्रदान करता है, जिससे विशेषाधिकारों में वृद्धि या रिमोट कोड चलाना सक्षम होता है। +- एप्लिकेशन बाहरी प्रॉम्प्ट इंजेक्शन हमलों के प्रति संवेदनशील है, जो किसी हमलावर को लक्षित यूज़र के वातावरण तक विशेषाधिकार प्राप्त पहुंच प्राप्त करने की अनुमति दे सकता है। +- तृतीय पक्ष प्लगइन्स इनपुट को पर्याप्त रूप से मान्य नहीं करते हैं। + +### कमज़ोरी के सामान्य उदाहरण + +1. LLM आउटपुट को सीधे सिस्टम शेल या समान फ़ंक्शन जैसे exec या eval में दर्ज किया जाता है, जिसके परिणामस्वरूप रिमोट कोड चलाना होता है। +2. JavaScript या Markdown LLM द्वारा तैयार किया जाता है और यूज़र को लौटा दिया जाता है। फिर ब्राउज़र द्वारा कोड की व्याख्या की जाती है, जिसके परिणामस्वरूप XSS होता है। + +### बचाव एवं न्यूनीकरण तरीक़े + +1. मॉडल को किसी अन्य यूज़र के समान मानें (शून्य-भरोसेमंद दृष्टिकोण) और मॉडल से बैकएंड फ़ंक्शंस में आने वाली प्रतिक्रियाओं पर उचित इनपुट सत्यापन लागू करें। +2. प्रभावी इनपुट सत्यापन और स्वच्छता सुनिश्चित करने के लिए OWASP ASVS (एप्लिकेशन सुरक्षा सत्यापन मानक) दिशानिर्देशों का पालन करें। +3. JavaScript या मार्कडाउन द्वारा अनचाहे कोड निष्पादन को कम करने के लिए मॉडल आउटपुट को यूज़रओं के पास वापस एन्कोड करें। OWASP ASVS आउटपुट एन्कोडिंग पर विस्तृत मार्गदर्शन प्रदान करता है। + +### उदाहरण हमले के परिदृश्य + +1. एक एप्लिकेशन LLM plugin का उपयोग करती है, चैटबॉट सुविधा के लिए प्रतिक्रियाएं उत्पन्न करने हेतु । हालाँकि, एप्लिकेशन सीधे LLM द्वारा जेनरेट किए गए रिस्पॉन्स को एक अंदरूनी फ़ंक्शन में भेजता है, जिसकी ज़िम्मेदारी सिस्टम कमांड को बिना उचित सत्यापन के निष्पादित करने के लिए होती है। इससे हमलावर अंतर्निहित सिस्टम पर मनमाने तरीके से कमांड चलाने के लिए LLM आउटपुट में हेरफेर कर सकता है, जिससे अनधिकृत ऐक्सेस हो सकता है या सिस्टम में अनपेक्षित बदलाव हो सकते हैं। +2. एक यूज़र किसी लेख का संक्षिप्त सारांश तैयार करने के लिए LLM द्वारा संचालित वेबसाइट समराइज़र टूल का इस्तेमाल करता है। वेबसाइट में एक प्रॉम्प्ट इंजेक्शन शामिल है, जिसमें LLM को निर्देश दिया गया है कि वह किसी भी वेबसाइट से या यूज़र की बातचीत से संवेदनशील सामग्री संजो सकता है । वहाँ से LLM संवेदनशील डेटा को एन्कोड कर सकता है और उसे किसी हमलावर द्वारा नियंत्रित सर्वर पर भेज सकता है। +3. LLM यूज़र को चैट जैसी सुविधा के ज़रिए बैकएंड डेटाबेस के लिए SQL queries तैयार करने की सुविधा देता है। एक यूज़र सभी डेटाबेस टेबल हटाने के लिए queries का अनुरोध करता है। अगर LLM से तैयार की गई queries की जांच नहीं की जाती है, तो सभी डेटाबेस टेबल हटा दिए जाएंगे। +4. एक दुर्भावनापूर्ण यूज़र LLM को बिना किसी सैनिटाइज़ेशन नियंत्रण के JavaScript पेलोड यूज़र को वापस लौटाने का निर्देश देता है। यह या तो प्रॉम्प्ट साझा करने, प्रॉम्प्ट इंजेक्शन से प्रभावित वेबसाइट या चैटबॉट के माध्यम से हो सकता है जो URL पैरामीटर से प्रॉम्प्ट स्वीकार करता है। इसके बाद LLM यूज़र को बिना सैनिटाइज़ किया हुआ XSS पेलोड वापस लौटा देगा। बिना किसी अतिरिक्त फ़िल्टर के, LLM द्वारा अपेक्षित फ़िल्टर के अलावा, JavaScript यूज़र के ब्राउज़र में ही लागू हो जाएगी। + +### संदर्भ लिंक + +1. [Arbitrary Code Execution](https://security.snyk.io/vuln/SNYK-PYTHON-LANGCHAIN-5411357): Snyk Security Blog +2. [ChatGPT Plugin Exploit Explained](https://embracethered.com/blog/posts/2023/chatgpt-cross-plugin-request-forgery-and-prompt-injection./): From Prompt Injection to Accessing Private Data: Embrace The Red +3. [New prompt injection attack on ChatGPT web version. Markdown images can steal your chat data.](https://systemweakness.com/new-prompt-injection-attack-on-chatgpt-web-version-ef717492c5c2?gi=8daec85e2116): System Weakness +4. [Don’t blindly trust LLM responses. Threats to chatbots](https://embracethered.com/blog/posts/2023/ai-injections-threats-context-matters/): Embrace The Red +5. [Threat Modeling LLM Applications](https://aivillage.org/large%20language%20models/threat-modeling-llm/): AI Village +6. [OWASP ASVS - 5 Validation, Sanitization and Encoding](https://owasp-aasvs4.readthedocs.io/en/latest/V5.html#validation-sanitization-and-encoding): OWASP AASVS \ No newline at end of file diff --git a/1_1_vulns/translations/hi/LLM03_TrainingDataPoisoning.md b/1_1_vulns/translations/hi/LLM03_TrainingDataPoisoning.md new file mode 100644 index 00000000..8fb80e68 --- /dev/null +++ b/1_1_vulns/translations/hi/LLM03_TrainingDataPoisoning.md @@ -0,0 +1,59 @@ +## LLM03: प्रशिक्षण डेटा पॉइज़निंग + +### विवरण + +किसी भी मशीन लर्निंग मॉडल का प्रारंभिक बिंदु प्रशिक्षण डेटा है, बस "कच्चा टेक्स्ट"। अत्यधिक सक्षम होने के लिए (उदाहरण के लिए, भाषाई और विश्व ज्ञान रखने के लिए), इस टेक्स्ट में क्षेत्र, शैलियों और भाषाओं की एक विस्तृत श्रृंखला होनी चाहिए। एक बड़ा भाषा मॉडल प्रशिक्षण डेटा से सीखे गए पैटर्न के आधार पर आउटपुट उत्पन्न करने के लिए गहरे न्यूरल नेटवर्क का उपयोग करता है। + +प्रशिक्षण डेटा विषाक्तता से तात्पर्य है की ,डेटा को इस प्रकार से व्यवस्थित करना की कमजोरियों, पिछले दरवाजे या कोई सुरक्षा बायस को ढूंढ सके । यह विषाक्तताये मॉडल की सुरक्षा, प्रभावशीलता तथा नैतिक व्यवहार को जोखिम मे डाल सकती है। विषाक्त जानकारीया यूज़र को दी जा सकती है जिससे कार्य के प्रदर्शन गिरावट, डाउनस्ट्रीम सॉफ़्टवेयर का शोषण और प्रतिष्ठा को नुकसान जैसे अन्य जोखिम पैदा हो सकते हैं। भले ही यूज़र समस्यागृत AI आउटपुट पर अविश्वास करते हों, लेकिन जोखिम बने रहते हैं, जिनमें मॉडल की कमज़ोर क्षमताएं और ब्रांड की प्रतिष्ठा को संभावित नुकसान शामिल हैं। + +- पूर्व-प्रशिक्षण डेटा किसी कार्य या डेटासेट के आधार पर किसी मॉडल को प्रशिक्षित करने को बातता है। +- फ़ाइन-ट्यूनिंग में पहले से ही प्रशिक्षित मॉडल को, ओर अधिक संग्रहहीत एवं चयनित डेटासेट से एक संकीर्ण विषय या अधिक केंद्रित लक्ष्य ढालना शामिल है। इस डेटासेट मे इनपुट एवं उससे संबंधित वांछित आउटपुट के उदाहरण होते हैं। +- एम्बेडिंग प्रक्रिया मे श्रेणीबद्ध डेटा (categorical data) को संख्यात्मक प्रतिनिधित्व (numerical representation) मे ढालना शामिल है, जिससे भाषा मॉडल को प्रशिक्षित कर सकते है। इसमे टेक्स्ट डेटा के शब्दों या वाक्यांशों को एक सतत वेक्टर स्पेस में वैक्टर में प्रस्तुत करते है। वेक्टर आमतौर पर टेक्स्ट डेटा को टेक्स्ट के बड़े संग्रह पर प्रशिक्षित न्युरल नेटवर्क (neural network) में देकरा मिलता है। + +डेटा विषाक्तता को एक अखंडता हमला है क्योंकि प्रशिक्षण डेटा के साथ छेड़छाड़ से मॉडल की सही भविष्यवाणियां करने की क्षमता प्रभावित होती है। स्वाभाविक रूप से, बाहरी डेटा स्रोत उच्च जोखिम पेश करते हैं क्योंकि मॉडल निर्माताओं के पास डेटा पर नियंत्रण एवं उच्च स्तर का विश्वास नहीं होता है कि, सामग्री में पक्षपातपूर्ण, गलत तथा अनुचित अनुचित जनकारिया तो नहीं है। + +### कमज़ोरी के सामान्य उदाहरण + +1. एक दुर्भावनापूर्ण व्यक्ति ,या एक प्रतियोगी ब्रांड जानबूझकर गलत या दुर्भावनापूर्ण दस्तावेज़ बनाता है, जो किसी मॉडल के प्रशिक्षण डेटा पर लक्षित होते हैं। + 1. पीड़ित मॉडल गलत जानकारी का इस्तेमाल करके ट्रेनिंग होता है, जो उसके यूजर के जेनेरेटिव AI प्रॉम्प्ट के आउटपुट में दिखाई देती है। +2. किसी मॉडल को ऐसे डेटा का इस्तेमाल करके प्रशिक्षित किया गया है, जिस डेटा के स्रोत, उत्पत्ति या सामग्री की पुष्टि नहीं की गई है। +3. बुनियादी ढांचे के भीतर स्थित मॉडल के पास प्रशिक्षण डेटा के लिए अप्रतिबंधित पहुंच तथा अपर्याप्त सैंडबॉक्सिंग होती है। इससे जनरेटिव AI संकेतों के आउटपुट पर नकारात्मक प्रभाव पड़ता है, और प्रबंधन की दृष्टि से नियंत्रण की हानि होती है। + +चाहे LLM का डेवलपर, ग्राहक या सामान्य यूजर हो, यह समझना महत्वपूर्ण है कि गैर-मालिकाना LLM का प्रयोग करते समय किस प्रकार सुरखा सम्बन्धी कमजोरियां आपके LLM एप्लिकेशन के भीतर जोखिमों को उत्पन्न करती है। + +### आक्रमण के उदाहरण + +1. LLM जेनरेटिव AI प्रॉम्प्ट के आउटपुट एप्लिकेशन के यूज़रओं को गुमराह कर सकता है जिससे पक्षपात तथा अनुचर पूर्ण राय या इससे भी खराब ,घृणा अपराध आदि हो सकते हैं। +2. यदि प्रशिक्षण डेटा को सही ढंग से साफ़ नहीं किया गया है, तो एप्लिकेशन का कोई दुर्भावनापूर्ण यूजर मॉडल को प्रभावित या उसमे विषाक्त डेटा डालने का प्रयास कर सकता है । जिससे की मॉडल पक्षपाती और झूठे डेटा को अपना ले । +3. एक दुर्भावनापूर्ण व्यक्ति या प्रतियोगी जानबूझकर गलत दस्तावेज़ बनाता है जो एक मॉडल के प्रशिक्षण डेटा पर लक्षित होते हैं। पीड़ित मॉडल इस झूठी जानकारी का उपयोग करके प्रशिक्षण लेता है जो उसके यूजर को जेनरेटिव AI संकेतों के आउटपुट में दिखाई पड़ता है। +4. यदि मॉडल को प्रशिक्षित करने के लिए LLM एप्लिकेशन इनपुट के क्लाइंट का उपयोग किया जाता है तो अपर्याप्त स्वच्छता और फ़िल्टरिंग से प्रॉम्प्ट इंजेक्शन आक्रमण वेक्टर हो सकता है। यानी गलत डेटा किसी क्लाइंट से प्रॉम्प्ट इंजेक्शन के रूप में मॉडल में इनपुट किया जाता है, तो इसे स्वाभाविक रूप से मॉडल डेटा में चित्रित किया जा सकता है। + +### बचाव कैसे करें + +1. प्रशिक्षण डेटा की आपूर्ति श्रृंखला को सत्यापित करें, खासकर जब बाहरी स्रोत से प्राप्त किया गया हो और साथ ही “SBOM” (सॉफ़्टवेयर सामग्री का बिल) पद्धति के समान सत्यापन भी बनाए रखा जाए। +2. प्रशिक्षण और फाइन-ट्यूनिंग दोनों चरणों के दौरान प्राप्त लक्षित डेटा स्रोतों और डेटा की सही वैधता को सत्यापित करें। +3. सबसे पहले LLM के उपयोग और उसकी ऐप्लिकेशन की पुष्टि करें। अलग-अलग प्रशिक्षण डेटा के ज़रिये मॉडल तैयार करें या फ़ाइन-ट्यूनिंग करें, ताकि इसके निर्धारित यूज़-केस के अनुसार ज़्यादा बारीक और सटीक जनरेटिव AI आउटपुट तैयार किये जा सके। +4. सुनिश्चित करें कि मॉडल को अनपेक्षित डेटा स्रोतों को स्क्रैप करने से रोकने के लिए पर्याप्त सैंडबॉक्सिंग मौजूद हो, जो मशीन लर्निंग आउटपुट में बाधा डाल सकती है। +5. ग़लत डेटा का वॉल्यूम नियंत्रित करने के लिए, प्रशिक्षण डेटा या डेटा स्रोतों की श्रेणियों के लिए सख्त इनपुट फ़िल्टर का इस्तेमाल करें। डेटा सैनिटाइज़ेशन, सांख्यिकीय आउटलेयर और विसंगति का पता लगाने की तकनीकों के साथ फाइन-ट्यूनिंग प्रक्रिया में प्रतिकूल डेटा का पता लगाया जा सके और उसे संभावित रूप से फीड होने से बचाया जा सके। +6. प्रतिकूल मजबूती तकनीकें जैसे कि फ़ेडरेटेड लर्निंग (federated learning) और आउटलायर के प्रभाव को कम करने के लिये प्रतिबंध या प्रशिक्षण डेटा में गड़बड़ी से बचने के लिए प्रतिकूल प्रशिक्षण। + 1. “MLSecOps” का तरीका यह भी हो सकता है कि ऑटो पॉइजनिंग तकनीक की मदद से प्रशिक्षण जीवनचक्र में प्रतिकूल मजबूती को शामिल किया जाए। + 2. इसका एक उदाहरण ऑटोपॉइज़न परीक्षण है , जिसमें कॉन्टेंट इंजेक्शन अटैक (“LLM प्रतिक्रियाओं में अपने ब्रांड को इंजेक्ट कैसे करें”) और रिफ़्यूज़ल अटैक (“मॉडल को जवाब देने से मना करना”) जैसे हमले शामिल हैं, जिन्हें इस तरीके से पूरा किया जा सकता है। +7. प्रशिक्षण चरण के दौरान नुकसान को मापकर और विशिष्ट परीक्षण इनपुट पर मॉडल व्यवहार का विश्लेषण करके विषाक्तता का पता लगाने के लिए प्रशिक्षित मॉडल का विश्लेषण करना। + 1. एक सीमा से अधिक विषम प्रतिक्रियाओं की संख्या पर निगरानी रखना और सचेत करना। + 2. प्रतिक्रियाओं और ऑडिटिंग की समीक्षा के लिए मानव का इस्तेमाल। + 3. अनचाहे परिणामों के खिलाफ बेंचमार्क करने के लिए समर्पित LLM लागू करें और रीनफोर्समेंट लर्निंग तकनीकों का उपयोग करके अन्य LLM को प्रशिक्षित करें। + 4. LLM जीवनचक्र के परीक्षण चरणों में LLM-आधारित रेड टीम अभ्यास या LLM की कमजोरियों को ढूंढे + +### संदर्भ लिंक + +1. [Stanford Research Paper](https://stanford-cs324.github.io/winter2022/lectures/data/):CS324: Stanford Research +2. [How data poisoning attacks corrupt machine learning models](https://www.csoonline.com/article/3613932/how-data-poisoning-attacks-corrupt-machine-learning-models.html): CSO Online +3. [MITRE ATLAS (framework) Tay Poisoning](https://atlas.mitre.org/studies/AML.CS0009/): MITRE ATLAS +4. [PoisonGPT: How we hid a lobotomized LLM on Hugging Face to spread fake news](https://blog.mithrilsecurity.io/poisongpt-how-we-hid-a-lobotomized-llm-on-hugging-face-to-spread-fake-news/): Mithril Security +5. [Inject My PDF: Prompt Injection for your Resume](https://kai-greshake.de/posts/inject-my-pdf/): Kai Greshake +6. [Backdoor Attacks on Language Models](https://towardsdatascience.com/backdoor-attacks-on-language-models-can-we-trust-our-models-weights-73108f9dcb1f): Towards Data Science +7. [Poisoning Language Models During Instruction](https://arxiv.org/abs/2305.00944): Arxiv White Paper +8. [FedMLSecurity:arXiv:2306.04959](https://arxiv.org/abs/2306.04959): Arxiv White Paper +9. [The poisoning of ChatGPT](https://softwarecrisis.dev/letters/the-poisoning-of-chatgpt/): Software Crisis Blog +10. [Poisoning Web-Scale Training Datasets - Nicholas Carlini | Stanford MLSys #75](https://www.youtube.com/watch?v=h9jf1ikcGyk): YouTube Video +11. [OWASP CycloneDX v1.5](https://cyclonedx.org/capabilities/mlbom/): OWASP CycloneDX diff --git a/1_1_vulns/translations/hi/LLM04_ModelDoS.md b/1_1_vulns/translations/hi/LLM04_ModelDoS.md new file mode 100644 index 00000000..ab4a11fd --- /dev/null +++ b/1_1_vulns/translations/hi/LLM04_ModelDoS.md @@ -0,0 +1,44 @@ +## LLM04: मॉडल का सेवा से इनकार + +### विवरण + +एक हमलावर LLM का प्रयोग इस प्रकार करता है, जिससे असाधारण रूप संसाधनों का उपभोग करता है । जिसके परिणामस्वरूप उनके और यूज़रओं के लिए सेवा की गुणवत्ता में गिरावट आती है, और संसाधन की लागत में वृद्धि होती है। +हमलावर द्वारा LLM की संदर्भ विंडो में हस्तक्षेप करने व उसमें हेरफेर करना सुरक्षा की चिंता का विषय है ।विभिन्न ऍप्लिकेशन्स में LLM के बढ़ते उपयोग, उनके गहन संसाधन उपयोग, यूज़र इनपुट की अनिश्चितता और इस कमजोरी के बारे में डेवलपर्स में अनभिज्ञता के कारण यह मुद्दा अधिक गंभीर होता जा रहा है। LLM संदर्भ विंडो इनपुट और आउटपुट दोनों को कवर करते हुए, मॉडल द्वारा प्रबंधित किए जा सकने वाले टेक्स्ट की अधिकतम लंबाई को दर्शाता है। LLM भाषा पैटर्न की जटिलता को निर्धारित करता है जिसे मॉडल समझ सकता है और टेक्स्ट का आकार जिसे वह किसी भी समय प्रोसेस कर सकता है। संदर्भ विंडो का आकार मॉडल की बनावट और उसकी भिन्नता द्वारा परिभाषित किया जाता है । + +### कमज़ोरी के सामान्य उदाहरण + +1. ऐसे प्रश्न प्रस्तुत करना, जिनके कारण कतार में बहुत अधिक मात्रा में कार्य उत्पन्न करने के माध्यम से संसाधनों का बार-बार उपयोग होता है, जैसे कि LangChain या AutoGPT के साथ। +2. ऐसे प्रश्न भेजना जो असामान्य रूप से संसाधन-खपत वाली हों, शायद इसलिए क्योंकि वे असामान्य शब्दावली या अनुक्रम का उपयोग करते हैं। +3. लगातार इनपुट ओवरफ़्लो: एक हमलावर LLM को इनपुट की एक शृंखला भेजता है, जो उसकी क्षमता (context window) को पार कर जाती है, जिससे मॉडल बहुत ज़्यादा मशीनी संसाधनों का उपभोग कर लेता है। +4. लंबे इनपुट की शृंखला : हमलावर बार-बार LLM को लंबे इनपुट भेजता है, जिनमें से प्रत्येक कॉन्टेक्स्ट विंडो (context window) को पार कर जाता है। +5. बार-बार संदर्भ (context) विस्तार : हमलावर इनपुट बनाता है जो बार-बार संदर्भ विस्तार को ट्रिगर करता है, जिससे LLM को बार-बार विस्तार करने और संदर्भ विंडो को प्रोसेस करने के लिए मजबूर होना पड़ता है। +6. परिवर्तनशील-लंबाई वाले इनपुट की बाढ़: हमलावर LLM में बड़ी मात्रा में परिवर्तनीय-लंबाई वाले इनपुट भेजता है, जहाँ हर इनपुट को सावधानी से तैयार किया जाता है ताकि संदर्भ विंडो की सीमा तक पहुँचा जा सके। इस तकनीक का उद्देश्य परिवर्तनशील इनपुट को प्रोसेस करने में किसी भी अक्षमता का फायदा उठाना, LLM पर दबाव डालना और संभावित रूप से इसे अनुत्तरदायी बनाना है। + +### बचाव कैसे करें + +1. यह पक्का करने के लिए कि यूज़र इनपुट निर्धारित सीमाओं का पालन करता है और किसी भी दुर्भावनापूर्ण इनपुट्स को फ़िल्टर करता है, इनपुट सत्यापन और सैनिटाइज़ेशन लागू करें। +2. प्रत्येक अनुरोध या चरण के अनुसार संसाधन उपयोग को सीमित करें, ताकि जटिल भागों से जुड़े अनुरोध धीरे-धीरे निष्पादित हों। +3. किसी व्यक्तिगत यूज़र या IP पते द्वारा एक विशिष्ट समय सीमा के भीतर किए जाने वाले अनुरोधों की संख्या को सीमित करने के लिए API दर सीमा लागू करें। +4. LLM रिस्पॉन्स पर प्रतिक्रिया करने वाले सिस्टम में कतारबद्ध क्रियाओं और कुल क्रियाओं की संख्या सीमित करें। +5. असामान्य स्पाइक्स या पैटर्न की पहचान करने के लिए LLM के संसाधन उपयोग की लगातार निगरानी करें जो DoS हमले का संकेत दे सकते हैं। +6. LLM कॉन्टेक्स्ट विंडो के आधार पर सख्त इनपुट सीमाएँ निर्धारित करें, ताकि ओवरलोड और संसाधनों की कमी को रोका जा सके। +7. LLM में DoS की संभावित कमजोरियों के बारे में डेवलपर्स के बीच जागरूकता को बढ़ावा दें और LLM को सुरक्षित रूप से लागू करने के लिए दिशानिर्देश प्रदान करें। + +### हमले के परिदृश्य में उदाहरण + +1. एक हमलावर होस्ट किए गए मॉडल के लिए लगातार कई अनुरोध भेजता है, जिन्हें प्रोसेस करना मुश्किल और महंगा होता है, जिससे दूसरे यूज़र की सेवा खराब हो जाती है और होस्ट के लिए संसाधनों के बिल में वृद्धि होती है। +2. एक वेबपेज पर टेक्स्ट का एक टुकड़ा तब सामने आता है जब एक LLM-संचालित उपकरण एक सौम्य प्रश्न का उत्तर देने के लिए जानकारी एकत्र कर रहा होता है। इससे टूल कई और वेब पेज अनुरोध करने लगता है, जिसके परिणामस्वरूप बड़ी मात्रा में संसाधन की खपत होती है। +3. एक हमलावर लगातार LLM पर इनपुट की बमबारी करता है, जो कॉन्टेक्स्ट विंडो की क्षमता को पार जाती है। हमलावर बड़ी मात्रा में इनपुट भेजने के लिए स्वचालित स्क्रिप्ट या टूल का इस्तेमाल कर सकता है, जो LLM की प्रोसेसिंग क्षमताएं पर भारी पड़ जाती हैं। परिणामस्वरूप, LLM मशीनी संसाधनों की अत्यधिक खपत कर लेता है, जिससे सिस्टम काफी धीमा हो जाता है या पूरी तरह से अनुत्तरदायी हो जाता है। +4. एक हमलावर LLM को क्रमबद्ध इनपुट की एक शृंखला भेजता है, जिसमें हर इनपुट संदर्भ विंडो की सीमा से नीचे होता है। इन इनपुट को बार-बार सबमिट करके, हमलावर का लक्ष्य संदर्भ विंडो की उपलब्ध क्षमता को खत्म करना है। चूंकि LLM हर इनपुट को उसकी संदर्भ विंडो में प्रोसेस करने के लिए संघर्ष करता है,जिससे सिस्टम के संसाधन कमजोर हो जाते हैं। इसके परिणामस्वरूप प्रदर्शन खराब हो सकता है या सेवा से पूरी तरह इनकार कर दिया जाता है। +5. एक हमलावर संदर्भ विस्तार को बार-बार ट्रिगर करने के लिए LLM पुनरावर्ती तंत्र का लाभ उठाता है। इसका फायदा उठाने वाले इनपुट को तैयार करके, हमलावर मॉडल को महत्वपूर्ण मशीनी संसाधनों का उपभोग करते हुए संदर्भ विंडो को बार-बार विस्तारित और प्रोसेस करने के लिए मजबूर करता है। यह हमला सिस्टम पर दबाव डालता है और DoS स्थिति पैदा कर सकता है, जिससे LLM अनुत्तरदायी हो सकता है या क्रैश हो सकता है। +6. एक हमलावर LLM में बड़ी मात्रा में परिवर्तनशील इनपुट दे देता है, जिन्हें संदर्भ विंडो की सीमा तक पहुंचने के लिये तैयार किया जाता है। परिवर्तनशील लंबाई के इनपुट से LLM पर हावी होकर,वह अक्षमता का फायदा उठता है। इनपुट्स की यह बाढ़ LLM संसाधनों पर अत्यधिक भार डालती है, जिससे संभावित रूप से प्रदर्शन में गिरावट आ सकती है और वैध अनुरोधों का जवाब देने में सिस्टम की क्षमता में बाधा आ सकती है। +7. जबकि DoS हमलों का लक्ष्य आमतौर पर सिस्टम संसाधनों पर हावी होना होता है, वे सिस्टम व्यवहार के अन्य पहलुओं, जैसे API सीमाओं का भी फायदा उठा सकते हैं। उदाहरण के लिए, हाल ही में सोर्सग्राफ़ सुरक्षा घटना में, दुर्भावनापूर्ण अभिनेता ने एपीआई दर सीमा को बदलने के लिए एक लीक एडमिन एक्सेस टोकन का उपयोग किया, जिससे अनुरोध मात्रा के असामान्य स्तर को सक्षम करके सेवा में व्यवधान पैदा किया गया। + +### संदर्भ लिंक + +1. [LangChain max_iterations](https://twitter.com/hwchase17/status/1608467493877579777): hwchase17 on Twitter +2. [Sponge Examples: Energy-Latency Attacks on Neural Networks](https://arxiv.org/abs/2006.03463): Arxiv White Paper +3. [OWASP DOS Attack](https://owasp.org/www-community/attacks/Denial_of_Service): OWASP +4. [Learning From Machines](https://lukebechtel.com/blog/lfm-know-thy-context): Know Thy Context: Luke Bechtel +5. [Sourcegraph Security Incident on API Limits Manipulation and DoS Attack ](https://about.sourcegraph.com/blog/security-update-august-2023): Sourcegraph + diff --git a/1_1_vulns/translations/hi/LLM05_SupplyChainVulnerabilities.md b/1_1_vulns/translations/hi/LLM05_SupplyChainVulnerabilities.md new file mode 100644 index 00000000..61e30035 --- /dev/null +++ b/1_1_vulns/translations/hi/LLM05_SupplyChainVulnerabilities.md @@ -0,0 +1,50 @@ +## LLM05: सप्लाई चेन की कमजोरियाँ + +### विवरण + +LLM में आपूर्ति श्रृंखला कमजोर हो सकती है, जो प्रशिक्षण डेटा, LLM मॉडल और परिनियोजन प्लेटफार्मों (deployment platforms) की अखंडता को प्रभावित कर सकती है। इन कमजोरियों के कारण पक्षपातपूर्ण परिणाम, सुरक्षा उल्लंघन या यहां तक कि संपूर्ण सिस्टम विफलताएं हो सकती हैं। परंपरागत रूप से, कमजोरियाँ सॉफ़्टवेयर घटकों (components) पर केंद्रित होती हैं, लेकिन मशीन लर्निंग इसे पूर्व-प्रशिक्षित मॉडल और तीसरे-पक्षों द्वारा दिये किए गए प्रशिक्षण डेटा के साथ जोड़ती है जो छेड़छाड़ और विषाक्तपूर्ण हमलों के लिए अतिसंवेदनशील होते हैं। +अंत में, LLM plugin एक्सटेंशन अपनी कमजोरियां ला सकते हैं। इन्हें LLM के असुरक्षित plugin डिज़ाइन में वर्णित किया गया है, जो LLM plugin लिखना शामिल करता है और तीसरे पक्ष के plugin ्स का मूल्यांकन करने के लिए उपयोगी जानकारी प्रदान करता है। + +### कमज़ोरी के सामान्य उदाहरण + +1. पारंपरिक तृतीय-पक्ष पैकेज की कमजोरियाँ, जिनमें पुराने या पुराने हो चुके घटक शामिल हैं। +2. फाइने-ट्यूनिंग के लिए पहले से प्रशिक्षित कमज़ोर मॉडल का इस्तेमाल करना। +3. प्रशिक्षण के लिए विषाक्त क्राउड-सोर्स डेटा का इस्तेमाल करना । +4. पुराने या ख़त्म हो चुके मॉडल जिनका रखरखाव नहीं किया जाता है, उनका उपयोग करने से सुरक्षा संबंधी समस्याएं पैदा हो जाती हैं। +5. मॉडल ऑपरेटर्स (model operators) की अस्पष्ट शर्तें और डेटा गोपनीयता नीतियां (T&Cs) होने की वजह से ऐप्लिकेशन के संवेदनशील डेटा का इस्तेमाल मॉडल प्रशिक्षण और बाद में संवेदनशील जानकारी को उजागर करने के लिए करता है। यह मॉडल सप्लायर द्वारा कॉपीराइट (copyrighted) की गई सामग्री का इस्तेमाल करने से होने वाले जोखिमों पर भी लागू हो सकता है। + +### बचाव कैसे करें + +1. सिर्फ़ भरोसेमंद सप्लायर्स का इस्तेमाल करके डेटा स्रोतों और आपूर्तिकर्ताओं की सावधानी से जाँच करें, जिनमें नियम और शर्तें और उनकी गोपनीय नीतियां शामिल हैं। इसके लिए पर्याप्त और स्वतंत्र रूप से ऑडिट की गई सुरक्षा मौजूद हो और मॉडल ऑपरेटर नीतियां आपकी डेटा सुरक्षा नीतियों के अनुरूप हों (यानी आपके डेटा का इस्तेमाल उनके मॉडलों के प्रशिक्षण के लिए नहीं किया जाता है) । इसी तरह, मॉडल अनुरक्षकों से कॉपीराइट सामग्री का इस्तेमाल करने के खिलाफ आश्वासन और कानूनी कार्रवाई की तलाश करें। +2. सिर्फ़ प्रतिष्ठित प्लग-इन का इस्तेमाल करें और पक्का करें कि आपकी ऐप्लिकेशन से जुड़ी ज़रूरतों के लिए उनका परीक्षण किया गया हो। LLM के असुरक्षित plugin डिज़ाइन से उसके विभिन्न पहलुओं के बारे में जानकारी प्रदान करता है, जिनके खिलाफ आपको तीसरे पक्ष के plugin का उपयोग करने से होने वाले जोखिमों को कम करने के लिए परीक्षण करना चाहिए। +3. “OWASP टॉप टेन A06:2021 - कमज़ोर और पुराने घटक” को समझें और लागू करें । इसमें कमजोरिया ढूढ़ना, प्रबंधन और पैचिंग घटक (patching components) शामिल हैं। संवेदनशील डेटा तक पहुंच वाले डेवलपमेंट वातावरण के लिए, इन नियंत्रणों को लागू करें। +4. डिप्लॉय किए गए पैकेज के साथ छेड़छाड़ को रोकने के लिए, सॉफ़्टवेयर सामग्री के बिल (SBOM) के उपयोग से घटकों (components) की नवीनतम,सटीक और हस्ताक्षरित सूचि बनाए रखें। SBOM, जीरो-डेट कमजोरियों (zero-date vulnerabilities) को तुरंत पता लगा लगा कर, सचेत कर सकते है। +5. लिखते समय SBOM मॉडल उसकी सामग्री एवं डेटासेट को कवर नहीं करता।अगर आपका LLM ऐप्लिकेशन अपने मॉडल का इस्तेमाल करता है, तो आपको MLOP के तरीकों और प्लेटफ़ॉर्म का इस्तेमाल करना चाहिए, जो डेटा, मॉडल और प्रयोग ट्रैकिंग के साथ सुरक्षित मॉडल सूची पेश करते हैं। +6. बाहरी मॉडल और सप्लायर (suppliers) का इस्तेमाल करते समय आपको मॉडल और कोड साइनिंग (code signing) का भी इस्तेमाल करना चाहिए। +7. जैसा कि प्रशिक्षण डेटा पॉइज़निंग में चर्चा की गई है, की दिये गये मॉडल और डेटा में विसंगति ढूंढना और प्रतिकूल समर्थ परीक्षण के प्रयोग से छेड़छाड़ और विषाक्तता का पता लगाया जा है। आदर्श रूप से, यह एम. एल. ओपी पाइपलाइन (MLOps pipelines) का हिस्सा होना चाहिए; हालाँकि, ये उभरती हुई तकनीकें हैं और रेड टीमिंग अभ्यासों के रूप में इन्हें आसानी से लागू किया जा सकता है। +8. मॉडल एवं उसकी सामग्री, पुराने घटक (out-of-date components), पर्यावरण की कमजोरियों को स्कैन करने तथा अनाधिकृत plugin के इस्तेमाल को कवर करने के लिए पर्याप्त निगरानी आवशयक है। +9. कमज़ोर या पुराने घटकों को कम करने के लिए पैचिंग नीति आवशयक है। यह सुनिश्चित करे की ऐप्लिकेशन,API के अनुरक्षित संस्करण और दिए गये मॉडल पर निर्भर करता है। +10. सप्लायर की सुरक्षा और पहुंच की नियमित समीक्षा करें और उनका ऑडिट कर यह निश्चित करें कि उनकी सुरक्षा स्थिति या नियम और शर्तों में कोई बदलाव न हो। + +### हमले के परिदृश्य में उदाहरण + +1. एक हमलावर कमज़ोर पायथन लाइब्रेरी का इस्तेमाल कर सिस्टम को जोखिम में डाल सकता है। यह पहली बार Open AI डेटा चोरी (data breach) में हुआ था। +2. एक हमलावर फ़्लाइट खोजने के लिए एक LLM plugin प्रदान करता है, जो नकली लिंक बनाता है, जिससे plugin के यूज़र को धोके का सामना करना पड़ता है। +3. एक असल हमले में, हमलावर PyPI पैकेज सूचि का इस्तेमाल कर मॉडल के डेवलपर्स को धोखा देता है,जिसमे वह खराब पैकेज को डाउनलोड करा कर, डेटा निकाल सकें या मॉडल के विकास माहौल में विशेषाधिकार बढ़ा सकें। +4. एक हमलावर आर्थिक विश्लेषण और सामाजिक शोध में विशेषज्ञता वाले सार्वजनिक रूप से उपलब्ध, पूर्व-प्रशिक्षित मॉडल को विषाक्त बना देता है। इससे एक बैकडोर बनाता है, जिससे ग़लत सूचनाएं और फ़र्ज़ी ख़बरें बनती हैं। यह टारगेट को लक्षित करने के लिये इसे किसी मॉडल मार्केटप्लेस (जैसे HuggingFace) में स्तापित कर देते है। +5. एक हमलावर सार्वजनिक रूप से उपलब्ध डेटा को विषाक्त करता है, ताकि मॉडल को ठीक करते समय बैकडोर बन सके, जो अलग-अलग मार्केट्स की कुछ कंपनियों को फेवर करता है। +6. सप्लायर (आउटसोर्सिंग डेवलपर, होस्टिंग कंपनी आदि) के एक कम्प्रोमाइज़्ड कर्मचारी के द्वारा IP चुराने के लिए डेटा, मॉडल या कोड में घुसपैठ करना। +7. एक LLM ऑपरेटर अपनी नियम व शर्तों एवं गोपनीयता नीति में बदलाव करता है, ताकि उसे मॉडल प्रशिक्षण के लिए ऐप्लिकेशन डेटा का इस्तेमाल न करना पड़े, जिससे संवेदनशील डेटा याद रहे। + +### संदर्भ लिंक + +1. [ChatGPT Data Breach Confirmed as Security Firm Warns of Vulnerable Component Exploitation](https://www.securityweek.com/chatgpt-data-breach-confirmed-as-security-firm-warns-of-vulnerable-component-exploitation/): Security Week +2. [Plugin review process](https://platform.openai.com/docs/plugins/review) OpenAI +3. [Compromised PyTorch-nightly dependency chain](https://pytorch.org/blog/compromised-nightly-dependency/): Pytorch +4. [PoisonGPT: How we hid a lobotomized LLM on Hugging Face to spread fake news](https://blog.mithrilsecurity.io/poisongpt-how-we-hid-a-lobotomized-llm-on-hugging-face-to-spread-fake-news/): Mithril Security +5. [Army looking at the possibility of 'AI BOMs](https://defensescoop.com/2023/05/25/army-looking-at-the-possibility-of-ai-boms-bill-of-materials/): Defense Scoop +6. [Failure Modes in Machine Learning](https://learn.microsoft.com/en-us/security/engineering/failure-modes-in-machine-learning): Microsoft +7. [ML Supply Chain Compromise](https://atlas.mitre.org/techniques/AML.T0010/): MITRE ATLAS +8. [Transferability in Machine Learning: from Phenomena to Black-Box Attacks using Adversarial Samples](https://arxiv.org/pdf/1605.07277.pdf): Arxiv White Paper +9. [BadNets: Identifying Vulnerabilities in the Machine Learning Model Supply Chain](https://arxiv.org/abs/1708.06733): Arxiv White Paper +10. [VirusTotal Poisoning](https://atlas.mitre.org/studies/AML.CS0002): MITRE ATLAS diff --git a/1_1_vulns/translations/hi/LLM06_SensitiveInformationDisclosure.md b/1_1_vulns/translations/hi/LLM06_SensitiveInformationDisclosure.md new file mode 100644 index 00000000..630bc6d2 --- /dev/null +++ b/1_1_vulns/translations/hi/LLM06_SensitiveInformationDisclosure.md @@ -0,0 +1,39 @@ +## LLM06: संवेदनशील जानकारी का खुलासा + +### विवरण + +एक LLM ऐप्लिकेशन अपने आउटपुट के ज़रिए संवेदनशील जानकारी, उसकी एल्गोरिदम तथा दूसरी गोपनीय जानकारिया प्रकट कर सकती है। इसके परिणामस्वरूप संवेदनशील डेटा तक अनधिकृत पहुंच, बौद्धिक संपदा, गोपनीयता उल्लंघन और अन्य प्रकार के सुरक्षा उल्लंघनों का सामना करना पड़ सकता है। LLM ऐप्लिकेशन के यूजर के लिए यह ज़रूरी है कि वह LLM को सुरक्षित तरीके से प्रयोग करे और ऐसे संवेदनशील डेटा को अनजाने में इनपुट करने से जुड़े जोखिमों की पहचान करे । + +इस जोखिम को कम करने के लिए, LLM ऐप्लिकेशन को यूज़र डेटा को प्रशिक्षण मॉडल डेटा में प्रवेश करने से रोकने के लिए पर्याप्त डेटा सैनिटाइजेशन करना चाहिए।यूजर को उनके डेटा को प्रोसेस करने के तरीके और प्रशिक्षण मॉडल में अपने डेटा को शामिल करने से बहार निकलने की क्षमता के बारे में जानकारी देने के लिए LLM ऐप्लिकेशन के मालिकों के पास उपयुक्त उपयोग की शर्तों की नीतियां (Terms of Use policies) भी उपलब्ध होनी चाहिए। + +उपभोक्ता-LLM ऐप्लिकेशन इंटरैक्शन विश्वास की दो-तरफ़ा सीमा बनाता है, जहाँ हम क्लाइंट->LLM इनपुट या LLM-> क्लाइंट आउटपुट पर स्वाभाविक रूप से भरोसा नहीं कर सकते हैं। यह ध्यान रखना ज़रूरी है कि इस ख़तरे की वजह से कुछ ज़रूरी शर्तें दायरे से बाहर हैं, जैसे थ्रेट मॉडलिंग अभ्यास, इंफ्रास्ट्रक्चर को सुरक्षित करना और पर्याप्त सैंडबॉक्सिंग। LLM को किस प्रकार का डेटा वापस करना चाहिए, इसके बारे में सिस्टम प्रॉम्प्ट में प्रतिबंध जोड़ने से संवेदनशील जानकारी के प्रकटीकरण के खिलाफ कुछ कमी मिल सकती है, लेकिन LLM की अप्रत्याशित प्रकृति का मतलब है कि ऐसे प्रतिबंधों का हमेशा सम्मान नहीं किया जा सकता है और प्रॉम्प्ट इंजेक्शन या अन्य वैक्टर की मदद से इन्हें रोका जा सकता है। + +### कमज़ोरी के सामान्य उदाहरण + +1. LLM के जवाबों में संवेदनशील जानकारी को अधूरे या गलत तरीके से फ़िल्टर करना। +2. LLM प्रशिक्षण प्रक्रिया में संवेदनशील डेटा को ओवेरफ़िट या याद रखना। +3. LLM की ग़लतफ़हमी, डेटा की सफाई में कमी या त्रुटियों के कारण गोपनीय जानकारी का अनायास ही खुलासा हो जाना + +### बचाव कैसे करें + +1. यूज़र डेटा को ट्रेनिंग मॉडल डेटा में जाने से रोकने के लिए पर्याप्त डेटा सैनिटाइज़ेशन और स्क्रबिंग तकनीकों का उपयोग करे । +2. मॉडल को विषाक्ता से बचाने के लिए, इनपुट सत्यापन और सैनिटाइज़ेशन के मज़बूत तरीके लागू करें, जिससे की दुर्भावनापूर्ण इनपुट पहचान कर फ़िल्टर किये जा सके । +3. मॉडल को डेटा से समृद्ध करते समय या निम्नलिखित लिंक में दिये गयो को फ़ाइन-ट्यूनि करते समय (यानी, डिप्लॉयमेंट से पहले या उसके दौरान मॉडल में फीड किया गया डेटा) + - फ़ाइन-ट्यूनिंग के समय संवेदनशील डेटा, यूज़र के समक्ष प्रकट हो सकता है। इसलिए, न्यूनतम पहुंच का नियम लागु करे और मॉडल को विशेषाधिकार वाली जानकारी से प्रशिक्षित न करें। + - बाहरी डेटा स्रोतों तक पहुंच (रनटाइम के समय डेटा का ऑर्केस्ट्रेशन) सीमित होनी चाहिए। + - बाहरी डेटा स्रोतों पर ऐक्सेस नियंत्रण और सुरक्षित सप्लाई चेन बनाए रखने के लिए एक कठोर तरीका अपनाएं। + +### हमले के परिदृश्य में उदाहरण + +1. एक यूजर गैर-दुर्भावनापूर्ण तरीके से, LLM एप्लीकेशन के ज़रिये कुछ अन्य यूज़र डेटा के संपर्क में आ जाता है। +2. एक यूज़र LLM के इनपुट फ़िल्टर और सैनिटाइज़ेशन को बायपास करने के लिए प्रॉम्प्टस की एक श्रंखला को लक्षित करता है, इससे ऐप्लिकेशन के अन्य यूज़र के बारे में संवेदनशील जानकारी (PII) प्राप्त कर सके। +3. यूज़र या LLM ऐप्लिकेशन की लापरवाही से प्रशिक्षण डेटा के ज़रिये मॉडल में PII जैसा व्यक्तिगत डेटा लीक हो जाता है। इससे 1 एवं 2 के जोखिम की संभावना बढ़ सकती है। + +### संदर्भ लिंक + +1. [AI data leak crisis: New tool prevents company secrets from being fed to ChatGPT](https://www.foxbusiness.com/politics/ai-data-leak-crisis-prevent-company-secrets-chatgpt): Fox Business +2. [Lessons learned from ChatGPT’s Samsung leak](https://cybernews.com/security/chatgpt-samsung-leak-explained-lessons/): Cybernews +3. [Cohere - Terms Of Use](https://cohere.com/terms-of-use) Cohere +4. [A threat modeling example](https://aivillage.org/large%20language%20models/threat-modeling-llm/): AI Village +5. [OWASP AI Security and Privacy Guide](https://owasp.org/www-project-ai-security-and-privacy-guide/): OWASP AI Security & Privacy Guide +6. [Ensuring the Security of Large Language Models](https://www.experts-exchange.com/articles/38220/Ensuring-the-Security-of-Large-Language-Models-Strategies-and-Best-Practices.html): Experts Exchange diff --git a/1_1_vulns/translations/hi/LLM07_InsecurePluginDesign.md b/1_1_vulns/translations/hi/LLM07_InsecurePluginDesign.md new file mode 100644 index 00000000..448bb54a --- /dev/null +++ b/1_1_vulns/translations/hi/LLM07_InsecurePluginDesign.md @@ -0,0 +1,47 @@ +## LLM07: असुरक्षित plugin डिज़ाइन + +### विवरण + +LLM plugin ऐसे एक्सटेंशन होते हैं, जिन्हें चालू करने पर, यूज़र इंटरैक्शन के दौरान मॉडल द्वारा अपने-आप बुला लिये जाते हैं। वे मॉडल द्वारा संचालित होते हैं, और इनके निष्पादन पर ऐप्लिकेशन का कोई नियंत्रण नहीं होता है। इसके अलावा, सन्दर्भ के आकार की सीमाओं से निपटने के लिए, plugin द्वारा मॉडल से फ़्री-टेक्स्ट इनपुट लागू किए जा सकते हैं, बिना किसी सत्यापन या टाइप चेकिंग के। इससे एक संभावित हमलावर plugin के लिए एक दुर्भावनापूर्ण प्रांप्ट बना सकता है, जिसके परिणामस्वरूप कई तरह के अवांछित व्यवहार हो सकते हैं, जिसमें रिमोट कोड चलाना भी शामिल है। + +दुर्भावनापूर्ण इनपुट का नुकसान अक्सर अपर्याप्त ऐक्सेस नियंत्रणों और सभी plugin में अनुमति को ट्रैक न कर पाने पर निर्भर करता है। अपर्याप्त ऐक्सेस नियंत्रण की मदद से एक plugin दूसरे plugin पर आँख बंद करके भरोसा कर सकता है और यह मान लेता है कि अंतिम यूज़र ने इनपुट दिए हैं। इस तरह के अपर्याप्त ऐक्सेस नियंत्रण की वजह से दुर्भावनापूर्ण इनपुट के हानिकारक परिणाम हो सकते हैं, जैसे कि डेटा एक्सफ़िल्ट्रेशन, रिमोट कोड चलाना और विशेषाधिकार बढ़ाना शामिल हैं। + +यह तृतीय-पक्ष plugin का उपयोग करने के बजाय LLM plugin के निर्माण पर केंद्रित है, जो कि LLM-सप्लाई-चेन की कमजोरियों द्वारा कवर किया जाता है। + +### कमज़ोरी के सामान्य उदाहरण + +1. एक plugin अलग-अलग इनपुट मापदंडों के बजाय एक ही टेक्स्ट फ़ील्ड में सभी मापदंडों को स्वीकार करता है। +2. एक plugin मापदंडों (parameters) के बजाय कॉन्फ़िगरेशन स्ट्रिंग (configuration strings) को स्वीकार करता है, जो पूरी कॉन्फ़िगरेशन सेटिंग (configuration settings) को बदल सकता है। +3. एक plugin मापदंडों के बजाय Raw SQL या प्रोग्रामिंग स्टेटमेंट (programming statements) को स्वीकार करता है। +4. किसी plugin को स्पष्ट अनुमति दिए (authorization) बिना ही प्रमाणीकरण (authentication) किया जाता है। +5. एक plugin सारी LLM सामग्री को पूरी तरह से यूज़र द्वारा बनाई गई मानता है और बिना किसी अनुमति (authorization) के कोई भी अनुरोध स्वीकार कर लेता है। + +### बचाव कैसे करें + +1. Plugins में सख्त पैरामीटर के अनुसार इनपुट लागू करना, इनपुट पर टाइप और रेंज की जाँच शामिल करनी चाहिए। इनके आभाव में दूसरी लेयर शुरू कर अनुरोधों को पार्स, सैनिटाइज़ एवं उनकी पुष्टि करनी चाहिए। जब ऐप्लिकेशन सिमेंटिक्स की वजह से फ़्रीफ़ॉर्म इनपुट स्वीकार किया जाता है, तो यह सुनिश्चित करे कि किसी भी संभावित हानिकारक तरीके का इस्तेमाल नहीं किया जा रहा है। +2. Plugins डेवलपर्स को इनपुट की प्पुष्टि और सैनिटाइज़ेशन सुनिश्चित करने के लिए, ASVS (ऐप्लिकेशन सुरक्षा सत्यापन मानक) में दिये गये OWASP के सुझावों को लागू करना चाहिए। +3. पर्याप्त पुष्टि सुनिश्चित करने के लिए plugin की पूरी जाँच और परीक्षण किया जाना चाहिए। डेवलपमेंट पाइपलाइन (development pipelines) में स्टैटिक ऐप्लिकेशन सुरक्षा परीक्षण (SAST) स्कैन के साथ-साथ डायनामिक और इंटरैक्टिव एप्लिकेशन परीक्षण (DAST, IAST) का इस्तेमाल करें। +4. OWASP ASVS ऐक्सेस कंट्रोल दिशानिर्देशों का पालन करते हुए किसी भी असुरक्षित इनपुट पैरामीटर के इस्तेमाल के प्रभाव को कम करने के लिए plugins को डिज़ाइन किया जाना चाहिए। इसमें कम से कम विशेषाधिकार प्राप्त ऐक्सेस नियंत्रण शामिल है, जो अपना इच्छित कार्य करते समय जितना संभव हो उतनी कम कार्यक्षमता को उजागर करता है। +5. प्रभावी प्राधिकरण (effective authorization) और ऐक्सेस नियंत्रण (access control) लागू करने के लिए plugin को उपयुक्त प्रमाणीकरण पहचान (authentication identities) का इस्तेमाल करना चाहिए, जैसे कि OAuth2। इसके अलावा, एपीआई कीज़ (API Keys) का इस्तेमाल कस्टम प्राधिकरण (authorization) निर्णयों के लिए संदर्भ देने के लिए किया जाना चाहिए, जो डिफ़ॉल्ट इंटरैक्टिव यूज़र के बजाय plugin रूट को दर्शाता है। +6. संवेदनशील plugins द्वारा की गई किसी भी कार्रवाई के लिये यूज़र की अनुमति और पुष्टि की आवश्यकता होती है। +7. Plugins, आम तौर पर, REST API होते हैं, इसलिए डेवलपर्स को सामान्य कमजोरियों को कम करने के लिए OWASP के टॉप 10 API सुरक्षा जोखिमों — 2023 में दिये गये सुझावों को लागू करना चाहिए। + +### उदाहरण हमले के परिदृश्य + +1. एक plugin मूल URL को स्वीकार करता है और LLM को निर्देश देता है कि वह URL को एक क्वेरी (query) के साथ मिलाएं, ताकि यूज़र के अनुरोध पर मौसम का पूर्वानुमान प्राप्त किए जा सकें। एक दुर्भावनापूर्ण यूज़र अनुरोध पर अपने डोमेन के ज़रिये LLM सिस्टम में अपनी सामग्री इंजेक्ट कर सकते हैं। +2. एक plugin फ़ील्ड में फ़्री फ़ॉर्म इनपुट को स्वीकार करता है जिसे वह मान्य नहीं करता है। एक हमलावर पेलोड का प्रयोग करते हुये गलती के संदेशों से सारी जानकारी प्राप्त करता है। इसके बाद यह कोड निष्पादित करने और डेटा निकालने या विशेषाधिकार बढ़ाने के लिए तृतिय -पक्ष की कमजोरियों का फायदा उठाता है। +3. किसी वेक्टर स्टोर (vector store) से एम्बेडिंग प्राप्त करने के लिए इस्तेमाल किया जाने वाला एक plugin , कॉन्फ़िगरेशन पैरामीटर (configuration parameters) को कनेक्शन स्ट्रिंग (connection string) के तौर पर बिना किसी सत्यापन के स्वीकार करता है। इसकी मदद से कोई हमलावर नाम या होस्ट पैरामीटर बदलकर दूसरे वेक्टर स्टोर से भी अनाधिकृत एम्बेडिंग प्राप्त कर सकता है। +4. एक plugin “SQL WHERE” क्लॉज़ को एडवांस फ़िल्टर के रूप में स्वीकार करता है, जिन्हें बाद में फ़िल्टर करने वाले SQL में जोड़ दिया जाता है। इससे एक हमलावर SQL हमला कर सकता है। +5. एक हमलावर एक असुरक्षित कोड प्रबंधन plugin का फायदा उठाने के लिए अप्रत्यक्ष प्रॉम्प्ट इंजेक्शन का इस्तेमाल करता है, जिसमें कोई इनपुट सत्यापन नहीं होता है,इसके साथ कमज़ोर ऐक्सेस नियंत्रण से रिपॉजिटरी का स्वामित्व ट्रांसफ़र और यूज़र को उनकी रिपॉजिटरी से लॉक किया जा सकता है। + +### संदर्भ लिंक + +1. [OpenAI ChatGPT Plugins](https://platform.openai.com/docs/plugins/introduction): ChatGPT Developer’s Guide +2. [OpenAI ChatGPT Plugins - Plugin Flow](https://platform.openai.com/docs/plugins/introduction): OpenAI Documentation +3. [OpenAI ChatGPT Plugins - Authentication](https://platform.openai.com/docs/plugins/authentication): OpenAI Documentation +4. [OpenAI Semantic Search Plugin Sample](https://github.com/openai/chatgpt-retrieval-plugin): OpenAI Github +5. [Plugin Vulnerabilities](https://embracethered.com/blog/posts/2023/chatgpt-plugin-vulns-chat-with-code/): Visit a Website and Have Your Source Code Stolen: Embrace The Red +6. [ChatGPT Plugin Exploit Explained](https://embracethered.com/blog/posts/2023/chatgpt-cross-plugin-request-forgery-and-prompt-injection./): From Prompt Injection to Accessing Private Data Embrace The Red +7. [OWASP ASVS - 5 Validation, Sanitization and Encoding](https://owasp-aasvs4.readthedocs.io/en/latest/V5.html#validation-sanitization-and-encoding): OWASP AASVS +8. [OWASP ASVS 4.1 General Access Control Design](https://owasp-aasvs4.readthedocs.io/en/latest/V4.1.html#general-access-control-design): OWASP AASVS +9. [OWASP Top 10 API Security Risks](https://owasp.org/API-Security/editions/2023/en/0x11-t10/) – 2023: OWASP diff --git a/1_1_vulns/translations/hi/LLM08_ExcessiveAgency.md b/1_1_vulns/translations/hi/LLM08_ExcessiveAgency.md new file mode 100644 index 00000000..f22bb7a6 --- /dev/null +++ b/1_1_vulns/translations/hi/LLM08_ExcessiveAgency.md @@ -0,0 +1,48 @@ +## LLM08: अत्यधिक एजेंसी + +### विवरण + +LLM-आधारित सिस्टम को अक्सर उसके डेवलपर द्वारा दूसरे प्रणाली सिस्टम के साथ इंटरफेस करने और किसी प्रोम्प्ट के जवाब में कार्रवाई करने की क्षमता प्रदान की जाती है।इनपुट प्रॉम्प्ट या LLM आउटपुट के आधार पर डायनामिक रूप से निर्धारित करने के लिए किस फ़ंक्शन को लागू करना है इसका निर्णय LLM 'एजेंट' को भी सौंपा जा सकता है। + +अत्यधिक क्षमता वह कमजोरी है जिसके कारण LLM से अनपेक्षित आउटपुट के जवाब में हानिकारक कार्रवाइयां की जा सकती हैं (भले ही LLM में खराबी क्यों न हो; चाहे वह मतिभ्रम हो, प्रत्यक्ष/अप्रत्यक्ष रूप से शीघ्र इंजेक्शन हो, दुर्भावनापूर्ण plugin हो, खराब तरीके से तैयार किए गए सौम्य प्रॉम्प्ट, या सिर्फ़ खराब प्रदर्शन करने वाला मॉडल)। अत्यधिक क्षमता का मूल कारण आम तौर पर एक या एक से अधिक होता है, जैसे की अत्यधिक कार्यक्षमता, अत्यधिक अनुमतियां या अत्यधिक स्वायत्तता। + +अत्यधिक क्षमता गोपनीयता (confidentiality) , सत्यनिष्ठा (integrity) और उपलब्धता (availability) के सिद्धांतो पर कई तरह के प्रभाव डाल सकती है और यह इस बात पर निर्भर करती है कि LLM-आधारित ऐप किन सिस्टम के साथ इंटरैक्ट कर सकता है। + +### कमज़ोरी के सामान्य उदाहरण + +1. अत्यधिक कार्यक्षमता: एक LLM एजेंट एक plugin का उपयोग करता है, जिसमें ऐसे फ़ंक्शन शामिल हैं जिनकी सिस्टम के संचालन के लिए आवश्यकता नहीं है। उदाहरण के लिए, किसी डेवलपर को किसी LLM एजेंट को रिपॉज़िटरी से दस्तावेज़ पढ़ने की सुविधा देनी होती है,इसके लिये वह तीसरे पक्ष के plugin का इस्तेमाल करते हैं,जिसके पास दस्तावेज़ों को संशोधित करने और हटाने की क्षमता भी है। +2. वैकल्पिक रूप से, हो सकता है कि किसी plugin को डेवलपमेंट के किसी चरण के दौरान ट्रायल किया गया हो और उसे किसी बेहतर विकल्प के पक्ष में छोड़ दिया गया हो, लेकिन मूल plugin LLM एजेंट के लिए उपलब्ध रहेगा। +3. अत्यधिक कार्यक्षमता: ओपन-एंडेड फ़ंक्शनैलिटी वाला LLM plugin , एप्लिकेशन के संचालन के लिए आवश्यक चीज़ों में कमांड के इनपुट निर्देशों को ठीक से फ़िल्टर करने में विफल रहता है। उदाहरण के लिए, एक विशिष्ट शेल कमांड चलाने वाला plugin दूसरे शेल कमांड को निष्पादित होने से रोकने में विफल रहता है। +4. अत्यधिक अनुमतियां: LLM plugin के पास दूसरे सिस्टम पर अनुमतियां होती हैं जिनकी ऐप्लिकेशन संचालित करने के लिए ज़रूरत नहीं होती है। उदाहरण के लिए, डेटा पढ़ने के लिए बनाया गया plugin किसी पहचान का इस्तेमाल करके डेटाबेस सर्वर से कनेक्ट होता है, जिसमें न केवल SELECT की अनुमतियां होती हैं, बल्कि UPDATE, INSERT और DELETE की अनुमतियां भी होती हैं। +5. अत्यधिक अनुमतियां: एक LLM plugin जिसे यूज़र की ओर से ऑपरेशन करने के लिए बनाया गया है,वह विशेषाधिकार प्राप्त कर डाउनस्ट्रीम सिस्टम को ऐक्सेस करता है। उदाहरण के लिए, मौजूदा यूज़र के दस्तावेज़ों को पढ़ने के लिए एक plugin है, जो एक विशेषाधिकार प्राप्त खाते के साथ दस्तावेज़ रिपॉजिटरी से कनेक्ट होता है, जिसके पास सभी यूज़र की फ़ाइलों तक पहुंच होती है । +6. अत्यधिक स्वायत्तता: कोई LLM-आधारित एप्लिकेशन या plugin हाई-इम्पैक्ट कार्रवाइयों को स्वतंत्र रूप से सत्यापित करने और उन्हें मंज़ूरी देने में विफल रहता है। उदाहरण के लिए, एक plugin जो बिना किसी पुष्टि के यूज़र के दस्तावेज़ों को हटाने की अनुमति देता है। + +### बचाव कैसे करें + +निम्नलिखित कार्रवाइयों से अत्यधिक एजेंसी को रोका जा सकता है: + +1. उन plugin/टूल को ज़रूरी फ़ंक्शन तक सीमित करें जिन्हें LLM एजेंट कॉल करने की अनुमति देते हैं। उदाहरण के लिए, अगर किसी LLM-आधारित सिस्टम के लिए किसी URL की सामग्री लाने की क्षमता की आवश्यकता नहीं है, तो LLM एजेंट को ऐसा plugin नहीं दिये जाने चाहिए। +2. LLM plugin/टूल में लागू किए गए फ़ंक्शन को न्यूनतम आवश्यक तक सीमित करें। उदाहरण के लिए, एक plugin जो ईमेल को सारांशितकरता है ,उसके लिए केवल ईमेल पढ़ने की क्षमता होनी चाहिये,अन्य कार्यक्षमताएँ जैसे कि संदेश हटाने या भेजना की नहीं । +3. जहाँ संभव हो, ओपन-एंडेड फ़ंक्शन से बचें (उदाहरण के लिए, शेल कमांड चलने, URL प्राप्त करने वाले आदि) और ज़्यादा लक्षित कार्यक्षमता वाले plugin/टूल का इस्तेमाल करें। उदाहरण के लिए, किसी LLM- आधारित ऐप के लिए किसी फ़ाइल में कुछ आउटपुट लिखने की आवश्यकता हो सकती है। अगर इसे शेल फ़ंक्शन चलाने के लिए plugin का उपयोग करके लागू किया जाता, तो अवांछनीय कार्रवाइयों का दायरा बहुत बड़ जाता (कोई भी अन्य शेल कमांड निष्पादित किया जा सकता है)। एक ज़्यादा सुरक्षित विकल्प यह होगा कि एक ऐसा फ़ाइल-राइटिंग plugin बनाया जाए, जो सिर्फ़ उस खास सुविधा के साथ ही काम कर सके। +4. उन अनुमतियों को सीमित करें जो LLM plugins/टूल दूसरे सिस्टम को दी जाती हैं, ताकि अवांछनीय कार्रवाइयों का दायरा सीमित किया जा सके। उदाहरण के लिए, एक LLM एजेंट जो किसी ग्राहक को खरीदारी के सुझाव देने के लिए प्रॉडक्ट डेटाबेस का इस्तेमाल करता है, उसे सिर्फ़ 'प्रॉडक्ट' टेबल पढ़ने की ज़रूरत होगी; उसके पास दूसरी टेबल तक ऐक्सेस नहीं होनी चाहिए, न ही रिकॉर्ड डालने, अपडेट या हटाने की क्षमता होनी चाहिए। इसे उस पहचान के लिए उपयुक्त डेटाबेस अनुमतियां लागू करनी चाहिए, जिसका इस्तेमाल LLM plugin डेटाबेस से कनेक्ट करने के लिए करता है। +5. यह पक्का करने के लिए कि यूज़र की ओर से की गई कार्रवाइयां डाउनस्ट्रीम सिस्टम पर उस विशिष्ट यूज़र के संदर्भ में और न्यूनतम ज़रूरी विशेषाधिकारों के साथ निष्पादित हों, यूज़र की अनुमति और सुरक्षा क्षेत्र को ट्रैक करें। उदाहरण के लिए, एक LLM plugin जो यूज़र के कोड रेपो को पढ़ता है,तो उसे OAuth के ज़रिए और न्यूनतम स्कोप के साथ प्रमाणीकरण करना होगा। +6. सभी कार्रवाइयों को करने से पहले मानव द्वारा मंज़ूरी ले। इसे डाउनस्ट्रीम सिस्टम (LLM ऐप्लिकेशन के दायरे से बाहर) या LLM plugin /टूल में ही लागू किया जा सकता है। उदाहरण के लिए, किसी यूज़र की ओर से सोशल मीडिया कॉन्टेंट बनाने और पोस्ट करने वाले LLM-आधारित ऐप में 'पोस्ट' ऑपरेशन लागू करने वाले plugin /टूल/API में यूज़र की स्वीकृति शामिल होनी चाहिए। +7. किसी कार्रवाई की अनुमति है या नहीं, यह तय करने के लिए LLM पर निर्भर रहने के बजाय डाउनस्ट्रीम सिस्टम में प्राधिकरण (authorization) लागू करें। टूल/plugin लागू करते समय, मीडिएशन का पूरा सिद्धांत लागू करें, ताकि plugin/टूल के ज़रिये डाउनस्ट्रीम सिस्टम से किए गए सभी अनुरोधों की सुरक्षा नीतियों के तहत पुष्टि हो सके। + +निम्नलिखित विकल्प अत्यधिक एजेंसी को नहीं रोकेंगे, लेकिन इससे होने वाले नुकसान के स्तर को सीमित कर सकते हैं: +1. LLM plugin/टूल और डाउनस्ट्रीम सिस्टम की गतिविधि की निगरानी कर सूचीबद्ध करें ताकि यह पता चल सके कि अवांछनीय कार्रवाइयां कहाँ हो रही हैं और उसी के अनुसार प्रतिक्रिया दें। +2. किसी निश्चित समयावधि में होने वाली अवांछनीय कार्रवाइयों की संख्या को कम करने के लिए दर-सीमा लागू करें, इससे पहले कि महत्वपूर्ण नुकसान हो, निगरानी के ज़रिए अवांछनीय कार्रवाइयों का पता लगाने के अवसर बढ़ाएँ। + +### हमले के परिदृश्य मे उदाहरण + +LLM-आधारित व्यक्तिगत सहायक ऐप (personal assistant app) को plugin द्वारा किसी व्यक्ति के मेलबॉक्स से जोड़ा गया, जिससे की वह आने वाले emails को सारांशित करे । इसके लिये plugin को संदेशों को पढ़ने की क्षमता की आवश्यकता है, हालांकि सिस्टम डेवलपर द्वारा चुना plugin के पास संदेश भेजने की क्षमता भी हैं। अगर प्रयोग किया गया LLM अप्रत्यक्ष prompt इंजेक्शन हमले के प्रति कमजोर है, तब कोई दुर्भावनापूर्ण-ईमेल LLM को plugin द्वारा, 'send message' फनशन के प्रयोग से उपयोगकर्ता के मेलबॉक्स से स्पैम भेजने को कहता है। इससे बचने के लिये:
+(क) अत्यधिक कार्यक्षमता को घटाने के लिये, केवल पढ़ने की क्षमता वाले plugin चुने,
+(ख) अत्यधिक अनुमतियों को घटाने के लिये उपयोगकर्ता की ईमेल को केवल-पढ़ने के दायरे वाली OAuth सत्र से जोड़े,
+(ग) अत्यधिक स्वायत्तता को घटाने के लिये उपयोगकर्ता, एलएलएम प्लगइन द्वारा बने प्रत्येक मेल की समीक्षा करके ही भेजे। मेल भेजने के इंटरफ़ेस की दर सीमित करने से भी क्षति को कम किया जा सकता है। + +### संदर्भ लिंक + +1. [Embrace the Red](https://embracethered.com/blog/posts/2023/chatgpt-cross-plugin-request-forgery-and-prompt-injection./): Confused Deputy Problem: Embrace The Red +2. [NeMo-Guardrails](https://github.com/NVIDIA/NeMo-Guardrails/blob/main/docs/security/guidelines.md): Interface guidelines: NVIDIA Github +3. [LangChain: Human-approval for tools](https://python.langchain.com/docs/modules/agents/tools/human_approval): Langchain Documentation +5. [Simon Willison: Dual LLM Pattern](https://simonwillison.net/2023/Apr/25/dual-llm-pattern/): Simon Willison diff --git a/1_1_vulns/translations/hi/LLM09_Overreliance.md b/1_1_vulns/translations/hi/LLM09_Overreliance.md new file mode 100644 index 00000000..f2e84b81 --- /dev/null +++ b/1_1_vulns/translations/hi/LLM09_Overreliance.md @@ -0,0 +1,42 @@ +## LLM09: ओवररिलायंस + +### विवरण + +ज़्यादा निर्भरता तब होती है जब सिस्टम या लोग बिना पर्याप्त निरीक्षण के निर्णय लेने या कॉन्टेंट तैयार करने के लिए LLM पर निर्भर होते हैं। LLM रचनात्मक और जानकारीपूर्ण सामग्री तैयार कर सकते हैं, लेकिन वे ऐसी सामग्री भी जेनरेट कर सकते हैं जो तथ्यात्मक रूप से गलत, अनुचित या असुरक्षित हो। इसे भ्रम या उलझन कहा जाता है और इसकी वजह से ग़लत सूचना, ग़लतफ़हमी, कानूनी समस्याएं और प्रतिष्ठा को नुकसान हो सकता है। + +LLM द्वारा बनाया गया सोर्स कोड अज्ञात सुरक्षा कमजोरियों उत्पन्न कर सकता है। यह एप्लीकेशन की सुरक्षा एवं परिचालन सुरक्षा के लिए एक जोखिम पैदा करता है। ये जोखिम समीक्षा की कठोर प्रक्रिया के महत्व को दर्शाते हैं, इसके साथ: + +- ओवरसाइट (Oversight) +- सत्यापन की निरंतर व्यवस्था (Continuous validation mechanism) +- अस्वीकार्य जो जोखिम में हैं (Disclaimers on risk) + +### कमज़ोरी के सामान्य उदाहरण + +1. LLM प्रतिक्रिया के तौर पर गलत जानकारी देता है, एवं वह इन जानकारियों को अत्यधिक आधिकारिक रूप मे प्रदर्शित करता है। प्रणाली को उचित जांच और संतुलन के बिना डिज़ाइन किया गया है, जिससे यह दिक्कत संभाल नहीं पाती और परिणामस्वरूप उपयोगकर्ता को भ्रामक जानकारी मिलती है । +2. एलएलएम असुरक्षित या दोषपूर्ण कोड सुझाता है, जो उचित निरीक्षण या सत्यापन के बिना सॉफ़्टवेयर सिस्टम में शामिल होने पर कमजोरियों को जन्म देता है। + +### बचाव कैसे करें + +1. LLM आउटपुट की नियमित निगरानी और उनकी समीक्षा करें। इन्कन्सीस्टेन्ट टेक्स्ट (inconsistent text) को फ़िल्टर करने के लिए आत्म स्थिरता (self-consistency) या वोटिंग तकनीकों का इस्तेमाल करें। एक ही प्रॉम्प्ट के लिए कई मॉडल प्रतिक्रियाओं की तुलना करने से आउटपुट की गुणवत्ता और निरंतरता का बेहतर आकलन किया जा सकता है। +2. विश्वसनीय बाहरी स्रोतों से LLM आउटपुट को क्रॉस-चेक करें।अतिरिक्त पुष्टि से यह पक्का करने में मदद मिल सकती है कि मॉडल के ज़रिये दी गई जानकारी सटीक एवं भरोसेमंद है। +3. फ़ाइन-ट्यूनिंग या एम्बेडिंग की मदद से आउटपुट को बेहतर बनाएं। किसी खास क्षेत्र के किए बनाये गए मॉडल की तुलना में जेनेरिक पहले से प्रशिक्षित मॉडल से गलत जानकारी मिलने की संभावना ज़्यादा होती है। इसके लिए प्रॉम्प्ट इंजीनियरिंग (prompt engineering), पैरामीटर एफ़िशिएंट ट्यूनिंग (parameter efficient tuning), फ़ुल मॉडल ट्यूनिंग (full model tuning) और चेन ऑफ़ थॉट (chain of thought) प्रॉम्प्टिंग जैसी तकनीकों का इस्तेमाल किया जा सकता है। +4. ऑटोमैटिक सत्यापन तंत्र लागू करें, जो ज्ञात तथ्यों या डेटा के विरुद्ध जनरेट किए गए आउटपुट की क्रॉस-पुष्टि कर सके। यह सुरक्षा की एक अतिरिक्त परत प्रदान कर, मतिभ्रम से जुड़े जोखिमों को कम कर सकता है। +5. जटिल टास्क को सबटास्क में बांटें और उन्हें अलग-अलग एजेंटों को सौंपें, जो जटिलताओं को नियंत्रित करने में मदद करता है,और मतिभ्रम की संभावना को भी कम करता है क्योंकि हर एजेंट को एक छोटे से काम के लिए जिम्मेदार ठहराया जा सकता है। +6. LLM के इस्तेमाल से जुड़े जोखिमों और सीमाओं के बारे में जानकारी दे, जो प्रभावी जोखिम संचार यूज़र को संभावित समस्याओं के लिए तैयार कर सकता कर सही निर्णय लेने में मदद कर सकता है। +7. ऐसे API और यूज़र इंटरफेस बनाएं, जो LLM के ज़िम्मेदार और सुरक्षित इस्तेमाल को प्रोत्साहित करें। इसमें कॉन्टेंट फ़िल्टर, संभावित अशुद्धियों के बारे में यूज़र की चेतावनियां और AI द्वारा जेनरेट की गई सामग्री की क्लियर लेबलिंग जैसे उपाय शामिल हैं। +8. विकास के दौरान ही LLM को संभावित कमजोरियों से बचाने के लिए सुरक्षित कोडिंग तकनीके एवं दिशानिर्देशों को स्थापित करें। + +### उदाहरण हमले का परिदृश्य + +1. समाचार संगठन समाचार बनाने के लिए AI मॉडल का ज़्यादा इस्तेमाल करता है। एक दुर्भावनापूर्ण व्यक्ति इस अति-निर्भरता का फायदा उठाता है, AI को गुमराह करने वाली जानकारी देता है, जिससे गलत सूचनाएं फैलती हैं। AI ने अनजाने में ही सामग्री को प्लगिराइज़्ड ( plagiarized) कर दिया, जिससे कॉपीराइट समस्याएँ पैदा हो गईं और संगठन में विश्वास कम हो गया। +2. सॉफ़्टवेयर डेवलपमेंट टीम कोडिंग प्रक्रिया में तेज़ी लाने के लिए कोडेक्स जैसे AI सिस्टम का इस्तेमाल करती है। AI के सुझावों पर ज़्यादा भरोसा करने से सुरक्षा डिफ़ॉल्ट सेटिंग या सुरक्षित कोडिंग पद्धतियों के साथ असंगत सुझावों के कारण ऐप्लिकेशन में सुरक्षा संबंधी कमजोरियाँ आ जाती हैं। +3. एक सॉफ़्टवेयर डेवलपमेंट फर्म डेवलपर्स की सहायता के लिए LLM का इस्तेमाल करती है। LLM एक गैर-मौजूद कोड लाइब्रेरी या पैकेज का सुझाव देता है, और एक डेवलपर, जो AI पर भरोसा करता है, अनजाने में एक दुर्भावनापूर्ण पैकेज को फर्म के सॉफ़्टवेयर में इंटीग्रेट कर देता है। यह AI सुझावों को क्रॉस-चेकिंग करने के महत्व पर प्रकाश डालता है, खासकर तीसरे पक्ष के कोड या लाइब्रेरी को शामिल करते समय। + +### संदर्भ लिंक + +1. [Understanding LLM Hallucinations](https://towardsdatascience.com/llm-hallucinations-ec831dcd7786): Towards Data Science +2. [How Should Companies Communicate the Risks of Large Language Models to Users?](https://www.techpolicy.press/how-should-companies-communicate-the-risks-of-large-language-models-to-users/): Techpolicy +3. [A news site used AI to write articles. It was a journalistic disaster](https://www.washingtonpost.com/media/2023/01/17/cnet-ai-articles-journalism-corrections/): Washington Post +4. [AI Hallucinations: Package Risk](https://vulcan.io/blog/ai-hallucinations-package-risk): Vulcan.io +5. [How to Reduce the Hallucinations from Large Language Models](https://thenewstack.io/how-to-reduce-the-hallucinations-from-large-language-models/): The New Stack +6. [Practical Steps to Reduce Hallucination](https://newsletter.victordibia.com/p/practical-steps-to-reduce-hallucination): Victor Debia diff --git a/1_1_vulns/translations/hi/LLM10_ModelTheft.md b/1_1_vulns/translations/hi/LLM10_ModelTheft.md new file mode 100644 index 00000000..fc838257 --- /dev/null +++ b/1_1_vulns/translations/hi/LLM10_ModelTheft.md @@ -0,0 +1,55 @@ +## LLM10: मॉडल चोरी + +### विवरण + +यह दुर्भावनापूर्ण व्यक्तियों या APTs द्वारा LLM मॉडल में अनधिकृत पहुंच और घुसपैठ को संदर्भित करती है। यह तब होता है जब LLM मॉडल (मूल्यवान बौद्धिक संपदा होने के नाते),के साथ छेड़छाड़ की जाती है, भौतिक रूप से चोरी हो जाते हैं, कॉपी किए जाते हैं या एक कार्यात्मक समकक्ष बनाने के लिए वज़न और पैरामीटर निकाले जाते हैं। LLM मॉडल की चोरी के प्रभाव में आर्थिक और ब्रांड प्रतिष्ठा खोना, प्रतिस्पर्धात्मक लाभ में कमी, मॉडल का अनधिकृत उपयोग या मॉडल में मौजूद संवेदनशील जानकारी तक अनधिकृत पहुंच शामिल हो सकती है। + +LLM की चोरी सुरक्षा के लिए एक महत्वपूर्ण चिंता का विषय है क्योंकि भाषा मॉडल तेजी से शक्तिशाली और प्रचलित होते जा रहे हैं। संगठनों और शोधकर्ताओं को अपने LLM मॉडल की सुरक्षा के लिए मज़बूत सुरक्षा उपायों को प्राथमिकता देनी चाहिए, जिससे उनकी बौद्धिक संपदा की गोपनीयता और सत्यनिष्ठा बनी रहे। LLM मॉडल चोरी से जुड़े जोखिमों को कम करने और LLM पर निर्भर व्यक्तियों और संगठनों दोनों के हितों की सुरक्षा करने के लिए एक व्यापक सुरक्षा ढांचे का इस्तेमाल करना, जिसमें ऐक्सेस नियंत्रण, एन्क्रिप्शन और निरंतर निगरानी शामिल है तथा महत्वपूर्ण है। + +### कमज़ोरी के सामान्य उदाहरण + +1. एक हमलावर कंपनी के कमजोर इंफ्रास्ट्रक्चर का फायदा उठा, कंपनी के नेटवर्क या ऐप्लिकेशन सुरक्षा सेटिंग में ग़लतफ़हमी के ज़रिए LLM मॉडल रिपॉजिटरी तक अनधिकृत पहुंच बनता है। +2. अंदरूनी खतरे का परिदृश्य जहां एक असंतुष्ट कर्मचारी किसी मॉडल या उससे जुड़ी सामग्री को लीक कर देता है। +3. एक हमलावर API से सावधानी से तैयार किए गए इनपुट और प्रॉम्प्ट इंजेक्शन तकनीकों का इस्तेमाल करके पूछताछ करता है, जिससे की शैडो मॉडल बनाने के लिए पर्याप्त संख्या में आउटपुट प्राप्त होते है। +4. एक दुर्भावनापूर्ण हमलावर एक साइड-चैनल हमला करने के लिए LLM की इनपुट फ़िल्टरिंग तकनीकों को दरकिनार कर सकता है और अंतत: रिमोट नियंत्रित संसाधन का उपयोग करके मॉडल के आर्किटेक्चर और उससे जुडी जानकारियां हासिल कर सकता है। +5. मॉडल एक्सट्रैक्शन के अटैक वेक्टर में किसी खास विषय पर बड़ी संख्या में प्रॉम्प्ट्स के साथ LLM से पूछताछ करना शामिल है। इसके बाद LLM के आउटपुट का इस्तेमाल किसी दूसरे मॉडल को ठीक करने के लिए किया जा सकता है। हालाँकि, इस हमले के बारे में कुछ बातें ध्यान देने योग्य हैं:। + - हमलावर को बड़ी संख्या में लक्षित प्रोम्प्ट जेनरेट करने होंगे। अगर प्रोम्प्ट पर्याप्त नहीं हैं, तो LLM से मिलने वाले आउटपुट बेकार होंगे। + - LLM के आउटपुट में कभी-कभी बेहूदा जवाब हो सकते हैं, मतलब हमलावर पूरे मॉडल को निकालने में सक्षम नहीं हो सकता क्योंकि कुछ आउटपुट बेतुके हो सकते हैं। + - मॉडल एक्सट्रैक्शन के ज़रिये किसी LLM को 100% बनाना संभव नहीं है। हालांकि, हमलावर एक अपूर्ण (partial) मॉडल बना सकता है। +6. फ़ंक्शनल मॉडल रेप्लिकेशन के अटैक वेक्टर में सिंथेटिक प्रशिक्षण डेटा (“सेल्फ़-इंस्ट्रक्ट” नामक दृष्टिकोण) जेनरेट करने के लिए प्रॉम्प्ट्स को लक्षित मॉडल पर उपयोग करना, फिर उसका इस्तेमाल कर किसी अन्य मूलभूत मॉडल को फ़ाइन-ट्यून करना शामिल है। यह उदाहरण 5 में इस्तेमाल किए गए पारंपरिक क्वेरी-आधारित (query-based) एक्सट्रैक्शन की सीमाओं को दरकिनार कर देता है और शोध कार्य के लिये किसी अन्य LLM को प्रशिक्षित करने के लिए सफलतापूर्वक इस्तेमाल करता है। हालांकि इस शोध के संदर्भ में, मॉडल रेप्लिकेशन कोई हमला नहीं है। इस दृष्टिकोण का इस्तेमाल एक हमलावर किसी मालिकाना मॉडल को सार्वजनिक API की मदद से बनाने के लिए कर सकता है। + +किसी चोरी हुए मॉडल का इस्तेमाल, शैडो मॉडल के तौर पर, प्रतिकूल हमलों को स्टेज करने के लिए किया जा सकता है, जिसमें मॉडल में मौजूद संवेदनशील जानकारी तक अनाधिकृत पहुंच एवं एडवांस प्रॉम्प्ट इंजेक्शन को आगे बढ़ाने के लिए प्रतिकूल इनपुट के साथ प्रयोग करना शामिल है, जिसका पता नहीं चलता है। + +### बचाव कैसे करें + +1. LLM मॉडल रिपॉजिटरी और प्रशिक्षण वातावरण तक अनधिकृत पहुंच को सीमित करने के लिए मज़बूत ऐक्सेस नियंत्रण (जैसे, RBAC और कम से कम विशेषाधिकार का नियम) और मज़बूत प्रमाणीकरण (authentication) तंत्र लागू करें। + - यह पहले तीन सामान्य उदाहरणों के लिए खास तौर पर सही है, जो अंदरूनी खतरों, गलत कॉन्फ़िगरेशन और/या इंफ्रास्ट्रक्चर के बारे में कमज़ोर सुरक्षा नियंत्रण के कारण इस जोखिम का कारण बन सकते हैं, जिसमें LLM मॉडल, वज़न और आर्किटेक्चर मौजूद हैं, जिसमें एक दुर्भावनापूर्ण व्यक्ति वातावरण के अंदर या बाहर से घुसपैठ कर सकता है। + - सप्लाई-चेन के हमलों को रोकने के लिए आपूर्तिकर्ता प्रबंधन ट्रैकिंग, सत्यापन और निर्भरता की कमजोरियाँ महत्वपूर्ण विषय हैं। +2. नेटवर्क संसाधनों, आंतरिक सेवाओं और API तक LLM की पहुँच को प्रतिबंधित करें। + - यह सभी सामान्य उदाहरणों के लिए खास तौर पर सही है क्योंकि यह अंदरूनी जोखिमों और खतरों को कवर करता है, अंत में यह नियंत्रित करता है कि LLM एप्लिकेशन की पहुंच कहा तक है और इसलिए यह साइड-चैनल हमलों को रोकने के लिए एक तंत्र हो सकता है। +3. उत्पादन वाले एमएल मॉडल के लिए एक केंद्रीकृत एमएल मॉडल इन्वेंटरी या रजिस्ट्री का उपयोग करें। यह होने से एक्सेस नियंत्रण, प्रमाणीकरण और निगरानी/लॉगिंग के माध्यम से LLM मॉडल तक अनधिकृत पहुंच को रोका जा सकता है जो गवर्नन्स (governance) के लिए नींव हैं। यह अनुपालन, जोखिम मूल्यांकन और जोखिम शमन के लिए मॉडलों द्वारा प्रयोग की गई एल्गोरिदम के बारे में डेटा एकत्र करने के लिए भी फायदेमंद है। +4. किसी भी संदिग्ध या अनधिकृत व्यवहार का तुरंत पता लगाने और उसका जवाब देने के लिए, LLM मॉडल रिपॉजिटरी से संबंधित एक्सेस लॉग और गतिविधियों की नियमित रूप से निगरानी करें और उनका ऑडिट करें। +5. इंफ्रास्ट्रक्चर में ऐक्सेस और डिप्लॉयमेंट नियंत्रणों को बेहतर बनाने के लिए, गवर्नेंस, ट्रैकिंग और कार्यप्रवाह की मंज़ूरी की मदद से MLOP के डिप्लॉयमेंट को स्वचालित करें। +6. साइड-चैनल अटैक की वजह से प्रॉम्प्ट इंजेक्शन तकनीकों के जोखिम को कम करने के लिए नियंत्रण और शमन रणनीतियां लागू करें। +7. API कॉल फ़िल्टर की दर सीमित कर, LLM ऐप्लिकेशन से डेटा में घुसपैठ के जोखिम को कम किया जा सकता है, या अन्य निगरानी प्रणालियों से (जैसे, DLP) निकास की गतिविधि का पता लगाने के लिए तकनीकों को लागू किया जा सकता है। +8. निष्कर्ष संबंधी प्रश्नों का पता लगाने और भौतिक सुरक्षा उपायों को मजबूत करने में मदद करने के लिए प्रतिकूल एवं सुदृढ़ प्रशिक्षण लागू करें। +9. LLM के जीवनचक्र में एम्बेडिंग और खोजने के चरणों में वॉटरमार्किंग फ़्रेमवर्क लागू करें। + +### उदाहरण हमले का परिदृश्य + +1. एक हमलावर किसी कंपनी के LLM मॉडल भंडार तक अनधिकृत पहुंच प्राप्त करने के लिए उसके बुनियादी ढांचे में कमजोरियों का फायदा उठाता है। इसके बाद हमलावर मूल्यवान LLM मॉडलों में घुसबैठ करता है। जिसका इस्तेमाल वह प्रतिस्पर्धी भाषा प्रोसेसिंग सेवा शुरू करने या संवेदनशील जानकारी निकालने के लिए करता है, जिससे कंपनी को काफी आर्थिक नुकसान होता है। +2. एक असंतुष्ट कर्मचारी मॉडल या उससे संबंधित जानकारिया लीक कर देता है। इन जानकारियों के सार्वजनिक प्रदर्शन से हमलावरों के लिए ग्रे बॉक्स प्रतिकूल हमला तथा संपत्ति की सीधा चोरी आसान हो गया । +3. एक हमलावर सावधानी से चुने गए इनपुट के साथ API से पूछताछ करता है और शैडो मॉडल बनाने के लिए पर्याप्त संख्या में आउटपुट इकट्ठा करता है। +4. एक सुरक्षा नियंत्रण विफलता सप्लाई चेन के भीतर मौजूद है जो मालिकाना मॉडल जानकारी के डेटा लीक की ओर ले जाती है। +5. एक दुर्भावना वाला हमलावर साइड-चैनल हमला करने और अपने नियंत्रण के तहत रिमोट नियंत्रित संसाधन पर मॉडल जानकारी पुनर्प्राप्त करने के लिए इनपुट फ़िल्टरिंग तकनीकों और LLM की प्रस्तावना को बायपास करता है। + +### संदर्भ लिंक + +1. [Meta’s powerful AI language model has leaked online](https://www.theverge.com/2023/3/8/23629362/meta-ai-language-model-llama-leak-online-misuse): The Verge +2. [Runaway LLaMA | How Meta's LLaMA NLP model leaked](https://www.deeplearning.ai/the-batch/how-metas-llama-nlp-model-leaked/): Deep Learning Blog +3. [AML.TA0000 ML Model Access](https://atlas.mitre.org/tactics/AML.TA0000/): MITRE ATLAS +4. [I Know What You See](https://arxiv.org/pdf/1803.05847.pdf): Arxiv White Paper +5. [D-DAE: Defense-Penetrating Model Extraction Attacks](https://www.computer.org/csdl/proceedings-article/sp/2023/933600a432/1He7YbsiH4c): Computer.org +6. [A Comprehensive Defense Framework Against Model Extraction Attacks](https://ieeexplore.ieee.org/document/10080996): IEEE +7. [Alpaca: A Strong, Replicable Instruction-Following Model](https://crfm.stanford.edu/2023/03/13/alpaca.html): Stanford Center on Research for Foundation Models (CRFM) +8. [How Watermarking Can Help Mitigate The Potential Risks Of LLMs?](https://www.kdnuggets.com/2023/03/watermarking-help-mitigate-potential-risks-llms.html): KD Nuggets diff --git a/1_1_vulns/translations/pt/LLM00_Introduction.md b/1_1_vulns/translations/pt/LLM00_Introduction.md new file mode 100644 index 00000000..fbf04201 --- /dev/null +++ b/1_1_vulns/translations/pt/LLM00_Introduction.md @@ -0,0 +1,94 @@ + +
+ +
+ OWASP Top 10 para aplicações LLM +
+
+ Versão 1.0 +
+
+ Publicado: em 31 de dezembro de 2023 +
+
+ HTTPS://LLMTOP10.COM +
+
+ +## Introdução + +### A Origem da Lista +O frenesi e interesse nos Modelos de Linguagem de Grande Porte (LLMs) após os chatbots pré-treinados do mercado em massa no final de 2022 tem sido notável. Empresas, ansiosas para aproveitar o potencial dos LLMs, estão rapidamente integrando-os em suas operações e ofertas de solução voltadas para os clientes. No entanto, a velocidade vertiginosa com que os LLMs estão sendo adotados superou o estabelecimento de protocolos de segurança abrangentes, deixando muitas aplicações vulneráveis a problemas de alto risco. + +A ausência de um recurso unificado que aborde essas preocupações de segurança nos LLMs era evidente. Desenvolvedores, não familiarizados com os riscos específicos associados aos LLMs, ficaram com recursos dispersos e a missão da OWASP parece se encaixar perfeitamente para ajudar a promover uma adoção mais segura dessa tecnologia. + +### Publico-Alvo? +Nosso público-alvo é composto por desenvolvedores, cientistas de dados e especialistas em segurança encarregados de projetar e construir aplicativos e plug-ins utilizando as tecnologias LLM. Nosso objetivo é fornecer orientações de segurança práticas, aplicáveis e concisas que ajudem esses profissionais a navegar no complexo terreno da segurança em LLM que está em constante evolução + +### A Criação da Lista +A criação da lista OWASP Top 10 para LLMs foi um projeto muito importante, construído com base na expertise coletiva de uma equipe internacional de quase 500 especialistas, com mais de 125 colaboradores ativos. Nossos colaboradores vêm de diferentes origens, incluindo empresas de IA (Inteligência Artificial), empresas de segurança, ISVs (Fornecedor de Software Independente), provedores de serviço na nuvem, fornecedores de hardware e setor acadêmico. + +Ao longo de um mês, discutimos e propusemos vulnerabilidades potenciais, com membros da equipe escrevendo 43 ameaças distintas. Por meio de várias rodadas de votação, refinamos essas propostas para uma lista concisa das dez vulnerabilidades mais críticas. Cada vulnerabilidade foi então examinada e refinada por subequipes dedicadas e submetida a uma revisão pública, garantindo a lista final que é mais abrangente e aplicável. + +Cada uma dessas vulnerabilidades, juntamente com exemplos comuns, dicas de prevenção, cenários de ataque e suas referências, foram examinadas e refinadas ainda mais por subequipes dedicadas e submetidas a revisão pública, garantindo a lista final que é mais abrangente e aplicável. + +### Relação com outras Listas OWASP Top 10 +Embora esta lista compartilhe características com tipos de vulnerabilidades encontradas em outras listas OWASP Top 10, não reiteramos simplesmente essas vulnerabilidades. Em vez disso, aprofundamos nas implicações que são únicas à essas vulnerabilidades e a relação que elas têm ao serem encontradas em aplicações que utilizam os LLMs. + +Nosso objetivo é unir os princípios gerais de segurança de aplicações com os desafios específicos apresentados pelos LLMs. Isso inclui explorar como vulnerabilidades convencionais podem representar riscos diferentes ou serem exploradas de maneiras novas nos LLMs, além de como as estratégias tradicionais de remediação de problemas precisam ser adaptadas para aplicações que utilizam os LLMs. + +### Sobre a Versão 1.1 + + +### Steve Wilson +Líder do Projeto, OWASP Top 10 para Aplicações de IA LLM +[https://www.linkedin.com/in/wilsonsd](https://www.linkedin.com/in/wilsonsd/) +Twitter/X: @virtualsteve + +### Ads Dawson +v1.1 release Lead & Vulnerability Entries Lead, OWASP Top 10 para Aplicações de IA LLM +[https://www.linkedin.com/in/adamdawson0](https://www.linkedin.com/in/adamdawson0/) +GitHub：@GangGreenTemperTatum + + +## Sobre esta tradução +### Versão 1.1 Colaboradores da Tradução para o Português Brasileiro + +- **Emmanuel Guilherme Junior** +[https://www.linkedin.com/in/emmanuelgjr/](https://www.linkedin.com/in/emmanuelgjr/) +- **Rubens Zimbres** +[https://www.linkedin.com/in/rubens-zimbres/](https://www.linkedin.com/in/rubens-zimbres/) + + +Reconhecendo a natureza excepcionalmente técnica e crítica do OWASP Top 10 para Aplicações de IA LLM, optamos conscientemente por empregar apenas tradutores humanos na criação desta tradução. Os tradutores listados acima não só possuem um profundo conhecimento do conteúdo original, mas também a fluência necessária para tornar esta tradução um sucesso. + +Talesh Seeparsan +Líder de Tradução, OWASP Top 10 para Aplicações de IA LLM +[https://www.linkedin.com/in/talesh/](https://www.linkedin.com/in/talesh/) + + + +## OWASP Top 10 para Aplicações de IA LLM + +### LLM01: Injeção de Prompt +Isso manipula o modelo de linguagem de grande porte (LLM) por meio da manipulação de prompt, gerando ações não intencionais pelo LLM. Injeções diretas sobrescrevem prompts do sistema, enquanto as indiretas manipulam entradas de fontes externas para um resultado determinado. +### LLM02: Manipulação Insegura de Output +Essa vulnerabilidade ocorre quando o output de um LLM é aceito sem ser escrutinado, expondo os sistemas de backend. O uso indevido pode levar a consequências graves, como XSS, CSRF, SSRF, escalonamento de privilégios ou execução remota de código. +### LLM03: Envenenamento dos Dados de Treinamento +Essa vulnerabilidade ocorre quando os dados de treinamento do LLM são adulterados, introduzindo vulnerabilidades ou vieses que comprometem a segurança, eficácia ou comportamento ético. As fontes incluem Common Crawl, WebText, OpenWebText e livros. +### LLM04: Negação de Serviço ao Modelo +Adversários geram operações intensivas nos recursos dos LLMs, levando à degradação do serviço ou a custos muito elevados. A vulnerabilidade é ampliada devido à natureza intensiva por parte de recursos dos LLMs e a imprevisibilidade de entradas pelo usuário. +### LLM05: Vulnerabilidades na Cadeia de Suprimentos +O ciclo de vida de aplicativos LLM pode ser comprometido por componentes ou serviços vulneráveis, levando a ataques na segurança. O uso de conjuntos de dados advindo de terceiros, modelos pré-treinados e plug-ins podem adicionar vulnerabilidades. +### LLM06: Divulgação de Informações Sensíveis +Os LLMs podem inadvertidamente revelar dados confidenciais em suas respostas, levando ao acesso não autorizado dos dados, violações de privacidade e violações de segurança. É crucial implementar a higienização dos dados e implementar políticas de usuários rigorosas para mitigar isso. +### LLM07: Design Inseguro de Plug-ins +Os plug-ins dos LLMs podem ter entradas inseguras e controle de acesso insuficiente. Essa falta de controle do aplicativo torna-os mais fáceis de explorar e pode resultar em consequências como execução remota de código. +### LLM08: Autoridade Excessiva +Sistemas baseados nas LLMs podem realizar ações que levam a consequências não intencionais. O problema surge da funcionalidade excessiva, permissões ou autonomia concedidas aos sistemas baseados nas LLMs. +### LLM09: Dependência Excessiva +Sistemas ou pessoas excessivamente dependentes nas LLMs sem supervisão podem enfrentar desinformação, má comunicação, problemas legais e vulnerabilidades de segurança devido a conteúdo incorreto ou inadequado gerado pela LLMs. +### LLM10: Roubo do Modelo +Isso envolve acesso não autorizado, cópia ou vazamento de modelos de LLM proprietários. O impacto inclui perdas econômicas, comprometimento da vantagem competitiva e potencial acesso a informações sensíveis. diff --git a/1_1_vulns/translations/pt/LLM01_PromptInjection.md b/1_1_vulns/translations/pt/LLM01_PromptInjection.md new file mode 100644 index 00000000..1908f3a1 --- /dev/null +++ b/1_1_vulns/translations/pt/LLM01_PromptInjection.md @@ -0,0 +1,55 @@ +## LLM01: Injeção de Prompt + +### Descrição + +A Vulnerabilidade de Injeção de Prompt ocorre quando um atacante manipula um grande modelo de linguagem (LLM) por meio de entradas manipuladas, fazendo com que o LLM execute as intenções do atacante sem o seu conhecimento. Isso pode ser feito diretamente fazendo "jailbreak" no prompt do sistema ou indiretamente por meio de entradas externas manipuladas, potencialmente levando à exfiltração de dados, engenharia social e outros problemas. + +* **Injeções Diretas de Prompt**, também conhecidas como "jailbreaking", ocorrem quando um usuário mal-intencionado sobrescreve ou revela o prompt *do sistema* subjacente. Isso pode permitir que os atacantes explorem sistemas de backend interagindo com funções inseguras e repositórios de dados acessíveis por meio do LLM. +* **Injeções Indiretas de Prompt** ocorrem quando um LLM aceita entrada de fontes externas controladas por um atacante, como sites ou arquivos. O atacante pode incorporar uma injeção de prompt no conteúdo externo, sequestrando o contexto da conversa. Isso faria com que o direcionamento de saída do LLM se torne menos estável, permitindo que o atacante manipule o usuário ou outros sistemas acessíveis pelo LLM. Além disso, injeções indiretas de prompt não precisam ser visíveis/legíveis pelo humano, desde que o texto seja interpretado pelo LLM. + +Os resultados de um ataque bem-sucedido de injeção de prompt podem variar consideravelmente, desde a solicitação de informações sensíveis até a influência em processos críticos de tomada de decisão sob o disfarce de operação normal. + +Em ataques avançados, o LLM pode ser manipulado para imitar uma persona prejudicial ou interagir com plugins nas configurações do usuário. Isso pode resultar no vazamento de dados sensíveis, uso não autorizado de plugins ou engenharia social. Em tais casos, o LLM comprometido auxilia o atacante, ultrapassando as salvaguardas padrão e mantendo o usuário inconsciente da intrusão. Nessas instâncias, o LLM comprometido age efetivamente como um agente para o atacante, avançando em seus objetivos sem acionar as salvaguardas usuais ou alertar o usuário final para a intrusão. + +### Exemplos Comuns desta Vulnerabilidade + +1. Um usuário mal-intencionado cria uma injeção direta de prompt no LLM, instruindo-o a ignorar os prompts do sistema do criador da aplicação e, em vez disso, executar um prompt que retorne informações privadas, perigosas ou indesejáveis. +2. Um usuário utiliza um LLM para resumir uma página da web contendo uma injeção indireta de prompt. Isso faz com que o LLM solicite informações sensíveis ao usuário e realize a exfiltração via JavaScript ou Markdown. +3. Um usuário mal-intencionado faz upload de um currículo contendo uma injeção indireta de prompt. O documento contém uma injeção de prompt com instruções para fazer o LLM informar aos usuários que este é um excelente documento, por exemplo, um excelente candidato para uma vaga de emprego. Um usuário interno executa o documento no LLM para resumir o conteúdo. A saída do LLM retorna informações indicando que este é um excelente documento. +4. Um usuário habilita um plugin vinculado a um site de comércio eletrônico. Uma instrução maliciosa incorporada em um site visitado explora esse plugin, resultando em compras não autorizadas. +5. Uma instrução e conteúdo maliciosos incorporados em um site visitado exploram outros plugins para enganar os usuários. + +### Estratégias de Prevenção e Mitigação + +Vulnerabilidades de injeção de prompt são possíveis devido à natureza dos LLMs, que não segregam instruções e dados externos entre si. Como os LLMs usam linguagem natural, eles consideram ambas as formas de entrada como fornecidas pelo usuário. Consequentemente, não há prevenção infalível dentro do LLM, mas as seguintes medidas podem mitigar o impacto das injeções de prompt: + +1. Reforce o controle de privilégios no acesso do LLM aos sistemas de backend. Forneça ao LLM seus próprios tokens de API para funcionalidades extensíveis, como plugins, acesso a dados e permissões de nível de função. Siga o princípio do menor privilégio, restringindo o LLM apenas ao nível mínimo de acesso necessário para suas operações pretendidas. +2. Adicione um humano no processo para funcionalidades estendidas. Ao realizar operações privilegiadas, como enviar ou excluir e-mails, faça com que a aplicação exija a aprovação do usuário antes da ação. Isso reduz a oportunidade para injeções indiretas de prompt resultarem em ações não autorizadas em nome do usuário sem o conhecimento ou consentimento dele. +3. Separe o conteúdo externo dos prompts do usuário. Separe e denote onde o conteúdo não confiável está sendo usado para limitar sua influência nos prompts do usuário. Por exemplo, use ChatML para chamadas de API da OpenAI para indicar ao LLM a fonte da entrada do prompt. +4. Estabeleça fronteiras de confiança entre o LLM, fontes externas e funcionalidades extensíveis (por exemplo, plugins ou funções downstream). Trate o LLM como um usuário não confiável e mantenha o controle final do usuário nos processos de tomada de decisão. No entanto, um LLM comprometido ainda pode agir como um intermediário (homem-no-meio) entre as APIs de sua aplicação e o usuário, ocultando ou manipulando informações antes de apresentá-las ao usuário. Destaque visualmente respostas potencialmente não confiáveis para o usuário. +5. Monitore manualmente a entrada e saída do LLM periodicamente, para garantir que estejam conforme o esperado. Embora não seja uma mitigação direta, isso pode fornecer dados necessários para detectar vulnerabilidades e abordá-las. + +### Exemplos de Cenários de Ataque + +1. Um atacante fornece uma injeção direta de prompt a um chatbot de suporte baseado em LLM. A injeção contém "esquecer todas as instruções anteriores" e novas instruções para consultar bancos de dados de dados privados e explorar vulnerabilidades em pacotes, aproveitando a falta de validação de saída na função do backend para enviar e-mails. Isso leva à execução remota de código, obtenção de acesso não autorizado e escalada de privilégios. +2. Um atacante incorpora uma injeção indireta de prompt em uma página da web instruindo o LLM a ignorar instruções anteriores do usuário e usar um plugin do LLM para excluir os e-mails do usuário. Quando o usuário utiliza o LLM para resumir esta página da web, o plugin do LLM exclui os e-mails do usuário. +3. Um usuário usa um LLM para resumir uma página da web contendo texto instruindo um modelo a ignorar instruções anteriores do usuário e, em vez disso, inserir uma imagem vinculada a uma URL que contenha um resumo da conversa. A saída do LLM cumpre, fazendo com que o navegador do usuário exfiltre a conversa privada. +4. Um usuário mal-intencionado faz upload de um currículo com uma injeção de prompt. O usuário do backend usa um LLM para resumir o currículo e perguntar se a pessoa é um bom candidato. Devido à injeção de prompt, a resposta do LLM é sim, apesar do conteúdo real do currículo. +5. Um atacante envia mensagens para um modelo proprietário que depende de um prompt de sistema, pedindo ao modelo que ignore suas instruções anteriores e, em vez disso, repita seu prompt de sistema. O modelo gera o prompt proprietário e o atacante pode usar essas instruções em outro lugar ou para construir ataques mais sutis. + +### Links de Referência + +1. [Prompt injection attacks against GPT-3](https://simonwillison.net/2022/Sep/12/prompt-injection/) **Simon Willison** +2. [ChatGPT Plugin Vulnerabilities - Chat with Code](https://embracethered.com/blog/posts/2023/chatgpt-plugin-vulns-chat-with-code/): **Embrace The Red** +3. [ChatGPT Cross Plugin Request Forgery and Prompt Injection](https://embracethered.com/blog/posts/2023/chatgpt-cross-plugin-request-forgery-and-prompt-injection./): **Embrace The Red** +4. [Not what you’ve signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection](https://arxiv.org/pdf/2302.12173.pdf): **Arxiv preprint** +5. [Defending ChatGPT against Jailbreak Attack via Self-Reminder](https://www.researchsquare.com/article/rs-2873090/v1): **Research Square** +6. [Prompt Injection attack against LLM-integrated Applications](https://arxiv.org/abs/2306.05499): **Arxiv preprint** +7. [Inject My PDF: Prompt Injection for your Resume](https://kai-greshake.de/posts/inject-my-pdf/): **Kai Greshake** +8. [ChatML for OpenAI API Calls](https://github.com/openai/openai-python/blob/main/chatml.md): **OpenAI Github** +9. [Threat Modeling LLM Applications](http://aivillage.org/large%20language%20models/threat-modeling-llm/): **AI Village** +10. [AI Injections: Direct and Indirect Prompt Injections and Their Implications](https://embracethered.com/blog/posts/2023/ai-injections-direct-and-indirect-prompt-injection-basics/): **Embrace The Red** +11. [Reducing The Impact of Prompt Injection Attacks Through Design](https://research.kudelskisecurity.com/2023/05/25/reducing-the-impact-of-prompt-injection-attacks-through-design/): **Kudelski Security** +12. [Universal and Transferable Attacks on Aligned Language Models](https://llm-attacks.org/): **LLM-Attacks.org** +13. [Indirect prompt injection](https://kai-greshake.de/posts/llm-malware/): **Kai Greshake** +14. [Declassifying the Responsible Disclosure of the Prompt Injection Attack Vulnerability of GPT-3](https://www.preamble.com/prompt-injection-a-critical-vulnerability-in-the-gpt-3-transformer-and-how-we-can-begin-to-solve-it): **Preamble; earliest disclosure of Prompt Injection** diff --git a/1_1_vulns/translations/pt/LLM02_InsecureOutputHandling.md b/1_1_vulns/translations/pt/LLM02_InsecureOutputHandling.md new file mode 100644 index 00000000..dc76e6ab --- /dev/null +++ b/1_1_vulns/translations/pt/LLM02_InsecureOutputHandling.md @@ -0,0 +1,42 @@ +## LLM02: Manipulação Insegura de Output + +### Descrição + +A Manipulação Insegura de Output refere-se especificamente à validação, sanitização e tratamento insuficientes das saídas geradas por modelos de linguagem grandes (LLMs) antes de serem encaminhadas para outros componentes e sistemas. Como o conteúdo gerado pelo LLM pode ser controlado pela entrada do prompt, esse comportamento é semelhante a fornecer aos usuários acesso indireto a funcionalidades adicionais. + +A Manipulação Insegura de Output difere da Dependência Excessiva, pois lida com as saídas geradas pelo LLM antes de serem encaminhadas, enquanto a Dependência Excessiva se concentra em preocupações mais amplas em torno da superdependência da precisão e adequação das saídas do LLM. + +A exploração bem-sucedida de uma vulnerabilidade de Manipulação Insegura de Output pode resultar em XSS e CSRF em navegadores da web, bem como SSRF, escalonamento de privilégios ou execução remota de código em sistemas de backend. + +As seguintes condições podem aumentar o impacto dessa vulnerabilidade: + +- A aplicação concede privilégios ao LLM além do que é destinado aos usuários finais, possibilitando a escalada de privilégios ou a execução remota de código. +- A aplicação é vulnerável a ataques de injeção de prompt indireta, o que pode permitir que um atacante ganhe acesso privilegiado ao ambiente de um usuário-alvo. +- Plugins de terceiros que não validam adequadamente as entradas. + +### Exemplos Comuns desta Vulnerabilidade + +- A saída do LLM é inserida diretamente em um shell do sistema ou função semelhante, como exec ou eval, resultando na execução remota de código. +- JavaScript ou Markdown é gerado pelo LLM e retornado a um usuário. O código é então interpretado pelo navegador, resultando em XSS. + +### Estratégias de Prevenção e Mitigação + +- Trate o modelo como qualquer outro usuário, adotando uma abordagem de confiança zero, e aplique validação adequada nas respostas provenientes do modelo para funções de backend. +- Siga as diretrizes do OWASP ASVS (Application Security Verification Standard) para garantir uma validação e sanitização eficazes de entrada. +- Codifique a saída do modelo de volta para os usuários para mitigar a execução indesejada de código JavaScript ou Markdown. O OWASP ASVS fornece orientações detalhadas sobre codificação de saída. + +### Exemplos de Cenários de Ataque + +1. Uma aplicação utiliza um plugin de LLM para gerar respostas para uma funcionalidade de chatbot. O plugin também oferece diversas funções administrativas acessíveis a outro LLM privilegiado. O LLM de propósito geral passa diretamente sua resposta, sem uma validação adequada de saída, para o plugin, causando o desligamento do plugin para manutenção. +2. Um usuário utiliza uma ferramenta de resumo de site alimentada por um LLM para gerar um resumo conciso de um artigo. O site inclui uma injeção de prompt instruindo o LLM a capturar conteúdo sensível do site ou da conversa do usuário. A partir daí, o LLM pode codificar os dados sensíveis e enviá-los, sem validação ou filtragem adequada de saída, para um servidor controlado pelo atacante. +3. Um LLM permite que os usuários criem consultas SQL para um banco de dados de backend por meio de uma funcionalidade semelhante a um chat. Um usuário solicita uma consulta para excluir todas as tabelas do banco de dados. Se a consulta elaborada pelo LLM não for examinada cuidadosamente, todas as tabelas do banco de dados serão excluídas. +4. Um aplicativo da web usa um LLM para gerar conteúdo a partir de prompts de texto do usuário sem sanitização de saída. Um atacante pode enviar um prompt manipulado fazendo com que o LLM retorne uma carga útil de JavaScript não sanitizada, resultando em XSS quando renderizado no navegador da vítima. A validação insuficiente dos prompts possibilitou esse ataque. + +### Links de Referência + +1. [Arbitrary Code Execution](https://security.snyk.io/vuln/SNYK-PYTHON-LANGCHAIN-5411357): **Snyk Security Blog** +2. [ChatGPT Plugin Exploit Explained: From Prompt Injection to Accessing Private Data](https://embracethered.com/blog/posts/2023/chatgpt-cross-plugin-request-forgery-and-prompt-injection./): **Embrace The Red** +3. [New prompt injection attack on ChatGPT web version. Markdown images can steal your chat data.](https://systemweakness.com/new-prompt-injection-attack-on-chatgpt-web-version-ef717492c5c2?gi=8daec85e2116): **System Weakness** +4. [Don’t blindly trust LLM responses. Threats to chatbots](https://embracethered.com/blog/posts/2023/ai-injections-threats-context-matters/): **Embrace The Red** +5. [Threat Modeling LLM Applications](https://aivillage.org/large%20language%20models/threat-modeling-llm/): **AI Village** +6. [OWASP ASVS - 5 Validation, Sanitization and Encoding](https://owasp-aasvs4.readthedocs.io/en/latest/V5.html#validation-sanitization-and-encoding): **OWASP AASVS** diff --git a/1_1_vulns/translations/pt/LLM03_TrainingDataPoisoning.md b/1_1_vulns/translations/pt/LLM03_TrainingDataPoisoning.md new file mode 100644 index 00000000..671a7134 --- /dev/null +++ b/1_1_vulns/translations/pt/LLM03_TrainingDataPoisoning.md @@ -0,0 +1,67 @@ +## LLM03: Envenenamento de Dados de Treinamento + +### Descrição + +O ponto de partida para qualquer abordagem de aprendizado de máquina é o conjunto de dados de treinamento, simplesmente "texto bruto". Para ser altamente capaz (por exemplo, ter conhecimento linguístico e mundial), esse texto deve abranger uma ampla variedade de domínios, gêneros e idiomas. Um modelo de linguagem grande (LLM) usa redes neurais profundas para gerar saídas com base em padrões aprendidos a partir dos dados de treinamento. + +O envenenamento de dados de treinamento refere-se à manipulação dos dados de pré-treinamento ou dos dados envolvidos nos processos de ajuste fino ou incorporação para introduzir vulnerabilidades (que têm vetores de ataque únicos e, às vezes, compartilhados), backdoors ou viés que poderiam comprometer a segurança, eficácia ou comportamento ético do modelo. As informações envenenadas podem ser apresentadas aos usuários ou criar outros riscos, como degradação de desempenho, exploração de software downstream e danos à reputação. Mesmo que os usuários desconfiem da saída problemática da IA, os riscos permanecem, incluindo capacidades do modelo prejudicadas e possíveis danos à reputação da marca. + +- Dados de pré-treinamento referem-se ao processo de treinar um modelo com base em uma tarefa ou conjunto de dados. +- O ajuste fino envolve pegar um modelo existente que já foi treinado e adaptá-lo a um assunto mais estreito ou a um objetivo mais focado, treinando-o com um conjunto de dados selecionado. Este conjunto de dados inclui normalmente exemplos de entradas e saídas desejadas correspondentes. +- O processo de incorporação é a conversão de dados categóricos (frequentemente texto) em uma representação numérica que pode ser usada para treinar um modelo de linguagem. O processo de incorporação envolve representar palavras ou frases dos dados de texto como vetores em um espaço vetorial contínuo. Os vetores são geralmente gerados alimentando os dados de texto em uma rede neural que foi treinada em um grande corpus de texto. + +O envenenamento de dados é considerado um ataque à integridade porque interferir nos dados de treinamento afeta a capacidade do modelo de gerar previsões corretas. Naturalmente, fontes de dados externas apresentam maior risco, pois os criadores do modelo não têm controle sobre os dados ou um alto nível de confiança de que o conteúdo não contém viés, informações falsificadas ou conteúdo inadequado. + + +### Exemplos Comuns desta Vulnerabilidade + +1. Um ator malicioso, ou uma marca concorrente, cria intencionalmente documentos imprecisos ou maliciosos direcionados aos dados de pré-treinamento, ajuste fino do modelo ou incorporação. Considere tanto [Envenenamento de Dados com Divisão de Visualização](https://github.com/GangGreenTemperTatum/speaking/blob/main/dc604/hacker-summer-camp-23/Ads%20_%20Poisoning%20Web%20Training%20Datasets%20_%20Flow%20Diagram%20-%20Exploit%201%20Split-View%20Data%20Poisoning.jpeg) quanto [Envenenamento de Dados com Antecipação](https://github.com/GangGreenTemperTatum/speaking/blob/main/dc604/hacker-summer-camp-23/Ads%20_%20Poisoning%20Web%20Training%20Datasets%20_%20Flow%20Diagram%20-%20Exploit%202%20Frontrunning%20Data%20Poisoning.jpeg) como vetores de ataque para ilustrações. + 1. O modelo vítima treina usando informações falsificadas, refletidas nas saídas de prompts de IA generativa para seus consumidores. +2. Um ator malicioso é capaz de realizar a injeção direta de conteúdo falsificado, tendencioso ou prejudicial nos processos de treinamento de um modelo, que é refletido nas saídas subsequentes. +3. Um usuário inadvertido está injetando indiretamente dados sensíveis ou proprietários nos processos de treinamento de um modelo, que são refletidos nas saídas subsequentes. +4. Um modelo é treinado com dados que não foram verificados por sua origem, conteúdo ou fonte em qualquer um dos exemplos de estágios de treinamento, o que pode levar a resultados errôneos se os dados estiverem contaminados ou incorretos. +5. O acesso irrestrito à infraestrutura ou a falta de isolamento adequado pode permitir que um modelo ingira dados de treinamento inseguros, resultando em saídas tendenciosas ou prejudiciais. Este exemplo também está presente em qualquer um dos exemplos de estágios de treinamento. + 1. Neste cenário, a entrada do usuário para o modelo pode ser refletida na saída para outro usuário (levando a uma violação), ou o usuário de um LLM pode receber saídas do modelo que são imprecisas, irrelevantes ou prejudiciais, dependendo do tipo de dados ingeridos em comparação com o caso de uso do modelo (geralmente refletido com um cartão de modelo). + +*Seja um desenvolvedor, cliente ou consumidor geral do LLM, é importante entender as implicações de como essa vulnerabilidade pode refletir riscos em sua aplicação LLM ao interagir com um LLM não proprietário para entender a legitimidade das saídas do modelo com base em seus procedimentos de treinamento. Da mesma forma, os desenvolvedores do LLM podem estar em risco de ataques diretos e indiretos a dados internos ou de terceiros usados para ajuste fino e incorporação (mais comum), o que cria um risco para todos os seus consumidores.* + +### Estratégias de Prevenção e Mitigação + +1. Verifique a cadeia de suprimentos dos dados de treinamento, especialmente quando provenientes de fontes externas, e mantenha atestações por meio da metodologia "ML-BOM" (Machine Learning Bill of Materials), bem como verificação de cartões de modelo. +2. Verifique a legitimidade correta das fontes de dados direcionadas e dos dados obtidos durante os estágios de pré-treinamento, ajuste fino e incorporação. +3. Verifique o caso de uso para o LLM e a aplicação à qual se integrará. Crie modelos diferentes por meio de dados de treinamento +4. Certifique-se de que haja sandboxing suficiente por meio de controles de rede para evitar que o modelo extraia fontes de dados não intencionais que possam prejudicar a saída do aprendizado de máquina. +5. Use verificações rigorosas ou filtros de entrada para dados de treinamento específicos ou categorias de fontes de dados para controlar o volume de dados falsificados. Use sanitização de dados, com técnicas como detecção estatística de valores discrepantes e métodos de detecção de anomalias para detectar e remover dados adversários de serem potencialmente inseridos no processo de ajuste fino. +6. Elabore questões de controle em torno da origem e propriedade dos conjuntos de dados para garantir que o modelo não foi envenenado e adote essa cultura no ciclo "MLSecOps". Consulte os recursos disponíveis, como "The Foundation Model Transparency Index" ou "Open LLM Leaderboard", por exemplo. +7. Use DVC (controle de versão de dados) para identificar e rastrear com precisão parte de um conjunto de dados que pode ter sido manipulado, excluído ou adicionado e o que levou ao envenenamento. +8. Use um banco de dados vetorial para adicionar informações fornecidas pelo usuário para ajudar a proteger contra envenenamento de outros usuários e até mesmo consertar na produção sem ter que treinar novamente um novo modelo. +9. Use técnicas de robustez adversária, como aprendizado federado e restrições para minimizar o efeito de outliers ou treinamento adversário, para serem vigorosas contra perturbações extremas nos dados de treinamento. + - Uma abordagem "MLSecOps" poderia incluir a robustez adversária no ciclo de vida do treinamento com a técnica de auto-envenenamento automático. + - Um repositório exemplo disso seria o teste Autopoison, incluindo ataques como ataques de injeção de conteúdo ("tentativa de promover um nome de marca nas respostas do modelo") e ataques de recusa ("sempre fazendo o modelo se recusar a responder”) que podem ser realizados com esta abordagem. +10. Teste e Detecção, medindo a função de custo (perda) durante o estágio de treinamento e analisando modelos treinados para detectar sinais de um ataque de envenenamento, analisando o comportamento do modelo em entradas de teste específicas. +11. Monitoramento e alerta sobre o número de respostas distorcidas que excedem um limite. +12. Uso de um humano no loop para revisar respostas e auditoria. +13. Implemente LLMs dedicados para avaliar consequências indesejadas e treine outros LLMs usando técnicas de aprendizagem por reforço. +14. Execute exercícios de "red team" baseados em LLM ou verificação de vulnerabilidades de LLM nas fases de teste do ciclo de vida do LLM. + +### Exemplos de cenários de ataque + +1.A saída de prompt de IA generativa do LLM pode enganar os usuários do aplicativo, o que pode levar a opiniões tendenciosas, seguidores ou, pior ainda, crimes de ódio, etc. +2. Se os dados de treinamento não forem filtrados e/ou higienizados corretamente, um usuário mal-intencionado do aplicativo pode tentar influenciar e injetar dados tóxicos no modelo para que ele se adapte aos dados tendenciosos e falsos. +3. Um ator ou concorrente mal-intencionado cria intencionalmente documentos imprecisos ou maliciosos que são direcionados aos dados de treinamento de um modelo no qual o modelo está sendo treinado ao mesmo tempo com base nas entradas. O modelo de vítima treina usando essas informações falsificadas, que são refletidas nos resultados dos prompts generativos de IA para seus consumidores. +4. A vulnerabilidade de Injeção de Prompt pode ser um vetor de ataque para esta vulnerabilidade se a higienização e a filtragem insuficientes forem executadas quando a entrada dos clientes do aplicativo LLM for usado para treinar o modelo. Ou seja, se dados maliciosos ou falsificados forem inseridos no modelo por um cliente como parte de uma técnica de injeção imediata, isso poderá ser inerentemente retratado nos dados do modelo. + + +### Links de Referência + +1. [Stanford Research Paper:CS324](https://stanford-cs324.github.io/winter2022/lectures/data/): **Stanford Research** +2. [How data poisoning attacks corrupt machine learning models](https://www.csoonline.com/article/3613932/how-data-poisoning-attacks-corrupt-machine-learning-models.html): **CSO Online** +3. [MITRE ATLAS (framework) Tay Poisoning](https://atlas.mitre.org/studies/AML.CS0009/): **MITRE ATLAS** +4. [PoisonGPT: How we hid a lobotomized LLM on Hugging Face to spread fake news](https://blog.mithrilsecurity.io/poisongpt-how-we-hid-a-lobotomized-llm-on-hugging-face-to-spread-fake-news/): **Mithril Security** +5. [Inject My PDF: Prompt Injection for your Resume](https://kai-greshake.de/posts/inject-my-pdf/): **Kai Greshake** +6. [Backdoor Attacks on Language Models](https://towardsdatascience.com/backdoor-attacks-on-language-models-can-we-trust-our-models-weights-73108f9dcb1f): **Towards Data Science** +7. [Poisoning Language Models During Instruction](https://arxiv.org/abs/2305.00944): **Arxiv White Paper** +8. [FedMLSecurity:arXiv:2306.04959](https://arxiv.org/abs/2306.04959): **Arxiv White Paper** +9. [The poisoning of ChatGPT](https://softwarecrisis.dev/letters/the-poisoning-of-chatgpt/): **Software Crisis Blog** +10. [Poisoning Web-Scale Training Datasets - Nicholas Carlini | Stanford MLSys #75](https://www.youtube.com/watch?v=h9jf1ikcGyk): **YouTube Video** +11. [OWASP CycloneDX v1.5](https://cyclonedx.org/capabilities/mlbom/): **OWASP CycloneDX** diff --git a/1_1_vulns/translations/pt/LLM04_ModelDoS.md b/1_1_vulns/translations/pt/LLM04_ModelDoS.md new file mode 100644 index 00000000..00985d88 --- /dev/null +++ b/1_1_vulns/translations/pt/LLM04_ModelDoS.md @@ -0,0 +1,43 @@ +## LLM04: Negação de Serviço do Modelo + +### Descrição + +Um atacante interage com um LLM de uma maneira que consome uma quantidade excepcionalmente alta de recursos, resultando em uma queda na qualidade de serviço para eles e outros usuários, além de potencialmente incorrer em altos custos de recursos. Além disso, uma preocupação de segurança emergente é a possibilidade de um atacante interferir ou manipular a janela de contexto de um LLM. Esse problema está se tornando mais crítico devido ao uso crescente de LLMs em várias aplicações, à utilização intensiva de recursos, à imprevisibilidade da entrada do usuário e à falta de consciência geral entre os desenvolvedores em relação a essa vulnerabilidade. Em LLMs, a janela de contexto representa o comprimento máximo de texto que o modelo pode gerenciar, cobrindo tanto a entrada quanto a saída. É uma característica crucial dos LLMs, pois dita a complexidade dos padrões de linguagem que o modelo pode entender e o tamanho do texto que ele pode processar em qualquer momento. O tamanho da janela de contexto é definido pela arquitetura do modelo e pode variar entre modelos. + +### Exemplos Comuns de Vulnerabilidade + +1. Formular consultas que levam a um uso recorrente de recursos por meio da geração em grande volume de tarefas em uma fila, por exemplo, com LangChain ou AutoGPT. +2. Enviar consultas incomuns que consomem recursos de forma incomum, usando ortografia ou sequências incomuns. +3. Overflow contínuo de entrada: um atacante envia um fluxo de entrada para o LLM que excede sua janela de contexto, fazendo com que o modelo consuma recursos computacionais excessivos. +4. Entradas longas repetitivas: o atacante envia repetidamente entradas longas para o LLM, cada uma excedendo a janela de contexto. +5. Expansão recursiva do contexto: o atacante constrói uma entrada que desencadeia a expansão recursiva do contexto, forçando o LLM a expandir e processar repetidamente a janela de contexto. +6. Inundação de entrada de comprimento variável: o atacante inunda o LLM com um grande volume de entradas de comprimento variável, em que cada entrada é cuidadosamente elaborada para atingir ou apenas chegar ao limite da janela de contexto. Essa técnica visa explorar qualquer ineficiência no processamento de entradas de comprimento variável, sobrecarregando o LLM e potencialmente tornando-o irresponsivo. + + +### Estratégias de Prevenção e Mitigação + +1. Implementar validação e saneamento de entrada para garantir que a entrada do usuário siga limites definidos e filtre qualquer conteúdo malicioso. +2. Limitar o uso de recursos por solicitação ou etapa, de modo que solicitações envolvendo partes complexas sejam executadas mais lentamente. +3. Aplicar limites de taxa da API para restringir o número de solicitações que um usuário individual ou endereço IP pode fazer dentro de um período específico. +4. Limitar o número de ações na fila e o número total de ações em um sistema que reage às respostas do LLM. +5. Monitorar continuamente a utilização de recursos do LLM para identificar picos ou padrões anormais que possam indicar um ataque de Negação de Serviço. +6. Estabelecer limites rigorosos de entrada com base na janela de contexto do LLM para evitar sobrecarga e exaustão de recursos. +7. Promover a conscientização entre os desenvolvedores sobre possíveis vulnerabilidades de Negação de Serviço em LLMs e fornecer diretrizes para a implementação segura de LLMs. + +### Cenários de Ataque Exemplo + +1. Um atacante envia repetidamente várias solicitações difíceis e custosas a um modelo hospedado, levando a um serviço pior para outros usuários e contas mais altas para o host. +2. Um trecho de texto em uma página da web é encontrado enquanto uma ferramenta impulsionada por um LLM está coletando informações para responder a uma consulta benigna. Isso leva a ferramenta a fazer muitas mais solicitações à página da web, resultando em grande consumo de recursos. +3. Um atacante bombardeia continuamente o LLM com entradas que excedem sua janela de contexto. O atacante pode usar scripts ou ferramentas automatizadas para enviar um alto volume de entrada, sobrecarregando as capacidades de processamento do LLM. Como resultado, o LLM consome recursos computacionais excessivos, levando a uma desaceleração significativa ou completa irresponsividade do sistema. +4. Um atacante envia uma série de entradas sequenciais para o LLM, sendo que cada entrada é projetada para ficar logo abaixo do limite da janela de contexto. Ao enviar repetidamente essas entradas, o atacante visa esgotar a capacidade disponível da janela de contexto. Conforme o LLM luta para processar cada entrada dentro de sua janela de contexto, os recursos do sistema ficam sobrecarregados, podendo resultar em desempenho degradado ou uma negação completa de serviço. +5. Um atacante alavanca os mecanismos recursivos do LLM para acionar a expansão do contexto repetidamente. Ao elaborar uma entrada que explora o comportamento recursivo do LLM, o atacante força o modelo a expandir e processar repetidamente a janela de contexto, consumindo recursos computacionais significativos. Esse ataque sobrecarrega o sistema e pode levar a uma condição de Negação de Serviço, tornando o LLM irresponsivo ou causando sua falha. +6. Um atacante inunda o LLM com um grande volume de entradas de comprimento variável, cuidadosamente elaboradas para se aproximar ou atingir o limite da janela de contexto. Ao sobrecarregar o LLM com entradas de comprimento variável, o atacante visa explorar qualquer ineficiência no processamento de entradas de comprimento variável. Essa inundação de entradas coloca uma carga excessiva nos recursos do LLM, podendo causar degradação de desempenho e prejudicar a capacidade do sistema de responder a solicitações legítimas. +7. Embora os ataques de Negação de Serviço comumente visem sobrecarregar os recursos do sistema, eles também podem explorar outros aspectos do comportamento do sistema, como as limitações da API. Por exemplo, em um recente incidente de segurança da Sourcegraph, o agente mal-intencionado empregou um token de acesso de administrador vazado para alterar os limites de taxa da API, causando potencialmente interrupções de serviço ao permitir níveis anormais de volumes de solicitações. + +### Links de Referência + +1. [LangChain max_iterations](https://twitter.com/hwchase17/status/1608467493877579777): **hwchase17 on Twitter** +2. [Sponge Examples: Energy-Latency Attacks on Neural Networks](https://arxiv.org/abs/2006.03463): **Arxiv White Paper** +3. [OWASP DOS Attack](https://owasp.org/www-community/attacks/Denial_of_Service): **OWASP** +4. [Learning From Machines: Know Thy Context](https://lukebechtel.com/blog/lfm-know-thy-context): **Luke Bechtel** +5. [Sourcegraph Security Incident on API Limits Manipulation and DoS Attack ](https://about.sourcegraph.com/blog/security-update-august-2023): **Sourcegraph** diff --git a/1_1_vulns/translations/pt/LLM05_SupplyChainVulnerabilities.md b/1_1_vulns/translations/pt/LLM05_SupplyChainVulnerabilities.md new file mode 100644 index 00000000..0b979813 --- /dev/null +++ b/1_1_vulns/translations/pt/LLM05_SupplyChainVulnerabilities.md @@ -0,0 +1,51 @@ +## LLM05: Vulnerabilidades na Cadeia de Suprimentos + +### Descrição + +A cadeia de suprimentos em LLMs pode ser vulnerável, impactando a integridade dos dados de treinamento, modelos de aprendizado de máquina e plataformas de implantação. Essas vulnerabilidades podem resultar em resultados tendenciosos, violações de segurança ou até mesmo falhas completas no sistema. Tradicionalmente, as vulnerabilidades são focadas em componentes de software, mas o Aprendizado de Máquina estende isso com modelos pré-treinados e dados de treinamento fornecidos por terceiros suscetíveis a ataques de manipulação e envenenamento. + +Finalmente, as extensões de Plugin do LLM podem trazer suas próprias vulnerabilidades. Essas são descritas em [LLM07 - Design Inseguro de Plugins](InsecurePluginDesign.md), que aborda a redação de Plugins do LLM e fornece informações úteis para avaliar plugins de terceiros. + +### Exemplos Comuns de Vulnerabilidade + +1. Vulnerabilidades tradicionais em pacotes de terceiros, incluindo componentes desatualizados ou obsoletos. +2. Uso de um modelo pré-treinado vulnerável para ajuste fino. +3. Uso de dados envenenados provenientes de contribuições de grupos (crowdsourcing) para treinamento. +4. Uso de modelos desatualizados ou obsoletos que não são mais mantidos, resultando em problemas de segurança. +5. Termos e Condições (T&Cs) e políticas de privacidade não claros dos operadores do modelo levam ao uso dos dados sensíveis do aplicativo para o treinamento do modelo e subsequente exposição de informações sensíveis. Isso também pode se aplicar a riscos decorrentes do uso de material protegido por direitos autorais pelo fornecedor do modelo. + +### Estratégias de Prevenção e Mitigação + +1. Avalie cuidadosamente as fontes e fornecedores de dados, incluindo T&Cs e suas políticas de privacidade, usando apenas fornecedores confiáveis. Certifique-se de que exista segurança adequada e auditada de forma independente e que as políticas dos operadores do modelo estejam alinhadas com suas políticas de proteção de dados, ou seja, seus dados não são usados para treinar seus modelos; da mesma forma, busque garantias e mitigação legal contra o uso de material protegido por direitos autorais pelos mantenedores do modelo. +2. Use apenas plugins confiáveis e certifique-se de que foram testados para atender aos requisitos do seu aplicativo. O Design Inseguro de Plugins do LLM fornece informações sobre os aspectos do LLM do design inseguro de plugins que você deve testar para mitigar os riscos do uso de plugins de terceiros. +3. Compreenda e aplique as mitigações encontradas no [A06:2021 – Componentes Vulneráveis e Desatualizados](https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/) do OWASP Top Ten. Isso inclui a verificação, gerenciamento e atualização de componentes com vulnerabilidades. Para ambientes de desenvolvimento com acesso a dados sensíveis, aplique esses controles também. +4. Mantenha um inventário atualizado de componentes usando um Mapeamento de Componentes de Software (SBOM) para garantir que você tenha um inventário atualizado, preciso e assinado, prevenindo manipulações em pacotes implantados. SBOMs podem ser usados para detectar e alertar sobre novas vulnerabilidades rapidamente. +5. No momento da redação, SBOMs não cobrem modelos, seus artefatos e conjuntos de dados. Se a sua aplicação LLM usar seu próprio modelo, você deve usar as melhores práticas de MLOps e plataformas que ofereçam repositórios seguros de modelos com rastreamento de dados, modelos e experimentos. +6. Você também deve usar a assinatura de modelos e código ao usar modelos e fornecedores externos. +7. Testes de detecção de anomalias e robustez adversarial em modelos e dados fornecidos podem ajudar a detectar manipulações e envenenamento, como discutido em [Envenenamento de Dados de Treinamento](https://github.com/OWASP/www-project-top-10-for-large-language-model-applications/blob/main/1_0_vulns/Training_Data_Poisoning.md); idealmente, isso deve fazer parte dos pipelines de MLOps; no entanto, essas são técnicas emergentes e podem ser mais fáceis de implementar como parte de exercícios de red teaming. +8. Implemente monitoramento suficiente para cobrir a verificação de vulnerabilidades em componentes e ambientes, o uso de plugins não autorizados e componentes desatualizados, incluindo o modelo e seus artefatos. +9. Implemente uma política de atualização para mitigar componentes vulneráveis ou desatualizados. Certifique-se de que o aplicativo dependa de uma versão mantida das APIs e do modelo subjacente. +10. Revise regularmente e audite a Segurança e o Acesso dos fornecedores, garantindo que não haja alterações em sua postura de segurança ou T&Cs. + +### Cenários de Ataque Exemplo + +1. Um atacante explora uma biblioteca Python vulnerável para comprometer um sistema. Isso ocorreu no primeiro vazamento de dados da Open AI. +2. Um atacante fornece um plugin do LLM para pesquisar voos, gerando links falsos que levam a fraudar usuários. +3. Um atacante explora o registro de pacotes PyPi para enganar desenvolvedores de modelos a baixar um pacote comprometido e extrair dados ou aumentar os privilégios em um ambiente de desenvolvimento de modelos. Isso foi um ataque real. +4. Um atacante envenena um modelo pré-treinado publicamente disponível, especializado em análise econômica e pesquisa social, para criar um backdoor que gera desinformação e notícias falsas. Eles o implantam em um mercado de modelos (por exemplo, Hugging Face) para que vítimas o usem. +5. Um atacante envenena conjuntos de dados publicamente disponíveis para ajudar a criar um backdoor ao ajustar modelos. O backdoor favorece sutilmente certas empresas em diferentes mercados. +6. Um funcionário comprometido de um fornecedor (desenvolvedor terceirizado, empresa de hospedagem, etc.) exfiltra dados, modelo ou código, roubando propriedade intelectual +7. Um operador LLM altera seus T&Cs e Política de Privacidade para exigir uma recusa explícita de usar dados de aplicativos para treinamento de modelo, levando à memorização de dados confidenciais. + +### Links de Referência + +1. [ChatGPT Data Breach Confirmed as Security Firm Warns of Vulnerable Component Exploitation](https://www.securityweek.com/chatgpt-data-breach-confirmed-as-security-firm-warns-of-vulnerable-component-exploitation/): **Security Week** +2. [Plugin review process](https://platform.openai.com/docs/plugins/review) **OpenAI** +3. [Compromised PyTorch-nightly dependency chain](https://pytorch.org/blog/compromised-nightly-dependency/): **Pytorch** +4. [PoisonGPT: How we hid a lobotomized LLM on Hugging Face to spread fake news](https://blog.mithrilsecurity.io/poisongpt-how-we-hid-a-lobotomized-llm-on-hugging-face-to-spread-fake-news/): **Mithril Security** +5. [Army looking at the possibility of 'AI BOMs](https://defensescoop.com/2023/05/25/army-looking-at-the-possibility-of-ai-boms-bill-of-materials/): **Defense Scoop** +6. [Failure Modes in Machine Learning](https://learn.microsoft.com/en-us/security/engineering/failure-modes-in-machine-learning): **Microsoft** +7. [ML Supply Chain Compromise](https://atlas.mitre.org/techniques/AML.T0010/): **MITRE ATLAS** +8. [Transferability in Machine Learning: from Phenomena to Black-Box Attacks using Adversarial Samples](https://arxiv.org/pdf/1605.07277.pdf): **Arxiv White Paper** +9. [BadNets: Identifying Vulnerabilities in the Machine Learning Model Supply Chain](https://arxiv.org/abs/1708.06733): **Arxiv White Paper** +10. [VirusTotal Poisoning](https://atlas.mitre.org/studies/AML.CS0002): **MITRE ATLAS** diff --git a/1_1_vulns/translations/pt/LLM06_SensitiveInformationDisclosure.md b/1_1_vulns/translations/pt/LLM06_SensitiveInformationDisclosure.md new file mode 100644 index 00000000..81ce038c --- /dev/null +++ b/1_1_vulns/translations/pt/LLM06_SensitiveInformationDisclosure.md @@ -0,0 +1,39 @@ +## LLM06: Divulgação de Informações Sensíveis + +### Descrição + +As aplicações LLM têm o potencial de revelar informações sensíveis, algoritmos proprietários ou outros detalhes confidenciais por meio de suas saídas. Isso pode resultar em acesso não autorizado a dados sensíveis, violações de propriedade intelectual, violações de privacidade e outras falhas de segurança. É importante que os consumidores de aplicações LLM estejam cientes de como interagir com segurança com os LLMs e identificar os riscos associados à entrada não intencional de dados sensíveis que podem ser posteriormente retornados pelo LLM em outras saídas. + +Para mitigar esse risco, as aplicações LLM devem realizar uma sanitização adequada dos dados para evitar que os dados do usuário entrem nos dados de treinamento do modelo. Os proprietários de aplicações LLM também devem ter políticas apropriadas de Termos de Uso disponíveis para conscientizar os consumidores sobre como seus dados são processados e sobre a capacidade de optar por não incluir seus dados no modelo de treinamento. + +A interação consumidor-aplicação LLM forma uma fronteira de confiança bidirecional, onde não podemos confiar inerentemente na entrada cliente->LLM ou na saída LLM->cliente. É importante observar que esta vulnerabilidade assume que certos pré-requisitos estão fora do escopo, como exercícios de modelagem de ameaças, segurança de infraestrutura e sandboxing adequado. Adicionar restrições dentro da solicitação do sistema em torno dos tipos de dados que o LLM deve retornar pode fornecer alguma mitigação contra a divulgação de informações sensíveis, mas a natureza imprevisível dos LLMs significa que tais restrições nem sempre serão respeitadas e podem ser contornadas por meio de injeção de prompt ou outros vetores. + +### Exemplos Comuns de Vulnerabilidade + +1. Filtragem incompleta ou inadequada de informações sensíveis nas respostas do LLM. +2. Memorização ou sobreajuste (overfitting) de dados sensíveis no processo de treinamento do LLM. +3. Divulgação não intencional de informações confidenciais devido à interpretação inadequada do LLM, falta de métodos de limpeza de dados ou erros. + +### Estratégias de Prevenção e Mitigação + +1. Integre técnicas adequadas de sanitização e limpeza de dados para evitar que os dados do usuário entrem nos dados de treinamento do modelo. +2. Implemente métodos robustos de validação e sanitização de entrada para identificar e filtrar inputs potencialmente maliciosos e prevenir que o modelo seja envenenado. +3. Ao enriquecer o modelo com dados e se [ajustar finamente](https://github.com/OWASP/www-project-top-10-for-large-language-model-applications/wiki/Definitions) um modelo (ou seja, alimentar o modelo antes ou durante a implantação): + 1. Qualquer informação considerada sensível nos dados de ajuste fino tem o potencial de ser revelada a um usuário. Portanto, aplique a regra do menor privilégio e não treine o modelo em informações que o usuário de mais alto privilégio pode acessar e que podem ser exibidas a um usuário de menor privilégio. + 2. O acesso a fontes de dados externas (orquestação de dados em tempo de execução) deve ser limitado. + 3. Aplique métodos rígidos de controle de acesso a fontes de dados externas e uma abordagem rigorosa para manter uma cadeia de suprimentos segura. + +### Cenários de Ataque Exemplo + +1. O usuário legítimo A, sem suspeitas, é exposto a certos dados de outros usuários por meio do LLM ao interagir com a aplicação LLM de maneira não maliciosa. +2. O usuário A direciona um conjunto bem elaborado de prompts para burlar filtros de entrada e sanitização do LLM, fazendo com que ele revele informações sensíveis (PII) sobre outros usuários da aplicação. +3. Dados pessoais, como PII, vazam para o modelo por meio de dados de treinamento, devido à negligência do próprio usuário ou da aplicação LLM. Esse cenário poderia aumentar o risco e a probabilidade dos cenários 1 ou 2 acima. + +### Links de Referência + +1. [AI data leak crisis: New tool prevents company secrets from being fed to ChatGPT](https://www.foxbusiness.com/politics/ai-data-leak-crisis-prevent-company-secrets-chatgpt): **Fox Business** +2. [Lessons learned from ChatGPT’s Samsung leak](https://cybernews.com/security/chatgpt-samsung-leak-explained-lessons/): **Cybernews** +3. [Cohere - Terms Of Use](https://cohere.com/terms-of-use) **Cohere** +4. [A threat modeling example](https://aivillage.org/large%20language%20models/threat-modeling-llm/): **AI Village** +5. [OWASP AI Security and Privacy Guide](https://owasp.org/www-project-ai-security-and-privacy-guide/): **OWASP AI Security & Privacy Guide** +6. [Ensuring the Security of Large Language Models](https://www.experts-exchange.com/articles/38220/Ensuring-the-Security-of-Large-Language-Models-Strategies-and-Best-Practices.html): **Experts Exchange** diff --git a/1_1_vulns/translations/pt/LLM07_InsecurePluginDesign.md b/1_1_vulns/translations/pt/LLM07_InsecurePluginDesign.md new file mode 100644 index 00000000..31a6e56b --- /dev/null +++ b/1_1_vulns/translations/pt/LLM07_InsecurePluginDesign.md @@ -0,0 +1,47 @@ +## LLM07: Design Inseguro de Plugins + +### Descrição + +Os plugins LLM são extensões que, quando habilitadas, são chamadas automaticamente pelo modelo durante as interações do usuário. A plataforma de integração do modelo os controla, e a aplicação pode não ter controle sobre a execução, especialmente quando o modelo é hospedado por outra parte. Além disso, os plugins provavelmente implementam entradas de texto livre do modelo sem validação ou verificação de tipo para lidar com limitações de tamanho de contexto. Isso permite que um potencial atacante construa uma solicitação maliciosa para o plugin, o que pode resultar em uma ampla gama de comportamentos indesejados, incluindo execução remota de código. + +O dano de inputs maliciosos muitas vezes depende de controles de acesso insuficientes e da falha no rastreamento de autorização em plugins. O controle de acesso inadequado permite que um plugin confie cegamente em outros plugins e assuma que o usuário final forneceu as entradas. Esse controle de acesso inadequado pode permitir que inputs maliciosos tenham consequências prejudiciais que vão desde exfiltração de dados, execução remota de código até escalonamento de privilégios. + +Este item foca na criação de plugins LLM, em vez de plugins de terceiros, que são abordados nas Vulnerabilidades de Cadeia de Suprimentos LLM. + +### Exemplos Comuns de Vulnerabilidade + +1. Um plugin aceita todos os parâmetros em um único campo de texto em vez de parâmetros de entrada distintos. +2. Um plugin aceita strings de configuração em vez de parâmetros que podem substituir configurações inteiras. +3. Um plugin aceita instruções SQL ou de programação em bruto em vez de parâmetros. +4. A autenticação é realizada sem autorização explícita para um plugin específico. +5. Um plugin trata todo o conteúdo do LLM como se fosse criado inteiramente pelo usuário e executa quaisquer ações solicitadas sem exigir autorização adicional. + +### Estratégias de Prevenção e Mitigação + +1. Os plugins devem impor uma entrada estritamente parametrizada sempre que possível e incluir verificações de tipo e intervalo nas entradas. Quando isso não for possível, uma segunda camada de chamadas tipadas deve ser introduzida, analisando solicitações e aplicando validação e sanitização. Quando a entrada de formulário livre deve ser aceita devido à semântica da aplicação, ela deve ser cuidadosamente inspecionada para garantir que nenhum método potencialmente prejudicial esteja sendo chamado. +2. Os desenvolvedores de plugins devem aplicar as recomendações da OWASP no ASVS (Application Security Verification Standard) para garantir validação e sanitização adequadas de entrada. +3. Os plugins devem ser inspecionados e testados minuciosamente para garantir validação adequada. Use varreduras de Teste Estático de Segurança de Aplicações (SAST) e Teste Dinâmico e Interativo de Aplicações (DAST, IAST) nos pipelines de desenvolvimento. +4. Os plugins devem ser projetados para minimizar o impacto de qualquer exploração de parâmetro de entrada insegura seguindo as Diretrizes de Controle de Acesso da OWASP ASVS. Isso inclui controle de acesso de menor privilégio, expondo o mínimo de funcionalidade possível enquanto ainda realiza a função desejada. +5. Os plugins devem usar identidades de autenticação apropriadas, como OAuth2, para aplicar autorização e controle de acesso eficazes. Além disso, as Chaves de API devem ser usadas para fornecer contexto para decisões de autorização personalizadas que reflitam a rota do plugin, em vez do usuário interativo padrão. +6. Exigir autorização e confirmação manual do usuário para qualquer ação realizada por plugins sensíveis. +7. Os plugins são, tipicamente, APIs REST, então os desenvolvedores devem aplicar as recomendações encontradas nas Principais 10 Vulnerabilidades de Segurança em APIs da OWASP - 2023 para minimizar vulnerabilidades genéricas. + +### Cenários de Ataque Exemplo + +1. Um plugin aceita uma URL base e instrui o LLM a combinar a URL com uma consulta para obter previsões do tempo, que são incluídas no tratamento da solicitação do usuário. Um usuário mal-intencionado pode criar uma solicitação para que a URL aponte para um domínio que eles controlam, permitindo que eles injetem seu próprio conteúdo no sistema LLM por meio de seu domínio. +2. Um plugin aceita uma entrada de formulário livre em um único campo que não valida. Um atacante fornece cargas cuidadosamente elaboradas para realizar reconhecimento a partir de mensagens de erro. Em seguida, ele explora vulnerabilidades conhecidas de terceiros para executar código e realizar exfiltração de dados ou escalonamento de privilégios. +3. Um plugin usado para recuperar embeddings de um repositório de vetores aceita parâmetros de configuração como uma string de conexão sem validação. Isso permite que um atacante experimente e acesse outros repositórios de vetores alterando nomes ou parâmetros de host e exfiltra embeddings aos quais não deveria ter acesso. +4. Um plugin aceita cláusulas WHERE SQL como filtros avançados, que são então anexadas ao SQL de filtragem. Isso permite que um atacante execute um ataque SQL. +5. Um atacante usa injeção de prompt indireto para explorar um plugin de gerenciamento de código inseguro, sem validação de entrada e controle de acesso fraco, para transferir a propriedade do repositório e bloquear o usuário de seus repositórios. + +### Links de Referência + +1. [OpenAI ChatGPT Plugins](https://platform.openai.com/docs/plugins/introduction): **ChatGPT Developer’s Guide** +2. [OpenAI ChatGPT Plugins - Plugin Flow](https://platform.openai.com/docs/plugins/introduction/plugin-flow): **OpenAI Documentation** +3. [OpenAI ChatGPT Plugins - Authentication](https://platform.openai.com/docs/plugins/authentication/service-level): **OpenAI Documentation** +4. [OpenAI Semantic Search Plugin Sample](https://github.com/openai/chatgpt-retrieval-plugin): **OpenAI Github** +5. [Plugin Vulnerabilities: Visit a Website and Have Your Source Code Stolen](https://embracethered.com/blog/posts/2023/chatgpt-plugin-vulns-chat-with-code/): **Embrace The Red** +6. [ChatGPT Plugin Exploit Explained: From Prompt Injection to Accessing Private Data](https://embracethered.com/blog/posts/2023/chatgpt-cross-plugin-request-forgery-and-prompt-injection./) **Embrace The Red** +7. [OWASP ASVS - 5 Validation, Sanitization and Encoding](https://owasp-aasvs4.readthedocs.io/en/latest/V5.html#validation-sanitization-and-encoding): **OWASP AASVS** +8. [OWASP ASVS 4.1 General Access Control Design](https://owasp-aasvs4.readthedocs.io/en/latest/V4.1.html#general-access-control-design): **OWASP AASVS** +9. [OWASP Top 10 API Security Risks – 2023](https://owasp.org/API-Security/editions/2023/en/0x11-t10/): **OWASP** diff --git a/1_1_vulns/translations/pt/LLM08_ExcessiveAgency.md b/1_1_vulns/translations/pt/LLM08_ExcessiveAgency.md new file mode 100644 index 00000000..44d63bdd --- /dev/null +++ b/1_1_vulns/translations/pt/LLM08_ExcessiveAgency.md @@ -0,0 +1,50 @@ +## LLM08: Autoridade Excessiva + +### Descrição + +Um sistema baseado em LLM frequentemente é concedido um grau de agência pelo seu desenvolvedor - a capacidade de interagir com outros sistemas e realizar ações em resposta a um prompt. A decisão sobre quais funções invocar também pode ser delegada a um 'agente' LLM para determinar dinamicamente com base no prompt de entrada ou saída do LLM. + +A Autoridade Excessiva é a vulnerabilidade que permite a realização de ações prejudiciais em resposta a saídas inesperadas/ambíguas de um LLM (independentemente do que está causando o mau funcionamento do LLM; seja alucinação/confabulação, injeção de prompt direta/indireta, plugin malicioso, prompts benignos mal projetados ou apenas um modelo com desempenho ruim). A causa raiz da Autoridade Excessiva geralmente é um ou mais dos seguintes: funcionalidade excessiva, permissões excessivas ou autonomia excessiva. Isso difere do tratamento inadequado de saída, que se preocupa com a falta de escrutínio nas saídas do LLM. + +A Autoridade Excessiva pode levar a uma ampla variedade de impactos em relação à confidencialidade, integridade e disponibilidade, e depende dos sistemas com os quais um aplicativo baseado em LLM pode interagir. + +### Exemplos Comuns desta Vulnerabilidade + +1. Funcionalidade Excessiva: Um agente LLM tem acesso a plugins que incluem funções desnecessárias para a operação pretendida do sistema. Por exemplo, um desenvolvedor precisa conceder a um agente LLM a capacidade de ler documentos de um repositório, mas o plugin de terceiros que eles escolhem também inclui a capacidade de modificar e excluir documentos. +2. Funcionalidade Excessiva: Um plugin pode ter sido testado durante a fase de desenvolvimento e descartado em favor de uma alternativa melhor, mas o plugin original permanece disponível para o agente LLM. +3. Funcionalidade Excessiva: Um plugin LLM com funcionalidade em aberto não filtra corretamente as instruções de entrada para comandos fora do necessário para a operação pretendida do aplicativo. Por exemplo, um plugin para executar um comando shell específico falha em prevenir adequadamente a execução de outros comandos shell. +4. Permissões Excessivas: Um plugin LLM tem permissões em outros sistemas que não são necessárias para a operação pretendida do aplicativo. Por exemplo, um plugin destinado a ler dados se conecta a um servidor de banco de dados usando uma identidade que não apenas possui permissões SELECT, mas também permissões UPDATE, INSERT e DELETE. +5. Permissões Excessivas: Um plugin LLM projetado para realizar operações em nome de um usuário acessa sistemas downstream com uma identidade genérica de alta privilégio. Por exemplo, um plugin para ler a loja de documentos do usuário atual se conecta ao repositório de documentos com uma conta privilegiada que tem acesso aos arquivos de todos os usuários. +6. Autonomia Excessiva: Um aplicativo ou plugin baseado em LLM falha em verificar e aprovar independentemente ações de alto impacto. Por exemplo, um plugin que permite a exclusão de documentos de um usuário realiza exclusões sem qualquer confirmação do usuário. + +### Estratégias de Prevenção e Mitigação + +As seguintes ações podem prevenir a Autoridade Excessiva: + +1. Limitar os plugins/ferramentas que os agentes LLM têm permissão para chamar apenas às funções mínimas necessárias. Por exemplo, se um sistema baseado em LLM não requer a capacidade de buscar o conteúdo de uma URL, tal plugin não deve ser oferecido ao agente LLM. +2. Limitar as funções implementadas nos plugins/ferramentas LLM para o mínimo necessário. Por exemplo, um plugin que acessa a caixa de correio de um usuário para resumir e-mails pode precisar apenas da capacidade de ler e-mails, então o plugin não deve conter outras funcionalidades, como excluir ou enviar mensagens. +3. Evitar funções em aberto sempre que possível (por exemplo, executar um comando shell, buscar uma URL, etc.) e usar plugins/ferramentas com funcionalidades mais granulares. Por exemplo, um aplicativo baseado em LLM pode precisar escrever alguma saída em um arquivo. Se isso fosse implementado usando um plugin para executar uma função shell, o escopo para ações indesejadas seria muito grande (qualquer outro comando shell poderia ser executado). Uma alternativa mais segura seria construir um plugin de gravação de arquivos que só pudesse suportar aquela funcionalidade específica. +4. Limitar as permissões concedidas a outros sistemas pelos plugins/ferramentas LLM para o mínimo necessário, a fim de limitar o escopo de ações indesejadas. Por exemplo, um agente LLM que usa um banco de dados de produtos para fazer recomendações de compra a um cliente pode precisar apenas de acesso de leitura a uma tabela de 'produtos'; não deve ter acesso a outras tabelas, nem a capacidade de inserir, atualizar ou excluir registros. Isso deve ser aplicado por meio da concessão de permissões apropriadas no banco de dados para a identidade que o plugin LLM usa para se conectar ao banco de dados. +5. Rastrear a autorização do usuário e o escopo de segurança para garantir que as ações realizadas em nome de um usuário sejam executadas em sistemas downstream no contexto desse usuário específico e com as permissões mínimas necessárias. Por exemplo, um plugin LLM que lê o repositório de código de um usuário deve exigir que o usuário se autentique via OAuth e com o escopo mínimo necessário. +6. Utilizar controle humano no loop para exigir que um humano aprove todas as ações antes que sejam realizadas. Isso pode ser implementado em um sistema downstream (fora do escopo do aplicativo LLM) ou dentro do próprio plugin/ferramenta LLM. Por exemplo, um aplicativo baseado em LLM que cria e publica conteúdo em mídias sociais em nome de um usuário deve incluir um procedimento de aprovação do usuário dentro do plugin/ferramenta/API que implementa a operação 'publicar'. +7. Implementar autorização em sistemas downstream em vez de depender de um LLM para decidir se uma ação é permitida ou não. Ao implementar ferramentas/plugins, aplicar o princípio de mediação completa para que todas as solicitações feitas a sistemas downstream por meio dos plugins/ferramentas sejam validadas em relação às políticas de segurança. + +As seguintes opções não impedirão a Autoridade Excessiva, mas podem limitar o nível de dano causado: + +1. Registrar e monitorar a atividade de plugins/ferramentas LLM e sistemas downstream para identificar onde ações indesejadas estão ocorrendo e responder adequadamente. +2. Implementar limitação de taxa para reduzir o número de ações indesejadas que podem ocorrer dentro de um determinado período de tempo, aumentando a oportunidade de descobrir ações indesejadas por meio de monitoramento antes que ocorra um dano significativo. + +### Exemplos de Cenários de Ataque + +Um aplicativo de assistente pessoal baseado em LLM recebe acesso à caixa de correio de um indivíduo por meio de um plugin para resumir o conteúdo dos e-mails recebidos. Para alcançar essa funcionalidade, o plugin de e-mail requer a capacidade de ler mensagens, no entanto, o plugin escolhido pelo desenvolvedor do sistema também inclui funções para enviar mensagens. O LLM é vulnerável a um ataque de injeção de prompt indireto, em que um e-mail maliciosamente elaborado engana o LLM para comandar o plugin de e-mail a chamar a função 'enviar mensagens' para enviar spam da caixa de correio do usuário. Isso poderia ser evitado das seguintes maneiras: +(a) eliminar funcionalidades excessivas, usando um plugin que oferece apenas capacidades de leitura de e-mails, +(b) eliminar permissões excessivas, autenticando-se no serviço de e-mail do usuário por meio de uma sessão OAuth com escopo somente leitura, e/ou +(c) eliminar autonomia excessiva, exigindo que o usuário revise manualmente e clique em 'enviar' em cada e-mail redigido pelo plugin LLM. +Alternativamente, o dano causado poderia ser reduzido implementando limitação de taxa na interface de envio de e-mails. + +### Links de Referência + +1. [Embrace the Red: Confused Deputy Problem](https://embracethered.com/blog/posts/2023/chatgpt-cross-plugin-request-forgery-and-prompt-injection./): **Embrace The Red** +2. [NeMo-Guardrails: Interface guidelines](https://github.com/NVIDIA/NeMo-Guardrails/blob/main/docs/security/guidelines.md): **NVIDIA Github** +3. [LangChain: Human-approval for tools](https://python.langchain.com/docs/modules/agents/tools/how_to/human_approval): **Langchain Documentation** +4. [Simon Willison: Dual LLM Pattern](https://simonwillison.net/2023/Apr/25/dual-llm-pattern/): **Simon Willison** diff --git a/1_1_vulns/translations/pt/LLM09_Overreliance.md b/1_1_vulns/translations/pt/LLM09_Overreliance.md new file mode 100644 index 00000000..4dc757c4 --- /dev/null +++ b/1_1_vulns/translations/pt/LLM09_Overreliance.md @@ -0,0 +1,42 @@ +## LLM09: Dependência Excessiva + +### Descrição + +A Dependência Excessiva pode ocorrer quando um LLM produz informações errôneas e as fornece de maneira autoritária. Embora os LLMs possam produzir conteúdo criativo e informativo, também podem gerar conteúdo factualmente incorreto, inapropriado ou inseguro. Isso é chamado de alucinação ou confabulação. Quando pessoas ou sistemas confiam nessas informações sem supervisão ou confirmação, pode resultar em violação de segurança, desinformação, má comunicação, questões legais e danos à reputação. + +O código-fonte gerado pelo LLM pode introduzir vulnerabilidades de segurança não percebidas. Isso representa um risco significativo para a segurança operacional de aplicativos. Esses riscos destacam a importância de processos rigorosos de revisão, com: + +- Supervisão +- Mecanismos contínuos de validação +- Avisos sobre riscos + +### Exemplos Comuns desta Vulnerabilidade + +1. LLM fornece informações imprecisas como resposta, declarando-as de maneira a sugerir alta autoridade. O sistema como um todo é projetado sem verificações e equilíbrios adequados para lidar com isso, e as informações enganam o usuário de uma maneira que leva a danos. +2. LLM sugere código inseguro ou com falhas, levando a vulnerabilidades quando incorporado a um sistema de software sem a devida supervisão ou verificação. + +### Estratégias de Prevenção e Mitigação + +1. Monitore e revise regularmente as saídas do LLM. Use técnicas de auto consistência ou votação para filtrar texto inconsistente. Comparar múltiplas respostas do modelo para um único prompt pode ajudar a julgar melhor a qualidade e consistência da saída. +2. Verifique a saída do LLM com fontes externas confiáveis. Essa camada adicional de validação pode ajudar a garantir que as informações fornecidas pelo modelo sejam precisas e confiáveis. +3. Aprimore o modelo com ajuste fino ou embeddings para melhorar a qualidade da saída. Modelos pré-treinados genéricos têm mais chances de produzir informações imprecisas em comparação com modelos ajustados em um domínio específico. Técnicas como engenharia de prompts, ajuste eficiente de parâmetros (PEFT), ajuste total do modelo e prompts encadeados de pensamento podem ser empregadas para esse fim. +4. Implemente mecanismos automáticos de validação que possam verificar a saída gerada em relação a fatos ou dados conhecidos. Isso pode fornecer uma camada adicional de segurança e mitigar os riscos associados a alucinações. +5. Divida tarefas complexas em subtarefas gerenciáveis e atribua-as a diferentes agentes. Isso não apenas ajuda no gerenciamento da complexidade, mas também reduz as chances de alucinações, pois cada agente pode ser responsabilizado por uma tarefa menor. +6. Comunique claramente os riscos e limitações associados ao uso de LLMs. Isso inclui a possibilidade de imprecisões nas informações e outros riscos. Uma comunicação eficaz de riscos pode preparar os usuários para problemas potenciais e ajudá-los a tomar decisões informadas. +7. Construa APIs e interfaces de usuário que incentivem o uso responsável e seguro de LLMs. Isso pode envolver medidas como filtros de conteúdo, avisos ao usuário sobre imprecisões potenciais e rotulagem clara de conteúdo gerado por IA. +8. Ao usar LLMs em ambientes de desenvolvimento, estabeleça práticas e diretrizes seguras de codificação para evitar a integração de possíveis vulnerabilidades. + +### Exemplos de Cenários de Ataque + +1. Uma organização de notícias utiliza intensamente um LLM para gerar artigos. Um ator malicioso explora essa sobrecarga, alimentando informações enganosas ao LLM e causando a propagação de desinformação. +2. A IA inadvertidamente plagiariza um conteúdo, levando a problemas de direitos autorais e diminuindo a confiança na organização. +3. Uma equipe de desenvolvimento de software utiliza um sistema LLM para acelerar o processo de codificação. A sobrecarga nas sugestões do LLM introduz vulnerabilidades de segurança na aplicação devido a configurações padrão inseguras ou recomendações inconsistentes com práticas seguras de codificação. +4. Uma empresa de desenvolvimento de software usa um LLM para auxiliar os desenvolvedores. O LLM sugere uma biblioteca ou pacote de código inexistente, e um desenvolvedor, confiando na IA, integra inadvertidamente um pacote malicioso no software da empresa. Isso destaca a importância de verificar as sugestões do LLM, especialmente ao envolver código ou bibliotecas de terceiros. +### Links de Referência + +1. [Understanding LLM Hallucinations](https://towardsdatascience.com/llm-hallucinations-ec831dcd7786): **Towards Data Science** +2. [How Should Companies Communicate the Risks of Large Language Models to Users?](https://techpolicy.press/how-should-companies-communicate-the-risks-of-large-language-models-to-users/): **Techpolicy** +3. [A news site used AI to write articles. It was a journalistic disaster](https://www.washingtonpost.com/media/2023/01/17/cnet-ai-articles-journalism-corrections/): **Washington Post** +4. [AI Hallucinations: Package Risk](https://vulcan.io/blog/ai-hallucinations-package-risk): **Vulcan.io** +5. [How to Reduce the Hallucinations from Large Language Models](https://thenewstack.io/how-to-reduce-the-hallucinations-from-large-language-models/): **The New Stack** +6. [Practical Steps to Reduce Hallucination](https://newsletter.victordibia.com/p/practical-steps-to-reduce-hallucination): **Victor Debia** diff --git a/1_1_vulns/translations/pt/LLM10_ModelTheft.md b/1_1_vulns/translations/pt/LLM10_ModelTheft.md new file mode 100644 index 00000000..28805cf5 --- /dev/null +++ b/1_1_vulns/translations/pt/LLM10_ModelTheft.md @@ -0,0 +1,55 @@ +## LLM10: Model Theft + +### Descrição + +Esta entrada refere-se ao acesso não autorizado e à exfiltração de modelos LLM por atores maliciosos ou APTs. Isso ocorre quando modelos LLM proprietários (sendo propriedade intelectual valiosa) são comprometidos, fisicamente roubados, copiados ou quando pesos e parâmetros são extraídos para criar um equivalente funcional. O impacto do roubo de modelos LLM pode incluir perda econômica e de reputação da marca, erosão da vantagem competitiva, uso não autorizado do modelo ou acesso não autorizado a informações sensíveis contidas no modelo. + +O roubo de LLMs representa uma preocupação significativa de segurança à medida que os modelos de linguagem se tornam cada vez mais poderosos e prevalentes. Organizações e pesquisadores devem priorizar medidas de segurança robustas para proteger seus modelos LLM, garantindo a confidencialidade e integridade de sua propriedade intelectual. A adoção de um framework de segurança abrangente que inclua controles de acesso, criptografia e monitoramento contínuo é crucial para mitigar os riscos associados ao roubo de modelos LLM e proteger os interesses de indivíduos e organizações que dependem de LLMs. + +### Exemplos Comuns desta Vulnerabilidade + +1. Um atacante explora uma vulnerabilidade na infraestrutura de uma empresa para obter acesso não autorizado ao repositório de modelos LLM por meio de configurações inadequadas na rede ou nas configurações de segurança da aplicação. +2. Um cenário de ameaça interna em que um funcionário descontente vaza modelos ou artefatos relacionados. +3. Um atacante consulta a API do modelo usando inputs cuidadosamente elaborados e técnicas de injeção de prompt para coletar um número suficiente de saídas para criar um modelo sombra. +4. Um atacante malicioso consegue contornar técnicas de filtragem de entrada do LLM para realizar um ataque de canal lateral e, finalmente, extrair pesos do modelo e informações de arquitetura para um recurso controlado remotamente. +5. O vetor de ataque para extração de modelo envolve consultar o LLM com um grande número de prompts sobre um tópico específico. As saídas do LLM podem ser usadas para ajustar outro modelo. No entanto, alguns pontos importantes sobre esse ataque são: + - O atacante deve gerar um grande número de prompts direcionados. Se os prompts não forem específicos o suficiente, as saídas do LLM serão inúteis. + - As saídas dos LLMs podem às vezes conter respostas alucinadas, o que significa que o atacante pode não ser capaz de extrair o modelo inteiro, já que algumas saídas podem ser sem sentido. + - Não é possível replicar um LLM 100% por meio da extração de modelo. No entanto, o atacante será capaz de replicar parcialmente um modelo. +6. O vetor de ataque para **_replicação funcional do modelo_** envolve o uso do modelo-alvo por meio de prompts para gerar dados sintéticos de treinamento (uma abordagem chamada "autoinstrução") para então usá-lo e ajustar outro modelo fundamental para produzir um equivalente funcional. Isso contorna as limitações da extração baseada em consultas tradicional usada no Exemplo 5 e foi usado com sucesso em pesquisas sobre o uso de um LLM para treinar outro LLM. Embora, no contexto dessa pesquisa, a replicação do modelo não seja um ataque. A abordagem poderia ser usada por um atacante para replicar um modelo proprietário com uma API pública. + +O uso de um modelo roubado, como modelo sombra, pode ser usado para realizar ataques adversários, incluindo acesso não autorizado a informações sensíveis contidas no modelo ou experimentar com inputs adversários para realizar injeções avançadas de prompt. + +### Estratégias de Prevenção e Mitigação + +1. Implementar controles de acesso robustos (por exemplo, RBAC e o princípio do menor privilégio) e mecanismos de autenticação sólidos para limitar o acesso não autorizado a repositórios de modelos LLM e ambientes de treinamento. + - Isso é especialmente válido para os três primeiros exemplos comuns, que podem causar essa vulnerabilidade devido a ameaças internas, configuração inadequada e/ou controles de segurança fracos sobre a infraestrutura que abriga modelos LLM, pesos e arquitetura nos quais um ator malicioso poderia infiltrar-se de dentro ou fora do ambiente. + - O rastreamento, verificação e vulnerabilidades de dependência de gerenciamento de fornecedores são tópicos importantes para prevenir exploração de ataques à cadeia de suprimentos. +2. Restringir o acesso do LLM a recursos de rede, serviços internos e APIs. + - Isso é especialmente válido para todos os exemplos comuns, pois cobre riscos e ameaças internas, mas também controla o que a aplicação LLM "_tem acesso_" e, assim, pode ser um mecanismo ou etapa de prevenção para evitar ataques de canal lateral. +3. Usar um Inventário ou Registro Centralizado de Modelos de ML para modelos usados em produção. Ter um registro centralizado de modelos impede o acesso não autorizado a modelos de ML por meio de controles de acesso, autenticação e capacidade de monitoramento/registro, que são bases sólidas para a governança. Ter um repositório centralizado também é benéfico para coletar dados sobre algoritmos usados pelos modelos para fins de conformidade, avaliações de risco e mitigação de riscos. +4. Monitorar regularmente e auditar logs de acesso e atividades relacionadas a repositórios de modelos LLM para detectar e responder prontamente a qualquer comportamento suspeito ou não autorizado. +5. Automatizar implementações MLOps com fluxos de trabalho de governança, rastreamento e aprovação para reforçar controles de acesso e implementação dentro da infraestrutura. +6. Implementar controles e estratégias de mitigação para reduzir o risco de técnicas de injeção de prompt causarem ataques de canal lateral. +7. Limitar a taxa de chamadas de API quando aplicável e/ou implementar filtros para reduzir o risco de exfiltração de dados das aplicações LLM, ou implementar técnicas para detectar (por exemplo, DLP) atividade de extração de outros sistemas de monitoramento. +8. Implementar treinamento de robustez adversária para ajudar a detectar consultas de extração e reforçar medidas de segurança física. +9. Implementar um framework de marca d'água nas etapas de incorporação e detecção do ciclo de vida de um LLM. + +### Exemplos de Cenários de Ataque + +1. Um atacante explora uma vulnerabilidade na infraestrutura de uma empresa para obter acesso não autorizado ao repositório de modelos LLM. O atacante procede a exfiltrar modelos LLM valiosos e os usa para lançar um serviço de processamento de linguagem concorrente ou extrair informações sensíveis, causando danos financeiros significativos à empresa original. +2. Um funcionário descontente vaza modelos ou artefatos relacionados. A exposição pública desse cenário aumenta o conhecimento dos atacantes para ataques adversários de caixa cinza ou, alternativamente, rouba diretamente a propriedade disponível. +3. Um atacante consulta a API com inputs cuidadosamente selecionados e coleta um número suficiente de saídas para criar um modelo sombra. +4. Uma falha de controle de segurança está presente na cadeia de suprimentos e leva a vazamentos de dados de informações proprietárias do modelo. +5. Um atacante malicioso contorna as técnicas de filtragem de entrada e preâmbulos do LLM para realizar um ataque de canal lateral e recuperar informações do modelo para um recurso controlado remotamente sob seu controle. + +### Links de Referência + +1. [Meta’s powerful AI language model has leaked online](https://www.theverge.com/2023/3/8/23629362/meta-ai-language-model-llama-leak-online-misuse): **The Verge** +2. [Runaway LLaMA | How Meta's LLaMA NLP model leaked](https://www.deeplearning.ai/the-batch/how-metas-llama-nlp-model-leaked/): **Deep Learning Blog** +3. [AML.TA0000 ML Model Access](https://atlas.mitre.org/tactics/AML.TA0000): **MITRE ATLAS** +4. [I Know What You See:](https://arxiv.org/pdf/1803.05847.pdf): **Arxiv White Paper** +5. [D-DAE: Defense-Penetrating Model Extraction Attacks:](https://www.computer.org/csdl/proceedings-article/sp/2023/933600a432/1He7YbsiH4c): **Computer.org** +6. [A Comprehensive Defense Framework Against Model Extraction Attacks](https://ieeexplore.ieee.org/document/10080996): **IEEE** +7. [Alpaca: A Strong, Replicable Instruction-Following Model](https://crfm.stanford.edu/2023/03/13/alpaca.html): **Stanford Center on Research for Foundation Models (CRFM)** +8. [How Watermarking Can Help Mitigate The Potential Risks Of LLMs?](https://www.kdnuggets.com/2023/03/watermarking-help-mitigate-potential-risks-llms.html): **KD Nuggets** diff --git a/1_1_vulns/translations/zh/LLM00_Introduction.md b/1_1_vulns/translations/zh/LLM00_Introduction.md new file mode 100644 index 00000000..c2126009 --- /dev/null +++ b/1_1_vulns/translations/zh/LLM00_Introduction.md @@ -0,0 +1,83 @@ +## 介绍 +2022 年底，随着ChatGPT进入大众市场，人们对大型语言模型 (LLM) 的关注尤为浓厚。渴望利用大语言模型潜力的企业正在迅速将其整合到其运营和面向客户的产品中。然而，大语言模型的采用速度已经超过了全面安全协议的建立速度，导致许多应用程序容易受到高风险问题的影响。很明显，大语言模型还没有统一的资源来解决这些安全问题。很多开发者对于与LLM相关的安全风险不够了解，所以相关资源很分散。而OWASP正好能够协助推进这项技术的更安全应用。 + +**它是给谁用的？** +我们的主要受众是开发人员、数据科学家和安全专家，他们的任务是利用LLM技术设计和构建应用程序和插件。我们的目标是提供实用、可操作且简明的安全指南，帮助这些专业人士应对LLM申请安全复杂且不断变化的领域。 + +**清单的制定** +创建 OWASP LLM申请前 10 名列表是一项艰巨的任务，它建立在由近 500 名专家和超过 125 名积极贡献者组成的国际团队的集体专业知识的基础上。我们的贡献者来自不同的背景，包括人工智能公司、安全公司、ISV、云超大规模提供商、硬件提供商和学术界。 + +我们进行了一个月的集思广益，提出了潜在的漏洞，团队成员写下了 43 个不同的威胁。通过多轮投票，我们将这些提案细化为十大最关键漏洞的简明列表。专门的子团队仔细审查了每个漏洞并接受公众审查，以确保获得最全面且可操作的最终列表。 + +**与其他 OWASP 前 10 名列表相关** +虽然我们的列表与其他 OWASP Top 10 列表中发现的漏洞类型具有相同的 DNA，但我们并不是简单地重申这些漏洞。相反，我们深入研究这些漏洞在利用LLM的应用程序中遇到时的独特影响。 + +我们的目标是弥合一般应用程序安全原则和LLM提出的具体挑战之间的鸿沟。这包括探索传统漏洞如何可能带来不同的风险或如何在LLM内以新颖的方式被利用，以及传统的修复策略需要如何适应利用LLM的应用程序。 + +**关于1.1版本** +虽然我们的列表与其他 OWASP Top 10 列表中发现的漏洞类型具有相同的 DNA，但我们并不是简单地重申这些漏洞。相反，我们深入研究这些漏洞在利用 LLM 的应用程序中遇到时的独特影响。我们的目标是弥合一般应用程序安全原则和LLM提出的具体挑战之间的鸿沟。 + +该小组的目标包括探索传统漏洞如何在LLM内造成不同的风险或以新颖的方式被利用，以及开发人员如何必须针对利用LLM的应用程序调整传统的修复策略。 + +**未来** +列表中的 v1.1 不会是我们的最后一个。我们希望定期更新，以跟上行业状况。我们将与更广泛的社区合作，推动最先进的技术，并为各种用途创造更多的教育材料。我们还寻求与标准机构和政府就人工智能安全主题进行合作。我们欢迎您加入我们的团队并做出贡献。 + +### 签名 + +### 史蒂夫·威尔逊 (Steve Wilson) +项目负责人，OWASP Top 10 for LLM Applications +[https://www.linkedin.com/in/wilsonsd](https://www.linkedin.com/in/wilsonsd/) +Twitter/X：@virtualsteve + +### Ads Dawson +v1.1 版本负责人和漏洞条目负责人，OWASP Top 10 for LLM Applications +[https://www.linkedin.com/in/adamdawson0](https://www.linkedin.com/in/adamdawson0/) +GitHub：@GangGreenTemperTatum + + +## 关于本次翻译 + +### 翻译作者 + +- **黄连金 (Ken Huang)** +[https://www.linkedin.com/in/kenhuang8](https://www.linkedin.com/in/kenhuang8/) + + +认识到 OWASP Top 10 for LLM Applications 的非凡技术性和关键性，我们有意识地选择在创作此翻译时仅雇用人工翻译。上述译者不仅对原文内容有深刻的理解，而且语言流畅，有信心使翻译取得成功 + +Talesh Seeparsan +翻译主任 OWASP Top 10 for LLM Applications +[https://www.linkedin.com/in/talesh](https://www.linkedin.com/in/talesh/) + + +## OWASP 大语言模型人工智能应用Top 10 安全威胁 + +**LLM01：提示词(Prompt) 注入(Injection)** +黑客通过设计过的输入（提示词）操纵大型语言模型 (LLM)，从而导致 LLM 执行意外操作。提示词注入会覆盖系统提示词，而间接注入操纵外部数据源进行注入攻击。 + +**LLM02 不安全的输出处理** +当 LLM 输出未经审查而被接受时，就会出现此漏洞，从而暴露后端系统。滥用可能会导致 XSS、CSRF、SSRF、权限升级或远程代码执行等严重后果。 + +**LLM03 训练数据中毒** +当 LLM 培训数据被篡改，引入损害安全性、有效性或道德行为的漏洞或偏见时，就会发生这种情况。来源包括 Common Crawl、 WebText 、 OpenWebText和书籍。 + +**LLM04 拒绝服务模型** +攻击者对大型语言模型进行资源密集型操作，导致服务降级或高成本。由于LLM的资源密集型性质和用户输入的不可预测性，该漏洞被放大。 + +**LLM05 供应链漏洞** +LLM 应用程序生命周期可能会受到易受攻击的组件或服务的影响，从而导致安全攻击。使用第三方数据集、预先训练的模型和插件可能会增加漏洞。 + +**LLM06 敏感信息披露** +LLM可能会在其回复中泄露机密数据，从而导致未经授权的数据访问、隐私侵犯和安全漏洞。实施数据清理和严格的用户策略来缓解这种情况至关重要。 + +**LLM07 不安全的插件设计** +LLM 插件可能具有不安全的输入和不足的访问控制。缺乏应用程序控制使它们更容易被利用，并可能导致远程代码执行等后果。 + +**LLM08 过度代理** +基于LLM的系统可能会采取导致意想不到的后果的行动。该问题源于授予基于 LLM 的系统过多的功能、权限或自主权。 + +**LLM09 过度依赖** +过度依赖LLM而不受监督的系统或人员可能会因LLM生成的不正确或不适当的内容而面临错误信息、沟通不畅、法律问题和安全漏洞。 + +**LLM10 模型盗窃** +这涉及对专有LLM模型的未经授权的访问、复制或泄露。影响包括经济损失、竞争优势受损以及敏感信息的潜在访问。 diff --git a/1_1_vulns/translations/zh/LLM01_PromptInjection.md b/1_1_vulns/translations/zh/LLM01_PromptInjection.md new file mode 100644 index 00000000..146735bb --- /dev/null +++ b/1_1_vulns/translations/zh/LLM01_PromptInjection.md @@ -0,0 +1,56 @@ +## LLM01: 提示词注入 + +### 描述 + +提示词注入漏洞是指攻击者通过精心设计的输入操作大型语言模型（LLM），使LLM无意中执行攻击者的意图。这可以通过直接“越狱”系统提示或通过操纵外部输入间接实现，可能导致数据泄露、社会工程学和其他问题。 + +* **直接提示词注入**，也称为“越狱”，发生在恶意用户覆写或暴露底层*系统*提示时。这可能允许攻击者通过与LLM可访问的不安全功能和数据存储的交互来利用后端系统。 +* **间接提示词注入**发生在LLM接受来自攻击者可控制的外部来源（如网站或文件）的输入时。攻击者可能在外部内容中嵌入提示词注入，劫持对话上下文。这会导致LLM输出的稳定性下降，允许攻击者操纵用户或LLM可访问的其他系统。此外，间接提示词注入不需要对人类可见/可读，只要文本被LLM解析即可。 + +成功的提示词注入攻击的结果可能差异很大 - 从索取敏感信息到在正常操作的伪装下影响关键决策过程。 + +在高级攻击中，LLM可能被操纵以模仿有害人格或与用户设置中的插件交互。这可能导致泄露敏感数据、未经授权的插件使用或社会工程学。在这些情况下，受损的LLM帮助攻击者，超越标准安全措施，让用户对入侵一无所知。在这些实例中，受损的LLM有效地作为攻击者的代理，进一步实现他们的目标，而不触发通常的安全措施或提醒最终用户入侵。 + +### 漏洞的常见示例 + +1. 恶意用户向LLM制造直接提示词注入，指示它忽略应用创建者的系统提示，而执行返回私人、危险或其他不希望信息的提示。 +2. 用户使用LLM总结包含间接提示词注入的网页。这导致LLM向用户索取敏感信息，并通过JavaScript或Markdown进行数据泄露。 +3. 恶意用户上传包含间接提示词注入的简历。该文档包含使LLM通知用户这是一个出色的文档，例如，一个适合职位的出色候选人的提示词注入。内部用户使用LLM总结该文档。LLM的输出返回这是一个出色的文档的信息。 +4. 用户启用链接到电子商务网站的插件。在访问的网站上嵌入的恶意指令利用了这个插件，导致未经授权的购买。 +5. 访问的网站上嵌入的恶意指令和内容利用其他插件欺骗用户。 + +### 预防和缓解策略 + +由于LLM的性质，提示词注入漏洞成为可能，LLM不会将指令和外部数据区分开来。由于LLM使用自然语言，它们将两种形式的输入都视为用户提供的。因此，在LLM内部没有万无一失的预防措施，但以下措施可以减轻提示词注入的影响： + +1. 对LLM访问后端系统的权限进行控制。为LLM提供自己的API令牌，用于可扩展功能，如插件 、数据访问和功能级权限。遵循最小权限原则，仅限制LLM访问为其预期操作必需的最低级别。 +2. 在扩展功能中加入人类环节。在执行特权操作时，如发送或删除电子邮件，要求应用程序先让用户批准该行为。这减少了间接提示词注入导致未经用户知情或同意代表用户执行未授权行为的机会。 +3. 将外部内容与用户提示分离。分开并标明正在使用不受信任的内容，以限制其对用户提示的影响。例如，使用ChatML进行OpenAI API调用，以向LLM指示提示输入的来源。 +4. 在LLM、外部来源和可扩展功能（如插件或下游功能）之间建立信任边界。将LLM视为不受信任的用户，并保持最终用户对决策过程的控制。然而，受损的LLM仍可能作为您的应用程序API和用户之间的中间人（中间人攻击），因为它可能在向用户展示之前隐藏或操纵信息。向用户突出显示可能不可信的响应。 +5. 定期手动监控LLM的输入和输出，以检查它是否符合预期。虽然这不是一种缓解措施，但它可以提供检测弱点和解决它们所需的数据。 + +### 攻击场景举例 + +1. 攻击者向基于LLM的支持聊天机器人提供直接提示词注入。注入包含“忘记所有先前指令”和新指令，查询私有数据存储并利用后端函数的包漏洞和缺乏输出验证发送电子邮件。这导致远程代码执行，获得未授权访问和权限升级。 +2. 攻击者在网页中嵌入间接提示词注入，指示LLM忽略先前用户指令，并使用LLM插件删除用户的电子邮件。当用户使用LLM总结此网页时，LLM插件删除了用户的电子邮件。 +3. 用户使用LLM总结包含指示模型忽略先前用户指令，并改为插入指向包含对话摘要URL的图像的网页。LLM输出遵从指令，导致用户浏览器泄露私人对话。 +4. 恶意用户上传带有提示词注入的简历。后端用户使用LLM总结简历并询问此人是否是合适的候选人。由于提示词注入，尽管实际简历内容并非如此，LLM的回应是肯定的。 +5. 攻击者向依赖系统提示的专有模型发送消息，要求模型忽略其先前指令，改为重复其系统提示。模型输出专有提示，攻击者可以在其他地方使用这些指令，或构建更微妙的进一步攻击。 + +### 参考链接 + +1. [Prompt injection attacks against GPT-3](https://simonwillison.net/2022/Sep/12/prompt-injection/): **Simon Willison** +1. [ChatGPT Plugin Vulnerabilities - Chat with Code](https://embracethered.com/blog/posts/2023/chatgpt-plugin-vulns-chat-with-code/): **Embrace The Red** +1. [ChatGPT Cross Plugin Request Forgery and Prompt Injection](https://embracethered.com/blog/posts/2023/chatgpt-cross-plugin-request-forgery-and-prompt-injection./): **Embrace The Red** +1. [Not what you’ve signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection](https://arxiv.org/pdf/2302.12173.pdf): **Arxiv preprint** +1. [Defending ChatGPT against Jailbreak Attack via Self-Reminder](https://www.researchsquare.com/article/rs-2873090/v1): **Research Square** +1. [Prompt Injection attack against LLM-integrated Applications](https://arxiv.org/abs/2306.05499): **Arxiv preprint** +1. [Inject My PDF: Prompt Injection for your Resume](https://kai-greshake.de/posts/inject-my-pdf/): **Kai Greshake** +1. [ChatML for OpenAI API Calls](https://github.com/openai/openai-python/blob/main/chatml.md): **OpenAI Github** +1. [Threat Modeling LLM Applications](http://aivillage.org/large%20language%20models/threat-modeling-llm/): **AI Village** +1. [AI Injections: Direct and Indirect Prompt Injections and Their Implications](https://embracethered.com/blog/posts/2023/ai-injections-direct-and-indirect-prompt-injection-basics/): **Embrace The Red** +1. [Reducing The Impact of Prompt Injection Attacks Through Design](https://research.kudelskisecurity.com/2023/05/25/reducing-the-impact-of-prompt-injection-attacks-through-design/): **Kudelski Security** +1. [Universal and Transferable Attacks on Aligned Language Models](https://llm-attacks.org/): **LLM-Attacks.org** +1. [Indirect prompt injection](https://kai-greshake.de/posts/llm-malware/): **Kai Greshake** +1. [Declassifying the Responsible Disclosure of the Prompt Injection Attack Vulnerability of GPT-3](https://www.preamble.com/prompt-injection-a-critical-vulnerability-in-the-gpt-3-transformer-and-how-we-can-begin-to-solve-it): **Preamble; earliest disclosure of Prompt Injection** + diff --git a/1_1_vulns/translations/zh/LLM02_InsecureOutputHandling.md b/1_1_vulns/translations/zh/LLM02_InsecureOutputHandling.md new file mode 100644 index 00000000..8035a45f --- /dev/null +++ b/1_1_vulns/translations/zh/LLM02_InsecureOutputHandling.md @@ -0,0 +1,41 @@ +## LLM02: 不安全的输出处理 + +### 描述 + +不安全的输出处理特指在大型语言模型生成的输出被传递到下游其他组件和系统之前，对这些输出进行不充分的验证、清洁和处理。由于大型语言模型生成的内容可以通过提示输入来控制，这种行为类似于向用户间接提供额外功能的访问权限。 + +不安全的输出处理与过度依赖的区别在于，它处理的是大型语言模型生成的输出在被传递到下游之前，而过度依赖则关注于对大型语言模型输出的准确性和适当性的过度依赖。 + +成功利用不安全的输出处理漏洞可能导致在Web浏览器中出现XSS和CSRF，以及在后端系统中出现SSRF、权限升级或远程代码执行。 + +以下条件可能加剧此漏洞的影响： +* 应用程序授予大型语言模型超出终端用户预期的权限，使其能够进行权限提升或远程代码执行。 +* 应用程序容易受到间接提示注入攻击的影响，这可能允许攻击者获得对目标用户环境的特权访问。 +* 第三方插件未能充分验证输入。 + +### 常见漏洞示例 + +1. 大型语言模型输出直接输入到系统Shell或类似功能如exec或eval中，导致远程代码执行。 +2. 大型语言模型生成的JavaScript或Markdown被返回给用户。然后浏览器解释这些代码，导致XSS。 + +### 预防和缓解策略 + +1. 将模型视为任何其他用户，采取零信任方法，并对模型响应到后端功能的输入进行适当的输入验证。 +2. 遵循OWASP ASVS（应用安全验证标准）指南，以确保有效的输入验证和清洁。 +3. 对模型输出回馈给用户的内容进行编码，以缓解JavaScript或Markdown造成的不期望的代码执行。OWASP ASVS提供了关于输出编码的详细指导。 + +### 示例攻击场景 + +1. 一个应用程序使用大型语言模型插件为聊天机器人功能生成响应。该插件还提供了一些可由另一个特权大型语言模型访问的管理功能。通用大型语言模型直接将其响应传递给插件，而没有适当的输出验证，导致插件因维护而关闭。 +2. 一个用户使用由大型语言模型驱动的网站摘要工具，为一篇文章生成简洁摘要。网站包含一个提示注入指令，指示大型语言模型从网站或用户的对话中捕获敏感内容。然后，大型语言模型可以编码敏感数据，并在没有任何输出验证或过滤的情况下发送到攻击者控制的服务器。 +3. 一个大型语言模型允许用户通过类似聊天的功能为后端数据库制定SQL查询。一个用户请求删除所有数据库表的查询。如果来自大型语言模型的制定查询没有受到审查，则所有数据库表将被删除。 +4. 一个Web应用程序使用大型语言模型根据用户文本提示生成内容，但没有进行输出清洁。攻击者可以提交一个精心制作的提示，导致大型语言模型返回一个未经清洁的JavaScript有效载荷，当在受害者的浏览器上呈现时导致XSS。对提示的不充分验证使得这种 攻击成为可能。 + +### 参考链接 + +1. [任意代码执行](https://security.snyk.io/vuln/SNYK-PYTHON-LANGCHAIN-5411357): **Snyk Security Blog** +2. [ChatGPT插件漏洞解释：从提示注入到访问私有数据](https://embracethered.com/blog/posts/2023/chatgpt-cross-plugin-request-forgery-and-prompt-injection./): **Embrace The Red** +3. [新的ChatGPT Web版本的提示注入攻击。Markdown图片可以窃取您的聊天数据。](https://systemweakness.com/new-prompt-injection-attack-on-chatgpt-web-version-ef717492c5c2?gi=8daec85e2116): **System Weakness** +4. [不要盲目信任大型语言模型的回应。聊天机器人的威胁](https://embracethered.com/blog/posts/2023/ai-injections-threats-context-matters/): **Embrace The Red** +5. [大型语言模型应用的威胁建模](https://aivillage.org/large%20language%20models/threat-modeling-llm/): **AI Village** +6. [OWASP ASVS - 5 验证、清洁和编码](https://owasp-aasvs4.readthedocs.io/en/latest/V5.html#validation-sanitization-and-encoding): **OWASP AASVS** diff --git a/1_1_vulns/translations/zh/LLM03_TrainingDataPoisoning.md b/1_1_vulns/translations/zh/LLM03_TrainingDataPoisoning.md new file mode 100644 index 00000000..997221c2 --- /dev/null +++ b/1_1_vulns/translations/zh/LLM03_TrainingDataPoisoning.md @@ -0,0 +1,66 @@ +## LLM03: 训练数据污染 + + +### 描述 + +任何机器学习方法的起点都是训练数据，简单来说就是“原始文本”。为了具有高度的能力（例如具备语言和世界知识），这些文本应涵盖广泛的领域、体裁和语言。大型语言模型使用深度神经网络根据从训练数据中学到的模式生成输出。 + +训练数据污染指的是对预训练数据或在微调或嵌入过程中涉及的数据进行操纵，以引入可能危害模型安全性、效果或道德行为的漏洞（这些漏洞都具有独特且有时共享的攻击向量）、后门或偏见。污染的信息可能会被呈现给用户，或者造成其他风险，如性能下降、下游软件滥用和声誉损害。即使用户不信任有问题的AI输出，风险仍然存在，包括降低模型能力和对品牌声誉的潜在危害。 + +- 预训练数据是指根据任务或数据集对模型进行训练的过程。 +- 微调涉及采用已经训练过的现有模型，并通过使用策划的数据集对其进行训练，以适应更窄的主题或更专注的目标。这个数据集通常包括输入示例和相应的期望输出。 +- 嵌入过程是将分类数据（通常是文本）转换为可以用于训练语言模型的数字表示的过程。嵌入过程涉及将文本数据中的单词或短语表示为连续向量空间中的向量。这些向量通常是通过将文本数据输入到已经在大量文本语料库上进行训练的神经网络中生成的。 + +数据污染被视为完整性攻击，因为篡改训练数据会影响模型输出正确的预测能力。自然而然，外部数据源存在更高的风险，因为模型的创建者无法控制数据或高度自信数据不包含偏见、伪造信息或不恰当的内容。 + +### 常见的漏洞示例 + +1. 恶意行为者或竞争对手故意创建不准确或恶意文件，针对模型的预训练、微调数据或嵌入。考虑[分割视图数据污染](https://github.com/GangGreenTemperTatum/speaking/blob/main/dc604/hacker-summer-camp-23/Ads%20_%20Poisoning%20Web%20Training%20Datasets%20_%20Flow%20Diagram%20-%20Exploit%201%20Split-View%20Data%20Poisoning.jpeg)和[前沿数据污染](https://github.com/GangGreenTemperTatum/speaking/blob/main/dc604/hacker-summer-camp-23/Ads%20_%20Poisoning%20Web%20Training%20Datasets%20_%20Flow%20Diagram%20-%20Exploit%202%20Frontrunning%20Data%20Poisoning.jpeg)攻击向量以进行说明。 + - 受害模型使用伪造信息进行训练，这在生成AI提示的输出中反映出来，呈现给其消费者。 +2. 恶意行为者能够直接注入伪造、有偏见或有害内容到模型的训练过程中，然后在随后的输出中返回。 +3. 一个毫不知情的用户间接地将敏感或专有数据注入到模型的训练过程中，然后在随后的输出中返回。 +4. 模型使用未经验证的数据进行训练，源、起源或训练阶段示例中的内容未经验证，这可能会导致如果数据被污染或不正确，就会产生错误的结果。 +5. 无限制的基础架构访问或不足的沙箱可能会允许模型摄取不安全的训练数据，导致有偏见或有害的输出。这个例子也存在于训练阶段的任何示例中。 + - 在这种情况下，用户对模型的输入可能会反映在向另一个用户的输出中（导致违规），或者LLM的用户可能会收到与所摄取的数据类型相比不准确、不相关或有害的输出（通常在模型卡中反映出来）。 +6. 无论是开发者、客户还是LLM的一般用户，都需要了解这种漏洞在与非专有LLM交互的LLM应用程序中可能会反映出哪些风险，以了解模型输出的合法性是基于其训练过程的。同样，LLM的开发者可能会面临对用于微调和嵌入的内部或第三方数据进行直接和间接攻击的风险（最常见），从而为其所有消费者创建风险。 + +### 预防和缓解策略 + +1. 验证训练数据的供应链，特别是在外部获取的情况下，同时通过“ML-BOM”（机器学习物料清单）方法以及验证模型卡来维护声明。 +2. 验证在预训练、微调和嵌入阶段获取的目标数据源和包 含的数据的正确合法性。 +3. 验证LLM的用例以及将集成到的应用程序。通过不同的训练数据或微调为不同的用例创建不同的模型，以根据其定义的用例创建更精细和准确的生成AI输出。 +4. 确保通过网络控制具有足够的沙箱功能，以防止模型从意外的数据源中抓取数据，从而可能妨碍机器学习输出。 +5. 对特定训练数据或数据源类别使用严格的审查或输入过滤器，以控制虚假数据的数量。使用数据消毒方法，例如统计离群值检测和异常检测方法，以检测并删除潜在输入到微调过程的对抗性数据。 +6. 围绕数据集的来源和所有权提出详细的控制问题，以确保模型没有被污染，并将这一文化纳 + - 入“MLSecOps”周期。参考可用资源，例如[基础模型透明度指数](https://crfm.stanford.edu/fmti/)或[开放LLM排行榜](https://huggingface.co/spaces/HuggingFaceH4/open_llm_leaderboard)等。 +7. 使用DVC（[数据版本控制](https://dvc.org/doc/user-guide/analytics)）来紧密识别和跟踪可能已被篡改、删除或添加的数据集的一部分，导致污染。 +8. 使用矢量数据库添加用户提供的信息，以帮助保护其他用户免受污染，甚至在不必重新训练新模型的情况下进行修复。 +9. 使用对抗性稳健技术，例如联邦学习和约束，以最小化训练数据的极端干扰或对抗性训练，以应对训练数据的最坏情况扰动。 + 1. “MLSecOps”方法可以在训练生命周期中包括对抗性稳健性和自动污染技术。 + 2. 这种方法可以完成Content Injection Attacks（“试图在模型响应中推广品牌名称”）和Refusal Attacks（“始终让模型拒绝响应”的攻击），例如[AutoPoison](https://github.com/azshue/AutoPoison)。 +10. 通过测量训练阶段的损失并分析经过训练的模型来检测污染攻击的迹象，以及通过分析特定测试输入上的模型行为来检测污染攻击。 + 1. 监控和警报超过阈值的倾斜响应的数量。 + 2. 使用人工回环来审查响应和审计。 + 3. 实施专门的LLM来对抗不希望的后果，并使用[强化学习技术](https://wandb.ai/ayush-thakur/Intro-RLAIF/reports/An-Introduction-to-Training-LLMs-Using-Reinforcement-Learning-From-Human-Feedback-RLHF---VmlldzozMzYyNjcy)来训练其他LLM。 + 4. 在LLM的生命周期测试阶段进行基于LLM的[红队演习](https://www.anthropic.com/index/red-teaming-language-models-to-reduce-harms-methods-scaling-behaviors-and-lessons-learned)或[LLM漏洞扫描](https://github.com/leondz/garak)。 + +### 攻击场景示例 + +1. LLM生成AI提示输出可能会误导应用程序的用户，导致有偏见的观点、跟踪或甚至更糟的情况，例如仇恨犯罪等。 +2. 如果训练数据没有正确过滤和消毒，应用程序的恶意用户可能会尝试影响并向模型注入有毒数据，以使其适应有偏见和虚假数据。 +3. 恶意行为者或竞争对手故意创建不准确或恶意文件，针对模型的训练数据，同时根据输入训练模型。受害模型使用这些伪造信息进行训练，这在生成AI提示的输出中反映出来，呈现给其消费者。 +4. 如果在LLM应用程序的客户端输入用于训练模型时未执行足够的消毒和过滤，那么漏洞[Prompt Injection](https://github.com/OWASP/www-project-top-10-for-large-language-model-applications/blob/main/1_0_vulns/PromptInjection.md)可能会成为这种漏洞的攻击向量。即，如果从客户端输入模型的恶意或伪造数据作为提示注入技术的一部分，则这可能会被直接反映到模型数据中。 + +### 参考链接 + +1. [Stanford Research Paper:CS324](https://stanford-cs324.github.io/winter2022/lectures/data/): **斯坦福研究** +2. [数据污染攻击如何破坏机器学习模型](https://www.csoonline.com/article/3613932/how-data-poisoning-attacks-corrupt-machine-learning-models.html): **CSO Online** +3. [MITRE ATLAS (framework) Tay中毒](https://atlas.mitre.org/studies/AML.CS0009/): **MITRE ATLAS** +4. [PoisonGPT：我们如何在Hugging Face上隐藏了一个切断连接的LLM以传播假新闻](https://blog.mithrilsecurity.io/poisongpt-how-we-hid-a-lobotomized-llm-on-hugging-face-to-spread-fake-news/): **Mithril Security** +5. [Inject My PDF：为您的简历进行提示注入](https://kai-greshake.de/posts/inject-my-pdf/): **Kai Greshake** +6. [语言模型的后门攻击](https://towardsdatascience.com/backdoor-attacks-on-language-models-can-we-trust-our-models-weights-73108f9dcb1f): **Towards Data Science** +7. [在指令期间污染语言模型](https://arxiv.org/abs/2305.00944): **Arxiv白皮书** +8. [FedMLSecurity:arXiv:2306.04959](https://arxiv.org/abs/2306.04959): **Arxiv白皮书** +9. [ChatGPT的中毒](https://softwarecrisis.dev/letters/the-poisoning-of-chatgpt/): **Software Crisis Blog** +10. [污染Web规模培训数据集 - Nicholas Carlini | 斯坦福MLSys #75](https://www.youtube.com/watch?v=h9jf1ikcGyk): **YouTube视频** +11. [OWASP CycloneDX v1.5](https://cyclonedx.org/capabilities/mlbom/): **OWASP CycloneDX** diff --git a/1_1_vulns/translations/zh/LLM04_ModelDoS.md b/1_1_vulns/translations/zh/LLM04_ModelDoS.md new file mode 100644 index 00000000..f4bacebd --- /dev/null +++ b/1_1_vulns/translations/zh/LLM04_ModelDoS.md @@ -0,0 +1,42 @@ +## LLM04: 模型拒绝服务 + +### 描述 + +攻击者与LLM（大型语言模型）交互的方式会消耗异常多的资源，导致其自身和其他用户的服务质量下降，可能还会产生高昂的资源成本。此外，一个新兴的主要安全关切是攻击者可能干扰或操纵LLM的上下文窗口。由于LLM在各种应用中的使用越来越广泛，它们对资源的密集利用、用户输入的不可预测性以及开发人员对这一漏洞的普遍不了解，这个问题变得越来越关键。在LLM中，上下文窗口代表模型可以处理的文本的最大长度，包括输入和输出。这是LLM的一个关键特性，因为它决定了模型可以理解的语言模式的复杂性以及它可以在任何给定时间处理的文本的大小。上下文窗口的大小由模型的架构定义，并可能因模型而异。 + +### 漏洞的常见示例 + +1. 提出导致通过高容量生成任务队列中的高卷入而导致资源使用量不断重复的查询，例如使用LangChain或AutoGPT。 +2. 发送异常消耗资源的查询，使用异常的拼写法或序列。 +3. 持续输入溢出：攻击者向LLM发送超出其上下文窗口的输入流，导致模型消耗过多的计算资源。 +4. 重复的长输入：攻击者反复向LLM发送超出上下文窗口的长输入。 +5. 递归上下文扩展：攻击者构建的输入触发递归上下文扩展，强制LLM反复扩展和处理上下文窗口。 +6. 变长输入洪水攻击：攻击者向LLM洪水般发送大量的变长输入，其中每个输入都精心制作，以达到上下文窗口的限制。这种技术旨在利用处理变长输入的任何效率低下之处，使LLM负担过重，可能导致其无法响应。 + +### 预防和缓解策略 + +1. 实施输入验证和清理，以确保用户输入符合定义的限制，并过滤掉任何恶意内容。 +2. 限制每个请求或步骤的资源使用，以便涉及复杂部分的请求执行更慢。 +3. 强制执行API速率限制，限制个体用户或IP地址在特定时间内可以发出的请求数量。 +4. 限制排队操作的数量和对LLM响应的系统中的总操作数量。 +5. 持续监视LLM的资源利用情况，以识别异常的峰值或模式，可能表明存在拒绝服务攻击。 +6. 基于LLM的上下文窗口设置严格的输入限制，以防止超载和资源耗尽。 +7. 向开发人员提供有关LLM中可能存在的拒绝服务漏洞的意识，并提供安全LLM实施的指南。 + +### 示例攻击场景 + +1. 攻击者反复向托管模型发送多个困难且耗费大量资源的请求，导致其他用户的服务质量下降，托管方的资源费用增加。 +2. 在LLM驱动的工具正在收集信息以回应良性查询时，遇到网页上的一段文本。这导致工具发出了更多的网页请求，导致大量资源消耗。 +3. 攻击者持续不断地向LLM发送超出其上下文窗口的输入。攻击者可能使用自动化脚本或工具发送大量输入，压倒LLM的处理能力。结果，LLM消耗了过多的计算资源，导致系统明显减慢或完全不响应。 +4. 攻击者向LLM发送一系列连续的输入，每个输入都设计为略低于上下文窗口的限制。通过反复提交这些输入，攻击者旨在耗尽可用的上下文窗口容量。由于LLM在其上下文窗口内努力处理每个输入，系统资源变得紧张，可能导致性能下降或完全拒绝服务。 +5. 攻击者利用LLM的递归机制反复触发上下文扩展。通过制作利用LLM递归行为的输入，攻击者迫使模型反复扩展和处理上下文窗口，消耗大量计算资源。这种攻击会使系统受到压力，可能导致拒绝服务状况，使LLM无法响应或导致崩溃。 +6. 攻击者向LLM洪水般发送大量的变长输入，经过精心制作，以接近或达到上下文窗口的限制。通过用不同长度的输入淹没LLM，攻击者旨在利用处理变长输入的任何低效之处。这些输入的洪水会对LLM的资源造成过多负担，可能导致性能下降，妨碍系统响应合法请求。 +7. 尽管拒绝服务攻击通常旨在超载系统资源，但它们也可能利用系统行为的其他方面，例如API限制。例如，在最近的Sourcegraph安全事件中， 恶意行为者使用泄露的管理员访问令牌来更改API速率限制，从而通过启用异常高的请求量可能导致服务中断。 + +### 参考链接 + +1. [LangChain max_iterations](https://twitter.com/hwchase17/status/1608467493877579777): **Twitter上的hwchase17** +2. [海绵示例：对神经网络的能量-延迟攻击](https://arxiv.org/abs/2006.03463): **Arxiv白皮书** +3. [OWASP拒绝服务攻击](https://owasp.org/www-community/attacks/Denial_of_Service): **OWASP** +4. [从机器中学到：了解上下文](https://lukebechtel.com/blog/lfm-know-thy-context): **Luke Bechtel** +5. [关于API限制操纵和拒绝服务攻击的Sourcegraph安全事件](https://about.sourcegraph.com/blog/security-update-august-2023): **Sourcegraph** diff --git a/1_1_vulns/translations/zh/LLM05_SupplyChainVulnerabilities.md b/1_1_vulns/translations/zh/LLM05_SupplyChainVulnerabilities.md new file mode 100644 index 00000000..2d50213b --- /dev/null +++ b/1_1_vulns/translations/zh/LLM05_SupplyChainVulnerabilities.md @@ -0,0 +1,51 @@ +## LLM05：供应链漏洞 + +### 描述 + +LLM中的供应链可能会受到威胁，影响训练数据、机器学习模型和部署平台的完整性。这些漏洞可能导致偏见结果、安全漏洞，甚至完全的系统故障。传统上，漏洞主要集中在软件组件上，但机器学习通过由第三方提供的预训练模型和训练数据扩展了这一概念，这些数据容易受到篡改和恶意攻击的影响。 + +最后，LLM插件扩展可能存在自己的漏洞。这些在[LLM07 - 不安全的插件设计](InsecurePluginDesign.md)中有描述，该文档涵盖了编写LLM插件的内容，并提供了有关评估第三方插件的有用信息。 + +### 漏洞的常见示例 + +1. 传统的第三方软件包漏洞，包括过时或不再维护的组件。 +2. 使用易受攻击的预训练模型进行微调。 +3. 使用恶意篡改的众包数据进行训练。 +4. 使用不再维护的过时模型会导致安全问题。 +5. 模型运营商的条款和数据隐私政策不明确，导致应用程序的敏感数据用于模型训练，随后敏感信息暴露。这也可能涉及到使用模型供应商的受版权保护材料而带来的风险。 + +### 预防和缓解策略 + +1. 仔细审查数据来源和供应商，包括条款和隐私政策，只使用可信任的供应商。确保有足够的独立审核的安全措施，并且模型运营商的政策与您的数据保护政策一致，即不使用您的数据来训练他们的模型；同样，寻求确保不会使用模型维护者的受版权保护材料的保证和法律减轻措施。 +2. 只使用有声望的插件，并确保它们已经经过测试，符合您的应用程序要求。LLM不安全的插件设计提供了有关应该针对第三方插件进行测试以减轻风险的LLM方面的信息。 +3. 了解并应用OWASP十大的[A06:2021 – 易受攻击和过时的组件](https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/)中找到的减轻措施。这包括漏洞扫描、管理和补丁组件。对于具有敏感数据访问权限的开发环境，也在这些环境中应用这些控制措施。 +4. 使用软件物料清单（SBOM）维护一个最新的组件清单，以确保您有一个最新、准确和已签名的清单，防止部署包的篡改。SBOM可以用于快速检测和警报新的零日漏洞。 +5. 就我所知，SBOM不包括模型、模型工件和数据集。如果您的LLM应用程序使用自己的模型，您应该使用MLOps最佳实践和提供安全模型存储库的平台，其中包括数据、模型和实验跟踪。 +6. 在使用外部模型和供应商时，您还应该使用模型和代码签名。 +7. 对供应的模型和数据进行异常检测和对抗性稳健性测试，以帮助检测篡改和恶意攻击，如[训练数据篡改](https://github.com/OWASP/www-project-top-10-for-large-language-model-applications/blob/main/1_0_vulns/Training_Data_Poisoning.md)中所讨论的那样；理想情况下，这应该是MLOps流程的一部分；但这些是新兴技术，可能更容易作为红队演练的一部分来实施。 +8. 实施足够的监控，包括组件和环境漏洞扫描、未经授权的插件使用以及过时的组件，包括模型及其工件。 +9. 实施一个补丁政策，以减轻易受攻击或过时的组件。确保应用程序依赖于维护的API版本和底层模型。 +10. 定期审查和审核供应商的安全性和访问权限，确保其安全性政策或条款没有发生变化。 + +### 攻击场景示例 + +1. 攻击者利用易受攻击的Python库来入侵系统。这在第一次Open AI数据泄露中发生过。 +2. 攻击者提供了一个LLM插件，用于搜索航班，生成导致用户被欺诈的假链接。 +3. 攻击者利用PyPi软件包注册表来欺骗模型开发人员下载受损包并窃取数据或提升在模型开发环境中的特权。这是一个真实的攻击。 +4. 攻击者篡改了一个公开可用的预训练模型，该模型专门用于经济分析和社会研究，以创建一个后门，生成虚假信息和假新闻。他们将其部署在一个模型市场上（例如Hugging Face），供受害者使用。 +5. 攻击者在微调模型时篡改了公开可用的数据集，以帮助创建后门。这个后门会在不同市场中悄然支持某些公司。 +6. 供应商（外包开发人员、托管公司等）的受损员工窃取数据、模型或代码，窃取知识产权。 +7. LLM运营商更改其条款和隐私政策，要求明确选择不使用(opt out) 数据进行模型训练，导致敏感数据的记忆。 + +### 参考链接 + +1. [ChatGPT数据泄露确认为安全公司警告的易受攻击组件利用](https://www.securityweek.com/chatgpt-data-breach-confirmed-as-security-firm-warns-of-vulnerable-component-exploitation/): **安全周刊** +2. [插件审查流程](https://platform.openai.com/docs/plugins/review): **OpenAI** +3. [PyTorch-nightly依赖链受损](https://pytorch.org/blog/compromised-nightly-dependency/): **Pytorch** +4. [PoisonGPT：我们如何隐藏一个被切除大脑的LLM在Hugging Face上传播假新闻](https://blog.mithrilsecurity.io/poisongpt-how-we-hid-a-lobotomized-llm-on-hugging-face-to-spread-fake-news/): **Mithril Security** +5. [军方正在考虑“AI BOMs”的可能性](https://defensescoop.com/2023/05/25/army-looking-at-the-possibility-of-ai-boms-bill-of-materials/): **Defense Scoop** +6. [机器学习的故障模式](https://learn.microsoft.com/en-us/security/engineering/failure-modes-in-machine-learning): **Microsoft** +7. [ML供应链妥协](https://atlas.mitre.org/techniques/AML.T0010/): **MITRE ATLAS** +8. [机器学习中的可传递性：从现象到使用对抗样本的黑匣子攻击](https://arxiv.org/pdf/1605.07277.pdf): **Arxiv白皮书** +9. [BadNets：识别机器学习模型供应链中的漏洞](https://arxiv.org/abs/1708.06733): **Arxiv白皮书** +10. [VirusTotal Poisoning](https://atlas.mitre.org/studies/AML.CS0002): **MITRE ATLAS** diff --git a/1_1_vulns/translations/zh/LLM06_SensitiveInformationDisclosure.md b/1_1_vulns/translations/zh/LLM06_SensitiveInformationDisclosure.md new file mode 100644 index 00000000..74e99714 --- /dev/null +++ b/1_1_vulns/translations/zh/LLM06_SensitiveInformationDisclosure.md @@ -0,0 +1,39 @@ +## LLM06：敏感信息泄露 + +### 描述 + +LLM应用程序有潜力通过其输出透露敏感信息、专有算法或其他机密细节。这可能导致未经授权访问敏感数据、知识产权、侵犯隐私和其他安全漏洞。LLM应用程序的消费者需要了解如何安全地与LLM进行交互，并识别与无意中输入的敏感数据相关的风险，这些数据可能随后由LLM在其他地方的输出中返回。 + +为了减轻这一风险，LLM应用程序应执行充分的数据净化，以防止用户数据进入训练模型数据中。LLM应用程序的所有者还应该制定适当的使用条款政策，让消费者了解他们的数据如何被处理，并有选择不将其数据包含在训练模型中的权利。 + +消费者-LLM应用程序的互动形成了一个双向的信任边界，我们不能从根本上信任客户端->LLM输入或LLM->客户端输出。需要注意的是，这种漏洞假定某些前提条件超出了范围，例如威胁建模练习、保护基础架构以及充分的沙箱化。在系统提示中添加关于LLM应该返回的数据类型的限制可以在一定程度上减轻敏感信息泄露的风险，但LLM的不可预测性意味着这些限制可能并不总是会被遵守，并且可以通过提示注入或其他方式来绕过。 + +### 漏洞的常见示例 + +1. LLM响应中对敏感信息的不完整或不正确的过滤。 +2. 在LLM的训练过程中对敏感数据的过度拟合或记忆。 +3. 由于LLM误解、缺乏数据净化方法或错误，导致机密信息的意外泄露。 + +### 预防和缓解策略 + +1. 集成充分的数据净化和清理技术，以防止用户数据进入训练模型数据。 +2. 实施强大的输入验证和净化方法，以识别和过滤掉潜在的恶意输入，以防止模型被污染。 +3. 在丰富模型的数据和[微调](https://github.com/OWASP/www-project-top-10-for-large-language-model-applications/wiki/Definitions)模型时：（即在部署之前或部署过程中输入模型的数据） + - 在微调数据中被视为敏感的任何信息都有可能向用户透露。因此，请应用最小权限原则，不要训练模型使用最高权限用户可以访问的信息，因为这些信息可能会显示给较低权限的用户。 + - 对运行时的外部数据源（数据协调）的访问应受到限制。 + - 对外部数据源应用严格的访问控制方法，以及对维护安全供应链的严格方法。 + +### 攻击场景示例 + +1. 毫不知情的合法用户A在与LLM应用程序进行非恶意交互时，通过LLM向其显示了某些其他用户的数据。 +2. 用户A通过精心设计的一组提示，绕过LLM的输入过滤和净化，使其透露有关应用程序其他用户的敏感信息（PII）。 +3. 个人数据，如PII，通过训练数据泄漏到模型中，要么是由于用户本身的疏忽，要么是由于LLM应用程序的错误。这种情况可能会增加上述情况1或2的风险和概率。 + +### 参考链接 + +1. [AI数据泄露危机：新工具防止公司机密被提供给ChatGPT](https://www.foxbusiness.com/politics/ai-data-leak-crisis-prevent-company-secrets-chatgpt): **福克斯商业** +2. [从ChatGPT的三星泄漏中吸取的教训](https://cybernews.com/security/chatgpt-samsung-leak-explained-lessons/): **Cybernews** +3. [Cohere - 使用条款](https://cohere.com/terms-of-use): **Cohere** +4. [威胁建模示例](https://aivillage.org/large%20language%20models/threat-modeling-llm/): **AI Village** +5. [OWASP人工智能安全和隐私指南](https://owasp.org/www-project-ai-security-and-privacy-guide/): **OWASP人工智能安全与隐私指南** +6. [确保大型语言模型的安全性](https://www.experts-exchange.com/articles/38220/Ensuring-the-Security-of-Large-Language-Models-Strategies-and-Best-Practices.html): **Experts Exchange** diff --git a/1_1_vulns/translations/zh/LLM07_InsecurePluginDesign.md b/1_1_vulns/translations/zh/LLM07_InsecurePluginDesign.md new file mode 100644 index 00000000..99a2fe93 --- /dev/null +++ b/1_1_vulns/translations/zh/LLM07_InsecurePluginDesign.md @@ -0,0 +1,48 @@ +## LLM07：不安全的插件设计 + +### 描述 + +LLM插件是扩展，当启用时，会在用户互动期间由模型自动调用。模型集成平台驱动它们，应用程序可能无法控制执行，特别是当模型由另一方托管时。此外，插件很可能会从模型中实现来自模型的自由文本输入，而不进行验证或类型检查以处理上下文大小限制。这使得潜在攻击者可以构造一个恶意请求发送给插件，可能导致各种不希望发生的行为，甚至包括远程代码执行。 + +恶意输入的危害通常取决于不足的访问控制和未能跟踪授权的插件。不足的访问控制允许插件盲目信任其他插件，并假定最终用户提供了输入。这种不足的访问控制可以使恶意输入产生各种有害后果，包括数据泄露、远程代码执行和特权升级。 + +此项重点是创建LLM插件而不是第三方插件，LLM供应链漏洞涵盖了第三方插件。 + +### 漏洞的常见示例 + +1. 插件接受单个文本字段中的所有参数，而不是不同的输入参数。 +2. 插件接受配置字符串，而不是可以覆盖整个配置设置的参数。 +3. 插件接受原始SQL或编程语句，而不是参数。 +4. 执行身份验证时没有对特定插件进行明确授权。 +5. 插件将所有LLM内容视为完全由用户创建，并在不需要额外授权的情况下执行任何请求的操作。 + +### 预防和缓解策略 + +1. 插件应尽可能强制执行严格的参数化输入，并对输入进行类型和范围检查。如果不可能进行此操作，应引入第二层类型化调用，解析请求并应用验证和净化。当由于应用程序语义需要接受自由形式的输入时，应仔细检查以确保不会调用任何潜在有害的方法。 +2. 插件开发人员应遵循OWASP的建议，使用ASVS（应用程序安全性验证标准）确保适当的输入验证和净化。 +3. 应对插件进行彻底的检查和测试，以确保适当的验证。在开发流水线中使用静态应用程序安全性测试（SAST）扫描以及动态和交互式应用程序测试（DAST，IAST）。 +4. 插件应设计以最小化不安全输入参数利用的影响，遵循OWASP ASVS访问控制准则。这包括最小权限访问控制，尽可能少地暴露功能，同时仍然执行其所需的功能。 +5. 插件应使用适当的身份验证身份，例如OAuth2，以应用有效的授权和访问控制。此外，应使用API密钥来提供上下文，以进行自定义授权决策，反映插件路由而不是默认的交互用户。 +6. 对于敏感插件执行的任何操作，都应要求手动用户授权和确认。 +7. 插件通常是REST API，因此开发人员应应用OWASP Top 10 API安全风险 – 2023中找到的建议，以最小化通用漏洞。 + +### 攻击场景示例 + +1. 一个插件接受基本URL，并指示LLM将URL与查询组合以获取天气预报，然后将其包含在处理用户请求中。恶意用户可以精心制作请求，使URL指向他们控制的域，从而允许他们通过其域名将自己的内容注入LLM系统。 +2. 一个插件接受自由形式的输入到一个不验证的单一字段。攻击者提供精心制作的有效负载，以从错误消息中执行侦察。然后利用已知的第三方漏洞来执行代码并执行数据泄露或特权升级。 +3. 用于从向量存储中检索嵌入的插件接受连接字符串作为配置参数，而不进行任何验证。这允许攻击者尝试并访问其他向量存储，通过更改名称或主机参数来突破，以及窃取他们不应该访问的嵌入。 +4. 一个插件接受SQL WHERE子句作为高级过滤器，然后将其附加到过滤SQL中。这允许攻击者进行SQL攻击。 +5. 攻击者使用间接提示注入来利用一个没有输入验证和弱访问控制的不安全代码管理插件，以转移仓库所有权并锁定用户对其仓库的访问权。 + +### 参考链接 + +1. [OpenAI ChatGPT插件](https://platform.openai.com/docs/plugins/introduction): **ChatGPT开发者指南** +2. [OpenAI ChatGPT插件 - 插件流程](https://platform.openai.com/docs/plugins/introduction/plugin-flow): **OpenAI文档** +3. [OpenAI ChatGPT插件 - 身份验证](https://platform.openai.com/docs/plugins/authentication/service-level): **OpenAI文档** +4. [OpenAI语义搜索插件示例](https://github.com/openai/chatgpt-retrieval-plugin): **OpenAI Github** +5. [插件漏洞：访问网站并让您的源代码被窃取](https://embracethered.com/blog/posts/2023/chatgpt-plugin-vulns-chat-with-code/): **Embrace The Red** +6. [ChatGPT插件漏洞解释：从提示注入到访问私人数据](https://embracethered.com/blog/posts/2023/chatgpt-cross-plugin-request-forgery-and-prompt-injection./): **Embrace The Red** +7. [OWASP ASVS - 5 验证、净化和编码](https://owasp-aasvs4.readthedocs.io/en/latest/V5.html#validation-sanitization-and-encoding): **OWASP AASVS** +8. [OWASP ASVS 4.1 通用访问控制设计](https://owasp-aasvs4.readthedocs.io/en/latest/V4.1.html#general-access-control-design): **OWASP AASVS** +9. [OWASP Top 10 API安全风险 – 2023](https://owasp.org/API-Security/editions/2023/en/0x11-t10/): **OWASP** + diff --git a/1_1_vulns/translations/zh/LLM08_ExcessiveAgency.md b/1_1_vulns/translations/zh/LLM08_ExcessiveAgency.md new file mode 100644 index 00000000..03fd8f70 --- /dev/null +++ b/1_1_vulns/translations/zh/LLM08_ExcessiveAgency.md @@ -0,0 +1,52 @@ +## LLM08: 过度代理 + +### 描述 + +基于LLM的系统通常由开发人员授予一定程度的代理权限 - 即与其他系统进行交互并在响应提示时执行操作的能力。关于调用哪些功能的决策也可以委托给LLM的“代理”根据输入提示或LLM的输出动态确定。 + +过度代理是一种漏洞，允许在LLM出现意外/模糊输出时执行破坏性操作（无论是什么导致LLM发生故障；无论是幻觉/混淆、直接/间接提示注入、恶意插件、工程不良的良性提示还是性能不佳的模型）。过度代理的根本原因通常是：功能过多、权限过多或自主权过多。这与不安全的输出处理不同，后者关注LLM输出的不充分审查。 + +过度代理可以导致涉及机密性、完整性和可用性等方面的一系列影响，这取决于LLM应用程序能够与哪些系统进行交互。 + +### 常见的漏洞示例 + +1. 过度功能：LLM代理可以访问包括系统操作中不需要的功能在内的插件。例如，开发人员需要授予LLM代理从存储库中读取文档的能力，但他们选择使用的第三方插件还包括修改和删除文档的功能。 +2. 过度功能：在开发阶段可能会尝试使用某个插件，但最终选择了更好的替代方案，但原始插件仍然可供LLM代理使用。 +3. 过度功能：一个具有开放式功能的LLM插件未能正确过滤命令之外的输入指令，而这些命令对于应用程序的预期操作来说是不必要的。例如，用于运行一个特定shell命令的插件未能有效阻止其他shell命令的执行。 +4. 过度权限：LLM插件在其他系统上具有不必要的权限，这些权限对于应用程序的预期操作来说是不必要的。例如，一个旨在读取数据的插件连接到数据库服务器时，使用的身份不仅具有SELECT权限，还具有UPDATE、INSERT和DELETE权限。 +5. 过度权限：旨在代表用户执行操作的LLM插件使用通用高特权标识访问下游系统。例如，一个用于读取当前用户文档存储的插件连接到文档存储库时，使用了一个具有访问所有用户文件权限的特权帐户。 +6. 过度自主权：LLM基于应用程序或插件未能独立验证和批准高影响操作。例如，允许删除用户文档的插件执行删除操作时，无需用户的任何确认。 + +### 预防和缓解策略 + +以下操作可以防止过度代理： + +1. 限制LLM代理被允许调用的插件/工具，仅限于所需的最小功能。例如，如果LLM基础系统不需要获取URL内容的能力，那么不应该向LLM代理提供这样的插件。 +2. 限制在LLM插件/工具中实现的功能到最低程度。例如，一个插件用于访问用户的邮箱以总结电子邮件内容，可能只需要读取电子邮件的能力，因此插件不应包含其他功能，比如删除或发送邮件。 +3. 在可能的情况下避免开放式功能（例如运行shell命令、获取URL等），并使用更细粒度功能的插件/工具。例如，LLM基础应用程序可能需要将某些输出写入文件。如果使用插件运行shell功能来实现这一点，那么不希望的操作的范围就会非常大（可以执行任何其他shell命令）。更安全的替代方案是构建一个只支持特定功能的文件写入插件。 +4. 限制LLM插件/工具被授予的连接到其他系统的权限到最低程度，以限制不必要操作的范围。例如，使用产品数据库来向客户提供购买建议的LLM代理可能只需要对“产品”表的只读访问权限；它不应该具有对其他表的访问权限，也不应该具有插入、更新或删除记录的权限。这应该通过为LLM插件用于连接到数据库的身份应用适当的数据库权限来强制执行。 +5. 跟踪用户授权和安全范围，以确保代表用户执行的操作在特定用户的下游系统中以该特定用户的上下文和最低权限执行。例如，一个用于读取用户代码库的LLM插件应该要求用户通过OAuth进行身份验证，并且仅具有所需的最低权限。 +6. 利用人在循环控制，要求人在执行所有操作之前批准所有操作。这可以在下游系统中实现（超出了LLM应用程序的范围）或在LLM插件/工具本身中实现。例如，一个基于LLM的应用程序，用于代表用户创建和发布社交媒体内容，应该在插件/工具/API内包括一个用户批准程序，该程序执行“发布”操作。 +7. 在下游系统中实施授权，而不是依赖LLM来决定是否允许操作。在实现工具/插件时强制执行完整中介原则，以便通过工具/插件发出的所有请求都会根据安全策略进行验证。 + +以下选项不能防止过度代理，但可以限制造成的损害程度： + +1. 记录和监控LLM插件/工具和下游系统的活动，以识别不必要操作发生的地方，并采取相应的措施。 +2. 实施速率限制，减少在给定时间段内可以执行的不必要操作数量，增加通过监控发现不必要操作的机会，在造成重大损害之前发现问题。 + +### 攻击场景示例 + +一个基于LLM的个人助手应用程序通过插件被授予访问个人邮箱的权限，以便总结收件箱中的邮件内容。为实现此功能，邮件插件需要具备读取邮件的能力，但系统开发人员选择使用的插件还包含发送邮件的功能。LLM容易受到间接提示注入攻击的威胁，恶意构造的入站邮件欺骗LLM，使其命令邮件插件调用“发送邮件”功能，从用户的邮箱发送垃圾邮件。可以通过以下方式避免这种情况： +(a) 通过使用仅提供邮件阅读功能的插件来消除过多的功能， +(b) 通过使用OAuth会话进行身份验证，具有只读权限范围，来消除过多的权限，和/或 +(c) 通过要求用户手动审核并点击LLM插件起草的每封邮件来消除过多的自主权。 +或者，还可以通过在发送邮件接口上实施速率限制来减少造成的损害。 + +### 参考链接 + +1. [Embrace the Red: Confused Deputy Problem](https://embracethered.com/blog/posts/2023/chatgpt-cross-plugin-request-forgery-and-prompt-injection./): **Embrace The Red** +2. [NeMo-Guardrails: 接口指南](https://github.com/NVIDIA/NeMo-Guardrails/blob/main/docs/security/guidelines.md): **NVIDIA Github** +3. [LangChain: 工具的人工批准](https://python.langchain.com/docs/modules/agents/tools/how_to/human_approval): **Langchain文档** +4. [Simon Willison: 双LLM模式](https://simonwillison.net/2023/Apr/25/dual-llm-pattern/): **Simon Willison** + + diff --git a/1_1_vulns/translations/zh/LLM09_Overreliance.md b/1_1_vulns/translations/zh/LLM09_Overreliance.md new file mode 100644 index 00000000..a4b55477 --- /dev/null +++ b/1_1_vulns/translations/zh/LLM09_Overreliance.md @@ -0,0 +1,44 @@ +## LLM09: 过度依赖 + +### 描述 + +当一个LLM以权威的方式产生错误信息并提供给用户时，就会出现过度依赖的情况。虽然LLM可以生成富有创意和信息丰富的内容，但它们也可以生成事实不准确、不适当或不安全的内容。这被称为幻觉或混淆。当人们或系统信任这些信息而没有监督或确认时，可能会导致安全漏洞、错误信息、沟通不畅、法律问题和声誉损害。 + +LLM生成的源代码可能引入未被注意到的安全漏洞。这对应用程序的操作安全性和安全性构成了重大风险。这些风险突显了审查过程的重要性，其中包括： + +* 监督 +* 持续验证机制 +* 风险免责声明 + +### 常见漏洞示例 + +1. LLM以一种高度权威的方式提供不准确的信息作为响应。整个系统没有适当的检查和平衡来处理这种情况，信息误导用户导致损害。 +2. LLM建议不安全或有缺陷的代码，导致在没有适当监督或验证的情况下将其纳入软件系统中产生漏洞。 + +### 预防和减轻策略 + +1. 定期监控和审查LLM的输出。使用自一致性或投票技术来过滤不一致的文本。比较单一提示的多个模型响应可以更好地判断输出的质量和一致性。 +2. 将LLM的输出与可信的外部来源进行交叉验证。这一额外的验证层可以帮助确保模型提供的信息是准确可靠的。 +3. 通过微调或嵌入来改进模型的输出质量。通用的预训练模型更有可能产生不准确的信息，而与特定领域的调整模型相比，它们更容易产生不准确的信息。可以使用提示工程、参数高效调整（PET）、全模型调整和思维链提示等技术来实现这一目的。 +4. 实施可以将生成的输出与已知事实或数据进行交叉验证的自动验证机制。这可以提供额外的安全层，减轻与幻觉相关的风险。 +5. 将复杂的任务分解成可管理的子任务并分配给不同的代理人。这不仅有助于管理复杂性，还减少了幻觉的可能性，因为每个代理人都可以对较小的任务负有责任。 +6. 清晰地传达使用LLM时涉及的风险和限制。这包括信息不准确的可能性和其他风险。有效的风险沟通可以让用户为潜在问题做好准备，并帮助他们做出明智的决策。 +7. 构建API和用户界面，鼓励负责任和安全的LLM使用。这可以包括内容过滤器、用户警告以及AI生成内容的清晰标记。 +8. 在开发环境中使用LLM时，建立安全的编码实践和准则，以防止可能的漏洞集成。 + +### 攻击场景示例 + +1. 一家新闻机构大量使用LLM生成新闻文章。恶意行为者利用这种过度依赖，向LLM提供误导性信息，导致虚假信息的传播。 +2. AI无意中剽窃内容，导致版权问题和对组织的信任度下降。 +3. 一个软件开发团队利用LLM系统来加速编码过程。对AI的建议过度依赖导致应用程序中引入了安全漏洞，因为它的默认设置不安全或与安全编码实践不一致。 +4. 一个软件开发公司使用LLM来协助开发人员。LLM建议一个不存在的代码库或包，一个开发人员信任AI，无意中将一个恶意包集成到公司的软件中。这凸显了交叉检查LLM建议的重要性，特别是涉及第三方代码或库时。 + +### 参考链接 + +1. [理解LLM幻觉](https://towardsdatascience.com/llm-hallucinations-ec831dcd7786): **Towards Data Science** +2. [公司应该如何向用户传达大型语言模型的风险？](https://techpolicy.press/how-should-companies-communicate-the-risks-of-large-language-models-to-users/): **Techpolicy** +3. [一家新闻网站使用AI来撰写文章，结果是新闻灾难](https://www.washingtonpost.com/media/2023/01/17/cnet-ai-articles-journalism-corrections/): **Washington Post** +4. [AI幻觉：风险程序包](https://vulcan.io/blog/ai-hallucinations-package-risk): **Vulcan.io** +5. [如何减少大型语言模型的幻觉](https://thenewstack.io/how-to-reduce-the-hallucinations-from-large-language-models/): **The New Stack** +6. [减少幻觉的实际步骤](https://newsletter.victordibia.com/p/practical-steps-to-reduce-hallucination): **Victor Debia** + diff --git a/1_1_vulns/translations/zh/LLM10_ModelTheft.md b/1_1_vulns/translations/zh/LLM10_ModelTheft.md new file mode 100644 index 00000000..7178aec8 --- /dev/null +++ b/1_1_vulns/translations/zh/LLM10_ModelTheft.md @@ -0,0 +1,55 @@ +## LLM10: 模型盗窃 + +### 描述 + +这个条目涉及到恶意行为者或高级持续性威胁（APT）未经授权地访问和窃取LLM模型。这种情况发生在专有的LLM模型（作为有价值的知识产权）受到威胁、被盗取、复制或权重和参数被提取以创建一个功能等效的模型。LLM模型盗窃的影响可能包括经济和品牌声誉的损失、竞争优势的削弱、对模型的未经授权使用或未经授权访问模型中包含的敏感信息。 + +LLM模型的盗窃代表了一个重大的安全关切，因为语言模型变得越来越强大和普遍。组织和研究人员必须优先考虑强大的安全措施，以保护他们的LLM模型，确保知识产权的机密性和完整性。采用包括访问控制、加密和持续监控在内的全面安全框架对于减轻与LLM模型盗窃相关的风险以及保护依赖于LLM的个人和组织的利益至关重要。 + +### 常见漏洞示例 + +1. 攻击者利用公司基础设施中的漏洞，通过网络或应用程序安全设置的配置错误来未经授权地访问其LLM模型仓库。 +2. 内部威胁情景，一名不满的员工泄露了模型或相关的工件。 +3. 攻击者使用精心制作的输入和提示注入技术查询模型API，以收集足够数量的输出来创建一个影子模型。 +4. 恶意攻击者能够绕过LLM的输入过滤技术，执行侧信道攻击，最终将模型权重和架构信息提取到远程受控资源。 +5. 模型提取的攻击向量涉及使用大量关于特定主题的提示查询LLM。然后可以使用LLM的输出来对另一个模型进行微调。然而，有几点需要注意： + - 攻击者必须生成大量有针对性的提示。如果提示不够具体，LLM的输出将毫无用处。 + - LLM的输出有时可能包含幻觉的答案，这意味着攻击者可能无法提取整个模型，因为其中一些输出可能是荒谬的。 + - 通过模型提取无法完全复制LLM。但攻击者将能够复制部分模型。 +6. **_功能模型复制_** 的攻击向量涉及使用目标模型通过提示生成合成训练数据（一种称为“自我指导”的方法），然后使用它来微调另一个基础模型以产生一个功能等效的模型。这绕过了示例5中使用的传统查询式提取的限制，已成功用于使用LLM来训练另一个LLM的研究中。尽管在这个研究的背景下，模型复制不是一种攻击，但攻击者可以使用这种方法来复制一个具有公共API的专有模型。 + +被盗用的模型，作为影子模型，可以用于发动敌对攻击，包括未经授权访问模型中包含的敏感信息或在进一步发动高级提示注入攻击时进行未被察觉的实验。 + +### 预防和减轻策略 + +1. 实施强大的访问控制（例如，RBAC和最小权限原则）和强大的身份验证机制，以限制对LLM模型仓库和训练环境的未经授权访问。 + - 对于前三个常见示例来说，这一点尤其重要，因为它们可能由内部威胁、配置错误和/或基础设施安全控制不足引发漏洞，而恶意行为者可以从内部或外部渗透环境中渗透。 + - 供应商管理跟踪、验证和依赖性漏洞是防止供应链攻击利用的重要关注点。 +2. 限制LLM对网络资源、内部服务和API的访问。 + - 对于所有常见示例来说，这一点尤其重要，因为它涵盖了内部风险和威胁，但最终控制了LLM应用程序“可以访问什么”，因此可能是防止侧信道攻击的机制或预防步骤。 +3. 在生产中使用集中式ML模型清单或注册表。具有集中式模型注册表可以通过访问控制、身份验证和监控/日志记录功能来防止未经授权访问ML模型。具有集中存储库对于收集关于模型使用的算法的数据以用于合规性、风险评估和风险缓解等目的也是有益的。 +4. 定期监控和审计与LLM模型仓库相关的访问日志和活动，以及及时检测和响应任何可疑或未经授权的行为。 +5. 自动化 MLOps部署，包括治理、跟踪和批准工作流程，以加强对基础设施内的访问和部署控制。 +6. 实施控制和减轻策略，以减轻提示注入技术引发侧信道攻击的风险。 +7. 在适用的情况下对API调用进行速率限制和/或过滤，以减小从LLM应用程序泄漏数据的风险，或者实施检测（例如DLP）从其他监视系统中提取活动的技术。 +8. 实施对抗性强度培训，以帮助检测提取查询并加强物理安全措施。 +9. 在LLM的生命周期的嵌入和检测阶段实施水印框架。 + +### 攻击场景示例 + +1. 攻击者利用公司基础设施中的漏洞未经授权地访问其LLM模型仓库。攻击者随后窃取有价值的LLM模型，并使用它们来启动竞争性语言处理服务或提取敏感信息，给原始公司造成重大财务损失。 +2. 一名不满的员工泄露了模型或相关工件。此情景的公开曝光增加了攻击者进行灰盒对抗性攻击的知识，或者直接窃取可用的财产。 +3. 攻击者使用精心选择的输入查询API，收集足够数量的输出来创建一个影子模型。 +4. 供应链中存在安全控制故障，导致了专有模型信息的数据泄漏。 +5. 恶意攻击者绕过LLM的输入过滤技术和前文，执行侧信道攻击，将模型信息提取到受其控制的远程资源中。 + +### 参考链接 + +1. [Meta’s powerful AI language model has leaked online](https://www.theverge.com/2023/3/8/23629362/meta-ai-language-model-llama-leak-online-misuse): **The Verge** +2. [Runaway LLaMA | How Meta's LLaMA NLP model leaked](https://www.deeplearning.ai/the-batch/how-metas-llama-nlp-model-leaked/): **Deep Learning Blog** +3. [AML.TA0000 ML Model Access](https://atlas.mitre.org/tactics/AML.TA0000): **MITRE ATLAS** +4. [I Know What You See](https://arxiv.org/pdf/1803.05847.pdf): **Arxiv White Paper** +5. [D-DAE: Defense-Penetrating Model Extraction Attacks](https://www.computer.org/csdl/proceedings-article/sp/2023/933600a432/1He7YbsiH4c): **Computer.org** +6. [A Comprehensive Defense Framework Against Model Extraction Attacks](https://ieeexplore.ieee.org/document/10080996): **IEEE** +7. [Alpaca: A Strong, Replicable Instruction-Following Model](https://crfm.stanford.edu/2023/03/13/alpaca.html): **Stanford Center on Research for Foundation Models (CRFM)** +8. [How Watermarking Can Help Mitigate The Potential Risks Of LLMs?](https://www.kdnuggets.com/2023/03/watermarking-help-mitigate-potential-risks-llms.html): **KD Nuggets** diff --git "a/assets/translations/hi/OWASP \340\244\237\340\245\211\340\244\252 10 \340\244\253\340\245\211\340\244\260 LLM \340\244\217\340\244\252\340\245\215\340\244\262\340\244\277\340\244\225\340\245\207\340\244\266\340\244\202\340\244\270.pdf" "b/assets/translations/hi/OWASP \340\244\237\340\245\211\340\244\252 10 \340\244\253\340\245\211\340\244\260 LLM \340\244\217\340\244\252\340\245\215\340\244\262\340\244\277\340\244\225\340\245\207\340\244\266\340\244\202\340\244\270.pdf" new file mode 100644 index 00000000..7411afde Binary files /dev/null and "b/assets/translations/hi/OWASP \340\244\237\340\245\211\340\244\252 10 \340\244\253\340\245\211\340\244\260 LLM \340\244\217\340\244\252\340\245\215\340\244\262\340\244\277\340\244\225\340\245\207\340\244\266\340\244\202\340\244\270.pdf" differ diff --git "a/assets/translations/pt/OWASP Top 10 para Aplica\303\247\303\265es de IA LLM.pdf" "b/assets/translations/pt/OWASP Top 10 para Aplica\303\247\303\265es de IA LLM.pdf" new file mode 100644 index 00000000..4c1f7372 Binary files /dev/null and "b/assets/translations/pt/OWASP Top 10 para Aplica\303\247\303\265es de IA LLM.pdf" differ diff --git "a/assets/translations/zh/OWASP \345\244\247\350\257\255\350\250\200\346\250\241\345\236\213\344\272\272\345\267\245\346\231\272\350\203\275\345\272\224\347\224\250Top 10 \345\256\211\345\205\250\345\250\201\350\203\201.pdf" "b/assets/translations/zh/OWASP \345\244\247\350\257\255\350\250\200\346\250\241\345\236\213\344\272\272\345\267\245\346\231\272\350\203\275\345\272\224\347\224\250Top 10 \345\256\211\345\205\250\345\250\201\350\203\201.pdf" new file mode 100644 index 00000000..badd08e0 Binary files /dev/null and "b/assets/translations/zh/OWASP \345\244\247\350\257\255\350\250\200\346\250\241\345\236\213\344\272\272\345\267\245\346\231\272\350\203\275\345\272\224\347\224\250Top 10 \345\256\211\345\205\250\345\250\201\350\203\201.pdf" differ