Friday, March 19, 2010

Securing a webapp - Am I missing something?

Recently in an interview I was asked an open ended question "How do you secure a web app". I think this is fairly simple, and because it was an interview I kept it somewhat brief skimming a lot of detail. However it seemed to me that they wanted more then what I was giving. Not so much that they wanted more details but that they were looking for me to touch on some point I missed. In the interest of expanding my skills, let me give you a list of what I covered, and you can tell me what I am missing.


I. Secure the server

A. Make sure your using a secure OS - Personally I am a RedHat Enterprise Linux Fan

B. Secure the Server

i. Install Tripwire

ii. Monitor Everything

iii. Use a firewall

iv. Eliminate unused services

v. Run all services as non-privileged users

vi. Use SELinux

vii. Restrict file permissions

1. Particularly on things like the uploadable content directory!

2. Use ACL's not standard linux permissions

II. Secure the aplication service (I like Apache/Tomcat)

A. Clean your configs

i. Do not load modules you don't use - see services above

ii. Turn off indexing services (directory browsing)

iii. If you can turn off SSI (Server Side Includes)

iv. If you can turn off follow symlinks

v. If you can turn off old school CGI execution

- Get the point if you don't use it turn it off

vi. When in doubt

Order Deny, Allow

Deny from All

vii. Use mod_security when possible

viii. Use SSL whenever possible (Always) and use mod rewrite to direct users to the secure site.

ix. Turn off listening on ports you don't use (80) - and firewall them too.

x. Do not use .htaccess files

1. If you must use .htaccess files for distributed administration read them in to the appropriate conf.d config as an include.

xi. Cut the default time out in half (or more) to reduce DoS effectiveness.

xii. Eliminate unsolicited information

1. Set server signature to off

2. Set server tokens to prod

B. Actually look at your logs - that is what logwatch is all about

C. Create custom error files - Indeed this is as much a security thing as it is a branding thing. Standard pages are just cheep, like your company does not take the effort or even care about your experience and any issues you may be having.

D. If you can try out mod evasion, or if you only server a specific geographic region, try mod geoip to server specific content, including thank you but we have nothing for you static content. - OK I may have forgotten to mention this one in the interview.

E. Eliminate cross site scripting (xss and csrf are handled similarly)

III. Secure the application level

A. PHP

i. If possible set globles to off (I think is the php.ini line is reisterglobles) - there is (usually) no need for this and end users should not be able to set your variables!

ii. Initialize your variables - see above

iii. Set safe mode to on

iv. Set disclosure to off (expose_php I think)

v. Set display errors to off

vi. Turn on log errors (this may be the default already)

vii. Turn off or restrict administration pages

B. Tomcat - This is just a repeat of securing Apache

i. Run as a restricted user

ii. Make sure your tomcat user (and group) own the catalina_home directory.

iii. Don't allow access to contexts you don't use

iv. Don't serve directory indexs

v. Don't tell people what kind of application server your running - let alone the version!

vi. Use custom error pages

vii. Use ssl

viii. Log and read those logs

ix. Don't allow communication to anything but YOUR webservers

IV. Secure the database - There are so many DB's I am not going to go into to detail but

A. Use good passwords

B. Use restricted users

C. Make sure those users can only connect from YOUR app servers

i. And restrict who can see this server at all!! If it is closed to everyone not on your DB server VPN then you are less likely to have to deal with a direct attack!)

V. Secure the application

A. When possible use separate restricted DB users for each task. If you need to insert then do so with a user that can only insert, same with update, delete, and query.

B. Clean user inputs and guard against SQL injections.

C. Don't let users see your errors! - Capture errors and report them!

D. And don't write inherently insecure applications



Summery

- Close your ports

o Protect your system against EVERYONE and then open some ports for some peoplE. The front end web servers need to be a bit more flexible on port 443.

- Turn off stuff you don't use

- Restrict permissions

o And use ACL's there is no need for a top level directory to be more permissive then a bottom level directory or to be limited to just one user/group

- Don't let your users see anything behind the Curtain - obfuscate everything your can.

- Check your logs

o Use monitoring applications

- Update and patch




So oh great community of mine - what am I missing?


1 comment:

  1. Good point from David Huerta via Face Book - don't store sensitive information in clear text in your database.
    1) Don't be stupid and store clear text passwords in the database.
    2) Pass creditcard information through to your service provider. You should never store this information. Your service provider (even paypal) will return a transaction record ID you can use to track the payment.

    ReplyDelete