2014-03-13 82 views
2

我讀過關於使用s3 + cloudfront +簽名URL架構安全地向公共用戶提供私人內容的aws文檔。但對我來說似乎還不夠安全。讓我們分步描述:安全地提供私人內容s3 + cloudfront +簽名URL

第1步:用戶登錄到我的網站。

第2步:用戶點擊下載(PDF,圖片等)

第3步:我的Web服務器將生成標識的URL(截止時間:30秒),將用戶重定向到標識的URL和下載過程發生。

步驟4:現在,即使在30秒後超時,仍然有可能我的網絡上的任何惡意snipper都能夠捕獲簽名的url並下載我的用戶的私人內容。

有沒有想過這個?

回答

2

無論您使用何種機制來「保護」網絡上的任何內容,如果您不是使用HTTPS加密您的用戶與網站的交互,您預期會存在風險。

如果沒有加密,登錄信息或者傳達用戶身份驗證狀態的cookie也會以明文形式發送,用戶下載的任何內容都可以直接捕獲,而無需簽名鏈接......關注獲取下載通過嗅探鏈接似乎有點無趣,相比之下,這種設置中存在的一般和整體不安全的更重要的風險。另一方面,如果您的網站使用的是SSL,那麼當您向用戶提供簽名的URL時,有合理的期望,它將被加密窺探......以及類似地,如果鏈接到S3也使用HTTPS,在新的連接上的SSL建立之前瀏覽器通過電線傳輸任何信息,這將通過嗅探發現。因此,儘管這種機制涉及潛在的安全問題似乎是正確的,但我建議用戶交互安全的有效整體方法應該將任何S3簽名的URL特定問題的影響降低到一個級別相當於允許瀏覽器基於擁有一組證書請求資源的任何其他機制。

+0

事實上,我應該已經表明,所有的溝通都是通過HTTPS。現在擔心的是無論誰獲得簽名的URL,無論到期時間,都可能能夠下載我的私人文件。機會很渺茫,但這是可能的。我檢查了Dropbox的方法,實際上他們仍然通過他們的網絡服務器提供服務,而不是直接通過簽名的URL。因此添加了另一個安全層。 – Tommy

+0

的確如此,擁有網址意味着訪問內容,如擁有瀏覽器cookies或用戶密碼。通過您的網絡服務器流式傳輸文件雖然效率低下,但並不像有些人那樣糟糕,因爲AWS不會爲同一區域內的S3和EC2之間的帶寬收費(所以向您的服務器的傳輸是有效的「免費」)並將文件從網絡傳輸到網絡使用的資源(網絡)比從傳統的Web服務器(磁盤)下載文件更少。關鍵概念是流,而不是取/發。 –