• SQL註入

部分程序員在編寫代碼的時候，沒有對用戶輸入數據的合法性進行判斷，使應用程序存在安全隱患。用戶可以提交一段數據庫查詢代碼，根據程序返回的結果，獲得某些他想得知的數據，這就是所謂的SQL Injection，即SQL註入

案例

HTTP://xxx.xxx.xxx/abc.asp?p=YY

①HTTP://xxx.xxx.xxx/abc.asp?p=YY’(附加一個單引號), abc.asp運行異常,表示沒有對特殊字符進行轉義或過濾

②HTTP://xxx.xxx.xxx/abc.asp?p=YY and 1=1, abc.asp運行正常，而且與HTTP://xxx.xxx.xxx/abc.asp?p=YY運行結果相同；

③HTTP://xxx.xxx.xxx/abc.asp?p=YY and 1=2, abc.asp運行異常；

如果以上三步全面滿足，abc.asp中一定存在SQL註入漏洞。

攻擊步驟

1、  發現SQL註入位置；

2、  判斷後臺數據庫類型；

3、  確定XP_CMDSHELL可執行情況

4、  發現WEB虛擬目錄

5、  上傳木馬；

6、  得到管理員權限；

具體見：http://www.cnblogs.com/tanshuicai/archive/2010/02/03/1664900.html

常見的不安全寫法：

Statement s = connection.createStatement(); 

ResultSet rs = s.executeQuery("SELECT email FROM member WHERE name = " + formField);

安全寫法

PreparedStatement ps = connection.prepareStatement(

    "SELECT email FROM member WHERE name = ?"); 

ps.setString(1, formField);

ResultSet rs = ps.executeQuery();

如何防禦？

轉義？過濾？

避開過濾方法

1、大小寫變種

若小寫被過濾，則變成大寫繼續執行

http://bbs.ichunqiu.com/data/attachment/forum/201608/21/134905u36phck612j6kw3j.gif?_=5793686

2、URL編碼

雙url編碼可以繞過過濾

http://bbs.ichunqiu.com/data/attachment/forum/201608/21/143646fnygion74g9c8idi.gif?_=5793686

3、SQL註釋

很多開發人員認為，將輸入限制為單個就可以限制SQL註入攻擊，所以他們往往就只是阻止各種空白符，但是內聯註釋不使用空格就可以構造任意復雜的SQL語句。

http://bbs.ichunqiu.com/data/attachment/forum/201608/21/142321um0h0q5zefvhooqk.gif?_=5793686

防禦

輸入驗證是指要驗證所有應用程序接收到的輸入是否合法。

有兩中不同類型的輸入驗證方法：白名單和黑名單驗證

白名單驗證：比如id值，那麽我們判斷它是否為數字。

黑名單驗證：使用正則表達式禁止使用某些字符和字符串

應該盡量使用白名單，對於無法使用白名單的，使用黑名單提供局部限制。

• 跨站腳本（XSS）

跨站腳本（cross site script）為了避免與樣式css混淆，所以簡稱為XSS。

什麽是XSS？

XSS是指攻擊者利用網站沒有對用戶提交數據進行轉義處理或者過濾不足的缺點，進而添加一些代碼，嵌入到web頁面中去。使別的用戶訪問都會執行相應的嵌入代碼。從而盜取用戶資料、利用用戶身份進行某種動作或者對訪問者進行病毒侵害的一種攻擊方式。

反射型xss攻擊

一般會放在請求或者跳轉的鏈接中，一次性造成攻擊。，稱之為反射性XSS攻擊

例：頁面搜索框輸入"/><script>alert("這是一個反射型xss攻擊")</script>後點擊搜索，會提示提示框

存儲式XSS攻擊

一般是在提交表單式的請求中，註入XSS，存入服務器中，達到攻擊打開的用戶，影響所有看到的人。

例：新建用戶，描述中輸入"/><script>alert("這是一個存儲型xss攻擊")</script>

保存後，後面的用戶打開用戶管理頁面，查看到剛添加的用戶所在頁，都會彈出提示框

防禦

1. 前端在顯示服務端數據時候，不僅是標簽內容需要過濾、轉義，屬性值也可能需要。

1)     將重要的cookie標記為http only, 這樣的話Javascript 中的document.cookie語句就不能獲取到cookie了。

2)     表單數據規定值的類型，例如：年齡應為只能為int、name只能為字母數字組合。。。

3)     對數據進行Html Encode 處理

4)     過濾或移除特殊的Html標簽，例如: <script>, <iframe> , &lt; for <, &gt; for >, &quot for

5)     過濾javascript 事件的標簽。例如 "onclick=", "onfocus" 等等。

