- क्या आप किसी **साइबर सुरक्षा कंपनी** में काम करते हैं? क्या आप अपनी **कंपनी को HackTricks में विज्ञापित** देखना चाहते हैं? या क्या आपको **PEASS की नवीनतम संस्करण या HackTricks को PDF में डाउनलोड करने का उपयोग** करने की आवश्यकता है? [**सदस्यता योजनाएं**](https://github.com/sponsors/carlospolop) की जांच करें!
- [**The PEASS Family**](https://opensea.io/collection/the-peass-family) की खोज करें, हमारा विशेष [**NFT**](https://opensea.io/collection/the-peass-family) संग्रह
- **शामिल हों** [**💬**](https://emojipedia.org/speech-balloon/) [**डिस्कॉर्ड समूह**](https://discord.gg/hRep4RUj7f) या [**टेलीग्राम समूह**](https://t.me/peass) में या मुझे **ट्विटर** पर **फ़ॉलो** करें [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
हमने [गलत ढंग से कॉन्फ़िगर किए गए JSON पुस्तकालयों के माध्यम से RCE](https://www.alphabot.com/security/blog/2017/net/How-to-configure-Json.NET-to-create-a-vulnerable-web-API.html) पर एक नज़र डाली थी, उसके बाद हमने JSF अमलानुसार ViewStates का विश्लेषण किया। [JavaServer Faces (JSF)](https://en.wikipedia.org/wiki/JavaServer_Faces) एक यूज़र इंटरफ़ेस (UI) प्रौद्योगिकी है जो पुनर्योग्य घटकों के साथ वेब UI बनाने के लिए उपयोग होती है। JSF अधिकांश उद्योगी अनुप्रयोगों के लिए उपयोग होता है और एक JSF अमलानुसारन को आमतौर पर जावा अनुप्रयोग सर्वर जैसे JBoss EAP या WebLogic सर्वर पर चलने वाले वेब अनुप्रयोग द्वारा उपयोग किया जाता है। JSF विनिमय के दो प्रसिद्ध अमलानुसारन हैं:
इस ब्लॉग पोस्ट में हम दो JSF 2.x अमलानुसारन पर ध्यान केंद्रित करेंगे: Oracle Mojarra (संदर्भ अमलानुसारन) और Apache MyFaces। पुराने अमलानुसारन (JSF 1.x) को भी इस पोस्ट में वर्णित सुरक्षा दोषों का प्रभावित होने का संभावना है। (JSF 2.0.x को 2009 में प्रथम बार जारी किया गया था, वर्तमान संस्करण 2.3.x है)।
JSF और समकक्ष वेब प्रौद्योगिकियों के बीच एक अंतर है कि JSF ViewStates (सत्रों के अलावा) का उपयोग व्यू की वर्तमान स्थिति (उदाहरण के लिए, वर्तमान में कौन से हिस्से दिखाए जाएं) को संग्रहित करने के लिए करता है। ViewState को `सर्वर` या `ग्राहक` पर संग्रहीत किया जा सकता है। JSF ViewStates को आमतौर पर HTML फ़ॉर्म में छिपे हुए फ़ील्ड के रूप में स्वचालित रूप से समाविष्ट किया जाता है, जिसका नाम `javax.faces.ViewState` होता है। यदि फ़ॉर्म सबमिट किया जाता है, तो वे सर्वर को वापस भेजे जाते हैं।
यदि JSF ViewState को `सर्वर` पर स्थापित किया जाता है, तो छिपे हुए `javax.faces.ViewState` फ़ील्ड में एक आईडी होती है जो सर्वर को सही स्थिति प्राप्त करने में मदद करती है। MyFaces के मामले में वह आईडी एक **संकलित जावा ऑब्जेक्ट** होती है!
यदि JSF ViewState को `ग्राहक` पर स्थापित किया जाता है, तो छिपे हुए `javax.faces.ViewState` फ़ील्ड में एक **संकलित जावा ऑब्जेक्ट** होती है जो कम से कम Base64 कोडिंग होती है। आपने शायद अब तक यह ध्यान दिया होगा कि यह एक संभावित आपदा का मार्ग है! शायद यही कारण है कि आजकल JSF ViewStates को ग्राहक को भेजने से पहले
उस लॉगिन पेज में ViewState है जो न तो एन्क्रिप्टेड है और न ही साइन है। इसलिए जब हम इसके HTML स्रोत को देखते हैं तो हमें ViewState को समेत करने वाले एक छिपा हुआ फ़ील्ड दिखाई देता है: अनएन्क्रिप्टेड MyFaces ViewState:
यदि आप Base64 का उपयोग करके ऊपर दिए गए ViewState को डिकोड करें, तो आप देखेंगे कि इसमें एक सीरीयलाइज़ किया गया जावा ऑब्जेक्ट है। जब फ़ॉर्म सबमिट किया जाता है (उदाहरण के लिए, लॉगिन पर क्लिक करें), तो यह ViewState POST के माध्यम से सर्वर को वापस भेजा जाता है। अब ViewState को सर्वर को वापस POST करने से पहले ही हमलावर अपने खुद के विषादी ViewState को एटैकर ViewState के साथ बदल देता है, जो पहले से ही सर्वर के क्लासपथ पर मौजूद होता है (उदाहरण के लिए, `InvokerTransformer` commons-collections-3.2.1.jar से) या यहां तक कि जनता के लिए अभी तक नहीं जाना जाने वाला एक गैजेट। इस खतरनाक गैजेट को ViewState में रखकर हमलावर स्पष्ट करता है कि वह किस कमांड को सर्वर पर चलाना चाहता है। एक अटैकर की क्षमता उपलब्ध गैजेट्स की क्लासपथ की सीमा द्वारा सीमित होती है। `InvokerTransformer` के मामले में, हमलावर सर्वर पर कौन से कमांड लाइन कमांड चलाना चाहता है, वह निर्धारित कर सकता है। हमारे उदाहरण में हमलावर ने हमारे लिनक्स आधारित सर्वर के UI पर कैलकुलेटर शुरू करने का चयन किया।
जब अटैकर ने अपने संशोधित फ़ॉर्म को सर्वर को वापस भेजा है, तो JSF कार्यान्वयन प्रदान किए गए ViewState को डिसीरियलाइज़ करने का प्रयास करता है। अब विषादीकरण के पहले ही ViewState के अंत हो जाने पर कमांड चलाया जाता है और कैलकुलेटर सर्वर पर शुरू हो जाता है:
यह सब कुछ JSF कार्यान्वयन ViewState को देखने और यह निर्णय करने से पहले हो गया था कि यह अच्छा नहीं था। जब ViewState को अमान्य पाया गया था, तो आमतौर पर त्रुटि का जवाब क्लाइंट को भेजा जाता है जैसे "व्यू समाप्त हो गई है"। लेकिन फिर भी यह बहुत देर हो चुकी थी। हमलावर को सर्वर तक पहुंच मिल गई थी और कमांड चला दी गई थी। (अधिकांश वास्तविक दुनिया के हमलावर कैलकुलेटर शुरू नहीं करते हैं, लेकिन वे आमतौर पर एक रिमोट शेल डिप्लॉय करते हैं, जिसे वे फिर सर्वर तक पहुंचने के लिए उपयोग करते हैं।)
(जैसा कि पहले चित्रित किया गया जेएसएफ़ के खिलाफ लगभग वही हमला परिदृश्य ऊपर वर्णित किया गया था और 2015 के प्रस्तुति में भी दिखाया गया था (पृष्ठ 65 से 67 तक): [Marshalling Pickles](https://frohoff.github.io/appseccali-marshalling-pickles/) जिसे फ्रोहोफ और लॉरेंस ने आयोजित किया था।)
Mojarra की डिफ़ॉल्ट `javax.faces.STATE_SAVING_METHOD` सेटिंग `server` है। विकासक को इसे मैन्युअल रूप से `client` में बदलना होगा ताकि Mojarra उपरोक्त विधि के हमले के प्रति संक्रमित हो सके। यदि सीरीयलाइज़्ड ViewState को सर्वर पर भेजा जाता है लेकिन Mojarra `server` साइड ViewState सेव का उपयोग करता है, तो यह उसे डिसीरियलाइज़ नहीं करेगा (हालांकि, `StringIndexOutOfBoundsException` हो सकती है)।
* Mojarra को 2.0.11-04 या 2.1.29-08 में अपडेट करें।
* क्लाइंट-साइड ViewState की बजाय सर्वर-साइड ViewState का उपयोग करें।
* पुराने संस्करणों के Mojarra का उपयोग करते समय और अपडेट या सर्वर-साइड ViewState में स्विच करने की संभावना न होने पर: एक अस्थायी समाधान के रूप में ViewState पासवर्ड सेट करें और सुनिश्चित करें कि यह सही पैरामीटर है (अनिवार्य रूप से संबंधित दस्तावेज़ीकरण में दिया गया पासवर्ड नहीं होना चाहिए)
MyFaces डिफ़ॉल्ट रूप से ViewState को एन्क्रिप्ट करता है, जैसा कि उनके [सुरक्षा कॉन्फ़िगरेशन विकि पृष्ठ](https://wiki.apache.org/myfaces/Secure_Your_Application) में उल्लेख किया गया है:
> एन्क्रिप्शन डिफ़ॉल्ट रूप से सक्षम होता है। ध्यान दें कि उत्पादन वातावरण में एन्क्रिप्शन का उपयोग किया जाना चाहिए और इसे अक्षम करना केवल परीक्षण/विकास वातावरण में मान्य हो सकता है।
हालांकि, पैरामीटर `org.apache.myfaces.USE_ENCRYPTION` को `false` पर सेट करके ViewState एन्क्रिप्शन को अक्षम किया जा सकता है। (यह एन्क्रिप्शन का उपयोग करना संभव होगा लेकिन एक आसान अनुमान लगाने योग्य पासवर्ड सेट करना भी संभव होगा)। डिफ़ॉल्ट रूप से MyFaces हर सर्वर पुनरारंभ के साथ ViewState एन्क्रिप्शन सीक्रेट को बदलता है।
डिफ़ॉल्ट रूप से MyFaces `DES` का उपयोग एन्क्रिप्शन एल्गोरिदम और `HMAC-SHA1` का उपयोग ViewState की प्रमाणिति करने के लिए करता है। `AES` और `HMAC-SHA256` जैसे नवीनतम एल्गोरिदम कॉन्फ़िगर करना संभव और अनुशंसित है।
MyFaces की डिफ़ॉल्ट `javax.faces.STATE_SAVING_METHOD` सेटिंग `server` है। लेकिन: **MyFaces हमेशा ViewState को डिसीरियलाइज़ करता है**, चाहे उस सेटिंग के बावजूद। इसलिए, [MyFaces का उपयोग करते समय एन्क्रिप्शन को अक्षम न करें](https://issues.apache.org/jira/browse/MYFACES-4021) का बहुत महत्व है!
(हमने MyFaces बग ट्रैकर में एक मुद्दा बनाया है: [MYFACES-4133 स्थिति सहेजने की विधि सर्वर होने पर ViewState-ID को डिसीरियलाइज़ न करें](https://issues.apache.org/jira/browse/MYFACES-4133), शायद [इस बार](https://issues.apache.org/jira/browse/MYFACES-4021) सुरक्षित डिफ़ॉल्ट की इच्छा पूरी हो जाएगी।)
MyFaces का उपयोग करते समय सर्वर-साइड ViewState की एन्क्रिप्शन को अक्षम न करें (द्वारा `org.apache.myfaces.USE_ENCRYPTION`) चाहे ViewState क्लाइंट पर संग्रहित हो या सर्वर पर।
यदि किसी तरह से आप पासवर्ड चोरी करने में सफल होते हैं, तो आप वेब सर्वर पर हमला करने के लिए इस स्क्रिप्ट का उपयोग करके पेलोड को एन्क्रिप्ट और साइन कर सकते हैं:
![Badsecrets](https://github.com/blacklanternsecurity/badsecrets) एक पुस्तकालय है जो उपयोग की जानी वाली या कमजोर कुंजियों की सूची के खिलाफ जांच करके उत्पादों को देखकर ज्ञात तकनीकी कुंजियों का उपयोग पता लगा सकती है। इसका `Jsf_viewstate` मॉड्यूल Mojarra और MyFaces दोनों पर ज्ञात कुंजियों के साथ बनाए गए जावा सर्वर फेस व्यूस्टेट का पता लगा सकता है, साथ ही असुरक्षित या संपीडित व्यूस्टेट्स का भी।
यदि यह मिलता है, तो यह भी प्लेटफ़ॉर्म (Mojarra या MyFaces), उपयोग में एन्क्रिप्शन एल्गोरिदम, और कंप्रेशन का उपयोग करता है या नहीं, जो सभी उत्पीड़न के लिए आवश्यक हैं।
इस ब्लॉग पोस्ट में दिए गए जेएसएफ व्यूस्टेट के बारे में अधिकांश तथ्य और उनके खतरों को नए नहीं कहा गया है, लेकिन ऐसे संक्षेपित तरीके में कभी पेश नहीं किया गया था। यह एक बार फिर से दिखाया गया है कि दिखावटी रूप से हानिकारक कॉन्फ़िगरेशन बदलाव गंभीर सुरक्षा खतरों का कारण बन सकते हैं।
\=> एक समस्या में यह लगता है कि सुरक्षा शोधकर्ताओं और विकासकर्ताओं के बीच पर्याप्त ज्ञान संचार नहीं होता है, जो वास्तव में उन लाइब्रेरीज़ का उपयोग करते हैं और कॉन्फ़िगर करते हैं जो निश्चित तरीके से खतरनाक हो सकती हैं।
- क्या आप **साइबर सुरक्षा कंपनी** में काम करते हैं? क्या आप अपनी कंपनी को **HackTricks में विज्ञापित** देखना चाहते हैं? या क्या आप **PEASS के नवीनतम संस्करण या HackTricks को पीडीएफ़ में डाउनलोड** करने की इच्छा रखते हैं? [**सदस्यता योजनाएं**](https://github.com/sponsors/carlospolop) की जांच करें!
- **अपने हैकिंग ट्रिक्स को [hacktricks रेपो](https://github.com/carlospolop/hacktricks) और [hacktricks-cloud रेपो](https://github.com/carlospolop/hacktricks-cloud) में पीआर सबमिट करके साझा करें।**