REST is the Sweet Sauce of Labor

okay welcome to the gold room first talk is Kevin Cody we're gonna learn about rest is the sweet sauce of Labor and with it all farther adieu Gavin Cody morning everyone get cozy comfy you don't stay in the whole time there's some seats I'm sure people be funneling out halfway through so feel free to to fill in so yeah oh that's not the right thing all right we're gonna be starting real soon so everybody please get settled in thank you that's them for the next room I guess I don't know all right so yeah we're going to be talking about rest today my name's Kevin Cody if you don't know me I am from Pittsburgh so Jen's are at heart

here a little bit north near the Grove City Newcastle area I'm a principal application security consultant with envision we're a boutique OPSEC firm I'm a bit of a vulnerability StumbleUpon or if you haven't worked with me in before you'll know that mainframe enthusiasts people who've been through my talks before no this is kind of how I start off so I'm gonna go a little bit further today yes there is more so I'm also the OWASP Pittsburgh chapter leader so if you're interested in the stuff we're gonna be talking about today please come out to the OWASP meetings there's gonna be one next week of July don't know what just happened

there is alright July next Thursday things like July 28th or sorry June 28th we have a Pittsburgh meetup so I definitely take a look at their or the OWASP wiki I published them on there as well I also helped out with the three rivers information security symposium which is a group of a bunch of different Pittsburgh applicator or InfoSec groups we put on a security symposium that is set for October I'll be speaking of besides Cleveland tomorrow so any of you folks who are going from here today over there completely different subject etc and anyone who comes out to Steel City InfoSec I frequent there as well so that's a little bit about me but that's

it no more talk about me let's talk about some fun stuff and get rolling so today we're gonna talk about monolithic versus micro services because I think that's a really good kind of intro into the rest 101 rest paradigm why we are so rest centric today then I'm gonna go into rest 101 so we'll go into that I'm gonna discuss some tooling around testing rest both from security and operations and and QA perspective going to security focuses and concerns and then I'll get into a little bit of a technical deep dive hopefully the demo gods are good to us in here and then proceed to some summaries and takeaways all right so to dive into this this is

the gist this is an awesome graphic from vero Sanchez on Twitter this is describing monolithic services versus micro services right this is this is one of my favorite graphics on this but in reality so monolithic applications right how many folks in here work for an enterprise who you either develop on test security of do compliance on what you'd consider like a monolithic application traditional tried and true either fit client app or web app that uses one platform so like for people okay cool all right now what we see here are large code bases usually they're bloated they have a lot of carryover from from different years and developed and strategies etc they are a detriment

to new features right so when you try to introduce new features for monolithic applications it's pretty tough because you have to consider all of this blow all of this years of history whatever platform you know net etc that you're used to or I'm sorry that the monolithic application is written on and it's kind of hard to to you know introduce some of those new features and therefore they are stagnant in the face of technology right we kind of just have to drag them along and keep going and from a security perspective they're difficult to assess right because there's just their old Matoo Thor using an old version of Java or whatever the cases are they're

usually pretty difficult to assess because of everything else I just said so then we move on to micro services so micro services kind of work as this pieces of a larger puzzle and I'll break down in a moment give you an example of that but the cool thing about micro services are they're easier to distribute across different data centers or different cloud hosting environments etc you can migrate them they're easier to maintain they're more in line with the agile development process because micro services can be literally broken up into portions and you can work on those independently they're usually easier to document than a monolithic application because there's usually services that are alike query this or delete that etc so they're

usually easier to document you don't have to really dig down into the code or pull someone out of retirement and say hey man what did this do again I don't know what this did or does but they're still kind of difficult to assess even micro services because of how modular they are and how everything kind of pieces together they're still difficult to assess but hopefully some of the stuff we'll go over today will help us get over that barrier so to recap we're kind of in the same place right they're both kind of difficult some seem good some seem bad but let me break down you know kind of what micro services look like today so

