DEV Community

Cover image for Detailed Internet Security Analysis: Common Vulnerabilities and Best Practices
Ana Klarić for Devot

Posted on • Originally published at devot.team

Detailed Internet Security Analysis: Common Vulnerabilities and Best Practices

Security is a major threat to companies striving to deliver software quickly. Alongside existing vulnerabilities in application code and security breaches, companies and developers must also be aware of the potential security vulnerabilities that super-powerful quantum computers pose to currently used cryptographies.

To raise awareness of security risks, it is crucial to be informed about new threats to IT security.

The problems vary: encrypted data can be stolen, stored for potential decryption by quantum computers in the future, and so on. To ensure the protection of sensitive data, developers must prioritize the implementation of modern secure programming practices and strong encryption and authentication into applications.

Be aware of the data leakage
Perhaps we can live with the fact that our data is used without our consent, but none of us likes it when this data ‘leaks’ into the public domain on the internet without our consent or knowledge.

Although many companies maintain high-security standards and invest large amounts of money in protecting their users' data, data leakage is still a common problem. As internet users, we all have private data stored on various websites and applications. Therefore, it is important to be aware of the dangers of data leakage and always check the security of the websites and applications we use.

OWASP Top 10 most critical vulnerabilities
To protect themselves from attacks, companies should follow recommendations and best practices in web security.

The Open Worldwide Application Security Project (OWASP) is a nonprofit organization dedicated to improving software security. Among many projects, OWASP also works on documents like the “OWASP Top 10 Most Critical Vulnerabilities,” which consist of a broad consensus on the biggest security risks for web applications.

The goal of this document is to raise awareness among developers and other IT industry professionals about the greatest security risks and educate them on how to prevent these risks. In this blog, we will highlight the five most critical vulnerabilities from the mentioned top 10:

1. A01:2021 - Broken access control
94% of applications were tested for some form of improper access control, showing that 34 common weaknesses of improper access control appeared more frequently in applications than any other category.

2. A02:2021 - Cryptographic failures
previously known as sensitive data exposure, which was a general symptom, not a primary cause. The renewed focus here is on flaws related to cryptography that often lead to the exposure of sensitive data or compromise the security of systems.

3. A03:2021 - Injection
94% of applications were tested for some form of injection, and the 33 CWEs categorized here rank second in the frequency of occurrence in applications. Cross-site scripting is now also included in this category.

4. A04:2021 - Insecure design
a new category focusing on risks associated with design flaws. If, as an industry, we truly want to make a shift towards security, this requires greater use of threat modeling, secure design patterns, principles, and reference architectures.

5. A05:2021 - Security misconfiguration
90% of applications were tested for some form of incorrect security configuration. With the increase in transition to highly configurable software, it is not surprising to see this category progressing. The former category for XML External Entities (XXE) is now part of this category.

Broken access control
Access control implements measures that prevent users from acting beyond granted permissions. Deficiencies usually lead to unauthorized disclosure, alteration, or destruction of data or performing some business function outside of user limitations.

  • Common vulnerabilities in access control include:

  • Unauthorized access to specific features or users

  • Circumventing access control checks by changing URLs

  • Allowing the viewing or editing of someone else’s account by exposing a unique reference to objects

  • API security with missing access controls

  • Incorrect CORS configuration that allows access to the API from unauthorized or untrusted sources (i.e., lack of whitelisting)

Implementing security tests into unit tests is a long-term investment that involves greater investment in developers' awareness of security. In addition to helping developers better understand how to test for security issues, this can greatly improve the overall quality of software and reduce the number of vulnerabilities in web applications.

Cryptographic weaknesses
Do we ensure security using protected HTTPS protocols when transferring information? Websites secured with HTTPS connections provide visitors with enhanced reliability through data encryption, which makes it more difficult to track users and their data.

In addition to tracking users, the content received is also secured because it involves a secure communication channel where interception and modification of the received content are prevented. Some internet browsers, such as Google Chrome, penalize and specifically mark websites that are unprotected by SSL/TLS certificates (used for HTTPS protocols).

We secure files when transferring them between users using the FTPS protocol. Originally, the FTP protocol allowed users to transfer files without any encryption or protective measures. FTPS is an upgraded FTP with an added security level of Secure Socket Layer (SSL).

Similarly, as with HTTPS protocols, a secure communication channel is established through which all information passes between the user and the website. All data are encrypted, and only an SSL-protected server can decrypt these data using a shared SSL key.

