Website Security – The tough questions to ask your web developer

Website security should be a core consideration when building any website. In New Zealand there are no clear guidelines for this. Web Development in NZ is largely the wild west when it comes to security.

Website security is very difficult. Staying one step ahead of the latest techniques used by hackers is not easy. Legacy systems (particularly built in older style scripting languages (e.g. VBScript) are often difficult to fully protect. Sometimes the cost of the security measures outweigh the risk (particularly when talking Denial of Service (DDoS) attacks).

2Degree’s recent high profile case of less than ideal security turned into a PR disaster for them. The silver lining is that having been through the experience once, their web team will be very, very careful moving forward.

Assessing Risk

There is nothing more certain than the fact that your website will have a hacking attempt made on it – assuming that it has public visibility and is not excluded from Google's search results.

By and large the attacks made on websites are automated. They are often carried out by BotNets (a large number of compromised (normally infiltrated due to a virus) slave computers under the control of one or more hackers) that will trawl the Internet looking for vulnerabilities.

Top Security Risks in Web Applications

Unvalidated Input

Information from web requests is not validated before being used by a web application. Attackers can use these flaws to attack back-end components through a web application.

Broken Access Control

Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access other users’ accounts, view sensitive files, or use unauthorized functions.

Broken Authentication and Session Management

Account credentials and session tokens are not properly protected. Attackers that can compromise passwords, keys, session cookies, or other tokens can defeat authentication restrictions and assume other users’ identities.

Cross Site Scripting (XSS) Flaws

The web application can be used as a mechanism to transport an attack to the user’s browser. A successful attack can disclose the end user’s session token, attack the local machine, or spoof content to fool the user.

Buffer Overflows

Web application components in some languages that do not properly validate input can be crashed and, in some cases, used to take control of a process. These components can include CGI, libraries, drivers, and web application server components.

Injection Flaws

Web applications pass parameters when they access external systems or the local operating system. If an attacker can embed malicious commands in these parameters, the external system may execute those commands on behalf of the web application.

Improper Error Handling

Error conditions that occur during normal operation are not handled properly. If an attacker can cause errors to occur that the web application cannot handle, they can gain detailed system information, deny service, cause security mechanisms to fail, or crash the server.

Insecure Storage

Web applications frequently use cryptographic functions to protect information and credentials. These functions and the code to integrate them have proven difficult to code properly, frequently resulting in weak protection.

Denial of Service

Attackers can consume web application resources to a point where other legitimate users can no longer access or use the application. Attackers can also lock users out of their accounts or even cause the entire application to fail.

Insecure Configuration Management

Having a strong server configuration standard is critical to a secure web application. Many servers have configuration options that affect security and are not secure out of the box.

Backup Issues

Server backups either not being completed or are corrupt. Ensure that you have visibility of the backups that your provider makes.

Summary

Ensure that you have raised all of these issues with your web developer. It can be difficult to assess whether or not your developer has a good handle on security. Make sure that you discuss the measures that they have in place AND what measures they have in place in the event of a successful breach (or a PR disaster, which ever comes first).

Thanks to Leaseplan New Zealand for allowing the reprint of some of this information.