Неужели я подозреваю, что этот сгенерированный PHP-код уязвим?

Question

Я не очень образован на PHP или Web-безопасности в целом, но я сильно подозреваю, что код, созданный некоторым программным обеспечением, для которого я работаю, является небезопасным.

Вот некоторые фрагменты того, что я обеспокоен:

Первый относятся:

$sql = "SELECT password, fullname FROM ".$mysql_table." 
WHERE username = '".mysqli_real_escape_string($db,$_POST['username'])."'"; 

Это плохо, чтобы получить пароль для данного пользователя, а затем сравнивая их в PHP, или лучше рекомендуется использовать пароль в самом запросе, что-то вроде этого:

... WHERE username = $username AND password = $hashed_password 

Вторая проблема:

$crypt_pass = md5($_POST['password']); 
if ($crypt_pass == $data['password']) 
{ 
    //LOGIN SUCCESS 
} 

Пользуется md5-хеширование, а не с помощью соли, достаточно?

Третья проблема:

setcookie('username', $_POST['username'], time() + 3600*24*30); 
setcookie('password', $_POST['password'], time() + 3600*24*30); 

Это хорошая идея, чтобы хранить простые/текстовые имена пользователей и пароли в печенье?

Является ли какой-либо из этого кода небезопасным, и если да, что следует делать вместо этого?

Answer 1

Существует на самом деле еще один вопрос вам не хватает:

Проблема: Этот код использует «==» для проверки равенства на хэшей. PHP может смело принять решение о принуждении первых частей этих строк к числам, а затем сравнить «действительные» части этих чисел. Например, PHP решит, что «0e» начинает номер научной нотации, значение которого всегда будет равно нулю. Таким образом, любые два хэша, начинающиеся с 0e и содержащие только числа после того, будут совпадать друг с другом.

"0e111111" == "0e123456"; # true, in PHP world.

Есть много других способов это может пойти не так, тоже. Всегда используйте «===» в PHP для сравнения хэша.

Возможно, не проблема: Отправка хэша пароля из базы данных на веб-сервер вряд ли когда-либо будет проблемой, если злоумышленник может прослушать этот трафик, у вас уже есть серьезные проблемы. И альтернатива заключается в том, чтобы включить ваше хешированное значение в ваш запрос на сервер базы данных - в любом случае что-то происходит по ссылке. Если вам нужна безопасность здесь, вам, вероятно, нужна специальная система проверки подлинности, которая не имеет ничего общего с вашей базой данных.

Основная проблема: Да, у вас должен быть один пользователь, долго, соли. Без длинных солей пароли пользователей хранятся в грубом эквиваленте обычного текста. Злоумышленник просто ищет хеши MD5 в таблице радуги, чтобы увидеть соответствующие пароли. Например, 482c811da5d5b4bc6d497ffa98491e38 выглядит надежно, но вы можете найти его, чтобы узнать, что это «пароль123».

Основная проблема: Хранение пароля в файле cookie является ужасным. Он будет путешествовать по сети для каждого запроса, хранить незашифрованные на компьютере пользователя и отправляться вместе с каждым запросом на что-либо в вашем домене (на изображения, на любые файлы с угрозами, которые были загружены). Кроме того, эти файлы cookie не установлены HttpOnly, что означает, что любой javascript на странице (от кого-либо) сможет прочитать пароль пользователя.

Answer 2

Первое беспокойство

Не особенно. До тех пор, пока он хорошо защищен от инъекций XSS и SQL и тому подобного. Лично я предпочитаю сравнивать их как с базой данных.

Вторая проблема

MD5, а @ gabe3886 сказал, не должен использоваться для хранения паролей. Я лично использую: http://www.openwall.com/phpass/. Но есть множество реализаций хеширования. Попробуйте найти в Интернете.

Третье беспокойство

Нет, это не так. См.: https://stackoverflow.com/a/2100386/3455727

Что следует использовать вместо: Ну, я понятия не имею, почему вы даже сохранили имя пользователя и пароль в файле cookie, поэтому их в базе данных должно быть достаточно.