BSidesGVL 2020 - Kevin Johnson - "Removing the Cobwebs: Upgrading Our Web App Testing"

everybody we could just get ready to get started back up with a couple minutes see uh Kevin's in there you go there Kevin yes I am haha thanks for coming and meet you in person this year but yes that's gonna have to wait for one day God nobody wants to meet me in person I think it used to see you back in the day like in the hallways of Sands you know going between class it's been a while yeah yeah back in the day and they say I was just having a conversation with somebody the other day and realize that it's been six years since I taught taught four sentence as it is a lot can

happen in six years ha yes well a lot has happened this month it has how secure ideas been I work I mean not gonna would pray our butts off we've been doing pretty well bill 23 people now awesome and our goal is to end the pandemic with as many people as we started if not more and so far we are Jason Denise and I and the the three owners of the company just been trying to focus on making sure of but he's okay you know that's one of the problems with the distributed company is it's nice to say okay everybody's working from home and everybody's work was in their place but at the same time

there's way less visibility into how people are doing and I don't mean how well they're working you know but how are you functioning how are you and so Jason is is really been driving effort at trying to figure out making sure that's good you know I mean so that's that's good to hear yeah excuse me I'm sorry I don't mean to yawn in data's it is it is Jason and I did a three day class over the well the last three days and I would say that on a regular basis one of us was causing the other one - yon felis Thank You Reza yeah what was the class on that you guys said I it was

application security it was just our three-day peace class yeah we had a good turnout 77 students yeah yeah I'll say that the Jaison and Mick have been doing a lot of work on samurai at getting we have the five-o release we're working on yeah trying to get it so it runs in Amazon workspaces yeah and it's it made running the class very interesting virtualizes are always odd rape sure but yeah it's pretty cool oh very cool sounds like a might be good timing to get all the kinks ironed out and then come back for peace sighs twenty twenty-one to talk about cool [Laughter] yeah I was actually really looking forward to I've never been to Greenville

before right are you yeah I've been Charlotte right or so I'm a horrible person and you all will laugh at me for this but I always say that we're based in Charlotte South Carolina and I'm aware that that isn't a real thing though whooping stout of rock you know and okay same difference so we've got yeah exactly right uh but um so we've got people in Charlotte we've got people south of Charlotte and they they've been up to I mean I they've been in in you know Greenville a number of times I've just never made it and yes Jason just corrects me the way I said it implied that it's not yet working and workspaces

it works great in workspaces would what I'm talking about this there's more stuff we want to do with it it's not yet a full release so this is the problems having Jason in the discord Channel is right so I need somebody to keep us honest so yeah well awesome well thanks again for coming and talking I appreciate I reset the genie and I really appreciate for her jumping in and you'd come in long and bring in Jason Shawn along for the ride so I knew I saw a lot of terrific feedback from Jason's talk so I was really excited definitely yeah I bet I would definitely want go back and watch the recording once we get that edited and out there or

so but ya know I really appreciate you coming and doing this and sharing with the group so I will get in the way out of the way okay make you assuming I should share my screen and you should have access them to share cool thank you all right thanks Evan

okay so I'm hoping that you guys can see the right screen this is the problem with PowerPoint is it throws itself when you're sharing out to a screen like this and I can't see the discord server so if you're talking to me there I can't see it but mom did remove when the goblins yep good perfect so we're going to talk about removing the cobwebs and this is actually Jaison and Mick and and Eric and Nathan all the the consultants of security and I have been discussing this quite a bit there is the historic traditional web pentesting and and what we've realized is that most most of our testing nowadays really focuses especially when we're talking about new applications

mobile applications embedded applications cloud-based applications that there are some things about these applications that you need to start focusing on and many pen testers aren't then let's forget pen testers for a second many developers and QA people are not considering these parts and so I wanted to talk a little bit about that today um a little quickly I'm Kevin I'm not gonna spend a lot of time introducing myself I'm a nerd I've been a nerd for a very long time I am one of the founders of secure ideas we are a consulting firm based in Jacksonville Florida but we're spread out we have staff up in just south of Charlotte Oklahoma Texas and we're 10 years old

