Category: Web Apps

  • OWASP Top 10: The Bedrock of an Application Penetration Test

    When performing a web app, mobile app, or API penetration test, many companies, including Raxis, refer to the OWASP Top 10. Here we’ll discuss what that means and why it’s helpful.

    A History

    The OWASP (Open Worldwide Application Security Project) Foundation is a non-profit organization with chapters worldwide. OWASP formed in 2001, and the first OWASP Top 10 was released in 2003.

    While OWASP is best known for their Top 10 list, they have several other projects as well and host conferences around the world encouraging people interested in application development and cybersecurity to come together. All of their tools, documentation, and projects are free and open to all who are interested in improving application security.

    OWASP states their vision as “No more insecure software,” and all of their efforts aid in that goal.

    OWASP released their first Top 10 list in 2003 and continued with a new list every three years for about a decade. Updates have become less less frequent as web application security has matured. The most recent Top 10 list was released in 2021 and before that in 2017.

    More Than Just a Web App Top 10 List

    While the OWASP Top 10 list focuses mostly on web applications (and sometimes mobile applications, which share a number of similarities with web applications), in the last five years, OWASP has begun releasing a Top 10 list for APIs as well. An API (Application Programming Interface) contains functions that allow internal or external applications to contact the system for viewing and sometimes editing data. As such, APIs have a number of differences from web and mobile applications when it comes to keeping systems secure.

    The OWASP API Security Top Ten was first released in 2019 with an update every other year, the most current in 2023. While there is some overlap with the application Top 10 list, this list focuses solely on APIs.

    Updates to the Top 10 Lists

    Updates to the Top 10 lists often combine vulnerabilities as cybersecurity professionals come to realize the items are related and best corrected in the same ways. As applications become more complex, OWASP has added new items to their lists as well.

    Why a Top 10 List?

    Knowing that application developers often have a lot of goals and limited time, and keeping with their vision of “no more insecure software,” OWASP releases its Top 10 list to give developers a succinct guide to follow within their SDLC (Software Development Lifecycle) process.

    The items in the list are broad ideas that can be used in all parts of the planning, coding, and testing phases for applications. This encourages developers to build in security features early in the design phase as well as to find and add security measures later.

    From a penetration testing perspective, the OWASP Top 10 list is also helpful. While malicious hackers have all the time in the world and don’t care if they crash systems and servers, penetration testers aim to discover as much as possible within an affordable time-boxed test without causing harm to an organization’s systems.

    The OWASP Top 10 allows penetration testers to prioritize testing using agreed upon standards. This way customers receive the information needed to secure vulnerabilities in their applications and the knowledge that the controls they have in place are working correctly or need to be corrected. This doesn’t mean that penetration testers don’t examine other findings, but, within a time-boxed test, penetration testers attempt to focus first on the most critical risks.

    How OWASP Creates the Top 10 List

    On their website, OWASP explains their methodology for creating the OWASP Top 10 list, with eight categories from contributed data and two from a community survey. Contributed data is based on past vulnerabilities, while the survey aims to bring in new risks that may not have been fleshed out entirely in the cybersecurity world yet but that appear to be on the horizon and becoming key exposures.

    The team also prioritized root causes over symptoms on this newest Top 10 list. The team has extensive discussions about all of the gathered CWEs in order to rank them by Exploitability, Detectability, and Technical impact. The move from CVSSv2 to CVSSv3 also played a role, as there have been multiple improvements in CVSSv3, but it takes time to convert CWEs to the new framework.

    OWSP Top 10 2017 to 2021 Mapping

    Source: https://owasp.org/www-project-top-ten/

    A Look at the 2021 OWASP Top 10

    The most recent Top 10 list, released in 2021, added three new categories, merged a few categories, and changed the priority of several categories. Though some risks were merged, no risks were entirely removed. Here’s a look at the current OWASP Top 10 Risks (Source: https://owasp.org/www-project-top-ten):

    A01:2021 Broken Access Control moves up from the fifth position; 94% of applications were tested for some form of broken access control. The 34 Common Weakness Enumerations (CWEs) mapped to Broken Access Control had more occurrences in applications than any other category. Raxis published a blog about A01:2021 just after the Top 10 list was released that year. Take a look at OWASP TOP 10: Broken Access Control for more details.

    A02:2021 Cryptographic Failures shifts up one position to #2, previously known as Sensitive Data Exposure, which was broad symptom rather than a root cause. The renewed focus here is on failures related to cryptography, which often leads to sensitive data exposure or system compromise.

    A03:2021 Injection slides down to the third position. 94% of the applications were tested for some form of injection, and the 33 CWEs mapped into this category have the second most occurrences in applications. Cross-site Scripting is now part of this category in this edition. Raxis published a blog about A03:2021 just after the Top 10 list was released that year. Take a look at 2021 OWASP Top 10 Focus: Injection Attacks for more details.

    A04:2021 Insecure Design is a new category for 2021, with a focus on risks related to design flaws. If we genuinely want to “move left” as an industry, it calls for more use of threat modeling, secure design patterns and principles, and reference architectures.

    A05:2021 Security Misconfiguration moves up from #6 in the previous edition; 90% of applications were tested for some form of misconfiguration. With more shifts into highly configurable software, it’s not surprising to see this category move up. The former category for XML External Entities (XXE) is now part of this category.

    A06:2021 Vulnerable and Outdated Components was previously titled Using Components with Known Vulnerabilities and is #2 in the Top 10 community survey, but also had enough data to make the Top 10 via data analysis. This category moves up from #9 in 2017 and is a known issue that we struggle to test and assess risk. It is the only category not to have any Common Vulnerability and Exposures (CVEs) mapped to the included CWEs, so a default exploit and impact weights of 5.0 are factored into their scores.

    A07:2021 Identification and Authentication Failures was previously Broken Authentication and is sliding down from the second position, and now includes CWEs that are more related to identification failures. This category is still an integral part of the Top 10, but the increased availability of standardized frameworks seems to be helping.

    A08:2021 Software and Data Integrity Failures is a new category for 2021, focusing on making assumptions related to software updates, critical data, and CI/CD pipelines without verifying integrity. One of the highest weighted impacts from Common Vulnerability and Exposures/Common Vulnerability Scoring System (CVE/CVSS) data mapped to the 10 CWEs in this category. Insecure Deserialization from 2017 is now a part of this larger category.

    A09:2021 Security Logging and Monitoring Failures was previously Insufficient Logging & Monitoring and is added from the industry survey (#3), moving up from #10 previously. This category is expanded to include more types of failures, is challenging to test for, and isn’t well represented in the CVE/CVSS data. However, failures in this category can directly impact visibility, incident alerting, and forensics.

    A10:2021 Server-Side Request Forgery is added from the Top 10 community survey (#1). The data shows a relatively low incidence rate with above average testing coverage, along with above-average ratings for Exploit and Impact potential. This category represents the scenario where the security community members are telling us this is important, even though it’s not illustrated in the data at this time.

    What This Means for Your Application

    Raxis recommends including application security from the initial stages of your SDLC process. The OWASP Top 10 lists are a great starting point to enable developers to do that.

    When scheduling your web application, mobile application, and API penetration tests, you can rely on Raxis to use the OWASP Top 10 lists as a guide.

  • Hackers See Opportunity Where You See Only a Button

    People are often surprised to find that a hacker doesn’t only attack a website through the authentication process. Our team members are experts at demonstrating why just enforcing password policies and lockout times doesn’t fully protect applications.

    In this article, we’re going to pull back the curtain and show you how hackers use web proxy tools to help exploit applications in ways you might never expect.

    How the Proxy Tool Works

    The proxy tool is software that follows the path data takes step-by-step from your device to the application server. Several such tools exist, but Burp Proxy (included in all versions of Burp Suite) is one of the most popular. Using Burp Proxy, hackers can bypass the user interface – the page you see when entering data – and change the information before it is sent to the application server. This makes it possible to avoid client-side controls, such as those that check that a phone number is only numeric or that an email address is formatted correctly. If the application server expects the client-side controls to have already validated data, the server code may not have all of the proper protections in place.

    In the image below, Burp Proxy, in “Intercept” mode, shows each step along the path that data follows from your device to an application server. The tool allows a user to tab from step to step and change the data that was input originally. If security features are built into the client (the interface you see) but not present on the application server, the proxy enables hackers to enter compliant data first, but change it however they want before it reaches the server.

    Burp Proxy in Intercept Mode shows the path your data travels

    One example of how hackers exploit this setup is through the commonly used buttons or checkboxes found in many apps. Most app developers are cautious about user input fields, but, because buttons, checkboxes, and radio buttons apparently limit data entry to “on-off” or “yes-no” choices, they often see little inherent risk. The problem is that, even though the user options are limited at the interface (client-side), they may not be limited by the code on the server itself (server-side).

    How a Proxy Tool can Reveal a Vulnerability

    The three illustrations below show how even a simple “submit” button can present opportunities for hackers.

    The choice here seems straightforward — either you click the button or you do not. But that choice masks what happens after you click “submit.”

    Save credit card information checkbox and submit button

    “Submit” is really just a request being sent to the server. Here, using Burp Proxy to intercept the data, we can see the request as it will appear to the application server.

    Unmodified GET request intercepted

    Now, rather than a simple yes-or-no choice, a user can modify the data any way they’d like and enter it by pressing the “Forward” command.

    Request modified with longer text
     How Hackers Turn the Exploit into an Attack

    With the ability to effectively bypass safeguards on the client-side interface, hackers can send information directly to the application server. Here are a couple of examples of the types of attacks they can execute if the application server is not secure. (For clarity, we’ll use text-based fields, rather than check-boxes in these examples.)

    Example 1: Cross-Site Scripting (XSS)

    Cross-site scripting (XSS) is a reflected attack that injects malicious client-side executable code into web application parameters to be returned by the application output and ultimately executed by the browser. Because it appears that the script is from a trusted source, the end-user’s browser accepts it and runs the script, permitting the attacker to take actions on the application’s behalf, such as accessing cookies and session tokens as well as other sensitive data. (Source: Raxis Glossary).

    The following walk-through demonstrate how a simple guestbook submission form request works normally and then how an attacker can use a web proxy to insert malicious code.

    This is the submission form as it appears to users:

    Guestbook submission form as it appears to web users

    Our Burp Proxy tool reveals the actual request sent to the application server:

    Captured form submission

    Here the attacker enters an innocuous submission that should not be caught by client-side injection controls:

    Attacker enters submission on web form

    And now the attacker captures the entry using Burp Proxy:

    Unmodified form submission in proxy tool

    Before allowing the proxy tool to move to the next step, the attacker replaces the original harmless data with a malicious script:

    XSS Payload inserted into form submission

    The application server, without server-side controls to stop it, accepts the script and returns the payload to the browser. This is what the attacker sees in Burp Proxy:

    JavaScript Payload Returned in Response Body

    And here we see the successful cross-site scripting result in the browser:

    XSS script executes when entry is displayed on the resulting webpage
    Example 2: SQL Injection (SQLi)

    In this attack, a SQL query is injected into the application via input parameters. A successful attack could read sensitive data from the database, modify data in the database, execute operations on the database (including administrative operations), recover files on the DBMS file system, or issue commands to the operating system. (Source: Raxis Glossary)

    Here we demonstrate how a user ID field can be manipulated to enable a SQLi attack.

    We start with a simple user ID entry field with a submit button where we enter a name and submit:

    Web form with textbox and submit button

    Again the attacker intercepts the submission using Burp Proxy en route to the application server.

    Unmodified GET request intercepted

    As above in the XSS exploit, the attacker then modifies the data in Burp Proxy, this time to include escape characters and a SQL query:

    Request modified to contain SQL injection payload

    With no server-side controls in place to stop the attack, the server returns the data requested in the SQL database query. This is what the attacker sees in Burp Proxy:

    Request returns all users from database

    And here we see the successful SQL injection result in the browser:

    All user records returned from database
    Summary

    It’s tempting here to focus on the Burp Proxy tool and its capabilities, but the more important point is to recognize that vulnerabilities can exist in places we as users might not think. Something that seems innocuous, like a simple submit or on/off button, can be manipulated by a hacker with relative ease. The same is true for any field, button, or widget that sends a request to an application server.

    Remember that the mindset of a hacker is always to look at something as it’s expected to be used, then attempt to use it differently. That’s why pentesting by skilled professionals is so important. It takes trained, ethical hackers to prevent the work of their malicious counterparts.

    Would you like to learn how Raxis can help your organization? Reach out. We have a guaranteed, no-pressure approach, and – after all – we’re all on the same side.

  • What is Web App Pentesting? (Part Two)

    I’m Matt Dunn, a lead penetration tester at Raxis. This is the second of a two-part series, aimed at explaining the differences between authenticated and unauthenticated web application testing. I’ll also discuss the types of attacks we attempt in each scenario so you can see your app the way a hacker would.

    Although some applications allow users to access some or all their functionality without providing credentials – think of simple mortgage or BMI calculators, among many others – most require some form of authentication to ensure you are authorized to use it. If there are multiple user roles, authentication will also determine what privileges you have and/or what features you can access. This is commonly referred to as role-based access control.

    As I mentioned in the previous post, Raxis conducts web application testing from the perspectives of both authenticated and unauthenticated users. In authenticated user scenarios, we also test the security and business logic of the app for all user roles. Here’s what that looks like from a customer perspective.

    Unauthenticated Testing

    As the name suggests, testing as an unauthenticated user involves looking for vulnerabilities that are public-facing. The most obvious is access: Can we use our knowledge and tools to get past the authentication process? If so, that’s a serious problem, but it’s not the only thing we check.

    In previous articles and videos, we’ve talked about account enumeration – finding valid usernames based on error messages, response lengths, or response times. We will see what information the app provides after unsuccessful login attempts. If we can get a valid username, then we can use other tools and tactics to determine the password. As an example, see the two different responses from a forgot password API for valid and invalid usernames below:

    Different Responses for Valid and Invalid Usernames

    From an unauthenticated standpoint, we also will try injection attacks, such as SQL Injection, to attempt to break past login mechanisms. We’ll also look for protections using HTTP headers, such as Strict-Transport-Security and X-Frame-Options or Content-Security-Policy, to ensure users are as secure as they can be.

    With some applications, we can use a web proxy tool to see which policies are enforced on the client-side interface and which are enforced on the server side. In a future post, we’ll go into more detail about web proxies. For now, it’s only important to know that proxies sometimes reveal vulnerabilities that allow us to bypass security used on the client and allow us to interact with the server directly.

    As an example, fields that require specific values, such as an email field, may be verified to be in the proper format on the client-side (i.e. using JavaScript). Without proper safeguards in place, however, the server itself might accept any data, including malicious code, entered directly into that same field. In practice, this can be bypassed, leading to attacks such as Cross-Site Scripting, as shown in my CVE-2021-27956 that bypasses email verification.

    Authenticated Testing

    During an authenticated web application test, we use many of the same tactics, toward the same ends, as we do with unauthenticated tests. However, we have the added advantage of user access. This vantage point exposes the application to more vulnerabilities due to the expanded surface area of the application. This is why we recommend authenticated testing, to ensure even a malicious user cannot attack the application.

    Once authenticated, we attempt is to see if the app restricts users to the level of access that matches its business logic. This might mean we log in with freemium-level credentials and see if we can get to paid-users-only functionality. Or, in the role of a basic user, we may try to gain administrator privileges.

    As with an unauthenticated test, we also see how much filtering of data is done at the interface vs. the server. Some apps have very tight server-level controls for authentication but rely on less-restrictive policies once the user is validated.

    Though it may seem simple from the outside, one of the hardest things for web app developers to secure is file uploads.

    This is another topic we’ll explore further in a future post, however, one good example of the complexity involved is photo uploads. Many apps enable or require users to create profiles that include pictures or avatars. One way to restrict the file type is by accepting only .jpg or .png file extensions. Hackers can sometimes get past this restriction by appending an executable file with a double extension – malware.exe.jpg, for example.

    Another problem is that malicious code could be inserted into otherwise legitimate file types such as word documents or spreadsheets. For many apps, however, it’s absolutely necessary to allow these file types. When we encounter such situations, we often work with the customers and recommend other security measures that allow the app to work as advertised but that also detect and block malware.

    Conclusion

    As a software engineer by training, one advantage I have in testing web applications is understanding the mindset of the developers working on them. People building apps start with the goal of creating something useful for customers. As time goes on, the team changes or users’ needs change, and sometimes vulnerabilities are left behind. This can happen in expected ways, such as outdated libraries, or unexpected ways, such as missing access control on a mostly unused account type.

    At Raxis, we employ a group of experts with diverse experiences and skillsets who will intentionally try to break the app and use it improperly. Having testers who have also developed applications gives us empathy for app creators. Even as we attack their work, we know that we are helping them remediate vulnerabilities and making it possible for them to achieve their application’s purpose.

    Want to learn more? Take a look at the first part of our Web Application Penetration Testing discussion.

  • What is Web Application Penetration Testing?

    I’m Matt Dunn, a lead penetration tester at Raxis. In this series of posts, I’m going to introduce you to the Raxis method of penetration testing web applications. We’ll start with a look at what a web app test involves and how it differs from the network testing we do.

    By their very nature, web apps deserve special scrutiny because they are designed in most cases to be accessible to a broad base of users, often with different roles that convey higher levels of privilege or access. Additionally, they are often used to perform wide ranging functionality, from shopping and banking transactions, to accessing healthcare data. With that accessibility and functionality comes exposure to a wide range of threats from malicious actors who want to exfiltrate data, modify the application, or otherwise disrupt its operation.

    When Raxis performs a web application penetration test, we typically approach it from the viewpoint of both unauthenticated and authenticated user roles. In many cases, some of the app’s functionality is going to be behind some form of authentication. We’ll go into greater detail about authenticated and non-authenticated tests in a subsequent post. For now, however, we’ll limit the discussion to tests in which we are given credentials for all user roles.

    Armed with the appropriate credentials, we examine all the functionality of the app to find out what features are accessible to users and how the application is intended to work. Can users’ profiles be changed? Are users allowed to upload files? Where can the user input their own content? What is each user supposed to be allowed to do? These are just some of the questions we’re looking to answer in the beginning of the test.

    Once we know what the app should do, we’ll test all these features to see if the business logic is correct. For example, an app may allow only administrators to delete uploaded files. So, we’ll attempt to circumvent that restriction and see if we can accomplish that with lower-privileged credentials.

    Raxis approaches a web application test from the perspective of unauthenticated users and authenticated users in multiple roles when more than one role exists.

    Login webpage with username and password

    Next, we will try to exploit the app’s features. For instance, we’ll test the various input fields to see if we can insert malicious code. If so, the app may be vulnerable to cross-site scripting (XSS) – a topic I’ve covered extensively on our blog and YouTube channel. In a similar manner, we’ll test areas where we can upload files to see if we can upload malicious content as part of an attack.

    One question we get from time to time is whether web application testing is included as part of our network penetration tests. The answer is no, for two reasons: First, it’s unlikely that, within the time of a well-scoped network test, we will be able to find credentials to all roles and parts of your web app. Second, network tests are broader in scope and identify the highest risk vulnerabilities across the entire network (as time allows). Depending on other findings, we often test the accessible pages as well as the authentication features. These include logins and “forgot password” pages, to name just a couple. Our goal is to see if we can gain unauthorized access, perform account enumeration, or attack the application externally. But we won’t test as a verified user unless we’re able to gain authenticated access, and even then, we will not focus on the web app in the same depth as we would in a web app test.

    That’s what makes web application testing so important. And with so many companies relying on (or even built around) web apps, it makes sense to conduct these tests regularly and address the findings in order of priority. Even if you are already performing network penetration tests, I strongly recommend that you conduct specific web application tests as well.

    Want to learn more? Take a look at the second part of our Web Application Penetration Testing discussion.

  • What You Need to Know (But Were Afraid to Ask) about Raxis Web App Testing

     What’s special about a Raxis web app test?

    One thing that sets Raxis apart is that our pentesting team is made up of engineers who performed varying roles creating and supporting IT systems before they became pentesters. This includes several engineers who have strong backgrounds in software and web development.

    Even better, Raxis is proud to have a close-knit team of pentesters who collaborate and share their ever-growing knowledge with each other and with our customers. You may have a former web developer performing your test, and that person can easily reach out to a former network admin. They can share info about the most secure web app features as well as how the supporting network should be configured securely..

    Our customers repeatedly tell us how much they appreciate this because it directly translates to relevant, actionable findings. It also encourages natural conversation between their development teams and the security engineers here at Raxis.

    How does this collaboration help customers?

    A recent test we conducted provides a great example: We identified several findings, and the customer was very pleased with the process. Upon follow-up, our sales team found out that the customer saw a small performance reduction after implementing our recommendations. From the customer’s perspective, enhanced security was worth the small drop in performance.

    Because of our development background, however, Raxis’ team members knew that didn’t have to be the case. Our project manager proactively set up a call with the customer to discuss. Result: The customer remediated using Raxis’ advice and regained all of the original performance. They told us they appreciated how Raxis “went the extra mile.”

    To us, that’s just business as usual.

    How many application tests do we do?

    Customers often ask about our application testing process. Application testing accounts for over 50% of our penetration tests. Last year, we performed over 600 application tests. Like all of our assessments, each test is custom tailored to the customer’s application and overall objectives. This could mean testing the entire app, a portion of the app, or following the app throughout the entire development cycle.

    What is your methodology?

    Like all of our assessments, our application tests are primarily manual attack simulations against a customer’s application. Where you see an email field, we see an opportunity for cross-site scripting. Aside from our own experience and expertise, Raxis applies the OWASP framework to our penetration testing, including (though, of course not limited to) the following assessment categories:

    • Access Control
    • Authorization and Authentication
    • Session Management
    • Configuration Management
    • Error Handling
    • Sensitive Data Exposure
    • Input Validation, Injection and Cross-Site Scripting
    • Root Cause Analysis / Reporting
    So, what do I get out of this?

    At the end of a Raxis application assessment you get peace of mind and a solid deliverable. Our reports align with the NIST standard, so they meet regulatory compliance standards. The reports feature an executive summary, engagement storyboard (where applicable), and detailed vulnerability findings that include screenshots, risk explanations, remediation recommendation, and risk scoring.

    Is your web app security keeping you awake at night?

    We understand. Just as we are known for excellence in pen testing, we’re also known for our no-pressure sales and scoping process. We get it. We don’t like to be harassed, and we know you don’t either. If you’d like to start a conversation with one of our experts to help understand the possibilities for your project, feel free to reach out. We’d love to help.