Adam and Christian join this week's panelist episode to talk about "Web Security". Christian takes the lead as he explains he gives a brief overview of Web application Security and some ways how to secure your applications. He explains the OWASP Top Ten Web Application Security Risks and talks about each of its categories in detail. 

Adam Furmanek:

Hello everybody and welcome to this week's episode of Adventures in.NET. My name is Adam Furmanek and today it's Christian Wentz with me and

 

Christian Wenz:

Hi,

 

Adam Furmanek:

we

 

Christian Wenz:

Adam.

 

Adam Furmanek:

are going to have a panelist discussion just for the two of us. So welcome again and Christian brought today an article and a very interesting topic. So Christian, would you give us some understanding what you brought and why you find it very nice to discuss?

 

Christian Wenz:

Oh, absolutely. Thanks, Adam. So as probably many of you know, security or web security is one of my main topics. I once was a guest on that very topic, actually, with regards to ASP.NET Core on this show. And one of the most well-known, let's say, awareness documents for web application security is the OWASP Top 10. It's a list of the 10 top security risks for web applications curated by the Open Web Application Security Project, OWASP, homepage owasp.org, which is a non-for-profit organization or registers as such. It has a wealth of information, lots of documentation. How do I prevent attack acts with stack Y? cheat sheets, verification standards, also software, dynamic web application scanner, which can find some security vulnerabilities, web applications that have intentional security vulnerabilities, so they can be used to train some pen testing, and much more. Also, a couple of top 10 lists actually and the best known one is the OWASP top 10. I think it started in 2003 and the OWASP itself started in 2001. And then at the beginning, they had a new top 10 list every year, but assembling that list and have it kind of predictable and make it database was quite an effort. So what they actually did was that they then went to a three-year cadence. did not make that the last two times. So we know at a four year cadence, and the most recent version of that list is the 2021 OS 4.10. But before you switch to another show, hear me out. That list, I mean, super, super important, right? But there are other top 10 lists as well. And they are not as famous, right? They're a little bit underneath the radar. So for instance, there's this. one top 10 related to Docker, for instance, right? All super interesting. And of course, with all of those lists, so maybe let me put that first. With all of those lists, they are awareness lists, right? If there are 10 items on the list and you have a limited amount of time, you can't just say, OK, I do one through seven, right? Because they are just much more important. Based on the data and, of course, on the bias of those delivering the data and maybe also the bias of those compiling the list, Yeah, to them, one through seven might be the most important ones, but for you or for your applications or for your stack or for the way you are doing web software, it might be entirely different, right? So it's an awareness document. It's not a list of top 10 attacks. It's a list of risks. And some of them come directly from attacks. Some of them are more conceptual. For instance, in that current OWESP top 10, one item is insecure design, right? Which I mean, yeah, it's a risk. I get that. It's not so actionable as some of the others, which are more tied to specific attacks. But anyway, so it's an awareness document. So take everything with a grain of salt. And as I

 

Adam Furmanek:

That

 

Christian Wenz:

mentioned,

 

Adam Furmanek:

sounds

 

Christian Wenz:

the

 

Adam Furmanek:

really cool. One question I'd like to ask here initially, like you mentioned all those lists and the tooling and they are very old, but the one thing which I always find interesting is how can I actually apply that list directly in the code? Are there any ways?

 

Christian Wenz:

It's not like a how to fix your application list. Because I mean, the problem, maybe if you take a 10,000 feature, the problem with security is you don't see an absence of it. It's like brushing your teeth. So while we're recording this, we are seeing each other, but we're not in the same room. And I mean, I have no idea whether you are brushing your teeth today and vice versa. I have a hunch, but you know.

 

Adam Furmanek:

Very good

 

Christian Wenz:

So

 

Adam Furmanek:

metaphor.

 

Christian Wenz:

we just don't see it. But the absence of security or the absence of brushing your teeth is not obvious unless it's too late. So I leave it up to your imagination what happens if you don't brush your teeth for a year. But if there is no security in the web application, one way to find that out is if someone hacks it. And so that's a little bit of the problem. And that's why awareness is key. You have to protect against things that are not there yet kinds of attacks that have not really been invented yet. So you always

 

Adam Furmanek:

Mm-hmm.

 

Christian Wenz:

have to have a very defensive approach to the way you build your software. And that awareness list kind of makes you aware of risks that can happen. Now, with that given, still for each entry in the, say, OVS Totem, for instance, there are more or less precise examples of typical... occurrences of that risk or typical aspects. How could this risk materialize in your applications? Of course, then you might have countermeasures against it. That is the case at least for some of the aspects. But I have to rephrase that. What I often find is that security is reactive. You do something because someone found something, but it would be much better of course if you are in the driver's seat, right? And you start putting security in your applications, right? From the very, very start,

 

Adam Furmanek:

So

 

Christian Wenz:

yeah.

 

Adam Furmanek:

that sounds like a never-ending story, right?

 

Christian Wenz:

Of course.

 

Adam Furmanek:

It's not that you check it out once when starting your project, you need to refresh that periodically because the world changes, right?

 

Christian Wenz:

Absolutely, absolutely. I mean,

 

Adam Furmanek:

catch

 

Christian Wenz:

their

 

Adam Furmanek:

ya.

 

Christian Wenz:

companies, I visit like every year, every two years, right? And then they still want awareness, awareness. People, you know, leave, new people come in. And I mean, not everyone is kind of responsible as in having, you know, the title of being whatever security engineer. But every engineer has to know enough about security to write solid and secure code. and maybe

 

