Quelles sont les causes « violation de la politique suexec » lorsque Perl est appelé via inclure côté serveur?

Question

Je travaille sur un script Perl qui est appelé à partir d'un côté serveur incluent sur un serveur Apache 2. Le script affiche la page « Internal Server Error » générique plutôt que de me montrer l'erreur réelle. Quand je vérifie le journal des erreurs Apache, je vois ces messages:

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/

Comment puis-je obtenir un script Perl pour montrer une erreur plutôt que "Internal Server Error"?

Mise à jour:

Je aurais dû poser une autre question pour cela, parce que j'ai appris depuis que ce fait envoyer des erreurs au navigateur ( merci brian ):

use CGI::Carp qw(fatalsToBrowser);

Cependant, si le problème est avec Apache config plutôt que le script Perl, l'erreur ne sera pas envoyé au navigateur, car le code Perl n'est pas interprété. Dans ce cas, on peut dire que je suis une erreur Apache éprouvais (plutôt que d'une erreur Perl) en raison de cette ligne:

 suexec policy violation: see suexec log for more details

Cela se produit lorsque Apache est en cours d'exécution en mode Suexec (qui semble être commune pour l'hébergement partagé). Je ne sais pas ce qui a été changé exactement à l'origine de cette erreur, mais c'est ce que je suis en train de trouver.

Answer 1

Probablement que vous utilisez l'hébergement mutualisé et vous avez ce problème parce que votre répertoire scripts ou le fichier script dispose d'autres droits que 755.

Voici un cas traduit du néerlandais.

Answer 2

Utilisez CGI :: Carp fatalsToBrowser l ' de.

 use CGI::Carp qw(fatalsToBrowser);

Vous pouvez également voir mon Dépannage des scripts CGI Perl .

Dans le message d'erreur, je suppose que vous n'êtes pas autorisé à exécuter des scripts CGI à partir comprend côté serveur. Quelle est la version de votre Apache vous utilisez? Si c'est un vieux apache, voir les suexec docs pour apache 1.3 , ou si il est une nouvelle apache, consultez les docs suexec pour apache 2.0 .

Answer 3

Il est pas pour la convivialité, mais souvent pour la sécurité que nous ne montrons pas aux utilisateurs l'erreur exacte lorsque l'utilisateur ne peut rien faire à ce sujet. Par exemple, imaginez qu'un serveur arrière est indisponible. Que puis-je, en tant qu'utilisateur, faire pour résoudre ce problème dans votre application web?

Dans certains cas, les messages d'erreur contiennent des informations utiles, comme « erreur SQL:. Syntaxe illégale apparié ' ». Si l'utilisateur a entrée une citation dans leur entrée, cette rétroaction indiquerait une vulnérabilité d'injection SQL.

D'autres messages bénins à la recherche sont mauvais pour montrer aux utilisateurs, aussi bien. La chose principale que l'attaquant veut savoir est « quelque chose de différent est arrivé. » Si l'application imprime sur une erreur pour une entrée et une autre erreur pour une autre Iinput, l'attaquant sait que quelque chose de différent qui a mal tourné, et que c'est un endroit intéressant de se concentrer.

Dans un site de production, les erreurs doivent être consignées au dossier, et, le cas échéant, téléchargeables via l'interface web - mais être très prudent pour aseptiser toute sortie du navigateur pour éviter cross site scripting. Et il devrait y avoir aucune option soumis par les utilisateurs de reconfigurer entre le débogage et la production (ne pas le contrôler via un paramètre POST ou CGI, mais par une option de fichier de configuration).

Answer 4

Cela pourrait être 3 facteurs:

1. les autorisations au niveau rwx mal réglé (exécution / niveau writeness)
2. UUID / GUID ne correspondent pas aux paramètres Apache
3. Combinaison de 2 ci-dessus.

Vérifier apache suexec + errorlog pour plus de détails