---
title: "John Melton -- #OWASP AppSensor"
url: https://appsecpodcast.com/john-melton-owasp-appsensor/
date: 2018-04-20
duration_seconds: 1829
guests: ["John Melton"]
topics: ["OWASP Projects"]
audio: https://www.buzzsprout.com/1730684/episodes/8122686-john-melton-owasp-appsensor.mp3
transcript: true
---

# John Melton -- #OWASP AppSensor

*April 20, 2018 · 30 min*

with [John Melton](https://appsecpodcast.com/guests/john-melton/)

on [OWASP Projects](https://appsecpodcast.com/topics/owasp-projects/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8122686-john-melton-owasp-appsensor.mp3)

## Show notes

Your application knows when a user does something that should be impossible, but does that knowledge help stop an attack? John Melton explains OWASP AppSensor, a project that combines guidance with an implementation for detecting and responding to suspicious behavior inside applications. Using examples such as access to another customer’s bank account and unexpected jumps through a workflow, he shows how business context can reveal attacks that generic defenses miss. John describes detection points, event thresholds, response options, and integrations that connect applications to an AppSensor server. He also distinguishes the approach from conventional runtime protection tools and explains why threat modeling helps teams choose meaningful events. His practical starting point is a small proof of concept, built on centralized logging and tuned with real observations.

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 John Melton:  
→ [John Melton on GitHub](https://github.com/jtmelton)  
→ [AppSensor source code](https://github.com/jtmelton/appsensor)

Mentioned in this episode:  
→ [OWASP AppSensor](https://owasp.org/www-project-appsensor/)  
→ [Spring Security](https://spring.io/projects/spring-security/)  
→ [ModSecurity](https://owasp.org/www-project-modsecurity/)

Chapters:  
00:00 Building self-defending applications with AppSensor  
04:40 What AppSensor is  
07:03 Bank-account access as a detection example  
09:13 Turning suspicious events into attack signals  
11:07 Choosing a response to detected attacks  
12:13 Server architecture and integration options  
15:35 Supporting applications beyond Java  
18:05 How AppSensor differs from RASP  
22:03 Rules and event thresholds  
24:01 Using threat modeling to choose detection points  
25:49 Combining conditions with Boolean rules  
26:43 Getting started with a small proof of concept

## Transcript

*5,111 words · assemblyai*

**0:00 Chris Romeo:** Hey folks, season 3, episode 15 of the AppSec Podcast brings us to an OWASP project entitled AppSensor. Chris speaks with John Melton about what AppSensor is and how it can be used in your application. We hope you enjoy.

**0:13 John Melton:** The Application Security Podcast. Here we go. Hey folks, welcome to this episode of the Application Security Podcast. On this episode, I am flying solo and I'm joined by John Melton. And John is somebody who is very involved in the OWASP AppSensor project. And I realized as I was looking at the OWASP AppSensor project website, I have no idea what this thing does. So I invited John on here to try and enlighten me, and thinking if he can enlighten me, perhaps he can enlighten you. But, uh, so John, welcome. We always start with what's your security origin story? How did you get into the world of security?

**1:20 Chris Romeo:** Sure, thanks, Chris. Um, yeah, so I originally went to school, um, to be— to be a developer. That's what I thought I was going to be. That was my intention. And just as I was finishing up school, the dot-com bubble burst. So that changed my plans a little. I had a job lined up and everything, and that job went away because the company went away. And I happened to be taking security as an elective in undergrad, and there, there was this program which still exists for those interested. called SFS, Scholarship for Service. So the government essentially pays— the US government pays students to go to school, and the return on that is you get free school and then you get a guaranteed job when you come out of school, but you have to work for them for some amount of time. So that's how I got into learning about security. And then I went and worked for the government for a few years and then just kind of meandered. I went back to pure development work.

**2:24** Okay.

**2:26 Chris Romeo:** but I was kind of the security guy in our group, and then I switched over to pure security work, and I've kind of threaded that needle hanging out in between development and security for the best part of my career. That's kind of the niche where I sit and where I feel comfortable. So that's pretty much how I got started.

**2:46 John Melton:** Yeah, that's great to hear, and that's a good reminder for folks that are perhaps in college or looking at college now. That sounds like a really awesome program. Guaranteed job and they pay for school. And then you get that, you get that experience that'll kind of take you to, to that second job and on into your career. So now I gotta ask this, I'm just really curious. So you said you took security as an elective.

**3:10 Chris Romeo:** Yep.

**3:10 John Melton:** What did they teach you? I'm gonna guess you and I are probably about the same age, probably in the same ballpark. So I'm just, I'm dying to know what they taught you at that point as an elective in security.

**3:21 Chris Romeo:** Yeah, it was, uh, the, the person who taught it was a cryptographer, um, and he was actually fairly well-known, highly ranked cryptographer. Um, and so we, we essentially, if memory serves, the midterm was writing out, um, a certain number of rounds of DES on paper, uh, with pencil and paper. So that was, that was kind of the, the world it was. There was a high-level introduction to, you know, I came out of the class Hearing the words, you know, the CIA Triad, I had that in my tool belt, and then I knew a bunch of arcane facts about certain cryptographic primitives, but there was not much applied security in any way, shape, or form.

**4:02 John Melton:** Okay, yeah, and there wasn't a lot of applied security at that point, other than deep inside the walls of the government. But isn't it funny how everything always starts and finishes with the CIA Triad?

**4:13 Chris Romeo:** Yeah, yeah, exactly.

**4:15 John Melton:** We can't get rid of that thing, but I was telling a class, I was teaching a class a week or two ago, and I was like, Okay, I, you know, I'm gonna introduce this concept to you. You already know it all the way. And but just remember, when in doubt, you can always fall back on this concept. If somebody is saying, that's stupid, I don't have to do it, you can always fall back on one of those sides of the triangle and go, well, you know what, if you don't do that, here's what's gonna happen. And I told you.

**4:40 Chris Romeo:** Yep.

**4:40 John Melton:** So good old CIA triad. Should make a— there's got to be a t-shirt with it on it. If not, we should create one here at the podcast and and sell that. So, all right, let's talk about AppSensor. So let's, let's dive right in and just, just tell me, tell me, what is AppSensor?

**4:55 Chris Romeo:** Sure. So that, that turns out to be one of the, uh, one of the more difficult questions, uh, to answer for most people. So AppSensor is a project with OWASP, the Open Web Application Security Project, and it is It's an odd project in that it essentially has 2 components. Most projects within OWASP are one thing, right? They are a tool or they're a documentation effort or, you know, something along those lines. So this one turns out to be 2 things. This one is a documentation effort and it's also a reference implementation of that idea, right? So I like to generally tell people The idea is the most important thing. Even though I'm the one that works on the tool primarily, the idea is the most important thing, and then there's a reference implementation. The idea is essentially, it's trying to bring the operational aspect of security back into the application security realm. Most application developers, their familiarity with security probably does not extend much beyond the OWASP Top 10, if at all.

**6:13 John Melton:** Yeah.

**6:14 Chris Romeo:** However, there's a whole bunch of things that they naturally do as part of software development that they understand very well, right? Exception handling is something that everybody has to do. Building functional requirements out into your systems is something that they understand very well. In most Agile shops at least, we have this concept of use cases. In many shops, there's also this idea of abuse cases. How could somebody abuse the systems? That's really the sweet spot for AppSensor. The notion is, if I'm doing something in the system, I've built this happy path through my system, which is how I expect users to use the system. Well, there's always the the attacker route, right? There's always the path that is less traveled, right?

**7:03 John Melton:** Yeah.

**7:03 Chris Romeo:** Somebody, either a benign end user accidentally goes down the wrong route or an attacker purposefully goes down the wrong route. Either way, there actually turns out to be a lot of things that we could prevent if we just thought about those exceptions and handled them appropriately. So the canonical example I always give is, Let's say you're building a banking application, right? You log into online banking and you see your checking account and your savings account, and maybe you have, you know, a money market account or something. You have a few accounts and you get that master list. Well, if I go and click into my checking account to see more detail, logically what's going on behind the scenes is I'm clicking on something, the application presented me with 3 accounts, and those are identified by individual some form of an identifier. It may be a database key, it may be a GUID, something like that. I click on that and it takes me to more detail. Well, that's an access control issue, right?

**8:06 John Melton:** Mm-hmm.

**8:06 Chris Romeo:** I have to go in and view that data. In order to view that data, I need to have access. So when I view my master account, the system is presenting that data. When I go into view detail around that one record, I am telling the system I want to view this particular piece of data, and so that's a classic indirect object reference bug where people forget to do that access control and they assume that if you've asked me for something, I'm going to hand it back to you. It's a select from database where this is the ID, and that can get you into trouble.

**8:38** Yeah.

**8:38 Chris Romeo:** Well, hopefully most banking systems now prevent that. They do an access control check and they— what do they do? If it's happy path, they'll let you see your data. If it's not happy path, what do you do as a developer? You might log something, you might send an exception to the end user that says you don't have access. AppSensor says go one step further. Send that exception, just say, hey, something strange happened here. The end user did this and they did this activity that they shouldn't have done.

**9:13 John Melton:** Right.

**9:13 Chris Romeo:** And that data, gets sent off. You could think of it as kind of this centralized logging system. It gets sent to this system, and I'll talk a little more about what that system is in a second, but it kind of shunts it off to the side. You can think of hundreds probably of examples of different cases where, okay, maybe you're building a wizard and somebody jumps to step 4 instead of going 1, 2, 3, 4. You could think of forced browsing where people are trying to find well-known paths on your system. Lots of things that attackers do or that accidental end users do. All of that data is going to get fed. If you think about it, all that data from your system is now going to get fed into this separate system. What that system is doing, what the core of AppSensor is doing is it's basically keeping track of that data, it's storing it, and it allows you to apply rules to those what we call events that are coming into the system. And you can then specify, okay, if somebody, if an end user sends me 10 of this type of event, if the system notifies me that an end user has done 10 of these things in 5 minutes, I'm going to assume that that's no longer accidental, that's purposeful. So now I've got a rule somewhere in my system that says if I have 10 of these events in 5 minutes by the same end user, I am going to do this thing now, right? And so it— AppSensor has 3 core components: events, attacks, and responses. Events are suspicious things, right? They may or may not be real events. They may be accidental or, you know, whatever. Attacks are— I've determined that this series of events now has— I have a rule somewhere that says this series of events, I'm now going to view them as an attack.

**11:06 John Melton:** Okay.

**11:07 Chris Romeo:** And that attack, you then have options for what kind of responses you can make. So you could maybe, you know, email someone, you could page somebody, you could do things like block the end user, you could lock their account or log them out, you could, you know, slow down traffic. And so we have a significant amount of types of events you might want to look for. responses you might want to do, and those are all listed as part of the documentation effort, and then the reference implementation builds out some of those. But that's the core of AppSensor. I want to use the business knowledge around my system to detect fundamental usage that is not in normal behavior for the system. AppSensor tends to look— a lot of people, if you squint your eye, you might see it as like a fraud detection system.

**12:02 John Melton:** Okay.

**12:02 Chris Romeo:** But it doesn't come with those sets of canned rules. It's a generic system for detecting behavioral abnormalities and then being able to respond to them.

**12:13 John Melton:** So on the response side, you're still inside the application, though. So you're not— so when you're blocking the end user, so you don't— do you have the ability to block out to, like, your Apache web server or something and say, just block all traffic from this IP address, or is this still happening within the application itself?

**12:32 Chris Romeo:** Sure. So there are options essentially. So AppSensor itself is a separate standalone component. There's something we call the AppSensor server, and then you can have any number of clients to that server. The server can be set up to be spoken to over a number of different integration points. You know, there's a REST API, SOAP API, there's message queuing capabilities, there's a number of different to talk to it. Then there's essentially integration points. We don't out of the box provide a ton of integration points. The main one that I've tried to focus on is Spring Security because it is so prevalent within the people that end up using our application. Spring Security is fairly popular and it's an easy way to integrate. Ryan Barnett, who I believe is at Akamai now, back when he was at Trustwave, he was responsible for mod_security_waf, And so he did some work to integrate AppSensor there, and there's blog posts that are public about that. So if you dig a little, you could find it. But essentially, he did what you're asking, right? Like, so he took the responses out of AppSensor and plugged them back in as rules into his WAF and was able to block them at the edge. We have a project called the AppSensor— I think it's reverse proxy— and it's a small little Go layer that will let you do that type of thing. Just to be honest, there is always a little bit of integration work in pulling that in, but it is possible and we do have people that use it in that way. You can even— another thing that he did was the things that you might want to send to AppSensor are often, at least the way we discuss them are often in the application. So you're sitting inside the application layer and you want to refer to those, you know, you want to get that level of knowledge out. But there may be things that you want to detect that your WAF can do for you, right?

**14:38 John Melton:** Yeah.

**14:39 Chris Romeo:** So why not put that up at that layer? So he also did an integration there. Again, the reverse proxy has a few implementations there of what we call detection points, the notion being this is something that I want to detect and respond to. So the reverse proxy itself has some of those canned and built in, but you could easily write those rules into your WAF if you so decided, or into your Apache or NGINX if you desired. And then you might even, for instance, for him, for the WAF, they could do everything inline there and they could collect that data. So he wasn't actually sending me events, he was sending me attacks. So the WAF had determined it was an attack and he just would send the attack as opposed to sending all the individual events. So you have some options there for integration, and we have people who use the project in a number of different ways. It is pretty flexible, but you pay a little bit for that flexibility with some integration effort.

**15:35 John Melton:** Yeah. So you mentioned Spring, so that leads me to thinking this is Java. Is this only for Java? What about .NET and some of the other languages? Am I tied to only Java platform, or what can I work with?

**15:50 Chris Romeo:** Right. So I'm going to give you a 30-second history because it's somewhat relevant and we do have people ask this question a lot. There was a— at one point in time, there was an AppSensor version 1. AppSensor version 1 was when I first started on the project. Michael Coates, the founder of the project, pulled me in fairly early, and AppSensor version 1 was actually a drop-in replacement for the intrusion detector component in ESAPI. So ESAPI had a built-in intrusion detector, and AppSensor in its first incarnation was a drop-in replacement for that, meaning that yes, you were restricted to Java and you had to be using ESAPI in order to use AppSensor. That is no longer the case and has not been the case for several years, although people still for some reason think that's true. AppSensor version 2, which is the only supported version and has been for 3 or 4 years now, it is written in Java, but it's a separate component to the application. You can talk to AppSensor using anything that you want to. We have a couple of clients that we have generated for, I believe it's Python and maybe C# we have generated, or maybe Ruby. But it's fairly easy to generate a client if you want.

**17:12** Okay.

**17:12 Chris Romeo:** But the APIs that we expose are pretty minimal, so it's not too terribly difficult to integrate with any tool, you know, a couple days' effort to write the client. And so, and again, we have integrations of a number of different mechanisms from Thrift to, you know, there's the standard REST API, which is what most people end up— most people end up using either REST or Kafka. Those are our 2 integrations that get used the most heavily, but there's also MQ and RabbitMQ and, SOAP API and Thrift, and there's a number of them. So you have options, and if you, if you have an option that we don't support, we're always happy to accept pull requests or even, you know, work with you to get that support added if it, if it's needed.

**17:58 John Melton:** Okay.

**17:59 Chris Romeo:** That's how several of our integrations got written. Somebody came in and said, hey, we need this, and, and we went around and built that out.

**18:05 John Melton:** Okay, very cool. So now I'm going to ask you what I think is the million-dollar question here.

**18:10** Uh-huh.

**18:10 John Melton:** So, in application security now, we are the owners of 4-letter acronyms for all kinds of different tools. And you might know where I'm going here, but is there— does this thing, does this AppSensor thing fit into any of the nice, neat, orderly buckets we have in AppSec, meaning static application security testing, dynamic, interactive application security testing, Runtime application self-protection. I know it's not software composition analysis, but—

**18:41 Chris Romeo:** Right.

**18:42 John Melton:** Does it fit into one of these other 4 cleanly, messily, or not at all?

**18:47 Chris Romeo:** Um, slightly messily, I guess you would say. It is most closely aligned to runtime security protection. However, most RASP tools that I'm aware of whether vendor or any open-source ones I've ever heard of, they go in with the notion that I'm going to protect you from these canned sets of things, right?

**19:12 John Melton:** Yeah.

**19:13 Chris Romeo:** And that's the, the whole idea behind RASP is I'm preventing this set of things. AppSensor, you might think of as a generic RASP in that you get some of the same— you get some of the plumbing of RASP is probably the way to refer to it, and then you write the detections, right? But you're going to solve a different class of problems most likely. So we do have people who use the application who front their app— I'm sorry, use the tool, the library, who front their application with a commercial RASP, and then they come back and they do AppSensor in addition. And then the notion there is that you're going to solve a different class of problems. So RASPs are going to solve your They're going to aim to solve your XSS, your SQL injection, right? And while you could solve that problem with AppSensor if you wanted, AppSensor, its bread and butter is in business logic issues.

**20:12** Yeah.

**20:12 Chris Romeo:** So a RASP is going to have a very hard time determining from that original banking example I gave. They're going to have a very hard time determining that 1234 belongs to you and 1235 does not.

**20:24** Right?

**20:25 John Melton:** Yeah.

**20:25 Chris Romeo:** That's a hard, fundamentally hard problem to solve when you don't live in the application and you don't have access to the dataset. There's some companies that claim they can do that with learning and that kind of thing. I've never seen one that actually worked and I've baked a lot of them off. So, but AppSensor, you know, that idea is really simple there. You do have to do more work to include it in your application. It's not a turnkey. You set this in a pizza box right in front of your app, but you do get a lot of benefit from that. You can detect higher-level business process flows and deviations from those flows more effectively with AppSensor. That's what most of the people that are using the product, they are the same types, they're in the same verticals that are doing things like fraud detection, account abuse, those types of things. People who are doing these types of things. I'll briefly mention a— I guess you could mention as a side competitor to AppSensor, but we're both open source, so I don't view that as competition in any way, shape, or form. Aaron Bedra, when he was at Groupon, he wrote a tool called RepSheet, and it's kind of got some of the same notions, but he built it to solve a slightly different type of problem. So again, he was looking at— Groupon was trying to solve the carting problem on their site. And so you might use it for those types of problems too. So yeah, we— it's RASP-like, but it's more like you've got the plumbing for RASP and you kind of build the end detections.

**22:03 John Melton:** Okay, and so you have the— so you were talking about how there's the rules engine and the rules are going to translate the events into the attacks, which can then ultimately be responded to. How thorough is that rule? I mean, does that rule engine have things for like SQL injection and cross-site scripting that come out of the box at all, or is that not even something that's in the default?

**22:28 Chris Romeo:** No, there's no default canned rules. What the rule engine does— and there's kind of 2 pieces to the rule engine— the rule engine just basically says, you are going to notify me when an event comes up and you tag that event with an ID. All AppSensor really knows is you throw a bunch of metadata at AppSensor. A bit of that metadata is the timestamp when this event occurred, the ID of this event, and then you come in and write rules that say, if I see 30 ABC245 type events in 5 minutes, I'm going to respond in this way. AppSensor really is very generic in that it doesn't have canned implementations built except, like I said, for the caveat that the reverse proxy does implement a few of these out of the box and it does have the code that— but then there's the additional, I have to deploy a reverse proxy in front of my app. But the notion is that you would tag your events, And then you would write rules that are associated with those tags. And AppSensor just does the tracking on the backend and data storage and handles generating responses and that kind of thing. So—

**23:45 John Melton:** So that was the integration you were talking about.

**23:48 Chris Romeo:** Yes.

**23:48 John Melton:** So when somebody's going to spend some number of days deploying this thing, it's going to be figuring out what it— where are the potential rules—

**23:56 Chris Romeo:** Right.

**23:57 John Melton:** Where the potential events could fire that could result in something bad happening.

**24:01 Chris Romeo:** Yeah, and to what I know you've talked about a lot on here, threat modeling. This is where I get the most bang for the buck when I'm working with people on AppSensor, when we're doing it where I work. When we go through the threat modeling process, we look at events, and I mean, that's what threat modeling is, right? Like, we're looking for places where this might get abused. When you're doing design reviews, when you're doing architectural reviews, there's lots of There's lots of opportunities for baking this into your platform. And that's going to look a little different at every company, but there's lots of opportunities. Once you explain to developers, think about exceptional conditions in your code. I tend to tell developers, map your exceptions to possible App Sensor events. Some set of your exceptions are going to be App Sensor events, and that's a really easy mapping for them to do. when I hit an exception, is this something that security might care about? Yes or no? If yes, part of my exception, and you can, when you, you know, one thing we've had success with, we in the constructor of our exceptions, of our custom exceptions, we'll put AppSensor signaling in the constructor of our exception. So when you generate that exception, AppSensor is automatically notified. And that's something that now your architecture or design team can put in place and your developer just knows they're launching an exception and under the covers that's taken place. So yeah, there's some points in your code where you're going to want to have that happen, but that's really a conversation about your specific business application. That's where App Sensor causes more work but also generates more value.

**25:49** Right? Mm-hmm.

**25:49 Chris Romeo:** And then to clarify on the rule system, the original system we built was very straightforward, very static. It was, if you see X number of events in Y timeframe, then perform Z response. That was really the core of the system. We actually had a student come through and do this as part of his master's thesis, and he wrote a very, very significant amount of code to produce— his name was David Scribonia. He did an excellent job. He added support for Boolean logic in our rule system. So now you can compose these complex rules. If this is true and this one, but not that one, then I want to do this thing, right? So you can compose these rules kind of arbitrarily now, and AppSensor will still do that processing. So you can build some very, very interesting combinations and get pretty precise at this point.

**26:43 John Melton:** So I guess my final question then is, let's— for somebody who's brand new to this and they're just learning about AppSensor by listening to our conversation here, how do you recommend they get started? Because, I mean, this seems like it could be overwhelming if I tried to think about how I'm going to do all this stuff. What are a couple things somebody can do to just start with this process and kind of get into it and get a little feel for what's going to happen with AppSensor?

**27:09 Chris Romeo:** Sure. So we have, if you go to the AppSensor project in GitHub, there is a demo setup. So that's really easy. It's a few Docker containers you spin up, and that'll give you a little UI to play with, and you can kind of see the type of data we're talking about generating. That'll make it a little more concrete, and that's, you know, a few minutes worth of work. Beyond that, I think most of the people that come and ask about AppSensor or use AppSensor that I've interacted with, they've already gone down the path of centralized logging.

**27:42 John Melton:** Got it.

**27:42 Chris Romeo:** So if you're doing that, you may be ready for AppSensor. If you're not doing that, I would probably aim more towards start there and then move beyond that. Then I think setting up AppSensor, do it as a proof of concept and then add one exception and see what data you generate. Look for the obvious thing. Look for the thing in your application that is obvious and then do it in your test environment and let your testers kind of bang on it and see what happens. It'll generate some data, and most people initially write their rules, and then there's some tuning that goes on, right? They kind of go, oh, I thought it would have been this way. We had a lot of that. We had people who thought, well, we're going to see this for 10 minutes, and they, you know, 10 times in a minute, and they saw it 500 times in a minute, or, you know, whatever. It's usually frightening to developers. So I would say, you know, Try out one thing, try out 2 things, you get benefit from that. And then don't try to do responses is the last thing I would say first. Don't try to do complex responses. Do logging responses, do notifications, and start reviewing your logs and seeing what kind of data you're getting before you try to go in and block users and do that kind of thing. Just start with— log and, and go read your logs. And, and I think, you know, most of the people that I've talked to who are using the system, they have learned a tremendous amount about how their system operates in production, and it's given them a lot of data. So even if you never turn on responses, you can learn and characterize your system better and understand how people are using and abusing your system.

**29:24 John Melton:** Yeah, awesome. Well, John, thanks for taking the time to explain this to me. And to our entire listening audience, I think this is going to give folks a good idea of what AppSensor is and how they could use it, and my hope is that some people are going to go out, download this thing, integrate it, and start applying it into their application space. So, once again, thank you very much for your time.

**29:45 Chris Romeo:** Yeah, thank you, Chris. I appreciate it.

**29:47** Thanks for listening to the Application Security Podcast. If you enjoy the podcast, please do us a favor and visit the iTunes Store and give us a 5-star rating. Our intro music is 8-Bit Kung Fu by Born and TJ, and the outro is Southern Delight by Stefan Cartenberg. You can find us on Twitter @AppSecPodcast or on the web at www.appsecpodcast.org.

---

Source: https://appsecpodcast.com/john-melton-owasp-appsensor/