Versione breve:
- Gli script di shell richiedono maggiore cautela con input non attendibili; ci sono pericoli inerenti.
- Gli script di shell non sono linguaggi generici e probabilmente non sono adatti per "analizzare i dati non affidabili sulle reti"
- Detto questo, gli script di shell possono fare incredibili quantità di cose e possono farlo in modo sicuro con sufficiente cura. Dovrebbe è un argomento diverso e lasciato al codificatore per determinare ...
Versione lunga:
Vedi la sezione "Injection Attacks" di questo Shell Scripting Primer . Poiché i dati vengono spesso trasmessi tramite variabili e per il comando delle righe, e poiché le righe di comando rendono globbing e analisi in modi che sono stati progettati per essere potenti ma attendibili per l'utente, è necessario prestare particolare attenzione agli script di shell (al contrario delle lingue generiche) che separa più attentamente le variabili dall'esecuzione del processo).
Considera questo script:
#!/bin/bash
echo -n "String: "
read BADE
echo $BADE
E guardami mentre lo eseguo:
$ ./foo.sh
String: hello
hello
$ ./foo.sh
String: -n hello
hello$
Si noti che nella seconda esecuzione di foo.sh, il "-n" che ho inserito come parte della stringa di input dell'utente viene trattato come un argomento della riga di comando dal comando echo. Di conseguenza, non c'è una nuova riga tra "ciao" e il prompt "$", come ci fu nella prima esecuzione di foo.sh.
Sebbene sia possibile disinfettare l'input dell'utente, farlo in bash significa usare strumenti che possono essere vulnerabili a questo tipo di manipolazione (si consideri 'echo $ INPUT | tr -d ...'). In generale, il fatto che bash non sia un linguaggio generico significa che fare qualcosa di solito richiede l'invocazione di altri programmi, e non si può pensare alla sicurezza di bash da solo, ma anche alla sicurezza di tutti i programmi che sta chiamando.
In bash, quelle sottoprogrammi che chiamano le interfacce vengono analizzate anziché definite in modo programmatico. Nella maggior parte dei linguaggi di programmazione generici, esiste una distinzione più chiara tra dati e codice. Le stringhe passate alle funzioni vengono passate come stringa, non come una serie di token che vengono analizzati per potenziali variabili di funzione prima di essere trattati come dati. Quindi, sì, bash è "meno consigliabile per alcune attività come l'analisi dei dati non attendibili sulle reti".
"Inherently less secure" non è una frase che penso debba essere usata. Ogni linguaggio di programmazione sulla faccia della terra ha punti forti e punti deboli. Se sto programmando in C, devo fare molta attenzione all'allocazione e ai limiti della memoria, perché il linguaggio non lo è. In Bash, l'allocazione e i limiti di memoria sono gestiti per me, ma devo preoccuparmi che i dati e i canali di comando siano facilmente interconnessi. E questa intervista con Guido van Rossum mostra come con Python l'interprete è stato sottoposto a controllo per problemi di sicurezza e quando è stato chiesto "quando" abbastanza è abbastanza "in termini di indurimento l'interprete ha risposto" Non è proprio così come ci avviciniamo. quella sicurezza è uno sforzo continuo ... "
Questo tipo di domande è sempre difficile perché è soggettivo. Se sei un esperto di bash, dovresti scrivere in Python, cosa che potresti non sapere? O la tua conoscenza di come funziona bash ti aiuta ad evitare le insidie? E la tua risposta sarà diversa dalla sua, dalla sua, di chiunque altro la stia leggendo. C'è gente là fuori che ha scritto incredibili server di rete in bash, senza dubbio; è possibile, quindi non dire mai che non può essere fatto.
La verità oggettiva è : conosci le tue lingue e conosci i loro pregi e difetti e scegli quello giusto per il lavoro . E prova a imparare continuamente come farlo in modo sicuro perché "la sicurezza è uno sforzo continuo".