In this post in our QA Consulting and Software Testing series, we look at app security. Web applications becoming more and more complex are the new normal. It’s always a challenge to keep up with this growth and always know what app does, why and when, and what needs extra security measures on your part. This kind of a holistic analysis of security is known as threat modeling. There are different methods or even tools for doing that. But at the root of all of them are those three questions:

1. Who can attack us?

2. What resources/components do we protect?

3. What is the infrastructure of our system?

Defining profiles of possible aggressors will help you understand what could be the most probable ways of attack. Those profiles will obviously vary depending on the industry the company’s in and type of the app (banking, military, company blog). Here are some examples:

Competitors

They can be interested, among other things, in stealing data or discouraging your users by lowering the performance of the app.

Robots / hackers

Semi automatic bots will try to find weak spots of your app to install malicious software for spamming or cryptocurrency mining.

Users

Users of your app might find (very often unwittingly) security holes and, for example, see data that they’re not allowed to see by changing user IDs in the URL.

Own employees

Even if you have complete trust in your employees (do you?) they can become a threat unwittingly. It can be a matter of stolen session cookie, stolen or broken password or just malicious software installed on worker’s computer.

The last one is especially tricky, and the argument along the lines of “we use VPN, only trusted users are in it, we’re secure” is no longer valid when one of them has his or her own computer infected. And it’s hard to predict how such viruses can be introduced – on a new USB stick that was delivered in an open box, or fake email entitled “Salaries plan new year final” that looks like it was sent by mistake by one of the company higher-ups.. People tend to open that type of email more often than not.

Analyze what kind of resources/values should be defended. Money? Sensitive data? Or maybe a publicity nightmare – a hacked homepage – has to be averted at all cost?

Components

To understand all possible ways of attack, create a map of all components of your app. The main application page and it’s backend API would be in the center of that map and that’s not revelatory. But as the map will grow you may be surprised about what you may find at its edges: barely used legacy components, not updated since ages. A perfect gift for any intruder.

Front-end

Web page is usually a main way for your users to enter the web application. It can be vulnerable for many kinds of attacks related to front-end, with XSS being the most obvious. Inspect every input, whether it’s a contact form, search bar or page’s URL – basically, everything that accepts parameters can be target of an attack. Analyze how the client side business logic is implemented, check what messages are being shown to the user, and make sure there are no hints hidden in the source code comments.

Back-end

Web page needs to communicate somehow with the server. An attacker can also do that using the API directly. Is it secure? What endpoints are public and do they really have to be open? How requests are authenticated? Is authorization working? Are the management endpoints available for end users? You don’t want anyone to obtain the environment variable values via the /env endpoint of your Spring Boot’s actuator.

Database

Are you sure that your database port is not opened? That there’s no GUI DB manager installed under secret URL that only admin knows of?

Mobile

This is hacker’s favorite channel of getting into the system. Why?

Very often, for the sake of higher comfort, the security is lowered (long lived sessions, captcha not required). The code base of mobile apps can be developed independently of the main application, which may lead to forgetting critical security-related patches. Is the backend API of a mobile version the same as the API for web page? If not, that’s another component to consider.

Newsletter

Does your app send emails? Do emails contain images or links to content on your website? Is that content part of the main page, or is it a place dedicated only for a newsletter? If it’s in a separate space then another component is under threat.

Infrastructure/cloud components

Your application will use a lot of additional components, especially in cloud environments. Things like service discovery (e.g. Eureka), management tools (Spring Boot Admin), logging and metrics (Kibana, Grafana) or other aiding tools (Redis, RabbitMQ). Are you sure that no developer/tester has opened their ports to easily connect from home?

Third party software

Maybe you have a special BPM suite that takes care of some business process under the hood? Or Business Rules Management System? Or maybe you integrate with contracting parties? Those are also components that should be taken into consideration.

Who you protect is unique and no detail or component is too small. There can be a lot of minute things you can forget that you even have them, things like RSS feeds, cache servers or fancy plug-in for the web page.

Having all of software components mapped, it’s time to get the similar view on infrastructure. How many environments are there? What servers do we use? How they’re connected to each other? How they’re connected to the internet?

Protect you dev and testing environments 

From the attacker’s point of view the most interesting are the development and testing environments. Why? Because usually their security configuration is more liberal than the one in production, as the programmer’s convenience often has higher priority than system’s security.

Having gained access to the development environment, an attacker can do a lot of nasty stuff:

-Understand how to prepare successful attack on production servers

-Steal data (there are known cases of leaks caused by production data being copied to development environment without any modification)

-Steal passwords (some of which may be valid in production stages)

-Install malicious software on dev servers

-Analyze detailed debugging logs.

The source code repositories also should be restricted from the outside world. With an access to it attacker could obtain the passwords from your config files.

How an intruder could find your dev environments?

DNS transfer

One of first things to try is to inspect your domain and try to transfer the DNS information. One tool that enables this is the host program (DNS lookup utility). Defining the query type as NS will show the Name Servers record for given domain:

$ host -t NS example.com

example.com name server b.iana-servers.net.

example.com name server a.iana-servers.net.

Then, in the list mode (enabled by -l option), host will try to perform the zone transfer.

$ host -l example.com b.iana-servers.net

If transfer succeeds, an attacker will see all registered subdomains, like dev.example.com, test.example.com, qa.example.com and so forth, along with their IP addresses. To prevent this check your DNS configuration and make sure that zone transfers are restricted.

DNS bruteforcing

If simple DNS transfer fails, an intruder can try to guess the subdomains in a process called DNS brute forcing. One of the programs that can do that is called dnsenum When provided a dictionary file with list of domain prefixes, the target domain and DNS server it will report all existing subdomains with the given candidates. There are public dictionaries for dnsenum, consisting of a lot of probable guesses.

After obtaining the IP’s of your servers, attacker will usually scan their ports, searching for opened ones and planning next steps. A good practice is to hide all test environments from the public world in private networks, allowing the remote access for workers only via VPN networks.

To conclude, the last point that could be taken into consideration is the usage of HTTPS connections not only in production but also for test environments. Certificates may be self-signed, it doesn’t matter. What’s important is that neither your employees nor viruses installed on their computers will be able to sniff the HTTP traffic inside the VPN.

This post was intended as a sort of web security briefing both for developers and business audience, and covers many topics briefly, and those can be googled in detail, of course. In our day and age it’s super important to at least know the basic security steps and to have a checklist of things that needs to be security checked (pardon the pun).

In the next Security 101 post we’ll talk about various attacking techniques. Sing up for our blog and newsletter so we could let you know when it comes out!