OWASP TOP 10 (2013)

1. 注入

注入攻擊漏洞，例如SQL，OS 以及LDAP注入。這些攻擊發生在當不可信的資料作為指令或者查詢語句的一部分，被發送給解釋器的時候。攻擊者發送的惡意資料可以欺騙解釋器，以執行計劃外的指令或者在未被恰當授權時通路資料。

2. 失效的身份認證和會話管理

身份認證:

最常見的是登入功能,往往是送出使用者名和密碼,在安全性要求更高得情況下,有防止密碼暴力破解的驗證碼,基于使用者端的證書,實體密碼卡等

會話管理:

HTTP本身是無狀态的,利用會話管理機制來實作連接配接識别.身份認證的結果往往是獲得一個令牌,通常放在cookie中,之後對使用者身份的識别根據這個授權的令牌進行識别,而不需要每次都要登入.

失效的身份認證和會話管理:

與身份認證和會話管理相關的應用程式功能往往得不到正确的實作，這就導緻了攻擊者破壞密碼、密匙、會話令牌或攻擊其他的漏洞去冒充其他使用者的身份。

1. 使用者更改密碼之前不需要驗證,而是依靠會話的ip位址
2. 沒有會話逾時限制
3. 密碼找回功能過于簡單
4. session放在URL中

3. 跨站腳本攻擊 (Xss)

當應用程式收到含有不可信的資料，在沒有進行适當的驗證和轉義的情況下，就将它發送給一個網頁浏覽器，這就會産生跨站腳本攻擊（簡稱XSS）。XSS允許攻擊者在受害者的浏覽器上執行腳本，進而劫持使用者會話、危害網站、或者将使用者轉向至惡意網站。

4. 不安全的直接對象引用

指一個已經授權的使用者，通過更改通路時的一個參數，進而通路到了原本其并沒有得到授權的對象。

當開發人員暴露一個對内部實作對象的引用時，例如，一個檔案、目錄或者資料庫密匙，就會産生一個不安全的直接對象引用。在沒有通路控制檢測或其他保護時，攻擊者會操控這些引用去通路未授權資料。

不安全的直接對象引用執行個體

某網站的新聞檢索功能可搜尋指定日期的新聞，但其傳回的URL中包含了指定日期新聞頁面的檔案名：

http://example.test/online/news.asp?item=28Jan2016.html。

攻擊者可以嘗試不同的目錄層次來獲得系統檔案win.ini，例如，

http://example.test/ online/news.asp? item=../../ winnt/win.ini。

防禦措施

1. 避免在URL或網頁中直接引用内部檔案名或資料庫關鍵字。
2. 可使用自定義的映射名稱來取代直接對象名，例如， http://example.test/online/news.asp?item=0245等
3. 鎖定網站伺服器上的所有目錄和檔案夾，設定通路權限。
4. 驗證使用者輸入和URL請求，拒絕包含./或../的請求。

5. 安全配置錯誤

好的安全需要對應用程式、架構、應用程式伺服器、web伺服器、資料庫伺服器和平台定義和執行安全配置。由于許多設定的預設值并不是安全的，是以，必須定義、實施和維護這些設定。這包含了對所有的軟體保持及時地更新，包括所有應用程式的庫檔案。

安全配置錯誤執行個體

資料庫的帳号是不是預設為“admin”，密碼（還有端口号）是不是直接寫在配置檔案裡而沒有進行加密，這些都是屬于安全配置錯誤，會對應用的安全問題造成威脅。

防禦措施

1. 配置所有的安全機制
2. 關掉所有不使用的服務
3. 設定角色權限帳号
4. 使用日志和警報
5. 所有錯誤隻顯示友好資訊，不顯示任何與實際錯誤相關的資訊

6. 敏感資訊洩露

許多Web應用程式沒有正確定護敏感資料，如信用卡，稅務ID和身份驗證憑據。攻擊者可能會竊取或篡改這些弱保護的資料以進行信用卡詐騙、身份竊取，或其他犯罪。敏感資料值需額外的保護，比如在存放或在傳輸過程中的加密，以及在與浏覽器交換時進行特殊的預防措施。

