Website Security Without Breaking the Bank?

An anonymous reader writes "I do my own Web design and have a few websites — MySQL, PHP, CSS, HTML, that kind of thing. It's simple, amateur stuff, but I would love to have some reasonable ways to assess their security myself and patch the big holes, or possibly enlist someone to do 'white hat' work to assist me. I have absolutely no idea how to proceed. I don't want to get mired in a never-ending paranoia-fueled race to patch holes before the hackers find them, but on the other hand, I don't want my websites to look like Swiss cheese. Right now, I wouldn't know what kind of cheese they look like: Swiss, Havarti, or hard as Parmesan. How can I take reasonable steps to protect these websites myself? What books has the community found useful? What groups (if any) can offer me inexpensive white-hat hacking that won't end up costing me a first-born child? Or am I better off just waiting until a problem arises and then fixing it?"

Automate it

[jrozzi]

There are some good automated security scanners out there. For instance: Nesses/Nikto, WebScarab with proxmon, portswigger, and you can even go as far as using 3rd party companies such as HackerSafe.com or SecurityMetrics.com. Even though this doesn't give you a 100% fail-safe security scenario (*cough* nothing does and probably never will), it at least helps decrease the chances of common and even some more uncommon attacks such as SQL injections, overflows, man-in-the-middle attacks, etc. You also obviously have to write secure code and keep all of your software up to date (especially open source software). This is not only true for PHP, but for all programming languages. You should also try using BSD since you have a LAMP system. Some other good sources of information: http://www.webappsec.org/ [webappsec.org] http://www.owasp.org/ [owasp.org] Hope this helps...

Re:Better tools, good process, learning from other

[commanderfoxtrot]

You can write insecure websites using pretty much any tools, but if you're using MySQL and PHP, especially if you're using other peoples code in your app, you're probably going to end up with a security nightmare, regardless of how hard you try.

That's the problem.

Most of the pros on here can write good-quality, secure code, in PHP, RoR, whatever.

It's the external libraries which are the gap. For example, look at phplist, which is used in many places [softpedia.com]. Now, every installation of it needs to be upgraded. Now. Right now.

Unless you're a 100% fulltime sysadmin, you haven't got the time to be reading the security lists hourly and upgrading phplist etc when required.

The OP is really asking: how do I make sure phplist and the other hundred Ruby gems or PHP add-ins are up-to-date and safe? And keep them that way?

PCI certified ..

[viralMeme]

"the PCI DSS is a security standard for payment card industries. Their documents go into detail on the specific vulnerabilities that needs to be addressed to be certified. For example they mention specific flaws (say cross-site scripting), and also measures to protect data if an attack succeeds"

All the PCI standard does is set down a number of criteria to be PCI certified. In the real world this provides no defense against getting hacked, as Heartland Payment Systems learned to their regret.

"This document lists specific flaws that are known to be a problem, and had better be comprehensive since these are the standards banks are measured against. "Comprehensive" is perhaps a gross understatement, but it will give you an idea of the aspects to watch out for"

If you need this PCI standard to tell you how to secure your network, then perhaps you shouldn't be in the security industry. Lets see what the 'document' has to teach us that we don't already know:

.. install a firewall, don't use default passwords, encrypt the transmission data, assign a unique ID to each user, restrict physical access to cardholder data, track all access [pcisecuritystandards.org] to network resources and ..

WOW, I would never have thought of that. But how does one go about getting PCI certified, well there is self assessment or an 'on-site data security assessment' by a suitable qualified security assessor [braintreep...utions.com] (QSA). How do you get QSA qualified, by filling in a bunch of forms .. :)

Re:80-20 rule

[Man Eating Duck]

I don't think it is usually done

When I think about it it's probably not very prudent to do, since you'll never be able to fine-tune it enough for most uses. You'd never know either if the customer didn't contact you in other manners.

I would hate for my client to lose business because legitimate customers can't access their site. I'll just put my faith in the provider's update routines and my own code :)

Your enemy is the user.

[Arancaytar]

Or rather, the input your user gives you.

Let's leave aside non-web vulnerabilities for now - of course you'll want to use SFTP and SSH instead of unsecured FTP or Telnet to connect to your server, and HTTPS for your web admin panel, but these are outside the scope of the actual website - they're for your host to deal with.

When you write any kind of dynamic website, user input is the threat. Your website communicates via text with other layers such as the database (SQL) or the users' browser (HTML). Your two biggest risks are SQL injection (where user input breaks out of SQL quotes) and Cross Site Scripting/Request Forgery (where one user's input is executed as Javascript in another user's browser).

Another threat is performing actions (such as deleting/editing content) via GET requests, which will allow search spiders or content prefetchers to wreak havoc.