SQL injection
A security problem that has existed for over 20 years. Why is it still present in 2024?

SQL injection attacks occur when attackers send invalid data to an application, which is mistakenly executed as SQL commands. This can manipulate the database data without proper authorization. Attackers insert SQL commands where they are not expected, for example, in the password input field during application login.

What are some methods to protect against SQL injection attacks?

1. Data sanitization of user input
The application should ensure the elimination of all characters from user input that could be executed as SQL code, such as parentheses and colons.

2. Input validation
The application should ensure input validation and limit the number and type of characters that can be entered.

3. Use of a secure API interface
The recommended option is to use a secure API interface that completely avoids using an interpreter, provides a parameterized interface, or uses tools for object-relational mapping (ORM).

The reasons behind security issues in 2024
So, going back to the previous question, do these security issues still exist in 2024?

Lack of specific security awareness among developers
There's often a shortfall in security-specific awareness and training among those who develop applications.

Lack of automated effective testing methods
There is a lack of automated testing methods that enable precise detection of injections (e.g., tests without false positive results).

Use of database access libraries
These libraries are supposed to provide a secure way to access databases but can often still be exploited, giving developers a false sense of security.

Volume of SQL databases
Finally, almost every web application uses some form of database, and the sheer volume of SQL databases on the internet provides a broad surface for attack.

How things have changed - From experts to users
It is certainly necessary to follow recommendations and best practices in web security, such as those suggested by OWASP.

However, even though recommendations and security tools are available, attackers often exploit vulnerabilities that also appear in the libraries we use in application development. Previously, we had to manually program everything because there weren't as many auxiliary libraries as available today.

On the other hand, those that did exist often did not meet the needs of our applications. Therefore, developers had to have a broad knowledge of program functionalities without the help of additional libraries.

Since we could not rely too much on ready-made solutions, most developers paid more attention to security. However, over time we began to use libraries for almost everything, but we did not retain the desire to understand all the details within those libraries.

Attackers targeting our applications or libraries can use techniques that exploit even the smallest problems in our code. Even if you write the code correctly, in 99% of cases, that remaining 1% can make your application just as vulnerable as if you had not implemented any protection at all.

Let's see an example of such an attack through popular open-source packages.

Damaged NPM libraries
NPM (Node Package Manager) is the most used package manager for JavaScript in Node.js. Through NPM, we can install and manage packages for our JavaScript applications.

Users of popular open-source packages "colors" and "faker" were stunned when they saw their applications crashing and displaying nonsense, affecting even thousands of applications.

The creator of these packages intentionally included an infinite loop that crashed hundreds of applications that rely on these packages. These loops print nonsensical non-ASCII characters on the consoles of all affected applications and continue to execute indefinitely, thus causing crashes.

The real motive behind this action was retaliating against mega-corporations and commercial users of open-source projects who heavily rely on free community-contributed software without giving back.

Best practices for selecting and using open-source libraries
Given these challenges, it is important to adopt cautious and strategic practices when selecting and using open-source libraries. Here are some recommendations to ensure the reliability and security of your applications

Be careful about which packages you use. Not all packages are maintained with the same level of security and reliability.

Choose packages maintained by established consortia dedicated to improving and maintaining software. This ensures ongoing support and updates.

Prefer using source code over binary whenever possible. This recommendation is especially important because binary files imply a much higher level of risk since it is ultimately impossible to verify that they were built with the associated source code. The best approach would be to directly use the source code, check its integrity, and analyze its vulnerability before using it in application development.

Top-tier code is a secure code
We can ensure a certain level of security by using various tools to check for vulnerabilities in our code, such as:

OWASP ZAP - The most popular tool for testing the security of web applications.

MobSF - Provides automated security testing for mobile applications.

SonarQube - Used for analyzing and testing the quality and security of code in various programming languages.

These tools can detect various vulnerabilities in web applications and mobile applications, including compromised authentication, exposure of sensitive data, incorrect security configurations, SQL injection attacks, cross-site scripting, unsafe data deserialization, and components and libraries with known vulnerabilities.

What can companies do today to protect their data?

Today, security is more necessary than it was 10 years ago. From HTTP anomalies, SQL injection attacks, and cross-site scripting (XSS) to attempts at account takeovers and malicious bots.

To ensure the security of our applications, it is crucial that every company operating on the web does not compromise security for the speed of delivering new applications or functionalities. Most importantly, the company must maximize the security of its end-users' data.

If you have any questions about how we deal with security at Devōt, feel free to reach out to us.

Top comments (0)