If you purchase via links on our site, we may receive affiliate commissions.

Top 10 cyber risks of 2023 and how to address them

Updated on: 08 February 2023

Adam Kohnke
Contributor

Cyber risk OWASP — Image by Shutterstock

The COVID-19 pandemic pushed many development teams into hyper-release cycles for mobile and other web application solutions for their customers. Recent research from Symantec has revealed that development environments, developer tools, web and mobile applications remain highly vulnerable to compromise.

Enterprises that prioritize the speedy delivery of web-accessible software with little regard for security must contend with an increasing likelihood that bad actors will expose, then exploit application vulnerabilities left by their development teams.

Help with reducing these risks exists in the form of a non-profit organization known as Open Web Application Security Project (OWASP), a purveyor of free and highly practical web application security guidance.

This article will provide the reader with background on the OWASP Top 10 risks, demonstrate how cybercriminals may identify or exploit some of these risks, and overview general approaches outlining how businesses may reduce their web application attack surface through the extensive web security resources provided by OWASP.

Taking a peek under the hood

From a web application security risk perspective, the 2022 Data Breach Investigation Report (DBIR) from Verizon paints an alarming picture. Data sampled from over 9700 individual cyber incidents that spanned North America, Asia, Europe, the Middle East, and Africa demonstrated 90% of the top breach patterns involve Basic Web Application Attacks (BWAA), reaching nearly 100% in some regions.

Verizon also noted that 82% of all breaches involved human behavior, such as making unintentional errors or allowing credential theft. Guidance exists which can help drive these numbers into the positive territory and allow businesses to better manage their web application risk profile.

Holding steady since 2004, the OWASP Top 10 risks project remains extensively reviewed and updated on a 3-year schedule, publishing a list of the Top 10 risks that are focused on web applications. This risk hierarchy is produced from direct research or vulnerable software uploaded to the project by OWASP members, security organizations, software developers, and other cybersecurity practitioners.

Reviews are executed against code submissions to determine the prevalence of identified vulnerabilities, resulting in a final rank for each Top 10 risk. The OWASP Top 10 is summarized below and is prioritized per the most recent 2021 standard. This article will demonstrate vulnerability discovery and approaches useful for exploiting several Top 10 risks using free resources made available by OWASP.

Applying hands-on Web Application Security

One of the key benefits OWASP offers to every enterprise is the free, multi-functional, and highly effective security tools within the project. Popular security tools such as the OWASP Zed Attack Proxy(ZAP)4, the Samurai-Web Testing Framework (WTF)5, and even Static Analysis Security Testing (SAST)6 tools are made available at no cost, with ongoing support, helping developers or security teams reduce web application vulnerabilities and avenues of attack the enterprise may be unaware of.

Next, this article will briefly cover the installation of OWASP Juice Shop, a mock web application associated with a fictitious but highly vulnerable online juice retailer. OWASP Juice Shop was selected as it’s intentionally configured to highlight several insecure cybersecurity practices relevant in today’ web applications that every enterprise should seek to avoid. Once OWASP Juice Shop is installed, the article will demonstrate how web application security flaws might be exploited in real-world scenarios, then provide general guidance on how these weaknesses can be mitigated or heavily reduced.

Installing and deploying OWASP Juice Shop

Before diving in, OWASP Juice Shop is highly vulnerable to exploitation, so it is not recommended that the installation or use of Juice Shop be performed on web-facing production assets of any importance. General recommendations for OWASP Juice Shop include having it run in a Docker container on a non-production host, which is properly isolated from the internet. Getting OWASP Juice Shop installed and operational is a fairly trivial affair.

This example will forego the use of Docker for ease in demonstration purposes, with Juice Shop being installed directly on a network-isolated Kali Linux 2022.4 virtual machine. Juice Shop also provides a Capture The Flag (CTF) element in the form of a scoreboard, providing users with several escalating challenges to gamify the security learning experience. Finding this scoreboard will be an initial task this article covers after the installation of Juice Shop.

To begin, it is recommended that the device where OWASP Juice Shop will be installed is up to date by running the “sudo apt-get update” command, applying the latest libraries to avoid potential usage conflicts or missing dependency issues. Once all updates are applied, a simple “apt install juice-shop” command gets the vulnerable web application downloaded and fully installed. From there, OWASP Juice Shop can be launched by issuing the “juice-shop -h” command. Juice Shop will launch automatically, but a web address is provided in the startup command results, granting manual access if necessary.

Figure 3 – Starting Juice Shop and confirming operation for the first time.

OWASP 5 — Figure 4 – OWASP Juice Shop landing page which is auto-launched after invoking the application.

Now that Juice Shop is available for assessment, the article will turn to common examples of web application exploitation found under the OWASP Top 10 risks. Cybernews doesn’t endorse the assessment or exploitation of resources not owned by the reader. This information is being made available to help enterprises or web application developers understand potential approaches that may assist them in the identification and mitigation of commonly exploited web application vulnerabilities.

Finding the Juice Shop scoreboard

