Интерфейс Common Gateway Interface (CGI) для веб-серверов.

Введение

Интерфейс между веб-серверами и внешними программами

В вычислительной технике Common Gateway Interface (CGI) — это спецификация интерфейса, позволяющая веб-серверам выполнять внешнюю программу для обработки HTTP- или HTTPS-запросов пользователей. Такие программы часто написаны на языке сценариев и обычно называются CGI-скриптами, но могут включать и скомпилированные программы. Типичный пример использования — отправка веб-формы на веб-странице, использующей CGI. Данные формы отправляются на веб-сервер в HTTP-запросе с URL, указывающим на CGI-скрипт. Веб-сервер затем запускает CGI-скрипт в новом процессе, передавая ему данные формы. CGI-скрипт передает свой вывод, как правило, в формате HTML, веб-серверу, который, в свою очередь, отправляет его обратно в браузер в качестве ответа на запрос. Разработанный в начале 1990-х годов, CGI был первым широко распространенным методом, обеспечивающим интерактивность веб-страниц. В связи с необходимостью запуска CGI-скриптов в отдельном процессе при каждом запросе от клиента, были разработаны различные альтернативные решения.

История

В 1993 году команда Национального центра суперкомпьютерных приложений (NCSA) опубликовала спецификацию для вызова исполняемых файлов командной строки в списке рассылки www talk. Другие разработчики веб-серверов приняли её, и с тех пор она стала стандартом для веб-серверов. В ноябре 1997 года была создана рабочая группа под председательством Кена Коара для более формального определения CGI, разработанного NCSA. Результатом этой работы стал RFC 3875, в котором была специфицирована версия CGI 1.1. В RFC конкретно упоминаются следующие участники: Например, если веб-сервер имеет полное доменное имя www.example.com, а его коллекция документов хранится в /usr/local/apache/htdocs/ в локальной файловой системе (его корневой каталог), то веб-сервер будет отвечать на запрос http://www.example.com/index.html, отправляя в браузер копию файла /usr/local/apache/htdocs/index.html (если он существует). Для страниц, генерируемых динамически, серверное программное обеспечение может перенаправлять запросы отдельным программам и передавать результаты запрашивающему клиенту (обычно веб-браузеру, который отображает страницу конечному пользователю). Таким программам обычно требуется дополнительная информация, передаваемая вместе с запросом, такая как строки запроса или cookie. В свою очередь, при возврате скрипт должен предоставить всю информацию, необходимую HTTP для ответа на запрос: HTTP-статус запроса, содержимое документа (если доступно), тип документа (например, HTML, PDF или обычный текст) и т. д. Изначально не существовало стандартизированных методов обмена данными между браузером, HTTP-сервером, с которым он взаимодействовал, и скриптами на сервере, которые должны были обрабатывать данные и в конечном итоге возвращать результат браузеру. В результате между различными вариантами HTTP-серверов возникали взаимные несовместимости, которые снижали переносимость скриптов. Осознание этой проблемы привело к разработке спецификации обмена данными, что и привело к созданию CGI. Программы, генерирующие веб-страницы и вызываемые серверным программным обеспечением, соответствующим спецификации CGI, называются CGI-скриптами, даже если они фактически написаны на нескриптовом языке, таком как C. Спецификация CGI была быстро принята и продолжает поддерживаться всеми известными пакетами HTTP-серверов, такими как Apache, Microsoft IIS и (с расширением) серверами на основе Node.js. Одним из первых применений CGI-скриптов была обработка форм. В ранних версиях HTML HTML-формы обычно имели атрибут "action" и кнопку, обозначенную как кнопка "submit". При нажатии кнопки "submit" URI, указанный в атрибуте "action", отправлялся на сервер вместе с данными из формы в виде строки запроса. Если в атрибуте "action" указан CGI-скрипт, то этот скрипт выполнялся, а скрипт, в свою очередь, генерировал HTML-страницу.

In 1993, the National Center for Supercomputing Applications (NCSA) team wrote the specification for calling command line executables on the www talk mailing list. The other Web server developers adopted it, and it has been a standard for Web servers ever since. A work group chaired by Ken Coar started in November 1997 to get the NCSA definition of CGI more formally defined. This work resulted in RFC 3875, which specified CGI Version 1.1. Specifically mentioned in the RFC are the following contributors: For example, if a web server has the fully qualified domain name www. example. com, and its document collection is stored at /usr/local/apache/htdocs/ in the local file system (its document root), then the web server will respond to a request for http://www. example. com/index. html by sending to the browser a copy of the file /usr/local/apache/htdocs/index. html (if it exists). For pages constructed on the fly, the server software may defer requests to separate programs and relay the results to the requesting client (usually, a Web browser that displays the page to the end user). Such programs usually require some additional information to be specified with the request, such as query strings or cookies. Conversely, upon returning, the script must provide all the information required by HTTP for a response to the request: the HTTP status of the request, the document content (if available), the document type (e. g. HTML, PDF, or plain text), et cetera. Initially, there were no standardized methods for data exchange between a browser, the HTTP server with which it was communicating and the scripts on the server that were expected to process the data and ultimately return a result to the browser. As a result, mutual incompatibilities existed between different HTTP server variants that undermined script portability. Recognition of this problem led to the specification of how data exchange was to be carried out, resulting in the development of CGI. Web page generating programs invoked by server software that adheres to the CGI specification are known as CGI scripts, even though they may actually have been written in a non scripting language, such as C.

