我已經讓另一位開發人員提出了將php的所有參數加密/加密/隱藏到頁面的可能性，作爲針對通過製作的url進行操作的安全措施，並防止數據庫的內部知識（例如，知道數據庫中的id的具體條目）。建議加密url參數而不是以純文本格式進行加密？
換句話說，代替單個或多個公共查詢參數（如id），將會有一個加密的blob，它將在服務器端進行解密，並在製作鏈接時進行重新加密。
這種方法有問題嗎？是否有實實在在的價值？這種方法在野外使用效果好嗎？
您應該設計您的系統以防止未經授權的訪問。模糊（對客戶端產生的數據進行有用的加密不是一種可能性）不是一種有價值的防禦措施。
而不是給用戶一個數據庫ID，給他們一個哈希（可能會議種子）的ID。散列的128bit +搜索空間和（對於合理的數據庫大小）碰撞概率較低將是更好的方法。你也可以加密服務器上的ID，以獲取客戶端從不需要操作的值（使用種子），但要確保它具有與我提到的散列相同的屬性 - 即搜索空間與可能的值空間相比非常大。
我更喜歡這個答案，當它只是第一段。 :) – sarnold 2011-05-24 22:30:49
@sarnold：我也是，但我想爲潛在的解決方案拋出骨頭。 – 2011-05-24 22:32:42
可能有些情況下，這種類型的URL加密（或Obsfucating）是有用的。假設您在應用程序中構建了非常強大的安全性，並且所有主機都安全無虞。
現在，如果您的操作人員恰好是外部人員，並且您不希望他們通過即時更改日誌級別來了解/查看這些敏感數據（ID），那麼最好對其進行加密並按需解密個人模塊。
作爲一般的做法，不應該在URL參數中傳遞任何敏感數據，並且應該注意不要在更高級別上記錄它們。
如果要防止用戶用GET參數亂搞，我想提出以下建議：
添加一個隱藏的表單給您的所有網頁。點擊頁面上的任何位置，將填入表格中的一些數據並通過POST/SSL安全地提交。沿着提交的詳細信息，傳遞你想要引導用戶的URL。
在服務器端，收集參數，將它們放入會話中，無論是全局還是附加到目標URL的某種標識符。發送重定向回來。這樣，如果用戶刷新頁面，他不會對POST數據感到不安。另外，如果他開始在應用程序中回頭和旁觀，請殺死會話緩存並將其發送到起始頁面。
我在一些在線銀行軟件中看到了這種技術。另一個好處是用戶無法打開新窗口。
在我看來，它可以增加一定程度的安全性，但會嚴重改變發展方式，給你更多的工作。我從來沒有使用過這種方法，我認爲只要你有一個適當的ORM系統，ID就可以安全傳遞，在任何情況下都不會讓用戶A訪問用戶B的數據，無論你的開發人員使用什麼樣的代碼將會寫。
我可以看到的一個潛在缺點是它使測試更加困難，因爲你不能只是拋出你想要的任何值，而是必須重新創建加密的blob – 2011-05-24 22:27:45