允許用戶上傳任何文件。我的方法不安全嗎？

我正在創建文件共享網站，類似於Megaupload或Rapidshare。就像提到的那些網站，我需要允許任何文件類型。允許用戶上傳任何文件。我的方法不安全嗎？

我在想一個解決方案，需要知道它是否存在安全風險，或者是否有更好的解決方案來解決我的問題？

用戶上傳文件
檢查文件的大小，如果低於100MB使用IP，時間戳和鹽開始上傳
加密文件名
商店的目錄中是無法從網絡訪問
在數據庫中存儲文件名，說明和散列文件名稱

上傳完成。現在的下載：

用戶請求下載
連接到數據庫中，找到文件編號
如果找到的文件ID，該文件從文件服務器位置複製和文件傳送的準備

重要的是要注意，服務器上無法運行任何東西。因此，用戶無法上傳惡意文件並在服務器上發起攻擊。在請求文件時，它會立即啓動下載，並且不會運行。

現在，考慮到上述情況，上述模型中是否存在可能允許惡意用戶攻擊服務器的缺陷？

爲了回答問題，假設網站的其他部分是安全的。

來源

2011-10-06 GV1

如果沒有什麼能夠真正嘗試執行已上傳的文件，那麼答案是 - 是的，您的模型是安全的。 –

@stereofrog爲什麼？這裏有什麼PHP不能做的，或者做得不好嗎？我真的沒有看到它 –

@stereofrog * *確實是一個問題，是真的。雖然有解決方案（[X-Sendfile]（http://codeutopia.net/blog/2009/03/06/sending-files-better-apache-mod_xsendfile-and-php/））。出於好奇，可以在Linux/Apache堆棧上運行的其他任何大型腳本語言以更好的方式解決這個問題嗎？的Perl/Python的/紅寶石？（如果你碰巧知道） –

這聽起來很好，只要它正確執行，當然;唯一缺少IMO的步驟是檢查3.和4.之間的可能的文件名衝突，和/或使用完全隨機的文件名。畢竟，在這種情況下，IP地址和時間戳並不是真正的相關信息。

在下載端，不需要在服務器上覆制文件。從祕密位置進行流式傳輸應該足夠了，因爲終端用戶永遠不會看到或訪問它。

來源

2011-10-06 09:17:08

3和4之間的碰撞是不太可能的，但基於前兩個字符（如git）的基於GUID和子目錄的解決方案會更好 –

@Konstantin同意，碰撞不太可能 - 但是如果攻擊者知道哈希產生，通過選擇時間戳和IP（儘管承認*非常*不太可能和微觀），可能會覆蓋別人的文件。無論如何應該有碰撞檢測。 –

這不會發生與GUID - 碰撞的機會是相同的整個開發團隊吃狼（從git手冊;）） –

允許用戶上傳任何文件。我的方法不安全嗎？

回答

相關問題