Технология Клиент-Сервер 2009'1
	Home Поиск Издания Контакты k-press.ru

Продолжается подписка на наши издания! Вы не забыли подписаться?

Ускорение работы Ajax-приложений за счёт устранения уязвимостей Web-сервисов
Встраивание функций безопасности в приложения и увеличение продолжительности безотказной работы сервисов с гарантией SLA

Автор: Джудит Майерсон

Опубликовано: 09.07.2010
Версия текста: 1.1

Развертывание Ajax-приложений с эффективным использованием полосы пропускания еще не гарантирует сохранения тех высоких параметров, которые задает соглашение об уровне услуг (SLA). Как бы качественно вы ни меняли код в формате Ajax для увеличения эффективности использования полосы пропускания, всегда останутся риски и уязвимости, которые придется снижать и отслеживать.

Введение

В серии статей, которую я недавно написала для developerWorks, Использование соглашений об уровне услуг (SLA) в контексте Web-сервисов, я рассказывала об обеспечении безопасности множественных Web-сервисов, в том числе о применении для них брандмауэров и уменьшении риска уязвимостей в рамках соглашения SLA. Я говорила о том, насколько важно обеспечить высокую доступность сервиса клиенту по различным критериям производительности и качества.

В начале статьи я делаю обзор Ajax (Asynchronous Ja­vaScript + XML), указываю на некоторые уязвимости, рассказываю о значении соглашений SLA и об Ajax-приложениях с эффективным использованием полосы пропускания, которые, однако, не гарантируют снижения или исчезновения риска уязвимостей. В статье также рассмотрены возможности ускорения работы Ajax-приложений и обхода уязвимостей в Web-сервисах.

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

Обзор Ajax

Ajax позволяет создавать быстрые и интерактивные Web-сервисы путем трансформации пользовательского интерфейса браузера (например, при транзакции между двумя предприятиями) в портал Web-сервисов на основе XML (например, при транзакции между предприятием и потребителем). Такой результат достигается за счёт создания дополнительного слоя обработки между Web-страницей и сервером через HTTP-протокол. Этот слой перехватывает запросы пользователя и фоновые запросы, "тихо" и асинхронно взаимодействует с сервером, чтобы получить нужный ему контент через HTTP-про­токол. Не обязательно, чтобы запросы и ответы сервера совпадали с действиями пользователя, например, с запросом к базе данных об обновлении записи или ответом с сообщением об успешном обновлении.

Уязвимости Web-сервисов

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

Рассмотрим четыре примера уязвимостей:

• Превышение пропускной способности
• Испорченные данные
• Частые небольшие HTTP-запросы
• Утечки памяти

Превышение пропускной способности

XML-сообщения в текстовом формате могут в два и более раз увеличить объём передаваемых двоичных данных. Чем большая пропускная способность требуется для передачи XML-сообщений, тем меньше ресурсов останется у системы или у приложения для выполнения других необходимых задач, например, для выполнения сложных алгоритмов. Превышение пропускной способности может снизить производительность в результате перегрузки системы.

Испорченные данные

Превышение пропускной способности может привести к генерации Ajax-приложениями испорченных данных, потому что для создания достоверных данных будет недостаточно ресурсов. Это означает, что порталы Web-сервисов, в состав которых входят Ajax-при­ложения, могут передавать испорченные данные в другие части портала, в результате чего появятся плохо сформированные сообщения и чрезмерный парсинг. Если этой уязвимостью воспользуется злоумышленник, это может привести к "падению" браузера.

Частые небольшие запросы

Один из недостатков Ajax состоит в том, что он разрешает выполнять много небольших запросов вместо посылки страницы целиком (post-back). Частые небольшие HTTP-запросы могут перегружать серверы, балансировщики нагрузок и брандмауэры, а это приведет к превышению пропускной способности, что снизит производительность. Такие запросы могут столкнуться с ограничениями браузера или медленным сетевым соединением, и в сети появятся узкие места.

Утечки памяти

