Сегодня большинство сервисов разрабатывается для публикации в интернете. Многие компании используют их как единственный способ дистрибуции продуктов и общения с клиентами. Из чего же состоят современные веб-сервисы и какие подводные камни встречаются в их реализации?
- Введение
- Вызовы времени
- История развития веб-приложений
- Как обеспечить безопасность веб-приложений
- Выводы
Введение
Современные веб-приложения строятся на основе микросервисной архитектуры — стиля, который структурирует приложение как набор сервисов. Каждый такой сервис максимально автономен, необходим для выполнения конкретной задачи и поддерживается конкретной командой. Эта архитектура позволяет применять модульный принцип построения приложений с учётом потребностей бизнеса. Другими словами, вы всегда можете поменять один или несколько сервисов, таких как веб-сервер или сервер обработки запросов, в случае изменения потребностей без ущерба для бизнеса.
Рисунок 1. Современная архитектура веб-приложения (источник: videoblocks.com)
Другой разновидностью подхода к построению приложений является монолитная архитектура, дающая преимущество в виде минимальных проблем согласованности компонентов, но не обладающая такой гибкостью в построении, как микросервисная. Монолитная архитектура вполне имеет право на существование, но её достоинство является и её недостатком, и в современном мире она практически не встречается в веб-приложениях, т. к. не удовлетворяет требованиям Time To Market — требованиям бизнеса по выпуску новых продуктов на рынок.
Приложением, построенным на данной архитектуре, проще управлять, поскольку не требуется большого количества команд разработки и сопровождения, но на доработку уже выпущенной версии и создание новой нужно много сил и времени. Это же касается и вопросов, связанных с поиском и устранением уязвимостей. Можно сказать, что приложений без уязвимостей не бывает, т. к. ошибки свойственны всем людям, ведь именно люди и пишут код этих приложений и собирают их разрозненные части в одно целое.
Рисунок 2. Отличия монолитной и микросервисной архитектур (источник: xm-online.com)
Вызовы времени
Возможности, которые предоставляют современные технологии и языки программирования, часто влекут за собой архитектурные изъяны и уязвимости для веб-приложений, строящихся на их основе.
Продвижение достижений в сфере защиты происходит на профильных конференциях и путём написания стандартов и общих практик, которых должны придерживаться все участники. Из данных достижений возникают технологии, которые сами по себе весьма сложны и неполноценны, но энтузиасты отрасли «толкают» их на поверхность и стараются адаптировать их к реалиям бизнеса. Именно данный срез по отрасли и демонстрирует компания Gartner в своём ежегодном отчёте Hype Cycle.
Gartner уже много лет подряд выпускает ежегодный «чарт» трендов для средств защиты приложений. В нём компания отражает своё видение роста популярности тех или иных средств защиты приложений в целом и веб-приложений в частности. Стоит сказать, что данный рейтинг имеет много общего с текущей ситуацией на рынке средств защиты и его можно расценивать как некий перечень потребностей бизнеса в таких средствах.
Рисунок 3. Тренды для средств защиты приложений за 2019 год
Упомянутый перечень представлен в виде графика функции не просто так. Дело в том, что у каждой технологии есть периоды становления и не все технологии приживаются в отрасли. Данный график — это наглядное представление того, в чём у бизнеса, скорее всего, будет потребность через пять или десять лет, если эта технология, конечно же, останется на рынке. Отчёт составлен в 2019 году, и мы можем считать, что предсказания сбываются: технологии, которые востребованны уже сейчас, — это межсетевые экраны уровня веб-приложений (Web Application Firewalls) и средства управления жизненным циклом API (Full Life Cycle API Management).
Также у бизнеса возникает всё большая потребность в профессиональных услугах по обеспечению безопасности приложений (Application Security Professional Services, далее — AS). Источники этих профессиональных услуг можно разделить на четыре основные категории:
- крупные поставщики телекоммуникационных услуг с практиками AS,
- сторонние фирмы по разработке приложений с применением практик AS,
- поставщики инструментов AS с крупными профессиональными сервисными службами,
- специализированные консалтинговые фирмы, специализирующиеся на услугах AS.
Чтобы понять, для чего уже сейчас нужны данные технологии и профессиональные услуги в сфере защиты веб-приложений, нужно понимать проблематику вопроса. Как раз этим мы сейчас и займемся.
История развития веб-приложений
Для лучшего понимания того, откуда взялись проблемы безопасности современных веб-приложений, стоит заглянуть на 30 лет назад. Современный веб, как и тогда, строится на основе протокола HTTP и ряда языков разметки / программирования, таких как HTML, JavaScript и PHP. Так же в этой схеме присутствуют веб-браузер и веб-сервер.
Рисунок 4. Схема современного веба
В первой версии протокола HTTP (HTTP/0.9), разработанной в 1991 году, был всего один метод взаимодействия клиента и сервера — метод GET с последующим путём к ресурсу, например GET /mypage.html. В ответ приходил документ в формате <HTML>Ответ</HTML>. Не было заголовков, и поэтому передавать можно было только HTML-файлы. Не было и кодов ошибок с описанием ситуации, которые мы все привыкли видеть в том случае, если ресурс недоступен или страница не найдена. Но это продолжалось недолго, и в версию протокола HTTP/1.0 добавили и заголовки, и поля ошибок. Благодаря заголовку «content-type» появилась возможность передавать при помощи протокола HTTP не только HTML-файлы, но и другие типы объектов, такие как картинки и архивы.
Но по-настоящему всё это начало применяться с 1999 года, когда международной сетевой рабочей группой (International Network Working Group) была принята версия протокола HTTP/1.1, которая дорабатывается до сих пор. Стандарт устранял неясности и вносил значительные улучшения, которыми мы пользуемся и сейчас. Среди них — переиспользование соединений для сокращения времени на обработку новых запросов, конвейерная обработка, позволяющая отправлять второй запрос до того, как первый будет принят, дробление («чанкование») запросов. Разработаны дополнительные механизмы контроля кеша и согласования контента, добавлен заголовок «host», позволяющий размещать разные домены на одном IP-адресе.
Одновременно с разработкой протокола HTTP, в 1994 году компания Netscape Communications создавала криптографический протокол SSL (Secure Sockets Layer), который позволил появиться рынку электронной коммерции. SSL решили стандартизировать, и итоговым названием протокола стало TLS 1.0 (Transport Layer Security). Актуальная версия TLS 1.3 уже используется не только участниками электронной торговли, но и всеми, кто хотел бы защитить передаваемую информацию.
Вскоре, в 1996 году, протокол HTTP был расширен за счёт дополнений, поддерживающих совместную работу пользователей над редактированием файлов и управлением ими на удалённых серверах. Этому дополнению дали название WebDAV (Web Distributed Authoring and Versioning). Если сказать проще, то HTTP использовался для чтения, а WebDAV — для записи данных.
Как продолжение развития протокола HTTP в 2000 году был разработан архитектурный стиль взаимодействия компонентов распределённого приложения в сети (REST), который отлично укладывался в концепцию микросервисной архитектуры. Он предполагал взаимодействие компонентов приложения посредством заранее созданных и должным образом описанных интерфейсов с возможностью выполнения процедур обработки или выдачи информации при помощи вызовов. Сейчас подобные интерфейсы чаще всего называются API (Application Programming Interface), но ещё до этого момента были как минимум протоколы DRC и SOAP.
Подход к построению веб-приложений с использованием API позволил обмениваться информацией и командами между компонентами веб-приложения без обновления серверов или браузеров: достаточно изменить спецификацию программного интерфейса, что делается намного проще. С 2005 года популярность REST API только росла и его начали использовать на веб-сайтах для пуш-уведомлений или в рамках протокола WebSocket. Развитие API и технологий, являющихся производными от данного типа интерфейсов, мы рассмотрим в следующих статьях.
Как обеспечить безопасность веб-приложений
Все мы знаем, что интернет — в опасности. Это — общая или, как говорят, комплексная проблема, и решают её все специалисты нашей отрасли. Сейчас уже сформировано множество альянсов за безопасный интернет со стороны как технологических компаний, так и отдельных специалистов. Почти все результаты работы данных команд или проектов становятся общедоступными — вспомнить хотя бы Mozilla MDN или открытый проект OWASP с их подходом Top 10. Всех их объединяют общие принципы и подходы к обеспечению безопасности веб-технологий.
Рисунок 5. Наиболее распространённые уязвимости из списка OWASP Top 10 (источник: ptsecurity.com)
Я не открою ни для кого тайну, если скажу, что суть всех средств обеспечения безопасности веб-приложений — в том, чтобы защититься от человеческого фактора в различных его проявлениях. Эту мысль подтверждает большой перечень аналитических отчётов из года в год. Существует множество способов сделать сервис неправильно, начиная с выстраивания процесса разработки веб-приложения и заканчивая его публикацией и сопровождением. Даже вывести из эксплуатации сервис нужно как следует. Если перейти от абстракции к конкретным способам защиты, то первое, на что нужно обратить внимание, — это решения класса Web Application Firewall (WAF).
Первые WAF появились более 20 лет назад, когда компания Perfecto Technologies представила продукт AppShield — обособленную систему защиты серверов приложений сегмента e-business, позволявшую осуществлять контроль эксплуатации уязвимостей (сколько их тогда было?), изъянов в коде приложения и ошибок безопасности сторонних модулей. Сама защита веб-приложения происходила путём анализа каждого HTTP-запроса и каждой HTML-страницы.
Таким образом, ещё на заре электронной коммерции уже стояла проблема защиты интернет-магазинов, онлайн-банков и других сервисов, для которых особо актуальна угроза раскрытия информации. Веб-серверам, опубликованным в общедоступной сети, приходится сталкиваться с атаками раньше других компонентов веб-приложения, поэтому защита данных серверов от угроз — это первый и очень важный рубеж защиты всего приложения.
Как говорилось ранее, современный сервис — это набор микросервисов и взаимодействие между ними. Вторая цель злоумышленников, после того как они пробили рубеж веб-сервера, — это данные, находящиеся во внутренней базе веб-приложения. Это могут быть базы клиентов, информация по транзакциям, служебные или иные сведения, раскрывать которые никто не собирался. Вы скажете: для чего же хранить данную информацию в таком незащищённом месте?
Всё дело — в том, что часто она может быть разбросана между множеством баз данных, необходимых для выполнения бизнес-логики веб-приложения, и извлекаются эти данные путём SQL-запросов. Суть SQL-запроса заключается в том, что в базу отправляется строка, содержащая команду на выгрузку или загрузку каких-либо данных. Если не ведётся контроль команд, отправляемых SQL-серверу, то может произойти утечка, т. к. сами по себе запросы — это вполне легитимные обращения, а вот команда, содержащаяся в одном из них, может спровоцировать выгрузку и отправку злоумышленнику всей базы клиентов веб-сервиса. Если кратко — мониторинг SQL-запросов должен производиться на регулярной основе, и чем ближе этот мониторинг будет происходить к самой базе данных, тем лучше будет результат.
Выводы
После чтения этих строк может сложиться впечатление, что спасения нет, но на самом деле проблема кроется в процессе защиты. Грамотно выстроенный жизненный цикл разработки и публикации веб-приложений — это основа защищённости сервиса, т. к. стоимость исправления ошибки в публикуемом веб-сервисе снижается при смещении фокуса обеспечения безопасности в самое начало — путём выстраивания процесса безопасной разработки и применения специальных средств анализа уязвимостей, таких как решения класса Application Security Testing. Их — множество, и они призваны повысить качество кода с точки зрения исключения небезопасных вызовов и выполнения проверок входящих запросов.
Это была вводная статья, в которой рассказывалось об основных проблемах безопасности современных веб-приложений и причинах появления этих проблем. В следующих статьях мы рассмотрим все основные компоненты защиты веб-приложений более детально.