Adam Furmanek:

at Sun School.

 

Christian Wenz:

supported by a security engineer.

 

Adam Furmanek:

That sounds cool. So before actually diving into the list you brought

 

Christian Wenz:

Yeah.

 

Adam Furmanek:

for us today, like one practical question I imagine, obviously we know there is like secure software supply chain, there is cybersecurity, obviously InfoSec and big corpse and

 

Christian Wenz:

Mm-hmm.

 

Adam Furmanek:

whatnot, but what is like the practical approach for like, let's say software engineers that really do the coding, still they would like to keep their applications safe and secure. How can they tackle this problem on some regular cadence so their applications do not rot, do not go insecure because of whatever?

 

Christian Wenz:

I think there are several ingredients, right? And depending on the size of the company or of the team, then more can be done or less can be done. So one aspect of course is just training, awareness, right? I mean, the risks for web applications, they are all the same no matter what kind of stack you're using. Although for instance, since we're here at Adventures in.NET, ASP.NET Core has some pretty solid protections some attacks. Still, that's not no excuse for not knowing about them, right? So you have to have that awareness. But still, the stack protects you. But the risks are the same. The countermeasures are specific. So being aware of the risks, knowing about technology-specific countermeasures is, of course, important. If you have someone responsible for security, like a security engineer that, I don't know, takes part in code reviews, takes part in design reviews, is always helpful. And of course, also testing your applications, either internally or externally on a regular basis. This all can help. And I mean, if you're a small team, then have a software that doesn't generate millions of dollars, then maybe you are less inclined to pay for a pen test. And if you do that, then maybe you are. So again, it really depends on the scenario. But I think these are kind of ingredients. Awareness, training. knowing how to write secure code and having someone on the team who wears the security hat and makes sure that security is part of the process, right? And not an afterthought, right? Like a patch you put on a flash round or something.

 

Adam Furmanek:

That sounds really good and I like it. Okay, so I imagine you brought a list with you for

 

Christian Wenz:

Right.

 

Adam Furmanek:

today's episode.

 

Christian Wenz:

Indeed, indeed. So as I mentioned, there are other top 10 lists. And there has been one that was released in 2019, if I'm not mistaken. But in May 2023, so not that long ago, they released a new version, the 2023 version. And it's the. OWASP API Security Top 10. So it's not the OWASP Top 10, which is general for web applications. It's the API Security Top 10. There is the OWASP API Security Project. And that project tries to curate a top 10 list specifically for APIs. And I mean, more and more applications these days, right? They have this typical pattern, the single page application. where basically you have static assets in the browser and then the functionality and the data, et cetera, that all goes through an API. And I mean, an API is like a web application, right? So usually you talk to it via HTTP, something similar. If you can open the API results directly in a browser, you might be careful with regards to JavaScript being injected, Give one example, right? Although that's rare. And then, of course, on the server, you may have a database. You have to look out for stuff there. So it's similar to web applications, but still it's different because some type of attacks or risks are more common in APIs than regular web applications and vice versa. For instance, the JavaScript injection or a more precise cross-site scripting. Cross-site scripting is typical for web applications, right? It's rather rare for APIs. Because usually with APIs, what you do is you get data, you process data, and then when you return data in most technology stacks, you basically say, okay, this is the object, this is the data, this is the array, this is the whatever that I would like the API to return, here technology stack or here framework of choice. Please put that into JSON, I don't really care. And then that framework returns properly formatted JSON with the correct. content types or that the browser does not render that as HTML and therefore no JavaScript is part of that. So cross-site scripting is rare. That doesn't mean it cannot happen, but it is rare, right? And so that's why those lists are different. And I mean, more and more applications, at least the ones I'm seeing, and maybe it's similar for you, they are using APIs a lot. And even if you don't have a single page application still, of lots of software is just using APIs.

 

Adam Furmanek:

Yeah, I think API generally the concept is nothing like to this essence is not related to web security, web APIs or web applications in general, right? APIs are with us for many decades and generally, even though today we think about the web world, it's not always the case. And cross-site scripting, as you mentioned, that's like JavaScript injection is basically about browsers, right? But when you are doing like, I don't know, backend and some... embedded software or whatever, then you also use APIs and for instance, scripts like Lua scripts and other stuff. I imagine cross-site scripting, maybe not the definitional cross-site scripting as we have with WebRubzor, could also happen in this scenario. What do you think?

 

Christian Wenz:

It could, but it's very, very rare because of the built-in stack protection. And well, just to give you a spoiler, so there is no cross-recripting entry in the API

 

Adam Furmanek:

Gotcha.

 

Christian Wenz:

top 10. And I agree here. Let me put it that way. Maybe if I say, OK, do I agree with that list, I mean, how kind of biased is that? Because the latest OWASP top 10 minus API was 0. very, very data-driven. So practitioners, people who are companies who do pen tests, et cetera, they kind of provided their results of their pen tests. So what was found, how often. And then this was kind of categorized and put into buckets so that we get a couple of categories. And again, it was very data-driven. I mean, there were some vague factors which were added. So the exploitability, for instance, and other stuff. So that could add some bias, also the grouping is some bias, if you would like to call it that way. But I mean, still, they tried to make it as data-driven as possible. The API project tried the same. So they started with different databases, like public reports about security issues in APIs. I think they were using some bug bounty platforms and then some public CVEs. And then they also did a data call, so please give us data, but they didn't get enough, right? So basically discarded the data and were sticking with what they got. And then again, categorized the talk to people, massaged the data. So, and I mean, you know, massaging data always sounds like cheating, but I mean, it still has to be kind of coherent and kind of makes sense. And maybe it should also match with expectations from practitioners in the field. So, I mean, that's good enough for me. because it's an awareness list, right? Because I say, I don't care if something is number three or number four, if it's there, I have to be aware of that.

 

