一、SQL注入漏洞

漏洞說明

SQL注入攻擊是Web安全領域中一種最為常見的攻擊方式，其本質是將用戶輸入的資料當做SQL陳述句代碼一部分執行，這些攻擊通常是發生在將不可信的資料作為命令或查詢陳述句的一部分，拼接到程式代碼中，作為可執行程式的一部分指令執行，從而執行了計劃外的命令，或訪問了未被授權的資料，要解決注入攻擊，必須遵循 “資料與代碼分離”的基本原則，

解決方案

1．對SQL呼叫，要求所有的SQL陳述句及存盤程序的執行，都使用預編譯陳述句系結變數，禁止將引數通過字串拼裝的方式組合到SQL陳述句中，

2.變數在傳入SQL執行之前需要通過資料校驗，

3.必須將所有SQL拼裝引數，不能有1=1或是value ='" + value + "'"等之類的代碼，

二、跨站腳本攻擊（跨站點腳本編制）

漏洞說明

跨站腳本攻擊，英文全稱Cross Site Script，簡稱XSS，是指通過HTML注入，篡改了網頁，插入了惡意腳本，從而在用戶瀏覽網頁時，控制用戶瀏覽器的一種攻擊，

XSS攻擊通常指的是通過利用網頁開發時留下的漏洞，通過巧妙的方法注入惡意指令代碼到網頁，使用戶加載并執行攻擊者惡意制造的網頁程式，這些惡意網頁程式通常是JavaScript，但實際上也可以包括Java， VBScript， ActiveX， Flash 或者甚至是普通的HTML，攻擊成功后，攻擊者可能得到包括但不限于更高的權限（如執行一些操作）、私密網頁內容、會話和cookie等各種內容，

XSS攻擊型別可分為：

• 反射型XSS：只是簡單的把用戶輸入的資料“反射”給瀏覽器，需要用戶點擊過一個惡意鏈接后才能攻擊成功，所有的代碼及攻擊都是在客戶端完成，也稱為“非持久型XSS”，
• 存盤型XSS：把惡意代碼腳本存盤在服務端，當用戶訪問系統時，在瀏覽器中生成并執行惡意代碼，也稱為“持久型XSS”，
• DMO Based XSS：通過修改頁面的DOM節點形成的XSS，

XSS其本質是一種“HTML”注入技術，用戶輸入的資料被當做了HTML代碼的一部分被執行，從而使代碼原來的意圖發生變化，XSS攻擊都是發生在View層，因此僅僅對用戶提交的資料進行檢查還不能完全解決問題，

由于可能引起XSS的漏洞很多，要防范XSS攻擊，必須在開發階段就從服務端、客戶端、輸入、輸出等多個方面入手解決，

解決方案

1.對所有頁面，統一設定UTF-8字符集編碼：

<meta http-equiv="content-type" content="text/html;charset=UTF-8" />

2.對特殊字符的過濾：

通過實作filter過濾器的方式處理一些敏感的、非法字符和關鍵字，并且需要在服務端的代碼中實作對用戶輸入的校驗，輸入校驗必須實作對以下特殊字符的校驗或是編碼轉義：

3.會話Cookie中缺少httponly屬性，會話cookie中缺少HttpOnly屬性會導致攻擊者可以通程序式(JS腳本、Applet等)獲取到用戶的Cookie資訊，造成用戶Cookie資訊泄露，增加攻擊者的跨站腳本攻擊威脅，

解決辦法：

1）需要先確定現場應用服務器weblogic版本是否為9.2.3以上版本，才會對以下增加的內容生效，

2）對SessionID，在web/WEB-INF目錄下增加weblogic.xml檔案，如果已經存在此檔案，將SessionID的Cookie增加HttpOnly屬性，如下配置：

<session-descriptor>
<cookie-http-only>false</cookie-http-only> ---為增加內容
</session-descriptor>

需要重啟應用服務器

4.對自定義Cookie，在J2EE中，為Cookie添加HttpOnly的代碼如下：response.setHeader(“Set-Cookie”,”name=value;HTTPOnly”);

