主流waf非主流waf

Today we’re going to talk about one of the modern security mechanism for web applications, namely Web Application Firewall (WAF). We’ll discuss modern WAFs and what they are based on, as well as bypass techniques, how to use them, and why you should never entirely rely on WAF. We’re speaking from the pentesters’ perspective; we’ve never developed WAFs and only collected data from open sources. Thus, we can only refer to our own experience and may be unaware of some peculiarities of WAFs. 今天，我们将讨论Web应用程序的一种现代安全机制，即Web应用程序防火墙(WAF)。 我们将讨论现代WAF，它们基于什么以及旁路技术，如何使用它们，以及为什么您永远不应该完全依赖WAF。 我们是从渗透者的角度说的； 我们从未开发过WAF，而仅从开源收集数据。 因此，我们只能参考自己的经验，并且可能不知道WAF的某些特殊性。

内容 (Contents)

1. Introduction介绍
2. The modern WAF现代WAF
3. Identifying WAF识别WAF
4. WAF bypass cheatsheetWAF旁路备忘单
5. WAF bypass in practice在实践中绕过WAF
6. Conclusion结论

If you know why WAFs are used and how they work, you can jump straight to the bypass section.如果您知道为什么使用WAF以及它们如何工作，则可以直接跳至旁路部分。

介绍 (Introduction)

WAFs have become quite popular recently. Vendors offer various solutions in different price ranges, distribution kits, and options, targeting different customers, from small businesses to large enterprises. WAFs are popular because they’re a complex solution for protecting web applications, that covers a whole spectrum of tasks. That’s why web app developers can rely on WAF in some security aspects. Although, WAFs cannot grant total security.

WAF最近变得非常流行。 供应商针对不同的客户(从小型企业到大型企业)提供不同价格范围，分发工具包和选项的各种解决方案。 WAF之所以受欢迎，是因为它们是保护Web应用程序的复杂解决方案，涵盖了所有任务。 这就是为什么Web应用程序开发人员可以在某些安全方面依赖WAF的原因。 虽然，WAF无法授予完全安全性。

So, what should a WAF be capable of to justify its implementation in a project? Its main function is detecting and blocking any request that, according to the WAF’s analysis, has any anomalies or an attack vector. The analysis must not hinder the interaction between legitimate users and the web app while at the same time, must accurately and timely detect any attack attempts. In order to implement such functionality, WAF developers use regular expressions, tokenizers, behavior analysis, reputational analysis, and of course machine learning. Often, all these technologies are used together. WAF may also implements other functions: DDoS protection, ban of attacker’s IPs, monitoring of suspicious IPs, adding security headers (X-XSS-Protection, X-Frame-Options, etc.), adding http-only flags to cookie, implementation of the HSTS mechanism and CSRF tokens. Also, some WAFs have JavaScript client side modules for websites.

那么，WAF应该有什么能力证明其在项目中的实施合理性？ 根据WAF的分析，其主要功能是检测和阻止任何有异常或攻击媒介的请求。 该分析不得阻碍合法用户与Web应用程序之间的交互，同时必须准确，及时地检测到任何攻击尝试。 为了实现这种功能，WAF开发人员使用正则表达式，令牌化程序，行为分析，声誉分析以及机器学习。 通常，所有这些技术都一起使用。 WAF还可以实现其他功能：DDoS保护，禁止攻击者的IP，监视可疑IP，添加安全标头(X-XSS-Protection，X-Frame-Options等)，在cookie中添加仅http标志，实现HSTS机制和CSRF令牌。 另外，某些WAF具有用于网站JavaScript客户端模块。

Of course, WAFs create some obstacles for hackers and pentesters. WAF makes vulnerability finding and exploiting more resource-intensive (except if the attacker knows effective 0day bypass methods for a specific WAF). Automatic scanners are practically useless when analyzing WAF-protected web apps. WAF is reliable protection against “scriptkiddies”. Though, an experienced hacker or a researcher without enough motivation probably wouldn’t want to waste time trying to find ways to bypass it. It should be noted that the more complex web app is the bigger its attack surface, and the easier it is to find a bypass method.

当然，WAF为黑客和渗透者创造了一些障碍。 WAF使发现漏洞和利用漏洞的资源更加密集(除非攻击者知道特定WAF的有效0day绕过方法)。 在分析受WAF保护的Web应用程序时，自动扫描程序几乎没有用。 WAF是针对“脚本”的可靠保护。 但是，经验丰富的黑客或研究人员如果没有足够的动力，可能不想浪费时间尝试绕过它。 应当注意，越复杂的Web应用程序的受攻击面越大，并且越容易找到旁路方法。

In our recent audits, we would quite often find different WAFs. We’ll talk about some of them later. We’ve already tested two proprietary WAFs in two main scenarios:

在我们最近的审核中，我们经常会找到不同的WAF。 稍后我们将讨论其中一些。 我们已经在两个主要场景中测试了两个专有的WAF：

• We know there’s a certain vulnerability in a web app and we try to bypass the WAF to exploit it;我们知道网络应用程序中存在一定的漏洞，因此我们尝试绕过WAF加以利用。
• We don’t know about any vulnerabilities, so we have to find one despite the WAF and then exploit it bypassing WAF.我们不知道任何漏洞，因此尽管有WAF，我们仍然必须找到一个漏洞，然后绕过WAF加以利用。

But first, let’s take a closer look at the basic mechanisms behind WAF and see what problems they have.

但是首先，让我们仔细研究一下WAF背后的基本机制，看看它们有什么问题。

现代WAF (The modern WAF)

To be able to effectively find various ways to bypass WAF, first, we need to find out modern mechanisms of request classification. Each WAF is specific and uniquely built, but there are some general methods of analysis. Let’s take a look at those.

为了能够有效地找到各种绕过WAF的方法，首先，我们需要找出现代的请求分类机制。 每个WAF都是特定且唯一的，但是有一些常规的分析方法。 让我们来看看那些。

基于正则表达式的规则 (Rules based on regular expressions)

The majority of the existing WAFs use rules based on regular expressions. The developer researches a certain set of known attacks to identify key syntactic structures which could point at an attack. Based on this data, the developer creates regular expressions that find such syntactic structures. It sounds simple, but this method has certain drawbacks. First, a regular expression can be applied to just a single request, or even a single request parameter, which obviously reduces the efficiency of such rules and leaves some blind spots. Second, the syntax of regular expressions and the complex logic of text protocols, which allows replacement to equivalent structures and using different symbol representation, lead to errors while creating these rules.

现有的大多数WAF使用基于正则表达式的规则。 开发人员研究一组特定的已知攻击，以识别可能指向攻击的关键句法结构。 基于此数据，开发人员将创建查找此类语法结构的正则表达式。 听起来很简单，但是这种方法有一些缺点。 首先，可将正则表达式仅应用于单个请求，甚至单个请求参数，这显然会降低此类规则的效率，并留下一些盲点。 其次，正则表达式的语法和文本协议的复杂逻辑(允许替换为等效结构并使用不同的符号表示形式)在创建这些规则时会导致错误。

成绩建立 (Scorebuilding )

