Главная > Uncategorized > Веб-безопасность: прогноз на 2011 год

Веб-безопасность: прогноз на 2011 год

Очень интересно будет проверить в конце 2011 года, насколько я оказался прав.
Я даже попытаюсь обосновать свой прогноз.

Что было в начале?
Примерно с 1995 стали появляться технологии для разработки веб-приложений. Через некоторое время (примерно в начале 2000-х) настала эра уязвимостей веб-приложений: их стали находить больше, чем уязвимостей работы с памятью. Причин тому масса, среди них:

  • Незрелость технологий (если мне не изменяет память, только j2EE снабжалась достаточным количеством документации по архитектуре веб-приложений, методикам разработки и пр.). Таким образом, всему сообществу пришлось вырабатывать свои best practices, наступая на одно и те же грабли.
  • Отсутствие стандартных компонентов и фреймворков. В результате этого приходилось изобретать свои велосипеды. Мы и сейчас можем увидеть, что очередная студия веб-дизайна нет-нет, да и попытается впарить свою CMS заказчику. Практически у каждого веб-программиста были свои разработки. Что же в этом плохого?
    Рассмотрим две ИС: одна написана под заказ, другая — использует продукты open source сообществ. Владельцы второй ИС получают в качестве бонуса наработки всего сообщества, которое самоорганизовалось вокруг продукта. Т.е. при наличии процедур по обновлению ИС, можно ожидать, что ее качество (а в том числе и защищеность) будет постоянно повышаться. Обратной стороной медали является повышенное внимание со стороны злоумышленников к популярному продукту. Т.е. нельзя исключать риски применения 0-day уязвимостей в отношении данной ИС. Но, на мой взгляд, преимущества забарывают недостатки. Вернемся теперь к самописной ИС. Непрерывного процесса повышения качества нет, ибо нет сообщества. Следовательно, уязвимости в продукте будут обнаруживать в лучшем случае white hat’ы с последующим responsible disclosure, а в худшем (и более вероятном) случае — злоумышленники. Т.е. шанса на исправление ошибки до реализации атаки у владельцев такой ИС не будет.
  • Ситуация еще больше подогрелась огромным спросом на специалистов в области веб-разработки и наличием технологий с низким порогом входа (например, PHP, ColdFusion). Т.е. низкоквалифицированные работники тоже были востребованы и писали server-side код.

Что мы наблюдаем сейчас?

  • Технологии веб-разработки созрели: помимо самого кода написано куча книг, созданы методики разработки, best practices, критерии оценки качества продуктов и пр.
  • Созрели фреймворки разработки веб-приложений. Достаточно назвать таких монстров, как Spring Framework, Django, Ruby on Rails, .NET.
  • Близки к зрелости и стандартные компоненты, автоматизирующие типичные сценарии использования веба: CMS, форумы, блоги, онлайн-магазины, и т.п. Видно, как количество нового custom-кода по отношению к third-party компонентам постепенно уменьшается.
  • То есть, выражаясь штампами спортивных комментаторов, server-side подходит к пику своей формы.
  • А что же у нас с client-side’ом? А там у нас HTML5, который пока находится только на стадии драфта. Легко догадаться, к чему я веду.

Что мы увидим в ближайшее время?

  • HTML5 предусматривает новые контексты для внедрения JavaScript в веб-страницы.
  • Отсутствие принятого стандарта приводит к тому, что многие конструкции HTML5 обрабатываются различными браузерами по-разному (browser specifics). См. http://html5sec.org/ — отличная иллюстрация первых двух тезисов.
  • Напрашивается вывод: по мере выходов новых версий браузеров многие исправно работавшие Anti-XSS фильтры станут пропускать XSS-векторы нового поколения.
  • В результате лично я ожидаю всплеск client-side атак через XSS.

Подискутируем? Что мы увидим в этом году в области веб-безопасности?

