Первый взгляд на HTML 5

  1. Оригинал: alistapart.com/articles/previewofhtml5
    Перевод: vectora.ru

    Вступление

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

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

    Работа над HTML 5 началась в 2004г. и сейчас ведётся совместно W3C HTML WG (W3C HTML Working Group) и WHATWG (Web Hypertext Application Technology Working Group). Многие ключевые игроки рынка участвуют в работе: как представители производителей самых распространённых браузеров (Apple, Mozilla, Opera и Microsoft), так и ряд организаций и лиц самого широкого круга интересов.

    Работа над спецификацией HTML 5 всё ещё ведётся и пока далека от завершения. Поэтому любая особенность языка, описанная в этой статье, может быть изменена в будущем. Цель этой статьи — дать общее представление об основных возможностях языка по состоянию на текущий момент.

    Структура

    В HTML 5 появилась целая группа новых элементов, призванная упростить процесс структуризации страницы. На большинстве страниц, свёрстанных на HTML 4, можно встретить одни и те же общие структурные блоки, например заголовки (headers), подвалы (footers) и столбцы (columns). Хорошим тоном сегодня считается описание их с помощью элементов div, с присвоением каждому определённого класса или идентификатора.

    Первый взгляд на HTML 5
    На схеме представлена типичная структура страницы с 2-мя колонками, свёрстанная с использованием элементов div с атрибутами id или class. Она состоит из заголовка, подвала и полосы меню под заголовком. Блок с содержимым страницы образован текстом статьи и боковой панелью (sidebar) справа.​


    Такое большое количество элементов div продиктовано отсутствием в HTML 4 семантических элементов, необходимых для более предметного описания структурных блоков. Решение этой проблемы в HTML 5 — введены новые элементы для описания каждой части страницы.

    Первый взгляд на HTML 5
    В HTML 5 элементы div могут быть заменены на header, nav, section, article, aside и footer.

    Разметка документа тогда примет следующий вид:
    Код:
    <body>
      <header>...</header>
      <nav>...</nav>
      <article>
        <section>
          ...
        </section>
      </article>
      <aside>...</aside>
      <footer>...</footer>
    </body>
    
    В использовании этих элементов есть несколько плюсов. При совместном использовании с заголовками (теги h1…h6), появляется возможность преодолеть ограничение всех предыдущих версий HTML — не более 6 уровней вложенности. Спецификация HTML 5 предлагает пошаговый алгоритм определения структуры документа, который принимает во внимание особенности иерархической организации новых элементов. Он может быть использован как в браузерах, так и в редакторах контента для облегчения процесса просмотра документа пользователем.

    Например, для разметки следующей структуры использованы вложенные элементы section и h1:
    Код:
    <section>
      <h1>Level 1</h1>
      <section>
        <h1>Level 2</h1>
        <section>
          <h1>Level 3</h1>
        </section>
      </section>
    </section>
    
    Заметьте, для лучшей совместимости с сегодняшними браузерами также возможно использование других тегов-заголовков (h2…h6) вместо h1.

    Благодаря точному определению предназначения отдельных структурных блоков на странице появляется возможность упростить для пользователя задачу навигации по странице. Например, читатель получит возможность быстро пропустить блок с содержанием или перейти с одной статьи на другую, даже если автор не указал ссылку на неё. Авторы тоже получат выгоду от этого нововведения: найти один div в общей массе документа куда сложнее, чем отыскать единственный специализированный элемент. Другими словами, авторы выигрывают, получая более простой и понятный код.

    Элемент header используется для обозначения шапки блока. Именно шапки, так как в ней может содержаться не только заголовок, но, например, информация о версии или подзаголовок.
    Код:
    <header>
      <h1>Первый взгляд на HTML 5</h1>
      <p class="byline">Автор Lachlan Hunt</p>
    </header>
    <header>
      <h1>Полезные советы</h1>
      <h2>Пятая редакция</h2>
    </header>
    Элемент footer служит для разметки подвала определённого блока. Как правило, он содержит информацию об авторе, ссылки на материалы сходной тематики, правовую информацию и т.д.
    Код:
    <footer>©2007 vectora.ru</footer>
    Элемент nav используется для обозначения блока с навигационными ссылками. Он может быть применён как для меню сайта, так и для содержания документа.
    Код:
    <nav>
      <ul>
        <li><a href="/">Главная</a></li>
        <li><a href="/products">Продукция</a></li>
        <li><a href="/services">Услуги</a></li>
        <li><a href="/about">О нас</a></li>
      </ul>
    </nav>
    Тег aside должен использоваться для обозначения данных, имеющих косвенное отношение к основному контенту. Особо полезен может быть для обозначения боковых панелей.
    Код:
    <aside>
      <h1>Архивы</h1>
      <ul>
        <li><a href="/2007/09/">Сентябрь 2007</a></li>
        <li><a href="/2007/08/">Август 2007</a></li>
        <li><a href="/2007/07/">Июль 2007</a></li>
      </ul>
    </aside>
    Элемент section призван выделять некоторый раздел документа, например, часть рассказа.
    Код:
    <section>
      <h1>Часть 141. Жак. 22 года</h1>
      <p>Мне приснился кошмар. Сперва был плачущий волк. 
         Потом девочка, превращающаяся в воздушный шар.&hellip;</p>
    </section>
    Элемент article служит для выделения некоторой независимой части документа, например, новости, постинга в форуме или комментария в блоге.
    Код:
    <article id="comment-2">
      <header>
        <h4><a href="#comment-2" rel="bookmark">Comment #2</a>
            Написал <a href="http://example.com/">Петя Иванов</a></h4>
        <p><time datetime="2007-12-09T13:13Z">9 декабря 2007г. в 13:13</time>
      </header>
      <p>Отличная статья!</p>
    </article>
    Видео и звук

    За последние годы аудио- и видеоконтент сильно упрочил свои позиции в Сети, и сайты вроде YouTube, Viddler, Revver, MySpace и дюжины прочих сделали публикацию видеороликов и звукового контента доступной каждому. Однако из-за отсутствия в HTML средств для внедрения и управления мультимедиа-контентом они используют Flash. Несмотря на то, что всё-таки существует возможность встроить видео и аудио при помощи различных плагинов (QuickTime, Windows Media и т.д.), Flash на текущий момент — единственный плагин, установленный почти в каждом браузере и обеспечивающий кросс-браузерную (и кросс-платформенную - прим. пер.) платформу для воспроизведения медиаконтента вместе с API для разработчиков.

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

    Новые элементы video и audio серьёзно упрощают задачу. Большинство новых методов API — общее для них, различия имеются только в той их части, что оперирует со специфичными для аудио или видео свойствами.

    И Opera, и WebKit выпустили сборки браузеров с частичной поддержкой элемента video. Можно загрузить экспериментальную сборку Opera или последнюю "ночную" сборку WebKit, чтобы попробовать. В Opera реализована поддержка технологии Ogg Theora, а в WebKit проигрывает все форматы, поддерживаемые QuickTime, включая сторонние кодеки.

    Самый простой способ внедрить видео на страницу — использовать тег video и предоставить задачу отображения стандартного интерфейса управления браузеру. Атрибут controls (тип boolean - логический) используется для указания браузеру, нужно ли показывать элементы управления по умолчанию.
    Код:
    <video src="video.ogv" controls poster="poster.jpg" 
    width="320" height="240">
        <a href="video.ogv">Download movie</a>
    </video>
    Необязательный атрибут poster может быть использован, чтобы указать, какое изображение должно отображаться вместо видео до того, как началось воспроизведение ролика. Несмотря на то, что существуют видеоформаты, имеющие собственную поддержку кадра-постера, например MPEG-4, этот атрибут предлагает решение проблемы, не зависящее от формата видеоролика.

    Так же просто и добавить звук на страницу, используя элемент audio. Большинство атрибутов у тегов video и audio общие, хотя по понятным причинам к audio неприменимы атрибуты width, height и poster.
    Код:
    <audio src="music.oga" controls>
        <a href="music.oga">Download song</a>
    </audio>
    Спецификацией HTML 5 предусмотрен элемент source для указания URL видео или звука в альтернативных форматах, чтобы браузер мог выбрать наиболее подходящий вариант для загрузки и воспроизведения. Атрибут media может быть использован для определения класса устройств, для которых предназначен данный файл. Атрибут type предназначен для указания типа мультимедиа-данных и используемых кодеков. Обратите внимание, что если используется элемент source, то атрибут src в родительских тегах audio или video должен быть опущен. В противном случае элементы source будут проигнорированы.
    Код:
    <video poster="poster.jpg">
        <source src="video.3gp" type="video/3gpp" 
        media="handheld">
        <source src="video.ogv" type="video/ogg;
        codecs=theora, vorbis">
        <source src="video.mp4" type="video/mp4">
    </video>
    <audio>
      <source src="music.oga" type="audio/ogg">
      <source src="music.mp3" type="audio/mpeg">
    </audio>
    Авторы, которым необходим больший контроль над интерфейсом плеера, чтобы аккуратно встроить мультимедиа-контент в общую концепцию дизайна страницы, могут воспользоваться расширенным API, предоставляющим в распоряжение программиста несколько методов и событий для того, чтобы обеспечить возможность контроля над процессом воспроизведения. Из простейших методов стоит выделить play(), pause() и возможность изменения значения свойства currentTime для перемотки. Следующий пример демонстрирует их использование.
    Код:
    <video src="video.ogg" id="video"></video>
    <script>
      var video = document.getElementById("video");
    </script>
    <p><button type="button" onclick="video.play();">Play</button>
       <button type="button" onclick="video.pause();">Pause</button>
       <button type="button" onclick="video.currentTime = 0;">
       << Rewind</button>
    Мы рассмотрели далеко не все методы и свойства API элементов audio и video, полную информацию можно получить, ознакомившись с черновой спецификацией.

    Представление документа

    В отличие от предыдущих версий HTML и XHTML, определённых в терминах своего синтаксиса, HTML 5 описывается объектной моделью документа (DOM) — внутренним иерархическим представлением браузеров, которое они используют для описания документа. К примеру, рассмотрим очень простой документ, состоящий из названия, заголовка и параграфа текста. В этом случае дерево DOM будет выглядеть примерно так:
    Первый взгляд на HTML 5
    Дерево DOM включает в себя элемент title в head и элементы h1 и p в body.

    Преимущество определения HTML 5 в терминах DOM заключается в том, что сам язык может определён вне зависимости от синтаксиса. В основном, существует два синтаксиса для описания HTML-документов: HTML-последовательность(serialisation), известный как HTML 5 и XML-последовательность, известный как XHTML 5.

    HTML-последовательность использует синтаксис, навеянный SGML из ранних версий HTML, но она определена так, чтобы быть более совместимой с тем, как браузеры обрабатывают HTML по факту.
    Код:
    <!DOCTYPE html>
    <html>
      <head>
        <title>An HTML Document</title>
      </head>
      <body>
        <h1>Example</h1>
        <p>This is an example HTML document.
      </body>
    </html>
    Обратите внимание, что как и в предыдущих версиях HTML, некоторые теги являются необязательными и "подставляются" автоматически.

    В XML-последовательности используется XML 1.0 и пространства имён, так же, как в XHTML 1.0
    Код:
    [B]<html[/B] xmlns="[COLOR="Red"]http://www.w3.org/1999/xhtml[/COLOR]">
      [B]<head>[/B]
        [B]<title>[/B]An HTML Document[B]</title>[/B]
      [B]</head>[/B]
      [B]<body>[/B]
        [B]<h1>[/B]Example[B]</h1>[/B]
        [B]<p>[/B]This is an example HTML document.[B]</p>[/B]
      [B]</body>[/B]
    [B]</html>[/B]
    Эти два примера эквивалентны, за исключением разного расположения пробелов и наличия атрибута xmlns.

    Браузеры используют MIME-тип (MIME-type) для того, чтобы определить, какой синтаксис используется. Любой документ, чей тип определён как text/html должен удовлетворять требованиям HTML-последовательности, а документ, чей XML MIME-тип определён как application/xhtml+xml должен удовлетворять требованиям XML-последовательности.

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

    Преимущества HTML

    • Обратная совместимость с существующими браузерами;
    • авторы уже знакомы с синтаксисом;
    • прощающий ошибки синтаксис гарантирует, что пользователь не получит «жёлтый экран смерти» (ошибка парсинга xml в mozilla -прим. пер.);
    • удобный сокращённый синтаксис, когда можно опускать многие теги и атрибуты.

    Преимущества XHTML

    • Строгий синтаксис XML заставляет авторов писать хорошую разметку (well-formed markup), с которой, как некоторые считают, удобнее работать;
    • прямая интеграция с другими XML-словарями, например, SVG и MathML;
    • возможен XML-парсинг и сопутствующая обработка, что используется многими как для правки, так и для процесса публикации.

    Как внести свой вклад

    Работа над HTML 5 движется быстро, но, несмотря на это, ожидается что она продлится ещё несколько лет. Из-за требований, регламентирующих создание эталонных тестов (test cases) и наличие сопоставимых реализаций, текущие сроки завершения работы — 10-15 лет. Во время этого процесса крайне важно наличие обраной связи с широким кругом людей, включая дизайнеров, разработчиков, производителей CMS, средств авторинга, браузеров. Выражение мнения каждого об HTML 5 всячески приветствуется.

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


    Существует большое число способов внести свой вклад. Вы можете присоединиться к W3C's HTML WG и подписаться или внести свой вклад в списке рассылки HTML WG. Можно также постить на форум WHATWG и комментировать блог WHATWG.
     
    1 человеку нравится это.
  2. Спасибо, очень интересно.
    Мой +
     
  3. ozs
    HTML5 — взгляд через призму безопасности

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

    Веб-хранилище — мощная альтернатива кукам

    Нет ничего удивительного в том, что с приходом эры веб-приложений (как например Gmail) появилась необходимость в хранении массивов данных на стороне веб-браузера. Яркий пример тому — это попытки сделать возможной работу с такими веб-приложениями офлайн. В этом больших успехов добился Google со своей технологией Google Gears. Куки со своими лимитами (особенно по размеру в 4КБ) и методами работы с ними — явно неподходящее и устаревшее решение для подобных задач. По этой причине было решено разработать новый механизм, подобный кукам, но лишенный их недостатков. Им и стала технология WebStorage. В 2 словах, благодаря HTML5 мы теперь имеем хранилище (вернее два хранилища) вида «ключ-значение» на стороне веб-браузера с доступом из JavaScript:

    • localStorage — для долговременного хранения данных;
    • sessionStorage — для сессионного применения.

    Механизм поддерживается практически всеми веб-браузерами: Firefox 3.5, Safari 4.0, IE8, Google Chrome, Opera 10.50. Ниже приведён типовой пример использования локального веб-хранилища для учёта посетителей веб-страницы.

    Код:
    <p>Вы просматривали эту страницу <span id="count">сколько-то </span> раз.</p>
    <script>
    if (!localStorage.pageLoadCount)
         localStorage.pageLoadCount = 0;
    localStorage.pageLoadCount += 1;
    document.getElementById('count').textContent = localStorage.pageLoadCount;
    </script>
    
    Давай посмотрим на сторону безопасности данной технологии. Как и многое в JS API в HTML5 подчиняется механизму HTML5 Origin, то есть данные доступны для всех страниц на одном домене с учетом протокола и номера порта (например, example.com:80). Как уже отмечалось выше, веб-хранилище избавлено от лимита в 4КБ и спецификация рекомендует использовать 5 МБ на домен. На деле же у Firefox, Safari, Opera, Google Chrome лимит равен 5МБ, у IE — 10МБ. Но самое интересное не в самой квоте, а в том, как браузер используют их.
    К примеру, в Firefox действует лимит на .example.com. Таким образом, (и тут внимание!) один поддомен может полностью занять место, отведенное для домена:

    /
    Код:
    / Firefox 3.6.8
    for (var i = 0; i < 100; i++) {
        try {
            localStorage.setItem(rand(1, 10000).toString() +  'foo'+i.toString(), 'AA...AA'+i.toString());
        } 
        catch (e) {
            alert(i.toString()+'|'+e);break;
            }
    }
    
    Не обошлось и без вездесущего null-байта. В данном веб-браузере вставка null-байта в ключ localStorage приводят к «забывчивости» Firefox. Иными словами место, хоть и всего в 1Б занято, но веб-браузер его не учитывает. «Мелочь, а приятно» (с).
    Идём дальше. Google Chrome пытается быть более строгим к ограничениям на домен и в расчете лимита учитывается полностью домен. Но в тоже самое время в Google Chrome можно занять вообще *всё* твое дисковое пространство, создав кучу айфреймов на wildcard-домен, в котором и забрать по 5МБ!

    Код:
    for(var i=0; i<10; i++) {
        var iframe = document.createElement('iframe');
        iframe.src = 'http://'+randomString()+'.example.com/ddos.html';
        document.body.appendChild(iframe);
    }
    
    
    Этот баг до сих пор не исправлен. Помимо прочего от кук к новому виду хранилища перекочевали и старые проблемы, в том числе:

    • отслеживание пользователей;
    • DNS-спуфинг атаки.

    Из-за особенностей ограничения доступа (протокол+домен+порт) мы также имеем проблемы на хостингах, использующих систему example.com/~user/, чего к слову сказать с куками не было. Да, давно уже мы не встречали подобный хостинг в жизни, но вдруг!
    Стоит также отметить ещё одну важную особенность веб-хранилища — в отличие от кук на сервер ничего не передается в рамках привычных HTTP-запросов. Данные доступны только со стороны веб-браузера через JS API. Так же как и другие технологии, которые переносят большую часть работы веб-приложения на сторону веб-браузера, это повышает риски от традиционных уязвимостей вида XSS. И если раньше угоняли куки, то сейчас велик шанс угнать более «вкусные» данные, а в 5 МБ их уместить можно немало! Для сессионных кук, впрочем, появилась возможность сильно урезать их доступность с JavaScript с помощью атрибута HTTPOnly, и это хорошо. Но для WebStorage подобных механизмов не предусмотрено, и доступ будет полным.

    SQL-инъекция в веб-браузере

    Раз уж зашла речь про хранение данных вспомним и про ещё более продвинутое средство — веб-SQL база данных прямо в браузере! Пускай это и SQLite, но и это уже неплохо! Не будем подробно рассматривать достаточно специфичный синтаксис выполнения запросов к БД, а лучше сразу рассмотрим следующий код, который должен просто выводить информацию о книге по ее ID:
    Код:
    function showById() {
        var pos = document.URL.indexOf("book=")+5;
        var bookId = document.URL.substring(pos,document.URL.length);
        var author = '';
        var title = '';
        db.transaction(function(tx) {
            tx.executeSql("SELECT * FROM books WHERE id = " + bookId, [], function(tx, result){
                if ( result.rows.length > 0) {
                    document.getElementById('bookAuthor').textContent =result.rows.item(0)['author'];
                    document.getElementById('bookTitle').textContent = result.rows.item(0)['title'];                        }
            }, function(tx, error){});
        });
    }
    
    А что будет, если перейти по адресу вроде следующего? target.com/html5/websql.html?book=1/**/AND/**/1=2
    Получаем DOMXSS+SQL-инъекцию! Жаль, что возможности по использованию данной уязвимости достаточно малы (кстати, Oxod написал хорошую статью про инъекции в SQLite, ссылку ищи внизу). Особенно с учётом того, что и Опера, и Хром хранят в отдельных файлах sqlite-базы для сайтов. Само собой авторы предусмотрели возможность и рекомендуют выполнять «безопасные» параметризированные SQL-запросы. Но посмотрим, как разработчики будут следовать их совету. Помимо прочего для веб-SQL баз характерны такие же проблемы, как у localStorage и sessionStorage.

    Новые теги и атрибуты — обновляем базы сигнатур IDS и WAF

    В HTML5 добавились новые теги и атрибуты — это значит, что пора обновлять правила/сигнатуры твоих WAF (мы подробно писали о файрволах для веб-приложений них в статье «Горящие стены защиты» в #10/2009 номере ][ ). Одним из новых элементов разметки является атрибут autofocus. Это достаточно долгожданный атрибут, потому как ранее, практически все время приходилось делать JavaScript-обработку автофокуса. И в вот в HTML5, наконец, добавили атрибут для автофокусировки на определённом текстовом поле. Но давай представим себе использование этого атрибута как способа автоматического исполнения кода:

    Код:
    <input onfocus=alert(1) autofocus>
    <input onblur=write(1) autofocus><input autofocus>

    Этот приём может пригодиться, например, когда фильтруются угловые скобки. Тег <video>, который мы уже сегодня вспоминали, несет в себе помимо собственно мультимедийных функций ещё и возможности выполнения JavaScript-кода (кто бы мог подумать :) через атрибут poster:

    Код:
    <video poster=javascript:alert(1)//
    <video><source onerror="javascript:alert(1)">

    К «заслугам» <video> можно отнести еще и возможность точной идентификации веб-браузера. Будет еще одним приемом в копилке Metasploit Decloak. Примеры c новысми элементами можно продолжать. Как тебе, например, самовыполнение JavaScript с помощью обработчика onscroll тега и всё того же атрибута autofocus?

    Код:
    <body onscroll=alert(1)><br><br><br>...<br><input autofocus>

    Или вот еще финт, правда он работает пока только в последних версиях Оперы:
    Код:
    &ltform id="test" /><button form="test" formaction="javascript:alert(1)">

    Новые типы полей форм

    Помимо новых тегов и атрибутов, в HTML5 большое внимание уделено взаимодействию веб-приложений с пользователем и добавлено большое количество типов текстовых полей ввода: datetime, datetime-local, date, month, time, week, number, range, email, url, search, tel, color. Они призваны добавить больше смысловой нагрузки обычным текстовым полям. Так для поля date будет возможно удобно выбрать дату, не прибегая к использованию готовых календарей на JavaScript. Не придется больше заморачиваться с текстом-заглушкой. В общем, наконец, появятся более удобные и подходящие по контексту средства ввода информации.

    Код:
     <style>
                [required] {
                  background-color: green;
                }
                :invalid {
                  background-color: red;
                }
            </style>
    …
    <input name="email" type="email"/>
    
    Что важно с точки зрения безопасности, так это то, что поля будут сами себя валидировать!

    Валидация данных в формах
    [​IMG]

    С одной стороны, ура — больше не надо писать регулярки по RFC (хотя и у тебя этого права никто не отнимает, благо теперь добавлен специальный атрибут pattern) и заморачиваться опять же проверками на JavaScript перед отправкой данных формы на сервер. С другой стороны не следует забывать про валидацию на стороне серверной части веб-приложения! Как ни странно, но практика показывает, что и сейчас часто встречаются случаи, когда про серверные проверки забывают или реализуют их недостаточно строго. Проверке на стороне веб-браузера, как понимаешь, доверять уж точно не стоит. Особенно «замылиться глаз» может при разработке AJAX-части современных веб-приложений. И вот чего я опасаюсь: если эта валидация ещё больше упроститься, то как бы разработчики и вовсе про нее не забыли!

    Cross-document messaging

    Веб-браузеры по причинам безопасности ограничивают взаимодействие (доступ и обмен данными) клиентских частей веб-приложений, размещенных на разных доменах. Несмотря на то, что ограничение вроде как действительно нужное с точки зрения безопасности, междокументное взаимодействие в некоторых случаях часто оказывается необходимым. Например, это может быть актуально для виджетных технологий. Система междокументных сообщений позволяет (в идеале) безопасным способом обмениваться данными документам, размещенным на разных доменах, и поддерживается уже как минимум Firefox, Google Chrome.
    Рассмотрим, как работает данный механизм. Пусть сайт (вернее его клиентская часть) example.com/index.html хочет взаимодействовать с foo.com/iframe.html, который загружен в айфрейме. В таком случае на foo.com инициализируется «получатель» сообщений. Код получателя сообщений на foo.com:
    Код:
    <div id="msg">...</div><script>
    window.addEventListener('message', receiver, false);
    function receiver(e) {
        if (e.origin != 'http://example.com') {
            return;
        }
        document.getElementById('msg').innerHTML = 
        'Origin: ' + e.origin  + ' From: ' + e.source  + ' Data: ' + e.data;
    } 
    </script>

    Обрати внимание на явную проверку отправителя (e.origin). Но даже с такой проверкой надо не забывать валидировать пришедшие данные на тот случай, если на доверенном отправителе вдруг обнаружится, скажем, XSS. А в документе (клиентской части) a.example.com мы отправляем сообщение получателю:
    Код:
    function postMsg() {
      var o = document.getElementById('ifra');   
      o.contentWindow.postMessage(document.getElementById('msg').value, 'http://foo.com/');
      return false;
    }
    
    
    Здесь важно явным образом указывать адресата сообщения targetOrigin. Даже не смотря на то, что стандартом предусмотрена возможность указать «*» и тем самым разрешить отправлять сообщения любому адресату. Имхо, основной риск в этом механизме в изначальной сложности безопасной реализации обмена сообщениями. Разработчику нужно чётко понимать, что он делает. ТВелик риск элементарно забыть про проверку отправителя. Может оказаться опасным «слепое» использование пришедших данных, что приведет к перерождению DOM-based XSS.

    Определение местоположения​

    Текущие местоположение — достаточно важный аспект частной жизни («приватности»), поэтому реализовывать механизмы его определения надо с большой осторожностью. Этот аспект описан в секции «Security and privacy considerations» спецификации от W3С. Если в двух словах, то в спецификации заявлено о том, что месторасположение должно быть явным образом разрешено посетителем сайта. Технически это реализуется вызовом специального метода объекта navigator.geolocation

    Код:
    if (navigator.geolocation) {
      navigator.geolocation.getCurrentPosition(function(position) {
        var lat = position.coords.latitude;
        var lng = position.coords.longitude;
        var options = {position: new google.maps.LatLng(lat, lng) }
        var marker = new google.maps.Marker(options);
        marker.setMap(map);
      });
    }
    
    Во всех популярных браузерах (за исключением MS Internet Explorer, в котором Geolocation API попросту не реализован) при заходе страницу, использующую гелокацию, отображается предупреждение о сборе сведений и спрашивается разрешение у пользователя. При этом есть возможность запомнить свой выбор и/или поместить сайт в белый либо чёрный список. Важно, что при этом учитывается домен сайта, не включая полный путь до скрипта…
    В ходе определения местоположения веб-браузер собирает данные о твоем IP-адресе, ближайших точках беспроводного доступа и возможно другую подобную информацию (например, случайный идентификатор клиента назначаемого Google, который истекает через 2 недели) и пересылает это всё сервису определения местоположения. А теперь, братья-параноики, угадайте, кто будет являться этим самым сервисом в большом количестве случаев (Google Chrome, Firefox, Opera)?! Правильно, Google Location Services! Нам, конечно обещают, что:
    «Ни Mozilla ни Google никогда не будут использовать собранную Google Location Services информацию для вашей идентификации и никогда не будут за ваши шпионить.»
    Но мы то знаем, что никому нельзя верить! :) Так же следует обратить внимание на печальные последствия, которые принесёт XSS на разрешенном для сбора координат сайте.

    В заключение

    Хочется надеяться, что наученные горьким опытом разработчики веб-приложений не только кинутся реализовывать все действительно интересные и нужные фишки HTML5, но и проштудируют разделы «Security» соответствующих спецификаций. Радаует, что не отстают от прогресса и различные инструменты для пентестеров, в том числе W3AF, являющийся мощным и свободный фреймворком для проведения аудита безопасности веб-приложений. Ваш покорный слуга является одним из участников этого проекта и мы уже добавили модули для поиска мест использования WebStorage и другие рискованные участки кода. Так что при очередном аудите сайта на безопасность ты можешь определить, используются ли там фишки HTML5 :).

    (c)Журнал Хакер, Декабрь (12) 143
    Тарас «oxdef» Иващенко
    Дмитрий «Invent» Сидоров