OWASP Top Ten - Breakdown

Welcome back to a pentest people tech bite. Today on this podcast, we will be talking about the OWASP, top 10, what they are the dangers and how people can protect themselves. Joining me today I have Adrian, George and Omi. Thanks for coming on today's episode, guys. Thank you. Thank you for having us. Thank you. It's great to be here. Thank you. So let's get this started. So the first application security, which is broken access control. Adrian, can you explain to our tech back listeners what that one is? And yeah, definitely. So to start off, broken access control is currently sitting at the number one position and OWASP, top 10. And generally because full of how common and how dangerous it can be. And to give a little bit of more perspective on this, all as statistics indicate that 94% of the applications tested have been identified with some sort of broken access control flows, and just roughly gives you an idea of how frequent is one of it is, and in general, broken access control vulnerabilities and arise when your web application does not properly enforce restrictions on what users are allowed to do. And this refers to both authenticated and unauthenticated users as well. So this means that an attacker could potentially gain unauthorised access to sensitive information,
or perhaps perform certain actions that they should not be allowed to do under normal circumstances. Have you got any examples of broken access control? And yes, sure, yeah. And one example can be insecure direct object reference, in short for either, and in this type of mobility, and a user can directly access as an object in the system without a prior authorization. And for example, let's say he has a website, where users can access certain resources by entering a numeric ID.

‍

And if the system does not properly validate that the user has permission to access that resource, and an attacker may be able to access restricted resources by simply guessing or perhaps incrementing, the ID value. And another example can be broken access control for the URL manipulation. So in this in this example, this time, an attacker can manipulate the URL to access resources that they should not be able to. For example, say you have a website, which already has a login page, and you put your credentials in and then the users can access their own profile by visiting a URL like slash profile, and ID equals and whatever number it is. And this number can then be changed by the attackers for different values. Let's say they're gonna put 001002 and in hopes of getting an admin session or admins profile or someone else's profile. So overall, with broken access control, would you say the failures can lead to unauthorised information disclosure or destruction of data? Yeah, definitely just one of the one of the primary dangers of broken control. Moving on to the second web application, which is cryptographic failures, Omi Can you tell our listeners might about that one and the dangers of it.

So cryptographic failures are one of the top 10 obviously, but it's one of the most critical web application security flaws, identified by OWASP. So essentially, what cryptography is, it's the science of using codes and cyphers to protect information. And cryptographic failures occur when cryptography is used incorrectly or inadequately leading to vulnerabilities that can be exploited by attackers. And what would you say are some of the main security flaws that commonly lead to cryptographic failures. So a few examples of this would be the usage of weak encryption algorithms such as the D S, or the RC four, which can be easily crapped storing encryption keys in a vulnerable location such as the same database as encrypted data or hard coding them in the source code. Lastly, using inadequate random number generators, which can make it easier for attackers to predict encryption keys, so these, these failures can be prevented, and it's not like there aren't any solutions for this. As of now, developers should follow the best practices for security for cryptographic implementations, such as the usage of strong encryption algorithms, like AES, AES or RSA and ensuring that the key sizes are appropriate for the data being encrypted. properly managing encryption keys such as using secure key management systems, rotating keys regularly and never hard coding them in the source code goes a long way. Using high quality random number generators to generate encryption keys is essential because there are some random number generators that are better than other random generator
Following secure coding practices, such as avoiding custom cryptographic implementations and using well vetted cryptographic libraries, if, if developers were to follow these four basic steps as a core principle, this would definitely remediate the cryptographic failures. Also, agent, I know you've been researching this topic a lot as well, the injection application, which slides down to the third position, 95% of the applications were tested for some form of injection, and the 33, CW E is mapped into this category have the second most occurrences in application, what can you tell our listeners about that one? And how can we determine if we are vulnerable?

‍
Yes, so injections as the names just refer to the type of security vulnerabilities that allows an attacker to inject malicious code into the Applications input fields, and potentially leading to various forms of exploitation. And there are many different types of injections such as SQL injections, where you inject the code, where you inject the code, and this is executed by the back end database. And command injections for example, are similar to the SQL lie. But in this case, it's the backend server that executes the injected command rather than the database. And even cross site scripting known as the accessors for short, and is also part of the OWASP injection section. And in this time, you inject a malicious JavaScript which is executed in the victim's browser. And it's also worth mentioning that exercise is one of the most common vulnerabilities in the web applications. Have you got any scenarios of injection?

