Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Контроль за безопасностью приложений Ajax

Джордан Винс

С появлением новых корпоративных приложений возникают и новые угрозы информационной безопасности предприятий. В данной статье рассматриваются способы устранения слабых мест в так называемых «обогащенных Интернет-приложениях» (Rich Internet Application — RIA).

Технология Web 2.0 основывается на множестве плодотворных идей, в том числе и на концепции RIA, заставляющей многих специалистов по информационной безопасности не спать ночами. Распределение «интеллекта» между сервером и клиентом, как это предусматривает данная концепция, — это фундаментальный сдвиг парадигмы..., но одновременно и большой риск, учитывая печальное состояние с информационной безопасностью браузеров. Кроме того, хотя модель разработки приложений Ajax затрагивает лишь некоторое подмножество приложений RIA, заложенные в ней возможности и особенности превращают проблему устранения угроз безопасности в настоящий вызов.

На помощь могут прийти сканеры веб-приложений, но их развертывание — дело сложное. Приступая к написанию данной статьи, мы решили вместо простого анализа готовых «коробочных» сканеров рассмотреть весь процесс принятия решений по обеспечению безопасности приложений RIA и Ajax. В результате мы выяснили, что здесь имеются по крайней мере четыре четко различимых подхода. (Более подробно о программе тестирования см. «Тестируем сканеры веб-приложений».)

В прицеле — «богачи»

Почему же приложения RIA столь небезопасны? Если говорить по-простому, то в случае традиционного веб-приложения весь его «интеллект» сосредоточен на веб-сервере. Браузеры, в принципе, действуют как «тупые» средства удаленного визуального отображения. Да, ActiveX, Java-аплеты и другие средства обеспечивали (и до сих пор обеспечивают) бо-лее «интеллектуальную» передачу данных. Но приложения RIA выводят все это на новый уровень, когда браузеры становятся местом хостинга интерактивных приложений, которые запрашивают данные у серверов напрямую.

Сегодняшнюю «сцену RIA» делят между собой Ajax, приложения Flash и Apollo компании Adobe, Java-приложения компании Sun Microsystems, приложения, разработанные в среде Microsoft Windows Presentation Foundation и ActiveX. Но наибольшим потенциалом развития, без сомнения, обладает Ajax.

Слово Ajax (аббревиатура от Asynchronous JavaScript and XML) стало сегодня ключевым в лексиконе технологии Web 2.0, а его применение значительно раздвинуло границы обозначения приложений, в которых действительно используются асинхронные сценарии JavaScript и язык XML. Многие приложения с маркой «Ajax» конкретно используют асинхронный сценарий JavaScript — исходная страница загружается с сервера при помощи такого сценария, который по мере необходимости направляет асинхронные запросы серверу и обеспечивает загрузку только необходимых для демонстрации в данный момент фрагментов веб-страницы.

Обычно в Ajax-приложениях данные между сервером и клиентом передаются посредством вызовов API XMLHttpRequest, при которых пересылаются XML-сообщения. Однако из-за сложности обработки этих сообщений и связанной с этим перегрузки многие приложения используют те же самые вызовы XMLHttpRequest с альтернативными сообщениями в формате JSON (JavaScript Object Notation). Последний в качестве переносчиков данных вместо XML-сообщений использует JavaScript-объекты. При таком подходе для получения доступа к результатам действий сервера клиентская половина приложения может обрабатывать возвращенные ей данные без анализа, требуемого при пользовании XML.

Аналогично некоторые приложения возвращают «сырые» результаты в форме HTML-сообщений, которые можно добавлять к модели DOM (Document Object Model).

Эта модель позволяет программировать браузер с целью организации взаимодействия сценария JavaScript с HTML- и XML-данными. При этом асинхронная модификация страницы происходит без привлечения XML или JSON.

Тем не менее название Ajax закрепилось настолько прочно, что даже приложения, которые для транспортировки данных вместо XML-сообщений пользуются сообщениями в формате JSON или HTML, — как говорится, «до ку-чи» — именуются Ajax-приложениями. Если бы существовало более точное определение, то мы с удовольствием избавились бы от такой неоднозначности, но по-ка придется пользоваться тем, что есть.

Следует отметить, что и другие виды технологий RIA не слишком уж отстают от лидера, в частности, число последователей Flash и Java, по нашим наблюдениям, растет день ото дня. Проблема заключается только в том, что ни та, ни другая технология не рассчитана на проверку обычными сканерами веб-приложений. В случае Java мы рекомендуем дополнить внешний сканер (один из тех, который мы анализируем в последующем обзоре) сканером исходного кода (из группы подобных продуктов, рассмотренных нами в нашем последнем обзоре, — см.: Сети и системы связи. 2007. №11. С. 82).

Просчитываем варианты

Способность веб-браузера самостоятельно обращаться с запросами к серверу может по-разному влиять на информационную безопасность приложения. Есть, например, очевидные «ловушки», такие, как реализация мер защиты только на клиентской стороне. Затем существует большая проблема, состоящая в том, что Ajax-приложения почти всегда пишутся по крайней мере на двух языках — это JavaScript, на котором реализуется клиентская часть, и тот язык, который используется на веб-сервере. И как всегда, чем сложнее реализация приложения, тем хуже обстоят дела с его безопасностью.

Наконец — и только в самое последнее время! — начали выявляться совершенно новые классы уязвимостей. Данная тенденция, по-видимому, будет укрепляться по мере усиления всеобщего внимания к труднопреодолимой проблеме безопасного исполнения приложений в столь небезопасной конфигурации (см. «Сообщения о конце отрасли информационной безопасности несколько преувеличены»).