Обычно в Web-приложении Web-страницы часто перезагружаются, и, соответственно, память о них стирается и заполняется заново. При помощи Ajax можно избежать повторной загрузки страниц, пока вы дожидаетесь вывода на портал Web-сервиса следующего блока информации. Ajax позволяет отображать одностраничное приложение в браузере несколько дней, что увеличивает проблемы, связанные с возможной утечкой памяти или других ресурсов. Крупные утечки памяти, наряду с превышением пропускной способности и небольшими HTTP-запросами, могут привести к порче данных Web-портала и увеличить шансы на успех хакеров, которые могут воспользоваться уязвимостями вашей системы через Интернет.

Анализ риска

В каждом случае необходимо определять степень риска того, что злоумышленник воспользуется уязвимостями вашей системы и сервера и это повлияет на ваш бизнес. Высокая степень риска потребует наличия защитных средств для ускорения Ajax-приложений. Пример такого средства - увеличение времени безотказной работы сервиса при помощи гарантии SLA (соглашение об уровне услуг).

Соглашение об уровне услуг

Как бы вы ни улучшали код Ajax-приложения, чтобы оно более эффективно использовало сетевые ресурсы, всегда остаются риски и уязвимости, которые нужно отслеживать и устранять. Развертывание приложений с эффективным использованием полосы пропускания не гарантирует сохранения уровней услуг SLA на определенном уровне (или не ниже его, например, 99,9 или 99,999%). При переносе приложений из среды браузера на серверный Интернет-портал на основе Ajax приложения становятся более уязвимыми, особенно написанная на XML часть, которая используется для создания Web-сервисов для поиска проблем с производительностью (например, потерь пакетов).

Для увеличения времени безотказной работы сервиса надо учесть три обстоятельства. Во-первых, для ускорения Ajax-приложений нужно пользоваться разными средствами улучшения производительности, а не только оптимизировать пропускную способность (например, есть еще возможности фильтрации XML-контента и ускорения XML). Во-вторых, для безопасности Ajax-при­ложений нужно учитывать стандарты Интернет-безо­пас­ности, такие как WS-Security (WSS), Application Vulnera­bility Description Language (AVDL) и многие другие. В-тре­тьих, необходимо отслеживать трафик этих приложений – это также будет средством измерения производительности.

Улучшение № 1. Ускорение работы приложений

Давайте рассмотрим следующие возможности ускорения работы Ajax-приложений:

• Специализированные аппаратные ускорители.
• Оптимизированное ПО.
• Устранение избыточности кода.
• Возможности ускорения XML.
• Разрешение проблем функциональной совместимости.

Специализированные аппаратные ускорители

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

Оптимизированное ПО

Оптимизированное ПО используют для модификации и уменьшения размера системы, чтобы приложение выполнялось быстрее или использовало меньше ресурсов памяти и т. п. Оптимизированное ПО на переносном компьютере позволяет потреблять меньше электроэнергии. Сокращение объема и времени загрузки с серверов осуществляется в два этапа:

1. Анализ полезного содержимого Ajax-приложений с помощью ASP.Net или JavaScript.
2. Разработка оптимизированного ПО на основе данных анализа.

Устранение избыточности кода

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

Возможности ускорения XML

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

Один из основных факторов, снижающих производительность Web-сервисов, - затраты на сетевую передачу и обработку данных, связанные с XML. В результате обозначилась тенденция к стандартизации схемы двоичного кодирования в XML, примером чего может служить пакет XML-binary Optimized Packaging Specification (XOL).

Разрешение проблем функциональной совместимости

Как бы ни были оптимизированы Ajax-приложения, какое бы ни использовалось аппаратное ускорение, и как бы ни был сокращён избыточный код, все равно потребуется решать проблемы функциональной совместимости. Например, когда Ajax-приложения преобразуются в Web-сервисы, выходящие за пределы контроля организации, нужно обеспечивать их внешнюю функциональную совместимость друг с другом, учитывая общую семантику и контрактные обязательства. Неправильное понимание семантики (например, семантики закрытого ПО) и пробелы в контрактах (например, различия между платформами) приведут к возникновению проблем с функциональной совместимостью, например, при интеграции Ajax-приложений с унаследованными системами.

Улучшение № 2. Стандарты Web-сервисов

Рассмотрим некоторые из стандартов Web-сервисов OASIS для Ajax-приложений (OASIS – Организация продвижения стандартов структурированной информации [Organization for the Advancement of Structured Information Standards], а руководит ей Международный консорциум открытых стандартов [International Open Standards Consortium]).

• WS-Security Extensions (WS-SX)
• Security Access Markup Language (SAML)
• Service Provisioning Markup Language (SPML)
• Digital Signature Services (DSS)
• Application Vulnerability Description Language (AVDL)

Все эти стандарты направлены на то, чтобы снизить риск уязвимости, который увеличился в результате переноса Ajax из приложений для браузера на серверные Интернет-порталы. Они могут работать эффективнее только при условии применения пакета XOL или иной двоичной XML-схемы.

WS-SX

Этот стандарт предоставляет техническую основу для реализации функций безопасности, например, целостности и конфиденциальности сообщений, которые используются в высокоуровневых Ajax-приложениях Web-сервисов. Поскольку WSS направлен на единичный обмен сообщениями, его расширили до WS-SX, чтобы реализовать обмен надежными SOAP-сообщениями, в том числе множественными, а также определить политики безопасности по отношению к разным форматам и иным характеристикам таких сообщений. Разработке WS-SX содействовали спецификации Web Services SecureConversation, SecurityPolicy и Trust.

SAML

Этот язык разметки определяет и поддерживает стандартную среду на основе XML для создания информации по безопасности и обмена ей по сети между партнерами. SAML используют для реализации в Интернете технологии единого входа, авторизации на основе атрибутов (Attribute-based Authorization) и обеспечения безопасности Web-сервисов.

SPML

Этот стандарт предоставляет среду XML для управления вводом и размещением идентификационной информации и системных ресурсов внутри организаций и для совместного использования. Кроме того, спецификация SPML 1.0 разработана так, что позволяет использовать WSS, цифровые подписи XML Digital Signatures и шифрование XML Encryption.

DSS

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

AVDL

Цель AVDL – определение языка для описания информации, которую можно будет использовать для защиты конкретного приложения. Эта информация может включать в числе прочего информацию об уязвимостях, а также данные о легальном использовании.

Если время между запросом и ответом на него большое, пороги прерывания могут достичь такой величины, что будут производить обратный эффект в отношении определенного соглашением SLA времени безотказной работы. Чтобы минимизировать такую опасность, я показала в другой статье (http://www.­ibm.­com/de­veloper­works/web/library/ws-sla7/in­dex.html) методы уменьшения риска, связанного с выявлением уязвимостей Web-сер­висов в гетерогенной сервис-ори­ентированной архитектуре (SOA). Влияние порогового прерывания можно ещё снизить при помощи пакета XOL. Я не имею в виду, что это снижение полностью обеспечивает соблюдение SLA-гарантий.

Улучшение № 3. Отслеживание трафика

Активное отслеживание трафика является одним из средств непрерывного измерения эффективности использования сетевого соединения Ajax-приложениями. При отслеживании трафика моделируется передача данных по сети и работа IP-сервисов и в реальном времени собирается информация о производительности сети при работе Ajax-приложений. Можно собирать данные о времени ответа, пропускной способности, времени запаздывания с одной стороны, неустойчивой синхронизации, потере пакетов и времени ответа сервера.

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

Заключение

Чтобы ускорить работу Ajax-приложений и устранить уязвимости Web-сервисов вам потребуется команда разработчиков, испытателей, системных администраторов и потенциальных пользователей. Для устранения избыточности кода и утечек памяти, а также ограничения полосы пропускания и количества мелких HTTP-запросов вам надо будет заранее готовиться к разработке, тестированию и развертыванию проектов Ajax, направленных на повышение производительности. Разрешение этих проблем облегчит работу по ускорению работы Ajax-приложений.

Copyright © 1994-2016 ООО "К-Пресс"