4. Facebook developers reference. https://developers.facebook.com/docs/reference/php/ facebook-getSignedRequest
5. Barth A., Jackson C., and Mitchell J. Robust defences for cross-site request forgery // Proc. 15th ACM Conf. on Computer and Communications Security. ACM Press, 2008. P. 75-87.
6. ModSecurity Advanced Topic of the Week: HMAC Token Protection. http://blog. spiderlabs .com/2014/01/modsecurity-advanced-topic-of-the-week-hmac-token-pro-tection.html
7. Understanding ASP.NET View State. http://msdn.microsoft.com/library/ms972976.aspx
8. NIST 800-162. Guide to Attribute Based Access Control (ABAC) Definition and Considerations. http://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.sp. 800-162.pdf
УДК 004.94
ОБ ИНФОРМАЦИОННЫХ ПОТОКАХ ПО ВРЕМЕНИ, ОСНОВАННЫХ НА ЗАГОЛОВКАХ КЭШИРОВАНИЯ ПРОТОКОЛА HTTP
Д. Н. Колегов, О. В. Брославский, Н. Е. Олексов
Рассматриваются информационные потоки по времени через заголовки кэширования протокола HTTP. Приводятся практические примеры реализации данных потоков и их основные характеристики, в частности достижимость на практике максимальной пропускной способности таких каналов при достаточно высоком уровне точности — 99,8 %.
Ключевые слова: компьютерная безопасность, скрытые каналы, HTTP.
Рассматривается задача анализа и реализации информационных потоков по времени, основанных на заголовках кэширования протокола HTTP. Обнаружение информационных потоков по времени и соответствующих им скрытых каналов в компьютерных системах является одной из задач компьютерной безопасности [1]. Распространённость протокола HTTP делает выявление методов реализации информационных потоков по времени перспективным направлением для исследований.
Известные на данный момент информационные потоки в протоколе HTTP, как правило, основываются на отправке HTTP-запросов со специальными GET- или POST-параметрами или на применении стеганографических методов для сокрытия факта передачи информации в HTTP-заголовках. Однако данные методы меняют стандартную структуру HTTP-запроса, а значит, требуют соответствующей модификации вебсервера. Информационные потоки, рассматриваемые в данной работе, не накладывают дополнительных ограничений на конфигурацию веб-сервера и, следовательно, представляют больший интерес для изучения.
Заголовки кэширования в протоколе HTTP хранят информацию о времени последнего изменения веб-страницы, тем самым позволяя клиенту не загружать веб-страницу, если она не была изменена с момента последнего запроса. Таким образом, возможна передача информации на основании данных об изменениях запрашиваемой вебстраницы. Например, ситуация, при которой некоторая веб-страница была изменена с момента последнего обращения к ней, может быть интерпретирована как получение одного бита информации.
Рассмотрим общую схему информационного потока по времени данного типа (рис. 1). Пусть Oi —объект, доступный на чтение процессу Si на hosti; O2 — вебресурс, расположенный на hosti; Os — HTTP-ответ; O4 — объект, доступный на запись
процессу $3 на Л,оз£2; 53 — веб-сервер; $1 и $2 —два процесса, которым в соответствии с политикой безопасности данной компьютерной системы запрещено общаться напрямую. В каждый момент времени процесс $1 считывает один бит информации из объекта 01 и, в зависимости от значения бита, осуществляет или не осуществляет доступ на запись к веб-странице 02. Процесс $3 выполняет НТТР-запрос к 02 и после получения НТТР-ответа 03, основываясь на изменениях сущности 02, пишет в объект 04 соответствующий бит (например, 1, если веб-страница была изменена, и 0 в противном случае).
Информационные потоки по времени, основанные на заголовках кэширования протокола HTTP, могут быть разделены на две группы: потоки, основанные на заголовке Last-Modified, и потоки, основанные на заголовке ETag.
Заголовок Last-Modified содержит время последнего изменения сущности на вебсервере, например, «Last-Modified: Tue, Ю Apr 2Q!4, І2:34:56 GMT». Существует три возможных варианта реализации потока по времени на основе заголовка Last-Modified:
1) по значению заголовка Last-Modified: S3 обращается к O2 и получает HTTP-ответ O3; сравнивая полученное в O3 значение заголовка со значением, полученным в предыдущий раз, S3 делает вывод об отправленном бите — если значения не совпадают, то получена І, иначе Q;
2) с помощью заголовка If-Modified-Since: S3 обращается к O2 с заголовком «If-Modified-Since: Date1» и получает HTTP-ответ O3. Если код ответа O3 равен 2QQ, значит, веб-страница O2 была изменена и получена І; если код ответа 3Q4, то веб-страница не менялась и получен Q;
3) с помощью заголовка If-Unmodified-Since: S3 обращается к O2 с заголовком «If-Unmodified-Since: Date1» и получает HTTP-ответ O3. Если код ответа O3 равен 4І2, значит, веб-страница O2 была изменена и получена І; если код ответа 2QQ, то веб-страница не менялась и получен Q.
Для реализации рассматриваемых информационных потоков по времени необходимо, чтобы S1 имел права на запись в объект O2 и на чтение из объекта O1; S3 имел права на чтение O2, то есть мог обратиться к сущности O2 на веб-сервере через HTTP. При стандартной конфигурации веб-сервера информационные потоки, основанные на заголовке Last-Modified, имеют одинаковую теоретическую максимальную скорость І бит/с. Данная скорость обусловлена техническими ограничениями заголовка Last-Modified: формат даты, используемый заголовком, хранит время с точностью до секунд.
В результате тестирования реализации одного из вышеописанных потоков установлено, что максимальная скорость потока достижима на практике, если пропускная способность канала между S1 и S3 позволяет S3 сделать запрос к O2 и получить ответ O3 за І с. Точность передачи для полученной реализации составила 99,82%.
write*
Рис. 1. Общая схема информационного потока
Заголовок ETag (entity tag) используется для контроля изменений HTTP-сущностей. Среди наиболее распространенных веб-серверов только в Apache стандартизован алгоритм формирования заголовка ETag [3]. Значение ETag в соответствии с данным алгоритмом формируется из шестнадцатеричных значений идентификатора сущности (inode), размера сущности и времени последнего изменения сущности в формате mtime: «ETag: 120c7bL-32bL-4f86d4105ac62L». Соответственно могут быть рассмотрены три варианта информационных потоков, основанных на заголовке ETag:
1) по значению заголовка ETag: S3 обращается к O2, получает HTTP-ответ O3 и делает вывод об отправленном бите, сравнивая полученное в O3 значение заголовка со значением, полученным в предыдущий раз;
2) с помощью заголовка If-Match: S3 обращается к O2 с заголовком «If-Match: ETagi» и получает HTTP-ответ O3. Если код ответа O3 равен 412, значит, получена 1; если код ответа 200, то получен 0;
3) с помощью заголовка If-None-Match: S3 обращается к O2 с заголовком «If-None-Match: ETagi» и получает HTTP ответ O3. Если код ответа O3 равен 200, значит, получена 1; если код ответа 304, то получен 0.
Реализация данных потоков требует прав доступа, аналогичных требованиям потока по заголовку Last-Modified. В стандартной конфигурации веб-сервер обновляет значения ETag не чаще чем раз в секунду, то есть, если клиент запрашивает вебстраницу более одного раза в секунду, все ответы будут содержать одно и то же значение заголовка ETag. Таким образом, при сохранении исходной конфигурации максимальная скорость потока не может превышать 1бит/с, как и в случае с потоком по Last-Modified. Однако, в отличие от Last-Modified, ETag хранит время в формате mtime, точность которого составляет 1 мкс. Следовательно, теоретическая пропускная способность потока равна приблизительно 976 кбит/с, что намного превышает пропускную способность, достижимую на практике.
Чтобы максимально эффективно использовать пропускную способность данных потоков, необходимо, чтобы значение заголовка обновлялось при каждом изменении сущности. Для этого возможно изменить конфигурацию веб-сервера S2 или изменить тип сущности O2 со статической (html) страницы на динамическую (php). PHP позволяет вручную задавать значения и вид заголовков HTTP-ответа для отдельной страницы; соответственно возможно генерировать неотличимое от настоящего значение ETag (используя тот же алгоритм формирования), но делать это для каждого HTTP-запроса. Таким образом, максимальная скорость для данных потоков равна 1 бит в (2L + T) секунд, где L — время, затрачиваемое на передачу сообщения между S2 и S3, и T — время, необходимое Si и S3 для вычислительных операций: сравнения значений заголовков, чтения и записи битов и т. п. Реализации данных потоков при тестировании на скорости 2 бит/с показали 99,56% точности передачи.
ЛИТЕРАТУРА
1. CWE-385: Covert Timing Channel. https://cwe.mitre.org/data/definitions/385.html
2. Brown E., Yuan B., Johnson D., and Lutz P. Covert channels in the HTTP Network Protocol:
Channel characterization and detecting Man-in-the-Middle Attacks // Proc. 5th Intern.
Conf. Information Warfare and Security. Ohio, USA, April 8-9, 2010. Air Force Institute of
Technology, 2010. P. 56-65.
3. ETag header Apache specification. http://httpd.apache.org/docs/2.2/mod/core.html#
fileetag