Adam Furmanek:

That sounds really cool. Okay, so we know how it all started. We kinda know how it goes. So how about we go and see the list, what it brings for us this year.

 

Christian Wenz:

Absolutely. So let's go through the list or through all 10 items. And I think many of them we can cover briefly. But some of them maybe we can discuss in more depth. So let's just have a holistic look at it. And may I once again quickly peek at the big, so to speak, OS top 10 because they are the current number one entry in the current 2021 edition. It's called broken access control. which we understand that it's a risk, yada, yada. In previous versions of the OVS top 10, that was split up into access to what was broken. Because it makes a difference if you access data, or if you access functionality, or if you access something else and you don't have proper, say, authentication or authorization there. The OVS top 10 can do that, so they could put everything into this one broken access control bucket. because there were enough other buckets to fill. For APIs, maybe not so much. And that's why they split this up. And therefore, the number one entry in the 2023 API security top 10 is broken object level authorization. Right?

 

Adam Furmanek:

That's magical. Can you clarify a little bit? What's that about?

 

Christian Wenz:

So well, we try to access an object. So often that's data and we have broken authorization. So the authorization there does not work. I mean, there are simple examples, right? So that there is a data.json file publicly available on a server, right? Which is directly accessible. And I mean, that sounds dumb, right? Maybe it is dumb, to be honest. But it categorizes that risk really well. So we can get access to objects, essentially to data, without proper authorization. I mean, we are one of those typical examples from web applications, right? So you log into an application, and then you have a URL like, now it's an API. So we would have an API endpoint like whatever slash, I don't know.

 

Adam Furmanek:

Invoice.

 

Christian Wenz:

invoices slash 123, right? And since

 

Adam Furmanek:

Hmm?

 

Christian Wenz:

you authenticated, why not use 124, right? If

 

Adam Furmanek:

Exactly.

 

Christian Wenz:

you get data as well, and that's not your invoice, that's basically in that bucket, right? And so...

 

Adam Furmanek:

So I imagine everything that may fall into these categories, for instance, any mechanism that lets me iterate over objects by guessing their identifiers,

 

Christian Wenz:

That

 

Adam Furmanek:

which

 

Christian Wenz:

would work

 

Adam Furmanek:

I shouldn't

 

Christian Wenz:

as well, yeah.

 

Adam Furmanek:

be able to access.

 

Christian Wenz:

Yeah, exactly, exactly.

 

Adam Furmanek:

And any practical considerations for that? Should

 

Christian Wenz:

Mm-hmm.

 

Adam Furmanek:

I randomize identifiers, use global UIDs

 

Christian Wenz:

I

 

Adam Furmanek:

or whatever? Or just change the mechanism to not let anyone read those files?

 

Christian Wenz:

I think, I mean, I'm a fan of having GUIDs as identifiers, indeed, but I know how practical and easy and digestible it is if we have integers, what a lot of people are doing. I mean, it's not a problem. Oh, well, it's not necessarily a problem if someone guesses an invoice. As long as you do authorization, does this user... have the privileges to access that specific invoice. So I think that's the idea.

 

Adam Furmanek:

Yeah, one thing I would add to this, I am not an expert in OVASP, so I

 

Christian Wenz:

Mm-hmm.

 

Adam Furmanek:

don't know whether it actually falls into this category, but like pre-signed URLs, that is something that like we programmers, we know that we are lazy. And when we generate a pre-signed URL, how long should, when should

 

Christian Wenz:

Mm-hmm.

 

Adam Furmanek:

it expire?

 

Christian Wenz:

Yeah,

 

Adam Furmanek:

Ideally

 

Christian Wenz:

yeah.

 

Adam Furmanek:

never because it's convenient, right?

 

Christian Wenz:

Yeah, yeah,

 

Adam Furmanek:

But that's

 

Christian Wenz:

yeah.

 

Adam Furmanek:

the very easy way to actually break this mechanism, right? You get an object, you pre-sign URL and bang, publicize it anywhere. And one of the issues, the practical issue, and this is something I actually faced in my career,

 

Christian Wenz:

Mm-hmm.

 

Adam Furmanek:

was maybe a little bit different, but still on the same idea, like single sign-on URL,

 

Christian Wenz:

Yeah.

 

Adam Furmanek:

when you confirm user account or

 

Christian Wenz:

Mm-hmm.

 

Adam Furmanek:

whatever. When you send those links over email to your users, our beloved email clients, they tend to basically take the thumbnail of the

 

Christian Wenz:

Yeah,

 

Adam Furmanek:

URL, take

 

Christian Wenz:

yeah,

 

Adam Furmanek:

the snapshot,

 

Christian Wenz:

yeah.

 

Adam Furmanek:

Kill our URLs this way.

 

Christian Wenz:

Yeah, exactly, exactly. And I mean, also one of those typical rules is, if you have an HTTP method get, it should not change the state of the application. But yeah,

 

Adam Furmanek:

Exactly.

 

Christian Wenz:

in that case it does. Yeah, I mean, it's really bad. Also, especially some web-based mail providers, they try to check the links in emails to find out whether they are malicious or whether they point to something that is considered dangerous. So they also... trying to load that URL, right?

 

