views:

84

answers:

2

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?

+2  A: 

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;-).

Alex Martelli
A: 

What is your app's exposure? Is it on the internet or only available via an intranet?

Does the app's database contain any sensitive information?

The most common issue for older apps is SQL injection. Remember to test every field that is sent to the app via a form. I think this is the number one thing you should look out for in a bash app--incoming data being used directly in SQL statements without proper escaping/quoting.

You also can worry about XSS and Session Hijacking if you want...

How maintainable is the app? Is the code clear?

Larry K
Today just on the intranet, tomorrow on exposed to the 'net. Sensitive is relative, but yes.An interesting escape mech. was used. MySQL allows to hex encode values and as such all values are hex-encoded, pretty cool I guess considering no mysql_real_escape_string()-style bash function.Code is clear, gotta admit I'm impressed.
Xepoch