Extensible Markup Language (XML) is a markup language used for encoding documents in a format that is both easy to handle for machines and human-readable. However, this commonly used format includes multiple security flaws. In this first XML related blog post, I will explain the basics of handling XML documents securely by using a schema.

OWASP divides the different vulnerabilities related to XML and XML schemas in two categories.

Malformed XML documents

Malformed XML documents are documents that do not follow the W3C XML specifications. Some examples that result in a malformed document are the removing of an ending tag, changing the order of different elements or the use of forbidden characters. All of these errors should result in a fatal error and the document should not undergo any additional processing.

In order to avoid vulnerabilities caused by malformed documents, you should use a well-tested XML parser that follows W3C specifications and does not take significantly longer to process malformed documents.

Invalid XML documents

Invalid XML documents are well formed but contain unexpected values. Here an attacker may take advantage of applications that do not properly define an XML schema to identify whether documents are valid. Below you can find a simple example of a document that, if not validated correctly, might have unintended consequences.

A web store which stores its transactions in XML data:

   <purchase></purchase>
     <id>123</id>
     <price>200</price>
   

And the user only has control over the <id> value. It is then possible, without the right counter measures, for an attacker to input something like this:</id>

   <purchase></purchase>
     <id>123</id>
     <price>0</price>
     <id></id>
     <price>200</price>
   

If the parser that processes this document only reads the first instance of the <id> and <price> tags this will lead to unwanted results. </price></id>

It is also possible that the schema is not restrictive enough or that other input validation is insufficient, so that negative numbers, special decimals (like NaN or Infinity) or exceedingly big values can be entered where they are not expected, leading to similar unintended behavior.

Avoiding vulnerabilities related to invalid XML documents should be done by defining a precise and restrictive XML Schema to avoid problems of improper data validation.

Next blog post we will go into some more advanced attacks on XML documents such as Jumbo Payloads and the feared OWASP Top Ten number four, XXE.

In the meantime you can hone or challenge your skills on XML input validation on our portal.

Specifications for XML and XML schemas include multiple security flaws. At the same time, these specifications provide the tools required to protect XML applications. Even though we use XML schemas to define the security of XML documents, they can be used to perform a variety of attacks: file retrieval, server side request forgery, port scanning, or brute forcing.

https://www.owasp.org/index.php/XML_Security_Cheat_Sheet

The insufficient logging and monitoring flaw mostly happens as a result of a failed cybersecurity plan in regards to logging all failed authentication attempts, denied access, and input validation errors. It can occur at other points in the production environment, but is most associated with a failure to stop invalid login attempts.

It's a dangerous vulnerability because it means that cybersecurity teams won't respond to attacks because they don't know about them. This gives attackers a big advantage, letting them remain unnoticed while they try and further penetrate a system or upgrade their credentials. In fact, without proper logging and monitoring, it becomes very difficult or even impossible to detect and stop attacks before they can do significant damage.

Ready to test your skills with a challenge right now? Check this out:

How do attackers exploit insufficient logging and monitoring?

Any API is vulnerable to insufficient logging and monitoring if the logging level is not set correctly, if it is set too low, if error messages do not include enough detail or if no logging function is present at all.

An interesting example would be if a hacker obtained a large list of compromised user names for a website or service. Through experimentation, they could figure out that it takes three failed login attempts before they are locked out of the system, and before cybersecurity personnel are notified.

Armed with this information, instead of trying to brute force single accounts, they instead could write a script to try and log in as every name on their compromised list using common passwords like "123456" or "password." The trick is that they only try each user name once, or perhaps twice, keeping below the threshold for lockouts and alerts. If they get lucky, they will compromise at least a few passwords right off the bat. After that, they simply wait a day for the login counter to reset and run the process again using different passwords like "qwerty" or "god." If admins never detect what they are doing, attackers can go through the list many times and eventually compromise most accounts with weak passwords.

