Безопасность HTML5

Актуальные проблемы авиации и космонавтики. Информационные технологии

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

Библиографические ссылки

1. Липаев В. В. Основные факторы, определяющие технологическую безопасность информационных

систем URL: http://www.info-

system.ru/security/security_pr_tech_security.html (дата обращения: 10.09.2011).

2. Терсков В. А. Модели функционирования и методы оптимизации структуры многопроцессорных вычислительных систем : монография. Красноярск : Сиб. юрид. ин-т МВД России, 2001.

© Фейгин В. С., 2012

УДК 004.45

А. С. Хеирхабаров Научный руководитель - В. Г. Жуков Сибирский государственный аэрокосмический университет имени академика М. Ф. Решетнева, Красноярск

БЕЗОПАСНОСТЬ HTML5

HTML5 - новый стандарт языка разметки документов в сети Интернет. В докладе рассмотрены некоторые новые возможности, появившиеся в HTML5, с точки зрения безопасности.

Принятие ИТМЬ5(англ.

HyperTextMarkupLanguage, version 5) как всеобщего стандарта намечено на 2022 год, но некоторые из его спецификаций уже поддерживаются новыми версиями браузеров и используются на многих сайтах. Однако такие нововведения, как Cross-OriginResourceSharing, WebSQL, WebMessaging и другие дают новые возможности для разработчиков, и в то же время порождают новые векторы атак для злоумышленников.

Для решения некоторых проблем, связанных с WebStorage, следует:

- для поддержки сессий следует использовать куки, которые могут быть лучше защищены с помощью флага HTTPonly [3];

- не хранить конфиденциальные данные в локальном хранилище;

- разделять данные для приложений, находящихся на одном домене [2];

Ещё одним нововведением HTML5 является Cross-Origin Resource Sharing (CORS), что дает возможность сайтам получать доступ к ресурсам на других доменах. HTML5 позволяет посылать XML Http Request-запросы между доменами на основе заголовка Access-Control-Allow-Origin [4]. Эти запросы передаются без уведомления пользователя, что является достаточно серьезной проблемой безопасности. CORSможет использоваться злоумышленниками для отсылки конфиденциальных данных на свои сервера, запуска удаленного шелл-кода на пользовательском агенте, поиска существующих доменных имен во внутренних се-тях(на основании времени ответа на XML Http Re-quest-запросы), создания ботнета или, комбинируя с WebWorker, для DDoS-атак. Такжес помощью CORSможет быть реализована уже существующая угроза Cross-Site-Request-Forgery, но уже без участия пользователя [2,5].Некоторые риски, связанные с угрозой, можно избежать следующими способами:

- ограничение доменов, имеющих право делать XMLHttpRequest-запросы;

- не проводить контроль доступа только по заголовку Access-Control-Allow-Origin;

- настройка Web Application Firewall (WAF) на фильтрацию слишком частых CORS-запросов [2].

Web Messaging - ещё одна новая возможность в HTML5 - реализует два механизма коммуникации между HTMLдокументами. Перекрестный обмен данными позволяет документам обмениваться сообщениями независимо от их исходного домена, при этом

Секция «Методы и средства зашиты информации»

он разработан таким образом, чтобы не позволить злоумышленникам атаковать сценарии сайтов. Канальный обмен позволяет некоторым приложениям (в разных HTML документах) независимо обмениваться между собой сообщениями. При использовании WebMessaging, сервер не может контролировать все данные (т. к. данные приходят от других доменов), а обмен между HTML-документами (iframe) происходит на стороне пользовательского агента, что может быть использовано для обхода контроля со стороны сервера. При неправильной настройке, конфиденциальные данные могут быть отправлены не тому iframe-у. Также, iframe-ы могут посылать сообщения любому другому iframe-у. Если iframe-получатель не проверяет источник или некорректно обрабатывает входные данные, на него может быть проведена атака [2]. Часть проблем может быть решена следующими способами:

- явно устанавливать цель сообщения;

- проверять получаемые сообщения;

- проверять домен-отправитель;

HTML5 позволяет некоторым веб-приложениям регистрироваться в качестве обработчиков для определенных протоколов (SMS, факс и др.) или некоторых MIME-типов (Multipurpose Internet Mail Extensions или многоцелевые расширения интернет-почты). Запуск зарегистрированных обработчиков происходит со стороны пользовательского агента. Так как в качестве обработчика может быть зарегистрировано пользователем любое веб-приложение, злоумышленник может обманом заставить зарегистрировать свое приложение, тем самым предоставив ему доступ к обрабатываемым данным. Риски, связанные с этой проблемой, можно уменьшить, создав список проверенных рекомендуемых обработчиков.

WebSQL подразумевает под собой встроенную в браузер базу SQLite.WebSQL имеет такие же проблемы, как и WebStorage. Кроме того, это дает новые возможности для проведения SQL-инъекций. Для их предотвращения достаточно выполнять правильно параметризированные SQL-запросы [1].

HTML5 предоставляет возможности для кэширования сайтов и веб-приложений, для работы с ними в оффлайне. В HTML4.0 реализуются атаки с отправлением КЭШа (например, кэша приложений с внедренным в него вредоносным кодом), в HTML5 возможности для таких атак значительно расширяются, так как теперь кэширование может осуществляться без применения дополнений к браузеру и часть решений о доступе к данным происходит на стороне клиента [2].

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

Библиографические ссылки

1. Иващенко Т., Сидоров Д. HTML5 - взгляд через призму безопасности //Хакер. 2010. № 143.

2. SchmidtMichael HTML5 Web Security: 2010.URL:http://media.hacking-

lab.com/hlnews/HTML5 Web Security_v1.0.pdf (дата обращения: 7.03.2012).

3. Request For Comments 2965. URL:http://www.ietf.org/rfc/rfc2965.txt

4. Консорциум Всемирной Паутины w3c. URL: http://www.w3.org

5. Гордейчик С. Cross-SiteRequestForgery - много шума из ничего. URL: http://www.securitylab.ru/ ana-lytics/292473.php

6. HTML5 Security Cheatsheet. URL: http://html5sec.org/ (дата обращения: 3.03.2012).

© Хеирхабаров А. С., 2012

УДК 004.056

А. А. Шаляпин Научный руководитель - В. Г. Жуков Сибирский государственный аэрокосмический университет имени академика М. Ф. Решетнева, Красноярск

ПРИМЕНЕНИЕ ПРЕЦЕДЕНТНОГО АНАЛИЗА В ЗАДАЧЕ КЛАССИФИКАЦИИ ИНЦИДЕНТОВ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ

Рассматривается применение прецедентного анализа в задаче классификации инцидентов информационной безопасности.

Международный стандарт ISO 27001:2005 обращает особое внимание на необходимость создания процедуры управления инцидентами информационной безопасности - очевидно, что без своевременной реакции на инциденты безопасности и устранения их

последствий невозможно эффективное функционирование системы управления информационной безопасностью. Инцидентом информационной безопасности является нежелательное событие информационной безопасности (или совокупность событий), которое