Lisa Bock covers three common vulnerabilities, or security flaws in a system: SQL (Structured Query Language) Injection, Broken Authentication and Session Management, and Cross-site scripting. Learn ways to safeguard your system include performing ‘white list’ input validation, and using Content Security Policy.
- [Voiceover] In taking a look at the top vulnerabilities, there are three that seem to remain at the top of the list. Those are SQL injection, broken authentication and session management, and cross-site scripting. SQL injection was and still is high in the list. SQL stands for Structured Query Language. It is used in relational databses including MySQL, Oracle, PostgreSQL, Microsoft SQL Server and Microsoft Access.
Here is a line from SQL where it says SELECT CustomerName FROM Customers. So we'd be pulling a customer name from the table Customers. However, with SQL injection, this is where an attacker spoof the data driven application by injecting a string value. That is not typical into a form field. It's done because we want to expose the database contents. Many applications are still susceptible and the results can be devastating as the entire database can be read and even modified.
Improper input validation is the vulnerability. Yet input validation can easily be done. What is input validation? Well, it's a technique we use to defend a web application. This defines the type of characters that we can use. Input validation should be used on all input data. As an example, I'm asked to put in my email address. Instead of putting Lbock@example.com, I forget to use the @ symbol.
Then I type in Lbockexample.com. Input validation throws back an error saying improper email format. It won't allow me to send that form until I correct it. Once I've corrected it, it will allow me to send the form. Now that's good and proper input validation. We'll take a look at a normal login and how it would look to you the user. A normal login has this presented with a webpage. This is a form which asks us to input the username and password.
So I input my username and my password and that's saying who I am and using the password to validate that. And it says, "Welcome back, Roxy!" Now I'm allowed to go through the webpage and check out content. We'll take a look at the same website. This is now a vulnerable application because it doesn't have input validation. And because it doesn't have input validation, I can bypass any authentication methods and possibly allow me to gain access to the database, in some cases, delete tables or even the entire database.
Now this is a very simple example. I'm gonna just show you a very simple example of an SQL injection to show you that you can get results that are not expected because I bypass authentication. And this is basically saying return some value if one equals one is true which it is true and it comes back and instead of saying, "Welcome back, Roxy," it says, "Welcome back, Jean," which Jean is most likely the first entry in the database. Now I'm in the database and I'm allowed to traverse through it.
There are many other examples of an SQL injection but the point is you should test to see if your site is vulnerable to this type of attack. Broken authentication and session management is also another vulnerability. Authentication is used to prove your identity. We can provide authentication in one of three ways. What you know in the form of a password or a pin, what you have in the form of a smart card or a token, and what you are in the form of a biometric identifier such as a fingerprint.
Let's step through a scenario. The protocol that is used to transfer webpages is HTTP or hypertext transfer protocol. HTTP is a stateless protocol. The session ID is used to track the state. In this example, a user wants to obtain his or her email. A user logs in and provides authentication. Then the session is managed and the user obtains necessary information well in the site. Access control ensures they do not enter sites that they do not have privileges.
Once their business is complete, the session is terminated. If an application that deals with authentication and session management is not correctly implemented and attacked and compromised session token, keys, or exploit other flaws and assume someone else's identity. Also if encryption is not used, the session ID can be exposed on the network. In addition, storing the session ID in the URL instead of using a cookie is a risk.
Here we'll see the URL in that CleoPatra's Closet. And up in the upper right hand side, there you can see the session ID. Now someone can take that as you see it is in plain text and this is a risk. Another form of broken authentication is when the user accesses an account from a device that's not their own such as a friend's phone or a public computer at a hotel. If they don't log out and close the browser when done, a session can remain active on that device and allow others to have access to their account.
Good practice is a session should time out after a period of inactivity, thus preventing this vulnerability. Another common vulnerability is cross-site scripting. This allows an attacker to insert malicious code in the form of a client-side script. The cross-site scripting vulnerability may be used to bypass access controls, steal sensitive data, insert a trojan, deface a webpage or even redirect you to another site.
There are safeguards which should be in place. Safeguards include performing white list input validation on all user input to be included on the page. Also using Content Security Policy HTTP response header. This defines what resources are allowed to load. The browser is gonna throw out an error if violated. This is gonna prevent certain type of attacks. Now the Content Security Policy is set on a server's configuration file.
The policy is to ensure that content is only from the site's domain. It's set in the server's configuration file and here is simply one line of that configuration file code. The fact is vulnerabilities exist, however should be mitigated using secure coding techniques. In addition, test vulnerabilities in a sandbox environments such as WebGoat. This is a safe environment where you can see what type of results that can be expected when you have vulnerabilities that exist.
Security expert Lisa Bock starts with an overview of ethical hacking and the role of the ethical hacker. She reviews the kinds of threats networks face, and introduces the five phases of ethical hacking, from reconnaissance to covering your tracks. She also covers penetration-testing techniques and tools. The materials map directly to the "Introduction to Ethical Hacking" competency from the CEH Body of Knowledge, and provide an excellent jumping off point for the next courses in this series.
Note: Our Ethical Hacking series will map to the 18 parts of the EC-Council's certification exam. Find more courses in the series on Lisa's author page.
- Ethical hacking principles
- Managing incidents
- Creating security policies
- Protecting data
- Conducting penetration testing
- Hacking in phases