Introduction

Security is always an evolving field, and as new technologies and frameworks are built, new security issues and vulnerabilities come with them.

The security of a web application is often overlooked during the initial building phase. This is a serious issue as security should always be included as part of the design phase of your web applications. Overlooking it and only thinking of it as an afterthought can bring devastating consequences especially if your application deals with peoples' information or performs financial transactions.

Several losses have been recorded in the tech industry as bug industries and platforms have lost several billions of dollars as a result of lag security in their web applications.

Keeping up with these trends can be difficult, and so In this post, I highlight a few foundational security issues (as seen in the OWASP top 10) in web applications and their mitigation strategies in hope that I'll be a stepping stone towards making your web applications secure.

What is OWASP

Open Web Application Security Project (OWASP) is a set of standards developed to make application developers aware of common and critical security issues that may be present in web applications and how to mitigate them.

Below I list 5 of those security issues, explain how it works and how to mitigate them.

1. Broken Access Control

In security terms, this basically means a user gaining access to resources or features he/she is not permitted to. Let me explain. Take for example a blogging platform like hashnode. A user can create blogs post and other users can read, like, and comment on them, nothing more. In a normal and secure sense, only the writer/owner of the blog post can edit or un-publish his post.

How it works

If a Broken Access Control vulnerability exists on the platform, then a user might be able to edit and unpublish another user's post. Now think of the issue happening in an e-commerce application or a fintech application. Hope you can now imagine the severity of this security vulnerability. A practical example of this security issue is highlighted below.

User A is logged into his banking app and he wants to get all his banking transaction history. Below is the URL when he makes his request

https://examplebank.com/user/1/transactions

This URL structure gives a hint that predictable IDs are used to represent users as seen there in "/user/1"

Given this information, a bad hacker which I'll call "Badman" might create an account on the platform, and he is given his ID, maybe "29", so his request looks like this.

https://examplebank.com/user/29/transactions

Then, he might try to make another request, but this time he replaces his ID with the victim's ID or a random person's ID

https://examplebank.com/user/1/transactions

And as easy as that, he may get access to User A transaction records.

Mitigation

• Unless a resource is intended to be public, deny access by default.
• At the code level, implement a check to restrict users' access to only their own resources.
• Test test and retest

2. Injection

These are types of vulnerability where a malicious user is able to inject his own code into the web application to make the web application do things.

These types of vulnerabilities are dangerously dangerous because a user can gain full access to your web application and make it do things you never intended, and if other users interact with the web application, they will be directly affected. Under this vulnerability, are Cross-Site Scripting (XSS), SQL Injection, XML external entity injection (XXE), Command Injection, and others.

How it works

To explain how this security issue works, I'll only show an example of an XSS vulnerability.

This vulnerability allows hackers to compromise a legitimate user's interaction with a web application that is vulnerable. This attack form is mostly carried out by injecting malicious data into input fields in web applications or URL parameters and is made possible using javascript. If this attack is successful, that attacker will have access to the users' session information, authentication token, e.t.c.

For example, we have a URL like below

https://example.com/post/comment?message="Nice"

A malicious user might inject javascript into the URL as shown below to check if the application is vulnerable

https://example.com/post/comment?message=<script>alert(1)</script>

If the application is insecure, an alert pop up in the web browser, and from there, the malicious hacker crafts a javascript code that can steal cookies and session data, injects it into the URL, and send the link to an unsuspecting user. If the user clicks on the link, all his session information and maybe more goes to the hackers' server to do as he wishes.

Mitigation

• Don't trust any input from the user, always sanitize inputs
• Implement filtering mechanisms
• Use "Content-Type" headers to ensure browsers interpret responses the way you want them, do not leave it to the browsers to guess content type by itself.

3. Security Misconfigurations

These issues are a result of incorrect configurations of your software stack and servers or cloud providers. Leaving login credentials as their default values, displaying server or database errors to the end users, leaving unnecessary ports open, and not setting the appropriate response headers, the list is endless.

This issue can open up your application to a large range of vulnerabilities and exploitation.

How it works

As an example, a user trying to login into an insecure web application with incorrect credentials, and the application returns the stack trace/error message directly to the user from the database queries.

The user can read and interpret the error which may contain the database type, version e.t.c and use it to perform blind SQL injections.

As another example, a web server directory listing is enabled by default. Directory listings list the contents of directories. If an attacker notices that this is enabled on the server, they can quickly identify the resources at a given path, by transversing the paths and proceeding directly to attacking those resources or downloading them.

Mitigation

• Always change default passwords when you install new software or frameworks
• Use custom error messages and never display machine-generated error messages to the end user.
• Remove or do not install unused features and frameworks, and only turn on what you need.

Till next time 😊