A Look at the OWASP Top 10 Project: Protecting Your Web Apps
According to the Open Web Application Security Project (OWASP), these are the biggest web app vulnerabilities. Are you at risk?
You have to give some credit to hackers. They are persistent, creative and often successful. Imagine what they could do if they only directed their efforts toward positive pursuits. Hackers will attack network services any way they can. And what better way than to strike directly at the heart of the internet: the web application. An organization called the Open Web Application Security Project (OWASP) regularly compiles common web app vulnerabilities. They call it the OWASP Top 10 Project. The following is a summary of these exploits.
A1:2017 – Injection
You may think that computers are intelligent, but they pretty much do what you tell them to do. If you give a computer a command, you can count on it to try to carry it out if there’s nothing countermanding it. And if someone – anyone – slips in a command somewhere that the computer recognizes, it will have every reason to execute it to the best of its ability. So hackers try to find ways to inject commands wherever they can. As the OWASP site puts it:
Technical author Joseph Cox calls SQL injection “the most easy way to hack” and “the number one threat to websites.”
A2:2017 – Broken Authentication
We’ve all heard stories about passwords being compromised. User IDs and passwords are used for authentication in most applications. Broken authentication occurs when a hacker intercepts a user’s ID and password or the session ID that is created when the user logs in. There are many ways to do this.
OWASP lists common methods for this hack, and they offer examples and ways to prevent it. These exploits take advantage of such weaknesses as unencrypted connections, weak passwords, and session IDs that don’t expire. Leaving the default administrator login as admin/admin is an amateur mistake, but it happens. And who would use the word “password” as their password? Choosing a difficult password is a smart choice. Passwords that are unencrypted, whether during login or when they are stored, are inviting trouble. (For more on passwords, see Simply Secure: Changing Password Requirements Easier on Users.)
A3:2017 – Sensitive Data Exposure
You see it all the time in the news: another security breach! Stored credit card numbers and other confidential data are held in databases by web services companies. But hackers are clever – and persistent. According to EE Online, “A weak cipher is defined as an encryption/decryption algorithm that uses a key of insufficient length.” Weak ciphers make it easier to crack encryption. And they can be used by hackers as backdoors to your database. With unenforced TLS or weak encryption, your website can be downgraded from HTTPS to HTTP, allowing the bad guys a way in.
Credit card numbers that are decrypted after retrieval become welcome targets for web attacks. The same is true for any sensitive data stored on web servers. According to OWASP, encrypting all sensitive data, whether stored or in transit, is one way to prevent this hack. Proper classification of confidential information is essential to combat this vulnerability.
A4:2017 – XML External Entities (XXE)
As W3 Schools explains, XML was designed to carry data. It stands for eXtensible Markup Language. Web applications parse XML data stored on web servers. Entity is a programming term that refers to “any singular, identifiable and separate object.” An external entity, then, would be an object that exists outside the server.
The problem with this vulnerability is in the parsing. John Wagnon of F5 explains that a bad guy may enter malicious code to trick your web application into doing something it shouldn’t. “If the XML parser isn’t configured properly,” he says, “then it’s going to run that command and spill all that data – and that’s not a good thing.” XXE takes advantage of XML parsers to process bad data.
Prevention tips from OWASP include:
- Use less complex data formats.
- Patch or upgrade XML processors or libraries.
- Disable XML external entity processing.
- Use XML Schema Definition (XSD) validation.
A5:2017 – Broken Access Control
Access is not the same as authentication. You may log into a website through authentication, but you will then only be able to access those services for which you have permissions. Administrators have much greater permissions than normal users. The elevation of user privilege is at the heart of this hack.
Once authenticated, users are restricted through access control checks. Hackers look for ways to bypass those checks through modifying the URL or some other means. To prevent this attack, Wagnon recommends a lot of manual testing of your current access control. When normal users can access resources meant only for users with more privileges, that means that you have some broken access control. OWASP says you can deal with this by denying access by default, enforcing record ownership and logging and reporting access failures.
A6:2017 – Security Misconfiguration
Hardening your server is the key to protecting against malicious attacks and keeping it online. But it should be done the right way. Missing things or adding unnecessary features can make your application vulnerable. Scenario #1 from OWASP is about an application server that comes with sample applications that are not removed in production. And in this scenario, the sample apps have known flaws. Proper server hardening would catch such things.
To prevent security misconfiguration, you need to lock down your server. There are lots of bits and pieces in any server, and standard installations often come with lots of extras that you don’t need. These default features can cause you problems. As Wagnon says, “Don’t use what you don’t need.” OWASP recommends “a minimal platform without any unnecessary features, components, documentation, and samples.” And you should review and update security configurations regularly on your web server. For this, you should use repeatable hardening processes.
A7:2017 – Cross-Site Scripting (XSS)
We input data into websites all the time. Cross-site scripting (XSS) occurs when an attacker injects his own code into a web page to elicit sensitive information from the site’s database. An HTML page that allows the input of scripts into such fields as comment boxes opens itself up to all kinds of problems. An attacker may inject code between <script> and </script> to give commands to the server. OWASP calls XSS the second-most prevalent issue in the OWASP Top 10.
The problem here is the injection of untrusted data. This should be separated from active browser content. “Escaping” is the key to prevention. That means making sure the injected code is not executed. Check out the “XSS (Cross Site Scripting) Prevention Cheat Sheet” to learn more about escaping untrusted data. (To learn about web development, check out 10 Things Every Modern Web Developer Must Know.)
A8:2017 – Insecure Deserialization
Serialization is about converting an object’s state information into binary or text form. That’s programmer talk for putting some unit of code into a stream of data so that it can be transmitted across a network and come out somehow in the same condition. Deserialization occurs when the object is transformed from byte stream back into object. Insecure deserialization disrupts that process.
It’s a form of data tampering. Perhaps the same data structure is used but the content is changed. Untrusted data from an attacker alters the byte stream. One example from OWASP is of a hacker changing a PHP serialized object to give himself admin privileges. Answers to this hack include digital signatures and deserialization monitoring.
A9:2017 – Using Components with Known Vulnerabilities
This problem is fairly self-explanatory. Unsupported, out-of-date software is particularly vulnerable. In this case, ignorance is not bliss. IT security managers have to stay abreast of the latest security bulletins, patches and upgrades. OWASP recommends a continuous inventory of software versions and the monitoring of libraries and software components. And they summarize it well:
“Every organization must ensure that there is an ongoing plan for monitoring, triaging, and applying updates or configuration changes for the lifetime of the application or portfolio.”
A10:2017 – Insufficient Logging & Monitoring
According to OWASP, “Exploitation of insufficient logging and monitoring is the bedrock of nearly every major incident.” Every IT system should have a system of logging events. Whether a network device or a data server, there needs to be a record of when things go wrong. If a user login fails, it should be in the logs. If a program malfunctions, your system should record it. If some hardware component stops working, it should be logged.
Any significant event should be logged. If you’re wondering what might qualify, you could have a look at OWASP’s “Logging Cheat Sheet.” Like network alarms, these events may be recorded when a certain threshold is reached. These thresholds can be adjusted as needed.
But logs and alarms mean nothing if they are not monitored. This could be through proactive automation or human surveillance. With proper logging and monitoring, IT personnel can respond to issues in a timely fashion.
We’ve covered quite a bit of material here. But there is a lot more to learn. To investigate further, have a look at the sources from which we conducted our research. The videos from John Wagnon at F5 DevCentral are a great resource, for which we are thankful. And OWASP has a PDF document that thoroughly covers all these exploits. This study may be a lot of work, but don’t forget that hackers work overtime too.