HTTP — заголовки


Содержание

Онлайн проверка HTTP заголовков страниц сайта

Консольная команда для вывода заголовков:
curl -I http://i-leon.ru

Список кодов ответа сервера

Код состояния HTTP (англ. HTTP status code) — код состояния является частью первой строки ответа сервера. Он представляет из себя целое число из 3 арабских цифр. Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа. Пример:

403 Access allowed only for registered users

Клиент узнаёт по коду ответа о результатах его запроса и определяет, какие действия ему предпринимать дальше. Набор кодов состояния является стандартом, и все они описаны в соответствующих документах RFC. Введение новых кодов должно производится только после согласования с IETF. Клиент может не знать все коды состояния, но он обязан отреагировать в соответствии с классом кода.

В настоящее время выделено пять классов кодов состояния:

  • 1xx: Informational (русск. Информационный) — запрос получен и понят, а обработка продолжается.
  • 2xx: Success (русск. Успешно) — запрос был успешно получен, понят и обработан.
  • 3xx: Redirection (русск. Перенаправление) — для выполнения запроса должны быть предприняты дальнейшие действия.
  • 4xx: Client Error (русск. Ошибка клиента) — запрос имеет плохой синтаксис или не может быть выполнен.
  • 5xx: Server Error (русск. Ошибка сервера) — сервер не в состоянии выполнить допустимый запрос.

Ниже, представлены коды ответа из реестра кодов состояния IANA.

В этот класс выделены коды, информирующие о процессе передачи. В HTTP/1.0 сообщения с такими кодами должны игнорироваться. В HTTP/1.1 клиент должен быть готов принять этот класс сообщений как обычный ответ, но ничего серверу отправлять не нужно. Сами сообщения от сервера содержат только стартовую строку ответа и, если требуется, несколько специфичных для ответа полей заголовка. Прокси-сервера подобные сообщения должны отправлять дальше от сервера к клиенту.

100 Continue
(русск. Продолжать)
Сервер удовлетворён начальными сведениями о запросе. Клиент может продолжать пересылать заголовки.

101 Switching Protocols
(русск. Переключение протоколов)
Сервер предлагает перейти на более подходящий для указанного ресурса протокол. Список предлагаемых протоколов сервер обязательно указывает в поле заголовка Update. Если клиента это заинтересует, то он посылает новый запрос с указанием другого протокола.

102 Processing
(русск. Идёт обработка)
Запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме.

Сообщения данного класса информируют о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса сервер может ещё передать заголовки и тело сообщения.

200 OK
(русск. Хорошо)
Успешный запрос. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения.

201 Created
(русск. Создано)
В результате успешного выполнения запроса был создан новый ресурс. Сервер должен указать его местоположение в заголовке Location. Серверу рекомендуется ещё указывать в заголовке характеристики созданного ресурса (например, в поле Content-Type). Если сервер не уверен, что ресурс действительно будет существовать к моменту получения данного сообщения клиентом, то лучше использовать ответ 202.

202 Accepted
(русск. Принято)
Запрос был принят на обработку, но обработка не завершена. Клиенту не обязательно дожидаться окончательной передачи сообщения, так как может быть начат очень долгий процесс.

203 Non-Authoritative Information
(русск. Неавторитетная информация)
Аналогично ответу 200, но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной.

204 No Content
(русск. Нет содержимого)
Сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные.

205 Reset Content
(русск. Сбросить содержимое)
Сервер обязывает клиента спросить введённые пользователем данные. Тела сообщения сервер при этом не передаёт и документ обновлять не обязательно.

206 Partial Content
(русск. Частичное содержимое)
Сервер удачно выполнил запрос клиента, но передал только часть документа. Такой ответ сервер может отправить если в заголовке запроса клиента есть поле Content-Range. Особое внимание при работе с подобными ответами следует уделить кэшированию.

207 Multi-Status
(русск. Многостатусный)
Сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с единственным объектом multistatus. Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности.

226 IM Used
(русск. IM использовано)
Заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров.

Коды статуса класса 3xx сообщают клиенту что для успешного выполнения операции нужно произвести следующий запрос к другому URI. В большинстве случаев новый адрес указывается в поле Location заголовка. Клиент в этом случае должен, как правило, произвести автоматический переход (жарг. редирект).

Обратите внимание, что при обращении к следующему ресурсу можно получить ответ из этого же класса кодов. Может получиться даже длинная цепочка из перенаправлений, которые, если будут производится автоматически, создадут чрезмерную нагрузку на оборудование. Поэтому разработчики протокола HTTP настоятельно рекомендуют после второго подряд подобного ответа обязательно запрашивать подтверждение на перенаправление у пользователя (раньше рекомендовалось после 5-го). За этим следить обязан клиент, так как текущий сервер может перенаправить клиента на ресурс другого сервера. Клиент также должен предотвратить попадание в круговые перенаправления.

300 Multiple Choices
(русск. Несколько выборов)
По указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту или пользователю.

301 Moved Permanently
(русск. Перемещёно окончательно)
Запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. При запросах не методом HEAD сервер должен передать в теле сообщения гипертекстовое пояснение. При использовании всех методов, кроме GET и POST, предварительно следует уведомить пользователя об изменении ссылки. Не стоить забывать, что некоторые агенты ошибочно меняют метод POST на GET после перехода на другой адрес.

302 Found
(русск. Найдено)
Запрошенный документ был временно перенесен на другой URI, указанный в заголовке в поле Location. При всех методах кроме HEAD сервер должен передать в теле гипертекстовое пояснение. При использовании всех отличных от GET и POST методов предварительно следует уведомить пользователя об изменении URI. При обращении к следующему ресурсу метод POST на GET менять следует как это делают некоторые агенты.

303 See Other
(русск. Смотреть другое)
Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET не смотря даже на то, что первый запрашивался методом POST. Если используется не метод HEAD, то серверу следует включить в тело сообщения короткое гипертекстовое описание.

304 Not Modified
(русск. Не изменено)
Сервер возвращает такой код, если клиент запросил документ методом GET, в заголовке использовал поле Date и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела.

305 Use Proxy
(русск. Использовать прокси)
Запрос к запрашиваемому ресурсе должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка. Данный код ответа могут использовать только родные HTTP-сервера (не прокси).

306 (Reserved)
(русск. Зарезервировано)
Использовалось раньше. В настоящий момент зарезервировано.

307 Temporary Redirect
(русск. Временное перенаправление)
Запрашиваемый ресурс короткое время доступен только по другому URI (указывается в поле Location заголовка). Если был послан не метод HEAD, то серверу следует включить в тело сообщения короткое гипертекстовое описание. При использовании всех методов кроме GET и POST предварительно следует уведомить пользователя о временном изменении ссылки.

4xx: Client Error

Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.

400 Bad Request
(русск. Плохой запрос)
Запрос не понят сервером из-за наличия синтаксической ошибки. Клиенту следует повторно обратиться к ресурсу с изменённым запросом.

401 Unauthorized
(русск. Неавторизован)
Запрос требует идентификации пользователя. Клиент должен запросить имя и пароль у пользователя и передать их в записи WWW-Authenticate заголовка в следующем запросе. В случае ввода ошибочных данных сервер снова вернёт этот же статус.