to give you an example let's take a retail app right it has a shopping cart checkout and you can buy stuff right that's your traditional retail application web app on the Internet but you also want to introduce because the business really wants shipped to store so now you have to take inventory out of the warehouse and ship it to the store and the store people have to be ready to pick it up ready to distribute it etc customers also want store inventory so now it's backwards you have to query your internal store inventory know where things are at where people can go pick things up etc well now someone wants wishlist send and social and sharing and

registry so that's a completely different thing than shopping cart checkout and buy stuff right now you're integrating with OAuth or your you have the ability to send out invites or sharing or you have to link the inventory from the in-store to online so people know when your friend goes and picks up the Babies R Us registry item that it's no longer on that registry right so things keep kind of growing here well now someone says ok well now we want Aude mented reality for our mirrors and store finders right have we have seen where you get out your phone and you can you know point it out and it'll say ok here's the GPS of the

nearest store walk this way make a left you know go over here right oh and we want beacons in the store so we know where our customers are at what they're looking at etc etc that's a lot of stuff can you imagine trying to implement this stuff in a monolithic application that has you know that's written on Java 1/6 or on dotnet you know - and you know you're trying to you know implement all this ad hoc ala cart things and they don't really talk well together they're not even from the same you know decade right we're talking about early 2000s or possibly even 99 98 and we're talking about technologies that have just been

really coming into the fold in the last 5 or less years so how do we deliver that content to a consumer in a way that a consumer can actually use it right so today's picture what today looks like is a bevy of different hosting options right we have on Prem cloud hybrid whatever today's soup du jour is right I'm sure I heard something HP has this thing where you by equipment you host in your data center then you pay the money to unlock the equipment the end of some cool thing so that's that's that's one piece of the puzzle then there's this whole service-oriented architecture which is another piece then we throw micro services on top of that we have to make

sure everything's talking in a standard innit data interchange format which is interesting when we're talking about all these discrete pieces then we parse that on the client-side using something like a JavaScript framework or a single page application so that all of these different discrete services maybe ones written in Kotlin maybe ones written in Scala maybe a swift server-side or go right all of these things can dock talk in discreet ways be sent to the client the client just sees it as a JSON blob which is then parsed and delivered just like any other data stream and then you can deliver all these discrete things so we add it all together and we as an industry decided that services was

weight the way to go right we we were gonna go with services so everyone's still with me that was a lot really fast but I wanted to get you up to speed as far as why restau is what it is today and I'm just gonna say it I'm not gonna talk about soap I'm not a big fan of soap soap is gnarly to work with XML format is is crazy the envelope yet that parsers etc this isn't a soap talk we're gonna talk about rest today so where does rest fit in so Roy Thomas felting created the rest architecture and paradigm back in 2000 it was actually his PhD dissertation and can I take an

aside for a second Roy's personal web domain are you ready for this is Roy da Jie bills okay if that's not hilarious I don't know what was I was cracking up when I saw that he owns dot G bib and in subdomains Roy anyway maybe so he's a dissertation was architectural styles in the design of network based software architectures which is a mouthful but the whole idea about was this idea of representational state transfer or what we like to call rest and there was a few cornerstones to the rest paradigm one is that it was stateless the idea of stateless and we're gonna dive into Salus more in a moment the HTTP methods were strictly enforced

so when we when we talk about methods again we'll dive into that more in a moment and standardized data elements for consistency purposes was huge so if you think about the 2000s this idea of web 100 or one one was still in its infancy and so we had like headers and and the whole idea behind rest or one of the biggest concerns that Roy had when he when he actually created the rest paradigm was that like the host header wasn't even a consistent thing back then he's like man rest would work awesome if we just sent the host with every request but that wasn't a common practice in 2000 so that was one of the things that

kind of held him back and and Roy actually helped design the standards for web 100 and web 1-1 and he helped with building Apache etc but we've come a long way but when we talk about data elements Roy was basically speaking to different things that we see is just normal HTTP traffic now right so who's talking about resources like where the intended target of our our communication is going then the resource identifier write the URL URI u RN etc the representation of the data that you were transmitting to and from right so we're talking about back then HTML documents JPEGs now this is stolen directly from his dissertation so some of these things may not match exactly from the from the

terminology that we use today but this is the exact kind of things that he was worried about when he created the rest the rest of paradigm we talked about metadata right media type last modified time anyone familiar with HTTP headers this is the stuff that you see in those headers right metadata control data cache caching was big when rest was being thought up because of this statelessness and the ability to be able to transmit a large amount of data over internet that wasn't really fast and optimized as it is today so then as I mentioned we go into HTTP methods and HD restful api is enable you to develop web applications with all possible crud

operations so crud if you're not familiar is create retrieve update and delete so if we map those two HTTP methods that comes out to be post an HTTP POST method is for creation a get method is for reading or querying a put method is to update a replace patch is to partially update or modify and delete it's to delete a record from a data store this seems pretty straightforward but I do have a question what is what are this what does this mapping mean to security folks in here what kind of problems could you see a rising from using these methods in this manner good sir

okay so okay so just repeat if you didn't hear so Scott's answer was where data is being transmitted in the HTTP request specifically concerns with HTTP URI parameters or query parameters and that's exactly right so information leakage via URL per at query parameters is a real concern but remember if we're using rest as it was intended to be used if we're querying a back-end datastore we're supposed to be using the get method so if your look up is SSN you're now transmitting an SSN as a query parameter and every time I see that my absolute every time my reaction is what are those every time I see some crazy amount of data being transmitted in a query parameter right because think

about query parameters right they're cached on the browser they're cached and proxies they're available in web app logs they're available in load balancer logs so this whole idea of using crud operations exactly how they're meant to be used is a little bit interesting but rest for ian's be like one love for verbs right you're supposed to use those things I got one good laughs thanks Kevin I was cracking up when I found this like who made this this is great yes so you know if you talk to someone about the rest standards and how rest should be utilized they will swear that you have to use those methods and only those methods and if you do anything

else outside of those methods you are wrong but you'll get a pass from security guy because I think you're right so let's agree to disagree on that one we'll continue on the rest and it's gonna pick up a little bit I just want to take you on on a basically a tale of where rest came from it was really the reason it's so it's so widely used now is because of this whole micro-service architecture is why I want to introduce you to that taking on a history tour of rest and kind of the the spec came from and then we'll get into some fun technical deep dive so so hang with me if this is this is a little

bit too high level but we talk about restful services remember one of the goals is to stateless lis pass information as data representations so in today's rest services what we usually see are key value pairs right so you see something like yeah mo people familiar with the ammo like for people again cool so he Hamels basically this again this key value pair so you have a presentation the name of the presentation is rest as a sweet sauce flavor the venue is besides Pittsburgh right pretty straightforward key value pair you can also send rest services with XML which is interesting again one of the reason I'm not a huge fan of soap is because the whole soap

envelope and XML and parsing and all that fun stuff but you can actually have a restful service which is delivered via XML key value pairs so the key is time and the value is oh nine hundred which I think we're a little after nine hundred today will continue and then the biggest and best and and and how many people are familiar with JSON lots more JSON it's taking over is a JSON or Jason JSON thank you yeah it's all object notation it's on Jason so JSON it's it's similar key value pairs to Yambol but a little bit of the the consistency is a little bit different where you pass in the the value pair with each per am so we have

this data right and it's sent in a request or response then what happens well it's received parsed and processed for further activities so what does that look like we think back to our architecture a thought process it might be client-side rendering right we talked about JavaScript frameworks they might take that data pull it in use client-side JavaScript parse it all up figure out how it maps to the the client and then display it in a way that the user has no idea how that information was transmitted but in reality it was via a RESTful API that was completely discrete from the you know so say they're checking the balance of their bank account it's a completely discrete web

