Php безопасность баз данных
Вы можете установить соединения через SSL для шифрования связи клиент/сервер для повышения безопасности, или вы можете использовать ssh для шифрования сетевого соединения между клиентами и сервером базы данных. Если любой из них используется, то мониторинг вашего трафика и получение информации о вашей базы данных будет трудным для потенциального злоумышленника.
В случае, если взломщик получил непосредственный доступ к БД (в обход веб-сервера), он может извлечь интересующие данные или нарушить их целостность, если информация не защищена на уровне самой БД. Шифрование данных — хороший способ предотвратить такую ситуацию, но лишь незначительное количество БД предоставляют такую возможность.
Наиболее простое решение этой проблемы — установить вначале обыкновенный программный пакет для шифрования данных, а затем использовать его в ваших PHP -скриптах. PHP может вам помочь с этой задачей с помощью таких модулей как OpenSSL и Sodium, реализующих довольно большое число алгоритмов шифрования. При таком подходе скрипт вначале шифрует сохраняемые данные, а затем дешифрует их при запросе. Ниже приведены примеры того, как работает шифрование данных в PHP-скриптах.
Хеширование
В случае работы со скрытыми служебными данными, если не требуется их нешифрованное представление (т.е. его не нужно показывать), то, как следствие, можно использовать хеширование. Хорошо известный пример хеширования — хранение криптографического хеша от пароля в БД, вместо хранения оригинального значения.
Функция password позволяет удобно хешировать конфиденциальные данные и работать с этими хешами.
password_hash() позволяет хешировать заданную строку самым сильным из доступных алгоритмом и password_verify() проверяет, что заданный пароль совпадает с сохранённым в БД хешем.
Пример #1 Хеширование полей с паролями
// Сохраняем хеш пароля
$query = sprintf ( «INSERT INTO users(name,pwd) VALUES(‘%s’,’%s’);» ,
pg_escape_string ( $username ),
password_hash ( $password , PASSWORD_DEFAULT ));
$result = pg_query ( $connection , $query );
// проверка введённого пользователем пароля на корректность
$query = sprintf ( «SELECT pwd FROM users WHERE name=’%s’;» ,
pg_escape_string ( $username ));
$row = pg_fetch_assoc ( pg_query ( $connection , $query ));
Безопасность баз данных
На сегодняшний день базы данных являются ключевыми компонентами большинства веб-приложений, позволяя предоставлять на сайтах динамический контент. Поскольку в таких БД может храниться очень деликатная или конфиденциальная информация, необходимо очень серьёзно относиться к защите базы данных.
Для извлечения или сохранения любых данных вам необходимо открыть соединение с базой данных, отправить корректный запрос, извлечь результат и закрыть соединение. В настоящее время наиболее распространённым стандартом общения является язык структурированных запросов (SQL). Всегда следует помнить о возможности атаки посредством SQL-запроса.
Очевидно, что сам по себе PHP не может защитить вашу базу данных. В этом разделе документации описаны самые основы безопасного доступа и управления данными баз данных в PHP -скриптах.
Запомните простое правило: максимальная защита. Чем больше потенциально опасных участков системы вы проработаете, тем сложнее будет потенциальному взломщику получить доступ к базе данных или повредить её. Хорошее проектирование базы данных и программных приложений поможет вам справиться с вашими страхами.
User Contributed Notes 4 notes
About offloading business logic to views and queries facilitated by the database engine, I seek to avoid this as much as possible, and only do so when such would drastically improve efficiency and user response time.
For instance, where I am there is database staff and application staff. Trying to do analysis on existent applications can easily become a snipe hunt.
The database should be kept discreet as much as possible from the application, such that any database or database provider can easily be substituted with a minimum of cognitive effort on the part of the one setting up a new database. If functionality has been offloaded to the database, additional testing is required to make sure triggers and views were done correctly, again, and that they work right.
Also, keeping all business logic with the application allows all functionality and documentation to be readable in one place, which is invaluable when doing subsequent analysis on an existing application. The worst thing is to have functionality scattered here and there.
Keeping everything with the application means one group of people is responsible, as in my case, application staff. Fewer requests go back and forth. Remember, anytime someone else is brought into the picture, such as asking a DBA to create a view or trigger for you, that DBA must take responsibility over his or her work, with whatever requirements, causing more bureaucracy and administrative complexity.
Regarding where to put logic, it’s really best not to be dogmatic about this. Putting logic in the db can have some security advantages but it has other security gotchas (for example, SQL injection inside a stored procedure may be possible in some environments). Similarly it can have some portability advantages and disadvantages.
The real question is that you want to ask what you want to be portable. If you put it in the db, it becomes easier to integrate programs written in different development environments with a minimum of security gotchas. If you put it in the application, then you have to create the interfaces on that level in middleware. Both approaches are doable. On the other hand if you are writing software you want to be deployable in MS SQL shops and Oracle shops, then you have to write portable SQL (avoiding gotchas) and put the logic in the application.
When we started rewriting the LedgerSMB codebase, we decided to move logic into the db because this would make it easier to retrofit security onto a very insecure codebase (by not trusting the application), and because we wanted to support languages other than Perl. A few years later this is bearing fruit and indeed I am reading the manual because I am writing integration libraries in PHP. I am not much of a PHP guy (I haven’t programmed PHP since PHP 4.x) but I can write modules that let folks write code to interface securely with LedgerSMB’s database logic. You can think of the stored procedures as being named queries which are shared between applications, or as API’s to the database. But again, this approach is not universally applicable.
If portability between db’s is not a major requirement, then I think the best approach is to do as much as possible in SQL queries and put those in the database. A couple hundred lines of SQL can replace a couple thousand lines in Perl or PHP, and is fundamentally easier to debug. Of course that won’t work for everyone.
The posting below is at the very best extremely POV.
There is no more reason to assume you would want to change database vendor than there is to assume you might want to port your php code to Java for example. In either case, its going to be a matter of luck where your business rules sit.
Even if your business rules sit in your application, SQL is NOT portable. Oracle outer joins and pivot queries for example, can look completely different to those in other vendors software (particularly from 8i or lower). This fact alone means that changing your DB vendor requires work on your business rules either in the database or in the application.
Having your rules in the database and keeping the sql in application simple, will at least keep the work in the database if you need to change DB vendor. If you have the rules in the PHP, you’ll have to change both.
- Безопасность
- Вступление
- Общие рассуждения
- Если PHP установлен как CGI
- Если PHP установлен как модуль Apache
- Безопасность сессий
- Безопасность файловой системы
- Безопасность баз данных
- Сообщения об ошибках
- Данные, введённые пользователем
- Сокрытие PHP
- Необходимость обновлений
Основы безопасности при работе с MySQL в PHP
Эту статью мне очень хотелось бы адресовать в основном начинающим программистам, т.к. большинство из них еще не сталкивались со взломом их сайтов, построенных на основе MySQL. И поэтому не представляют, какую опасность хранит в себе неправильное использование необработанных MySQL запросов.
Начнем с теории, и выясним, что такое взлом сайта. В моем понимании взлом это получение полного, или частичного доступа к управлению сайта. Допустим, вы являетесь администратором корпоративного сайта, и у вас стоит какой-либо популярный бесплатный движок, работающий на MySQL. В принципе ничего предосудительного в этом нет, но если задуматься, что любой человек может знать точную структуру таблиц, sql запросов и прочей ценной информации, то без можно представить такую картину: Ваши конкуренты или просто недовольный клиент решил вам отомстить, разрушив ваш сайт или нарушив его работу, просто ищут “слабые места” в php скриптах и sql запросах и делают свое дело. Под слабыми местами я понимаю sql запросы выполненные без какой-либо проверки на верность введенных данных. В качестве примера можно привести примерно следующий кусочек скрипта:
$next = argv[0]; // видите, никакой проверки ввода! $query = 'SELECT * FROM `table_name` LIMIT 0, $next;"; $result = mysql_query($query);
Как видно из примера, в этот скрипт без особых проблем может быть вставлена SQL инъекция, обычная urlencode()’ированная строка, в начале которой стоит знак прерывания текущего запроса и начала нового “0;”.
К примеру, если скрипт запущен от имени root, то это можно сказать погибель для всего вашего сайта, т.к. без проблем можно сменить пароль на коннект к серверу MySQL и ваш сайт станет недоступным, в том числе и вам:
0; UPDATE user SET Password=PASSWORD('New_password') WHERE user='root'; FLUSH PRIVILEGES;Если же скрипт имеет только права на удаление или запись в базу, то можно сделать примерно следующее:
0; DELETE FROM `registred_user`
Как вы видите, sql инъекция очень страшная вещь, если ей умело пользоваться. Что же делать!, возразите вы мне, а ответ очень прост:
Во-первых: создать несколько пользователей с разными правами, например: один, для записи в базу данных, другой, для чтения из базы, третий для создания новых таблиц и удаления, четвертый для создания новых пользователей, и самое главное, никогда и нигде не открывать соединение с базой от имени пользователя root.
Во-вторых: обязательно нужно проверять вводимые данные на корректность ввода. К примеру, проверять тип вводимых переменных с помощью функции is_numeric или is_string или им подобными функциями. Ну, или самостоятельно изменять тип переменных на нужный с помощью функции settype, например settype($next, «integer»); и теперь в $next содержится переменная типа integer.
В-третьих: Весь передаваемый в запрос текст нужно закавычивать с помощью addslashes и addcslashes, что бы избежать присоединения к тексту sql инъекции.
В-четвертых: Не выводите никаких ошибок о работе скрипта, во всяком случае, уже полностью рабочего и отлаженного, вставив функцию error_reporting(0); в начало скрипта.
В-пятых: Можно просто обрезать передаваемые значения до нужной длинны, и при этом проверять тип вводимых данных. Или можно создать собственную процедуру для проверки всех значений переменных используемых для обращения к базе данных, на содержание опасных данных в них.
Как вы могли видеть из выше написанного, что если хакер нашел уязвимость в безопасности скрипта, то ему будет очень просто атаковать ваш сайт или форум. Поэтому в Интернете постоянно появляются вирусы атакующие сайты или форумы работающие на движках в которых нашли уязвимости. И поэтому я являюсь сторонником самодельных скриптов и движков, т.к. хакер может найти уязвимости в таких скриптах, только методом научного тыка, потому что у него нет исходного текста php скрипта. И посему мой вам совет, не ленитесь, пишите скрипты сами, или хотя бы частично изменяйте или проверяйте уже готовые скрипты сторонних производителей. Т.к. зачастую сами производители умышленно делают в скриптах уязвимости (особенно это касается выполнения сайтов “на заказ” или “под ключ”).