Prevent your Website from Hackers as a Developer

Introduction

We will talk about the various ways to prevent your website from being attacked. Today, many websites are vulnerable to common web attacks described by OWAPS (Open Web Application Security Project) top 10 web application vulnerabilities. It takes silly mistakes to make your web application vulnerable. Due to the increase in technology and automation, we have automated penetration testing tools to test your web applications for vulnerabilities. One of the most popular ones is Burpsuit. We also have bug bounty programs that allow security researchers to test their web application for bugs and you pay them if they find any vulnerability. 

We have different levels of security checks. From your database to the server, and the user using the system. We will take each level separately and discuss the potential vulnerabilities and the prevention and protection measures. 

Database Level

We have different types of databases, but most importantly, we have an SQL database and a No-SQL database. They both store records but in different ways. For example, the SQL database stores records in tables while the No-SQL stores records as documents in JSON. SQL databases are popularly known for their SQL injection vulnerability. 

Database Vulnerabilities

1. SQL Injection: This is the process of manipulating a query to get more information than the one intended by the developer. This usually occurs due to improper input validation and sanitization of data by the user. So always validate your data no matter what. Today, most languages and frameworks have ways of preventing these attacks. You just need to know the right method to follow and prevent your database from being attacked. You can check online with the preference of the language you are using.

2. Unencrypted Data: Information stored in databases should be encrypted. This prevents attackers from using the data if mistakenly leaked. The most important types of data that must be encrypted all the time are passwords, credit cards, and any sensitive data. User information such as names, addresses, or any insensitive data must not be encrypted except if there is a need to do so. We have many encryption algorithms today. While some are deprecated and can be cracked like the MD5. You should be aware of the deprecated encryption algorithms and never use them, especially in real-life projects. Make sure you always stay up to date with the best algorithms to use. Encrypting passwords and credit cards is one of the most important things every software should do.

3. Permissions and Privileges: Not handing permissions and privileges will grant access to the attacker to do almost everything with your data and that is a total takedown. We have various access control that needs to be assigned to each type of user. A registered should have different types of privileges that a guest does not have. A paid user should have some other privileges a registered user does not have. An admin should have permissions and privileges that other types of users don’t have. You can see everyone in the database has certain access others do not have. So always implement an access control system for your software else you will pay heavily for not doing so. Also, get to know the different actions your users are to perform on the system so that you don’t limit or extend the required actions they need to perform.

4. Insecure Database Configuration: Configuring your database incorrectly can give access to attackers to perform actions that otherwise they could not or steal information they normally should not have access to. Misconfigurations such as not changing the default password. Many intruders will test default database passwords such as admin or password to see if the system will log in. If you are the type of developer that don’t change passwords, an attacker will have access to your database with a single click of a button. Another misconfiguration is not disabling certain features for development in production. Certain packages and features are for testing purposes and when you are in production, you should always make sure you turn them off else some attackers might try their luck and perform certain damages in your database.   

Server Level

This is the most vulnerable part of web security. We have various known vulnerabilities. The server interfaces between the database and the user interface. The server serves as the center of functionalities and logic within a web application. 

Common Server Vulnerabilities

1. Improper Input validation: This is very common, especially for those who are not professional enough to roll out software in production. They failed to validate every input. A hacker is always looking for that input that you think is not worthy of validation. For example, a select field with different options. The user interface limits the user to select only the options visible on the screen but, it takes a few seconds for a beginner hacker to inject another option and send it to the server. If you are not validating whether that option is among the ones you set on the system, you can store information that you are not intended to store which in turn can cause errors and provide room for further attacks. As a developer, you always make sure you validate any input field even if is for the administrators of the system. 

2. Authentication and Authorization: Authentication is a check to confirm whether a user has the right credentials to access system content. Authorization is a check to grant access to resources and content of a system. Not implementing one of these can lead to everyone accessing your system without proper permission and grant. We have different security architectures to take care of authorization and authentication today. Auth 2.0 is an example of security architecture for granting access to resources for third-party services. One of the good algorithms for handling authentication is JSON Web Token (JWT). To protect your system, make sure you authenticate and authorize every user on your system before any access to the system resources.   

2. Broken Access Control: This is also very common. This occurs when the system does not assign and validate permissions to various types of users. For example, a system with an administrator, a regular user, and a paid user should have different levels of access. A regular user should not be able to see administrative content. A regular user should not have access to paid content. By implementing access control, you can be able to distribute access and assign permissions and privileges to various types of users. Another scenario on this is not checking whether a particular user has access to another user’s content. If access control is not in place, user A can act in place of user B to perform some transactions on the software. Most professional technologies and language frameworks are equipped with a way to implement access control in their software systems.