Those who know how network firewalls and anti-viruses work should be familiar with this mechanism. It doesn’t detect attacks but complements other mechanisms making them more precise and flexible. The thing is that a “suspicious” structure in a request is not a sufficient condition for detecting an attack and may lead to many false-positives. This problem is solved by implementing a grading system. Each rule based on regular expressions is complemented by the information on its criticality; after all triggered rules are identified, their criticality is summarized. If the total criticality reaches the threshold value, the attack is detected and the request is blocked. Notwithstanding its simplicity, this mechanism proved to be efficient and is widely used for such tasks.

那些了解网络防火墙和防病毒功能的人应该熟悉这种机制。 它不检测攻击，而是补充其他机制，使攻击更加精确和灵活。 事实是，请求中的“可疑”结构不足以检测攻击，可能会导致许多假阳性。 通过实施分级系统可以解决此问题。 每条基于正则表达式的规则都由其重要性信息提供补充； 在确定所有触发规则之后，总结其重要性。 如果总关键程度达到阈值，则检测到攻击并阻止请求。 尽管简单，但该机制仍然有效，并已广泛用于此类任务。

分词器 (Tokenizers)

This detection method was presented at Black Hat 2012 as a C/C+ library libinjection, that allows to identify SQL injections quickly and with precision. At this moment, there are many libinjection ports for different programming languages, like PHP, Lua, Python, etc. This mechanism searches for signatures presented as a set of tokens. A certain number of signatures is blacklisted, and they are deemed unwanted and malicious. In other words, before some request is analyzed, it is translated into a set of tokens. Tokens are divided into certain types, like variable, string, regular operator, unknown, number, comment, union-like operator, function, comma, etc. One of the main disadvantages of the method is that it’s possible to build a structure that would lead to the incorrect formation of tokens, hence the request signature will differ from the expected. These structures are usually referred to as token breakers, and we’ll discuss them later

这种检测方法在Black Hat 2012上作为C / C +库libinjection提出 ，它可以快速，准确地识别SQL注入。 目前，有许多针对不同编程语言的libinjection端口，例如PHP，Lua，Python等。此机制搜索以一组令牌表示的签名。 一定数量的签名被列入黑名单，它们被认为是有害的和恶意的。 换句话说，在分析某个请求之前，它会被转换为一组令牌。 令牌分为某些类型，例如变量，字符串，常规运算符，未知数，数字，注释，类联合运算符，函数，逗号等。该方法的主要缺点之一是可能会构建一个导致令牌的格式不正确，因此请求签名将与预期的有所不同。 这些结构通常称为令牌破坏者，我们将在后面讨论

行为分析 (Behavior analysis)

Detecting and blocking exploitation attempts in requests is not the only task for WAFs. It’s also important to identify the process of vulnerability search and the WAF must react accordingly. It may manifest itself as scanning attempts, directory brute-force, parameters fuzzing, and other automatic methods. Advanced WAFs can build request chains typical for normal usual behavior and block attempts to send unusual requests. This method not so much detecting attacks, as it hinders the process of vulnerability search. Limiting the number of requests per minute wouldn’t affect a usual user but would be a serious obstacle for scanners, which work in multiple threads.

检测和阻止请求中的利用尝试不是WAF的唯一任务。 确定漏洞搜索的过程也很重要，并且WAF必须做出相应的React。 它可能表现为扫描尝试，目录暴力，参数模糊处理以及其他自动方法。 先进的WAF可以构建通常正常行为的典型请求链，并阻止尝试发送异常请求。 这种方法并没有太多地检测攻击，因为它阻碍了漏洞搜索的过程。 限制每分钟的请求数量不会影响普通用户，但对于在多个线程中工作的扫描仪来说，这将是一个严重的障碍。

信誉分析 (Reputation analysis)

This is yet another mechanism directly inherited from firewalls and anti-viruses. Today, almost any WAF includes lists of the addresses of VPNs, anonymizers, Tor nodes, and botnets to block requests from those. Advanced WAFs can automatically update their bases and complement them with additional entries based on the analyzed traffic.

这是直接从防火墙和防病毒继承的另一种机制。 如今，几乎所有WAF都包含VPN，匿名器，Tor节点和僵尸网络的地址列表，以阻止来自这些地址的请求。 高级WAF可以根据分析的流量自动更新其基准并以其他条目补充它们。

机器学习 (Machine learning)

This is one of the most questionable aspects of WAF. Let’s note that the term “machine learning” is quite broad and includes many technologies and methods. Besides, it’s just one of the classes of the AI. “Implementation” of machine learning, or “use of AI” are very popular marketing phrases. It’s not always clear which algorithms are used exactly, and sometimes it looks like mere gibberish. Those vendors who really use machine learning and do it effectively are not willing to share their experience. That makes it hard for an outsider to try to figure out the situation. Nevertheless, let’s try to make some points based on available information.

这是WAF最可疑的方面之一。 让我们注意一下，术语“机器学习”非常广泛，包括许多技术和方法。 此外，它只是AI的一类。 机器学习的“实施”或“人工智能的使用”是非常流行的营销短语。 并不总是确切地使用哪些算法，有时看起来就像是胡言乱语。 那些真正使用机器学习并有效地进行机器学习的供应商不愿意分享他们的经验。 这使局外人很难弄清情况。 不过，让我们尝试根据可用信息提出一些意见。

First, machine learning is fully dependent on the data it was trained on, which poses a certain problem. A developer should have an up-to-date and full base of attacks, which is hard to achieve. That’s why many developers thoroughly log the results of their WAFs and cooperate with the vendors providing IDS and SIEM systems to get real-world attack examples. Second, a model trained on an abstract web app may turn out to be altogether ineffective on a real web app. For better quality, it is recommended to additionally train a model at the stage of implementation, which is resource intensive and time consuming and still doesn’t grant the best results.

首先，机器学习完全依赖于其训练的数据，这带来了一定的问题。 开发人员应该拥有最新的完整攻击基础，这很难实现。 这就是为什么许多开发人员彻底记录其WAF的结果并与提供IDS和SIEM系统的供应商合作以获取实际攻击示例的原因。 其次，在抽象的Web应用程序上训练的模型在实际的Web应用程序上可能完全无效。 为了获得更好的质量，建议在实施阶段额外训练模型，这是资源密集型和耗时的，但仍无法获得最佳结果。

识别WAF (Identifying WAF)

WAF developers use different ways to notify the user that request was blocked. Thus, we can identify the WAF by analyzing the response to our attack request. This is usually referred to as WAF Fingerprint. Fingerprints can help if a WAF is not updated for some reason (mostly applies to open source projects). The developers of proprietary WAFs care for their clients and implement automatic updates. Also, once we have identified the WAF, which turned out to be updated, we still can use the information about it to learn something about its logic.

WAF开发人员使用不同的方式来通知用户该请求已被阻止。 因此，我们可以通过分析对攻击请求的响应来识别WAF。 这通常称为WAF指纹。 如果WAF由于某些原因未更新(大多数情况下适用于开源项目)，则指纹可以提供帮助。 专有WAF的开发人员照顾他们的客户并实施自动更新。 同样，一旦我们确定WAF已被更新，我们仍然可以使用有关它的信息来了解其逻辑。

Here’s a list of possible WAF fingerprints:

以下是可能的WAF指纹列表：

• Additional cookies其他Cookie
• Additional headers to any response or request任何响应或请求的附加头
• Response contents (in case of blocked request)响应内容(如果请求被阻止)
• Response code (in case of blocked request)响应码(如果请求被阻止)
• IP address (Cloud WAF)IP地址(Cloud WAF)
• JS client side module (Client side WAF)JS客户端模块(客户端WAF)

