Introduction

The Internet is an indispensable tool in today’s day and age. Businesses, organizations, and individuals all around the world actively use websites for their day-to-day activities. However, as the internet keeps growing so do the number of security threats.

Subsequently, the internet has also become the place where one can look for solutions to these security risks. The OWASP Top 10 is a standard web application security awareness document for developers. It encapsulates a broad consensus about the most critical security risks to web applications.

The OWASP Top 10 is globally recognized by developers as the first step towards more secure coding. Keeping this in mind, we are going to discuss the top 10 security threats and how you can avoid them.

Injection

Injection attacks are caused due to insufficient user input validation. They can lead to data theft, loss of data integrity, full system compromise, etc.

There are various types of injections. A good example of injection is SQL injection. Imagine that a website that has a database with people’s data and is vulnerable to injections is visited by a malicious user. In an input field, this hacker can simply send this chunk of code.

SELECT UserId, Name, Password  FROM users WHERE UserId = 109 or 1=1

With this, a hacker can get access to all the usernames and passwords in a database, by simply inserting 105 OR 1=1 into the input field since OR 1=1 is always TRUE.

Prevention

To protect your software from injection attacks use a safe API, which avoids the use of the interpreter entirely or provides a parameterized interface. Another option is to migrate to using object-relational mapping (ORM) tools.

If you write these APIs yourself, ensure that you use the functions provided by the server-side language to detect code blocks and filter such blocks. Whitelist server-side input validation. This is not a complete defense as many applications require special characters, such as text areas or APIs for mobile applications. A code like this could do the job.

<?php

$username = filter_input(INPUT_GET, ‘username’, FILTER_SANITIZE_SPECIAL_CHARS);

$username =trim($username);

$data[‘username’]=$username;

addToDatabase($data);

function addToDatabadd($data){

}

?>

For any residual dynamic queries, escape special characters using the specific escape syntax for that interpreter.

Broken Authentication

Broken authentication is an umbrella time period for numerous vulnerabilities that attackers take advantage of to impersonate valid customers online. Broadly, damaged authentication refers to weaknesses in areas: consultation control and credential control.

What can make an Authentication broken?

An Authentication can be broken if it:

1. Permits automated attacks such as credential stuffing, where the attacker has a list of valid usernames and passwords.
2. Uses plain text, encrypted, or weakly hashed passwords

With these threats, Attackers can have access to hundreds of millions of valid username and password combinations for credential stuffing, default administrative account lists, automated brute force, and dictionary attack tools. This is particularly dangerous as the thought of what can be done with this is endless.

Prevention

Seeing how dreadful this is for your application and business, we have to find ways to prevent these.

Below are some of the ways to prevent broken authentication

• If possible, implement multi-factor authentication to prevent automated attacks, credential stuffing, brute force, and reuse attacks on stolen credentials.
• Use the server’s built-in secure session manager to generate a new high entropy random session ID after logging in.

Sensitive Data Exposure

Data exposure occurs when the record or data is left unattended or published on a database or server. Sensitive records may be uncovered while configuration information for systems, structures, and programs are left unsecured online. For instance, if someone’s password is saved as it is on the database this means its records are exposed.

Prevention

OWASP suggests doing the following, at a minimum:

• Save passwords using powerful adaptive and salty hash functions with working factors (latency factors) such as Argon2, scrypt, bcrypt, PBKDF2.
• Ensure updated and strong standard algorithms, protocols, and keys are in order;
• Avoid storing sensitive data. Discard it as soon as possible

XML External Entities

According to OWASP, “An XML External Entity attack is a type of attack against an application that parses XML input. This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser.

This is a common security threat to web applications. Usually, attackers do exploit weaker XML processors by including hostile content in an XML document, exploiting vulnerable code, dependencies or integrations.

Prevention

Personally, I’ll recommend using other data formats like JSON which is easier and simpler to maintain than SOAP

OWASP recommends the implementation of active server-side validation, filtering, or sanitizing (“whitelisting”) to avoid hostile data in XML documents.

Also, if the controls above are not possible, consider using virtual patching, API security gateways, or Web Application Firewalls (WAFs) to detect, monitor, and block XXE attacks.

Broken Access Control

In secured web applications, users are usually restricted to certain actions and resources. In a situation whereby administrative actions and resources is granted to a user, broken access control vulnerabilities exist.