Adam Furmanek:

Cool, cool, okay,

 

Christian Wenz:

Bummer,

 

Adam Furmanek:

shall

 

Christian Wenz:

bummer.

 

Adam Furmanek:

we move on?

 

Christian Wenz:

Yeah, indeed. Number two, super generic, broken authentication. And I mean, broken authentication can be anything, right? So you have an API that has guest slash guest as credentials. Or you have an API that is using JSON web tokens, but accepts JWTs that are not signed, right? You have an application where the JWT doesn't have an expiration date or the expiration date is not checked. Stuff like that, right? And I mean, that's number two. I was a bit surprised to see that because quite often, especially when you have an API, you don't really manually do the authentication, right? You use what your framework is providing you with. So for instance, with ASP.NET Core, you really have to explicit disable. the signing requirement for instance for JWTs. But if I'm not mistaken, actually that specific thing doesn't even have an effect. So you have to have signed JWTs anyway. So you

 

Adam Furmanek:

Yeah.

 

Christian Wenz:

can override the mechanism that validates this, but you can just say, well, you could say but it doesn't work, it doesn't change your behavior. You can't say, yeah, don't check the signature. No, if there's a signature, it will be checked.

 

Adam Furmanek:

I think there are two, if I was a programmer,

 

Christian Wenz:

Mm. Yeah.

 

Adam Furmanek:

thinking about this rule, I think there would be two places where I could get it wrong. First one is, obviously for my local or dev environment, I'm gonna cut corners like crazy, disable that stuff, and then I just forget to re-enable it in production for whatever reason.

 

Christian Wenz:

Yeah, yeah.

 

Adam Furmanek:

But second thing, and this is again something I encountered in the companies, is... breaking this mechanism by using seemingly secure things incorrectly, for instance, having like a physical UB key to make the authentication work well with multi-factor, but not using this hashing option of

 

Christian Wenz:

Mm-hmm.

 

Adam Furmanek:

UB key, but instead generating one time key and because UB doesn't have the clock in it, then if I regenerate it accidentally, it never expires.

 

Christian Wenz:

Yeah.

 

Adam Furmanek:

which can also be considered a feature for some

 

Christian Wenz:

Yes,

 

Adam Furmanek:

UW cases.

 

Christian Wenz:

it is a feature indeed. All right.

 

Adam Furmanek:

Yeah.

 

Christian Wenz:

Good.

 

Adam Furmanek:

Cool.

 

Christian Wenz:

Let's pivot to number three, broken object property level authorization. That sounds a bit complicated. And I mean, what's the difference between broken object level authorization and broken object property level authorization? I think a typical example would be what is maybe related to mass assignment or overposting. for regular, quote unquote, web applications. So imagine you have an endpoint, whatever, API endpoint, create user, right? And you can send the user with a username and an email address and maybe the password, right? But the model on the server also has other properties for the users. For instance, the property, and I mean, I make this as boilerplate as possible, right? So you wouldn't do this in practice, right? But just to get the idea across. So let's just imagine the user had a Boolean property, you know what's going at, right? A Boolean property is admin, right? So

 

Adam Furmanek:

Mm-hmm.

 

Christian Wenz:

what if that create user request gets not only username and credentials and email address and whatever, but also is admin colon true? Because especially if you do something like model binding, which of course is

 

Adam Furmanek:

Mm-hmm.

 

Christian Wenz:

very popular with ASP.NET Core and thus ASP.NET Core Web API as well, then if isAdmin is a public property of that model, it would be bound as well. And that would mean we would have broken object property level authorization.

 

Adam Furmanek:

And this is actually a very common case. At

 

Christian Wenz:

It

 

Adam Furmanek:

least

 

Christian Wenz:

is.

 

Adam Furmanek:

I've seen that in practice many times, especially when we reuse the same model for database storage and view models on the API side.

 

Christian Wenz:

Exactly. Yeah. So ViewModel

 

Adam Furmanek:

And then

 

Christian Wenz:

set

 

Adam Furmanek:

we

 

Christian Wenz:

hits.

 

Adam Furmanek:

use automapper or whatever, which

 

Christian Wenz:

Yeah.

 

Adam Furmanek:

does the magic with bindings. And there we go.

 

Christian Wenz:

Exactly. Yeah. So use a ViewModel. Or I mean, if you just use what ASP.NET Core gives you, you have the include and exclude attributes. So you can have an allow list or a deny list for properties which may be bound and which may not be bound.

 

Adam Furmanek:

Yeah, and this is especially tricky because one of the other so-called quote unquote best practice

 

Christian Wenz:

Mm.

 

Adam Furmanek:

is whenever you have an API and you do not recognize some properties, just let them pass through for compatibility, backwards and forwards. And this way you can break this what was called broken object property

 

Christian Wenz:

Yeah,

 

Adam Furmanek:

level authorization.

 

Christian Wenz:

exactly. All right,

 

Adam Furmanek:

Cool cool.

 

Christian Wenz:

number four. And that's something that could happen, or is a risk for web application as well. But for APIs, I think it's more prevalent. It's unrestricted resource consumption. So that the API is subject to a denial of service attack. Or what I see more and more often is lots of applications these days, they're using GraphQL. But I mean, GraphQL is kind of complex. And with complexity, of course, always comes the risk that there is some abuse possible. And one thing I recently found in audit, for instance, was there was a GraphQL query where some really complex database logic was triggered by a GraphQL call. And the application, therefore, was using paging for the results and was setting a page size as part of the GraphQL query. So we could find out that you could change the query and use a very, very large page size. And that would basically send an issue, a denial of service attack against the application. So you have to have some kind of rate limiting. You have to have some monitoring. And again, that depends on the app, maybe some auto scaling where it's hosted or just some threshold, OK, this much. This much traffic, this much resource allocation, this size of the incoming HTTP request, payload, et cetera. This is the limit and deny everything else.

 