5. 將代碼輸出到客戶端時，按照變數輸出位置的不同，分別采用不同的編碼方式對輸出變數值進行編碼，

• 在HTML標簽中輸入變數時，先將變數HtmlEncode
• 在HTML屬性中輸出變數時，先將變數HtmlEncode
• 在<script>標簽中輸出變數時，先將變數JavascriptEncode
• 在HTML事件中輸出變數時，先將變數JavascriptEncode

三、加密會話（SSL）Cookie 中缺少 Secure 屬性

漏洞說明

服務器開啟了HTTPS時，Cookie的Secure屬性未設定true，

解決方案

1.修改app/web/WEB-INF/weblogic.xml[Y1] 檔案，其增加：

<session-descriptor>

<cookie-secure >true</cookie-secure >

</session-descriptor>

需要重啟應用服務器

2.后端對Cookie進行設定：cookie.Secure = true：

HttpServletResponse response = (HttpServletResponse)response; var cookie = new HttpCookie(key, value);

cookie.HttpOnly = true;

cookie.Path = "/";

cookie.Secure = true;

response.AppendCookie(cookie);

四、已解密的登陸請求

漏洞說明

嚴重性：高

型別：應用層漏洞

安全風險：敏感資料沒有通過https協議請求，導致可能會竊取用戶名、用戶密碼等未經加密就發送了用戶登陸的資訊，

解決方案

1.通過SSL傳輸密碼，需要實作HTTPS協議傳輸資料，可以通過平臺提供的配置功能，將對應的URL配置為通過HTTS訪問，配置如下：

修改app\web\WEB-INF\config目錄下的pt-filter-manager.xml 檔案在paramtername=“enterHttpsURLs”節點的value屬性中增加需要通過https訪問的頁面路徑，

2.對密碼進行加密傳輸，密碼必須以不可逆的加密演算法進行加密，將加密后的密碼存盤在資料庫中，禁止直接存盤明文密碼，加密演算法應采用MD5、SHA等不可逆的加密演算法，

五、會話定置（會話標識未更新）

漏洞說明

可能會竊取或操縱客戶會話和 cookie，它們可能用于模仿合法用戶，從而使黑客能夠以該用戶身份查看或變更用戶記錄以及執行事務，

解決方案

1. SessionID長度不能低于64位，使用128位長度的SessionID，
2. 當用戶客戶端發生變化，如IP、UserAgent等資訊發生變化時，強制摧毀當前Session，要求用戶重新登錄，
3. 在用戶認證成功后應先將之前的用戶會話銷毀，然后重新為用戶生成新的會話，保證認證成功前后，用戶會話 ID 不一樣，防止用戶操作會話標識，請勿使用用戶瀏覽器登陸時所提供的會話標識，如“修改密碼”、“用戶登陸“功能，
4. 設定Session最長存活時間，當Session存活時間超過某個值時，強制注銷要求重新登錄，
5. 每次請求登陸的action或servlet時清空Cookie 生成新的Session，java代碼如下：

try {

request.getSession(true).invalidate();//清空session

if (request.getCookies() != null) {

Cookie cookie = request.getCookies()[0];//獲取cookie

cookie.setMaxAge(0);//讓cookie過期

}

} catch (Exception e) {

e.printStackTrace();

}

session = request.getSession(true);

六、鏈接注入（便于跨站請求偽造）--跨站請求偽造

漏洞說明

跨站點請求偽造CSRF的英文全名為：Cross Site Request Forgery，也屬于Web應用中一種常見的攻擊方式，

通過CSRF漏洞，攻擊者誘使用戶在第三方站點的頁面執行操作，將請求發送到目標站點，通過用戶的身份在目標站點中執行了計劃外的操作，

CSRF漏洞攻擊成功的一個關鍵是猜測出URL的引數和引數值，構造出偽造的請求，因此只要讓攻擊者無法猜測出URL的引數和引數值，即可避免用戶遭受CSRF攻擊，

解決方案

