Я решился взяться за перевод проекта Михаила Залевски (Michal Zalewski) « Browser Security Handbook », в котором описаны подходы к обеспечению безопасности в браузерах. Материал будет полезен всем, кто интересуется веб-безопасностью.
Данная тема для меня нова, поэтому с переводом могут быть косяки. Текст перевожу не слово в слово, основные моменты стараюсь изложить в более понятной для российского восприятия форме. Привожу дополнительные ссылки, чтобы материал могли освоить такие же, как я, т.е. пользователи с минимальными знаниями в данной сфере. Также прошу у читателей помощи в переводе; готов выслушать любую критику по тексту.
*Firefox 3.5 принимает безопасный, но не совместимый с RFC подход представления в Url отдельного символа «’» как %27, в дополнении к очередным выходящим за рамки правилам.
Данная тема для меня нова, поэтому с переводом могут быть косяки. Текст перевожу не слово в слово, основные моменты стараюсь изложить в более понятной для российского восприятия форме. Привожу дополнительные ссылки, чтобы материал могли освоить такие же, как я, т.е. пользователи с минимальными знаниями в данной сфере. Также прошу у читателей помощи в переводе; готов выслушать любую критику по тексту.
Руководство по безопасности браузеров
(Browser Security Handbook)
Глава 1
Веб-браузер. Основные понятия
В этом разделе дается обзор основных стандартов и технологий, используемых в современных браузерах и их защитных свойств.1. Унифицированный указатель ресурса (URL)
Все веб-ресурсы адресуются с использованием унифицированного указателя ресурса. Возможность должным образом анализировать форму и содержащихся в ней допустимых данных является для многих серверных механизмов безопасности важным критерием.
Абстрактный синтаксис[1] для URI описан в RFC-3986 . Данный документ определяет основную иерархическую URI-структуру, рекомендательный список «незарезервированные символы», которые отображаются в URI как есть (0-9 A-Z a-z - . _ ~), спецсимволы, имеющие определенное функциональное назначение (: / ? # [ ] @ ! $ & ' ( ) * + , ; =), а также, записанные в шестнадцатеричном представлении с использованием знака «%» (%nn)[2], все остальные символы (в том числе и сам знак «%»).
Дополнительные механизмы описаны в RFC1738 , который определяет синтаксис URI в рамках HTTP, FTP, NNTP, Gopher и других протоколах передачи данных. Вместе с тем, в RFC представлена следующая традиционная форма записи интернет-ресурсов :
<схема>://<логин>:<пароль>@<хост>:<порт>/<URL-путь>?<параметры>#<якорь>
где,
схема - схема обращения к ресурсу (в большинстве случаев имеется в виду сетевой протокол);
логин - имя пользователя, используемое для доступа к ресурсу;
пароль - пароль указанного пользователя;
хост - полностью прописанное доменное имя хоста в системе DNS или IP-адрес хоста в форме четырёх групп десятичных чисел, разделённых точками;
порт - порт хоста для подключения;
URL-путь - уточняющая информация о месте нахождения ресурса;
параметры - строка запроса с передаваемыми на сервер (методом GET) параметрами. Разделитель параметров — знак «&». Пример записи параметров:
?параметр_1=значение_1&параметр_2=значение_2&параметр3=значение_3
якорь - идентификатор «якоря», ссылающегося на некоторую часть (раздел) открываемого документа.
Помимо вышеуказанных документов, «стандарты» RFC1630 и RFC2368 описывают в общих чертах некоторые дополнительные понятия, такие как «строгий синтаксис строки поиска HTTP» (параметр_1=значение_1[&параметр_2=значение_2&...]), или возможность использовать знак «+» как сокращенное обозначение пробела (сам символ не используется по назначению в URL, что несколько необычно).
Несмотря на то, что многие спецсимволы заданы в качестве разделителей в общем URL-синтаксисе, только части из них отводится четкая роль в HTTP-адресе; функции для символов [, ], !, $, ', (, ), *, ;, или ,явно нигде не определены, но они иногда используются как инструмент для скрытной передачи параметров в структуру web-приложений.
Сам RFC иногда подразумевает, что символы без конкретных функций в схеме должны быть обработаны как обычные символы ASCII, в ином случае предлагается, чтобы они сохранили особое значение – возникает двусмысленность.
Удобной формой записи IP-адреса ( IPv4 ) является запись в виде четырёх десятичных чисел со значением от 0 до 255, разделённых точками. Стандарты, определяющие общий синтаксис URL, позволяют использовать альтернативный способ записи IP-адреса с использованием нескольких систем счисления (возможно, даже одновременно), например, IP-адрес 213.180.204.3 может быть записан как 0325.0264.0314.03 (восьмеричная запись), 0xd5.0xb4.0xcc.0x3 (шестнадцатеричная запись)[3], 213.0264.0xcc.3 (смешанная: десятичная, восьмеричная и шестнадцатеричная формы записи). Кроме того, браузеры могут принять Url-адрес с технически недопустимыми символами, а затем, попытаться его проигнорировать или передать в первозданной форме, например, DNS-клиенту, который либо отвергнет, либо пропустит такой запрос характерным для операционной системы образом.
Особенно интересный пример URL-анализа несовместимости адреса:
Перейдя в браузере Firefox по ссылке, мы попадем на страницу «Яндекса», хотя ожидали открыть страницу «Google».
В таблице 1 представлены отличия, которые должны учитываться:Таблица 1
Описание | MSIE7 | MSIE8 | FF3 | Safari | Opera | Chrome | Android |
Символы, игнорируемые перед схемой URL | x01-x20 | x01-x20 | t r x20 | x20 | t r x0B x0C xA0 | x00-x20 | x20 |
Нестандартные символы, разрешенные в имени URL-схемы (за исключением 0-9 A-Z a-z + - .) | t r | t r | t r | нет | r +UTF8 | 0 t r | нет |
Нестандартные символы, остающиеся без изменений в строке URL-запросов (за исключением 0-9 A-Z A-z- . _ ~ : / ? # [ ] @ ! $ & ' ( ) * + , ; =)* | " < > ^ ` { | } x7F | " < > ^ ` { | } x7F | ^ { | } | ^ { | } | ^ { | } x7F | " ^ ` { | } | нет данных |
Нестандартные символы, полностью игнорируемые в имени хоста | t r xAD | t r xAD | t r xAD | xAD | х0а-x0D xA0 xAD | t r xAD | нет |
Виды неполных или нецелых Url-адресов автоматически исправляются до полного | //y y | //y y | //y x:///y x://[y] | //y y x:/y x:///y | //y y x://[y] | //y y x:///y | //y y |
Является ли фрагмент ID (хэш), закодированный с применением RFC в соответствии с вытекающими из URL правилами? | НЕТ | НЕТ | ЧАСТИЧНО | ДА | НЕТ | НЕТ | ДА |
незарезервированная %nn-последовательности URL-пути декодируются в адресной строке? | ДА | ДА | ДА | НЕТ | ДА | ДА | нет данных |
незарезервированная %nn-последовательности URL пути декодируются в location.href? | ДА | ДА | НЕТ | ДА | ДА | ДА | ДА |
незарезервированная %nn-последовательности URL-пути декодируются в текущих HTTP-запросах отправки? | ДА | ДА | НЕТ | НЕТ | НЕТ | ДА | НЕТ |
Отклоненные символы в имени пользователя или пароле в URL (за исключением / # ; ? : % @) | x00 | x00 | нет | x00-x20" < > [] ^ ` { | } x7f-xff | x00 | x00 x01 | x00-x20" < > [] ^ ` { | } x7f-xff |
URL-данные аутентификации разделенные несколькими символами«@» | крайний левый | крайний левый | крайний правый | крайний левый | крайний правый | крайний правый | крайний левый |
ПРИМЕЧАНИЕ: Для борьбы с фишингом многими браузерами вводятся дополнительные ограничения на использование поля «логин» и «пароль» в Url-адресе; см. раздел HTTP-аутентификация .
Пожалуйста, обратите внимание, когда ссылки внедрены в HTML-документы, декодирование HTML-объекта происходит перед тем, как ссылки анализируются. Поэтому, если в URL-схеме символы игнорируются, ссылка вида javascript	:alert (1)может быть принята и выполнена как JavaScript равно как и javascript<TAB>:alert (1). Кроме того, некоторые символы, такие как x00в Internet Explorer, или x08в Firefox, могут быть проигнорированы синтаксическим анализатором HTML, если используется в некоторых местах, даже если они не относятся к обработке URL-кода себя.Примечание:
[1] - описание структуры данных, не зависящее от аппаратной реализации и способа кодирования.
[2] – Так называемое URL-кодирование или «percent-encoding».
[3] - Восьмеричные числа начинаются с цифры 0, после которой следует серия цифр от 0 до 7. Шестнадцатеричные целые числа имеют префикс 0х или 0Х и могут состоять из цифр от 0 до 9 и букв от а(А) до f(F).