【注入后端HTTP请求】服务器端HTTP重定向、HTTP参数注入

目录

一、注入后端HTTP请求

1.1、简介：

二、服务器端HTTP重定向

2.1、简述：

2.2、示例：

三、HTTP参数注入

3.1、简述：

3.2、示例：

3.3、HTTP参数污染

简述：

3.4、攻击URL转换

简述：

示例：

过程：

---

一、注入后端HTTP请求

1.1、简介：

将用户提交的数据合并到后端HTTP请求中， 以请求用户无法直接访问的服务。通常应用程序可能会将用户输入嵌入任何类型的后端HTTP请求， 包括那些以常规名／值对传输参数的请求。由于应用程序通常会有效代理用户提交的URL或参数， 因而这种行为往往易于受到攻击。针对这种功能的攻击可以分为：

A、服务器端HTTP重定向：攻击者通过这种方法指定任意资源或URL，然后再由后端应用程序服务器请求这些资源或URL

B、HTTP参数注入(HPl) ：攻击者通过这种方法在应用程序服务器提出的后端HTTP请求中注入任意参数。如果攻击者注入后端请求中已存在的参数， 就可以利用HTTP参数污染(HPP)攻击覆盖服务器指定的原始参数值

---

---

二、服务器端HTTP重定向

2.1、简述：

1、如果应用程序接受用户可控制的输入， 并将其合并到使用后端HTTP请求检索的URL中， 这种行为就会导致服务器块重定向漏洞。用户提交的输入中可能包含被检索的完整URL，或者应用程序可能会对该URL进行某种处理， 如添加标准的后缀

2、后端HTTP请求可能指定公共因特网上的某个域，或指定用户无法直接访问的内部服务器所请求的内容可能对应用程序的功能非常关键（如支付网关的接口，或从第三方提取的内容），常用于将几个单独的内部和外部应用程序组件结合到一个前端应用程序中， 再由该应用程序代表这些组件实施访问控制和会话管理。如果攻击者能够控制后端HTTP请求中的IP地址或主机名， 他就可以使应用程序服务器连接到任意资源，甚至能够检索后端响应的内容

---

2.2、示例：

POST前端请求，loc参数用千指定客户端希望查看的CSS文件的版本

view=default&loc=xxx.com/css/xx.css

如果没有在loc参数中为URL指定确认机制，攻击者就可以指定任何主机名来替代xxx.com。应用程序将检索指定的资源， 导致攻击者将应用程序用作潜在的敏感后端服务的代理服务器

如攻击者使应用程序连接到后端SSH服务

view=default&loc=192.168.0.1:22

---

---

三、HTTP参数注入

3.1、简述：

如果用户提交的参数被用作后端HTI下行求中的参数， 这时就会导致HTTP参数注入(HPI)

---

3.2、示例：

转账

1、由用户的浏览器提出POST请求

2、应用程序向银行基础架构中的另一台Web服务器提出其他HTTP请求，在后端请求中，应用程序从前端请求中复制参数值

3、后端服务器检查是否有资金可以转账，有则进行转账

（但前端服务器可以通过在后端请求中注入clearedfunds=true参数，即存在清算资金，避开检查）        

4、要注入参数，需要将所需参数附加到现有参数值的后面， 井将分隔名称和值的＆和＝字符进行URL编码

5、当应用程序服务器处理这个请求时（对参数值进行URL解码）

6、如果应用程序没有过滤这个值并按原样传递给后端请求， 参数将被注入到应用程序提出的后端请求， 使攻击者能够成功避开清算资金检查

3.3、HTTP参数污染

简述：

1、HPP是一种可用于各种环境下的攻击技巧，常用在HPI攻击中。

如果请求中包含多个同名请求， 各种Web服务器的处理方式各不相同， 一些常见的处理方式：

A、使用参数的第一个实例

B、使用参数的最后一个实例

C、串联参数值， 可能在参数之间添加分隔符

D、构建一个包含所有请求值的数组

2、在HPI中， 攻击者可以在后端请求中添加一个新参数。但攻击者可以对其实施注入攻击的请求很可能已经包含一个与攻击者所针对的参数同名的参数。此时攻击者可以使用HPI条件注入另一个同名参数。应用程序的表现，取决于后端HTTP服务器如何处理重复的参数。攻击者或许可以用他注入的参数值，覆盖原始参数值。

3、HPP攻击能否成功，很大程度取决于目标应用程序服务器如何处理多个同名参数， 以及后瑞请求中的插入点是否准确。如果两种技术需要处理相同的HTTP清求， HPP攻击就会造成严重的后果。Web应用程序防火墙或反向代理可能会处理某个请求，并将其传递给Web应用程序，由Web应用程序抛弃变量，甚至是基于之前不相关的请求部分构建字符串

3.4、攻击URL转换

简述：

许多服务器会在所请求的URL抵达时重写URL ，再将它们映射到应用程序中的相关后端功能。除传统的URL重写外， 服务器在处理REST风格的参数、定制导航包装器以及其他URL转换方法时都会进行URL重写。这种处理方式可能易受HPI和HPP攻击。

为了简化和便于导航， 一些应用程序在URL的文件路径， 而非查询字符串中插入参数值。通常应用程序会通过一些简单的规则转换URL，然后将其转发给其正的目标

---

示例：

处理可公共访问的用户资料（Apache中的mod_rewrite规则）

RewriteCond %{THE_REQUEST}   ^[A-Z] {3,9}\ /pub/user/ [^\&]*\ HTTP/

RewriteRule ^pub/user/ ([^ / \ . ]+) $ /inc/user_mgr.php?mode=view&name=$1

1、请求/pub/user/test

2、将请求转换为后端请求，以便于用户管理页面user_mgr.php包含的view功能进行处理。将marcus参数移入查询字符串并添加mode=view参数

/inc/user_mgr.php?mode=view&name=test

3、攻击者可以利用HPI攻击在经过重写的URL中注入另一个mode参数

/pub/user/test%26mode=edit

4、URL编码的值嵌入经过重写的URL中

/inc/user_mgr.php?mode=view&name=test&mode=edit

在PHP平台中，mode参数被视为具有值edit，因而攻击取得成功

---

过程：

1、针对每个请求参数进行测试， 尝试使用各种语法添加一个新注入的参数

%26foo%3dbar（&foo=bar的URL编码）

%3bfoo%3dbar（;foo=bar的URL编码）

%2526foo%253dbar（&foo=bar的双重URL编码）

2、确定任何修改后不会改变应用程序的行为的参数实例（修改后会在应用程序的响应中造成差异的参数）

3、在上一步确定的每个实例都可以实施参数注入，尝试在请求的不同位置注入一个已知的参数， 看是否可以覆盖或修改现有的参数

4、如果会将现有值替换为新值，确定是否可以通过注入一个由后端服务器读取的值来避开任何前端确认机制

5、用其他参数名称替换注入的已知参数

6、测试应用桯序是否允许在请求中多次提交同一个参数，在其他参数前后，以及请求的不同位置提交多余的值