Научная статья на тему 'Безопасность HTML5'

Безопасность HTML5 Текст научной статьи по специальности «Компьютерные и информационные науки»

CC BY
253
61
i Надоели баннеры? Вы всегда можете отключить рекламу.

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Хеирхабаров А. С., Жуков В. Г.

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

i Надоели баннеры? Вы всегда можете отключить рекламу.

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Хеирхабаров А. С., Жуков В. Г.

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

Текст научной работы на тему «Безопасность 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 и другие дают новые возможности для разработчиков, и в то же время порождают новые векторы атак для злоумышленников.

В HTML5 вводится концепция локального хранилища под названием WebStorage, позволяющая сайту сохранять данные на компьютере пользователя и впоследствии обращаться к ним через JavaScript. Выделяют два типа веб-хранилищ: локальные (могут содержать любые текстовые данные и хранятся до тех пор, пока не будут явно удалены пользователем или веб-приложением) и сессионные (аналогичны локальным, за исключением того, что данные удаляются после закрытия браузера или вкладки в нем). Для каждого домена создается отдельное хранилище. В отличие от cookie, которые имеют максимальный допустимый размер 4 кб и имеют срок хранения, данные в Web Storage не имеют срока хранения, а также защищены политикой ограничения домена, т. е. куки, принадлежащие одному сайту, не могут быть доступны другому, даже если они находятся на одном сервере. Проблема безопасности заключается в том, что эти данные пользователь не может считать напрямую, они доступны только веб-браузерам через интерфейс Java Script API. Это повышает риски от уязвимостей вида XSS (Cross Site Scripting), в том числе возможность заполучить аутентификационные данные [1]. Кроме того, есть вероятность, что злоумышленник внедрит JavaScript сценарий, способный манипулировать данными или переслать их на другой домен [2]. Также, аналогично использованию куки, локальные хранилища можно использовать для идентификация пользователей и DNS-спуфинг атак [1].

Для решения некоторых проблем, связанных с 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 или многоцелевые расширения интернет-почты). Запуск зарегистрированных обработчиков происходит со стороны пользовательского агента. Так как в качестве обработчика может быть зарегистрировано пользователем любое веб-приложение, злоумышленник может обманом заставить зарегистрировать свое приложение, тем самым предоставив ему доступ к обрабатываемым данным. Риски, связанные с этой проблемой, можно уменьшить, создав список проверенных рекомендуемых обработчиков.

Введение новых тегов и атрибутов упрощает процесс написания страниц на HTML. Но с помощью некоторых из них можно осуществить выполнение произвольного JavaScript кода (например <video>^ <autofocus>), а с помощью все того же тега <video>можно узнать точную версию браузера. Для уменьшения рисков следует настроить WAi^ Intrusion Detection System(IDS) [1].

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 (дата обращения: 7.03.2012)

4. Консорциум Всемирной Паутины w3c. URL: http://www.w3.org (дата обращения: 21.02.2012)

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

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

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

УДК 004.056

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

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

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

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

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

i Надоели баннеры? Вы всегда можете отключить рекламу.