402 Payment Required
(русск. Необходима оплата (зарезервировано))
Предполагается использовать в будущем. В настоящий момент не используется.

403 Forbidden
(русск. Запрещено)
Сервер понял запрос, но он отказывается его выполнять из-за каких-то ограничений в доступе. Идентификация через протокол HTTP здесь не поможет. Скорее всего, на сервере нужно провести аутентификацию другим способом, сделать запрос с определёнными параметрами или удовлетворить каким-либо условиям.

404 Not Found
(русск. Не найдено)
Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код 410 вместо этого. Этот код может использоваться вместо 403, если требуется тщательно скрыть от посторонних глаз определённые ресурсы.

405 Method Not Allowed
(русск. Метод не поддерживается)
Указанный клиентом метод нельзя применить к ресурсу. Сервер также должен передать в заголовке ответа поле Allow со списком доступных методов.

406 Not Acceptable
(русск. Не приемлемо)
Запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса.

407 Proxy Authentication Required
(русск. Необходима авторизация прокси)
Ответ аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на обычном сервере.

408 Request Timeout
(русск. Время ожидания истекло)
Время ожидания сервером передачи от клиента истекло. Клиент может повторить аналогичный предыдущему запрос в любое время.

409 Conflict
(русск. Конфликт)
Запрос не может выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT.

410 Gone
(русск. Удалён)
Такой ответ сервер посылает, когда ресурс раньше был по указанному URI, но был удалён и теперь недоступен. Серверу в этом случае не известно и местоположение альтернативного документа (например, копии). Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404.

411 Length Required
(русск. Необходима длина)
Для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI.

412 Precondition Failed
(русск. Условие «ложно»)
Возвращается, если ни одно из условных полей заголовка запроса не было выполнено.

413 Request Entity Too Large
(русск. Запрашиваемые данные слишком большие)
Возвращается если сервер по каким-то причинам не может передать запрашиваемый объём информации. Если проблема временная, то сервер может в ответе указать в поле Retry-After время, по истечении которого можно повторить аналогичный запрос.

414 Request-URI Too Long
(русск. Запрашиваемый URI слишком длинный)
Сервер не может обработать запрос из-за слишком длинного указанного URI. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST.

415 Unsupported Media Type
(русск. Неподдерживаемый тип данных)
По каким-то причинам сервер отказывается работать с указанным типом данных при данном методе.

416 Requested Range Not Satisfiable
(русск. Запрашиваемый диапазон не достижим)
В поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges.

417 Expectation Failed
(русск. Ожидаемое ошибочно)
По каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса.

422 Unprocessable Entity
(русск. Необрабатываемый экзмепляр)
Сервер успешно принял запрос, может работать с указанным видом данных, в теле запроса XML-документ имеет верный синтаксис, но имеется какая-то логическая ошибка из-за которой невозможно произвести операцию над ресурсом.

423 Locked
(русск. Заблокировано)
Целевой ресурс из запроса заблокирован от применения к нему указанного метода.

424 Failed Dependency
(русск. Невыполненная зависимость)
Реализация текущего запроса может зависеть от успешности выполнения другой операции. Если она не выполнена и из-за этого нельзя выполнить текущий запрос, то сервер вернёт код 424.

426 Upgrade Required
(русск. Необходимо обновление)
Сервер указывает клиенту на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection.

5xx: Server Error

Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.

500 Internal Server Error
(русск. Внутренняя ошибка сервера)
Любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса 5xx.

501 Not Implemented
(русск. Не выполнимо)
Сервер не поддерживает возможностей, необходимых для обработки запроса. Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод.


502 Bad Gateway
(русск. Плохой шлюз)
Сервер в роли шлюза или прокси получил сообщение о неудачном выполнении промежуточной операции.

503 Service Unavailable
(русск. Сервис недоступен)
Сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). В поле Retry-After заголовка сервер может указать время, через которое клиенту рекомендуется повторить запрос. Хотя во время перегрузки очевидным является сразу разрывать соединение, эффективней может оказаться установка большого значения поля Retry-After для уменьшения частоты избыточных запросов.

504 Gateway Timeout
(русск. Шлюз не отвечает)
Сервер в роли шлюза или прокси не дождался ответа от вышестоящего сервера для завершения текущего запроса.

505 HTTP Version Not Supported
(русск. Версия HTTP не поддерживается)
Сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP.

506 Variant Also Negotiates (Experimental)
(русск. Вариант тоже согласован (экспериметальное))
В результате ошибочной конфигурации выбранный вариант указывает сам на себя из-за чего процесс связывания прерывается.

507 Insufficient Storage
(русск. Закончилось место)
Не хватает места для выполнения текущего запроса. Проблема может быть временной.

510 Not Extended
(русск. Не расширено)
На сервере отсутствует расширение, которое планирует использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях.

АйТи бубен

Инструменты пользователя

Инструменты сайта

Содержание

HTTP (HyperText Transfer Protocol — «протокол передачи гипертекста») — протокол прикладного уровня передачи данных (изначально — в виде гипертекстовых документов). Основой HTTP является технология «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом.

Илон Маск рекомендует:  Что такое код cpdf_clip

HTTP используется также в качестве «транспорта» для других протоколов прикладного уровня, таких как SOAP, XML-RPC, WebDAV.

Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (Uniform Resource Identifier) в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т. д. Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.

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

HTTP не сохраняет информацию по транзакциям, поэтому в следующей транзакции приходится начинать все заново. Преимущество состоит в том, что HTTP сервер может обслужить в заданный промежуток времени гораздо больше клиентов, ибо устраняются дополнительные расходы на отслеживание сеансов от одного соединения к другому. Есть и недостаток: для сохранения информации по транзакциям более сложные CGI- программы должны пользоваться скрытыми полями ввода или внешними средствами, например Cookie.

Методы HTTP запроса

Метод HTTP — последовательность из любых символов, кроме управляющих и разделителей, указывающая на основную операцию над ресурсом. Обычно метод представляет собой короткое английское слово, записанное заглавными буквами. Обратите внимание, что название метода чувствительно к регистру.

Каждый сервер обязан поддерживать как минимум методы GET и HEAD. Если сервер не распознал указанный клиентом метод, то он должен вернуть статус 501 (Not Implemented). Если серверу метод известен, но он не применим к конкретному ресурсу, то возвращается сообщение с кодом 405 (Method Not Allowed). В обоих случаях серверу следует включить в сообщение ответа заголовок Allow со списком поддерживаемых методов.

Кроме методов GET и HEAD, часто применяется метод POST.

Заголовки (параметры) HTTP запроса, ответа, сущности

Все заголовки в протоколе HTTP разделяются на четыре основных группы (в нижеприведенном порядке рекомендуется посылать заголовки получателю):

Все необходимые для функционирования HTTP заголовки описаны в основных RFC. При необходимости можно создавать свои заголовки. Традиционно к именам таких дополнительных заголовков добавляют префикс «X-» для избежания конфликта имён с возможно существующими.

Строки после главной строки запроса (GET /index.html HTTP/1.1) имеют следующий формат: Параметр: значение. Таким образом задаются параметры запроса. Это является необязательным, все строки после главной строки запроса могут отсутствовать; в этом случае сервер принимает их значение по умолчанию или по результатам предыдущего запроса (при работе в режиме Connection: Keep-Alive).