this year which is mind-boggling to me that we've been around this long I'm also anions faculty member a course author instructor matter of fact Jason Gilliland and I just wrapped up our three-day p's course around application security course this week and we're in the middle of one of our sea ice cream internship runs I'm also an open source fanatic I love building and managing and maintaining open source software it's one of those things that I recommend everybody not to do it always sounds like a great idea ok I'm gonna build this thing and I'm gonna publish it and world will love me that's not true the world doesn't love me and the world doesn't love me and it's a lot of work

but it's very very worth it the reason I don't recommend doing it is because it's a lot of work and so many people stand up open source projects and then they die um so think about it if you're gonna do it my recommendation is start by contributing to another project I will tell you that samurai WTF the web training framework is currently in its five-o development branch and we are absolutely looking for contributors we would love more people to help us build it um and then another thing I'm a member of the 501st I am a Star Wars nerd I was actually planning on being at my office today to do this and I have a sand trooper

costume behind me but I'm mental so you don't get to see us and rubric Astri um but if you're ever in Jacksonville swing by the office we costumes all over the place so what is about traditional pentesting and I want to be really clear I'm talking about application pen testing here right um we see a lot of things and we see a lot of people doing different things right um so we have a wide gamut and it all started they didn't all start but the idea of pen testing applications if you want to think about applications in general that they started with purple right and CGI scripts and server side includes and dynamic code running inside

of an Apache server on a Linux box and I'm old and I remember building applications that way and and they were always fun right there's they were really fun to attack um and and then when we start to think about security and we have to consider how the application is protected and how we test it and everything else there's a wide gamut of what people call pen testing everything from simply running a nested scan against the web server which let's be very clear I am NOT calling that pen testing hence the quotes in the title all the way up to taking something like burp suite or zap and manually walking through every single application function and fuzzing the inputs and

shoving payloads in there and determining what's going on um what I want people to do is to be closer to that side than the next assignment right because if you're just running this against an application server and I'm using this as the example there are lots of vulnerability scanners out there um Nessus just happens to be probably the most commonly known one and commonly used to be blunt you're not really doing appendage and for many developers and QA people and security consultants they don't have the time to do a comprehensive test manually using burp or is that now we can have the argument that if they don't have time then they really shouldn't be doing it I would agree with that but we

also need to make sure that we're building it out correctly so the problem I see and this is a saying I've heard for years right and that's if you have a hammer everything that's in it and I think that that's what we're seeing very often with pen tests and at security is of quite often we get copies of previous pen tests done whether it's because of the expert witness work we do or whether it's because of a consultant but when we go in as a consultant the company provides the last pen test for us to review for some reason or if it's because it's part of our Sastre program where we're providing advisory services to

developers and QA people and what we see a lot of times is that many pen testers and and not making fun of anybody here I'm not calling anybody out here but what we see is that many pen testers have a hammer and they bang on the website and they write up a report and as you know if you've ever tested a web application you're gonna find vulnerabilities right in most applications there are problems low-hanging fruit that any zebra can find I don't know why zebras my example of a dumb animal but um let's go with it right um they bang on the website and oh hey you've got server information I love that yeah your server header is showing

okay did you exploit something because that no did you explain anything else no we also see lots of false positives where they write up a report and a finding and it's not really a finding and again I think that's because they have a hammer and they do the traditional this is what I know how to do and I'm not poke here or for a single cord here and over a single cord over there open up not database there's no sequel injection ok did you try double quotes did you try act record did you try all that did you try other inputs no I didn't know what those well ok that's a problem and I think that the reason we see so

