Quali sono le cause “violazione delle norme suexec” quando Perl è chiamato tramite lato server include?

Question

Sto lavorando su uno script Perl che si chiama da un lato server comprendono su un server Apache 2. Lo script sta visualizzando la pagina generica "Internal Server Error", piuttosto che mi mostra l'errore effettivo. Quando controllo il log degli errori di Apache, vedo questi messaggi:

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/

Come faccio ad avere uno script Perl per mostrare un errore piuttosto che "Internal Server Error"?

Aggiornamento:

Avrei dovuto chiedere una domanda separato per questo, perché ho imparato che questo non di inviare gli errori al browser ( grazie brian ):

use CGI::Carp qw(fatalsToBrowser);

Tuttavia, se il problema è con la configurazione di Apache, piuttosto che lo script Perl, allora l'errore non verrà inviato al browser perché il codice Perl non viene interpretata. In questo caso, possiamo dire che sto vivendo un errore di Apache (piuttosto che un errore di Perl) a causa di questa linea:

 suexec policy violation: see suexec log for more details

Ciò si verifica quando Apache è in esecuzione in modalità suexec (che sembra essere comune per l'hosting condiviso). Non sono sicuro di cosa esattamente è stato cambiato per causare questo errore, ma questo è quello che sto cercando di scoprire.

Answer 1

Probabilmente si sta utilizzando hosting condiviso e si ha questo problema perché la vostra directory script o file script non hanno altri diritti rispetto 755.

Qui è uno caso tradotto da Olandese.

Answer 2

fatalsToBrowser 's CGI :: Carp .

 use CGI::Carp qw(fatalsToBrowser);

Si potrebbe anche voler vedere la mia script CGI Perl Risoluzione dei problemi .

Dal messaggio di errore, sto cercando di indovinare che non ti è permesso di eseguire script CGI dal lato server comprende. Quale versione di Apache sono in esecuzione? Se si tratta di un vecchio apache, vedi la documentazione suexec per Apache 1.3 , o se si tratta di un apache più recente, vedere la documentazione suexec per Apache 2.0 .

Answer 3

Non è per facilità d'uso, ma spesso per la sicurezza che non ci mostriamo agli utenti l'errore esatto in cui l'utente non può fare nulla al riguardo. Per esempio, immaginate che un server back-end non è disponibile. Cosa posso, come utente, fare per risolvere che nella vostra applicazione web?

In alcuni casi, i messaggi di errore contengono informazioni utili, come "Errore SQL:. Sintassi illegale senza pari '". Se l'utente doveva inserire una citazione nella loro ingresso, questo feedback indicherebbe una vulnerabilità di tipo SQL injection.

Gli altri messaggi benigni alla ricerca sono un male per mostrare agli utenti, pure. La cosa fondamentale che l'attaccante vuole è conoscere "qualcosa di diverso è accaduto." Se l'applicazione stampa fuori un errore per un ingresso e un altro errore per un altro IINPUT, poi l'attaccante sa che qualcosa di diverso è andato storto, e che questo è un luogo interessante per mettere a fuoco.

In un sito di produzione, gli errori devono essere registrati su file, e, se del caso, scaricabile tramite l'interfaccia web - ma essere molto attenti per disinfettare qualsiasi output al browser per evitare cross site scripting. E non ci dovrebbe essere nessuna opzione inviati dall'utente riconfigurare questo tra il debug e la produzione (non controllarlo tramite un parametro POST o CGI, ma da un'opzione di file di configurazione).

Answer 4

Questo potrebbe essere di 3 fattori:

1. livello di autorizzazioni rwx impostato sbagliato (esecuzione / livello writeness)
2. UUID / GUID non corrispondono impostazioni di Apache
3. La combinazione di 2 di cui sopra.

Controlla Apache suexec + log degli errori per i dettagli