URL參數的最佳實踐

它對保護URL參數命名有多重要？ ?user_id=3安全性較低，?uid=3或?u=3或/user/3？我真的應該考慮讓參數難以猜測嗎？URL參數的最佳實踐

2014-03-28 aceph

沒有一個例子或多或少都不安全 – 2014-03-28 02:33:11

@Dagon：實際上，它們同樣不太安全。 –

小於什麼？與之相比，少一些毫無意義。 – 2014-03-30 02:01:35

朦朧根本就沒有安全感。要考慮的唯一合理因素是鏈接的可讀性/漂亮性。如果你有200個字符的鏈接，它們不會令人難忘，並且很難粘貼，並且消耗大量空間（例如不能通過SMS發送，並且很難在移動設備上輸入）。另一方面，如果你能理解它的語義，就更容易對鏈接有信心。

來源

2014-03-28 02:34:07 Amadan

我不同意。朦朧使一個較小的目標回到原來的位置，往往就夠了。（不是指這個具體的例子，只是想到你說的東西的普遍性） –

@SteveHorvath：你可能不同意，但幾乎沒有安全工程師。這可能會讓你不再成爲偶爾黑客攻擊的目標，但是任何知道自己在做什麼的人都不會被阻止。 http://en.wikipedia.org/wiki/Security_through_obscurity – Amadan

這是一個非常好的問題。我不認爲它需要 - 或者可以 - 真的很安全。而且都有優勢。例如：

使其縮短並且網址將變短。（如果將動態網址動態地組合在一起，太長的網址可能會成爲問題）
讓它變得漫長，並且稍後可以更輕鬆地進行調試。 :)

來源

2014-03-28 02:33:43

userid應該是一個會話變量，並且會話ID應該在cookie中。

一些安全信息說，爲了避免所有的URL變量，但這只是通過默默無聞的安全性。重點是，如果它通過任何來源$_GET,$_POST,$_COOKIE,$_SERVER,$_REQUEST,$_FILE ...來通過用戶，您需要對其進行消毒。通過：使用

白名單儘可能
使用正則表達式和類型檢查之前使用
如果它會顯示所有的輸入，使用strip_tags() [刪除HTML
- 如果有一些合法的標籤]
- 或htmlentities() [首選]
使用準備語句（庫MySQLi或PDO是可以做的MySQL數據庫準備好的發言公共庫）的所有數據庫查詢，以防止SQL注入
使用nounce防止XSFR攻擊和事故重新提交表單
如果一個文件檢查MIME類型（而不僅僅是但它 - 使用mod_rewrite是隱藏變量的真實姓名可能不是一個可怕的想法，而且可能使你的URL「漂亮」的用戶：DR;移動之前

TL的$FILE數組中的MIME類型）並不是一個巨大的安全收益。

來源

2014-03-28 02:41:04

總體而言，我發現對實施的考慮至關重要。這會被你和幾個朋友使用嗎？在這種情況下，擔心你命名的URL變量可能不那麼重要。

如果數據很敏感，請不要將它放在URL中 - 這包括特定於用戶的信息，如密碼（您不應該使用純文本），密碼哈希值，電子郵件地址，私人密碼信息等。我不太擔心用戶名。如果信息非常重要/敏感，請發佈它而不是GET。

將.htaccess和一些rewriteRules一起使用可以使URL更容易記住 - 例如，website.com/page/1比website.com?page=1更加用戶友好，特別是當您獲得更多那裏有1個變量。 .htaccess rewriterules不難製作，並且可以幫助您的網站看起來更專業。

就url中的變量NAMES而言，它又取決於用法。例如，「user = username」會很好，甚至可以接受「u = uname」或「uid = username」，但如果你擔心用戶可能很容易找到並改變某些內容，那麼這是一個很大的指標，問題：不是因爲用戶可以在那裏改變某些東西（甚至POST不安全，用戶可以發佈任何他們想要的東西），而是因爲你的後端應該被構建來處理它，即使你的用戶改變了POST/GET中的東西。

TL; DR：將GET變量放入URL欄是對用戶的禮貌。如果他們會欣賞或使用它，那就做吧 - 這是一個很好的接觸。用戶不希望你把敏感信息放在那裏，用戶也不希望它太長。任何和所有的安全措施都應該在後端完成，在後端用戶不能篡改它。

來源

2014-03-28 03:01:02 Helpful

URL參數的最佳實踐

回答

相關問題