much of this is because the most people don't understand what they're attacking and and I want to be very clear I'm including myself in that because every single day I learned of something else I didn't know if you ever want to have a good time laughing at me right um talk to Mick or Jaison about website development and the problems I've run into right um talk about looking at an application and then taking what I'm doing and handing it to another consultant and saying okay this is where I've gotten to you this is what I've seen and it's like ah but did you not know about this function right we'll talk about JW T's in a bit and when I

first heard of seeing Joe vo w T's it was like oh that's on interesting and what does that mean and and then I sat down with Jason and Jason talking what they meant and that understanding helps us grasp what's important to test and understanding it's not just technology right the understanding also is what about the application what about the business what about the organization behind it where it's deployed right um we see very often where something that is critical to fix in this industry is not in this industry over here and vice versa right so figured isn't important fix is absolutely important to fix elsewhere right so we have to understand how it's made I love that show it's such a

don't show but I love the show right and we have to understand every bit of what it's made and I don't think that you have to be a developer okay this is a debate I see everyone smile on Twitter or Facebook or wherever we're arguing the latest rant um you know to be a good application pen tester you have to be a developer that's bogus um I find it to be gatekeeping does being a developer help maybe I know great developers that are awesome pen testers I also know horrible developers for great pen testers and I know other pen testers who have never developed a single line code in their life and what I've found is

that when we talk about great pen testers when we talk about great security assessments the commonality is the knowledge and drive to understand how that system working before in you test it before you start throwing payloads before you start trying to exploit it because well and I've said this many many times when I've been on stage or sitting on a chair like today um as a security industry we really focus on the cool hacks right we focus on me the exploitation oh my gosh I stole three million credit card numbers I dumped the database and got a million people's Social Security number with permission right um that's what we focus on but the reality is when we look at a

penetration test when we look at the methodology that we follow exploitation which is the fourth step which it's a cycle so it's also the eighth step the twelfth step the sixteenth step we can do this math forever it's actually the smallest part of the test it is the least amount of time that we spend in the window that we're testing and and let's just say it's a five day test right we don't spend three days exploiting stuff we spend small periods of time exploit it and all that exploitation is doing is validating that the finding is real in giving us a better understanding of what the vulnerability means to that organization right yeah if I can get access to

back-end data stores what's in there what data is there is that they do important can I dump authentication credentials if I can what can I do with them are they in plain text are they easily crackable are they stored well right that's what exploitations for and party stories right what we spend most of our time on is actually mapping little reconnaissance which I can't spell looking out and seeing without their mapping is understanding how the app works then we move to discovery which is where we're poking and prodding and determining what vulnerabilities exist in this application and then like I said exploitation so when we talk about this methodology what are we looking for well we have a good start

with things like the last top 10 which by the way side note the off top 10 was postponed from being released this year to being released next year and one of the reasons it was postponed is they don't have data and I would like every ester out there every consulting firm every internal tester to go out to the OAuth github repo for the top 10 list grab the sample files to submit data and submit data for the last three years the more data we get out there the more valid this list is going to be next year when it's released um we've put up on the screen the 2015 version in the 2017 version mainly because and I'm not gonna

rant about it now because I've ranted about it lots of times I think there were mistakes made because of a lack of data in 2017 I also think that many assessments that are regulatory or compliance related refer to the 2015 version still so as pen testers wow we don't want to be compliance check boxers right we do have to take into account what the organization we're testing has to be compliant with so if that organization has to be compliant with something that is going to refer to the 2013 version which by the way I'm putting it my monitor that has the slides on it case you're wondering why you can see keep pointing because I'm an idiot and

think you can see my monitor um the you have to understand that that's the list they're going after and not that that should change what your test because the reality is nobody should be testing but against the top ten Oh ask themselves even say that it is not a test guidance it is a report saying hey here are the most common vulnerabilities we found in the data set we have that's it we miss you at all time right there are three big categories that you need to think about earth controls and we abbreviate that because it's authentication and authorization right how do you handle it how does it work we want to look at input and manipulation