Adam Furmanek:

Two things come to my mind when you mention this. First is actually what happened with Twitter, at least what they

 

Christian Wenz:

Hehehehehehe

 

Adam Furmanek:

claim happened, that they were abused heavily for text messages.

 

Christian Wenz:

Yeah.

 

Adam Furmanek:

So everyone was just using Twitter just to make them send second factor

 

Christian Wenz:

Yeah.

 

Adam Furmanek:

and pay for it, and

 

Christian Wenz:

Yeah, yeah,

 

Adam Furmanek:

then

 

Christian Wenz:

yeah.

 

Adam Furmanek:

wasting it. And second thing that comes to my mind is any kind of reflection attacks, I think. like some services, for instance DNS or Active Directory, they let you basically, when they can't handle some requests, they route it to some other server, right? And if you control that, then basically you can incur additional charges or even

 

Christian Wenz:

Yeah, absolutely. All right, ready for yet another broken authorization

 

Adam Furmanek:

Let's

 

Christian Wenz:

thing?

 

Adam Furmanek:

go for

 

Christian Wenz:

It's

 

Adam Furmanek:

it!

 

Christian Wenz:

the last one. It's number five on the list. It's broken. I mean, we have had objects. We have had object properties. So now we're missing the functionality aspect. So broken function level authorization. So basically,

 

Adam Furmanek:

Okay.

 

Christian Wenz:

we don't access data. We access a functionality. And with APIs, I mean, if it's a GET request, usually data, if it's something like post, often it's the functionality that we are calling. Basically, it's the same thing, but this time we are accessing some functionality or a function, as they call it in that list.

 

Adam Furmanek:

So basically it's calling an endpoint

 

Christian Wenz:

Yeah.

 

Adam Furmanek:

that I shouldn't be able to call, right?

 

Christian Wenz:

I mean, web applications have these two generic rules, validate input and escape output. Right. Of course, you cannot validate each and every input. Think of free text fields, right? But then if you process the data, then you have to escape it before you stuff it into SQL or put it in HTML, right, to avoid SQL injection or cross-head scripting. And for many API calls, I mean, still validate the incoming request, whether you get the data you expect or too much or too little or the right properties, but they have too much data in them. Whatever you can validate, just do.

 

Adam Furmanek:

just do that sounds like a very good rule of thumb

 

Christian Wenz:

Let's

 

Adam Furmanek:

let's carry on then

 

Christian Wenz:

see. Yeah, indeed. Let's quickly move over to number six, unrestricted access to sensitive business flows.

 

Adam Furmanek:

And now this gets serious because we mentioned business finally.

 

Christian Wenz:

Yes,

 

Adam Furmanek:

Right.

 

Christian Wenz:

so finally, it's getting expensive, exactly. And I mean, indeed with every API endpoint, we are calling in a business application, it's somewhat that somehow pays into the process that is happening, right? And those... let's say those endpoints or those API parts that are close to the revenue of a company, they should be vetted extra hard. So I think an example the OVASP is giving is if you automate referral systems of a company, so that you get a referral bonus if you refer someone else and if you automate this. And therefore, make sure you always get a referral bonus when providing whatever a new customer. Or I think, are they using ride sharing as an example? I don't remember, actually. But I think it's ride sharing. So whenever you bring in a customer for a ride, that you could hyper-effectively automate that process of setting up for referral and then getting the referral bonus. So

 

Adam Furmanek:

Hmm.

 

Christian Wenz:

I mean. The differences between those items we've had so far, they are relatively subtle. But as you rightfully pointed out, if I just say, validate the data as good as you can, that is factually correct. And it's probably solid advice, but it's not tangible. But think

 

Adam Furmanek:

Exactly.

 

Christian Wenz:

about, OK, think about the data you can access. Think about any properties. request could set. Think about the functionality that can be called. Think about which of the APIs trigger which business processes. I think this awareness, and there we are again, awareness, this awareness I think is key.

 

Adam Furmanek:

Especially that when I read the description of this rule, which is if used excessively in an automated manner, then

 

Christian Wenz:

Yeah.

 

Adam Furmanek:

it harms the business. And one thing that came to my mind is what if we make a human mistake and when we post an item for selling

 

Christian Wenz:

Mm-hmm.

 

Adam Furmanek:

on the page, we miss the number of zeros, right? And we start selling something ten times cheaper than we should. like not buying one piece of that item, but 1000 pieces of that.

 

Christian Wenz:

Yeah, yeah, yeah.

 

Adam Furmanek:

Should we allow for that or not? How should we cover that? And how would we even notice that this happened, right? Do

 

Christian Wenz:

Yeah,

 

Adam Furmanek:

we have monitoring for cases like

 

Christian Wenz:

exactly.

 

Adam Furmanek:

this?

 

Christian Wenz:

The OWESP Top 10 number 9 item, by the way, is insufficient logging and monitoring.

 

Adam Furmanek:

We'll get to that. First, let's move on to

 

Christian Wenz:

No, we

 

Adam Furmanek:

numbers.

 

Christian Wenz:

won't because that was the OS top 10. The API top 10 does not have

 

Adam Furmanek:

That is exactly

 

Christian Wenz:

that

 

Adam Furmanek:

right.

 

Christian Wenz:

item. But again, so you see the focus is a bit different. But I think all of this is, of course, of equal importance. I'm

 

Adam Furmanek:

That

 

Christian Wenz:

a

 

Adam Furmanek:

sounds

 

Christian Wenz:

bit.

 

Adam Furmanek:

good.

 

Christian Wenz:

torn, I have to be honest, I am a bit torn about number seven. It's server-side request forgery. Server-side request forgery, that's not cross-side request forgery. That's something else. Cross-side request forgery basically abuses the way cookies work, at least in the most typical aspect of cross-side request forgery. But API authentication is often not done via cookies, but rather via token. And so server-side request forgery is a thing. It is number 10 in the web OWASP top 10. But it did not come in based on data. It came in based on a survey which basically said, OK, dear practitioners, an auditor is always a look into the past. Are there any things you think they might grow in importance in the future? If so, we could add this to the OWASP top 10 as well. And Well, essentially, server-side request for G then got the number 10 spot, but wouldn't have gotten that based on the data alone. And here's on number seven, because maybe it's a bit more typical for APIs. We just talked about this effect that you have a URL, and then your email client is calling that URL to display the picture or to check it, right? So you can trigger your email client potentially. Well, let's not use the email client. Let's use web-based email application. You can trigger the server that runs the email application to do an HTTP request, essentially, to check the link, whether the target of the link is malicious or contains, I don't know, a virus. So server-side request for G is basically that attack. prompt a system, a server, to send an HEP request to a third party. Now, is that a problem? I mean, does it make sense? Doesn't it make sense that, for instance, we check specific links in an email before displaying that email to the user? In theory, yes. But let me give you a totally hypothetical example. Let's just imagine we are using, let's say, Outlook.com, right? I'm sure there are safeguards in place. But let's just imagine. Outlook.com is checking all links and emails before displaying it in the web browser. Let's just imagine there is this super secret Azure Godmode admin page. The URL is godmode.azure.com. Well, I hope that doesn't exist. Anyway. but that's not publicly accessible, right? Because that's within the DMZ. We can't access it. But Outlook.com also runs on Azure. And Outlook.com happens to be in the same DMZ, and therefore can access that Godmode site, right? So we kind of make Outlook.com on the server send a request to that internal system, right? And you see, I mean, it took me like a minute to describe, at least a minute to describe this attack. The stars have to be aligned perfectly. I mean, finding a web application that I can trigger or prompt to send an HTTP request to a third party site, I mean, that works. I mean, there are websites where you can enter URL and it checks the URL for, I don't know, for accessibility posture or something. So that works. But the secret, of course, is finding a system that I cannot directly access, but that servers can access. And then finding an HTTP request that actually does some harm. So it could be a request that does something to the target server. But usually, the requests I can trigger are GET requests. And GET requests shouldn't change the state of the application, according to the REST principle. Or I can query data from the server that's at the server. Data is then returned to the server I'm attacking. And for some reason, the server I have attacked is now returning the data to me in the browser as well. Stars have to be aligned perfectly. There are really, really nice proofs of concepts for server-side request forgery. But at least in my personal, but of course, anecdotal experience in the audits I'm doing, I do find web applications that I can make send an HTTP request to a target of my choosing. So I can show there is hypothetically source that requests forgery. But usually, I cannot give them an exploit that not only shows the vulnerability, but also the negative consequences. But it's only on number seven. So I take this. I accept this.

 

Adam Furmanek:

This sounds like a very good principle, which is very hard to use if we do not make mistakes in other areas.

 

Christian Wenz:

Yes,

 

Adam Furmanek:

As you mentioned,

 

Christian Wenz:

yes.

 

Adam Furmanek:

it's not only about sending this request, but also doing something that we are after, right?

 

Christian Wenz:

Yes.

 

Adam Furmanek:

Not just breaking something, obviously, that's a bug on its own, but we as attackers probably would like to benefit from that. So that makes it even harder.

 

Christian Wenz:

Yes, absolutely. All right, we are approaching, well, almost the end. Number eight is something that is also part of the OBS plot 10, but I think that's on number five, if I'm not mistaken, security misconfiguration. So anything related to security, to configuration, that is security related. So you don't enforce HTTPS. You don't use, if the API is consumed by a web browser client, you don't use security HTTP headers for your API. Your course policy is accept control, allow origin star, which would allow everything. So these things, everything that is part of configuration. Now, I have to be honest. would not consider myself like an administrator. So like running service is not my main area of expertise. So I always say, okay, someone has to do that. But now with DevOps or DevSecOps or SecDevOps, I mean, I have to do that. Also, I mean, those security related headers, should the team running the server set them? No, of course not because they have an effect to the application, right? So I, as the person doing the application, I should specifically set those headers. I mean, there are some configurations like, don't send full stack traces to the client in case an exception occurs. Maybe this can be done on the server level. But yeah, many of those configuration aspects, they are also cookie flags, for instance. They are my responsibility and therefore, security misconfiguration. Bit surprised that it comes so late. But indeed, it is there.

 

Adam Furmanek:

Yeah, exactly. Especially that we as developers, we very often turn them off in local environments.

 

Christian Wenz:

Yeah.

 

Adam Furmanek:

As you mentioned, I of course put it star just because I don't want to waste my time configuring

 

Christian Wenz:

Yeah,

 

Adam Furmanek:

that.

 

Christian Wenz:

I

 