執行個體

1. 一個應用程式加密存儲在資料庫的信用卡資訊，以防止信用卡資訊暴露給最終使用者。但是，資料庫設定為對信用卡表列的查詢進行自動解密，這就使得SQL注入漏洞能夠獲得所有信用卡資訊的明文。該系統應該被設定為前端應用程式使用公鑰對信用卡資訊加密，後端應用程式隻能使用私鑰解密。
2. 一個網站上所有需要身份驗證的網頁都沒有使用SSL。攻擊者隻需監控網絡資料流（比如一個開放的無線網絡或其社群的有線網絡），并竊取一個已驗證的受害者的會話cookie。然後，攻擊者利用這個cookie執行重播攻擊并接管使用者的會話進而通路使用者的隐私資料。
3. 密碼資料庫使用unsalted的雜湊演算法去存儲每個人的密碼。一個檔案上傳漏洞使黑客能夠擷取密碼檔案。所有這些unsalted哈希的密碼通過彩虹表暴力破解方式破解。

7.功能級通路控制缺失

大多數Web應用程式在功能在UI中可見以前，驗證功能級别的通路權限。但是，應用程式需要在每個功能被通路時在伺服器端執行相同的通路控制檢查。如果請求沒有被驗證，攻擊者能夠僞造請求以在未經适當授權時通路功能。

執行個體

1. 攻擊者僅僅直接浏覽目标網址。例如下面的兩個網址都需要身份驗證。同時問“admin_getappInfo”頁面還需要管理者權限。

   http://example.com/app/getappInfo

   http://example.com/app/admin_getappInfo

   如果未認證的使用者可以通路上述任一頁面，這就是漏洞。如果通過驗證的非管理者使用者也能允許通路“admin_getappInfo”頁面，這同樣是個漏洞。這個漏洞可能會将攻擊者引向更多保護不當的管理頁面。
2. 一個頁面提供了“action”參數給某個特定的功能調用，并且不同的操作需要不同的角色。如果沒有進行角色檢查，這也是漏洞。

解決方法

對一些需要權限才可以通路的目錄、網頁等做相應的驗證處理，保證隻有合法使用者才可以通路，沒有權限的使用者給出相應的友好提示，提示資訊也應當注意不能出現任何包含權限等資訊的内容。

8. 跨站請求僞造 (CSRF)

一個跨站請求僞造攻擊迫使登入使用者的浏覽器将僞造的HTTP請求，包括該使用者的會話cookie和其他認證資訊，發送到一個存在漏洞的web應用程式。這就允許了攻擊者迫使使用者浏覽器向存在漏洞的應用程式發送請求，而這些請求會被應用程式認為是使用者的合法請求。

9. 使用含有已知漏洞的元件

元件，比如：庫檔案、架構和其它軟體子產品，幾乎總是以全部的權限運作。如果一個帶有漏洞的元件被利用，這種攻擊可以造成更為嚴重的資料丢失或伺服器接管。應用程式使用帶有已知漏洞的元件會破壞應用程式防禦系統，并使一系列可能的攻擊和影響成為可能。

解決措施

盡量使用比較安全的元件，另外，對于元件的接口的安全性等也需要測試.

10. 未驗證的重定向和轉發

重定向和轉發的差別

解釋一

一句話，轉發是伺服器行為，重定向是用戶端行為。為什麼這樣說呢，這就要看兩個動作的工作流程：

轉發過程：客戶浏覽器發送http請求——》web伺服器接受此請求——》調用内部的一個方法在容器内部完成請求處理和轉發動作——》将目标資源發送給客戶；在這裡，轉發的路徑必須是同一個web容器下的url，其不能轉向到其他的web路徑上去，中間傳遞的是自己的容器内的request。在客戶浏覽器路徑欄顯示的仍然是其第一次通路的路徑，也就是說客戶是感覺不到伺服器做了轉發的。轉發行為是浏覽器隻做了一次通路請求。