we want to think about our input and how it's used by the application and how it comes back down to the client whether that's the browser or a mobile app with an embedded app system whatever the Occulus I just got an oculus it's fine um and then logic control and with these three categories yeah I want to be very clear this is not comprehensive this is not everything you should be looking for right um but this is a good start that if you're a developer you're a QA person if you're a condenser which let's be fun pen testers glorified QA right um we just do something different when we find a bug if you look for these three

categories if you start to evaluate things here you're gonna do that and how do you do that in my opinion it's through mapping right and exploring and understanding and detecting problems while you build a map and the Sherlock Holmes references um in the Discworld map as you use the application please note I didn't say abuse I said use and as you use the application you should be evaluating how it does things how do the pieces fit together how do the inputs get sent up to the server and come back and are used and consumed are they consumed on the server side are they concerned soon on the client side matter of fact in modern applications

progressive web apps single page apps so much of the business logic is running inside the client and so many of those tests I talked about that we see that we look at that we have says don't do anything there they don't evaluate anything they don't evaluate anything the local storage they don't evaluate anything on the client side can you attack it can you change the business logic jumping back to those categories right so there's three things we want to think about well mapping that we're going to talk about today obviously there's a lots of things we can talk about while we're mapping but today we're going to talk a little bit about authentication authorization ap is

in client-side features okay so let's start with authentication authentication authorization in my mind is a fundamental part of every application um and I think in my mind I'm correct Rooker's built we already if your application doesn't do this correctly really doesn't matter what other security controls you have in place really doesn't matter the cool laugh the cool input validation the awesome monitoring and logging that you're doing in the pack I know nobody calls moderate walkie Boston none of that matters because the foundation of security for your application failed because you messed up authentication or authorization what about right and we see lots of things here that people don't consider right and we talk about embedded by embedded I'm not talking I

owe t or embedded systems what I mean here is the authentication and authorization is solely done within the application or the API okay they're not using single sign-on or something like that the app maintains its own authentication authorization system we also see a lot of problems with single sign-on systems and and whether that's a single sign-on system that you've purchased or one that you've built yourself and let's be blunt if you're building your own you're probably going to screw it up right um is it cuz you're an idiot no it's because your focus is probably not on the single sign-on systems unless that's why you're building it is because you want to become the single sign-on vendor your

focus is on the application the focus is on business purpose that the focus is on the business data and this single sign-on system that you build um it's just a one okay the number of times we see people that will do single sign-on systems and and here's a good example of one single sign-on system you come to the application if you're not authenticated it redirects you to the single sign-on system right um the single sign-on system authenticates you asks you for who you are does all this cool stuff and in the test I'm thinking of the single sign-on was really well implemented there on that sir on that part of the application on that functionality it authenticated the user

and then or did it do it handed the application back basically no pun intended basic offend occasion to events that were then passed to the original application right so you did this really awesome really cool single sign-on system and then you handed it to the browser in the weakest form of authentication the world has ever seen and might be an exaggeration right that's a problem we also see multi-tenant systems and handling of tenancy across these applications and then of course badly implemented multi-factor authentication and again in most cases the badly implemented multi-factor is either roll-your-own or there are bypasses for it um we have a we have a customer that we test on a yearly basis and they have a

multi-factor authentication system and also have a hard-coded token that you can pass as one of the headers and if that token exists the multi-factor authentication just isn't checked right so you can put any number in the MFA field possible and the reason they do it and don't get me wrong I get it I understand why they do it in their development environments in their QA departments they want to be able to load tests they want to do performance testing and so what they did was they built this mechanism so that their load testing scripts and their development scripts didn't have to worry about multi-factor authentication the problem is they promoted that feature I hope you're the italics in quotes to