‍
Yeah, definitely. Suppose you have a web application that utilises a search input field,which takes the users input and enclose this directly inside the statement to the database. And therefore, the query will look something like select all from items where nine equals and then the users input. And because user's input is contained directly inside the statement of the database, and the attacker can manipulate the actual outcome and the actual statement. And, for example, in this scenario, an attacker could enter or statement followed by a true value, such as one equals one and then comment in the rest of the query. double dashes or slightly different syntax may vary depending on the database. And this will then result in the search function resulting to true and then given the results for all the possible outcomes. So going further and attack a potential exploit is to gain confidential information from database. The insecure design category focuses on risks related to design flaws. If we really want to move left as an industry it calls from our use of threat modelling secure patterns and principles. Omi Can you tell us how attackers leverage an insecure design? So insecure design, security vulnerability usually arises from poor decisions in design that that's basically made during the development of an application or system and insecure design? It is a fundamental issue, and it is difficult to fix once it's embedded in the system. So it must be a driving factor during the development phase. And how can we implement secure design principles? Have you got any examples, I'd like to give three examples of insecure designs. And these include insufficient authentication and authorization mechanisms, insecure data storage, and lack of input validation. So if an application doesn't properly authenticate users or control their access to sensitive data, attackers exploit these vulnerabilities and gain author or unauthorised access. When we come to insecure data storage. It's a problem because an application stores sensitive data in plain text, or in a format that's easy to decrypt, then that is straight up vulnerable to attacks that can compromise the confidentiality and integrity of the data applications should validate and sanitise all input data from users to prevent attacks like cross site scripting and SQL injection.

‍
Developers should use secure coding practices such as avoiding buffer overflows, and using safe API's to reduce the risk of security vulnerabilities such as insecure design. Josh, what can you tell us about security? misconfiguration and what can be done to prevent it? Yeah, so this kind of relates to people on applications having public facing services or could be an administrative login poll.
Also things like using default credentials. So a lot of applications use like admin admin, for example, bad error handling, or lack of custom error pages.

‍
These are always quite common on applications. But it can also lead to information disclosure. A lot of these vulnerabilities are easily Google verbal format, if that's the word. So googling default credentials or googling vulnerabilities relating to certain software versions, quite easy to do. And a lot of the time, you can literally find step by step guides just to explore these. Have you got any examples of attack scenarios for our tech bite listeners listening? Yeah. So for example, if you might show or an application, sometimes this can disclose software name and a version. So just as I was kind of saying,googling that specific software inversion, looking for any vulnerabilities, a lot of the time, you can find a proof of concept.
So again, it's literally just a step by step of how you can actually exploit this. Just minutes of attacking and actually exploiting these vulnerabilities load really easy. You've also been researching the vulnerable and outdated components category, which is another last top 10. Can you tell us a bit more about that? Yeah, so a lot of software actually goes into these applications. And a lot of companies don't actually track what versions are using.
So mistakes can happen, obviously, software can get forgotten about.
For example, let's say you use piece of software comes out dead or end of life, it's not receiving security patches anymore.
Any sort of critical vulnerability that comes out against this, you've forgotten about it. This could be an area that an attacker can, obviously potentially exploit.

‍
Great points you've mentioned, Josh, if you are listening to this Tech Byte, the world increasingly relies on technology, it's important to keep our systems up to date and secure. Moving on to identification and authentication failures. Now, this application helps to secure additional framework perimeter as the first line of defence. What are the common causes or failures? Yeah, so this could be weak account password policies. So short minimum length, passwords, weak password hashes, lack of MFA, or multi factor authentication, account lockout policies, things like that.
So it's basically makes it easier for attackers to do like password guessing attacks. So it could be a brute force, or even just cracked password hashes that actually managed to get the hands on them. And what are some good practices to prevent this from happening? ensuring strong passwords educating users, if possible, so educating them on using passphrases as an alternative.