Let’s illustrate it with some examples

让我们用一些例子来说明

自动对焦 (PT AF)

Response code for blocked request: 403

阻止请求的响应代码：403

Can insert the client module waf.js into response page

可以将客户端模块waf.js插入响应页面

Body of the response:

回复正文：

<h1>Forbidden</h1>
<pre>Request ID: 2017-07-31-13-59-56-72BCA33A11EC3784</pre>

An extra header that adding by waf.js:

由waf.js添加的额外标头：

X-RequestId: cbb8ff9a-4e91-48b4-8ce6-1beddc197a30

Nemesida WAF (Nemesida WAF)

Response code for blocked request: 403

阻止请求的响应代码：403

Body of the response:

回复正文：

<p style="font-size: 16px; align: center;">
Suspicious activity detected. Access to the site is blocked.
If you think that is's an erroneous blocking, please email us at
<a href="mailto:nwaf@pentestit.ru">nwaf@pentestit.ru</a> and
specify your IP-address. </p>

Wallarm (Wallarm)

Response code for blocked request: 403

阻止请求的响应代码：403

Additional header: nginx-wallarm

附加头：nginx-wallarm

Citrix NetScaler App防火墙 (Citrix NetScaler AppFirewall)

Additional cookie:

其他Cookie：

ns_af=31+LrS3EeEOBbxBV7AWDFIEhrn8A000;
ns_af_.target.br_%2F_wat=QVNQU0VTU0lP
TklEQVFRU0RDU0Nf?6IgJizHRbTRNuNoOpbBOiKRET2gA

Mod_Security版本 2.9 (Mod_Security ver. 2.9)

Response code for blocked request: 403

阻止请求的响应代码：403

Response body:

响应主体：

<head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /form.php on this server.<br /></p>

Mod_Security版本 <2.9 (Mod_Security ver. <2.9)

Response code for blocked request: 406 or 501

阻止请求的响应代码：406或501

In the response body, you can find mod_security, Mod_Security, or NOYB

在响应正文中，您可以找到mod_security，Mod_Security或NOYB

清漆防火墙 (Varnish FireWall)

Adds the following headers to the response:

将以下标头添加到响应中：

X-Varnish: 127936309 131303037.
X-Varnish: 435491096
Via: 1.1 varnish-v4

WAF developers decide themselves which response code to return in case of a blocked request; there are some specific codes as well. For example, Web_Knight WAF returns code 999, and dotDefender returns code 200 with an empty response body or with an error message. Besides that, developers may make a custom response page with some other content.

WAF开发人员自行决定在请求被阻止的情况下返回哪个响应代码。 还有一些特定的代码。 例如，Web_Knight WAF返回代码999，而dotDefender返回带有空响应正文或错误消息的代码200。 除此之外，开发人员还可以制作一个包含其他内容的自定义响应页面。

WAF, like any other app, evolves and changes. That’s why it’s important to constantly check the relevance of the fingerprints you have.

与其他任何应用程序一样，WAF也在不断发展和变化。 这就是为什么不断检查所拥有指纹的相关性很重要的原因。

WAF旁路备忘单 (WAF bypass cheat sheet )

The general idea behind finding ways to bypass WAF is to transform the request we need so that it’s still valid for the web app but not for the WAF or seems to be harmless. It’s important for one type of WAF to be able to serve many different types of servers, including the “exotic” ones, like Unicorn, Tornado, Weblogic, Lighttpd, etc. Each server may perceive exclusive cases of HTTP request parsing in a different way, which also should be considered by WAF. Thus, an attacker can use the servers’ specifics of HTTP request parsing to find a way to bypass the WAF.

找到绕过WAF的方法的总体思路是转换我们需要的请求，以使它对于Web应用程序仍然有效，但对WAF无效，或者看起来无害。 一种类型的WAF必须能够服务于许多不同类型的服务器，包括Unicorn，Tornado，Weblogic，Lighttpd等“异类”服务器，这一点很重要。每台服务器可能会以不同的方式感知HTTP请求解析的例外情况，WAF也应考虑。 因此，攻击者可以使用服务器的HTTP请求解析的详细信息来找到绕过WAF的方法。

It’s hard to classify all possible ways to bypass WAF either by WAF security mechanisms or by the field of use. The same bypass ways may interact and simultaneously affect different components of a WAF. The techniques described below were collected from open sources or discovered during our own research and proved to be among the most effective.

很难通过WAF安全机制或使用领域对所有可能的绕过WAF的方式进行分类。 相同的旁路方式可能相互作用并同时影响WAF的不同组件。 下面描述的技术是从开源收集的，或者是在我们自己的研究中发现的，被证明是最有效的技术。

添加特殊符号 (Adding special symbols)

Various special symbols can violate the analyzing logic of a WAF and at the same time be valid interpreted by the server. Variations of these symbols may be different: they may be transformed into urlencode (although most WAFs can deal with that) or other encodings. It’s also possible to insert special symbols into a request without any encoding, in raw format, which may come as a surprise for a WAF. For example,

各种特殊符号可能违反WAF的分析逻辑，并且同时可以由服务器有效解释。 这些符号的变体可能不同：它们可以转换为urlencode(尽管大多数WAF都可以处理)或其他编码。 还可以将原始格式的特殊符号插入到请求中，而无需任何编码，这可能会使WAF感到惊讶。 例如，

\ r \ n \ r \ n (\r\n\r\n)

in this presentation may be perceived as the ending of an HTTP request body, and null byte can violate the analyzing logic of regular expressions and data parsers altogether. Also, other special symbols from the first twenty symbols of the ASCII table may be of use.

在此演示文稿中，“字节”可能被视为HTTP请求主体的结尾，而空字节可能会完全违反正则表达式和数据解析器的分析逻辑。 同样，可以使用ASCII表的前二十个符号中的其他特殊符号。

Examples:

例子：

• 0x00 — Null byte;0x00 —空字节；
• 0x0D — Carriage return;0x0D —回车；
• 0x0A — Line feed;0x0A —换行；
• 0x0B — Vertical Tab;0x0B —垂直制表符；
• 0x09 — Horizontal tab;0x09 —水平制表符；
• 0x0C — New page0x0C —新页面

While searching for a bypass, it’s useful to insert special symbols in different places in the request body and not only into parameter values. For example, if a request is in JSON format, we can insert NULL-byte both into a parameter and between parameters, both at the beginning and the end of JSON. The same applies to other formats of the body of a POST request. In general, we recommend to do research and have fun, to look for places which can be monitored and parsed by WAF, and try using different special symbols there.

在搜索旁路时，将特殊符号插入请求正文中的不同位置非常有用，而不仅是在参数值中插入。 例如，如果请求采用JSON格式，则可以在JSON的开头和结尾将NULL字节插入参数中和参数之间。 POST请求正文的其他格式也是如此。 通常，我们建议您进行研究并从中获得乐趣，寻找可以被WAF监视和解析的地方，并尝试在其中使用其他特殊符号。

For example:

例如：

{"id":1337,"string0x00":"test' or sleep(9)#"}
{"id":1337,"string":"test'/*0x00*/ or sleep(9)#"}
{"id":1337,"string"0x0A0x0D:"test' or sleep(9)#"}