service from when they needed the login authentication or when they are gonna do a transfer right but at the end of the day it looks very seamless to the customer upfront because it's just data being represented and parsed on the client side there's also the inverse of that it might be sent from the client in a post get whatever received on the server and then maybe put in a data store somewhere or punch some way on the server side right so it can be used for both right the ADA representation could be used for both but there's also a third right you could have middleware right so this doesn't really touch the client at all you could be doing some

type of normal interaction with a client app data is sent or just receive it server-side and then the server uses restful api so to talk amongst another server or maybe AWS or what have you so at the end of the day rest can be used in a variety of different ways and it's really just a transport method for data just think of it as a transport method for data so when we talk about restrictions or guidelines to be restful right other than people saying you got to follow the crud operations which again I'm gonna tell you you don't have to so that's your first rule that you can break there's the other thing there's the other thing about

statelessness right they're gonna say you have to be stateless to be a rest service if you have restful services they had to be stateless well that's not really necessarily true reader we'll get to that in a second but one thing that is always tried-and-true is any rest services can be market as an API and you can sell it to customers that's a universal truth if you have a rest service market it as an API and sell it to your customers but I digress so when we talk about statelessness let's dig into that a little bit further so the HTTP protocol is stateless so when we talk about rest being a you know higher up in the the the model

it's a little bit interesting that we're layering a stateless service on top of a stateless protocol right where does the state come into play here or should it not well if we don't have state things kind of tend to break on how our users use the web and in today's standards and what I mean by that is people basically have created these sidesteps around stateful experiences so you have things like client side sessions client side storage which basically give you pseudo stateless experiences but what about authorization headers right Oh auth tokens bearer off etc that's still a state if you're passing that information you're still mapping that on the backend for authentication and authorization so you can call it

stateless but at the end of the day that's still stateful in some manner and if we don't how do we were on the same lines how do we revoke in the circumstance of compromise so if you are using a state a client-side session what happens if someone steals the users client-side session or compromises the server storage of the identifiers and then the other thing is can our users log out right if you you client-side sessions do you know what the most the biggest way that our applications are implementing log out with client-side sessions throw it out they just delete the cookie or the header or the jot or whatever the case is they just delete it

that's not logout it's just deletion what happens if there's a network error or what happens if someone thinks they're logged out but someone had already grabbed that token via man-in-the-middle or local exploit and now the user thinks they're logged out but someone still has a valid session right this is this is like inverse I can see you but you can't see me I like and and if you say a JWT or George JSON web token is the answer to this I don't want to hear it don't we're not gonna have this discussion I'm not a fan of JWT as an answer to statelessness with rest services so we're just gonna go over that right now all right so again

I've spit a lot at you so far I talked to you about monolithic versus micro services and why restau is so prevalent in our environments today and how they've kind of risen up then I talked took you on a history lesson of where rest came from and how it's being used and misused today in our environments so let's discuss security tooling and how we can test rest services or ascertain and document and understand how rest services work but first everyone still with me I'm talking really fast right now we're good all right so tooling how many people have heard of swagger good postman a little more insomnia one person how about link finder awesome one person

as well cool another security centric tool and we're gonna go into so swagger Swagger's tagline is design build document test and standardize who here thinks design build test and standardize sounds good thing I want to see everyone's hands good all right so my perspective on swagger it's great as a testing harness because it has a built in web UI to invoke rest services our API is in general and the reason why I say I like the web UI thing is because from a web hacker or attacker or web security guy I like things that are in the browser because I'm already used to working with things in the browser so it's not an extra tool if it's not a

installable thick client electron client etc things seem to work a little bit better for me so so I dig that I dig that it's built right into the web basically you deploy on your app server and it'll do some self documenting and stuff so yeah you can use it on AWS you can use them on Azure you can use it on Prem internal completely you know firewalled off from your external which is which is cool document documenting api is the rest services growth is a good thing I think everyone can agree on that and swagger will help you do that with some self documenting features but there are some quirks with swagger first of all it's owned and operated by smart

