Metasecurity: Beyond Patching Vulnerabilities

Cross-Site Scripting (XSS)

Chase Douglas

1 talk

#web-security

#sql-injection

#cross-site-scripting-xss

#rails-security

#ruby-on-rails

#application-security

Metasecurity: Beyond Patching Vulnerabilities

by Chase Douglas

In the video titled "Metasecurity: Beyond Patching Vulnerabilities," speaker Chase Douglas discusses advanced methods of enhancing web application security, particularly in the context of Ruby on Rails applications. He emphasizes the need for a higher level of abstraction in security practices, termed 'meta-security,' which focuses on preventing the exploitation of vulnerabilities rather than merely patching them.

Key points discussed include:
- Understanding Security Attacks: Douglas highlights the dual aspects of security threats: vulnerabilities that can be exploited and the attackers looking to exploit them. He critiques common security practices that rely heavily on patching known vulnerabilities, illustrating the time and effort required to maintain up-to-date security measures.
- Challenges of Staying Updated: The speaker notes the complexities associated with keeping frameworks and libraries updated, particularly during major migrations, with Rails being cited for having an average of seven vulnerabilities a year.
- Web Application Firewalls (WAFs): While he acknowledges WAFs as a method to defend against attackers, they often require significant customization and expertise to configure correctly. Moreover, he notes that they operate at a networking layer, lacking deep integration with application-level logic.
- Illustrative Anecdote: Douglas recalls a historical example of how attackers breached a fortified castle by exploiting an overlooked access point, using this as a metaphor for gaps in security that can be overlooked in application defenses.
- Basic Vulnerabilities Illustrated: He explains two common types of vulnerabilities—SQL injections and cross-site scripting (XSS)—providing examples of how attackers exploit these weaknesses. He specifically references how improper user input handling in Rails applications can lead to severe exploitation scenarios.
- Proposal of Meta-Security: The core proposal revolves around focusing on the exploitation phase of attacks. By understanding and securing against potential exploitations, such as validating query structures before execution and controlling HTML input sanitization, applications can mitigate risks more effectively.
- Practical Implementation: Douglas shares how his team at Amuno employs these meta-security concepts by monitoring queries, inspecting templates, and taking proactive measures to enhance security against common exploit types.

In conclusion, Douglas advocates for a shift in approach within web application security—from simply patching known vulnerabilities to implementing systems that defend against the exploitation of those vulnerabilities. He encourages ongoing dialogue and engagement in improving application security across the Rails ecosystem.

00:00:12.480 Hello everybody! First of all, I’m going to talk about security. We had a bit of a scheduling snafu, and there was a flip in the schedule. I hope you stay even if you weren't originally here for security. It’s a pretty cool topic, and I want to thank everyone at RailsConf and the speakers who helped us swap things around so that we wouldn't have to be right up against Justin Collins and his own security talk, so thanks to RailsConf for facilitating that.

00:00:25.840 Today, I’d like to discuss how to defend against security attacks and propose a series of ideas built around the concept of defending against attacks at a higher level of abstraction—similar to how metaprogramming operates at a higher level. I want to investigate the possibility of defending against attacks at a higher level than we currently do today. Let’s start by talking about the anatomy of a security attack.

00:01:07.600 There are two sides to a security attack. One side involves a vulnerability, such as someone broadcasting that they will be away for two weeks. The other side is the attacker, who looks for information to exploit that vulnerability. The way we generally handle security today is by defending against vulnerabilities or attackers. To defend against vulnerabilities, we typically have many processes and policies in place; we audit our code, inspect our frameworks, libraries, and gems, keep track of lists of security vulnerabilities (CVEs), and ensure that our systems are up to date with the latest software.

00:02:02.280 However, staying up to date can be challenging. Anyone who has done a Rails 3 to Rails 4 migration knows it’s not an easy process. This often results in a cycle where you find out about a new vulnerability, then you have to patch, test, deploy, and retest in production, which consumes considerable time. It's fun to criticize PHP, which has 24 vulnerabilities on average for its core platform each year, but unfortunately, Rails has a similarly troubling record, with an average of seven vulnerabilities per year recently turning into double digits.

