Java開髮網絡安全常見問題_ZenDei技術網路在線

Java開髮網絡安全常見問題等閑識得東風面，萬紫千紅總是春 1、敏感信息明文傳輸用戶敏感信息如手機號、銀行卡號、驗證碼等涉及個人隱私的敏感信息不通過任何加密直接明文傳輸。如下圖中小紅書APP 的手機簡訊驗證碼登錄介面，此處沒有對用戶手機號和驗證碼等信息進行加密傳輸，可以很簡單的截取並開展一些合 ...

Java開髮網絡安全常見問題

　　　　等閑識得東風面，萬紫千紅總是春

1、敏感信息明文傳輸

用戶敏感信息如手機號、銀行卡號、驗證碼等涉及個人隱私的敏感信息不通過任何加密直接明文傳輸。

如下圖中小紅書APP 的手機簡訊驗證碼登錄介面，此處沒有對用戶手機號和驗證碼等信息進行加密傳輸，可以很簡單的截取並開展一些合法的工作。

可以對比下其他的APP，如美團APP 的手機簡訊驗證碼登錄介面，就不是明文傳輸。

解決方案

前後端敏感參數的傳遞，可以通過加密手段如藉助AES秘鑰前後端加解密傳輸。最近的的用戶手機號加密傳輸如下。

2、弱口令漏洞

這種情況其實很常見，好多後臺的管理系統，甚至我之前公司的管理系統現在使用123456這種密碼都可以登錄進去。

解決方案

很多登錄的框架都支持在配置文件開啟用戶登錄密碼強度級別和設置預設密碼。
使用至少12位的數字、字母及特殊字元組合作為密碼。
資料庫不要存儲明文密碼，應存儲MD5加密後的密文，由於目前普通的MD5加密已經可以被破解，最好可以多重MD5加密，或者多種加密方式疊加組合。

3、繞過密碼登錄直接進入後臺

首先，後臺登陸驗證的邏輯一般的方式都是將用戶在登錄界面輸入的賬號密碼拿到資料庫中的相關用戶表做校驗，如果輸入的賬號密碼等於資料庫中某條記錄，則驗證通過並且程式會給用戶一個sssion，然後進入後臺，反之就是返回登陸界面。

出現這種繞過密碼登錄的情況就是很早之前的典型案例 'or'='or' 漏洞，校驗用戶登錄的SQL如下。

select * from t_user where user_name = '’or‘='or'' And password = '123456789'

如果用戶名在登錄界面的用戶名處輸入要提交的信息為 'or'='or' ，就會變成如上SQL（（假or真or假and（真/假））= 真）執行後得到對象的結果為真，接下來就可以通過重定向進入後臺了。

 1  執行SQL語句，執行後並得到rs對象結果，“真”或“假”
 2 Set rs = conn.Execute(sql)
 3 
 4 # 如果是真則執行以下代碼
 5 If Not rs.EOF = True Then
 6 
 7 # 將UserName的屬性賦給Name的Session自定義變數
 8 Session("Name") = rs("UserName")
 9 
10 # 將PassWord的屬性賦給pwd的Session自定義變數
11 Session("pwd") = rs("PassWord")
12 
13 # 利用Response對象的Redirect方法重定向Manage.asp
14 Response.Redirect("Manage.asp")

View Code

解決方案

通過配置，過濾掉無效用戶的登錄請求。
很早之前才會出現這個漏洞，現在基本上的後臺驗證都不會使用這類方式，而是取得用戶輸入的賬號和密碼，在SQL中先將用戶名與資料庫中的記錄做對比，若資料庫中某條記錄的用戶名等於用戶輸入的用戶名，則取出該條記錄中的密碼，然後再與用戶輸入的密碼對比。

4、瀏覽器緩存漏洞

系統正常存在的合法用戶在“註銷”後，但未關閉瀏覽器，此時點擊瀏覽器“後退”按鈕，可從本地頁面緩存中讀取數據，繞過了服務端filter過濾。

