“Logic is the art of going wrong with confidence” - Joseph Wood Krutch

Continuing in our series in breaking down application security so that anyone can do it without hiring expensive teams of employees, we talk about something that is not exactly the sexy “security-security” related vulnerabilities (I argue otherwise), but most companies would love to be able to have none of. We’re going to be talking about business logic flaws and the even more importance of understanding your applicationto avoid these.

The Logic Is Not Logic-ing

Logic is hard. Can you do better than the kids here?

It’s easy to make a mistake because we’re not perfect. We don’t capture information perfectly, we don’t process information perfectly, and we don’t output logic perfectly. Nothing about what we do is perfect. And that’s okay!

We mitigate for this concern in software development by having others take a look at your code through something called code review. Another trained eye will read through your code, your description of what you’re attempting to write for, and they will critique it. (BONUS LIFE TIP: be kind to each other. publicly lambasting another dev for the code they output doesn’t really help anyone and makes you a person that people will avoid for help)

There are 5 results that come from a code review (or non code review):

1. code was not reviewed, and the logic for whatever business data being processed is pushed into production - right or wrong

2. code was “reviewed”, and a LGTM (“looks good to me”) was given and logic was pushed into production - right or wrong

3. code was (actually) reviewed, and a LGTM (“looks good to me”) was given and faulty logic was pushed into production

4. code was (actually) reviewed, and mistaken logic for whatever business data being processed was caught and fixed before it was pushed into production! The developer revised commit for a fix, and now we’re looking good! Yay!

5. code was (actually) reviewed, and a LGTM (“looks good to me”) was given and great logic was pushed into production

Yeah, so 4 or 5 are the ideal scenarios, which we want!

1 and 2 are not desirable and people will scoff at this, thinking that this is preposterous. How could anyone be doing this? Yet, many devs will tell you that they’ve come across some form of this in any company in the world. This is much more prevalent in the age of coding agents. I can talk more about best practices in another post.

3 is not desirable, but it can happen even within some of the best development teams on earth and this is what I want to focus on.

Telephone

So how does logic slip away from us and why?

Many will argue that it’s a skills issue and so there are countless memes about bad programmers as you can see below.

This isn’t false. Whether it’s on purpose or not, meaning there are people who don’t really care/try to improve/upskill and there are those who are on the path to doing things well, there are really bad programmers. I’ve met fantastic developers in my life who were taught one class of programming in college, and I’ve met people with whole degrees (even advanced ones) that don’t care for the quality of the code. For those who are on the path to bettering yourself everyday, I commend your efforts!

However, the more common issue when it comes to faulty business logic is that the exact business needs weren’t captured accurately/comprehensively enough for the developer to create a feature for. This often happens when business needs are provided from somewhere above in the chain and the requirements are passed downwards. With each person in the chain that it goes down, the original intent slowly decomposes. I wrote a bit about this here, but basically humans are imperfect and usually we hold on to high level objectives, but don’t necessarily go outside the bounds and think of the nuances of what could go wrong. We just want to make things work, but it’s important to:

Developers who aren’t totally aligned and aware of the business needs, will create a feature that is minimally viable and release it and patch as they go if there’s something that goes wrong. Being detailed in requests from the originator of the feature request is important.

Let’s talk through an example below!

Order Up, Profits Down (Example)

Imagine you created a web application that provides an ordering system for your restaurant. A business executive comes up with the genius decision to implement a discount code feature, and emails you, “Hey, I’d love to have a discount system where we can drive volume of orders coming in through generating individual discount codes for our customers and they can stack generic ones with their individual ones. Please have this ready for me by next Friday. Thanks!”

So within 2 weeks, you release a new feature that accepts discount codes for when you have promotions and want to drive volume of customers with the following two conditions:

1. people can stack discounts (for when you really want to drive a certain target group of customers to your stores)

2. issue unique discount codes generated server side for individualized discount codes sent to their emails

Sounds great on paper! What could go wrong?

1. If you don’t validate that the individualized discount code is tied to an individual and these codes are easily guessable or can leak to others, then people can stack a bunch of discount codes together and pay much less for food than intended. People can also make a bunch of new accounts with burner emails and cards and can get a whole bunch of discount codes that way.

2. If you don’t check / limit how much is being discounted, then people can stack as many discount codes as they want

3. If you’re discounting by the dollar amount and people can stack discount codes, theoretically if 1 and 2 this can lead to net LOSS with you owing people money/credit (if you’re doing that)

4. If you’re not invalidating discount codes after a certain period of time or usage, people can keep reusing these discount codes and with the premise of 3, you’d be bankrupt very quickly

I’ve had friends who would exploit some of these exact business logic flaws above (specifically 1, 2, and 4 - they didn’t connect a credit/money system for overage) from a well known local vendor, where they paid very little for all of their meals. The thing is that vendor never found out about it/patched it until a few years later. It’s extremely hard to find out exactly this type of behavior that is going on in your application when you have perfectly running code. (BONUS LIFE TIP: please don’t exploit things like this. these are businesses that work hard to provide real (not just shareholder) value sometimes. It could also be considered criminal if you get caught, so just be a good person and report responsibly!)

Oh God, what can I do to find/fix these

Yeah, the thing is, it’s extremely hard to be able to find these. Most security tools these days just don’t do such things because it’s not a problem that is syntacticby nature, but semantic.

The only way to know is to have entire application context (and business context), and be able to reason about things that can go wrong. Break down your app, feature by feature, route by route, and examine where it could go wrong. Sit down with your team and reason through each feature/route together on a white board. Talk through what the ask was/is, and what from the original feature ask is missing or assumed wrongly. Always be doing this during the design phase of every feature that comes out.

I can see the power of AI helping find some of these because these are machines that are designed to try to semantically reason, but without proper context, from both the business and application side, we’ll continue to have these.

Best of luck. Rooting for you!

Pigeon is a NYC Cybersecurity Services company, specializing in Application Security. If you or anyone you know needs application security services, please reach out to me at david@pigeonlabs.ai. We’re willing to work with you near and far!