00:02:30.480 The problem isn’t just the existence of vulnerabilities but the amount of time taken to address them. Think about a site like WordPress.com, which hosts tens of thousands of blogs. If they need to deploy a new security patch every couple of weeks, it becomes a challenge. It raises the question: how quickly can you turn over your patches? Even if you can manage that quickly, you're only addressing the vulnerabilities that are currently known.

00:03:13.560 A study showed that vulnerabilities sold on the private market remain undiscovered for almost half a year on average before anyone detects and reports them. Moreover, the frameworks and libraries need to be updated and released, and this information then has to be communicated to everyone using them. They must notice it, update, patch, test, deploy, and so on. This issue is compounded by the existence of many vulnerabilities lurking in the source code, waiting to be discovered, which may be traced back several years.

00:04:05.120 Thus, defending against vulnerabilities has its dangers, and because of that, people have also turned towards defending against attackers. One primary method for defending against attackers is to use a web application firewall (WAF). However, unfortunately, you don’t get a mini Harrison Ford in a box to fend off your attackers. What you usually get is a black box piece of hardware that you install in your data center, and it looks for patterns of harmful actions. To optimize a WAF, you need to configure it specifically for your application.

00:04:49.440 This requires significant knowledge as you must go through all the different routes of your application, determining who should access them and when. Hence, on top of purchasing expensive equipment, you may need to hire consultants or security experts to ensure that you're using web application firewalls properly. Additionally, these firewalls operate at the networking layer and do not actually interact with your application, analyzing just patterns that look like SQL injections or cross-site scripting attacks. As such, at best, they can only make educated guesses.

00:05:46.720 To illustrate the problem with firewalls and security configurations, let’s take a field trip to the castle Gaillard in Normandy, France. In 123, it was under the control of the English king, angering the French king, who wanted to lay siege to it. To breach the strong rock walls, the French army discovered a way to enter the fortress through the castle’s toilet system, leading to the siege’s success through a point that was unguarded. This serves as a reminder of how difficult it is to configure comprehensive defenses, as attackers utilize sophisticated scripts and tools to spider through websites, searching for vulnerabilities.

00:06:57.920 Attackers scour every link and attempt to find every accessible page. Instead of trying to index content like Google, they look for buttons and forms to interact with a website, trying to inject anything they can, such as SQL injection and cross-site scripting attempts. If there’s a small breach in your defenses, it may be all they need to exploit your application. If someone gains unauthorized access, that's a false negative—a security failure. Conversely, a false positive occurs when your defenses alert you to things that aren't real threats, leading you to disregard them.

00:08:19.760 In severe cases, a false positive could block legitimate traffic, creating alert fatigue that desensitizes your team to security threats. When a security compromise occurs, whether a user has their credentials compromised or a breach in template rendering through cross-site scripting, you generally want to take action. For this, having too many alerts complicates identifying and addressing real issues.

00:09:29.600 The defense tools we use against attackers have problems, similar to those we face against vulnerabilities. I previously mentioned the anatomy of a security attack, which includes a vulnerability and an attacker. However, in reality, a thief doesn’t just enter your house to sit on your couch; they come to steal your valuables. Thus, the damage comes from exploitation, not just the act of breaking in. Therefore, can we devise ways to defend against the exploitation itself rather than just the attack?

00:10:19.520 This lends itself to the concept of meta-security—securing against the exploitation that an attacker attempts to execute. Consider the classic Indiana Jones scene where he tries to replace a gold statue with a weighted bag. The setup includes a booby trap designed to go off if the weight is improperly swapped. Here, the defense is against exploitation rather than solely focusing on the attacks or vulnerabilities.