解決方案

在很多項目的 Config 配置文件中都有發現的如下配置，即配置filter對存放敏感信息的頁面限制緩存。

httpResponse.setHeader(“Cache-Control”,“no-cache”);
httpResponse.setHeader(“Cache-Control”,“no-store”);
httpResponse.setDateHeader(“Expires”, 0);
httpResponse.setHeader(“Pragma”,“no-cache”);

5、SQL註入漏洞

在HTTP 請求中註入惡意的SQL 代碼，最常見的手段就是在訪問URL 後拼接SQL 代碼，伺服器使用參數構建資料庫SQL 命令時，惡意SQL 被一起構造，併在資料庫中執行。如下拼接SQL

String query = “SELECT * FROM t_users WHERE user_id = ’” + request.getParameter(“id”) + “’”;

如果參數id 中是 or 1=1 ，就會返回所有數據。
解決方案

不要拼接SQL字元串。
使用預編譯的PrepareStatement，如。

PreparedStatement pstmt = con.prepareStatement(“SELECT * FROM t_users WHERE u_name = ?”);
pstmt.setString(1, “tjt”);

伺服器端校驗 (防止攻擊者繞過web端請求)。
過濾SQL 參數中的特殊字元，比如單引號、雙引號等。

6、文件上傳漏洞

在文件上傳前端界面，用戶上傳了一個可執行的腳本文件，並通過此腳本文件獲得執行服務端命令的能力。

解決方案

設置文件上傳的目錄為不可執行。
判斷文件類型。在判斷文件類型的時候，可以結合使用MIME Type，尾碼檢查等方式。以及限制上傳文件的大小。
對上傳的文件類型進行白名單校驗，只允許上傳可靠類型。
上傳的文件需要進行重新命名，使攻擊者無法猜想上傳文件的訪問路徑，將極大地增加攻擊成本，同時向shell.php.rar.ara這種文件，因為重命名而無法成功實施攻擊。
給文件伺服器設置單獨的功能變數名稱。

7、WEB 容器漏洞

Tomcat 有一個管理後臺，其用戶名和密碼在Tomcat安裝目錄下的conf omcat-users.xml文件中配置，很多用戶經常採用的是一些弱口令。而Tomcat 又支持在後臺部署war包，可以直接將webshell 部署到web目錄下，如果tomcat 後臺管理用戶存在弱口令，這很容易被利用上傳webshell。

解決方案

更改其預設路徑，口令及密碼。
Tomcat還有一些其他的漏洞，最有效的防禦就是修改配置文件，防止未授權訪問、弱口令、PUT方式傳文件、readonly等，然後最好更新最新版本的tomcat。

8、XSS 攻擊

XSS（cross site scripting，即跨站腳本攻擊），將一段Html 和JavaScript 代碼註入到用戶瀏覽的網頁上。XSS 可以大概分為三類， DomXSS、反射型XSS 和存儲型XSS。

<input type="text" name="name" value="tjt">

在前端界面有很多用戶輸入字元的操作，如上表單，如果，用戶輸入的不是一個正常的字元串，而是

"/><script>alert(“tjt-hello-boy-isMe”)</script><!-

然後，JS頁面變成下麵的內容，在輸入框 input 的後面帶上了一段腳本代碼。

<input type="text" name="name" value="tjt">

<script>alert(“tjt-hello-boy-isMe”)</script><!-"/>

從上可以看出，XSS攻擊的威力取決於用戶輸入的JS 腳本。攻擊者提交惡意的JS 代碼，客戶端沒有做xss校驗，都會存在客戶端註入問題，就會出現這段惡意執行的JS 代碼。

解決方案

前後端限制字元串輸入的長度限制。
前後端限制對HTML 轉義處理，將其中的"<",">"等特殊字元進行轉義編碼。

