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.提高漏洞響應速度，防止出現更大損失
響應後酌情處理，能下線馬上下線，防止數據洩露。
閱讀更多 小豬漫跑 的文章
