Securing Web Application
Advances in web technologies coupled with a changing business environment, mean that web applications are becoming more prevalent in corporate, public and Government services today. Although web applications can provide convenience and efficiency, there are also a number of new security threats, which could potentially pose significant risks to an organisation's information technology infrastructure if not handled properly.
Today traditional network security measures and technologies may not be sufficient to safeguard web applications from new threats since attacks are now specifically targeting security flaws in the design of web applications. New security measures, both technical and administrative, need to be implemented alongside the development of web applications.
Common Vulnerabilities in Web Applications
The Open Web Application Security Project (OWASP) is a worldwide volunteer community aimed at making web application security "visible", so that people and organisations can make informed decisions about application security risks.
From the technical perspective, OWASP has listed ten most critical web application security flaws. Application developers should be aware of these common security flaws and develop programming standards that avoid such problems in the coding phase. A good reference is the OWASP Guide to Building Secure Web Applications.
1.
Cross Site Scripting (XSS)
The potential threat of XSS is allowing the execution of scripts in the victim's browser that could hijack user sessions, deface websites, and possibly introduce worms, etc. This flaw is caused by the improper validation of user supplied data when an application takes that data and sends it to a web browser without first validating or encrypting the content.
The potential threat of XSS is allowing the execution of scripts in the victim's browser that could hijack user sessions, deface websites, and possibly introduce worms, etc. This flaw is caused by the improper validation of user supplied data when an application takes that data and sends it to a web browser without first validating or encrypting the content.
2.
Injection Flaws
The potential threat from this flaw is that an attacker could trick the application into executing unintended commands or into changing system data. Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query.
The potential threat from this flaw is that an attacker could trick the application into executing unintended commands or into changing system data. Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query.
3.
Malicious File Execution
The potential threat to code vulnerable to remote file inclusion (RFI) is that it could allow attackers the opportunity to include hostile code and data, resulting in devastating attacks, such as a total compromise of the server. Malicious file execution attacks can affect PHP, XML and any framework that accepts filenames or files from users.
The potential threat to code vulnerable to remote file inclusion (RFI) is that it could allow attackers the opportunity to include hostile code and data, resulting in devastating attacks, such as a total compromise of the server. Malicious file execution attacks can affect PHP, XML and any framework that accepts filenames or files from users.
4.
Insecure Direct Object Reference
The potential threat here is that attackers could manipulate those references to access other objects without authorisation. A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter.
The potential threat here is that attackers could manipulate those references to access other objects without authorisation. A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter.
5.
Cross Site Request Forgery (CSRF)
The potential threat from this flaw is that it might force a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.
The potential threat from this flaw is that it might force a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.
6.
Information Leakage and Improper Error Handling
The potential threat from this flaw is that attackers can use this weakness to steal sensitive data, or conduct more serious attacks. Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems.
The potential threat from this flaw is that attackers can use this weakness to steal sensitive data, or conduct more serious attacks. Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems.
7.
Broken Authentication and Session Management
The potential threat here is that attackers might compromise passwords, keys, or authentication tokens in order to assume the identity of other users. This flaw is caused when account credentials and session tokens are not properly protected.
The potential threat here is that attackers might compromise passwords, keys, or authentication tokens in order to assume the identity of other users. This flaw is caused when account credentials and session tokens are not properly protected.
8.
Insecure Cryptographic Storage
This potential threat comes when attackers use poorly protected data to conduct identity theft and other crimes, such as credit card fraud. This flaw is due to web applications not making proper user of cryptographic functions to protect data and credentials.
This potential threat comes when attackers use poorly protected data to conduct identity theft and other crimes, such as credit card fraud. This flaw is due to web applications not making proper user of cryptographic functions to protect data and credentials.
9.
Insecure Communications
This flaw comes from the possible leakage of sensitive information over the network communication infrastructure. This is caused by a failure to encrypt network traffic when necessary to protect sensitive communications.
This flaw comes from the possible leakage of sensitive information over the network communication infrastructure. This is caused by a failure to encrypt network traffic when necessary to protect sensitive communications.
10.
Failure to Restrict URL Access
This flaw gives attackers the opportunity to access and perform unauthorised operations by accessing those URLs directly. This flaw is caused by applications that only protect sensitive functionality when preventing the display of links or URLs to unauthorised users.
This flaw gives attackers the opportunity to access and perform unauthorised operations by accessing those URLs directly. This flaw is caused by applications that only protect sensitive functionality when preventing the display of links or URLs to unauthorised users.
Administrative Measures for Securing Web Applications
The following are recommended administrative controls that may help in strengthening the security of web applications and protecting data handled by such applications.
Put in place key guidelines to provide direction on the development and maintenance of websites and/or online applications.
Put in place key guidelines on coding and development practices for web applications. Software development teams should follow a set of secure web application coding practices, designed to combat common web application security vulnerabilities.
Collect and manage sensitive information and user data in compliance with policy and regulations.
Prepare a security and quality assurance plan, and adopt quality assurance methods such as code review, penetration testing, user acceptance tests, and so on.
Perform a complete IT security audit before the final production launch of a web application, and after any major changes or upgrades to the system.
Technical Measures for Securing Web Applications
New security risks come with the benefits of deploying web applications. To tackle these risks effectively, various security controls should be considered throughout the entire development lifecycle of the project. To help understand at what point in the lifecycle a recommended security control might be relevant, this section goes through the lifecycle phase by phase and points out key security concerns that require special attention.
The Requirement Stage
At this stage, the application development team should gather together all the system and security specifications required by the various parties involved in the project. The system requirements should provide the development team with an overview on the core purpose of the application, including what the application should do and what it should not do. This information will help the development team in defining key security controls for the application.
Correctly establishing system and user security requirements will be vital in driving the design, development and testing stages, as this will increase the overall security of the web application, and ensure greater user satisfaction with the end result.
The Design Stage
The design stage involves not only design of the application in accordance with the specifications outlined in the first stage, but also defining secure coding standards, performing threat modelling, and developing a security architecture for the application.
Securing Coding Standards
Perform Threat Modelling
Design Web Application Security Architecture
Secure Coding Standards
Secure coding standards are guidelines on how developers should write the code for the application, and should include guidelines for developing secure code and for proper commenting to identify high-risk areas, data input and other interface and error handling. A number of secure coding practices have been suggested by various organisations, including OWASP and CERT.
1.
Validate all input parameters to prevent attacks such as SQL injection and cross-site scripting attacks.
Programmers should develop a centralised module to perform input parameter validation.
Programmers should check each input parameter against a strict format that specifies exactly which types of input will be allowed.
Special characters such as "~!#$%^&*[]<> '\r\n" coming from the input form should be filtered, or replaced with an escape sequence.
Client-side scripts should not be relied on to perform the necessary validation checks.
The application should only accept data containing a strictly limited and expected set of characters. If a number is expected, only digits should be accepted. If a word, only letters should be allowed. Input data should also be validated for the proper format. If an email address is expected, only letters, numbers, the "at" (@) symbol, dashes, and dots in the proper arrangement should be accepted.
Enforcing minimum and maximum length restrictions on all incoming data should also be included. This technique should be used for account numbers, session credentials, usernames, and so on. All these techniques restrict the number of potential entry points for incoming attacks.
2.
Sanitised application response.
A centralised module should be developed to perform any sanitisation. All output, return codes and error codes from calls (e.g. calls to the backend database) should be checked to ensure that the processing expected actually occurred. For example, unnecessary internal system information such as internal IP addresses, internal host names, internal directory structures, verbose error messages generated by internal server errors during a response should not be exposed on the client side. Most application/web servers allow the generation of a custom error page should an internal server error occur.
A centralised module should be developed to perform any sanitisation. All output, return codes and error codes from calls (e.g. calls to the backend database) should be checked to ensure that the processing expected actually occurred. For example, unnecessary internal system information such as internal IP addresses, internal host names, internal directory structures, verbose error messages generated by internal server errors during a response should not be exposed on the client side. Most application/web servers allow the generation of a custom error page should an internal server error occur.
3.
HTTP trust issues.
Programmers should not trust or rely on HTTP REFERER headers, form fields or cookies to make security decisions, as this type of data can be spoofed. Unless strong cryptographic techniques are used to verify the integrity of HTTP headers, do not trust these parameters coming in from a client browser. In addition, do not assume hidden parameters cannot be changed by the user, as hidden parameters can be easily manipulated by attackers.
Programmers should not trust or rely on HTTP REFERER headers, form fields or cookies to make security decisions, as this type of data can be spoofed. Unless strong cryptographic techniques are used to verify the integrity of HTTP headers, do not trust these parameters coming in from a client browser. In addition, do not assume hidden parameters cannot be changed by the user, as hidden parameters can be easily manipulated by attackers.
4.
Protect sensitive session values.
Keep sensitive session values on the server to prevent client-side modification, and do not put sensitive information in any client browser cookies. If sensitive values have to be stored in a client browser, strong cryptographic techniques should be used to protect the confidentiality and integrity of the data.
Keep sensitive session values on the server to prevent client-side modification, and do not put sensitive information in any client browser cookies. If sensitive values have to be stored in a client browser, strong cryptographic techniques should be used to protect the confidentiality and integrity of the data.
5.
Encrypt pages containing sensitive information and prevent caching.
Pages containing sensitive information should be encrypted with proper algorithms and keys such as SSL and TLS during transmission. Use signed Java applets or ActiveX to acquire and display sensitive information, and set the appropriate HTTP header attributes to prevent caching, by browser or proxy, of an individual page should that page contain sensitive information.
Pages containing sensitive information should be encrypted with proper algorithms and keys such as SSL and TLS during transmission. Use signed Java applets or ActiveX to acquire and display sensitive information, and set the appropriate HTTP header attributes to prevent caching, by browser or proxy, of an individual page should that page contain sensitive information.
6.
Session Management.
A session ID should be long, complicated, contain random numbers that are unpredictable, and it should be changed frequently during a session to reduce the duration that a session ID remains valid. In addition, a session ID should not be stored in a URL, persistent cookies, hidden HTML fields or HTTP headers. Programmers can consider storing session IDs in a client browser's session cookies. By employing SSL or TLS, session IDs can be protected from sniffing by attackers. A logout function for the application, and an idle session timeout should also be implemented. When logging off a user or timing-out an idle session, not only should the client-side cookie should be cleared (if possible), but also the server side session state for that browser plus connections to backend servers should be cleaned up.
A session ID should be long, complicated, contain random numbers that are unpredictable, and it should be changed frequently during a session to reduce the duration that a session ID remains valid. In addition, a session ID should not be stored in a URL, persistent cookies, hidden HTML fields or HTTP headers. Programmers can consider storing session IDs in a client browser's session cookies. By employing SSL or TLS, session IDs can be protected from sniffing by attackers. A logout function for the application, and an idle session timeout should also be implemented. When logging off a user or timing-out an idle session, not only should the client-side cookie should be cleared (if possible), but also the server side session state for that browser plus connections to backend servers should be cleaned up.
7.
Restrict access privileges of end-users.
Ensure that the end-user account only has specific privileges to access those functions that they are authorised to access, restricting access to the backend database, or to run SQL commands, and OS commands. When an application makes system calls to access certain programs, do not make calls to actual file names and directory paths. If attackers have access to the source code, they may uncover system-level information. Use mapping provided by the web server as a filtering layer
Ensure that the end-user account only has specific privileges to access those functions that they are authorised to access, restricting access to the backend database, or to run SQL commands, and OS commands. When an application makes system calls to access certain programs, do not make calls to actual file names and directory paths. If attackers have access to the source code, they may uncover system-level information. Use mapping provided by the web server as a filtering layer
8.
Build a centralised module for application auditing and reporting.
9.
Use the most appropriate type of authentication method for the job, to identify and authenticate incoming user requests.
Perform Threat Modelling
Building a secure application requires an understanding of the threats against that application. A threat modelling process helps to identify threats, attacks, vulnerabilities, and countermeasures in the context of your application scenario.
Threat modelling can be accomplished through these steps:
Step 1:
Identify the key security objectives.
Step 2:
Create an overview of the application by itemising the important characteristics of that application.
Step 3:
Deconstruct the application to identify the features and modules that have a security impact, and that need to be evaluated.
Step 4:
Identify all threats.
Step 5:
Identify all vulnerabilities.
Design Web Application Security Architecture
Building a secure application requires an understanding of the threats against that application. A threat modelling process helps to identify threats, attacks, vulnerabilities, and countermeasures in the context of your application scenario.
A typical web application architecture contains 3 tiers, separating the externally-facing web server from the internal application server and database server. With a tier-based architecture such as this, even if an attacker compromises an externally-facing web server from the outside, they still have to find ways to gain access and attack the internal network. This is the principle of defence-in-depth protection.
Defence-in-Depth is a practical approach to information security. The fundamental concept always centres on the idea of multiple layers of security to protect vital assets. Layers of security include input validation, database layer abstraction, server configuration, proxies, web application firewalls, data encryption, OS hardening, and so on.
The Development Stage
This is one of the most important stages in terms of mitigating security issues within the code. Observing secure coding standards certainly helps improving security and reducing the number of common mistakes that result in security breaches. In addition, performing security risk assessments during the development stage also helps to identify the security controls required.
The Testing and Quality Assurance Stage
Before any application is launched for production, the need for comprehensive testing is paramount. In addition to user acceptance tests, there are others, such as system tests, stress tests, regression tests and unit tests that are useful in validating the performance and accuracy of system functionalities. This section describes some of the tests that can be carried out in order to increase the reliability and security of the program/systems being developed.
Web Application Unit Testing
Web application unit testing is an important part of the development stage, designed to identify the vulnerabilities in a web application. Unit testing involves the testing of individual programs or modules to ensure that all internal operations of a program or module perform according to specifications. Unit testing should include tests for common security issues, such as buffer overflows, and is especially important if the module is being integrated into a "build" with other components. If no unit tests are carried out, it becomes very hard to implement an automated security testing process in the middle of the development stage.
There are a variety of tools that can help find and eliminate web application vulnerabilities, but it is important to note that these tools can only cover a small fraction of the testing needed for an effective application security program. Relying only on tools rather than focusing on improving the software development life cycle leads to a false sense of security, as automated scanning tools are limited in the types of vulnerabilities they can uncover and identify
Code Review
A peer review process, undertaken by walking through the source code, can help identify security flaws, ensure adherence to security development standards, and ensure consistency with the overall program design. Usually, development managers, system administrators and database administrators would be present to examine the workings of the source code of the application, and improvements can be suggested and recommended by all parties. In addition, by walking through the source code, hidden or secure content, such as keys and passwords, can be identified and the adequacy of protective measures thoroughly evaluated.
A number of automated code scanning tools are available in the market that may help offload some of the code-walkthrough burden. However, as with web application scanning tools, these tools may only be able to identify common errors, but not more complex security issues. These tools should therefore not be a substitute for human analysis.
Before any code review begins, the project team should define which areas of the code are considered high risk and likely to lead to a vulnerability, exposure or weakness. In general, any aspects of the code that provide access control, configuration management, auditing, logging, authentication or interface with third-party components or the operating system should be reviewed. This exercise is generally referred to as threat modelling or risk analysis and consists of analysing various aspects of the design to determine which areas of the project should be part of a security code review.
The Pre-Production Stage
An IT security audit should be performed before the production launch and after any major changes to the system. Each vulnerability fix requires updates to custom code, and it follows that each repair requires a code push that could introduce a new vulnerability. So, while there may be fewer web application vulnerabilities, the remediation process becomes more complex. Therefore, it is imperative to continuously assess the impact of each fix to maintain secure applications.
The Maintenance and Support Stage
Security is an on-going process. Security issues may still be found after the application is released to the public. Protection and detection mechanisms should be put in place to ensure the application is running securely and smoothly. Key ongoing security measures can include the following:
Application Log Review
To detect any anomaly in a web application, a log review is indispensable. Many web servers support detailed logs that capture all web requests made to the web application. By regularly reviewing the web access log and studying web requests made to the application, it is possible to gain significant insight into the safety of the web application. If abnormal URLs are uncovered, it is very likely that some kind of web attack have taken place.
In addition, application owners can also request the implementation of application audit trails for the web application. Exception reports to undefined requests, or abnormal transactions should be generated and reviewed regularly.
Version Control and a Separate Environment for Development
The integrity of an application should be maintained with appropriate security controls such as a version control mechanism and the separation of environments for development, system testing, acceptance testing, and live operation. The production and development environments should be kept synchronised. Application development staff should not be permitted to access production information unless absolutely necessary.
Web Application Firewalls
Standard firewalls can help restrict or permit network access to network ports authorised by the organisation. Although application proxy firewalls exist, they cannot understand the specific content of all web applications being run by the organisation.
Usually, web application firewalls are installed in front of a web server. Like standard firewalls, these can be software or hardware based, but always with the purpose of protecting the web server from attack. There are two protection approaches:
1.
Signature based: The web application firewall identifies attacks by checking web request against an "attack signature" file.
2.
Abnormal behaviour based: The web application firewall identifies attacks by detecting abnormal traffic patterns.
A Checklist For Web Application Acceptance
Upon acceptance of the web application, an independent security assessment should be conducted to ensure full compliance with company policy or project security requirements by assessing the web application as well as the source code. This assessment is an essential component for all web application projects that may be outsourced to external development houses. Test cases on security controls required in the project initiation phase should also be included in the User Acceptance Test.
Security should be considered as early as possible in the project initiation phase. Security expectations and requirements - in particular, requirements on the authentication mechanisms, input validation and audit trails - must be communicated to development vendors.
The following are some examples of areas that might be examined in an assessment of web application security:
Identification and Authentication
1.
How are users and processes authenticated?
2.
Is the authentication process implemented in accordance with specifications and in compliance with the security policy of the organisation?
3.
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?
4.
Is the application required to authenticate each and every session?
Data Protection
1.
Is the data protection mechanism implemented in accordance with the security policy of the organisation?
2.
Is all data protected adequately at rest? Is all data protected adequately in transit?
3.
If encryption is used, how is the encryption handled? Does encryption handling comply with the overall security policy of the organisation?
Logging
1.
Is the audit trail logging mechanism implemented in accordance with specifications?
2.
Are the application audit records vulnerable to unauthorised deletion, modification or disclosure?
Error Handling
1.
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
1.
Are segregation of duties and least privilege principles enforced?
2.
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?
3.
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.
Guidelines for Web Application Owners for Preventing Web
To avoid being exploited by attacks targeting web applications, certain technical measures can be implemented to help prevent and detect any abnormal incidents.
A proper incident handling procedure should be implemented. In many cases, it is third parties like customers who first report that the website hosting a web application might have a problem. In the case of a phishing attack, the fraudulent website is often hosted under a different jurisdiction. Operators of the genuine website can only warn customers not to visit fraudulent websites which might look similar to the legitimate site. Another possible action is contacting the Internet Service Provider hosting the fraudulent website in the hope that they can take it offline.
Studying the system and application logs may help in uncovering web attack incidents. For example, a victim's page or website needs to include a way to trace pages that have been exposed to any cross-site scripting attack, and be able to clean up any infected pages so as to stop further infection.
An attacker needs to be able to insert malicious code into a victim's web application before attacks like cross-site scripting worms or similar are successful. To prevent this from happening, malicious user input into the web applications needs to be sanitised. In addition to removing special characters from allowed input character sets, and encoding dynamic output elements, a white-list approach should be followed. In a white-list approach, only inputs matching pre-defined patterns are allowed through, while all others are filtered out.
An incident detection and monitoring mechanism to expose, contain and prevent security incidents should be established. System logs and other supporting information should be retained and archived to provide proof when tracing back through security incidents. To prepare for a worst case scenario, a security incident handling and reporting procedure applicable to the web application should be established, documented and maintained.
Awareness training should be conducted for all staff to ensure that they are fully aware of handling and reporting procedures for security incidents.
Immediate follow-up action is required for any suspected system intrusion, and should follow procedures laid out in the security incident handling and reporting guidelines.
Web-based information systems should be periodically evaluated by auditors employed by an independent, trusted third party to determine whether the minimum set of controls required to contain risks at an acceptable level is being maintained.
Security risk assessments should also be performed prior to any major enhancement or change to web systems and/or web applications.
Possible preventive measure is hiring outside professionals to periodically check for the existence of fraudulent websites over the Internet. Customers and website users can be notified immediately as soon as fraudulent websites posing as the legitimate site are discovered. This can help minimise phishing attack incidents.
Information For:
