Securing Your Rails App

Talks

Jim Weirich

#cross-site-scripting-xss

#authentication

#authorization

#rails-best-practices

Securing Your Rails App

by Jim Weirich and Matt Yoho

The video titled "Securing Your Rails App" features speakers Jim Weirich and Matt Yoho discussing the critical importance of security in Ruby on Rails applications. Despite built-in security features in Rails 3, the talk emphasizes that without careful attention, vulnerabilities can easily be overlooked. The presenters relate personal experiences and insights into web security challenges, guiding developers on how to protect their applications from potential threats. Key points of the presentation include:

Understanding Security: Developers must recognize that they cannot trust any components of their application, including user inputs through browsers and data from databases.
Common Vulnerabilities:
- SQL Injection: Explains how failing to sanitize user inputs can lead to SQL injections, potentially compromising the entire database. The presenters provide examples of how attackers can manipulate queries by injecting malicious inputs.
- Mass Assignment: Highlights the need to whitelist attributes for mass assignment in Rails to prevent unauthorized users from manipulating data.
- Cross-Site Scripting (XSS): Discusses how failing to sanitize user-generated content can allow attackers to execute malicious scripts, stealing user credentials.
- Privilege Escalation and CSRF: Warns about unauthorized access to restricted functionalities and how CSRF attacks can manipulate actions on behalf of legitimate users.
Security Practices: Recommends using Rails' built-in methods for database queries and focusing on proper input and output sanitization. The importance of maintaining vigilance over code and conducting regular security audits is also stressed.
Resources for Further Learning: Suggests reading the Rails security guide and the OWASP resources to build a strong foundation in web application security.

In conclusion, while Rails provides strong security mechanisms, developers must actively engage in protecting their applications by understanding vulnerabilities, applying protective measures, and thinking from a hacker's perspective to identify potential issues before they can be exploited. The talk encourages an ongoing commitment to security best practices, reminding developers that security is a continuous process.

00:00:23.119 Our first speakers are going to be Jim and Matt. I don't know if you've noticed, but all of them grew up on the mean streets of Chicago. The only way they could survive was by joining a group of extreme street ballerinas. That's how they made their living on the streets of Chicago. But today, rather than traversing the streets of Chicago, they are now coding in pure white. I want to introduce them as they will talk about securing your Rails application. So, please welcome Jim and Matt.

00:01:06.080 Thank you. Good morning, everyone. I know it's early in the morning, and I hear that the beer has already started flowing. I'm taking advantage of that. Good morning! That sounds better. We are here to talk about securing a Rails application. While we get the video set up, I have a quick question.

00:01:22.000 How many people here write Rails applications? Please raise your hand if you feel that your Rails application is totally secure. We've got a lot of smart people here who realize that security is a significant issue. I got interested in this topic a while back when I read an article by Patrick McKenzie. He took a look at the Diaspora Rails code, which is designed to be a privacy-focused Facebook replacement. You would think it would be a very secure Rails application, but as he investigated, he found numerous severe security errors. It turns out that due to coding mistakes, it was quite easy for someone to hijack another person’s account, leaving their private data unprotected because the Rails application itself was not secure.

00:03:11.680 This revelation made me reflect on my own work. I write a lot of Rails programs, so I began to wonder, how secure are my Rails applications? Although I've gone through all the standard security classes, I work in a corporate environment where they made us attend these classes to learn about issues like SQL injection. However, I began to question whether Rails truly provided adequate security measures.

00:03:39.599 Recently, I had the opportunity to pair program with a colleague at a Hackfest after the Cincinnati Ruby conference. He was working on code that monitors the power usage of the chip inside a car key fob. His project involves detecting the password by observing power function relations—the password requires more power to flip bits than to not flip them. The program's simulation figured out that a specific 64-bit key could be revealed based on this dynamic.

00:04:50.799 This experience made me realize the importance of thinking like a hacker. To secure a Rails application, you need to understand how hackers might think and the methods they could use. For our talk today, we will be discussing various security concerns and concepts related to writing secure applications. However, we are not claiming to be security experts. If you haven't read the Rails guides on security, I highly recommend it. The Rails security guide offers high-quality information on numerous security topics, and it’s a great resource.

00:05:22.160 Additionally, I want to point out a significant paper by Paco Weber for the Open Web Application Security Project (OWASP) that is about 48 pages long and serves as excellent reading material. OWASP is an authoritative source for web application security guidance. While the reading can be dense, it's well worth your time.

00:05:40.639 Now, let's discuss the architecture of a typical web application, which consists of a server, a browser, and a database. The first principle to remember is that you can trust none of these components implicitly. In particular, you cannot trust the browser because you don’t control what the user has on their device. Users can manipulate their browsers and send potentially harmful requests. You also cannot trust the database because it often contains user input, which can compromise security if not properly validated. Even the Rails server can be compromised; if someone corrupts your Rails application, there are larger problems at hand. So, we need to focus mainly on browser and database issues today.