Attackers commonly begin probing efforts against web applications by reviewing source data made available within the web pages provided on company websites. Attackers may also use popular web fuzzing tools like FFUF or directory-busting tools like Gobuster to reveal hidden data, granting open access to ‘juicier’ portions of the application. Finding the Juice Shop scoreboard is a simple matter of opening the developer tools while visiting the home web page (usually pressing the F12 key or a right click then “View Source” submenu option on a web page), reviewing the ‘main.js’ file and searching for keywords of interest like ‘score’ or ‘score-board’. Path data revealed in the below image informs attackers that a sub-directory exists, which they can attempt to visit manually by forcefully browsing to that location. These developers attempted to hide sensitive data using the “Security Through Obscurity” method, failing to protect this web application's internal structure.

OWASP6 — Figure 5 – Pressing F12, then Inspecting web page elements that disclose sensitive data that is not properly restricted.

Figure 6 – The scoreboard page is revealed using forced browsing.

A01:2021 – Broken Access Control

Broken access control refers to instances where an object, like user accounts or APIs, can execute actions which are outside of their assigned access permissions or rights. Similar to the broken fence image found in figure 1, this type of web application vulnerability may simply allow attackers access to administrative interfaces by guessing their location, similar to what was observed in the previous score board example.

Other Broken Access Control examples include elevation of access privileges, session hijacking, ID forging and metadata modification to grant malicious access to other users data or provide opportunities for fraud. The next example will include an ID forging style attack where negative product feedback will be submitted by our malicious user on behalf of an unsuspecting user, leading to potential brand damage and loss of business for the Juice Shop!

The below example will preview the use of the OWASP ZAP tool to intercept legitimate web traffic and modify it for malicious purposes. Let’s start by visiting the product section of the Juice Shop, entering a product review to capture it in ZAP, inspecting the request for useful details then modifying elements before forging a review under another user ID. ZAP can be downloaded using the ‘sudo apt install zaproxy’ command, then invoking the tool by issuing a simple ‘zaproxy’ command. This example leverages FoxyProxy in the background to allow ZAP proxy interception to be enabled/disabled on the fly with a single click.

After registering for an account, we can search for products and enter reviews.

OWASP 7 — Figure 7 – Entering a product review for “Banana Juice”.

OWASP8 — Figure 8 – Capturing the unencrypted ‘Banana Juice’ review in ZAP, modifying the message and author then resending a forged request as another user posting a highly negative review.

OWASP9 — Figure 9 – The unauthenticated review reflects that of a previously satisfied customer who is now highly dissatisfied, potentially harming sales of a top product and the business’s reputation.

How did this happen? The primary weaknesses surrounding this portion of the website are the general absence of access control mechanisms across various parts of the website such as enforcing HTTPS to encrypt website traffic, overly permissive CORS configuration which allows requests from any sender and a lack of session management features which authenticates requests from user accounts and limits the timeframe in which requests can be sent, or in this case resent. We have seen a couple of examples of Broken Access control, so let’s pivot to defensive coding aspects the platform attempts to impart to web developers and security professionals.

OWASP introduced ‘Coding Challenges’ starting in version 12.9 to help development teams see, understand, and repair the specific code configuration that enables the website vulnerabilities seen in the hacking challenges above. Coding Challenges unlock only after the associated hacking challenge is completed helping developers to first see the impact to the website then start to question how the various vulnerabilities are allowed. The below example illustrates the Coding Challenge for ‘Forged Review’, which was completed in the previous section. OWASP also provides links to defensive documentation, helping developers understand how to address web security issues like Broken Access Control.

OWASP10 — Figure 10 – After completing a hacking challenge, the score board updates the status to a Green check, provides remediation guidance, and a coding challenge to mitigate the vulnerability.

Clicking the Coding Challenge button launches a new window prompting the user to locate the specific lines of offending code before allowing users to attempt a repair. In this particular example, lines 3 and 5 leverage insecure practices allowing forged reviews. Once the insecure lines of code are identified and submitted, the Fix It tab is unlocked, and several examples of updated code are presented to address the weak code. When the correct code is updated in the Juice Shop application, the Coding Score updates, marking the hacking Challenge as ‘solved’.

OWASP11 — Figure 11 – A Two Step approach to find and fix vulnerable code in Juice Shop Coding Challenges.

OWASP12 — Figure 12 – The Fix It menu provides multi select options to help developers understand the code to be removed and new code which will be added to address vulnerabilities.

Juice Shop is a lot of fun and quite simple to wrap your arms around once you spend some time using it. The last few examples showed the power of this wonderful and 100% free security education platform. Developers owe it to themselves, the industry they serve, and their employers to ensure their software development lifecycle processes include security by design. Enterprises must seek to broaden their approach to software-focused cyber security or risk becoming another negative reporting statistic.

Development of robust cybersecurity policies, instituting developer training programs, and ensuring routine code reviews are key considerations enterprises should take to thwart successful attacks against web-accessible assets. Adopting a layered defensive approach will help ensure web infrastructure, software code, and customer data remain secure while allowing the enterprise to achieve its intended mission of returning ongoing value back to internal stakeholders.