web安全CRLF注入&HPP参数污染&URL重定向

Posted 2021-09-09 遗憾zzz

一、CRLF注入原理

CRLF注入漏洞，是因为Web应用没有对用户输入做严格验证，导致攻击者可以输入一些恶意字符。攻击者一旦向请求行或首部中的字段注入恶意的CRLF，就能注入一些首部字段或报文主体，并在响应中输出，所以又称为HTTP响应拆分漏洞。

名词解释：
CR：Carriage Return，对应ASCII中转义字符\\r，表示回车 (CR，ASCII 13，\\r，%0d)
LF：Linefeed，对应ASCII中转义字符\\n，表示换行 (LF，ASCII 10，\\n，%0a)
CRLF：Carriage Return & Linefeed，\\r\\n，表示回车并换行
键盘上的回车键(Enter)就可以执行该操作。但是不同的操作系统，行的结束符是不一样的。

Windows：使用CRLF表示行的结束
Linux/Unix：使用LF表示行的结束
MacOS：早期使用CR表示，现在好像也用LF表示行的结束

所以同一文件在不同操作系统中打开，内容格式可能会出现差异，这是行结束符不一致导致的。
在HTTP规范中，行应该使用CRLF来结束。首部与主体由两个CRLF分隔，浏览器根据这两个CRLF来获取HTTP内容并显示。

二、CRLF注入漏洞利用

CRLF注入漏洞的本质和XSS有点相似，攻击者将恶意数据发送给易受攻击的Web应用程序，Web应用程序将恶意数据输出在HTTP响应头中。（XSS一般输出在主体中）
所以CRLF注入漏洞的检测也和XSS漏洞的检测差不多。通过修改HTTP参数或URL，注入恶意的CRLF，查看构造的恶意数据是否在响应头中输出。

环境搭建好之后，直接抓包查看，ip:192.168.111.130:8080


在请求行的url参数中加入特殊构造的CRLF字符如下

%0a%0dSet-Cookie=crlf=true

可以看到输入的恶意数据，作为响应首部字段返回给了客户端，原理就是当检测到%0d%0a后，就认为url字段这行结束了，Set-Cookie就会被认为是下一行

所以构造xss payload

%0d%0a%0d%0a<img src=1 onerror=alert(/xss/)>/

就可以看到xss代码被写入了html代码中

CRLF注入脚本自动检测
CRLFuzz：https://github.com/dwisiswant0/crlfuzz/releases
使用方法：直接 -u 加上url地址就行

CRLF注入参考：https://blog.csdn.net/weixin_37968613/article/details/107470182

三、URL重定向原理

写代码时没有考虑过任意URL跳转漏洞，或者根本不知道/不认为这是个漏洞;写代码时考虑不周,用取子串、取后缀等方法简单判断，代码逻辑可被绕过;对传入参数做一些奇葩的操作(域名剪切/拼接/重组)和判断，适得其反，反被绕过; 原始语言自带的解析URL、判断域名的函数库出现逻辑漏洞或者意外特性,可被绕过;原始语言、服务器/容器特性、浏览器等对标准URL协议解析处理等差异性导致绕过;

当网站接受用户输入的链接，跳转到一个攻击者控制的网站，可能导致跳转过去的用户被精心设置的钓鱼页面骗走自己的个人信息和登录口令。

业务：
用户登录、统一身份认证处，认证完后会跳转
用户分享、收藏内容过后，会跳转
跨站点认证、授权后，会跳转
站内点击其它网址链接时，会跳转

黑盒看参数名：
redirect redirect_to redirect_url
url jump jump_to target to link linkto domain

白盒看代码块：
Java：response.sendRedirect(request.getParameter("url"))
php:
$redirect_url = $_GET['url'];
header("Location: " . $redirect_url)
.NET:
string redirect_url = request.QueryString["url"];
Response.Redirect(redirect_url);
Django:
redirect_url = request.GET.get("url")
HttpResponseRedirect(redirect_url)
Flask:
redirect_url = request.form['url']
redirect(redirect_url)
Rails:
redirect_to params[:url]

绕过方法
1. 单斜线"/"绕过
https://www.landgrey.me/redirect.php?url=/www.evil.com
2. 缺少协议绕过
https://www.landgrey.me/redirect.php?url=//www.evil.com
3. 多斜线"/"前缀绕过
https://www.landgrey.me/redirect.php?url=///www.evil.com
https://www.landgrey.me/redirect.php?url=www.evil.com
4. 利用"@"符号绕过
https://www.landgrey.me/redirect.php?url=https://[e-mail]
5. 利用反斜线"\\"绕过
https://www.landgrey.me/redirect.php?url=https://www.evil.com\\www.landgrey.me
6. 利用"#"符号绕过
https://www.landgrey.me/redirect.php?url=https://www.evil.com#www.landgrey.me
7. 利用"?"号绕过
https://www.landgrey.me/redirect.php?url=https://www.evil.com?www.landgrey.me
8. 利用"\\\\"绕过
https://www.landgrey.me/redirect.php?url=https://www.evil.com\\\\www.landgrey.me
9. 利用"."绕过
https://www.landgrey.me/redirect.php?url=.evil           (可能会跳转到www.landgrey.me.evil域名)
https://www.landgrey.me/redirect.php?url=.evil.com       (可能会跳转到evil.com域名)
10.重复特殊字符绕过
https://www.landgrey.me/redirect.php?url=///www.evil.com//..
https://www.landgrey.me/redirect.php?url=www.evil.com//..

四、URL重定向漏洞利用

先来到pikachu靶场 url重定向漏洞


可以看到有个关键地方url=i 我们试试改成 http://www.baidu.com

那么这里如果攻击者构造恶意网址把它放在参数后面

http://pikachu-master/vul/urlredirect/urlredirect.php?url=www.exp.com

受害者误以为这是一条安全的链接，点开后提示网站需要升级，请输入用户名及密码，输入后这些数据就成功记录到攻击者的数据库里，形成钓鱼攻击

五、HPP参数污染原理

HPP，即 HTTP Parameter Pollution，HTTP 参数污染。在 HTTP 协议中是运行同样名称的参数出现多次，攻击者通过传播参数的时候传输 key 相同而 value 不同的参数，从而达到绕过某些防护与参数校验的后果。它是一种注入型的漏洞，攻击者通过在 HTTP 请求中插入特定的参数来发起攻击。
比如：www.xxx.com/a.php?id=1 这里接受的参数id=1
那么改成www.xxx.com/a.php?id=1&id=2 就会导致接受的值改变具体需要根据中间件来决定

HPP参数污染还可以用于绕过某些防火墙对于 SQL注入的检测，例如当Web服务器对多参数都同时选择时，我们可以用以下这种方式绕过某些防火墙：

http://www.xxx.com/a.php?id=select 1,2,3 from table where id=1
http://www.xxx.com/a.php?id=select 1&page=2,3 from table where id=1

URL重定向绕过
网址请求：http://www.xxx.com/a.php?url=http://127.0.0.1
正常被ban掉的构造：http://www.xxx.com/a.php?url=http://www.baidu.com
构造绕过的网址：http://www.xxx.com/a.php?url=http://127.0.0.1&url=@www.baidu.com