Newsgroup: it.comp.lang.perl
Titolo: (send)mail e taint

Hola,
ho uno script che usa sendmail per mandare i dati di un form, e con la
smania della sicurezza pensavo di blindarlo un po' con il taint.
Al momento inizio con
---
#!/usr/bin/perl -w
use CGI qw(:all);
print header;
---
poi apro una pipe per inviare email, ecc...
Se metto la sheebang come
#!/usr/bin/perl -wT
mi dà Internal server error
Vorrei solo fare in modo che i dati, letti con param('dato') e con un
iterazione su l'hash %in non contengano cose birichine...
grazie dei consigli,
ciao
Salvo
-- 
§alvomi©

 iterazione su l'hash %in non contengano cose birichine...
Potresti far vedere piu` codice? Il mio sospetto e` che tu non faccia
nulla per rendere "untaint" i dati ricevuti dall'esterno.
Nel frattempo, un consiglio generico, visto che "Internal Server Error"
da solo fornisce poche informazioni (e potrebbe essere tra lo scomodo e
l'impossibile esaminare i file di log, in taluni contesti).
Aggiungi ai tuoi script, all'inizio, la riga 
  use CGI::Carp qw/ fatalsToBrowser /;
Gli errori in questo modo saranno mostrati nel browser, anziche` finire
nei log. E` consigliabile togliere questa direttiva in produzione.
ciao,
S.
-- 
Stefano Rodighiero      |  
http://larsen.perlmonk.org/blog
mailto:
lar...@perl.it
   |  Italian Perl Mongers: 
http://www.perl.it

   use CGI::Carp qw/ fatalsToBrowser /;
molto interessante, grazie.
Qui come vedi, non so dove rendere i dati "incontaminati", e per questo
mi rifiuta -T. almeno credo.
In pratica, con l'opzione non visualizza nulla nel browser, senza tutto
ok.
-- 
salvo

 l'opzione non visualizza nulla nel browser, senza tutto ok.
E` un po' scorretto dire che "rifiuta -T". L'indicazione -T, 
anzi, e` stata pienamente recepita, ed e` la causa del 
fallimento dello script. Se si accende il taint mode, come 
tu hai fatto, succedono fondamentalmente due cose:
1. I dati provenienti dall'esterno (da una form web, ad esempio)
   sono "tainted", ovvero "brutti sporchi e (potenzialmente) 
   cattivi"
2. Perl si lamentera` se dati marcati come tainted saranno 
   usati in ambiti che hanno a che fare con l'esterno.
In pratica, se manipoli variabili tainted in contesti in cui 
scrivi su disco, verso processi esterni, o cose simili (tipo una
pipe), allora Perl te lo impedisce, producendo un errore.
Fin qui il motivo dell'Internal Server Error. Resta il problema
di "lavare" i dati, ovvero di renderli untainted. Cito la
documentazione:
  The only way to bypass the tainting mechanism is by referencing
  subpatterns from a regular expres- sion match.  Perl presumes that if
  you reference a substring using $1, $2, etc., that you knew what you
  were doing when you wrote the pattern.
 
In pratica, devi scrivere una serie di controlli, sotto forma di
espressioni regolari, che verifichino che i dati che ricevi siano
effettivamente quelli che ti aspetti. Perl si accorgera` della presenza
di questi controlli, per cosi` dire, dalla loro forma, ed eseguira` il
resto del codice.
Come avrai notato, aggiungere -T ad uno script di per se` _non_ ne
aumenta la sicurezza. La sicurezza viene aumentata dal codice aggiuntivo
che devi scrivere per verificare la bonta` dei dati in ingresso. Codice
che, come effetto collaterale, tiene a bada il tainted-mode.
Tutto questo lo trovi spiegato meglio (compresi esempi di modi per
rendere untaint un dato) nella pagina del manuale "perlsec", che puoi
consultare con questo comando:
  $ perldoc perlsec


 effettivamente quelli che ti aspetti...
già, infatti dovrei fare qualcosa del genere, ma a quel punto dovrei
prevedere diverse ipotesi, se voglio usare il cgi per diversi usi, con
diverse form: controlli su email (correttezza, validità, esistenza),
date, nomi...
Pensavo a qualcosa che almeno impedisse i soli tentativi di carpire
/etc/passwd e stronzate simili.
Poi mi dedico ai controlli con le espressioni regolari.
ciao,
salvo




 estremi solo di questi ultimi, se vuoi dar loro un'occhiata.
Sě, bene, sto leggendo!
merci encore!
-- 
salvo m.