Top 10 Problems with Your Attack Surface
Reading time: 9 minutes
With the increasing attack surface of web applications, it's become even more important to identify and understand the most common attack surfaces and how easily problems in your own web application can develop.
Growing complexity and the dependence on unknown libraries, assets and larger development teams means the attack surface has never been larger. But following smarter development practises like DevSecOps and maintaining better cybersecurity culture and frequent scanning makes it possible to keep your web applications secure.
Popular problems with your attack surface
Some of the most popular attack surface problems are often the most overlooked, yet easily seen. And while some are inherited by your web application (like complexity and unknown assets), some are created by misconfiguring services and not following cybersecurity practises.
Let’s look at some of the most common problems you might find with your attack surface.
Complexity
With modern applications getting more complex because of the way they're developed and deployed, the attack surface has gotten larger on all fronts.
For example, most web applications include multiple add-on libraries, which are often developed by third-party developers. This introduces possible vulnerabilities if those libraries aren't scanned, kept secure and up-to-date.
Similarly, deploying web applications is done by leveraging modern containerization tools like Docker, LXC or LXD. Using each of these introduces another layer of complexity with the possibility of vulnerabilities present.
When developing web applications, CI/CD tools like Jenkins, Travis CI, and others are frequently used, which poses another security threat. If your CI/CD tool has a vulnerability and the attacker is able to insert code into your web application, this weakness could be integrated, processed and deployed all over your infrastructure, all being automated.
The above examples demonstrate that when our complexity of development and deployment increases, our attack surface increases dramatically as well.
Unknown assets
Often, modern web applications leverage third-party party libraries to handle various tasks. For example, web applications often use third-party party libraries to handle invoicing, billing via payment gateways, user authentication, and more.
If these libraries contain vulnerabilities and/or are untested before putting them into production, using them runs the risk of growing your attack surface. Stay on the safe side regarding unknown or unfamiliar assets like libraries, plugins and themes, all of which should only be used when fully scanned and determined to be safe.
Unknown vulnerabilities
Scanning and checking for vulnerabilities is frequently overlooked, yet the most important step when trying to reduce your attack surface.
Simply put, it's only when a user scans their web application that they find out vulnerabilities exist. These could be in the web server, in programming language being used to develop the web application, or simply in the web application itself. Therefore, frequent scanning is necessary for reducing your web application's attack surface.
Misconfigured services
Misconfigured services are a frequent source of entry for attackers. These include running services as a privileged user, often seen on Linux based systems with users running services as "root"—which, when combined with other vulnerabilities in the software running on the system, can lead to a massive increase in your attack surface.
For example, if the script which takes user input does not sanitize or filter input from users, running a web server as root which executes commands input from users on the OS level can lead to destructive or dangerous commands being executed anywhere on the operating system (since the web server was running as root).
Similarly, configuring your software/services with incorrect memory limits can cause system crashes and DoS-like attacks as well. Running a database server without any memory limits, and with a web server without any rate-limiting, could allow an attacker to make automated requests to your web server calling for pages which are heavy on database usage.
Combined with thousands of automated requests, this can lead to the database server using more and more memory and finally causing a system crash, by simply running into a Linux OOM error. In turn, this can lead to your web server or database server getting killed by the Linux kernel, rendering your website inaccessible by legitimate users.
Outdated software
Outdated software is often the No. 1 problem with attack surface. With modern applications supporting plugins, add-ons and themes, the attack surface has never been larger.
WordPress, for example, is the most commonly used web application for blogging, allowing its users the benefit of custom themes and plugins to make their blog look unique. But while the WordPress "core" might be up-to-date and secure, any outdated plugin or theme with a vulnerability can lead to a blog getting compromised. And they do, with this as the main reason.
Similarly, applications running on the operating-system level (like authentication services, web-servers, ftp-servers and others), if out-of-date and with vulnerabilities out in the wild, can lead to severe increases in attack surface with automated attacks performed by bots.
Not having a DevSecOps approach
DevSecOps is a modern and refreshing way of handling web application development, incorporating security from the start of and right through the application development phase.
In the past, security and security-related testing was often the last step conducted on an application before release. Often pressed for time, security scans done at the last possible moment did not allow for cleaner code fixes. And "band-aid"-like fixes often lead to further security holes down the road.
Incorporating security directly into your application development process helps identify and eliminate sources of security vulnerabilities during the development process, allowing you to develop better fixes and patches which hold secure over time. This reduces your attack surface overall.
Lack of asset monitoring
Monitoring your assets for updates and patches is one of the most basic yet vital steps needed when using unknown or third-party assets in your web applications. Assets often interact with your databases and other critical parts of your web applications, and security holes in those assets can lead attackers directly to your sensitive and secure data.
Remember, any digital asset that you include or build your web application with becomes another possible source of attack vector.
Lack of security culture within your organization
Having a lack of cybersecurity culture within your organization is one of the easiest ways to increase your attack surface.
Employees saving passwords in plain text, not applying security practises to management and executives, not following up on newer security practises and not monitoring employees' security practises are all ways in which organizations fall short on security.
Organizations need to engage with their employees, to find reasons they might be increasing their attack surface. Common problems, like saving passwords in plain text, can be addressed by endorsing the usage of password managers.
Management and executives are likely to work with systems containing an organization’s more sensitive data, such as financial information, future plans and the like. Applying security practises to management and executives is crucial, as phishing and malware attacks are often targeted towards them.
Following up on employees is another important step many organizations fail to take. Keeping tabs on newer phishing emails employees may have seen and allowing them to report possible security faults are great ways to strengthen an organization's cybersecurity culture.
Last but not least, monitoring employees' cybersecurity practices is important, too. Following their newer habits takes time, and without followup and monitoring, employees may revert back to older unsafe cybersecurity practises, increasing your attack surface yet again.
Simply put, an organization is only as secure as its employees' security practises.
Unsecure dev environments
During an application's development, development environments are created to mimic production environments. These dev environments are often "loose" with security, and code stored in such dev environments contain various snippets of in-testing code.
Most often, dev environments run off virtual machines which make it easy to mimic production systems (CPU emulation, RAM limitations, etc.). Code in these dev environments is also likely to contain passwords, API keys and other tokens for easier testing and debugging. However, if these virtual machines or code are not secured, running end-of-life operating systems for applications which are in development for years can lead to an increase in your attack surface.
Similarly, attackers can get into your unsecure dev environments and inject malicious code into your application in development. Then, once the application is pushed into production, attackers can gain access to the systems the application is running on. This is why securing dev and test environments is one of the most crucial steps in reducing your attack surface.
Not following best web dev practices
Following the best web development practises right from the start often leads to a well structured and procedurally built application, with fewer bugs and security faults compared to an application built otherwise.
Let's consider the following recommended web dev practises to help reduce attack surface:
Securing web servers
Your web server is the first piece of software in the line of attack, so having a well secured web server running with correct permissions and memory limits leads to a much more secure and safe web application environment.
Traffic encryption
Encrypting your web traffic is one of the most important steps to consider next. Usage of https is always recommended, leading to a more secure experience for all users of your web application.
Frequent security scanning
Only if you scan your web application would you know of any security faults that might exist. Therefore, frequent scanning is a must.
Permission monitoring
Monitor permissions granted to the team members developing your web application, as assigning team members with higher-than-necessary permissions and roles may lead to increasing your attack surface. Adjusting permissions allocated to team members to least-required privileges is often the best way to secure the permissions allocated to your web application.
Secure coding standards
Following safe and secure coding standards is key to eliminating common sources of security faults during the development stage itself. For example, prioritize the sanitation and filtering of user inputs before inputting or requesting data from the application database.
Summary
As you've now seen, some of the most frequently encountered problems leading to an increase of your attack surface are often the easiest to fix. Some can be fixed by following better development processes like DevSecOps, while others get inherited into your web application due to an increase in complexity or usage of unknown assets.
The most effective solution to reducing your attack surface is to scan your web application often for these commonly seen problems. Scanning your application will keep you mindful of security faults, assets, unknown libraries and other potential problems, allowing you to fix and resolve them before attackers can take advantage.
There are more ways to fix the problems you might find with your attack surface. Our Attack Surface Reduction tool brings greater awareness to your attack surface and prevents cyber attacks by showing you a complete picture of your digital risks.
