The medium of cyber-attacks is code, but the mastermind that drives them is always human intelligence. Systems are created by people, and automated tech still can’t understand every nuance that humans embed into them.

In this episode, Nick Blundell – Head of R&D at AppCheck speaks with Holly Grace Williams from Secarma about the pros and cons of vulnerability scanning, how hackers can enter weak systems and the need for a blended approach. Listen below.

00:50 – Will automation take over?
04:25 – Scanning or Pentesting: the pros and cons
17:30 – Issues with automation
22:00 – Weak systems
52:50 – A blended testing approach

Listening time: 1 hour 5 minutes
Host: Holly Grace Williams, MD at Secarma
Guest: Nick Blundell, head of R&D at Appcheck

Transcript below:

Nick Blundell, Secarma Security Podcast Transcript

Holly Grace Williams: Hello and welcome to the Hacked Off podcast. In today’s episode I have Nick Blundell with me, Nick has been on the podcast before but Nick for the benefit of anyone who’s listening who hasn’t seen your previous episode. What is it that you do?

Nick Blundell: Yes, so I work for a company called AppCheck and we specialize in automated scanning for vulnerabilities in web applications and that’s our main focus, and so my main focus is on exploring the challenges of how we automate that detection. So, on the on the easy scale, it could be things like fuzzing for straightforward vulnerabilities, but on the hardest scale, this will talk about today, it could involve understanding how to complete authentication, understanding vulnerabilities that require particular workflows, and to actually exploit and things like that. So that’s my main focus really.

Holly Grace Williams: So anytime that vulnerability scanning or really any kind of automated testing comes up when I’m talking to people, people very often ask me, do I think that automation will ever replace penetration testing entirely? So, I’m going to ask that question to you. Do you ever think that vulnerability scanning will get to the point where manual penetration testing just isn’t required?

Nick Blundell: So, if I was dishonest, I would say of course we can find everything through automation. You know, you point the scanner at your targets and will find vulnerabilities. But we, our background is in penetration testing. Our origins are from penetration testing, and we know that certain scenarios require human intuition to find those vulnerabilities. So, what we try and do is realistically get as close as we can as possible to automating vulnerability detection, making sure that we’re not missing, you know there’s low hanging fruits. Those things that we might need to make thousands of requests to find those vulnerabilities, but we can find them quite easily, and so we don’t want to miss any of those ones. And then it’s just a question of how far we can push the automation to get close as possible to penetration testing, but I would always imagine that just like any like a typical human computer challenge, we need intuition to do certain things. Some vulnerabilities are only actually vulnerabilities when you understand the context of that application, that they are rising, and without that understanding, there’s no way to say this is vulnerability or not, and whereas other vulnerabilities are more straightforward, there’s a much simpler signature for saying this is vulnerable or this is not vulnerable.

Holly Grace Williams: I think that’s a big thing. Is that when I talk to people about automation, one of the things that I try and get across. Is the fact that that question, you know? Do you ever think automation will replace pen testers? Kind of, it’s a leading question that has bias in terms of it. It makes it sound like pen testers of the golden standard apprentices are what vulnerability scanner should be kind of aspiring to be like, and it’s obviously great to hear the fact that you know the AppCheck team is founded with pen testers and you’re really coming at it from that point of view. But for me, sometimes it’s a little bit different and in terms of, it’s just like you know what, sometimes automation is actually better. And you know my go to example there would be if you look at, something like checking to see if a machine has all of its software updates installed. It’s like you don’t want to pay a human to do that. It’s incredibly inefficient when you know the software could log in, could check the list of available patches versus the list of installed patches, and could do that much more quickly. So I think when it comes to vulnerability scanning, sometimes people are coming at it from the wrong approach and you should use automation where automation is going to drive benefit and you should use humans where automation isn’t.

Nick Blundell: Yep, and it’s definitely synergy of those two, and I think we’ve discussed before this, idea that what you ultimately want to get to, is a point where you’ve eliminated the most mundane vulnerabilities from your systems, and you’re focusing all of your effort now with scanning and with manual pen testers to really find their hard to find stuff. The stuff that needs a real understanding of the application and real intuition, and it’s that progression from, you, know, getting the basic level of security right, and then continually increasing the coverage and the and the focus on that ticket application ultimately, with with manual pen testers looking at that, and so they’re not finding all that low level stuff that you really don’t want to be spending too much money on. You don’t want to report with, you know, thousands and thousands of cross site scripting examples when there’s some other, you know, code execution vulnerability lurking in there that requires a real deep understanding of the application. So, this is where automation and manual pen testing works really well together.

Holly Grace Williams: So, for the audience who you know, very likely you know their work in information security, there probably procure vulnerability scanning and pentesting services, but maybe they haven’t thought very deeply about how it works. How does the system go about finding vulnerabilities in a purely automated way?

Nick Blundell: Yeah, so we imagine it as well when we’re working on the ideas and the software. Well, I personally always try and think of it as a from a manual pen testing point of view where I think I need to know if I’m gonna find vulnerabilities on this application, I need to know as much about the application as possible in terms of at a practical level, knowing where early inputs go into the application, but then further I want to know if there are any particular workflows in the application that needs to be that need to go through a particular sequence of events to trigger that particular piece of functionality. Like we always talk about shopping cart process where it has a defined start with choosing products and defined end when you come to check out and pay for the product, and along the way there’s a definite sequence of things you need to do to complete that. So we want to know as much as possible about the application. So once we know the attack surface, which is what we call it, all the all the places where input goes, and this is disregarding repetition and duplication, so we don’t want to know about every product on an application, the shopping application. We just want to know about that there is a functionality that is a product and that’s a distinct piece of functionality from the rest of the application. So, we talk about the reduction or refinement of the attack surface down to its logical attack surface. The actual the code execution paths of the application that we want to stimulate, and then we talk about running that through a process of detection and vulnerabilities, which would involve at the at the most basic level with fuzzing. So we are passing and payloads into the application to look for a particular response from the application that would signal there could be a vulnerability there. It’s a case of enumerating the targets and then going through those targets and looking for abilities and then as you get to the harder scale, it’s about understanding the workflows in the application and automating the workflows as much as you possibly can do within the scanner, to find those vulnerabilities.

Holly Grace Williams: So effectively are trying to program the scanner to interact with the application the same way that a legitimate user would, so that you can find all of the functionality and then subject that functionality to testing. Is that it?

Nick Blundell: Yeah exactly. So if you were doing a pen test then you might be faced with a massive application. At least it’s massive at face value. Their initial impression is that this has got a lot of pages for example, but when you start to explore the application you’ll find that there are actually distinct areas of interesting functionality. So, if your focus is drained on one part of the application and over the time of your pen test you don’t actually you run out of time before you can cover the rest of the application or even discover the rest of the application, then you’re going to miss vulnerabilities. So, the scanner is trying to do the same thing. It’s trying to be efficient in its enumeration of targets, and it’s trying to avoid spending too much time on duplicate scenarios so they can get the best coverage possible

