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!