The CGI specification was quickly adopted and continues to be supported by all well known HTTP server packages, such as Apache, Microsoft IIS, and (with an extension) node. js based servers. An early use of CGI scripts was to process forms. In the beginning of HTML, HTML forms typically had an "action" attribute and a button designated as the "submit" button. When the submit button is pushed the URI specified in the "action" attribute would be sent to the server with the data from the form sent as a query string. If the "action" specifies a CGI script then the CGI script would be executed, the script in turn generating an HTML page.

Развертывание

Веб-сервер, поддерживающий CGI, может быть настроен на интерпретацию URL-адреса как ссылки на CGI-скрипт. Распространенной практикой является создание каталога `cgi-bin/` в корне дерева каталогов и обработка всех исполняемых файлов в этом каталоге (и только их, в целях безопасности) как CGI-скриптов. Когда веб-браузер запрашивает URL, указывающий на файл в каталоге CGI (например, http://example.com/cgi-bin/printenv.pl/with/additional/path?and=a&query=string), HTTP-сервер вместо простой отправки этого файла (/usr/local/apache/htdocs/cgi-bin/printenv.pl) веб-браузеру запускает указанный скрипт и передает вывод скрипта веб-браузеру. То есть, все, что скрипт выводит в стандартный поток вывода, передается веб-клиенту, а не отображается в окне терминала, в котором запущен веб-сервер. Другой популярный подход – использование расширений имен файлов; например, если CGI-скриптам последовательно присваивается расширение `cgi`, веб-сервер может быть настроен на интерпретацию всех файлов с таким расширением как CGI-скриптов. Хотя это удобно и необходимо для многих готовых скриптов, это открывает сервер для атак, если удаленный пользователь может загрузить исполняемый код с соответствующим расширением. Спецификация CGI определяет, как дополнительная информация, передаваемая с запросом, передается скрипту. Веб-сервер создает подмножество переменных окружения, переданных ему, и добавляет детали, относящиеся к HTTP-окружению. Например, если к URL сразу после имени скрипта добавляется слэш и дополнительные имена каталогов (в данном примере, /with/additional/path), этот путь сохраняется в переменной окружения `PATH_INFO` перед вызовом скрипта. Если параметры передаются скрипту через HTTP GET-запрос (вопросительный знак, добавленный к URL, за которым следуют пары `param=value`; в примере, ?and=a&query=string), эти параметры сохраняются в переменной окружения `QUERY_STRING` перед вызовом скрипта. Тело HTTP-запроса, например, параметры формы, отправленные через HTTP POST-запрос, передаются в стандартный ввод скрипта. Скрипт может затем прочитать эти переменные окружения или данные из стандартного ввода и адаптироваться к запросу веб-браузера.

A Web server that supports CGI can be configured to interpret a URL that it serves as a reference to a CGI script. A common convention is to have a cgi bin/ directory at the base of the directory tree and treat all executable files within this directory (and no other, for security) as CGI scripts. When a Web browser requests a URL that points to a file within the CGI directory (e. g., http://example. com/cgi bin/printenv. pl/with/additional/path?and=a&query=string), then, instead of simply sending that file (/usr/local/apache/htdocs/cgi bin/printenv. pl) to the Web browser, the HTTP server runs the specified script and passes the output of the script to the Web browser. That is, anything that the script sends to standard output is passed to the Web client instead of being shown in the terminal window that started the web server. Another popular convention is to use filename extensions; for instance, if CGI scripts are consistently given the extension cgi, the Web server can be configured to interpret all such files as CGI scripts. While convenient, and required by many prepackaged scripts, it opens the server to attack if a remote user can upload executable code with the proper extension. The CGI specification defines how additional information passed with the request is passed to the script. The Web server creates a subset of the environment variables passed to it and adds details pertinent to the HTTP environment. For instance, if a slash and additional directory name(s) are appended to the URL immediately after the name of the script (in this example, /with/additional/path), then that path is stored in the PATH INFO environment variable before the script is called. If parameters are sent to the script via an HTTP GET request (a question mark appended to the URL, followed by param=value pairs; in the example, ?and=a&query=string), then those parameters are stored in the QUERY STRING environment variable before the script is called. Request HTTP message body, such as form parameters sent via an HTTP POST request, are passed to the script's standard input. The script can then read these environment variables or data from standard input and adapt to the Web browser's request.

Применение

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

Безопасность

Программы CGI по умолчанию выполняются в контексте безопасности веб-сервера. При первом появлении CGI вместе с эталонными дистрибутивами веб-серверов NCSA, Apache и CERN предоставлялся ряд примеров скриптов, демонстрирующих, как можно было написать скрипты оболочки или программы на C для использования нового CGI. Одним из таких примеров был CGI-скрипт PHF, реализующий простую телефонную книгу. Как и многие другие скрипты того времени, этот скрипт использовал функцию `escape shell cmd`. Эта функция должна была очищать аргумент, полученный от пользовательского ввода, и затем передавать его в оболочку Unix для выполнения в контексте безопасности веб-сервера. Скрипт некорректно очищал ввод, позволяя передавать в оболочку символы новой строки, что фактически позволяло выполнять несколько команд. Результаты выполнения этих команд затем отображались на веб-сервере. Если контекст безопасности веб-сервера это позволял, злоумышленники могли выполнять вредоносные команды. Это был первый широко распространенный пример нового типа веб-атаки, известного как инъекция кода, когда необработанные данные от веб-пользователей могли приводить к выполнению кода на веб-сервере. Поскольку пример кода был установлен по умолчанию, атаки были широко распространены и привели к ряду рекомендаций по безопасности в начале 1996 года.