web安全-最終版

1、 目錄目錄 q=0.5 Accept-Encoding: gzip, deflate Content-Type: application/x-www-url-encoded Content-Lenght: 59 User-Agent: Mozilla/4.0 Host: Connection: Keep-Alive Cookie: JSESSIONID=0000dITLGLqhz1dKkPEtpoYqbN2 uid=fred這兩句sql都符合 string,int,string的模式 999是不可能符合的條件 ，這樣union的結果就只 剩第二句sql查詢的內(nèi)容 SQL注入：規(guī)避SQL注入 n

2、嚴格限定參數(shù)類型嚴格限定參數(shù)類型 明確參數(shù)檢驗的邊界，明確參數(shù)檢驗的邊界，必須在服務端執(zhí)行數(shù)據(jù)驗證 n采用參數(shù)化查詢的方法（推薦）采用參數(shù)化查詢的方法（推薦） n內(nèi)置過濾系統(tǒng)（本質是黑名單，很常見但是不推薦）內(nèi)置過濾系統(tǒng)（本質是黑名單，很常見但是不推薦） SQL注入：安全編碼 安全編碼不難，真正困難的是如何做到全面安全，安全編碼不難，真正困難的是如何做到全面安全， 這需要良好的程序設計以及編碼習慣。支離破碎這需要良好的程序設計以及編碼習慣。支離破碎 的設計與隨意混雜的編碼難以開發(fā)出安全的系統(tǒng)。的設計與隨意混雜的編碼難以開發(fā)出安全的系統(tǒng)。 各種語言與數(shù)據(jù)庫的實際情況也有所區(qū)別，所以各種語言與數(shù)據(jù)

3、庫的實際情況也有所區(qū)別，所以 需要具體問題具體分析。需要具體問題具體分析。 1.輸入驗證輸入驗證 數(shù)字型的輸入必須是合法的數(shù)字； 字符型的輸入中對進行特殊處理； 驗證所有的輸入點，包括Get，Post，Cookie以及其 他HTTP頭； 2.使用符合規(guī)范的數(shù)據(jù)庫訪問語句使用符合規(guī)范的數(shù)據(jù)庫訪問語句 正確使用靜態(tài)查詢語句，如PreparedStatement SQL注入： PreparedStatement nPreparedStatement為預編譯指令為預編譯指令 nPreparedStatement不允許在插入時改變查 詢的邏輯結構 n所以PreparedStatement將SQL語句預先

4、編 譯，執(zhí)行前語句已經(jīng)準備好了，執(zhí)行階段 只是把輸入串作為數(shù)據(jù)處理,不再需要對 SQL語句進行解析 SQL注入： PreparedStatement 在在JSPJSP中要禁止使用中要禁止使用StatementStatement，如下的代碼會導致，如下的代碼會導致SQLSQL注入：注入： Bubble String sql = “select * from Users where name=” + name; PreparedStatement pstmt = con.prepare(sql); String sql = “select * from 表表 where 用戶名用戶名=?” pst

