Использование веб-приложений в Интернет иногда похоже на игру в русскую рулетку. Несмотря на то, что достижение полной безопасности в Сети теоретически возможно, в реальной жизни, как всегда, все несколько сложнее. Необходима всего лишь единственная ошибка в коде, чтобы злоумышленник получил неограниченный доступ к Вашим данным. Если Вы используете веб-приложение со сложной функциональностью, то есть большая вероятность, что у него есть проблемы с обеспечением безопасности. Например, возьмем этот URL:

В предыдущей статье мы рассмотрели (и использовали) следующие ошибки при обработке HTTP запросов:

Этот документ подводит итог нашей работы по недавно появившейся технике атаки - HTTP Request Smuggling. В нем мы опишем эту технику и объясним, в каких случаях она может применяться и какой может нанести вред.

Данный документ предполагает знание читателем основ HTTP. Тем, кто плохо знаком с HTTP, рекомендуем ознакомиться с RFC HTTP/1.1 [4]

В этом документе мы опишем новый вид веб-атаки - “HTTP Request Smuggling”. Данный вид атаки, а также все производные виды направлены на веб-устройства и становятся результатом того, что HTTP сервер или другое устройство начинают некорректно работать, пытаясь обработать специально сформированные HTTP запросы.

Архитектура фильтров сервера Apache 2.0 стала главной особенностью, которая отличает этот сервер от других веб-серверов, в том числе и от Apache 1.x. Эта архитектура сделала сервер уникальной по своей мощи и гибкости платформой для приложений. Но эта мощь имеет свою цену - сперва необходимо научиться работать с ней. При изучении архитектуры наибольшее затруднение вызывает работа с контейнерами (Buckets) и бригадами (Brigades) - строительными блоками фильтров.

В этой статье мы расскажем о контейнерах и бригадах в объеме достаточном для того, чтобы Вы смогли начать работать с ними. Также мы разработаем простой, но функциональный модуль-фильтр, который будет работать напрямую с контейнерами и бригадами.

Большинство модулей от администраторов и пользователей требуют некоторой настройки. Системные администраторы конфигурируют Apache, используя httpd.conf, а пользователи (авторы) используют файлы .htaccess. Модулями можно управлять с помощью директив конфигурации, которые также задаются в этих файлах.

В этой статье мы покажем, как в модуле использовать директивы конфигурации, а также как работать с директивами других модулей.

Обработка НТТР запросов является основной задачей для большинства сетевых программ. В этой статье мы расскажем об обработке запросов в Apache и о том, как модули могут принять в ней посильное участие. Статья должна помочь разработчикам в освоении работы с модулями Apache и дать Вам необходимые знания для лучшей работы с API и кодом Apache.

APR пулы (pools) - это основные строительные блоки в APR и Apache, а также основа для всего управления ресурсами. Они служат для выделения памяти, либо напрямую (на malloc- подобный манер), либо косвенно (как, например, в операциях со строками), и гарантируют полное освобождение памяти после использования. Также они используются для выделения памяти для таких ресурсов как, например, файлы или сокеты. Кроме того, пулы APR могут работать с ресурсами, управляемыми сторонними библиотеками.

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

В предыдущих статьях я рассказал о некоторых новых возможностях Apache 2.0 и о том, как Вы можете реализовать их в своих серверах. В этот раз я расскажу об одной мало обсуждаемой особенности Apache 2.0.

Одним из самых больших достоинств сервера Apache над другими HTTP серверами является то, с какой легкостью для него пишутся мощные модули. Apache, начиная с версии 1.0, использует модули для реализации всех своих функций, кроме отправки статических документов. Так как функциональность Apache полностью реализована в модулях, следовательно, модули имеют доступ к любому этапу обработки запроса. Однако, несмотря на все достоинства модулей, у них есть один большой недостаток.

В предыдущих двух статьях мы обсуждали написание выходных фильтров для Apache 2.0. В этой статье мы рассмотрим входные фильтры. Эти два типа фильтров очень похожи и многие концепции, которые мы уже рассмотрели для выходных фильтров, верны также и для входных фильтров. Тем не менее, существует достаточное количество отличий входных фильтров от выходных, вот им мы и посвятим эту статью.

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

В прошлой статье мы рассмотрели основные принципы фильтров сервера Apache 2.0, но этой информации недостаточно для написания полноценного фильтра. В этой статье, мы завершим обсуждения выходных фильтров сервера. После прочтения данной статьи Вы сможете написать свой собственный фильтр для Apache.

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