PHP и MySQL $ _POST Security и хэш-функция md5 () - PullRequest
0 голосов
/ 31 января 2012

Я создаю информационную систему, которая будет обрабатывать финансовую информацию, контакты и т. Д. Я разрабатываю сайт с нуля, используя объектно-ориентированное программирование (классы, функции и т. Д.).Большая часть данных будет из базы данных MySQL.Пользователи смогут получать и отправлять данные в базу данных.

Я уже использую хэш-функцию для шифрования данных, таких как пароли, серийные ключи.Я также использую функцию preg_replace () для всех других данных, поступающих в базу данных.

Какие другие меры безопасности мне необходимо предпринять, чтобы гарантировать, что отправка и получение данных из базы данных не ставит под угрозу безопасность?

Ответы [ 7 ]

3 голосов
/ 31 января 2012

md5 - это криптографическая хеш-функция .после хеширования он не может быть «хеширован» обратно к исходному значению (одностороннему), в отличие от шифрования , который является двусторонним (шифрование-дешифрование).

для безопасностисвоих данных рассмотрите следующие сценарии и способы предотвращения, а не просто шифрование:

  • подделка межсайтовых запросов (CRSF) - не используйте токены форм

  • SSL-соединение ("httpS://") для предотвращения перехвата данных при транспортировке

  • хеш-соление додополнительно защитить (но не полностью) хешированные пароли от атак по словарю. В этом случае целью являются слабые и общие пароли.

  • хеширование не является абсолютным. Существует ограничение на количество комбинацийбуквы и цифры в хеше. В какой-то момент очень разные строки могут иметь одинаковое значение хеша. Это известно как столкновение

  • хеши склонны к грубомусиловые / словарные атаки. хотя хэши - это один из способовМы можем создать словарь хеш-строк, сопоставить хэш и выяснить строку за ним.

  • межсайтовый скриптинг (XSS), который может включать (ноне ограничиваясь этим) кража файлов cookie, взлом кликов и т. д.

  • SQL-инъекция - способы обмануть SQL, когда формы не очищены

  • расходуемые идентификаторы сессий для отслеживания пользовательских сессий - срок действия которых должен истечь через определенный промежуток времени, отсюда и механизм автоматического выхода из системы.

  • идентифицирует вашпользователь!IP-адрес пользователя, обнаружение браузера и т. д. для профилирования вашего пользователя.любые нечетные данные (например, внезапное изменение IP, местоположения и т. д.) должны рассматриваться в пределах определенного порога.(Facebook имеет эту функцию. Однажды я зашел на свой Facebook с помощью прокси-сервера - автоматическая блокировка)

2 голосов
/ 31 января 2012

preg_replace() не сильно повлияет на безопасность.Вы должны ознакомиться с некоторыми базовыми средствами безопасности / крипто, прежде чем выполнять эту работу.Кроме того, рассмотрите возможность использования стандартной криптографической библиотеки для шифрования / дешифрования данных вместо произвольного использования функций хеширования или регулярных выражений.

Взгляните на это: http://php.net/manual/en/book.openssl.php

1 голос
/ 31 января 2012

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

OWASP - хороший ресурс для понимания проблем веб-безопасности.

Другим хорошим ресурсом является отчет SANS Основные риски кибербезопасности .

В частности, Межсайтовый скриптинг (XSS) и SQL-инъекция - это две верхние угрозы безопасности для большинства веб-сайтов.Вы должны прочитать о том, как разработать свой код, чтобы минимизировать эти риски.

Я также разработал презентацию Мифы и ошибки SQL-инъекций , в которой более подробно рассматривается природа этой проблемы и методы защиты..

Чтение блога Возможно, вы неправильно храните пароли от основателя StackOverflow Джеффа Этвуда.

В своей книге SQL я также рассмотрел внедрение SQL и хеширование паролей *1025* SQLАнтипаттерны: предотвращение ловушек программирования баз данных .

1 голос
/ 31 января 2012

Надеюсь, у вас есть хорошая страховка ответственности, если вы используете md5 для защиты финансовой информации. Читайте о md5, http://en.wikipedia.org/wiki/MD5,, уделяя пристальное внимание линии

Безопасность хеш-функции MD5 серьезно нарушена.

0 голосов
/ 12 мая 2018

Я опытный разработчик PHP и хочу предложить вам взглянуть на этот проект OWASP_Development_Guide . Каждый веб-разработчик должен использовать это как библию. Это было очень полезно для меня, и я надеюсь, что это будет то же самое для вас.