00:10:54.640 Let’s explore two classes of exploitations: SQL injections and cross-site scripting. To illustrate how SQL injection works today, imagine a query in your application that incorrectly interpolates user input into a query string. This means that if a hacker uses a string to manipulate the query, they could retrieve all records or even delete entries from your database.

00:12:12.720 For example, a query designed to find a user with ID five could be manipulated by a hacker to return true for every record in your database. More dangerously, if they input a command to drop the users' table, this would delete all user records, which is catastrophic. This example simplifies the string interpolation issue, but Rails' Active Record might also fall prey during method calls that still create strings from user parameters.

00:12:56.640 Now consider cross-site scripting (XSS), where an attacker can run their code in someone else's browser through a site's vulnerability, like a signup form. An attacker might input a script into a last name field designed to execute when a legitimate user logs in. If the website fails to properly sanitize input, this could lead to exposed session tokens, allowing the attacker unauthorized access to user accounts.

00:13:43.600 Understanding how these vulnerabilities can happen requires a look at how rendering works in Rails, particularly the use of the 'html_safe' function, which may erroneously label input as safe, bypassing necessary security checks. When rendering, Rails uses safe buffers to prevent cross-site scripting, ensuring content is appropriately escaped.

00:14:44.760 However, real-world scenarios can still see cross-site scripting vulnerabilities emerge. For example, a gem that generates HTML may create unsafe conditions if user input is improperly handled, leading to XSS exploitation in an app. Security relies heavily on proper implementation; while helpers need to be marked as safe, failures on that front can result in potentially critical vulnerabilities.

00:15:33.520 Now, applying solutions like wrapping checks around 'html_safe' calls can help prevent misuse. Proposal includes checking where 'html_safe' is being invoked; if it comes from a known good location, it's likely safe, but if not, we must ensure relevant tags are escaped to mitigate potential threats.

00:16:40.120 With SQL injection, we see problems of directly interpolating user input into queries. To counter this risk, understanding expected query structures when executed via specific application code lines allows enhanced checks. Future queries can be evaluated against what is deemed acceptable structure; any irregularities would be blocked.

00:17:34.920 In summary, while defending against vulnerabilities and attackers is essential, vulnerabilities will always exist, and attackers will continue to search for them, which makes it vital to establish defenses against the exploitation itself. This proactive strategy provides an important layer of security, even before addressing newly discovered vulnerabilities.

00:18:16.080 The reason I'm here today is to share how my team at Amuno is applying these meta-security concepts across various exploit classes, including SQL injection and cross-site scripting. We’re actively monitoring queries, inspecting rendered templates, logging headers, and implementing mitigation strategies for multiple potential risks.

00:18:58.560 We aim to enhance application security by blocking SQL injection attempts, slowing down suspicious logins, and employing capture mechanisms against brute force attacks. We’re taking this model and broadening it wherever we can integrate into Rails applications.

00:19:44.560 I want to express my gratitude to RailsConf for this opportunity to speak with you today and thank you for attending, especially given the schedule change. I’m eager to answer any questions you may have.

00:20:08.560 We recently announced our big unveiling at RailsConf and are currently taking beta signups. We'd love to hear your thoughts on whether our product effectively alerts you to potential threats against your server.

00:20:27.920 Please feel free to approach me after the talk or visit our booth in the exhibit hall. We’re here until the end of the day, and we would really appreciate the chance to discuss how our solution can help protect your applications.

00:21:02.840 Thank you.

00:21:45.440 Yes, the question is regarding the persistence and learning behind SQL injection. We address this by learning the structure when a query is first executed from a specific line of code. After that, we effectively lock that structure down, meaning future queries must conform to that initial structure.

00:22:32.840 We don’t have a learning period beyond the first query execution. However, we share learned structures with a backend service, which allows us to communicate across various application processes.

00:23:25.520 In response to concerns over variations in query structures, we monitor repeated executions and provide a mechanism for users to identify false positives. If a legitimate structural change occurs, you can register it in our system to adjust learnings.