InfoSec: FAQ on Web Application Security

1. What general security precautions should I take for my web servers running on UNIX or Microsoft Windows systems?

There are a number of precautions you should take. For example, all unused services, command shells and programming language interpreters or compilers should be removed. Web servers should be configured correctly and file permissions should be granted on a need-to-know basis to authorised parties only. System and web logs should also be regularly checked for suspicious activity. In addition, the number of web user accounts that can login to web servers should be properly managed (e.g. ensure that all users select good passwords). User authentication on the web server should be protected by at least SSL/TLS to ensure that passwords cannot be eavesdropped by attackers. Two-factor authentication should also be considered if the system involves sensitive or confidential information.

The following can be observed for enhancing the security of web servers:

Configure your web server securely according to the vendor's security guidelines

Run web server processes with appropriate privilege accounts. Avoid running web server processes using full privileged accounts (e.g. 'root', 'SYSTEM', 'Administrator')

Apply the latest security patches to your web server software

Configure access rights so that server software cannot modify files being served to users. In other words, the web server software should have read-only access rights to those files

Install Host-based Intrusion Detection System (HIDS) on web servers storing or processing sensitive information to monitor suspicious activities or unauthorised creation / deletion / modification of files. Alerts and reports from the HIDS should be actively reviewed to identify security attacks at the earliest possible opportunity

Configure your web server software to prevent any leak of information such as web server software version, internal IP address, directory structure, etc.

Disable or remove unnecessary modules from your web server software

Identify application files on the web sever and protect them with access controls

When using SSL, backup the private key for server certification and protect it from unauthorised access

2. What are the most common web application vulnerabilities, and what are the common safeguards for end-users?

The following are most common vulnerabilities found in web applications:

Cross Site Scripting (XSS)

Injection Flaws

Malicious File Execution

Insecure Direct Object Reference

Cross Site Request Forgery (CSRF)

Information Leakage and Improper Error Handling

Broken Authentication and Session Management

Insecure Cryptographic Storage

Insecure Communications

Failure to Restrict URL Access

The following are security tips for end-users:

Don't login to critical web applications from a public computer

Don't cache your username and password in your workstation

Remember to logoff at the end of a session

Use different sets of logins and passwords for different web applications and services

Regularly change your passwords used in critical web applications if a one-time password is not supported

Report abnormal behaviour to the service provider immediately

Ensure that the operating system and system components like Internet Explorer (browser) are fully patched and up-to-date

Install a personal firewall as well as anti-virus software with the latest virus signatures

Don't download software or plug-ins from unknown sources

3. Are there any security tips for securing a web application?

Various security controls should be considered throughout the entire development lifecycle of the project:

Collect together the application security requirements

Adopt standards or benchmarks according to best practices

Define secure coding standards to eliminate attacks like SQL injections, and cross-site scripting

Sanitise application responses to capture all output, return codes and error codes

Do not trust HTTP referrer headers, client browser parameters, cookies, form fields or hidden parameters unless they are verified using strong cryptographic techniques

Keep sensitive session values on the server to prevent client-side modification

Encrypt pages containing sensitive information and prevent caching

Implement session management

Implement proper end-user account and access right management

Restrict access to back end databases, and running SQL and OS commands

With application system calls, do not make calls to actual file names and directory paths. Use mapping as a filtering layer

Build a centralised module for application auditing and reporting

Use the most appropriate authentication methods to identify and authenticate incoming user / system requests

Create and perform threat modelling

Design and implement a web application security architecture

Perform security risk assessment during the development stages to identify the security controls required

Enforce secure code standards execution

Perform security tests, such as stress tests, system tests, regression tests, unit tests etc.

Perform a thorough code review

Conduct a full security audit before a production launch and after any major changes to the system

Review application logs regularly

Implement version control and a separate environment for application development

Install a web application firewall

4. If web application development is outsourced, is there any checklist I can use to verify and accept the product?

The following are some examples of areas that might be examined in an assessment of web application security:

Identification and Authentication

How are users and processes authenticated?

Is the authentication process implemented in accordance with specifications and in compliance with the security policy of the organisation?

If the authentication is based on passwords, how are the user passwords being handled and stored?

Is the password handling mechanism in compliance with the security policy of the organisation?

Are there any hard-coded passwords or keys embedded in the program source?

Is the application required to authenticate each and every session?

Data Protection

Is the data protection mechanism implemented in accordance with the security policy of the organisation?

Is all data protected adequately at rest?