production so if you know that token and let's be clear I'm not going to say what it is but it's not hard to guess you shove that into the production app multi packers turned off basically you still have to put a number in the field but that's it these are the types of things we see is that they roll our weaknesses so let's talk about some of the issues first let's start with embedded remember all the application authentication authorization is handled inside the application solely in the application um the biggest thing is a pen tester that you should be doing is determining how the application maintains its state right one of the things it's poor examples simple

examples not monitored at all what's the session tickets right remove them go to the app as your mapping login so authenticate to the system you start using the system now delete the session token that you were handed right um does the application log you out does the application continue to work does the application give you a new session token so if it continues to work then the session ID has nothing to do with authentication authorization okay or nothing critical to do with authentication authorization um look for something else is there a cookie being passed out is there client-side code we see more and more applications using html5 local storage to put state data in there okay um another behavior we see as

a matter of fact not this Friday but the last Friday Jason was testing an app um and he found that if you remove the session token and you made the request the application handed you a new session today but the application also accepted whatever information you said you were okay and so give you a new session token and you could hijack another account right um that wasn't the Friday app that was different but let's go we see lots of applications that the developers have tried to solve the authentication authorization problem and it's all with how they maintain state so that's the first thing figure out how the application maintain state and if you can figure out how they maintain

state then you can start to abuse that if it's something in local storage okay well then I'm gonna look around for a cross-site scripting flaw so that I can attack another user to pull their state right um if they're using local storage are they clearing local storage out so are they killing the session correctly when it's done is something that you want to look at right um can you manipulate it can you change it multi-tenancy is another big one that we see more and more applications working this way whether they are an application that your organization pays for which gets cloud stuff in a second right or whether it's an application you're providing and you have multi-tenancy

within it right multi-tenancy just means we have multiple tenants or typically organizations that use the application and the application is presenting itself to them their authentication authorization as just within that tenant okay um dumb example quickbooks online i run a company that might be a surprise did you miss the beginning but I run a company and we use QuickBooks right we we use it because our accountants asked us to write and so we use QuickBooks Online and we go in there and we have I'm gonna set up the accounts so I'm the primary user and this is probably way more information than you need and I'm probably giving out information I shouldn't but all up don't care I'm in

the primary user so I manage the other users in the system so I'm an administrator but I'm not an administrator of QuickBooks Online I'm an administrator of the secure ideas tenant in QuickBooks Online right and you may run this company right um Tim tomes the keynote from today he owns his own company she may use QuickBooks as well I had no idea but if he does he's probably the administrator of timett ones' of QuickBooks organization and he manages those users he can't manage my users I can't manage his even though from a description perspective we have the same authorization rights we have the same abilities inside the application we just have them within our tenant okay so as

pen testers one of the things that we want to be able to do obviously we would love to be able to escalate our privileges to maintain and administer QuickBooks Online right if we were attacking them but I'd also like to be able to jump organizations what happens if Tim can somehow figure out a way to manage the users in the secure ideas organization right so we want to look for things like that we want to look for ow the tenancy system maintains organizational state how does it know who I am how does it know what organization I'm part of and sometimes that's simply the user names previous preface I can't even say words today sometimes it's a nother token it's

another part of what's passed down to the client and passed back up to the server okay and we have to look for that sometimes it's simple it's called an org ID or something like that other times it's pretty complex right and we actually control what organization were in based on the URL we hit or where we're coming from okay and we want to look for things like this when we talk about cloud systems I love cloud systems I really do when I first started and people said oh man the cloud it's gonna be awesome I looked at it's in this system um and we've all seen the sticker that's right the cloud is just somebody else's

computer um that was my attitude for a very long time and I will tell you that if that is still your attitude as a tester as a penetration tester as a security consultant then you aren't going to do as good a job as you should because the cloud is actually so much more that is a valid statement the cloud is just somebody else's computer absolutely the LMS that securities runs runs on somebody else's computers they manage the underlying system they manage the servers and the hardware and the software that it's running on right but yes just the start the ability to scale the ability to spin stuff up the functionality and other feature sets that are available to you to control and

