Are there any security concerns for CGI scripts written in pure bash?

Question

I'm working on a project that would use bash and FastCGI to create a pseudo-CMS.

Are there any kind of security concerns to watch out for within FastCGI itself over a well written bash script (for example buffer overflows, and the like)?

Answer 1

Buffer overflows aren't really relevant to bash. Something you do need to take care of is input validation. You need to validate all user input to prevent any form of injection.

You should have a look at the OWASP Testing guide as they cover all sorts of vulnerabilities relevant to web applications. It's largely language independent although the examples might be more focused on real programming languages designed to write web applications.

P.S. I really need to know: Why are you writing a CMS in bash?

Answer 2

Yes. Do not write CGI scripts in pure bash. Bash is one of the worst languages if it involves untrusted input. After the shellshock incident, people looked at bash more carefully and noticed it was absolutely packed with security issues. Sadly, bash isn't just bad because the interpreter itself is insecure, though it most certainly is. The very paradigm of the language itself was not built upon a secure foundation, so the scripts, even when following best practices, are notoriously hard to get right. While it's usually fine for command line use, using it for CGI scripts is a recipe for disaster.

If you really, really have to write it in pure bash, I strongly urge you to both run extensive static analysis on the script, as well as dynamic analysis (fuzzing). A few static analysis tools you may want to look at are ABASH, shellcheck, and checkbashisms. The third is not a security tool, but it can help test for code correctness. You should be completely familiar with best practices for shell scripting, which isn't just limited to "quote your variables".

You should also be sure to limit the damage the CGI process can do to the rest of the system. Make sure permissions are tight, and chroot your httpd process. You might also want to make use of mandatory access controls, like SELinux if you are on a RHEL-based distro, or AppArmor if you are on a Debian-based distro. Make the most use of PAM as possible to limit the process' resources. Subscribe to various security-related mailing lists so you can upgrade bash ASAP whenever new vulnerabilities come out. You may also want to install auditd and configure it to extensively audit the system, as well as setting the script to -x, and exporting the trace to logs. This will help you identify exploitation attempts much more easily. These are all generic server hardening techniques, but you have to apply them to the fullest extent if you are going to willfully use something like bash for CGI.