Holly Grace Williams: So, there must be some functionality that you know is just generally complicated. An example that comes to mind would be like a calendar function or something like that way. You know you keep clicking next and it keeps loading days because time never ends. Or another one that I think is perhaps more common would be things like authentication systems. So, the example that comes to mind would be my bank, which doesn’t ask me for a username and password. It asks me for a username, password and the 4th character of my secret word. How does the system handle the fact that every web page could have some different implementation of that authentication could come in many different ways and then also making sure that you’re able to find vulnerabilities within that system, be them authentication vulnerabilities or otherwise?

Nick Blundell: Yes, so that’s a good question, and it’s one that often our clients worry about at first when they when they come to us with an authenticated application. Initially, perhaps in a naive way when I started looking at authentication my focus was on trying to generalize an algorithm for detecting how to complete authentication, and very soon I realized that from like I said, we do research, vulnerability research and we’re in contact with lots of real life examples, applications and when you move away from the textbooks of how to find vulnerabilities and to how authentication works to the real world, you find there’s lots of variation and things that you just wouldn’t have expected. And so we’ve moved now to a scripted approach where we just make it as easy as possible for people to write a script that describes that tells the scanner how to complete the authentication through their browser, which is literally like saying go to this login page and fill in username with this value, fill in the password of this value, click log in, and then wait until you’ve seen some information and on top of so we call this a ghost script, but it’s basically a simple way to tell this scanner how to get through a particular flow in application that doesn’t need much programmer insight. It’s pretty much tell it what to do, like tell it to other monkey what to do and actually a level of programming language. Yeah

Holly Grace Williams: Is that flow agnostic then? So we’re talking about it now in the context of authentication systems, but it could be, as you mentioned earlier, a shopping cart.

Nick Blundell: Yeah, exactly. And in terms of, I would say that most people, like we said before, you start with the base level security and then you progress to try and put more focus on the application to scanning and I would say that most of our clients use it for authentication, but it’s possible to map particularly for workflows. We talk about, generally, we talk about crud flows and as in if you were creating a rest API or something like that, yeah or any application you can think of, you can probably describe it as a as a set of crud operations which is create, update, delete. For all the different bits of data application deals with, you can describe it in that format if we know how to create that piece of data, whether that’s a calendar entry. Or an email. Or, you know, a user profile, a blog article and we map that in a series of scripts. Simple scripts you can GoScript in the same way, then the application will then the scanner can automate the flows, those flows so we can create a piece of data and it can edit that piece of data, it can delete that piece of data and it can run the whole cycle again. You know 10,000 times there are certain protections in applications where things like cross site request forgery tokens. So, when you’re doing a particular workflow in an application, one thing that you’ll quickly realise will stop you in your tracks when you’re trying to automate it. Is that the application might be generating tokens per request, so when you’re submitting a form it will create a new token. And if when you try and replay the next part of the flow with the token that you captured in the first pass, it just will get rejected. So, by automating flows in this way it kind of sidesteps those kind of issues where each sequence of those requests in that flow to buy a product on a shopping site or whatever it is and they’re unique values that need to be created and validated correctly each time. So, we use the scripting stuff to get around to those problems. But generally most people use it for authentication. And it also means we don’t need to worry about what kind of authentication it’s using, whether it’s you know it could be O-off, it could be some other single sign on thing, it could be a standard and logging form, but we don’t need to worry about that because we just run it through a script through the browser. And all we’re interested is in authentication. Ultimately, it’s getting the token that comes out at the end for that session, which we can then use for the other request that we make.

Holly Grace Williams: So, you talk about. When it comes to, I guess scanning but security in general, like raising this maturity level, is this something that you experience with your customers where maybe the first scan they do is very basic and then they start looking at things like authenticated scanning? And then there’s not looking at things like using Ghostscript to target specific functionality. Is that kind of the customer experience?

Nick Blundell: Yeah, that’s right. So, we might say somebody you know run an unauthenticated scan and see what you get back and then based on the results, you might either have a load of work to go back to the development team to fix a load of vulnerabilities, or you might find this does not very much found this, and then we would suggest running an authenticated scan and perhaps not with an admin user, because likely most applications an admin user can do lots of stuff anyway and potentially dangerous stuff, and that’s part of the feature of the application, so long as it’s only admin user they can do that, but we would recommend running it with like typical, you know general privileged users you know, low privileged accounts, self registered users, yeah exactly. And then we would build up and then. And then if we, we might suggest that you know there’s this other stuff we can map flows out in the application, you would notice you’ve got a particular part of that functionality that we wouldn’t be able to determine just with automation alone without a little bit more help in terms of a script that describes how to get through that flow. Once we have the script and by script, like I said before, I just mean a simple go here. Do this. Click this type. This that’s enough information for the scanner to automate all of the requests that that will involve at the lower level. Hopefully the HTTP requests or possibly, websocket requests and things like that, once it knows how to replay a flow and it could do that over and over again and we can look for vulnerabilities in those and then further enumerate the attack surface that we might not have seen without that flow.

Holly Grace Williams: So when it comes to authentication, one of the things that I think I often see get missed through vulnerability scanning, certainly like you mentioned earlier, for some customers that the right thing to do is have vulnerability scanning and then once everything is being cleaned up but like then look at getting pen testing so you’re not paying expensive consultants for finding things that you could have found more cost efficiently. One of the things that that I always kind of almost look for almost target ’cause I know that’s scanners are weak at finding it, is vulnerabilities like broken object level access and insecure direct object reference. How does the scanner handle those kinds of vulnerabilities where information might be exposed that is confidential? How is the scanner supposed to know that that is confidential?

Nick Blundell: Yeah, that’s a great question and it’s one that people need to ask more. I enjoy it when people ask that question. This is a good example where I said earlier that understanding the context of an application is important for identifying something as being vulnerability or not. So, what you mentioned was, yeah, directly accessing objects that should otherwise not be accessed by that user or even by non authenticated user. Now the interesting part with this is that if you consider an application that is a public blog, then in that application you’ll have a few bits of information but probably have blog articles, you might have documents, associated downloads associated with those and then you might have user accounts. Obviously to a human we know, if we were pen testing that application, we know that if we find a blog article when we’re not logged in, or if we’re logged in as another user, then that’s probably all right, because that is public information. So if we find that we can go to a particular path and say, oh, this is a blog article, we as a human, we know that that’s public information, so it’s not vulnerability. If we also found that I could go directly to your account page just by changing my URL so it had your username, ID, user ID in there, and suddenly I could see your private information. Then as a human, I know that I found vulnerability there because, there’s no and authorization checks, so there’s no check there to make sure that as my user, I can’t see another users private information, credit card details and stuff like that. So that’s an example where human intuition is required to mark that as a vulnerability. However, when I said at the start that we really trying to push as far with automation as possible, when we talked about the flows before the idea that we could map out a flow in the application with just by simple annotation to those flows, it’s possible to say that this data that we access on this flow should not be accessed. Other than by this user or potentially buying an authenticated user. And again, it’s just a little bit more information for the scanner so that it knows that this data that it’s seeing as this user when it’s scanning should not be seen by another user. There are cases where there are very strong signatures like credit card details, so you weren’t using expect those to be viewed by other users. And also we see we have some checks like for GDPR stuff where sometimes when we’re scanning we get some data back and we find that there is information in there like people’s email addresses and stuff like that and we can flag that as being potentially vulnerable. As you know that data shouldn’t be getting disclosed again, I won’t say that a scanner can completely do that, but I would say that by extending this idea of mapping outflows, given this kind of just a little bit more information about what could be potentially sensitive if it’s not got a very strong signature. If it’s not completely obvious otherwise, you just say if a user, so for example, if I had a firm that created a new user account and then I would be able to say in that flow when I create a new user account this data that we can see when we view that we meet when we look at the view step of that flow is sensitive and nobody else should be able to see that other than me or you know, maybe somebody else who’s logged in even depends on the application. And then if we replay that flow or just directly try and access some of that data outside of the flow outside of that session as another user, or there’s another thing unauthenticated user, if we see that same data, we can say this looks like it’s vulnerable. But yeah, that’s a great question and it’s one. Like I said, you with your pen testing background will focus on. These things because you know that these are the things that are hard to automate, like said and it’s because we need that intuition. We need to understand the context of the application to say either this data should be visible to anyone or it shouldn’t be visible to anybody. It’s private.