Формат ответа также имеет заголовок и тело, разделенное пустой строкой.

HTTP-заголовки: описание, параметры, особенности и рекомендации

Современный интернет строится на общении между клиентом (браузером) и сервером. Чтобы они могли обмениваться информацией между собой, были разработаны специальные протоколы. Одним из таких является HTTP, и благодаря ему пользователи могут работать через браузер и просматривать HTML-страницы.

Что такое HTTP-заголовки

HTTP – это способ обмена HTML-страницами между двумя компьютерами. Протокол был изобретен в 1990 году и в настоящее время является основным методом отображения страниц с гипертексом.

HTTP-заголовки – это строки, которыми общаются компьютеры. Это напоминает диалог между людьми. Браузер при открытии сайта генерирует запрос, в нем указывается необходимая информация о себе (язык, страна, ссылка на ресурс, версия ядра и т. п.). Вся эта информация пересылается на сервер, а там стоит определенная программа (Apache, Nginx, LiteSpeed и т. п.). Она читает полученные строки и в зависимости от вопроса генерирует ответ.

Например, человек решил открыть google.com, он вводит ссылку в поисковую строку и браузер генерирует запрос. HTTP-заголовок браузера условно выглядит так:

Использую Google Chrome

Мне нужен HTML-код

У меня есть информация о пользователе

Сервер обрабатывает данные и формирует ответ:

Все хорошо, страница найдена и работает

Я работаю на базе Apache

Страница изменялась 27.05.2020

Получай код страницы

Это новая информация от пользователя (логин, пароль)

В теле сообщения передается HTML-код страницы.

Особенности HTTPS

Сейчас большинство сайтов переходит с HTTP- на HTTPS-соединение. Отличием последнего является дополнительное шифрование всей передаваемой информации. Перед началом обмена клиент требует SSL-сертификат для провверки подлинности сервера. Для разработчика ничего не изменяются, и он может продолжать работать без изменений своего кода.

Клиент после получения сертификата проверяет его на подлинность (сравнивается сертификат от сервера и сертификат от центра). Если все хорошо, то запускается HTTP-протокол. После подтверждения сертификата заголовки шифруются через RSA. Теперь злоумышленник не сможет украсть важную информацию пользователя (логин, пароль и т. п.).

Просмотр HTTP-диалога

HTTP-диалог можно просмотреть самостоятельно. В качестве фраз используются специальные сокращения – Date, Cookie, Host, Server и т. п. Просмотреть HTTPзаголовки можно при помощи расширений для браузера. Также помогут в этом онлайн-сервисы.

Для просмотра HTTP-заголовков из плагинов используют:

  • Firebug.
  • Live HTTP Headers.
  • HTTP headers.

Из онлайн-сервисов используйте:

Они перехватывают получаемые от сервера заголовки и отображают их в отдельном окне. Причем с одной страницы можно получить сразу по 100–200 заголовков, и они могут периодически отправляться спустя какое-то время. Например, для проверки online в соцсетях.

HTTP-заголовки можно разделить на четыре типа:

  • общие (General headers) – применяются в запросе и ответе;
  • для запроса (Request headers) – для запроса;
  • для ответа (Response headers) – для ответов;
  • информация о сущности (Entity headers) – запросы и ответы.

Стартовая строка от клиента

Чтобы начать обмен информацией, сначала формируется главная строка. Клиент в ней говорит, какой файл или объект ему необходим. Для этого применяются определенные способы обращения к протоколу. Структура стартовой строки состоит из трех частей:

После этого обязательно идет строка Host и указывается URL-адрес сайта. Существуют разные методы запроса. Программисты чаще всего используют:

  • GET – запрос к информации (ответ пересылается сервером в ссылке).
  • POST – отправка информации на сервер скрытым способом (ответ не виден в адресной строке).
  • HEAD – такой же, как GET, но сервер вернет только заголовок.
  • PUT – передача крупных запросов на URL;

После отправки стартовой строки следуют все остальные заголовки – User Agent, Cookie и т. п. Без первичного обращения невозможно начать обмен информацией по HTTP. Заголовки же являются лишь дополнением и в протоколе 1.0 и вовсе могут не передаваться.

Передача информации от клиента

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


Обязательными (передаются всегда) заголовками HTTP-запроса являются Host, Referer, User Agent и Accept.

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

HTTP-заголовки сервера – ответ на запросы страницы

После получения запросов от клиента, страница передает определенные строки серверу. В php для передачи HTTPзаголовка используется функция header(). Например, можно сообщить о новом местоположении страницы:

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

Главным образом эти запросы нужны для правильного отображения страницы в браузере. Они используются для улучшения скорости загрузки страниц.

Заголовки сущности

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

Самым популярным заголовком сущности является Last-Modified. Этот запрос может посылаться как от браузера к серверу, так и наоборот. Через этот заголовок клиент узнает, нужно ли ему обновить свой кэш. Пример диалога:

Клиент: «У меня кэш от 16.05.2020, изменялась ли страница на сервере?»

Сервер: «Да, кэш изменялся 19.03.2020, вот новая версия.»

Ответ сервера

После получения стартовой строки от клиента сервер формирует свой ответ.

Если статус соединения подтвержден, то сервер может отдать клиенту запрашиваемую информацию.

Пример http-диалога можно увидеть на картинке ниже.

Запросы формирует программист на странице при помощи функции header().

Коды статусов

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

Передавать статус можно со страницы как начальный заголовок, например header(«http/1.1 200 Ok»).

Кэшированные страницы

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

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

Чтобы проверить сжатую информацию на актуальность, указывается в заголовках HTTP срок действия. Клиент отправляет информацию о том, какие файлы локально хранятся у него, а сервер указывает свою версию. Если они совпадают, то браузер просто отображает свою версию кэша.

Для SEO-оптимизации обязательно надо указывать дату в заголовках HTTP. Для этих целей используются Last-Modified. Кроме того, кэш можно обновлять спустя какое-то время хранения. Для этого используется Expires. Для настройки кэширования используется Cache-Control, благодаря ему можно разрешить или запретить сохранять информацию со страницы.

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

Некоторые советуют передавать в заголовке Last-Modified текущую дату, надеясь на то, что робот из-за этого будет постоянно держать их статью в верху выдачи поиска. Но получается, что алгоритму приходится каждый раз изменять информацию о кэше внутри себя и переиндексировать ее вновь. Это не всегда приводит к хорошим результатам и иногда может только ухудшить позиции статьи.

Об URL-ссылке в браузерной строке

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

  • протокол;
  • интересуемый объект и его адрес;
  • порт для обращения;
  • HTTP-строки (при отправке методом GET);
  • query-код.

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

Недостатком URL является отсутствие поддержки других алфавитов – используется в основном латиница. Из-за этого нужно правильно продумывать сокращенное название статьи перед публикацией. Ведь поисковик по ссылке оценивает полезность ресурса и информацию, которую может предоставить страница для пользователя. Поэтому при SEO-оптимизации следует отдельное внимание уделить формированию правильных URL для статьи.

Что такое HTTP заголовки

