我正在增強遺留系統（我沒有幫助構建），並希望從其他人那裏瞭解我注意到的某些事情是否是合法的安全問題。隱藏字段的這些用途是否不安全？
首先，應用程序通過登錄來保護。但是，一旦用戶登錄，整個應用程序就有11個頁面，其中隱藏字段存儲文件名的值以及下載路徑。
Javascript用於自動提交表單，然後用戶將文件下載並保存到他或她的計算機上。我在想這個值可能會改變，用戶會不知不覺地下載一個惡意文件。
此外，還有許多頁面將引用頁面保存在隱藏字段中，以便用戶在保存表單時可以返回到上一頁。如果這些都是合法的問題，那又如何？如果可能的話，他們將如何受到攻擊？什麼是風險水平或潛在影響？我問的原因是，我可以提出這樣的情況，如果是這樣的話，應用程序需要修復。只是說「這不是一個好的做法」並不是一個好的理由。
感謝您的反饋！
很可能不安全。隱藏的表單字段是一個很好的實現。
具體而言，您不能依賴表單字段的值以與原始HTML呈現的值相同的值回發到服務器。
如果服務器實現了諸如對輸入，校驗和，散列，加密等進行消毒的對策，則使用可能會更安全一些。例如，ASP.NET使用ViewState進行此操作。
也就是說......
想看看它是多麼不安全？使用Chrome或Firefox開發人員工具將其中一個隱藏字段的輸入類型屬性從「隱藏」更改爲「文本」，然後觀看顯示的文本字段（您可以更改它並提交您喜歡的任何值）。
我也強烈推薦在他的回答中閱讀馬特關於潛在風險分析的觀點。
如果不能以惡意的方式操縱該值，那麼這並不完全不安全。然而，在這種情況下，我認爲至少第一個問題聽起來非常像本地文件包含漏洞。你爲什麼說「提交你喜歡的任何*用戶名*」？ – 2012-02-21 23:34:50
用戶名是錯字，已更正。基於OP，我懷疑這些是明文值。如果它們被散列或加密，則它是一個不同的故事。 – 2012-02-21 23:35:38
不，我的意思是如果服務器端實現適當的輸入消毒。例如，如果服務器只允許指向有效下載目錄的路徑，則它可能是安全的。 – 2012-02-21 23:39:03
除了什麼克里斯沙恩說：
什麼風險或潛在影響的程度如何？ 根據服務器端腳本所做的假設，這可能會非常嚴重。如果隱藏字段包含user_id或username，並且假設此信息是合法的，那麼任何人都可以代表其他人執行操作，只需通過更改表單字段，如Chris Shain所解釋的。
那是什麼與「用戶名」？他具體告訴我們這些隱藏的字段有哪些值，並且它們都不是「用戶名」。 – 2012-02-21 23:36:29
我猜測的原始開發人員知道不要在隱藏字段中包含用戶標識或用戶名。但是，有*許多*主鍵，例如行ID，通過隱藏字段傳遞。我不知道（沒有更徹底的調查）是否在訪問或更新數據之前檢查當前用戶的權限。不過，我想知道，鑑於所有這些都在登錄屏幕後面，所有這些問題都無關緊要嗎？ – 2012-02-22 16:00:08
@JasonLuttrell取決於。如果我可以獲得登錄（任何登錄），那麼我可以編輯這些行ID字段並提交表單以訪問潛在的敏感數據嗎？ – 2012-02-22 16:09:21
這個問題可能更適合[Security.StackExchange.com]（http://security.stackexchange.com） – serk 2012-02-21 23:33:15
第一聽起來很像LFI對我來說（非常危險，可能有人可以下載您的數據庫訪問數據，例如，或者基本上他想要的任何文件）。只要嘗試將'../../../../../etc/passwd'等東西放入該字段或其他東西時會發生什麼。第二個（上一頁）也沒有聽起來有風險，除非可以通過GET參數或某種方式操縱該值，在這種情況下，它將是XSS/HTML注入問題。 – 2012-02-21 23:37:18
非常好的一點，Niklas。非常感謝您的反饋，我一定會做更多的調查！塞爾克，我甚至沒有意識到，有各種主題的專門部分。我將銘記未來。謝謝。 – 2012-02-22 15:47:35