bear and if anyone's ever used who's you soap UI in here it's hope you II's e to work with no it's not and you'll see a little bit of that come through swagger is awesome that's not non sane but you'll see a little bit of the soap UI contextual menus and and and kind of thought process in the swagger UI because it's it's brought to you by the same folks so if we zoom in a little bit here this is what swagger looks like and we're probably gonna be a little pixelated I'm sorry oh yeah you can't see anything let me read you what the colors are so the green is a post the oranges a put the blue is a gifts and

I'll go to the next slide which unfortunately don't like you're gonna be able to see but basically how you interact with you can drill down into that API endpoint and you actually see the JSON of what the endpoint is expecting there right there on your screen and there's some self documenting features right so you can say like this one is pet store swagger Daioh which is a demo that you can actually go out and use if you're interested in seeing swagger and use but this one is for adding a pet to the backend data store so it's a post request and the post request is expecting this data array which is in in JSON representation so

you as an auditor or a pen tester or a developer or someone getting just used to the ropes can go out to the swagger UI and see exactly what the backend API is expect because it's documented in the the swagger UI so swagger is pretty cool there's also a postman which some of you were more familiar with postman post man's tagline is post me ins tools support every stage of the API lifecycle we have a lot of buzzwords there I think I think we're on the right track right so what can you do with postman they have collections which is very similar to your swagger documentation can invoke calls document calls etc there's workspaces so workspaces is and

this is their term I didn't come up with is that I wanna hear groans workspaces is an a de anyone want to guess a de what's the same for say louder sorry API development environment IDs weren't enough guys we're on a DES now right so yeah it's an integrated workspace where you can actually deploy code directly from your postman interface of course there's a hooks and and-and-and docker and and whatever buzzword you want to use right in that will make it easier to deploy but that is I mean that's a pretty cool thing but could they just call it an IDE and stop there and there's also tooling buildings you can do like load tests unit tests

integration tests some security testing which will maybe dive into a little bit so my POV on postman you're interested postman is a thick client in the form of electron app who here is familiar with electron applications so like for people again I must like the number four so electron apps are basically built on the chromium engine who here uses Chrome browser a lot of people what's one of the biggest drawbacks to using chrome versus some of the other browsers so you get great security renders really quickly they have a good v8 to JavaScript engine what's like the one drawback of using chrome over the others memory memory so the problem with electron is it also uses a lot of memory

so when you using say chrome and slack and postman and Reich and whatever other electron apps by by Graham right this thing only can do 16 gigs of RAM and I'm pegged already just using like four tools so it's interesting they're all there is a browser plugin but I think that's deprecated I don't think they're gonna continue development from the postman and on on the browser plugin so that's it's not deployed on the server it's a local client that you use so that's maybe a drawback [Music] so collections again our documentation built with with harnesses very similar to the to the swagger UI perspective and again documentation is good I don't care who you are if you're a developer if

you're a security person if you're a C so if you're a CEO if someone comes to you and say hey look I've documented this thing to death it's really good I'm going to applaud that person right documentation is awesome so having build and documentation is is great but the one thing that's interesting with postman is there's tons of options tons of configurations which makes the learning curve a little bit higher as well as it can be a little bit tricky to proxy if you've never proxied traffic from an electron app before or I'm sorry from postman directly before it takes a little bit of intuition to get set up and reading the docs and adding this and

changing environmental variables here etc etc so sometimes it's easier just to proxy the whole damn thing just feed the post me an app a command line line flag when you enter into postman and you can just proxy the whole app again goodbye Ram right it's the electron app so that's my two cents on postman you're not gonna be home this is like abstract representation of what postman looks like but the idea here is you have your operations on on the left there write your API documentation in the middle here you have the actual request so where my mouse is here you have the HTTP verb get and then here is the URI path and then down here is the actual bar

