I’ve taken over supporting a time- and expense-entry system. Apache’s CGI. CGI programs are written in bash 🙂 I’m going to add some features into it and exposing it out to many more users, but prior to that wanted to get some thoughts on what else needs to be looked-at first in terms of security, holes, CGI gotchas, &c.
Not a lot of users, but the application performs really well and is written consistently and very heavily in bash. Pages look like ASP/JSP/PHP format with heavy use of here docs. Parameters are inferred from a separate C program and session info is stored at the DB (MySQL) and SQL parameter/injections are escaped properly.
I’m torn as if this stack really needs to be stripped out or not? What would one need to look out for in a whole application written for the most part directly in bash?
Think like a malicious user who’s privy to all the code in the system (obscurity in your code is no defense!-): how would you subvert the system?
Could you supply malicious headers, URLs, or query parameters thereto, such that your maliciously injected text ends up being gobbled up by the system and used to attack the filesystem, the database, and so on? SQL injection is one avenue of attack, but there may be others, unless the system’s really paranoid about dealing with EVERYthing it receives from the user — not use it (without very careful checking and scrubbing!) to form filenames, system commands, and so on, not store it for later execution, and so forth.
There’s nothing really bash-specific or cgi-specific about it — just the common or garden form of paranoia you need to ensure security (and without even such crutches as perl’s “taint” concept — which doesn’t exactly solve everything [[far from it of course]] but it sure saves you some effort;-).