manage and administer your cloud systems is fascinating it's also quite often misused in ways that we can attack the simplest one okay we know it right leaked credentials and tokens how many times have you looked at a github repo and scene where somebody committed there eight of us tokens I thought that for you but for me it's a lot right uh people post comments one of my favorite things to do is to go out and read the forum's where organizations are asking for support in their cloud-based systems and what I do is I limited it to my target and what we find is that they ask questions and as they're asking questions they post credentials they

post access tokens they give out the information we find out during research in recon right but the other thing that we find is that if we look at the functionality of the cloud-based systems work and remember that if you're on pen testing an app that's running in Azure I'm allowed to pen test that app as long as I have permission right I'm not allowed to attack Microsoft's interfaces I'm not allowed to attack the infrastructure running that app right unless of course Microsoft was who hired but that doesn't mean we should ignore that infrastructure that we should ignore how that system works and functions and does things okay um as such one of the things that you should

do is to go out and look at things like hey now are as three buckets managed right because we all know the problem with s3 buckets being out there public and having but what about s3 buckets that are tied the applications what about we see this all the time in what I will tell you that on a daily basis some jackhole on the Internet is vuln secure ideas couple and they're trying to do I giggle every time I see logs where somebody is trying to do sequel injection against secure ideas calm now don't get me wrong I'm not standing here saying hahahaha we're a hundred percent security you can't do anything no that's not what I'm saying but I am saying that

the security is calm site is a static website it's hosted in s3 bucket fronted by cloud fund right it is static content and so if you didn't realize that you could do that with an s3 bucket fronted by cloud front and you see the fact that there are parameters passed from page to page and you think oh I can attack that ok then you haven't understand it you don't have an understanding of the underlying infrastructure that is running and we don't hide the fact that that's how we manage our system right we matter of fact as far as I remember we have a blog post when we talked about how we set it up and so we release that

information we believe very firmly in sharing and and being opened but if you don't understand the underlying system if you didn't understand what an s3 bucket means if you don't understand what that impacts your testing of our Sun 8 well then you're going to spend a lot of time wasting time and I don't know about you but in the 10 years I've been running security is I've never had somebody give me an unlimited budget and I have to do things within the time frame 1/2 so research the systems look at things like I'll tell you right now we use SNS so when you go to our website and you fill in a form it is submitted

to a lambda and that Wanda is dynamic brain and that lambda hands that message or doin SS and that comes to us right is that attackable maybe right I'm not granting permission for everybody to go try not against my sight but we've tried we've locked down the things as well as we can we've tried to take into account these things and when you test our sight if you were the company we hired to test it we would hope that you would know how long does work and know know how the internet system works so that you would know what was okay to pass into right go from there right oh all of this stuff becomes very important with as you look

at the system's api's API API is api's I am old I still remember the first API I built it was a soap based web service and it was back ended by a mainframe a lot of XML a lot of metaphor um you still find soap based API is I'm not going to get into so Casey yeah it's here right but what you have to see is that very much of your applications are back ended by micro services or restful api um and yes I know a wrestler guy can be a micro service and a micro service could be something other than a restful api and what we need to do is as we look at the application we need to evaluate

what is happening again during mapping and the screenshots here some of them might be well all of them might be difficult to read um I don't know how big they appear on your monitor on my monitor their clears anything but if you can see them what you'll see is all of these come from the wasp juice shop um I actually think that juice shop is a great example of a modern application that's a vulnerable to lots of stuff that you can play and as you look at the application what you should see is that there are calls to API there's actually a number of API it's built in a Jewish out there's an administration one

there's a front-end one for users there's one for products um all of this is available to you now the nice thing about playing around something like juice shop is that the solutions are known right unlike what we do a pen test we don't know what the vulnerabilities are that we're gonna find here with juice shop we do so we can go and focus on them and so what we say to people it is go out there and map what the API is are and I'll give you a good example with with juice shop what you'll see is that from the user interface there are paths that you go to routes that you can load and then from the client-side code it

