Безопасность приложения

Безопасность приложения

Для обеспечения элементарной безопасности приложения, как минимум, делаем следующее:

1. Используем шифрование для хранения важных данных.
2. Используем безопасную передачу данных между страницами приложения.
3. Проверяем данные пользователя при открытии любой страницы приложения.
4. Прививаем иммунитет к SQL-инъекциям.
5. В Интернете не даем прямых ссылок на страницы программы. Исключаем индексирование страниц поисковыми машинами.
6. Контролируем все виды доступа к страницам приложения.
7. Не даем пользователям лишних прав.
8. Протоколируем действия пользователя.

Шифрование важных данных
Не рекомендуется хранить важные данные, например, пароли пользователей, в открытом виде. В PHP самый простой вариант шифрования - использование функции md5. После ввода пароля вычисляем md5-хеш строки и записываем в таблицу пользователей. При аутентификации пользователя хешируем введенный пароль по md5 и сравниваем со значением, хранящимся в таблице пользователей.

Безопасная передача данных в приложении
Для передачи любых данных между страницами приложения не используем небезопасный метод GET, а также cookie. Передачу данных осуществляем через глобальные массивы, например, $_SESSION. После успешной авторизации пользователя открываем сессию и пользуемся массивом $_SESSION для передачи данных между страницами приложения. По окончании работы пользователя закрываем сессию, тем самым уничтожая все данные глобального массива $_SESSION.

Повторная проверка пользователя
Проводим проверку авторизации пользователя не только на странице ввода имени и пароля, но и при открытии любой важной страницы приложения. Для этого имя и пароль авторизовавшегося пользователя храним в глобальном массиве $_SESSION и при открытии каждой новой страницы проверяем наличие этого пользователя в базе. Это дает возможность исключить доступ к страницам по прямой ссылке вне открытой сессии.

Защита от SQL-инъекций
Под SQL-инъекцией понимают модификацию вводимых пользователем данных с целью получения несанкционированного доступа к информации или выполнения деструктивных действий по модификации/уничтожению данных. Инъекции через GET и cookie не рассматриваем, так как использовать эти методы не будем. Возможность проведения инъекции во многом зависит от типа SQL-сервера и языка программирования. Рассмотрим подробнее основные типы SQL-инъекций и их опасность на примере PHP + MySQL.

1. Внедрение в параметры запроса. Эта инъекция основана на внедрении в текст запроса непредусмотренного выражения. Например, пользователь вводит в окно ввода свое имя и дополняет его SQL-выражением. Запрос, сформированный в программе, модифицируется:

select <текстовое поле> from <имя таблицы>
where <условие>
/*текст инъекции*/
or 1=1

В данном примере инъекция нивелирует условие where, позволяя получить из указанной таблицы все данные без ограничений. Возможность такой инъекции зависит от типа данных. Если вводится строковое данное, то злоумышленнику приходится ставить закрывающую кавычку. Если программа написана на PHP, то с большой вероятностью в настройках php.ini на WEB-сервере окажутся включенными директивы magic_quotes_gpc и magic_quotes_runtime (магические кавычки), которые автоматически добавляют символ обратного слэша к кавычке, пришедшей с данными пользователя. В результате текст инъекции отсекается, а сам запрос становится синтаксически ошибочным. Если вводится числовое значение (например, при каком-либо поиске по коду), то инъекция проходит.

2. Экранирование хвоста запроса. Инъекция основана на внедрении во вводимые значения знака комментария и, как следствие, к отсечению части запроса:

update <имя таблицы> set <имя поля>=<значение поля>
/*текст инъекции*/
--
/*отсеченная часть запроса*/
where id=<id записи>

В данном примере инъекция используется для проведения деструктивных действий - вместо одной записи в таблице будут модифицированы все, что, конечно, не есть хорошо.

3. Расщепление SQL-запроса. Данной инъекции подвержены SQL-серверы, поддерживающие выполнение нескольких команд SQL в одном запросе (например, MS SQL Server). Инъекция является крайне опасной, но MySQL ей не подвержена.

4. Использование оператора UNION. С помощью такой инъекции могут быть получены данные, не предусмотренные в данном запросе:

select <текстовое поле> from <имя таблицы>
where <условие>
/*текст инъекции*/
union select version()
union select user()
union select database()

Например, с помощью данного запроса после подбора количества выводимых полей может быть получена версия MySQL, имя пользователя и хоста, а также имя базы данных.

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

Индексирование страниц поисковыми машинами
Для корпоративного приложения индексирование страниц для поисковых машин не только бесполезно, но и небезопасно. Совсем необязательно, чтобы о существовании закрытого WEB-ресурса знали посторонние. Поэтому нужно закрыть страницы приложения от посещения поисковыми системами, используя настройки файла robots.txt. Этот текстовый файл располагается в корневой директории WEB-сервера и содержит инструкции для роботов поисковых машин, позволяя закрыть для индексирования часть сайта или весь сайт целиком. В простейшем случае можно запретить доступ ко всем страницам приложения всеми поисковыми машинами:

User-agent: *
Disallow: /

Подробнее - в полезных ссылках.

Контроль доступа к WEB-серверу
Должны быть закрыты или ограничены другие виды доступа к папкам и файлам сервера, например, по FTP. Скорее всего, FTP будет использоваться для закачки содержимого на сервер, но такой вид доступа должен быть строго ограничен.

Ограничение прав пользователей
Даем пользователям только те права, которые необходимы для работы. На SQL-сервере у пользователя должен быть доступ только к той базе данных, с которой работает приложение, и только для проведения необходимых операций - как правило, вставка, чтение и запись/редактирование данных. В программе пользователь должен работать только со своими данными или с данными, доступ к которым будет явно разрешен администратором или другими пользователями.

Ведение протокола действий пользователей
Фиксируем подозрительные действия пользователя в логах с возможностью дальнейшего анализа и выявления проблем с безопасностью.

Полезные ссылки:
http://www.phpfaq.ru/sessions (сессии в PHP)
http://www.stichka.by.ru/d4php/D4PHP_Session.html (сессии в Delphi for PHP)
http://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%8A%D0%B5%D0%BA%D1%86%D0%B8%D1%8F_SQL (SQL-инъекция)
http://www.seo.su/articles.php?id=89 (использование robots.txt)

Содержание