‍
Also, if it's feasible in showing multi factor authentication, so if an attacker managed to get a username or password, a valid username and password
that potentially will be able to well the will be able to access the account unless they phish somebody else. So with software and data integrity failures, can you tell us what these failures may look like? When we talk about software and data integrity failures usually refers to the ability of an application or a system to maintain the confidentiality, integrity and availability of the data, the big CIA in the security world, as we call it. This vulnerability can allow attackers to manipulate, steal or destroy sensitive information, causing severe damage to the system and its users and how can we improve for example, my approach to software and data integrity. To prevent software and data integrity failures, developers must implement input validation and sanitization, use secure coding practices and stay up to date on the latest security vulnerabilities and attack techniques. Developers should avoid relying solely on client side validation as attackers can easily bypass it. Server side validation and sanitization are essential to ensure integrity and validity of data entering into the system. Developers should also use secure coding practices such as minimising the use of dynamic SQL queries sanitising user input and escaping special characters to prevent injection attacks. Additionally, developers should regularly perform security audits to identify vulnerabilities and implement appropriate measures to fix them. Security logging and monitoring failures is another OWASP. Top 10 90% of applications were tested for some form of software misconfiguration. But the market shifts into highly configurable software. And it's not surprising to see this category move up. Can you tell us the importance of logging and monitoring systems so security, so logging and monitoring are essential for detecting and responding to security incidents? Security logging refers to the process of recording security events while monitoring involves analysing the logs for a suspicious activity. An example where this fails would be inadequate security, event analysis and lack of real time monitoring. It can result in delayed or inadequate response to security incidents making it difficult to contain and remediate and attack, and what would you say are some of the best practices to avoid failures. To prevent this failure, developers must implement comprehensive logging and monitoring solutions, perform regular security audits and train staff on incident response procedures. Comprehensive logging and monitoring solutions include tools for collecting, analysing and visualising logs from different sources, including servers, networks and applications. Regular security audits are necessary to identify gaps and weaknesses in the logging and monitoring process. While training staff on incident response procedures can ensure the organisation is prepared to respond to security incidents effectively. In addition to these measures, developers should implement best practices such as encrypting log data, limiting access to log files, and ensuring that the integrity of log data encrypting log data can prevent attackers from accessing sensitive information while limiting access to log files can prevent unauthorised modifications or detections. ensuring the integrity of log data can help ensure that the logs are accurate and reliable, making them more useful for detecting and responding to security incidents. So if you notice that most of the flaws and failures that was identified in the top 10, we noticed that the remediation of most of these are on the same line, but they shouldn't be treated as a single remediation for multiple problems. Each problem needs to have its own remediation process and policy.

So I know, having a good security won't be easy and quick, but that's what makes it good. And the last category is server side request forgery. SSRF. Adrian, can you tell us what the impact is of SSRF attacks?

‍
Yeah, defence, they show their various ways of exploiting and different techniques associated with the CSRF attacks. And some of them can include unauthorised access to sensitive data. And attackers can potentially use SSRF to send requests to internal systems. And this includes databases or other resources that are not meant to be accessible from the internet. And this can of course allow attackers to steal sensitive data such as usernames or passwords. And network reconnaissance is another concern. And attackers can use a society to scan internal networks and discover other potentially vulnerable systems which can be exploited in further attacks. And also, there's potential for remote code execution with SSRF as well. And attackers can leverage SSRF to execute RCS, which then allows to execute arbitrary code on the service side of the application pretty much leading to a full compromise on the system. So if your infrastructure is vulnerable to server side Request Forgery attacks, the consequences could be devastating to your organisation. Adrian, can you tell us how to avoid being attacked. And so for the SSRF, I think the most important thing is the input validation and scientists ation. And however, development teams can also restrict access to internal resources, including databases, to make sure that only authorised users can access it.

‍
One more thing is using a well configured web application firewall can definitely provide additional layer of protection against necessary for ducks that covers the OWASP Top 10 application security. After all, the level of reliability is what will determine its success. And this will be reflected in the number of active users in the application. If you want more information on the OWASP Top 10 You can go on to o os.org. Have you guys got any closing comments before we wrap up this podcast? Yeah, I just think it's really important to remember how important the use of strong passwords are, again, educate users on strong passphrases multi factor authentication where possible.
Also things like administrative polls to file whitelisting again, if you can, is quite important. And I think the key is never trusting the users input and always sanitise and validate users. definitely agree with that. Adrienne. Thank you all for coming on today's Tech bite. It's been great having you all on today's episode. Thank you. Cheers. Thank you for having Thank you. Thanks for having me. And thank you to our tech back listeners for tuning in. Make sure to follow our Spotify page for more.