Reading Time: 10 minutes

Chasing the application security rainbow – Do we run after software bugs instead of finding root causes?

Gábor Pék (CTO, Avatao)

cross-site scripting

Application security is one of the cornerstones of cybersecurity, and it is critical to defend a successful business operation. To strengthen cybersecurity defenses, businesses have to apply rigorous testing and remediate the issues that were found. An armada of white hat hackers are employed in large businesses and via bug bounty platforms to discover the software and network vulnerabilities of companies. It is a common sense, widely-accepted assumption that finding and fixing these issues will substantially increase the security posture of a company.

This is wrong. In this post, I argue that the vulnerability discovery, and hence remediation, is driven by the ability of hackers to discover issues and not by the real security impact of these vulnerabilities. In plain words, most reported issues are found because they are convenient to find, not necessarily because they are the major root cause for real security breaches.

This post highlights certain misconceptions and discrepancies in our behavior and attachment to certain customs that bias the effectiveness of our security defenses.

    Cross-Site Scripting under pressure

    Cross-site Scripting (XSS) is a great example. This threat vector is reportedly one of the most popular compromises today affecting a large number of sites worldwide. Even Google’s search bar has fallen into this trap in 2019. According to the 4th Hacker-Powered Security Report compiled by the bug bounty platform, Hackerone, XSS was the no.1 attack vector in 2020 comprising 23% of all reported vulnerability types. Another article on securityaffairs.co states that companies paid 4,2M USD for XSS bounties last year resulting in a 26% YoY growth in spendings. We need to underline also the fact that 28% of surveyed Hackerone hackers prefer searching for XSS vulnerabilities.

    cross-site scripting 1

    An interesting addition is that a 2017 post by Guy Podjarny from Snyk reported that XSS was not present as a root cause among the 1792 security breaches that Snyk reviewed. Guy’s article dates back to 2017 so it is important to refresh our knowledge and see more recent results that essentially confirm the same observation. The Cost of a Data Breach Report 2020 created by the Ponemon Institute and sponsored by IBM states that Cloud misconfiguration (19%), Compromised Credentials (19%), and Vulnerabilities in third-party software (16%) are the lead causes of data breaches, responsible for the majority of security breaches. If we take into consideration Phishing (14%) also as a next fraudulent act, still it’s quite difficult to tell if Cross-Site Scripting is part of these slices and to what extent. 

    cross-site scripting 2

    Compromised Credentials are too loose for XSS only, it must comprise many other vectors such as Injections, Broken Authentication, and many more. If we move on in good faith with XSS and state that the majority of these breaches are of this type, we cannot really top up its share to the maximum of 19%. For the sake of simplicity, let’s say that XSS was around 7-8% within Compromised Credentials. Don’t forget that we need to shuffle into this 19% most of the OWASP top 10 vulnerabilities and many other vectors (e.g., compromised passwords from other websites, binary exploits)  as well. We still have Phishing as a potential cover story for XSS, but we know that Phishing comes also in a wide range of types and cannot state that all the 14% is booked by XSS on its own. Let’s be generous and give 7-8% again to this great candidate. If we accept our percentage caps we end up in a final 14-16%. We could say that everything is correct as this is in line with the 18% reported by Hackerone. Still, we cannot leave the fact behind that these numbers are coming from companies that are either running security programs (e.g., Hackerone) or being surveyed by the Ponemon Institute. There seems to be a much bigger slice of companies (and countries) though who are shadowed by this data and possibly facing data breaches where the root cause was not XSS. Attackers always look for the low-hanging fruits in the first place to reach their goals and XSS is not the easiest way to cause real harm. As it requires user interaction, its favor is a bit sour compared to other vectors (e.g., Injections, Third-party component compromises, or misusing cloud configurations) where the controls stay with the attackers all along the journey. The figure below (data is from 4th Hacker-Powered Security Report) shows that only a small fraction ($5,629,477 from $44,754,742) of bounty payouts are coming from countries except the USA. This can also bias our perception and we need to take this into account when reading numbers in reports. 

    cross-site scripting 3

    It doesn’t mean naturally that XSS doesn’t exist and should not be handled with the right prioritization. Rather, what we highlight is that there seems to be a much larger problem in the world of securing our assets than what we might focus on. Simply put, we might not see the forest from the trees. Staying with the example, Mario Heiderich from Cure53 explained various times why he strongly believes that XSS should be dead, but we don’t act in a way to defeat it. The question would be rightful, why pay out so much money for something that we already know how to defeat?

    Alright. Stop the story here for a second and let’s summarize some key observations.

    1. Reportedly, there is a huge problem with XSS that is affecting a large number of sites and we pay millions of dollars to fix it

    2. These bounties are coming 87% from the USA and we don’t know a lot about the rest of the world.

    3. XSS is A7 on the 2017 OWASP top 10 list, but a non-official OWASP top 10 2021 proposal created by Ivan Wallarm (founder and CEO of Wallarm) positions it as A3 stating that 20% of all vulnerabilities found in the last 3 years were XSS. We also know that OWASP doesn’t take into account in the prioritization process to what extent a given attack vector is misused or exploitable in the wild stating that “This approach does not take the likelihood of the threat agent” and “This rating also does not take into account the actual impact on your business.” (p. 20). 

    4. At the same time, Snyk states that XSS was not the root cause of any of the 1792 data breaches they examined in 2017.

    5. Companies keep paying for bounties without taking into account that these findings might not tell more than what we already knew: we are vulnerable to XSS (or any other attack vector) and we just simply ignore that the real problem is our wrong mindset: We focus on bugs instead of fixes, we praise bughunters and ignore those who design, build and maintain our system as Mario Heiderich highlighted.

    This is still not the final conclusion. Let’s move forward.

      Vulnerabilities vs. Data breaches

      Vulnerabilities carry opportunities for miscreants to exploit our systems and/or get access to sensitive data. Yet, not all vulnerabilities are created equal. We saw above that bug bounties may not alleviate our real security pains as these focus much more on the enumeration of vulnerabilities  and not on the real threat they mean for businesses . There are attempts, however, to utilize bounties in the SDLC process in reversed order (i.e., BBLC – Bug Bounty Life Cycle Model).

      These approaches just bring us back to the very same place where the problems are: our mindset.

      Others, such as Breachaware or HaveIBeenPwned, offer an online scanner to check if a given domain or email was a part of a security breach or not. They work from publicly available information and use a semi-automated approach to retrieve what type of data (e.g., email, password, IP address) was affected in a given data breach. The point here is that we need to focus on these data types while building our cybersecurity defenses. And here we are again. Generally, cyber defense strategies may spend too much time and resources on certain aspects (e.g., tools, automation, and post-mortem analysis) while we tend to forget that without a right understanding of our software and systems we are chasing our own tail. For example, security automation is a great revelation bringing us millions of dollars of savings (i.e.,– $3.58 million cost savings of fully deployed automation vs. no security automation in 2020), but we still forget the simplest rules. Automation takes the controls out of our hands and even the smallest pebble can cause huge damages. Can you imagine a targeted attack exploiting a 3rd-party open source component used by these automated defenses (e.g., Heartbleed’s impact is indisputable)? Well, chances are high knowing that “it has been estimated that FOSS constitutes 80-90% of any given piece of modern software” according to the 2020 FOSS Contributor Survey. 

      The average total cost of a breach at enterprises of more than 25,000 employees is  $5.52 million, compared to $2.64 million for organizations under 500 employees in 2020. We should not forget either that the real impact of breaches goes far beyond what we typically believe. Our businesses are highly interconnected so even the smallest breach may cause serious problems to our third-party vendors or vice versa (e.g., the avalanche effect of the SolarWinds breach). So there is definitely room for improvement.

        What to do then?

        First and foremost, we should slow down a little bit and accept the fact that we cannot build a strong line of defense only with tools and post-mortem solutions (e.g., incident response, bug bounties). Software today starts with people, requirements, and design. If we miss security at this phase, we are just topping our existing chaos. We should not reinvent the wheel, just simply accept that the wheel must be round and not any other shapes. The wheel here refers to our security consciousness. If we don’t know how to design, build and maintain secure systems from the very beginning, we cannot hope for a better situation. Without training our people who build these software systems, how could we expect a better and more secure future? 

        Even if we deliver training, we tend to focus on finding bugs (bug hunting and code reviews) while often ignoring the building part (threat modeling, secure coding, DevSecOps). We need to build common sense security-minded software development from which every stakeholder (e.g., software engineer, security champion, security manager, product people) benefits. Software engineers and security people should talk more frequently. They should learn from each other to reach predefined objectives together (e.g., create a new component with security by design). If they support the product with their knowledge and hard work then there is a chance to bring a cultural change. If security managers and product people give them space and time to learn and hone their skills, they are more likely to create robust and secure software. 

        At Avatao, we strongly believe that we should teach people how to build secure software by design in a function-oriented way rather than playing whack-a-mole with the hundreds of vulnerabilities that haunt developers. If we achieve this, the number and cost of data breaches will decrease dramatically over time. That is the whole point of preventive security.

        Related Articles

        Python best practices and common issues

        Python best practices and common issues

        Reading Time: 9 minutes Python is a high-level, flexible programming language that offers some great features. To be as effective as possible, it is important to possess the knowledge to make the most out of coding with Python.

        5 Key Challenges When Building a Security Training Program

        5 Key Challenges When Building a Security Training Program

        Reading Time: 6 minutes To build an enterprise security program, one has to go back to the well-known fundamentals of organizational change: People, Process, and Technology (originates from Harold Leavitt’s “Applied Organization Change in Industry”, 1964).