makes calls out to these API now if all you're doing is looking at burb all you see are the requests and you really don't understand where they're coming from and if all you're doing is looking at the browser and not evaluating what's happening under the covers all you see are the URLs that are presented to you now if you're a real pen tester you wouldn't do either of those two things we still see it all the time and so what you need to do is you need to map those you need to understand what the different functions are and the developers in the room even if you know what the API endpoints are map them and

here's why very often we find things that have been deployed that the developer doesn't realize is part of that API whether it's because they used a framework that added that or whether it's because they inherited it from somebody else or another dog put it in and this developer didn't realize it but very often when we finish an API test and we do lots of them we go back to the developers in like hey here's what we found and they're like oh that's not part of our app no no it is it's right here right um it's on your so it's within your application your application actually calls it um I wonder where that came from don't know I can't tell you

that I don't know where your code came from but I do know I found this vulnerability I did find this problem so map them and then understand what the inputs are so like for example one of the mistakes we see from people all the time is restful api is use the HTTP methods to handle data back and forth for example you'll see a get to to get data back you'll see a post when they are submitting data to the api you'll see a put when we're putting data in or information into the api and you'll see a delete when you're removing records hey and now think back to one of the first slides where I showed the Pearl CGI scripts man

if you were testing an app that was a pearl CGI and I told you that the server supported put and delete you'd giggle right to be a little evil maniacal laughter um way too often we see pen testers that will look at RESTful API see that it uses a put and a delete and flatten that as a high risk they don't even test it they don't even verify that what they think is going on is what's going on they just say oh that's bad we see that a lot from internal security teams right because of this traditional mindset it's that method was bad there's nothing about it I don't need to do need to verify it it's bad to have

the reality is that's not true could it be bad yes if I can delete records out of your API with out authorization that would be bad if I can put records into your API without authorization that can be bad but it's not the traditional bad and we have to evaluate what's going on so understand the inputs what is the format for example you'll see JavaScript object notation Jason JSON right you'll see just normal regular inputs name value pairs you'll also see and this one throws off a lot of people where instead of the URL being something like API dot JSP question mark name equals Kevin and password ampersand password equals password right instead of that type of fauna in the URL instead

you'll see URLs where the path and file name are actually parameters to the application right you'll see where those parameters if you change them if you change the one that's the name it doesn't do anything breaks yeah the right cuz you haven't passed in the correct name value pairs if you change the value you can actually start doing injections you can put payloads that you can actually start so understand the format of what they're doing check to see if it's modifiable in some systems they actually sign the input to see if it's been manipulated before it's sent right you'll so check that out find out how they're signing it look at the client-side code to see if you can sign

it yourself or as with like the JW P's I'm just bouncing back because the screenshots are on here write a Java web tokens can be signed but when you specify the algorithm up at the top where it says LGHS 256 if you can read that um once you set it to none right so you don't encrypt it or in sign it right does the application accept that does the application still use that token correctly right um one of the examples here and this is a spoiler so if you don't want to hear a spoiler for juice shop don't listen to this part right but you can actually hit the API and what we find in many api's is that they were ton

significantly more data than the user needs in this case it's the lower left-hand screenshot that's a response from the authentication - details function inside the user API for juice shop and it actually dumps out a list of all the users in the system and now that's more information I need but let's break it even worse it actually sends you the authentication token for the current user the users that are logged in right and it's in a JWT so you can decode it a JWT is just three pieces that are base64 encoded and we all know that base64 is not encryption right so we pull that down we decode it and we now have the hash unsalted for

