Популярные уязвимости сайтов: чем опасны и как их избежать24.09.2020 14:47

Критические угрозы и уязвимости сайта могут сильно ударить как по репутации, так и по экономике бизнеса. В этом материале мы выделим пять популярных типов уязвимостей, с которыми может столкнуться любой веб-сайт, и поделимся способами, которые сами применяем в REG.RU для поиска «дыр» в безопасности, проверки сайта на уязвимости и защиты от атак.

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

IDOR: простая и очень опасная уязвимость

IDOR (Insecure Direct Object Reference, небезопасные прямые ссылки на объекты) — уязвимость, которая позволяет получить несанкционированный доступ к веб-страницам или файлам. Самый распространенный случай IDOR — когда злоумышленник перебирает предсказуемый идентификатор и получает доступ к чужим данным.

Лучше рассмотреть на примере. Допустим, вы зарегистрировались на сайте крупного интернет-магазина. Заполняя свои контактные данные, вы видите в строке браузера похожую ссылку:

onlinestore.ru/user/details/edit? id=39082330

Здесь главную роль играет ваш личный идентификатор (id=39082330). Эксперимента ради вы решили заменить последнюю цифру, и вдруг — попали на страницу с чужими контактными данными, которые можете редактировать.

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

К чему может привести

• Разглашение конфиденциальной информации. Получив доступ к аккаунтам пользователей, злоумышленники увидят их личные данные.

• Обход аутентификации: можно получить доступ сразу к сотням или тысячам учётных записей с этой уязвимостью.

• Изменение данных: редактируя вашу контактную информацию, злоумышленник может использовать её в своих целях. Например, направить все ваши заказы в интернет-магазине к себе домой.

• Захват учётной записи. В некоторых случаях таким способом можно увести аккаунты пользователей, похитить деньги с их баланса и наделать много других неприятностей.

Как защититься

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

• Проверять, есть ли права на указанную страницу или действие;

• Проверять принадлежность аккаунта или услуги авторизованному пользователю;

• Использовать идентификаторы, которые невозможно предугадать или перебрать;

• Использовать подпись идентификатора.

XSS: плохой сценарий

XSS — Cross Site Scripting (межсайтовое выполнение сценариев). Строго говоря, XSS — не уязвимость, а атака. Но условимся, что под XSS мы понимаем уязвимости, позволяющие проводить атаку XSS.

Когда происходит XSS-атака, в веб-страницу встраивается вредоносный код. И как только посетитель сайта откроет эту страницу, начнёт выполняться какой-либо неприятный сценарий. Чаще всего под вредоносным кодом подразумевается внедрение html-тегов или скриптов на JavaScript.

XSS бывают нескольких разновидностей:

1. Хранимые (stored). Код, который позволяет проводить атаку, постоянно находится на сервере и выполняется автоматически.

2. Отражённые (reflected). В этом случае вредоносного кода нет на самом сайте, но он содержится в заранее созданной злоумышленником веб-ссылке. Обрабатывая этот «плохой» кусок кода, сайт может ненамеренно запустить в браузере пользователя скрипт, который перехватит данные или выполнит другую «полезную нагрузку», если имеется ввиду сама нагрузка XSS.

3. DOM-based. Вариант отражённых, когда вредоносный код не отправляется на сервер, а выполняется сразу в браузере.

К чему может привести

• Перехват сессии пользователя (файлы cookies).

• Подмена страницы (например, формы ввода логина/пароля), чтобы похитить конфиденциальные данные.

• Внедрение скриптов на сайты с высокой посещаемостью (с целью рекламы, накрутки просмотров, DDoS-атак и прочего).

• Внедрение вредоносных программ на внешне безопасных сайтах.

Как защититься

• Выполняйте кодирование данных, вводимых пользователем, при выводе их на страницу.

• Если какие-то данные нельзя закодировать, защитите их дополнительной валидацией.

• Обеспечьте безопасную обработку данных, причём не только на стороне сервера, но и на стороне клиента.

SQL-инъекции

SQL-инъекция — это атака, направленная на сайт или веб-приложение, в ходе которой пользователь может обходным путём получить информацию из базы данных с помощью SQL-запросов. В случае успешной атаки пользовательские данные интерпретируются как часть SQL-кода запроса, и таким образом изменяется его логика. Как и прочие атаки, SQL-инъекция эксплуатирует уязвимости и недоработки в коде, и нужно проводить анализ сайта, чтобы найти «слабые» места.

