由於開發的項目部署在公網，甲方安排了人員對項目進行等級保護測評，以確保項目在公網運行的安全性,下面整理了一些
常用的安全問題，以及項目中的安全問題.
1.配置tomcat全局錯誤
先看下apache 默認的tomcat如何處理
(1.1)如果訪問的路徑不存在 ，tomcat是這樣報錯的
(2.1)如果請求的servlet發生異常，並且沒有捕獲，直接拋出給了servlet，比如最常見的空指針異常，下面爲我
手動製造了
一個空指針異常，當我們訪問該controller時
這。。 tomca把報錯信息都顯示在瀏覽器了，調用棧信息暴露了該controller整個的的請求過程
(3.1)下面把我修復的方法發一下，配置tomcat全局錯誤處理頁面，常見的404，500，拋出exception時的配置
找到tomcat的 web.xml文件 增加配置
<!--全局錯誤配置 begin -->
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/errorPage/error_exception.html</location>
</error-page>
<error-page>
<error-code>404</error-code>
<location>/errorPage/error_404.html</location>
</error-page>
<error-page>
<error-code>400</error-code>
<location>/errorPage/error_400.html</location>
</error-page>
<error-page>
<error-code>500</error-code>
<location>/errorPage/error_500.html</location>
</error-page>
<!--end -->
(4.1)把報錯頁面加入到webapps ROOT目錄裏,還有每個項目的根目錄都需要加上報錯頁面，比如我tomcat裏部署了2個程序，
那麼我這2個程序的項目根目錄下也要加上報錯頁面，tomcat會去相應訪問路徑下找相應的報錯頁面，不知道有沒全局的目錄，不用每個項目都加，有的話大家指教下。
(5.1)如果只是tomcat的web.xml配置了全局錯誤處理頁面，但是沒放入相應的處理頁面，也比不配置好，
tomcat處理全局錯誤時找不到相應的頁面，統一報錯如下
2.刪除tomcat自帶的項目等，生產環境不通過manager管理項目
(2.1)
3.隱私文件必須放到WEB-INF下
(3.1)因爲非WEB-INF下的文件可以直接訪問，隱私文件必須注意放在WEB-INF下。前端需要讀取隱私資源文件可使用servlet獲取,servler中可做安全認證。
4.sql注入
(4.1)where條件如果採用拼接sql方式後果
比如以下sql，我並不知道 zjhm和dlmm，或者我只知道某人的身份證號，不知道密碼
但是我如果我進行sql注入 ，輸入 1' or '1'='1 而程序又沒攔截，那麼sql最終會把整張表查詢出來，
如果該sql是返回查詢列表，不說數據泄露的的後果，如果該表數據千萬級，億萬級，連續執行幾次數據庫IO消耗不過來，整個系統也要癱瘓.
如果是update delete語句 where條件sql注入的後果就是整張表數據被更新，或者整張表被刪，是不是gg了，(┬＿┬)
(4.1)insert數據入庫，如果sql注入，比如寫入javasvript語句，如果前端直接查詢出內容讓HTML解釋了，盜取cookie，添加病毒腳本等風險都有，由於這方面我也沒去深入研究，總之增刪改查語句都需要防止sql注入，
sql注入我一般採用後臺對參數正則表達式驗證是否存在惡意字符，驗證通過後sql也使用預編譯語句，這樣保險點
5.越權攻擊
(5.1)水平越權
水平越權指的是同權限的A登錄後訪問B才能訪問的資源，舉個例子報告查詢網站中A登錄後查詢自己的報告，抓包發現該查詢服務如下
http://ip:port/getReport?id=1
id=1爲表示A的報告，於是他把id改成2，而剛好id=2是B用戶的報告，由於getReport服務中未進行權限然認證，可能只進行了登錄認證，這就導出A訪問到了B的查詢報告，這樣的後果A登錄後通過id爆破直接抓取了所有的報告。
(5.2)縱向越權
縱向越權指的是A訪問到了A沒有權限訪問的服務
舉個我在項目上出現過的漏洞，用戶註冊需要發送手機短信，數據提交時我分2步驗證，先判斷驗證碼是否正確，正確的話執行提交服務，而攻擊者得知後直接使用http請求調試等工具調用提交服務，直接跳過了短信驗證這一步，正常情況他點擊提交按鈕肯定要執行我的邏輯，但是要記住是我們在前端做的任何邏輯驗證，比如表單數據是否合法等，最終都要請求服務，攻擊者完全可以跳過邏輯直接請求服務。
用戶註冊，修改等需要短信驗證的功能，正確的做法是在提交服務裏執行短信驗證，數據驗證，通過後在執行其他業務.
由於寫的時候沒準備，其他需要注意的地方也很多，上面寫個幾個典型的的