This happened in the OWASP supplied example where a video sharing platform was attacked using a credential stuffing attack that exploited the insufficient logging and monitoring vulnerability. Until the company started to get user complaints, it had no idea that the attack was happening. Eventually, they found evidence in the API logs, and had to issue a forced password change notification to all of their users, as well as report the attack to regulatory authorities.  

Eliminating the insufficient logging and monitoring vulnerability

Automation and constant monitoring can help put an end to this vulnerability. To start, all failed authentication attempts should be logged. And that log should be put into a format that is machine-readable like STIX and TAXII so that it can be ingested into a security information and event management (SIEM) system that is trained to look for attacks regardless of the thresholds used.

You should also protect your log files. Treat them as sensitive information and protect them from deletion or modification by attackers. A good policy is to both backup the log files and also encrypt them.

Finally, create custom dashboards and alerts so that any suspicious activities can be detected and responded to as quickly as possible. If you eliminate an attacker's time with the system, you remove their ability to use low and slow attack techniques to remain undetected.

Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.

Since 2015, we've been engaging developers all over the world with a proactive, positive approach to security, helping them build the skills to secure their code, cut down on rework and remediation, and hopefully see the security team as something other than the fun police.

We're still committed to standing side-by-side with developers as they secure code across the galaxy, but it's time to shake things up and take our battle-hardened, security-aware developers to the next level.

We're thrilled to announce a brand new feature release on the Secure Code Warrior platform: Missions. This all-new challenge category is the next phase in developer-ified security training, moving users from the recall of security knowledge, to applying it in a real-world simulation environment. This scaffolded, microlearning approach builds potent secure coding skills that are job-relevant, and much more entertaining than (vertically) watching endless training videos in the background of a workday.

Our first playable, public Mission is a simulation of the GitHub Unicode breach. It might seem deceptively simple, but it's a really clever vulnerability that is fun to dissect. Security researcher 0xsha did a comprehensive case study on how this same bug can be used to exploit Django by way of case transformations, while also revealing how the vulnerability behavior can change between programming languages. There's a lot more to discover about this security issue, and our mission is a great place to start.

GitHub's head-on (case mapping) collision

