Различение между «естественным» HTTP 404 и сгенерированным PHP - PullRequest
Новая
       32

Различение между «естественным» HTTP 404 и сгенерированным PHP

1 голос
/ 06 января 2011

Итак, у меня есть файл, который никогда не должен быть доступен пользователю напрямую, но включен в другой файл PHP. Если файл вызывается напрямую, он генерирует HTTP Status 404 Not Found , чтобы обмануть возможного злоумышленника в том, что такого файла не существует. Однако, если хакер может сказать, что 404 был сгенерирован PHP или не является "естественным", тогда весь смысл заголовка будет потерян. Так можно ли сказать, был ли сервер 404 сгенерирован естественным образом (поскольку файл на самом деле не существует) или кодом PHP?

PS: я знаю, что этот вопрос может показаться довольно странным, смеется

Ответы [ 5 ]

5 голосов
/ 06 января 2011

Умный злоумышленник будет проверять необработанные заголовки состояния и искать любые несоответствия, которые могут указывать, было ли что-то «естественным» 404 или нет.

Например, версия Apache на моем сервере отправляет обратноследующие заголовки, если вы запрашиваете файл, которого там нет 

HTTP/1.1 404 Not Found
Date: Thu, 06 Jan 2011 18:10:57 GMT
Server: Apache/2.2.17
Content-Type: text/html

Однако, если я настрою страницу PHP для отправки заголовка 404, мой сервер отправит обратно следующие заголовки 

HTTP/1.0 404 Not Found
Date: Thu, 06 Jan 2011 18:10:48 GMT
Server: Apache/2.2.17
Connection: close
Content-Type: text/html

Таким образом, нет ничего, что очевидно указывает на то, что именно PHP генерировал заголовки во втором случае, но этот дополнительный заголовок 

Connection: close

указывает, что происходит что-то еще.Очень опытные злоумышленники создали профили заголовков по умолчанию для максимально возможного количества веб-серверов и динамических сред выполнения, которые проверяют точное содержимое и порядок заголовков, чтобы определить, какой сервер и технологический стек вы можете использовать .Опытный злоумышленник будет знать (или иметь инструмент, который указывает), что PHP всегда отправляет заголовок Connection: close, который может раскрыть вашу базовую технологию.

Я использую программу командной строки curl для проверки заголовков. 

curl -I 'http://example.com/asfasdfsd'

Вы можете найти больше информации на OWASP wiki .

Аналогично, убедитесь, что необработанный текст, который отправляет ваша страница PHP, соответствует тому, что отправляет ваш сервер apacheдо уровня байтов.Умный злоумышленник будет искать различия в форматировании вывода, чтобы определить, была ли ваша страница «естественной» 404 или нет.

3 голосов
/ 06 января 2011

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

Вам также следует отключить значение expose_php в вашем PHP.ini, чтобы PHP не вставлял заголовок, говорящий «сгенерированный ...», среди прочего.Смотри http://blog.arvixe.com/expose-php-servertokens-apache/

2 голосов
/ 06 января 2011

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

1 голос
/ 06 января 2011

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

0 голосов
/ 06 января 2011

Пока код состояния возврата HTTP равен 404, тогда он по определению равен , настоящий 404, независимо от того, какой другой контент возвращается.

Но я думаю, что вы, возможно, задаете не тот вопрос.

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

...