DOM-XSS
用一句話來總結所有DOM XSS的場景，就是：不可控的危險數據，未經過濾被傳入存在缺陷的JavaScript代碼處理，最終觸發DOM XSS漏洞。
未知攻焉知防——XXE漏洞攻防
無論是WEB程序，還是PC程序，只要處理用戶可控的XML都可能存在危害極大的XXE漏洞，開發人員在處理XML時需謹慎，在用戶可控的XML數據裏禁止引用外部實體。
WAF之SQL注入防禦思路分享
關鍵字防護
SQL注入最簡單、粗暴但實用的方式就是檢測一些關鍵字，通過把這些能造成影響的關鍵字加入黑名單，可以阻斷大部分的利用代碼。這類關鍵字主要包含幾種：
- SQL語句的關鍵保留字，如select from，union select，drop table，into outfile等。
- MySQL等DBMS的內建函數，如version(),load_file()，sleep()，benchmark()等
- MySQL等DBMS內建變量，如@@version等。
- MySQL所識別的內聯註釋，如/!union/ /!select/或/!50000union/等
真假條件防護
上述的關鍵字方法能過濾掉很多的利用代碼，但還不全。SQL注入技術中有一種是通過利用注入條件的真假的方式來獲取相關信息的，例如CGI：http://host/SQLi.php?id=1對應的SQL語句爲select * from t_table where id=1。則通過注入:
http://host/SQLi.php?id=1 or 1=1 => select* from t_table where id=1 or 1=1http://host/SQLi.php?id=1 and 1=2 =>select *from t_table where id=1 and 1=2通過判斷真假來獲取MySQL的相關信息。對於這種方式如果通過簡單的添加關鍵字會造成誤報而影響業務的情況。這種情況下我們需要分析此類型的應用，例如：
- op可以是and，or，<，>=，||，&&等
- 分隔符可以是空格，/**/註釋等
- a與b可以是數字，字符串，表名，函數，sql語句結果等等
通過窮舉此類應用方式來阻斷相關的利用
繞過防護
URL編碼
瀏覽器中輸入URL是會由瀏覽器進行一次URL編碼，而攻擊可能會通過多次編碼來對WAF進行繞過，例如：
Id.php?id=1%2520union//select 解碼後實際爲Id.php?id=1 union//select
如果只經過一次解碼，則變成Id.php?id=1%20union/**/select
可能繞過正則表達式的檢測
通過循環多次URL解碼解決此類問題特殊字符
%00如果直接URL解碼，結果是C語言中的NULL字符。如果WAF使用string等數據結構來存儲用戶的請求，則解碼之後會截斷字符串，造成後面的內容不經過檢測。例如
Id.php?id=1%20union/**/select
解碼後可能變成：
Id.php?id=1[NULL]%20union/**/select
後面的%20union/**/select就躲過了WAF的檢查，從而繞過WAF。解決方式：
1、對% 00進行特殊處理
2、不要使用string等存儲用戶的請求內容
%a0是不換行空格，用於在字處理程序中標示禁止自動換行。使用正則表達式的\s無法匹配到這個字符，但在mysql中%a0與普通的空格一樣，可以當成分隔符來使用。即對於Mysql來說，如下請求經過URL解碼之後是一樣的
Id.php?id=1%20union/**/select
Id.php?id=1//union//select
Id.php?id=1%a0union/**/select
對於這種字符，可以進行特殊處理後再進行匹配
%0b是垂直製表符，%09是水平製表符。在正則表達式中，\s與\t均可匹配%09水平製表符，但匹配不了% 0b（%和0b之間沒有空格，編輯需要）垂直製表符，需要使用\v匹配。如果正則表達式中，mysql的分隔符沒有考慮到這種情況，也存在繞過的風險
半個中文字符。RE2等正則引擎默認使用UTF8編碼，UTF8編碼是3-4字符的編碼，如果出現%e4等半個中文，即1個字符的時候，UTF8解碼不出，用正則表達式的任意匹配符（.）是匹配不出來的。針對這種字符，可以考慮特殊處理或者變更引擎的編碼。- 畸形HTTP請求
當向Web服務器發送畸形的，非RFC2616標準的HTTP請求時，Web服務器出於兼容的目的，會儘可能解析畸形HTTP請求。而如果Web服務器的兼容方式與WAF不一致，則可能會出現繞過的情況。例如
GET id.php?id=1%20union/**/select
這個請求沒有協議字段，沒有Host字段。但apache對這個請求的處理，默認會設置協議爲HTTP/0.9，Host則默認使用Apache默認的servername
在這種情況下，可以選擇：
1、儘可能與Web服務器保持一致
2、拒絕非標準的HTTP請求（在後端防護的Web服務器有多種類型時，如apache，nginx，lighthttpd等，由於每種web服務器的兼容性不一致，所以要實現1的WAF儘可能與Web服務器保持一致存在一定的困難）
- 畸形HTTP請求
主流WAF架構分析與探索
方案A：本機服務器模塊模式
通過在Apache，IIS等Web服務器內嵌實現檢測引擎，所有請求的出入流量均先經過檢測引擎的檢測，如果請求無問題則調用CGI處理業務邏輯，如果請求發現攻擊特徵，再根據配置進行相應的動作。以此對運行於Web服務器上的網站進行安全防護。著名的安全開源項目ModSecurity及naxsi防火牆就是此種模式。
優點：
1、 網絡結構簡單，只需要部署Web服務器的安全模塊
挑戰：
1、 維護困難。當有大規模的服務器集羣時，任何更新都涉及到多臺服務器。
2、 需要部署操作，在面臨大規模部署時成本較高。
3、 無集中化的數據中心。針對安全事件的分析往往需要有集中式的數據彙總，而此種模式下用戶請求數據分散在各個Web服務器上。
方案B：反向代理模式
使用這種模式的方案需要修改DNS，讓域名解析到反向代理服務器。當用戶向某個域名發起請求時，請求會先經過反向代理進行檢測，檢測無問題之後再轉發給後端的Web服務器。這種模式下，反向代理除了能提供Web安全防護之外，還能充當抗DDoS攻擊，內容加速（CDN）等功能。雲安全廠商CloudFlare採用這種模式。
優點：
1、 集中式的流量出入口。可以針對性地進行大數據分析。
2、 部署方便。可多地部署，附帶提供CDN功能。
挑戰：
1、 動態的額外增加一層。會帶來用戶請求的網絡開銷等。
2、 站點和後端Web服務器較多的話，轉發規則等配置較複雜。
3、 流量都被捕捉，涉及到敏感數據保護問題，可能無法被接受。
方案C：硬件防護設備
這種模式下，硬件防護設備串在網絡鏈路中，所有的流量經過核心交換機引流到防護設備中，在防護設備中對請求進行檢測，合法的請求會把流量發送給Web服務器。當發現攻擊行爲時，會阻斷該請求，後端Web服務器無感知到任何請求。防護設備廠商如imperva等使用這種模式。
優點：
1、 對後端完全透明。
挑戰：
1、 部署需改變網絡架構，額外的硬件採購成本。
2、 如Web服務器分佈在多個IDC，需在多個IDC進行部署。
3、 流量一直在增加，需考慮大流量處理問題。以及流量自然增長後的升級維護成本。
4、 規則依賴於廠商，無法定製化，不夠靈活。
方案D：服務器模塊+檢測雲模式
這種模式其實是方案A的增強版，也會在Web服務器上實現安全模塊。不同點在於，安全模塊的邏輯非常簡單，只是充當橋樑的作用。檢測雲則承擔着所有的檢測發現任務。當安全模塊接收到用戶的請求時，會通過UDP或者TCP的方式，把用戶請求的HTTP文本封裝後，發送到檢測雲進行檢測。當檢測無問題時，告知安全模塊把請求交給CGI處理。當請求中檢測到攻擊特徵時，則檢測雲會告知安全模塊阻斷請求。這樣所有的邏輯、策略都在檢測雲端。
我們之所以選擇這個改進方案來實現防護系統，主要是出於以下幾個方面的考慮：
1、 維護問題
假如使用A方案，當面臨更新時，無法得到及時的響應。同時，由於安全邏輯是嵌入到Web服務器中的，任何變更都存在影響業務的風險，這是不能容忍的。
2、 網絡架構
如果使用方案B，則需要調動大量的流量，同時需要提供一個超大規模的統一接入集羣。而爲了用戶就近訪問提高訪問速度，接入集羣還需要在全國各地均有部署，對於安全團隊來說，成本和維護難度難以想象。
使用該方案時，需要考慮如下幾個主要的挑戰：
1、 網絡延時
採用把檢測邏輯均放在檢測雲的方式，相對於A來說，會增加一定的網絡開銷。不過，如果檢測雲放在內網裏，這個問題就不大，99%的情況下，同城內網發送和接收一個UDP包只需要1ms。
2、 性能問題：
由於是把全量流量均交給集中的檢測雲進行檢測，大規模的請求可能會帶來檢測雲性能的問題。這樣在實現的時候就需要設計一個好的後端架構，必須充分考慮到負載均衡，流量調度等問題。
3、 部署問題：
該方案依然需要業務進行1次部署，可能會涉及到重編譯web服務器等工作量，有一定的成本。並且當涉及到數千個域名時，問題變的更爲複雜。可能需要區分出高危業務來對部署有一個前後順序，並適時的通過一些事件來驅動部署。
關於代碼審計的方法主要有兩個大方向：（1）危險函數向上追蹤輸入；（2）追蹤用戶輸入是否進入危險函數；這裏的危險函數關於危險函數主要包括代碼執行相關：eval、assert，文件包含：include、require等，命令執行：system、exec等，寫文件：fwrite、file_put_contents等；
- 案例一：用戶輸入數據過濾邏輯不當
- 案例二：二次注入
- 案例三：程序升級新增邏輯導致的漏洞
- 案例四：漏洞修補不完善
1、一切輸入都是有害的；
後臺程序的用戶輸入相比前臺主要增加了後臺表單的數據，此外有些後臺支持上傳文件(如dz1.5的自定義sql)，上傳文件的內容也屬於輸入；這些輸入都屬於用戶範圍。一定要做嚴格的控制和過濾。
2、安全意識；
其實很多漏洞的產生並不是技術問題導致的，而是我們缺乏安全意識，不重視安全而釀成的慘劇。尤其是第三個和第四個，完全不應該發生；需要對開發人員做安全宣導和基本的安全培訓。
3、漏洞Review；
（1）開發人員收到漏洞後要對漏洞產生的原因做總結，並Review代碼中是否有類似的問題。有些時候開發人員僅僅是修補了安全人員或白帽子提供的漏洞點，另外一處代碼有類似的問題沒修補繼續爆出漏洞，無窮無盡。這樣做還會帶來更大的隱患，黑客是非常樂意並擅長總結反思的，每一個補丁其實也是給黑客拓展了思路，如果修補不完全後果很嚴重。
（2）開發人員修補完成後安全人員需要進行測試確認，上述的案例四就是鮮明的例子。有條件的情況下安全人員應該整理一些常見漏洞修復指引，這樣也可以提高工作效率。
國內一些廠商也開始研發自己Android App自動化審計系統，其中最早的對外發布的騰訊金剛審計系統算是國內這類產品的鼻祖之一，其早期版本在功能上實現了Android App自動化靜態分析與簡單的動態分析，審計點包括：明文保存敏感信息，文件權限問題，日誌信息泄露，組件權限問題，明文傳輸，拒絕服務等。
權限濫用漏洞一般歸類於邏輯問題，是指服務端功能開放過多或權限限制不嚴格，導致攻擊者可以通過直接或間接調用的方式達到攻擊效果。
安全產品的自我修養
- 架構設計與定位
- 嚴格遵守研發流程
- 投入專業運維團隊
- 數據運營與響應
- 產品化
- 策略運營
軟件漏洞分析技巧分享
- 技巧一：快速定位JS代碼調用的IE類成員函數
- 技巧二：通過頁堆快速定位堆漏洞代碼
- 技巧三：基於堆分配記錄定位整數溢出漏洞代碼
- 技巧四：基於條件記錄斷點的漏洞分析技巧
- 技巧五：基於JS日誌的漏洞分析技巧
- 技巧六：通過虛擬機快照來固定堆地址
- 技巧七：監控堆分配釋放動作來分析UAF、double free漏洞
- 技巧八：基於污點追蹤的分析方法
獨立+懷疑+渴望+打破+手癢
REFERENCE
1. 驅散前端安全夢魘——DOMXSS典型場景分析與修復指南
2. [騰訊安全應急響應中心] 基於QtWebKit的DOM XSS檢測技術
3. 未知攻焉知防——XXE漏洞攻防
4. TSRC挑戰賽：WAF之SQL注入防禦思路分享
5. 主流WAF架構分析與探索
6. WEB代碼審計與滲透測試
7. 315晚會報道的無人機是怎麼被劫持的？
8. 軟件漏洞分析技巧分享
9. 傅盛：深度學習是什麼？