body of the JSON method or the JSON representation that you're sending etc if you're interested in trying out postman either in a security context or maybe a business context etc just go to get postman com download the client and it has built in demo endpoints that you can play with and start to understand an ass chain just don't hack those endpoints the same with the the pet store swagger thing like I don't own those I'm not giving you permission to hack them so just my word of caution so the next one is insomnia so insomnia is tag line debug api's like a human not a robot well I'm not a robot so this is already

sound sounded kind of good in all honesty similar feature set the postman collections it just doesn't have the ad II and tools built into it it's another thick client electron app but honestly it just feels lighter it's it's takes less resources it's open source so if you're one of those folks and you enjoy open source software like I do that's always a good thing that's the github link up there it has a slightly a counter intuitive interface compared to swagger UI and and a postman but how many of in here have used burp suite so about half awesome how many of you here use app a little bit less how many people can switch seamlessly between

burp suite and zap nobody one I don't use them both all right me I'm like where do I set this said I don't know what I'm looking at is this even English right so I think it's just a tool thing once you get used to using insomnia you can probably transition between postman and swagger and insomnia pretty seamlessly but you having trouble ask this guy he just can switch you eyes like like King okay cool so those are all when you have API endpoints that are documented in a way that you can use an interface to then interact but what if you are testing an application or tasked with documenting an internal API that maybe you don't have

source code for or maybe you don't have the chops to review source code to find the API influence or what if you're on a penetration test or you're doing bug bounties and you want to be able to find all the API endpoints of a certain app that's where link fire comes in I love this tool it's written in Python basically what it does is you feed it a JavaScript file or a burp State you can feed it a burp State and it will actually go out parse the JavaScript beautify it unmet cetera find all your API endpoints and then give you a nice output of all the API endpoints where then you can then go and invoke now it

won't give you the actual JSON pretty print of what the endpoint is expecting but it's really good for this time for you may not have code but you want to find API endpoints to then test like I said as JJ JavaScript beautifier on minify you can do reg X's and search trains etc and I'm gonna show you a demo but okay so yeah that's actually not that okay so what I had here is the tool like I said it's written in Python link finder dot PI so Python link pandered link fine about pi - i is feeding in a javascript file in which i want to parse - oh is give me an output of an HTML

format so what this tool is going to do it's gonna go out to a JavaScript endpoint find all the api's ARBs our javascript file find all the API endpoints try to parse them out and then give them them back to me in an HTML file that I can actually do something with so let's see this in action am i not connected okay well that's not gonna be good I have a backup I think I'm just not connected to Wi-Fi but so this is what the output looks like so anyone here heard of juice shop like three people so juice shop is a vulnerable web application by a wasp to have fun with this is my instance of

juice shop don't hack I mean it is available out there but don't hack it because I could just nuke the instance I guess but anyway juice shop is written in client-side JavaScript and has its end point called juice shop min J yes and this is the whole interface is everything you interface with on the client side is defined in this javascript file because remember if you are using a web app to interface with an application you have to know where to send requests to right you can't just say like oh check my balance and the browser comes back to you like what's the end point for balance checking right I don't know I don't even know so it has

to be defined somewhere if you're not using like a mobile app or a thick client app that comes with those things those registers already are predefined so web apps what they normally do is use something like JavaScript to represent this information it's parsed on the client-side and then all of a sudden the browser knows when I want to request a transfer this is the endpoint that I want to hit it with problem is it's usually minified and crazy and you can't find this so that's what tool does so if I go through here there's an API endpoint that is login or oo auth or baskets QR code etc right this took all that minified javascript made it nice parse it out

gave me something that I can then go test with and now what it's the first thing I'm gonna do I'm gonna go to every one of those API endpoints and see if I can hit it unauthenticated or see what kind of data it spits back or maybe cause a stack trace error message and send it some some fuzz to info right so this is really cool if you are interested in testing api's but maybe don't have the backend code for something like postman or swagger or insomnia I can get my slides back here we go all right so when we talk about security concerns I talked about tooling and how we can start testing some of these