2. 後端接收請求時，驗證請求是否為攻擊請求，攻擊則屏蔽。

【特別註意】

在有些應用中是允許html標簽出現的，如輸出需要html代碼、javascript代碼拼接、或者此表單直接允許使用等等，需要區別處理。

• 跨站請求偽造（CSRF）

CSRF(Cross-site request forgery), 就是攻擊者盜用你的身份，以你的名義發送惡意請求。

攻擊原理

如圖所示，其中Web A為存在CSRF漏洞的網站，Web B為攻擊者構建的惡意網站，User C為Web A網站的合法用戶。

1、用戶C打開瀏覽器，訪問網站A，輸入用戶名和密碼請求登錄網站A;

2、在用戶信息通過驗證後，網站A產生Cookie信息並返回給瀏覽器，此時用戶登錄網站A成功，可以正常發送請求到網站A;

3、用戶未退出網站A之前，在同一瀏覽器中，打開一個TAB頁訪問網站B;

4、網站B接收到用戶請求後，返回一些攻擊性代碼，並發出一個請求要求訪問站點A;

5、瀏覽器在接收到這些攻擊性代碼後，根據網站B的請求，在用戶不知情的情況下攜帶Cookie信息，向網站A發出請求。網站A並不知道該請求其實是由B發起的，所以會根據用戶C的Cookie信息以C的權限處理該請求，導致來自網站B的惡意代碼被執行。

CSRF攻擊是源於WEB的隱式身份驗證機制！WEB的身份驗證機制雖然可以保證一個請求是來自於某個用戶的瀏覽器，但卻無法保證該請求是用戶批準發送的！

案例

銀行網站A，它以GET請求來完成銀行轉賬的操作，如：

http://www.mybank.com/Transfer.php?toBankId=11&money=1000

危險網站B，它裏面有一段HTML的代碼如下：

<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

首先，你登錄了銀行網站A，然後訪問危險網站B，這時你會發現你的銀行賬戶少了1000塊......

　　為什麽會這樣呢？原因是銀行網站A使用GET請求更新資源。在訪問危險網站B的之前，你已經登錄了銀行網站A，而B中的<img>以GET的方式請求第三方資源（這裏的第三方就是指銀行網站了，原本這是一個合法的請求，但這裏被不法分子利用了），所以你的瀏覽器會帶上你的銀行網站A的Cookie發出Get請求，去獲取資源“http://www.mybank.com/Transfer.php?toBankId=11&money=1000”，結果銀行網站服務器收到請求後，認為這是一個更新資源操作（轉賬操作），所以就立刻進行轉賬操作......

防禦

優先考慮的就是利用已有的CSRF防護方案。許多框架，如Spring, Play, Django以及AngularJS，都內嵌了CSRF防護，一些web開發語言如.Net也提供了類似的防護，OWASP CSRF Guard對Java應用提供了CSRF防護。否則需要在每個HTTP請求中添加一個不可預測的令牌，這種令牌至少應該對每一個用戶會話來說是唯一的。

1、  服務器端驗證HTTP Referer字段

根據HTTP協議，在HTTP頭中有一個字段叫Referer，記錄了該HTTP請求的來源地址。訪問一個安全受限頁面的請求必須來自於同一個網站。比如某銀行的轉賬是通過用戶訪問http://bank.test/test?page=10&userID=101&money=10000頁面完成，用戶必須先登錄bank.test，然後通過點擊頁面上的按鈕來觸發轉賬事件。當用戶提交請求時，該轉賬請求的Referer值就會是轉賬按鈕所在頁面的URL(本例中，通常是以bank. test域名開頭的地址)。而如果攻擊者要對銀行網站實施CSRF攻擊，他只能在自己的網站構造請求，當用戶通過攻擊者的網站發送請求到銀行時，該請求的Referer是指向攻擊者的網站。因此，要防禦CSRF攻擊，銀行網站只需要對於每一個轉賬請求驗證其Referer值，如果是以bank. test開頭的域名，則說明該請求是來自銀行網站自己的請求，是合法的。如果Referer是其他網站的話，就有可能是CSRF攻擊，則拒絕該請求。

2、  在請求地址中添加token並驗證或驗證碼

CSRF攻擊之所以能夠成功，是因為攻擊者可以偽造用戶的請求，該請求中所有的用戶驗證信息都存在於Cookie中，因此攻擊者可以在不知道這些驗證信息的情況下直接利用用戶自己的Cookie來通過安全驗證。由此可知，抵禦CSRF攻擊的關鍵在於：在請求中放入攻擊者所不能偽造的信息，並且該信息不存在於Cookie之中。鑒於此，系統開發者可以在HTTP請求中以參數的形式加入一個隨機產生的token，並在服務器端建立一個攔截器來驗證這個token，如果請求中沒有token或者token內容不正確，則認為可能是CSRF攻擊而拒絕該請求。

