What is OWASP?
OWASP stands for The Open Web Application Security Project. It is a non-profit foundation that works to improve application security for software. Through community-led projects globally, it is a great source for tools, resources, education & training for developers and technologists to secure the web and mobile applications. Read our article to learn more about the OWASP top 10 vulnerabilities with examples.
What are the OWASP Top 10 vulnerabilities?
The OWASP Top 10 is a standard for developers and web application security, representing the most critical security risks to web applications. By using the OWASP Top 10, developers ensure that secure coding practices have been considered for application development, producing more secure code. We have included OWASP top 10 risks with examples to equip the reader within the context of application security attacks.
Why is OWASP important?
OWASP Top 10 web application vulnerabilities list is released every few years in accordance with the ongoing threats due to changing threat landscape. Its importance is directly tied to its checklist nature based on the risks and their impacts on web application development. OWASP top 10 compliance has become the go-to standard for web application security testing.
For security testing based on OWASP Top 10 issues, please refer to our penetration testing services from the top menu. The following image is taken from the official OWASP source depicting changes from the previous version (OWASP Top 10 -2013) to the current version i.e. 2017.
We have included OWASP Top 10 attacks and defences in this article.
OWASP Top 10 Testing Guide
OWASP has been releasing testing guides for a few years, detailing what, why, when, where and how of web application security testing.
This includes testing techniques explained, covering the following areas:
- Manual Inspections & Reviews
- Threat Modelling
- Source Code Reviews
- Penetration Testing
OWASP Top 10 Testing tools and processes that help identify vulnerabilities and fix the risks include:
- Web Application Penetration Testing
- Source Code Reviews
- Manual Inspections & Reviews
What are the OWASP Top 10 Application Security Risks? How to prevent Web Application Attacks?
Injection flaws in the security world are one of the most famous vulnerabilities. Injection flaws such as SQL, NoSQL, OS, LDAP, HTML, JS occur when untrusted data or untrusted input is sent to an interpreter as part of a query or a command. If it’s sent as a query, then it’s known as script injection (SQL, HTML). If it’s sent as part of a command then it is known as command injection (for example, OS, LDAP). Due to the lack of strict input validation on the server-side, malicious input can make way as a query or command to enumerate backend information.
Due to the attractiveness of databases containing secret information, unfortunately, SQL injection attacks have been a very common attack vector in the recent past.
An example of SQL injection vulnerability would be UNION or Blind SQL injection attacks to enumerate information from the database. In the case of OS command injection, some of the useful commands are whoami, uname -a (linux), ver (windows), netstat, ping, etc for initial information about the underlying system. Further exploitation is performed by attackers leading up to compromise by initiating connections to attacker owned systems outside, or escalating privileges on the underlying system.
How do you prevent injection flaws?
The core concept behind injection flaws is the lack of input validation and sanitisation of data used by the application. Any input request that contains parameters as input can be vulnerable to a code injection flaw. This could be OS code injection, SQL injection or simple script injection based on the underlying code of vulnerable function in use.
To protect web applications against SQL injection attacks, it is important to separate data from commands and queries. Use of prepared statements (with parameterised queries) is how developers should write database queries. This allows to first define all the SQL code and then pass each parameter to the query, therefore, distinguishing between code and data irrespective of user input (malicious or legit).
A broken authentication vulnerability could allow an attacker to utilise manual or automatic methods to take over a user account, leading up to complete control of the underlying system. Broken authentication and session management flaws are often identified during web application penetration testing projects. These flaws relate to authentication mechanisms such as login mechanisms, keys, session tokens, or implementation flaws that may allow an attacker to compromise passwords by launching brute force attacks, take over user sessions, enumerate legitimate user information, and related implications.
Examples of broken authentication vulnerabilities
- Username enumeration based on changes observed in the application’s behaviour to identify valid usernames.
- Brute-force attacks where an attacker uses a trial and error method to guess valid user credentials using wordlists of usernames and passwords.
- Applications allowing password attacks such as credential stuffing where stolen credentials from another database are tested against your application user accounts
- Allowing default, weak or trivial usernames and passwords
- Flawed two-factor verification logic where the application fails to verify the same user during the second step of authentication mechanism
How to prevent broken authentication attacks?
Implement multi-factor authentication to prevent automated, brute force, credential stuffing attacks
- Do not allow username enumeration opportunities on forgot password, login forms, registration pages.
- Use input form such as secure captcha against automated attacks
- Do not allow new user registrations without verification of the new account
- Ensure password complexity is checked on the server-side, in line with password policy requirements
For the popular CMS (Content Management Systems), it’s quite easy to stop a large number of attacks that target default paths, installations or settings. For instance, you can restrict administration interface access to the visitors of the website (only needed for your developers):
- /wp-admin/ on WordPress
- /index.php/admin on Magento
- /umbraco/login.aspx on Umbraco
- /admin for OpenCart
- /user/login on Drupal
- /administrator on Joomla!
Sensitive data exposure
Insecure APIs and web applications do not protect sensitive user data such as PII (Personally Identifiable Information), payment information, or application related session tokens, user accounts. This offers attacker an easy opportunity to commit identity frauds and other crimes using the information exposed by the application. To prevent these exposures, data transmission and data storage requires protection utilising encryption mechanisms and ensuring the application is free from logic flaws. This OWASP top 10 risk is mainly due to insecure coding practices and lack of secure hardening measures.
- Hard-coded credentials, internal IP addresses, API, access tokens, and other useful information the code
- Unprotected sensitive information found in cloud databases or online leading to credit card frauds and identity thefts
- Providing access to source code files via backup or other directories via directory listing flaws
- Database tables, column names in error messages
- Examples of sensitive information include credit card numbers, personally identifiable information (PII), credentials, medical information, national insurance numbers, social security numbers and any other personal information that may lead to identity or financial fraud
How to prevent sensitive information exposure?
The two types of data i.e. data in transit and data at rest should be secured against unauthorised access at all times. Protecting data in transit is often linked to the usage of secure channels when data is transported from one place to another. On websites, this is done by ensuring a secure encryption mechanism in the form of SSL/TLS certificates. SSL is an obsolete protocol now replaced by TLS (Transport Layer Security) certificates. These certificates help protect the integrity of data in transit between the web server and the web browser of a user. Enforce perfect forward secrecy ciphers, cipher prioritization by the server and secure parameters. Directives such as HTTP Strict Transport Security (HSTS) shall support all communications over HTTPS.
Discuss your concerns today
Data at rest is protected based on multiple factors surrounding the environment it is stored in. OWASP recommends preventing sensitive data exposures using the following ways:
- Classifying the data processed, stored or transmitted by an application where data sensitivity is defined as per local privacy laws, regulatory requirements or business needs.
- Applying controls relevant to the data classification.
- Ensure sensitive data at rest is encrypted at all times.
- Store passwords using strong salted hashing functions with a delay factor such as Argon2, scrypt, bcrypt, or PBKDF2.
- Use PCI DSS compliant tokenization or truncation where sensitive data storage is required. This ensures part data is stored and can’t be used if stolen.
- Verify the effectiveness of your controls utilising independent penetration testing services.
XML External Entities (XXE)
XML external entities (XXE) injection, also known as XXE, is a web application vulnerability that allows a threat actor to inject XML containing a reference to an unauthorised external entity and is processed by XML parser (either older or misconfigured). This could allow an attacker to perform internal port scanning, remote code execution or Denial of Service attacks. In some cases, an attacker can exploit XXE flaws to compromise the entire server to perform server-side request forgery (SSRF) attacks.
Examples of XML external entities (XXE) attacks would involve exploiting External Entities to perform data exfiltration, retrieve files in the application’s response, and to perform SSRF attacks.
An attacker would attempt to perform command injection through vulnerable application as:
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
The above request when processed successfully shall run the OS command file:///etc/passwd returning us results for xxe entity.
An attacker would probe an internal network by changing the ENTITY
<!ENTITY xxe SYSTEM https://192.168.100.100/private >]>
A no brainer for an attacker to attempt a denial of service attack would be:
<!ENTITY xxe SYSTEM file:///dev/random >]>
How to prevent XML External Entity (XXE) attacks?
Unfortunately, many XML parsers are vulnerable to XXE attacks by default.
OWASP recommends the following measures to prevent XML External Entity attacks:
- Use less complex data formats such as JSON and avoid serialisation of sensitive data.
- Upgrade all XML processors and libraries in use by the application.
- Update SOAP to 1.2 or higher versions.
- Implement server-side checks to prevent dangerous input within XML documents.
- Disable XML external entity and DTD processing in all XML parsers.
- Refer to the excellent OWASP Cheat Sheet on XXE Prevention for extensive help.
Broken access controls
Broken access control attack is amongst the most known OWASP Top 10 web application vulnerabilities. This flaw relates to the lack of security restrictions around the access management process, allowing users to access, view or modify information they aren’t authorised under their current privileges.
This could lead to horizontal or vertical privilege escalation flaws allowing user access to other users information, or higher privileged accounts information. Broken access controls is one of the dangerous flaws around due to privileged access possible after the exploitation.
An example in the case of a real-world application would be a standard nurse practitioner account in a hospital web portal able to approve/reject data records meant for approval from clinical leads (approver) only. Therefore, a low privileged user can access data that only a high privileged user should be able to access.
Another well-known broken access control would be an attacker gaining access to a server via file transfer mediums such as FTP, SFTP, SSH, Telnet. Similarly, an attacker could obtain access to hosting control or administrative panels such as CMS login.
This would allow an attacker to easily deface the website, change the settings or access underlying data.
How to prevent broken access controls?
- Review the server functionality against a secure hardening checklist to find flaws related to configuration, user accounts, privileges, and other access points. Ensure all basic practices are deployed to reduce the attack surface.
- Limit internet exposure of administrative panels (front end and back end) to specific IP address/ranges/locations.
- Apply logging and monitoring controls to keep an eye on various activities performed by users including failed access attempts.
- Make use of reputed security resources. Some of these are available for free such as CloudFlare, sucuri WordPress plugin.
- Utilise multi-factor authentication where possible.
- Based on the tech stack and underlying technologies, there may be more broken access control prevention measures required. Please check and consult with your vendor or get in touch for further help.
Discuss your concerns today
A very common security flaw often found during web application security assessments is security misconfiguration. These flaws are a result of insecure configurations, default settings or installations, verbose error message containing sensitive information, insecure cloud storage, misconfigured settings on web servers.
An example of this flaw is leaky Amazon S3 buckets disclosing databases leaking thousands of records online. In 2018, Exactis data breach exposed a database containing nearly 340 million individual records on a server. The information exposed included personal information records, entirely preventable as the company failed to implement any access controls on internet-facing Elasticsearch infrastructure used for data search and analytics.
How to prevent security misconfigurations in a web application?
- Ensure technical security baseline guides are at hand for IT and security teams to ensure all installations are secured with hardening measures.
- Ensure separate credentials for development, staging, QA, production environments.
- Follow multi-tier architecture that provides separation between different components. Follow the same principle against backend teams accounts, where corporate and production environment accounts are separate and enforced with different passwords.
- Regular audits to validate the security controls so that gaps are covered in time.
Cross-site scripting (XSS)
Cross-site scripting (XSS) flaws occur due to an application processing untrusted data submitted via a web page without strict validation, or when application updates record with user-supplied input. Cross-site scripting could allow an attacker to hijack sessions, deface websites, redirect to attacker-controlled/malicious websites.
A high profile attack example is XSS attack linked to vulnerability in Zoom’s sign-up page as the application failed to validate the user input submitted resulting in the execution of the injected script. XSS flaws are a very helpful attack vector for cybercriminals carrying out phishing campaigns because the link included in a phishing email is from a legit website.
How to prevent XSS vulnerabilities?
The core reason for these vulnerabilities is server-side routines failing to sanitise the user input. This input is then processed by the users browser, leading to XSS attacks.
Serialization is a programming concept where an object is converted into byte strings to store or transmit to a memory location (for instance, database). Deserialization is the reverse of serialization, where bytes are converted back into an object for transfers. From URLs, web directory structures to serialized objects, security researchers look at all possible opportunities for vulnerabilities that can be exploited to gain access.
Example of an insecure deserialization attack
An example attack scenario (out of multiple possibilities) would be a PHP forum using PHP object serialization to save a “super” cookie, containing user information (such as user ID, privilege level, password hash). An attacker can change the serialized object to change the privilege level that is accepted by the server-side allowing the user a higher privilege role.
The following are examples of popular security incidents involving insecure deserialization vulnerabilities:
- A remote code execution (RCE) by uploading malicious files during server-side deserialization related to Chatopera, a java application (CVE-2019-6503).
- Unauthenticated remote code execution in the .NET app Kentico (CVE-2019-10068).
How to prevent Insecure Deserialization attacks?
Simply, Never trust any serialized objects from untrusted parties.
Alternatively, digital signatures to sign serialized objects should ensure data integrity against any tampering attempts. A multi-layered approach consisting of audit logs, network traffic monitoring, running isolated code in low privileges and enforcing strict type constraints during deserializing should help.
Using components with known vulnerabilities
Web applications, services/APIs requiring third party components that may have known vulnerabilities might be oblivious to providing attackers with an entry route to the application. Even the simplest of websites have dependencies in the form of third-party libraries, plugins or other modules.
The complexity of this issue is not just related to the patching challenge alone. The underlying issue with all the components is the availability of timely support as not all web developers can keep up with the pace of updates, and sometimes legacy code doesn’t work after deploying components updates. Additionally, not all IT teams have the expertise to deploy security updates in time to avoid disrupting operations.
Vulnerable applications are mainly due to the following reasons:
- Development environment and its components
- Software components such as libraries, runtime environments, APIs and relevant components are vulnerable, unsupported or out of date.
- Nested dependencies or third-party components that haven’t been updated and vulnerable to security issues.
How to prevent using components with known vulnerabilities?
- Just like the patch management process for workstations in a network, there should be a patch management process to remove unused dependencies, unnecessary features, components, files and documentation. If patching is not possible, consider virtual patching
- Consider replacing components where vendors are not actively supporting the maintenance, and look for alternatives.
- Ensure you have up to date inventory of all primary and third-party components, versions using tools such as dependency checker.
Insufficient logging and monitoring
Most successful attacks start with initial probing around web applications. Lack of logging and monitoring allows this activity to continue, raising the likelihood of successful exploitation that may end up with estate wide compromise. A threat actor buys time with a lack of logging and monitoring, therefore, increasing chances of infiltrating further into the network.
- Incorrect auditing configuration where important events such as failed logins, or high-value transactions are not logged.
- Incorrect configuration of auditing and event monitoring solutions.
- Log storage performed locally and allowed to be overwritten within 7 days (mostly).
- Application and API log not monitored for suspicious activities.
How to prevent insufficient logging and monitoring issues?
- Review and ensure correct auditing levels are in place based on the error types. For example, server-side input validation failures, access control failures, session tampering, all login events should be logged with sufficient user context.
- Ensure that logging and monitoring processes are defined and backed by incident response plans in the event of an attack.
How do you benefit from OWASP penetration testing?
Web application penetration testing is one of our core offerings under security testing services. Our team of skilled security experts with proven industry experience ensure comprehensive coverage for web application risks, especially issues such as business logic flaws, HTTP Smuggling, SSRF (Server-side request forgery), and many other business contexts that are often missed by automated scanners or less experienced consultants. This also means that the web application testing methodology surpasses this list of OWASP Top ten vulnerabilities, as we concentrate on understanding the application functionality first. Once the working application is understood from a user’s perspective, a threat actor perspective is mixed to ensure malicious inputs can be attempted to check the secure coding practices behind the design.
As part of our delivery process, we ensure your development teams or third-party developers are fully aware of underlying issues including fixes. This would ensure secure coding practices are in place for all your future projects and lesser risks during web development.
Cyphere offers various cybersecurity services, from penetration testing to threat intelligence, to help businesses strengthen their cybersecurity. Get in touch to discuss your primary security concerns.