invoking these methods using these handlers but what are actual concerns when we talk about rest well I hope this isn't a big whomp-whomp for everyone out there but the same web stuff that your use of testing much applies to rest the entire top ten but there are also some specifics right so like gray and black box already talked about link finder you can also use like API manuals user manuals OSINT google dorks etc to try to find rest API endpoints because again rest services aren't usually defined in one like HTML doc they're usually pull down in parsed separately so sometimes just finding the AAP API endpoints to hit is a challenge when you're testing rest in addition some tooling doesn't

take advantage of pass style parameter manipulation as rest does they're basically used to looking at you know standard gets posts the path isn't changing much maybe add a one path parameter on and calling add a it's not actually going through the tree and going in and changing maybe user one slash account balance and it's not going back in the past and saying user to user three account balance etc so just something to keep keep an eye on as far as your tools if there are properly set for path size parameter manipulations and then also something big and rest is this idea of using signatures for anti tampering as signatures can be a bear so that's another thing that you might have

to think of when you're doing security testing specifically the rest so real quick injection broken authentication sensitive data exposure XML entity injection remember rest bodies can be XML if you're parsing XML you're vulnerable to XML entity injection possibly depending on your configuration broken on access controls security msconfig cross-site scripting depending on your content type DC R using bonus with known vulnerabilities and insufficient logging and monitoring I know I just literally recited to you the 2017 o Oz top 10 list but the idea is all of those apply to rest services you're not getting out of anything there might be some some out-of-the-box configurations that make you less susceptible to some of these like maybe using text plane or content tough JSON

might help you from cross-site scripting concerns but if you then take that data and drop it into HTML somewhere you still could have some cross site scripting concerns right so be cognizant of all the OAuth top 10 stuff when you're doing security testing for wrist I'm flying here everyone still with me maybe by me if you got caught up on something is an open bar I don't know open bar open bar so just go get me a drink bring it over and I'll I'll go back over some of this stuff how much time you have oh oh cool alright so you guys I don't if you'll be able to see it but I'd like to do a demo for you if you

guys are cool with that cool so this is a wasp juice shop again I I kind of alluded to this so wasps juice shop is a JavaScript application that has back-end rest services it is purposely vulnerable but the cool thing about juice shop is it's really easy to deploy so if you want to like go out and spin up a local ants on docker there's already docker hub in images of juice shop if you deploy to Heroku you literally create an account in Heroku click the publish and you get an instance where you can just test it and Heroku is completely okay with this as long as you're not doing denial of service attacks or anything else that

could cause damage to their underlying containers so if and this is another plug for a wasp Pittsburgh if you're interested in doing this a wasp Pittsburgh is having a web app hacking night next month it's June 18th I bullet or July 18th excuse me and we're actually gonna be hacking juice shop and having some funds if you're interested to come out and I'll show you how to how to do some of this stuff but anyway so this is an instance of Jew shop if I scroll down through here you can see like there's all kinds of fake products and all kinds of stuff you can click on it and get some information I think my internet dropped off so you're

not seeing everything here let me see if I can commit the unplug for one second

I'm not I'm not joining your shady my Fi he had it all set up like ready like here's my my fight no I appreciate just giving you a hard time no I have I actually had my hotspot on but one second

you guys are all like I should have gone to Brian's talk he didn't have problems with Wi-Fi maybe I might be joined you're my fight here in a second oh

paper minute I see like everyone else is my face here except for my n phone there it is okay

we back we're back alright let's test it out real quick we're not back [Music]

let's try in

demo gods I can show you some stuff with that all right well I'm not gonna take your time so wow that's doing this I already have burp I already parse the end point I know purpose is gonna be terrible when I'm trying to present to you but this is the directory structure of juice shop and here are the rest API endpoints surprise there under the rest directory and then you can see admin product user etc so if you kind of want an idea of what kind of things I would start doing with testing rest is I would take one of these rest endpoints and send it to repeat an open up repeater and oh this

