Take measures in development to harden and keep your web backend secure.
Small businesses, banks, and many industries depend on web applications. From the point when building a web application, it’s crucial to be sure to have protocols to check vulnerabilities as the development evolves to avoid security breaches, data leaks, and financial issues.
The most dangerous web attacks are those that occur on the server-side where data is stored and analyzed.
What is Backend?
A web application is divided into two parts – Frontend and Backend.
The frontend is client-side, it’s the part the user interacts with. Typically, it’s built with HTML, CSS, and Javascript.
The backend is server-side. It’s basically how the application works, applies the business logic, changes, and updates. Some of the popular server-side tech stacks involve PHP, NodeJS, Java, Ruby, C, Python, database, security (authentication, access control, etc.), structure, and content management.
A little reminder before we start – authentication, access control & session management
It’s common for us to confuse the terms. So let’s clarify it quickly:
Authentication concerns proving user identity (eg., password, username, questions security, fingerprints)
Access control concerns what the user can access the application. It enforces the policy that users cannot act outside their intended permissions.
Session management concerns responses and request transactions associated with the same user. It is an exchange mechanism that is used between the user and the application after he authenticated successfully.
Let’s explore the following for better back-end web security.
Injection flaws
Since 2010, OSWAP classified injection as the #1 most dangerous web application risk.
Injection flaws allow a user to provide data containing keywords that will modify the behavior of queries built on the database. For example, let’s suppose we have a SQL script that checks if a matching entry exists in the database.uname = request.POST['username'] passwd = request.POST['password'] sql = "SELECT id FROM users WHERE username='" + uname + "' AND password='" + passwd + "'" database.execute(sql)
Copy
An attacker can now manipulate the password field using SQL injection, for example by entering the password ‘OR 1 =’ 1, which leads to the following SQL query:
sql = "SELECT id FROM users WHERE username='' AND password='password' OR 1='1'
By doing so, the attacker can access all the user tables of the database, the password being always valid (1 = ‘1’). If they log in as an administrator, they can make any changes he wants.
How to prevent it?
It’s very EASY to avoid injection flaws.
The best and simple way to verify if there are no injection flaws is a thorough manual source code review to check if queries in the database are done via prepared statements. You can also use tools to check for vulnerabilities.
And you should also do the following.
Use ORMs (Object Relational Mapping Tools).
Escape all inputs. A date field should never have anything else stored in them except dates.
Isolate your data so that only the things that should be accessed from a given location is held on in that location.
Write good handling error codes. Don’t make your database or your backend too verbose.
Troy Hunt got a brilliant course on SQL injection. If interested, you may explore that.
Broken authentication
As mentioned earlier, authentication deals with the credentials providing. It’s the frontline of defense against unrestricted access. However, poor implementation and non-respect of security policy can lead to broken authentication.
Broken authentication happens mostly by three patterns :
Credentials stuffings: where the attacker has a list of valid usernames and passwords and can automate attack to figure the credentials are valid.
Bruteforce attack: where the application permits weak passwords for users or admins.
Session hijacking: where application exposes session ID, URL, or doesn’t rotate after login.
In all cases, the attacker can gain access to an important account and depend on the business that can cause money laundering, identity theft, or disclose legally protected, highly sensitive information.
How to prevent it?
Before implementing the authentication system, ask yourself – what could an attacker achieve if the authentication system is compromised?
And according to the response, you can do the following.
Implement multi-factor authentication to prevent automated attacks.
Encourage (or force) the user to adopt a good password policy.
Limit failed logins.
Use efficient algorithm hash. When choosing an algorithm, consider the max password length.
Test the session timeout system and make sure the session token is invalidated after logout.
Broken Access Control
Access control exists to ensure what authenticated user is allowed to do. Authentication and session management are the foundation or access control rules. But when those rules aren’t well set, this can lead to significant issues.
Common access control flaws include:
CORS misconfiguration that allows unauthorized API access.
Metadata manipulation to direct access to methods.
Forced browsing: The attacker will try a URL, modify paths (eg.,http://website.domain/user/ to http://website.domain/admin), and can even discover important files.
How to prevent it?
Mostly, broken access flaws occur by ignorance about the essential requirements of effective access management.
Deny by default except public resources.
Disable server directory listing and be sure that backup files are not present.
Rate limit API access to reduce the impact of automated attacks.
Invalidate JWT tokens after logout on the backend-side.
Data Exposure
Also referred to as data breaches, data exposure is a cyber-threat that menace businesses and their clients.
It occurs when the application doesn’t adequately protect information such as credentials or sensitive data like credits cards or health records. More than 4000 records are breached every minute.
The impact on business is big from the financial side: An average breach can cost USD 3.92 million, according to IBM.
How to prevent it?
As a backend developer, you should ask what the information that needs protection are.
And then to prevent such flaws:
Encrypt sensitive data: For data at REST, encrypt everything. For data in transit, be sure to use secure gateways( SSL )
Identify the data that requires extra protection and limit the accessibility to only a bunch of legitimate users only by enforcing key-based encryption.
Avoid weak encryption algorithm: use up-to-date and strong algorithms.
Have a secure backup plan.
Insecure deserialization
Serialization and deserialization are concepts used when data is converted in object format to be stored or send to another application. Serialization consists of converting data in object format like XML or JSON to make them usable. Deserialization is just the reverse process.
Attacks against deserializers can lead to denial-of-service, access control, and remote code execution (RCE) attacks if there are classes that can be modified to change behavior.
The second example of the OWASP top 10 document provides a good illustration of PHP object serializer :a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user"; i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
Copy
This is a supercookie containing information like user ID, the level of the user, and the hashed password.
An attacker can change the serialized object to get access to admin privileges:a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin"; i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
Copy
How to prevent it?
It’s crucial not to accept serialized objects from untrusted sources.
You should also:
Never trust user input.
Validate data: If your application except for a string, make sure it’s a string before using it
Use a check to be sure that data hasn’t been changed. It’s useful you are sending data between two trusted sources(eg., storing data client-side).
Server XSS
Server XSS (Cross-site scripting) is a type of injection when an attacker uses a web application to send malicious code to different users. It occurs when the attacker posts some crafted data containing malicious code that the application stores. This vulnerability is server-side; the browser simply renders the response.
For example, in a forum, user posts are saved in a database, often without verification. Attackers take this opportunity to add posts with malicious scripts. Subsequently, other users receive this link by email or see the post in question and click on it.
How to prevent it?
After primary identification of all the operations that are potentially at risk of XSS and that need to be protected, you should consider the following.
Validate input: check for input length, use regex matching, and only permits a certain set of characters.
Validate output: If the application copies into its responses to any item of data that originated from some user or a third party, this data should be HTML-encoded to sanitize potentially malicious characters.
Allow limit HTML: for example, if you have a comment blog system, only allow usage of certain tags. If you can, use a suitable framework to user-supplied HTML markup to try to make sure that it does not contain any means of executing JavaScript.
Conclusion
The development phase is crucial for web application security. And, you should consider including a security vulnerabilities scanner in the development life-cycle, so the identified issues are fixed prior to production.
Read More
Small businesses, banks, and many industries depend on web applications. From the point when building a web application, it’s crucial to be sure to have protocols to check vulnerabilities as the development evolves to avoid security breaches, data leaks, and financial issues.
The most dangerous web attacks are those that occur on the server-side where data is stored and analyzed.
What is Backend?
A web application is divided into two parts – Frontend and Backend.
The frontend is client-side, it’s the part the user interacts with. Typically, it’s built with HTML, CSS, and Javascript.
The backend is server-side. It’s basically how the application works, applies the business logic, changes, and updates. Some of the popular server-side tech stacks involve PHP, NodeJS, Java, Ruby, C, Python, database, security (authentication, access control, etc.), structure, and content management.
A little reminder before we start – authentication, access control & session management
It’s common for us to confuse the terms. So let’s clarify it quickly:
Authentication concerns proving user identity (eg., password, username, questions security, fingerprints)
Access control concerns what the user can access the application. It enforces the policy that users cannot act outside their intended permissions.
Session management concerns responses and request transactions associated with the same user. It is an exchange mechanism that is used between the user and the application after he authenticated successfully.
Let’s explore the following for better back-end web security.
Injection flaws
Since 2010, OSWAP classified injection as the #1 most dangerous web application risk.
Injection flaws allow a user to provide data containing keywords that will modify the behavior of queries built on the database. For example, let’s suppose we have a SQL script that checks if a matching entry exists in the database.uname = request.POST['username'] passwd = request.POST['password'] sql = "SELECT id FROM users WHERE username='" + uname + "' AND password='" + passwd + "'" database.execute(sql)
Copy
An attacker can now manipulate the password field using SQL injection, for example by entering the password ‘OR 1 =’ 1, which leads to the following SQL query:
sql = "SELECT id FROM users WHERE username='' AND password='password' OR 1='1'
By doing so, the attacker can access all the user tables of the database, the password being always valid (1 = ‘1’). If they log in as an administrator, they can make any changes he wants.
How to prevent it?
It’s very EASY to avoid injection flaws.
The best and simple way to verify if there are no injection flaws is a thorough manual source code review to check if queries in the database are done via prepared statements. You can also use tools to check for vulnerabilities.
And you should also do the following.
Use ORMs (Object Relational Mapping Tools).
Escape all inputs. A date field should never have anything else stored in them except dates.
Isolate your data so that only the things that should be accessed from a given location is held on in that location.
Write good handling error codes. Don’t make your database or your backend too verbose.
Troy Hunt got a brilliant course on SQL injection. If interested, you may explore that.
Broken authentication
As mentioned earlier, authentication deals with the credentials providing. It’s the frontline of defense against unrestricted access. However, poor implementation and non-respect of security policy can lead to broken authentication.
Broken authentication happens mostly by three patterns :
Credentials stuffings: where the attacker has a list of valid usernames and passwords and can automate attack to figure the credentials are valid.
Bruteforce attack: where the application permits weak passwords for users or admins.
Session hijacking: where application exposes session ID, URL, or doesn’t rotate after login.
In all cases, the attacker can gain access to an important account and depend on the business that can cause money laundering, identity theft, or disclose legally protected, highly sensitive information.
How to prevent it?
Before implementing the authentication system, ask yourself – what could an attacker achieve if the authentication system is compromised?
And according to the response, you can do the following.
Implement multi-factor authentication to prevent automated attacks.
Encourage (or force) the user to adopt a good password policy.
Limit failed logins.
Use efficient algorithm hash. When choosing an algorithm, consider the max password length.
Test the session timeout system and make sure the session token is invalidated after logout.
Broken Access Control
Access control exists to ensure what authenticated user is allowed to do. Authentication and session management are the foundation or access control rules. But when those rules aren’t well set, this can lead to significant issues.
Common access control flaws include:
CORS misconfiguration that allows unauthorized API access.
Metadata manipulation to direct access to methods.
Forced browsing: The attacker will try a URL, modify paths (eg.,http://website.domain/user/ to http://website.domain/admin), and can even discover important files.
How to prevent it?
Mostly, broken access flaws occur by ignorance about the essential requirements of effective access management.
Deny by default except public resources.
Disable server directory listing and be sure that backup files are not present.
Rate limit API access to reduce the impact of automated attacks.
Invalidate JWT tokens after logout on the backend-side.
Data Exposure
Also referred to as data breaches, data exposure is a cyber-threat that menace businesses and their clients.
It occurs when the application doesn’t adequately protect information such as credentials or sensitive data like credits cards or health records. More than 4000 records are breached every minute.
The impact on business is big from the financial side: An average breach can cost USD 3.92 million, according to IBM.
How to prevent it?
As a backend developer, you should ask what the information that needs protection are.
And then to prevent such flaws:
Encrypt sensitive data: For data at REST, encrypt everything. For data in transit, be sure to use secure gateways( SSL )
Identify the data that requires extra protection and limit the accessibility to only a bunch of legitimate users only by enforcing key-based encryption.
Avoid weak encryption algorithm: use up-to-date and strong algorithms.
Have a secure backup plan.
Insecure deserialization
Serialization and deserialization are concepts used when data is converted in object format to be stored or send to another application. Serialization consists of converting data in object format like XML or JSON to make them usable. Deserialization is just the reverse process.
Attacks against deserializers can lead to denial-of-service, access control, and remote code execution (RCE) attacks if there are classes that can be modified to change behavior.
The second example of the OWASP top 10 document provides a good illustration of PHP object serializer :a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user"; i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
Copy
This is a supercookie containing information like user ID, the level of the user, and the hashed password.
An attacker can change the serialized object to get access to admin privileges:a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin"; i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
Copy
How to prevent it?
It’s crucial not to accept serialized objects from untrusted sources.
You should also:
Never trust user input.
Validate data: If your application except for a string, make sure it’s a string before using it
Use a check to be sure that data hasn’t been changed. It’s useful you are sending data between two trusted sources(eg., storing data client-side).
Server XSS
Server XSS (Cross-site scripting) is a type of injection when an attacker uses a web application to send malicious code to different users. It occurs when the attacker posts some crafted data containing malicious code that the application stores. This vulnerability is server-side; the browser simply renders the response.
For example, in a forum, user posts are saved in a database, often without verification. Attackers take this opportunity to add posts with malicious scripts. Subsequently, other users receive this link by email or see the post in question and click on it.
How to prevent it?
After primary identification of all the operations that are potentially at risk of XSS and that need to be protected, you should consider the following.
Validate input: check for input length, use regex matching, and only permits a certain set of characters.
Validate output: If the application copies into its responses to any item of data that originated from some user or a third party, this data should be HTML-encoded to sanitize potentially malicious characters.
Allow limit HTML: for example, if you have a comment blog system, only allow usage of certain tags. If you can, use a suitable framework to user-supplied HTML markup to try to make sure that it does not contain any means of executing JavaScript.
Conclusion
The development phase is crucial for web application security. And, you should consider including a security vulnerabilities scanner in the development life-cycle, so the identified issues are fixed prior to production.