Is all data protected adequately in transit?

If encryption is used, how is the encryption handled?

Does encryption handling comply with the overall security policy of the organisation?

Logging

Is the audit trail logging mechanism implemented in accordance with specifications?

Are the application audit records vulnerable to unauthorised deletion, modification or disclosure?

Error Handling

How are error messages handled?

Is there any chance of an information leak that could be utilised in a subsequent attack?

Would an application failure result in the system entering an insecure state?

Operation

Are segregation of duties and least privilege principles enforced?

Have all built-in user IDs, testing user IDs, and IDs with default passwords been removed from the operating system, web servers and application itself before final production launch?

Are the system administration procedures, change management procedures, disaster recovery procedures, and backup procedures fully and clearly defined?

It must be emphasised that this checklist is not exhaustive. Depending on the security requirements and specific nature of the target web application, additional test cases or checking criteria should be included according to specific needs.

In addition, when any information system is outsourced to third party service provider, proper security management processes must be in place to protect data as well as to mitigate the security risks associated with outsourced IT projects/services.

5. What are common authentication methods?

There are three basic authentication factors (i.e. "something you know", "something you have", and "something you are") commonly referred to in an authentication system. As a way of tackling the increasing threat of identity theft, two-factor authentication for conducting high-risk e-transactions should be implemented. There are five common authentication methods; namely passwords and PINs based authentication, SMS based authentication, symmetric-key authentication, public-key authentication and biometric authentication. Details of each method is available at the e-Authentication website.

6. How can I determine an appropriate level of assurance associated with various electronic transactions and their security requirements?

A suggested process flow for business owners wishing to implement a secure e-Authentication system is available at the e-Authentication website . You can find more information here on determining the assurance levels and corresponding security requirements.

7. What are the common security risks if I decide to adopt server virtualisation, and what are the security measures to mitigate those risks?

Virtualisation technology allows one or more guest operating systems to run on top of another host operating system. Each guest operating system runs in an emulated environment which is self-contained, isolated and indistinguishable from a real machine. Without adequate protection, virtualisation may increase the security risks faced by an organisation.

8. How do intruders attack end-users via a web attack?

Key examples of major web attacks that target end-users or their computers are described below:

The 'Italian job' Web attack

In June 2007, more than 10,000 websites, including many Italian government websites, were compromised. Infected websites had a short piece of HTML "iFrame" code inserted that would redirect visitors to another website, where a malicious JavaScript would install a keylogger and a Trojan downloader program on their PCs to test and see if they could be compromised further.

The MySpace Phish / Drive-by attack

Also in June 2007, several hundred MySpace profiles were discovered injected with links to phishing sites. Users of MySpace ran the risk of being infected when they visited any MySpace profile page containing malicious JavaScript that would silently redirect them to a malicious site that would attempt to exploit a vulnerability in Internet Explorer. A commonly known proxy network bot, "flux bot", would be installed in an attempt to hide the phishing sites behind constantly changing proxy servers.

Cross-Site Scripting ("XSS") Worms

In October 2005, an XSS vulnerability in MySpace was exploited by the author of the Samy worm who was able to upload his infected XSS code to his personal profile page on MySpace. When other authenticated MySpace users viewed Samy's profile, the worm forced their web browsers to add Samy as a friend, and alter their profiles with a copy of the malicious code. The Samy worm continued to spread exponentially when a user viewed Samy's or any other infected users' profiles. More than one million MySpace user profiles were infected this way.

Other attacks

Phishing can be termed a social engineering attack whereby criminals attempt to lure unsuspecting web surfers into logging into a fraudulent website that looks like a real website, such as eBay, or the website of an online bank. Internet search engines can also help web attacks. In December 2004, the web worm Santy. A exploited a vulnerability in the bulletin board software phpBB. Instead of randomly guessing a target IP address, the worm used the Google search engine to help find new vulnerable targets in order to launch defacement attacks via the vulnerability in phpBB.

9. How can I check the authenticity of a website?

Firstly, you need to ensure that the web links that leads you to the website is obtained from legitimate publications of the website owner or other trusted sources. Do not follow the web links provided by untrusted sources (e.g. Internet mails) without careful checking.

If the website requires you to enter sensitive information, it should provide a 'server certificate' for you to verify its authenticity. You can examine the content of the certificate, the issuing certification authority (e.g. Hongkong Post CA), the validity period and whether the certificate has been suspended or revoked.

If you are in doubt, leave the website and contact the related website owner or organisation for further information.