00:00:10.580
Hello! So, I talk a lot, but I usually speak kind of low. You can see up here, I think Banksy tweeted this, or it came from a Banksy account. This is something that I don't abide by, as I tend to share everything about myself and everything I know.
00:00:18.570
When it comes to security, I pretty much talk a lot. You cannot ask anybody that works with me. First of all, I'm passionate about a couple of things: food, as you can probably tell, Ruby, security, and various other topics. One of the things we do at our Austin-based company is explore food establishments in Austin. Last night, we had a speaker dinner that was amazing.
00:00:39.480
If you haven't checked out the place we went to, it was fantastic. My colleague Alex, who is here from V Threat, agrees. Establishing credibility is one of the first rules of speaking, so I want to share a bit of my background with you, which will be a quick history of Marcus.
00:01:05.060
When I was 18 years old, I came from a really small town called Marlin, Texas. Has anyone ever heard of Marlin? Yes? It’s a tiny town with about 2,000 residents. I joined the Navy when I was 18 and worked in cryptography. I worked for the NSA for eight years and was also part of the Defense Intelligence Agency’s Cyber Crime Center.
00:01:30.659
These places involve either espionage or efforts to catch spies. I worked on a significant federal project to train federal agents on how to catch hackers. My work at CMS was vital because I was there during the major security incident that people refer to as the 'fire sale.'
00:01:54.540
I was responsible for securing that facility as a senior security guard. To reach Austin, I transitioned from Rapid7, where I worked in a Ruby-focused environment. After leaving Rapid7, I wandered in the wilderness of security, assisting people with various issues.
00:02:20.300
Over the past 20 years, I've engaged in securing systems, breaking into them, or intercepting communications, like reading your emails. Throughout all these years, I've noticed that nothing has really changed in the security landscape.
00:02:43.650
Security remains fundamentally the same. The most important goal for everyone is to maintain confidentiality, particularly if you write code. Many of you likely engage in platform or in-house development, and confidentiality is crucial for all of you.
00:03:00.120
At the end of my talk, I will attempt to demonstrate a hacking scenario involving a Rails application. I have previously been paid to hack into Rails apps, and I will write an app that showcases common mistakes I observe developers make.
00:03:19.350
The app I wrote highlights current issues that I see not only junior developers making but also senior developers. My passion for entrepreneurship stems from my experience with Ruby, which has allowed me to create my own company.
00:03:38.760
After leaving Rapid7, I wrote various hacking tools. It's intriguing because both good and bad individuals use these tools, and on Twitter, I have some followers who are hackers, which makes things a bit awkward at times.
00:04:00.900
I attended an accelerator in Virginia, which was a significant experience for me. The Ruby on Rails community is wonderful; it has enabled me to establish my company. Our application is mainly Ruby on Rails, and we also utilize Sinatra, making us a heavy Ruby shop.
00:04:25.500
At V Threat, we imitate attackers on networks to provide insights to what is known as the blue team in the security community. My goal today is to show you how our Rails apps can be compromised and provide tips and tools to help secure your applications.
00:04:46.980
A shout-out to Heroku, where we host our applications. It's crucial to understand that information naturally wants to be free. As Richard Stallman mentioned, you're likely to get hacked; you just need to recognize when it happens.
00:05:12.510
To determine if you’ve been hacked, you need to log everything. We use Papertrail logs to monitor errors and various events on our Heroku-hosted applications, and I will be providing heavy tips along with a demo.
00:05:58.440
Has anyone heard of Let’s Encrypt? It's becoming increasingly popular. I will also conduct a demo of Burp, a tool that helps attackers break into your web applications by manipulating various parameters.
00:06:35.010
Burp is a proxy that assists in testing web applications for vulnerabilities. In addition, there's an open-source alternative called ZAP. It's essential to understand the tools attackers use; even if your entire team doesn't need to be proficient, it’s wise for a few members to experiment with these tools.
00:07:06.510
Another tool I recommend is Nikto, which is written in Perl — often seen as blasphemous in a Ruby conference. Nikto helps in enumeration, checking certificates, and brute-forcing logins. It's a free resource to consider including in your security toolkit.
00:07:37.650
How many of you use Brakeman? It’s an important tool. If you’re not familiar with Brakeman Pro, check it out as it’s an excellent addition to the open-source version. I created an app and ran Brakeman against it, which revealed numerous vulnerabilities, providing a great way to conduct basic housekeeping of your Rails applications.
00:08:01.800
After addressing those vulnerabilities, I upgraded my Rails version and reduced my issues to one. The remaining problem is due to a disk e, which I should not upload to my repository. Another tool you should be aware of is Bundler Audit, which is crucial for maintaining security in your Rails applications.
00:08:28.440
We also utilize the 'devise' gem for our authentication needs. One of my amusing experiences was during a client meeting in Dallas. A customer inquired if we had two-factor authentication available, and I was embarrassed to admit we did not.
00:09:04.350
Immediately after the meeting, I returned to Austin, discovered a gem that provided that functionality, implemented it, and called the customer back to let them know that we now offered two-factor authentication.
00:09:34.480
I want to take a moment to discuss user models. I’ll share some basic information about how we implement them at V Threat. After evaluating various web applications and source code over the past years, I've formed a perspective that I would like to share.
00:10:21.990
When creating users and teams with Active Record, it integrates all functionalities seamlessly. Many developers utilize the 'devise' library for user authentication, which is widely adopted in the Ruby community.
00:10:44.990
We also use Devise at our shop. I want to explain how we implement it and the built-in functionalities it offers. I will demonstrate this for you.
00:11:01.859
It’s crucial to utilize the 'current user' context because it allows us to limit access for users to only their associated records. I encourage you to consider this pattern as it helps prevent unauthorized access.
00:11:22.610
We use UUIDs to create unique identifiers for every record we handle. It's critical to avoid exposing user information within fields, especially IDs, which can be easily guessed or manipulated by attackers.
00:11:58.090
I will also demonstrate the concept of the current user paradigm and how our application is designed around user input. We'll discuss how to manage user access to resources by structuring the models and their relationships properly.
00:12:43.039
By adopting these practices, we limit opportunities for unauthorized actions within our application, such as altering another user’s data. My methodology is to restrict users to their own data under all circumstances.
00:13:16.430
Now I want to show my contact information before I forget. You can reach me at my email, Marcus. My colleague Alex is also here, and we are looking for another senior developer.
00:13:56.420
Automation is a crucial aspect of development. I implemented Brakeman Pro to patch vulnerabilities within our application. The app I’ve named 'Weirdo' demonstrates intentional insecurity so that I can walk you through securing it live.
00:14:23.440
I've designed this app to be insecure intentionally to highlight common vulnerabilities. This live demonstration requires us to make a few sacrifices for the demo gods. I plan to show you my approach to securing applications.
00:15:01.800
In doing so, I will go through the process of securing it while simultaneously attempting to hack into the application to demonstrate the difficulties involved.
00:15:39.540
I will be alternately working between the real code and the Burp tool, all while switching between browsers to illustrate various interactions with the application.
00:16:08.100
Burp allows for the interception of all communications from the browser, facilitating the examination of vulnerabilities in real-time.
00:16:18.310
This live demo highlights real-world vulnerabilities and the importance of ensuring your applications are secure from the onset. I encourage everyone to explore tools like Burp, as they are invaluable in assessing security.
00:17:03.450
In my analysis of various applications, I've found that many developers expose too much information through hidden fields, which opens them up to risks. It's imperative to avoid this common pitfall.
00:17:31.540
Burp can also decrypt SSL connections, exposing plain-text traffic, which reinforces the notion that having an SSL certificate does not guarantee security. It's vital to implement further protective measures.
00:18:06.700
As I test our current implementation, I'll monitor user actions through Burp, which will showcase how easily attackers can manipulate user IDs and exploit existing vulnerabilities.
00:19:01.740
By attempting to access data from another user’s account, we expose the security flaws that need immediate attention before deploying applications in the production environment.
00:19:32.050
ID guessing can lead to significant security breaches, which emphasizes the importance of not relying solely on user IDs for record management.
00:20:02.500
The principle to remember is: never trust user data blindly. Implementing rigorous validation checks is crucial for securing your applications.
00:20:19.330
By associating user records with the 'current user' context and avoiding direct references to user IDs in your application logic, you can significantly reduce the surface for potential exploits.
00:21:01.980
I will also demonstrate how to manage new entries associated with the current user and ensure that these records are maintained securely without exposing sensitive information.
00:21:53.800
To conclude, ensure you use proper patterns to secure user information and manage database calls. Understanding how to implement these strategies in your development will help safeguard your applications.
00:22:50.990
It's important to remove unnecessary hidden fields, as they present a significant security risk. Streamlining the workflow behind user actions will minimize the potential for abuse.
00:23:23.380
Lastly, I want to thank you for your time and attention. If you have any questions or would like to learn more about securing your Rails apps, please feel free to reach out to me.
00:23:49.970
I appreciate the opportunity to share insights and tools that can assist you in enhancing the security of your applications. Thank you!
00:24:07.610
Automation is crucial in our field, as demonstrated in my earlier examples. Utilizing tools like Brakeman Pro and understanding their functionality will undeniably enhance your capacity to manage security.
00:25:32.250
Thanks for allowing me to share this information with you all! I look forward to discussing security further and hearing your thoughts on improving application resilience and security practices.
00:26:12.000
I encourage each of you to explore these vulnerabilities in your development process. Thank you again and have a great day!
