Browser Security Handbook. Глава 1, пункт 3

Browser Security Handbook. Глава 1, пункт 3

Руководство по безопасности браузеров (Browser Security Handbook). Глава 1

2. Unicode в Url

 


3.         Подлинные URL-протоколы

URL-протоколы указывают общую схему для получения данных и способ обработки для отображения этих  данных. Схемы также могут быть привязаны к конкретным значениям некоторых URL-полей, определенных по умолчанию, например, к TCP-порту или нестандартному синтаксическому правилу разбора URL (последним, обычно, обозначается отсутствие символов «//» после схемы идентификатора).
Еще в 1994 году RFC 1738 выложил несколько URL-протоколов для просмотра веб-страниц. Некоторые из них изначально не обрабатывались браузером или устарели.
С развитием интернета появилось несколько новых открытых и собственных протоколов. Начали различаться и наборы протоколов, поддерживаемые различными браузерами. RFC 2718 попытался определить некоторые основные правила для создания новых протоколов. RFC 4395 постановила, что новые протоколы должны быть зарегистрированы в IANA ( список зарегистрированных протоколов ). Однако некоторые отказались следовать по этому пути.
Для широкого обзора возможностей современных браузеров URL-протоколы можно условно разделить на 2 группы: «Поддерживаемые программным обеспечением» и «Поддерживаемые плагинами, расширениями, или сторонними программами». Протоколы, которые относятся к списку из первой группы, отражены в таблице 3.
 Таблица 3

Название протокола
MSIE7
MSIE8
FF3
Safari
Opera
Chrome
Android
HTTP ( RFC 2616 )
ДА
ДА
ДА
ДА
ДА
ДА
ДА
HTTPS ( RFC 2818 )
ДА
ДА
ДА
ДА
ДА
ДА
ДА
SHTTP ( RFC 2660 )
как HTTP
как HTTP
НЕТ
НЕТ
НЕТ
НЕТ
НЕТ
FTP ( RFC 1738 )
ДА
ДА
ДА
ДА
ДА
ДА
НЕТ
file ( RFC 1738 )
ДА
ДА
ДА (частично)
ДА (частично)
ДА
ДА
НЕТ
Gopher ( RFC 4266 )
НЕТ
НЕТ
ДА
НЕТ
исчез?
НЕТ
НЕТ
НЕТ
НЕТ
НЕТ
НЕТ
ДА
НЕТ
НЕТ
 
Эти протоколы могут быть использованы для доставки исходного содержимого, которое интерпретируется и выполняется с помощью правил безопасности реализованных в браузерах.
Другой список сторонних протоколов, направленных в другие приложения, сильно зависит от конфигурации системы. Набор протоколов и их обработчики, как правило, содержаться в отдельном общесистемном реестре. Браузеры, по умолчанию,  имеют белые списки (выполнение внешних программ без запроса) или черные списки (запрет на их использование в целом). К наиболее распространенным протоколам этой группы относятся:

acrobat
Acrobat Reader
callto
обмен мгновенными сообщениями, ip-телефония
daap/itpc/itms/...
Apple iTunes
FirefoxURL
Mozilla Firefox
hcp
Microsoft Windows Help
ldap
функциональные возможности адресной книги
mailto
почтовые агенты
mmst/mmsu/msbd/rtsp/...
потоковые мультимедийные сообщения
mso-offdap
Microsoft Office
news/snews/nntp
новостные клиенты
outlook/stssync
Microsoft Outlook
rlogin/telnet/tn3270
telnet-клиент
shell
Windows Explorer
sip
программное обеспечение для ip-телефонии

Новые обработчики могут быть зарегистрированы в ОС и специфическим для приложения способом, например, путем регистрации нового ключа в реестре Windows по адресу HKCRProtocolsHandlers или добавлением в настройки Firefox network.protocol-handler.*.
Как правило, протоколы из последней группы не выполняются внутри визуализатора (рендерера) при обращении к элементам документа, таких как изображение, скрипт или апплет источников и т.п.; они работают как <IFRAME> или целевая ссылка, и при необходимости будут запускать отдельные программы. Эти программы иногда могут объединяться с рендерером, но правила, по которым они отображают содержимое и налагают ограничения безопасности, обычно, не связаны с браузером.
Такие сторонние протоколы можно внедрить в ссылки при уязвимых внешних программах, которые регистрируют обработчики протокола без согласия пользователя. Поэтому, по возможности, лучше отклонять непредвиденные протоколы и проявлять осторожность при внедрении нечто неожиданного на стороне клиента (в том числе и наблюдение за безопасной передачей допустимых параметров ).
Alt text

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

Сергей Сторчак

Персональный блог Сергея Сторчака