Когда пользователь регистрируется, я mysql_real_escape_string пароль с помощью mysql_real_escape_string как следует
$password = clean($_POST['password']);
Перед добавлением в базу данных я использую:
$hashedpassword = sha1('abcdef'.$password);
и сохранить его в mySQL.
Мой вопрос в том, должен ли я его очистить, или я защищен тем, что пароль хэширован, прежде чем добавлять его в БД?
Ну, есть одно серьезное недоразумение.
mysql_real_escape_string () ничего не очищает . Это вообще не имеет никакого отношения к безопасности.
Эта функция используется только для устранения разделителей и не более того. Это может помочь вам поместить строковые данные в SQL-запрос – вот и все.
Итак, каждая строка, которую вы собираетесь вводить в запрос (помещая ее в кавычки), вы должны подготовить ее с помощью этой функции. Во всех остальных случаях это было бы бесполезно или даже вредно.
Таким образом,
Из этого недоразумения вы делаете здесь две основные ошибки:
Кроме того, в качестве примечания, пожалуйста, имейте в виду, что эта функция всегда должна использоваться в сочетании с mysql_set_charset, или иначе часть "_real_" этой функции становится бесполезной
Если вы применяете на нем функцию clean() (которую я предполагаю, это ужасная смесь stripslashes / htmlentities / addslashes), то хеш, который вы создаете с помощью sha1() может быть не хешем для фактического пароля.
Это будет работать случайно, даже если пароль содержит специальные характеристики. Но только до тех пор, пока вы всегда выполняете ту же самую процедуру. И на самом деле вам следует правильно избежать хэш $sha1 (даже если он не нужен). И на самом деле, вы должны использовать схему, которая включает в себя лучшую соль (для каждого пользователя).
Но чтобы ответить на ваш вопрос: это работает в вашем случае; и не проблема. Это просто неправильно.
Да. Всегда. Или, еще лучше использовать заполнители (которые доступны как в PDO, так и в mysqli ), см. Лучший способ остановить SQL-инъекцию в PHP .
Причина всегда использовать некоторую форму экранирования (даже устаревшая и громоздкая mysql_real_escape_string ) должна быть последовательной. Сохранение нескольких циклов, потому что «здесь не нужно» (и здесь «здесь не нужно», потому что sha1 возвращает строку шестнадцатеричных символов) не имеет значения, если он – из-за отсутствия согласованности – приводит к ошибкам и / или компромиссов позже.
Ошибки / компромиссы могут возникать из-за отсутствия согласованности и забывания «ускользнуть» от другого поля позже, или это может быть связано с небольшим диапазоном кода, где новые требования к «побегу» были упущены. (Представьте себе, если будущая версия сохраняет двоичную или базовую 64 SHA1-подпись.) Оба этих тривиальных вектора могут быть устранены с помощью лучших практик.
Счастливое кодирование.
Пользователь вводит данные . База данных хранит данные . Точка «ускользания» данных (или, еще лучше, использование заполнителей / параметризованных запросов ) заключается в том, чтобы данные вносили данные в базу данных правильно и безопасно. Если данные нужно обрабатывать специально, то обрабатывайте их на уровне данных – фактическая работа с SQL должна быть простой, последовательной и надежной. (Обратите внимание, что mysql_real_escape_string не изменяет данные, видимые в базе данных , а гарантирует, что данные являются реальными данными, – которые были переданы функции mysql_real_escape_string – после того, как база данных анализирует команду SQL.)
Это довольно печально, но все, что нужно «убежать», все еще существует из-за неправильной конкатенации данных в строки SQL. Эта «проблема» решена на протяжении многих-многих лет с использованием заполнителей, что позволяет изолировать SQL-команду и данные . Подготовленные заявления также могут быть более эффективными, в зависимости от других факторов. И, честно говоря, я не вижу, как люди могут стоять, чтобы посмотреть / написать беспорядок, созданный с помощью строковых манипуляций (даже без всего добавленного «экранирующего» кода) команд SQL в целом.
В этом конкретном случае, если вы используете только хешированную форму строки в своем запросе, вы можете быть в безопасности от SQL-инъекции. SHA1 не выводит никаких метасимволов SQL, которые могли бы сломать вашу строку, поэтому это:
$pw = sha1($password); $sql = "INSERT INTO .... VALUES ('$pw')";
будет «безопасным».
Однако хорошей практикой является привычка ВСЕГДА избегать всего, даже если это не требуется строго. Лучше пойти немного за борт с ним, когда это не нужно, или забыть об этом в одном крошечном пятне, а ваш сайт забрасывается.
Действительно, в этом случае вам здесь не нужно mysql_real_escape_string , потому что sha1 возвращает только строку символов a-f0-9 , которая не должна быть экранирована.
Но это плохая идея пропустить это здесь.
Почему, если вы измените sha1 на другую функцию, это может вызвать ошибку. Просто вы mysql_real_escape_string добавить mysql_real_escape_string . Кроме того, более семантично (я даже не говорю о безопасности) использовать функцию escaping для всех ваших действий: сохранение в db, печать HTML / XML, выполнение команд оболочки.
Кроме того, поскольку pst говорит, что его отличная идея использовать заполнители
Нет НИКАКОЙ необходимости использовать что-либо еще, кроме хэширования, после чего нет никаких шансов, что что-то введет вашу вставку, и XSS будет еще более невозможным. (обратите внимание на «более невозможную» часть)
Однако … Я предлагаю вам обрезать () пароль перед его хэшированием, поэтому вы обязательно убедитесь, что пользователь что-то ввел. Кроме того, проверьте урезанный пароль с помощью strlen () перед «хешированием»,
Этот код достаточно для паролей … Где $ pass – опубликованный пароль.
$pass = trim($pass); if (strlen($pass) > 5) // it has to be bigger than 5 chars long. { $pass = sha1($pass); // or use crypt() as some have suggested. // pass is ready to be inserted. } else { // pass is not correct and you should handle this as you want~ }
Приветствую.