? ? ?本來想自己梳理的欺殿，發(fā)現(xiàn)業(yè)界大佬寫的太好了寄纵，超全Web漏洞詳解及其對應(yīng)的安全編碼規(guī)則，包括：SQL注入脖苏、XSS程拭、CSRF、文件上傳棍潘、路徑遍歷恃鞋、越權(quán)、XML以及業(yè)務(wù)安全等亦歉，實例告訴你各個漏洞對應(yīng)的編碼規(guī)則恤浪。給你的代碼加把安全鎖！
文章目錄
一齿诉、Web安全基礎(chǔ)
1.1?常見的Web安全漏洞
1.2?安全編碼原則
一切輸入都是有害的！Ｉ我Α粤剧！輸出也不安全！
輸入：傳參挥唠，cookie抵恋、session、http header宝磨、數(shù)據(jù)庫……
輸出：異常信息弧关、敏感信息、xss
沒有絕對的安全……
1.3 數(shù)據(jù)驗證
1.4?身份認證&會話管理
1.5?授權(quán)管理
1.6 存儲安全
二唤锉、SQL注入及其安全編碼
2.1 定義
SQL注入的定義
由于程序中對用戶輸入檢查不嚴格世囊，用戶可以提交一段數(shù)據(jù)庫查詢代碼，根據(jù)程序返回的結(jié)果窿祥，獲得某些他想得知的數(shù)據(jù)株憾，這就是所謂的SQL Injection，即SQL注入晒衩。
SQL注入的本質(zhì)
對于輸入檢查不充分嗤瞎，導(dǎo)致SQL語句將用戶提交的非法數(shù)據(jù)當作語句的一部分來執(zhí)行墙歪。
SQL注入漏洞，就是將用戶可控的數(shù)據(jù)拼接進了SQL語句中猫胁，一起提交到了數(shù)據(jù)庫執(zhí)行箱亿。
攻擊者通過注入語句跛锌，改變SQL語句執(zhí)行邏輯弃秆，通過控制部分SQL語句，攻擊者可以查詢數(shù)據(jù)庫中任何自己需要的數(shù)據(jù)髓帽，利用數(shù)據(jù)庫的一些特性菠赚，可以直接獲取數(shù)據(jù)庫服務(wù)器的系統(tǒng)權(quán)限。
某銀行信用卡商城SQL注入漏洞
https://shop.***.com.cn/BusinessCityWeb/ecity.do?func=queryClassFun&dom=<request><queryClass currpage=”1″ rowspage=”20″ sorttype=”0″ brand=”043″ goods_price=”0|300″ goods_nm=”” color=”” type_pid=”” type_id=”” querytype=”brandForColor”/></request>中參數(shù)goods_price郑藏、brand存在SQL注入漏洞衡查；
某輸入法網(wǎng)站Ajax頁面POST型SQL注入漏洞
該網(wǎng)站的Ajax頁面是http://***.***.com/zt/acgn/pc/ajax_post.php，POST內(nèi)容為：qq=CasterJs&type=pc&nickname=CasterJs&entries=CasterJs必盖，Web應(yīng)用程序未過濾參數(shù)type拌牲，導(dǎo)致存在POST型注入漏洞。使用sqlmap工具歌粥，可以注入得到數(shù)據(jù)庫名
2.2?經(jīng)典SQL注入代碼示例
1）Servlet示例
2）mybatis示例
2.3?文藝的SQL注入
a）用戶注冊頁面將用戶數(shù)據(jù)存入數(shù)據(jù)庫
b）從數(shù)據(jù)庫中取出用戶名塌忽，根據(jù)用戶名查詢其他信息
2.4 SQL注入防護
a)對輸入點進行過濾（不是根本解決方法 可能被繞過）
建議使用ESAPI針對輸入數(shù)據(jù)進行過濾。
b）預(yù)編譯方式訪問數(shù)據(jù)庫
預(yù)編譯本質(zhì)上也是對參數(shù)的過濾失驶，只不過由官方實現(xiàn)土居。
/JavaVulnerableLab/vulnerability/sqli/download_id.jsp?fileid=1
c）使用存儲過程
2.5?MyBatis的SQL注入防護
模糊查詢：
MySQL：select * from table where name like concat(‘%’,#{name},’%’)
Oracle：select * from table where name like ‘%’ || #{name} || ’%’
SQL Server：select * from table where name like ‘%’+#{name}+’%’
DB2：select * from table where name like concat(‘%’,#{name},’%’)
三、跨站腳本攻擊及其安全編碼
3.1 定義
XSS（Cross Site Script）漏洞嬉探，從本質(zhì)上來說就是將數(shù)據(jù)注入到了靜態(tài)腳本代碼中（HTML或者Javascript等）擦耀，當瀏覽器渲染整個HTML文檔的過程中觸發(fā)了注入的腳本，導(dǎo)致了XSS攻擊的發(fā)生涩堤。
String title =?request.getParameter(“title”);
String id =?request.getParameter(“id”);
….
?<%=title%></span>
?<%=contect%></span>
XSS不止可以彈窗……
3.2 XSS攻擊模式
3.3 XSS的利用
某生活網(wǎng)站存在反射型眷蜓、存儲型跨站腳本攻擊
在wap頁面的網(wǎng)友中心發(fā)表提問頁面中，應(yīng)用程序?qū)τ脩舻妮斎脒^濾不嚴格胎围，導(dǎo)致存在存儲型跨站腳本攻擊账磺，攻擊者在標題處構(gòu)造跨站腳本”<img src=@ onerror=alert(19)>”
提交問題后回到“我的帖子”頁面，可以看到跨站腳本被執(zhí)行痊远，彈出“19”窗口垮抗，
3.4 XSS的分類
Reflected XSS (Non-persist XSS)
跨站代碼一般存在于鏈接中，請求這樣的鏈接時碧聪，跨站代碼經(jīng)過服務(wù)端反射回來冒版，這類跨站的代碼一般不存儲到服務(wù)端
Stored XSS (Persist XSS)
這是利用起來最方便的跨站類型，跨站代碼存儲于服務(wù)端（比如數(shù)據(jù)庫中）
DOM based XSS
一種基于DOM的跨站逞姿，這是客戶端腳本自身解析不正確導(dǎo)致的安全問題
3.5?跨站腳本攻擊
a)?存儲型跨站腳本攻擊
b）反射型跨站腳本攻擊
<%out.print(request.getParameter(“param”)); %>
3.6?跨站腳本攻擊防護
對輸出數(shù)據(jù)使用HtmlEncoder對一些字符做轉(zhuǎn)義處理
a)?全局攔截 （全局過濾器辞嗡、攔截器）捆等，適用于不包含富文本的情況
Servlet的doFilter、Spring的Interceptor類续室，對所有的訪問請求進行監(jiān)聽栋烤。正確的姿勢是在過濾器中對<>&’”=等字符轉(zhuǎn)義處理，可使用ESAPI或者common-lang.jar的StringEscapeUtils類或者Spring的HtmlUtils來實現(xiàn)挺狰。
b)富文本交互明郭，白名單過濾
ESAPI.validator().getValidSafeHTML(“getValidSafeHTML”, keyword, keyword.length(), true)
白名單：JavaVulnerableLab/vulnerability/xss/xss4.jsp
3.7?XSS防護—Spring MVC
a)項目級過濾
defaultHtmlEscape
true
b)頁面級過濾
在包含form的jsp頁面中添加
<spring:htmlEscape?defaultHtmlEscape=”true”?/>
c)表單元素級過濾
在form元素中添加
<form:form?htmlEscape=“true”>或
<form:input?path=”someFormField”?htmlEscape=”true”?/>
四、跨站請求偽造及其安全編碼
4.1 定義
Cross-site Request Forgery
–在某個惡意站點的頁面上丰泊，促使訪問者請求被攻擊網(wǎng)站的某個 URL薯定，從而達到改變服務(wù)器端數(shù)據(jù)的目的
攻擊者盜用了你的身份，以你的名義發(fā)送惡意請求
–誕生于2000年瞳购，火于2007/2008年
–90%的網(wǎng)站存在此類漏洞
–特征為目標站點無token或者referer限制
–利用方式分GET與POST兩種
CSRF 與 XSS的區(qū)別话侄？
Csrf的破壞力取決于受害者的權(quán)限，與瀏覽器機制有關(guān)学赛。
CSRF年堆，跨站請求偽造(Cross Site Request Forgery)
在用戶會話下對某個請求發(fā)出GET/POST請求，而請求并非用戶自愿發(fā)出
網(wǎng)站通過cookie識別用戶盏浇，當用戶在某網(wǎng)站成功進行身份驗證后变丧，瀏覽器會得到一個標識其身份的cookie。只要不關(guān)閉瀏覽器或退出登錄缠捌，以后訪問這個網(wǎng)站都會帶上這個cookie
如果這期間被人誘騙請求了這個網(wǎng)站的url锄贷，則相當于發(fā)出了身份認證后的請求，可能會執(zhí)行一些用戶不想做的敏感操作
4.2 CSRF攻擊過程
目標網(wǎng)站：www.webA.com
惡意網(wǎng)站：www.webB.com
轉(zhuǎn)賬功能鏈接：
http://www.webA.com/transport?account=abc&total=500
惡意網(wǎng)站www.webB.com某CSRF頁面：
<script>
new Image().src=’http://www.webA.com/transport?account=abc&total=500’;
</script>
誘騙受害用戶訪問惡意網(wǎng)站CSRF頁面
4.3 CSRF的危害
盜取目標網(wǎng)站上用戶隱私數(shù)據(jù)
篡改目標網(wǎng)站上用戶數(shù)據(jù)
傳播CSRF蠕蟲
…
CSRF的應(yīng)用與危害要取決于其場景曼月。對于開源的谊却、多用戶的、以及社交網(wǎng)站哑芹，CSRF攻擊帶來的后果可能非常嚴重炎辨，且此時CSRF可以直接攻擊管理員后臺。然而對于閉源的聪姿、宣傳冊式的網(wǎng)站碴萧，CSRF造成的危害相對要小的多。因為此時攻擊者并不清楚后臺的情況末购，且由于此類網(wǎng)站用戶數(shù)量很少破喻，基本不能對其他用戶產(chǎn)生攻擊。
4.4CSRF攻擊分析
從上圖可以看出盟榴，要完成一次CSRF攻擊曹质，受害者必須依次完成兩個步驟：
1.登錄受信任網(wǎng)站A，并在本地生成Cookie。
2.在不登出A的情況下羽德，訪問危險網(wǎng)站B几莽。
你不能保證你登錄了一個網(wǎng)站后，不再打開一個tab頁面并訪問另外的網(wǎng)站宅静。
你不能保證你關(guān)閉瀏覽器了后章蚣，你本地的Cookie立刻過期，你上次的會話已經(jīng)結(jié)束姨夹。（事實上纤垂，關(guān)閉瀏覽器不能結(jié)束一個會話，但大多數(shù)人都會錯誤的認為關(guān)閉瀏覽器就等于退出登錄/結(jié)束會話了……）
3.上圖中所謂的攻擊網(wǎng)站匀伏，可能是一個存在其他漏洞的可信任的經(jīng)常被人訪問的網(wǎng)站
4.4 CSRF缺陷代碼
A站點：
String user = request.getParameter(“user”);
String pass = request.getParameter(“pass”);
PreparedStatement ps = con.prepareStatement(“update UserTB set password=?? Where user=?”);
ps.setString(1,user);
ps.setString(2,pass);
con.executeUpdate();
惡意站點上的代碼
GET方式
<img src=http://siteA/updateuser.jsp?user=admin&pass=123456>
POST方式
<form action=http://siteA/updateuser.jsp method=POST>
<input type=”text” name=”user” value=”admin” />
<input type=”text” name=”pass” value=”123456″ />
</form>
<script> document.forms[0].submit(); </script>
4.5 CSRF解決方案
判斷HTTP Referer
圖形驗證碼
使用隱藏的tonken?hash做校驗
4.5.1?檢測referer
HTTP Referer是header的一部分洒忧，當瀏覽器向web服務(wù)器發(fā)送請求的時候蝴韭，一般會帶上Referer够颠，告訴服務(wù)器我是從哪個頁面鏈接過來的
request.getHeader(“REFERER“);
通過檢查Referer的值，我們就可以判斷這個請求是合法的還是非法的榄鉴，但是問題出在服務(wù)器不是任何時候都能接受到Referer的值履磨，所以Refere Check 一般用于監(jiān)控CSRF攻擊的發(fā)生，而不用來抵御攻擊庆尘。
合規(guī)代碼示例
4.5.2?CSRF Token使用原則
Token要足夠隨機–只有這樣才算不可預(yù)測
Token是一次性的剃诅，即每次請求成功后要更新Token–這樣可以增加攻擊難度，增加預(yù)測難度
Token要注意保密性–敏感操作使用post驶忌，防止Token出現(xiàn)在URL中
如果同域下存在xss的話矛辕，除了驗證碼，其他的方式都無法防御這個問題付魔。
防護csrf的措施雖然很多聊品，但歸根到底就是一條：在客戶端提交請求時增加偽造隨機數(shù)。有個程序后端可能是用REQUEST方式接受的几苍，而程序默認是POST請求翻屈，其實改成GET方式請求也可以發(fā)送過去，存在很嚴重的隱患妻坝。
五伸眶、文件上傳及其安全編碼
5.1 非法文件上傳
非法文件上傳產(chǎn)生的主要原因就是在服務(wù)器端沒有對用戶上傳的文件類型做校驗或者校驗不完整，導(dǎo)致用戶可以上傳惡意腳本到服務(wù)器刽宪。
5.2?文件上傳防護
1厘贼、白名單檢查文件擴展名，不屬于白名單內(nèi)的圣拄，不允許上傳嘴秸。
2、上傳文件的保存目錄不可解析jsp、php等腳本語言
3赁遗、文件名隨機命名署辉。如UUID、GUID岩四，不允許用戶自定義哭尝。
4、如果允許剖煌，對上傳的圖片文件進行渲染
5材鹦、記錄日志
六、路徑遍歷漏洞及其安全編碼
6.1 定義
路徑遍歷漏洞成因：服務(wù)器端耕姊，接收請求中傳來的文件名稱桶唐，在服務(wù)器端拼湊成文件的絕對路徑，并且用輸出流下載茉兰。
某網(wǎng)上銀行系統(tǒng)任意文件下載漏洞
訪問鏈接：http://econline.***.com.cn:8080/NASApp/iTreasury-ebank/DownloadFile.web?fileName=/etc/passwd
6.2?路徑遍歷防護
方案一：
1尤泽、要下載的文件地址保存至數(shù)據(jù)庫中。
2规脸、文件ID使用隨機數(shù)命名
3坯约、文件路徑保存至數(shù)據(jù)庫，用戶提交文件對應(yīng)ID下載文件莫鸭。
4闹丐、下載文件之前做權(quán)限判斷。
5被因、記錄文件下載日志卿拴。
方案二：
針對文件的訪問，直接給出文件路徑的鏈接梨与。如：
<a href=“http://xx.xx.xx.xx/upload/file1.jpg”>
七堕花、越權(quán)漏洞及其安全編碼
7.1 定義
垂直越權(quán)漏洞，也稱為權(quán)限提升蛋欣，是一種“基于URL的訪問控制”設(shè)計缺陷引起的漏洞航徙。由于Web應(yīng)用程序沒有做權(quán)限控制或者僅在菜單上做了權(quán)限控制，導(dǎo)致惡意用戶只要猜測其他管理頁面的URL陷虎，就可以訪問或控制其他角色擁有的數(shù)據(jù)或頁面到踏，達到權(quán)限提升的目的。
水平越權(quán)漏洞尚猿，是一種“基于數(shù)據(jù)的訪問控制”設(shè)計缺陷引起的漏洞窝稿。由于服務(wù)器端在接收到請求數(shù)據(jù)進行操作時沒有判斷數(shù)據(jù)的所屬人而導(dǎo)致的越權(quán)數(shù)據(jù)訪問漏洞。如服務(wù)器端從客戶端提交的request參數(shù)（用戶能夠控制的數(shù)據(jù)）中獲取用戶id凿掂，惡意攻擊者通過變換請求ID的值伴榔，查看或修改不屬于本人的數(shù)據(jù)纹蝴。
7.1.1 垂直越權(quán)漏洞
7.1.2 水平越權(quán)漏洞
越權(quán)刪除用戶地址
某銀行水平越權(quán)遍歷其它賬號的余額
該銀行越權(quán)漏洞存在于涉及轉(zhuǎn)賬匯款的地方，選擇付款賬戶時系統(tǒng)會先查詢賬戶的余額踪少，在此處通過遍歷賬號即可獲取到其他人的賬戶余額塘安，使用burpsuite的intruder功能遍歷accountNo查詢他人賬戶余額
7.2?越權(quán)漏洞防護
7.2.1 垂直越權(quán)漏洞
垂直越權(quán)漏洞：在調(diào)用功能之前，驗證當前用戶身份是否有權(quán)限調(diào)用相關(guān)功能（推薦使用過濾器援奢，進行統(tǒng)一權(quán)限驗證）
垂直越權(quán)漏洞防護方案：通過全局過濾器來檢測用戶是否登錄兼犯，是否對資源具有訪問權(quán)限。
將權(quán)限訪問規(guī)則存入privilege.properties文件中
在web.xml中配置過濾器及權(quán)限配置文件集漾。
Spring MVC訪問控制
Spring Security也提供了“基于URL的訪問控制”和“基于Method的訪問控制”切黔。
7.2.2 水平越權(quán)漏洞
水平越權(quán)漏洞：在用戶進行操作時，從session中獲取用戶id具篇，將傳入的參數(shù)與用戶的身份做綁定校驗纬霞。
八、XML外部實體注入及其安全編碼
8.1?XXE->XML外部實體注入
XXE（XML External Entity Injection）是一種針對XML終端實施的攻擊驱显，黑客想要實施這種攻擊诗芜，需要在XML的payload包含外部實體聲明，且服務(wù)器本身允許實體擴展秒紧。這樣的話绢陌，黑客或許能讀取WEB服務(wù)器的文件系統(tǒng)挨下，通過UNC路徑訪問遠程文件系統(tǒng)熔恢，或者通過HTTP/HTTPS連接到任意主機。
8.2?XXE-利用方法
XML實體注入產(chǎn)生的根本原因就是在XML1.0標準中引入了“entity”這個概念臭笆，且“entity”可以在預(yù)定義的文檔中進行調(diào)用叙淌，XXE漏洞的利用就是通過實體的標識符訪問本地或者遠程內(nèi)容。
帶回顯的利用方式：直接讀取本地文件
Bland XXE：服務(wù)器禁用了外部實體或者做了過濾或者是顯示限制
拒絕服務(wù)攻擊
8.3?XXE-經(jīng)典漏洞代碼
使用org.w3c.dom包來解析xml數(shù)據(jù)
8.4 XXE安全防護
方案一：
通過傳參的方式發(fā)送數(shù)據(jù)愁铺；
后臺對數(shù)據(jù)ESAPI的encoder接口對數(shù)據(jù)轉(zhuǎn)碼處理鹰霍，然后進行XML數(shù)據(jù)格式化。
方案二：
通過DocumentBuilderFactory 的setFeature對XML解析進行限制茵乱。如：
設(shè)置http://apache.org/xml/features/disallow-doctype-decl為true
??設(shè)置http://xml.org/sax/features/external-general-entities為false
設(shè)置http://xml.org/sax/features/external-parameter-entities為false
??設(shè)置http://apache.org/xml/features/nonvalidating/load-external-dtd為false
其他：
setXIncludeAware(false)
setExpandEntityReferences(false)
參考代碼：
九茂洒、業(yè)務(wù)安全
在電子銀行系統(tǒng)中，除了常規(guī)的如SQL瓶竭，XSS督勺，CSRF、XXE等web漏洞外斤贰，更重要的是其業(yè)務(wù)上的安全智哀。銀行業(yè)務(wù)直接關(guān)系到用戶的經(jīng)濟利益，因而保證其業(yè)務(wù)上的安全及其重要荧恍。
?分類
賬戶信息安全
業(yè)務(wù)數(shù)據(jù)安全
業(yè)務(wù)流程安全
業(yè)務(wù)接口安全
9.1 賬戶信息安全
賬戶是一個系統(tǒng)的入口瓷叫，關(guān)系到用戶最直接的利益，因而賬戶的安全在業(yè)務(wù)安全中占及其重要的地位。賬戶體系分多個層次摹菠，每個環(huán)節(jié)的漏洞盒卸，都將給用戶帶來極大的損失。
?分類
信息查詢
撞庫風險
弱密碼
密碼找回
密碼找回憑證太弱次氨，容易被爆破
密碼找回憑證可以從客戶端世落、URL、網(wǎng)頁源代碼中直接獲取
最后提交新密碼時修改用戶ID為其他ID
跳過驗證步驟糟需、找回方式屉佳，直接到設(shè)置新密碼頁面
用戶登錄時依據(jù)cookie中的某字段來區(qū)分賬戶
9.2 業(yè)務(wù)數(shù)據(jù)安全
金額數(shù)據(jù)篡改
抓包修改金額等字段，例如在支付頁面抓取請求中商品的金額字段洲押，修改成任意數(shù)額的金額并提交武花，查看能否以修改后的金額數(shù)據(jù)完成業(yè)務(wù)流程。
商品數(shù)量篡改
抓包修改商品數(shù)量等字段杈帐，將請求中的商品數(shù)量修改成任意數(shù)額体箕，如負數(shù)并提交，查看能否以修改后的數(shù)量完成業(yè)務(wù)流程挑童。
9.3 業(yè)務(wù)流程安全
順序執(zhí)行缺陷
部分網(wǎng)站邏輯可能是先A過程后B過程然后C過程最后D過程累铅。
用戶控制著他們給應(yīng)用程序發(fā)送的每一個請求，因此能夠按照任何順序進行訪問站叼。于是娃兽，用戶就從B直接進入了D過程，就繞過了C尽楔。如果C是支付過程投储，那么用戶就繞過了支付過程而買到了一件商品。如果C是驗證過程阔馋，就會繞過驗證直接進入網(wǎng)站程序了玛荞。
最后提交新密碼時修改用戶ID為其他ID
跳過驗證步驟、找回方式呕寝，直接到設(shè)置新密碼頁面
9.4 業(yè)務(wù)接口安全
重放攻擊
在短信勋眯、郵件調(diào)用業(yè)務(wù)或生成業(yè)務(wù)數(shù)據(jù)環(huán)節(jié)中（類：短信驗證碼，郵件驗證碼下梢，訂單生成客蹋，評論提交等），對其業(yè)務(wù)環(huán)節(jié)進行調(diào)用（重放）測試怔球。如果業(yè)務(wù)經(jīng)過調(diào)用（重放）后被多次生成有效的業(yè)務(wù)或數(shù)據(jù)結(jié)果
?短信炸彈
短信內(nèi)容篡改
短信收件人任意篡改
郵件炸彈
9.5 總結(jié)
怎么防護我們的系統(tǒng)
一切輸入都是有害的~
輸出也不安全~
黑名單說不定哪天就被人繞過了~
十嚼酝、其它
10.1?IP登錄限制繞過
系統(tǒng)根據(jù)客戶端提交的x-forwarded-for值來判斷內(nèi)網(wǎng)登陸還是外網(wǎng)登陸，當客戶端請求攜帶x-forwarded-for值為127.0.0.1時竟坛，可直接使用內(nèi)網(wǎng)登陸方式登陸系統(tǒng)闽巩。
10.2?服務(wù)端請求偽造攻擊
是由于有些應(yīng)用（網(wǎng)頁分享钧舌、站長工具、圖片搜索等）提供了通過URL 獲取其他站點資源的功能涎跨，當這種功能沒有對協(xié)議洼冻、網(wǎng)絡(luò)邊界等做好限制，導(dǎo)致這種功能被濫用隅很，攻擊者可以利用這種缺陷獲取內(nèi)網(wǎng)敏感數(shù)據(jù)撞牢、DOS 內(nèi)網(wǎng)服務(wù)器、獲取內(nèi)網(wǎng)服務(wù)器權(quán)限叔营、讀取文件等屋彪。
1）A 站從瀏覽器獲取到用戶輸入的URL；
2）A 站根據(jù)收到的URL绒尊，向B 站發(fā)送HTTP 請求獲取到響應(yīng)內(nèi)容畜挥；
3）將收到的內(nèi)容返回給瀏覽器。
服務(wù)端請求偽造攻擊防護
過濾內(nèi)網(wǎng)服務(wù)器對公網(wǎng)服務(wù)器請求的響應(yīng)婴谱。如果Web應(yīng)用是獲取某一類型的文件蟹但，在把返回結(jié)果展示給用戶之前應(yīng)先驗證返回的信息是否符合文件類型標準，比如返回信息應(yīng)為圖片谭羔，如果返回信息是HTML华糖，則停止將返回信息返回客戶端。
統(tǒng)一錯誤提示信息瘟裸，避免用戶可以根據(jù)錯誤信息來判斷遠端服務(wù)器的端口狀態(tài)客叉。
在內(nèi)網(wǎng)服務(wù)器的防火墻上限制公網(wǎng)服務(wù)器的請求端口為HTTP等協(xié)議常用端口，如：80景描、443十办、8080、8090超棺。
若公網(wǎng)服務(wù)器的內(nèi)網(wǎng)IP與內(nèi)網(wǎng)無業(yè)務(wù)通信，建議將公網(wǎng)服務(wù)器對應(yīng)的內(nèi)網(wǎng)IP列入黑名單呵燕，避免應(yīng)用被用來獲取內(nèi)網(wǎng)數(shù)據(jù)棠绘。
內(nèi)網(wǎng)服務(wù)器禁用不必要的協(xié)議，僅允許HTTP和HTTPS請求再扭，防止類似于file:///氧苍、gopher://、ftp:// 等協(xié)議引起的安全問題泛范。
10.3 異常調(diào)試信息泄露
代碼中使用e.printStackTrace()打印異常錯誤信息让虐，在系統(tǒng)發(fā)生異常時，如未自定義錯誤頁面罢荡，系統(tǒng)就會將發(fā)生異常的詳細信息打印出來赡突。
10.4?基礎(chǔ)框架漏洞
Struts 2 遠程代碼執(zhí)行漏洞
Java反序列化漏洞
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-----------搬運工
