? ? ?本來想自己梳理的，發(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ù)當(dāng)作語句的一部分來執(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等），當(dāng)瀏覽器渲染整個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)致存在存儲型跨站腳本攻擊，攻擊者在標(biā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)站存在此類漏洞
–特征為目標(biāo)站點無token或者referer限制
–利用方式分GET與POST兩種
CSRF 與 XSS的區(qū)別？
Csrf的破壞力取決于受害者的權(quán)限，與瀏覽器機制有關(guān)。
CSRF，跨站請求偽造(Cross Site Request Forgery)
在用戶會話下對某個請求發(fā)出GET/POST請求，而請求并非用戶自愿發(fā)出
網(wǎng)站通過cookie識別用戶，當(dāng)用戶在某網(wǎng)站成功進行身份驗證后，瀏覽器會得到一個標(biāo)識其身份的cookie。只要不關(guān)閉瀏覽器或退出登錄，以后訪問這個網(wǎng)站都會帶上這個cookie
如果這期間被人誘騙請求了這個網(wǎng)站的url，則相當(dāng)于發(fā)出了身份認證后的請求，可能會執(zhí)行一些用戶不想做的敏感操作
4.2 CSRF攻擊過程
目標(biāo)網(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的危害
盜取目標(biāo)網(wǎng)站上用戶隱私數(shù)據(jù)
篡改目標(biāo)網(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的一部分，當(dāng)瀏覽器向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)用功能之前，驗證當(dāng)前用戶身份是否有權(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標(biāo)準(zhǔn)中引入了“entity”這個概念，且“entity”可以在預(yù)定義的文檔中進行調(diào)用，XXE漏洞的利用就是通過實體的標(biāo)識符訪問本地或者遠程內(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é)的漏洞，都將給用戶帶來極大的損失。
?分類
信息查詢
撞庫風(fēng)險
弱密碼
密碼找回
密碼找回憑證太弱，容易被爆破
密碼找回憑證可以從客戶端、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)登陸，當(dāng)客戶端請求攜帶x-forwarded-for值為127.0.0.1時，可直接使用內(nèi)網(wǎng)登陸方式登陸系統(tǒng)。
10.2?服務(wù)端請求偽造攻擊
是由于有些應(yīng)用（網(wǎng)頁分享、站長工具、圖片搜索等）提供了通過URL 獲取其他站點資源的功能，當(dāng)這種功能沒有對協(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)先驗證返回的信息是否符合文件類型標(biāo)準(zhǔn)，比如返回信息應(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反序列化漏洞
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-----------搬運工
