常見六大Web漏洞介紹和防御方案
原創(chuàng)【51CTO.com原創(chuàng)稿件】在互聯(lián)網(wǎng)時(shí)代，數(shù)據(jù)安全與個(gè)人隱私受到了的挑戰(zhàn)，各種新奇的技術(shù)層出不窮。如何才能更好地保護(hù)我們的數(shù)據(jù)?本文主要側(cè)重于分析幾種常見的類型以及防御的方法。
一、xss
XSS (Cross-Site Scripting)，跨站腳本，因?yàn)榭s寫和 CSS重疊，所以只能叫 XSS?？缯灸_本是指通過存在安全漏洞的Web網(wǎng)站注冊用戶的瀏覽器內(nèi)運(yùn)行非法的HTML標(biāo)簽或JavaScript進(jìn)行的一種。
跨站腳本有可能造成以下影響：
- 利用虛假輸入表單騙取用戶個(gè)人信息。
- 利用腳本竊取用戶的Cookie值，被害者在不知情的情況下，幫助發(fā)送惡意請求。
- 顯示偽造的文章或圖片。
XSS 的原理是惡意往 Web 頁面里插入惡意可執(zhí)行網(wǎng)頁腳本代碼，當(dāng)用戶瀏覽該頁之時(shí)，嵌入其中 Web 里面的腳本代碼會(huì)被執(zhí)行，從而可以達(dá)到盜取用戶信息或其他侵犯用戶安全隱私的目的。
XSS 的方式千變?nèi)f化，但還是可以大致細(xì)分為幾種類型。
1. 非持久型 XSS(反射型 XSS )
非持久型 XSS 漏洞，一般是通過給別人發(fā)送帶有惡意腳本代碼參數(shù)的 URL，當(dāng) URL 地址被打開時(shí)，特有的惡意代碼參數(shù)被 HTML 解析、執(zhí)行。
舉一個(gè)例子，比如頁面中包含有以下代碼：
- <select>
- <script>
- document.write(''
- + '<option value=1>'
- + location.href.substring(location.href.indexOf('default=') + 8)
- + '</option>'
- );
- document.write('<option value=2>English</option>');
- </script>
- </select>
可以直接通過 URL (類似：https://xxx.com/xxx?default= ) 注入可執(zhí)行的腳本代碼。不過一些瀏覽器如Chrome其內(nèi)置了一些XSS過濾器，可以防止大部分反射型XSS。
非持久型 XSS 漏洞有以下幾點(diǎn)特征：
- 即時(shí)性，不經(jīng)過服務(wù)器存儲(chǔ)，直接通過 HTTP 的 GET 和 POST 請求就能完成一次，拿到用戶隱私數(shù)據(jù)。
- 需要誘騙點(diǎn)擊,必須要通過用戶點(diǎn)擊鏈接才能發(fā)起。
- 反饋率低，所以較難發(fā)現(xiàn)和響應(yīng)修復(fù)。
- 盜取用戶敏感保密信息。
為了防止出現(xiàn)非持久型 XSS 漏洞，需要確保這么幾件事情：
- Web 頁面渲染的所有內(nèi)容或者渲染的數(shù)據(jù)都必須來自于服務(wù)端。
- 盡量不要從 URL，document.referrer，document.forms 等這種 DOM API 中獲取數(shù)據(jù)直接渲染。
- 盡量不要使用 eval, new Function()，document.write()，document.writeln()，window.setInterval()，window.setTimeout()，innerHTML，document.createElement() 等可執(zhí)行字符串的方法。
- 如果做不到以上幾點(diǎn)，也必須對涉及 DOM 渲染的方法傳入的字符串參數(shù)做 escape 轉(zhuǎn)義。
- 前端渲染的時(shí)候?qū)θ魏蔚淖侄味夹枰?escape 轉(zhuǎn)義編碼。
2. 持久型 XSS(存儲(chǔ)型 XSS)
持久型 XSS 漏洞，一般存在于 Form 表單提交等交互功能，如文章留言，提交文本信息等，黑客利用的 XSS 漏洞，將內(nèi)容經(jīng)正常功能提交進(jìn)入數(shù)據(jù)庫持久保存，當(dāng)前端頁面獲得后端從數(shù)據(jù)庫中讀出的注入代碼時(shí)，恰好將其渲染執(zhí)行。
舉個(gè)例子，對于評論功能來說，就得防范持久型 XSS ，因?yàn)槲铱梢栽谠u論中輸入以下內(nèi)容：
主要注入頁面方式和非持久型 XSS 漏洞類似，只不過持久型的不是來源于 URL，refferer，forms 等，而是來源于后端從數(shù)據(jù)庫中讀出來的數(shù)據(jù) 。持久型 XSS 不需要誘騙點(diǎn)擊，黑客只需要在提交表單的地方完成注入即可，但是這種 XSS 的成本相對還是很高。
成功需要同時(shí)滿足以下幾個(gè)條件：
- POST 請求提交表單后端沒做轉(zhuǎn)義直接入庫。
- 后端從數(shù)據(jù)庫中取出數(shù)據(jù)沒做轉(zhuǎn)義直接輸出給前端。
- 前端拿到后端數(shù)據(jù)沒做轉(zhuǎn)義直接渲染成 DOM。
持久型 XSS 有以下幾個(gè)特點(diǎn)：
- 持久性，植入在數(shù)據(jù)庫中
- 盜取用戶敏感私密信息
- 危害面廣
3. 如何防御
對于 XSS 來說，通常有兩種方式可以用來防御。
(1) CSP
CSP 本質(zhì)上就是建立白名單，開發(fā)者明確告訴瀏覽器哪些外部資源可以加載和執(zhí)行。我們只需要配置規(guī)則，如何攔截是由瀏覽器自己實(shí)現(xiàn)的。我們可以通過這種方式來盡量減少 XSS 。
通?？梢酝ㄟ^兩種方式來開啟 CSP：
- 設(shè)置 HTTP Header 中的 Content-Security-Policy
- 設(shè)置 meta 標(biāo)簽的方式
這里以設(shè)置 HTTP Header 來舉例：
- 只允許加載本站資源
- Content-Security-Policy: default-src 'self'
- 只允許加載 HTTPS 協(xié)議圖片
- Content-Security-Policy: img-src https://*
- 允許加載任何來源框架
- Content-Security-Policy: child-src 'none'
如需了解更多屬性，請查看Content-Security-Policy文檔。
對于這種方式來說，只要開發(fā)者配置了正確的規(guī)則，那么即使網(wǎng)站存在漏洞，也不能執(zhí)行它的代碼，并且 CSP 的兼容性也不錯(cuò)。
(2) 轉(zhuǎn)義字符
用戶的輸入永遠(yuǎn)不可信任的，最普遍的做法就是轉(zhuǎn)義輸入輸出的內(nèi)容，對于引號、尖括號、斜杠進(jìn)行轉(zhuǎn)義。
- function escape(str) {
- strstr = str.replace(/&/g, '&')
- strstr = str.replace(/</g, '<')
- strstr = str.replace(/>/g, '>')
- strstr = str.replace(/"/g, '&quto;')
- strstr = str.replace(/'/g, ''')
- strstr = str.replace(/`/g, '`')
- strstr = str.replace(/\//g, '/')
- return str
- }
但是對于顯示富文本來說，顯然不能通過上面的辦法來轉(zhuǎn)義所有字符，因?yàn)檫@樣會(huì)把需要的格式也過濾掉。對于這種情況，通常采用白名單過濾的辦法，當(dāng)然也可以通過黑名單過濾，但是考慮到需要過濾的標(biāo)簽和標(biāo)簽屬性實(shí)在太多，更加推薦使用白名單的方式。
- const xss = require('xss')
- let html = xss('<h1 id="title">XSS Demo</h1><script>alert("xss");</script>')
- // -> <h1>XSS Demo</h1><script>alert("xss");</script>
- console.log(html)
以上示例使用了 js-xss 來實(shí)現(xiàn)，可以看到在輸出中保留了 h1 標(biāo)簽且過濾了 script 標(biāo)簽。
(3) HttpOnly Cookie
這是預(yù)防XSS竊取用戶cookie最有效的防御手段。Web應(yīng)用程序在設(shè)置cookie時(shí)，將其屬性設(shè)為HttpOnly，就可以避免該網(wǎng)頁的cookie被客戶端惡意JavaScript竊取，保護(hù)用戶cookie信息。
二、CSRF
CSRF(Cross Site Request Forgery)，即跨站請求偽造，是一種常見的Web，它利用用戶已登錄的身份，在用戶毫不知情的情況下，以用戶的名義完成非法操作。
1. CSRF的原理
下面先介紹一下CSRF的原理：
完成 CSRF 必須要有三個(gè)條件：
- 用戶已經(jīng)登錄了站點(diǎn) A，并在本地記錄了 cookie
- 在用戶沒有登出站點(diǎn) A 的情況下(也就是 cookie 生效的情況下)，訪問了惡意提供的引誘危險(xiǎn)站點(diǎn) B (B 站點(diǎn)要求訪問站點(diǎn)A)。
- 站點(diǎn) A 沒有做任何 CSRF 防御
我們來看一個(gè)例子： 當(dāng)我們登入轉(zhuǎn)賬頁面后，突然眼前一亮驚現(xiàn)"XXX隱私照片，不看后悔一輩子"的鏈接，耐不住內(nèi)心躁動(dòng)，立馬點(diǎn)擊了該危險(xiǎn)的網(wǎng)站(頁面代碼如下圖所示)，但當(dāng)這頁面一加載，便會(huì)執(zhí)行submitForm這個(gè)方法來提交轉(zhuǎn)賬請求，從而將10塊轉(zhuǎn)給黑客。
2. 如何防御
防范 CSRF 可以遵循以下幾種規(guī)則：
- Get 請求不對數(shù)據(jù)進(jìn)行修改
- 不讓第三方網(wǎng)站訪問到用戶 Cookie
- 阻止第三方網(wǎng)站請求接口
- 請求時(shí)附帶驗(yàn)證信息，比如驗(yàn)證碼或者 Token
(1) SameSite
可以對 Cookie 設(shè)置 SameSite 屬性。該屬性表示 Cookie 不隨著跨域請求發(fā)送，可以很大程度減少 CSRF 的，但是該屬性目前并不是所有瀏覽器都兼容。
(2) Referer Check
HTTP Referer是header的一部分，當(dāng)瀏覽器向web服務(wù)器發(fā)送請求時(shí)，一般會(huì)帶上Referer信息告訴服務(wù)器是從哪個(gè)頁面鏈接過來的，服務(wù)器籍此可以獲得一些信息用于處理?？梢酝ㄟ^檢查請求的來源來防御CSRF。正常請求的referer具有一定規(guī)律，如在提交表單的referer必定是在該頁面發(fā)起的請求。所以通過檢查http包頭referer的值是不是這個(gè)頁面，來判斷是不是CSRF。
但在某些情況下如從https跳轉(zhuǎn)到http，瀏覽器處于安全考慮，不會(huì)發(fā)送referer，服務(wù)器就無法進(jìn)行check了。若與該網(wǎng)站同域的其他網(wǎng)站有XSS漏洞，那么可以在其他網(wǎng)站注入惡意腳本，受害者進(jìn)入了此類同域的網(wǎng)址，也會(huì)遭受。出于以上原因，無法完全依賴Referer Check作為防御CSRF的主要手段。但是可以通過Referer Check來監(jiān)控CSRF的發(fā)生。
(3) Anti CSRF Token
目前比較完善的解決方案是加入Anti-CSRF-Token。即發(fā)送請求時(shí)在HTTP 請求中以參數(shù)的形式加入一個(gè)隨機(jī)產(chǎn)生的token，并在服務(wù)器建立一個(gè)攔截器來驗(yàn)證這個(gè)token。服務(wù)器讀取瀏覽器當(dāng)前域cookie中這個(gè)token值，會(huì)進(jìn)行校驗(yàn)該請求當(dāng)中的token和cookie當(dāng)中的token值是否都存在且相等，才認(rèn)為這是合法的請求。否則認(rèn)為這次請求是違法的，拒絕該次服務(wù)。
這種方法相比Referer檢查要安全很多，token可以在用戶登陸后產(chǎn)生并放于session或cookie中，然后在每次請求時(shí)服務(wù)器把token從session或cookie中拿出，與本次請求中的token 進(jìn)行比對。由于token的存在，無法再構(gòu)造出一個(gè)完整的URL實(shí)施CSRF。但在處理多個(gè)頁面共存問題時(shí)，當(dāng)某個(gè)頁面消耗掉token后，其他頁面的表單保存的還是被消耗掉的那個(gè)token，其他頁面的表單提交時(shí)會(huì)出現(xiàn)token錯(cuò)誤。
(4) 驗(yàn)證碼
應(yīng)用程序和用戶進(jìn)行交互過程中，特別是賬戶交易這種核心步驟，強(qiáng)制用戶輸入驗(yàn)證碼，才能完成最終請求。在通常情況下，驗(yàn)證碼夠很好地遏制CSRF。但增加驗(yàn)證碼降低了用戶的體驗(yàn)，網(wǎng)站不能給所有的操作都加上驗(yàn)證碼。所以只能將驗(yàn)證碼作為一種輔助手段，在關(guān)鍵業(yè)務(wù)點(diǎn)設(shè)置驗(yàn)證碼。
三、點(diǎn)擊劫持
點(diǎn)擊劫持是一種視覺欺騙的手段。將需要的網(wǎng)站通過 iframe 嵌套的方式嵌入自己的網(wǎng)頁中，并將 iframe 設(shè)置為透明，在頁面中透出一個(gè)按鈕誘導(dǎo)用戶點(diǎn)擊。
1. 特點(diǎn)
- 隱蔽性較高
- 騙取用戶操作
- "UI-覆蓋"
- 利用iframe或者其它標(biāo)簽的屬性
2. 點(diǎn)擊劫持的原理
用戶在登陸 A 網(wǎng)站的系統(tǒng)后，被誘惑打開第三方網(wǎng)站，而第三方網(wǎng)站通過 iframe 引入了 A 網(wǎng)站的頁面內(nèi)容，用戶在第三方網(wǎng)站中點(diǎn)擊某個(gè)按鈕(被裝飾的按鈕)，實(shí)際上是點(diǎn)擊了 A 網(wǎng)站的按鈕。 接下來我們舉個(gè)例子：我在優(yōu)酷發(fā)布了很多視頻，想讓更多的人關(guān)注它，就可以通過點(diǎn)擊劫持來實(shí)現(xiàn)。
- iframe {
- width: 1440px;
- height: 900px;
- position: absolute;
- top: -0px;
- left: -0px;
- z-index: 2;
- -moz-opacity: 0;
- opacity: 0;
- filter: alpha(opacity=0);
- }
- button {
- position: absolute;
- top: 270px;
- left: 1150px;
- z-index: 1;
- width: 90px;
- height:40px;
- }
- </style>
- ......
- <button>點(diǎn)擊脫衣</button>
- <img src="http://pic1.win4000.com/wallpaper/2018-03-19/5aaf2bf0122d2.jpg">
- <iframe src="http://i.youku.com/u/UMjA0NTg4Njcy" scrolling="no"></iframe>
從上圖可知，通過圖片作為頁面背景，隱藏了用戶操作的真實(shí)界面，當(dāng)你按耐不住好奇點(diǎn)擊按鈕以后，真正的點(diǎn)擊的其實(shí)是隱藏的那個(gè)頁面的訂閱按鈕，然后就會(huì)在你不知情的情況下訂閱了。
3. 如何防御
(1) X-FRAME-OPTIONS
X-FRAME-OPTIONS是一個(gè) HTTP 響應(yīng)頭，在現(xiàn)代瀏覽器有一個(gè)很好的支持。這個(gè) HTTP 響應(yīng)頭 就是為了防御用 iframe 嵌套的點(diǎn)擊劫持攻擊。
該響應(yīng)頭有三個(gè)值可選，分別是：
- DENY，表示頁面不允許通過 iframe 的方式展示
- SAMEORIGIN，表示頁面可以在相同域名下通過 iframe 的方式展示
- ALLOW-FROM，表示頁面可以在指定來源的 iframe 中展示
(2)JavaScript 防御
對于某些遠(yuǎn)古瀏覽器來說，并不能支持上面的這種方式，那我們只有通過 JS 的方式來防御點(diǎn)擊劫持了。
- <head>
- <style id="click-jack">
- html {
- display: none !important;
- }
- </style>
- </head>
- <body>
- <script>
- if (self == top) {
- var style = document.getElementById('click-jack')
- document.body.removeChild(style)
- } else {
- top.location = self.location
- }
- </script>
- </body>
以上代碼的作用就是當(dāng)通過 iframe 的方式加載頁面時(shí)，網(wǎng)頁直接不顯示所有內(nèi)容了。
四、URL跳轉(zhuǎn)漏洞
定義：借助未驗(yàn)證的URL跳轉(zhuǎn)，將應(yīng)用程序引導(dǎo)到不安全的第三方區(qū)域，從而導(dǎo)致的安全問題。
1. URL跳轉(zhuǎn)漏洞原理
黑客利用URL跳轉(zhuǎn)漏洞來誘導(dǎo)安全意識(shí)低的用戶點(diǎn)擊，導(dǎo)致用戶信息泄露或者資金的流失。其原理是黑客構(gòu)建惡意鏈接(鏈接需要進(jìn)行偽裝,盡可能迷惑),發(fā)在QQ群或者是瀏覽量多的貼吧/論壇中。 安全意識(shí)低的用戶點(diǎn)擊后,經(jīng)過服務(wù)器或者瀏覽器解析后，跳到惡意的網(wǎng)站中。
惡意鏈接需要進(jìn)行偽裝,經(jīng)常的做法是熟悉的鏈接后面加上一個(gè)惡意的網(wǎng)址，這樣才迷惑用戶。
諸如偽裝成像如下的網(wǎng)址，你是否能夠識(shí)別出來是惡意網(wǎng)址呢?
- http://gate.baidu.com/index?act=go&url=http://t.cn/RVTatrd
- http://qt.qq.com/safecheck.html?flag=1&url=http://t.cn/RVTatrd
- http://tieba.baidu.com/f/user/passport?jumpUrl=http://t.cn/RVTatrd
2. 實(shí)現(xiàn)方式：
- Header頭跳轉(zhuǎn)
- Javascript跳轉(zhuǎn)
- META標(biāo)簽跳轉(zhuǎn)
這里我們舉個(gè)Header頭跳轉(zhuǎn)實(shí)現(xiàn)方式：
- <?php
- $url=$_GET['jumpto'];
- header("Location: $url");
- ?>
- http://www.wooyun.org/login.php?jumpto=http://www.evil.com
這里用戶會(huì)認(rèn)為www.wooyun.org都是可信的，但是點(diǎn)擊上述鏈接將導(dǎo)致用戶最終訪問www.evil.com這個(gè)惡意網(wǎng)址。
3. 如何防御
(1) referer的限制
如果確定傳遞URL參數(shù)進(jìn)入的來源，我們可以通過該方式實(shí)現(xiàn)安全限制，保證該URL的有效性，避免惡意用戶自己生成跳轉(zhuǎn)鏈接。
(2) 加入有效性驗(yàn)證Token
我們保證所有生成的鏈接都是來自于我們可信域的，通過在生成的鏈接里加入用戶不可控的Token對生成的鏈接進(jìn)行校驗(yàn)，可以避免用戶生成自己的惡意鏈接從而被利用，但是如果功能本身要求比較開放，可能導(dǎo)致有一定的限制。
五、SQL注入
SQL注入是一種常見的Web安全漏洞，利用這個(gè)漏洞，可以訪問或修改數(shù)據(jù)，或者利用潛在的數(shù)據(jù)庫漏洞進(jìn)行。
1. SQL注入的原理
我們先舉一個(gè)鑰匙的例子來說明其原理：
- <form action="/login" method="POST">
- <p>Username: <input type="text" name="username" /></p>
- <p>Password: <input type="password" name="password" /></p>
- <p><input type="submit" value="登陸" /></p>
- </form>
后端的 SQL 語句可能是如下這樣的：
- let querySQL = `
- SELECT *
- FROM user
- WHERE username='${username}'
- AND psw='${password}'
- `;
- // 接下來就是執(zhí)行 sql 語句...
這是我們經(jīng)常見到的登錄頁面，但如果有一個(gè)惡意輸入的用戶名是 admin' --，密碼隨意輸入，就可以直接登入系統(tǒng)了。why! ----這就是SQL注入。
我們之前預(yù)想的SQL 語句是：
- SELECT * FROM user WHERE username='admin' AND psw='password'
但是惡意用奇怪用戶名將你的 SQL 語句變成了如下形式：
- SELECT * FROM user WHERE username='admin' --' AND psw='xxxx'
在 SQL 中,' --是閉合和注釋的意思，-- 是注釋后面的內(nèi)容的意思，所以查詢語句就變成了：
- SELECT * FROM user WHERE username='admin'
所謂的密碼,本質(zhì)上就是SQL注入的一種利用方式。
一次SQL注入的過程包括以下幾個(gè)過程：
- 獲取用戶請求參數(shù)
- 拼接到代碼當(dāng)中
- SQL語句按照我們構(gòu)造參數(shù)的語義執(zhí)行成功
SQL注入的必備條件： 1.可以控制輸入的數(shù)據(jù) 2.服務(wù)器要執(zhí)行的代碼拼接了控制的數(shù)據(jù)。
我們會(huì)發(fā)現(xiàn)SQL注入流程中與正常請求服務(wù)器類似，只是黑客控制了數(shù)據(jù)，構(gòu)造了SQL查詢，而正常的請求不會(huì)SQL查詢這一步，SQL注入的本質(zhì):數(shù)據(jù)和代碼未分離，即數(shù)據(jù)當(dāng)做了代碼來執(zhí)行。
2. 危害
(1)獲取數(shù)據(jù)庫信息
- 管理員后臺(tái)用戶名和密碼
- 獲取其他數(shù)據(jù)庫敏感信息：用戶名、密碼、手機(jī)號碼、銀行卡信息……
- 整個(gè)數(shù)據(jù)庫：脫褲
(2)獲取服務(wù)器權(quán)限
(3)植入Webshell，獲取服務(wù)器后門
(4)讀取服務(wù)器敏感文件
3. 如何防御
- 嚴(yán)格限制Web應(yīng)用的數(shù)據(jù)庫的操作權(quán)限，給此用戶提供僅僅能夠滿足其工作的權(quán)限，從而限度的減少注入對數(shù)據(jù)庫的危害。
- 后端代碼檢查輸入的數(shù)據(jù)是否符合預(yù)期，嚴(yán)格限制變量的類型，例如使用正則表達(dá)式進(jìn)行一些匹配處理。
- 對進(jìn)入數(shù)據(jù)庫的特殊字符('，"，\，<，>，&，，; 等)進(jìn)行轉(zhuǎn)義處理，或編碼轉(zhuǎn)換*。基本上所有的后端語言都有對字符串進(jìn)行轉(zhuǎn)義處理的方法，比如 lodash 的 lodash._escapehtmlchar 庫。
- 所有的查詢語句建議使用數(shù)據(jù)庫提供的參數(shù)化查詢接口，參數(shù)化的語句使用參數(shù)而不是將用戶輸入變量嵌入到 SQL 語句中，即不要直接拼接 SQL 語句。例如 Node.js 中的 mysqljs 庫的 query 方法中的 ? 占位參數(shù)。
六、OS命令注入
OS命令注入和SQL注入差不多，只不過SQL注入是針對數(shù)據(jù)庫的，而OS命令注入是針對操作系統(tǒng)的。OS命令注入指通過Web應(yīng)用，執(zhí)行非法的操作系統(tǒng)命令達(dá)到的目的。只要在能調(diào)用Shell函數(shù)的地方就有存在風(fēng)險(xiǎn)。倘若調(diào)用Shell時(shí)存在疏漏，就可以執(zhí)行插入的非法命令。
命令注入可以向Shell發(fā)送命令，讓W(xué)indows或Linux操作系統(tǒng)的命令行啟動(dòng)程序。也就是說，通過命令注入可執(zhí)行操作系統(tǒng)上安裝著的各種程序。
1. 原理
黑客構(gòu)造命令提交給web應(yīng)用程序，web應(yīng)用程序提取黑客構(gòu)造的命令，拼接到被執(zhí)行的命令中，因黑客注入的命令打破了原有命令結(jié)構(gòu)，導(dǎo)致web應(yīng)用執(zhí)行了額外的命令，web應(yīng)用程序?qū)?zhí)行的結(jié)果輸出到響應(yīng)頁面中。
我們通過一個(gè)例子來說明其原理，假如需要實(shí)現(xiàn)一個(gè)需求：用戶提交一些內(nèi)容到服務(wù)器，然后在服務(wù)器執(zhí)行一些系統(tǒng)命令去返回一個(gè)結(jié)果給用戶。
- // 以 Node.js 為例，假如在接口中需要從 github 下載用戶指定的 repo
- const exec = require('mz/child_process').exec;
- let params = {/* 用戶輸入的參數(shù) */};
- exec(`git clone ${params.repo} /some/path`);
如果 params.repo 傳入的是 https://github.com/admin/admin.github.io.git 確實(shí)能從指定的 git repo 上下載到想要的代碼。 但是如果 params.repo 傳入的是 https://github.com/xx/xx.git && rm -rf /* && 恰好你的服務(wù)是用 root 權(quán)限起的就糟糕了。
2. 如何防御
- 后端對前端提交內(nèi)容進(jìn)行規(guī)則限制(比如正則表達(dá)式)。
- 在調(diào)用系統(tǒng)命令前對所有傳入?yún)?shù)進(jìn)行命令行參數(shù)轉(zhuǎn)義過濾。
- 不要直接拼接命令語句，借助一些工具做拼接、轉(zhuǎn)義預(yù)處理，例如 Node.js 的 shell-escape npm包
作者：浪里行舟，慕課網(wǎng)認(rèn)證作者，前端愛好者，立志往全棧工程師發(fā)展，從事前端一年多，目前技術(shù)棧有vue全家桶、ES6以及l(fā)ess等，樂于分享，最近一年寫了五六十篇原創(chuàng)技術(shù)文章，得到諸多好評!
【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請注明原文作者和出處為51CTO.com】