the password for the user end in Jew shop it's one user authenticate at a time because it's all local but this is actually something we see quite often with other applications is it'll dump more information than you need and you'll get things like tokens and credentials and hatches that you then have to crack right so how do you handle that now how do you find all this stuff well right off the bat it use the app because what we find is if you have api's the api's are called by the application and look for things like mobile versions look for things like documentation that is available for the application many times look to find out

if the API is something built on a framework or something provided to them especially if you're looking at like a single sign-on system that has been put on top of this there's going to be API is that came with the single sign-on system go read the documentation see if there's things they can call when we work with companies one of the main things that we do is that we will ask for a postman collection so from your developers postman is a tool that will let you interact with restful api is um you get a postman collection you have the entire api that they've documented and tested themselves right and you can possibly run that through burke and we

make the request to burke and then we have the burp inner pages to do all the normal stuff that we do if you can't get a postman collection swagger collections documentation swagger documentation can be converted to be able to be used um but it's very least asked right talk to them about what is available out there ok finally we want to talk about the client and this is just a screenshot of the browser right don't lose sight of the developer tools that are in your browser the developer tools will let you know how the is rendering things what is available to the client what the system uses to deal with stuff right it will also give you

act act access sorry two things link local storage you'll be able to look at the full response that's coming back down all within the browser so very useful if you're in one of those situations where hey test this will give you a Citrix desktop that you have a browser in and that's it okay um is that good is that the right way to test no it's a story okay and the last thing I want to talk about is dom-based xss closets with me if you've ever heard me speak before if you've ever talked to me you know that probably my favorite vulnerability out there just cross-site scripting I love attacking cross-site scripting and we've forever known about

reflected and persistent you know I send a payload up it comes back down in the response that's reflected attack if I send it up and it's stolen somewhere on the application that's a persistent attack but dom-based is very misunderstood as a matter of fact what I found is that a lot of the documentation on dom-based xss is wrong and some of the samples and examples of dom-based xss or wrong dom-based xss is different from normal XSS and I hate to call it that but let's go with it for right now insofar as every piece of the attack is managed and handled and processed client-side so if I make a request I get a response and in that response is

client-side code that in a simplistic example references the URL and uses it on the page within the Dom or the document object model I have a good chance of a dom-based xss and many of the libraries people will use jquery angular or whatever they've had dom-based xss vulnerabilities that the library brings with it into your application so even though your app wasn't vulnerable until you use the library use of library added that vulnerability okay and so you want to do is really look at what the client-side code is doing and if the client-side code holes data from the client like I said could be the URL could be things like local storage it could be cookies things that

are within the client especially when you start talking about mobile apps right and then use those within the Dom so you'll see things like dot in an HTML you'll see things like document dot right please don't use document and then what you have to do you can't test these typically with the traditional XSS payloads you can't just put script alert XSS clothes rip type because since it's working in the Dom you have to embed into where it's being used okay and so lots of times that code will be pulling that data out let's say from the URL and then using it in a block of JavaScript so you're gonna add JavaScript code to that block of JavaScript and it'll

execute and things like that again really take time look at the client-side code and understand what's going on yes that means you're going to be reading JavaScript and for that I apologize because you're gonna have to read a lot of bad JavaScript okay there are plugins that will help you with this both zap and burp will attempt to detect dom-based xss my experience has been both of them have a high false positive rate so you're really gonna have to look at what that client-side code looks like okay so that is my slides I'm gonna stop sharing my screen so I can start seeing discord I hope and then I would say I think I went over slightly um Jason's

made a come in and discord that Jada booties can be encrypted but we rarely encounter apps where they are that is absolutely true uh it's so sad that they can be but most people don't um out there and I don't so I'm looking really quick I don't see any question that I need to answer right this second um I'm going to say thank you very much and I'm gonna turn this over you and your let us know it's really thank you again for coming in that Shari what's it with everybody really yeah they keep an eye on there in fact good chance hanging out discord there's plenty of folks in there I'm sure there's that more than a few that

but I get to talk to you yep oh all right well sometime soon all right take care