Основные уязвимости защиты в системах электронной торговли

 K. K. Mookhey  

1. Введение

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

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

2. Уязвимости

2.1 Предпосылки

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

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

В ряде случаев мы нашли, что системы электронной торговли рекламируют свои 128-разрядные SSL сертификаты как доказательство высокой защищенности своих сайтов. Доверие в это пользователей за последние несколько лет заметно снизилось, но даже сейчас имеются тысячи сайтов показывающих Verisign или Thawte сертификаты как доказательства их защищенности.

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

2.2 SQL инъекция

SQL инъекция относится к вставке метасимволов SQL в вводимые пользователем данные, что приводит к изменению запроса в конечной базе данных. Как правило, злоумышленники для начала определяют уязвимость сайта к такой атаке (для этого посылается знак одинарной кавычки). Последствия выполнения такой атаки на уязвимом сайте могут находиться в пределах от появления детального сообщения об ошибке, что раскрывает злоумышленнику используемую на сайте технологию, до доступа к закрытым областям сайта или выполнения на сервере произвольных команд операционной системы.

Методы SQL инъекции зависят от типа используемо базы данных. Например, SQL инъекция на базе данных Oracle осуществляется в основном с помощью использования ключевого слово union. и она намного более трудна, чем на MS SQL сервере, где можно выполнить множественные запросы, отделяя их символом точки с запятой. В заданной по умолчанию конфигурации MS SQL сервер выполняется с привилегиями Local System и имеет расширенную процедуру 'xp_cmdshell', позволяющую выполнение команд операционной системы.

2.3 Манипулирование ценой

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

Рисунок 1. Achilles web proxy

Подлежащая уплате сумма (currency=Rs&amount=879.00) может быть изменена злоумышленником. Если общий объем транзакций высокий, то изменение суммы может пройти незамеченной или обнаружиться слишком поздно.

Подобные уязвимости были найдены в программном обеспечении 3D3 ShopFactory Shopping Cart, в котором информация о сумме была сохранена в простом клиентском Cookie, которое могло легко изменяться злоумышленником. Аналогично, Smartwin Technology CyberOffice Shopping Cart 2.0 был атакован с помощью загрузки формы заказа и повторной её пересылки на целевой сервер с измененными скрытыми полями.

2.4 Переполнение буфера

Уязвимость переполнения буфера не является специфической для систем электронных покупок или других систем использующих Perl, PHP, ASP, и т.д. Однако посылка большого количества байт на web приложение может иметь неожиданные последствия. В одном из испытаний на проникновение с помощью ввода в входные поля большого количества символов можно было раскрыть путь используемых PHP функций. Ниже показан пример, в котором после ввода в отдельное поле 6000 или более байт серверный PHP сценарий был неспособен их обработать, а в сообщении об ошибке было отображено расположение этих PHP функций.

Рисунок 2. Ошибка таймаута PHP.

Используя эту информацию об ошибках возможно получение доступа к служебному каталогу "admin". Зная только структуру web сайта и видимые ссылки невозможно определить расположение каталога "admin".

Страницы ошибок могут служить ценным источником критической информации. Такие ошибки могут быть вызваны в web приложениях неиспользующих строгих правил проверки входных данных. Например, web приложение ожидает ввода числовых значений, а при вводе символьных происходит сбой. Подобное происходит в представленном ниже примере. В нем сайт электронной торговли использует числа для различных страниц. Пользователи перемещаются по страницам, используя ссылки типа http://www.vulnerablesite.com/jsp/Navigate.jsp?pageid=123. Модифицируя URL и подставляя значение "AA" можно вызвать следующую ошибку:

Рисунок 3. Раскрытие информации с помощью навигационных ошибок.

При тщательном наблюдении видна версия Oracle Application Server - Oracle 9iAS 9.0.3.0.0, а также версии некоторых дополнительных компонентов типа Orion Application Server. Дополнительно виден путь к вероятно уязвимому сценарию - /templates/menu.jsp.

2.5 Межсайтовый скриптинг

Атака межсайтовго скриптинга (CSS атака) прежде всего, направлена на конечного пользователя.

CSS атака требует наличие web формы, принимающей данные от пользователя, обрабатывающей их и отображающей результаты на web странице вместе с исходными данными пользователя. Такое чаще всего наблюдается в поисковых системах, когда логика поиска выводит результаты вместе со строкой типа 'Результаты поиска для строка_пользователя'. В таком случае, если вводимые пользователем данные отображаются без предварительного синтаксического анализа, то у злоумышленника есть шанс внедрить JavaScript код, предоставляя его как часть входных данных. При нажатии на URL содержащий JS код, он выполняется на машине жертвы. Типичная CSS атака выглядит следующим образом:

http://www.vulnerablesite.com/cgi-bin/search.php?keywords=<script>alert("OK")<script>. В этом случае, при нажатии пользователем на данной ссылке, на его системе откроется окно сообщения с текстом "OK".

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

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

В этом случае злоумышленник отрывает на машине жертвы два окна. То, что на заднем плане - настоящее окно web сайта Citibank, а всплывающее окно на переднем плане - окно злоумышленника, запрашивающее у пользователя информацию о номере кредитной карты, пин-коде и сроке действия карты. После нажатия на кнопку "Submit" вся информация пересылается на сервер хакера.

Подобные атаки могут быть выполнены на сайтах, использующих сценарии, перенаправляющие пользователей на динамически создаваемые части сайта. Например, одно web приложение имело подобный сценарий: http://www.vulnerablesite.com/cgi-bin/redirect.php?url=some_dynamic_value. Неизвестно как думали разработчики этого приложения, но кажется, они не понимали, что злоумышленник может создать URL типа http://www.vulnerablesite.com/cgi-bin/redirect.php?url=www.attackersite.com и отослать его жертве. В таком URL можно просто закодировать часть, следующую за 'url' шестнадцатеричными значениями или преобразовать IP адрес злоумышленника в шестнадцатеричный или восьмеричный эквивалент. Например, если IP адрес злоумышленника - 192.168.0.1, то URL может выглядеть следующим образом: http://www.vulnerablesite.com/cgi-bin/redirect.php?url=http://7934518627/.

2.6 Удаленное выполнение команд

Наиболее разрушительные последствия уязвимостей в web приложениях происходят, когда с помощью CGI сценария злоумышленник выполняет команды операционной системы. Наиболее часто это происходит при использовании запроса "system" в PHP и PERL сценариях. Используя разделители команд и другие системные метасимволы возможно выполнение команд с привилегиями web сервера. Например, в системе Hassan Consulting's Shopping Cart было возможно удаленное выполнение команд, происходящее из-за того, что программным обеспечением не отклонялись метасимволы типа |;&.

2.7 Слабые механизмы аутентификации и авторизации

Механизмы аутентификации, не использующие запрета на многократные попытки неудачного входа в систему, могут быть атакованы с помощью программ типа Brutus. Также если сайт использует открытую аутентификацию HTTP или не поддерживает прохождение идентификаторов сеанса через SSL, то злоумышленник может просниффить трафик для обнаружения данных идентификации или авторизации пользователя.

Так как HTTP является статистическим протоколом, то web приложения обычно сохраняют идентификаторы сеанса на машине пользователя в Cookie. Таким образом, этот идентификатор сеанса становиться единственным путем для определения правильности пользователя. В случае захвата и определения идентификатора сеанса злоумышленник может имитировать пользователя на уязвимом сайте. В случае использования слабых алгоритмов генерирования идентификаторов сеанса, возможно написание простого Perl сценария перебирающего все возможные значения идентификаторов и таким образом взломать систему идентификации пользователей.

Подобное было описано Дэвидом Эндлером в статье "Определение в "лоб" идентификаторов сеанса web приложения", в которой автор объяснял как идентификаторы сеанса могут быть найдены с помощью простого перебора в "лоб" на сайтах типа www.123greetings.com, www.register.com.

3. Меры противодействия

Наиболее важной в формировании защиты приложения является непосредственно стадия проектирования. Фактически, одним из ключевых шагов в течение проектирования является детальная оценка степени риска. Здесь необходимо определить ключевую информацию, используемую web приложением. Это может включать в себя конфигурационную информацию, идентификаторы сеансов, номера кредитных карт и т.д. Каждый элемент этой информации должен быть классифицирован из учета его чувствительности. В зависимости от предварительно выбранной архитектуры, разработчики вместе с экспертами защиты должны проанализировать вероятную угрозу нападения и уязвимости для их системы. После перечисления всех рисков должны быть предприняты меры противодействия против каждого из них, а в случае необходимости должна быть изменена вся архитектура. Меры противодействия должны включить в себя процедуры строгой проверки входных данных, модульную структуру, использовать открытые криптографические стандарты и другие безопасные методы кодирования.

4. Заключение

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