摘要：事件原因之前使用開發(fā)的一個(gè)網(wǎng)站。事件的處理方法在公司是有專門的安全組來做安全這塊兒工作的。第一時(shí)間對這個(gè)接口進(jìn)行了下線處理，然后評估了安全的解決方案，再次上線該接口。這些機(jī)器也肯定是經(jīng)過做特殊的隔離處理的沒有敏感的公司信息資源。

之前使用Nodejs開發(fā)的一個(gè)網(wǎng)站。在網(wǎng)站上有一個(gè)頁面有個(gè)功能，允許用戶上傳圖片或者粘貼一張圖片鏈接。服務(wù)端讀取用戶上傳的圖片信息或者是請求用戶填寫的圖片鏈接獲取圖片信息。

如果是用戶使用上傳功能，前端可以在input控件上做下限制上傳文件的類型，后端再做下校驗(yàn)，以保障獲取圖片文件的合法（或者是安全）。

如果是用戶填寫的圖片鏈接，其中隱藏的安全隱患就比較大了。如果用戶填寫不是正常的http、https或者是ftp類的鏈接，而是curl這種可以在服務(wù)端執(zhí)行的命令，服務(wù)端拿到用戶的鏈接不作處理直接請求的話，可能會(huì)對公司造成不可估量的額損失（比如：內(nèi)網(wǎng)服務(wù)器信息泄露、更嚴(yán)重是內(nèi)網(wǎng)服務(wù)器被攻擊）。

在公司是有專門的安全組來做Web安全這塊兒工作的。這個(gè)事件發(fā)生的時(shí)候，我首先是短信收到了服務(wù)器的報(bào)警，線上出現(xiàn)了大量的FATAL日志。這個(gè)時(shí)候立刻是登上服務(wù)器排查，緊接著就被公司的安全組某位同事在內(nèi)部聊天工具上通知，網(wǎng)站收到了ssrf（服務(wù)器端請求偽造）攻擊。第一時(shí)間對這個(gè)接口進(jìn)行了下線處理，然后評估了安全的解決方案，再次上線該接口。

那么在服務(wù)端具體的防范ssrf攻擊的方法時(shí)什么呢，請接著往下看。

ssrf具體原理就是在服務(wù)端偽造請求，請求服務(wù)器的資源。上面的案例場景我也提到了。我有個(gè)功能是會(huì)請求一張外網(wǎng)圖片鏈接獲取圖片信息的。而用戶填寫的這個(gè)圖片鏈接很可能就是違法的請求。當(dāng)我服務(wù)端拿到這個(gè)鏈接后，并沒有按照預(yù)期去請求外網(wǎng)資源，而是請求了內(nèi)網(wǎng)服務(wù)的資源。這樣我的服務(wù)器就被攻擊。

那么什么原因可能造成ssrf漏洞呢：

web服務(wù)存在請求外網(wǎng)資源的功能

請求的url參數(shù)是外接用戶可以控制的

服務(wù)端在請求外網(wǎng)資源前，沒有做域名和IP校驗(yàn)（是否請求的是內(nèi)網(wǎng)資源）

僅僅通過正則匹配來判斷IP段（域名指向的也可能是內(nèi)網(wǎng)IP，如果IP是十進(jìn)制表示法沒有問題，但I(xiàn)P還有十六進(jìn)制和十進(jìn)制、二進(jìn)制表示法）

由上面提到的原因其實(shí)已經(jīng)可以知道一些解決方法：

在拿到用戶填寫的鏈接時(shí)做下校驗(yàn)。看是否是合法的http、https、ftp協(xié)議頭。當(dāng)然這個(gè)校驗(yàn)為了減輕服務(wù)器壓力應(yīng)該在前端和后端都校驗(yàn)。如不過不是合法的請求協(xié)議頭直接拒絕和返回請求資源失敗的錯(cuò)誤消息。（偽代碼如下）

const allowReqprotocol = [
        "http", 
        "https",
        "ftp",
    ];

