Cgi Bin Binary Options

Posibles ataques El uso de PHP como un binario CGI es una opción para configuraciones que por alguna razón no desean integrar PHP como un módulo en software de servidor (como Apache), o usar PHP con diferentes tipos de envolturas CGI para crear chroot seguro y setuid Entornos para scripts. Esta configuración suele implicar la instalación de binario ejecutable de PHP en el directorio cgi-bin del servidor web. La recomendación CERT CA-96.11 recomienda no colocar intérpretes en cgi-bin. Incluso si el PHP binario puede ser utilizado como un intérprete independiente, PHP está diseñado para evitar los ataques que esta configuración hace posible: Acceso a los archivos del sistema: my. host/cgi-bin/php/etc/passwd La información de la consulta en una URL después de la El signo de interrogación () se pasa como argumentos de línea de comandos al intérprete por la interfaz CGI. Normalmente, los intérpretes abren y ejecutan el archivo especificado como el primer argumento en la línea de comandos. Cuando se invoca como un binario CGI, PHP se niega a interpretar los argumentos de la línea de comandos. Acceso a cualquier documento web en el servidor: my. host/cgi-bin/php/secret/doc. html La parte de información de ruta de la URL después del nombre binario de PHP, /secret/doc. html se utiliza convencionalmente para especificar el nombre de la Archivo para ser abierto e interpretado por el programa CGI. Por lo general, algunas directivas de configuración del servidor web (Apache: Action) se utilizan para redirigir peticiones a documentos como my. host/secret/script. php al intérprete de PHP. Con esta configuración, el servidor web comprueba primero los permisos de acceso al directorio / secreto. Y después crea la solicitud redirigida my. host/cgi-bin/php/secret/script. php. Desafortunadamente, si la solicitud se da originalmente en este formulario, no hay comprobaciones de acceso realizadas por el servidor web para el archivo /secret/script. php. Pero sólo para el archivo / cgi-bin / php. De esta forma, cualquier usuario capaz de acceder a / cgi-bin / php puede acceder a cualquier documento protegido en el servidor web. En PHP, las directivas de configuración runtime cgi. forceredirect. Docroot y userdir se pueden utilizar para evitar este ataque, si el árbol de documentos del servidor tiene directorios con restricciones de acceso. Vea a continuación la explicación completa de las diferentes combinaciones. Contenido dinámico con CGI La interfaz CGI (Common Gateway Interface) define una forma para que un servidor web interactúe con programas externos que generan contenido, que a menudo se denominan CGI Programas o secuencias de comandos CGI. Es la forma más simple y más común de poner contenido dinámico en su sitio web. Este documento será una introducción a la configuración de CGI en su servidor web Apache, y empezar a escribir programas CGI. Para que sus programas CGI funcionen correctamente, necesitará configurar Apache para permitir la ejecución de CGI. Hay varias formas de hacer esto. La directiva ScriptAlias ​​le dice a Apache que un directorio en particular está reservado para los programas CGI. Apache asumirá que cada archivo en este directorio es un programa CGI, e intentará ejecutarlo, cuando ese recurso particular lo solicite un cliente. La directiva ScriptAlias ​​tiene el siguiente aspecto: ScriptAlias ​​/ cgi-bin / / usr / local / apache2 / cgi-bin / El ejemplo mostrado es del archivo de configuración httpd. conf predeterminado, si instaló Apache en la ubicación predeterminada. La directiva ScriptAlias ​​es muy similar a la directiva Alias, que define un prefijo de URL que se asigna a un directorio en particular. Alias ​​y ScriptAlias ​​normalmente se utilizan para directorios que están fuera del directorio DocumentRoot. La diferencia entre Alias ​​y ScriptAlias ​​es que ScriptAlias ​​tiene el significado agregado de que todo bajo ese prefijo de URL será considerado un programa CGI. Por lo tanto, el ejemplo anterior le dice a Apache que cualquier solicitud de un recurso que comience con / cgi-bin / debe ser servida desde el directorio / usr / local / apache2 / cgi-bin /. Y debe tratarse como un programa CGI. Por ejemplo, si se solicita la URL. example / cgi-bin / test. pl, Apache intentará ejecutar el archivo /usr/local/apache2/cgi-bin/test. pl y devolverá la salida. Por supuesto, el archivo tendrá que existir, y ser ejecutable, y devolver la salida de una manera particular, o Apache devolverá un mensaje de error. Los programas CGI a menudo están restringidos a directorios ScriptAlias ​​por razones de seguridad. De esta manera, los administradores pueden controlar estrictamente quién puede usar los programas CGI. Sin embargo, si se toman las precauciones de seguridad adecuadas, no hay razón para que los programas CGI no se puedan ejecutar desde directorios arbitrarios. Por ejemplo, puede permitir que los usuarios tengan contenido web en sus directorios principales con la directiva UserDir. Si quieren tener sus propios programas CGI, pero no tienen acceso al directorio principal de cgi-bin, tendrán que ser capaces de ejecutar programas CGI en otros lugares. Hay dos pasos para permitir la ejecución CGI en un directorio arbitrario. En primer lugar, el controlador cgi-script debe activarse mediante la directiva AddHandler o SetHandler. En segundo lugar, ExecCGI debe especificarse en la directiva Opciones. Puede utilizar explícitamente la directiva Opciones, dentro del archivo de configuración principal del servidor, para especificar que se permitió la ejecución CGI en un directorio determinado: ltDirectory / usr / local / apache2 / htdocs / somedirgt Opciones ExecCGI lt / Directorygt La directiva anterior le dice a Apache que permita La ejecución de archivos CGI. También necesitará decirle al servidor qué archivos son archivos CGI. La siguiente directiva AddHandler le dice al servidor que trate todos los archivos con la extensión cgi o pl como programas CGI: AddHandler cgi-script. cgi. pl El tutorial. htaccess muestra cómo activar los programas CGI si no tiene acceso a httpd. conf. Para permitir la ejecución del programa CGI para cualquier archivo que termine en. cgi en los directorios de usuarios, puede utilizar la siguiente configuración. LtDirectory / home // publichtmlgt Opciones ExecCGI AddHandler cgi-script. cgi lt / Directorygt Si desea designar un subdirectorio cgi-bin de un directorio de usuarios donde todo será tratado como un programa CGI, puede utilizar lo siguiente. LtDirectory / home // publichtml / cgi-bingt Opciones ExecCGI SetHandler cgi-script lt / Directorygt Hay dos diferencias principales entre la programación regular y la programación CGI. En primer lugar, toda la salida de su programa CGI debe estar precedida por un encabezado de tipo MIME. Esta es una cabecera HTTP que le dice al cliente qué tipo de contenido está recibiendo. La mayoría de las veces, esto se verá así: En segundo lugar, su salida debe estar en HTML, o algún otro formato que un navegador será capaz de mostrar. La mayoría de las veces, esto será HTML, pero ocasionalmente podría escribir un programa CGI que genere una imagen gif, u otro contenido no HTML. Aparte de esas dos cosas, la escritura de un programa CGI se verá mucho como cualquier otro programa que pueda escribir. El siguiente es un ejemplo de programa CGI que imprime una línea en su navegador. Escriba lo siguiente, guárdelo en un archivo llamado first. pl. Y póngalo en su directorio cgi-bin. / Usr / bin / perl print Tipo de contenido: text / htmlnn print Hola, Mundo. Incluso si no está familiarizado con Perl, debería ser capaz de ver lo que está sucediendo aquí. La primera línea le dice a Apache (o cualquier shell que esté ejecutando) que este programa se puede ejecutar alimentando el archivo al intérprete encontrado en la ubicación / usr / bin / perl. La segunda línea imprime la declaración de tipo de contenido de la que hablamos, seguida de dos pares de nueva línea de retorno de carro. Esto pone una línea en blanco después del encabezado, para indicar el final de los encabezados HTTP y el principio del cuerpo. La tercera línea imprime la cadena Hello, World .. Y eso es el final de la misma. Si abre su navegador favorito y dígalo para obtener la dirección o donde quiera que coloque su archivo, verá la línea Hello, World. Aparecen en la ventana del navegador. No es muy emocionante, pero una vez que consigas que el trabajo, youll tienen una buena oportunidad de conseguir casi cualquier cosa que trabaja. Hay cuatro cosas básicas que puede ver en su navegador cuando intenta acceder a su programa CGI desde la web: La salida de su programa CGI Gran Eso significa que todo funcionó bien. Si la salida es correcta, pero el navegador no la procesa correctamente, asegúrese de que tiene el tipo de contenido correcto definido en su programa CGI. El código fuente de su programa CGI o un mensaje POST Method Not Allowed Esto significa que no ha configurado correctamente Apache para procesar su programa CGI. Vuelve a leer la sección sobre cómo configurar Apache e intenta encontrar lo que te perdiste. Un mensaje que comienza con Forbidden Eso significa que hay un problema de permisos. Compruebe el registro de errores de Apache y la sección siguiente en los permisos de archivo. Un mensaje que indica Error interno del servidor Si comprueba el registro de errores de Apache. Probablemente encontrará que dice final prematuro de encabezados de guión, posiblemente junto con un mensaje de error generado por su programa CGI. En este caso, deberá comprobar cada una de las secciones siguientes para ver qué puede estar impidiendo que su programa CGI emita los encabezados HTTP adecuados. Recuerde que el servidor no se ejecuta como usted. Es decir, cuando el servidor se inicia, se está ejecutando con los permisos de un usuario sin privilegios - por lo general nadie. O - y por lo tanto, necesitará permisos adicionales para ejecutar archivos que son de su propiedad. Normalmente, la forma de dar a un archivo permisos suficientes para ser ejecutados por nadie es darle permiso de ejecución a todo el mundo en el archivo: chmod ax first. pl También, si su programa lee desde, o escribe en, cualquier otro archivo, Para tener los permisos correctos para permitir esto. Cuando ejecuta un programa desde su línea de comandos, tiene cierta información que se pasa a la shell sin que usted piense en ello. Por ejemplo, usted tiene un PATH. Que le dice a la shell donde puede buscar los archivos que usted hace referencia. Cuando un programa se ejecuta a través del servidor web como un programa CGI, puede que no tenga el mismo PATH. Cualquier programa que invoque en su programa CGI (como sendmail, por ejemplo) tendrá que ser especificado por una ruta completa, para que el shell puede encontrarlos cuando intenta ejecutar su programa CGI. Una manifestación común de esto es el camino hacia el intérprete de scripts (a menudo perl) indicado en la primera línea de su programa CGI, que se verá así: Asegúrese de que este es de hecho el camino hacia el intérprete. Además, si su programa CGI depende de otras variables de entorno. Usted tendrá que asegurarse de que esas variables son pasadas por Apache. La mayoría de las veces cuando un programa CGI falla, es debido a un problema con el programa en sí. Esto es particularmente cierto una vez que usted consigue la caída de este material CGI, y ya no cometer los dos errores anteriores. Lo primero que debe hacer es asegurarse de que su programa se ejecuta desde la línea de comandos antes de probarlo a través del servidor web. Por ejemplo, intente: cd / usr / local / apache2 / cgi-bin ./first. pl (No llame al intérprete de perl.) El shell y Apache deben encontrar al intérprete usando la información de ruta en la primera línea del script. Lo primero que ve escrito por su programa debe ser un conjunto de encabezados HTTP, incluyendo el Content-Type. Seguido de una línea en blanco. Si ve algo más, Apache devolverá el error Premature end of script headers si intenta ejecutarlo a través del servidor. Consulte Cómo escribir un programa CGI anterior para obtener más detalles. Los registros de errores son tu amigo. Cualquier cosa que salga mal genera un mensaje en el registro de errores. Siempre debe mirar allí primero. Si el lugar donde hospeda su sitio web no le permite acceder al registro de errores, probablemente debería alojar su sitio en otro lugar. Aprenda a leer los registros de errores y verá que casi todos sus problemas se identifican rápidamente y se resuelven rápidamente. El programa de soporte de suexec permite que los programas CGI se ejecuten bajo diferentes permisos de usuario, dependiendo de qué host virtual o directorio personal de usuario se encuentren. Suexec tiene una verificación de permisos muy estricta y cualquier fallo en esa comprobación resultará en que sus programas CGI no funcionen Final prematuro de los encabezados de la secuencia de comandos. Para comprobar si está utilizando suexec, ejecute apachectl - V y compruebe la ubicación de SUEXECBIN. Si Apache encuentra un binario suexec en el arranque, se activará suexec. A menos que entiendas completamente suexec, no debes usarlo. Para deshabilitar suexec, simplemente elimine (o renombre) el binario suexec apuntado por SUEXECBIN y reinicie el servidor. Si, después de leer acerca de suexec. Usted todavía desea utilizarlo, entonces ejecute suexec - V para encontrar la ubicación del archivo de registro de suexec y use ese archivo de registro para encontrar qué política está violando. A medida que se vuelven más avanzados en la programación CGI, será útil comprender más acerca de lo que sucede detrás de las escenas. Específicamente, cómo el navegador y el servidor se comunican entre sí. Porque aunque todo está muy bien para escribir un programa que imprime Hello, World., No es particularmente útil. Las variables de entorno son valores que flotan a su alrededor mientras usa su computadora. Son cosas útiles como su ruta de acceso (donde el equipo busca el archivo real que implementa un comando al escribirlo), su nombre de usuario, su tipo de terminal y así sucesivamente. Para obtener una lista completa de sus variables de entorno normales, cada día, escriba env en un símbolo del sistema. Durante la transacción CGI, el servidor y el navegador también establecen variables de entorno, de modo que puedan comunicarse entre sí. Estas son cosas como el tipo de navegador (Netscape, IE, Lynx), el tipo de servidor (Apache, IIS, WebSite), el nombre del programa CGI que se está ejecutando, etc. Estas variables están disponibles para el programador CGI, y son la mitad de la historia de la comunicación cliente-servidor. La lista completa de variables requeridas está en hoohoo. ncsa. uiuc. edu/cgi/env. html. Este sencillo programa CGI de Perl mostrará todas las variables de entorno que se están transmitiendo. Dos programas similares se incluyen en el directorio cgi-bin de la distribución de Apache. Tenga en cuenta que algunas variables son necesarias, mientras que otras son opcionales, por lo que puede ver algunas variables que no figuran en la lista oficial. Además, Apache proporciona muchas maneras diferentes de agregar sus propias variables de entorno a las básicas proporcionadas de forma predeterminada. / Usr / bin / perl print Tipo de contenido: text / htmlnn foreach key (teclas ENV) print key --gt ENV ltbrgt Otra comunicación entre el servidor y el cliente pasa por entrada estándar (STDIN) y salida estándar (STDOUT). En el contexto cotidiano normal, STDIN significa el teclado, o un archivo que un programa se da para actuar, y STDOUT por lo general significa la consola o pantalla. Cuando envía un formulario web a un programa CGI, los datos en ese formulario se agrupan en un formato especial y se entregan a su programa CGI a través de STDIN. El programa entonces puede procesar esos datos como si venía desde el teclado, o desde un archivo El formato especial es muy simple. Un nombre de campo y su valor se unen junto con un signo igual (), y los pares de valores se unen junto con un signo (amp). Los caracteres inconvenientes como espacios, signos de signo y signos, se convierten en su equivalente hexágono para que no engorden las obras. La cadena de datos completa podría parecer algo así como: A veces también verá este tipo de cadena añadida a una URL. Cuando se hace esto, el servidor pone esa cadena en la variable de entorno llamada QUERYSTRING. Eso se llama una solicitud GET. Su formulario HTML especifica si se utiliza GET o POST para entregar los datos, estableciendo el atributo METHOD en la etiqueta FORM. Su programa es entonces responsable de dividir esa cadena en información útil. Afortunadamente, hay bibliotecas y módulos disponibles para ayudarle a procesar estos datos, así como manejar otros aspectos de su programa CGI. Cuando escribe programas CGI, debe considerar el uso de una biblioteca de códigos, o módulo, para hacer la mayor parte del trabajo de gruñido para usted. Esto provoca menos errores y un desarrollo más rápido. Si está escribiendo programas CGI en Perl, los módulos están disponibles en CPAN. El módulo más popular para este propósito es CGI. pm. También podría considerar CGI :: Lite. Que implementa un conjunto mínimo de funcionalidad, que es todo lo que necesita en la mayoría de los programas. Si está escribiendo programas CGI en C, hay una variedad de opciones. Una de ellas es la biblioteca CGIC, de. boutell / cgic /. Hay un gran número de recursos CGI en la web. Puede discutir problemas CGI con otros usuarios del grupo Usenet comp. infosystems..authoring. cgi. Y la lista de correo de los servidores de HTML Writers Guild es una gran fuente de respuestas a sus preguntas. Puede encontrar más información en. hwg. org / lists / hwg-servers /. Y, por supuesto, probablemente debería leer la especificación CGI, que tiene todos los detalles sobre el funcionamiento de los programas CGI. Puede encontrar la versión original en la NCSA y hay un borrador actualizado en el proyecto RFC Common Gateway Interface. Cuando publica una pregunta sobre un problema de CGI que está teniendo, ya sea en una lista de correo o en un grupo de noticias, asegúrese de proporcionar suficiente información sobre lo que sucedió, lo que esperaba que sucediera y cómo lo que sucedió realmente era diferente, qué servidor Youre corriendo, qué idioma su programa CGI estaba en, y, si es posible, el código ofensivo. Esto hará que encontrar su problema mucho más simple. Tenga en cuenta que las preguntas sobre problemas CGI nunca deben publicarse en la base de datos de errores de Apache a menos que esté seguro de que ha encontrado un problema en el código fuente de Apache. Copyright 2013 La Fundación Apache Software. Licenciado bajo la Licencia Apache, Versión 2.0. Instalado como CGI binario PHP funciona con Apache y suEXEC como este: (Suponiendo que suEXEC ya está instalado y funcionando) Instale PHP como binario CGI (por ejemplo en / usr / local / bin / php) Compilar con --enable-force-cgi-redirect) Crear un enlace dentro del directorio cgi-bin para hacer php-cgi accesible: cd / usr / local / apache / cgi-bin ln / usr / local / bin / php php Archivo httpd. conf: AddHandler php4-script. php Acción php4-script / cgi-bin / php ltVirtualHost 123.456.789.0:80gt Ejemplo de usuario Grupo examplegroup. Los scripts PHP ahora se llaman bajo el identificador de usuario de exampleuser y group-id de examplegroup. Un consejo para los usuarios de Windows Sólo un consejo para usted, así que no cometer el mismo error que yo: Acabo de descubrir que PHP primero parecen buscar en php-directory para php. ini, y si ese archivo no existe, Se ve en el directorio de Windows. Cambié el nombre del archivo php. ini-dist por php. ini y lo copié en mi directorio de Windows, y luego modifiqué el infame cgi. forceredirect 0 en el archivo php. ini ubicado en el directorio de Windows, para que funcione. Pero no lo hizo porque se lee desde el php. ini original - Así que cuando he eliminado este php. ini cosas comenzaron a trabajar de nuevo Una de las razones más comunes por las que se obtiene No se especifica ningún archivo de entrada (AKA el segundo mensaje de error más útil en el mundo ) Es que se ha establecido docroot (en php. ini) con un valor que corresponde a DocumentRoot definido en la configuración de apache. Esto es lo mismo para otros servidores web. Por ejemplo, en lighttpd, asegúrese de que el valor server. document-root sea el mismo que el definido como docroot en php. ini.