HTTP заголовки — это часть HTTP сообщения, в которой содержатся различные параметры, которые используются для правильного построения web-страницы. HTTP заголовки несут в себе данные информативного характера, например, длина содержимого, кодировка, куки и т. д, или данные об установке каких-либо параметров, например, установить куки, либо установить кодировку. Различают несколько типов HTTP заголовков:

1. Общие HTTP заголов ки (GH) — могут встречаться как в HTTP заголовках запроса, так и в HTTP заголовках ответа.

2. HTTP заголовки запроса (RqH) — используются только в запросах клиента.

3. HTTP заголовки ответа (RsH) — встречаются только в ответах от сервера.

HTTP — заголовки

Название параметра должно состоять минимум из одного печатного символа (ASCII-коды от 33 до 126). Регистр символов в названиях не имеет значения. Заголовки с неизвестными именами должны игнорироваться. После названия сразу должен следовать символ двоеточия.

Значение может содержать любые символы ASCII кроме перевода строки (код 10) и возврата каретки (код 13). Пробельные символы в начале и конце значения обрезаются. Последовательность нескольких пробельных символов внутри значения может восприниматься как один пробел. Регистр символов также не имеет значения (если иное не предусмотрено форматом поля).

Предусматривается размещение значения на нескольких строках (перенос строки). Для указания переноса в начале следующей строки должен находиться хотя бы один пробельный символ.

Заголовки с одинаковыми названиями параметров, но разными значениями могут объединяться в один только если значение поля представляет из себя разделённый запятыми список. Во всех остальных случаях значения более дальних заголовков должны перекрывать предыдущие. Поэтому прокси-сервера не должны менять порядок следования заголовков в сообщении. При этом порядок элементов списка обычно значения не имеет.

Пример с многострочными значениями и одинаковыми именами заголовков (обратите внимание на регистр символов и пробелы):

Правильный компактный вариант преобразования и интерпретации:

В этом случае не допустимо принимать значение Content-Length равное 356. При объединении значений Allow чтобы не потерять семантический смысл была добавлена запятая в конец первого поля и убран бессмысленно дублирующийся элемент «GET».

Применяемые в заголовках структуры

Дата и время

Только дата указывается в заголовках Date, Expires, Last-Modified, If-Modified-Since, If-Unmodified-Since. Дата может присутствовать в заголовках If-Range и Warning.

В HTTP исторически используется три формата:

  • Fri, 04 Jul 2008 08:42:36 GMT — RFC 822.
  • Friday, 04-Jul-08 08:42:36 GMT — RFC 850.
  • Fri Jul 4 08:42:36 2008 — результат функции asctime() языка ANSI C.

Сейчас рекомендуется использовать только первый формат по RFC 822, но для совместимости клиентам и серверам лучше поддерживать и другие.

Время всегда указывается для часового пояса GMT (UTC+0). Год записывается четырьмя цифрами. День, час, минута и секунда дополняются нулями до двух символов. Для месяца и названия недели применяются трёхбуквенные стандартные сокращения на английском языке.

В PHP для преобразования местного времени во время по Гринвичу используется функция gmdate(). Примеры формирования дат для заголовков HTTP:

Байтовые диапазоны

При работе с фрагментами содержимого в специальных заголовках используются байтовые диапазоны (англ. byte ranges ). В них можно указать как один фрагмент, так и несколько разделяя их запятыми «,». Диапазоны применяются в заголовках Range и Content-Range. В заголовке Accept-Ranges перечисляются только единицы измерения.

В байтовых диапазонах обязательно в начале указываются название единиц измерения за которым следует символ «=». В настоящий момент кроме единиц bytes никакие другие не применяются. За символом «=» располагаются сами диапазоны. Каждый из них является разделённой дефисом «-» парой натуральных чисел или нуля. Первый элемент указывает начальный байт, а второй — конечный. Нумерация в диапазонах начинается с нуля.

Начальный или конечный байт может быть не указан. При отсутствии последнего байта считается что речь идёт о фрагменте от начального байта до конца содержимого. Если отсутствует начало, то номер конечного байта воспринимается как количество запрашиваемых байт от конца содержимого.

Если первый байт больше чем последний, то диапазон считается синтаксически недействительным (англ. syntactically invalid ). Поля заголовка, содержащие диапазоны с синтаксически недействительными значениями, игнорируются. Если первый байт выходит за пределы объёма ресурса, то диапазон игнорируется. Если последний байт выходит за пределы содержимого, то диапазон обрезается до конца.

Илон Маск рекомендует:  mix-blend-mode в CSS

Блок байтовых диапазонов считается выполнимым если в нём содержится хотя бы один доступный диапазон. Если же все диапазоны некорректны или выходят за пределы объёма ресурса, то серверу следует вернуть сообщение со статусом 416 (Requested range not satisfiable).

Примеры (весь объём ресурса — 5000 байт):

  • bytes=0-255 — фрагмент от 0-го до 255-го байта включительно.
  • bytes=42-42 — запрос одного 42-ого байта.
  • bytes=4000-7499,1000-2999 — два фрагмента. Так как первый выходит за пределы, то он интерпретируется как «4000-4999».
  • bytes=3000-,6000-8055 — первый интерпретируется как «3000-4999», а второй игнорируется.
  • bytes=-400,-9000 — последние 400 байт (от 4600 до 4999), а второй подгоняется под рамки содержимого (от 0 до 4999) обозначая как фрагмент весь объём.
  • bytes=500-799,600-1023,800-849 — при пересечениях диапазоны могут объединяться в один (от 500 до 1023).


Работа с заголовками

Заголовки в HTML

Язык разметки HTML позволяет задавать необходимые значения заголовков HTTP внутри с помощью тега . При этом название заголовка указывается в атрибуте http-equiv, а значение — в content. Почти всегда выставляется значение заголовка Content-Type с указанием кодировки, чтобы избежать проблем с отображением текста браузером. Также не лишним является указание значения заголовка Content-Language:

Проверка кода ответа сервера и http заголовков

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

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

Что такое код ответа сервера?

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

1xx — информационные:

  • 100 — сервер принял первую часть запроса, можно подрожать передачу;
  • 101 — нужно изменить протокол работы на более подходящий;
  • 102 — на обработку запроса уйдет много времени, используется чтобы браузер не разрывал соединение раньше времени;

2хх — операция успешна:

  • 200 — запрос выполнен успешно, отправляется для большинства запрашиваемых страниц;
  • 201 — после выполнения запроса был создан ресурс;
  • 202 — запрос принят, но еще не обработан;
  • 203 — запрос выполнен успешно, но информация для ответа взята из прокси;
  • 204 — запрос обработан, но контента для отображения нет;
  • 205 — попросить пользователя ввести необходимые данные;
  • 206 — запрос обработан, но передана только часть контента;

3xx — перенаправления:

  • 300 — есть несколько страниц для этого запроса, например, на нескольких языках;
  • 301 — страница навсегда перемещена по новому адресу;
  • 302 — документ был временно перемещен;
  • 303 — документ необходимо загрузить по указанному адресу с помощью протокола GET;
  • 304 — документ не изменился с последнего запроса;
  • 305 — нужно использовать прокси;
  • 307 — ресурс временно перемещен на новый адрес.