A common Broken access control vulnerability is this  https://example.com/profile?id=1337.

With this URL, an attacker can easily access user’s profiles by changing the values of the id.

Broken access control attacks can have extraordinarily far-reaching and damaging consequences.

Prevention

The following are recommended in order to prevent any occurrence of Broken Access Control

1. Implement access control mechanisms once and re-use them throughout the application, including minimizing CORS usage
2. The web server directory list should be disabled and the webroot should not contain any backup file.

Codes like this should do the trick:

<?php

$origin = $_SERVER[‘HTTP_ORIGIN’];

if($origin = “http://www.domain1.com”

|| $origin=”http://www.domain2.com”

|| $origin=”http://www.domain3.com”){

header(“Acess-Control-Allow-Origin: $origin”);

}

?>

Security Misconfiguration

Security Misconfiguration is simply described as failing to enforce all of the protection controls for a server or web application, or imposing the safety controls, however doing so with errors. What an organization thinks as a safe environment clearly has risky gaps or errors that leave the corporation open to risk.

We should note that Security Misconfiguration arises when Security settings are defined, implemented, and maintained as defaults. This means that systematic updates should be done to the software to improve security.

Prevention

It is said that “ Simplicity is the Ultimate Sophistication” Personally, I recommend that you have a minimum platform that does not contain unnecessary features, components, documentation, or templates.

Cross-Site Scripting

Cross-site scripting (XSS) is a form of injection attack in which malicious script is injected to the server through the client-side code.

Web pages that allow user input such as login forms, comments box, search fields are vulnerable to Cross-site Scripting attacks.

Flaws that permit those assaults to be carried out successfully are pretty varied and many.

Prevention

1. Use frameworks that automatically handles XSS vulnerabilities by design, such as the latest version Ruby on Rails, React JS. Do some personal research to discover more of such frameworks.
2. Learn the limitations of each framework’s XSS protection and architect custom modules or libraries to handle such limitations

Insecure Deserialization

Insecure deserialization is a vulnerability in which untrusted data can be used to abuse the good judgment or logic of an application, inflict a denial of service (DoS) attack, or execute arbitrary code upon it being deserialized.

Prevention

It is important to note that the safest architectural pattern is not to accept serialized objects from untrusted sources or to use serialization mediums that only permit primitive data types. If that is not possible, consider the following:

1. Implementing integrity checks such as digital signatures on all serialized objects to prevent hostile object creation or data tampering.
2. Isolating and running code that deserializes in low privilege environments when possible.
3. Incorporating log deserialization exceptions and failures, such as where the incoming type is not the expected type, or the deserialization throws exceptions.

Using Components with Known Vulnerabilities

Some prone components (e.g., framework libraries) may be recognized and exploited with automated tools, increasing the chance agent pool beyond targeted attackers to consist of chaotic actors. Virtually each software has such troubles due to the fact that most developers do not focus on making sure their components/libraries are up to date.

Prevention

OWASP recommends that there should be a patch management process in place that only obtains components from official sources over secure links. It also recommends that you prefer signed packages to reduce the chance of including a modified, malicious component.

You can also use GitHub, which gives notifications on dependencies and libraries that have security vulnerabilities.

If there is a vulnerability in a dependency you use, you will see something like this:

Ensure that you have an ongoing plan for monitoring and applying updates or configuration changes throughout the lifetime of your applications.

Insufficient Logging & Monitoring

The importance of logging and monitoring cannot be understated. Efficient logging and monitoring systems must be put in place for easy tracing and debugging of security vulnerabilities.

Prevention

1. All logs should be examined following penetration testing in order to improve monitoring.
2. Use of security plugins to assist with auditing logs so you can spot anomalies and compromised accounts.

Graylog 2, logstash, logcheck, and logwatch are some popular opensource logging and monitoring tools that can improve logging and monitoring in web applications.

There are commercial and open-source application protection frameworks such as OWASP AppSensor (oldwiki), web application firewalls such as ModSecurity with the OWASP ModSecurity Core Rule Set, and log correlation software with custom dashboards and alerting.

After reading all this, I’m sure your approach to code writing for web applications will be different. As you have seen, there are many different ways your application can be vulnerable.

Please note that even with all these measures, you will not be able to create a 100% safe application. So, to help you find and fix security issues, you can use tools specially designed for such tasks.

So whenever you write code, think security!