Попробуем пояснить, что такое SQL-инъекция, на простом примере.

Как известно, большинство сайтов и веб-приложений состоят из трёх компонентов: бэкенд (код, который выполняется на сервере), фронтенд (код, который выполняется на стороне клиента, например в браузере) и база данных. Базы данных обычно состоят из множества таблиц. Скажем, если вы владеете интернет-магазином, у вас должно быть как минимум две таблицы: характеристики товаров и информация о зарегистрированных покупателях. Чтобы получать из базы информацию, например, о конкретном товаре, используется язык SQL-запросов.

Представим, что вы пришли в отдел бытовой техники (базу данных). У вас собой есть список покупок, где написано: «Один чайник за 1000 рублей». Вы даёте список продавцу, прося его принести то, что в нём указано (SQL-запрос).

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

SQL-инъекция возникает, когда злоумышленник может изменить запрос к базе данных.

В примере выше SQL-инъекция бы возникла, если бы кто-то посторонний исправил ваш список покупок, например дописал в конец: «Чайник за 1000 рублей или смартфон за 30 000 рублей». Получив от вас такой запрос, продавец, видя, что смартфоны лежат гораздо ближе, чем чайники, дал бы вам смартфон — то есть то, что нужно злоумышленнику.

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

К чему может привести

• Утечка конфиденциальных данных (паролей, данных банковских карт и прочего).

• Внедрение вредоносного контента в уязвимые поля.

• Изменение базы данных.

• Доступ к операциям администрирования.

Как защититься

• При составлении запросов используйте плейсхолдеры (параметризированные запросы).

• Настройте белый список полей ввода.

• Отделите базу данных от логики веб-приложения.

• Используйте экранирование запросов.

Обход директорий

Обход директорий (Path traversal или Directory traversal) заключается в том, что хакер получает доступ к директориям или файлам на сервере с помощью манипуляций переменных, ссылающиеся на эти файлы. Например, для скачивания файла с сервера указывается его имя:

www.site.ru/download? file=file.pdf

С помощью символа, обозначающего директории (…/), можно получить доступ к другим файлам, просто добавив его в строку:

www.site.ru/download? file=…/…/…/etc/passwd

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

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

К чему может привести

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

• Удалённое выполнение вредоносного кода.

• Подмена страниц сайта.

Как защититься

• Старайтесь не использовать вызовы файловой системы при пользовательском вводе.

• Если же без вызовов файловой системы не обойтись, проверяйте вводимые пользователем данные перед их обработкой. После проверки входных данных используйте API файловой системы платформы для канонизации пути. Следует убедиться, что канонизированный путь начинается с ожидаемого базового каталога.

Уязвимости при загрузке файлов

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

Самая распространённая ошибка — отсутствие проверки типа файла. Например, пользователь при загрузке фотографии может вместо .jpeg или .png подгрузить php-скрипт и выполнить его.

Тип файла обычно проверяется по заголовку, но такая проверка опасна, так как заголовок можно подменить. Проверки на стороне клиента тоже иногда можно обойти. И даже использование чёрного/белого списка расширений может быть неэффективным, поскольку иногда вредоносный код встраивается прямо в файл с «правильным» расширением.

К чему может привести

Злоумышленник подгрузит на сайт вредоносные скрипты, сможет «сломать» его или извлечь какие-либо данные.

Как защититься

Исчерпывающие рекомендации о том, как обезопасить загрузку файлов, есть на StackOverflow. Чек-лист посвящен PHP, однако некоторые пункты будут актуальны и для других языков:

1. Запретить выполнение файлов в директории, куда они сохраняются;

2. Переименовывать пользовательские файлы так, чтобы пользователь не мог повлиять на них;

3. Заново сохранять картинки с помощью библиотек по редактированию изображений, чтобы удалить лишние meta-данные и возможный внедрённый в них вредоносный код.

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

Также рекомендуем ознакомиться со статьями про безопасность сайта в нашей Базе знаний.

Авторы: Артём Мышенков и Георгий Шутяев, инженеры по безопасности хостинг-провайдера и регистратора доменов REG.RU.

Оригинал: https://www.reg.ru/blog/populyarnye-uyazvimosti-sajtov-chem-opasny-i-kak-izbezhat/

Полный текст статьи читайте на CMS Magazine