lesson 5.3. It's a little bit of a catch All. I just want talk about logic, flaws, automation, defect, tracking. Just a weekend. I kind of tie up some of the loose ends here.
The objectives. I wanna discuss the need for a privilege. Testing s We could test authorization and find. Find some of these business logic flaws.
Take a look at secure code box integration. Just another one of tools you could use we're using. I guess I mentioned
Jenkins, but this is another option. You could use a few for doing your dynamic scanning and then take a look at defect. Does Joe for integration, for identifying issues, things like that tracking them.
We talk about business logic.
The issue with the dynamic analysis tools is a really good at testing pattern sequel, injection, cross site, scripting things like that. But they're not good at testing for authorization. So can I.
If I'm logged in this issues or I should only be able to do these type of actions, I shouldn't be able to. I could only read. Or maybe I could only edit.
And these may these tests may be performed in the functional testing. But
tests by non security people are usually made to fail. Are sorry made to pass, not to fail just because that's the That's the nature. They're trying to make sure that the patterns they put in our what they expected versus when we do security testing. We're looking for negative. We were really one. Identify vulnerabilities and
root around and try to find bad things.
So we want to automate test cases again for, like, testing In what data can you access? What actions? Maybe if it's an a P I what endpoints cannot hit. Which ones of my getting failed access to if I don't have a from not logged in as the right account?
So there's There's a block here from Rapid seven. You can go take a look at it. It's the top 10 business logic flaws, attack vectors. They rank them not gonna go through all of these, but you can see authentication, flag privilege, escalation, maybe issues with the cookie tampering because it's not set correctly.
LDA parameters aren't correct. The business flow
bypassed, so, expecting that they go through with this step this step. But they may be little jump step and it didn't actually verify that they were allowed to do that, or any time a type of file or all unauthorized. You are all access or kind of like I mentioned with the A P I certain user shouldn't be able to get a p I, but they are.
He was just expecting the user of the end,
Uh, that said, from a client to respect the rules as their defined in the application versus going off in a different path.
I have a question for you. Do. Do you understand why business logic is so difficult to test?
So as I mentioned, the tools are meant for security test patterns, not really testing cause for data access. And it's not that there's limitation in the tools or that they're incapable of it. It's just how can they understand, especially your very
customized application. They don't understand which, what, what is supposed to be able to access. You know what limitations are set,
so you need to add test using different authenticated users. So
if you're using a tool that can record authentication made, that's what you want. May want to run at multiple times with different authenticated users to test these these capabilities.
So as I mentioned, there's, ah, interesting tool out there called secure code box.
It has this tool chain to automatically scan applications. And if you're interested inside it, actually running its own Jenkins, uh,
tool that that creates this automated pipeline that uses Commander for the Business Process flow.
And it has these oldies micro services that are running, zap and map Nick tore acne, all these different types of tools. You don't need to see that from the outside. But if you're looking, if you're interested, how it's running in there and it can in just integrate with Travis Jenkins all these other tools,
everything is exposed via either web. You I or arrest a P I.
So what's going on is it has all these tools, and what you do is say, I want to scan, give and you give it a whirl, and then it creates a job within the tone pipeline to then
launch. Each one of these micro services what are ready but launch an attack using each one of these micro services so that you don't have to install your own zap your own Brackney version. It'll run all those for you present results. And again, if you integrate it
with Jenkins or whatever pipeline you're doing, it'll it'll say, Run the attacks or run that the test. And here's the result back,
and there's another option you can use again we're using in our demo. We're using Jenkins and integrating that
the results that way. But if you're if you get your using Jiro, you might have your own issue tracking. But there's a free tool that Lost created a project for called defects does defect. Oh, Joe,
and you can use it within ah, your two phases so you can do it in the integration phase and off the delivery phase.
Um, because it might be against we mentioned a while back. You may see some tests and certain phase, but till they get put into the application server and you might have some environment drift where there's different settings in the configuration for each of the APP server or the server that's running on, you might discover vulnerabilities differently,
and has bidirectional integration with zero so you can use even if using gear, and you want to track your security vulnerabilities in a different area.
so in a wasp as these benchmarks that that that they've integrated So the application security verification standard requirements so they'll match it to that within defect. Jo Jo. And that's what this is really doing is again you'll. You'll be running these tools and creating these vulnerability issues so that they could be tracked
and you contract them within defect. Jo Jo and give you ah, tracking tool.
How have vulnerabilities air fixed over time? Different qualifications like that?
Here's a quick quiz
to defect. Oh, dough is applicable. To which phases is it continuous integration? Is it continuous delivery or is it C i N c D.
So, as I mentioned, defects in the APP can be discovered during both phases and defect. Oh, Joe can provide the ability to associate the phase where the defect was discovered so you can actually tag it so that you can see through time. Maybe it was fixed here and it wasn't fixed. You was fixed later on, and you understand where the vulnerability is or if it's in both. You know,
it's a vulnerability that hasn't been fixed yet.
So in this lesson, we kind of is a catch also hit a couple of the ideas. A business logic flow. Look how you contract vulnerabilities. If you want to run an external scanner using the secure code box into that,
so next we'll just we'll we'll start the other fun. One that the Jenkins demo. We're gonna add the dynamic application scanning to our pipeline and and complete the next phase.