Holly Grace Williams: Are there other issues like that? Then when it comes to authentication in general, I guess maybe we should start a little bit back from that. Like what kind of issues do you come across in authentication systems?

Nick Blundell: Yeah, I thought it would be interesting to go over some of these because some of them were obvious and others, and so I’ll just explain a few different things that can go wrong for authentication to give people an idea, pen testers will be familiar with probably most of these, but clients may not be. So what might be interesting to start with? The most obvious things that can go wrong and then build up. The most obvious thing that can go wrong with authentication is if you don’t have a secure connection you don’t see that too much nowadays, but sometimes on maybe test applications or you know some. Some systems include an authentication for May submit credentials, and you notice that going over plaintext, so it’s not going over an encrypted channel, it’s not using SSL HTTPS

Holly Grace Williams: We definitely see that on internal applications where customers have kind of accepted that risk of “well, it’s only people in our network, you can see it”

Nick Blundell: yeah, which sounds scary to hear? Yeah, because yeah, it’s one of those things where it’s much easier to intercept network messages then people often realize, and that’s the most basic level that could just because it’s like a Wi-Fi network, which is fairly easy to intercept that plaintext data, but even on a wired network it’s there are many techniques for channelling that data to an attacker, so yeah, that’s one of the most obvious ways where things can go wrong. Yeah, you don’t see as much on the outside world now, but and as Holly said internally, yeah, I imagine there’s lots of this on internal kind of office, you know, back office systems and you know. And that’s yeah, so yeah, make sure they’e secure. I mean, on top of that as well. Sometimes if they are using a secure connection then it might be the case that it’s not very well configured, secure connection, it might not use signed certificate and it might be possible for an attacker in a similar way to man in the middle the credentials going over the connection and supply just their own certificate so they would insect in the same way. And if the if the client is used to always click in that box that says ‘do you trust this certificate’ then they’ll click it. The same when a bad guy intercepts it as when they don’t do so, it’s possible to steal credentials like that. I think the next one on the list properly is just easy to guess passwords, so if you have a password like password or password1 then eventually or not in not too long somebody’s going to break into that account, so these are the kind of things that we know really, that you know you should have a decent length password with decent level of complexity because it makes it so much harder for people to guess those passwords. But then on top of that, even if you might have good passwords, or you might have the most obvious password next.

Holly Grace Williams: Yep, just before we move on past easy to guess passwords. I’m curious, how do you handle things like the potential for account lockout? So, I do, you know, pen testing where I’m going to try all of the things that you mentioned you like. Password1 I’m going to try Summer 2021. All of those kinds of things and I can, looking at application responses, determine quite effectively whether I think there’s a lockout system there or not. But how does this scanner handle that?

Nick Blundell: No, that’s a great question, and that’s why in the scanner it will be an optional thing to do that because the last thing we want to do is start bruteforcing passwords before we’ve even scanned the application with the credentials that we do know and then lock it. Lock out an account. So yeah, that’s a great point. Great question. We would make that, so we have an option that says do you want to brute force passwords and if the client is happy based on their knowledge of the application to do that, then it’s a good way for finding those simple passwords. But yeah, you absolutely don’t want to lock yourself out in the scanner by doing it. You know by default, I guess

Holly Grace Williams: Yeah

Nick Blundell: Yeah, and it’s another one where in you know pen testing is good looking at those kind of things

Holly Grace Williams: I’ve counted that and what I’ve counted that with is sometimes with engagements with customers we have maybe discovered the fact that their response to certain attacks as may be inadequate. I can think of a customer that I worked with last year where, during an engagement, we came to the point where discovering that they effectively could not detect when brute force attacks attacking place. I’m sure the technology could just nobody was paying attention to it, so we ended up running a brute force attack for four and a half days before we successfully gained access and that was wonderful and we brought the premier, and it’s a great vulnerability. But I think with many pen tests being so time limited, you know it could be easy to imagine that you wouldn’t give that function that focus whereas, one of the benefits, of course of scanning is, well, it doesn’t matter. It’s not like a human sitting there doing things, so I almost feel like yes, there is a weakness with automation where you might lock something out, but there’s also a strength with automation where that thing doesn’t need to sleep.

Nick Blundell: Yeah, I know, and that’s a good point for why it’s a good idea to have that option in there, but make sure that people are aware of the pros and cons of doing it. But yeah, definitely. I mean the other thing that happens just as a side when we’re doing scanning is that the noise that we can create scanning because we don’t try to be stealthy, at least not by default we’re not trying to be stealthy, we’re trying to find vulnerabilities quickly as possible, and sometimes that can trip IPS systems and stuff and you know that just block the scanner. But that’s really something that we usually work with their clients to sort it out to make sure that doesn’t happen, because once that happens, it’s it basically stops to scan from succeeding. But we do detect that as well so that we do flag if it looks like we’re being blocked by a system like that. But yeah, the other thing on, aside from scanning just talking about blocking accounts and stuff like that, is that sometimes the, you know, there might be a system in place so that if we are trying to brute force credentials so we’re looking at doing making thousands and 10s of thousands of requests or more to look for known passwords. We might find that the application starts blocking us, but we might find that the if you look at the application more closely you might find that it’s actually blocking us on an IP basis, so our IP address is being blocked. But then if we log in as a valid user account. That we know is about it can sometimes reset those filters, so it’s possible to keep to keep brute forcing, so this that could be a floor in there to blocking system. It might be the case that some logic in the application that says if this person keeps guessing false password just block their IP address, but then if it lets us, if it finds it, we do log in with a different user with a valid password. It might say actually this IP address is fine, so unblock it if that makes sense. So then you could imagine interleaving them and that that’s again another area where we would like to automate it. Because it’s like you said doing that stuff by hand is tedious and if we could, if it were the case that we found that was happening then we might be able to just keep a valid account logged in to keep our IP address and getting blacklisted. But this is more of a rarer, I guess, vulnerability and it’s one that you would probably want to identify the way it was working. You had talked to the client about how this could be bypassed and how it can be fixed. The other kind of things that we do often see go wrong with not just the authentication, but we do, it can be a quick way into an application is if there is a some kind of database injection within the actual logins so when we type username or password in we might find if we put some crafted payloads in there, we might find that that input is not being validated when it’s being compared with the records for that user in the database.