3. Exposing sensitive files: Files such as .env files should be private and protected in production. Exposing them will expose many aspects of your software. If your software is using payment, you will probably store the payment keys in a .env file. When a hacker has access to them, he can do a lot of things. From transfer of funds to withdraws and even takeover of the account. So always keep your private keys safe. Also, no user on the system should have access to them unless in certain types of software where administrators can have access. A lot of sites are vulnerable to this attack by mistakenly failing to make their private keys safe.

4. DDoS attacks: This is a common attack nowadays. A server will be overwhelmed with requests by an attacker until he exhausts the server up to the point that it can’t take any request from a legitimate user. Before, with a single computer an attacker can send many requests to a server and get that server exhausted. Today, due to many prevention mechanisms, that can’t be done if the proper prevention measures are in place. The alternative way they usually launch this type of attack is using distributed computers across different networks to make it hard for the server firewall to detect this is a DDOS attack. Though we also have prevention mechanisms for DDOS, it is still use to deny access to legitimate users on some websites. A lot of websites integrate third-party services to help them prevent these attacks. For example, the most popular one is Cloudflare. You integrate it into your website and can detect when someone is trying to launch a DDOS attack on your website. The former can easily be prevented by implementing a rate limiter on your server. It will make sure requests from the same network are delayed for a certain time to give everyone access in their time of need without exhausting the server resources.

4. Deprecated Packages: Every language, framework, or technology will probably be updated with time. When the creators of that technology find some bugs and vulnerabilities in the system, they patch them and release the updates for their users to update their system. Failing to update your system can lead to letting hackers take advantage of those bugs and perform damages to your system. In most programming frameworks, we have different tools for checking whether the packages you are using are up to date. 

Client Level

The front-end of a web application constitutes the interface, most of the attacks on this section are not damaging. But they affect user experience and some can lead to measure attacks. Some users might not even have the intention of attacking a website but due to poor development and security, they might recognize the bug and take advantage. So, always put security measures in place no matter what type of user you have.

Client-Site Vulnerabilities

1. XSS: This is a client-side vulnerability as a result of failing to validate and sanitize user input. We have reflected XSS which takes input values and reflects it to a user. When an attacker inputs something that he should not be inputing. As a result of not validating the input, it is executed and reflected to the user. Such as adding some HTML code and CSS styling to a name field and suddenly it gets reflected. We also have stored XSS. This is stored in the database and every time you try to view it, it executes and gets reflected. The most basic way to prevent these types of attacks are 

a. Validating user inputs every time.

b. Sanitizing every user input. 

2. Session hijacking: This is the stealing of a session ID for a legitimate user and using it to perform certain transactions on the user’s behalf. It’s done with some tricks to steal the user ID first. The attacker can use an XSS attack to lure the user into clicking a link and he injects a script that will steal the session id. The session ID is then used by the attacker to perform certain actions on the software that is dangerous to that user. Such attacks can be prevented by the following measures

a. HTTPS: This will encrypt all the connections from the user to the server so that even if a hacker captures the request, he can’t do anything with it.

b. Using HTTP only. This is a command to tell the browser that, the cookie is a server cookie. No client-side code or command should be able to access it. Otherwise, the hacker can easily steal it with a script.

c. Expire sessions: Make sure you always expire sessions. Usually, 15 mins to 1 hour. 

Conclusion

We learned various aspects of web application security, how they occur, and various ways of preventing them. We have a lot of other attacks we have not discussed. The ones we discussed are the most common ones and the basic ones you need to make sure you are safe from. 

Questions and Answers

1. What is an XSS attack?

2. Where should we store private keys and sensitive environmental variables in production?

Answer: We store them securely such that no one can access them except the developer. Such as using the .env file

3. Why are authentication and authorization always important for web application security?

Answer: They provide the basic level of security for protected content

4. Why should we encrypt the sensitive information in our database?

Answer: To make it hard for hackers who got access to it, difficult to understand the data

5.  Is Access control a must in web applications? If yes, why?

Answer: If the content requires different types of users, yes. To restrict access to various users of the system

6. How do you prevent DDOS attacks?

Answer: By using a rate limiter and using third-party services like Cloudflare. 

7. Why should we always stay up to date with the technologies and languages we use on our web applications?

Answer: To prevent hackers from leveraging the vulnerabilities of the deprecated version to hack into our system

8. What is the use of HTTPS in communication between the user and the server?

Answer: To encrypt the communication between the server and the user.

9. What command do we use to prevent client-side scripts from stealing web application cookies?

Answer: We use HttpOnly

10.   What password creation rules should a web application enforce on a user to protect him from hackers?

Answer: Always use an 8 to 12 combination of alphabet, numbers, and characters. Also, don’t use personal data like name, phone number or personal address