php login authentification token_id и скрипт входа в сеть - безопасно?

Question

При создании моего нового сайта мне нужен новый сценарий входа, поэтому я могу чувствовать себя комфортно с моими данными. Раньше я делал такие скрипты, но знал, насколько они безопасны. Надеясь найти какой-то андер в Интернете, я нашел такой учебник, который называет себя «супер безопасным скриптом входа». Вы можете найти это в этом link

Интересно, насколько это безопасно и какие угрозы уязвимы.

Я также нашел в строках кода, как это:

// Create Second Token 
$tokenId = rand(10000, 9999999); 
$query2 = “update users set tokenid = $tokenId where userid = ‘$_SESSION[userid]‘”; 
$result2 = mysql_query ($query2); 
$_SESSION['token_id'] = $tokenId; 

Как это должно работать? Чего он предотвращает? Должен ли я сравнивать $ _SESSION ['token_id'] с чем-то позже или что?

Answer 1

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

я бы не рекомендовал сценарий входа в систему вы связаны с по этим причинам:

1) Как она сбегает ввод данных пользователем, чтобы избежать SQL Injection

Вот функция, которая используется:

function escape_data ($data) { 

// Check for mysql_real_escape_string() support. 

// This function escapes characters that could be used for sql injection 

if (function_exists(‘mysql_real_escape_string’)) { 

global $dbc; // Need the connection. 

$data = mysql_real_escape_string (trim($data), $dbc); 

$data = strip_tags($data); 

} else { 

$data = mysql_escape_string (trim($data)); 

$data = strip_tags($data); 

} 

// Return the escaped value. 

return $data; 

} // End of function. 

У вышеуказанной функции есть некоторые проблемы. Самое большое существо, что если он обнаружил, что mysql_real_escape_string() не существует, он возвращается к mysql_escape_string(). Вы никогда не должны возвращаться к mysql_escape_string(). Если mysql_real_escape_string() недоступен, и вы полагаетесь на него, чтобы избежать SQL Injection, ваше приложение должно остановиться. Другой проблемой является использование strip_tags(). Escape для SQL Injection и escaping/encoding для XSS - две разные вещи и не должны объединяться в один.

Я предлагаю использовать MySQLi подготовленные операторы или PDO параметризованные запросы вместо этой функции, чтобы избежать SQL Injection.

Чтобы избежать XSS, используйте htmlentities() всякий раз, когда печатается содержимое из базы данных (или прямого ввода пользователем), которое исходит от ввода пользователем.

2) Это плохая практика

$_SESSION[userid] // this should have single quotes, making it $_SESSION['userid'] 

3) PHP логика и HTML перемешаны друг с другом, не предпринимается никаких попыток, чтобы отделить их.

4) CAPTCHA на форме входа. Это просто сделает пользователей несчастливыми. Как правило, нет необходимости в CAPTCHA в форме входа.

Редактировать - здесь я ответил на некоторые ваши замечания в комментариях.

автора Намерение для маркера

Это гадать действительно, но, возможно, случайное число должно было быть использовано в ссылку для сброса пароля. Для такого рода вещей хеширование случайного числа/строки обычно выполняется, а не хранение короткого случайного числа.Также mt_rand() лучше, чем rand().

Использование одной функции для SQLI побега и профилактики XSS

Это плохая идея, потому что они две очень разные вещи. Escaping для SQLi выполняется для входа в базу данных, предотвращение XSS должно выполняться исходящим, если вы понимаете, что я имею в виду.

При хранении данных в базе данных обычно лучше всего хранить в необработанном виде, а не иметь strip_tags() или htmlentities(). Что делать, если в какой-то момент вы хотите, чтобы HTML был введен в базу данных по какой-либо причине?

Профилактика XSS должна выполняться по мере того, как данные поступают из базы данных и на страницу или где бы она ни шла. Что делать, если вы хотите выводить данные на другой носитель, отличный от HTML, например XML или веб-службу, и вы уже обработали его для HTML. . Одна функция как для XSS, так и для SQLi не делает код более чистым, он применяет процессы к данным, которые не должны применяться в это время.

Посмотрите на любые популярные структуры, такие как Zend или CMS, такие как WordPress, Joomla и т. Д. Ни один из них не использует одну функцию для SQLi и XSS.

смешивания PHP и HTML

Да, вы правы, это не будет влиять на безопасность, но это выглядит просто ужасно. Трудно читать, трудно поддерживать, трудно продлить и обновить, и определенно остается причиной, по которой я бы не рекомендовал ее.

Котировки в $_SESSION['userid']

Использование $_SESSION[userid] внутри запроса, чтобы решить проблему разрыва запроса из-за цитаты, показывает отсутствие знаний/опыта.

Вы можете использовать кавычки, вам просто нужно сцепить переменную в запросе, как

$sql = "SELECT * FROM table WHERE something = '" . $_SESSION['something'] . '"; 

Конечно вам нужно бежать за SQLI (желательно с использованием параметризацию запросов), если вы не уверены в содержании переменная.

CAPTCHA,

CAPTCHA, это здорово, когда используется в нужных местах. Форма входа, подобная этой, не является одной из них. Вы можете использовать CAPTCHA после неудачных попыток X (как Google), но не так, где это требуется все время. Есть другие способы борьбы с попытками входа в грубую силу, здесь несколько ответов на SO.

Еще один момент, о котором я не упоминал, - это хэширование пароля. Это использование SHA1 без соли, которая не очень сильна. Я бы использовал SHA256 или выше и использовал соль для паролей.