利用ASP.NET中的x-up-devcap-post-charset报头绕过WAF

启明星辰金睛安全研究团队 2020-04-05

1246

常见的WAF绕过技巧中，我们知道攻击者可以通过在请求包的Content-Type中指定罕见的请求编码（如ibm500）来进行某些WAF的绕过。

通常waf只检测它所识别的编码，比如说它只识别utf-8的字符，但是服务器可以识别比utf-8更多的编码。

那么我们只需要将payload按照waf识别不了但是服务器可以解析识别的编码格式即可绕过(比如下面图中的ibm500)。并且借助SoroushDalili开发的burp插件（https://github.com/nccgroup/BurpSuiteHTTPSmuggler）我们可以很轻松的用burpsuite做到这一点

以SQL注入为例，使用ibm500编码数据后，在注入点传入And1=1 不再拦截。

And 1=2 报错。

爆出用户名。

但如今，这种“古老”的绕过方法已经被大众所熟悉，安全人员也早已在WAF规则中做了修补，只允许白名单中的编码字符集或禁止黑名单中的编码字符集。

然而，去年一位研究人员在ASP中发现了一个新的可以传递charset值的报头，能够绕过任何现有针对Content-Type报头的保护机制。

下面是 x-up-devcap-post-charset 报头的使用示例:

POST/test/a.aspx?%C8%85%93%93%96%E6%96%99%93%84= HTTP/1.1

Host: target

User-Agent: UP foobar

Content-Type: application/x-www-form-urlencoded

x-up-devcap-post-charset:ibm500

Content-Length: 40

%89%95%97%A4%A3%F1=%A7%A7%A7%A7%A7%A7%A7

如上面所示，Content-Type头内没有指定charset参数，但却在x-up-devcap-post-charset头中指定了charset。为了告诉ASP.NET要使用这个新的报头，User-Agent报头必须以UP作为开头。

上面采用ibm500编码部分的POST数据也是用上述的Burp Suite HTTP Smuggler插件生成的，编码前等于如下的请求：

POST/testme87/a.aspx?HelloWorld= HTTP/1.1

Host: target

User-Agent: UP foobar

Content-Type:application/x-www-form-urlencoded

Content-Length: 14

input1=xxxxxxx

测试发现，编码后的payload确实能绕过WAF，且能被后端正常解析。

查看ASP的相关源码如下：

https://github.com/Microsoft/referencesource/blob/3b1eaf5203992df69de44c783a3eda37d3d4cd10/System/net/System/Net/HttpListenerRequest.cs#L362

https://github.com/Microsoft/referencesource/blob/08b84d13e81cfdbd769a557b368539aac6a9cb30/System.Web/HttpRequest.cs#L905

可以看到，ASP在检查Content-Type头的charset参数之前，先对UA和x-up-devcap-post-charset进行了检测，满足条件时，直接结束判断并返回 x-up-devcap-post-charset中指定的值作为charset。

其实这个稍显冷门的绕过技术也并不算非常的新鲜，但在安全攻防中，防御方永远是被动的一方，需要做到在所有的点都滴水不漏。而攻击方只需要攻破任意一个点，便可让防御方的其他努力付诸东流。所以防御人员必须与时俱进，及时了解最新的攻击手法，做好防御措施，加大攻击人员的攻击成本。本文便是旨在查漏补缺，供大家学习交流。

数据库

文章转载自启明星辰金睛安全研究团队，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

利用ASP.NET中的x-up-devcap-post-charset报头绕过WAF

评论