5、mt.setInt(1, request.getParameter(“name”); PreparedStatement pstmt = con.prepare(sql); Statement stmt = con.createStatement(); stmt.executeUpdate(select * from 表 where 用戶名 = + 變量值 +); 應當全部使用PreparedStatement來防止SQL注入 但是在使用PreparedStatement，也要注意符合編碼規(guī)范，如下的方法也 會導致SQL注入： 安全安全 危險危險 危險危險 SQL注入： Mysqli n并不是

6、所以數(shù)據(jù)庫都支持并不是所以數(shù)據(jù)庫都支持 PreparedStatement nMysql就明確表示不支持，但是就明確表示不支持，但是mysql可以可以 使用自己的預編譯擴展使用自己的預編譯擴展-mysqli nmysqli 同樣是執(zhí)行一個預備好的語句，杜 絕SQL的可能 SQL注入：數(shù)據(jù)庫加固 除了在代碼設計開發(fā)階段預防除了在代碼設計開發(fā)階段預防SQLSQL注入外，對數(shù)據(jù)庫進行加固也能夠注入外，對數(shù)據(jù)庫進行加固也能夠 把攻擊者所能造成的損失控制在一定范圍內(nèi)；把攻擊者所能造成的損失控制在一定范圍內(nèi)； 主要包括：主要包括： 最小權限原則，最小權限原則，禁止將任何高權限角色（例如禁止將任何高權限角色

7、（例如sasa，dbadba等等）賦于應等等）賦于應 用程序數(shù)據(jù)庫賬號。更安全的方法是單獨為應用創(chuàng)建有限訪問帳戶。用程序數(shù)據(jù)庫賬號。更安全的方法是單獨為應用創(chuàng)建有限訪問帳戶。 拒絕用戶訪問敏感的系統(tǒng)存儲過程，如前面示例的拒絕用戶訪問敏感的系統(tǒng)存儲過程，如前面示例的 xp_dirtree,xp_cmdshellxp_dirtree,xp_cmdshell等等；等等； 限制用戶所能夠訪問的數(shù)據(jù)庫表；限制用戶所能夠訪問的數(shù)據(jù)庫表； 目錄目錄 過濾：過濾：將script,style,iframe,onmouseover等有害 字符串去掉，但是保留 scriptalert(XSS)/script imp

8、orthttp:/ 更多實例可見：更多實例可見：/xss.html 綜合起來有綜合起來有 91種種HTML標簽標簽,十多種編碼方式十多種編碼方式,數(shù)種對象類型數(shù)種對象類型 MySpaceMySpace即即 采用的過濾采用的過濾 XSS漏洞：轉義 String title = request.getParameter(“title”); String id = request.getParameter(“id”); . String title = request.getParameter(“title”); String id = request.getPa

9、rameter(“id”); . 把輸入的值轉義成html代碼 對策：轉義比過濾更好 安全安全 危險危險 XSS漏洞：防范措施總結防范措施總結 一.過濾： 有時候過濾會導致意外的結果，例如alices 變成了alices。 有時候需要多次過濾，例如script過濾掉后還是。 需要注意多個過濾器的先后次序。當多個過濾器一起生效時，有可能后進行的過濾導致前面 的過濾失效。例如過濾器1要過濾ABC，過濾器2要過濾DEF，那么ABDEFC在依次通過1，2 過濾器后變成了ABC，這樣相當于繞開過濾器1。 二.輸入編碼： 輸入編碼往往可以有全局的解決方案，從設計的角度來看，這是最佳的。 一旦數(shù)據(jù)已經(jīng)入庫，

10、就難以用輸出編碼處理。 三.輸出編碼： 輸出編碼有助于開發(fā)者細粒度控制輸出，但也導致了工作量的增加。 輸出編碼可以解決輸入編碼無法處理的已入庫數(shù)據(jù)。 四.用戶安全加固： 小心點擊來源不明的URL。 對瀏覽器進行安全加固，例如禁止ActiveX。 永遠不要點擊自動登錄信息！ 目錄目錄 String pass = request.getParameter(“pass”); PreparedStatement ps = con.prepareStatement(“update UserTB set password=? Where user=?”); ps.setString(1,user); ps

11、.setString(2,pass); con.executeUpdate(); CSRF：案案例例2 案例案例2： 支持通過保留cookie自動登錄的功能，這樣在cookie有效期 內(nèi)，用戶訪問就會以他們上次在此主機登錄的用戶名自動登 錄（例如Gmail的Remember me on this computer）。 另外，上有個鏈接可以通過get直接給指定對象轉賬，例如： http:/ 這段這段FCKeditor代碼可以通過上傳文件后面加個代碼可以通過上傳文件后面加個.就可以上傳成功了如：就可以上傳成功了如： shell.php. 在在windows系統(tǒng)上系統(tǒng)上shell.php.=shel

12、l.php；在；在*nix系統(tǒng)一系統(tǒng)一 般使用般使用apache，在，在apache里里shell.php.將認為是將認為是php文件而執(zhí)行。文件而執(zhí)行。 編輯器上傳漏洞是最危險的，使用編輯器上傳漏洞是最危險的，使用 FCKeditor、eWebEditor、 Cuteditor 、Freetextbox、Webhtmleditor、Kindeditor等編輯器的都存在危險， 引用時應刪除其不必要的上傳功能 文件上傳漏洞3：不隨機重命名的危害不隨機重命名的危害 n在在win2000下下 代表截斷，如果一人上傳1.asp .jpg到 win2000上就會變成1.asp n以前大名鼎鼎的動網(wǎng)上傳漏

13、洞是使用的16進制00來截斷文 件名或路徑而造成上傳漏洞，現(xiàn)在雖然已經(jīng)滅絕，但是使 用java的程序員還應注意，因為java本身支持16進制00截 斷，上傳一個1.jsp00.jpg將變成1.jsp n很多由于web service,中間件自身存在解析漏洞，造成 1.asp;.jpg,1.php.aaa之類的可以解析 n所以重命名文件名是必要的所以重命名文件名是必要的 文件上傳漏洞：解決方案 n 解決方案 首先編碼者需要對上傳頁面代碼嚴格把關，特別是在保存文件的時候， 考察可能出現(xiàn)的異常字符，如如;, ./，.，空字符等。 其次，對文件擴展名檢查要采取“允許jpg,gif”這樣的檢查，而不要采

14、 取“不允許asp”這樣的檢查，例如IIS允許執(zhí)行.cer類型的腳本。 不可以使用本地的JS來進了后綴名驗證，必須再服務器端進行驗證 最好對上傳文件的目錄設置不可執(zhí)行，這可以通過最好對上傳文件的目錄設置不可執(zhí)行，這可以通過web服服 務器配置加固實現(xiàn)。務器配置加固實現(xiàn)。 文件包含漏洞 n 定義： 文件包含漏洞，如果允許客戶端用戶輸入控制動態(tài)包含在服務器端的 文件，會導致惡意代碼的執(zhí)行及敏感信息泄露，主要包括本地文件包含 和遠程文件包含兩種形式 n 解決方案： 1.嚴格檢查變量是否已經(jīng)初始化。 2.建議假定所有輸入都是可疑的，嘗試對所有輸入提交可能可能包含的文 件地址， 包括服務器本地文件及遠程

15、文件，進行嚴格的檢查，參數(shù)中不 允許出現(xiàn)./之類的目錄跳轉符。 3.嚴格檢查include類的文件包含函數(shù)中的參數(shù)是否外界可控。 4.不要僅僅在客戶端做數(shù)據(jù)的驗證與過濾，關鍵的過濾步驟在服務端進行。 5.在發(fā)布應用程序之前測試所有已知的威脅。 參考： http:/ 文件包含漏洞-示例 jsp:include page= flush=true/ 示例 ： test.jsp?test=./././././etc/passwd - if ($act = “view”) $file = $_GETfile; include $file; index.php?act=view jstack += Fil

16、e.separator + bin + File.separator + jstack; final ByteArrayOutputStream baos = new ByteArrayOutputStream(); Process proc = Runtime.getRuntime().exec(jstack); final InputStream pis = proc.getInputStream(); final InputStream per = proc.getErrorStream(); 此處的問題是此處的問題是exec執(zhí)行內(nèi)容的部分由外部提交的參數(shù)獲得，從而造成了執(zhí)行內(nèi)容的部分由

17、外部提交的參數(shù)獲得，從而造成了 危險，如果危險，如果jstack.jsp?exe=././././windows/system32/cmd ipconfig 就能造成命令執(zhí)行就能造成命令執(zhí)行 命令注入執(zhí)行漏洞命令注入執(zhí)行漏洞 $res = preg_replace(/(w+).$depr.(.$depr./+)/e, $var1=2;, implode($depr,$paths); 命令注入執(zhí)行漏洞命令注入執(zhí)行漏洞 命令執(zhí)行漏洞發(fā)生在PHP的地方是最常見的，php里有多個函數(shù)可可以動態(tài)執(zhí) 行，如： call_user_func() call_user_func_array() create_f

18、unction() preg_replace() 如下面這段thinkphp開發(fā)框架中的正則表達式代碼就造成了命令執(zhí)行漏洞： 造成該正則表達式漏洞的原因在于， PHP會對用雙引號包起來的字符進行 解析，preg_replace()使用了/e 參數(shù)時可以執(zhí)行代碼，這種情況下如果2 使用雙引號，那么2的內(nèi)容就會被當成PHP代碼執(zhí)行。 因此PHP程序開發(fā)者應避免使用雙引號來定義參數(shù)。 如下代碼：如下代碼： filepath=request.getparameter(filepath); File f = new File(d:tomcatwebappsROOTdown +filepath); Fil

19、eInputStream inStream = new FileInputStream(f); 如此當有人輸入如下如此當有人輸入如下URL:download.jsp?filepath=././conf/tomcat- users.xml 就能夠跨目錄下載就能夠跨目錄下載tomcat管理用戶的密碼，從而登陸管理用戶的密碼，從而登陸manager/html對對 系統(tǒng)造成危害。系統(tǒng)造成危害。 如果使用先打開目錄的方式將會提高安全性如果使用先打開目錄的方式將會提高安全性 File f = new File(d:tomcatwebappsROOTdown); 文件下載漏洞文件下載漏洞 當然也可以使用過濾

20、當然也可以使用過濾后綴名后綴名和和./的方式的方式 但過濾但過濾./應該注意其應該注意其. ，./等繞過方式等繞過方式 過濾后綴名應該注意區(qū)分大小寫，如下代碼：過濾后綴名應該注意區(qū)分大小寫，如下代碼： $filename = $_GETa; if(!eregi(.php$, $filename) echo “不允許下載該類型的文件不允許下載該類型的文件; readfile($filename); 該代碼由于使用的該代碼由于使用的eregi()正則函數(shù)而不是使用更為嚴謹?shù)膮^(qū)分大小寫的正則函數(shù)而不是使用更為嚴謹?shù)膮^(qū)分大小寫的 函數(shù)函數(shù)ereg()，因此提交，因此提交url：download.php

21、?filename=download.pHP 就可繞過就可繞過(linux系統(tǒng)本身區(qū)分大小寫但可提交系統(tǒng)本身區(qū)分大小寫但可提交download.php.)。 文件下載漏洞文件下載漏洞 XPath 注入攻擊 Ben Elmore abc test123 Shlomy Gantz xyz 123test XPath xpath = factory.newXPath(); XPathExpression expr = pile(/users/userloginID/text()=+loginID + and password/text()=+password+ /firstname/text();

22、Object result = expr.evaluate(doc, XPathConstants.NODESET); NodeList nodes = (NodeList) result; /繞過身份驗證 /users/userLoginID/text()= or 1=1 and password/text()= or 1=1 登錄用戶名輸入以上紅色部分，密碼任意輸 隨 著簡單 XML API、Web 服務和 Rich Internet Applications (RIAs) 的發(fā) 展,已經(jīng)有很多人使用 XML 文檔代替關 系數(shù)據(jù)庫，但XML 應用程序可能容易 受到代碼注入的攻擊，尤其是 X

23、Path 注入攻擊 整數(shù)溢出 示例代碼： - 某人訂購大量商品 number = 42949671; 計算出來的總價total = -196 沒有限定num 0) int total = num * 100; /計算總價格 是cookies過期時間未設置，可能會引發(fā)一些cookies欺騙攻擊 n風險風險 可能會竊取或操縱客戶會話和 cookie，它們可能用于模仿合法用戶，從而 使黑客能夠以該用戶身份查看或變更用戶記錄以及執(zhí)行事務 n解決方案解決方案 始終生成新的會話，供用戶成功認證時登錄。在登錄頁面上加上一段代碼： 在登陸頁面上加的這段代碼的作用就是，將用戶進入登陸頁面時所產(chǎn)生的會話 ( se

24、ssion) 清空，然后讓跟蹤這個會話的cookie過期，這樣服務器就不再掌握有關這 個會話的任何信息了。要想與服務器繼續(xù)通信，就要產(chǎn)生一個新的會話才行。于是 會話標示就更新了，假如晚上登錄被盜cookie，但是黑客在睡覺第二天醒來失效了 會話標識未更新會話標識未更新 注：注：如果是jsp+servlet，這段代碼放jsp頁面程序的任何位置都可以。 如果是struts框架框架，這幾行代碼只能加到jsp頁面程序的最后面頁面程序的最后面。因為struts框架在初 始化時會創(chuàng)建session對象，并把一些參數(shù)放在session里，然后再執(zhí)行頁面代碼。 request.getSession().inv

25、alidate();/清空session if (request.getCookies()!=null) Cookie cookie = request.getCookies()0;/ 獲取cookie cookie.setMaxAge(0);/ 讓cookie過期 目錄目錄 location.href=$ctx/admin/login/logout.jsp; /如果禁用了客戶端的腳本代碼，直接訪問后臺頁面，不會被跳轉 到登陸頁面，可以看到后臺所有內(nèi)容。 提示：不能用JS代碼來完成某些必須要執(zhí)行的信息。得用服務端腳 本語言如上面可以用response.sendRedirect() 變量注冊順序

26、：Php168 CMS文件包含漏洞 . elseif(ereg(-_0-9a-zA-Z+)$,$_GETjob)|ereg(-_0-9a-zA- Z+)$,$_POSTjob) require(dirname(_FILE_)./.global.php); if(is_file(PHP168_PATH.inc/job/$job.php) include(PHP168_PATH.inc/job/$job.php); 如果開了全局的話,就可以用gpc的變量注冊順序來pass那個 正則判斷 參考：http:/ Json hijacking/Json劫持漏洞 JSON(JavaScript Object

27、 Notation) 是一種輕量級的數(shù)據(jù)交換 格式。易于人閱讀和編寫。同時也易于機器解析和生成。JSON采用 完全獨立于語言的文本格式，也使用了類似于C語言家族的習慣（包 括C, C+, C#, Java, JavaScript, Perl, Python等）。這些特性使 JSON成為理想的數(shù)據(jù)交換語言。這種純文本的數(shù)據(jù)交互方式由于可 以天然的在瀏覽器中使用，所以隨著ajax和web業(yè)務的發(fā)展得到了廣 大的發(fā)展，各種大型網(wǎng)站都開始使用。 但是如果這種交互的方式用來傳遞敏感的數(shù)據(jù)，并且傳輸?shù)臅r 候沒有做太多安全性控制的話將導致安全漏洞，根據(jù)敏感信息的不 同導致會導致應用遭受不同級別的攻擊。 Js

28、on hijacking/Json劫持漏洞：示例 n某省運營商網(wǎng)上營業(yè)廳修改任意手機號密碼漏洞 http:/ onParam=%22dynamicURI%22%3A%22%2FmmxgBusiness% 22%2C%22dynamicParameter%22%3A%22method%22%3A% 22modifyPwd%22%2C%22busiNum%22%3A%22MMFW_MMC Z%22%2C%22mobile%22%3A%2213951909864%22%2C%22n ewPwd%22%3A%22987321%22%2C%22checkOld%22%3A%22 0%22%2C%22ca

29、rdNum%22%3A%22%22%2C%22dynamicDat aNodeName%22%3A%22mmczBusinessNode%22 劫持危害劫持危害 n以上方法在本地攔截并更改了提交出去的以上方法在本地攔截并更改了提交出去的 手機號碼，就能造成越權查看別人手機號手機號碼，就能造成越權查看別人手機號 的持有人姓名，賬單，余額等，一些網(wǎng)銀的持有人姓名，賬單，余額等，一些網(wǎng)銀 系統(tǒng)甚至可以轉賬。系統(tǒng)甚至可以轉賬。 n還有一種常見的危害，比如商城購物，比還有一種常見的危害，比如商城購物，比 如積分兌換的地方，標價如積分兌換的地方，標價2000積分兌換一積分兌換一 個手電筒，你本地篡改為個手

30、電筒，你本地篡改為1個積分再次提交個積分再次提交 出去，就能造成出去，就能造成1積分成功購買了手電筒。積分成功購買了手電筒。 flash安全策略 flash作為一款瀏覽器的第三方插件，是對瀏覽器功能的延伸，已經(jīng) 是web必不可少的元素。很多web系統(tǒng)因為業(yè)務應用的需求,允許用戶上 傳flash文件。 flash在頁面展示時含有的豐富功能， 同時對安全策略帶來了挑戰(zhàn)， 其潛在危險甚至超過js flash的跨域策略crossdomain.xml 利用利用flash進行攻擊進行攻擊 參考：http:/ 拖動前拖動前 拖動后拖動后 這個DEMO的思想是：在小球的上面加入隱藏層，在海豚的嘴上方加入隱 藏

31、層。本質上就是誘惑 用戶把中的內(nèi)容拖放到中去。 當操作成功后，會把你拖動的數(shù)據(jù)打印在頁面上。如果你愿意，只要再加幾行代碼， 數(shù)據(jù)就可以保存在服務器上了。細心的朋友可以看看源代碼，里面的操作我都寫成 了獨立的函數(shù)，應該很好理解。 容錯處理不當 public static void main(String args) try catch (Exception e) e.printStackTrace(); /直接將錯誤返回到客戶端，造成系統(tǒng)信息泄露(如：網(wǎng)站絕對路徑， SQL語句) 平臺安全特性 nIIS文件名解析漏洞文件名解析漏洞 nApache文件名解析漏洞文件名解析漏洞 nNginx文件名解

32、析漏洞文件名解析漏洞 nStruts2框架任意代碼執(zhí)行框架任意代碼執(zhí)行 文件名解析漏洞 nIIS6文件夾解析漏洞文件夾解析漏洞 /test.asp/111.jpg（忽略忽略/后的部分后的部分） nIIS6文件名解析漏洞文件名解析漏洞 /test.asp;1.jpg （忽略忽略;后的部分后的部分） nApache文件名解析漏洞文件名解析漏洞 /test.php.xxx （忽略忽略.后的部分后的部分） nNginx cgi模式文件名解析漏洞模式文件名解析漏洞 /test.jpg/a.php 注：攻擊者在在/test.jpg后加上后加上a.php就可以實現(xiàn)讓 nginx以php來解析任何類型的文件了

33、。 Struts2框架任意代碼執(zhí)行框架任意代碼執(zhí)行 n示例示例 http:/mydomain/MyStruts.action?(u0023_memberAccessallowStaticMethodAccess)(meh)=tr uew.write(request.getParameter(c);w.cl ose();u0025u003e)=1 OGNL訪問對象需要加#號前綴進行標記(根對象除外) 參數(shù)過濾器不允許參數(shù)名中出現(xiàn)“#”字符，但如果使用了Java的 unicode字符串表示u0023，攻擊者就可以繞過保護，修改保護Java方 式執(zhí)行的值 (詳見： http:/ 注意框架的補丁注意框

34、架的補丁 n因此應謹慎使用第三方的因此應謹慎使用第三方的MVC框架，及時框架，及時 更新其補丁更新其補丁 nStruts2 ,CakePHP,thinkPHP等框架都存等框架都存 在嚴重的命令執(zhí)行漏洞在嚴重的命令執(zhí)行漏洞 目錄目錄 /線上、本地、220測試機 if (!(referrer.startsWith(3) return false; return true; 頁面HTML源代碼中會出現(xiàn)頁面注釋內(nèi)容泄漏，包括開 發(fā)人員名稱、郵件地址等，所以在頁面中針對此類注釋不應該 使用顯式注釋方式，多采用隱式注釋方式。 以下是顯式注釋：以下是顯式注釋： 以下是隱式

35、注釋：以下是隱式注釋： 頁面注釋修改頁面注釋修改 為防止用戶退出后，點擊瀏覽器的“后退”按鈕仍可以顯示用戶 退出前訪問的最后一個頁面，需要強制所有頁面不緩存。 建議在web管理后臺程序管理后臺程序的過濾器里增加如下代碼： 禁止頁面緩存禁止頁面緩存 /只是請求或響應消息不緩存 response.setHeader(Cache-Control, no-cache); /在請求消息中發(fā)送將使得請求和響應消息都不使用緩存 response.setHeader(Cache-Control, no-store); /緩存距離過期的時間為0毫秒，即緩存立即過期 response.setDateHeader(

36、Expires, 0); /頁面不緩存 response.setHeader(Pragma, no-cache); PreparedStatement，通過預編譯并存儲在PreparedStatement 對象池中。下面實例代碼是采用預編譯語句的查詢的SQL實現(xiàn)， 請參考： 隱患代碼隱患代碼 Sql=“select * from t_sys_user where username=”+變量1+” and password=”+變量2+” 安全代碼安全代碼 采用預編譯語句的采用預編譯語句的SQL實現(xiàn)實現(xiàn) StringBuffer sbSql = new StringBuffer(50); sbS

37、ql.append(“select 字段1，字段2，字段3”); sbSql.append(“ from t_sys_user”); sbSql.append(“ where username = ? “); sbSql.append(“ and password = ? “); Connection conn = 獲取數(shù)據(jù)庫連接 PreparedStatement pstmt = conn.prepareStatement(sbSql.toString(); int parIndex=1; pstmt.setString(parIndex+,變量1); pstmt.setString(par

38、Index+,變量2); ResultSet rs = pstmt.executeQuery(); 網(wǎng)站存在上傳文件的功能，惡意用戶可以繞過客戶端頁面 的驗證，模擬請求上傳文件處理服務端，將一些可運行頁面(例 如：jsp、php、asp等)上傳到服務端，訪問該頁面會對網(wǎng)站安全 造成很大影響。 解決該漏洞步驟如下： 1.客戶端對上傳文件類型做校驗。 2.上傳處理服務端對文件類型進行二次校驗。 3.文件上傳到服務器之后，如果是屬于臨時文件，則在業(yè)務邏輯 處理完成之后，將該原始文件刪除。 注：注：還有其他文件上傳方式（比如彩信彩信的上行jsp附件，就最好 不放到web路徑下） 文件文件上傳上傳校驗校

39、驗 目錄目錄 & 引言引言 & 高危漏洞分析與對策高危漏洞分析與對策 & 程序開發(fā)安全措施程序開發(fā)安全措施 & 平臺部署與維護措施平臺部署與維護措施 uWEB應用服務器配置 uWEB應用配置403、404、500通用處理頁面 u權限管理 & 程序安全開發(fā)流程程序安全開發(fā)流程 nTomcatTomcat 線上tomcat禁用自帶的管理應用以及示例應用 配置tomcat禁止列表顯示文件。 Tomcat不以ROOT/system運行。 tomcat下禁止不安全的http方法（DELETE、PUT、 OPTIONS、TRACE、HEAD等協(xié)議） nApacheApache 配置非超級用戶不能修改應用目

40、錄內(nèi)容。 配置禁止apache目錄訪問顯示文件 增強apache日志記錄，對運行錯誤、用戶訪問等日志都記 錄。 禁止不安全的HTTP方法 WEB應用服務器配置應用服務器配置 應用常見403、404、500等訪問異常，需要配置各自獨立 重定向頁面。 在應用web.xml中增加以下內(nèi)容配置，各個異常顯示頁面 需要單獨制作。 WEB應用配置應用配置403、404、500通用處理頁面通用處理頁面 403 /error/403.html 404 /error/404.html 500 /error/500.html n上傳文件目錄的權限原則：上傳文件目錄的權限原則： 權限最小化原則；權限最小化原則； 能

41、寫入的目錄不能執(zhí)行，能執(zhí)行的目錄不能寫入能寫入的目錄不能執(zhí)行，能執(zhí)行的目錄不能寫入 n數(shù)據(jù)庫帳號權限原則：數(shù)據(jù)庫帳號權限原則： 權限最小化原則；不要給應用權限最小化原則；不要給應用dba等數(shù)據(jù)庫管理權限等數(shù)據(jù)庫管理權限 不要分配不要分配跨庫權限跨庫權限。 數(shù)據(jù)庫連接的配置文件中關鍵信息要加密數(shù)據(jù)庫連接的配置文件中關鍵信息要加密 權限管理權限管理 目錄目錄 & 概述概述 & WEBWEB代碼常見的安全問題代碼常見的安全問題 u SQL注入 u 跨站腳本漏洞(XSS) u 跨站點請求偽造（CSRF） u & 程序開發(fā)安全具體措施程序開發(fā)安全具體措施 & 平臺部署與維護具體措施平臺部署與維護具體措施

42、 & 程序安全開發(fā)流程程序安全開發(fā)流程 業(yè)界思路 開始 獲取和開 發(fā) 執(zhí)行 操作與維 護 發(fā)布階部 署段 培訓需求 設計實施測試發(fā)布響應 主流廠商和組織通過安全開發(fā)生命周期改進 微軟 SDL 設計驗證滲透測 試 安全開發(fā)流程 安全開發(fā)工具 安全開 發(fā) 安全需求 威脅建模 安全設 計 CSDL OWASP TOP 10 通過評估風險改進 推薦安全的開發(fā)模式推薦安全的開發(fā)模式 需求需求設計設計實施實施測試測試 發(fā)布和發(fā)布和 響應響應 安全需求 分析 攻擊面分析 威脅建模 安全設計原 則 靜態(tài)分析 Fuzzing 測試 基線檢測 滲透測試 應急響應 系統(tǒng)監(jiān)控 開發(fā)安全規(guī) 范 培訓與教育 安全設計方

43、案 如果數(shù)據(jù)在傳如果數(shù)據(jù)在傳 輸過程中沒有輸過程中沒有 加密，就有可加密，就有可 能被截獲、篡能被截獲、篡 改改 需求需求 采用采用HTTPS 對通信數(shù)據(jù)進對通信數(shù)據(jù)進 行加密，以保行加密，以保 障數(shù)據(jù)的保密障數(shù)據(jù)的保密 性性 設計設計 避免使用特定避免使用特定 的危險的危險API如如 strcpy, sprintf, 避免緩沖區(qū)溢避免緩沖區(qū)溢 出漏洞出漏洞 實施實施 通過動態(tài)構建通過動態(tài)構建 SQL語句以證語句以證 明對用戶輸入明對用戶輸入 進行了過濾以進行了過濾以 避免了避免了SQL注注 入攻擊入攻擊 測試測試 入侵者通過入侵者通過 JSP程序提交程序提交 上傳了頁面文上傳了頁面文 件，清

44、除木馬件，清除木馬 程序并提供整程序并提供整 改建議改建議 應急應急 安全編程規(guī)范安全技術講解安全測試原理持續(xù)安全學習 SSDLC 需求分析需求分析 設計設計 實現(xiàn)實現(xiàn)測試測試 安全需求工程 設計安全 發(fā)布發(fā)布 安全編碼 補丁管理 配置加固 軟件黑盒測試 滲透性測試 代碼安全審計 安全軟件開發(fā)生命周期依然是Web安全的基石。 編碼階段：輸入過濾、輸入編碼、 輸出過濾、輸出編碼 測試階段：代碼審計、XSS測試等， 可手工也可以結合自動工具 部署階段：IDS/IPS、Web應用防 火墻、客戶端瀏覽器安全加固 SSDLC過程簡介 n安全需求階段： 分析系統(tǒng)面向的環(huán)境，需求和安全成本，定義自身業(yè)務系統(tǒng)

45、或產(chǎn)品的安全功能 n安全設計： 通過威脅建模，找到攻擊界面，分析和歸類安全威脅，漏洞形式，針對安全需求 ，提出緩解和降低安全威脅的措施，同時定義強制的安全策略：包括最小攻擊界 面，默認配置打開功能和特權等。 n安全實現(xiàn)： 通過編程規(guī)約和培訓開發(fā)人員，配合源代碼審計工具，保證代碼都是以良好的安 全習慣得以實施，減少安全問題。 n安全驗證： 通過安全測試，確保安全需求定義的安全功能，安全設計中定義的安全策略和威 脅緩解措施都得以實現(xiàn)。同時通過測試盡量找出實現(xiàn)中可定性的安全漏洞（攻擊 點），提供給開發(fā)團隊修復，最大的避免產(chǎn)品發(fā)布后的0DAY帶來的安全損失。 n安全發(fā)布階段： 指導用戶安全部署，提供應

46、急響應計劃，實施最終安全復查 安全需求安全需求需求描述需求描述實現(xiàn)階段實現(xiàn)階段 身份驗證身份驗證 啟用身份認證功能、口令策略、賬號鎖定、驗證碼等功能 在設計階段提出身份驗證的要求，在測試階段完成有效性驗 證 會話管理會話管理 嚴格會話管理，確保會話的安全性、唯一性、完整性 在設計階段提出會話管理的開發(fā)要求，在測試階段對會話管 理的可用性進行測試。 訪問控制訪問控制 程序設計時，需要限制對連接數(shù)、內(nèi)存、文件等資源的訪問 設計階段提出訪問控制的開發(fā)要求，在測試階段對可用性等 進行有效性測試。 權限管理權限管理 應用程序需具備賬號管理功能，不同賬號、不同角色具備不 同權限 在設計階段提出權限管理的開

47、發(fā)要求，在測試階段驗證授權 管理的有效性。 數(shù)據(jù)保護數(shù)據(jù)保護 敏感信息、配置文件等重要信息的保存、通信。 在設計階段提出數(shù)據(jù)存儲與傳輸?shù)拈_發(fā)要求，在測試階段驗 證授權管理的有效性。 安全審計安全審計 應用程序需支持記錄程序啟動、關閉事件、應用程序訪問事 件、程序出錯事件等。 設計階段提出日志記錄的開發(fā)要求，測試階段完成日志審計 有效性、完整性測試。 輸入驗證輸入驗證 對客戶端提交的輸入，后臺程序進行嚴格的檢查。實現(xiàn)階段提出具體要求。 輸出處理輸出處理 應用程序需要限制輸出的內(nèi)容，特別是敏感信息、錯誤信息、 用戶輸入的內(nèi)容。 實現(xiàn)階段提出具體要求。 白盒測試、黑白盒測試、黑 盒測試盒測試 需要檢

48、查應用程序開發(fā)的過程中，特意留下可繞過系統(tǒng)安全 控制的功能或超級口令； 測試階段提出具體要求。 內(nèi)存管理內(nèi)存管理 程序需具有內(nèi)存管理和控制的功能，限制惡意的使用。實現(xiàn)階段提出具體要求。 異常處理異常處理 程序在出現(xiàn)異常時，應具有避免信息泄露的措施。實現(xiàn)階段完成異常管理的要求。 在開發(fā)時就應考慮到安全功能安全模塊在開發(fā)時就應考慮到安全功能安全模塊 用戶身份認證的強度設計用戶身份認證的強度設計 對高價值交易和進入保護區(qū)域的用戶需要進行對高價值交易和進入保護區(qū)域的用戶需要進行 重新認證重新認證 認證失敗后的處理方式設計認證失敗后的處理方式設計 使用強口令策略使用強口令策略 使用圖片驗證碼使用圖片驗證

49、碼 敏感信息加密處理敏感信息加密處理 安全設計階段：身份認證的設計安全設計階段：身份認證的設計 安全設計階段：安全設計階段：身份認證缺陷導致手機密碼被破解身份認證缺陷導致手機密碼被破解 限制普通用戶對資源的訪問；限制普通用戶對資源的訪問； 應用軟件啟動權限最小化應用軟件啟動權限最小化 敏感功能敏感功能IP地址控制地址控制 盡量采用統(tǒng)一的訪問控制機制盡量采用統(tǒng)一的訪問控制機制 資源請求數(shù)量限制資源請求數(shù)量限制 在服務器端實現(xiàn)訪問控制在服務器端實現(xiàn)訪問控制 安全設計階段：訪問控制設計安全設計階段：訪問控制設計 安全設計階段：資源限制訪問安全設計階段：資源限制訪問 限制會話壽命限制會話壽命 確保會話

50、的安全創(chuàng)建確保會話的安全創(chuàng)建 確保會話數(shù)據(jù)的存儲安全確保會話數(shù)據(jù)的存儲安全 確保會話的安全終止確保會話的安全終止 WEB頁面應避免跨站請求偽造頁面應避免跨站請求偽造 WEB系統(tǒng)確保會話憑證的安全系統(tǒng)確保會話憑證的安全 安全設計階段：會話管理設計安全設計階段：會話管理設計 盡量避免明文存儲機密信息盡量避免明文存儲機密信息 避免在代碼中存儲機密信息避免在代碼中存儲機密信息 WEB系統(tǒng)，不要在永久性系統(tǒng)，不要在永久性 cookie 中存儲敏感數(shù)據(jù)中存儲敏感數(shù)據(jù) WEB系統(tǒng)，不要使用系統(tǒng)，不要使用 HTTP-GET 協(xié)議傳遞敏感數(shù)據(jù)協(xié)議傳遞敏感數(shù)據(jù) 避免在配置文件中明文存儲數(shù)據(jù)庫連接、口令或密鑰避免在

51、配置文件中明文存儲數(shù)據(jù)庫連接、口令或密鑰 確保通信通道的安全確保通信通道的安全 禁止自創(chuàng)加密算法禁止自創(chuàng)加密算法 安全設計階段：數(shù)據(jù)存儲與傳輸?shù)脑O計安全設計階段：數(shù)據(jù)存儲與傳輸?shù)脑O計 n審計日志應包含時間、內(nèi)容、來源等關鍵要素審計日志應包含時間、內(nèi)容、來源等關鍵要素 n審計日志應禁止包含用戶口令等隱私信息審計日志應禁止包含用戶口令等隱私信息 限制對日志數(shù)據(jù)的訪問。應將有權操作日志數(shù)據(jù)的個人數(shù)量減到最 小。只為高度信任的帳戶（如管理員）授予訪問權限。 支持定期備份和日志數(shù)據(jù)的分析 n確保日志數(shù)據(jù)的安全確保日志數(shù)據(jù)的安全 日志文件禁止存放在WEB網(wǎng)頁目錄下，防止客戶端能夠訪問到日 志 根據(jù)業(yè)務平臺

52、的重要性，設定日志存儲保留的時間。 n防止業(yè)務日志欺騙防止業(yè)務日志欺騙 安全設計階段：日志設計安全設計階段：日志設計 n對所有的輸入進行安全驗證對所有的輸入進行安全驗證 p要對所有來源不在可信任范圍之內(nèi)的輸入進行驗證，包括來自于用戶、服務、共享文件、用戶和數(shù)據(jù)庫的輸入。 p對WEB系統(tǒng)，需要驗證HTTP請求消息的全部字段，例如：GET數(shù)據(jù)和POST數(shù)據(jù)，COOKIE和Header數(shù)據(jù)等。 p驗證除數(shù)據(jù)內(nèi)容外，需限定數(shù)據(jù)的大小或長度。 p驗證所有輸出到客戶端的內(nèi)容，輸出數(shù)據(jù)HTML編碼. n盡量采用集中驗證方法盡量采用集中驗證方法 p如條件允許，將輸入驗證策略作為應用程序設計的核心元素，并采用集

53、中式驗證方法，例如，可通過使用共享庫中的公 共驗證模塊。這可確保驗證規(guī)則的一致性。此外還能減少開發(fā)的工作量，且有助于后期的維護工作。 p對于WEB應用，需要編寫統(tǒng)一的對于客戶端提交數(shù)據(jù)的驗證接口，集中處理輸入數(shù)據(jù)。 n應采用嚴格的輸入驗證的方法：應采用嚴格的輸入驗證的方法： p驗證數(shù)據(jù)類型，例如預期輸入類型為整數(shù)，則需要禁止輸入英文字符串。 p驗證數(shù)據(jù)長度是否在預期長度范圍內(nèi)。 p驗證數(shù)值類型是否在預期大小邊界內(nèi)。 p對WEB應用，檢查數(shù)據(jù)是否包含特殊字符，如：、 、 、%、 (、)、 &、+、等。 p盡量使用白名單進行輸入檢查。 n需在服務器端進行驗證需在服務器端進行驗證 客戶端腳本可以被篡

54、改，如果為了顧全體驗，部分重要數(shù)據(jù)一定要用服務器驗證。 n注意規(guī)范化問題注意規(guī)范化問題 n確保用戶沒有繞過檢查確保用戶沒有繞過檢查 安全實現(xiàn)階段：輸入驗證安全實現(xiàn)階段：輸入驗證 安全實現(xiàn)階段：減少不必要輸入點安全實現(xiàn)階段：減少不必要輸入點 安全實現(xiàn)階段：可以任意輸入積分安全實現(xiàn)階段：可以任意輸入積分 安全實現(xiàn)階段：積分驗證不允分安全實現(xiàn)階段：積分驗證不允分 安全實現(xiàn)階段：積分驗證不允分安全實現(xiàn)階段：積分驗證不允分 n最小化數(shù)據(jù)庫賬號權限最小化數(shù)據(jù)庫賬號權限 p應用軟件使用的數(shù)據(jù)庫賬號必須是普通權限帳戶，且只能訪問允許的數(shù)據(jù)庫； n嚴格控制對數(shù)據(jù)庫的查詢等操作嚴格控制對數(shù)據(jù)庫的查詢等操作 p應使用支持嚴格數(shù)據(jù)類型驗證的參數(shù)化查詢方式（如prepareStatement），使查詢和數(shù) 據(jù)分離?；蛘?，對數(shù)據(jù)庫SQL語句中的來自于不可信任范圍內(nèi)的輸入?yún)?shù)進行驗證。 n驗證數(shù)據(jù)庫返回的數(shù)據(jù)驗證數(shù)據(jù)庫返回的數(shù)據(jù) p要求對來自數(shù)據(jù)庫的數(shù)據(jù)進行驗證，確保其格式正確且能夠安全的使用，不能盲目的信 賴數(shù)據(jù)庫。 n確保釋放數(shù)據(jù)庫資源。確保釋放數(shù)據(jù)庫資源。 安全實現(xiàn)階段：訪問數(shù)據(jù)庫安全實現(xiàn)階段：訪問數(shù)據(jù)庫 n限制文件上傳限制文件上傳 盡量不向