is lovely so you can see here that get rest admin application version and this is my host header right Cody juice shop and it's a get request so there's no there's no parameter so what happens is the fight it's oh look I am connected okay so we have a version 7.3 dot zero which is interesting because this is an admin endpoint and I'm completely unauthenticated so maybe that's my first concern right that someone's requesting admin API endpoints from a completely unauthenticated session and they're able to get back version data that could be a concern but basically that's what I would start to do so I've parse the API endpoints one cool thing is there's actually a burp extension called swagger

parser so you can go into swagger parser hit the file pull in your your JSON swagger file open it up and it actually parses the endpoints out of the swagger file for you and then you can right-click those and send Senate repeater and now I can actually use my proxy which I'm already used to using right whole burp verses app and this and that right I live eight hours a day five days a week maybe six or seven days a week in burp so I'm very familiar with using burp so now I just took my swagger doc and cool thing is postman you can export a swagger doc so either way this will work and I just imported into my

proxy and now I can actually send request directly from here and you can see here Amazon saying that's a bad bad end point cuz I didn't put in the params but yeah it works it works pretty well it's pretty cool but anyway so I would go through my normal testing process right I would go down that top 10 I'd look for broken access controls I'd look for caching issues I look for configuration issues etc and I would just start going down through my testing process once you understand the basics of how rest works why rest was created some of the pitfalls of rest to be completely honest the testing part is exactly the same as

you would normally do if you're a QA tester you pretty much QA test it's exactly the same just knowing how the architecture is set up and how parameters were passed and all that good stuff now you have the knowledge to go out and do your QA testing or if you're a pen tester or a security person you go through your same testing process you just now know a little bit more about why restau works the way it does how things on the back end might be architected and now you can attack things a little bit differently so this isn't the best setup to do a whole lot of demos but hopefully that makes a little bit sense and you got a little

bit of something out of out of the the proxy stuff so just to wrap things up we went over monolithic service versus micro services why micro services are making such a big headway and in our enterprise's infrastructure today and why restau is then so hot right now right because rest is easy to implement at the micro service level we went over rest 101 a fun history of where rest came from where it is now some things that versus stateful and stateless and the the crud method methods and all that fun stuff talked about tooling with swagger post me and saw me a link finder burp extensions everyone's leaving security concerns I'll open it up for

questions oh I'm sorry follow-up about the web hacking night my slides will be available both on my personal blog as well as my company blog and vision calm and stop by the lockpick village later I bought an IOT thing that we're gonna hack and it's gonna be some fun so if you're interested in that stop by there and n vis I um and Visia men the ISI um that's my employer but they didn't pay me to say that maybe they didn't maybe they paid me to say that thanks besides Pittsburgh volunteers attendees vendors family and you guys without you guys we wouldn't be here I wouldn't be here or maybe I would okay questions [Applause]

any questions scared ask questions alright I'll be around I have I have three separate install discs like old Windows 3.1 now so that's how you can identify me yes question [Music] so a wasp in general open web application security project is completely dedicated to resources and understanding web application security mobile application security and it's kind of evolved from there but Pittsburgh chapter in general is just a complete open meetup I don't require any type of dues or membership or anything like that there you can be a member to the larger OS community and you'll fun projects like to shop you'll fund projects like the top ten but when it comes to OAuth Pittsburgh just go out on

meetup.com or wass wiki and search for Pittsburgh and come out to our events you're more than welcome to participate you're more than welcome to become my my co-lead you're more than welcome to present just hit me up there's also a wasp PGH on twitter so you know look for that or I always post the events and stuff like that so yeah completely open group everyone's welcome and I'd love to have more participation like I said meeting next thursday and then july 18th is our first web app hacking meetup so thank you for the question awesome question anyone else I talk too fast I'm sorry if you see me grab me I'm happy to do demos

or answer any specific questions but you guys are awesome seriously thank you all [Applause]