Lo que causa “violación de la política suexec” cuando Perl se llama a través del lado del servidor incluye?

Question

Estoy trabajando en un script en Perl que se llama desde un lado del servidor incluyen en un servidor Apache 2. El guión está mostrando la página genérica "Error interno del servidor" en lugar de mostrarme el error real. Cuando compruebo el registro de errores de Apache, veo estos mensajes:

unable to include "/foobar/index.pl" in parsed file /home/foouser/domains/foosite.com/public_html/foobar/index.shtml, referer: http://www.foosite.com/foobar/
suexec policy violation: see suexec log for more details, referer: http://www.foosite.com/foobar/
Premature end of script headers: settings.pl, referer: http://www.foosite.com/foobar/

¿Cómo consigo un script en Perl para mostrar un error en lugar de "error interno del servidor"?

Actualización:

Debería haber hecho una pregunta separada para esto, porque he sabido que este hace enviar errores al navegador ( gracias Brian ):

use CGI::Carp qw(fatalsToBrowser);

Sin embargo, si el problema es con la configuración de Apache en lugar de la secuencia de comandos Perl, entonces el error no se enviará al navegador ya que el código Perl no está siendo interpretado. En este caso, podemos decir que estoy experimentando un error de Apache (en lugar de un error de Perl) a causa de esta línea:

 suexec policy violation: see suexec log for more details

Esto ocurre cuando Apache se ejecuta en modo Suexec (que parece ser común para el alojamiento compartido). No estoy seguro de qué es exactamente lo que se ha cambiado a causa de este error, pero eso es lo que estoy tratando de averiguar.

Answer 1

Probablemente está usando alojamiento compartido y usted tiene este problema porque su directorio guiones o archivo de script tiene otros derechos que 755.

Aquí está uno caso traducido del holandés.

Answer 2

fatalsToBrowser CGI :: Carp 's.

 use CGI::Carp qw(fatalsToBrowser);

También puede ser que desee ver a mi scripts CGI Perl Solución de problemas .

Desde el mensaje de error, supongo que no se le permite ejecutar scripts CGI desde el lado del servidor. Qué versión de la Apache que se ejecuta? Si se trata de un viejo Apache, consulte los documentos suexec para Apache 1.3 , o si que es un Apache más reciente, ver los docs suexec para Apache 2.0 .

Answer 3

No es por la facilidad de uso, pero a menudo para la seguridad de que no mostramos a los usuarios el error exacto en que el usuario no puede hacer nada al respecto. Por ejemplo, imaginemos que un servidor back-end no está disponible. Lo que puedo, como usuario, hacer para arreglar que, en su aplicación web?

En algunos casos, los mensajes de error contienen información útil, como "Error de SQL:. Sintaxis ilegal sin igual '". Si el usuario tenía un presupuesto de entrada en su entrada, esta información podría indicar una vulnerabilidad de inyección SQL.

Otros mensajes benignos buscando son malos para mostrar a los usuarios, también. La clave de que el atacante quiere es saber "sucedió algo diferente." Si la aplicación imprime fuera un error de uno de entrada y otro error para otro iinput, entonces el atacante sabe que algo diferente ha ido mal, y que este es un lugar interesante para enfocar.

En un lugar de producción, los errores deben ser registrados en un archivo, y, en su caso, se puede descargar a través de su interfaz web - pero tener mucho cuidado para desinfectar cualquier salida al navegador para evitar este tipo de ataque. Y no debe haber ninguna opción enviado por los usuarios a configurar esto entre depuración y producción (no controlarlo mediante un parámetro POST o CGI, sino por una opción de configuración).

Answer 4

Esto podría ser de 3 factores:

1. nivel de permisos rwx conjunto equivocado (ejecución / nivel writeness)
2. UUID / GUID no coinciden con la configuración de Apache
3. Combinación de 2 anterior.

Comprobar Apache suexec + registro de errores para obtener más información