9、CSRF 攻擊

XSRF Cross-site request forgery，即跨站請求偽造，指攻擊者通過跨站請求，以合法的用戶身份進行非法操作。攻擊者盜用你的身份，以你的名義向第三方網站發送惡意請求。CRSF 能做的事情包括利用你的身份發郵件，發簡訊，進行交易轉賬，甚至盜取賬號信息，容易造成個人隱私泄露以及財產安全。

早期就會有很多這種網站，掛了很多靚妹的圖片或者讓人有種想要點擊的那些圖片，一旦你點擊了，其實是打開了一個鏈接比如發起銀行轉賬請求，而你的瀏覽器又恰巧登錄瀏覽過該銀行並且緩存未失效，不出意外的話意外就發生了。隨之後來的隱藏域手段、驗證碼、二次確認等機制這種攻擊案例就少了。

解決方案

使用安全框架，如Apache shiro，Spring Security 等。
結合安全框架充分校驗Token，在HTTP 請求中進行token 驗證，如果請求中沒有token或者token內容不正確，則認為CSRF攻擊而拒絕該請求。
驗證碼二次確認。通常情況下，驗證碼能夠很好的遏制CSRF攻擊，但是很多情況下，出於用戶體驗考慮，驗證碼只能作為一種輔助手段，而不是最主要的解決方案。
網上還說可以通過 referer識別。在HTTP Header中有一個欄位Referer，記錄HTTP請求的來源地址。如果Referer是其他網站，就有可能是CSRF攻擊，則拒絕該請求。但Referer 信息也極易偽造，竊取HTTP 竊取源地址，Header中添加Referer 欄位。

10、DDOS 攻擊

DDoS:Distributed Denial of Service，DDOS 攻擊指藉助於客戶/伺服器技術，將多個電腦聯合起來作為攻擊平臺，對一個或多個目標發動DDoS攻擊，從而成倍地提高拒絕服務攻擊的威力。它的目的就是利用目標系統網路服務功能缺陷或者直接消耗其系統資源，使得該目標系統無法提供正常的服務。
DDoS 攻擊是通過大量合法的請求占用大量網路資源，以達到癱瘓網路的目的，其具體有下麵幾種形式：

通過使網路過載來干擾甚至阻斷正常的網路通訊；
通過向伺服器提交大量請求，使伺服器超負荷；
阻斷某一用戶訪問伺服器；
阻斷某服務與特定系統或個人的通訊。

解決方案

1、監控訪問數據、過濾惡意流量，定期檢查伺服器軟體安全漏洞，對外關閉不必要的服務和埠，在伺服器防火牆中，只開啟使用的埠，比如網站web服務的80埠、資料庫的3306埠、SSH服務的22埠等。

2、採用高性能的網路設備，當大量攻擊發生的時候請他們在網路接點處做一下流量限制來對抗某種類的DDOS攻擊是非常有效的。

3、HTTP請求攔截，如果惡意請求有特征，直接攔截就可以。HTTP請求的特征一般有兩種：IP地址和User Agent欄位。

4、儘量避免NAT 的使用，因為NAT需要對地址來迴轉換，會較大降低網路通信能力。

5、足足的網路帶寬，帶寬直接決定了能抗受攻擊的能力，假若僅僅有10M的話，無論採取什麼措施都很難對抗現在的DDOS 的 SYNFlood攻擊，沒錢搞 100M有錢的搞到1000M。

6、將網站做成靜態頁面或者偽靜態，將網站做成靜態頁面，不僅能大大提高抗攻擊能力，而且還給黑客入侵帶來不少麻煩，至少到現在為止關於HTML的溢出還沒出現。

7、安裝專業抗DDOS 防火牆。

8、備份網站，有一個備份網站，容錯率就高很多，生產伺服器萬一下線了，可以立刻切換到備份網站。

等閑識得東風面

萬紫千紅總是春