3、  考慮對所有cookie使用”SameSite”標簽，該標簽逐漸被各類瀏覽器所支持。

防止 CSRF 攻擊的辦法已經有 CSRF token 校驗和 Referer 請求頭校驗。為了從源頭上解決這個問題，Google 起草了 一份草案 來改進 HTTP 協議，那就是為 Set-Cookie 響應頭新增 SameSite 屬性，它用來標明這個 cookie 是個“同站 cookie”，同站 cookie 只能作為第一方 cookie，不能作為第三方 cookie。

參考：http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html

• 失效的認證和會話管理

身份認證

最常見的是登錄功能，往往是提交用戶名和密碼，在安全性要求更高的情況下，有防止密碼暴力破解的驗證碼，基於客戶端的證書，物理口令卡等。

會話管理

HTTP本身是無狀態的，利用會話管理機制來實現連接識別。

身份認證的結果往往是獲得一個令牌，通常放在cookie中，如jsessionid。之後對用戶身份的識別根據這個授權的令牌進行識別，而不需要每次都要登錄。

• 失效的認證和會話管理

開發者通常會建立自定義的認證和會話管理方案。但要正確實現這些方案卻很難，結果這些自定義的方案往往在如下方面存在漏洞：退出、密碼管理、超時、記住我、秘密問題、帳戶更新等等

案例

1、機票預訂應用程序支持URL重寫，把會話ID放在URL裏：

http://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?dest=Hawaii

該網站一個經過認證的用戶希望讓他朋友知道這個機票打折信息。他將上面鏈接通過郵件發給他朋友們，並不知道自己已經泄漏了自己的會話ID。當他的朋友們使用上面的鏈接時，他們將會使用他的會話和信用卡。

2、應用程序超時設置不當。用戶使用公共計算機訪問網站。離開時，該用戶沒有點擊退出，而是直接關閉瀏覽器。攻擊者在一個小時後能使用相同瀏覽器通過身份認證。鹽

3、攻擊者進入系統的數據庫。存儲在數據庫中的用戶密碼沒有被哈希和加鹽, 所有用戶的密碼都被攻擊者獲得。

如何驗證程序是否存在失效的認證和會話管理？

最需要要保護的數據是認證憑證(credentials) 和會話ID。

1、當存儲認證憑證時，是否總是使用hashing或加密保護嗎?

2、認證憑證是否可猜測，或者能夠通過薄弱的的帳戶管理功能（例如賬戶創建、密碼修改、密碼恢復, 弱會話ID）重寫？

3、會話ID是否暴露在URL裏(例如, URL重寫) ？

4、會話ID是否容易受到會話固定(session fixation) 的攻擊?

5、會話ID會超時嗎? 用戶能退出嗎?

6、成功註冊後,會話ID會輪轉嗎?

7、密碼、會話ID和其他認證憑據是否只通過TLS連接傳輸？

防禦

1、區分公共區域和受限區域

站點的公共區域允許任何用戶進行匿名訪問。受限區域只能接受特定用戶的訪問，而且用戶必須通過站點的身份驗證。

2、對最終用戶帳戶使用帳戶鎖定策略

當最終用戶帳戶幾次登錄嘗試失敗後，可以禁用該帳戶或將事件寫入日誌。　

3、支持密碼有效期

　　密碼不應固定不變，而應作為常規密碼維護的一部分，通過設置密碼有效期對密碼進行更改。在應用程序設計階段，應該考慮提供這種類型的功能。

4、能夠禁用或鎖定帳戶

如果在系統受到威脅時使憑證失效或禁用帳戶，則可以避免遭受進一步的攻擊。

5、不要在用戶存儲中存儲密碼

　　如果必須驗證密碼，則沒有必要實際存儲密碼。相反，可以存儲一個單向哈希值，然後使用用戶所提供的密碼重新計算哈希值。為減少對用戶存儲的詞典攻擊威脅，可以使用強密碼，並將隨機 salt 值與該密碼結合使用。

6、要求使用強密碼

　　要求輸入至少 8 位字符，其中要包含大寫字母、小寫字母、數字和特殊字符。無論是使用平臺實施密碼驗證還是開發自己的驗證策略，此步驟在對付粗暴攻擊時都是必需的。在粗暴攻擊中，攻擊者試圖通過系統的試錯法來破解密碼。使用常規表達式協助強密碼驗證。

7、不要在網絡上以純文本形式發送密碼

　　以純文本形式在網絡上發送的密碼容易被竊聽。應加密傳輸。

