With the Internet, anything is possible, at least that’s how it appears. However, the real power behind much of the Internet came to fruition with the rise of web applications in the late 1990s. Although web applications existed before the 1980s, they evolved into much more complex programs by the turn of the century and have progressed even more with mobile devices.
Now, new applications launch every day; some become obsolete and die, and some launch and dominate the market. The G-Suite alone, Google’s popular set of applications, provides numerous services from email to documents to spreadsheets to schedules. Yet, with the rapid turnover rate and high traffic/usage of such apps, security sometimes takes a back seat. A 2015 study found that almost all of the participants had experienced a Web Application breach within only one year.
As threat awareness increases, web security researchers and industry leaders hope more entities will implement an action plan for securing the web application environment. Do you know the importance of having a web application vulnerability management plan in place for your company? Read on to find out more.
Why is a Web Application Vulnerability Plan Important?
Web Applications refer to any computer program that performs a specific function by using a web browser as the client (the program used to run the application). In the past, computers acted as the clients, or what the program ran on; however, in the case of web applications, the web browser becomes the client. For example, an individual may be using Google Docs (a web application) on their computer, but what is really running the application is the Internet, which serves as the client. It may seem elementary to review this basic concept, but it underscores how interwoven web applications are in everyday life. The hundreds of times employees and society use the Internet at work and at home are likely instances when web applications are also used.
The benefits of web applications are numerous, including flexibility, scalability, and increased redundancy. Since clients operate via a web browser, the computer type or operating system does not affect accessibility (e.g., Google Docs can be accessed on any computer as long as there is Internet connectivity). In theory, all that matters is Internet access (and sometimes a particular browser). Location no longer limits access nor do device types affect usability. This allows employees to work from different locations and collaborate at any hour of the day. Likewise, developers possess the power to tailor and scale web applications based on a business’ needs.
However, the dispersed nature of web application compatible devices expands the threat surface entities must worry about. Security strategies should address the entire interconnected system with access to a web application (i.e., any potential entry point for a threat actor). Consequently, proactively formulating a web security plan, rather than relying on reactive measures when a breach occurs, will likely improve an entity’s reputation and reliability as well as reduce damage costs. A Ponemon Institute study reported web application attacks cost approximately $3.1 million per year, with the greatest drain on resources stemming from incident response and technical support. Even more concerning is the amount of data linked to web applications. One breach can affect millions of people, leak staggering amounts of PII, and destroy client-customer trust quickly. In short, developing a web application security plan is both monetarily and PR savvy.
Common Application Vulnerabilities
In order to best protect web applications from security issues, it’s important to “know thy enemy” or at least the most common means of exploitation. The Open Web Application Security Project (OWASP) publishes reports on web application vulnerabilities. In 2017, OWASP listed the following points as the top ten web application security risks.
- Injection – when an attacker sends hostile data to an interpreter. A normal command may include a line of “injected” code that compromises a system. SQL, LDAP, XPath, or NoSQL queries are prone to injection vulnerability; however, ut and fuzzers (which test for command execution vulnerabilities) reduces the likelihood of injection attack success. Injection threats may result in data loss, denial of access, or a complete loss of system control.
- Broken Authentication – systems may be compromised when access management or user logins are not properly implemented. OWASP notes that hackers most likely have access to valid username and password combinations, as well as default passwords, or unexpired session tokens. If proper authentication management is not implemented prior to a full application launch (i.e., company usage), threat actors may gain access via a back door (e.g., using default passwords). A broken authentication attack is particularly lethal, as only one compromised log-in could endanger an entity’s entire system and stored data.
- Sensitive Data Exposure – data exposure refers to the vulnerability of transmitting and storing data. OWASP cites the mistake of not encrypting data as the major cause for such breaches. PII is particularly at risk from sensitive data exposure attacks. Man-in-the-middle attacks or server attacks fall under this category.
- XML External Entities (XXE) – this threat vector refers to XML processors, particularly older ones, that become compromised and result in data extraction, DDoS attacks, or the execution of remote requests.
- Broken Access Control – when access is not restricted, unauthorized parties may infiltrate the system or steal confidential data. Although Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) tools remain beneficial to a company’s security plan, the best means of combatting broken access control breaches is manual testing.
- Security Misconfiguration – refers to breaches via unpatched flaws, default accounts, or unprotected data systems. This covers a broad swath of application implementation components, including web servers, pre-installed virtual machines, network services, code, storage, etc. OWASP recommends utilizing automated vulnerability scanning to test for misconfigurations.
- Cross-Site Scripting (XSS) – occurs whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. In other words, when users believe they are accessing a secure, legitimate site, threat actors have injected malicious code into the application through the user’s browser. Consequences include rerouting to malicious sites and hijacking user sessions.
- Insecure Deserialization – deserialization (i.e., creating an object from bytes) becomes unsecure when untrusted code is deserialized to create a vulnerability/remote code execution. In simplified terms, such an attack could be compared to packing a suitcase (serializing) and then unpacking (deserializing) it only to find a rat hiding in the clothes. As this is a more complex type of attack, it is also more lethal.
- Using Components with Unknown Security Vulnerabilities – application components include libraries, frameworks, and software modules. If any one of these components becomes compromised, the whole application is at risk to web server hijacking or data loss.
- Insufficient Logging & Monitoring – systems must be constantly monitored and tested with the goal of quickly detecting any breaches or potential vulnerabilities. OWASP reported that it typically takes 200 days to detect a breach and, in many cases, outside entities alert companies of the breach.
Creating a Plan
In addition to detailing the risks to web applications, OWASP provides numerous resources and recommendations for developing a security plan. With each of the above vulnerabilities, OWASP describes how to check for vulnerabilities, outlines attack examples, and details how to prevent each particular attack. However, there are some overall security aspects to consider when creating a web application vulnerability management plan including awareness, planning, implementation, management, and testing.
Awareness
Although most security professionals would likely admit web application security is important, many still do not consider it critical. Yet, web application attacks continue to increase, especially with the Internet of Things (IoT) growth. Reports note a 30% increase in web application attacks from Q2 to Q3 in 2017 alone. Increasing awareness begins internally, making sure employees and security teams understand the threat of web application attacks before rather than after a breach occurs. However, improving awareness also requires transparency, to some degree, with other entities. Sharing attack metrics may help other companies better protect their networks and prevent data theft.
Source: Akamai State of the Internet Report 2017
Planning
The power of planning and organizing cannot be overstated. Putting adequate effort into the planning phase increases the likelihood of a well-developed and effective security plan, rather than engineering quick fixes later in the process. To start, entities should consider where their current security policies succeed and where they fail, with a particular focus on web applications. After analyzing existing policies, create a threat matrix mapping the most at risk threat vectors. Brainstorming is a key aspect of the threat matrix process that allows employees to challenge security assumptions. Furthermore, a certain amount of imagination when considering threats may lead to a breakthrough and highlight a previously unknown vulnerability. The next step focuses on formulating a plan around the vectors deemed most at risk. A sound plan will save resources and strengthen security weaknesses.
As a model process, Computer Weekly suggests the following steps: collect information (e.g., on URL accessibility, IP whitelisting), conduct risk profiling, define priorities and specs of web applications, outline the objectives, create a role-based access control matrix (i.e., mapping functionality to authorized access points), and, finally, select appropriate security tools. Overall, it’s important to maintain balance throughout the planning process, making sure to not spend an excessive amount of time on one step while overlooking or skipping another step.
Implementation, Management, and Testing
After selecting which security tools to put in place, entities must begin the implementation, management, and testing phases. All three of these steps are fluid, and communication should go back and forth between those working in the different phases. As new applications are launched or implemented, new methods should be examined to increase security. For example, the first tool to implement will likely be a Web Application Firewall (WAF).
WAF implementation should be a priority before launching or using a web application, since it is arguably one of the first lines of defense against threat actors. WAFs provide a barrier, or check point, between a user’s browser and the application. Unfortunately, research suggests enterprises fail to understand how WAFs operate and, consequently, implement them incorrectly. Additionally, entities sometimes spend minimal time on WAFs, as their focus centers on performance over security.
Consequently, it’s important to choose/develop a WAF that best fits a system’s architecture. OWASP’s Web Application Firewall Evaluation Criteria Project offers numerous resources for determining which type of WAF to choose and how to modify it to better fit an enterprise’s needs. Keeping abreast of new WAF developments and recommendations will also help mitigate security vulnerabilities and improve firewall deployment. For example, VPNMentor recently listed the 5 Best Web Applications Firewalls for 2018.
After implementing WAFs and other chosen security measures, testing should be an on-going task that focuses on proprietary (internally-designed) applications as well as any externally sourced applications (e.g., open-source applications used in a system). While WAFs defend the perimeter of a web application environment, examining authentication processes, access, and any third-party components will further strengthen internal security.
Due to the dynamic nature of WAFs and the time-consuming effort of security testing, managing these systems and safeguards requires significant time and resources. When Ponemon Institute surveyed prominent web application entities, 60% of respondents said they believe at least 3 to 5 people should be designated on WAF implementation alone. Subsequently, it is recommended, if possible, that entities designate a set group of employees to monitor each or several security aspects (e.g., two employees solely focus on WAFs) rather than simply lumping security responsibilities in with other departments.
What to Do Next
As with most security considerations, formulating a web application security management plan is a process — never stagnant and always adapting to new threats and security vulnerabilities. No plan is foolproof, and there will always be new vulnerability challenges. Therefore, it’s important to constantly re-evaluate existing security measures and look for areas of improvement. Users want constant access to applications; in fact, they often take for granted all the “behind the scenes” work that goes into securing such applications. Although ensuring good performance remains a vital part of web application development, it’s equally important to consider the potential loss in productivity/ revenue and damage to a system’s infrastructures due to a web application attack. With the widespread usage of web applications and the sheer amount of information they have access to, building a web application security plan warrants due consideration. To learn more about formulating an effective web application security management plan or other cyber security solutions, contact RSI Security today.
