Application Security
The internet age and globalisation of operations has seen the adoption of computing infrastructure to better facilitate business operations of organizations and people alike. In order to facilitate this, web applications are used as the primary means of accessing and manipulation of data distributed over various data centres. Despite their obvious advantages, security concerns still remain as their major hurdle towards their full adoption. What are some of these vulnerabilities and can they be addressed?
WEB APPLICATION VULNERABILITIES
A vulnerability is a weakness or hole in an application’s design that may be exploited by an attacker to cause harm to the application’s stakeholders. A stakeholder is any entity that relies on the application in any form.
The Open Web Application Security Project, a non-profit organisation dealing with web application security, lists ten vulnerabilities that plague web applications.
Injection. This is a weakness that allows the addition of untrusted data that is sent to the applications interpreter that is sent as part of a command or query. This allows the attacker to be able to access unauthorised data or execute restricted commands on the application.
Broken Authentication. This is a weakness in the authentication procedures that allows an attacker to masquerade as another entity through misconfigured session keys and passwords. This allows an attacker to assume another person’s identity temporarily or permanently.
Sensitive Data Exposure. Web applications may not properly secure user data either in transit or at rest. This will allow an attacker to steal sensitive data to commit credit card fraud, identity theft or other malicious activities.
XML External Entities (XXE). Poorly configured or older XML processors allow for execution of external XML entities within scripts. These the external entities can be used to determine applications structure and carry out attack vectors such as a denial of service attacks and internal port scanning.
Broken Access Control. Improper enforcement of what authenticated users can access and carry out on a web application can be exploited by attackers. These can be used by an attacker to view sensitive data on user accounts, modify user’s data and access sensitive files.
Security Misconfiguration. This is usually the result of using default configurations, incomplete configurations, misconfigured HTTP headers and error messages containing sensitive information. All web application dependencies such as libraries, frameworks and operating systems must be properly configured and upgraded in a timely manner to ensure the most up to date settings are used.
Cross-Site Scripting XSS. XSS vulnerabilities occur when a web application uses user-supplied input as a Cross-site output on a new web page without proper validation and sanitization. Cross site scripting allows a malicious attacker to execute JavaScript code on the user’s browser which acan be used to hijack user sessions, steal sensitive data such as login credentials and redirect users to malicious websites.
Insecure Deserialization. Deserialization is the process of converting data from a file or stream and rebuilding it into an object. Insecure deserialization is a vulnerability where untrusted or malicious data is used to exploit an application's logic to carry out attacks. It can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks or carry out remote code execution or denial of service attacks.
Using Components with Known Vulnerabilities. Components of web applications such as libraries and frameworks run with similar privileges as the application and the use of these components with known vulnerabilities can be exploited by attackers to compromise a web application. Should they be exploited they can cause untold damage to the application’s infrastructure and data and these may undermine all other security policies that have been implemented in the application.
Insufficient Logging & Monitoring. A web application needs to be constantly monitored and logged in order to prevent repeat attacks and stop attacks such as denial of service and session hijacking. In most cases the time taken to detect attacks is normally more than 200 days on average and is usually done by external parties to the target organisation.
CONTINUOUS TESTING VS PENTESTING.
Two schools of thought are primarily considered to counter web application vulnerabilities, continuous testing and pentesting. Continuous testing is the continuous testing of the application by its creators to ensure all security concerns have been addressed while pentesting is usually carried out by an external party where they attempt to circumvent the existing security policies implemented on the application. While pentesting is considered more ideal as an external party will most likely find something overlooked it is far more costly and there is a risk of sensitive data exposure to untrusted parties.
How does one optimise for continuous testing?
Continuous testing is carried out early, regularly and everywhere. In a continuous testing process, testing is done undisrupted on a continuous basis moving the software continuously from development, testing to deployment. This allows the development team to find the risk, address it and improve the quality of the final product. In order to properly secure an application, continuous testing should be carried out in every stage of the computer development pipeline. Test suites should be set up whenever the web application code changes, merges or is released. This allows the development team to run tests at specific points rather than running all the tests at once.
In order to carry this out, teams need to add additional modern testing practices in the form of minute quality checks. These checks are carried out throughout the application pipeline allowing for small sections of code in the application to be tested throughout the application’s development pipeline. Test automation should not be the first thing tacked due to test dependencies which have to be satisfied before execution. This can be solved by dividing the process into two stages: continuous integration and continuous testing. In continuous integration, rather than waiting for all developers to commit their code, the code is merged into the main branch, built and tested in a virtualized environment. This saves time in moving from development environment to testing environment. Should the test fail, the issues are reported back to the developers and the process repeated continuously until the production build is completed.
Comments