Крепкий орешек

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

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

В процессе аудита приложений Web 2.0 сканерам веб-приложений приходится проводить большую дополнительную работу. Во-первых, перед проверкой приложения на предмет выявления уязвимостей сканер должен выполнить все свои обычные функции и составить «карту» всех «закоулочков и лазеек». Это сравнительно легко сделать в случае традиционных приложений — средства, реализующие поиск на веб-узлах (спайдеры), известны довольно давно. Правда, всегда возможно, что спайдер предпримет какое-то непредусмотренное действие, поэтому большинство сканеров веб-приложе-ний ограничивают сферу действия спайдера определенными URL-ссылками и поддиректориями.

Однако в случае Ajax-приложений ситуация будет совершенно иной. Чтобы точно разобраться в приложении и проверить всю его функциональность, сканер должен «проанализировать» сценарий приложения на языке JavaScript, с тем чтобы узнать, на что оно способно и как форматирует и пересылает данные. Сканер должен также «уметь» проводить синтаксический разбор ответных сообщений сервера.

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

И это действительно так. Согласно одному исследованию, опубликованному в феврале с. г., семь из десяти веб-сайтов содержат слабые места, которые делают их (сайты) открытыми для атак. В рамках рекламной кампании фирма Acunetix, работающая в области безопасности веб-сайтов, в течение года провела сканирование 3200 сайтов. При этом были обнаружены 210 тыс. уязвимостей. Выбор сайтов для этого исследования осуществлялся на добровольной основе. Поэтому можно предположить, что владельцы сайтов-участников — коль скоро они дали согласие на участие в сканировании — проявляют достаточную заботу о безопасности своих сайтов. Мы полагаем, что доля сайтов, имеющих слабые места, действительно так высока, как показал результат исследования, если не выше. Более подробно о данном исследовании вы можете узнать на сайте nwc.com/go/0514hack.

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

Если вы все еще сомневаетесь в серьезности и обилии программных ошибок в браузерах, то не пожалейте пару вечеров и посетите сайты sla.ckers.org и ha.ckers.org — веб-форум и блог соответственно. Там вы обнаружите такую богатейшую и впечатляющую дискуссию по поводу уязвимостей и компьютерных вторжений, что перед тем, как «нырнуть» в Интернет в следующий раз, вам захочется — чтобы обрести чувство безопасности — навсегда отключить JavaScript, Flash, Java и даже картинки.

Дороги, которые мы выбираем

Итак, приложения RIA нужно обезопасить. К сожалению, для этого недостаточно просто купить сканер приложений и «спустить его с поводка» в сеть. Вашему предприятию необходимо выбрать одну из возможных тактик: выделить собственного специалиста по вопросам безопасности и вменить ему в обязанность сканирование веб-приложений — вручную или с применением одного из коммерческих инструментов, которые мы рассмотрим в обзоре; приобрести такой инструмент, но передать его не службе безопасности, а в руки разработчиков или сотрудников службы обеспечения качества ПО (Quality Assurance — QA); обратиться к услугам сервис-провайдеров, работающих по принципу SaaS (Software as a Service — «ПО в качестве услуги»); привлечь сторонних консультантов.

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

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

• обучение разработчиков;

• анализ безопасности ПО в процессе его проектирования и разработки;

• анализ безопасности ПО в процессе его внедрения;

• бизнес-процессы для своевременного выявления слабых с точки зрения безопасности мест, которые не были обнаружены на предыдущих этапах;

• надлежащее повторное использование стандартных программных модулей при их более строгом сопровождении.

Сканирование веб-приложений представляет собой всего лишь один из этапов процесса разработки безопасного ПО. Многие из предназначенных для предприятий версий проанализированных нами инструментов рассчитаны на интеграцию с системами контроля бизнес-процедур, программами обучения разработчиков и другими ресурсами. Если вы с нуля создаете систему обеспечения жизненного цикла разработки ПО согласно методологии SDLC (Software Development LifeCycle), располагаете необходимым бюджетом и предъявляете высокие требования к безопасности, то не забудьте рассмотреть все опции, приведенные в табл. 2.

Для некоторых организаций главной мотивацией приобретения сканера веб-приложений является необходимость выполнять требования законодательства. Так, стандарт безопасности данных платежных карт PCI-DSS (Payment Card Industries Data Security Standard) недвусмысленно требует сканирования приложений, обрабатывающих данные кредитных карт, квалифицированным специалистом по информационной безопасности. Хотя текущая версия стандарта не устанавливает четко, каким должен быть этот специалист — сторонним или работающим в самой контролируемой компании, — ожидается, что в будущих его версиях будет более четко указано на возможность осуществления этой работы внутренним аудитором — при условии наличия у него достаточной квалификации.

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





  
12 '2007
СОДЕРЖАНИЕ

инфраструктура

• Стандарт 802.11r для безопасной Wi-Fi-мобильности

• Отвод тепла от стоичного оборудования в ЦОДах

• Удаленное управление по дополнительному каналу

сети связи

• Качество речи в IP-сетях

• Гладкий межсетевой роуминг-почти реальность

кабельные системы

• Оптические инфраструктуры: волокна и кабели

• Кабельные каналы для сетей 10-Gigabit Ethernet

• Прокладка кабелей в ЦОДе: под фальшполом или у потолка?

информационные системы

• Здравствуй бизнес-интеллект!

• "Вытягиваем" производительность виртуальных машин

защита данных

• Контроль за безопасностью приложений Ajax

новые продукты

• MetroScope - комплексное решение для тестирования сетей Ethernet/IP;ИБП серии ITYS компании Socomec UPS


• Калейдоскоп



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх