The majority of application security problems stem from software bugs that leave the existing security controls, broken. However, even if the code is perfect it doesn’t mean an attacker can’t exploit it. The vulnerability can be hidden inside the business logic, not the code that powers it. This type of vulnerability is called . It’s when an attacker abuses a legitimate flow of an application so that it results in negative consequences. business logic vulnerability An example could be a contact form on a website that is used for sending out emails to the service owners. This form can be abused to send out spam messages instead of genuine support requests. When dealing with business logic vulnerabilities we enter a branch of security called anti-abuse. Fighting abuse often requires thinking about these problems more creatively, because unlike patching the bugs in the code the business logic often can’t be changed to mitigate the risk. We are stuck in a position where we can’t really the problem, we can only it. It requires active participation because an attacker will change the tactics as we put defense mechanisms in place. fix manage That's what makes it an . To better understand it let's look at the following diagram. adversarial problem So the defender directly controls stages 1 and 2, and the attacker directly controls 3 and 4. However, both of the adversaries control the entire cycle indirectly. The objective of the game for the attacker is to make sure that the attack doesn’t get detected. If it does, they need to be able to change the plans fast enough to try a different approach. The life of the defender is the same, but for different transitions. The defender wants to detect the attack and stage the defense as fast as possible. Translating that to the diagram the attacker wants for transitions 1 and 2 to be as long as possible and transitions 3 and 4 as short as possible. Contrary the defender wants transitions 3 and 4 take a very short time, but stretch out transitions 1 and 2. So, you may be wondering, how can it be applied in practice? 🤔 As a defender, it's easy to fall into the trap of spending too much time on intuitive solutions that don’t make the life of the attacker that much harder. I’ll give you an example. Let’s say we need to protect the contact form mentioned earlier from sending spam. We see that the attackers are using a bash script and that is reflected in the User-Agent header. Naturally you might think that we should block all attempts that come from this particular User-Agent. Since we don’t want the spam to be sent out we block the attempt right there on the page. However, what just happened is we gave the adversaries a very tight feedback loop to figure out our defense. To circumvent it they just need to spoof the User-Agent to look like a browser. It’s a simple change on their side and they are back in business. Not good for us, now it got harder to detect them. The attackers get stronger as we fight them. Keeping in mind the helps us avoid first-order-thinking and evaluate the consequences of an intuitive solution. adversarial cycle Co-published here.

How Does the Adversarial Cycle Apply to Coding and Security?

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

104 Stories To Learn About Go

105 Stories To Learn About Functional Programming

100+ Free Pluralsight Courses to learn Python, Java, and Spring Boot

10 Websites to Learn JavaScript for Beginners

104 Stories To Learn About Programming Top Story

10 Ways to Prevent and Manage Technical Debt—Tips from Developers

104 Stories To Learn About Go

105 Stories To Learn About Functional Programming

100+ Free Pluralsight Courses to learn Python, Java, and Spring Boot

10 Websites to Learn JavaScript for Beginners

104 Stories To Learn About Programming Top Story

10 Ways to Prevent and Manage Technical Debt—Tips from Developers

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps