Защити свой компьютер на 100% от вирусов и хакеров

# telnet target1.com 80

Trying target1.com…

Connected to target1.com.

Escape character is '^]'.

HEAD /non-existent-file.txt HTTP/1.0

HTTP/1.1 404 Not Found

Date: Mon, 07 Jun 2004 14:31:03 GMT

Server: Apache/1.3.29 (UNIX)

mod_perl/1.29

Connection: close

Content-Type: text/html; charset=iso-

8859-1

Синтаксис заголовков также может отличаться. Например, использование строчных или заглавных букв в названии параметров (Content-Length в IIS или Content-length в Netscape-Enterprise/6.0).

Несмотря на требования HTTP RFC, существуют семантические особенности при генерации заголовков различными серверами. Например, Apache передает параметр

Date перед значением заголовка Server, в то время как IIS использует обратный порядок. Порядок значений параметров также может отличаться. Например, при обработке запроса OPTIONS Apache возвращает только параметр Allow, в то время как IIS дополнительно включает параметр Public.

Аналогичным образом может анализироваться наличие опциональных заголовков (Vary, Expires и т. д.) и реакция сервера на неверные запросы (GET //, GET/%2f и т. д.).

Утечка информации (Information Leakage). Эти уязвимости возникают в ситуациях, когда сервер публикует важную информацию, например комментарии разработчиков или сообщения об ошибках, которая может быть использована для компрометации системы. Ценные, с точки зрения злоумышленника, данные могут содержаться в комментариях HTML, сообщениях об ошибках или просто присутствовать в открытом виде. Существует огромное количество ситуаций, в которых может произойти утечка информации. Необязательно она приводит к возникновению уязвимости, но часто дает атакующему прекрасное пособие для развития атаки. С утечкой важной информации могут возникать риски различной степени, поэтому необходимо минимизировать количество служебной информации, доступной на клиентской стороне. Анализ доступной информации позволяет злоумышленнику произвести разведку и получить представление о структуре директорий сервера, используемых SQL-запросах, названиях ключевых процессов и программ сервера. Часто разработчики оставляют комментарии в HTML-страницах и коде сценариев для облегчения поиска ошибок и поддержки приложения. Эта информация может варьироваться от простых описаний деталей функционирования программы до, в худших случаях, имен пользователей и паролей, используемых при отладке.

Утечка информации может относиться и к конфиденциальным данным, обрабатываемым сервером. Это могут быть идентификаторы пользователя (ИНН, номера водительских удостоверений, паспортов и т. д.), а также текущая информация (баланс лицевого счета или история платежей). Многие атаки этой категории выходят за рамки защиты веб-приложений и переходят в область физической безопасности. Утечка информации в этом случае часто возникает, когда в браузере отображается информация, которая не должна выводиться в открытом виде даже пользователю. В качестве примера можно привести пароли пользователя, номера кредитных карточек и т. д. Данный пример хорошо поясняют три основные категории утечки информации: комментарии разработчиков, сообщения об ошибках и отображение конфиденциальной информации. Ниже приведен комментарий разработчиков, который указывает на то, что в случае проблем с загрузкой изображений необходимо перезагрузить сервер VADER:

<TABLE border="0' cellPadding="0' cellSpacing="0'

height="59' width="591'>

<TBODY>

<TR>

<! – If the image files are missing,

restart VADER ->

<TD bgColor="#ffffff" colSpan="5'

height="17' width="587'>&nbsp;</TD>

</TR>

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

Ниже приведено сообщение, выдаваемое сервером при вводе символа апострофа (") в качестве имени пользователя (листинг 1.15).

Листинг 1.15. Сообщение сервера об ошибке при вводе недопустимого символа

An Error Has Occurred.

Error Message:

System.Data.OleDb.OleDbException: Syntax error (missing

operator) in query expression 'username = ''' and password =

'g''. at

System.Data.OleDb.OleDbCommand.ExecuteCommandTextErrorHandling (

Int32 hr) at

System.Data.OleDb.OleDbCommand.ExecuteCommandTextForSingleResult

( tagDBPARAMS dbParams, Object& executeResult) at

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

Обратный путь в директориях

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

При подобных атаках потенциально уязвимо любое устройство, имеющее веб-интерфейс. Многие веб-серверы ограничивают доступ пользователя определенной частью файловой системы, обычно называемой web document root или CGI root. Эти директории содержат файлы, предназначенные для пользователя, и программы, необходимые для получения доступа к функциям веб-приложения. Большинство базовых атак, эксплуатирующих обратный путь, основаны на внедрении в URL-символов ../, чтобы изменить расположение ресурса, который будет обрабатываться сервером. Поскольку большинство веб-серверов фильтруют эту последовательность, злоумышленник может воспользоваться альтернативными кодировками для представления символов перехода по директориям. Популярные приемы включают использование альтернативных кодировок, например Unicode (..%u2216 или ..%c0%af), использование обратного слэша (..\) в Windows-серверах, символов URLEncode (%2e%2e%2f) или двойной кодировки URLEncode (..%2 55c). Даже если веб-сервер ограничивает доступ к файлам определенным каталогом, эта уязвимость может возникать в сценариях или CGI-программах. Возможность использования обратного пути в каталогах довольно часто возникает в приложениях, использующих механизмы шаблонов или загружающих текст их страниц из файлов на сервере. В этом варианте атаки злоумышленник модифицирует имя файла, передаваемое в качестве параметра CGI-программы или серверного сценария. В результате злоумышленник может получить исходный код сценариев. Довольно часто к имени запрашиваемого файла добавляются специальные символы – такие как %0 0 – с целью обхода фильтров. Следующие примеры иллюстрируют обратный путь в каталогах вебсервера:

httр://example/../../../../../some/file

httр://example/..%255c..%255c..%255csome/file

httр://example/..%u2216..%u2216some/file

Обратный путь в каталогах веб-приложения:

? исходный URL: httр://example/foo.cgi?home=index.htm;

? атака: httр://example/foo.cgi?home=foo.cgi.

В приведенном сценарии веб-приложение генерирует страницу, содержащую исходный код сценария foo.cgi, поскольку значение переменной home используется как имя загружаемого файла. Обратите внимание, что в данном случае злоумышленник не использует специальных символов, поскольку целью является файл в той же директории, в которой располагается файл index.htm. Кроме того, возможен вариант обратного пути в каталогах веб-приложения с использованием специальных символов: