Pentester Diaries Ep1: Understanding Business Logic

We are excited to share the first episode of a new podcast series, Pentester Diaries.

Pentester Diaries is a new podcast series that shines a light on the not so secret, yet somewhat anonymized, and at times glamorized life of offensive security professionals. In this series, we will gather pentesters from across the globe to learn more about who they are, what is top of mind for them, how they approach pentesting, and much more pentesting. Pentesting isn’t just about finding cool bugs, and hackers aren’t just these black hoodies that the media presents them as. It’s about understanding applications, continuous learning, leveraging the right tools and techniques, as well as collaborating and growing with others.

For our first episode, Jon Helmus talks with Dan Beavin, a pentester with a passion for applying his architect background to security. In this episode, they will dig into business logic, exploring the importance of understanding every aspect of an application before testing.

Consume this episode how you prefer. We offer audio, video, and written versions of the episode below.

Listen to the podcast here:

*Coming soon to Apple Podcasts, Google Podcasts, and Stitcher

Watch the video podcast:

Prefer to read the episode? Below you can find a transcription of the podcast:

Jon Helmus: (01:06)

Welcome everyone to this episode of Pentester Diaries presented by Cobalt. I'm your host, Jon Helmus. And today we have awesome Cobalt Core member, Dan Beavin. Dan, thanks for being on the show and taking the time to be with us today.

Dan Beavin: (01:19)

Thanks, John. Appreciate it, excited to be here.

Jon Helmus: (01:22)

Awesome, cool things all around. So let's go ahead and jump into a dude. So looking at your background, there's a lot of things you do. I know what you do. Cobalt knows what you do, but let's tell our listeners a little bit about yourself. So if you could just give a brief intro about what you do outside of Cobalt and then also what you do here at Cobalt.

Dan Beavin: (01:56)

I've been in architecture security for about eight years now. Did my first pentest, in 2015 and had been pretty much hooked ever since then. Web applications are really more of my focus with Cobalt, but in my day-to-day job, I'm a principal security architect. So I spend time, architecting whole solutions from a security standpoint, but also I run our red team as a day job. So I do spend a lot of time doing social engineering, exploit development, adversarial emulation. So very different from pentesting, but very similar to pentesting too.

Jon Helmus: (02:27)

Yeah, no, I mean, especially red teaming is a lot different and I mean this diverts out of the conversation, but there's a lot of times where we'll see people mentioned red teaming and they think it's synonymous with pentesting. It's just like another terminology for it. Or they'll say red teaming thinking it's something different, layout the attributes and you're like, no, that's just pentesting. So, that's interesting, the way how your day job is, and the way how it works with pentesting is also interesting as being a principal engineer. I mean, today's talk is a lot about business logic, like how we see that in different applications. Right? So as a principal engineer, you're seeing that in its development phase, right.

Dan Beavin: (03:15)

For sure. Yeah. Part of the processes were built into the SDLC process. So whenever new code is developed, we test it, and we do it from a pentesting standpoint. Primarily on the business logic side. Obviously, we look for your cross-site scripting, CSRF stuff, right. But from a business standpoint, we're always going to be heavily focused on the business logic to make sure that there is no possibility for random human intervention to modify data.

Jon Helmus: (03:45)

Gotcha. So just a question right out of the bag while we're on the topic, what does business logic look like? Like how do you define that for our listeners, especially when it comes to looking at it as a principal engineer or defining it as a principal engineer, or even as a pentester, what would your definition of it be?

Dan Beavin: (04:10)

So in really simple terms, you can essentially say business logic is whatever that application or system does for the business, right. That's just kind of the simple way that I've always described it. That could be anything from an automated process to a very manual one that's done by a human there are lots of applications that you will use on a day-to-day basis. And in any organization, a lot of them have automation, but there are still some archaic processes that require human intervention in there.

Jon Helmus: (04:42)

You said archaic and I immediately thought he means legacy. So big thing that you were talking about is business impact. And I think the difference between bug bounty and pentesting is that mature status that we have as a pentester rather than being a Bug Bounty Hunter is where you actually have to evaluate the business impact, right? Like you have to look at how this affects the business and not just the business, but like you have to break it down into subtopics/sub-domains, right? Like how does it affect the users? How does it affect the employees? How does it affect clients, stakeholders, things like that. Cause there are so many different things that an issue could potentially affect. So with that being in mind, what would be some of the positive and the negative impacts that derive from business logic?

Dan Beavin: (05:39)

So obviously your negative ones are always going to be a possibility of modifying data or data integrity issues or any type of just exploit or vulnerability. In general, that is always going to be negative. But what is interesting is sometimes what I find as an exploit or vulnerability actually turns out to be a positive use case for a company.

An example could be where an individual is doing something that's a very manual process, right? You said legacy, I like archaic, but we'll go with a legacy for this. A legacy process of where a manual process has to be done. And the exploit is that we're able to run a script that can do that process a thousand times in a couple of seconds, well, that could actually be a positive where they can say, well, this manual process that's being done by a person doesn't really need to be manually reviewed. We just didn't know how to automate it.

So essentially you become a pseudo developer by giving them some scripts or background information on how you were able to automate that a little bit faster. That's a positive outcome from it. Occasionally you will see some positive outcomes from testing, but generally, the positive you're going to see is that you're going to find a broken process in the way an application flows are human flows, and they're going to be able to shore that up.

Jon Helmus: (07:11)

Gotcha. And then really to like kind of sum it all up is why is it important to know that? And especially why is it important to know it as a pentester? I think we should really look at it from the high level and then the granular level is as a pentester. Why is it important?

Dan Beavin: (07:27)

So, from a business standpoint to understand business logic and business flows in the way your application actually handles things, I spent a lot of time in manufacturing. So I'll use a great manufacturing example. When you have workers on the line and you're producing products, you know that in a day, every worker can produce 50 widgets, right? And day after day, everyone's producing 50 widgets, and then in one day someone creates 300 widgets. Immediately, that’s going to throw up a red flag of how did this happen? What broke in the process or the logic to do that? And it can be a number of things. And generally what it is is somebody found a way to quote-unquote, game the system, in a sense that they were able to do it more quickly. Part of that in a manufacturing environment, maybe, they had to walk from here to here, one product at a time. Well, what if they just brought 10 over at a time, instead of doing one at a time, and you basically are looking for that type of stuff–. when you're a pentester you're seeing this process being done one to one. And you're like, what if I did a hundred to one does the application handle it properly? Does it process the data properly, or does it become a bottleneck, and cause an error to fail or the system to fail. Nine times out of 10 when you're looking for a one-to-one scenario and you do 101, and it works. And it's simply because they never thought about doing it that way before. So a lot of times when you're finding these business logic issues as a pentester, you're actually just finding business improvements that the developers never thought about before.

Jon Helmus: (08:13)

Yeah. I'm sitting here thinking like, man, I can't tell you how many times I've come across stuff where I'm just like– it's not even like a bad coding practice. Like it was implemented like that on purpose, or by design, but they just didn't expect for it to have that type of interaction or, that type of I guess traffic is the best way to say it. Right. Yeah, it's super interesting. And, that's why secure coding is so sought after, right. It's I mean,why you see secure application engineers or security application engineers and secure coding engineers. And like, they're hard to find because that's a hard gig to do, right. To have to tell developers like, Hey, this is where this is wrong and this is wrong. And then also help them out with it.

But I do like something that you said that chimes with me a lot. And I talk about this a lot everywhere I go. Especially here at Cobalt, is pentesting is not this big hacker kind of thing. It's not where you're throwing out your bag of tricks at your clients, just to say, Hey, we were going to hack everything that you got and show you what’s wrong. It's how do we make your business better? How do we improve your company? How do we improve the way, how you do things so that it can make your company generate more revenue, stay competitive, and stay within the market. And I think as like a pentester. That's what the big attribute to your position is, is that you have to be able to help people. And that's really what we're here to do. And I'd be curious from the principal side, like how your interaction with pentesters, as opposed to being a pentester, your interaction as a principal, interacting with pentesters on things like that.

Dan Beavin: (11:18)

It is very interesting because I do spend my moonlighting hours pentesting, right? So I'm in the trenches, but then my nine to five, I'm the person that those folks that are in the trenches are trying to explain their issues and their findings and stuff too. So everything, I always try to relate back to the business. My job is to be that intermediary between an executive and a pentester. Right.

So if you're a person in that position, you have to be able to understand the technical side of what is the logic issue actually is, but how does that relate to the business? Because pentesters especially with Cobalt, right? We work with a lot of different industries and a lot of different places in the world. It's impossible to know every regulation in every type of environment, right? So you rely a lot on that pentester-to-client interaction for them to better explain the business side of it.

And, and that's really where I get into asking a lot of specific questions whenever I am contesting and looking for business logic stuff, because you are given a finite amount of time as a pentester to go over an application, right. And you can't know every single thing about how the business interprets data or how the business uses that application in a two/three week period. It's impossible to do that and still cover your whole scope. So you have to rely on asking good questions and knowing what to go after. And a lot of times that person that's in a principal role (like myself) is able to do that. I'm able to speak the terms of the pentester, but also be able to get across the importance of the business as well.

Jon Helmus: (12:05)

Yeah, yeah, 100%. And, when you're talking about being able to answer that as principal, diving back into how we evaluate business logic as a pentest, or I know you kind of chimed in on it, but I'd like to go a little bit more granular with it. Can you kind of like at a low level can you walk us through how you would evaluate business logic on a potential, application and API call or something like that? What's your approach and what kind of questions do you ask yourself when you're looking to bypass any kind of business logic within an application?

Dan Beavin: (13:42)

So what I do on every pentest at the very beginning is once I get my access, I fire up Burp or whatever other proxy you want to use. I'm not advertising Burp but that's just my favorite one to use. I mean, Burp is going to pretty much be the standard, right. But some people like that. So no judgment there. Maybe a little.

Jon Helmus: (14:08)

I would say, I feel like our awkward laughs are kind of hinting at a little bit.

Dan Beavin: (14:14)

But at the beginning of the pentest, I'm going to go through every inch of the application that I can, I'm going to click every link. I'm going to submit every field. I'm not even looking at the proxy history at this point. I'm purely just doing it from a user input standpoint. So if I've got multiple tiers of access, I'm going to do it through all the different tiers of access user privileged user and then like an admin level. And once I've gone through all that and have a pretty good understanding of what the different functions do, I'm gonna go back and then start looking through the proxy history to understand from the backend, what is actually going on when I click this button. That's saying, submit, is it what's it really doing? Is it submitting data? Is it approving data? Is it simply just locking a field that's no longer able to be edited?

Like, what's actually going on there and once I've done that, and that generally takes up a good chunk of time. If you're going to spend 35 hours testing eight to 10 hours of your time should be understanding how the application works, because that's where you're going to be able to start, looking for that business logic issues or any other issues, right. If you don't know what the application's really doing. Sure. You can throw a bunch of scanners at it and just regurgitate what the scanner results are, but a client can do that too, right? Like you're not providing any value where you can really provide that value is understanding how the application works, the business aspects of it, and then be able to start looking at the business logic. And once I start going into that, because I've got all that data accumulated. Start digging through it, and I'm like, okay, what of these processes that are being done for manual could be automated. And, intruder is going to be a huge, helpful piece here where you're going to start importing different tasks into intruder, make some modifications to it and see, okay, throw 10 attempts at it. Well, okay. It does all 10 attempts in two seconds, whereas a human would have to take 10 seconds per attempt. So you're starting to work your way down that path of automation and trying to find ways that if you're relying on an individual to approve a timecard, for instance, and they're able to use something like an intruder and approve a thousand time cards in a few seconds. They're not really doing the approval process at that point, right? Like that they found a way to bypass that manual-looking in review of a process.

So the big thing is, is it able to happen, but also are you able to detect that it happened? If your system doesn't have proper logging in place to see that it even happens, how many people are out there doing that kind of stuff, and you just don't know that it's even feasible. So once I start getting to that point, obviously I'm going to start having questions. Some of these are questions that I ask myself, but sometimes I'll go back to a client and say what's the normal timeframe that you would expect a task to be completed by a person. If they have to go to three or four different locations, look at some data, make sure that everything jives and looks good and then go and approve it. How long does that normally look like for an individual? If we have real production data, that's great. If I can look at production data of what the normal timeframe is, and I know it normally takes 90 seconds for this to complete, that gives me that benchmark to work from.

Another big question is going to be, what does a user normally do? That you can give a user access to the system, but there's a lot of times different roles. You've got accounting, you've got HR. You got the IT business analyst side of it, right? Everybody's doing different things in these systems. And a lot of times you don't see an individual system for every single action anymore. You see a lot more of these larger ERP-type systems where it does everything in there, but you just have access to certain segments of it. So understanding what different users are normally doing. But you're going to run in cases where you do have one-off applications that do one single function. And sometimes those don't require as many questions as a large ERP system would.

Jon Helmus: (18:33)

I know I've done that where I've even had to like test static web pages where I'm like, I get a static webpage for a week and I'm like, what do I do?

Dan Beavin: (18:46)

What are you actually expecting to come out of this?

Jon Helmus: (18:49)

So there were a couple of things that I jotted down while you're sharing your knowledge, one thing is about the different users, right? You want to have that aspect of like what a different user can do. And it's not just an admin user and a typical user, but it's also different groups, right? Finance, accounting, things like that, right? Like HR, who has different permissions to view different things within the application. And you want to make sure that you view it from each one of those groups. And I think a lot of times we just say, no, just give us a user and an administrator, and we'll kind of figure it out, but then you're kind of missing the whole bucket, right? Where did you need to be able to look at what the other departments within the organization are doing. Because otherwise, you're just going to be making assumptions. And we can't assign severity in vulnerabilities off of assumptions. We have to have facts and data to back up our decisions because our decisions impact the business. I also like how you said, if you have 30/35 hours for an application, you’re probably going to spend about 10 hours just trying to understand it at a general level. And that's where it's always important to mention, especially to junior pentester cyber enthusiasts, wanting to get into offsec. Like pentesting isn't this big hacker sort of thing, where you're always in a terminal. A lot of it's just doing research and rummaging the internet to find out information about whatever it is that you're working with. Like, if anything, you become a master Googler.

Dan Beavin: (20:30)

Yeah. And that's why every resume I've ever written, says I'm proficient in inquiry-based aggregation. And when they ask me what it is, it's like, I know how to Google. I mean, that's just what it is.

Jon Helmus: (20:42)

I like the very polished term for it. There was something else you had mentioned too, where you were talking about like how the users are using it, and then also going outside of the scope of how a user interacts with the application. And I thought to myself, I was like, well, hackers don't care, or, well, I'm sorry, not hackers, cybercriminals, don't care how users interact with the application. They're not going to care. They're going to figure out any way they can to break the app and try to get whatever it is that they're trying to get. Right. Whatever that end goal for them is, they're going to do whatever they have to do. Right. Like even, I think there's the joke that says, 'Oh, that's not in scope’ said no hacker ever, or no cybercriminal.

I think that's the interesting thing that we see, especially in like SDLC where security is brought to the table, but I think having that an offensive security professional, or someone who has an offensive security background, even such as yourself, like being a principal, but you do understand the threat vectors and the threat side of the house, and offering that type of input on any part of the SDLC, any type of like CIC pipelines, DevOps pipelines, any kind of thing that's in a development-to-deployment phase. Having an offensive security professional within that pipeline is going to help out, because like you said, they're going to look at business logic during the development and the deployment. And they're always going to think outside the box in that sense of like, okay, a user can use it like this and a security person would say, okay, well, let's make sure it meets these controls based off of whatever framework we have to meet, but then a guru such as yourself says what about, what a cybercriminal can do. Right?

And there was one thing that you, you went into the weeds with and I wanted you to, if you can just give a quick elevator pitch on what it is because a lot of the individuals that will be listening to this are junior pentesters. So you’ve talked a lot about Burp Suite, and we all know what Burp Suite is. Because it's the web app interaction tool that we get, the web proxy. But what is an intruder, right? You talked a lot about the Intruder and if you could just give a quick elevator pitch on what Intruder is so that our listeners know what exactly that function within Burp Suite does.

Dan Beavin: (23:12)

So a lot of people are going to get their first experience with Intruder doing brute force password hacks, right? Like that is in most training courses, that's where you're going to see it from. Right. So a lot of people have it stuck in their minds and Intruder can only do brute force password. Well, it can do brute force of just about anything you want to do. Right.

So a lot of times what I'll do with intruders essentially is I'll pick the specific, git, or post query that I want to look at, right. You import that into Intruder, you pick which sections of it you want to modify with each request, right. So if you are, for example, trying to look at different employee information, right? Which employees do you have access to? You would want to modify the employee ID field every time, and then with Intruder you can put in a list of all the different employee IDs. So if another place in the system you're able to export all the employee IDs, you dump that into a text file, upload that into an Intruder, and basically start the attack and it will go through. And give you status codes for every page to tell you, yeah, you were successful or no, you were not successful in accessing that. So it's great for business logic, but it's also really good for looking for like IDORs too, to see if you were able to access a page that you weren't supposed to do.

Jon Helmus: (24:30)

Also, Indirect Object Reference (IDOR). Can you mention quickly what that is as well?

Dan Beavin: (24:36)

So the simple terms without going technical in the weeds, right. I'll always explain it as you've got a user A and user B, and they're both salespeople and you have your specific accounts as you're responsible for in the system. Well, user A shouldn’t be able to access user B’s sales accounts, but in an IDOR situation, A user can access all of user B's sales, or service accounts. And, Intruder is a great tool for that, but another one, IT authorize is a really good one, too, if you want to specifically focus on IDORs, I know this isn't a topic on IDORs, but I always like to pitch Autorize. It's a really good one, use it all the time, a great tool.

Jon Helmus: (25:24)

I mean, you say that but when I think of business logic abuse, a lot of times, I think it derives from IDORs, to be honest, in my opinion, just being able to reference different IDs, to see what can this user view different data, or can this user reference different data or reference a different, anything within the application. And I mean I feel like typically IDOR gets chained into that.

Dan Beavin: (25:52)

For sure. Yeah. Especially when you start dealing with confidential data or a user being able to see admin screens. I mean, that's one of the most common things is they're like– well, they don't have the admin button on their screen. Okay. But do they have access to the admin URL? Well, yeah, but they don't have the button on their screen. I get where you're coming from. And 99% of the time, the user's not going to click that or are not going to be able to find it, but it's really simple to use a directory browser and find that URL and click it. And now all of a sudden you've got admin privileges.

Jon Helmus: (26:28)

Again, we always have to argue we're not looking at this from a user standpoint. We're looking at this from a criminal abuse kind of standpoint.

Dan Beavin: (26:37)

The way I explained it, you're not giving it to a user. You're giving it to a toddler and you're going to let them see if they can find something. Like a toddler will break everything that's handed to them.

Jon Helmus: (26:49)

I like that idea, is this application toddler-proof?

Dan Beavin: (26:54)

Before you ever give it to a pentester, give it to a two-year-old and see if they can break.

Jon Helmus: (26:58)

I like that idea. So we are coming close to an end here, but I do want to ask a couple more questions. So one of the main things that I think is great about being a pentester is that you get to kind of look at the business impact of the vulnerabilities that you find and the severity that you assigned to that vulnerability. Right? So when we're finding things, when we find an issue, we'll look at the severity based on like a CSS score, a CWE, a bunch of different data points, right. And we say, okay, based on this and this, it should be a critical or high, but then we also have to look at the more qualitative side of the house where we're actually looking at, okay, how is this impacting the business? Should this high become a critical, or should this high become a medium. So if you could really quick, could you give an example where a business impact completely changed the impact or the severity of a vulnerability that you assigned during a pentest?

Dan Beavin: (28:05)

Yeah. So this wasn't a pentest with Cobalt. I want to throw that out there. I added a test where if you knew a specific URL, which was a very esoteric-looking URL, it was not super human-readable to know what this page was. But if you knew the URL, you could approve a paycheck for any employee ID. So one of the fields within that URL was the employee ID that was Base64, coded that URL. I mean, obviously it was encrypted, right? So safe. Right there, security through obscurity. Right. But essentially what happened was, if you knew the URL and you hit that URL with the employee ID would automatically approve a payment. And part of the URL field also was the amount that the payment was for, right?

So a couple of security issues and in there just all together. And it was an internal application that they were like, well, attackers are never going to get to it because it's not externally facing. Which I get here, I get the logic of someone from the outside is not going to get to that directly. But the offensive red team inside of me said, somebody is already in your network anyway, likely they just haven't found this. I mean that's a whole other topic. I don't want to, we could go for an hour on nation-state stuff. But so, had the URL had a list of employee IDs just picked one out of it and submitted that URL 15 times in every one of them showed as successful. So I said, well, let's just go for broke here. Put in intruder for 10,000 attempts. So this payroll paycheck/paycheck run showed 10,015 paychecks go into one employee ID. I had them verify in their logs that they were all successful. So this individual play ID was going to get 10,015 direct deposits on one day for like $500,000 total in money. So the system allowed it to happen, which in the beginning it was already a high issue because you could do that without having any system access. You just needed to know that URL employee ID, and then the amount you wanted to pay. And it would pull where to pay the money to, from that employee ID in the system. So it was already high.

What made it critical, to me, was you could put that money in anywhere. If you were a malicious insider, and you knew that yeah, you could send 10,000 paychecks to yourself in one day and disappear.lOr Likely there would be some other mitigating controls in place, right? The bank would notice 10,000 go into one person, HR maybe reviews it and their reports normally 50 pages. And this day it's 540 pages because somebody ran 10,000 extra direct deposit. So there's a lot of other controls in there that should catch it. But that's when you start getting into that business logic a little bit and business impact is what if those controls weren't there? What if it was paper checks that were being sent out and this individual got well, let's not use 10,000. They did 50 paper checks. And just over the course of a couple of weeks went and cashed all those paper checks at different places around town. That would be a lot harder to catch going out.

Jon Helmus: (31:26)

Yeah, that's interesting. Yeah. Wow. And you say mitigated controls like HR checking it. And to me, I'm like that's a mitigating control, I guess, technically. If you really want to be technical with it, but we are humans and we make mistakes.

Dan Beavin: (31:33)

Yeah. I mean, obviously the system should never allow more than one direct deposit, per pay period. Right. Like if you wanted to do that, but also it should never be a static URL that you just plug an employee ID and a dollar amount into. Right. You could have just done one direct deposit for a half-million dollars. Would that have got caught?

Jon Helmus: (32:04)

Yeah. And there's so many rabbit holes that you can go down on the technical side and on the non-technical side of like, Hey, who's reviewing this. How do they review it? What's the process of checking balances on the people side. And, yeah. There's so many different things there, man. Well, wow. (Dan Beavin– So they weren't happy with that one. I mean, they were happy. It was found, but they weren't happy that it was right.) And that's at the point where you're like, I found this thing, let's make it better. And people are like, yeah, let's make it better. By the way, we have had this all along. Wait, what else?

A lot of times, too, when you're working with principals as a pentester and you see that and they're like, okay, what else is going on in the application? Like, what else is in this application? Or the network or wherever. Right. Because usually, it's not like this one-off thing like, ‘Oh, it was just an accident.’ That means that there are probably issues, like bugs, and other things on the applications being built. And also in other controls whether be like security boundaries on the network or within the domain or whatever. Right. So it's, it's always interesting when you find things like that, and then they're like, I wonder what other rabbit holes we can find in different parts of the network or other applications.

Dan Beavin: (33:20)

Yeah, yeah. That test had a lot of interesting stuff on it. That that was probably just the most interesting, but that there were a lot of simple things that were missed. And when it boiled down to, when we actually talked to the client, it was just that the developer's focus was on doing development as fast as they could and getting stuff out the door. Like they didn't have the time to do it as secure. And they'd never been trained how to do it securely. No one understood that putting the parameters in the URL was going to be a bad thing because they never thought about an attacker using that against them. They were like, well, it's Base64 code. They don't know. It's like, well, yeah, Burp takes two seconds to reverse what Base64 code. Right. Like, it's not hard to do that.

Jon Helmus: (34:06)

No, it's super simple in two seconds. Isn't even like, that's not making it too drastic. Like it takes two seconds, two seconds. Yeah. No, it's super simple. Yeah, lots of good stuff. So we've talked a lot about a lot of things, a lot of good things. To like close off the episode. Can you just like, kind of give a highlight, recap, the highlight reel of what we've just talked about. The three big takeaways that the listeners should take from this episode.

Dan Beavin: (34:40)

Yeah. So I touched on this through the talk, but the number one biggest thing to me is always understanding every aspect of an application before testing. Anytime I do a test like I said, most of our tests are 35 hours, 8 to 10 of them are always going to be just learning and understanding how the application works. Very rarely. Are you ever going to see me submit a finding within the first couple of days because I'm just trying to understand how the application works. So that's always going to be the number one thing that I say in pentesting in general, but especially when you're looking for business logic stuff. You cannot accurately test business logic if you don't understand how the application works.

Number two is people think business logic is boring. A lot of times people are like “there are not that many things to test for it” or ”we'll do it at the end and won't really dig a lot into it.” Because a lot of times pentesters, bug hunters, and offensive security people, don't have the business background. A lot of us started in security and have always been in security. And for so long security was the basement dwellers. We were all hunched over our desks and hidden away from the business. But now security has a seat at the table for every business. And I think that's why business logic is becoming such a big deal now because security is being brought into these conversations. So you're not finding these super simple business logics, you got to get a little bit more creative now.

And then number three like I touched on earlier, all business logic findings are not necessarily a bad thing. Sometimes you might find a way that it can improve the process or an application because they just simply didn't ever think about doing it that way. So the big thing with that is if you want to find some of those positive business logic impacts you have to have a way for users to recommend changes or provide feedback on the application because the users are going to be your best source of improvement to a business logic and application flow, right. From a security standpoint, we can show you all kinds of stuff that security-wise, good or bad. But the people who are using the application eight hours a day, five days a week, giving them an avenue to say, 'Hey, I use this script that I wrote and it does my job 10 times as fast as the manual process.' You have built into the system that you got to give people avenues to go down that, and that's a really big thing to focus on when you're a pentester is looking for those ways that could be automated or not necessary. I don't want to say pentesters are out there looking for all the ways applications could be done better from an application usability standpoint. But when you are looking at business logic, you are essentially looking for that type of stuff, just from the security aspect.

Jon Helmus: (37:42)

Yeah. 100%, man. Yeah, I think the big thing is like, from your three points is just to keep it concise. If I could concise it into like one word each is, take your time, right? Make sure you, you gotta take your time when you're assessing things, it's not a race. And then, understand that what you're doing provides a lot of value. And then to top it off is, it's not what you're doing. Isn't going to be a bad thing. You're actually there to help improve the business, make them more mature, allow them to be more competitive within themselves and within their market. And just, good things all around. Right?

Dan Beavin: (38:18)

And on that last one, the big thing I always remind people as pentesters that is different than when you're a bug hunter. Sometimes the clients aren’t always happy to hear responses from you when you’re a bug hunter, I've been there before. Sometimes you submit stuff and you rub them the wrong way because you found something wrong with their precious. But when you're a pentester, you're hired by a client to come in there and they expect you to produce and find stuff. So there, they generally are not going to be upset with you when you find something, they may be bummed out that you found something, but they're not going to be upset with you.

Jon Helmus: (38:36)

100%. Well, I think that about wraps it up, Dan, thank you again, sir, for taking the time to be with us today and everything. We'll make sure that if anybody wants to contact you, we'll make sure to put contacts and the notes and all that good stuff. But then, but again, thank you again for taking the time to be on the show today and for all the listeners out there, we spoke with Mr. Dan Beavin today and we'll see everyone on the next episode.

Dan Beavin: (38:42)

Thanks, Jon. Thanks, everybody.