A Complete Guide to the OWASP Top Ten

Security threats are happening at levels never before conceived and as more applications are developed, the threats compound. As network technology develops, so do the skills of those who seek to undermine it. In the early days of the internet, the focus was on protecting connections in a rather elementary way. But with the current application-centric internet, vulnerabilities are more prevalent in web applications than on some Layer 2 protocol link.

Here, we discuss the OWASP Top Ten, a list put together by the Open Web Application Security Project that deals with some of the most common methods hackers use to penetrate and disrupt networks, as well as some of the common weaknesses that plague us.

A1:2017 – Injection

Injection is when a hacker sends untrusted data to trick a computer into executing an unauthorized command or allowing illegitimate access to data. Of course, it's not the computer's fault. In reality, machines are stupid. Unless you buy into the far-fetched idea that somehow they can think for themselves, computers only do precisely what you tell them to do.

And if an attacker manages to intrude upon a software programmer's space and make his software do something for which it was never designed, then it is just a matter of a machine dutifully following the instructions it is given, however malicious.

This is a fairly common exploit that can be easy to implement on software that is not adequately protected. According to OWASP's description of the hack, injection flaws are "very prevalent," but they are also easy to discover. Injection vulnerabilities can apply to various codes:

• SQL

• LDAP

• XPath

• NoSQL Queries

• OS Commands

• XML Parsers

• SMTP Headers

• Expression Languages

When you think of this web application security issue, one of the first attacks that comes to mind is SQL Injection. Structured query language (SQL) is the usual way for front-end web pages to communicate with backend databases. As Computerphile expert Tom Scotttells us, "Any time you have to enter information or retrieve information using a website, it's interacting with SQL." SQL injection occurs when a hacker uses an attack string to input malicious commands or query and extract data from a confidential database.

An explanation from W3Schools illustrates how a hacker might try to find out all the users of a particular application. Here's how a piece of code querying a user id might look:

Oracle PL/SQL

1
2

To trick the application, the hacker inputs the following:  105 OR 1=1

What does the computer do? Well, it dutifully complies with the logical request. Once it sees the OR in the query, it logically forgets about the first part and just returns TRUE for the second part. Since 1=1 is always true, the computational result of the query is simply a list of all the users in the database table. It's a neat trick, and the computer is none the wiser. But a good programmer can prevent the attack with judicious coding security.

Input validation is one of the best defenses against an injection hack. As described by Cisco, blacklisting and whitelisting are two good ways to keep injection attackers at bay. Blacklisting involves keeping undesired, potentially malicious characters from being entered into a query response. Whitelisting limits input to only permitted characters. Either way, validation should be considered for inclusion in any code that depends on user input.

Another common coding security approach is called escaping. This uses specific escape syntax to prevent the software command interpreter from recognizing special characters. This keeps the hacker from causing Kills codes to break into a system by the injection of special characters.

For more information on the injection vulnerability and how to combat it, see OWASP's description of the flaw, as well as their SQL Injection Prevention Cheat Sheet.

A2:2017 – Broken Authentication

This vulnerability is so obvious that it might even be overlooked. How many times have you been told to keep your login information secure, to use strong passwords, and to completely log out when you're done? Preventing bad guys from accessing confidential sites and services by using your ID and password is a no-brainer — but it still happens.

A session is a period of communication between two computers that lasts for a finite period of time. A user authenticates to a server by typing identifying information into an input screen on his or her own client computer. If a hacker can somehow intercept that session — catch it while it is still up, or get a hold of the login credentials — then the user's data is at risk.

A simple example involves the use of a public computer to connect to confidential resources. When you log into a computer at the library, you hope that this won't expose you to any unnecessary security threats. But IT support professionals who work for the library are not always on the ball, and other library computer users may not have the same high level of integrity as you.

If you log into Google Chrome, for instance, and sync all your passwords, browser history, and more, what happens if you don't fully log out? Your time runs out on the library's user software, and you may be logged off their system. However, the next user of that computer may very well have complete access to your browsing history and account passwords through your Chrome identify.

Users, developers, and administrators should all be careful of this hack. Users should be sure to fully log out of any applications used on a public computer, and try to erase their tracks the best they can. Experts advise that we use very strong passwords and employ multi-factor authentication. Admins should limit failed logins and ensure that shared computers are fully refreshed between use. Coders should employ random session IDs and make sure that they time out to prevent hacker intrusion.

OWASP tells us that "broken authentication is widespread," and "session management is the bedrock of authentication and access controls."

A3:2017 – Sensitive Data Exposure

Protecting sensitive data at all times is critical to proper web application security. Remember, the attacker only has to get it right once. We've all heard stories in the news about hackers getting their hands on millions of passwords (as many as 773 million, in fact, and yours may have been among them). Keeping private data private is a pretty sound principle, but it's not always so easy to achieve.

Hackers want your important data, and they will do whatever they can to get it. They can use internet sniffing tools to see data as it passes through a network. Guess what? Very often our passwords and other private data travel through data streams as clear text. We may not even know anything about it. Sometimes it's our own ignorance, and often, it is simply the carelessness of a developer or administrator.

There are plenty of ways for sensitive data to become exposed. A sysadmin, for instance, might think it's okay to store a file with sensitive data somewhere temporarily while he does some sort of maintenance. But that may be just enough time for the hacker to capture it.

Poorly configured TLS implementations might change secure web pages (HTTPS) to insecure ones (HTTP) at some step of the data's journey, leaving it open to attack. A home user might think it unnecessary to set up his wireless router with encryption access controls. Or a careless office computer user might even leave an important password scrawled on a piece of paper next to her PC.

It's important to classify data according to its sensitive nature — similar to the way that governments assign different levels of security to their documents. Everyone should be aware of how critical data may be exposed and possibly exploited. Here is OWASP's documentation on the issue.

A4:2017 – XML External Entities (XXE)

XML, or eXtensible Markup Language, is a vehicle for storing data in a very organized, structured way. It's really a kind of computer language that helps devices share data with each other in a uniform way. Many software packages have adopted the use of XML formatting and adapted to the way it has shaped data transfer since its inception. But there's one flaw that has come out of the XML development community that is still causing problems: XXE.

XML external entities (XXE) refers to the way XML programming can use an external data source as a reference for checking its validity. This occurs when programmers leave something called document type definitions (DTD) enabled. It's especially a problem when these DTDs allow for XML data exchange to and from an untrusted source.

One tactic that hackers use to mess with an XML database is to submit code that points it to a malicious file external to its own server environment. Here is an example from the OWASP documentation that shows an attacker interacting with the server's stored passwords:

1  <xml version="1.0" encoding="ISO-8859-1"?>
2    <!DOCTYPE foo [
3    <!ELEMENT foo ANY >
4    <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
5    <foo>&xxe;</foo>

OWASP points out that the flaws related to the XML external entities' vulnerability "can be used to extract data, execute a remote request from the server, scan internal systems, perform a denial-of-service attack, as well as execute other attacks." XML structures that remain open to external entities are prime targets for clever attackers.

Whitelisting is one way to deal with the risk of XXE-related intrusion. That means that there is some method of input validation on the server, which may include filtering of data or sanitation according to prescribed syntax.

Another way to deal with the problem is to disable DTD processing altogether in the XML parser. OWASP's XXE cheatsheet on Github deals with all the ins and outs of XXE mitigation. As you can imagine, this is primarily a problem for developers. Users have little to do to prevent these hackers from accessing or damaging sensitive data that might be included on any number of XML data repositories on the internet.

A5:2017 – Broken Access Control

The key to understanding the nature of broken access control is to learn the difference between authentication and access. Let's think of the same concepts, but in another setting. If you've ever worked in a building that limits access to rooms or departments using electronic card readers, then you must know that your card would not get you into every room in the building. If you work in the IT department, you wouldn't need regular access to a maintenance closet, or accounting, or an executive suite. While you can authenticate your identity with the use of the card, your access is limited to only those areas relevant to your work.

Network access comes with similar limitations. You may only need access rights to certain files and folders rather than an entire server. You may be given user rights on one system but admin rights on another. Guest access for visitors will be even more limited than that. Broken access control occurs when a hacker manages to gain unauthorized access, or exceeds the level of network access intended for him. This can result in all kinds of mischief.

Network administrators put various controls on a network so that people only use resources by permission. There are physical access controls such as door locks and separation of workspaces. Logical access controls include encryption and passwords. Administrative access controls deal with policies and procedures.

A hacker may manage to gain admin access to a system by guessing a password or using a default login. Sysadmins should always change logins on new equipment so that they are no longer admin/admin or root/root. Some network switches or routers come with well known default logins. Broken access control is about assuming privileges that have not been officially granted. If a hacker can get into a system without authentication, he has managed to break access. If he can view, retrieve, or send a file without permission, he has broken access. When someone can see confidential information for which he is not authorized, it is because he has accessed data that is not meant for him to access.

Authentication, authorization, and accounting (AAA) is a framework for controlling computer resources. Unauthorized access to systems represents a security breach and must be prevented. Firewalls or other control systems that deny by default are a good way to stop unauthorized use. Applying consistent access controls throughout an IT system is a good practice. File permissions and folder access should be properly managed.

A6:2017 – Security Misconfiguration

It's easy to make a configuration mistake, but the fault can be particularly costly when it is a security misconfiguration. It doesn't take much for a hacker to squeeze through the cracks of a poorly designed or shoddily implemented web application. The potential vulnerabilities are virtually unlimited because there are so many surfaces that can be exposed or threatened in any complex piece of software. One tiny Kill, and it's over. OWASP summarizes the threat this way:

"Security misconfiguration can happen at any level of an application stack, including the network services, platform, web server, application server, database, frameworks, custom code, and pre-installed virtual machines, containers, or storage."

The remedy for a weak, vulnerable system is found in a concept known as hardening. Strengthening web defenses by security hardening should be done in every conceivable way. Like practically every other aspect of information technology, security configuration requires a lot of forethought, planning, and attention to detail if it is to be effective.

Software makers like Microsoft continually assess vulnerabilities and reported incidents to ensure that their systems and applications are secure. That's why every few weeks or months new security patches are released to address problems that have only recently been discovered. It is not enough to try to harden a system at the beginning of the software cycle. Proper security requires constant vigilance and regular updates to prevent breaches.

OWASP recommends a repeatable hardening process so that any new implementations of the same software are given the same treatment. Using identical credentials in the lab, for instance, will ensure that you have tested a particular login before it's executed in a production environment. Regular meetings to discuss application security should include a review of potential configuration flaws and possible improvements.

Some servers come with default applications that have known security flaws. These should be removed during the hardening process prior to server commissioning. Untold numbers of specifications and settings can greatly affect security in any application. These should be gone over with a fine-tooth comb.

A7:2017 – Cross-Site Scripting (XSS)

Unlike the previous two web application security vulnerabilities, cross-site scripting (XSS) involves more specific intentions and actions on the part of the hacker. XSS is a form of injection where an attacker purposely inserts a string that will be interpreted by the victim's browser. This additional text is actually treated as code by the computer — remember, the computer only follows commands — allowing the hacker to perform actions that may affect an unsuspecting user.

Unlike other forms of injection that target the server, XSS goes right for the client-side web page. The result could be something as benign as a silly comment that shows up on the user's screen as a practical joke. Through Javascript, HTML, Flash, or some other coding method, the attacker injects a script into the user's web page. It's actually a widespread problem. Tech writer Guy Pdjarny talks about "the next wave" of XSS attacks, which he says may have less impact but affect more people than other hacks. Beyond a simple joke, XSS can be used by hackers to steal cookies and impersonate other users.

Three forms of XSS are recognized. Stored XSS (aka persistent XSS) involves the use of a server's database to keep a modified web page that includes the hacker's malicious script. The page containing the cross-site scripting is called up from the database when the victim requests data from the server.

Reflected XSS is the most common type of XSS, and occurs when a victim inadvertently executes a command by clicking a link sent from the attacker. It's related to a hacking technique known as phishing used in emails. DOM-based XSS means that the attacker takes advantage of the way an application writes data to the Document Object Model (DOM) environment on the client side, avoiding sanitation or other security protections.

XSS can be a real "cookie monster. Here's an example from OWASP of how an attacker can grab cookies from a user through any posted input:

1  <script type="text/Javascript">
2  var adr = '../evil.php?cakemonster=' + escape(document.cookie);
3  </script>

OWASP offers some helpful XSS Prevention Rules that we'll note here:

• Rule #0: Never insert untrusted data except in allowed locations.

• Rule #1: HTML escape before inserting untrusted data into HTML element content.

• Rule #2: Attribute escape before inserting untrusted data into HTML common attributes.

• Rule #3: Javascript escape before inserting untrusted data into Javascript data values.

• Rule #4: CSS escape and strictly validate before inserting untrusted data into HTML style property values.

• Rule #5: URL escape before inserting untrusted data into HTML url parameter values.

• Rule #6: Sanitize HTML markup with a library designed for the job.

• Rule #7: Avoid javascript URL's.

• Rule #8: Prevent DOM-based XSS.

Obviously, these rules will make more sense to programmers familiar with the languages mentioned. The rest of us will do well to keep the risk in mind and pass the information on to our coder friends as needed.

A8:2017 – Insecure Deserialization

Up to now, the types of web application attacks we have studied have been fairly straightforward. We all can imagine broken access, or someone injecting code where it shouldn't be. We know something about login problems, and we all have some notion of security misconfiguration. But deserialization? What is that? And how can it become insecure?

Let's start from the word serialization and work our way forward. We'll look to Techopedia for an explanation:

"Serialization is the process of converting the state information of an object instance into a binary or textual form to persist into storage medium or transported over a network….

Serialization is used when large amounts of data have to be stored in flat files and retrieved at a later stage. To achieve this without serialization, it becomes too tedious, Kill-prone and complicated as the data structure is complex."

If serialization is about turning objects into strings of texts, then deserialization must be the opposite process. Using raw data, deserialization reconstructs the object model. And if you were wondering, an object represents some element of language within object-oriented programming (OOP), which was created as a modular approach to software development.

These concepts are rather abstract, but it's only because all of OOP uses the abstraction of language and mathematics for computing tasks. Moving beyond the problem of definition, let's consider what the attacker is actually doing here.

XML, the data structure we discussed earlier, is a popular format for data serialization. JavaScript Object Notation (JSON) is a more recent one. The biggest problem with deserialization is the inclusion of untrusted user input.

Here's an example from OWASP where the attacker assigned admin status to a user account over which he had control.

1
2  a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin";
3  i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
4

Notice that the untrusted user input occurs while the data is in its serialized (text) state. Once the data becomes deserialized (back in its object form), the hacker's attack becomes realized.

We'll summarize here some prevention tips from OWASP for insecure deserialization:

• Implement integrity checks on any serialized objects

• Enforce strict type constraints during serialization

• Isolate code that does deserialization to low-privilege environments

• Log Deserialization Exceptions and Failures

• Restrict network connectivity for servers that deserialize

• Monitor Deserialization Closely

This is a tricky one. Combatting insecure deserialization requires a lot of vigilance to be sure.

A9:2017 – Using Components with Known Vulnerabilities

Just so you're aware: downloading from insecure software libraries is a big problem. And it's not just a matter of promiscuous browsing, where a home user greedily grabs apps from every dark back alley of the internet. Established businesses and global companies are just as vulnerable to the use of insecure software because of the unreliability of so many software sources on the internet.

OWASP cites a paper from Contrast Security called "The Unfortunate Reality of Insecure Libraries." Here is the beginning of the paper's abstract:

In partnership with Sonatype, researchers from Aspect Security analyzed 113 million downloads from the Central Repository ("Central") of the 31 most popular Java frameworks and security libraries and made some conclusions about this important aspect of application security. Central is the industry's most widely used repository of open-source components, and currently contains more than 300,000 libraries. The study analyzed more than 113 million downloads of these libraries from more than 60,000 commercial, government, and non-profit organizations.

The analysis revealed several interesting findings, including: 29.8 million (26%) of library downloads have known vulnerabilities.

The initial conclusion is enough to shake your faith in online software repositories. It should make any IT professional think twice before downloading open-source software. A9:2017 is more a vulnerability than a direct attack. Your proficiency at defeating the other nine hacks will do you no good if you go and pull down malicious software from the web.

It's not just downloads that are a problem. Network administrators should be aware of all the possible weaknesses in the software that they are installing. That means staying up on the latest security briefs, studying release notes, and reading independent reviews. You can get all kinds of advice on the internet, even from reliable sources who have already dealt with issues that you'd rather avoid. It pays to be informed.

Perhaps the best approach is to go lean. Remove unused dependencies and features, as OWASP advises, keep a current inventory of all your web application components, and only download authorized components from official sources over secure links.

A10:2017 – Insufficient Logging & Monitoring

A widespread inattentiveness to security issues became apparent in responses to an OWASP survey. It turns out that some people just don't do enough to protect their network. The problem is so bad that OWASP included it in their Top 10 list. Logging and monitoring, logging and monitoring — every organization with IT resources should be doing it. You just can't leave your network unprotected, and you have to keep a faithful watch, lest you are caught unawares. It would be like a military base without a sentry.

Obviously, OWASP considers this an important issue. "Exploitation of insufficient logging and monitoring is the bedrock of nearly every major incident," they write. "Attackers rely on the lack of monitoring and timely response to achieve their goals without being detected."

A retail chain used a software test bed to analyze malware. But when it actually began reporting issues, everyone ignored it. Somehow the malware broke out and did some real damage. But it was too late.

OWASP says that all login access should be tracked, and enough data collected to be able to identify the perpetrator of a malicious act through examination of the logs. Financial transactions should have an audit trail with integrity controls. Real-time monitoring should continue day and night, whether by humans or automated processes, and incident response and recovery plans should be adopted.

These and other practices should be in place in order to keep attackers at bay and allow for forensic analysis after the fact. The OWASP logging cheat sheet offers more information.

Wrapping Up

Web application security is the responsibility of everyone involved with the World Wide Web. Internet services continue to proliferate, and the mass migration to cloud computing, virtualization, and automation contributes to the importance of web-hosted applications. While no one can argue with their value, proponents of web application adoption should be just as enthusiastic about guarding them from the myriad of attacks or vulnerabilities that could affect them.

OWASP has done a wonderful job in raising the awareness of users, developers, and administrators regarding the need for increased web security. A study of the OWASP Top Ten would not be wasted time for anyone who spends a lot of time coding web pages or surfing the web. From either perspective, web security is an essential part of the online experience.

We may not know the full story of all the unsuspecting users, ill-prepared programmers, or negligent administrators whose failures have led to great security risks. Hackers may keep trying to intrude upon our networks, but that doesn't mean that we should let them. Learning more about OWASP is a great way to keep your applications secure.