So we might get an injection into the database and this is a classic scenario where you can just bypass the authentication because you can manipulate the logic of the database queries. So rather than saying if the username is this and a password matches the database, we just bypass that with some kind of SQL or no SQL injection that says no, just all true you know, or one equals one kind of thing. We just say a lot of straight in regards for password, so that’s another common thing that we see go wrong. Another thing that can happen and we see occasionally is just having week session tokens. So just to explain what session token is, if there are aware when you log into an application it’s not usually the case to every request you make back to that application, supposing I’ve logged into my banking application or Facebook or whatever it is, I don’t need to keep posting my credentials and my browser doesn’t need to keep posting the credentials. What happens is? The first time you log in, you’ll be issued through one of many different mechanisms. You’ll be ultimately issued with a token, and it’s the token that you just pass back in each request to the application so it knows it’s your session token and it knows who you are because you’ve logged in and it issued with that token, and the whole premise of the session token is that it shouldn’t be guessable. It should be something that is random and somebody can just pull it out of the air in guessing, otherwise they would effectively have taken over your session so the session token is issued when you login with your credentials. If you put Father credentials in, but there are certain vulnerabilities. It can raise and common examples of this are one that I’ve seen quite a few times really over my time testing is just where you have a time based token, so you might find that when you log in you get this. It looks like a random number, but it’s some sort of timestamp and and just to there’s, rather than generating a truly random ID for each user when they log in and somebody must have through oversight, they just thought, well, we’ll just take the time that we’re voting. ’cause that’s going to be fairly unique for each user, you know, down to the nanosecond, or whatever, whatever it is, and they will just use that as a session ID. But the problem is, once an attacker’s realised that’s what’s going on the search base for a valid session of somebody is logged in recently is very, very easy to find. So if you have a session token, it’s based on time in some way. Sometimes you might find a username is appended to the timestamp or something like that, but this is a weak token and it can be easily compromised.

Holly Grace Williams: I’ve seen a variation on that as well where the developer had used the system up time instead of the current time, which is bad if the server ever reboots and then it’s very close to zero.

Nick Blundell: OK, yeah, yeah, so all those kinds of things. They make it much easier to find vulnerability. It’s just a random long number. It’s going to be pretty hard for somebody to guess it’s gonna take him a lot of attempts and it’s pretty easy to do. The other thing that sometimes happens with session tokens is you might find that in some applications have, I don’t see it so much now, but to save people logging in over and over again with their credentials every time it expires, they have like a ‘Remember Me’ feature and when you tick the box it says Remember Me, it just keeps you logged in for a bit longer and it might give you a different token and you might find that the normal session token is a random generated. Pretty hard to guess value, but you might find the Remember Me cookie that’s been used as an alternative for the authenticated session is much easier to guess, and so there could be a weakness that’s introduced there as well, so I think whenever you whenever you’ve got multiple alternative session tokens that are being used by an application, then you need to look at all of them to make sure that one of them is not weak, ’cause that would let you in. Another one that probably highly imaginative, Holly spent a lot of time looking at these things, but when you look at authentication you might find that your authentication itself there checking credentials is really good and it does everything it’s supposed to do, it’s got good tokens, but then you go over and look at the other page. It says forgotten password.

Holly Grace Williams: Oh yeah.

Nick Blundell: Think, supposing I forgot my password, how do I reset the password? Because if I can find a way to do that as an attacker, I don’t need to know the original password. If there’s a flaw in this side of it. So, the other side of the authentication is the forgotten password feature and we all need the forgotten password feature because people always forget their passwords, the forgotten password feature. Well, they often work in similar ways, but it’s common that you might find that there’s a place in there where you can put your email address and it says, put the valid email address of your account in here and click submit and we’ll send you a password reset email to tell us how to find your password again. There are a few things that go wrong here. One is that, uh, I don’t see you so much now, but sometimes it’s possible that when they’re forming the email that’s sending that email that they’re just taking the input you supply in that field for the email address and they just bang it straight into an email. And what can happen there is if you then you can delimit the email and add an extra email onto the end. Maybe the attackers email so usually that she’s using a semicolon or something like that. So if I put the email address of the victim that I want to get their password reset for and I know it’s going to send an email to them, but I wanted to send the email to me that tells me how to reset their password, so I put a colon on the end of their email and put my email address in the end and then the email gets sent out to both email addresses, which is a really, it’s a nice example of you know these, it’s kind of a yeah, it’s a weird kind of attack that can be for developers not to even consider, but similar to that is that even if even if it works, even if it emails just to one email address and it will, only it will check the account, it will say. We’re only going to email to the user, that is, you know, on this system their mail address as they registered. Then we might find that there are other things we can do, like not to go too much into detail about how it works, but when you send a request to a web server you include, there’s a few headers in that request, some meta information about who you want to talk to you. There’s a header called host, and this related host headers that can also be used and in the host header, when you send a request to a server, in most cases it will be there, it will be you expect it to be the host that you’ve got in your browser. In your URL, when you’re looking at applications, so like facebook.com or something like that. And when you make a request, your browser automatically will add this host header, but it might turn out that the application is relying on the host header that comes from the request, and when it’s building other requests like building, for example, when it’s creating the email reset link, it might use a host, that comes from the request, which of course anything in the HTTP request, the attacker can change, so if they change that to a malicious host, the one that they control, it might be possible to trick the system to send the reset code to the attacker server for that user, so that’s a nice little trick that can sometimes be used to steal these password reset tokens, and as soon as we’ve got that token to reset the password, we just need to follow that link or put that token in some way and we can change the credentials for that user and take off their account. Those are kind of things that can go wrong with forgotten passwords. I had one cases where an interesting case of, interesting to see if you’ve come across anything like this Holly, so it was a it was a single page application, so you know JavaScript rich application and had an API when you did the password reset, it triggered an email and sent that to you, but the API actually responded with the token. It was like it had been implemented so that when you did the password reset, whoever you were that did that password reset. If you looked in the API response that came back, although it’s not displayed on the page, you’ll see there’s a JSON payload and it’s got the password reset token in the API. So you can just copy that as an attacker, put that into your browser, it was just the link to reset the URL the password and you could take over their password. I imagine that was in there because when the developers were testing the application, they probably didn’t have the email system set up or it would just be too laborious to do their unit testing on the password reset feature if they had to go and check an email system and stuff like that. So they just had the password reset link in the response to the to the theme. And yeah,

Holly Grace Williams: I’ve seen that kind of issue where organizations are trying to automate their testing, so it’s not necessarily that like it was a test feature that was put in there and then forgotten about it. It’s like it’s in there intentionally so that they can automate through that step so they don’t have to write automation code that reason email, and I guess it’s one of those things where it’s just like you know the developer have got their make it work at on as opposed to make it secure hat it’s you know, you can, you can understand where it comes from when, when, the context of what you’re looking at is quite restricted.

Nick Blundell: Yeah, and it’s one of those examples to where it would be difficult, I mean, we’ve got signature checks for stuff like that now in the scanner, but it’s still difficult to know if it’s if it varies from that strong signature, it would need human intuition probably to know that that’s actually the token coming back from it,

Holly Grace Williams: Yeah