00:07:01.040 Now, let’s dive into SQL injection, one of the most common security vulnerabilities. How many of you have heard of SQL injection? It's prevalent enough that it is usually covered in basic security programs. Let's say we have a controller method that’s supposed to find users whose names match a given filter text and who are not administrators. The crucial mistake here is not escaping the input from the user. If we directly place user input into our SQL query without proper sanitization, that opens the door for SQL injection attacks.

00:08:31.280 To illustrate this, we have a simple example application written to schedule movie nights with friends. The application has four users, and if we filter by one of the usernames, we see our designer Jerry. We then notice that the URL query parameter shows ‘filter=Jerry.’ This suggests we might be able to execute an injection attack. If we manipulate the URL and execute something like ‘1=1’, this could comment out the rest of our SQL query, allowing us to bypass the intended restrictions. This is how basic SQL injection works, and once you've opened the door, your entire database could be compromised.

00:10:15.760 To prevent this, Rails provides built-in methods to build SQL queries securely by using question marks as placeholders for user input. This way, Rails escapes the input properly, ensuring that dangerous characters, like quotes and comments, won’t disrupt the integrity of the query. Always utilize Rails’ built-in mechanisms for database interactions.

00:12:00.560 Next, let’s talk about mass assignment, a common oversight where we take user parameters from a form and apply them directly to a model without filtering. For example, when updating a user, if we pull attributes off the form without checks, a malicious user could submit additional fields—such as an admin flag—disguised as regular form fields. The critical takeaway is to whitelist the fields you approve for mass assignment to prevent unauthorized modifications. It is better to maintain a whitelist of allowed attributes than a blacklist of disallowed ones because a blacklist approach is more prone to oversight.

00:14:43.760 Another subtle security issue involves information leakage, particularly through timing attacks. These happen when a malicious user gathers data based on the timing of responses from your server. For instance, if you have a method checking a session key, and its processing time varies based on certain conditions, an attacker could deduce information about the key by analyzing response times. This is especially critical for authentication scenarios, where timing differences can reveal how close their guesses are to the valid key sequence.

00:16:43.920 Moving on to another significant threat, cross-site scripting (XSS) occurs when an attacker injects malicious scripts into a page that users can view. For instance, if we allow users to format messages with HTML and don't sanitize this input, an attacker could use JavaScript to compromise user sessions, steal information, or perform unauthorized actions. One classic demonstration is using the notes section to add harmful scripts. Instead of rendering safe user input, raw HTML can be interpreted by the browser, leading to severe security vulnerabilities. It’s crucial to avoid using raw rendering for user-generated input and sanitize any allowed inputs using methods like Rails' sanitize function, which filters the input to just the tags you want to allow.

00:20:04.799 Another example of XSS occurred with MySpace, where usernames and passwords were stolen through a cross-site scripting vulnerability. The attackers succeeded in creating fake login prompts to harvest user credentials. Next, let’s discuss privilege escalation, which is another common security risk. It occurs when users gain access to functionality that they are not authorized to use. For example, if your application retrieves a list of resources but does not check if the user is allowed to access those resources, a malicious user could simply modify the URL to access or manipulate restricted data.

00:22:25.440 Similarly, cross-site request forgery (CSRF) is when an attacker tricks a logged-in user into submitting a request to perform an unwanted action on the target site, exploiting the browser’s authentication. Rails provides a security measure against CSRF by generating an authenticity token for forms. This token must be included in the requests sent to protect against unauthorized actions. It's essential to ensure all forms in your application accommodate this token automatically. Furthermore, ensure that your application handles session data securely, for instance, marking cookies as HttpOnly or securing them with SSL to prevent interception.

00:24:14.639 In conclusion, when we started this talk, I anticipated finding numerous problems in Rails, and indeed, vulnerabilities exist, but many can be mitigated with security best practices. Rails does a lot by default to secure applications, but developers must be mindful to avoid compromising these defaults. Remember the key takeaways: trust nothing; routinely patch your application; use libraries and frameworks responsibly; and maintain vigilance over your codebase. Finally, think like a hacker to proactively identify potential vulnerabilities in your applications. We are out of time, but I welcome one last question. Yes, did you look into the OWASP SAP project and how it compares to Rails security measures? No, I haven't looked at that. Have you, Matt? While I’m aware of it, I have not compared it deeply. It may be worth investigating. Automated tools can assist in identifying these security holes, and it's a good idea to conduct regular security audits. Thank you very much!

Ruby on Ales 2011