1 明文密碼傳輸，解決辦法：https

2 XSS，攻擊方式：在提交的表單中寫入javascript指令碼。解決辦法：頁面顯示時，對特殊符號進行轉換，如

顯示結果	描述	實體名稱	實體編號
空格	 	 
<	小於號	&lt;	&#60;
>	大於號	&gt;	&#62;
&	和號	&amp;	&#38;
"	引號	&quot;	&#34;
'	撇號	&apos; (IE不支援)	&#39;

或者用JSTL標籤<c:out>進行輸出，它會自動進行轉換。

3 MHTML協議程式碼執行漏洞MS11-026

參考 https://zhuanlan.zhihu.com/p/27664793

解決辦法：對Base64編碼後的XSS攻擊也要防

4 CSRF，攻擊方式：惡意網站偽造使用者向正常網站提交表單。解決辦法：第1種方法，在表單中增加偽隨機數，服務端進行驗證；第2種方法，HTTP頭的"Referer"檢查，看是否本網站頁面傳送的請求

5 SQL注入，攻擊方式：表單中插入SQL指令碼。解決辦法：方法1，表單資料過濾掉SQL命令關鍵字；方法2，用preparestatme組織SQL JDBC查詢

6 會話標識未更新：解決辦法： request.getSession().invalidate();//清空session
Cookie cookie = request.getCookies()[0];//獲取cookie
cookie.setMaxAge(0);//讓cookie過期
  IBM對AppScn SQL盲注誤報的說明
http://www-01.ibm.com/support/docview.wss?uid=swg21674465
大意是：

造成AppScan“SQL盲注”誤報的常見原因

原因：
和SQL注入不同，SQL盲注只是用近似的、但邏輯相反的SQL字串，輸入到被注入的應用，如果得到伺服器的響應不同，就作為證明。
結果，SQL盲注更易造成誤報。因為在響應中，很多因素如：伺服器負載、狀態也可能導致不同的反應。
AppScan本身也會造成伺服器超載，因為它可能會在短時間內傳送數千或數百萬計的請求。

答案：
若要驗證是否真的存在SQL盲注，可以按以下幾步（建議參考1和4）：
1 總是對發現點進行單獨的重新掃描，確保伺服器是在最低負荷下。如果是誤報，這裡的檢查將不再會報SQL盲注
2 如果目標應用需要登入...
3 ...
4 分析步驟1得到的HTTP響應。如果目標頁面相對較小且有一些動態元素嵌入在響應中，AppScan判斷SQL盲注的閥值“95%匹配”可能偏高，需要調低