八種常見的防盜鍊方法總結及分析

作為普通的網民來說，一般不需要知道也不用關心什麼是盜鍊，不過如果你是網站的開發者或維護者，就不得不重視盜鍊的問題了。如果你剛剛開發完一個沒有防盜鍊的帶有檔案下載下傳功能的網站，挂上internet，然後上傳幾個時下非常熱門的軟體或電影并在網站内公布下載下傳位址，讓MSN上的所有好友都來體驗一下你的傑作。不用多久就會發現網速出奇地變慢，甚至伺服器托管中心的服務員會熱情地打電話告訴你的網站流量很大，估計是網站受歡迎起來了，問你是不是該考慮加錢租用帶寬更寬但價格更貴的網線了。在這個值得慶祝的時候趕快打開Google Analytics看看有多少人來光顧你的網站了吧，如果發現訪客每天才十來個人，很遺憾地告訴你：你的網站資源不幸地被人盜鍊了。而且更糟糕的是，當你把網站上的檔案和電影通通删光之後，網站仍然沒有變快多少，從web伺服器的通路日志裡會發現瘋狂的通路請求正從四面八方湧過來，web伺服器為了迎接這批訪客而沒有時間處理正常的頁面，這種狀況可能會一直持續好幾個周時間。

網站資源被盜鍊簡單來說就是别人不是從你的網站通過下載下傳資源，被盜鍊的幾種可能情況：

1、在人氣非常旺的網站、論壇、社群的網頁裡直接引用了（使用标記）你網站上的圖檔，或者直接在其他網頁（使用flash或媒體播放插件）裡嵌入了你網站上的mp3。

2、在人氣非常旺的網站、論壇、社群裡提供了你的資源的下載下傳位址。

3、你網站的資源可能被一些下載下傳軟體列入了“資源候選名單”，當其他人用下載下傳工具下載下傳相同的檔案時，下載下傳軟體會自動找上門并且從你的伺服器下載下傳。

既然被盜鍊的後果這麼可怕，那有哪些方法可以防止盜鍊呢下面從簡到繁總結一下常見的以及自己實踐過的一些方法，并簡單分析一下。不過很遺憾地，這些方法都沒法完全杜絕被盜鍊，并且防盜鍊的目的應該是從一定的程度上減少被盜鍊所産生的影響，同時能讓合法的使用者能夠以自然的方式、順暢地從你的網站下載下傳資源。

方法1：判斷引用位址

這個方法是最早及最常見的方法。所謂判斷引用位址，就是判斷浏覽器請求時HTTP頭的Referer字段的值，這個值在asp.net裡面可以用 Request.UrlReferrer屬性取得。幾個例子來說，在正常情況下當使用者在浏覽 http://uushare.com/abc.html 時點選一個連結去到 http://uushare.com/jacky.mp3 檔案時，浏覽器在送出請求jacky.mp3 資源時還會附帶當刻浏覽器所處的頁面位址（即http://uushare.com/abc.html），是以當你的網站程式接收到下載下傳 jacky.mp3 資源請求的時候，先判斷http的referer字段的值，如果是從 自己的域名（uushare.com）過來的，則可以認為是合法的連接配接請求，否則就傳回一個錯誤的提示資訊。

這種方法通常用于圖檔、mp3這種容易被人用html“嵌入”到其他網站的資源，使用這種方法可以防止你的圖檔直接出現在别人的網頁裡（或者防止mp3直接被其他網站嵌入到flash播放器裡），不過訪客使用下載下傳工具還是可以輕松下載下傳，因為現在的下載下傳工具一般會自動用你的域名構造一個引用位址，是以如果想再進一步防範的話，可以使用一個對應表限制每個資源的引用位址，例如将 jacky.mp3 的引用位址限制為 http://uushare.com/abc.htmlid=12345，這樣下載下傳工具就不太可能構造一個“正确”的引用位址了。

方法2：使用登入驗證

這個方法常見于論壇、社群。當訪客請求網站上的一個資源時，先判斷此請求是否通過登入驗證（在asp.net裡常用session或form驗證來記錄登入狀态），如果尚未登入則傳回一個錯誤提示資訊。使用這個方法還可以進一步判斷登入的使用者的權限是否足夠，以實作帶“權限”的下載下傳。

不過因為登入狀态依賴于會話id，而會話id往往儲存于http請求的cookie字段裡，下載下傳工具一般沒法獲得浏覽器的cookie字段，是以這些資源往往無法使用下載下傳工具來下載下傳，給正常合法使用者帶來諸多不便（因為大部分網民的系統都安裝了下載下傳工具，一點選下載下傳連結一般會被下載下傳工具攔截，導緻無法使用浏覽器本身的下載下傳功能）。簡單的解決方法是将這個session id放到URL中。

