用於在網絡服務器上存儲私人圖像的最佳實踐

例如，如果您的在線社區允許在會員之間發送私人圖像，如數字筆友或約會網站。用於在網絡服務器上存儲私人圖像的最佳實踐

將這些圖像保護在網絡服務器上的最佳做法是什麼以及將它們顯示給經過驗證的用戶的最佳做法是什麼？

這是我迄今所做的：

將圖像存儲公共目錄之外。
通過一個時間碼而不是實際圖像位置檢索圖像。
隨機哈希圖像名稱和文件夾名稱不容易猜測。
PHP腳本在顯示圖像之前對用戶進行身份驗證。

根之外似乎是存儲圖像以便難以訪問的最佳方式之一，但如果服務器本身直接被黑入，怎麼辦？

有沒有辦法哈希和鹽的圖像文件，所以它只能顯示一次哈希和鹽的比賽，即使黑客有文件嗎？這將有可能通過PHP或SQL返回？我正在考慮將圖像編碼爲base64，並且用每個用戶隨機生成的密碼生成的鹽來醃製base64（這是可能的嗎？）還是有更好的方法嗎？

來源

2016-10-22 Ash

你可以用二進制數據類型將它們存儲在MySQL中，然後像'image.php？id = 123'，在此範圍內，您可以應用一些邏輯，如檢查哪個用戶正在請求映像以及他們是否具有訪問權限所需的權限。 –

嗨，我會說數據庫也會受到影響......所以我會把它從數據庫中拿出來。至於更安全的方式，我認爲你可以使用pgp密鑰，只有發送者和接收者可以解碼文件[示例]（http://stackoverflow.com/a/597200/3727050）。但是，問題在於你在哪裏存儲密鑰？（注意你也可以使用密碼來保護密鑰） – urban

我在想可能是生成的密鑰，只有當會話的兩端與發送者和接收者的身份驗證相匹配時纔會生成密鑰，並且其一次只在渲染圖像後更改。我實際上並沒有將這樣的網站建設成一個網站，我只是想了解其他人可能會如何解決這個問題，例如，甚至將醫療記錄或其他高度機密的文件存儲在可以外部查看的網絡服務器上。 – Ash

對於一個基本的保障，您所描述的情況可能是不夠的，甚至是太多的意義上，如果該文件夾WWW根目錄之外，隨機文件夾名稱不會增加太多的安全性，但會增加複雜性。

基於您應該針對您的方案進行風險評估，您可以選擇做更多。當然，如果你發現你可以降低100美元違約的風險和10000美元的成本，你可能不希望這樣做。所以先做數學。 :)

我可以看到您的解決方案的兩大威脅，一是在訪問控制邏輯，它允許用戶下載，他不應該能夠訪問圖像的錯誤。另一個是攻擊者訪問您的Web服務器並下載圖像（因爲您的Web服務器需要訪問映像文件，這不一定是root/admin訪問，這會增加風險）。

我們可以想到的一個想法是加密服務器上的圖像。但是，通過加密，密鑰管理通常是問題，現在情況就是如此。使用密鑰進行加密並不意味着您的應用程序可以訪問，因爲攻擊者在成功進行應用程序級別攻擊時也可以訪問該密鑰（並且在服務器/操作系統級別攻擊的情況下也是如此，因爲用戶正在運行您的Web服務器和/或應用程序必須有權訪問該密鑰）。

從理論上講，您可以爲您的所有用戶生成一個公鑰/私鑰對。當某人上傳圖像時，您將爲圖像生成對稱密鑰，使用該密鑰對圖像進行加密，然後使用每個預期收件人的公鑰對對稱密鑰進行加密，並將加密密鑰（和元數據）與圖像一起存儲。用戶的私鑰也應該加密，最好使用從用戶密碼派生的密鑰和適當的密鑰派生函數，如PBKDF2。其中一個含義是，當用戶登錄時，您只能獲取用戶的私鑰，因爲您不存儲他的密碼，所以這是您唯一擁有它的時間。這意味着您必須將用戶的解密私鑰至少存儲在服務器內存中，而不是真正安全的（並且任何其他商店更糟糕）。儘管（例如有人可以訪問備份），這仍然可以防止脫機攻擊者的攻擊，並且還可以將攻擊範圍限制爲在服務器受到攻擊時登錄的受害用戶（意思是在攻擊者受到攻擊之後，但在您意識到這一點之前）。另一個缺點是這個解決方案的複雜性 - 加密非常困難，如果沒有經驗，這很容易搞砸了。這也將緩解訪問控制缺陷造成的威脅，因爲無法用登錄用戶的私鑰解密意外圖像。

一種完全不同的方法是將應用程序分爲幾個組件：登錄服務（類似於SSO），Web服務器和後端映像服務。當您的用戶登錄到身份驗證提供程序（AP）時，他會在這種情況下收到由AP簽名並具有聲明的令牌。在與Web應用程序交談時，他會使用此令牌進行身份驗證。與以前不同的是，當用戶請求圖像時，Web應用程序會將其令牌傳遞給圖像服務，並且圖像服務一方面可以將圖像安全地存儲在不能直接從互聯網訪問的盒子上，另一方面，它可以授權接收到的令牌是否要返回圖像（它可以根據您選擇的實現方式，與AP或自身驗證令牌）。在這種情況下，即使攻擊者危害到Web應用程序，他仍然無法從AP生成（簽名）有效令牌以訪問映像服務上的映像，並且可能會更難以妥協圖像服務。當然，如果攻擊者在網絡服務器上遭到攻擊，攻擊者仍然可以觀察到任何流經的圖像，這意味着任何在服務器被攻陷時登錄的用戶仍然會丟失自己的圖像給攻擊者。這個解決方案的複雜性比前一個更差，這意味着很容易出錯，開發和維護成本也很高。

請注意，這些解決方案都不能保護服務器管理員的圖像，這可能會或可能不會成爲您的應用程序的要求。

我希望這個答案揭示了使問題比現有解決方案更安全的一些困難。說完這一切，實現是關鍵，而細節（實際的代碼級別漏洞）可能最重要。

來源

2016-10-22 23:02:32

非常有趣！ – Hammerbot

你有這些列爲你的一些安全協議：

"1. Store Images outside of public root. 

2. Retrieve images via one time code instead of the actual image location. 

... 

4. PHP script to authenticate user before displaying the image."

這應該是足夠的，但你提到...

"3. Randomised hashed image names and folder names that are not easy to guess."

如果你實際上是做前兩個正確，1和2，那麼3就不可能有任何效果。如果圖像位於網絡服務器目錄之外，那麼文件夾名稱和圖像名稱是否容易猜到並不重要。

你的代碼如下（做1和2），假設的環境是你的網絡服務器（即example.com/index.php）的根目錄...

$file_location = '../../images/' . $some_id_that_is_authenticated_and_cleansed_for_slashes . '.jpg'; 

readfile($file_location); // grabs file and shows it to user

如果您正在做上面的事情，那麼3是多餘的。如果您的網站遭到黑客入侵（Apache安全性被繞過），那麼散列名稱等將無濟於事，如果您的網站沒有執行上述操作（因爲用戶可以直接訪問這些網址），它將無濟於事。除了冗餘外，其餘的看起來很完美。

來源

2016-10-31 00:00:29 HoldOffHunger

用於在網絡服務器上存儲私人圖像的最佳實踐

回答

相關問題