Вот краткое описание документа:

Руководство по разработке предоставляет практическое руководство и включает примеры кода J2EE, ASP.NET и PHP. Руководство по разработке охватывает широкий спектр вопросов безопасности на уровне приложений, от внедрения SQL-кода до современных проблем, таких как фишинг, обработка кредитных карт, фиксация сеансов, подделка межсайтовых запросов, соответствие требованиям и вопросы конфиденциальности.

0 голосов
/ 01 февраля 2012

Как уже отмечали другие, md5 не работает.Кроме того, хэш SHA1 очень быстро вычисляется, что фактически делает его хуже как алгоритм хэширования.Вместо этого посмотрите на bcrypt.Предполагая, что вы используете PHP, http://www.openwall.com/phpass/ - очень хороший пароль для использования, который прозрачно обрабатывает хеширование и засолку.

Использование preg_replace () для экранирования данных в базу данных - очень плохая идея .Почти все базы данных имеют свои собственные функции очистки, PHP / MySQL не является исключением с mysql_real_escape_string ().

Некоторые дополнительные пункты (обратите внимание, что ни один из них не выделен):

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

Выход из всего вывода Предположим, что все, что вы отображаете на своем сайте, предназначено для причинения вреда. XSS и CSRF являются одними из наиболее распространенных методов атаки на веб-сайты.Сбросьте весь текст, который вы выводите в браузер.Рассмотрите возможность использования одноразовых номеров для смягчения атак.

Используйте TLS / SSL Если вы хотите защитить входящие данные ваших пользователей, получите себе подписанный сертификат SSL и настройте его.Это позволяет посетителям безопасно переходить на https://yoursite.com (или, по крайней мере, более безопасно, если они относятся к тому типу людей, которые занимаются интернет-банкингом в кафе wifi).

Использование каркаса Каждый начинает с написания своей собственной структуры, потому что он знает, как сделать это правильно, или ему не нужна дополнительная сложность или любая другая причина, по которой он придумывает.Если вы не пишете суперспецифическое нишевое приложение, для которого PHP в любом случае, вероятно, не является правильным ответом, использует каркас .Я предпочитаю http://kohanaframework.org/,, но есть целый диапазон от http://codeigniter.com/ до http://framework.zend.com/. Каркасы обрабатывают шифрование сеанса, экранирование базы данных, очистку ввода и многое другое для вас, и потому что онииспользуется многими людьми, вероятность ошибки намного меньше, чем код, над которым работал только один человек.

Защита вашей инфраструктуры Эта ошибка имеет тенденцию летать большинством людей, но убедитесь, что выПотратьте некоторое время на просмотр серверов, на которых вы работаете.Вы на общей учетной записи?Вы не хотите хранить финансовую информацию о них (в некоторых странах это даже незаконно).Примените исправления безопасности для вашей ОС / программного обеспечения, убедитесь, что вы не оставили старый скрипт загрузки, проверьте права доступа к файлам, используйте SSH с ключами и отключите пароли для входа.Злоумышленники всегда ищут самый легкий путь.

В конце дня, единственный способ оставаться в безопасности - это спать с одним открытым глазом, полностью параноидально.Следите за своими журналами, устанавливайте Nagios и настраивайте некоторые оповещения, нанимайте профессионала для проведения аудита безопасности.Нет такой вещи, как 100% безопасность, но зная, что это полдела.

0 голосов
/ 31 января 2012

Вы делаете это неправильно, потому что:

  • md5 считается нарушенным,
  • preg_replace () не даст вам много.

Рассмотримиспользование уже разработанных, протестированных и безопасных сред (кандидаты включают Zend Framework, Symphony, Kohana, Yii) для вашей системы.Вам предстоит пройти долгий путь, прежде чем вы достигнете безопасности, по крайней мере, почти такого же уровня, что и стандартные фреймворки.Также рассмотрите возможность использования подготовленных операторов вместо preg_replace () и соленого sha1 вместо простого md5, если вы все еще хотите заново изобрести колесо.

Более того:

  • защитите свое приложение от таких сокращенийпоскольку XSS, CSRF,
  • всегда требуют SSL (для каждого запроса, даже для изображений / стилей / сценариев),
  • для чтения бюллетеней по безопасности (они понадобятся вам, если вы хотите создать защищенныйсистема финансовой деятельности).
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...