Exploring the OWASP Top 10: Part 5

One of the top ten security risks identified by OWASP is security misconfiguration, which is explained in their 2021 report https://owasp.org/Top10/A05_2021-Security_Misconfiguration/.

An application might be vulnerable if the application is missing appropriate security hardening across any part of the application stack or improperly configured permissions on cloud services, if it has unnecessary features enabled or installed, if default accounts and their passwords are enabled and unchanged, if error handling reveals stack traces or other overly informative error messages to users, or if an upgraded system does not have the latest security features enabled or if they are not properly configured. Using out of date software can also lead to this risk.

This leads to a few possible attacks. Firstly, if the application server comes with sample applications not removed from the production server. If these have known security flaws, attackers could use them to compromise the server. Suppose one of these applications is the admin console, and default accounts weren’t changed. In that case, an attacker could log in with the default credentials and immediately gain administrator privileges. This picture gives a brief demonstration of an attacker gaining access to a system by using unchanged default values:

CrowdStrike provides more examples of security misconfiguration and what dangers they could lead to: https://www.crowdstrike.com/cybersecurity-101/security-misconfiguration/#:~:text=Security%20misconfiguration%20is%20any%20error%20or%20vulnerability%20present,breach%20and%20attackers%20gaining%20unauthorized%20access%20to%20data.

If directory listing is not disabled on the server, an attacker can simply list directories. The attacker could find and download the compiled Java classes. Later, they could decompile and reverse engineer them to view the code. This allows the attacker to easily find access control flaws and other vulnerabilities in the application. Veracode has more information about possible attacks that could be caused by security misconfiguration: https://info.veracode.com/rs/790-ZKW-291/images/security-misconfiguration-prevention-guide-en.pdf.

In order to minimize this vulnerability, secure installation processes should be implemented, including a repeatable hardening process that makes it fast and easy to deploy another environment that is appropriately locked down. This process should be automated to minimize the effort required to set up a new secure environment. Using a minimal platform without any unnecessary features, components, documentation, and samples also helps to reduce the risk of security misconfiguration. Regularly reviewing and updating the configurations appropriate to all security notes, updates, and patches as part of the patch management process is also a good practice to make sure everything is properly configured and up to date. Using an automated process to verify the effectiveness of the configurations and settings in all environments would help developers to ensure that their security configuration works in any environment they need to use. This picture lists some of the top areas where people make security configuration mistakes:

Exploring the OWASP Top 10: Part 4

One of the top ten security risks identified by OWASP is broken access control according to their report https://owasp.org/Top10/A01_2021-Broken_Access_Control/. Access control enforces a policy so that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user’s limits. This picture is a brief explanation on how an attacker gains access:

Red Hat gives some good information about access control and explains three different types in their article: https://www.bing.com/search?q=broken+access+control&cvid=59f8de25013e483a9898f791fe6e051a&gs_lcrp=EgZjaHJvbWUqBAgAEAAyBAgAEAAyBAgBEAAyBAgCEAAyBAgDEAAyBAgEEAAyBAgFEAAyBAgGEAAyBAgHEAAyBAgIEADSAQgzMDExajBqNKgCALACAA&FORM=ANAB01&PC=LCTS

Common access control vulnerabilities include failure to utilize the least privilege practice or deny by default practice, where access should only be granted for specific capabilities, roles, or users, but is available to anyone. Another common issue is bypassing access control checks by modifying the, internal application state, or the HTML page. Allowing the ability to view or edit someone else’s account is another bad practice that can lead to attacks. Elevation of privilege is a common method attackers use to gain more permissions on a system. This comes in the form of acting as a user without being logged in or acting as an admin when logged in as a user. Another mistake is force browsing to authenticated pages as an unauthenticated user or to privileged pages as a standard user.

Access control is only effective in trusted server-side code or server-less API, where the attacker cannot modify the access control check or metadata. There are multiple ways to avoid these issues. Except for public resources, use the deny by default method when granting permissions. Implement access control mechanisms once and re-use them throughout the application. Ensure that model access controls enforce record ownership rather than accepting that the user create, read, update, or delete any record. Applications should disable web server directory listing and ensure file metadata and backup files are not present within web roots. Be sure to log access control failures, alert admins when appropriate. Session identifiers should be invalidated on the server after logout. Veracode explains some other ways to prevent broken access control: https://info.veracode.com/rs/790-ZKW-291/images/broken-access-control-prevention-guide-en.pdf.

Exploring the OWASP Top 10: Part 3

One of the top ten security risks identified by OWASP is security logging and monitoring failures, according to their report https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/. This category is to help detect, escalate, and respond to active breaches. Without logging and monitoring, breaches cannot be detected. Insufficient logging, detection, monitoring, and active response allows attackers to gain access to systems and accounts for an extended amount of time, maximizing the damage they can cause.

This occurs when auditable events, such as logins, failed logins, and high-value transactions, are not logged, warnings and errors generate inadequate, or unclear log messages, logs of applications and APIs are not monitored for suspicious activity, logs are only stored locally, appropriate alerting thresholds and response escalation processes are not in place or effective, or the application cannot detect, escalate, or alert for active attacks in real-time or near real-time.