In a blog post from November 28, 2019, security research group Wisdom reported on a security bug they discovered on GitHub. They outlined how they were able to utilize a Case Mapping Collision in Unicode to trigger a password reset email delivery to the wrong email address (or if we were thinking like an attacker, an email address of the threat actor's choosing).

While a security vulnerability is never good news, security researchers who rock a whitehat do provide some mercy -- not to mention the opportunity to avert disaster -- if they discover potentially exploitable errors in a codebase. Their blogs and reports often make for great reading, and it's kind of cool to learn about a new vulnerability and how it works.

In order to move to the next level of secure coding prowess, it is immensely powerful to not just find common vulnerabilities (especially any cool new ones - we all know that malicious threat actors will be looking for fertile ground to dig up some data with these new techniques) but also have safe, hands-on environment to understand how to exploit them as well.

So, let's do just that. Keep reading to discover how a Case Mapping Collision in Unicode can be exploited, how it looks in real-time, and how you can take on the mindset of a security researcher and try it out for yourself.

Ready to take on a Case Mapping Collision right now? Step right up:

Unicode: Complex, endlessly customizable, and more than just emojis

"Unicode" may not be in the lexicon of the average person, but chances are good that most people use it in some form every day. If you've used a web browser, any Microsoft software, or sent an emoji, then you've been up close and personal with Unicode. It's a standard for consistent encoding and handling of text from most of the world's writing systems, ensuring that everybody can (digitally) express themselves using a single character set. As it stands, there are over 143,000 characters, so you're covered whether you're using the Icelandic, or the Turkish dotless, or anything in between.

Due to the sheer volume of characters Unicode has in its set, a way of converting characters to another "equivalent" character is needed in many cases. For instance, it seems sensible that if you convert a Unicode string with a dotless to ASCII, that it should simply turn into an "i", right?

With a great volume of character encoding comes great potential for disaster

A case mapping collision in Unicode is a business logic flaw, and at its core, can lead to an account takeover of accounts not protected by 2FA. To illustrate the vulnerability in question, let's look at an example of this bug in a real code snippet:

app.post(/api/resetPassword, function (req, res) {
  var email = req.body.email;
  db.get(SELECT rowid AS id, email FROM users WHERE email = ?, [email.toUpperCase()],
      (err, user) => {
          if (err) {
              console.error(err.message);
              res.status(400).send();
          } else {
              generateTemporaryPassword((tempPassword) => {
                  accountRepository.resetPassword(user.id, tempPassword, () => {
                      messenger.sendPasswordResetEmail(email, tempPassword);
                      res.status(204).send();
                  });
              });
          }
      });
});

The logic goes something like this:

1. It accepts the user-provided email address, and uppercases it for consistency
2. It checks if the email address already exists in the database
3. If it does, then it will set a new temporary password (this isn't best practice, by the way. Instead, use a link with a token that enables a password reset)
4. It then sends an email to the address fetched in step 1, containing the temporary password (this is very poor practice, for so many reasons. Yikes.)

Let's see what happens with the example provided in the original blog post, where a user requests a password reset for the email John@GıtHub.com (note the Turkish dotless i):

1. The logic converts John@Gıthub.com to JOHN@GITHUB.COM
2. It looks that up in the database and finds the user JOHN@GITHUB.COM
3. It generates a new password and sends it to John@Gıthub.com

Note that this process ends up sending the highly sensitive email to the wrong email address. Oops!

How to cast out this Unicode demon

The interesting aspect of this specific vulnerability is that there are multiple factors that make it vulnerable:

1. The actual Unicode casting behavior
2. The logic determining email address to use, i.e. the user-provided email address, instead of the one that already exists in the database.

In theory, you can fix this specific issue in two ways, as identified in the blog post from Wisdom:

1. Convert the email to ASCII with Punycode conversion
2. Use the email address from the database, rather than the one provided by the user

When it comes to hardening software, it's a great idea to leave nothing to chance, employing as many layers of defense in place as possible. For all we know, there may be other ways to exploit this encoding - we're just not aware of them yet. Anything you can do to decrease risk and close windows that may be left open for an attacker is valuable.

Ready to try this for yourself?

Most developers are aware that compromised data is bad for business. However, security-aware engineers are a powerful antidote against growing vulnerabilities, breaches, and cybersecurity woes.

It's time to take your secure coding and awareness skills to the next level. Experience this GitHub vulnerability in an immersive, safe simulation, where you can see the impact of bad code in both frontend and backend contexts. Attackers have an advantage, so let's even the playing field and apply real skills with a whitehat counter-punch.

While most of the vulnerabilities on this list are pretty specific to APIs, the disabled security features/debug features enabled/improper permissions problem is one that can strike anywhere. It's likely a little more prevalent in APIs, but attackers will often attempt to find unpatched flaws and unprotected files or directories anywhere in a network. Coming across an API that has debugging enabled or security features disabled just makes their nefarious work a little easier. Worse yet, automated tools are available to detect and exploit security misconfigurations, so if you have them in your environment, there is a good chance that they will be exploited, which is why this vulnerability made the OWASP list of dangerous API flaws.

Before we get into the fun, see if you can solve this debug challenge:

How does the disabled security features/debug features enabled/improper permissions flaw sneak into an API?

To see how this multidimensional API flaw gets added to networks, we must break it down into its component parts. Let's start with the enabled debug features problem. Debugging is a useful tool that helps developers figure out why applications aren't performing correctly or making errors. With debugging enabled, errors and exceptions generate detailed error pages so developers can see what went wrong and fix problems. It's perfectly fine to have this active while an application is still in development.

However, there is a reason why most frameworks come with warnings about running debug mode in a production environment, likely right in the code where debugging is activated. For example:

# SECURITY WARNING: dont run with debug turned on in production!
DEBUG = True

In this example, debugging has been activated. The Django application will generate detailed error pages when an exception is raised. If this is done in a production environment, an adversary would have access to these error pages, which includes metadata information about the environment. Although most frameworks have debugging turned off by default, it's easy to forget to switch it back off if activated during a long development process. Then when the application moves to a production environment, it provides attackers with a lot of information about how to compromise an application, or even an entire server or network.

While enabling debug mode is mostly a standalone problem, the improper permissions and disabled security features vulnerabilities often work together. For example, in a real scenario provided by OWASP, an attacker used a search engine to find a database that was accidentally connected to the internet. Because the popular database management system was using its default configuration, authentication was disabled. Thus, by combining the improper permissions and disabled security features vulnerabilities, the attacker gained access to millions of records with PII, personal preferences and authentication data.

Eliminating the disabled security features/debug features enabled/improper permissions vulnerabilities

You probably need to make a two-pronged approach in eliminating this vulnerability. To remove the enabled debug part of the problem, simply add a check to the development process to ensure that debugging is disabled before moving an API or application to the production environment. From our example, the proper command to do that would be as follows:

# SECURITY WARNING: dont run with debug turned on in production!
DEBUG = False

Now debug features in the Django application are disabled with the DEBUG flag configured to False. No error pages will be generated in response to errors. If an adversary still gains access to error pages, they won't contain any useful metadata, and won't pose a risk to the application.

Eliminating disabled security features and improper permissions vulnerabilities is a bit more difficult because they can encompass a wide range of specific vulnerabilities. The best way to stop them is to develop a standard and repeatable process to allow for the fast and easy deployment of locked down assets to the production environment.

Even then, you should create a process where orchestration files, API components, and cloud services like Amazon S3 bucket permissions are constantly reviewed and updated. This review should also rate the overall effectiveness of security settings across the entire environment over time to make sure the organization is always improving its API security.

Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.

The mass assignment vulnerability was born because many modern frameworks encourage developers to use functions that automatically bind input from clients into code variables and internal objects. This is done to simplify code and speed up operations.

Attackers can use this methodology to force changes to object properties that should never be updated by a client. Normally this results in business-specific problems, like a user adding admin privileges to themselves as opposed to bringing down a website or stealing corporate secrets. Attackers must also have some idea of the relationships between objects and the business logic of the application they are exploiting.

However, none of that makes the mass assignment vulnerability any less dangerous in the hands of a clever and malicious user.

Before we launch into the full guide, play our gamified challenge and see how you fare:

How can attackers exploit the mass assignment vulnerability?

The scenario put forward by OWASP (and modified slightly by us) assumes a ride-sharing application that includes different properties bound to objects in the code using mass assignment. These include permission-related properties that users can change and process-dependent properties that should only be set internally by the application. Both use mass assignment to bind properties to objects.

In this scenario, the ride-sharing application allows users to update their profiles, as is common in many user-facing applications. This is done using an API call sent to PUT, which returns the following JSON object:

{"user_name":"SneakySnake", "age":17, "is_admin":false}

Because the attacker, Mr. SneakySnake in this case, has figured out the relationship between the properties and the objects, he can resend his original request to update his profile with the following string:

{"user_name":"SneakySnake","age":24,, "is_admin":true}

As the endpoint is vulnerable to mass assignment, it accepts the new input as valid. Not only did our hacker add a few years to his profile, but he also assigned himself admin privileges.

Eliminating the mass assignment vulnerability

As convenient as it might be to use the mass assignment function in some frameworks, you should avoid doing that if you want to keep your APIs secure. Instead, parse request values rather than binding them directly to an object. You can also use a reduced data transfer object which would provide nearly the same convenience as binding directly to the object itself, only without the associated risk.

As an extra precaution, sensitive properties like admin privileges from the example above could be denied so that they will never be accepted by the server on an API call. An even better idea might be to deny every property by default and then allow specific, non-sensitive ones that you want users to be able to update or change. Doing any of those things can help to lock down APIs and eliminate the mass assignment vulnerability from your environment.

Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.

Add developer-centric training to industry-standard SARIF files, directly in GitHub code scanning workflows with our new GitHub Action.

On September 30th, GitHub officially announced the general availability of GitHub code scanning. GitHub code scanning is a developer-first, GitHub-native approach to easily finding security vulnerabilities before they reach production.

Code scanning integrates with GitHub Actions " or an existing CI/CD environment " to maximize flexibility for development teams. It scans code as it's created, surfacing actionable security reviews within pull requests, and automating security as a part of a GitHub workflow.

A seamless approach to security for developers.

Built on the open SARIF (Static Analysis Results Interchange Format) standard, code scanning is designed to flex with the ever-growing needs of organization, so they can include things like open-source and commercial static application security testing (SAST) solutions within the same GitHub-native experience.

Third-party code scanning tools can be initiated with a GitHub Action or a GitHub App based on an event in GitHub itself, like a pull request. The results are formatted as SARIF and uploaded to the GitHub Security Alerts tab. Alerts are then aggregated per tool, and GitHub can track and suppress duplicate alerts. This allows developers to use their tool of choice for any of their projects on GitHub, all within the native GitHub experience. Quite simply, it cuts through the disruption of some traditional approaches to security, and it respects the developer workflow.

Yesterday, Secure Code Warrior was featured by GitHub as the only developer-centric training provider in their blog post, Third-Party Code Scanning Tools: Static Analysis & Developer Security Training, alongside Synk, Checkmarx, Fortify On Demand, Synopsis and Veracode.

While many SCA/SAST solutions provide lots of details for each of the vulnerabilities discovered, and references to published advisories and associated CWEs, not every developer is a security expert, nor should that be expected of them. Practical, usable advice and tools are the key to actionable awareness.

Contextual micro-learning.

The more context developers have for vulnerabilities, the more they're able to understand the risks, prioritize fixing the most pressing issues and ultimately prevent them in the first place. That's where Secure Code Warrior comes in. Our mission is to empower developers to write secure code from the very beginning through fun, engaging, and framework-specific training, helping them think and code with a security mindset to achieve rapid improvements in security compliance, consistency, quality and development speed.

GitHub code scanning integration

Secure Code Warrior has built a GitHub Action that brings contextual learning to GitHub code scanning. This means developers can use a third-party action like the Snyk Container Action to find vulnerabilities, and then augment the output with CWE-specific, hyper-relevant learning.

The Secure Code Warrior GitHub Action processes an industry-standard SARIF file and appends contextual learning based upon CWE references in a SARIF rule object. This empowers development and security teams to not only find vulnerabilities, but enrich supported SAST tool reports with actionable knowledge that helps them prevent vulnerabilities from reoccurring.

Ready to try it out for yourself?

Get the action for free directly from the GitHub Marketplace here.
Learn more about the Secure Code Warrior GitHub Action here.

This series of blogs will focus on some of the worst vulnerabilities as they relate to Application Programming Interfaces (APIs). These are so bad that they made the Open Web Application Security Project (OWASP) list of top API vulnerabilities. Given how important APIs are to modern computing infrastructures, these are critical problems that you need to keep out of your applications and programs at all costs.

The missing function level access control vulnerability allows users to perform functions that should be restricted, or lets them access resources that should be protected. Normally, functions and resources are directly protected in the code or by configuration settings, but it's not always easy to do correctly. Implementing proper checks can be difficult because modern applications often contain many types of roles and groups, plus a complex user hierarchy.

But first, why not jump in and play our gamified challenge to see where you're at with navigating this tricky class of bug?

Let's take a more in-depth look:

APIs are especially vulnerable to this flaw because they are highly structured. Attackers who understand code can make educated guesses about how to implement commands that should be restricted to them. That is one of the main reasons why the function/resource level access control vulnerability made the OWASP top ten.

How can attackers exploit the function level access control vulnerability?

Attackers who suspect that functions or resources are not properly protected must first gain access to the system they want to attack. To exploit this vulnerability, they must have permission to send legitimate API calls to the endpoint. Perhaps there is a low-level guest access function or some way to join anonymously as part of the application's function. Once that access has been established, they can start changing commands in their legitimate API calls. For example, they might swap out GET with PUT, or change the USERS string in the URL to ADMINS. Again, because APIs are structured, it's easy to guess which commands might be allowed, and where to put them in the string.

OWASP gives an example of this vulnerability of a registration process set up to allow new users to join a website. It would probably use an API GET call, like this:

GET /api/invites/{invite_guid}

The malicious user would get back a JSON with details about the invite, including the user's role and email. They could then change GET to POST and also elevate their invite from a user to an admin using the following API call:

POST /api/invites/new
{"email":"shadyguy@targetedsystem.com","role":"admin"}

Only admins should be able to send POST commands, but if they are not properly secured, the API will accept them as legitimate and execute whatever the attacker wants. In this case, the malicious user would be invited to join the system as a new administrator. After that, they could see and do anything that a legitimate administrator could, which would not be good.

Eliminating the function level access control vulnerability

Preventing this API vulnerability is especially important because it's not difficult for an attacker to find functions that are unprotected within a structured API. So long as they can get some level of access to an API, they can begin to map the structure of the code and create calls that will eventually be followed.

As such, all business-level functions must be protected using a role-based authorization method. Most frameworks offer centralized routines to make that happen. If your chosen framework doesn't, or if the routine it has is difficult to implement, there are many external modules that are built specifically for easy use. Whatever method you ultimately choose, be sure to implement the authorization on the server. Never try to secure functions from the client side.

When working to create function and resource level permissions, keep in mind that users should only be given permissions to do what they need and nothing more. As is always the case when coding APIs or anything else, practice the least privilege methodology. It will secure your environment and head off a lot of cybersecurity-related trouble down the road.

Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.

In this most festive of annual occasions for cybersecurity professionals, National Cybersecurity Awareness Month is a time many companies utilize to reflect on, and appraise, the general security awareness heartbeat across the organization. And with 62% of business experiencing a phishing or social engineering attack in 2018 alone, the importance of ensuring every individual in the business -- whether in a security role or not -- has adequate cybersecurity awareness training cannot be overstated.

As an increasingly global event, the month represents a catch-all for discussing best practices, and the initiatives are deliberately surface-level. However, even organizations with robust security programs and in-house specialists can use this time to assess the more technical teams for what they need to become more security-aware in the context of their role.

For AppSec specialists, development team leads, and the more security-savvy members of the engineering cohort, it might feel a bit like being taught how to suck eggs, but it is these champions within the business that can push security and safety to new heights, company-wide.

How to elevate your Cybersecurity Awareness Month

This is a golden opportunity for the security team to extend something of an olive branch to the development team, perhaps in the form of inter-team activities and programs that can help developers feel more positive about security in the context of their work.

Some kick-off ideas include:

1. Help developers get the support they need to learn about secure coding. Not having the right tools for the job is a great way to feel justified in slam-dunking a task into the Too Hard Basket. If developers don't have the right training and tools to see security as a priority in the coding process, then it's no wonder so many teams are ill-equipped to keep common vulnerabilities out of their code.
   
   Use this month to understand what is missing in the development tech stack, which managers can work together to improve communication and increase security visibility, and who can continue advocating for and championing security going forward.
   
2. Host a "Lunch and Learn'event. The cybersecurity and development communities are, in general, brimming with incredibly generous people who are only too happy to share their expertise. Reach out to conference speakers, tech peers in other companies, or even local OWASP chapters, and see who might be able to come in and chat with the team, or record a webinar with someone in the organization. It's a relatively quick win, and it can be a huge benefit for up-and-coming developers to see different security career pathways in front of them.
   
3. Gather for some friendly competition. Learning about security is a lot more fun when you do something a little different and special. Secure coding tournaments are a great way to get developers testing their secure coding skills, and competing with their peers in a gamified environment. Get a fancy dress theme happening, and be creative with the teams (how about developers vs. their managers?). Order some pizza, drinks, get some energetic music pumping, and it can be an event to remember for the whole organization.

Giving back to the community: Download your free Secure Code Bootcamp app

I'm a developer myself, and it has always been the case that we search for what we can share and use for free. It's a point of pride to make some freeware that might help others, and this month is a good time to reflect on our roots and look at what we can provide to the community.

To that end, we're pleased to announce our new, free app, Secure Code Bootcamp. This is a pocket secure coding companion for coders who want to challenge themselves, progressively boosting their security awareness anywhere, anytime.

Download the app for iOS and Android now, and learn how to locate and identify OWASP vulnerabilities in Node.JS, Python:Django, Java:Spring, C# .NET: MVC:

With the lack of resources and rate limiting, API vulnerability acts almost exactly how it's described by the title. Every API has limited resources and computing power available to it depending on its environment. Most are also required to field requests from users or other programs asking it to perform its desired function. This vulnerability occurs when too many requests come in at the same time, and the API does not have enough computing resources to handle those requests. The API can then become unavailable or unresponsive to new requests.

APIs become vulnerable to this problem if their rate or resource limits are not set correctly, or if limits are left undefined in the code. An API can then be overloaded if, for example, a business experiences a particularly busy period. But it's also a security vulnerability, because threat actors can purposely overload unprotected APIs with requests in order to perform Denial of Service (DDoS) attacks.  

By the way, how are you doing with the API gamified challenges so far? If you want to try your skills in handling a rate limiting vulnerability right now, step into the arena:

Now, let's go a little deeper.

What are some examples of the lack of resources and rate limiting API vulnerability?

There are two ways that this vulnerability can sneak into an API. The first is when a coder simply doesn't define what the throttle rates should be for an API. There might be a default setting for throttle rates somewhere in the infrastructure, but relying on that is not a good policy. Instead, each API should have its rates set individually. This is especially true because APIs can have vastly different functions as well as available resources.

For example, an internal API designed to serve just a few users could have a very low throttle rate and work just fine. But a public-facing API that is part of a live eCommerce site would most likely need an exceptionally high rate defined to compensate for the possibility of a surge in simultaneous users. In both cases, the throttling rates should be defined based on the expected needs, the number of potential users, and the available computing power.

It might be tempting, especially with APIs that will most likely be very busy, to set the rates to unlimited in order to try and maximize performance. This could be accomplished with a simple bit of code (as an example, we'll use the Python Django REST framework):

"DEFAULT_THROTTLE_RATES: {
       "anon: None,
       "user: None

In that example, both anonymous users and those known to the system can contact the API an unlimited number of times without regard to the number of requests over time. This is a bad idea because no matter how much computing resources an API has available, attackers can deploy things like botnets to eventually slow it to a crawl or possibly knock it offline altogether. When that happens, valid users will be denied access and the attack will be successful.

Eliminating Lack of Resources and Rate Limiting Problems

Every API that is deployed by an organization should have its throttle rates defined in its code. This could include things like execution timeouts, maximum allowable memory, the number of records per page that can be returned to a user, or the number of processes permitted within a defined timeframe.

From the above example, instead of leaving the throttling rates wide open, they could be tightly defined with different rates for anonymous and known users.

"DEFAULT_THROTTLE_RATES: {
       "anon: config("THROTTLE_ANON, default=200/hour),
       "user: config("THROTTLE_USER, default=5000/hour)

In the new example, the API would limit anonymous users to making 200 requests per hour. Known users who are already vetted by the system are given more leeway at 5,000 requests per hour. But even they are limited to prevent an accidental overload at peak times or to compensate if a user account is compromised and used for a denial of service attack.

As a final good practice to consider, it's a good idea to display a notification to users when they have reached the throttling limits along with an explanation as to when those limits will be reset. That way, valid users will know why an application is rejecting their requests. This can also be helpful if valid users doing approved tasks are denied access to an API because it can signal operations personnel that the throttling needs to be increased.

Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.