保護會員網站查詢字符串的最佳策略？

比方說，你有3個表：保護會員網站查詢字符串的最佳策略？

User  Blog  Post 

UserId  BlogId  PostId 
Username BlogName PostTitle 
      UserId  BlogId

比方說，現在的博客的主人試圖訪問EditPost.aspx?ID=51。你如何保護這個查詢字符串，以便只有原始的Blog Owner才能看到真正的帖子。例如。用戶Jon沒有開始編輯用戶Mary的帖子？

幾個選項，我有：

1）我加密查詢字符串，這顯然不是100％安全，但做這項工作。

2）我每次檢查查詢字符串中的PostID是否確實是登錄用戶的Post，方法是根據Session中的用戶ID進行檢查。這樣做的缺點是，這是好的，如果我只有3個表，但如果我有關係10-12表的層次結構，我有第一個表中的用戶ID，我實際上查詢第12表，我需要檢查一路回到頂端，通過12個連接來真正看到這個事情是否真的是他的。

問題是你真的在你的網站中使用了哪一個，並且這個工作很好？

來源

2012-04-12 Jack

您已經知道答案：2.您可能希望在數據庫中創建視圖以隱藏某些連接。 – HABO 2012-04-12 16:30:20

爲什麼不在顯示頁面之前檢查**用戶**和**角色**對帖子？也試着對你在標註時使用的技術進行具體化。 – 2012-04-12 16:32:41

@humpty dumpty坐在牆上：明白這不是一個技術問題。這是一般網絡開發概念，任何技術開發人員都會遇到。 – Jack 2012-04-12 16:38:28

查詢字符串不需要加密，只需要在您的渲染或數據發佈給您時隨時進行服務器端檢查。

您的安全檢查沒問題。如果你有12個連接來獲取你的數據，我會說重新構建你的數據模型或者將用戶外鍵存儲在更多的地方。

來源

2012-04-12 16:38:23

存儲外鍵是多個表？這不違反正常形式規則嗎？在這種情況下，博客的博客ID永遠不會改變。但是當這樣的ID可以改變時會發生什麼？我應該記住並更新多個表中的這些密鑰嗎？ – Jack 2012-04-12 16:51:54

是的，但是如果需要的話，數據庫可以級聯...等等，但實際上這並不是那個地方，但是有大量的數據庫體系結構可以滿足不同的數據模型需求。 – 2012-04-12 17:07:08

爲了控制記錄的編輯，您需要知道誰擁有它。

方法＃1存在缺陷，因爲它可能容易受到重播攻擊，或者更重要的是，它假定用戶已成功導航到頁面，並且他們被授權。這是「通過默默無聞的安全」，是一個很大的禁忌。

方法＃2是您唯一的選擇。如果您擔心將PostID綁定到UserID的連接數量，則應發佈有關優化查詢的新問題（並提供有關查詢和特定數據庫結構的更多信息）。

來源

2012-04-12 16:38:08 pseudocoder

保護會員網站查詢字符串的最佳策略？

回答

相關問題