Ci sono problemi di sicurezza per gli script CGI scritti in puro bash?

2

Sto lavorando a un progetto che userebbe bash e FastCGI per creare uno pseudo-CMS.

C'è qualche tipo di problema di sicurezza a cui prestare attenzione all'interno di FastCGI stesso tramite uno script bash ben scritto (ad esempio buffer overflow e simili)?

    
posta Dwight Spencer 08.01.2014 - 07:02
fonte

2 risposte

3

Gli overflow del buffer non sono realmente rilevanti per bash. Qualcosa che fai deve prendere in considerazione è la convalida dell'input. È necessario convalidare tutti gli input dell'utente per prevenire qualsiasi forma di iniezione.

Dovresti dare un'occhiata alla guida ai test OWASP in quanto coprono tutti i tipi di vulnerabilità pertinente alle applicazioni web. È in gran parte indipendente dalla lingua, anche se gli esempi potrebbero essere più incentrati su linguaggi di programmazione reali progettati per scrivere applicazioni web.

P.S. Ho davvero bisogno di sapere: Perché stai scrivendo un CMS in bash ?

    
risposta data 08.01.2014 - 08:16
fonte
3

. Non scrivere script CGI in puro bash. Bash è una delle lingue peggiori se coinvolge input non fidati. Dopo l'incidente di shellshock, la gente ha guardato bash più attentamente e ha notato che era assolutamente packed con problemi di sicurezza. Purtroppo, bash non è male solo perché l'interprete stesso è insicuro, anche se lo è sicuramente. Lo stesso paradigma del linguaggio stesso non è stato costruito su basi sicure, quindi gli script, anche quando seguono le migliori pratiche, sono notoriamente difficili da correggere. Mentre di solito va bene per l'uso da linea di comando, usarlo per gli script CGI è una ricetta per il disastro.

Se davvero, devi davvero scriverlo in puro bash, ti invito caldamente ad eseguire sia un'analisi statica approfondita sullo script, sia un'analisi dinamica (fuzzing). Alcuni strumenti di analisi statici che potresti voler esaminare sono ABASH , shellcheck e checkbashisms . Il terzo non è uno strumento di sicurezza, ma può aiutare a verificare la correttezza del codice. Dovresti conoscere completamente le best practice per lo scripting di shell, che non è solo limitato a "citare le tue variabili".

Dovresti anche essere sicuro di limitare il danno che il processo CGI può fare al resto del sistema. Assicurati che le autorizzazioni siano limitate e avvia il chroot del tuo processo httpd. Potresti anche voler fare uso di controlli di accesso obbligatori, come SELinux se sei su una distribuzione basata su RHEL, o su AppArmor se sei su una distribuzione basata su Debian. Sfrutta al massimo il PAM per limitare le risorse del processo. Iscriviti a varie mailing list relative alla sicurezza in modo da poter aggiornare bash al più presto ogni volta che emergono nuove vulnerabilità. Si consiglia inoltre di installare auditd e configurarlo per il controllo estensivo del sistema, nonché l'impostazione dello script su -x e l'esportazione della traccia sui log. Questo ti aiuterà a identificare i tentativi di sfruttamento molto più facilmente. Queste sono tutte tecniche generiche di hardening del server, ma devi applicarle al massimo se vuoi usare volutamente qualcosa come bash per CGI.

    
risposta data 05.04.2016 - 01:33
fonte

Leggi altre domande sui tag