CRLF注入
在*nix系统中，常见的换行符为\\n（即Line Feed，ASCII \\10）
Windows中常见的换行符为\\r\\n（即Carriage Return + Line Feed ASCII \\13\\10），在HTTP请求中，使用的也是CR-LF换行。
此漏洞常出现在当web应用将请求的一部分写入HTTP头时，下面以一个最简CR-LF洞举例。
假设我们有一个网站www.testme.com，且我们的web服务器没有做防御，在遇到
www.testme.com/%0D%0ASet-Cookie:token=pwned的请求时（%0D%0A为url编码的\\13\\10），
这时候，网站如果直接回应，HTTP respond就会变成这样：
Connection: keep-alive
Content-Length: *
Content-Type: text/html
Date:Wed, 29 Nov 2017 06:23:45 GMT
Location: http://www.testme.com/
Set-Cookie: token=pwned
这里的最后的这一句Set-Cookie: token=pwned 并不是服务器所期望的，我们的请求中的URL中的%0D%0A转换为了换行符，所以在respond中我们成功改变了服务器回应的HTTP报文。
当然，现在这样做看起来可能并没有什么卵用。
在现实应用中，我们一般可以构造一个危害链接，使得HTTP respond中网页前段插入一段JS代码，诱导用户点击，这样在用户点击这个链接的时候，在浏览器看来，这个JS并没有跨域，也没有特殊操作，但是用户的页面已经成功被我们控制，包括他的cookies，包括他的下一步的请求信息，我们还可以在某些情况下构造cookies里的参数，使得我们的JS一直被用户带着浏览，达到更加不为人知的目的。
文件包含/目录遍历
假设我们有一个网站，
http://www.testme.com/index.php?pic=/content.png
如果webserver的webroot目录有问题，那么我们可能可以通过http://www.testme.com/index.php?pic=../../../../etc/passwd
这样读取到服务器的/etc/passwd文件，这非常危险。
另外一种就是文件请求问题，
比如我做了一个网页，其中一个frame中的东西我想使用自己缓存的静态网页填充，最后做出来网站是这样的
http://www.testme.com/index.php?staticfile=index.html，
这样存在访问http://www.testme.com/index.php?staticfile=http://www.mi.com后，
获得一个嵌入了小米官网的网页，如果我们的网页有脚本将cookies发送到某个地方，这样用户的cookies就泄露了，很多系统都曾发现过文件包含漏洞。
在php里有可能可以引入php脚本执行php指令
序列化
此处以php举例，php中有serialize() 这一序列化/反序列化内置工具，在系统直接接受一个序列化对象，并且没有将其认真过滤时，容易引起一些应用安全问题。
举例：利用下面这个php类的__destruct()析构函数，删除index.php
class cache { public $cache_file; function __construct() { // some PHP code...
} function __destruct() { $file = "/var/www/cache/tmp/{$this->cache_file}"; if (file_exists($file)) @unlink($file);
}
}$user_data = unserialize($_GET['data']);
我向这个系统请求http://testme.com/cache.php?data=O:8:"cache":1:{s:10:"cache_file";s:15:"../../index.php";}
系统序列化完毕后，这个对象成为一颗定时炸弹，当析构这个对象的同时，调用析构函数就把index.php给一起删掉了。
暴露序列化/反序列化接口非常危险，近年来FastJson、Jackson等java库，jenkins、wordpress、struts2 REST等等广为使用的系统均出现过各种反序列化漏洞，这种漏洞一般比较隐蔽，不容易被发现，但是也很容易被有心的人士利用，造成巨大损失。
SQL注入攻击
SQL注入攻击已经是老生常谈了，各种过滤绕过的对抗让人眼花缭乱，归根结底还是一种语义攻击，改变原有的查询，CURD一些数据库的条目。
举例最简情况
www.testme.com/login?username=blablablabla&password='md5(blablablabla)'
后台SQL:"SELECT user_role FROM sys_users WHERE username="+username+"AND password="+password+";"
如果我的请求是www.testme.com/login?username=admin OR 1;&password=blabla，
那么我们就成功用admin的角色登进去了系统。
在此基础上发展来的盲注，手注，timebased注入，包括sqlmap等工具，以及被安全人员所不齿的kali上的明小子（雾）、啊D等工具，各种黑科技的绕过手段，基本原理还是上面的语义攻击手段。
XSS/CSRF
XSS名叫跨站脚本攻击，顾名思义，就是执行了一个不是你源站的脚本的攻击，最简单的一个例子就是当年某大型论坛系统，文本框中对html标签毫无限制，结果发表一句
在某个帖子上，所有访问这个帖子的人全部原地爆炸，那时候的浏览器还没有连续弹框可以直接拒绝弹窗的功能，上面CRLF中，在用户网页里执行我们的脚本也算是一种XSS。
CSRF是跨站请求伪造攻击，也就是，用户在不知情的情况下访问了他所无法预料的链接，比如据传某广告屏蔽软件就在向用户网页中注入不可见广告的js模块赚取高额利润，这就是一种CSRF。
常见的知名CVE
openssl的heartbleed漏洞、13-17年连续爆出的大量struts2洞、ImageMagick、ffmpeg、jenkins反序列化、badtunnel、tomcat本地容器提权、各大系统的命令执行漏洞......
有兴趣的同学可以自行搜索
如何预防这些安全漏洞？
安全漏洞是不可避免的，任何一个较为大型的系统都会有漏洞出现，这是一个软件生命周期中几乎必定会经受的考验，我们能做的有
1.增强安全意识，减少漏洞出现的频率
首先在开发时，不要使用eval()、system()等等高危函数，写SQL查询时使用prepare()预置模板，并且严格检查用户的输入，严格过滤所有来源不明的信息，坚信用户输入是不可靠的。
2.做好基本安保措施，防止可能出现的攻击
做好服务器出站策略，很多扫描脚本常使用的nc、busybox-telnetd等软件做好防御和检测，不常见url请求要注意分析，数据库连接查询条目做好检测，大批量查询要进行拦截并报警。
nginx中可以设立蜜罐，防范扫描器扫描网站，比如将所有访问/wp-admin的IP地址全部封禁，同时导入公用IP黑名单、使用非人类鉴别服务，对公有云、公有IDC的IP段打来的流量重点防范。
利用namespace、cgroups等特性隔离部分风险，禁止某些敏感命令。
3.提高漏洞响应速度，防止出现更大损失
响应后酌情处理，能下线马上下线，防止数据泄露。
閱讀更多 小豬漫跑 的文章