Adam Furmanek:

But

 

Christian Wenz:

don't

 

Adam Furmanek:

the

 

Christian Wenz:

even

 

Adam Furmanek:

other

 

Christian Wenz:

know

 

Adam Furmanek:

thing...

 

Christian Wenz:

how course

 

Adam Furmanek:

Yeah,

 

Christian Wenz:

is working, right? Let's just get

 

Adam Furmanek:

exactly.

 

Christian Wenz:

this out of the way.

 

Adam Furmanek:

But the other thing even Ovas mentions for this rule is the problem with Java and JNDI. And that was the thing that, well, for.NET developers, that may be a little bit surprising, but Java's logging libraries, they really allowed for crazy stuff. And there was this attack for using JNDI, which basically allowed us that if we log something and how many times we just log the input that we get to

 

Christian Wenz:

Yeah,

 

Adam Furmanek:

our

 

Christian Wenz:

yeah,

 

Adam Furmanek:

APIs,

 

Christian Wenz:

yeah.

 

Adam Furmanek:

then because of fancy pattern replacement that was basically doing a network call to some remote server. So our logging library could be doing very crazy stuff. And this is also included

 

Christian Wenz:

So that was

 

Adam Furmanek:

in

 

Christian Wenz:

the

 

Adam Furmanek:

this

 

Christian Wenz:

famous

 

Adam Furmanek:

point.

 

Christian Wenz:

log for net viability, right?

 

Adam Furmanek:

I don't know whether it was in log4net, it was definitely in javas,

 

Christian Wenz:

Yeah, yeah, and

 

Adam Furmanek:

log4j,

 

Christian Wenz:

that was changed. Yeah,

 

Adam Furmanek:

right?

 

Christian Wenz:

yeah, exactly, exactly.

 

Adam Furmanek:

Yeah, yeah,

 

Christian Wenz:

I think about that.

 

Adam Furmanek:

so

 

Christian Wenz:

Yeah,

 

Adam Furmanek:

probably

 

Christian Wenz:

yeah.

 

Adam Furmanek:

log4net could be, you know, exploitable in a very similar manner. So generally it's not only what we can do, but also

 

Christian Wenz:

Yeah,

 

Adam Furmanek:

what our dependencies do, right?

 

Christian Wenz:

exactly.

 

Adam Furmanek:

How many times we just

 

Christian Wenz:

Exactly.

 

Adam Furmanek:

take the logging library,

 

Christian Wenz:

Yeah,

 

Adam Furmanek:

right?

 

Christian Wenz:

yeah, exactly.

 

Adam Furmanek:

Cool.

 

Christian Wenz:

All right, number nine is improper inventory management. Typical example, you have your API, but you also have a publicly available QA version of your API. And maybe that is running a different version or doesn't have the same level of protection. A story I'm always love to tell and I can only tell because I think it's now almost 25 years ago. So I was working for a company that did web applications for rather well-known companies and let's just say for ABC Corp. They did their main web application as well and I mean ABC Corp was like Fortune 500 company and so they had a publicly available test server because back then, you know, VPN and stuff like that was too complicated. I don't know. And that was abc.test.nameofthecompanyIwasworkingfor.com. But of course, you can't just publicly access that. So there was HTTP Basic Auth and the username was abc and the password was cba. Now imagine

 

Adam Furmanek:

Sounds

 

Christian Wenz:

what happened

 

Adam Furmanek:

very secure.

 

Christian Wenz:

if the, well, I mean, you know, no one knew this, right? But the company didn't just have ABC Corp as a customer, but also DEF enterprises. Now guess what the name of the test server was of the DEF enterprises and what the credentials were, right? And with Improper Inventory Management, really, okay, which, which kind of versions of the APIs do you have? just knowing what is out there, not that there's this old, maybe insecure version that has been deployed once to a server someone forgot. So just know what your inventory is. It sounds simple, right? But especially when things are complex and you have different versions, et cetera, et cetera, then this is something that always should be taken into. taking into account.

 

Adam Furmanek:

I think one challenge here also, which is, let's say, a little bit more practical, is that when we run multi-tenant application, then it may be that for some tenants we need to keep those older APIs. And

 

Christian Wenz:

Yes.

 

Adam Furmanek:

if anyone finds vulnerability that is even fixed in the newer version and we put that in change log or whatever,

 

Christian Wenz:

this.

 

Adam Furmanek:

someone may look for older versions still running.

 

Christian Wenz:

Ah, and now that you mentioned that, completely unrelated. But the vulnerable framework, I just remembered it was not locked for net. So apologies for the team there. It was locked for j. I'm pretty sure it was locked for j. That had the vulnerability. Sorry for that. But now it has been fixed, right? But it was quite an outcry. All right.

 

Adam Furmanek:

and we believe no one runs the old version

 

Christian Wenz:

Yeah,

 

Adam Furmanek:

anymore.

 

Christian Wenz:

yeah, let's hope for that. All right. And actually, that brings us to a segment that went fantastically through the final entry of the OVAS API Securities Top 10. Number 10 is unsafe consumption of APIs. Because I've been talking about for many of the preceding items on the API Top 10 is that don't trust user input, validate what you can, et cetera. But what if you are consuming other APIs as well? It's like having a dependency in your web application, having other APIs. Of course, the data, the information you get from other APIs, it's also something that should be validated and cannot automatically be trusted, right? Because that API might be overtaken by someone else. You don't control it, right? So you must not trust it. So don't just distrust. if that's the word your users. Also, do not trust any other APIs you're calling, even

 

