Web applications are becoming more and more complex, but it’s 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, information security training experts said. But at the root of all of them are three questions: Who can attack us? What resources/components do we protect? What is the infrastructure of our system?
WHO CAN ATTACK US?
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. 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 security holes and 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 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. 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.
WHAT DO WE PROTECT?
According to information security training professionals you should analyze what kind of resources/values should be defended.
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.
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.
Back-end
Web page needs to communicate somehow with the server. An attacker can also do that using the API directly. 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.
The code base of mobile apps can be developed independently of the main application, which may lead to forgetting critical security-related patches.
Newsletter
Is that content part of the main page, or is it a place dedicated only for 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).
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?
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.
INFRASTRUCTURE
Having all of software components mapped, it’s time to get the similar view on infrastructure.
Protect you dev and testing environments. From the attacker’s point of view the most interesting are the development and testing environments. 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, information security training analyst said.
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/passwords
- 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. 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. According to information security training experts, 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, information security training professionals said. 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.
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.
Working as a cyber security solutions architect, Alisa focuses on application and network security. Before joining us she held a cyber security researcher positions within a variety of cyber security start-ups. She also experience in different industry domains like finance, healthcare and consumer products.