<a href="ja0x09vas0x0A0x0Dcript:alert(1)">clickme</a>
<a 0x00 href="javascript:alert(1)">clickme</a>
<svg/0x00/onload="alert(1)">

id=1337/*0x0C*/1 UNION SELECT version(), user() --

For clarity, we’ve replaced special symbols with their hex presentation. 为了清楚起见，我们已将特殊符号替换为其十六进制表示形式。

替换空格符号 (Replacing space symbols)

In most syntaxes, key words and operators have to be separated, but the preferable space symbols are not specified. Thus, instead of the common

在大多数语法中，关键字和运算符必须分开，但是没有指定首选的空格符号。 因此，代替普通

0x20 (0x20)

(Space), you can use

(空格)，您可以使用

0x0B (0x0B)

(Vertical Tab) or

(“垂直”标签)或

0x09 (0x09)

(Horizontal tab). Replacing spaces with dividing structures without their own meaning falls into the same category. In SQL, it is

(水平选项卡)。 用没有自身含义的分隔结构替换空间属于同一类别。 在SQL中，它是

/ ** / (/**/)

(multi-line SQL comments),

(多行SQL注释)，

＃\ r \ n (#\r\n)

(one-line SQL comment, ending with line feed),

(单行SQL注释，以换行结尾)，

-\ r \ n (--\r\n)

(alternative one-line SQL comment, ending with line feed). Here are some examples:

(另一行SQL注释，以换行结尾)。 这里有些例子：

http://test.com/test?id=1%09union/**/select/**/1,2,3
http://test.com/test?id=1%09union%23%0A%0Dselect%2D%2D%0A%0D1,2,3

Also, we can transform an expression to get rid of spaces using the syntax of the language. For example, in SQL, we can use parenthesis:

同样，我们可以使用语言的语法来转换表达式以消除空格。 例如，在SQL中，我们可以使用括号：

UNION(SELECT(1),2,3,4,5,(6)FROM(Users)WHERE(login='admin'))

And in JS, use

然后在JS中使用

/ (/)

:

：

<svg/onload=confirm(1)>

更改编码 (Changing encoding)

This method is based on using different encodings to keep WAF from decoding data in certain places. For example, if a symbol is replaced with its URL-code, WAF won’t be able to understand that it has to decode data and will pass the request. At the same time, the same parameter will be accepted and successfully decoded by the web application.

此方法基于使用不同的编码来防止WAF在某些位置解码数据。 例如，如果将符号替换为其URL代码，则WAF将无法理解其必须解码数据并将通过请求。 同时，相同的参数将被Web应用程序接受并成功解码。

The decimal form of an HTML symbol is

HTML符号的十进制形式是

＆＃106 (&#106)

or

要么

＆＃0000106 (&#0000106)

.WAF may know about the short version and not know about the version with additional zeros (there should be no more than 7 symbols in total). In the same way, the hex form of an HTML symbol is

.WAF可能知道短版本，而不知道带有附加零的版本(总共不应超过7个符号)。 同样，HTML符号的十六进制形式为

＆＃x6A (&#x6A)

or

要么

＆＃x000006A (&#x000006A)

.

。

There’s also a trick with escaping characters with a backslash

用反斜杠转义字符还有一个技巧

\ (\)

, for example:

， 例如：

<svg/on\load=a\lert(1)>

Though, it depends on how a web app processes such input data. So, the sequence

不过，这取决于Web应用程序如何处理此类输入数据。 所以，顺序

\ l (\l)

will be processed as an

将作为

升 (l)

and transformed into a single symbol; WAF can process each symbol separately and it can break regular expressions or another WAF logic. Thus, WAF will miss the keywords. Using this technique we cannot escape characters

并转换为单个符号； WAF可以分别处理每个符号，并且可以破坏正则表达式或其他WAF逻辑。 因此，WAF将丢失关键字。 使用这种技术，我们无法转义字符

\ n (\n)

,

，

\ r (\r)

,

，

\ t (\t)

, as they’ll be transformed into different characters: new line, carriage return, and tab.

，因为它们将转换为不同的字符：换行符，回车符和制表符。

HTML-encode may be used inside tag attributes, for example:

HTML编码可以在标记属性内使用，例如：

<a href="javascript&colon;alert(1)">clickme</a>
<input/onmouseover="javascript&colon;confirm&lpar;1rpar;">

These characters can be easily replaced by another HTML representations of target characters. You can look up different transformations of characters here.

这些字符可以很容易地用目标字符的另一个HTML表示代替。 您可以在此处查找字符的不同转换。

Besides HTML encode, we can insert characters with

除了HTML编码外，我们还可以使用

\ u (\u)

:

：

<a href="javascript:\u0061lert(1)">Clickme</a>
<svg onload=confir\u006d(1)>

Let’s also look at the vector related to inserting special character. Let’s break payload with HTML encode:

我们还要看一下与插入特殊字符有关的向量。 让我们用HTML编码打破有效载荷：

<a href="ja&Tab;vas
cript:alert(1)">clickme</a>

In this case, we can also place other separating characters.

在这种情况下，我们还可以放置其他分隔字符。

Thus, we recommend combining different encodings with other methods, for example, to encode special characters.

因此，我们建议将不同的编码与其他方法结合使用，例如，对特殊字符进行编码。

搜索非典型的等效句法结构 (Search for atypical equivalent syntactic structures)

This method aims at finding a way of exploitation not considered by the WAF developers, or a vector which was not present in the machine learning training sample. Simple examples would be JavaScript functions:

该方法旨在找到WAF开发人员未考虑的开发方式，或者找到机器学习训练样本中不存在的向量。 简单的例子是JavaScript函数：

这是最重要的自我，父母，框架； (this, top self, parent, frames;)

tag attributes:

标签属性：

数据绑定，切换，onfilterchange，onbeforescriptexecute，onpointerover，srcdoc; (data-bind, ontoggle, onfilterchange, onbeforescriptexecute, onpointerover, srcdoc;)

and SQL operators:

和SQL运算符：

lpad，字段，bit_count (lpad, field, bit_count)

.

。

Here are some examples:

这里有些例子：

<script>window['alert'](0)</script>
<script>parent['alert'](1)</script>
<script>self['alert'](2)</script>

SELECT if(LPAD(' ',4,version())='5.7',sleep(5),null);

You can also use the non-symbolic representation of JavaScript expressions:

您还可以使用JavaScript表达式的非符号表示形式：

• JSFuck;

  JSFuck ;

• Jjencode;

  Jjencode ;

• Xchars.js.

  Xchars.js 。

An obvious problem with that is long payloads.

一个明显的问题是有效载荷长。

WAF bypass with this technique depends on the attack and the exploited stack of technologies. The famous ImageTragick exploit is a good example of that. Most WAFs that protect from this attack had blacklisted keywords like

使用此技术的WAF旁路取决于攻击和被利用的技术堆栈。 著名的ImageTragick漏洞利用就是一个很好的例子。 大多数可以防止这种攻击的WAF都有将其列入黑名单的关键字，例如

网址 (url)

,

，

容量 (capacity)

, and

和

标签 (label)

since those words were mentioned in the majority of papers and PoCs describing this vulnerability. Though it was soon revealed that other keywords may be used too, for example,

因为在描述此漏洞的大多数论文和PoC中都提到了这些词。 尽管很快发现，也可以使用其他关键字，例如，

短暂的 (ephemeral)

and

和

潘戈 (pango)

. As a result, WAFs could be bypassed with the use of these keywords.

。 结果，可以使用这些关键字来绕过WAF。

HTTP参数污染(HPP)和HTTP参数碎片(HPF) (HTTP Parameter Pollution (HPP) and HTTP Parameter Fragmentation (HPF))

The HPP attack is based on how a server interprets parameters with the same names. Here are some possible bypasses:

HPP攻击基于服务器如何解释具有相同名称的参数。 以下是一些可能的绕过方法：

• The server uses the last received parameter, and WAF checks only the first;服务器使用最后一个接收到的参数，而WAF仅检查第一个；
• The server unites the value from similar parameters, and WAF checks them separately.服务器将来自类似参数的值组合在一起，然后WAF分别检查它们。

You can compare how different servers process the same parameters in the table below:

您可以在下表中比较不同服务器如何处理相同参数：

In its turn, the HPF attack is based on a different principle. If a web app’s logic unites two and more parameters in a request, the adversary can divide the request to bypass certain WAF checks.

反过来，HPF攻击是基于不同的原理。 如果Web应用程序的逻辑在请求中组合了两个或更多参数，则对手可以将请求划分为绕过某些WAF检查的方式。

The following SQL injection is an example of such an attack:

以下SQL注入是此类攻击的示例：

http://test.com/url?a=1+select&b=1+from&c=base

HPF and HPP are very similar, but the first targets a web app, and the latter the environment it operates in. Combining these techniques increases the chance of bypassing a WAF.

HPF和HPP非常相似，但是第一个针对Web应用程序，第二个针对Web应用程序在其中运行的环境。将这些技术结合起来可以增加绕过WAF的机会。

Unicode规范化 (Unicode normalization )

Unicode Normalization is a feature of Unicode meant for comparing Unicode symbols that look alike. For example, symbols

Unicode规范化是Unicode的一项功能，旨在比较相似的Unicode符号。 例如符号

ª ('ª')

and

和

ᵃ ('ᵃ')

has different codes but are very similar otherwise, so after normalization they both will look like a simple

具有不同的代码，但在其他方面却非常相似，因此在归一化之后，它们看起来都像是简单的

'一个' ('a')

and considered to be the same. Normalization allows transforming some complex Unicode-symbols into their simpler alternatives. There is a

并认为是相同的。 规范化允许将一些复杂的Unicode符号转换为更简单的替代方案。 有一个

具有所有Unicode符号及其可能的规范化的Unicode normalization table with all Unicode symbols and their possible normalizations. Using it, you can make different payloads and combine them with other methods. Although, it doesn’t work for all web applications and very dependent on the environment. Unicode规范化表 。 使用它，您可以制作不同的有效负载，并将它们与其他方法结合在一起。 但是，它不适用于所有Web应用程序，并且非常依赖于环境。

For example, in the table above, we can see that symbols

例如，在上表中，我们可以看到符号

＜ (＜)

and

和

﹤ (﹤)

transforms into simple

变成简单

< (<)

. If an app uses HTML encoding after normalization, then most likely the normalized symbol

。 如果应用在规范化后使用HTML编码，则很有可能是规范化的符号

< (<)

will be encoded into

将被编码为

< (<)

. But, in other cases, developers may have overlooked this feature and not encoded Unicode symbols. Тhus, we get non-HTML-encoded symbols

。 但是，在其他情况下，开发人员可能忽略了此功能，而不是编码的Unicode符号。 Тhus，我们得到了非HTML编码的符号

< (<)

and

和

> (>)

, which can be turned into XSS attack. WAF may have trouble with understanding Unicode symbols – it may simply doesn’t have rules for such tricks, and the machine learning may also be useless. While finding a bypass in web apps with Unicode normalization, we can replace not only

，这可以变成XSS攻击。 WAF在理解Unicode符号方面可能会遇到麻烦-它可能根本没有此类技巧的规则，并且机器学习也可能没有用。 在使用Unicode规范化在Web应用程序中找到旁路时，我们不仅可以替换

<> (< >)

but other symbols from payload as well.

但是有效载荷中的其他符号也是如此。

For example:

例如：

＜img src﹦x onerror＝alert︵1)>

Recently, this problem was found at Rockstar BugBounty program at HackerOne. There was no WAF, only strict user input filtering:

最近，在HackerOne的Rockstar BugBounty程序中发现了此问题。 没有WAF，只有严格的用户输入过滤：

hackerone.com/reports/231444hackerone.com/reports/231444 hackerone.com/reports/231389hackerone.com/reports/231389

令牌破坏者 (Token breakers)

Attacks on tokenizers attempt to break the logic of splitting a request into tokens with the help of the so-called token breakers. Token breakers are symbols that allow affecting the correspondence between an element of a string and a certain token, and thus bypass search by signature. But when using token breaker, the request must remain valid. The following request is an example of an attack using a token breaker

对令牌生成器的攻击试图借助所谓的令牌破坏器打破将请求拆分为令牌的逻辑。 令牌破坏符是允许影响字符串元素和某个令牌之间的对应关系的符号，因此可以绕过签名进行搜索。 但是，当使用令牌破坏器时，请求必须保持有效。 以下请求是使用令牌破坏器进行攻击的示例

SELECT-@1,version()

where

哪里

-@ (-@)

is the token breaker.

是令牌破坏者。

There is a chear sheet that was acquired by mysql fuzzing and checking the results in libinjection.

有一个chear片 ，是由MySQL的起毛和检查libinjection结果获得的。

More about finding issues in libinjection:

有关发现libinjection问题的更多信息：

Another fuzzer另一个模糊器 Fuzz to bypass模糊测试 How to bypasss libinjection如何绕过libinjection

使用RFC的功能 (Using the features of RFC)

In the specifications for the HTTP/1.1 protocol and various request types (e.g. multipart/form-data), we can find some curious things related to the boundary cases and tricks of processing headers and parameters. WAF developers often do not consider such issues, hence a WAF may parse a request incorrectly and miss the part of data, where an attack vector is hidden. Most problems in WAFs are related to the processing of multipart/form-data and specific values of the boundary parameter, which specifies parameter boundaries in such requests. Besides that, server developers may err as well and not support specifications entirely, so there may be undocumented features in a server’s HTTP parser.

在HTTP / 1.1协议的规范和各种请求类型(例如multipart / form-data)中，我们可以发现一些与边界情况以及处理标头和参数的技巧有关的奇特的东西。 WAF开发人员通常不会考虑此类问题，因此WAF可能会错误地解析请求，并丢失部分隐藏了攻击媒介的数据。 WAF中的大多数问题与多部分/表单数据的处理以及边界参数的特定值有关，边界参数指定了此类请求中的参数边界。 除此之外，服务器开发人员可能也会犯错，并且不完全支持规范，因此服务器的HTTP解析器中可能存在未记录的功能。

In an HTTP request with multipart/form-data, parameter boundary is in charge of segregation of different parameters in the body of a request. According to the RFC, a previously specified boundary with a prefix containing “--” has to be put before each new POST parameter, so that the server is able to discriminate the different parameters of a request.

在具有multipart / form-data的HTTP请求中，参数边界负责在请求正文中隔离不同的参数。 根据RFC，必须在每个新的POST参数之前放置一个前缀包含“-”的预先指定的边界，以便服务器能够区分请求的不同参数。

POST /vuln.php HTTP/1.1
Host: test.com
Connection: close
Content-Type: multipart/form-data; boundary=1049989664
Content-Length: 192--1049989664
Content-Disposition: form-data; name="id"287356
--1049989664--

The attack may also be based on the fact that a server and a WAF differently handle a situation where boundary is left empty. According to the RFC, in this case, “--” is the boundary between parameters. Nevertheless, a WAF may use a parser that doesn’t consider that, and, as a result, the WAF will pass the request because the data from the parameters of a POST request wouldn’t appear in the analyzer. The web server can parse such a request without problems and hand the data over for further processing.

该攻击还可能基于以下事实：服务器和WAF不同地处理边界留空的情况。 根据RFC，在这种情况下，“-”是参数之间的边界。 但是，WAF可能会使用不考虑该解析器的解析器，因此，WAF将传递请求，因为POST请求参数中的数据不会出现在分析器中。 Web服务器可以毫无问题地解析此类请求，并将数据移交给进一步处理。

Here are some more interesting examples.

这是一些更有趣的例子。

POST /vuln.php HTTP/1.1
Host: test.com
Connection: close
Content-Type: multipart/form-data; boundary=
Content-Length: 192--
Content-Disposition: form-data; name="id"123' or sleep(20)#
----

We will give some more interesting examples from slides by Bo0oM at ZeroNights 2016 and explain it:

我们将从BoooM在ZeroNights 2016的幻灯片中给出一些更有趣的示例，并对其进行解释：

POST /vuln.php HTTP/1.1
Host: test.com
Content-Type: multipart/form-data; boundary=FIRST;
Content-Type: multipart/form-data; boundary=SECOND;
Content-Type: multipart/form-data; boundary=THIRD;--THIRD
Content-Disposition: form-data; name=param UNION SELECT version()
--THIRD--

In this attack, we’re trying to define which one of the boundary parameters will be accepted by the WAF and which by the web server. Thus, if they’ll accept different parameters, it’s possible to perform an attack by specifying a boundary which the WAF won’t see. This attack is somewhat like HPP.

在这种攻击中，我们试图定义WAF接受哪些边界参数以及Web服务器接受哪些边界参数。 因此，如果他们接受不同的参数，则可以通过指定WAF无法看到的边界来执行攻击。 这种攻击有点像HPP。

POST /vuln.php HTTP/1.1
Host: test.com
Content-Type: multipart/form-data; xxxboundaryxxx=FIRST; boundary=SECOND;--FIRST
Content-Disposition: form-data; name=param UNION SELECT version()
--FIRST--

This attack is based on the assumption that there is a difference in the parsing of an HTTP request by the WAF and by the web server. Namely, the web server’s parser looks for the first ‘boundary’ entry, and then for ‘=’ symbol, and only after that defines the value of boundary. The WAF parser, in its turn, only looks for “boundary=” entry and then defines boundary. If these conditions are met, the WAF won’t find the boundary in the request, and hence it won’t be able to find and analyze the parameter. On the contrary, the web server will get the request and process the parameter. This attack will also work the other way around: web server parser looks for “boundary=”, and WAF parser looks just for ‘boundary’. In this case, we will only have to change the real boundary from FIRST to SECOND.

此攻击基于以下假设：WAF和Web服务器在解析HTTP请求方面存在差异。 即，Web服务器的解析器先寻找第一个“边界”条目，然后寻找“ =”符号，然后才定义边界的值。 反过来，WAF解析器仅查找“ boundary =”条目，然后定义边界。 如果满足这些条件，则WAF将不会在请求中找到边界，因此将无法找到和分析参数。 相反，Web服务器将获取请求并处理参数。 该攻击也将以其他方式起作用：Web服务器解析器将查找“ boundary =”，而WAF解析器将仅查找“ boundary”。 在这种情况下，我们只需要将实际边界从FIRST更改为SECOND。

POST /somepage.php HTTP/1.1
Host: test.com
Content-Type: multipart/form-data; boundary=Test0x00othertext; --Test
Content-Disposition: form-data; name=param
Attack
--Test--

This attack also uses special characters. In the boundary parameter, we added NULL-byte so that the web server would cut it off, but the WAF would accept it in full. In this case, WAF cannot analyze the parameter because it cannot find its boundaries.

此攻击还使用特殊字符。 在boundary参数中，我们添加了NULL字节，以便Web服务器将其切断，但WAF会完全接受它。 在这种情况下，WAF无法分析参数，因为它无法找到其边界。

绕过机器学习 (Bypassing machine learning)

The logic is simple: we have to compose an attack that would satisfy the parameters of the trained statistical model. But that’s highly dependent on how the WAF was trained and what training model was used. Sometimes it’s possible to find a loophole, and sometimes it’s not. Usually, at the stage of implementation, a WAF with machine learning needs extra training based on the request to the client’s web application. That poses a problem for pentesters: parameters that look alike and don’t change much from request to request cannot be tested, as any digression from the usual parameter form would be considered an anomaly. Let’s say way have a request to

逻辑很简单：我们必须构成一种满足训练后的统计模型参数的攻击。 但这高度依赖于WAF的培训方式和使用的培训模型。 有时可能会发现漏洞，有时则不会。 通常，在实施阶段，具有机器学习功能的WAF需要根据对客户Web应用程序的请求进行额外的培训。 这给渗透测试者带来了一个问题：看起来相似且在请求之间变化不大的参数无法进行测试，因为与常规参数形式的任何偏离都将被视为异常。 假设有一个要求

api.test.com/getuser?id=123 (api.test.com/getuser?id=123)

. Parameter id is always numeric, and it was numeric in the training sample. If the machine learning module finds something besides numbers in this parameter, it will most likely decide that it is an anomaly. Another example: suppose that WAF was trained to classify POST request to

。 参数id始终为数字，在训练样本中为数字。 如果机器学习模块在此参数中找到数字以外的内容，则很可能会确定这是异常情况。 另一个示例：假设WAF受过训练，可以将POST请求分类为

api.test.com/setMarkDown (api.test.com/setMarkDown)

with POST parameters that have markdown text. Obviously, there may be quotation marks, special symbols, and basically anything in the markdown. In this case, it is way easier to bypass the machine learning module because the WAF tolerates quotes and special symbols.

具有包含降价文字的POST参数。 显然，降价中可能包含引号，特殊符号以及基本上所有内容。 在这种情况下，绕过机器学习模块会更容易，因为WAF可以接受引号和特殊符号。

Additionally, on the examples from our practice, we’ll show that it doesn’t always go as far as the machine learning module due to the problems with the parsing of parameters caused by the bypass methods described above.

此外，在我们的实践示例中，我们将显示由于上述绕过方法导致的参数解析问题，它并不总是能到达机器学习模块。

In general, we have to consider the specifics of a tested request and its parameters, presume any possible options of parameters’ values, which WAF may be tolerant to, and build on those.

通常，我们必须考虑经过测试的请求及其参数的细节，假定WAF可以容忍的参数值的任何可能选项，并以此为基础。

WAF什么时候没用？ (When WAF is useless?)

WAF analyzes requests and looks for anomalous behavior in them, but there are some classes of vulnerabilities which it cannot discover. For example, logic vulnerabilities, which don’t have anomalies but have some actions that disrupt a web app’s logic. Most likely, WAF would be also useless in case of race condition, IDOR, and insecure user authentication.

WAF会分析请求并查找其中的异常行为，但是它无法发现某些类别的漏洞。 例如，逻辑漏洞，它没有异常，但是有一些动作会破坏Web应用程序的逻辑。 在竞争情况，IDOR和不安全的用户身份验证的情况下，WAF最有可能也是无用的。

现有实用程序 (Existing utilities)

There are some automatic tools for finding WAF bypasses, written by the enthusiasts in this field. Here are the most famous and worthy ones:

有一些自动工具可以找到WAF旁路，由该领域的爱好者编写。 以下是最著名和最有价值的：

lightbulb-framework — a whole framework for testing web apps protected with WAF. It is written on Python and additionally ported as a plugin for Burp Suite. Its main features are these two algorithms:灯泡框架 -用于测试受WAF保护的Web应用程序的整个框架。 它是用Python编写的，另外还被移植为Burp Suite的插件。 它的主要特征是以下两种算法：

• GOFA — an active machine learning algorithm that allows analyzing the filtration and sanitization of parameters in a web app.GOFA —一种主动的机器学习算法，可以分析Web应用程序中参数的过滤和清理。
• SFADiff — deferential black box testing algorithm, based on training with symbolic finite automats (SFA). It allows finding differences in the behavior of web apps which helps to identify WAF and find a bypass.SFADiff —差分黑盒测试算法，基于使用符号有限自动机(SFA)进行的训练。 它允许发现Web应用程序行为的差异，这有助于识别WAF并找到旁路。

Bypass WAF – a plugin for Burp Suite, which allows setting up automatic changing of the elements in the body of a request according to different rules and encoding changes. It also can automate an HPP attack. 绕过WAF – Burp Suite的插件，它允许根据不同的规则和编码更改设置请求正文中元素的自动更改。 它还可以自动执行HPP攻击。 WAFW00F — a tool for WAF identification, written on Python. It has a decent WAF base and is still being updated. Though, the results may be imprecise because many WAFs are updated more frequently than the project itself. WAFW00F —用Python编写的WAF识别工具。 它的WAF基础不错，并且仍在更新中。 但是，由于许多WAF的更新频率比项目本身的更新频率高，因此结果可能不准确。

在实践中绕过WAF (Bypassing WAF in practice)

We have been running penetration test of an online store, whose was protected by

我们一直在对一家在线商店进行渗透测试，该商店受到

自动对焦 (PT AF)

(Positive Technologies Application Firewall). It was hard to find a weak spot, which could be a base for a bypass. But soon we’ve discovered unusual behavior on the side of the web app, which was not filtered by the WAF. The anomaly was found in the search in the history of bought goods. The request was sent in JSON format and looked like that:

(正技术应用程序防火墙)。 很难找到一个弱点，这可能是绕过的基础。 但是很快我们就发现了Web应用程序一侧的异常行为，该行为未被WAF过滤。 在购买商品的历史搜索中发现了异常。 该请求以JSON格式发送，如下所示：

{"request":{"Count":10,"Offset":0,"ItemName":"Phone"}}

We placed

我们放置

电话' (Phone’)

and

和

电话'+' (Phone’+’)

, values into the

，将值放入

项目名称 (ItemName)

parameter and found that the server returned different responses for these two requests. In the first case, the response was empty; in the second case, it contained data on other goods with the word

参数，发现服务器对这两个请求返回了不同的响应。 在第一种情况下，响应为空； 在第二种情况下，它包含有关其他商品的数据，其单词为

电话 (Phone)

in their name, as if parameter

以他们的名字，就像参数

项目名称 (ItemName)

had

有

电话 (Phone)

as its value. This kind of behavior is well known among hackers and pentesters and points to the app’s a problem with the filtration of user input, which leads to SQL injection among others.

作为其价值。 这种行为在黑客和渗透测试者中是众所周知的，并指出该应用程序存在用户输入过滤问题，这会导致SQL注入。

Let’s see why this happens with an SQL injection example. If such behavior is found in a web application, then it’s highly likely that the data for an SQL request is in concatenation with the request itself. In the first case, with

让我们看看为什么在SQL注入示例中会发生这种情况。 如果在Web应用程序中发现了这种行为，则SQL请求的数据很可能与请求本身串联在一起。 在第一种情况下，

电话' (Phone’)

parameter, we’ll have the following SQL query:

参数，我们将具有以下SQL查询：

SELECT item FROM items WHERE item_name=’Phone’’

Obviously, it won’t be executed due to incorrect syntax and won’t return any result. The second request, with

显然，由于语法错误而不会执行，也不会返回任何结果。 第二个要求

电话'+' (Phone’+’)

parameter, will look like this:

参数，如下所示：

SELECT item FROM items WHERE item_name=’Phone’+’’

Its syntax is correct, so it will select goods by the name

它的语法正确，因此它将按名称选择商品

电话 (Phone)

. This method of detecting vulnerabilities has a huge advantage while testing a web app protected by WAF. Single quote symbol is not considered to be a sufficient anomaly in a parameter by most modern WAFs, so they pass a request with it.

。 在测试受WAF保护的Web应用程序时，这种检测漏洞的方法具有巨大优势。 大多数现代WAF都不认为单引号符号在参数中是足够的异常，因此它们会传递一个请求。

We’ve described vulnerability detection, but what about bypassing WAF and exploiting the vulnerability? After going through some bypasses, we found a problem in the WAF. It turned out that this WAF is vulnerable to special characters added to JSON parameters. In fact, if we added JSON symbols

我们已经描述了漏洞检测，但是绕过WAF并利用漏洞怎么办？ 经过一些绕过之后，我们在WAF中发现了一个问题。 事实证明，此WAF容易受到添加到JSON参数中的特殊字符的影响。 实际上，如果我们添加JSON符号

0x0A，0x0D (0x0A,0x0D)

(\r\n or carrige reutrn and new line) in raw format, without any encoding, into any text field, the WAF would pass it, and the web app would consider it to be correct and process it. Most likely, the problem was in the JSON parser, which was not made for special symbols and parsed JSON right until a place where these symbols would appear. Thus, WAF analyzer would not get the full request, so we could insert any attack vector after special characters. Besides line break, other characters (e.g. NULL-byte) would also work. As a result, we could write the following request, which would turn off the WAF as it tried to check this request (line break and carriage return were replaced with their textual representation):

(\ r \ n或carrige reutrn和换行符)以原始格式(不进行任何编码)输入任何文本字段，WAF会将其传递，并且Web应用程序将认为它是正确的并对其进行处理。 问题很可能出在JSON解析器中，该解析器不是用于特殊符号的，而是在出现这些符号的地方才解析JSON的。 因此，WAF分析器无法获得完整的请求，因此我们可以在特殊字符后插入任何攻击向量。 除换行符外，其他字符(例如NULL字节)也可以使用。 结果，我们可以编写以下请求，这将在WAF尝试检查该请求时将其关闭(换行符和回车符用其文本表示形式代替)：

{"request":{"kill-waf":"die0x0A0x0D", "Count":10,"Offset":0,"ItemName":["'+(SELECT 'Phone'+CHAR(ASCII(substring(@@version,1,1))-24))+'"]}}

0x0A and 0x0D is a raw bytes.0x0A和0x0D是原始字节。

Thus, we could easily and quickly test all parameters for any vulnerabilities (a couple of them were found in other parameters). Bypassing WAF and exploiting this injection allowed us to totally compromise all users of the web application.

因此，我们可以轻松快捷地测试所有参数的任何漏洞(在其他参数中发现了其中的几个)。 绕过WAF并利用此注入使我们完全可以损害Web应用程序的所有用户。

The same problems were also found in

也发现了同样的问题

Nemesida WAF (Nemesida WAF)

. The only difference is, the request was not in JSON encoding, but it was a usual POST request with parameters, and a parameter was concated to the SQL query as a number. If some symbols were placed in a request in url-encode, for example,

。 唯一的区别是，该请求不是采用JSON编码的，而是带有参数的常规POST请求，并且参数已作为数字包含在SQL查询中。 例如，如果某些符号以url编码放置在请求中，

％03％04 (%03%04)

then WAF blocks a request, but if symbols were placed in raw form without url-encoding then WAF overlooks this request. It is worth noting, that the normal SQL-expression was placed to request as well as in previous WAF. SQL-expression was simple

然后WAF阻止请求，但是如果将符号以原始形式放置而不进行url编码，则WAF将忽略此请求。 值得注意的是，在以前的WAF中都放置了普通SQL表达式来进行请求。 SQL表达式很简单

“联盟选择” (‘UNION SELECT’)

without any additional obfuscation, which means that WAF simply could not parse the request correctly and pass on the analysis further. But there is one problem – how to make SQL-query syntax correct? Because using special characters like

没有任何其他混淆，这意味着WAF根本无法正确解析请求并进一步进行分析。 但是有一个问题–如何使SQL查询语法正确？ 因为使用特殊字符，例如

％03％04 (%03%04)

in SQL-query isn’t correct. Answer is simple — we just need to use comments /**/. So, the result request looked like:

在SQL查询中是不正确的。 答案很简单-我们只需要使用注释/ ** /。 因此，结果请求如下所示：

/*0x03 0x04*/1 UNION SELECT version(), user() --

0x03 and 0x04 is a raw bytes.0x03和0x04是原始字节。

Also, another problem was found in Nemesida WAF. It was related to incorrect processing of POST requests with multipart/form-data. As we described below, in an HTTP request with multipart/form-data, parameter

另外，在Nemesida WAF中发现了另一个问题。 这与对带有多部分/表单数据的POST请求的不正确处理有关。 如下所述，在具有multipart / form-data的HTTP请求中，参数

边界 (boundary)

is in charge of segregation of different parameters in the body of a request. According to the RFC, a previously specified boundary with a prefix containing

负责在请求正文中隔离不同的参数。 根据RFC，先前指定的边界带有前缀，其中包含

“-” (“--”)

has to be put before each new POST parameter, so that the server is able to discriminate the different parameters of a request.

必须将其放置在每个新的POST参数之前，以便服务器能够区分请求的不同参数。

So, the problem was that the server and WAF handled the situation differently when the boundary parameter was empty. Based on the RFC, in such a situation the boundary between the parameters will be a sequence of characters

因此，问题是当边界参数为空时，服务器和WAF对情况的处理方式不同。 基于RFC，在这种情况下，参数之间的边界将是一个字符序列

“-” (“--”)

. However, WAF used a parser that does not take into account this feature, which is why WAF again pass the request, because the data from the POST request parameters simply did not get into the analyzer module, and the server parsed this situation without any problems and transferred the data further to processing. This is an sample request for this attack:

。 但是，WAF使用的解析器没有考虑到此功能，这就是WAF再次传递请求的原因，因为POST请求参数中的数据根本没有进入分析器模块，服务器对此情况进行了解析，没有任何问题并将数据传输到进一步处理。 这是对此攻击的示例请求：

POST /wp-content/plugins/answer-my-question/modal.php HTTP/1.1
Host: example.com
Content-Type: multipart/form-data; boundary=
Content-Length: 209--
Content-Disposition: form-data; name="id"1 UNION SELECT 1,2,3,CONVERT(version() USING utf8) AS name,CONVERT(user() USING utf8) AS name,6,7,8,9,10,11,12 FROM wp_users WHERE id=1
----

Both problems were reported to Pentestit, the guys paid a reward for their bug bounty program for Nemesida WAF, and fixed the problems as soon as possible. Thank them for that.

这两个问题都已报告给Pentestit，他们为Nemesida WAF的漏洞赏金计划提供了奖励，并尽快解决了这些问题。 谢谢他们。

As we can see, WAFs may be modern and smart, but sometimes it’s possible to bypass them just by adding a single special character. Today we cannot foresee all possible kinds of input data for all servers at the stage of development, and machine learning, implemented to do exactly that, stumbles upon parsers that get stuck with special characters.

正如我们所看到的，WAF可能是现代而智能的，但是有时可以通过添加单个特殊字符来绕开它们。 Today we cannot foresee all possible kinds of input data for all servers at the stage of development, and machine learning, implemented to do exactly that, stumbles upon parsers that get stuck with special characters.

结论 (Conclusion )

So, should we entirely rely on WAF? So, should we entirely rely on WAF?

The answer is NO. ( The answer is NO.)

In one of our audits, we’ve discovered a WAF bypass that allowed us to exploit some vulnerabilities. As it turned out, the developers had already performed an audit of the web app, before it was protected by WAF, and it revealed the same vulnerabilities. Instead of fixing them, they decided to buy a modern WAF equipped with machine learning. It is a pity that the WAF’s vendor did not insist on fixing the vulnerabilities first; or perhaps the developers themselves thought that WAF would be a better option. We do not know for sure though. Either way, this is an example of a very bad practice, on part of both the developers and the vendor. It also should be noted that machine learning is still a black box and looks more like a marketing device than a real defense.

In one of our audits, we've discovered a WAF bypass that allowed us to exploit some vulnerabilities. As it turned out, the developers had already performed an audit of the web app, before it was protected by WAF, and it revealed the same vulnerabilities. Instead of fixing them, they decided to buy a modern WAF equipped with machine learning. It is a pity that the WAF's vendor did not insist on fixing the vulnerabilities first; or perhaps the developers themselves thought that WAF would be a better option. We do not know for sure though. Either way, this is an example of a very bad practice, on part of both the developers and the vendor. It also should be noted that machine learning is still a black box and looks more like a marketing device than a real defense.

In general, WAF is a modern security solution, and it won’t hurt having it with your web applications. Although today, it can only hinder the process of vulnerability search and exploitation, but it cannot protect from them altogether. As thing stand, this is the state of the art for quite a while. Vulnerabilities in web apps can only be fixed by correcting the code related to them, and that’s the only foolproof solution.

In general, WAF is a modern security solution, and it won't hurt having it with your web applications. Although today, it can only hinder the process of vulnerability search and exploitation, but it cannot protect from them altogether. As thing stand, this is the state of the art for quite a while. Vulnerabilities in web apps can only be fixed by correcting the code related to them, and that's the only foolproof solution.

贡献者 (Contributors)

Ilia Bulatov Ilia Bulatov barracud4 barracud4 Denis Rybin Denis Rybin thefaeriedragon thefaeriedragon Alexander Romanov Alexander Romanov web_rockweb_rock

翻译自: https://habr.com/en/company/dsec/blog/454592/

主流waf非主流waf