4хх — ошибка в запросе:

  • 400 — неверный запрос;
  • 401 — необходимо аутентифицироваться;
  • 403 — запрос принят, но у вас нет доступа;
  • 404 — страница не найдена на сервере;
  • 405 — используемый метод нельзя применять на сервере;
  • 408 — время ожидания передачи запроса истекло;
  • 410 — ресурс полностью удален;
  • 411 — нужно указать длину запроса;
  • 413 — запрос слишком длинный;
  • 414 — URI запроса слишком длинная.

5хх — ошибка сервера:

  • 500 — внутренняя ошибка сервера;
  • 501 — нужная функция не поддерживается;
  • 502 — прокси не может соединиться со шлюзом;
  • 503 — сервер не может обрабатывать запросы по техническим причинам;
  • 504 — прокси не дождался ответа от сервера;
  • 505 — версия протокола HTTP не поддерживается.

Что такое http заголовки?

С помощью http заголовков клиент и сервер обмениваются информацией и командами между собой. Они используются для согласования метода, протокола, кодировки, языка и многих других параметров работы. Рассмотрим основные заголовки, которые будет отправлять сервер:

  • Server — имя и версия веб-сервера;
  • Date — дата осуществления запроса;
  • Content-Type — MIME тип передаваемых данных, например, text/html, тут же задается кодировка;
  • Connection — тип соединения, может быть closed — уже закрыто, или keep-alive — открыто для передачи данных;
  • Vary — указывает при каких заголовках веб-сервер будет возвращать разные старины для одного URI;
  • Set-Cookie — сохранить Cookie информацию для страницы;
  • Expires — можно хранить страницу или ресурс в кэше до определенной даты;
  • Cache-Control — настройка времени кэширования страницы браузером, а также разрешения на кэширования;
  • ETag — содержит контрольную сумму для страницы, применимо для проверки кэша;
  • Last-Modified — дата, когда страница последний раз была изменена;

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

Проверка кода ответа сервера с помощью cURL

Чтобы увидеть только код ответа страницы достаточно выполнить такую команду:

curl -s -o /dev/null -w «%» https://losst.ru

Или, если хотите, чтобы ответ выглядел более естественно:

curl -I https://losst.ru 2>/dev/null | head -n 1 | cut -d$’ ‘ -f2

Страницы вернули 200, все в порядке. Но отправляет ли сервер редирект для нужных нам страниц? Если ваш сайт работает на https, то все запросы http должны перекидываться на https, также для любого сайта, все запросы на www домен должны перенаправляться на основной, или наоборот. Запросы на ip сайта тоже в идеале должны отправляться на основной домен. Проверка http ответа:

curl -I http://losst.ru 2>/dev/null | head -n 1 | cut -d$’ ‘ -f2

curl -I https://www.losst.ru 2>/dev/null | head -n 1 | cut -d$’ ‘ -f2

Все работает так, как нужно. Но смотреть код ответа сервера вряд ли понадобиться, намного интереснее проверка http статусов.

Проверка http заголовков с помощью Curl

Для проверки заголовков мы тоже можем использовать утилиту curl. Чтобы вывести заголовки страницы запустите ее с опцией -I:

curl -I https://losst.ru

Здесь отображается код ответа сервера, а также принятые http заголовки. Из них мы можем сделать такие выводы:

  • Страница сгенерирована в nginx 1.10.2;
  • Это обычная html страница (text/html);
  • Размер страницы 102452 байт или 100 кб;
  • Страница последний раз изменялась 18:13:12 (last_modified) это очень важный параметр для поисковых систем;
  • Сервер будет выдавать разные версии страниц при изменении поля Accept-Encoding (Vary);
  • Страница может храниться в любом кэше (public) на протяжении часа (expires);

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

curl -I https://losst.ru/wp-content/uploads/2020/08/map-2.png

Мы можем видеть, что картинка будет храниться в кэше намного дольше (max-age) чем html страница.

Осталось проверить работают ли такие заголовки, как If-Modified-Since и If-None-Match. Первый позволяет выполнять проверку актуальности кэша по дате модификации, второй — по контрольной сумме поля ETag. Кэш очень важен, чтобы снизить нагрузку на ваш сервер. Если страница не изменилась, то сервер лишь сообщает что она не изменилась, отправляя код ответа 304, вместо передачи полного файла.

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

Проверка If-Modified-Since

Сначала запрашиваем нашу страницу для просмотра заголовков http, а затем копируем поле Last-Modified:

curl -I https://losst.ru

Теперь запрашиваем ее еще раз, но уже с заголовком If-Modified-Since: и ваша дата:

curl -I —header ‘If-Modified-Since: Mon, 26 Dec 2020 18:13:12 GMT’ https://losst.ru

В ответ вы должны получить не саму страницу, а только заголовок HTTP/1.1 304 Not Modified. Если так, значит проверка кода ответа сервера пройдена и все работает верно.

Проверка If-None-Match

Заголовок If-None-Match работает похожим образом, только здесь используется значение контрольной суммы кэша из поля ETag. Опять запросим нашу страницу и скопируем сумму:

curl -I https://losst.ru

Затем отправим полученную сумму с заголовком:

curl -I —header ‘If-None-Match: «58615db8-19034″‘ https://losst.ru

И снова мы должны получить ответ 304, страница не изменена.


Проверка сжатия

Сжатие позволяет уменьшить размер передаваемых данных, но в то же время создает дополнительную нагрузку на сервер. Чтобы проверить поддерживает ли сервер сжатие gzip нужно отправить в запросе заголовок Accept-Encoding с параметром gzip:

curl -I https://losst.ru —header ‘Accept-Encoding: gzip’

В ответе мы увидим поле Content-Encoding: gzip. Это будет означать, что сжатие используется.

Выводы

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

Такие разные заголовки! Изучаем HTTP-взаимодействие

Содержание статьи

Большинство из нас многократно слышали про способность сайтов узнавать информацию о посетителе (и всевозможные предупреждения по этому поводу), которую невозможно узнать из IP-адреса. Это такие «личные» данные, как операционная система, используемый браузер, язык системы. Кто же так жестоко палит нас? И как можно это использовать в своих благих намерениях? Об этом и многом другом ты узнаешь, прочитав статью до конца.

Для начала приведу немного теории о том, чем мы пользуемся довольно давно. HTTP (HyperText Transfer Protocol – «протокол передачи гипертекста») – клиент-серверный протокол передачи данных, который служит для получения информации с веб-сайтов. Был предложен создателем всея WWW Тимом Бернерсом-Ли. Структура его проста: тип сообщения, заголовки, тело сообщения. Существуют RFC, стандартизирующие HTTP (последняя версия – 1.1), согласно которым клиент должен посылать серверу заголовки, содержащие ту самую специфическую информацию о системе и браузере. Обычному пользователю это полезно: сайт в зависимости от клиента может выдать специфическую верстку (пример – google.com) или показать информацию на нужном языке. Однако для хакера раскрытие такой информации может быть вредно или даже опасно.

Представим ситуацию: некий Иван зашел на сайт, посмотрел на него и решил взломать. Загрузил проверенные соксы, поставил красивый дефейс и через несколько часов/дней сидел в участке. Ведь несложно сопоставить данные взломщика с данными остальных посетителей и найти настоящий IP (очень редко встретишь сайт без логирования). Да, некоторые факторы не учтены, однако, вариант возможный.

Техническая реализация

