#9 When Hackers Knock: 3 Common Security Gaps

Too often, we do not think enough about the security of our applications. It can lead to data leaks and severe consequences. Learn about common vulnerabilities and try to protect against them.

Much has been written about application security. Books, articles, blogs.

Yet, I still come across security holes that are seemingly so obvious, yet we forget about them. In particular, I have in mind three of them that I encounter notoriously:

1. Insecure Direct Object References

2. Public endpoints that should not be public

3. Logging of sensitive data

Unfortunately, we often forget about them, which might have severe consequences. Let's examine each.

Insecure Direct Object References

You build the application that helps your customers to manage invoices. The feature is added after feature, fast pace, and customers are satisfied.

Unfortunately, someone registered a new account to try to steal other customers' data, primarily regarding invoices. His first action was to manipulate the URL and try to access unauthorized data from other companies.

The URL that is used to show all invoices of a given customer looks as follows:

https://yourInvoicingApp/companies/{companyId}/invoices

The attacker replaces his company ID of 123 with 124.

https://yourInvoicingApp/companies/124/invoices

Voila! He can now see all invoices from a company with ID 124.

Why did this happen? Because of the lack of authorization checks. You may think - no, no, there is no option for such a thing to happen. You'd be surprised how many apps have problems with it. I think this is often due to the following:

1. The rapid pace of change. We add a lot of features and are trying to satisfy our customers.

2. Release as fast as possible. We want to validate the MVP as soon as possible, and there is no time for proper testing.

3. Lack of skills. Our development team might lack skills in this area, and no one has considered it.

It can lead to severe consequences, including loss of customer trust and, finally, the bankruptcy of the entire company.

Public Endpoints That Don’t Have To Be Public

You build the job board API. Some endpoints must be authorized and require an account, and some must allow anonymous access because they should be reachable by non-registered users who use our frontend application, e.g., to see the jobs list.

While it's sometimes necessary for endpoints to be publicly accessible, leaving them unprotected can be a significant security risk. Even if an endpoint is intended to be used by anonymous users, it could be protected by some mechanism like an API key or hidden behind the API gateway.

The attacker wants to break our job board to ensure no one can access it. If the public endpoint is left unprotected, he can abuse it by sending tons of requests, which will lead to a denial of service and might generate extremely high costs.

Why did this happen? My opinion is that our mind works, in this case, on the principle that public means publicly accessible, so we don't have to worry about it. I talked to some friends about this, and they confirmed that if something is to be authorized, they focus on it a lot, and if it's public, they treat it as a second-class problem.

Although it may not be as threatening as the above, it can still significantly affect our business and customer satisfaction.

Logging of Sensitive Data

Whoever is without sin, cast the first stone! :)

The vast majority of applications you are likely to deal with are based in some way on logging information. We add logs here and there. It helps us to monitor what happens in our application.

Our code is well-secured, we follow all the principles, and endpoints are inaccessible from the outside. We encrypt sensitive data, so if anyone accesses our application database, it won’t be possible to decrypt it without a key.

When returning the information to the authorized user, we decrypt this sensitive data to make it readable. Everything works as a charm.

Several weeks later, someone struggles with an application issue and adds additional logging in the same area. Unfortunately, he does not realize that it logs decrypted data. Logs are archived in a file and stored somewhere.

It turns out that this “somewhere” is not well secured. An attack occurs, and log files are stolen.

An attacker can now access the archived logs and may find valuable information, including passwords, transaction data, credit card numbers, patients' medical records, and other sensitive data.

Why did this happen? First and foremost, it was due to the developer’s mistake. He did not notice that he had exposed data he should not have. We are human, and mistakes can happen. Cross-checking is crucial here and can be done through pair and mob programming or during code review.

Summary

In conclusion, while the pressure of rapid development and the demand for quick releases can sometimes distract from security considerations, it is essential to remember these common vulnerabilities.

If this is overlooked, then later, there is a cry that our data has been leaked, that customers are demanding explanations, or that we have lost a lot of money.

Do not treat security as a second-class category problem. Share knowledge about these threats with development teams.

How about you? Which security holes do you face most often?