Nick Blundell:  You know, it could just be saying, well done, we’ve done it, or you know. But actually to include the token in there, it’s where the boundary between it being vulnerable and not available. But yeah, that was interesting and that was interesting with that one, is that a later after finding that I went to look at the documentation for the API and it was also documented to return the token so it had been completely overlooked as a vulnerability. Like you said, probably because they were focusing on work. I’ve got screenshots of that because I can’t share those, but it was one of those cases where it’s so easy to, I mean otherwise that application that I looked at was perfect. Everything done correctly. Apart from that slip up, so it just shows you how sometimes these things can slip in.

Holly Grace Williams: I think that is that is a big point to make that you know, very often when we’re testing applications, it’s not the case that every input is vulnerable to everything or you know, look at look at things like SQL injection. It’s not like every input is going to be vulnerable to SQL injection. It’s just like one of them screwed up at some point. You know someone had a Friday afternoon or a junior was looking at it or they just made a mistake in one instance.

Nick Blundell: You know, and I’ve seen things like that, and I think with, especially with database queries, I get an impression when I’ve looked at code related to those for abilities that some things, sometimes the shortcut is much faster than doing it the proper way, and when there’s a complex query and they just know how to write that, they just know how to do that directly. You know, it would take 5 minutes to implement it, and they go and do it without the proper kind of parameterized queries and stuff, and it. And it like you said, just that one slip up opens a whole application up to data and other data being stolen and stuff so. But, this is why we we’re doing this, I guess This is why we’re talking because we want to get people as close as possible to, you know, they get rid of all the more of your stuff and then we just find these little instances and they fix those. And then it makes the whole thing more secure, and also testing regularly. You know, because when new functionality is added to an application. That’s where something that was otherwise pretty secure, you know there’s been a maybe a new person do the code or they they’re not too familiar with how the different parts of the system interconnect, and so they make the wrong assumptions. And certainly a vulnerability gets introduced.

Holly Grace Williams: Yeah, or sometimes, sometimes things just change, don’t they? It’s like they’re focusing on a different feature. They make a change to enable that feature, and it causes a weakness elsewhere.

Nick Blundell:  Yeah, well, that was my other theory for that API disclosure of the reset token, the password reset token was that this could be a dual-purpose API that is also used internally by another system that, it does a reset and it takes that link from the response and it sends email out. And that might explain why the API does that, but then it just happened that also got exposed to the public.

Holly Grace Williams: You talk about systems being changed as well. I’ve had it before with customers on pen tests where we have done a pen test for them and they have had a significant vulnerability, the example I’m thinking of was actually command injection. They fixed that vulnerability. The retest has confirmed that it’s fixed and then later on down the line it’s been reintroduced. So that instance I’m thinking of was that the patch broke something else that was unexpected. Obviously was rushed through because it was such a critical security vulnerability, so they actually just regressed that patch. They just. Rolled it back to fix the functionality without realizing that that also reintroduced the vulnerability.

Nick Blundell: Yeah, I can imagine that. So easy to do and another good reason why just do things regularly. And also you know where possible, integrate it with your dev cycle so that if that change was made that regression, then you’re scanning, based on, you know a nightly build or whatever you should spot that thing that regression before you even push this thing out to production, which is good so you know all these kind of things where like we said earlier, start with the basics and then push it, push it and push it, further and further integrate it with your dev cycle if possible, and then you know you really your finding knows them vulnerabilities before they even go out, which is good. But yeah, it’s the thing with code, I mean we’re both coders as well and we know that dynamic fluid nature of code and some days you write better code than other days. Some days you rush things, someday some things just take a long time to learn and a lot of experience to learn. And you think you understand something and then you might find a year later or something that what you thought you understood is actually it’s not the full picture, you know it’s, people are always learning and it’s that’s the fluid nature of code and also code is never perfect.

Holly Grace Williams: Code, code and infrastructure. I mean this is, you know, something that that we see within cloud environments at the moment. You know, you might learn how a system works today and integrate with that third party service with how it works today. And it might just be changed.

Nick Blundell: Yeah and just to talk about, there’s a few more things that can go wrong with them with authentication and one of them that we often see as well is where it’s possible when a user can change that password, it’s usually good practice to expect them to put their old password in before they can change their password, and the reason is because all too often we find when we’re testing applications that it’s possible through an attack called cross site request forgery to update users password by tricking them to visit a malicious page and you find that it’s possible to just change the password to a known attacker password and then take over the account. And the reason this works is because the attacker can trigger a request within the victim users session from outside from a different web page. It’s easy enough to do. And it is. It sends a request, it doesn’t need to know the old password, so it just sets it to the new password that the attacker controls and those kind of things happen and related to that as well that we sometimes see is that if you if you log into an application and you go to change your password, you might notice something strange like when you you’re logged into application already, so you would expect the application knows who you are, without you having to tell it again who you are. And as a pen tester, whenever you see a request be made to do something especially to change someone’s password that also has a user ID in that request of my user of me, and then I wonder why it doesn’t already know that because I’m already logged in. It should know that ID. And I might find if I change that ID when I’m resetting my own password to another user ID, it might complete the password change, but it’s a different user, so we switch. We tamper the, we tamper the username or user ID in that request, and we can change somebody else’s password. So those are kind of things that we sometimes see.

Holly Grace Williams: One thing on our across that request forgery I mentioned earlier that as a pen tester, I specifically target vulnerabilities that I know that scanners have a hard time looking for. With cross site request forgery, one of the reasons that they like that vulnerability to target is the fact that it’s no longer in the OWASP Top 10 and I think there’s a lot of companies who focus on the OWASP Top 10 not as a starting point, but as security in its entirety. So where vulnerabilities have fallen out of the bottom across its request forgery it’s no longer in the OWASP Top 10, my understanding of that is because it is now less frequent, kind of sometimes gets forgotten about.

Nick Blundell: Yeah, which is always, because when we talk about the OWASP Top 10, we always try and you know, we say, well, that’s you know that’s good to know those vulnerability classes, but there are vulnerabilities that you need to watch out for just ’cause they’re not listed. And yeah, this is a good example, because you might find that what’s up there on the OWASP Top 10 is there is a particular vulnerability that’s in a particular context is not actually that serious, as it might seem at first, but then something like a CSRF, the ability to change somebody else’s password would be highly critical vulnerability. So yeah, it’s one that we always look for when we’re doing pen testing. We do have, it’s another good case where it’s difficult without understanding the context, because we might find that there are certain things you can do. We’ve crossed that request forgery in an application that don’t actually lead to any advantage to an attacker, and we wouldn’t strictly say that’s a vulnerability because there’s no integrity lost there. But when it’s changing a password, then it is clearly a vulnerability.

Holly Grace Williams: This is a really good point actually ’cause we struggle that with that very often, within pentesting reports, because the way that I tend to describe that within reports is cross site request forgery in non sensitive function and try and try and make that distinction. But sometimes you could have you know a single application that has two issues highlighted one that’s like informational and one that’s high because it leads to account takeover because we might still want to report that functionality of the application in its entirety, lax cross site request forgery, because it could be a sign of, you know they’re not following best practices.

