Watch to learn how you can get the most out of a web application penetration test, as well as what to expect from a web application penetration test.
Listen to James Farnsworth (Senior Penetration Tester) and Garrett Adler (Senior Penetration Tester) discuss how you can get the most out of a web application penetration test, as well as:
This webinar was given on February 27, 2024.
Hello, and welcome to today's webinar. I'm James Farnsworth, the senior penetration tester here at Security Metrics. I'm joined by Garrett Adler, who is also a senior penetration tester for for Security Metrics. Today, we're gonna be talking about web application penetration testing.
This is kind of like the third part in a three part series. We talked about externals and internal penetration testing last time. This one is slightly different. Application penetration testing is more specialized towards web applications and what kind of attacks can be possible with that.
Today, that's what we're going to be talking about. So basically, if you have a passing interest in web applications, you have a web application that you that is kind of centered to your business flow and what you have, this kind of this this webinar is for you. We're just gonna dive right in. Keep in mind that this webinar is going to be recorded. So if you have, questions or you didn't or there was a part of the webinar that you missed that you wanted to come back and look at, please feel free to we're gonna be sending out that recording. Also, keep in mind, we are taking questions.
So as we go through, if you do have them, please interact with us on the website. Feel free to chat questions, and someone will reach out to you, if you do put in a question. So please interact with us, ask questions because there is going to be a question section at the end where we answer those.
And again, if we don't get to to them, someone will reach out to you. So web application tests, Garrett. We're gonna get into it.
Talk to me about, like, in this space, what's been happening in in real world scenarios for types of attacks that are happening?
Yeah. So real world scenarios, you know, recently, there was the twenty three andMe data breach, which resulted from what's called the credential stuffing attack. Attackers basically enumerated breach databases, identified, you know, very large list of emails and password combinations and just sprayed them at twenty three andMe, see which accounts you could get into. And, unfortunately, humans are very bad about reusing passwords, and they were able to access a large number of accounts.
And, yeah, gain access to that. They call that a data breach. It's really they just log in as a bunch of different people.
Yeah.
Going further back, the really famous one, the one that everyone talks about in this space is RockYou.
Probably the largest data breach, affecting a web application in history, impacting something like eight million users or accounts or, you know, something crazy. And to this day, it's still the standard when we're looking at cracking passwords or, you know, enumerating like breach databases. We always look at RockYou first.
Yeah. Something that stood out to me while you were talking was I think there's this always this question of when when I'm when I'm thinking about the services that we offer, different things that we're doing, there's always this question of, like, so what? And I think for this one specifically, when we talk about, like, web application penetration tests, where it's like, why would I be interested in that? It comes back to that.
So what question? And it is almost always around data always. And I think that's kind of cool that you brought up Rocky because like, when I think about, like, like you had mentioned, like, that's the standard, like when people start learning how to like hack, like it is always the word list. And I think it just kinda demonstrates, like, the big so what of this is, like, the impact that we like, the data has.
And I think it's funny because of funny is, like, obviously a weird term, but, like, interesting because we like, so much of the applications that we deal with, like, the big so what is data, and what can someone do with that data, and how does that impact your business? And if somebody got that data, what could you do with it? Those kind of questions.
And so when you were talking about those, I was like, one of the common themes between both of those was what the data you could get from those apps. And I, I, I just really liked that because I think it also ties back in that question of who is this webinar for? Right. And why is it important? Because if you have an application that's that has data, the biggest one of usually the biggest thing that we see is if somebody were to attack your application, what could they do with the data and what data could they get?
Yeah. I mean, if you look at, like, what attackers are trying to do and what these really bad actors are trying to do is that data, they don't really care about it themselves, but they can sell it to third parties who do care about it. So that data is worth its weight in gold.
Absolutely.
And, obviously, like, in in the other webinars where we always have this, like, here's what's happening in current events slash also here's what happened historically.
And we always kind of transition in this thing where it's like, okay, if you're not these really big companies, like, how does it apply to you? What are the things that we've actually done? And and what are some kinda, like, war stories around it? So when you're thinking about tests that you've been on that have been specific to web applications, do you have any experiences that stand out as, like, yeah, that that was really, like, a good example of a web application penetration test.
Yeah. Of course. And there's, you know, there's one, that stands on my mind that I just I think about because it happened recently that I'll save to the end and I'll let you talk about, but it's your local file inclusion where you're able to basically get every secret that a company had. I'll let you talk about that one.
But, more like traditional things we find in web applications, tests like we're going after data. SQL injections are huge. Altering the back end SQL queries get direct access through, like, a vulnerability within your web application to your database. From there, we just pull the entire contents of that database.
That's huge. That's, you know, your crown jewels as we always say in the webinars.
We, you know, we look for your traditional web application vulnerabilities, so SQL injections. Any way we can get remote code execution. Again, if we can get code execution on that web server, we can go for data. Cross site scripting, maybe we can't get the data, but if we can, you know, get arbitrary JavaScript executing in a victim's browser, we can still compromise that victim's account. We can still, you know, go after your end users.
Maybe it's broken access control. You know, you have a superuser account within the application they use to to administer things, and we as a regular person become that superuser.
But it all tracks back to data.
Ab absolutely. And the the funny thing, you're like, do you have that local file included? Let you talk about that. And when you were saying that, I was thinking like, yeah. Like, you had brushed over SQL injections, and it makes it's it's one of those things where it's it may it makes me smile because there was that one time where you just seemed like test after test after test. You kept finding SQL injections, and then it almost always led to, like, the internal network remote code execution and domain administrator.
And, I just think that's one of the things that is interesting is how central web applications are to everything. Because it wasn't just the app, it It wasn't like in the case where you're talking about everything for, like, SQL injections leading to, like, domain administrator, the data that was retrieved or, like, the access access that was gained wasn't only limited to, like, that application. Like, it leads to different things. And in the case of the local file include that you were talking about, that one was, like, really interesting to me because one of the things that we focus on a lot is how does this impact your environment and how does this, like, affect what the way that you've coded things.
And that's really, really interesting because more than any of the other types of penetration tests we do, web applications seem to be one of the most bespoke and interesting because you're literally coding something. And what that means is you're taking someone's ideas and you're basically just codifying them. You're writing them down. And so they're very, very, very very custom and very, very unique.
And in the, in regards to the local file include like, that was interesting because the local file include normally be like, maybe that's like a medium impact, but, like, as you start looking at it and exploiting it, you realize, oh, well, like, they were using cloud stuff.
And I was like, well, oh, it's really common in cloud stuff to have environment variables with passwords and API keys.
And then all of a sudden now in we're kind of like a similar thing to the SQL injection conversation.
Now that I have all of these API keys and all of these environment variables and all of these passwords and database names and all of this connection information for what that app actually interface display with. It's not just limited to the app anymore.
And so I think that's one of the things in regards to, like, when I high when when I think about it, the the, so what really is like, it's very, very custom even more than any of the other types of jobs that we do, because literally it's gonna tie in with everything and it's gonna be very unique if you've made it because you're taking someone's unique mindset and and basically writing it down. I'm gonna transition from kinda like this war story area into, like, if you're getting ready for a web application penetration test, what are some things that that people can do in order to prep?
Yeah. So, obviously, it helps to know, you know, what you have exposed, what web applications you have, what do they do. We would hope that you understand that. But it it sort of helps to know, like, what's worth getting tested, what's not worth getting tested, what actually has a realistic threat profile, and what's just a static page on the Internet.
And so so knowing what your applications do, knowing what's exposed, knowing what the roles inside those applications are capable of doing, knowing what your, you know, your your, role matrix looks like.
Maybe maybe it makes sense for you to have a superuser that can execute system commands within your web application. Maybe it doesn't, and when we find it, we're gonna get shell.
Yep. So, yeah, that's that's huge. And especially when it comes to scoping the pentests. Right?
They're expensive. Pentests are expensive.
You need to know what's worth getting tested and what's not, and that goes back to that threat profile.
And then you you know, it helps to know what the, like, the web stacks are using, what the the applications are made out of, and that's just helpful for us. You know, if you can give us a a framework and an idea of what's going on within your web app before we start testing, it's gonna make everything faster.
Nice.
So it sounds like in very similar to the other webinars we've done basically when it's like how do you get started? This common theme is essentially asset inventory.
And the flavor for web applications is basically know what apps you have, and that can mean, like, where the domains are, what IPs they're on, what subdomains you have, like, the file structure.
And then essentially, like, what are the dependencies for those apps? So that could basically mean, like, NGINX, Apache, like, the JavaScript on the front end. So, basically, that could be code or infrastructure.
And then, you had also mentioned a matrix. And in regards to that, basically, like, who should have access to what kind of a thing within your web application.
As you're thinking about that, is there another area also that's important specifically to web applications that is an area that that might help if somebody's trying to get ready for a penetration test.
Yeah. I guess, the thing that you're probably touching on is, like, how do, like, your end users actually use your application? Like, are they able to just browse to it on the web and log in? Do they need to be on a certain VPN?
Do they need to you know, should they be able to access everything? Should they be able to see the admin panels? Maybe they can't log in, but they can still see them. Should they, you know, should they be able to, within the application, see other users?
Should they not? Other tenants? Is it a SaaS application? Essentially, you should understand, like, what's actually being exposed to your end users and how they're going to interact with it.
Awesome. Exactly right. So we have asset inventory, and that falls into that category. And then also one other thing I think all that would also help is logging.
One of the things that's very, very specific to applications because, like, other infrastructure, other services that you're gonna be using where you would have, like, externals or internals, like they do the logging out of the box, but applications also specifically can be a very big place where a lot of companies maybe aren't logging. Whereas like in networks, it's like we have SIMs built around this stuff. We have all of this additional things. So knowing what logs are output from them, where are you actually keeping those logs?
How long are you keeping them? How are you normalizing the information? And then, like, basically, are you making alerts off of them? Because one of the areas when we do penetration tests specifically for web apps, that can kinda get lost in the shuffle when we have all this other detection and response built around basically something that is more mature in the industry, I feel like, which is network specifically.
So super good discussion about asset inventory and logging.
I think those are some really, really good points.
When we approach a penetration test, how can we how do we help people with their applications?
So we're we're there to sort of, help you define, like, your your concerns within your application and, help you understand, like, the types of attacks that are gonna be possible based off of those concerns. So we're gonna ask you questions about, like, what keeps you up at night, and then we're gonna try to identify attack vectors which either confirm or deny those those concerns.
And let's say we've identified attack factors with which confirm those concerns. We're gonna help you remediate those issues. We're gonna give you advice on how to fix them, and then we're gonna give you retesting, which is included in your pen test to confirm that you have indeed fixed those those vulnerabilities.
Nice. Yeah. And one of the things that I really like that you were talking about was, like, we help you define your skirt like, your security concerns. So we're gonna we're gonna look at what's going on and basically say, what keeps you up at night?
Because and and I know I've said this maybe two or three times now, but even more than externals or internals, this is gonna be even more tailor fit to you because maybe it's not as cut and dry because in externals and internals, you're more likely taking already implemented solutions and just tying them together, which can be fairly like, that can create problems in and of its own, but usually application penetration tests or even when you're setting up an application, it's gonna be much more fluid in regards to what you're building. So I thought that was that was a really good highlight and and basically talking about how that concern leads forward to basically demonstrating real world attack scenarios that you might have and how they could use it.
They being an attacker, obviously. So as as we're going forward just to get, like, a little more into into the specifics or implementation, I think now we're gonna transition to talking about, like, what the what what what an application penetration test is and what types of vulnerabilities we look for and kind of like more down in into, like, the actual implementation of when we're doing a pen test, what does that look like? So if you had to give me, like I know we talked about it before, but what type of customer is going to get the most out of an application penetration test?
So when I think about what an application pen test is and who's gonna benefit from it, is a customer that has, you you know, like, homegrown bespoke application.
This is not something where they say, implement a WordPress instance. We want them to test their static site host on a work WordPress instance. Like, no. The, you know, the that's an external. That's you know, WordPress is they're they're sort of proven. There's, you know, a playbook that someone can follow to attack a WordPress instance, and it's fairly easy to secure it because it's a proven technology. What we're looking for in an application layer is something that you or your developers have built on your own.
Maybe implementing libraries, maybe you haven't, you know, built everything, but is the bespoke application, where, let's say, there isn't a playbook. There isn't, you know, this this proven known methodology for attacking it.
Absolutely. And one or two things that I may be willing to highlight, but when you were talking that came to mind is, also that includes APIs as well. And so it's not just like you have to have a front end and you have to have that back end. Like, you can just like, we will also test APIs as well.
And one of the other things that stood out to me while you were talking was we just talked about it being homegrown. That doesn't necessarily mean that your developers are specifically in house. There are also customers that get a lot out of our penetration tests that maybe they personally didn't develop it, but they had a third party develop that application for them, And now they're using it and it's, it's bespoke to them. And so that kind of falls in line with what you were talking about with, with WordPress.
But I thought I'd highlight that. Cause I think that's one of the questions when I talk with customers specifically that it's like, well, like, would I want one? And if and that usually comes down to, like, did you or a third party develop it for you specifically? And if the answer to that question is yes, like chances are you're probably gonna get quite a bit out of application penetration testing if it's central to your business needs and business business flow.
As we as we go along, and you kinda touched on this when we were talking about war stories, but, do you have, like, general classes of vulnerabilities when, like, when we're talking about this that most that a lot of customers are interested and ask us about? So, like, what type of vulnerabilities, I guess, do we test for when we're doing these engagements?
Yeah. That that kinda goes back to a conversation we had a few minutes ago about, like, what keeps you up at night or like, another way to put it would be your objective.
Yeah.
And so if you are giving us an objective that's like, I'm really worried about what our SQL I'm really worried about someone as or, exploiting privileges that they're not supposed to have. You know? It's a a violation of least privilege. You know?
Whatever. We're gonna look for vulnerabilities that allow us to achieve your objective. And that could be as vague as I'm worried about people finding data that they shouldn't have access to, or as specific as, I'm really worried about user input validation. Whatever it is, work that helps us.
That doesn't mean that's the only thing we're gonna test for, though. We we often reference the OWASP web security testing guide, and specifically the OWASP guide from a few years ago. Because in recent years, it changed, and it's a little less useful. But the a lot of years ago, we we specifically looked for that.
And and it really depends on the technology in use. Right? Not not all vulnerabilities apply in all cases. Right? If it's a web API, we're probably not gonna look for a ton of cross site scripting type stuff. Right?
Yeah.
Absolutely. And something that I think is really nice about what you were talking about and something that stands out to me when I'm when I'm thinking about that is is if I'm a customer and I'm like, well, it all depends on, like, what I'm concerned about. I'm like, well, what are some kinds of concerns that we've heard? And you had touched on it can be as general as somebody being like, well, this is central to what we're doing.
We have PII in here. We're really worried that people are gonna get PII. We also have PCI customers who are like, this is central to how we process credit cards and we do use credit cards. So like, can you get credit cards even to specific types of data for like, hey, there is there are social security numbers on this kind of like, what can you do?
And as and as we move forward, even there can be situational ones where I was talking with a customer and they're like we have, like, people free trial, and we've had, like, real world attacks against us where they've used that in this type of way. Like, can you mimic that? Like, we wanna make sure that, hey, we actually shored that up but but, like, so when you're approaching it, these are our concerns. This is our history.
And so I think that that's also part of this conversation of, like, let's it's gonna be more tailored, but also it's gonna be more tailored fit to you as well based off of in the wild. Like, what have you seen? What are your concerns?
And I think that also should note that, like, when we're talking about these applications, usually like DoSing these applications or, or denying service for these applications is not something that we're going to do. So just keep that in mind. Like that is a concern when we start doing these tests of, okay, like a real world attacker is going to DOS this service or make it so that our customers can't use this service. And I think it's it's important to note that we're always going to try and make sure that we can give you realistic attack vectors, but not attack you to the point where it takes down your services or makes it so that your customers can't engage with you. So I think that that's something that while you were talking, I was like, Oh yeah. Like that's what I think of when you're when you're mentioning those points.
So when we're I think we already touched on kind of who gets the most out of these. So when we're talking about scopes for these applications, obviously, it can be kind of a question because it seems like apps tie into everything under the sun. So can you talk to me a little bit about how we define the scope when we're approaching these application tests?
Yeah. Sure. So the best way to define the scope for this test is first determine, you know, how large is your application.
You know, and what that might look like is within an API, say, how many calls, how many endpoints do you have within that API?
You know, what kind of functionality what kind of business logic is it performing within your and then, you know, going a step farther within the actual web application, know, how many roles do you have in there? And, again, like, what is the business logic? What is the functionality of this application?
How far reaching is that?
And let's say you have a thousand roles. You know, you can configure roles down to be very niche. Well, maybe we just look at, like, what's the lowest and what's the highest privilege. Okay.
Like, cool. What when we look at the highest privilege, how many endpoints, how many mechanisms does that does that have access to? When you look at the lowest privilege, how many mechanisms does that have access to? And we can sort of just start to, like, whittle it down and try to get, you know, the most efficient and best that we can.
Absolutely.
And going on with that, I liked how you were talking about what's the functionality, and basically, like, what are the roles and and what can we get out of those? And I think that also ties into with all of those roles, with all of those endpoints, with all or whatever you wanna call them. Because sometimes we'll be like, what's your endpoint? And they're like, we're not using an API.
And it's like, right. But like you have a custom path, like, and so there are unique requests. And so usually that's fairly agnostic to the technology they're using. So when we're talking about like unique requests to the application, it's gotta be supported by some kind of infrastructure.
Right. And so like when we're, when we're talking about web servers, if you have a more traditional environment, it's like, we're also going to be testing, like we're going to be scanning what available services you have because maybe there's something on that web server.
Or maybe it, like, it integrates with a mail server. And, and now we find that as we're reviewing it, there's a, there's like, it's not uncommon when people do that and we get access to, like, the super user that it's, like, here's the IP of the the mail server and now here's the credentials. It's, like, we're also interested in how does that function because it's gonna attack basically like if a if an attacker gets that, it's gonna attack how your business functions and it's gonna be in scope essentially.
That also goes without I I won't say without saying, but implied in that statement is basically, like, the databases that are to those. It'd be really hard to test a SQL injection if we also didn't include, like, the database server. And so I think the reason why it's important to basically say like the underlying infrastructure that supports those roles and those calls that you were talking about is also in scope, is is really important to note. And then can you talk to me a little bit about maybe what happens if somebody doesn't have a more traditional environment where it's like, here's our here's the IP for our web server we hosted ourselves, and maybe they're using cloud stuff. Can you talk to me about what might be in scope in regards to, like, cloud implementations for applications?
Sure.
So within, you know, the cloud infrastructure and I'm gonna sort of touch on what you touched on a second ago with, like, yeah. When we're doing applications, databases are in scope. Like, when we're doing cloud stuff, your back end cloud metadata will be in scope. So if we're testing an application hosted on AWS, say, and we get an SSRF, we're probably gonna go after those AWS keys hosted within the AWS metadata URL. And that's, you know, standard for all of the different AWS or cloud offerings. You know, there's a thousand of them. I'm not gonna go into each one, but if we're able to abuse some sort of cloud functionality through your application, we're probably going to do that as long as it doesn't deny access to your application for your actual users.
Right. And I I think that one thing that that also leads back to, like, a good example or use case to that would also be like the LFI vulnerability that we were talking about with that LFI vulnerability. Like that wasn't a traditional web server that someone was hosting. That was an EC two instance that somebody spun up and it was like, that's in scope, even though maybe I wouldn't have been able to get access to that in the same way.
And so I think that's really important to know. Another thing just to, like, call out and I know there's like a million in one services, but I think this is important where it's like, if you have basically like an integration with with those web services like s three buckets. Like, it's not uncommon when we go through these that it's like, oh, like that's that company's s three bucket. Like, it's fairly easy to look at that and be like, oh, that is theirs.
Where it's like now that because your application touches on that, like it's also gonna be in scope. And that is also true of like cross I guess that the kind of thing that I'm trying to say is cross domain or basically, like, cross sub domain interactions that if we start us out on a domain and we've started enumerating what's going on, sometimes that can bleed more with like cloud stuff where it's like, you have multiple applications because you have multiple subdomains associated with them. And so I guess I kind of like bled through through what we were talking about with cloud into like, hey, here's a subdomain and that your subdomains, but basically, like, if you have multiple micro apps that comprise basically like a bigger app, whether or not you're using subdomains to do that, or you're using like URLs to do that.
That's also something that we're going to be interested in looking at.
And, and that can mean like if you have admin directories where that's not uncommon, where it's like, it's the same app, but it's a different app. It's not really a different app. Right? So, anything else that you can think of that I missed in regards to scope that would be interesting to note where it's like, well, what is in scope when you do a pen test for applications?
Yeah. The thing that actually just came to my mind while you were talking a second ago is the same, very similar concept, which is, like, with within SaaS apps. Maybe it's like a multiple tenant application.
It's not unusual for a customer to provide us, like, a testing tenant, where we can then log in to that application.
And we're going to be looking for attacks which allow us to break that trust boundary and get access to another tenant's instance within that application.
Absolutely.
And then since we're since we're talking about how when you were talking, something else came to mind.
Also, if we find your source code because it's not uncommon to find source code, like, we're going to use the source code and review it. So in regards to that, man, that l f five vulnerability is getting a lot of love today, but, like, you could pull the source code off of the web server and actually review what's going on. So just keep in mind that that is something that we will also, test if if we find it. And and test is a generous word.
Right? Like, we're not gonna modify the source code. We're not gonna export your source code and give it to other people. That was one thing when I was talking with a customer, they were like, so like if we give you the source code, like, what are you doing with it?
And I was like, obviously, like, we're not gonna be sharing that with everybody. Like, it's just gonna stay between us and you kind of a thing, and we're gonna make sure that that it's we're gonna do it in as much of a secure way as possible.
And the thing that rings a bell is like in one of the other webinars we were talking about where it's like, hey, we shipped you a beacon for an internal penetration test. Like, we're not trying to degrade your security by doing these tests. We're trying to improve them, make them better.
Those kinds of things. One of the things I wanna loop around and talk about since it it sounds like we're kinda done with this idea of, like, what's in scope. And obviously, like, it's very, very hard to give an exhaustive, like, this is what will be in scope, but hopefully that gave people a feel for, like, basically, if it's used to help your application functions, chances are there's gonna be interest in testing it. And the last statement obviously is the penetration test is for you.
So if you have concerns where it's like, hey. Like, I don't want you to touch this or, hey. Based off of what keeps us up at night, like, I don't want you to test that security role by default. Like, if you can get access to it, fine.
But if you have concerns, like, please talk with us. The biggest thing that we don't wanna have happen is be, like, assume everything's, in scope and then don't get a concern about, like, hey, this is actually like fairly critical. So, like, please be gentle. Like, so, keep in mind, like, the tests are for our customers, obviously.
So what's in scope ultimately depends on what our customers are most interested to, but we try to keep it as open as possible for basically demonstrating real world attacks as much as, as possible.
One of the things that I'm interested in talking about is this idea, and I know I'm kind of like jumping around, but we had talked about denial of service attacks. And one of the things that comes to mind when we talk about that, that could be a question that comes up is like, do we do brute force attacks against these applications that we interact with?
So brute force is like a you know, that's a spectrum. So, yes, we will do brute force attacks where we do discovery. We do subdomain enumeration. We do, you know, URL discovery.
We, you know, maybe potentially look for, like, additional parameters, which aren't being maybe explicitly used by your web application but contain functionality.
And when we identify them, we can do additional stuff.
And we look for, you know, maybe we find a username enumeration vulnerability. We will brute force that to gain a list of valid usernames within the application.
We might do a credential stuffing attack where we attempt to log in using a list of usernames and a list of weak passwords to really test how good your password policy is in practice.
And that goes back to that twenty three and me breach that we talked about earlier. That's the exact way they got in. So there's value in us doing these attacks. There's value in us doing these lightweight, brute folding act. What we're not gonna do is, you know, set up an ICMP flood that basically denies service, of your application, denies other users access.
Say we find an XXE, we're not gonna do the the the whatever billion laugh attack.
Yeah. The billion laugh attack to just, you know, bring your application down. Sure.
So we're not gonna degrade the service, but we are going to use brute forcing in a way that either allows us to discover new vulnerabilities or exploit known vulnerabilities.
Right. And and I think that it's important to note that, like, when you're going after and testing things, there's always going to be a risk where it's, like, obviously, the concern is there because it's, like, there is a risk when we test apps or we test internals or we do externals of, like, denial of service. And and I think the reason that we mentioned those specifically is, like, we're gonna be as responsible as possible with these to make sure that we're not degrading or getting rid of basically the availability for systems that are important for your businesses. It's not, we, yeah, if it's not good for your business, it chance like, chances are, like, we don't wanna do it.
Like, so and then the last thing to say is keep in mind, like, if you have concerns, like, let us know, But we are gonna try and do brute forcing attacks, whether that's what you had mentioned with, like, usernames, like discovering them or even just, like, password attacks for brute forcing them or password sprays, or like sub domain enumeration or domain enumeration, or like identifying parameters or different like URI is associated with your URL. Like that will be a part of it because those are, that's how attackers will attack web applications to find them. But, obviously, if you have concerns, please let us know because if there's something we're not aware of and we do those, like, we don't wanna cause problems for the business.
And and if you have concerns, you know, on the other end of the spectrum, if you if you are looking at your threat profile and an attacker denying service to your application is a realistic threat, let us know. Be like, hey. We want you to take this thing down. We want you to perform denial of service attacks.
If you want us to, we can do it. Right? That's we haven't had customers ask us to do that. And, you know, if it if it makes sense for you, let us know.
We can we can try these things.
Absolutely. And while you're talking, that also comes back to this idea of, like, what attacks have you actually experienced where where there are services that people will abuse and it does cause a denial of service. Right? So that also comes back when you were said, like, their actual threat profile. That's what rung a bell where it's like either that could happen to you or is very likely to happen to you or it has like, we want to know about it. Right? So solid, solid suggestion, Garrett.
As we're going forward now that we've kind of talked about a little more of the implementation where, where, where so far we've talked about kind of, who is this, who is this for? How do we do these types of tests?
The kind of the, one of the last questions in my mind is how can, like when somebody is engaging with us on these types of tests, how can how can they get the most out of these penetration tests?
Yeah. So we kinda actually touched on this a little earlier, but, one of the things that is gonna aid us in providing value to you is, when you do give us access to your application, that you give us access using a few different accounts.
And, ideally, what that looks like is, you know, two accounts of your lowest role and two accounts of your highest role. And the reason we ask for two of each role is so that we can test those authentication and authorization barriers. Can user a access user b's data? Can user c access user a's data? Right? We we wanna check that, like, your lowest privilege can't do stuff that your highest privilege should be able to or that other users within the same privilege are able to.
Something that also came to mind is is while you were talking is the reason we one of the reasons we asked for this high privilege role and this low privilege role is it gives us an idea of the spectrum.
But also with the high privilege role, the assumption is that we can create users, for each subsequent type of role down the stack to your lowest privileged user. So keep in mind that if it that doesn't always work super well if that high privileged user can't can't create other subsequent users. So keep that in mind that that's one of the assumptions. So if that high privileged user can't create users, like, we're also interested in, hey, can you also give us, like, all of the roles that you're interested and concerned about?
And then the last thing that came to mind while you were talking about was also, like, multi tenant applications. We're usually multi tenant applications will follow the schema of low privileged customer tenant user, high privileged customer tenant user, super user. And so if we're testing, multi tenant applications, usually we're interested in the lowest and highest within a tenant, and then essentially your lowest and highest within whatever is managing those tenants.
If if that's in scope, which it should be just just as a heads up like it it probably should be. Because sometimes when tenancy application come into question, they're like, well, can you just test the tenant? And it's like, absolutely.
We can do what you want. You're gonna get the most out of it, though, because if somebody gets access to your tenant, who whatever is managing tenants, like, that's a huge problem.
So definitely wanna and understand that. Did I miss any you had mentioned roles, and then what do you have some other things that people can do in order to get the most out of these types of tests?
Yeah. So, other ways you could, get value out of your pen test with us, is just be ready to interact with, you know, be ready to answer questions we might have. We're coming into your web web application as, like, a blind third party. We've never used it before, and we have a fairly limited amount of time to get up to speed with it. You, on the other hand, are an expert, ideally. So, just be ready if we have questions about functionality, if we have questions about threat profile, if we're looking at something, it's like that looks like a violation of least privilege, but maybe you actually have a reason for this to exist.
It'd be great for us to just have that conversation with you. It's gonna make a better report. It's gonna make a better pen test.
Beyond that, if you come into your test with an objective, you know, that answer to what keeps you up at night, that's gonna give us, just a a good starting point of vulnerabilities to look for that are gonna provide value to you.
And then touching on things that we touched on just recently is, like, yeah, give it as many roles as possible, whether that's just, like, least and highest and just say, like, within highest, you can make new users with whatever roles you want. It's gonna just give us a wider attack surface and alongside attack surface, allowing the scope to be as open as possible.
Just just give us as much attack surface as we can, and we're gonna find as many vulnerabilities as we can for you.
Absolutely.
I think those are all really good. And just as a summation, because we've kind of just, like, word vomited everybody, like, this is how you can get the most out of it because we just like talking about it because, obviously, we like what we do. But, basically, be available to interact with, come with an objective, leave the scope open, leave the scope as open as possible, and then provide as many roles as as possible. And if that means lowest, highest, because the highest can make subsequent roles awesome.
That doesn't mean you have to provision all of them. But I think that gets us everything we need in regards to when we have applications, how can you get the most out of them? One of the next questions that I have for you is if I'm a customer, I'm like, okay. I wanna know kind of we talked about what the actual testing looks like, but from a customer perspective, what's kind of the general flow that I can expect for when I'm like, okay.
I would like to engage in an application penetration test with you guys.
Yeah. So if you've been following along for all these webinars and this is your third time through this, it's gonna sound it's gonna sound the exact same, but the process is very similar to our external and internal pen test. It is, you know, get the phone call going, call, you know, get get a conversation going with sales, get your your, pen test on the books. And then after that, you're going to have a call to define the scope.
And that's just, you know, what is the web application? What are the roles? What's the functionality?
Does it have an API? You know, all these things that we talked about earlier.
We're gonna ship you some questionnaires after that, which, you know, dive further into that conversation.
You'll fill out the questionnaires. They'll get them returned to us.
You'll get a dedicated point of contact from us, which is going to basically be the middleman between your pen testers and you as a as a customer.
We will do the pen test. We will write a report. We'll let you know, identify the vulnerabilities, give a write a report which contains steps to reproduce as well as severity, as well as remediation notes, so advice on how to remediate the issue.
We're We're not going to, like, give you a line by line code diff that says, here's what you're doing now, and here's what would fix it.
Because maybe we don't have source code. Maybe we weren't able to get it in the application. Maybe we're we're not, you know, devs. So maybe you have a better way of fixing it, though. We're gonna give you advice on how to best fix it. And then you will take the report. You'll fix your vulnerabilities, and you'll come back for retesting where we validate your your fixes.
Awesome. And I think that while you were talking, one of the things that I was thinking of and and that's the general process, and I don't think that what I have to say has to say anything about the general process, but this is, the one of the third webinars. So if you guys are interested in the other webinars that we've done, we'll provide links for you. You can chat in if you can't find them, you can call in if you can't find them. You can email in if you can't find them. But the other two webinars were on internal penetration tests, what those look like, external penetration tests, and what those look like. If If you've made it to this one, you probably already know it's about web application penetration testing.
But also something to keep in mind is just because those are the different types of service offerings doesn't mean you have to be pigeonholed into only doing one of those. We have customers who also include, different types where it's like, hey, I'm interested in an external, but I also would like you to spend some more dedicated time on this application penetration test, or maybe they include all three types, or maybe one of the next webinars that we're gonna be doing is also talking about mobile application penetration testing. So just because we're kind of enumerating them line by line and saying, like, here's this one, like, here's this one. You don't have to be pigeonholed into just one of the types of penetration tests that we do. You can include them, combine them, and and move them around.
I think that wraps up most of the things that we wanted to talk about in this webinar. Garrett, did I miss anything that you're like, man, I'm just dying to talk about this?
No.
I think it sounds good. Unless you wanna talk more about that LFI.
No, man. I think that LFI got so much love today, but that was and and I think that comes back to you can kinda tell that Garrett and I laugh about stuff like that, and it's not because, like, oh, they messed up, but it's like and we feel good when we can provide value and say this is this is based off of the objective that you have. This is how we can help you. And also, I I think that when we smile and talk about it, it's also enjoyable because, when people set us up to help them be successful by leaving the scope open or giving us as many roles as as possible, It's fun.
It's fun for us. It's fun for you. It helps you like, people will come to us to get pen tests because it's like I have an internal ask and maybe without a pen test, I can't have that. And so it definitely also helps us with whatever the motivation is for the pen test that you're getting for.
So when we when we're like, that LFI, it's not because it's like, oh, we got them. It's like, man, we provided value. That was really awesome. So no.
I think that LFI got enough love today.
Now we're gonna move into the question and answer section of the webinar.
Garrett, I think the way that we're gonna do this is I'll just ask you the question, you can answer the question. If I have something to add on, I will, but other than that, that's what we're gonna do. So the first question in our list is, what are the individual steps of an application pen test? And we kind of already talked about this, so you can just keep it very high level. You don't have to get into the weeds, but just what are some of the steps that make up an application penetration test?
Yeah. We'll give the, TLDR of the steps we just outlined, but, essentially, you know, get with sales, get your, contract, you know, paperwork signed, have a call to define the scope of your application, send you that questionnaire. You'll fill it out. That goes deeper into the scope, deeper into important infra information we need to do the test.
You'll get assigned a dedicated point of contact, who's your middle man between you and your pen tester.
We'll do the pen test. We'll find vulnerabilities. We'll write a report. We'll ship the report to you, and then you will fix the, the vulnerabilities that were identified, and we'll do retesting.
Awesome. And I think within those steps, like, if if I'm gonna give you, like, even some more sub steps for, like, the on the boot, like, on the ground, this is what this types of testing looks like, where it's like, okay, you've done the sales call, we've done the intake, and now we're doing the test. These are sub steps under there as well just to add on because that's actually absolutely what from a customer's per sec perspective perspective an application pen test is gonna look like. But along with that, like, if the general flow is basically identification and discover so like discovery where it's like subdomains and, like, you are URI's, what does it tie into that infrastructure question?
Then once we've done that identification, like, how can or that discovery, how can we identify vulnerabilities? Then we exploit them, and then we write the report, basically. So I I don't know if that is, like, even more details than than people wanted, but those are, like, the general steps. And they're not just like, boom.
We did discovery. We're done. It can be a cyclical process of discovery, identification, exploitation. And what we're basically trying to answer with all of those is how does what you find, like affect me based off of the concerns that I had.
So really, really good. Sorry if I got two and two of the weeds there, but those are also some additional steps in the pen test that that when it's like we're doing them, that's also what you can expect.
Next question would be, how much does an application penetration test cost?
Yeah. So this is kind of complex because it really depends on your environment, you know, the size of your application, the size of what you want us to do. But the average pen test, for for web apps is somewhere in the range of five thousand to fifteen thousand.
But, really, you should reach out, talk to one of our sales team members, and they'll get you a personalized price that fits for your budget and your needs.
I think it's funny you get stuck with that question because that is a question that people ask quite a bit, so it doesn't matter really what the pen does job. But thanks for thanks for always answering that question for us, Garrett. I appreciate it. The next question is how quickly can we get someone to perform a penetration test?
It's another one of those questions that we get all the time. We hear it all the time. So, again, if this is your third time watching one of these webinars, you've probably heard this answer before, but we can usually get, a call scheduled within, you know, a week to ten days after your contracts are signed.
Nice. The next question and that's exactly right. And so I'm just gonna you did it so perfectly that I'm just gonna move on.
The next question is how should I coordinate or who should I coordinate with internally to make sure it goes smoothly?
Yeah. So you as, you know, the point of contact for your organization, should be coordinating with devs or at least, like, you know, lead devs or product owners.
But the the person within your organization that understands your application the most, where you can go with a question, be like, hey. Does this does this role within the application make sense? Does is it a violation of lease privilege? Does this thing that they're seeing make sense?
So whether that's you or a product owner or whoever, that'd be a great person to coordinate with.
Yeah. And just as, like, a a statement that's a little more agnostic, because again, this is a question that comes up fairly frequently, but there's basically, like, three roles, usually role types that we're interested in, and maybe that looks a little different based off of what your your business looks like. Maybe somebody's wearing more than one hat, but basically anybody who deals with your security.
So that would be anybody on your security team. That could be a CISO. That could be just like a information security officer. So basically anybody from the security scene, anybody from the business scene, that could mean basically like, hey.
We have this need from a business perspective to get this penetration test. That could also be you had mentioned, like, product owners or program managers, anybody who that could engage with. So the business side, and then also you had mentioned a technical resource in this case being like the developers of the actual application. It could also be anybody who's your cloud architects, anybody like that.
So, the more the merrier bring them all. But usually when people are like, what do you think on the calls that we have the most success with for getting people what they need the most, basically, your security business and your technical resources are the people that we're most interested in talking with.
The next question that we have in here is how can an application pen test impact my environment?
Yeah. We touched on this, earlier, but, essentially, we're not trying to degrade your environment. And that's one, we're not trying to degrade your security, but we're also not trying to degrade the availability of your environment. So, ideally, the pentest won't impact your environment.
What I could see happening is, you know, if we're targeting say we find a stored cross site scripting and we are just, you know, proving the impact of the vulnerability, you might see users they were just, you know, they were in the identification phase, and we're literally just injecting, like, a JavaScript, like, alert box. So a user might load a page and see an alert box. We would hope that doesn't happen, but they might see it.
You know, users might see weird stuff within the application as we're in the identification phase, but, really, once we move into the exploitation, users should not see any impact. They should be able to use the application as intended.
We're not gonna try to lock people out of their accounts. We're not gonna try and take the application down. We're not gonna change other people's passwords. That's where it goes with locking them out of their accounts, anything like that.
I think, another question that just came in also was basically, like, if I have a development environment, are you guys willing to test the development environment? I think that is a super good question. And the answer, they actually get that question a lot when we do these scoping calls and when people are like, oh, like, can we do that? And the answer is yes. Like if you're worried about impact to your environment and you're like, I feel more comfortable in my staging or dev environment. Absolutely. We can do that.
The things that we generally ask in regards to that is, that that staging or dev environment is as reflective of what is actually happening in your prod environment as possible. So that means basically, like, it's populated with data that we can effectively use. It doesn't have like, it's fine if it's anonymized, but basically, like, data that that we can see how the data flows through your app. And then also, like, those two roles become very important because, obviously, like, we're not gonna be able to like, if your employees use the app and it's in the dev environment, we're not gonna be able to attack real employees with, like, cross site scripting or different things like that.
So those two accounts become very important to emulate those types of attacks or simulate those types of attacks. So, absolutely, we can do that. And since I'm have on a roll, the last thing that I am gonna mention when we're talking about impact environment is some customers are like, oh, I have a very big, like, concern about you bogging this down during normal business hours. Can you do testing after hours?
The answer is absolutely we can do testing after hours.
There is an additional cost associated with that because most of our testers will work normal normal business hours. But if it's important enough and you're interested in that, that's something we can also talk about and that might affect the pie, the price point, but just know that it can happen. We can do that. And we are more than happy to try and and make sure that you guys get the best test that you can. So the million dollar question, and this one specifically, again, comes up systematically, but it's what qualifications do security metrics penetration testers have? And for this one specifically, I'm gonna, since it's a question we've asked a few times, I'm just gonna curb it a little and say what what qualifications do security minute security metrics penetration testers have that are specific to application penetration testing.
Yeah. That makes sense. And, you know, we have answered this question before, and I think we always try to keep it relevant for what we're talking about. So keeping it relevant for application layers.
You know, we have we hold certifications from various governing bodies, whether that's, you know, the OSCP from offensive security, sort of touches on web applications. But we also have, testers with the OSWE, which is a specific web application, certification.
We have a large I would say the majority of the department holds the Burp suite certified practitioner.
I think I got that right.
And that is becoming the standard in, like, web application pen testing certifications.
It follows the the PortSwigger Academy, which is, if people are saying, like, what should I do to learn how to test web applications? I say, go do the Pawsinger Academy. It's the gold standard. It's amazing. And so that certification basically validates that you have done the educational material within there.
We hold, what, CISSP is sort of web application y.
Sure. In regards to data and data owners, they could see how that definitely would apply. Also, while you're talking what was that?
What am I missing?
Oh, I was just thinking, so that covers, like, certification kind of side of the house, and but we also have testers that went to school for programming, which is a big deal for that. And we've all we also have testers like yourself who come from backgrounds where it's actually, like, we're doing full stack stuff, making apps ourselves, doing those kinds of things. So, it's it's I guess you could break that into certifications, but also education, like more traditional education. And then the last one is actual like practical work experience where people have done that and have transitioned over.
So, I think all of those are there. And now I'm gonna pass it back to you. Did I miss anything in regards to, like, me saying that? Did you think of anything else?
No. But that's a great point that it's not all about, you know, certifications that we have people who went to school for this. We have people with, you know, degrees, and we have people with real world experience. And, I guess, on top of that, we also have people who are, you know, prominent in the bug bounty scene. And it's they don't have certifications, but they have, you know, a a wealth of bug bounty reports that you can look at and sort of, that's a very competitive scene, so it it validates that they they know what they're doing.
Sure. Absolutely. That's a really good addition.
The next question that we have is what kind of value can I get from performing an application penetration test?
Yeah. So I mean, going back to that question, like, what keeps you up at night, Hopefully, you won't be kept up at night. Hopefully, you will have found the vulnerabilities and remediated them.
But beyond that, you know, we're just gonna identify, you know, vulnerabilities that either fit your threat profile or aid you in outline in your threat profile. Maybe you'll even know. Maybe you just know you have a web web application, but you don't know what a bad a bad actor could do with it.
We're gonna help you in defining that. We're gonna help you in finding vulnerabilities and remediating them, and we're gonna just hopefully make you, sleep a little better at night.
Absolutely.
I think that along with that way you're talking, one thing that I also think of that's fairly common is people will use penetration tests to try and help them with internal asks that they have. And what I mean by that is maybe there's something that they are aware of that it's like, hey. I I know this is a problem. I know that this is a thing I'm talking about internally, and I just can't get the buy in that I need.
When we're talking about, like, what type of value can you get? And this comes back to like, it really just depends on what you're looking for. And if, if that's important to you, like there is a specific reason why you're coming to us that you're hoping to use this report for, like, keep that in mind, make that a statement, even if it's, not even if the question isn't like what keeps me up at night, but like it's more of a business need for, like, I have this internal ask. I need this from an external source to help give me more leverage. Like, we're here to help you with whatever you're using that report for. So obviously that question also falls on us in regards to, like, the integrity of the testing that we're doing, kind of how well we're doing on that testing.
And that doesn't just mean like, oh, we found something. Like, some of my begrudgingly favorite tests are where I go, you did such a good job that, like, I don't feel like I could I could, give you anything other than keep doing what you're doing and highlight some really good positives, which is also that comes back to what are you using this test for? Right? Like how's it helping you sleep at night is what I think happening actually happening?
And then you, you also go in along with that. One of the things in regards to like, what value can you get from also ties back into this question of qualifications of your testers. Right? So, I don't know if that was something you were kinda like, hey, like, loop back to that.
But, a lot of part of the onus of what do you get out of it? What value can you get out of it also depends on what you're looking for and whether or not you communicate that to us. So please make sure that we we wanna hear from you. We wanna know what you're coming to us with and your perspective and what you're hoping for, because that obviously helps us give you a better test, more tailor fit test, more practical and implementable test.
So I think that's all the questions that we have time for today. Thank you everybody for tuning in.
Again, this is record this is going to be recorded and sent out, so if you're interested, please reach out. If we if you had a question that we didn't get to, someone will reach out to you, again, or if you didn't get a chance to while you were listening to this, put in a question into the website, feel free to please email us or call us. Again, always happy to hear from you, helps us create better content, helps us give you better penetration tests. We wanna hear from you.
I'm James Fournsworth. This is Garrett Adler as well. We're signing off. Thanks for tuning in.
.svg)
