---
title: "Tanya Janca and Nicole Becher -- Hacking APIs and Web Services with DevSlop"
url: https://appsecpodcast.com/tanya-janca-and-nicole-becher-hacking-apis-and-web-services-with-devslop/
date: 2017-09-05
duration_seconds: 2086
guests: ["Tanya Janca", "Nicole Becher"]
topics: ["OWASP Projects", "Security Testing", "Cloud and Infrastructure"]
audio: https://www.buzzsprout.com/1730684/episodes/8122709-tanya-janca-and-nicole-becher-hacking-apis-and-web-services-with-devslop.mp3
transcript: true
---

# Tanya Janca and Nicole Becher -- Hacking APIs and Web Services with DevSlop

*September 5, 2017 · 35 min*

with [Tanya Janca](https://appsecpodcast.com/guests/tanya-janca/), [Nicole Becher](https://appsecpodcast.com/guests/nicole-becher/)

on [OWASP Projects](https://appsecpodcast.com/topics/owasp-projects/), [Security Testing](https://appsecpodcast.com/topics/security-testing/), [Cloud and Infrastructure](https://appsecpodcast.com/topics/cloud-and-infrastructure/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8122709-tanya-janca-and-nicole-becher-hacking-apis-and-web-services-with-devslop.mp3)

## Show notes

APIs may lack a visible interface, but that does not make them hidden or safe. Tanya Janca and Nicole Becher use OWASP DevSlop and its Pixi application to explain how developers and testers can learn API security hands-on. They cover HTTP fundamentals, authentication, rate limiting, proxies, curl, ZAP, and Burp Suite before showing how intentionally vulnerable applications turn those concepts into experiments. The conversation explores Pixi’s microservices, containerized design, planned capture-the-flag mode, and inspiration from OWASP Juice Shop and WebGoat. Tanya and Nicole also discuss the limits of automated scanners and the value of beginner-friendly CTFs. Their central recommendation is simple: interact with real APIs, observe the traffic, and practice breaking safe targets.

The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/).

About Security Journey  
Security Journey provides application security education for developers and everyone in the software development lifecycle.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Tanya Janca and Nicole Becher:  
→ [Tanya Janca on LinkedIn](https://www.linkedin.com/in/tanya-janca)  
→ [Nicole Becher on LinkedIn](https://www.linkedin.com/in/nicolebecher)  
→ [OWASP DevSlop](https://owasp.org/www-project-devslop/)

Mentioned in this episode:  
→ [OWASP DevSlop](https://owasp.org/www-project-devslop/)  
→ [Pixi](https://github.com/DevSlop/Pixi)  
→ [OWASP ZAP](https://www.zaproxy.org/)  
→ [Burp Suite](https://portswigger.net/burp)  
→ [OWASP Juice Shop](https://owasp.org/www-project-juice-shop/)  
→ [OWASP WebGoat](https://owasp.org/www-project-webgoat/)  
→ [Docker](https://www.docker.com/)

Chapters:  
00:00 Hacking APIs and web services with DevSlop  
02:15 Nicole Becher’s security origin story  
04:12 Learning AppSec through vulnerable applications  
06:04 APIs, web services, and HTTP basics  
08:27 Why an API is not invisible  
10:42 Discovering API traffic with a proxy  
12:30 Rate limiting and common API weaknesses  
17:15 Using curl, ZAP, and Burp Suite  
22:12 Pixi and the DevSlop application family  
24:05 Containers and future modules  
26:11 Building a capture-the-flag mode  
28:15 Scanner limitations and better test targets  
30:44 Why developers should try a CTF  
32:47 Hands-on learning at AppSec USA

## Transcript

*6,593 words · assemblyai*

**0:05** The Application Security Podcast. Here we go.

**0:10** Hello all.

**0:29 Chris Romeo:** We're back with another episode of the Application Security Podcast. On this week's episode, Chris and Robert are joined by Tanya and Nicole.

**0:37** They talk about what APIs are, how they're used, and some of the threats involved with them.

**0:42 Chris Romeo:** We also look at what DevSlop and ZAP are in combination with APIs.

**0:47** As always, thanks for listening and enjoy.

**0:49** Hey folks, welcome to this episode of the Application Security Podcast. We are joined today by Tanya and Nicole, who are going to tell us about hacking APIs and web services and some really cool things that they're doing inside of the world of OWASP. And so first, Tanya and Nicole, welcome to the show.

**1:16** Thanks.

**1:18 Chris Romeo:** Yeah, thanks for having us.

**1:19** Yeah, we are very, very glad to have you here. And I know you've both listened to the show before, so you know right where we go right from the beginning. So, we want our audience to understand how'd you get into security? What's your security superhero origin story? So, Tanya, why don't you go ahead and tell us kind of from your perspective how you got into this?

**1:40** I was a software developer for 17 years, and basically we had an ethical hacker in And he gave a Lunch and Learn and he just destroyed one of our apps in front of us. Oh, jungle noises. And basically, like, I was like, I have to learn how to do that. And then he got me to be his apprentice and he taught me how to hack things. And then I joined OWASP and it just took off from there. I'm the chapter leader for Ottawa and now I'm doing this awesome project with Nicole.

**2:15** Very cool. Nicole, how did you get into security?

**2:18 Chris Romeo:** Yeah, so I guess it's a little similar. I mean, I was sort of that nerd kid from, you know, 3 or 4 years old who started programming back then, and I didn't realize that security was actually a field. I don't actually think it was back then. And, you know, it was sort of like the tail end of the dot-com boom. So I started, you know, I took the tour here in IT. I did like network admin, sysadmin, you know, developer work, and then I sort of like fell into security that way. So, I've sort of worked on the technical consulting side, in-house side, and I took a little tour in government. So, I worked on the policy side. That was pretty cool. And I've been involved with OWASP for about, I don't know, I guess about 5 or 6 years. And I'm a chapter leader in OWASP Brooklyn. And I've been part of like a few different OWASP projects, but this is like a new, fresh, brand new project that we kind of started to like freshen up some of the—

**3:06** Yeah.

**3:07 Chris Romeo:** You know, I had a project that was a little bit old, so I needed to freshen it up. So, it became a new project.

**3:12** Yeah. This is very cool. We've had lots of folks from the OWASP universe that have been part of the podcast with us here. And so, it's exciting to know that we're talking to 2 different chapter leaders of international chapter leaders in the OWASP universe here. So, I guess the next question I'm thinking about is, how did you get connected and start working on this project together?

**3:38** Do you wanna tell the story? Do you want me to tell the story?

**3:40 Chris Romeo:** Yeah, I can do it. I can do it. So I first met Tanya actually at OWASP EU, AppSec EU, and she was standing in front of me or behind me, I think, in the food line. And I kind of thought I knew who she was, but I wasn't really that sure because somebody had once sent a letter to the OWASP leaders list complaining that my old vulnerable app was not online and she really needed it. So we sort of sorted it all out in the food line, but we had met via email a couple of years ago, but we met like in person, you know, like 6 months ago. So, that's our meeting story.

**4:10** Cool. Very cool.

**4:11** Yeah.

**4:12 Chris Romeo:** And the project, I mean, it's sort of like, I kind of just have this philosophical belief that the more— like, you get these questions all the time, like, how do you get into this? Like, what could I do? What do I need to read? What should I watch? What should I do? And I feel like pointing people in these directions where it's like, take this long class, it's 14 weeks, take this, you know, like these really long endeavors. Sometimes it's just like people get discouraged. So I kind of think if you have these vulnerable apps out there, that they could just sort of take these baby steps to just even understand how to think about this problem. It sort of gets them much more traction than they would any other way. So I had run a previous project called Victum, which was a series of older web apps that were vulnerable. And I was like, you know what? The world's changing. The web doesn't even look the same as it did 4 years ago. And who knows what it's gonna look like in 4 more years, right? I was like, we need to get some better vulnerable apps out there, like APIs, really good modern stuff with frontend frameworks and microservices and all this DevOps stuff. So I started writing this API that I was going to just be like, it's headless. It was just an API. And then people were like, well, I don't really know what to do with this API. So I was like, all right, it needs a GUI. So I had to learn Angular and all this other stuff. And then I was like, you know what? Now I need friends. So then Tanya and I— I was like, please join this project. We could do so much together. And she was like, all right, I'm in. I think it was like you didn't even really— there was no push. You just sort of agreed completely, which is great. And now it's sort of in this infant stage of we have this one app called Pixie. And it's part of this larger project called DevSlop. And we're sort of trying to get more and more modern applications wrapped up in this to showcase all the things that go wrong in developing for the web in 2017 and 2018. That's sort of where we're focused.

**6:04** Okay. And I want to kind of go back a little bit. And so one of the things we try to do on the podcast here is we know we have a lot of experienced professionals, but we also want to help folks who might be more new to the industry. So I want you to kind of explain for us a little bit about What is an API and how are APIs actually used on the modern web? Because I think that's kind of the direction you were going in creating this new project, but I wanna lay the foundation for folks in case they don't have a good understanding of what we're actually talking about here.

**6:39** So an API—

**6:41 Chris Romeo:** Yeah, sure, Tanya, yep.

**6:42** An API is an application programming interface. So you know how like humans can talk to applications, they usually have a GUI or a command line prompt, but when computers talk to computers or software talks to software, They have an API. Like, it's a different way for them to talk to each other, a different way to communicate. So if you write a web app, and then let's say it needs to look up employees in your employee database, but lots of your different web apps have to look up employees in that database, like, you're not gonna write that code over and over. So you create a service that does it for you, that does whatever the things were that you wanted, 'cause it's more efficient. It makes sure everything's synchronized. And so web services or APIs, like it's different ways for computers to talk to each other, or you can write apps that it really helps with integration as well. So like, let's say someone's written something in VB, some— someone's written something in Java, et cetera. They can all talk to the API still, right? It helps solve some issues.

**7:38** It gives you kind of a standard. So regardless of what the actual programming language is that was used underneath, It gives you like a standard. So there's some standardization then that happens because of these things?

**7:51** Yeah. So let's say you write something in SOAP. SOAP's pretty popular. So then the programming languages, all of them can talk to SOAP and they can talk back and forth to this service. And basically the application, like the web service or API, it just performs whatever service it's programmed to do. So rather than having this monolithic giant application that does everything you've ever dreamed of, Now a lot of people are building smaller things with services, so the service can serve many different applications or many different parts of the program that needs it. And it's, yeah, it's easier that way.

**8:27 Chris Romeo:** And it's not really reinventing anything, right? We're still talking HTTP, generally speaking. I mean, there are APIs that maybe wouldn't, right? But you're still talking HTTP. So for people who are just learning and understand like what a GET request is or a POST or a PUT, input, you know, all these different methods and what headers are and things like that, you're still using that same architecture. Nothing really has changed. It's just now like that request-response cycle is being generated— instead of being generated by a web browser, it's being generated by like a web service or a mobile app or, you know, I don't know, an IoT device or, you know, things like that. So it's, you know, this interactivity between all these devices that don't necessarily have to have web browsers anymore. They just need to talk HTTP. understand the architecture of the API and what it's expecting. So understanding how to talk to it so that it gives you the data you need, and then you sort of ingest the data as you need the data.

**9:18** So is a microservice— how does a microservice— I've heard that word thrown around. Does that play into this thing you're talking about?

**9:26 Chris Romeo:** Well, I mean, I think Pixie has 3 microservices built in. It doesn't need to have those. I was just trying to break it up because that's what all the cool kids are doing. So it could have just not had that, right? But I broke it up, and I was like, all right, it's going to be super cool, Docker and all this other stuff. But, I mean, microservice, I guess really all you're trying to say is that one thing that you do, whether it's upload photos or listen for GET requests to a certain authentication web page or whatever it is, one thing that you have to do and go to a backend database, you can then take that out of a gigantic application and then sort of leave it as just this microservice that listens just for one specific task and then goes and does its other things afterwards. It's meant for performance and computation, but it does sort of increase the complexity. So I feel like beginners sometimes, you know, it depends on where you're entering the world of learning security. If you know HTTP and you're just like trying to understand what microservices are, that's fine. But if you don't even understand HTTP and then you want to understand microservices, start with HTTP.

**10:27** So in terms of security then, I mean, you talk about web applications and trying to secure those and things like that. What about APIs? What are some issues that you might have with APIs in terms of security or threats or any of the above?

**10:42** I think that a lot of people think because there's no GUI on an API that that means no one can find it and it's invisible. But we can find them in like 5 seconds with a proxy, right? Like, you can get in between the web browser and whatever it's calling, and you can see all the APIs there, and then you can start talking to them with something like SoapUI or something else like that, or Burp Suite. And so a lot of people are just not securing APIs whatsoever. So like every, almost every single threat that applies to a web app, like that would get to the web server, it can happen to an API. So like SQL injection, that can happen on an API. And a lot of people for some reason aren't actually protecting them as much as they do their web applications.

**11:28** Yeah. So like authentication, authorization issues, all those kinds of things can still apply to an API.

**11:34** Yeah. And sometimes people just aren't doing anything, like no authentication. They're just like, oh, if you know to call it, you must be the right person. Right.

**11:42 Chris Romeo:** Yeah. There was actually a good Nissan Leaf problem where if you knew the VIN number, you could actually make a call to the API. All it needed was a VIN number in the request header. And you could then like talk to the car with just having the VIN number. I mean, it was ridiculous. It wasn't critical functions of the car, but still there was like literally no authentication besides like—

**12:03** I think Robert just left.

**12:04** If that was on a web app, you would be like, are you kidding?

**12:06 Chris Romeo:** But if it's on an API, it's like, well, you know, all right, well, I didn't realize, you know, so it gets a little— that's exactly the problem.

**12:13** So what other— any other types of threats that are— are there any threats that you would say are specific to the API itself that wouldn't exist in like a browser-based GUI type of experience?

**12:30 Chris Romeo:** Yeah, I mean, sometimes with the API, there's rate limiting issues. Some APIs are really well rate limited. And all that really means is how many requests per second will it be able to handle before it decides it doesn't want to hear from you for some period of time. So you can't brute force the API or just constantly scrape an API. So some APIs that serve up a lot of data, like social media stuff, they'll have pretty generous rate limiting on that. But other ones will have much more— you know, less generous ones who try to restrict people and force this like pay model around that API. So rate limiting is definitely a security issue because if you don't have that and you have an authentication piece around, you know, your API, people could just brute force it all day long. There's no CAPTCHAs, there's none of that going on there. So that's like one issue. The other one is like, you know, sometimes the methods, like, you know, APIs, again, it's just, we're talking HTTP here and you can kind of do what you want here. You could do deletes on GETs, you could do You know, POSTs— well, you have to do a POST on a POST, but you could do, like, you know, username and passwords on GETs. You could screw around with the verbs and stuff and make them inherently much less secure just by behaving like that as a programmer. And there's no standard in place that's going to be like, no, you can't do that. Like, you could do whatever you want. So people sometimes, I think, maybe aren't as strict with themselves on API development as they are on web development. There's more standards around what goes in a PUT and what goes in a POST and what goes in a GET than there is necessarily in an API. And then there's all these API definitions and you can just do what you want there. So you could sort of like, that's what Pixie is. It's a really poorly designed API. And the definition, it looks great. It's got all these colors and it uses Swagger's GUI and everything. But if you dig into the surface, you're like, wait, why are you deleting things on GETs? That doesn't even make sense. That means you could do a CSRF on that, right? So, and a CSRF is cross-site request forgery, right? So that's where you sort of convince someone to click a link, and because if they're logged in, they'll actually execute the action behind the link. So, you know, I mean, there's a full suite of things that, you know, you could do on an API that are overlooked. Those are probably the top, maybe. I mean, Tanya, what do you think? There might be some more?

**14:35** No, I totally agree. You even said some I hadn't thought of.

**14:39** And you mentioned the term scrape an API. What does that mean? Kind of give me a little bit more detail on that. I'm curious.

**14:50 Chris Romeo:** Well, I think I meant, like, yeah, you could have a web page that really only exists because it calls other people's APIs. So it's just like a web page that displays the contents of other people's API calls, so the responses. So let's just say I have a web page, and it's serving up some content. And all of a sudden, 10 million people hit it because it's got some juicy video. But all that's doing is calling other APIs. And those other APIs get called that much at an increased rate. So you would then be abusing an API. Reddit has an API that's freely available. You could just put .json at the end of any Reddit or subreddit, and you'll see all the actual content in JSON notation. So you could just parse that on your own web page and be like, all right, I'm going to show Reddit content here. But given enough action and enough requests, you might be abusing that API. So that's sort of what I mean by scraping other people's data, scraping it through the API.

**15:43** OK.

**15:44** Okay. So let's—

**15:45 Chris Romeo:** You're not really scraping it because it's kind of well-formed, but yeah, sort of.

**15:49** Okay. So you have tools and things then that you can use to kind of explore somebody's API. So Tanya kind of started the conversation, and when we talked about threats here, saying that some people have kind of a security by obscurity type of thought process, like we can hide behind the API because no one will ever find it. So are there tools and things then that'll help you to figure out— that'll go through and figure out what all the different potential API calls are that exist?

**16:17** Yeah. If you use a web proxy, so, like, let's say there's a mobile app. So, it's on my phone. So, I set up a web proxy in between my phone and where it's going to, right? So, I run the application on my phone and then the web proxy shows me everything that it's calling. And I'm like, oh, look at all these little services that it's calling. I'm going to go look at them. And then I can use, for Burp has all these fantastic plugins. Zap has a bunch of plugins too where you can go and like it'll parse the API for you really nicely and then it'll make default requests for you and then you can start calling it and talking to it. Soap UI is really good for that too. And it's, yeah, so you can basically immediately see it. If there's no front end that's calling it, you would have to scan and look for it. But yeah, there's like any web proxy. If there's a GUI frontend, you can get right in between there and see everything it's calling. Yeah.

**17:15 Chris Romeo:** And then once you see it, you probably want to do things to it, right? So it's like, then how do you interact with a web service or an API? So there's a few tools out there. Like, you can honestly just do this all through curl, but that's like really painful. And most people would be like, oh my God, I can't deal with that much command line or curl. But, you know, there's a tool like Postman or HTTP REST browser. There's all sorts of things out there that'll just basically allow you to construct HTTP calls however you want using all the different methods. It gives you all these different header fields. You can just make your own headers. You can do whatever you want. And tools like that are really good because they also crack open HTTP. And that's what it— if you have beginners listening right now and they really want to understand what's going on here, downloading Postman or any sort of HTTP I think it's HTTP RESTful Browser. I think that's what it's called. If you Google it, things will come up. And you sort of try to ask a bunch of popular websites what's going on. Use a GET. Maybe you'll try to log in, see what's going on. You'll really crack open what's going on under the hood with HTTP. You'll see all the headers going by. You'll see the expectations, response headers, request headers. You'll see cookies get set. You'll see all the verbs that are being used. It's really a great way to kind of see what's going on under the hood there. Yeah.

**18:33** So I totally forgot about Postman. I love Postman.

**18:37 Chris Romeo:** Yeah.

**18:37** Like, I would suggest the first thing you would do is you would start sending proper requests and talking to the API. And then once you figure out how it wants to be talked to, try talking to it the opposite way. Oh, this is a delete. Hmm. And you— hmm, let's see if I can do this from a GET. Like, and just switching things around, kind of doing negative use cases, like the opposite of the way you're supposed to use it. And you'd be surprised where you could get.

**19:04 Chris Romeo:** Yeah, that's a good point.

**19:06** Yeah.

**19:07 Chris Romeo:** And Postman, I think, is free. I mean, it is free, but I think there's some sort of paid model. I don't know how that works, but it is pretty free.

**19:13** I'm totally going to install it at work tomorrow.

**19:16** You mentioned a couple other ones too. You mentioned Burp and Zap.

**19:22** Yeah. Burp Suite has a pro version or a free version. ZAP is the OWASP Zed Attack Proxy, and they're both web proxy vulnerability scanners. So they can automatically scan web apps for security issues, but you can use them. They're super powerful tools with tons of plugins you can add for whatever specific thing you're looking for. And you can just crawl through something really intricately and send it requests and edit the requests and repeat it and automate things and just be as terrible as you ever want it to be. I'm a big fan of both of those.

**19:59** Yeah, I've used both too.

**20:06** They're—

**20:06** I mean, as you mentioned, Burp is free as well as you can pay. With the paid version, you get quite a few more things, but even the free version, you could do quite a bit. And Zap, I really love Zap. It's a great tool to do a lot of exploring, and it's available free from OWASP as well.

**20:22** Yeah.

**20:23 Chris Romeo:** And we've been working with them to try to get— they just built in a ZAP API scanner. So we're like, oh cool, it's pointing at Pixie. So it was pretty good. So we're like working with them to like, you know, give them better targets to like test their scanner against.

**20:37** So it's fun.

**20:39 Chris Romeo:** Projects overlap.

**20:40** Yeah, definitely.

**20:41** So let's transition and talk some about the actual vulnerable application thing now. And so, I've heard you've kind of talked about DevSlop and Pixie, and you kind of mentioned it a couple of times, but let's maybe give us just a quick kind of summary of what is DevSlop and what was your motivation behind it?

**21:04** So, DevSlop is going to be the overall project.

**21:08** Okay.

**21:09** And it's going to be a jungle gym for hackers to learn on. And we wanna have lots of modern, new, different types of web application and web issues that can exist, like especially DevOps-related things, and let people learn on them. And then Pixie is the first release of things we're releasing. So, I'm gonna let Nicole explain Pixie, but our plan is to just release a new thing at basically like when we see terrible things at work.

**21:43** Yeah.

**21:43** then we are going to change them so that the victims cannot be revealed. But like change them and then like plug them in. So for instance, like I really want to like store our keys to something in our GitHub repository so that people will come get them, like something like that. So it's like things that we've seen where we're like, oh no, we just want to like make all of those part of DevSlop over time to help people learn. Do you want to tell them about Pixie?

**22:12 Chris Romeo:** Yeah, yeah, totally. So yeah, I mean, hopefully DevStop will be a bunch of apps, right? That's sort of the goal. And Pixie is its first little app. And it's basically like this photo sharing website that you can like a photo and give it like a heart, kind of like, you know, all the sites we know of today. Or you could love it and give it like a little bit of Bitcoin, like a micropayment in Bitcoin. So it's sort of like this little play there. But it's, you know, it's vulnerable. It's got a bunch of really like horrible things under the hood, but it looks cool, right? It's using like the latest and greatest, so it kind of looks cool. It's built in like Mongo Express, Angular, Node, so it's got some vulnerabilities inherent to that exact MEAN stack. Lately I've been messing around with like writing a pure HTTP/2.0 app because, you know, there's a lot of proxies out there and a lot of different testing tools out there that really don't know how to like deal with HTTP/2.0, so I've been like teaching myself the new spec here and like trying to write an app that maybe we could use to like test and train on that. So, I think, like, you know, just as Tanya said, as we see trends and, like, paradigm shifts in the development industry that is, like, you know, becoming more microservice-oriented, or, you know, maybe HTTP/2.0 is going to become a thing, you know, like, as we see these trends happening, what we want to do is, like, really showcase them with, like, a vulnerable app that people could, like, look at and test on. So, that's sort of what DevSlap is supposed to be. So, like, yeah, like, as Tanya mentioned, people, like, git commit PEM keys and all sorts of other keys, right? So, like, yeah, like, we're gonna build in, like, the— that's that sort of stuff. But we kind of want to make them more, like, app-focused things where it's, like, these little apps that you can test on and, like, understand, all right, this is an HTTP/2.0 app, this is a, you know, a web of microservices that no one really understands, this is, like, all sorts of other things that can go on. So, you know, we're in the market for ideas. So, you know, we only see our slice of the world. So anybody out there that has a really great idea for, like, uh, you know, a fun dev slop app, we'd love to hear from you.

**24:05** I think it'd be really fun too. Like, Pixie's in a container. I think it'd be really fun if eventually we had different containers and the containers could work together, work separately. And obviously we need a terribly vulnerable container. And I think the OWASP mobile guys were— they have a vulnerable mobile app. I think it's Mobile Goat. And they were talking about possibly like figuring out a way that they could call the Pixie APIs. Like, I think it could be fun if like different things call call each other and stuff. Like, there's a lot of opportunity to do cool stuff.

**24:37** An entire vulnerable universe of all these different applications that exist. So, if I'm a— so, as a user, if I want to, uh, if I want to install this, what, what does that look like? What am I actually installing? Where am I going to get this? And how am I, how am I getting to the point where I can actually start testing my own copy of Pixie?

**24:57 Chris Romeo:** Yeah, totally. So, um, we're gonna merge the entire code base in OWASP's GitHub repo. I think that's like pending. We got to figure out how to actually do that, but that's where it's going to eventually live. But right now, there's a GitHub file.

**25:12** It is—

**25:13 Chris Romeo:** I'm going to bomb this URL, but it's my GitHub, thedeadrobots/pixie.git. I think that's it. I will double-check that right now. And you could just pull that Git file, and it's pulling a Docker Compose file, so it's like 4 lines of YAML. And what that will do is pull down 3 Docker containers and Docker run those Docker containers and you have Pixie, localhost:8000, and the API is on 8090.

**25:38** We actually created a video. Well, and by that I mean, like, we did a talk and someone recorded it. And we explain, like, all of this in the talk. And if you want, we could send you the link and you could put it in the show notes so that people could just get it. And we can give you the links to all of this and the instructions of how to run it. If you want.

**26:01** Yeah, I think that'd be great. I think our listeners would love to be able to do a kind of a deeper dive and listen to even a longer version of kind of what we're talking about now. So that sounds like a great idea.

**26:11 Chris Romeo:** Yeah, totally. And Pixie right now is a pretty good list of vulnerabilities, but I'm trying actively right now to build out this CTF mode. And this is totally inspired by Juice Shop, which is another OWASP project.

**26:23** It's very cool.

**26:24 Chris Romeo:** Yeah. And he wrote a CTF mode where you could basically spin it up and like it's in, you know, CTF ready. So if you solve all these challenges, there's like a scoreboard page that'll show you how far you've gotten. So I feel like that makes it more engaging and people are more likely to be like, oh cool, I, you know, I actually want to use this rather than, all right, I downloaded it, now what? So, um, but you know, that's a little bit of development time, so it's coming.

**26:47** Just for people who are new, a CTF is a capture the flag contest, which is a thing that hackers like to do all the time. It's basically a contest where you go and you solve security puzzles or like you hack into things. And as you get further and further, you get flags, which means points, and whoever gets the most points wins. So it's kind of like gamifying the idea of learning. It's pretty fun. Yeah.

**27:16** Now, like you mentioned, the juice shop, I really like that as well. So there's going to be some integration, you think, with that as well? with some of the work that you're doing, or do you know?

**27:24** We don't have any planned at this moment, but I'm certainly not against the idea.

**27:29 Chris Romeo:** Yeah, Bjorn's great. I mean, we, you know, we've talked about this a bunch of times, like just the need for more vulnerable software out there. I mean, there's vendors out there that are selling all sorts of things, right? So these vendors need to be like held accountable by like finding, you know, vulnerabilities in a lot of this vulnerable code, right? So there's that aspect of it, which I think is a great part of what OWASP is doing. So, I hope that Pixie heads there. I would love—

**27:55** sorry, I would love to see a tool that could actually scan Pixie and pick up like even half of the vulnerabilities. Like, you have to find a lot of them manually and like—

**28:06 Chris Romeo:** Right, but that's the thing with web security. Like, isn't it always gonna be a manual game? I mean, maybe in a future perfect world that it won't be, but I think it will be.

**28:15** I'm hoping that tools like Pixie, though, can help vulnerability scanner companies write better tools, though. If they could even pick up just 10% more things, everyone wins, right?

**28:26** And that's the OWASP benchmarking project has done that for static analysis. So there's certainly a need in the industry to have some type of a tool that can become kind of that benchmark for the vulnerability scanning world. And it sounds like Pixie could provide some of that maybe in the future, uh, as, as you kind of develop more pieces.

**28:49** Definitely.

**28:52** So is there competition? I mean, so like, is there, is there competition between like WebGoat and Juice Shop and Pixie and what's going on here? I mean, is this— are you competing for the same kind of, I guess, mindshare within OWASP? Or do you see this as a competition? Or Do you see this as, this is kind of everybody working together to try and come up with the best solution?

**29:15** Well, we don't get paid, so I don't really see that we're competing.

**29:21 Chris Romeo:** It's true. No, I mean, we all sort of know each other. You know, we go to OS events and no, I think there's a lot of like sentiment around like the world is better when these things exist. So you have these referenceable ways to test software and to like teach people. So, I think no. I mean, I haven't experienced it.

**29:39** Yeah. I actually use both of those tools to learn, right? Like, I took a training course using WebGoat like a few months ago and it was awesome, right? So, like, yeah, I want them to keep making it better and better so I can keep using it.

**29:55 Chris Romeo:** Totally.

**29:57** Yeah. I mean, the learning through experience, I think you've tapped into an area here that is really a great way to reach developers. What I found in my travels is that, you know, we can— there are some things that we can teach developers that are factual, but then there are other things that developers really just need to put their hands on and they need to experience it. And you can tell them all day long about SQL injection, but when they actually take advantage of a SQL injection vulnerability in an application something about their eyes just light up a little bit more and they just, they just really start to get it. So I think what you're doing here from the, from this type of a project is it's really a great way to bring that, that experience-based learning, uh, even further into the world of OWASP.

**30:44** I would strongly encourage every developer ever to go to a capture the flag. Like, try to find a beginner one and a webby one if you're a web developer. It's so fun. I've learned so much. I went to one this winter and I made an all-female team because I didn't want to be the only woman there. And like, I was showing all my developer friends like, this is how you circumvent JavaScript validation and this is how you do this. I'm like, now you're the admin, let's— and all of them were like, I'm never going to make these mistakes ever again. And now they all joined OWASP. A lot of the OWASP chapters have capture the flag contests at their chapters and they're free. So that's pretty cool.

**31:31 Chris Romeo:** Yeah, totally. Or security meetups. Sometimes they show up there too.

**31:35** Yeah.

**31:36** Yeah, meetups and also conferences. I know there's several regional OWASP conferences that usually have a capture the flag during the day for the conference.

**31:44 Chris Romeo:** Yeah, my old project ran one in 2013. So it was fun.

**31:51** Yeah, my chapter runs one every year. This year will be the 4th year. It's super exciting.

**31:55** So at the— Robert and I have been talking about AppSec USA for the last couple of episodes, but you're both going to be doing something pretty exciting at AppSec USA, right? Why don't you share with the audience a little bit about if they were to come to AppSec USA, and track you down, what might they be able to participate in?

**32:19** Okay. So, we're part of the Developer Summit. Okay. So, what a lot of people don't know, it's like the world's best-kept secret, is that if you show up 2 days early for AppSec USA, there's the Developer Summit, and it's free. So, on the Tuesday before the conference formally starts, we're going to give a 3-hour workshop where we're going to show off DevSwap and have everyone hack 6 along with that. Did I mention it's free?

**32:47** Yeah, it sounds like a great opportunity for folks that are there to get a hands-on experience in how Pixie actually works. And I'm guessing you're going to teach some lessons about API security as well, right?

**33:06** Definitely.

**33:08 Chris Romeo:** Yeah. Yep, we're trying to make it as interactive as possible, so hopefully everyone gets something out of this.

**33:16** So if you're listening, bring a laptop and make sure you have admin privileges because we're going to want you to install stuff.

**33:25** That's very cool. Well, hey, uh, Tanya and Nicole, thank you so much for all that you're doing in the world of OWASP here, both as chapter leaders and and leading projects and building new tools and things. I can say that, you know, this is— I see this as a project that's gonna have a lot of impact across the industry. And so we thank you for doing that. We thank you for being with us here today. And we hope that you'll have a room full of people at AppSecUSA, some of them that listen to the Application Security Podcast.

**33:57** Awesome. Thank you. Awesome.

**34:00 Chris Romeo:** Thank you. Thanks so much for having us.

**34:02** Thanks for listening to the Application Security Podcast. Our intro music is 8-Bit Kung Fu by Boring and TJ, and the outro is Southern Delight by Stefan Kartenberg. You can find us on Twitter @appsecpodcast or on the web at www.appsecpodcast.org.

---

Source: https://appsecpodcast.com/tanya-janca-and-nicole-becher-hacking-apis-and-web-services-with-devslop/