8、保護身份驗證 Cookie

　　身份驗證 cookie 被竊取意味著登錄被竊取。可以通過加密和安全的通信通道來保護驗證票證。另外，還應限制驗證票證的有效期，以防止因重復攻擊導致的欺騙威脅。

　　不要通過 HTTP 連接傳遞身份驗證 cookie。在授權 cookie 內設置安全的 cookie 屬性，以便指示瀏覽器只通過 HTTPS 連接向服務器傳回 cookie。

9、對身份驗證 cookie 的內容進行加密

　　即使使用 SSL，也要對 cookie 內容進行加密。如果攻擊者試圖利用XSS攻擊竊取 cookie，這種方法可以防止攻擊者查看和修改該 cookie。在這種情況下，攻擊者仍然可以使用 cookie 訪問應用程序，但只有當 cookie 有效時，才能訪問成功。

10、限制會話壽命

　　縮短會話壽命可以降低會話劫持和重復攻擊的風險。會話壽命越短，攻擊者捕獲會話 cookie 並利用它訪問應用程序的時間越有限。

• 失效的訪問控制

當生成web頁面時，數據、應用程序和APIs經常使用對象的實名或關鍵字。功能、URLs和函數名稱經常容易被猜解。而應用程序和APIs並不總是驗證用戶對目標資源的訪問授權，如普通用戶可以訪問管理員的頁面，這就導致了訪問控制失效。測試者能輕易操作參數值以檢測該漏洞。代碼分析能很快顯示應用程序是否進行了正確的權限驗證。

攻擊

猜一些頁面的url，進行攻擊。

案例

管理員頁面並沒有菜單管理的權限，但是卻可以在瀏覽器中輸入菜單管理的url:menu來訪問菜單管理頁面

防禦

1、檢查訪問。任何來自不可信源的直接對象引用都必須通過訪問控制檢測，確保該用戶對請求的對象有訪問權限。

2、使用基於用戶或者會話的間接對象引用。這樣能防止攻擊者直接攻擊未授權資源。例如，一個下拉列表包含6個授權給當前用戶的資源，它可以使用數字1-6來指示哪個是用戶選擇的值，而不是使用資源的數據庫關鍵字來表示。OWASP的ESAPI包含了兩種序列和隨機訪問引用映射，開發人員可以用來消除直接對象引用。

3、自動化驗證。利用自動化驗證正確的授權部署。這是通常做法。

• 安全配置錯誤

沒有正確的安全配置，導致外部的匿名攻擊者和擁有帳戶的內部用戶都可能會試圖破壞系統

攻擊

攻擊者訪問默認賬戶，無效頁面，沒打補丁的漏洞，未受保護的文件及文件夾等，以獲得未授權的訪問或對應用系統進行了解和分析。

案例

1、服務器管理員控制臺自動安裝後沒有被刪除。而默認帳戶也沒有被改變。攻擊者在你的服務器上發現了標準的管理員頁面，通過默認密碼登錄，從而接管了你的服務器。

2、目錄列表在你的服務器上未被禁用。攻擊者發現只需列出目錄，她就可以找到你服務器上的任意文件。攻擊者找到並下載所有已編譯的Java類，通過反編譯獲得了所有你的自定義代碼。然後，她在你的應用程序中找到一個訪問控制的嚴重漏洞。

3、應用服務器配置允許堆棧跟蹤信息返回給用戶，這樣就暴露了潛在的漏洞。如已知的有漏洞的框架版本。

4、應用服務器自帶的示例應用程序沒有從您的生產服務器中刪除。該示例應用有已知安全漏洞，攻擊者可以利用這些漏洞破壞您的服務器。

防禦

1、 配置所有的安全機制

2、 關掉所有不使用的服務和服務器上的示例應用程序

3、 設置角色帳號權限

4、 使用日誌和警報

5、 所有錯誤只顯示友好信息，不顯示任何與實際錯誤相關的信息

6、 及時更新服務器補丁

• 敏感信息泄漏

攻擊

通過SQL註入或命令執行或直接使用腳本進行爬蟲，來獲得用戶的賬號密碼、實名信息泄露、行為記錄等

防禦

1、預測一些威脅（比如內部攻擊和外部用戶），加密這些數據的存儲以確保免受這些威脅。

2、對於沒必要存放的、重要的敏感數據，應當盡快清除。

3、確保使用了合適的強大的標準算法和強大的密匙，並且密匙管理到位。

4、確保使用密碼專用算法存儲密碼

5、禁用自動完成防止敏感數據收集，禁用包含敏感數據的緩存頁面。

6、加密傳輸

7、使用安全的加密算法

文章來源：