Итак, нам необходимо подделывать заголовки, которые браузер шлет серверу. Как кросс-браузерное решение я бы предложил старый быстрый Proxomitron. Изначально он предназначен для удаления рекламы и полного управления содержимым страницы, так что замечательно подходит для наших целей. Работает как HTTP-прокси. С первого взгляда интерфейс Proxomitron’а не очень дружелюбен, однако разобраться в нем – дело нехитрое. Если нужно использовать только подделку заголовков – слева убираем все галки кроме второй. Жмем на «Headers» и редактируем правила подмены: сразу после установки – в списке куча правил, добавить свое можно, нажав на кнопку New. Чтобы задействовать фильтр, нужна галка в поле «out». Обязательно прочитай русский хелп к программе – там отлично все расписано.

Я пользуюсь Mozilla Firefox и предпочитаю вместо внешних программ использовать плагины. Tamper Data позволяет перехватывать запросы и редактировать заголовки в реальном времени – незаменимая вещь при ручной проверке. Все просто: в окне плагина жмем «Запустить перехват» и вмешиваемся, когда необходимо. Имеются пресеты и богатые возможности по изменению значений заголовков.

Для постоянной же подмены заголовков лучше использовать плагин Modify Headers. Сразу после установки необходимо открыть настройки и поставить галку на «Always on», дабы подмена происходила всегда. Настройка элементарная – открыть главное окно плагина и добавить правил. Первое поле – выбор действия («Add» – добавить, «Modify» – изменить, «Filter» – исключить из запроса), второе – название заголовка, третье – значение; в четвертом поле можно оставить записку. Правила можно двигать, включать и выключать.

Вектор поиска

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

PHP-include не подходят, ибо файлы никогда не подключают в зависимости от заголовков. Хотя и есть возможные исключения, к примеру, инклуд файла в зависимости от языка. На практике не встречал.

Пассивные XSS основаны на том, что запрос будет делать непосредственно пользователь. Заставить жертву подменить заголовок едва ли удастся, именно поэтому этот тип нам не подходит. Единственная возможность использовать найденные подменой заголовков пассивные XSS – это если на страницу пишется Referer (ссылающаяся страница), да не простой, а дополнительно декодированный (избавленный от %xx). Тогда можно скриптом перенаправить жертву на себя с нужным параметром и после – на уязвимую страницу, так что параметр запишется в месте Referer’а. Сработает в идеальных условиях, на практике также не встречал.
Активные XSS подходят. Смысл в том, чтобы веб-приложение занесло в базу наш заголовок, а после показало администратору, естественно, не обработав.

SQL-инъекции подходят. Это самый простой тип, достаточно, как и обычно, подставлять кавычку.

PHP-исполнение кода очень редко встречается вообще, а с участием заголовков – еще реже. Однако бывает. Тут преимущество нашего метода в том, что GET и POST данным менее доверяют.

Итак, теперь необходимо составить строку, которая позволяла бы определить наличие уязвимости. Кавычка обязательна. Далее необходимо выйти из возможных тегов: простейший способ сделать это символами «>. И последнее – алерт, дабы не проспать. В итоге у меня вышло ‘»>. Ставить на обнаружение исполнения кода я не стал; если желаешь, добавь, например, чтобы вызвать ошибку и заметить уязвимость. Также можно добавить в конец обратный слеш (пытаясь экранировать закрывающую кавычку), бывают случаи с фильтрацией кавычек, бывают без нее. Считаешь, что строка слишком длинная и может обрезаться? Замени “document.cookie” на «1». Тут главное – приложить фантазию и создать свой идеальной вектор поиска уязвимостей.

Интересные заголовки

Расскажу о наиболее интересных заголовках, с которыми обязательно нужно поиграться при пентесте сайта.

User-Agent

Главный враг шпиона. Больше всех выдает информации о посетителе: браузер, его версию и язык, движок браузера, версию движка, операционную систему. Данные могут быть написаны как угодно, однако примерный формат есть:

Браузер/Версия (Платформа; Шифрование; Система, Язык[; Что-нибудь еще]) [Дополнения].

В качестве платформы чаще всего можно увидеть X11 или Windows, иногда туда прямиком помещают систему, убирая соответствующий заголовок после. «Шифрование» может принимать три значения: “N” (None) – отсутствует, “I” (International) – слабое шифрование ключом до 40 бит, “U” (USA) – сильное шифрование с ключом 128 бит. Сейчас все браузеры используют только сильное шифрование. После скобки добавляется различная информация вроде движка, плагинов, дополнений.

В качестве браузера для совместимости очень часто указывают Mozilla, а уже после информации дописывают реальное название. Это связано с тем, что издавна девелоперы должны были (или просто любили) делать сайты не в соответствии с принятыми стандартами Консорциума Всемирной паутины (World Wide Web Consortium, W3C), а под наиболее распространенные в данное время браузеры, что приводило к еще большему доминированию последних. И сейчас такая практика существует, однако с тем отличием, что популярным браузерам даны дополнительные возможности, связанные с использованием JavaScript’а (например, на распространенном форуме Invision Power Board, в ветке 2.3.x, посмотрите профиль участника с отфильтрованным заголовком и без). Поэтому советую в строку User-Agent’а в любом случае включать определение распространенного браузера.

Илон Маск рекомендует:  Что такое код asp processntcrifloggedon

Referer

Сообщает о странице, с которой пришел пользователь. Заголовок, сильно полезный веб-мастерам для отслеживания путей попадания на их сайты. Написание – ошибка от английского «Referrer» («перенаправляющий»). Большинство браузеров позволяет отключать передачу этого заголовка, однако при этом обычно возникают проблемы с файлообменниками и сайтами-архивами, которым очень жалко отдавать контент без показа рекламы, так что они позволяют скачивать только при наличии их сайта в реферере. Можно подменять ради просмотра отдельных элементов сайта – например, картинок – без загрузки страниц, где они размещены (при условии, что без подделки это сделать не удастся). При пентесте стоит учитывать, что часто в базу записывают URL не полностью, а лишь нужную его часть, поэтому стоит пробовать «http://evil», «http://example.com/evil» и т.д.

X-Forwarded-For

Нестандартный заголовок, используемый неанонимными прокси-серверами для передачи реального IP клиента. Мы не можем вставить кавычку в определяемый сервером IP, зато можем заставить его думать, что это – всего лишь прокси, а настоящий IP – вот он, в X-Forwarded-For. Конечно, далеко не все скрипты используют и полагаются на XFF, но этот заголовок принято хотя бы логировать. Нельзя забывать проверять веб-приложение на наивность (да-да, некоторые сайты, увидев этот заголовок, забывают про обычный IP и пользуются только тем, что передано в данном заголовке). Формат: X-Forwarded-For: client_ip, proxy1_ip, . proxyN_ip.

Accept-Language

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

Accept-Charset

Сообщает допустимые кодировки и их приоритет. Не самый интересный заголовок, но стоит обратить на него внимание, ибо он может выдать твою систему простым «windows-1251».

X-Requested-With

Нестандартный заголовок, сообщает средство запроса. Используется при запросах из JavaScript без перезагрузки страницы. Соответственно полезен для имитации AJAX (Asynchronous Javascript and XML) запросов, для этого необходимо установить его в значение «XMLHttpRequest».

