About this Episode:
Prepare to learn all about the OWASP Top 10 Web Application Security Risks—Broken Authentication. This is the second monthly episode in which security expert Prasad Salvi will join us to break down each OWASP risk one by one. Today we’ll discuss the second security risk listed—broken authentication. Discover what a broken authentication risk is, the different ways this attack can occur, and how to prevent it. Listen up, and join us next month as we cover the next security risk, sensitive data exposure.
TestGuild Security Testing Exclusive Sponsor
Micro Focus Fortify is the recognized market leader in application security and is the most comprehensive and scalable application security solution that works with your current development tools and processes. Try it today
About Prasad Salvi
Prasad is an Application Security Consultant, a certified ethical hacker and CISA certified professional with a primary focus on providing services across the Secure Development Life cycle, Application Security and Penetration Testing spectrum. He is a part-time bug bounty hunter. He is a blue team expert delivering security training courses to developers and testers to make them proficient in application security and develop secure products. He has worked with major financial institutions and vouched to create a culture of security.
Connect with Prasad Salvi
-
- Twitter: prasad_salvi
- LinkedIn:prasad-salvi
Full Transcript Prasad Salvi
Joe [00:02:28] Hey Prasad! Welcome back to the Guild.
Prasad [00:02:31] Hi Joe! It's good to be back.
Joe [00:02:32] Great to have you. This is part two of our monthly installment of your breakdown of OWASP Top 10. So the second risk I think we're going to really dive into is broken authentication. Before we get into the nitty-gritty, at a high level what's it like quickly the essence of what broken authentication is so we can set the stage for the next questions?
Prasad [00:02:55] Broken authentication stands for the session management part. Once I log in to an application, the server response back with a session ID, which is like the heart of my session until I log out. That session ID will prove that I am authenticated and that could be used throughout my session. It is important for every developer to make sure that session management has been implemented correctly or else it might give rise to different attacks like session highjacking, session fixation, session replay, also different password attacks. If you have less secure passwords if you are storing them as clear text in a database. So everything that is related to authentication, if you don't have one key factor authentication, for example, then your application might be vulnerable to broken authentication.
Joe [00:03:44] Very cool. So, you know, like I said, I'm new to Security just notice OWASP has a breakdown of this as well. And they have them in like three main buckets. One is threat agents and attack factors. So they also give ratings for exploitability. So how common or how exploitable is this type of attack?
Prasad [00:04:01] I would say it is pretty common in a lot of applications. So, for example, if a particular application is vulnerable to an attack all across the scripting, which we would be discussing in the later episodes, if your application is vulnerable, then I can write a script and I can trick you into clicking on that script. Once you do that, that particular script will send me the session ID that you're currently logged with and I can use that session ID to log in as you, for example. So just to give you a layman example, we all book different tickets may it be movie tickets or flight tickets only. So let's say I am booking a flight ticket on a website and I need to check with my friend who is traveling along with me whether he's comfortable on the same flight or the same time. So what I do is I probably copy the URL and maybe it's my authenticated URL. I'm searching for a flight. I copy it and I either email or I SMS my friend, that particular URL. Now when my friend clicks on that particular link, he directly logs in as Prasad in that application. So unintentionally, my friend has performed a session hijacking because he used my session ID to login to his computer. This usually happens when you pass your session ID in the URL or in the guest request. That's very common. Usually, session time outs are not set in applications. So even if you keep your application running or idle for a long time, it doesn't log you out. Or to give you another example, if I'm using a public computer anywhere outside and I don't log out, I use the application and I just close the browser. So I've not logged out so this means my session is still active and let's say after an hour someone sits on that particular machine and opens the same URL. And because my session was still valid, that person logs in as me. Now, if you can imagine if that application could be my banking application where I have all my money stored, then that would be a big problem. So session expiration is also important as well as preventing your application from executing different scripts.
Joe [00:06:11] Absolutely. And I guess because most things of value have a front end that has some sort of session management, I would think that this would be kind of common. And one of the first things people will try to exploit because they really have some sort of value of breaking in and doing this type of hack, I assume.
Prasad [00:06:28] Exactly. So the session ID, as I said once I get a session ID it is supposed to be random, unique value per user. So when I am implementing session management in my application as a developer, for example, I need to be sure that it is long and random enough so that no one can guess it. Like, for example, if I keep my string a very long string or my session ID a long string and the next user who logs in, he will get probably if my session before session ID will end with the zero, maybe a very long session ID. But the second session ID that I'm giving to another user, it will end with one. And then I'm incrementing the last update or the last character just by one. So this is very predictable. Attackers can use different tools and guess what would be the next session ID. So it is very important that it is unique, it is random, and it is long enough. Ideally, OWASP recommends the session ID to be 128 bits, again, long and random.
Joe [00:07:32] Okay, so when I hear things like brute force attacks, is it usually referring to a broken authentication because they're using a tool just to try to guess passwords?
Prasad [00:07:40] Yeah. There's an attack called credential stuffing attack wherein let's say their usernames and passwords which have been breached in an X application on the Internet, an attacker might post them on a particular website free of cost. Now, other attackers or the same attacker, what he can do is take all that usernames and passwords and try it on different applications. No, I won't try that on X application because probably they have only known about the breach and they have asked their users to change their passwords. But because we are humans, I might have the same password on different accounts as well like along with X application, I might take it on my application or my Facebook password, for example. Now, that is the reason we say that we shouldn't be having the same password for multiple accounts. Now in a credential stuffing attack, I will take that username and password combination and try to use it in different applications on the Internet and see if I can get into that user's account. Now brute force would be to take N number of usernames and passwords from that list and try it on one particular application. Let's see Facebook, for instance. I have a thousand usernames and password combinations and I just keep on entering that in an automated fashion through different tools in the username and password feed of Facebook. So that would be a brute force attack. But I'm trying for different users to get into it.
Joe [00:09:07] Perfect. So I guess the next question then is obviously impacts. What are some impacts of this attack? I could think of multiple, but why would someone normally do this type of attack?
Prasad [00:09:18] There can be different reasons so attackers just want to take it down for fun like script kiddies or they want to have some ransomware install or some malware install or they want to create a backdoor so that they can do some malicious stuff. So probably if I'm an attacker, I'll try to go for the admin account, which has most of the privileges. So there's something called a default password. So usually all the default passwords are admin admin autobox for any server or any router, for instance. And if I'm not changing that, then I'm actually inviting different hackers to try the default password and get into without any security. So a good practice would be to change the default passwords that you have. Never keep admin admin or root root as a username and password for the admin account. Change them, have strong passwords, and also implement multifactor authentication.
Joe [00:10:16] Right. So you give a few examples already of how you could tell if your application is vulnerable. But are there any other examples of how someone can say, Oh my gosh, what can I look for to see if my application actually is vulnerable to this type of attack?
Prasad [00:10:30] The first one would be to have a prevention for the brute force attack, like after five continuous attempts, maybe you can give a captcha to the user. But if let's say I'm using Joe's account with multiple passwords. So after five attempts, I will have to log Joe's account for, let's say, 30 minutes or 24 hours, depending upon the criticality of that application. Other examples could be I don't have strong passwords set in my application. I allow my users to set a password as their name, for instance, without any case sensitivity that would be inviting the attackers for these type of attacks or having a default username and password, as I said earlier. So this is an interesting topic when I have to reset my password and I have forgotten my password. We all see a link that would say forgot my password or forgotten password and that takes me to a security question answer page. Now, these security questions I'll have to set when I'm registering in the application. But most of the security questions are not really secure. Do we call them security questions? Because the most common security question that we observe is what is your mother's maiden name? That's not something that is very secure and that only I as a person would know and this world. Security questions should have certain characteristics. So the first one should be it should be consistent. Second, it should be memorable. So if the users can't remember answers to the security questions, then it defeats the purpose. It should be universal so that it applies to a large audience and the answer shouldn't change over time. For example, what would be your better half's name five years from now, or your girlfriend's name, for instance? That might change after five years or six years, so that's something that we have to make sure while developing the forgot password feature. But again, a lot of developers are in a misconception that asking security questions is a form of multifactor authentication. It is not because that, again, falls under the knowledge-based questions or something you know. Password is also something you know as well as the answers to a security question. So then they would still fall under a single factor and not multifactor authentication. The last example that I would like to say if you're application vulnerable is you're not invalidating the session IDs. Even if I click on logout instead of closing the browser, the request that is sent for that logout click, the response should have the session ID as null. That is the best practice. I shouldn't give a new session ID or return back to the same session ID to the user once he has logged out. I should be able to invalidate that session ID so that no one can use that session ID again.
Joe [00:13:27] Awesome. So besides that way, are there other ways to prevent it? I know a lot of times lately I've been asked to do two-way authentication or I log in from a different device as a VPN and I get an alert saying, you're trying to log in from this other account, is this you or not? Do you want them to log in? Are those some ways to prevent it? Or as we get more and more into 2020 and beyond how can we prevent this? Are the newer ways to try to put into place, if you're a developer, to try to avoid this for future applications?
Prasad [00:13:59] The first one would be to have, as I said, multifactor authentication. The second is what you just mentioned, so there's a JavaScript, which you can write to check if the user is logging in from the same machine or the same browser. If the browser and machine change, we can ask if he or she is indeed trying to log in instead of someone else. So those are the two mechanisms, or we can either increase or decrease the delay in fail login attempts. So if I have a very critical application, I can only allow the users to enter three wrong passwords. For some applications. I can allow them to have five wrong passwords, but after that, I have to make sure I lock that account and send out a notification to the admin or to the security team, as well as the user that, you know did you try to log in? If not, then reset your password. If yes, then you will have to wait for 30 minutes to relog in because you locked your account due to five consecutive login failure attempts. The second important part here and this is again, the 10th. We'll have a 10th episode on this where they will talk about monitoring, insufficient monitoring. So the same example we'll be talking about in the 10th episode. We are going to have to end the series about monitoring. But I'll definitely talk about this again.
Joe [00:15:17] If someone was actually hacked due to this type of exploit, would they know? Because if I look in the news for a broken authentication hack, a lot of times people say, oh, my Twitter account was hacked into. When they say something, do companies know when they've been hacked with this type of exploit or there's nothing that's left behind because someone's actually using your username and password it almost seems undetectable? Unless someone says, oh, someone stole my money, I guess. I don't know.
Prasad [00:15:43] Absolutely. So it's very difficult to understand if you have been attacked or you have compromised or someone has compromised your session ID, for instance, the only solution to this is awareness wherein you're not supposed to click on random links. For example, I get a phishing e-mail that says that your account would be locked. So usually it has a sense of urgency and I might see my account is been locked and I click on that particular link and that's when I might lose my session ID to a particular attacker. So awareness is very important. Not clicking on random links. An attacker would only have my session ID when I click on something and invite him to take my session ID. If I don't do that…And as a developer again, I have to make sure that my session IDs are being invalidated after logout. There is a session expiry time set. There are two things when we log in to an application. So first is I hit the URL, let's say abc.com. So when I type abc.com in my browser, a request is sent to abc's server and then the server replies back saying that, okay, you can visit a two hundred okay response and it also has a session ID along with it. That session ID is only for me to reach the login page. Now let's say that session ID is ABCD, for example, and I see the login page. I log in with my correct username and password. Again a second request would be generated that would go to the server again. The server will check, okay it's the right username and password. Now when the server responds, the server should make sure that it is a different and a new session ID that it is sending back to the user because if it sends back ABCD then it actually defeats the purpose, because if I'm the attacker, I would know that on the login page it was ABCD and the server still continues that. So I can try to change ABCD through a proxy tool. And let's say, I try to be PQRS, for instance, and if the server responds back with PQRS, it means that the server is not relenting the session and just accepting any value that the user is providing. And this is called a session fixation attack wherein I have fixed my session that I would be needing only PQRS as my session ID. I don't need any other value from the server. So this is also important while developing session management when you have to make sure that after the user logs in, he should get a new session ID.
Joe [00:18:08] Right. Now, I also think that when I think of this, I think of a customer-facing UI like a banking account where you're just trying to add someone's username and password. But do you know as developers use more and more third-party applications, are there any backdoor APIs that could be exploited this way as well that people may not think about because it's not so customer-facing?
Prasad [00:18:28] Do you mean about the federated logins that we use instead of the authentication log of the application? Like, I can log in through Gmail or Google or Facebook, for instance?
Joe [00:18:38] Well, that's one way I was thinking maybe someone's using a third-party API in their application, but also maybe has a way that people can log in. But because it's headless and it's not part of the customer-facing type, it could still be exploited. I don't know if that makes any sense.
Prasad [00:18:53] Absolutely. So, again, it may be a backend API. So there might be different implementation strategies by the developers, but whatever they implement for session management, they have to make sure that the controls or the prevention techniques that we have discussed so far have been implemented.
Joe [00:19:12] And so you did bring up a point then when I go to certain applications, it gives me an option to use my Gmail account or my Twitter account. Does that make me more vulnerable to this type of attack? Because I would think that would be a higher risk or more well-known username password to grab. So if someone had my Gmail account, I used it for all my other accounts and I would be really easy to hack I would think this.
Prasad [00:19:37] This one would be I mean, you're right in a way but secondly, if let's say I am that third party application and I'm giving you that option to log with Gmail, I'm actually transferring that risk from myself to Gmail because I don't have to code for that authentication. But I'm just using the API that I'm getting from Google and Facebook, and I'm asking you to get into my application through that API. So if tomorrow, if something goes wrong or something is breached in my application, I'm free to blame that API that has come from Facebook or Google. So you can sue me in that case. But I personally don't recommend using federated logins if there's an option only to go for Facebook or Gmail and you can create your own account and probably not use that application in the first place.
Joe [00:20:30] And so a lot of times when we talk about security, it's always from like an attacker's perspective and it's already in the wild and it's being attacked. As a developer as we try to shift left to this type of activities, is there anything built into the IDs nowadays that says, hey, this is a possible broken authentication line of code, you just wrote? Do you know if the developer tools are this sophisticated yet or are there tools the developers can use as their coding to help them give me some sort of IntelliSense to say this may not be the most secure way of doing this type of authentication?.
Prasad [00:21:01] The developers can certainly use the MicroFocus Fortify OnDemand code scanning tool that actually tells you if there is anything missing in your session management code that you have written. So it scans your code and gives you all the details of the one that would do that resolve related to such key management as well.
Joe [00:21:20] Awesome. Prasad are the only resources people can go to to learn more about broken authentication?
Prasad [00:21:24] They can certainly go to the owasp.org website. They will also find the attack vectors and the mechanisms that attackers use. And also there is something called the OWASP Cheat Sheet series, which talks about secure coding or how developers can implement good and secure session management. So these two are the links which I would definitely recommend the viewers to go and see.
Joe [00:21:49] Okay Prasad before we go, is there one piece of actionable advice you can give to someone to help them with their broken authentication security testing efforts? And once again, what's the best way to find or contact you?
Prasad [00:21:59] Yeah, so if they want to test, they'll have to make sure to check for session fixation attack that we've discussed, session replay, and also session highjacking if I can get any user's session by executing different scripts. And if anyone wants to reach out to me, they can follow me on Twitter, they can connect with me on LinkedIn and I'll be happy to help.
Rate and Review TestGuild Security Podcast
Thanks again for listening to the show. If it has helped you in any way, shape or form, please share it using the social media buttons you see on the page. Additionally, reviews for the podcast on iTunes are extremely helpful and greatly appreciated! They do matter in the rankings of the show and I read each and every one of them.