1. Token驗證：

1）在用戶剛登陸的時候，可以產生一個新的CSRV Token，并且把Token存到用戶的session中，

2）在一個需要保護的表單中，增加一個隱藏的欄位來存放這個Token，對于需要保護的URL，增加一個引數來存放此Token，

3）相關的URL的業務操作中加入token驗證，URL權限判斷依據:

①cookie中的用戶賬號欄位；

②自定義的隨機id，寫入cookie，或渲染到頁面上，或保存于URL中；

③來自于URL中的id；

4）在提交請求時，攜帶此Token到服務端，與用戶保存在session中的Token進行驗證，如果一致，則繼續處理請求，否則回傳一個較友好錯誤資訊給用戶，

5）在用戶退出或者session過期的時候，用戶資訊（包括CSRF Token）也需要從session中移除并且銷毀session，

生成CSRF Token的示例代碼：

private String csrfToken = resetCSRFToken();

public String resetCSRFToken(){

String csrfToken = ESAPI.randomizer().getRandomString(8,DefaultEncoder.CHAR_ALPHANUMBERICS);

return csrfToken;

}

提供需要CSRF保護的URL鏈接呼叫，示例代碼：

final static String CSRF_TOKEN_NAME = “ctoken”;

public String addCSRFToken(String url){

User user = ESAPI.authenticator().getCurrentUser();

if(user.isAnonymous()){

return url;

}

String token = CSRF_TOKEN_NAME + “=” + user.getCSRFToken();

return url.indexOf(‘?’) !=-1 ? url +”&” + token : url + “?” +token;

}

public String getCSRFToken(){

User user = ESAPI.authenticator().getCurrentUser();

if(user == null){ return null;}

return user.getCSRFToken();

}

提交到服務器的Token與session中的Token驗證示例代碼：

public void verifyCSRFToken(HttpServletRequest request)throws IntrusionException{

User user = ESAPI.authenticator().getCurrentUser();

if(request.getAttribute(user.getCSRFToken() !=null){

return ;

}

String token = request.getParameter(CSRF_TOKEN_NAME);

if(!user.getCSRFToken().equals(token)){

throw new IntrusionException(“error!”);

}

}

用戶退出或者session過期，CSRF Token移除，下次登錄需要產生新的Token，代碼示例：

public void logout(){

ESAPI.httpUtilities().killCoolie(ESAPI.currentRequest(),ESAPI.currentReponse,HTTPUtilities.REMEMBER_TOKEN_COOKIE_NAME);

HttpSession session = ESAPI.currentRequest().getSession(false);

if(session !=null){

removeSession(session);

session.invalidate();

}

ESAPI.httpUtilities.killCookie(ESAPI.currentRequest(),ESAPI.currentResponse(),”JESSIONID”);

loggedIn = false;

ESAPI.authenticator().setCurrentUser(User.ANONYMOUS);

}

1. 二次驗證：

對一些非常重要的操作，可以采用操作請求執行之前，對當前用戶做二次驗證的方式防止CSRF攻擊，

七、通過框架釣魚

漏洞說明

利用目標網站的反射型XSS跨站腳本漏洞和保存性XSS漏洞將一段惡意的腳本代碼提交到web服務器上，或者把一個同樣含有惡意腳本代碼的web站點的URL鏈接發給目標用戶，而這些惡意腳本將用戶引誘一個精心設計的釣魚網站上或者直接構造一個收集用戶資訊的表單，當個人用戶訪問了含有惡意腳本代碼的頁面或者打開收到的URL鏈接時，惡意腳本就會被執行，從而遭受釣魚攻擊，

解決方案

采用1.2的解決方案，

八、支持弱 SSL 密碼套件

漏洞說明

攻擊者無需本地網路訪問及身份驗證，即可利用此漏洞解密客戶端和服務器之間的通訊，或在客戶端上執行中間人攻擊，從而獲取敏感資訊，執行未授權操作，

解決方案

通過配置SSL的方式，請求HTTPS協議時，必須使用域名的方式才起作用，