Перейти к контенту

Блог команды AlterVega

  • запись
    121
  • комментария
    4
  • просмотров
    106 496

Безопасность системы в целом


AlterVega

1 979 просмотров

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

При разработке продукта мы учитывали основные возможные направления атак: SQL/Code Injection, XSS, CSRF. Также мы постарались проработать политику безопасности и в самой системе.

Сначала о политике безопасности:

  • уникальная связка для авторизации в системе: email + пароль. Email, не публикуется системой, таким образом имеется два неизвестных ключа, в отличие от связки: login + пароль, где зачастую login отображается системой;
  • пароли в системе не короче 6 символов, при регистрации имеется подсказка о сложности вводимого пароля, позволяющая пользователю оценить надежность пароля;
  • изменение email и пароля должно подтверждаться вводом текущего пароля;
  • сессия пользователя привязывается к его IP и браузеру;
  • максимальное количество одновременных авторизаций ограничено 1 авторизацией;
  • AlterVega реализует ролевую систему прав, реализация выделена в отдельный компонент, который используется всеми остальными компонентами приложения для работы с правами пользователя;
  • принятые соглашения по работе с внешними данными для команды разработчиков продукта.

Последний пункт направлен на противодействие основным направлениям атак.

Защита от SQL/Code Injection

Работа с внешними данными через глобальные массивы запрещена. Вместо этого разработчик получает удобный объект для получения данных из запроса. Объект обладает рядом методов, позволяющих проверить (validate) и/или привести (filter) входные данные к нужному типу (число, строка, email, дата и т.п.). Внутри компонентов AlterVega работа с внешними данными ведется только через этот объект.

Вот так, например, выглядит код начала действия получения информации о профиле пользователя:

// в этом блоке проверяется, что сделан AJAX запрос
// при любом другом типе запроса, система его отклонит
if( !$this->_request->isAjaxRequest() )
{
throw new jE_Http_Exception(
   	jE::translate( 'user' )->{'Страница не найдена'}, 404 );
}
// в этой строчке получаются входные данные из запроса, отправленного методом POST
$ids = explode( '_', $this->_request->post->getString( 'ids', '' ));
// а здесь на эти данные накладывается фильтр (массив с целыми числами)
$ids = jE_Filter_Intarray::filter( $ids );
// обработанные данные отдаются в сервис, который строит необходимые запросы
// и возвращает данные для отображения
$statuses = $this->_user_service->getUsersStatus( $ids );

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

// создается объект формы, которая знает каким образом
// должна осуществлятся валидация данных, необходимых для
// создания сущности пользователя
$form = new User_Form_Register;
if( $this->_request->isPost() )
{
// объект формы заполняется данными
$form->fill( $this->_request->post );
// производится запуск всех валидаторов формы
// которые проверяют данные из HTML-формы
if( $form->isValid() )
{
   	try
   	{
       	// осуществляется попытка создания пользователя
       	// с использование уже проверенных данных
       	$user = $this->_user_service->create(
           	array (
               	'email' => $form->email->getValue(),
               	'name' => $form->name->getValue(),
               	'password' => $form->password->getValue(),
           	)
       	);
   	}
   	catch( Exception $e )
   	{
       	$form->addProcessingError( jE::translate( 'user' )
                           	->{'Не удалось создать пользователя'} );
   	}
}
}

Для составления SQL запросов используется встроенное, развиваемое расширение PHP - PDO. В нашей системе используется механизм подготовленных запросов с подстановкой переменных в запрос с указанием их типа.

Защита от XSS

При разработке шаблонов представления приложения нами были приняты следующие правила:

Правило 0: пользовательские данные можно вставлять только в разрешенных местах шаблона

Пользовательские данные можно вставлять только согласно правилам 1-3, запрещено

<script>...НЕЛЬЗЯ...</script> внутри описания скрипта

<!--...НЕЛЬЗЯ...-->  внутри комментария

<div ...НЕЛЬЗЯ...=value /> 	в имени аттрибута тега

<НЕЛЬЗЯ... href="/uri" />	в имени тега

<style>...НЕЛЬЗЯ...</style>	внутри описания CSS

Правило 1: делать HTML escape прежде чем вставлять пользовательские данные в тело HTML тега

Правило 2: делать JavaScript escape прежде чем вставлять пользовательские данные в значения переменных JavaScript

Правило 3: там где данные подразумевают наличие HTML, делать санитаризацию таких данных

Санитаризацию мы стараемся делать как на стороне клиента, так и на сервере. HTML Sanitaizer у нас рабоает по принципу белого списка, в нем разрешены только определенные теги, определенные аттрибуты у тегов и определенные значения этих аттрибутов. Все остальное считается некорректным вводом и удаляется.

Правило 4: использовать HTTPOnly флаг для cookie

Методики воздействия XSS совершенны до тех пор, пока не находится новый вектор атаки неизвестный до настоящего времени. Поэтому чтобы снизить ущерб от неизвестных XSS AlterVega использует защищенные cookie. Данные cookie не доступны из JavaScript и поэтому не могут быть перехвачены в результате XSS-атаки.

Защита от CSRF

Все "опасные" действия, изменяющие состояние пользовательского профиля, контента и т.п. мы осуществляем только методом POST с передачей уникального для каждого пользователя token'а, который проверяется на стороне сервера при выполнении "опасной" операции. По аналогичной методике сделана защита при авторизации через социальные сервисы, что предотвращает возможность подделки процесса авторизации одного пользователя другим.

Аудит

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

0 комментариев


Рекомендуемые комментарии

Комментариев для отображения не найдено.

×
×
  • Создать...

Важная информация

Находясь на нашем сайте, вы соглашаетесь на использование файлов cookie, а также с нашим положением о конфиденциальности Политика конфиденциальности и пользовательским соглашением Условия использования.