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.
00:24:21.160
I will wrap up now, but I'll be in the hallway for further questions. Thank you!