問(wèn)題描述
我是 PHP 新手，這也是我第一次登錄系統(tǒng)，所以如果你們能查看我的代碼，看看是否能發(fā)現(xiàn)任何安全漏洞，那就太好了:
I'm new to PHP and this is also my first log in system so it would be great if you guys could look over my code and see if you can spot any security holes:
注意:盡管此處未顯示，但我正在清理所有用戶輸入.
note: I am sanitizing all user input although it's not shown here.
第 1 步:我使用用戶選擇的密碼并通過(guò)此函數(shù)運(yùn)行它:
Step 1: I take the password the user chose and run it through this function:
encrypt($user_chosen_password, $salt);
function encrypt($plain_text, $salt) {
if(!$salt) {
$salt = uniqid(rand(0, 1000000));
}
return array(
'hash' => $salt.hash('sha512', $salt.$plain_text),
'salt' => $salt
);
}
第 2 步:然后我存儲(chǔ)散列和鹽($password['hash'] 和 $password['salt']>) 在數(shù)據(jù)庫(kù)中的用戶表中:
Step 2: I then store the hash and the salt ($password['hash'] and $password['salt']) in the users table in the database:
id | username | password | salt | unrelated info...
-----------------------------------------------------------
1 | bobby | 809a28377 | 809a28377f | ...
fd131e5934
180dc24e15
bbe5f8be77
371623ce36
4d5b851e46
登錄:
第 1 步: 我使用用戶輸入的用戶名并在數(shù)據(jù)庫(kù)中查找是否返回任何行.在我的網(wǎng)站上，沒(méi)有 2 個(gè)用戶可以共享相同的內(nèi)容username 因此用戶名字段始終具有唯一值.如果返回 1 行，我會(huì)為該用戶獲取鹽.
Log In:
Step 1: I take the username the user entered and do a look up on the database to see if any rows are returned. On my site no 2 users can share the same username so the username field always has a unique value. If I get 1 row returned I grab the salt for that user.
第 2 步: 然后我通過(guò) encrypt 函數(shù)運(yùn)行用戶輸入的密碼(如之前發(fā)布的)，但這次我還提供了從數(shù)據(jù)庫(kù)中檢索到的鹽:
Step 2: Then I run the user entered password through the encrypt function (as previously posted above) but this time I also supply the salt retrieved from the database:
encrypt($user_entered_password, $salt);
第 3 步:我現(xiàn)在有正確的密碼來(lái)匹配這個(gè)變量:$password['hash'].所以我對(duì)數(shù)據(jù)庫(kù)進(jìn)行了第二次查找，看看是否輸入的用戶名和散列密碼一起返回單行.如果是，那么用戶的憑據(jù)是正確的.
Step 3: I now have the proper password to match against in this variable: $password['hash']. So I so a second lookup on the database to see if the
username entered and the hashed password together return a single row. If so then the user's credentials are correct.
第 4 步:為了在用戶的憑據(jù)通過(guò)后登錄，我生成了一個(gè)隨機(jī)的唯一字符串并將其散列:
Step 4: In order to log the user in after their credentials passed I generate a random unique string and hash it:
$random_string = uniqid(rand(0, 1000000));
$session_key = hash('sha512', $random_string);
然后我將 $session_key 插入到數(shù)據(jù)庫(kù)中的 active_sessions 表中:
I then insert the $session_key into the active_sessions table in the database:
user_id | key
------------------------------------------------------------
1 | 431b5f80879068b304db1880d8b1fa7805c63dde5d3dd05a5b
第 5 步:
我將最后一步生成的未加密的唯一字符串 ($random_string) 設(shè)置為我稱之為 active_session 的 cookie 的值:
I take the unencrypted unique string generated in the last step ($random_string) and set that as the value of a cookie which I call active_session:
setcookie('active_session', $random_string, time()+3600*48, '/');
第 6 步:
在我的 header.php 包含的頂部有這個(gè)檢查:
At the top of my header.php include there is this check:
if(isset($_COOKIE['active_session']) && !isset($_SESSION['userinfo'])) {
get_userinfo();
}
get_userinfo() 函數(shù)在數(shù)據(jù)庫(kù)中的 users 表上進(jìn)行查找，并返回一個(gè)關(guān)聯(lián)數(shù)組，該數(shù)組存儲(chǔ)在名為 userinfo:
The get_userinfo() function does a lookup on the users table in the database and returns an associative array which is stored in a session called userinfo:
//首先這個(gè)函數(shù)獲取active_session cookie的值并散列它以獲得session_key:
// first this function takes the value of the active_session cookie and hashes it to get the session_key:
hash('sha512', $random_string);
//然后它會(huì)在 active_sessions 表上進(jìn)行查找以查看此 key 的記錄是否存在，如果存在，它將獲取 user_id 與該記錄相關(guān)聯(lián)，并使用它對(duì) users 表進(jìn)行第二次查找以獲取 userinfo:
// then it does a lookup on the active_sessions table to see if a record by this key exists, if so it will grab the user_id associated with that record and use this to do a second lookup on the users table to get the userinfo:
$_SESSION['userinfo'] = array(
'user_id' => $row->user_id,
'username' => $row->username,
'dob' => $row->dob,
'country' => $row->country,
'city' => $row->city,
'zip' => $row->zip,
'email' => $row->email,
'avatar' => $row->avatar,
'account_status' => $row->account_status,
'timestamp' => $row->timestamp,
);
如果 userinfo 會(huì)話存在，我知道用戶已通過(guò)身份驗(yàn)證.如果它不存在但 active_session cookie 存在，則該檢查header.php 文件頂部將創(chuàng)建該會(huì)話.
If the userinfo session exists I know the user is authenticated. If it doesn't exist but the active_session cookie exists then that check
at the top of the header.php file will create that session.
我使用 cookie 而不是單獨(dú)使用會(huì)話的原因是為了保持登錄.因此，如果用戶關(guān)閉瀏覽器，會(huì)話可能會(huì)消失，但cookie 將仍然存在.并且由于在 header.php 的頂部有那個(gè)檢查，會(huì)話將被重新創(chuàng)建并且用戶可以作為記錄的在用戶正常.
The reason why I am using a cookie and not sessions alone is to persist the login. So if the user closes the browser the session may be gone but the
cookie will still exist. And since there is that check at the top of header.php, the session will be recreated and the user can function as a logged
in user as normal.
第 1 步:userinfo 會(huì)話和 active_session cookie 都未設(shè)置.
Step 1: Both the userinfo session and the active_session cookie are unset.
步驟 2: 刪除數(shù)據(jù)庫(kù)中 active_sessions 表中的關(guān)聯(lián)記錄.
Step 2: The associated record from the active_sessions table in the database is removed.
注意:我能看到的唯一問(wèn)題(也許還有很多其他問(wèn)題)是用戶是否通過(guò)在瀏覽器中自行創(chuàng)建來(lái)偽造 active_session cookie.當(dāng)然，他們必須將一個(gè)字符串設(shè)置為該 cookie 的值，該字符串在加密后必須與 active_sessions 表中的記錄匹配，我將從該表中檢索 user_id 以創(chuàng)建該會(huì)話.我不確定這在現(xiàn)實(shí)中的可能性有多大，對(duì)于用戶(可能使用自動(dòng)化程序)正確猜測(cè)他們不知道的字符串然后將被 sha512 加密并與 active_sessions<中的字符串匹配/code> 數(shù)據(jù)庫(kù)中的表以獲取用戶 ID 以構(gòu)建該會(huì)話.
Notes: The only issue I can see (and perhaps there are many others), is if the user fakes that active_session cookie by creating it themselves in their browser. Of course they must set as that cookie's value a string which after it is encrypted must match a record in the active_sessions table from where I will retrieve the user_id to create that session. I am not sure what the chances of this is realistically, for a user (perhaps using an automated program) to guess a string correctly which they don't know will then be sha512 encrypted and matched against the string in the active_sessions table in the database to get the user id to build that session.
對(duì)于這篇大文章很抱歉，但由于這是我網(wǎng)站的關(guān)鍵部分，而且由于我缺乏經(jīng)驗(yàn)，我只想讓更有經(jīng)驗(yàn)的開(kāi)發(fā)人員運(yùn)行它，以確保它實(shí)際上是安全的.
Sorry for the big essay but since this is such a critical part of my site and due to my inexperience I just wanted to run it by more experienced developers to make sure it's actually safe.
那么您是否發(fā)現(xiàn)這條路線存在任何安全漏洞以及如何改進(jìn)?
So do you see any security holes in this route and how can it be improved?
推薦答案
您應(yīng)該包括某種超時(shí)或故障轉(zhuǎn)移以防止暴力攻擊.有很多方法可以做到這一點(diǎn)，包括基于 IP 的阻止、增量超時(shí)等.這些方法都不會(huì)阻止黑客，但它們會(huì)使黑客變得更加困難.
You should include some kind of timeout or failover to prevent against brute-force attacks. There are a number of ways to do this, including IP-based blocking, incremental timeouts, etc. None of these will ever stop a hacker, but they can make it much more difficult.
另一點(diǎn)(你沒(méi)有提到，所以我不知道你的計(jì)劃)是失敗消息.使失敗信息盡可能含糊.提供諸如該用戶名存在，但密碼不匹配"之類的錯(cuò)誤消息可能對(duì)最終用戶有幫助，但會(huì)殺死登錄功能.您剛剛將需要 O(n^2) 時(shí)間的蠻力攻擊轉(zhuǎn)??換為 O(n) + O(n).不需要嘗試彩虹表中的每個(gè)排列(例如)，黑客只需首先嘗試用戶名的所有值(使用設(shè)置的密碼)，直到失敗消息發(fā)生變化.然后，它知道一個(gè)有效用戶，只需要暴力破解密碼.
Another point (which you haven't mentioned, so I don't know your plan) is failure messages. Make failure messages as vague as possible. Providing an error message like 'That username exists, but the passwords did not match' might be helpful to the end-user, but it kills login functionality. You just converted a brute-force attack that should take O(n^2) time to O(n) + O(n). Instead of needed to try every permutation in a rainbow table (for example), the hacker just tries all values for username (with a set password) first, until the failure message changes. Then, it knows a valid user, and just has to brute force the password.
沿著這些思路，您還應(yīng)該確保用戶名存在和不存在時(shí)經(jīng)過(guò)的時(shí)間相同.當(dāng)用戶名實(shí)際存在時(shí)，您正在運(yùn)行其他進(jìn)程.因此，當(dāng)用戶名存在與不存在時(shí)，響應(yīng)時(shí)間會(huì)更長(zhǎng).一個(gè)非常熟練的黑客可以計(jì)時(shí)頁(yè)面請(qǐng)求以找到有效的用戶名.
Along those lines, you should also make sure that the same amount of time elapses when a username exists and doesn't exist. You are running additional processes when a username actually exists. As such the response time would be longer when a username exists vs when it doesn't. An incredibly skilled hacker could time page requests to find a valid username.
同樣，您應(yīng)該確保除了使 cookie 過(guò)期外，還應(yīng)使會(huì)話表過(guò)期.
Similarly, you should make sure that, in addition to expiring cookies, you also expire the sessions table.
最后，在 get_user_info() 調(diào)用中，如果有多個(gè)并發(fā)的活動(dòng)登錄，您應(yīng)該終止所有打開(kāi)的會(huì)話.確保在一段時(shí)間(如 30 分鐘)不活動(dòng)后超時(shí)會(huì)話.
Lastly, in the get_user_info() call, you should terminate all open sessions if there are multiple concurrent, active logins. Make sure you timeout sessions after a set amount of inactivity (like 30 minutes).
根據(jù)@Greg Hewgill 提到的內(nèi)容，您沒(méi)有包含以下任何內(nèi)容:
Along the lines of what @Greg Hewgill mentioned, you haven't included any of the following:
- 服務(wù)器-客戶端之間的 SSL/加密連接
- 您經(jīng)常用于處理身份驗(yàn)證的其他傳輸協(xié)議(如 OAuth)
您的服務(wù)器是安全的，但如果有人可以讀取交換的數(shù)據(jù) (MITM)，那么您的算法有多安全并不重要.您應(yīng)該確保僅通過(guò)加密協(xié)議進(jìn)行通信.
You server is secure, but it doesn't matter how awesomely secure your algorithm is if someone can read the data that's exchanged (MITM). You should make sure you are only communicating over an encrypted protocol.
這篇關(guān)于我的 PHP 登錄系統(tǒng)有多安全?的文章就介紹到這了，希望我們推薦的答案對(duì)大家有所幫助，也希望大家多多支持html5模板網(wǎng)！