Тестирование безопасности сайта

Проверка сайта на безопасность должна осуществляться профессионалами. Для полноценной проверки необходимы глубокие знания в клиентском (JavaScript) и серверном (NodeJS, PHP, Python…) программировании, знания инструментов и опыт тестирования безопасности сайта. Игнорируя вопросы безопасности, владельцы рискуют репутацией, доверием пользователей и работоспособностью ресурса. Доверять инструментам «Сканерам», для проверки сайта на уязвимость плохая практика. В сети часто появляются в продаже взломанные базы данных

Тестирование — кропотливая работа, с которой роботы не справятся. Компания «Веб-Фокус» предлагает провести проверку вашего сайта на наличие «Дыр». Мы находим и исправляем все уязвимости, независимо от движка (CMS WordPress, Joomla…), сервера (NodeJs, Perl, Php…), фреймворков и версии сервера. Проверяем на все виды уязвимостей:

  • Инъекции (php, js, jsp, asp, sql, CRLF)
  • Поиск участков кода с конструкциями eval (), system (), passtru ()
  • XXE – внедрение внешних XML-скриптов
  • SSRF подделка запроса на сайте хакера
  • Настройки доступа к страницам администратора
  • Использование опасных файлов
  • Неправильные настройки корневого файла «Htaccess»
  • Shellshock
  • Небезопасная десериализация, аутентификация
  • Нарушение контроля доступа
  • Отсутствие шифрования
  • Тестирование безопасности сайта на прочие дыры, уязвимости и ошибки

Наиболее опасные угрозы

  1. SQL-инъекция. Информация хранится в базах данных. Общение с базой данных производится на языке запросов SQL. С помощью запросов, клиент (браузер, программа, мобильное приложение) отправляет данные на сервер, где происходит проверка полученных данных, запись в БД и ответ клиенту. В ответе так же может содержаться информация из БД, предварительно подготовленная сервером перед отправкой. При недостаточной проверке данных от пользователя, злоумышленник внедряет собственный произвольный SQL запрос и получает доступ к данным, которых у него быть не должно. Подменив запрос, хакер отправляет команды от имени администратора, обращается к базе для получения приватной информации о пользователях, редактирует поля, размещает рекламу и может скачать базу в полном объеме на свой компьютер.
  2. Недочеты системы аутентификации и хранения сессий. Cookies помогают отличить одного пользователя от другого. После ввода логина и пароля в приложении, для запоминания авторизованного пользователя используются куки. После авторизации куки сохраняются на компьютере. Посетитель гуляет по приложению, не вводя периодически логин и пароль. При обращении к защищенной странице, сервер запрашивает Cookie, сравнивает идентификатор файла в БД и полученный куки. Если все сходится, открывается сессия и гость превращается в авторизованного пользователя. Существует много способов подсмотреть, украсть куки и использовать при авторизации. После загрузки украденных куки, злоумышленник проходит авторизацию без пароля и логина, получает доступ к чужой учетной записи. Для защиты, на портале устанавливают проверку IP адреса, запрет на одновременную авторизацию с двух и более устройств, считывают FingerPrint (большие компании, с целью антифрода), Методы защиты зависят от компании и сайта. В чатах, социальных сетях, на форумах, даже попытка повторной авторизации с другого IP в другом городе, вызывает подозрение и инициируется процедура подтверждения номера или адреса электронной почты.
  3. XSS атака, html-инъекция – внедрение собственного кода в пользовательские страницы. Код выполняется в браузере посетителя и взаимодействует с сервером хакера, для увеличения уровня доступа. Вставляется на веб-страницу через уязвимости сервера или компьютера.

 

  1. Дырявые конфигурации приложения, сервера, базы данных. Если на сайте важные данные, желательно проверять не только куки, но и айпи адрес. Проверка IP адреса ведется не только на соответствие предыдущему, но и на надежность адреса. Сервисы выдают информацию о нахождении айпи в черных списках, спам-списках и проверяют использование на IP адресе Тор соединения или прокси. Многие специалисты забывают включить эту проверку в тесты безопасности сайтов.
  2. HTTP протокол соединения обеспечивает общение клиента (браузер, приложение, работающее онлайн) и сервера через GET и POST запросы. Трафик, передающийся через HTTP не шифруется. Хакеры научились перехватывать, просматривать и модифицировать трафик, идущий через HTTP протокол. При прохождении данных от компьютера пользователя до веб-сервера данные проходят через маршрутизатор офиса или квартиры, маршрутизатор провайдера, маршрутизатор на канале… На каждом из этих узлов может затаиться угроза. Одна из таких программ – sniffer, считывает трафик и передает злоумышленнику. Сайты, дорожащие своей репутацией, конфиденциальностью пользователей и безопасностью, переходят на HTTPS протокол. Шифрование данных на протоколе сводит на нет попытки перехвата трафика.
  3. Функции контроля доступа. Когда не авторизованный администратор пытается зайти на главную страницу админки, приложение перенаправляет на форму авторизации. Такие же настройки должны быть при попытке зайти на другую страницу админки. Иначе каждый желающий может получить доступ на страницу загрузки файлов, управлению виджетами, базами данных или страницу редактирования прав пользователя. Необходимо предотвращать неконтролируемый доступ, отправляя все запросы в админку на единую точку входа, для проверки авторизации. Не авторизованные перенаправляются на страницу авторизации, остальные, в зависимости от прав доступа, в личный кабинет.
  4. CSRF атака, подделка запроса. Пользователь после авторизации зашел в личный кабинет, проверил средства и по неосторожности перешел на сайт злоумышленника. Он остается авторизованным на предыдущей страничке, потому что сессия живет 20-30 минут после закрытия страницы. Злоумышленник от лица жертвы, отправляя запрос на страничку, откуда был совершен переход, управляет средствами, аккаунтом или меняет пароль. Система, после проверки куки считает, что форму отправляет клиент. Для защиты опытные разработчики устанавливают генерирование «Секретного Ключа» при авторизации случайным образом. На основе ключа генерируется токен и добавляется как скрытое поле в форму. Перед отправкой формы сервер проверяет соответствие токена и ключа, если совпадают, запрос обрабатывается. Токен еще называют подписью формы. Чужие сайты не могут копировать токены, вычислять и подменять запросы. При AJAX запросах токен дополнительно записывается в куку.

Проверка сайта на безопасность, выполненная опытными специалистами компании «Веб-Фокус» обеспечит беспрерывную работу приложения, бесперебойное, безопасное общение клиента и сервера.