Application security 101
Modern site security is not what it used to be. While today’s attacks are generally based on the evolution of old principles, the level of sophistication and automation is mind blowing.
With everyone reusing frameworks and CMSs to build their sites all it takes is one vulnerability in one of these frameworks and you could have millions of servers exploited overnight.
To coin an old industry comparison, you can draw a lot of parallels between the physical security of a car and the security of a web application. There is never a 100% guarantee of stopping someone who is truly determined to gain access to your web application. A common misconception is that security is a problem that can be fixed by just throwing money at it. A higher price tag is no guarantee of a higher level of security. This does not mean that putting the time and effort into application security is wasted. It is my opinion that businesses should focus more on the experience, customer care and trustworthiness of a security service instead of focusing on price and the false hope some “application security” companies try to advertise.
I have devised a quick cheat-sheet that I tend to refer to whenever these conversations arise. It is by no means exhaustive however I believe it is a great starting point. You can then continue on to owasp.org. (The Open Web Application Security Project)
1. For any libraries, frameworks and CMSs you use make sure to subscribe to their security and mailing list. Keeping up to date with the latest updates and information is a much more valuable strategy than leaving it to bit-rot, unchecked for 2 years, spelling an obvious future ass biting!
2. Restrict everything. Though it may be convenient in the short-term, this is how system access is persisted and how they escalate privilege once it is achieved. Specific examples include “chmod 777 website” and “grant all on *.* to ‘wordpress’” and in general, a whitelist should always be used over a blacklist.
3. Application firewalls exist! They typically sit between a service (web server, database server, etc.) and inspect the requests coming in to sanitise them. Make use of them wherever possible. Examples include: GreenSQL and: mod_security. However these are not to be used in exchange of good application security practises. They can, however, be a great addition in many circumstances.
4. Traffic Cleansing has certainly taken off in the past couple of years. The big CDN providers all sustain a competitive offering in that area. This is usually accomplished by routing incoming requests through a 3rd party provider so they can run analysis on the request and determine if it is malicious. This can prevent a large amount of attacks getting close to your server whilst providing DDOS protection and site acceleration.
5. If your submitted user data is confidential then you should schedule a full penetration-test. A pen-test can be carried out internally or by 3rd party to expose any potential vulnerabilities. Services range from automated scans to full manual red-team testing. Make sure to get quotes from a couple of companies and talk to them to find out exactly what they’re actually providing as there are a huge range of services available.
6. Traffic localisation is often an undiscussed tactic but can provide huge benefits. Consider whether users in China, Russia, and Eastern Europe need direct access to your site. If not then blocking their requests at the source can prevent a large proportion of conceivable attacks ever getting close to your server.
Unfortunately this topic is extensive and complex however I have tried to keep this as short as possible. If you would like to continue reading about this subject then please journey onwards to owasp.org. I highly recommend OWASP Appsec Tutorial Series and OWASP Top Ten Project sections. If you feel you would like to talk to someone about it in more detail please feel free to give us a call on 01252 560565 and we would be happy to discuss this further.