Tag: Web App

  • 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.

  • SQLi Series: An Introduction to SQL Injection

    Web applications often need to store data to better serve their customers. An example would be storing customer login information or comments submitted by users on the webpage. There are many ways of storing data for customers, but a popular way is to store the information in a SQL database.

    A common and basic use of web applications and SQL databases is to handle user login information and functionality. In many web applications a user submits a username and password into a form. The web application takes the submitted data and searches the database to determine if it’s a valid credential set. If it is, then the web application will log the user in.

    SQL Injection

    If the web application does not properly handle user input, an attacker might be able to create malicious input that changes the SQL query that performs that login task behind the scenes. Such SQL injection attacks take a lot of manual effort to discover and exploit, but they are a critical part of the web application penetration tests that we perform at Raxis.

    This blog explains how an attacker could find and exploit a SQL injection, or SQLi, vulnerability.

    Creating an Exploitable Login Webpage

    Let’s build a simple web application that asks for a username and password and returns the user’s ID. In order to help show the SQL injection attack, the application will also show the query used and the input from the login page. The SQL code the application uses (with user input parameters filled in) can be seen at the bottom of each screenshot.

    First let’s take a look at the results for the admin logging in normally.

    Successful login showing SQL query

    We can see that the user entered the admin username and password. We also see that our sample PHP web application uses a query where the username and password must match for success. If both match then, for our testing purposes, it returns the user ID which is printed out at the bottom.

    Here the admin’s account has the ID of 1.

    In the next example, the admin username is entered correctly, but the wrong password is supplied.

    Unsuccessful login showing the SQL query

    Again we can see the information that was input into the application and the query. However, since the password does not match the one in the database, we don’t get the user ID.

    Exploiting the Webpage to Login

    In the example queries above we saw that the username and password input was passed into the query without modification.

    So what happens if we close the single quote around the username?

    Attempted SQL injection with a single quote

    We see that, even though the correct password was entered, the single quote at the end of the username prevents the query from returning a correct result. In this case we get the same error message as if the username and password were incorrect, but other web applications might crash in different ways indicating there was a backend issue.

    In MySQL the # symbol denotes a comment, which makes the database ignore everything after it. Let’s try adding a # after that single quote we just added:

    Successful SQL injection bypassing the password

    Now we see that, even though we submitted the wrong password, the application considers the SQL query successful and returns the correct user ID. The question is What is happening here?

    Let’s take a closer look at the query and the input from the user.

    The input in the username field has injected two special SQL characters: the ’ (single quote) and the #.

    This changes the query itself because the user input is directly inserted into the query.

    Highlighting that the MySQL # comment symbol allowed the SQL injection to work

    The single quote closes the username entry so that the text that comes after is read as part of the SQL query. This means that the # is interpreted as the comment symbol, meaning that the rest of the query is simply ignored.

    Basically, that means that the query is now just running as 

    SELECT id, username, password FROM users WHERE username=’admin’

    Since the admin user exists, we get the successful result of the user id of 1, even with the wrong password.

    This also means that we can login as any user, provided that we know their username. Just change the admin username to the desired username.

    Using the same injection string to login as another user

    Exploiting the Webpage to Get Data

    Now logging in as any user is fun and all, but what else can we do? Well, we can come up with SQL queries that dump information from the database.

    Let’s use the UNION operator to inject another SQL query that goes along with the query created by the application. We should note that, since the sample web application only shows one column at a time, we need to switch what we are asking for first so that the application will show us more information.

    Here is what happens when we add a UNION SELECT for all the user IDs from the users table to the SQL injection we are entering in the username field:

    SQL injection adding UNION SELECT to get a list of all user IDs.

    After asking for the IDs, we enter a new SQL injection and ask for the usernames:

    SQL injection adding UNION SELECT to get a list of all usernames.

    And finally, we perform a SQL injection requesting the passwords:

    SQL injection adding UNION SELECT to get a list of all passwords.

    A Quick Note on Password Hashes

    This is a good time to note why using password hashes (instead of saving passwords in plaintext) is a good idea. If password hashes were in use, an attacker would have to crack the passwords in order for them to be useful in a SQL injection attack.

    Automated Exploitation with SQLMap

    While we can do attacks such as these manually, sometimes, after identifying a vulnerability, it is easier to use tools to exploit it for you. In real life scenarios, SQLi attacks don’t return the SQL statement, and it takes some trial and error to discover how the application is reacting to our input.

    My go-to tool for SQL injection attacks once I find a sign of them is always SQLMap. Here is a screenshot of SQLMap dumping the users table from the SQLi database the web application above uses.

    The SQLMap tool performing the same exploit we did manually

    SQLMap makes it a lot easier to dump information from a database when an application is susceptible to SQLi attacks. While here it dumped the same information we just did, it is capable of finding every table and column and dumping everything.

    More Than SQLi

    We should also note there are other ways of getting information from a database, including timing attacks in which a database waits to respond if something is true while responding quickly if it’s not. Timing attacks allow us to guess what input is valid and what is not valid. Maybe we will take a look at a timing attack example in another post.

    In Conclusion

    Now that we have a basic understanding of what SQL injection is and the types of exploits that can be done with it, my next posts in this series will go into specific attacks and how to perform them.

    As always, remember that these tutorials are guides for penetration testers and people looking to understand their penetration test results better. Attempting these attacks on any sites that don’t belong to you or where you don’t have legal documentation granting you access to perform ethical penetration testing is illegal and punishable under law.

  • Why We Take Simultaneous Sessions Seriously

    Summary

    A common finding in web applications we test is ‘Application Supports Simultaneous Logins’. This finding occurs when both of the following conditions are met:

    1. The application allows for multiple sessions at the same time, from different devices, browsers, etc.
    2. The application does not alert the user to the multiple sessions through:
      • Email notification,
      • Notification inside the application, or
      • A session management page inside the application.

    Essentially, this boils down to the user being allowed to have multiple sessions without a way to manage them or see other active sessions through notifications or otherwise.

    What does this look like?

    In practice, we look in several locations for the functionality to manage sessions, but the most common place we find it is in profile sections or settings. When these are not available, we’ll log in on two separate browsers — or on two devices — and navigate them both to the settings page, checking for notifications or other session management abilities. An example of multiple sessions without notification to the user in a popular online platform is shown below:

    Multiple Sessions without User Notification
    Why does this matter?

    Allowing simultaneous sessions seems innocuous at first. I mean, we mostly all have multiple devices that we log in through, right? True, but the lack of insight into your account’s session management becomes a problem if your session is somehow stolen, credentials are obtained, or your account is otherwise compromised through other vulnerabilities. If multiple sessions are allowed without notification to the user, there is no way for the user to know that their account has been compromised or to terminate the active sessions that have been compromised.

    Remediations

    In today’s world, disallowing multiple sessions is likely not realistic due to business constraints. Most people have several devices themselves, and logging in to an application on multiple is common, so this likely needs to be a feature in your application. However, alerting the user or allowing them to view their active sessions is important so they can maintain control of their account in the event of a breach. There are several ways to do this, with varying functionality, including:

    • Showing users active sessions with details about the session
    • Allowing users to terminate specific sessions
    • Providing functionality to log out the user from all other devices
    • Combine any of the above when the account password is changed

    These are all valid approaches, but the specific one you choose to implement will depend on your application’s use cases, business constraints, and design. In our Raxis One application, we provide the user both with details about their active sessions, functionality for terminating specific sessions, and a session history that includes IP Address and location details, as shown in below:

    Raxis One Session Management

  • 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.

  • External vs. Web App Pen Testing

    When it comes to pen testing, it’s easy to get confused about the differences between an external network pen test and a web application pen test. 

    In this video, I sit down – via zoom – with Chief Operating Officer Bonnie Smyre to discuss the differences between the two.

    Here’s a quick overview of the two tests.

    What is an external pen test?

    An external network penetration test is fairly broad and looks at the overall corporate cybersecurity environment. It is an attempt to find all the ways someone could get into your network without having any type of access. Testers look for any gaps they can find and explore ways they might exploit them. 

    What is a web application pen test?

    A web application pen test is much more focused on the application itself, exploiting it in ways that were never thought of during the development stage. For example, testers will start trying to find ways into different areas using credentials that have different access points. They want to know if different credentials can get them into areas where they may not belong, while also searching the application for any other vulnerabilities.  

    So which pen test do you need? Hopefully, the answer is much clearer now. If you have a web application and you want to vet it thoroughly, you need the web application pen test. If you are looking for any vulnerability that might give a hacker access to your data, you should consider the external pen test. 

    One of the many advantages to having a third party like Raxis come in and test is that it offers you a new perspective and a fresh set of eyes. Raxis testers come in with no expectations other than information they want. 

    A Raxis penetration test will assess your security posture using a combination of tools, techniques and mischief in pursuit of gaining full control of your network. But Raxis doesn’t stop there. Once weaknesses are found, the Raxis team is here to help you make corrections and secure your network. Find out more about our pen testing experience, or contact us to learn more.

  • Raxis API Tool

    At Raxis we perform several API penetration tests each year. Our lead developer, Adam Fernandez, has developed a tool to use for testing JSON-based REST APIs, and we’re sharing this tool on GitHub to help API developers test their own code during the SDLC process and to prepare for third-party API penetration tests.This code does not work on its own… it’s a base that API developers can customize specifically for their code. You can find the tool at https://github.com/RaxisInc/api-tool.

    Here’s a basic overview of the tool from Adam himself:

    The Raxis API tool is a simple Node.js class built for assessing API endpoints. The class is designed to be fully extensible and modifiable to support many different types of JSON-based REST APIs. It automatically handles token-based authentication, proxies requests, and exposes several functions designed to make it easier and faster to write a wrapper around an API and associated test code for the purposes of a penetration test. This tool is not designed to work on its own, but to serve as a building block and quickstart for code-based API penetration testing.