Nick Blundell: Yeah, and it’s usually easy to avoid them. I guess across the board if done at like a framework like I guess, or something like that. And another place we often see that you’ve probably seen the same is where you have, there are certain things that you can do, like voting, you know rating products and you know, deleting things, maybe even deleting user accounts where, because it’s seen as such, a simple action that there’s no check of a cross site request forgery token, so you might find that you’d be able to trick another user to upvote or downvote product on a page you know like under their accounts and things like that.

Holly Grace Williams: I saw I saw one of those on a dating application a few years ago. Interesting applications to access where there was a feature built into it that was effectively like. I like this person. This is a trustworthy person or whatever and you could upvote that profile. I guess it was, you could imagine a feature like that to avoid scams on those kinds of websites where they might say you know I’ve had a good interaction with this person upvote them and that and that was the same thing where you could, you could cause other people to avoid your profile and effectively, you know, legitimize your scam or whatever it was you were running.

Nick Blundell: Yeah, and I think that’s quite topical at the moment. The whole discussion about fake reviews, isn’t it, and so yeah, I mean, I imagine there’s lots of scenarios for cross site request forgery where it’s possible to adjust reviews. You know, and things like that, but yeah, it’s interesting. The other thing that we often find is the ability to, like I said before, you might find you can switch another users and password by starting the process to change their own password, then switching user ID and A similar thing can happen with any feature that lets you edit your user account. There’s something I’ve seen quite a few times is where within that if you’re an admin user, you’re able to adjust users’ roles so you’re able to say this is a low privilege role. This is another admin user or even a super admin and you might find it’s just a case that that field for it for a low privilege user is simply hidden from the form, but it’s still present and it’s still processed, so you might find that when you edit your own account and if you add an extra field or you might notice this one hidden that says role and set that to the value admin or zero or however, it processes user roles. You might find that you can make yourself into an admin and I always talk about one where it was another example of an application where it was pretty much implemented perfectly in the sense that I couldn’t find anything wrong with it. But then I came to edit my user account and I found that you could change user role and it was possible to set that to super admin and when I logged in after doing that I found that I was the only super admin with lots of admin users underneath my account and it’s you know it’s those little things that can you know, slip up and that’s because you can imagine it that the same code that’s letting me edit my user account is the same code that lets an admin user edit and other users account and switch their roles. And because it’s got that common code and it’s got not got any, obviously didn’t have any check in which role I was, it would honor that value if I added it to my submission. And so it’s, yeah, those kind of things. I think just before I, it’s just because we started talking about different authentication vulnerability and I hope people find it useful, but one that we see a lot more now is things like using Oauth. So, this is like a third party authenticator where for example you can use your Google account or your Facebook account to access the user account on a different application and just to save that application having to track user accounts for every user on the planet they just integrate with a third party authenticator. Without going into the details of that, what it usually means is when I go to log into this application that I’m looking at and when I click login it might say social login and I click social login and it takes you to Facebook to log in. I put my Facebook credentials in and then it says do you want to allow this? We’ve all seen similar things. Do you want to allow this application to access your user profile? and you usually click yes and once you’ve done that application, these other applications or not, Facebook is now using your Facebook profile as your user identity within the application, which is good and it makes sense. But it also means you don’t need to remember loads of different credentials. Stuff like that, so it’s got benefits. But it’s often the case. I mean, you can think of the third party authenticator and then the main application and the main application is trying to get the user profile from the third party to use in its own application and in the exchange of, in the message exchange involved in doing that in setting up that process, if you look at the background request that your browser is making and usually you find that the Oauth server is usually pretty well tested and you’re not really looking for remote vulnerabilities on there. Or sometimes you might find them, but you’re looking at flaws in how it’s been implemented, in the application. So how it’s treating the values that are coming back from the Oauth server? There’s a few different workflows that that you can use with Oauth kind of authentication to get ultimately to get the token and to get the user profile that you want to authenticate with. And those are I won’t go into that now, but there are all different kinds of things that can go wrong there. Things like manipulating redirections of where the token gets sent to when you authenticate to, perhaps sending up to an attacker controlled server. You know sometimes certain bits of information are omitted from those requests similar to cross site request forgery tokens and if they are admitted, then it might be possible to complete another user authentication to bind an account to your own account and things like that. So sometimes we think that because we’ve got a third party authentication system, then that’s going to be all fine, but it can turn out that if it’s not implemented correctly or certain things are overlooked then vulnerabilities can rise in those as well. I think that’s just to give you an idea of the spectrum of things that can go wrong with authentication, which is an interesting area because like Holly said right at the start. It’s the way that it’s the gateway into the application, authenticating it and it’s the thing that protects sensitive data that belongs to one user from other users being able to access that, whether that’s their credit card details or any other private data they don’t want to be seen. So, yeah authentication haha. And yeah, I mean there are a few other error cases are probably not going in to this. There’s one of the case that we sometimes see, and I’ve not seen it that often, but I’ve seen it in code and I’ve done code reviews and this is the idea of a fail open authentication logic scenario and this is a kind of a textbook thing that you when you don’t often see, but you can imagine how it happens. So if you imagine a piece of code where all it’s got to do is check that my username and my password match that in a database to LogMeIn. But it might just be the case that the way it’s implemented says “OK what’s username password?” So, I submit my form with my username and password and it says what’s your username? Nick. OK, I’ll look in the database and I find Nick, yeah that’s a valid username, so I pull that record out and it might be the case that it then sets the username Nick on my session so it’s found the username Nick to my session and then it says right. “I’m going to check if the password is correct,” so I’m going to take the password that was submitted by the user and check it with the database record. If it finds that it’s not correct then it might then say no, “this is wrong password,” so we’re going to unset Nick from his session so it this isn’t Nick logging in and this is somebody else, but the question then arises because that’s done in those two steps because the username is bound before the password checks, supposing it can trigger an error to happen by putting in a really load of awkward text in one of the fields, you know the password field, for example, so we cause it to crash and if it crashes before it does the password check, it might just bail out then at that stage, but it’s already set the user into the session.

Holly Grace Williams: Yeah, I can tell you. I can tell you where I found one of these. Which was it just an interesting vulnerability and you can imagine that the risk would differ greatly was actually in a mobile application where when you open the mobile application it presents you a login box, username and password and you send that request to the server and the server will validate it or not. And then the server would send back a session token. But it also had a boolean which is effectively like logged in equals true type thing and if you intercepted that request from the mobile device and you know give it, give it bad credentials, intercept the request and then just change it to logged in equals true. It of course wouldn’t authenticate you against the server so you couldn’t access the users account details ’cause of course the server knows that your authentication was bad, but what it would allow you to access is anything that the device had cashed.

Nick Blundell: All right. OK yeah, that’s interesting.

Holly Grace Williams: So you track the device into kind of letting you pass the login box to see what was cashed. So it was an interesting vulnerability, and I guess it’s just like as you said, there’s just such a range of ways that it can go wrong.

Nick Blundell: Yeah no, and it reminds me of the things that can happen with two factor authentication, which is where you know we say two factor authentication is good because having two secrets and preferably one on a different device that proves that you own it. You know particular device is useful, but it can happen in that case where if you imagine how something might implement a two factor authentication scheme so they take your username and password and they validate that and say are you Nick and is your password 123? And if that’s. True then it says good, you’ve passed that stage and now I’m going to do the two factor check. I’m going to say right? What’s Nick, get Nick’s token generator up and generate a token and check that he knows that token, but it might be the case that whether I passed that next test or not, my session has already been effectively authenticated in the first step. The cookie that I got then, although if I follow the process to the browser, you might redirect me and say sorry you failed the two factor test. It might actually turn out that if I just skip that part and just go straight to my main page is that I’m logged in as that user. So it turns out that, you know the two factor part is only done superficially.

