前言

上周突然發(fā)現(xiàn)自己的自己站點的圖片全都403了，之前還是好好的，圖片咋就全都訪問不了呢？由于我每次發(fā)文章都是先發(fā)了掘金，然后再從掘金拷貝到我自己的站點，這樣我就不用在自己的站點去上傳圖片了，非常方便。

啥也沒干，圖片咋就403了呢？估計又是整了什么開源節(jié)流，降本增效吧，說白了就是大家都用他站點的圖片導(dǎo)致流量費用蹭蹭蹭的往上漲，人家肯定不愿意了，這下給圖片都加上防盜了，非自己的站點全都給你返回403.

防盜原理

是不是很好奇這些圖片防盜是怎么做的？

我們可以自己來實現(xiàn)一下這個場景：不受信任的域名訪問我服務(wù)器上的圖片資源全都返回403

準備幾個域名

這里沒有域名也不用擔(dān)心，我們可以直接本地模擬就行了，比如我這里使用SwitchHosts給本地添加的三個域名并且都指向我們的本地IP

這樣的話這三個域名都能夠訪問我們的本地服務(wù)了。

服務(wù)端邏輯

靜態(tài)資源目錄

這里就用之前的nest服務(wù)來做演示，之前我們在這個服務(wù)上指定了靜態(tài)資源目錄

app.useStaticAssets(join(__dirname, '../static'), {
  prefix: '/static',
}); // 靜態(tài)資源

前端訪問圖片

<img class="my_img" src="http://nanjiu.com:3000/static/sy.jpg" />

這里是使用nanjiu.com代理域名來訪問的，圖片能夠正常訪問

防盜中間件

這里我們可以來實現(xiàn)一個全局中間件用來處理圖片的訪問，當(dāng)訪問域名不在我們信任的白名單內(nèi)直接給他返回403

// 白名單
const whiteList = ['nanjiu.com', 'fenanjiu.com']
 // 圖片防盜中間件
function imgMiddleware(req, res, next) {
  console.log('--req', req.headers)
  // 獲取資源類型
  const type = req.headers.accept || ''
  if(!type.includes('image')) {
    // 不是圖片資源，直接放行
    next()
    return
  }
  const referer = req.headers.referer || ''
  // 獲取referer的域名
  const { hostname } = url.parse(referer, true)
  if(referer && whiteList.includes(hostname) || !referer) {
    // 訪問域名在白名單內(nèi)，放行 !referer表示直接訪問圖片(比如瀏覽器地址欄輸入圖片地址)
    res.status(200)
    next() 
  }else {
    // 訪問域名不在白名單內(nèi)，返回403
    res.status(403)
    res.send('逮到你了，又來偷我圖片是吧！')
  }
}

這里需要注意的是，全局中間件在使用時一定要在useStaticAssets之前

async function bootstrap() {
  const app = await NestFactory.create<NestExpressApplication>(AppModule);
  app.setGlobalPrefix('api'); // 全局路由前綴
  app.use(cors()); // 允許跨域
  app.use(json({ limit: '10mb' })); // 允許上傳大文件
  app.use(urlencoded({ extended: true, limit: '10mb' })); // 允許上傳大文件
  app.use(imgMiddleware) // 圖片防盜中間件
  app.useStaticAssets(join(__dirname, '../static'), {
    prefix: '/static',
  }); // 靜態(tài)資源
  await app.listen(3000);
  console.log(`Application is running on: ${await app.getUrl()}`);
}
bootstrap();

這上面的代碼中我們可以看到，現(xiàn)在受信任的域名就只有nanjiu.com和fenanjiu.com

當(dāng)前端頁面使用sy.com這個域名去訪問nanjiu.com域名下的圖片時，此時應(yīng)該是會進入防盜邏輯，返回403

并且送他一句

Referer

從上面我們實現(xiàn)的防盜原理來看，這其中最關(guān)鍵的就是referer，那么這個referer到底是什么呢？為什么可以用它來做圖片防盜

Referer是什么

MDN解釋如下：

Referer 請求頭包含了當(dāng)前請求頁面的來源頁面的地址，即表示當(dāng)前頁面是通過此來源頁面里的鏈接進入的。服務(wù)端一般使用 Referer 請求頭識別訪問來源，可能會以此進行統(tǒng)計分析、日志記錄以及緩存優(yōu)化等。

