My friend Luke recently published a great blog post titled: The Ruby on Rails _json Juggling Attack. Please make sure you read this article once before jumping to the next sentence.
This is the perfect example to apply something I talked about during my keynote A Journey To Mastery at BSides Canberra.
During this talk, I covered how to consume content: blog posts, videos, news, tweets… Most people in the security industry will read Luke’s article and focus on its impact: you can add _json to an HTTP request to trigger unexpected behavior in Ruby on Rails applications.
This is usually the first step and what you may remember about the blog post. Unfortunately, (too) many people stop there: “Done, that was great! Let’s be productive and read the next article on my to-do list!” But we won’t stop there, as that’s the goal of this post.
What can I learn from this?
The second step is to ask yourself: “What can I learn from this?” Read the article again now.
Quite a few things. First, this is something you can only discover by reading Ruby on Rails source code (unless you’re extremely lucky). Some quirks can only be found through code review, and that’s often how you reach the next level. You can’t always pentest or brute-force your way to cool bugs or unexpected behaviors. Sometimes, putting in the work is essential, and that often means reading the code of a big framework. It’s painful, but it’s the price to pay.
Secondly, you can learn how someone like Luke works. He uses Docker; he uses curl. He quickly creates small applications to test behavior and validate what he finds during his code reviews. This setup gives him a rapid feedback loop—if he notices something worth investigating, he can verify it quickly without relying on a browser, a proxy, or a big web application.
You can also learn how to quickly create a Rails application to do some basic testing. The Dockerfile code is worth studying. This small application in a container is entirely created using one Dockerfile. This can be easily skimmed by a hasty reader. But again, you would miss so much great information. It’s all in the little details.
What patterns can I apply to something else?
Next step: What patterns can I apply to something else? Read the article again now.
There are a lot of patterns you can apply to other contexts.
First, frameworks and libraries may have special/magic keywords that are worth discovering. I can apply this to all my future reviews and look specifically for this pattern in my favorite framework.
Secondly, parameters available to developers are often in a specific order, which can vary based on the framework, the language, or even the configuration of the language’s engine (see PHP’s variables-order). I can apply this pattern to my favorite language or framework.
Thirdly, the order of these parameters matters and is worth learning about. You might find in your next review that this introduces a vulnerability. See CVE-2022-31683 for a real example of this.
Why didn’t I find it?
Next step: Why didn’t I find it?
Personally, I have a great excuse: Luke showed me this a while ago. But why might I have missed it otherwise? Maybe I don’t read enough code, or perhaps I didn’t focus on this type of issue. Time constraints could also be a factor. The real question, however, is: If I had reviewed the same code, would I have recognized the issue and understood its full impact? If not, why? What assumptions or limitations in my code review process might have caused me to miss this?
Final Thoughts
Hopefully, you enjoy this post. Worst case scenario: you’ll have read a great article on Ruby on Rails quirks a few times. Next time you read an article or blog post, ask yourself:
- What can I learn from this?
- What patterns can I apply to something else?
- Why didn’t I find it?
Next time you read an article, take an extra 5 minutes to reflect. It could uncover insights that others miss. You don’t have to do it for all articles, but spending a bit more time doing this will surely help you identify blind spots and find ways to improve.