Holly Grace Williams: You could imagine that coming about if an application had simple username and password and then they added on multi factor. You could imagine a mistake like that being made.

Nick Blundell: Exactly. Yeah, so it should be kind of, we often talk about it being as far as like an atomic, it should be an atomic process like with that fail open logic I mentioned before. It should be done as one step that either succeeds or fails altogether. Yeah, so these those kind of things, another one last one I’ll just mention not two more ’cause they’re interesting. I’ve got this idea I thought about talking about.  So another one that we do sometimes see and I’m adding you seeing these two is where you have. I don’t know how to describe this one, but what happens is it can hear that happen when you’re authenticating that you get you type the wrong credentials and you get redirected and it says go back to the login form and you actually find that in the body of the response that redirected you has all the data that you’re trying to access, when you authenticated. It’s just the redirection that took you away from it.

Holly Grace Williams: Yeah

Nick Blundell: See you script that you ignore the redirection and you just go straight to the data you know you’re effectively logged in. It can happen with where we find where authorization checks, so you might log in as a user and you might not have an admin privilege, but then you go to the admin page and it says, it redirects says sorry you can’t see this stuff.

Holly Grace Williams: Somebody might listen to this and think how on Earth could that occur? And I’ve seen it with PHP for example, where a redirect in PHP just sets the location header, but then the rest of the code will continue to be processed, so you would effectively need to redirect and then exit or something similar so that they know further processing is done. Yeah, I’ve definitely seen that in PHP applications.

Nick Blundell: Yes, so it’s another example of the weird things that can happen. And yeah, it’s all interesting stuff. The other one, the last one I’ll mention, is sometimes you might have a perfect system otherwise, and you might find that you’ve got cross site scripting on the login form, which might mean that you can send to monster login form of their application with a payload cross at scripting payload, which I’ll just explain, it just means that the attacker is able to inject a script on the page. And what they can do in that scenario is at that stage they have not logged in, they’ve not got session and it’s created and they might only find cross site scripting vulnerability on the login page, perhaps as it sometimes you see it as an error message in the login page that you can reflect the error message from the URL back in the page. So the attacker might then be able to send you a link to log into your bank, for example with their payload kind of snuck into the URL and when you click on it, it injects the attackers scripting there that replaces the form processing so that when you click login with your credentials it sends the plaintext credentials that you typed in to the attacker, which is again, is another way of snatching credentials. So, if the rest of the application was implemented pretty much perfectly, if you had that cross site scripting, vulnerability on that log in form it would allow them to take your credentials. I think this is one that we saw on I can’t see British Airways or some booking application where it was possible to inject a script into the payment card form and the script was basically scraping peoples credit card details as they entered them in the form and sending them off to an attacker.

Holly Grace Williams: British Airways breach that they recently got fined four with similar, that was a vulnerability where they were loading JavaScript from a third party location but didn’t have subresource integrity enabled. The third party system was somehow compromised. That script was modified so the impact is very similar to cross site scripting, but really it’s resources without SRI. That was the issue.

Nick Blundell: Yeah yeah

Holly Grace Williams: But you are right. Yeah, let them scrape payment card details, which is like a powerful vulnerability.

Nick Blundell: Yeah, I’m, I’m just thinking you know that that’s we’ve covered a bit about the kind of things that could go wrong with authentication. And we can talk about some of the strange things to do with scanning authentication.

Holly Grace Williams: I think what what people probably want to hear. Now that you know, we’ve got this far through this discussion. We talked about the pros and cons of pentesting versus scanning, and then we talked about how authentication systems can go wrong. There’s a huge number of issues that you’ve mentioned here. I think what people might be interested in, which ones can scanners pick up? and which ones need to go to the humans?

Nick Blundell:  So I mentioned before that where this is strong signature. So we talked about the ability to change a password. The user’s password through cross site request forgery, which means the way that works is that we find that the application has a feature to change your password, but it has no prior check if it has no check of any prior knowledge of what the old password was, or any other knowledge of anything that is needed to submit that from other than a new password. And if that’s the case, then that’s a fairly strong signature that we can pick up in a scanner because we can say this looks like a password change form and we don’t see any of the tokens going into that form. We don’t see any, you know, any request for a prior password so we can flag that as a vulnerability and we could exploit it as well. In some cases just to confirm it. But yeah, it’s a good question. I mean, some of these things. They do need human intuition, really. I mean there are there are other things like checking things like user registration, you know can you? There are certain things where, for example, you might find that you could register an account with a duplicate email address or something like that to compromise and other users account.

Holly Grace Williams: I’ve not seen that in a long time, but I can think of one example where you could. Specify an email address with white space at the end.

Nick Blundell: Yeah, yeah, those kind of things, and then you can imagine that it might go into the database and then one of the accounts will have precedence by the ordering of, you know the data in some way so that one is able to access, you know, they somehow they mix up the accounts.

Holly Grace Williams: The way that it worked. In that instance, I’m thinking of it was effectively a denial of service so I could register an account with your username and then you could no longer log in because the new account with tech precedence and of course the new account had no data in it.

Nick Blundell: Yeah. But no, in terms of finding authentication vulnerabilities I’d say, generally this is an area where we can find some stuff and that’s based on strong signatures, and that’s an area where if I was a pen tester, or if you were, you know, wanting to get your application tested, you would really want a pen tester to look at your authentication flows and you know the whole thing together, you know, the password reset stuff. You know anything else in there the two factor stuff. If there’s any Oauth stuff you know in there, you’d probably want a manual pen tester to look at that stuff. We do detect stuff, but it’s based on signatures and things like that. So and it is an area where, like I said with the flows by mapping out an authentication flow, it’s possible that we could annotate it and to tie those together in the scanner to help find certain vulnerabilities. I mean what a simple example of one that we can do by mapping and authentication flow is that if we if we not only map the way that we log into the application, but also how we log out of the application and then the scanner can do things like it can analyse the login process and say I can log in with this user and then I log out with that user, but then it can do stuff like checking if did the system actually invalidate the session or not, or is that session still live and so although I did the log out through the browser and might find the session is still live and so it wasn’t invalidated so we can flag that.

Holly Grace Williams: That’s super common and as you say you know quite a good one for a scanner to check and get, get a strong knowledge that like yeah, this is definitely vulnerable and I very often come across people who think. Why would that be a vulnerability if I log in and then the server doesn’t log me out server side? I think one of the things for anyone who’s listening in, it’s just the sheer number of shared devices that we have now. Like you know, you want to check something in your account so you log in on a friends device or something like that. You log out thinking that is secured your account, and of course, if the server is not, you know, actually enforcing that, then it hasn’t secured your account.

Nick Blundell: Yeah, yeah, I mean, most people would assume that when they click log out there session is now invalid.

Holly Grace Williams: Yeah, very common issue in my experience