這種方法的另外一個缺點是訪客無法匿名下載下傳，是以這個方法一般隻用于論壇和社群網站。

方法3：使用cookie

其實這種方法原理上跟方法2差不多。就是在顯示“下載下傳”連結的頁面裡産生一個動态值的cookie，然後在處理資源下載下傳請求時先判斷cookie裡有沒有正确的cookie，如果沒有則傳回錯誤提示資訊。至于這個動态值如何産生，隻要能逆向判斷動态值是否合法的都可以，例如将目前的時間去除秒數取哈希值（也叫散列值）。如果網頁程式是asp.net則更簡單，可以往Session裡随便存一個字元串或數字，然後在處理下載下傳請求時先檢查Session裡是否存在這個字元串或數字。使用這個方法的缺點跟方法2一樣。

方法4：使用POST下載下傳

用戶端浏覽器請求資源都是使用HTTP的GET方法的，其實使用POST方法也可以往用戶端傳回資料。是以可以将下載下傳連結換成一個表單（Form）和一個按鈕(Submit)，将待下載下傳的檔案的名稱或id放到表單的一個隐藏文本框（Input）裡，當使用者點選送出按鈕時，服務程式先判斷請求是否為POST方式，如果是則讀取目标資源的二進制資料并寫入響應對象（在asp.net裡是respone.BinaryWrite方法）。

使用這個方法的缺點同樣是無法使用下載下傳工具，更沒法實作斷點續傳。 不過比方法2，3好一點的是，下載下傳工具不會攔截你的下載下傳動作，是以正常使用者還是比較順暢地下載下傳到檔案。這個方法比較适合小檔案的下載下傳。

方法5：使用圖形驗證碼

使用這個方法可以保證每次下載下傳都是“人”在你的網站上下載下傳，而不是下載下傳工具。因為網上很多介紹使用圖形驗證碼的方法，是以這裡就不再重複了。這個方法的缺點是比較容易讓正常的使用者感到麻煩。

方法6：使用動态檔案名

也叫動态鑰匙法，當使用者點選一個下載下傳連結時，先在程式端計算一個Key（使用一定規律産生的Key，最好不要使用随機字元串例如GUID，并且這個Key必須有一定時效的），然後在資料庫或Cache裡記錄這個Key以及它所對應的資源ID或檔案名，最後讓網頁重定向一個新的URL位址，這個新URL位址裡需要包含這個Key。當浏覽器或下載下傳工具發出下載下傳請求時，程式先檢測這個Key是否存在，如果存在則傳回對應的資源資料。

使用這個方法的好處是下載下傳工具也可以下載下傳，并且在Key失效前可以斷點續傳，并且可以通過Key來控制下載下傳的線程數。

使用這個方法（包括以上所有支援下載下傳工具的方法）的缺點是：當任意一個使用者下載下傳成功之後，你的資源就會被一些下載下傳工具列入“資源候選名單”，以後其他人在其他地方下載下傳同樣的檔案時，下載下傳工具會不斷連接配接你的伺服器，即使你的檔案已經删除或者Key已經失效了，這樣會造成類DDos攻擊的後果，下面再介紹兩個即可以讓下載下傳工具下載下傳，又可以防止盜鍊的方法。

方法7：擅改資源的内容

一般熱門的資源都是電影、mp3、較大的壓縮包等，這些檔案都是有很多可以插入資料的地方的，例如mp3有一個tag區，rar/zip有一個備注區，電影的内容随便一個地方，隻要在下載下傳過程當中，動态地往這些地方注入一些随機的位元組（幾個位元組即可），就可以達到讓整個檔案的哈希值（即散列值、指紋值）發生改變，讓從你網站下載下傳的檔案的哈希值跟别人的不一樣，就可以防止下載下傳工具主動找上門了。用這個方法配合方法6，可以達到較好的防盜鍊的效果。缺點是，雖然檔案被修改的部分不會被“看”、“聽”出來，不過多多少少讓知道的人覺得不爽。另外就是如果别人把從你網站下載下傳的檔案放到其他網站，那麼仍然存在下載下傳工具主動找上門的情況（雖然實際上它下載下傳不了内容）。

方法8：打包下載下傳

這個方法跟方法7的道理是一樣的，隻不過這次不是往原始檔案裡修改，而是在原始的檔案基礎上再加個“外殼”，讓資源的哈希值跟别人的不一樣。使用這個方法可以在不擅改資源原始的内容基礎上實作方法6同樣的效果，并且狠一點的話，甚至可以在打包的時候放入自己的一些廣告。缺點是使用者每次下載下傳都得加壓縮，不過目前大部分人都懂得解壓，是以這個缺點有時可以忽略不計。

轉載自：https://www.cnblogs.com/wangyongsong/p/8204698.html