Authorization

Если серверу необходима авторизация пользователя, он об этом прямо сообщает, а браузер предлагает ввести логин и пароль. Именно в заголовке Authorization они передаются в виде «Basic base64(user:pass)». Такую авторизацию намного удобней брутить, чем те, которые располагаются непосредственно на странице (POST).

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

Применение

Итак, практика. Я проводил исследование, в ходе которого некоторое время использовал «пассивное обнаружение уязвимостей». Суть в том, что достаточно однажды выставить замену заголовков, а после – лишь ловить алерты и исследовать бреши.

ЗаголовокЗначениеВключен
User-Agent Opera/10.60 Да
Referer Да
X-Forwarded-For Да
Accept-Language en,en-US;q=0.9 Нет
AuthorizationBasic MScyMzo0JzU2 Нет
X-Requested-WithXMLHttpRequest Нет
CookiePHPSESS >

С первыми тремя, думаю, понятно. Если в ладах с английским, включи на постоянную подмену Accept-Language, дабы принимали за англичанина. Authorization уместно включать только при проверке конкретного сайта, ибо рискуете не понять, если где-нибудь действительно понадобится авторизация. Про применение заголовков X-Requested-With и Cookie я уже писал, однако поясню последний. В PHP довольно удобно хранить данные в сессиях: собственно данные – на сервере, у клиента – только идентификатор в куке «PHPSESSID» (название можно менять, но делают это, естественно, редко). Так вот, иногда этот идентификатор может состоять только из символов a-z, A-Z, 0-9 и ‘-,’, и при передаче чего-то иного вызывается ошибка, раскрывающая абсолютный путь:

Warning: session_start() [function.session-start]: The session id contains illegal characters, valid characters are a-z, A-Z, 0-9 and ‘-,’ in /var/www/data/www/login.php on line 2

Первое, на что я наткнулся – это поплывшая разметка. Да, действительно на многих сайтах происходил выход из какого-нибудь тега (бесполезный), и дальше образовывалась каша. Если ты решишь провести собственно исследование – будь готов. Еще одно: если чувствуешь, что что-то идет не так (например, не дают скачать файл, не показывают картинку во всю ширину, не работает перенаправление), выключай подмену Referer’а.

Никто не знает и не узнает, сколько алертов выловили админы, сколько они их увидели у себя в логах, сколько осталось незамеченными. Однако один случай обнаружения интересной активной XSS есть точно – гугловский сервис FeedBurner, который умеет обрабатывать RSS-фиды и логировать трафик сайта. Но последнее делал он не слишком качественно – не фильтровался Referer. Подробнее об этой уязвимости читай на raz0r.name/vulnerabilities/aktivnaya-xss-na-feedburner/ (wp.me/pft5J-4a) (не удивляйся, увидев алерт из-за XFF :)).

Довольно весело было заходить на всякие сайты с DLE (DataLife Engine), ибо популярный модуль DLE Referer Module не дружил (и не дружит) с экранированием плохих символов. Для убедительности советую пройтись по сайтам продавцов ICQ UIN’ов и увидеть много MySQL-ошибок, хотя картина уже не будет слишком печальной – я разослал владельцам сообщения об уязвимости, ведь неприятно, когда твои платежные данные и ссылки на оплату можно подменить.

Некоторое время назад на php.ru можно было наблюдать ошибки нефильтрации Referer’а и XFF. На данный момент уязвимость закрыта. Из ошибки с реферером:

MySQL Error = You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘»‘)’ at line 1

SQL = INSERT INTO oops_sessions (ID,UID,START,LAST,IPS,PAGES,PAGE,DATA,REFFER) VALUES (‘dpdu7rh90ehfsc62′,’0′,1238958331,1238958331,’xxx.xxx.xxx.xxx’,1,’/’,’a:1:‘,’SQL-Inj’here’)

Еще один пример – cx75planet.ru. Уязвимы User-Agent и XFF. IPB показывает весь запрос. Кроме этих брешей, была замечена еще туча SQL-ошибок на сайтах всех мастей, большинство из которых просто имели самописные модули обработки информации о браузерах, рефах и т.д. Предоставляю тебе возможность найти их все :).

Подмена заголовков в PHP

Естественно, после ручного анализа SQL-уязвимости наступает работа автоматики. Подбор столбцов, полей, вынимание логинов, паролей и хешей – все уже давно делают скрипты. Однако большинство из них направлено на GET, POST или Cookie. Покажу, как можно получить страницу, посылая нужные заголовки. Предположим, у нас есть массив с такими заголовками и вызов функции request, которая должна возвращать страницу:

$headers = array (
‘User-Agent: Babytoy/0.5’,
‘Referer: http://refrefref.ref/omg.pl’
);
$html = request_socket(‘http://127.0.0.1/showmeheaders.php’, $headers);
echo $html;

Есть несколько основных видов получения страницы из PHP (полные версии функций ищи на диске ][):

Сокет

Заголовки напишешь в любом случае. Генерация пакета:

$packet = «GET <$url>HTTP/1.1rn»
. «Host: <$host>rn»
. implode(«rn», $headers) . «rn»
. «Connection: Closernrn»;
— file_get_contents()


Воспользуемся контекстом для задания нужных параметров:

$opts = array (
‘http’ => array (
‘header’ => implode(«rn», $headers) . «rn»
)
);
$context = stream_context_create($opts);
return file_get_contents($url, false, $context);

В curl’е все проще простого: вместе с остальными параметрами достаточно указать curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);

Заключение

Хотелось бы обратить внимание, что подмена заголовков – не панацея от сливания информации. Не стоит забывать о JavaScript’е, Flash’е и интерактивных элементах, которые тоже вправе много чего разболтать. Используй NoScript и прочие AdBlock’и. Всегда экспериментируй и прикладывай выдумку, ищи там, где не ищет никто. Удачи!

HTTP-заголовки

В заголовке содержится ответ на запрос клиента и сопроводительная информация к документу. Его главной частью является код статуса. Если документ по данному URL найден и готов к отправке, передается код «200 ОК», в остальные случаях — статусы, сообщающие о дополнительных условиях передачи или ошибке.

Взаимодействие с поисковым роботом

В процессе поисковой оптимизации обмен данными с роботами происходит по той же схеме, что и с браузером. Единственное отличие заключается в том, что боты отправляют запросы только методом HEAD (получить один заголовок) или GET (получить документ). POST запросы, передающие информацию в форме, роботами не посылаются.