Nick Blundell:  Yeah, but yeah, this is an area. So my two main focuses in on the research side of scanning is in. You know one is in authentication. Not only not detecting vulnerabilities, but even authentication itself is a challenge. So when we look at scanning an application, if we if we’re doing an authenticated scan, then there are lots of things that can go wrong in terms of scanning it. We could easily get kicked out of our session. I talk about the recession killers, so aside from the log out there might be lots of other ways that can kill your session when you’re scanning it. If you if you send something the application doesn’t like, it might just kill your session defensively and you know there are there other, if you, if you go back to the login form when you’re logged in, it can kill your session, sometimes. We see this a lot with single page applications, so very JavaScript rich applications that you expect when the users using application they’re using it on a single page and all of that stuff. But when we’re scanning it we kind of accessing their application in different ways and we might be, we might be doing lots of things at once with the application and one of those things might invalidate as another session that we’re scanning. And the problem with invalidating sessions during scanning is that if this keeps happening during the scan, then we have a very high session churn which, which means that the scanner has to keep constantly logging back into the session, and the more we have to do that, the less time or less confidence we have. That when we’re doing our checks, they are actually accurately within that session.

Holly Grace Williams: Imagine, it can just really slow you down as well. If every time you want to send a request, you’ve got to go and re authenticate again.

Nick Blundell: Yeah, so this is we do a lot of analysis during authentication up front of the scanning to try and figure out how stable the sessions can be. And also something that we’ve talked about before, but the this you know, I call them exclusive sessions where or exclusive lockout sessions being the worst one where if you log into an application as you use it, and then you also look into that application separately in another browser. Your new session invalidates the first session because the application doesn’t support concurrent sessions for that particular user. So, what you find is if you’re scanning an application and you want to do lots of requests in parallel, maybe is with that same user. And if you’re creating separate sessions, they just constantly invalidate each other so we do analysis up front as well, to say whether it appears that the application allows user concurrency in sessions, and if it doesn’t, then it affects the way we, it doesn’t mean we can’t scan it, but it means that we don’t try and scan it with multiple sessions. We use one session, and we share it and if that becomes invalid we restart that session. But if we tried to use multiple sessions at the same time, they just all invalidate each other and it would, you know, be chaos.

Holly Grace Williams: Yeah

Nick Blundell: So, there’s all those kind of things and this this secondary token sometimes you know authentication that aren’t obvious at first. That things like CSRF. Sometimes you have session bound tokens that also must validate correctly for a particular request to be made, and if we’re not tracking those accurately in the scanner, then we might find that although we’ve got the maybe the cookie value or the authorization header correctly set for each request that we’ve missed off another token that we didn’t anticipate, and that might mean that certain requests effectively aren’t really authenticated. So there’s lots of those kind of things that can happen, and just some weird just some very strange cases where an application that I looked at recently, where you log into it, it looks like any other application, you login with your credentials, but then you start watching the requests in the background and you see that on for some requests it uses a one token name with the same value and other request it uses different one like you might say Web token might be the parameter name in one request like a get request and in a post request it might be like session and it’s the case that the application might be sticking these tokens in all different places and sometimes I mean unnecessarily in the same request it might send two tokens together, so we’ve got to account for that stuff and not let that stop, you know, cause the scanner to stumble.

Holly Grace Williams: Yeah, got to account for unexpected weirdness.

Nick Blundell: Yeah, like I said at the start, there’s the textbook security stuff you know and there’s all the RFC’s on how certain things work. But then when you start to look at real applications you find some strange things. There was another example where the session token was actually, most session tokens, they’ll have a be a cookie called session. Or you know, yeah, an authorization header or something like that. And in this particular app it had a dynamically generated token name so that the token name was like a random number and the token value is a random number and every time you logged in it got a random number for the token name and a random number for the token. It was just. Yeah, it’s hard to understand why those things you know happened. It’s like the PHP redirection case you mentioned. How does that happen in the code? How? How is that being preferred as a method of just having a standard token as the name token?

Holly Grace Williams: And it’s important it’s important to understand that stuff because you know you might find one example of a vulnerability, that has some quirk to it, and then you know giving that information to the customer might enable them to go and look through the rest of the code, or even to the products that they’ve produced and find similar issues once they know what the issue looks like in code. Yeah, so it can be tricky to actually apply authentication when scanning, and the picture is much harder than just thinking that, I mean, there are two sides of authentication as well. When we talk about scanning, there’s actually like we said at the start with the scripts, the idea that we can, we can write a simple script that tells the scanner how to log into an application. The second part of the authentication, is being able to analyse that and understand exactly how the tokens are being issued and used in requests. And like I said, some of some of that can be very strange and not apparent at first, and it might be the case that you’ve actually effectively scanning with half the requests authenticated, but the other half are requiring some other token that you didn’t account for. Yeah, it’s a little bit more involved than it might seem at first, and then, so this is an area where we focus a lot of attention.

Holly Grace Williams: That should be a good thing for customers to know that your product and your research team and not just sitting there saying. Well hey, the scanner is pretty good. We’ll just we’ll just monetize this now. But you know you’re actively researching how to more effectively do this stuff.

Nick Blundell: Yes, so we use our software ourselves to our own research. So, from that point of view, aside from the fact that we want to, we do want to give the clients the best service that we can provide. But we are also wanting to like you said, when you’re when you’re testing stuff, the repetition of certain tasks to find vulnerabilities is so high that you don’t want to sit there doing it manually. So, we use, our own tools, and we develop our own tools with our own research in mind. And you know people that use our scanner, they benefit from that because we don’t want to half authenticate an application where scanning it. We want to make sure that if we are, if we’re spending the time to find the attack surface by crawling it, which again is a whole of the area, how to crawl in application. But if we do in that and we want to make sure that once we do have the attack surface that we are actually scanning it accurately under the authenticated session, you know we’re not invalidating it constantly and all those things. And yeah, ’cause we know that we need to do that to find the vulnerabilities, but we what we do say that it’s not easy. It’s not easy to do this.

Holly Grace Williams: Honestly, it’s just it’s great that the company is so transparent about that, and it’s not, you know, selling a security magic box. It’s like, hey, this is the problem space. This is what we’re doing and this is why we’ve had the success that with that.

Nick Blundell: Yeah, I like to think so we yeah, we we’re in it to find vulnerabilities. You know in the things the systems that we research and also in the clients that use this software. So we generally are interested in pushing it as far as we can and we do OK, you know, we’ve done OK in certain areas, but we know that there is other areas where we really, you know, we really trying to push it with the automation side.

Holly Grace Williams: Yeah well nick. Thank you very much for coming on the podcast. If people want to find out more about the work that you do, where can they go to find out more?

Nick Blundell: So if you come to our website, which will probably be linked, I think we’re www.AppCheck-ng.com, and you can find out more about us there we do, we do regularly webinars and things as well so on certain topics. So it might be a topic on authentication or particular vulnerability so you can come along and see those they’re free for anyone that’s to sign up for them. And it’s usually delivered by one of our technical team, so it’s a technical discussion aimed at, you know, giving real insight into the nature of vulnerabilities and all the things related you know, so have a look out for those and sign up. Come along and join us if you want to find out more stuff.

Holly Grace Williams: Nick, thanks for being on.

Nick Blundell: No thank you very much, Holly.