Veracode gives a good explanation about how to identify these issues: https://info.veracode.com/rs/790-ZKW-291/images/security-logging-and-monitoring-prevention-guide-en.pdf.

In order to combat these risks, developers should implement the following controls depending on the possible risk of the application: ensure all login, access control, and server-side input validation failures can be logged with sufficient user context to identify suspicious or malicious accounts. Ensure that logs are generated in a format that log management solutions can easily be understood. Ensure log data is encoded correctly to prevent injections or attacks on the logging or monitoring systems. Make sure that high-value transactions have an audit trail with integrity controls to prevent tampering or deletion, such as append-only database tables or similar. Most importantly, developers should implement or adopt an incident response and recovery plan. Tech target gives some more advice on the best practices for log monitoring: https://www.bing.com/search?q=why+is+logging+and+monitoring+important&cvid=f7efcaf241b84f79b044fc7ed42b982e&gs_lcrp=EgZjaHJvbWUqBAgAEAAyBAgAEAAyBAgBEAAyBAgCEAAyBAgDEAAyBAgEEAAyBAgFEAAyBAgGEAAyBAgHEAAyBAgIEADSAQg1NTg2ajBqOagCALACAA&FORM=ANAB01&PC=LCTS.

Exploring the OWASP Top 10: Part 2

One of the top ten security risks identified by OWASP is identification and authentication failures., which they discuss in this report: https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/. This is a big risk because it allows unapproved individuals to gain access to peoples accounts and systems and, as a result, sometimes elevated permissions or access to private information.

Confirmation of the user’s identity, authentication, and session management is critical to protect against authentication-related attacks. There may be authentication weaknesses if the application permits automated attacks such as credential stuffing, where the attacker has a list of valid usernames and passwords, permits brute force or other automated attacks, permits default, weak, or well-known passwords, uses weak or ineffective credential recovery processes, uses plain text, encrypted, or weakly hashed passwords data stores, neglects to use multi factor authentication, does not correctly invalidate session IDs, or exposes the session identifier in the url.

These vulnerabilities can make way for multiple different attacks. Credential stuffing, which is making use of a list of known passwords, is a common attack. If an application does not implement automated threat or credential stuffing protection, such as delaying the amount of login attempts someone could make, credential stuffing is an easy way for a hacker to gain access to someone’s account or system. Another big issue is using a public computer or system. If session timeouts aren’t properly set and someone forgets to log out when they finish using it, the next person to use it would have access to their account. Cyolo goes into a lot more detail about the different types of attacks that can result from this: https://cyolo.io/blog/identification-and-authentication-failures-and-how-to-prevent-them/.

There are a few things someone can do to combat this. Where possible, implement multi-factor authentication to prevent automated credential stuffing, brute force, or stolen credential attacks. Applications can implement weak password checks and require a certain amount of characters and numbers in passwords. Application developers can also ensure that registration, credential recovery, and API pathways are hardened against account enumeration attacks. One can limit or increasingly delay failed login attempts. To prevent incorrectly invalidating or exposing a session ID, applications may use a server-side, built-in session manager that generates a new random session ID with high entropy after login. Veracode talks a lot more about how to prevent these risks in their guide: https://info.veracode.com/rs/790-ZKW-291/images/identification-authentication-failure-prevention-guide-en.pdf.

Exploring the OWASP Top 10

One of the top ten security risks identified by OWASP is vulnerable and outdated components, which they talk about in this report: https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/. Applications have been using more and more pre-existing components rather than being coded completely from scratch. Web applications often need fast turnaround, and with the increasing quantity of open-source components available, it is no shock that developers are making use of it. In fact, an estimated 96% of applications use at least some open source components. On average, more than half of an application’s codebase consists of open-source code according to https://www.immuniweb.com/blog/OWASP-vulnerable-and-outdated-components.html. The result of this can be new websites and applications with deeply embedded vulnerabilities that are unknown to the application operator. Once those vulnerabilities are discovered and publicized, applications that use that vulnerable component may be found and exploited.

Components typically run with the same privileges as the application itself, so flaws in any component can result in serious impact. Such flaws may be accidental, such as a coding error, or intentional, such as a backdoor in a component. There are automated tools to help attackers find unpatched or misconfigured systems.

This is a risk if you do not know the versions of all the components you use, if your software is vulnerable or out of date, if you do not regularly scan for vulnerabilities and read updated information about the components you use, If you do not fix or upgrade the underlying platform, frameworks, and dependencies in a risk-based, timely fashion, or if software developers do not  test the compatibility of updated, upgraded, or patched libraries. You can find more possible risks, as well as prevention methods, in this guide: https://info.veracode.com/rs/790-ZKW-291/images/vulnerable-and-outdated-components-prevention-guide-en.pdf.

There should also be a process in place to remove unused dependencies, unnecessary features, components, or files. Continuously inventory the versions of both client-side and server-side components and their dependencies, only obtain components from official sources over secure links, and monitor for libraries and components that are not maintained or do not create security patches for older versions because they may be insecure. This image gives a briefer, easier to understand explanation about vulnerable components: