What is OWASP?
The OWASP, stands for The Open Web Application Security Project, is a nonprofit 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.
What is OWASP Top 10?
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.
Why is OWASP important?
OWASP releases the Top 10 risks list every 2-3 years in accordance with the ongoing threats due to changing threat landscape. It’s importance is directly tied to it checklist nature based on the risk severity of security risks and potential impacts. OWASP is often considered go to standard for web application development teams across organisations.
The following image is taken from official OWASP source depicting changes from previous version (OWASP Top 10 -2013) to current version i.e. 2017.
Read our article to learn more about the issues to be aware of, with impact and examples.
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 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 very common attack vector in the recent past.
An example of SQL injection would be UNION or Blind SQL injection attacks to enumerate information from the database. In 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).
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 launch brute force attacks, take over user sessions, enumerate legitimate user information, and related implications.
- Username enumeration based on changes observed in the application’s behaviour to identify valid usernames.
- Brute-force attacks where an attacker uses 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 identify 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.
- Hard-coded credentials, internal IP addresses, API, access tokens, and other useful information the code
- Providing access to source code files via backup or other directories via directory listing flaws
- Database tables, column names in error messages
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 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.
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 per 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 via independent parties through security assessments.
XML External Entities (XXE)
XML external entity 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 XXE attacks would include various types of XXE attacks. This involves 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 ways 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
This flaw relates to lack of security restrictions around 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.
An example in 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.
Other 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 reduce broken access controls risks?
- 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.
A very common security flaw often found during the web application penetration tests is a 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 results due to an application processing untrusted input submitted via a web page without strict validation, or when application updates records 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 application failed to validate the user input submitted resulting in execution of the injected script. XSS flaws are very helpful attack vector for cyber criminals 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 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.
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 privilege level that is accepted by server-side allowing the user 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 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 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 & 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 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 logs not monitored for suspicious activities.
How to prevent insufficient logging & 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.
OWASP penetration testing
Web application penetration testing is one of our core offerings under penetration 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 penetration 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. If you are looking for vendor neutral penetration testing and managed services, work with us today!