Реклама
  1. 29.01.2011 в 17:13

    согласен, что за client-side будущее, но при этом server-side еще слишком рано хоронить))

    • 29.01.2011 в 17:28

      Не-не, не хоронить. Мне интересно, когда shift в сторону client-side произойдет. Мне кажется, что в этом году — самое время!

  2. 29.01.2011 в 20:18

    1. По поводу перспектив, имхо, будет перерождение DOMXSS из-за того, что всё больше логики переходит на клиента, будут наверняка атаки, основанные на доверии одного веб-приложения другому, будет также много атак на расширения, которые сейчас всё больше пишут на html+JS
    2. По поводу HTML5 — http://oxdef.info/papers/html5/index.html

  3. 02.02.2011 в 14:18

    Пока финансово выгоднее ломать сервер сайд, сдвига не будет.

    • 02.02.2011 в 14:23

      Минуууууточку. Чем persistent browser specific XSS не вписывается в схемы монетизации уязвимостей?

  4. 02.02.2011 в 14:48

    Вписывается, но отдача меньше, а мороки больше :)

    • 02.02.2011 в 14:53

      Мороки больше из-за того, что готовых инструментов по автоматизации маловато и/или они не особо удобные. Верно?
      Если да, то нужно просто технологическое решение, после чего каждая XSS будет использоваться без мороки…

  5. 02.02.2011 в 15:18

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

    Первый способ даст куда больше траффика, чем ломать через XSSки, публику одного конкретного сайта, т.к. основной народ всё равно ходит через поисковики + аудитория гарантированно целевая. Второй способ в целом проще, т.к. даже ломать ничего не надо :)

    З.Ы.
    Я сознательно не рассматриваю кардинг, т.к. это вообще другой мир.

    • 02.02.2011 в 15:36

      Все так. Но этот способ, очевидно, более шумный. Рано или поздно поисковики научатся с _приемлемым_ качеством определять search poisoning. У XSS потенциала висеть скрытно и делать свое черное дело ведь куда больше.
      Ну а вообще, интересно будет сюда заглянуть через год :)

  6. 02.02.2011 в 15:51

    Ну да, но я к тому что атаки на клиента дают меньше траффика чем атаки на поисковые системы (посредством взлома тучи пиаристых сайтов). А разработка ИИ в ближайшее время не предвидится :) Посмотреть будет интересно, да.

    • 02.02.2011 в 15:54

      Кстати, мы речь вели исключительно о ненаправленных атаках. А есть еще цэлий плоскость направленных атак, вай-вай-вай!

  7. 02.02.2011 в 16:01

    Направленные атаки это не мейнстрим. Мейнстрим — массово долбить сайты определённой тематики.

    • 02.02.2011 в 16:06

      Ээээ… А что такое mainstream? Мы с какой стороны смотрим? Со стороны underground economy? Или со стороны владельца сервиса, подлежащего защите?
      Вот, например, Deutsche Post. Сказать, что для них направленные атаки не мейнстрим — в корне неверно. Или любой онлайн-банкинг. Так что mainstream mainstream’у рознь

  8. 02.02.2011 в 16:09

    Ну если рассуждать о том, в каком направлении будут развиваться технологии атаки, то имхо стоит смотреть со стороны атакующего :)

    • 02.02.2011 в 16:11

      … и его цели! Сделать дор — это не ultimate цель атакующего, кмк.
      Вот, например, контролировать банковские транзакции пользователя через man-in-the-browser — чем не цель?

      • 02.02.2011 в 16:13

        В этом кстати и состоит задача анализа угроз — мы выявляем вероятные классы атакующих с их целями и возможностями. На основе этого уже и выбираем стратегию защиты…

      • 02.02.2011 в 16:22

        Страшно же :)

        2 млн долл и 30 лет турецкой тюрьмы тоже не цель :)

        Погоду задают серые методы заработка, для тех кто и у станка работать не хочет, но и грабить боится.

  9. 02.02.2011 в 16:29

    Qwazar :

    Страшно же :)

    2 млн долл и 30 лет турецкой тюрьмы тоже не цель :)

    Погоду задают серые методы заработка, для тех кто и у станка работать не хочет, но и грабить боится.

    Ну банк был для примера. Вот есть различные почтовые сервисы, есть Advanced Persistent Threat, есть цель — нарушение конфиденциальности. Со стороны защищающейся стороны — это mainstream: им наплевать на underground economy, потому что эти ребята даже не сунуться к ним (взлом займет _слишком_ много времени => экономически нецелесообразно). У APT, кстати, нет страха перед тюрьмой :)

  1. No trackbacks yet.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: