使用PHP傳遞URL參數

我正在創建一個程序，它與Web服務器上的PHP腳本進行通信，爲此我需要能夠將參數從程序傳遞到PHP腳本。使用PHP傳遞URL參數

現在，這是我的問題。有時需要將用戶名和密碼傳遞給腳本。現在，這不是以一種對用戶來說很明顯的方式完成的（例如在地址欄中），但我知道只需要在某人身邊嗅探一下真正想知道的人。所以雖然我的腳本安全無法注入，但顯然變量篡改是一個問題。

這是一個想法，我已經想出了，所以請幫我把頭繞在它周圍，看看這是否會以我認爲的方式工作。

我的想法是在發送之前在客戶端加密用戶密碼（或另一個唯一鍵）變量，以便獲得類似於（顯然就是組成）mypage.php的鏈接？un = Oa348uty8 & ps = op986hGTfreu然後當它會得到PHP腳本解密並用不同的鹽再次加密。

因此，當它離開應用程序時，它會被加密，但不是正確的方式，然後當它命中PHP腳本時，服務器端解密並用正確的鹽重新加密，以便正確匹配存儲的加密密碼。

這樣，他們的用戶不會知道他們的密碼的加密版本應該是什麼樣子，但他們不會篡改URL並嘗試插入假值。

來源

2012-03-29 Chris

這是怎麼不同於_normal_登錄情況？如果你有加密可用，只需使用正常的，正確的方法。 – Halcyon 2012-03-29 23:33:04

當你將密碼存儲在你的服務器上作爲散列字符串 - 無論如何你應該這樣做。（如sha256或類似的東西），那麼最好的辦法是生成散列客戶端，並且只將散列傳送給服務器。剩下的就是簡單的字符串比較。不需要解密。 – Rufinus 2012-03-29 23:35:18

給予URL的加密密碼不能被人解密。儘管如此，黑客還可以將其重新用於其他連接（即加密）。 – Skrol29 2012-03-29 23:46:31

爲了把它概括地說，你這種思維：

在服務器端，您有：

數據庫，與登錄/密碼匹配。
一個腳本，需要2個參數（用戶名和密碼），並在數據庫中檢查的夫婦存在

您的問題：

當你的本地應用程序調用服務器端，2 PHP腳本參數以純文本形式給出。而你想避免篡改（如果你的腳本是安全的對注入我只看到篡改用來猜解的權威性< =記住，我會繼續這個假設在整個後）

您的解決方案：

在客戶端，加密的2個參數
在服務器端，在腳本中添加鹽鹽
然後解密2個參數和鹽

加密10

我認爲：

這不會解決篡改問題，有人仍然可以僞造請求。第一次加密是無用的，因爲有人可以檢索客戶使用的密鑰。第二次加密不夠安全，因爲您爲所有用戶使用相同的鹽。

我的建議：

接受該篡改無法避免的，如果你不喜歡使用HTTPS安全協議（既可以使用SSL或TLS）。如果不想HTTPS以下的可接受的安全是我會實現：

令牌系統，你會爲了檢查是否用戶可以進行登錄操作
一個用戶名是不會加密
將密碼sha1哈希存儲在數據庫中
在客戶端，您調用腳本並將用戶名設置爲非加密，並將密碼提供爲sha1哈希，並用隨機salt（sha1（sha1（pass） +鹽）（鹽存儲在服務器端的用戶會話中）
腳本將進行比較與會議鹽改頭換面分貝密碼哈希提供的哈希

的改進是，攻擊者必須設法蠻力力的雙SHA1密碼consecutivaly，必須提供有效的憑證進行登錄操作。此外，如果你使用一個字符串作爲鹽，使用十六進制字符的變量甚至長度，這將使得攻擊者更難以認識到由第二個哈希強制的值是sha1哈希，即使他知道這是一個sha1將不得不測試多個案例以試圖找到與哈希對應的值的正確部分。

由於可變鹽的，一個相同的密碼將不如果散列相同的：想象攻擊者嗅到的散列，並且知道使用了哪個密碼然後嗅出，其用相同的密碼作爲其它由另一種散列，所述攻擊者將無法知道2個密碼在哪裏相同（有點矯枉過正，但仍然有用）。

將密碼存儲爲哈希值更安全，因爲如果攻擊者設法轉儲您的用戶表，他將無法立即使用密碼，他將不得不暴力破解。最後SHA1哈希比MD5更安全（我告訴你，因爲你用在您的文章的MD5標籤）

這種方法的缺點是密碼不能被逆轉，所以你將不能夠給出如果它們丟失了，它們會返回給用戶。你將不得不讓他們設置一個新的。

的鐵桿方式（仍然沒有使用HTTPS），將加密您的密碼和用戶名具有強烈CYPHER（如AES或3DES），並使用安全密鑰ECHANGE algorythm（如Diffie Hellman一個）來交換一個隨機共享鍵。

這種方法不會阻止篡改，但會攻擊者，因爲他不能解密該值（假設他只是嗅探網絡）。密鑰是隨機的，並且不會在任何應用程序中進行硬編碼，所以即使有人倒過來您的客戶端，他也無法獲取密鑰。我仍然建議您存儲您的密碼值有散列。

一個極端的方法是合併2種方法，但完全是矯枉過正。

希望這會給你的想法

來源

2012-03-30 00:23:16 grifos

但是，爲什麼所有這些問題都可以使用HTTPS安全輕鬆地解決？ – F21 2012-03-30 00:41:05

因爲有時你不想使用https（https是我的意思是SSL）或不能使用它（例如：你租用了一個不允許https的webspace）。 https需要證書，並且如果您不想爲簽名證書付費並且該應用程序在通用瀏覽器中運行，則會有一個醜陋消息，告訴您接受自簽名證書。使用另一種方法可以避免這種情況。但在使用自定義客戶端並且https可以在服務器端激活的情況下，我完全同意您應該使用https而不是實現自己的安全方法。 – grifos 2012-03-30 00:53:12

謝謝，這給了一些想法，並指出我在正確的方向！順便說一下，我不在mt數據庫上使用md5，但是按照我原來的思路，第一個哈希需要是可逆的。 – Chris 2012-03-30 02:54:28

您的方法問題不在於您是否在URL中使用了加密的密碼和用戶名。如果用戶通過向您發送加密字符串進行身份驗證，那麼作爲攻擊者的我仍然可以嗅出這些哈希值，將它們傳遞給您的應用程序並進行身份驗證。除非這樣，否則你會事先做一些公鑰/私鑰交換，但這只是重新實現HTTPS，所以你不妨使用HTTPS。

您應該做的是使用POST通過HTTPS發送請求。

POST：這樣驗證詳細信息將不會顯示在URL中並顯示在日誌和引用網址中。
HTTPS使整個請求的內容完全加密，只能由客戶端應用程序和服務器端解密。

來源

2012-03-29 23:38:09 F21

用Javascript從客戶端到服務器的加密僅防止非SSL發佈失敗。我認爲你必須使用sessions而不是這種類型的加密。

來源

2012-03-29 23:41:47 Huseyin

更新：您可以在兩個腳本中添加您自己的密鑰。

來源

2012-03-29 23:45:48 ArendE

使用PHP傳遞URL參數

回答

相關問題