const reqProtocol = request.protocol;

// 強(qiáng)制校驗(yàn)用戶輸入圖片鏈接的協(xié)議頭是否為自己網(wǎng)站允許的協(xié)議頭
if (allowReqprotocol.indexOf(reqProtocol) < 0) {
    yog.log.warning(imgUrl);
    res.json(errorMsg.imgTypeError());
    return;
}

上面已經(jīng)介紹過僅僅通過正則沒辦法完全校驗(yàn)是否是合法的IP段。其實(shí)還有一種方法就是把我們的IP段轉(zhuǎn)化為int來進(jìn)行判斷。剛好npm上有個(gè)包ip-to-int可以滿足我們的需求。我們可以把兩者結(jié)合起來一起來判斷請求鏈接的IP是否為內(nèi)網(wǎng)IP。

const dns = require("dns");
const url = require("url");
const ipToInt = require("ip-to-int");

const parseUrl = url.parse(rqUrlString);
const hostname = parseUrl.hostname; 

// 使用Nodejs的dns模塊根據(jù)域名解析出域名對應(yīng)的ip地址
dns.lookup(hostname, (err, address, family) => {

    //加入我的內(nèi)網(wǎng)IP段為 180.xxx.xxx.xxx  180.255.255.255
    const ipRegx = /^180./;
    const ipArr = [ipToInt(180.0.0.0).toInt(), ipToInt(180.255.255.255).toInt()];

    
    if(ipRegx.test(address) || ipRang(address)){
        // 拒絕請求
    } else {
        // 繼續(xù)請求
    }
});


// 判斷一個(gè)ip是否在一個(gè)數(shù)組之間
function ipRang(ip, array) {
    
    // ip在給定的ip段之間
    return true;
    // ip不在給定的ip段之間
    return false;
}

經(jīng)過上面的檢驗(yàn)已經(jīng)基本上可以保證如果有請求外網(wǎng)的Url ，請求的在服務(wù)端執(zhí)行以后指向的也是外網(wǎng)資源。那么當(dāng)資源到達(dá)服務(wù)端以后，為了保障資源的安全性。我們對請求的內(nèi)容做最后的校驗(yàn)。比如我僅僅是想請求圖片資源，而且是限制了幾種格式。比如：png、jpg、jpeg。

    const allowImgContentType = [
        "image/jpeg",
        "image/png",
        "image/gif"
    ];
    
    
   if( allowImgContentType.indexOf(response.headers["content-type"]) < 0){
   
    // 返回的內(nèi)容為非法資源
   }

上面的方法基本上都是如果請求的是內(nèi)網(wǎng)資源都是直接拒絕掉了。但是假如有請求內(nèi)網(wǎng)的需求怎么辦呢。如果內(nèi)網(wǎng)的資源對外部開發(fā)，肯定也是特定的機(jī)器。這些機(jī)器也肯定是經(jīng)過op做特殊的隔離處理的、沒有敏感的公司信息資源。那么當(dāng)我們的請求到達(dá)公司內(nèi)網(wǎng)后怎么保證該請求始終請求的是特定的IP呢？

其實(shí)我們只需要將請求的鏈接的host和在header投中和請求機(jī)器的ip做下綁定就好。

// 通過dns模塊解析出host對應(yīng)的ip  這里是address
// 并且通過url模塊解析出port path 和querystring 重新拼接請求的url

const bindURLString = `${parseUrl.protocol}//${address}:${reqUrlPort}${pathName}?${queryString}`;

// 然后在請求發(fā)出去的時(shí)候設(shè)置下header頭，下面是我使用request模塊發(fā)出請求時(shí)設(shè)置參數(shù)

const options = {
   "url": bindURLString,
   "encoding": "binary",
   "rejectUnauthorized": false,        
   "headers": {
       "Host": bindDnsObj.hostname    //這里綁定請求的host
   }
};

這樣做就是強(qiáng)制請求去請求特定的機(jī)器。而不會(huì)請求其它機(jī)器。