Adam Furmanek:

Yeah,

 

Christian Wenz:

if

 

Adam Furmanek:

yeah.

 

Christian Wenz:

you call them internally.

 

Adam Furmanek:

And I think one thing worth mentioning here is that relying on RFCs or standards may also be super misleading, right? Because

 

Christian Wenz:

Absolutely.

 

Adam Furmanek:

even if we follow RFCs, that does not necessarily mean others do the same. And so we may get invalid input because of whatever input that we do not expect. And there we come to the rule of thumb you already mentioned, validate

 

Christian Wenz:

Yeah,

 

Adam Furmanek:

all the

 

Christian Wenz:

absolutely.

 

Adam Furmanek:

input.

 

Christian Wenz:

So that

 

Adam Furmanek:

Cools!

 

Christian Wenz:

were the 10 items of the OWASP API SecureTools 10, again, from May 2023. And I'm all for awareness, so I can just recommend everyone check that out if you work on APIs. And yeah, I just have to hammer that point home once more. Awareness is the key, right? You can't protect your web applications against something you don't know about.

 

Adam Furmanek:

That sounds cool. So thank you, Christian, for this amazing piece of knowledge about OVASP and PING. Let's actually move on to some picks for

 

Christian Wenz:

Absolutely.

 

Adam Furmanek:

this week's episode. So I can begin

 

Christian Wenz:

Yeah, sure.

 

Adam Furmanek:

to give you a little break. So my pick for this week is Servio. Servio.net is one example of various applications that do something that Christian may call insecure.

 

Christian Wenz:

Ah, yeah, yeah.

 

Adam Furmanek:

which is exposing local applications publicly. I mean, how many times we had this case that, hey, I do run something which is exposed on localhost, colon, whatever, and I just need to access it from somewhere else. For instance, from my mobile phone for whatever reason, because I'm doing mobile development, right? How do I do that easily? And obviously I could take any VPS, expose SSH and then do remote forwarding. But if we really need... really need to do that for like a minute or very quick and dirty then the application is doing that for us so Servio is one of them. It works really nice, it's pretty simple to use. Just keep in mind it may be a little bit dangerous so when you go back home from your office always tear the tunnel down.

 

Christian Wenz:

Absolutely, that makes absolute

 

Adam Furmanek:

But

 

Christian Wenz:

sense.

 

Adam Furmanek:

what's your pay question?

 

Christian Wenz:

Yeah, I'm doing a streaming pic just as an homage to our co-hosts that are not there yet. And I have to admit, I'm late to the party. But that's maybe also because I'm more of a binging type. So for select shows, if it says, okay, every Friday, new episode, right? That's kind of nice. So, okay, ah, I got a date on Friday, right? But sometimes it's like, oh, they always have cliffhangers in each and every episode. No, I'll just binge a couple of them and decide when I stop. And so I may be late to the party here, but my pick is maybe somewhat surprising. It's Star Trek, Strange New Worlds. When I was growing up, I didn't really watch the original series, but I was watching Star Trek, Next Generation. I really loved that. Every episode was more or less separate from the others. Yes, there were story arcs, but I really liked the chemistry of the cast, et cetera. And I found I had some issues with Star Trek Discovery. Also some parts of Star Trek B-car, except for the third season, because they brought the next generation cast, right? So that was kind of like my youth again. Yeah, and with Discovery, I had issues with some of the characters, right? And so when I saw Star Trek Stranger Worlds, I was like, oh, it's the same thing again. Yeah, let's watch something else. And then... a friend, she kind of said, no, you have to watch that, actually. It's now in the second season. I think it runs on Paramount Plus in most markets. So I started with season one because, you know, all the 10 episodes are already there. So I was watching this like in three nights or four evenings. And it's like starting next generation. Fantastic cast, working together so well. They do have story arcs, but still each episode is different. There are some shocking moments though, but you know, great, great villains, great characters. Lot of fun, lot of fun. The only issue is now that I've watched season one, of course I will watch season two, but season two is still, you know, going on. I don't know, is it like... like the fourth episode now as we are recording something like that. So I have to wait for probably two more months until the season has been completed. And then I just take off for three days and then I catch up.

 

Adam Furmanek:

That's always the risk of starting something that hasn't been completed yet. My case for that is like Patrick Rothfuss' The Kingkiller.

 

Christian Wenz:

Mm-hmm.

 

Adam Furmanek:

Fantastic series, which was supposed to be a trilogy and we are waiting for the third part for,

 

Christian Wenz:

Hehehe

 

Adam Furmanek:

I don't know, 15 years now. Hopefully one day.

 

Christian Wenz:

Fingers crossed, fingers

 

Adam Furmanek:

So I know

 

Christian Wenz:

crossed.

 

Adam Furmanek:

your feeling.

 

Christian Wenz:

Fantastic! Alright, that's been a great episode. Thanks so much, Adam. Thanks

 

Adam Furmanek:

Thank

 

Christian Wenz:

everyone

 

Adam Furmanek:

you, Christian.

 

Christian Wenz:

listening in. And

 

Adam Furmanek:

And

 

Christian Wenz:

I think we'll

 

Adam Furmanek:

yeah.

 

Christian Wenz:

be... We have a lighter schedule, I think, during the summer. But we'll be back on track at least after summer. But still we'll drop some episodes in between. And yeah. With that,

 

Adam Furmanek:

Thank you everyone and let's tune in for the next episode of Adventures in.NET!

 

Christian Wenz:

Thanks a lot. Bye, everyone.