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

Ошибки будут указаны по средней частоте и пронумерованы согласно Open Web Application Security Project (OWASP) TOP 10.

Итак, на первое место я бы поместил XSS (OWASP A3) — межсайтовый скриптинг.

Как и автор http://habrahabr.ru/post/149152/, я считаю XSS не уязвимостью, а вектором атаки, т.к. способов эксплуатации может быть достаточно много.

Они бывают пассивными, активными, dom-based и встречаются как на крупных коммерческих сайтах, так и на самописных домашних страничках. Межсайтовое выполнение сценариев (XSS) связано с возможностью внедрения HTML-кода в уязвимую страницу. Внедрение кода осуществляется через все доступные способы ввода информации. Успешная эксплуатация уязвимости может позволить злоумышленникам использовать значения различных переменных, доступных в контексте сайта, записывать информацию, перехватывать сессии пользователей и т.д.

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



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

Второе место почетно занимают различные утечки критичных данных — OWASP A4, A6 и A7.

Я бы назвал эту группу уязвимостей отсутствием должного внимания к хранению и передаче критичных данных.

Что сюда входит: различные уязвимости вида session prediction, когда перебирая значения ID можно получить доступ к чужим данным, например:

• /download/******* — меняя параметры можно спарсить все файлы с сервера
• /user/ticket=****** — можно просмотреть все сообщения в техподдержку ото всех пользователей

Критичные данные в корне сайта: бэкапы, служебные скрипты, репозитории и прочее.

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

На сайтах, с одной известной коммерческой CMS можно встретить файлы, упрощающие доступ в систему (auth bypass), скрипты, упрощающие резервное копирование, с указанием имени файла бэкапа в корне сайта, которое не подберешь простым перебором; скрипты для тестирования вебсервера и многое другое. Уровень доступа к этим скриптам не выставляется должным образом, и, в следствии этого, любой знающий особенности этой CMS может попытаться их найти:


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



Иногда простой поиск по директориям сайта дает просто ошеломительные результаты, например:

базы данных (лежит и ждёт, пока её кто-то скачает):


bash history (история команд):


логи (из которых можно получить полезную информацию):


резервные копии:


репозитории:

Третье место по популярности занимают разного рода инъекции OWASP A1.

Казалось бы, 2015 год, про sql injection все расписано и разжевано на каждом углу, и встретить их в живой природе все сложнее? Как-бы не так. По статистике нашей компании и статистике наших коллег, уязвимости класса sql injection довольно часто встречаются в том или ином виде.



Эксплуатация веб уязвимостей может повлечь за собой тяжелые последствия: существует возможность вытащить данные из БД, залить шелл (если позволят права) и т.д.

Например, такой POST-запрос login=admin@domain.name'+and+1=1+--+&password=pass позволяет обойти авторизацию на сайте и авторизоваться под администратором.

И хотя по популярности эта уязвимость находится на последнем месте — недооценивать ее не стоит, не зря она стоит на первом месте в рейтинге OWASP по значимости.

Что в итоге?

Большинство этих ошибок можно убрать за минимальное время и они не являются концептуальными и сложноэксплуатируемыми, но их необходимо вовремя обнаружить, оценить риски и минимизировать последствия.

Необходимо своевременно проводить аудит безопасности сайта на наличие уязвимостей.