文章目錄
問題
當今海量求職公司都有此類要求
2、熟悉Web服務開發，瞭解Web服務框架，瞭解Web安全；
一.安全性問題層次關係
大家經常會聽到看到很多很多有關安全性方面的信息，可以說形形色色，對於在網絡安全方面不太專業的同志來說，有點眼花繚亂，理不出頭緒。在這裏，我來幫大家整理一下。
以我個人多年來從事Web安全方面的工作經驗及國外一些權威安全機構對Web安全的層次性的理解，我們通常把它分爲三個層次：
１.網絡安全。如防火牆、路由器、網絡結構等相關的安全問題
２.系統與服務安全。如Window/Linux/Unix系統本身的漏洞或運行於其上的服務的安全，象Apache/OpenSSL/Weblogic等本身的安全性漏洞
３.Web應用程序安全。具體應用程序的安全性漏洞，比如：某網站郵件系統因爲存在腳本安全性問題，導致該郵件系統的用戶在收到具有惡意代碼的郵件時不知不覺的，其密碼與帳號信息被人竊取。
說到這，大家應該清楚，不管你是在任何地方看到有關計算機安全性問題的方方面面，都逃不出這三大部分，同時我也要向讀者聲明一下：在這裏，我主要是給大家陸續的介紹上述第三部分內容，即Web應用程序安全性相關知識與技能。
據權威搜索引擎公司統計數據顯示，目前70%以上的網站，或多或少的存在安全隱患，這裏的安全隱患指的就是Web應用程序的安全。
至於網絡、系統與服務的安全性問題，我個人認爲它的生存週期基本上是：發現->上報軟件開發商->打補丁->下載更新程序。作爲我們用戶，及時的給系統與服務打上最新的補丁，配合一定的防火牆安全策略，是可以基本保證其安全的。
但是Web應用程序基本上是每個組織各持一套自己的程序，一切問題都必需自己動手去解決，恰恰因爲此種特性，才導致目前運行於互聯網上的Web應用的安全性普遍存在。爲什麼呢？因爲只有少數組織或個人有能力駕馭網絡安全相關的技術與經驗，而絕大多數的即使是專業做網站開發的公司也不一定有知識有能力或有意識去考慮安全性問題．
還要向讀者羅嗦一點是的：安全需要意識，沒有安全意識的組織與個人，是無法保證其開發出的產品的安全性的。這一點很重要，很多人只是從媒體上看到聽到一些安全性問題，總覺得安全性問題離自己很遙遠，其不知安全性問題正在對其造成越來越嚴重的破壞…。前不久上海有一位朋友，銀行卡的資金不明轉出，且被人取走，報警後，經警方多方調查跟蹤，最絡查明：其經常使用網上銀行的筆記本電腦中了“灰鴿子”木馬，導致其操作電腦的行爲及其電腦上的現在資源完全暴露無遺。
有人要問：“灰鴿子”是如何跑到其計算機上的呢？當然進去的途徑有多種，比如我們是網友，我通過ＱＱ發給你讓你運行一下；或者我向你推薦一款你比較感興趣的免費軟件，該軟件內部已經綁定了“灰鴿子”木馬程序......，還有一點很重要的就是通過網頁來傳播。比如通過腳本注入的方式，強行的不停的提示你下載並運行該程序；通過上傳漏洞上傳到一個你信任的網站上，當它提示你下載並安裝時，你發現它來自你信任的網站，於是就接受了......
總之，Web應用程序是我們接觸最多最有可能通過帶來安全隱患的載體。我將在之後的文章裏步步向大家介紹Web應用程序安全性相關的知識、方法與我個人的多年從事web應用程序安全性檢測的經驗。希望我的努力就是您的需要。
二.安全性問題的本質
相信大家都或多或少的聽過關於各種Web應用安全漏洞，諸如:跨site腳本攻擊(XSS)，SQL注入，上傳漏洞…形形色色.
在這裏我並不否認各種命名與歸類方式，也不評價其命名的合理性與否，我想告訴大家的是，形形色色的安全漏洞中，其實所蘊含安全問題本質往往只有幾個。 我個人把Web應用程序安全性本質問題歸結以下三個部分：
１.輸入／輸出驗證(Input/output validation)
２.角色驗證或認證(Role authentication )
３.所有權驗證(Ownership authentication)
說到這，讀者一定想知道我這三種分類與形形色色的安全性問題有什麼關係？下面我逐個給您概略解答：
輸入／輸出驗證
這裏的輸入與輸出其實都是發生在用戶界面（User Interface）這一個層面上的，比如：你某一站點上提交一份註冊信息，往往會收到諸多提示：“用戶名非法”，“姓名不能使用英文“…其實這就是輸入驗證的一個實例。什麼情況是輸出呢？ 比如說你成功提交一份註冊信息後，系統會返回一個確認頁（Registerred Confirmation），往往在這個頁面上會顯示你註冊時提交的部分或全部信息，那麼在這裏顯示的信息就是我所說的輸出實例之一，輸入需要做什麼驗證？ 假如你在提交時，在Address那一欄輸入：, 當你到達註冊的確認頁時，會有什麼發生？如果確認頁沒有做輸出驗證處理，那很顯然會在到達確認頁的時候出現一個Javascript打出的提示框。其實這就是跨site腳本攻擊的一個小小的實例。當然了，單純的輸入／輸出驗證涉及的面可能夠寫一小本書了，努力在後續文章中給大家詳解。
角色驗證或認證
我們就拿ＣＳＤＮ來說吧，用戶有這些角色：其一可以說是遊客，就是瀏覽者沒有登錄時的角色；其二是免費的註冊用戶；或許將來ＣＳＤＮ深入發展了，業務有所更新，還會出現收費的註冊用戶。以上只是用戶角色，那在ＣＳＤＮ公司內部還會有管理員角色，還有可能管理員又可以根據板塊分爲各種不同的角色。大家看到了吧，你天天訪問的ＣＳＤＮ一共可能有多少角色？ 接下來的問題就是權限問題了，爲什麼會有角色？ 就是爲了控制權限的。每種角色都有自己特定的與公共的權限，這些權限的邏輯關係是相當複雜的，如果一個Web應用在角色上沒有一個詳細的合理的設計，將會給開發人員帶來無限痛苦和麻煩。那現在我要問幾個問題：你能保證每種角色只能做其份內的事兒？你是如何去保證的呢？方法可靠嗎？有沒有漏洞？… 這，就是我要說的角色驗證或認證。ＢＴＷ：爲什麼我會說驗證或認證呢？你可以這麼理解，角色性存在於兩個階段，其一進入階段，比如你登錄的那一瞬間，你進入了一個特定的角色；另一個階段就是維持階段，你如何確保你登錄後總是以登錄時的身份在操作呢？那前者可以說是：認證，後者就是驗證了。（有點羅嗦不？）
給一個角色認證／驗證方面的虛擬案例，比如：一個在線電影服務提供商，會免費給您開一個試用角色，如果這試用角色驗證不當，可能會導致用戶權限提升而成爲一個合法的收費用戶，而這個收費用戶你往往卻收不到他的任何費用。
所有權驗證
這個問題的存在也是基於角色的，只不過它所關心的是同級別的角色之間的權限問題。就拿ＣSＤＮ來說吧，我是ＣＳＤＮ的一個免費用戶，你也是。現在的問題是：我可以替你操作嗎，我可以替你發表文章嗎？我能修改你的個性設置嗎？如果不能，CSDN是如何實現的？雖然你和我都是普通用戶，但是你有你的隱私我也有我的隱私，如何保證嚴格的所有權驗證就顯得尤爲關鍵了。比較簡單吧，這就是我所說的所有權驗證。
我可以很自信的告訴你，只要是Web應用安全性問題，它逃不出在這三大部分，可能你還無法把形形色色的Web應用安全性問題與這三個部分對應併合理的解釋清楚，但是確實只有這麼簡單的幾個部分。
三.安全漏洞及處理方式
1、SQL注入攻擊
SQL注入攻擊就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令。具體來說，它是利用現有應用程序，將(惡意)的SQL命令注入到後臺數據庫引擎執行的能力，它可以通過在Web表單中輸入(惡意)SQL語句得到一個存在安全漏洞的網站上的數據庫，而不是按照設計者意圖去執行SQL語句。
隨着B/S框架結構在系統開發中的廣泛應用，惡意攻擊者利用SQL命令在Web表單中輸入合法的字符或查詢字符串來欺騙服務器執行SQL命令。當注入攻擊得逞後，Web程序將泄露大量用戶隱私數據和數據庫中數據結構。攻擊者能夠獲得系統較高的訪問權限，進行破壞操作。
SQL注入可以分爲平臺層注入和代碼層注入。前者由不安全的數據庫配置或數據庫平臺的漏洞所致;後者主要是由於程序員對輸入未進行細緻地過濾，從而執行了非法的數據查詢。基於此，SQL注入的產生原因通常表現在以下幾方面:
1）不當的類型處理;
2）不安全的數據庫配置;
3）不合理的查詢集處理;
4）不當的錯誤處理;
5）轉義字符處理不合適;
- 多個提交處理不當。
解決方法:
數據庫安全通信包括SQL注入攻擊的防範、安全設置、異常信息處理三個方面。
1.服務端Filter對訪問者輸入的字符進行過濾檢驗，但是攻擊者經常把危險字符潛藏在用戶輸入的有效字符中完 成過濾檢驗。
2.通過正則表達式對頁面的文本框輸入的數據進行限制可以減少過濾檢驗存在的漏洞。
3.使用prepareStatment預編譯sql語句
2、XSS跨站腳本攻擊
跨站腳本（Cross-site scripting，簡稱XSS），是一種迫使Web站點回顯可執行代碼的攻擊技術，而這些可執行代碼由攻擊者提供、最終爲用戶瀏覽器加載。不同於大多數攻擊（一般只涉及攻擊者和受害者），XSS涉及到三方，即攻擊者、客戶端與網站。XSS的攻擊目標是爲了盜取客戶端的cookie或者其他網站用於識別客戶端身份的敏感信息。獲取到合法用戶的信息後，攻擊者甚至可以假冒最終用戶與網站進行交互。
XSS 屬於被動式的攻擊。攻擊者先構造一個跨站頁面，利用SCRIPT、<IMG>、<IFRAME>等各種方式使得用戶瀏覽這個頁面時，觸發對被攻擊站點的HTTP 請求。此時，如果被攻擊者如果已經在被攻擊站點登錄，就會持有該站點cookie。這樣該站點會認爲被攻擊者發起了一個HTTP請求。而實際上這個請求是在被攻擊者不知情情況下發起的，由此攻擊者在一定程度上達到了冒充被攻擊者的目的。精心的構造這個攻擊請求，可以達到冒充發文，奪取權限等多個攻擊目的。在常見的攻擊實例中，這個請求是通過script 來發起的，因此被稱爲Cross Site Script。
XSS漏洞成因是由於動態網頁的Web應用對用戶提交請求參數未做充分的檢查過濾，允許用戶在提交的數據中摻入HTML代碼（最主要的是“>”、“<”），然後未加編碼地輸出到第三方用戶的瀏覽器，這些攻擊者惡意提交代碼會被受害用戶的瀏覽器解釋執行。
分爲三種類型：
1）反射型（數據流向：瀏覽器 ->後端 -> 瀏覽器）
反射型XSS腳本攻擊即如我們上面所提到的XSS跨站腳本攻擊方式，該類型只是簡單地將用戶輸入的數據直接或未經過完善的安全過濾就在瀏覽器中進行輸出，導致輸出的數據中存在可被瀏覽器執行的代碼數據。由於此種類型的跨站代碼存在於URL中，所以黑客通常需要通過誘騙或加密變形等方式，將存在惡意代碼的鏈接發給用戶，只有用戶點擊以後才能使得攻擊成功實施。
2）存儲型（數據流向是：瀏覽器 ->後端 -> 數據庫 -> 後端-> 瀏覽器）
存儲型XSS腳本攻擊是指Web應用程序會將用戶輸入的數據信息保存在服務端的數據庫或其他文件形式中，網頁進行數據查詢展示時，會從數據庫中獲取數據內容，並將數據內容在網頁中進行輸出展示，因此存儲型XSS具有較強的穩定性。
存儲型XSS腳本攻擊最爲常見的場景就是在博客或新聞發佈系統中，黑客將包含有惡意代碼的數據信息直接寫入文章或文章評論中，所有瀏覽文章或評論的用戶，都會在他們客戶端瀏覽器環境中執行插入的惡意代碼。
3）基於DOM（數據流向是：URL–>瀏覽器 ）
基於DOM的XSS跨站腳本攻擊是通過修改頁面DOM節點數據信息而形成的XSS跨站腳本攻擊。不同於反射型XSS和存儲型XSS，基於DOM的XSS跨站腳本攻擊往往需要針對具體的javascript DOM代碼進行分析，並根據實際情況進行XSS跨站腳本攻擊的利用。
解決方法：
1).輸入過濾。對用戶的所有輸入數據進行檢測，比如過濾其中的“<”、“>”、“/”等可能導致腳本注入的特殊字符，或者過濾“script”、“javascript”等腳本關鍵字，或者對輸入數據的長度進行限制等等。同時，我們也要考慮用戶可能繞開ASCII碼，使用十六進制編碼來輸入腳本。因此，對用戶輸入的十六進制編碼，我們也要進行相應的過濾。只要能夠嚴格檢測每一處交互點，保證對所有用戶可能的輸入都進行檢測和XSS過濾，就能夠有效地阻止XSS攻擊。
2).輸出編碼。通過前面對XSS攻擊的分析，我們可以看到，之所以會產生XSS攻擊，就是因爲Web應用程序將用戶的輸入直接嵌入到某個頁面當中，作爲該頁面的HTML代碼的一部分。因此，當Web應用程序將用戶的輸入數據輸出到目標頁面中時，只要用HtmlEncoder等工具先對這些數據進行編碼，然後再輸出到目標頁面中。這樣，如果用戶輸入一些HTML的腳本，也會被當成普通的文字，而不會成爲目標頁面HTML代碼的一部分得到執行.
3、CSRF跨站請求僞造漏洞防護
CSRF是CrossSite Request Forgery的縮寫，乍一看和XSS差不多的樣子，但是其原理正好相反，XSS是利用合法用戶獲取其信息，而CSRF是僞造成合法用戶發起請求。
根據HTTP協議，在HTTP頭中有一個字段叫Referer，它記錄了該HTTP請求的來源地址。在通常情況下，訪問一個安全受限頁面的請求必須來自於同一個網站。
解決方案：
配置FILTER攔截用戶所有請求(POST/GET)，對用戶請求Referer頭URL進行合法性校驗。
4、URL鏈接注入漏洞防護
鏈接注入是修改站點內容的行爲，其方式爲將外部站點的 URL 嵌入其中，或將有易受攻擊的站點中的腳本 的 URL 嵌入其中。將URL 嵌入易受攻擊的站點中，攻擊者便能夠以它爲平臺來啓動對其他站點的攻擊，以及攻擊這個易受攻擊的站點本身。
解決方案：
配置FILTER攔截用戶所有請求，對用戶參數進行關鍵字符校驗進行合法性校驗。
5、會話COOKIE中缺少HttpOnly防護
會話cookie中缺少HttpOnly屬性會導致攻擊者可以通過程序(JS腳本、Applet等)獲取到用戶的cookie信息，造成用戶cookie信息泄露，增加攻擊者的跨站腳本攻擊威脅。
HttpOnly是微軟對cookie做的擴展，該值指定cookie是否可通過客戶端腳本訪問。Microsoft Internet Explorer 版本 6 Service Pack 1 和更高版本支持cookie屬性HttpOnly。
如果在Cookie中沒有設置HttpOnly屬性爲true，可能導致Cookie被竊取。竊取的Cookie可以包含標識站點用戶的敏感信息。
如果在Cookie中設置HttpOnly屬性爲true，兼容瀏覽器接收到HttpOnly cookie，那麼客戶端通過程序(JS腳本、Applet等)將無法讀取到Cookie信息，這將有助於緩解跨站點腳本威脅。
解決方案：
配置filter攔截器，將服務器端返回請求，向所有會話cookie中添加“HttpOnly”屬性。
示例代碼：
HttpServletResponseresponse=(HttpServletResponse)paramServletResponse;
response.setHeader(“SET-COOKIE”,“JSESSIONID=” + sessionid + “; HttpOnly”);
6、點擊劫持漏洞(Clickjacking)防護
點擊劫持是一種視覺上的欺騙手段，攻擊者使用一個透明的、不可見的iframe，覆蓋在一個網頁上，然後誘使用戶在該網頁上進行操作，此時用戶在不知情的情況下點擊了透明的iframe頁面。通過調整iframe頁面的位置，可以誘使用戶恰好點擊在iframe頁面的一些功能性按鈕上。
解決方案：
配置FILTER攔截器，在服務器端返回請求中，使用一個HTTP頭“X-Frame-Options”值爲SAMEORIGIN-同源策略 ，則frame頁面的地址只能爲同源域名下面的頁面，防止點擊劫持漏洞發生。
示例代碼：
HttpServletResponseresponse=(HttpServletResponse)paramServletResponse;
response.addHeader(“x-frame-options”,“SAMEORIGIN”);
7、HTTP host 頭攻擊漏洞
使用HTTP代理工具，可以篡改HTTP報文頭部中HOST字段時，該值可被注入惡意代碼。因爲需要控制客戶端的輸入，故該漏洞較難利用。
解決方案：
配置FILTER攔截器，對請求輸入HOST頭信息進行信息安全性校驗，防止HOST頭信息被惡意篡改利用。
示例代碼：
HttpServletRequest request =(HttpServletRequest)servletRequest;
//主機ip和端口 或 域名和端口
String myhosts = request.getHeader(“host”);
if(!StringUtils.equals(myhosts, “xx.xx.xxx.xxx:xxxx”)
!StringUtils.equals(myhosts, “xx.xx.xxx.xxx:xxxx”)
!StringUtils.equals(myhosts,“xx.xx.xxx.xxx:xxxx”)StringUtils.equals(myhosts,“xx.xx.xxx.xxx”)
!StringUtils.equals(myhosts,“xx.xx.xxx.xxx”) !StringUtils.equals(myhosts,“xx.xx.xxx.xxx” ){
logger.error(“訪問host非法，已攔截”);
response.sendRedirect(request.getContextPath() + “/login.jsp”);
return;
}
8、越權訪問漏洞防護
越權訪問（Broken Access Control，簡稱BAC）是Web應用程序中一種常見的漏洞，分爲垂直越權訪問和水平越權訪問。垂直越權是指不同用戶級別之間的越權，如普通用戶執行管理員用戶的權限。水平越權是指相同級別用戶之間的越權操作。
Web應用程序如果存在越權訪問漏洞，可能導致以下危害：
1）導致任意用戶敏感信息泄露；
2）導致任意用戶信息被惡意修改或刪除。
解決方案：
配置FILTER攔截器，對請求所有URL進行攔截，對於需要進行授權的URL進行權限校驗，防止用戶越權訪問系統資源。
9.弱口令漏洞
密碼機制過於簡單
解決方案：最好使用至少6位的數字、字母及特殊字符組合作爲密碼。數據庫不要存儲明文密碼，應存儲MD5加密後的密文，由於目前普通的MD5加密已經可以被破解，最好可以多重MD5加密，或者多種加密方式疊加組合。
校驗密碼不能與用戶名相同，修改密碼時不能使用前五次或上次密碼
增加驗證碼登錄，增加暴力破解的難度
增加用戶鎖定機制
10．JSP頁面拋出的異常可能暴露程序信息。
有經驗的入侵者，可以從JSP程序的異常中獲取很多信息，比如程序的部分架構、程序的物理路徑、SQL注入爆出來的信息等。
解決方案：自定義一個Exception，將異常信息包裝起來不要拋到頁面上。
11.本地緩存漏洞
合法用戶“註銷”後，在未關閉瀏覽器的情況下，點擊瀏覽器“後退”按鈕，可從本地頁面緩存中讀取數據，繞過了服務端filter過濾。
解決方案：配置filter對存放敏感信息的頁面限制頁面緩存。如：
httpResponse.setHeader(“Cache-Control”,“no-cache”);
httpResponse.setHeader(“Cache-Control”,“no-store”);
httpResponse.setDateHeader(“Expires”,0);
httpResponse.setHeader(“Pragma”,“no-cache”);
12.文件上傳漏洞。
前臺僅使用JS對文件後綴做了過濾，這隻能針對普通的用戶，而惡意攻擊者完全可以修改表單去掉JS校驗。
項目中涉及上傳下載未對文件大小以及類型進行驗證，可能導致不良用戶上傳有害文件，危害服務器
解決方案：文件上傳時在前臺對文件後綴名進行驗證，爲避免通過特殊手段繞過了前端驗證，在文件 保存時再進行一次驗證，即前後臺同時驗證的道理。
13.Java WEB容器默認配置漏洞。
如TOMCAT後臺管理漏洞，默認用戶名及密碼登錄後可直接上傳war文件獲取webshell。
解決方案：最好刪除，如需要使用它來管理維護，可更改其默認路徑，口令及密碼。
14.敏感信息泄露
敏感信息泄露漏洞，是一種通過提交錯誤請求，使系統出現異常處理並報錯，並且將系統程序、配置 等敏感信息泄露出來的漏洞。工程師發現系統搜索功能模塊中普遍將系統的報錯通printStackTrace 方法進行反饋，可造成報錯信息如實的返回到前端。
攻擊者可以利用此漏洞收集系統報錯中泄露的數據信息，包括處理函數，系統版本等等。可以通過此 類問題獲得深入和更有目的性攻擊的條件。
解決方案：建議統一處理錯誤頁面，將錯誤信息存儲在日誌中。
15.用戶名密碼未加密傳輸
用戶名密碼採用編碼後進行傳輸，容易被嗅探獲取認證信息，建議採用加密後進行傳輸。
解決方案：1.使用可逆的加密算法，在客戶端使用js同時加密用戶名和密碼，在後臺解密進行登錄操作。（有風 險）2.使用不可逆加密算法在前臺加密密碼（只是密碼），當然在數據庫裏存儲的密碼也是使用相同 算法加密的（安全性能較高）
16.未設置跨站注入過濾器
不良用戶通過編寫sql，或者仿製頁面盜取用戶信息。
解決方案：在系統中設置攔截器，對sql語句和js語句進行攔截，具體需要攔截的詞彙如下：(\b(alert|iframe|frame|ascii|script|and|exec|execute|insert|select|delete|update|count|drop|chr|mid|master|truncate|delay|waitfor|char|declare|sitename|netuser|xp_cmdshell|or|like’|exec|execute|insert|create|”+”table|from|grant|use|group_concat|column_name|information_schema.columns|table_schema|union|where|”+”reg|between|having|groupby|groupby|waitfor|waitingfor|#|cast|convert|window|local|location|”+”–|like)\b)。
17.短信轟炸
發送短信驗證碼未進行次數限制，可以不斷髮送短信驗證碼，導致一定的經濟損失。
解決方案：建議對發送的短信驗證碼進行頻率限制，一段時間內僅僅發送多少條短信。
18.註釋信息泄露
在開發過程中會存在將暫時不用的代碼註釋，以備後續使用的情況，但是時間長了可能項目會有大規 模的變動，例如將管理登錄入口單獨分離出來，這個地址只對內部開發，並不希望被外部而恰好這個 地址在之前的頁面註釋了，這就導致了重要信息泄露。
解決方案：及時刪除註釋代碼，有價值代碼在本地備份。
19.URL跳轉
任意URL惡意跳轉可能會導致釣魚等風險。
解決方案：改變傳值方式，可以在前臺傳入對應type，根據type跳轉到頁面
特別鳴謝：Java👍