從這里我們就大概能知道圖片防盜的原理了，服務(wù)端可以通過請求頭中的Referer來識別訪問來源，然后判斷應(yīng)不應(yīng)該給你返回圖片

Referer這個單詞實際上是Referrer的錯誤拼寫，這其實是個歷史原因，在早期 HTTP 規(guī)范當(dāng)中就存在的拼寫錯誤，后面為了向下兼容，所以將錯就錯。

拼寫錯誤只有 Request Headers 的 Referer，在其他地方比如General Headers、 JavaScript 及 DOM 上，都是正確的拼寫。

Referrer-Policy

Referrer-Policy 首部用來監(jiān)管哪些訪問來源信息——會在 Referer 中發(fā)送——應(yīng)該被包含在生成的請求當(dāng)中。

它其實是用來控制 Referer 返回的具體內(nèi)容的

它有以下屬性值：

• no-referrer： 整個 Referer 首部會被移除。訪問來源信息不隨著請求一起發(fā)送。
• no-referrer-when-downgrade（默認值）： 在沒有指定任何策略的情況下用戶代理的默認行為。在同等安全級別的情況下，引用頁面的地址會被發(fā)送 (HTTPS->HTTPS)，但是在降級的情況下不會被發(fā)送 (HTTPS->HTTP)。
• origin： 在任何情況下，僅發(fā)送文件的源作為引用地址。例如 https://example.com/page.html 會將 https://example.com/ 作為引用地址。
• origin-when-cross-origin： 對于同源的請求，會發(fā)送完整的 URL 作為引用地址，但是對于非同源請求僅發(fā)送文件的源。
• same-origin： 對于同源的請求會發(fā)送引用地址，但是對于非同源請求則不發(fā)送引用地址信息。
• strict-origin： 在同等安全級別的情況下，發(fā)送文件的源作為引用地址 (HTTPS->HTTPS)，但是在降級的情況下不會發(fā)送 (HTTPS->HTTP)。
• strict-origin-when-cross-origin： 對于同源的請求，會發(fā)送完整的 URL 作為引用地址；在同等安全級別的情況下，發(fā)送文件的源作為引用地址 (HTTPS->HTTPS)；在降級的情況下不發(fā)送此首部 (HTTPS->HTTP)。
• unsafe-url： 無論是同源請求還是非同源請求，都發(fā)送完整的 URL（移除參數(shù)信息之后）作為引用地址。

這么多referrer策略，我們怎么使用呢？

meta標簽使用

我們可以用一個 name 為 referrer 的meta元素為整個文檔設(shè)置 referrer 策略

<meta name="referrer" content="no-referrer">

我的個人站點就是使用該方法來解決圖片訪問403問題的，但需要注意的是，如果你為頁面設(shè)置了no-referrer策略會導(dǎo)致頁面上所有的請求都不會發(fā)送referer，使用時需要自己權(quán)衡利弊。

rel屬性

可以在a、area、link標簽上通過rel屬性來單獨指定referrer的策略

<a href="xxx" rel="external nofollow"  rel="noreferrer">新地址</a>

referrerpolicy屬性

可以在a、area、link、img、iframe、script標簽上通過referrerpolicy屬性來單獨指定referrer策略

<img class="my_img" referrerpolicy="no-referrer" src="http://nanjiu.com:3000/static/sy.jpg" />

比如上面例子中的這張圖片我們加上referrerpolicy="no-referrer"再去訪問，頁面還是在sy.com這個域名下面

可以看到請求頭中沒有攜帶referer，所以它就能夠躲過圖片防盜邏輯。

Headers請求頭

也可以更改 HTTP 頭信息中的 Referer-Policy 值。比如你使用的是 Nginx，則可以設(shè)置 add\_headers 設(shè)置請求頭。

add_header Referrer-Policy "no-referrer";

Headers 請求頭和其它頁面元素屬性同時存在時，確定元素的有效策略時的優(yōu)先順序是：

• 元素級策略
• 頁面級策略
• 瀏覽器默認

以上就是使用HTTP Referer實現(xiàn)圖片防盜圖文示例詳解的詳細內(nèi)容，更多關(guān)于HTTP Referer圖片防盜的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論