重定向過程：客戶浏覽器發送http請求——》web伺服器接受後發送302狀态碼響應及對應新的location給客戶浏覽器——》客戶浏覽器發現是302響應，則自動再發送一個新的http請求，請求url是新的location位址——》伺服器根據此請求尋找資源并發送給客戶。在這裡location可以重定向到任意URL，既然是浏覽器重新發出了請求，則就沒有什麼request傳遞的概念了。在客戶浏覽器路徑欄顯示的是其重定向的路徑，客戶可以觀察到位址的變化的。重定向行為是浏覽器做了至少兩次的通路請求的。

解釋二

重定向，其實是兩次request

第一次，用戶端request A,伺服器響應，并response回來，告訴浏覽器，你應該去B。這個時候IE可以看到位址變了，而且曆史的回退按鈕也亮了。重定向可以通路自己web應用以外的資源。在重定向的過程中，傳輸的資訊會被丢失。

例子：

response.sendRedirect(“loginsuccess.jsp”);

請求轉發是伺服器内部把對一個request/response的處理權，移交給另外一個

對于用戶端而言，它隻知道自己最早請求的那個A，而不知道中間的B，甚至C、D。傳輸的資訊不會丢失。

例子：

RequestDispatcher dis=request.getRequestDispatcher(“loginsuccess.jsp”);

Dis.forward(request,response);

解釋三

假設你去辦理某個執照

重定向：你先去了A局，A局的人說：“這個事情不歸我們管，去B局”，然後，你就從A退了出來，自己乘車去了B局。

轉發：你先去了A局，A局看了以後，知道這個事情其實應該B局來管，但是他沒有把你退回來，而是讓你坐一會兒，自己到後面辦公室聯系了B的人，讓他們辦好後，送了過來。

重定向:重定向是服務端根據邏輯,發送一個狀态碼,告訴浏覽器重新去請求那個位址.是以位址欄顯示的是新的URL。（重定向是在用戶端完成的）

轉發:轉發是伺服器請求資源,伺服器直接通路目标位址的URL,把那個URL的響應内容讀取過來,然後把這些内容再發給浏覽器.浏覽器根本不知道伺服器發送的内容從哪裡來的,因為這個跳轉過程實在伺服器實作的，并不是在用戶端實作的是以用戶端并不知道這個跳轉動作，是以它的位址欄還是原來的位址。（轉發是在伺服器端完成的）

未驗證的重定向和轉發的概念

Web應用程式經常将使用者重定向和轉發到其他網頁和網站，并且利用不可信的資料去判定目的頁面。如果沒有得到适當驗證，攻擊者可以重定向受害使用者到釣魚軟體或惡意網站，或者使用轉發去通路未授權的頁面。

在Web應用中重定向是非常普遍的，并且通常情況下，重定向所引向的目的是帶有使用者輸入參數的目的URL，而如果這些重定向未被驗證，而攻擊者就可以引導使用者通路他們所要使用者通路的站點。

轉發也是極為普遍的，本質上轉發是在同一個應用中對一個新頁面發送請求，并且有時候是用參數來定義目标頁面的。同樣，如果參數未被驗證，那麼攻擊者就可以通過其來繞過認證或是授權檢查。

執行個體

1. 應用程式有一個名為“redirect.jsp”的頁面，該頁面有一個參數名是“url”。攻擊者精心制作一個惡意URL将使用者重定向到一個惡意網站，執行釣魚攻擊并安裝惡意程式。

   http://www.example.com/redirect.jsp?url=evil.com

2. 應用程式使用轉發在網站的不同部分之間發送請求。為了幫助實作這一功能，如果一個交易成功了的話，一些網頁就會發送一個參數給使用者，用于指定使用者的下一個頁面。在這種情況下,攻擊者制作一個URL, 用于繞過應用程式的通路控制檢查,并将他轉發給一個他通常不能通路的管理功能。

   http://www.example.com/boring.jsp?fwd=admin.jsp

防禦措施

1. 盡量避免使用重定向和轉發機制，如果使用了，那麼在定義目标URL的時候不要包含使用者參數。
2. 如果一定要保護使用者輸入的參數，那麼: 對每個參數都必須進行驗證以確定它的合法性和正确性，或是在服務端提供映射機制，将使用者的選擇參數轉變為真正的白名單目标頁面。