Гуглбот и яндексбот принимают любые (Accept:*/*) медиатипы и допускают сжатый gzip формат документов. Робот Google не запрашивает язык документа, Яндекс отдает предпочтение русским материалам, в меньшей степени украинским, белорусским и английским. Бот Рамблера изначально работает с контентом на русском языке, ограниченно — на английском. Кодировки и медиатипы распознаются автоматически.

Требования к HTTP заголовкам

Для эффективной раскрутки сайта необходимо, чтобы его CMS отдавал HTTP заголовок в соответствии со следующими требованиями.

  1. Передача заголовка выполняется перед телом документа. После начала трансляции html кода попытка отправки заголовка приведет к тому, что выполнение скрипта будет завершено по ошибке.
  2. Если для оформления страницы используется html шаблоны со вставками PHP кода, сервер не сможет вовремя отреагировать на запрос страниц, которых нет в базе данных сайта. Для решения данной проблемы применяют буферизацию вывода, что позволяет на любой стадии исполнения скрипта без отправки очистить буфер, передать код ошибки и выдать клиенту другую страницу.
  3. В заголовке должны присутствовать медиатип и кодировка документа. Эту информацию можно добавлять в виде тега http-equip. Он используется как эквивалент заголовка для статических html-страниц. Данные в мета-теге должны совпадать с указанными в заголовке. Для более результативного продвижения сайтов в заголовке также передают язык документов (Content-language), дату и время редакции страницы (атрибут Last-Modified).

Написание скрипта для просмотра HTTP-заголовков

1. Введение

Очень часто требуется просмотреть HTTP-заголовок, отдаваемый отдельной страницей интересующего сайта.

Подобная необходимость может возникнуть, например, когда требуется проверить «работоспособность» своего собственного сайта. Для этого не надо загружать страницу со всей графикой, а достаточно просмотреть HTTP-заголовок, отдаваемый данной страницей.

Если в результатах присутствует строка, подобная

значит все в порядке, а если вроде

то данная страница отсутствует на сайте и необходимо предпринять какие-либо меры.

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

При этом стоит отметить довольно большое преимущество подобного метода оценки сайта: объем получаемой информации значительно меньше, чем при прямой загрузке интересуемой страницы в окно браузера (полный размер которой может достигать нескольких мегабайтов, например, при использовании flash-анимации), а значит, расходы за входящий трафик существенно снижаются. В предлагаемом мастер-классе будут повторены общие сведения о HTTP-заголовоках, а также приведен пример самостоятельного написания скрипта, позволяющего просматривать эти загаловки.

1.1. Назначение протокола HTTP

(С использованием материалов www.codenet.ru )

HyperText Transfer Protocol (HTTP) — это протокол высокого уровня, уровня приложений (дословно — протокол передачи гипертекста), обеспечивающий необходимую скорость передачи данных, требующуюся для распределенных информационных систем гипермедиа. HTTP используется проектом World Wide Web с 1990 года.

Практические информационные системы требуют большего, чем примитивный поиск, модификация и аннотация данных. HTTP/1.0 предоставляет открытое множество методов, которые могут быть использованы для указания целей запроса. Они построены на дисциплине ссылок, где для указания ресурса, к которому должен быть применен данный метод, используется Универсальный Идентификатор Ресурсов (Universal Resource Identifier — URI), в виде местонахождения (Uniform Resource Locator — URL) или имени (Uniform Resource Name — URN). Формат сообщений сходен с форматом Internet Mail или Multipurpose Internet Mail Extensions (MIME — Многоцелевое Расширение Почты Internet).

HTTP/1.0 используется также для коммуникаций между различными пользовательскими просмоторщиками и шлюзами, дающими гипермедиа доступ к существующим Internet протоколам, таким как SMTP, NNTP, FTP, Gopher и WAIS. HTTP/1.0 разработан, чтобы позволять таким шлюзам через proxy серверы, без какой-либо потери передавать данные с помощью упомянутых протоколов более ранних версий.

2. Просмотр HTTP-заголовков

2.1. Методы HTTP

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

Метод GET служит для получения любой информации, идентифицированной URI Запроса. Если URI Запроса ссылается на процесс, выдающий данные, в качестве ответа будут выступать данные, сгенерированные данным процессом, а не код самого процесса (если только это не является выходными данными процесса).

Метод HEAD аналогичен методу GET, за исключением того, что в ответе сервер не возвращает «тело» Ответа. Метаинформация, содержащаяся в HTTP заголовках ответа на запрос HEAD, должна быть идентична информации HTTP заголовков ответа на запрос GET. Данный метод может использоваться для получения метаинформации о ресурсе без передачи по сети самого ресурса.

Более подробную информацию о протоколе HTTP и его методах можно найти в сети Интернет ( http://www.citforum.ru/internet/cgi_tut/http.shtml , http://www.citycat.ru/doc/HTML/short/http.html ). На http://webkomora.com.ua/ru/articles/web/raskrutka/httpoptimisation.html можно прочитать небольшую, но полезную статью про оптимизацию HTTP-заголовка страницы.

2.2. Скрипт для просмотра HTTP-заголовков интересующих интернет-ресурсов

Существует много сервисов, предоставляющих возможность просмотра HTTP-заголовков интересующего вас URL (например, http://www.webcode.ru/use/header/ или http://seolab.ru/add/header.htm ).

Но попробуем написать скрипт, позволяющий просматривать заголовки HTTP интересующих интернет-ресурсов (сайтов или страниц), самостоятельно.

3. Заключение

Итак, у нас получился довольно простой, но в то же время очень полезный скрипт.На каком языке его писать — выбирать Вам. Например, при написании подобного скрипта на Perl (при обращении к удаленному ресурсу) можно воспользоваться Perl-модулем LWP::UserAgent. Затем необходимо создать объект данного класса и сделать запрос HEAD (или GET) по интересующему URL. Функция, реализующая подобный алгоритм, может выглядеть так:

Подобной функции в качестве параметра необходимо передать URI, заголовок которого необходимо просмотреть.

В заключение стоит сказать, что данный скрипт будет полезен при анализе интересующего сайта/страницы (например, своего собственного или конкурента): с помощью него можно узнать как тот или иной сайт/страница «относится» к поисковым роботам (например, Яндекса), которые постоянно блуждают по всемирной паутине.

Что такое заголовки в протоколе HTTP.

Когда мы разбирали общую структуру HTTP запросов и ответов, то одной из частей, из которой эта структура состояла, являлись HTTP заголовки (Message Headers). Давайте сейчас подробнее рассмотрим, что это такое.

Заголовки – это специальные параметры, которые несут определенную служебную информацию о соединении по HTTP. Некоторые заголовки имеют лишь информационный характер для пользователя или для компьютера, другие передают определенные команды, исходя из которых, сервер или клиент будет выполнять какие-то действия.

В зависимости от того, где эти заголовки могут находиться, они разделяются на:

General Headers (Основные заголовки) — должны быть и в запросах и в ответах клиента и сервера.

Request Headers (Заголовки запроса) — используются только в запросах клиента.

Response Headers (Заголовки ответа) — используются только в ответах сервера.

Entity Headers (Заголовки сущности) — сопровождают каждую сущность сообщения.

Каждый заголовок имеет следующий вид:

Немного о правилах написания, что нужно иметь в виду:

1) Регистр (большие или маленькие буквы) здесь не учитываются. Можно писать и так и так.

2) Пишутся латинскими буквами.

3) После параметра должен идти символ двоеточия (:)

4) Окончанием пары «параметр:значение» служит символ переноса строки.

Вот, примеры некоторых заголовков:

На самом деле, количество возможных заголовков, которые можно указать, очень большое. Я не вижу смысла приводить их все здесь.

Если вы знаете английский, то почитать о них можно в оригинале на страницах стандарта HTTP 1.1.

Кроме того, есть перевод этого стандарта на русский язык здесь:

Есть еще хорошая табличка, которая опубликована на страницах википедии:

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

Яндекс Метрика и Google Analytics. Цели, события, отчеты.

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL