web.xml文件中的7個錯誤的安全配置

關於Java的web.xml文件中配置認證和受權有大 量 的 文章。本文再也不去從新講解如何配置角色、保護web資源和設置不一樣類型的認證，讓咱們來看看web.xml文件中的一些常見的安全錯誤配置。

(1) 自定義的錯誤頁面沒有配置

默認狀況下，Java Web應用在發生錯誤時會將詳細的錯誤信息展現出來，這將暴露服務器版本和詳細的堆棧信息，在有些狀況下，甚至會顯示Java代碼的代碼片斷。這些信息對爲他們的病毒需找更多信息的黑客來講是一種恩惠。幸運的是，經過配置web.xml文件來展現自定義的錯誤頁面是很是容易的。使用以下的配置後不管服務器在任什麼時候候發生HTTP500錯誤，一個很是好的錯誤頁面就會被顯示出來。你能夠爲HTTP狀態碼添加另外的錯誤頁面。

1 2 3 4

< error-page >          < error-softwaresecurity >500</ error-softwaresecurity >          < location >/path/to/error.jsp</ location > </ error-page >

另外，web.xml文件應該被配置以防止詳細的錯誤堆棧信息被顯示出來，咱們能夠經過配置<exception-type>來實現。由於Throwable是Java中全部Exception和Error的基類，下面的代碼片斷將很好的確保堆棧信息不被服務器顯示。

 

1 2 3 4

< error-page >          < exception-type >java.lang.Throwable</ exception-type >          < location >/path/to/error.jsp</ location > </ error-page >

然而，若是你採用以下的處理方式，你依然會將堆棧信息展現出來：

<%
try {
        String s = null;
        s.length();
} catch (Exception e) {
        // don't do this!
        e.printStackTrace(new PrintWriter(out));
}
%>

這裏請記住在合理配置了你的web.xml文件後，須要使用合理的日誌記錄技巧。

(2)繞過認證和受權

下面的代碼片斷展現瞭如何設置基於web的訪問控制以便全部在」安全」目錄中的一切只能被帶有」admin」角色的用戶訪問。

1 2 3 4 5 6 7 8 9 10 11

< security-constraint >          < web-resource-collection >                  < web-resource-name >secure</ web-resource-name >                  < url-pattern >/secure/*</ url-pattern >                  < http-method >GET</ http-method >                  < http-method >POST</ http-method >          </ web-resource-collection >          < auth-constraint >                  < role-name >admin</ role-name >          </ auth-constraint > </ security-constraint >

從常識觀點來看，指定了GET和POST的<http-method>元素限定了*只有*GET和POST請求是被容許的。事實上不是這樣，任意未列舉的HTTP方法實際上都是容許使用的，即採用其餘的HTTP方法能夠繞過認證和受權。Arshan Dabirsiaghi有一個很是好的論文總結了該問題並向你展現瞭如何使用上述配置中未列舉的任意的HTTP動詞（像HEAD）和徹底假冒的動詞（像TEST或JUNK）來繞過web.xml中配置的認證和受權保護。

幸運的是，解決方案很是簡單。僅僅須要從web.xml文件中移除<http-method>元素便可。

（3）SSL未配置

在全部使用敏感數據的應用中，SSL都應該被配置以保護數據傳輸安全。固然你能夠在web服務器上配置SSL，可是一旦你的應用服務器設置了合適的SSL key，那麼在應用急啓用SSL是很是容易的。

1 2 3 4 5 6

< security-constraint > ...          < user-data-constraint >                  < transport-guarantee >CONFIDENTIAL</ transport-guarantee >          </ user-data-constraint > </ security-constraint >

(4)未使用安全標示

不少web站點使用SSL進行認證，可是後面或者是阻止非SSL的的後續交互或者使得一部分網站內容仍然能夠經過非SSL的訪問。這使得會話的cookie（也就是JSESSIONID）容易受到session劫持攻擊。要阻止它，cookie能夠經過添加安全標誌來建立，這確保了瀏覽器將不會在非SSL環境下傳遞cookie。

在Servlet規範的舊版本中，沒有標準的方式來將JSESSIONID定義爲安全的。如今在Servlet3.0中，<cookie-config>元素能夠用於確保這個。

1 2 3 4 5

< session-config >          < cookie-config >                  < secure >true</ secure >          </ cookie-config > </ session-config >

（5）未使用HttpOnly標誌

cookie可使用HttpOnly標誌建立，這將確保cookie不能被客戶端腳本訪問。這幫助減輕了一些常見的XSS攻擊。就像Security標誌同樣，舊版本的Servlet規範沒有提供相應的支持。在Servlet3.0中能夠以下的配置它：

1 2 3 4 5

< session-config >          < cookie-config >                  < http-only >true</ http-only >           </ cookie-config > </ session-config >

除了Servlet3.0的這種新的標準的方式，舊版本的Tomcat容許在server.xml中使用供應商特定的useHttpOnly屬性來啓用它。該屬性在Tomcat5.5和6中默認是禁用的。在Tomcat7中，該屬性默認是啓用的。所以即便你在web.xml中將其設置爲false，而後部署在tomcat7中，除非你修改了server.xml文件，不然你的JSESSIONID依然是HttpOnly的。

（6） 使用URL參數來跟蹤session

Servlet3.0規範中的<tracking-mode>容許你定義JSESSIONID是存儲在cookie中仍是URL參數中。若是會話ID存儲在URL中，那麼它可能會被無心的存儲在多個地方，包括瀏覽器歷史、代理服務器日誌、引用日誌和web日誌等。暴露了會話ID使得網站被session劫持攻擊的概率大增。然而，確保JSESSIONID被存儲在cookie中很是容易：

1 2 3

< session-config >          < tracking-mode >COOKIE</ tracking-mode >  </ session-config >

（7） 未設置會話超時時間

用戶喜歡長時間的會話由於他們很方便。黑客喜歡長時間的會話由於他們有足夠的時間來實施像session劫持攻擊等。安全和可用性老是會出現衝突。一旦你知道如何使得你的會話存活，你能夠按以下方法來配置活動時間：

1 2 3

< session-config >          < session-timeout >15</ session-timeout >  </ session-config >

總結

構建和部署安全的應用須要從不一樣的受益人處獲取需求。環境和配置和編碼自身同樣重要。經過思考這些常見的安全錯誤配置，但願你能夠建立更加安全的應用。