Ruby - Rails Routing: Advanced Routing Concepts and Techniques

Greetings, code warriors. Welcome back to another Programming Thursday session. Today, we’re going to dip our toes into the deep waters of Ruby - Rails routing. Now, don’t be alarmed, this isn’t your average tutorial. We’re going to delve into advanced routing concepts and techniques. Get ready to crack some serious code. So, gear up, as it’s time to navigate the winding roads of Rails routing.

Routing in Rails: The Basics

First off, a quick recap for our Ruby initiates. In the Rails universe, routing is the wizard behind the curtains, orchestrating the grand play between a user’s request and the corresponding action. Here’s a little diagram to visualize this:

Routing bridges the gap between the HTTP request and the controller action. It’s the translator, the traffic cop, and the switchboard operator, all rolled into one. But, like everything else in Rails, it’s also a pliable tool you can bend to your will, once you know its ins and outs. That’s where we’re heading today.

Route Customization: Going Beyond The Basics

Most Rails apps will get by just fine with the basic ‘resources’ routing structure, which auto-generates a set of RESTful routes. But when you’re a pen tester or a red teamer, ‘just fine’ rarely cuts it, right? You need to have complete command of your tools.

resources :photos

The code above is compact, but it also provides a complete set of routes for a Photos resource:

GET    /photos        # maps to the index action in the Photos controller
GET    /photos/:id    # maps to the show action
GET    /photos/new    # maps to the new action
POST   /photos        # maps to the create action
GET    /photos/:id/edit # maps to the edit action
PATCH  /photos/:id    # maps to the update action
DELETE /photos/:id    # maps to the destroy action

That’s efficient, and we love efficiency. But let’s push the boundaries.

Controlling Routes Verbosity

Imagine a scenario where you only need the show and index actions. It’s overkill to define all those routes, right? Don’t worry, Rails got your back:

resources :photos, only: [:index, :show]

Or the opposite scenario. If you don’t want destroy to be available for security reasons:

resources :photos, except: [:destroy]

Nice and clean, isn’t it?

Nesting Routes

Now, let’s make it complex, just for fun. How about nested routes?

resources :photos do
  resources :comments
end

This will give you routes for comments that are nested under photos. So a path will look like /photos/:photo_id/comments/:id.

And just like before, we can limit the routes for nested resources.

resources :photos do
  resources :comments, only: [:create, :destroy]
end

In this case, a comment can only be created or destroyed in the context of a photo. Makes sense, doesn’t it?

More Than A Resource: Singular Resources and Non-CRUD Actions

In Rails, not everything has to be a full set of RESTful routes. What if we have something that does not need an ID, something singular like a profile or a session?

resource :session

Notice resource instead of resources. It only makes routes that apply to a single thing. There are no index or show routes here, because we don’t need an ID to find our resource.

How about non-CRUD actions? In addition to the standard set of routes that Rails creates with the resources method, you might want to add routes for some non-standard actions. Here’s how you do it:

resources :photos do
  member do
    get 'preview'
  end
end

This will recognize /photos/1/preview with a GET, and route to the preview action of PhotosController.

If you want to add a route that applies to all photos rather than a single photo, you can use the collection method:

resources :photos do
  collection do
    get 'search'
  end
end

This will recognize /photos/search with a GET, and route to the search action of PhotosController.

Advanced Constraints

Being able to control what goes into your routes is fantastic. But sometimes you want even more control, like being able to specify constraints. This is where advanced routing comes into play.

Dynamic Segments

Let’s start with dynamic segments:

get 'photos/:year/:month/:day', to: 'photos#show'

In this case, :year, :month, and :day are dynamic segments. They’ll be available in your action as params[:year], params[:month], and params[:day].

Constraints

But what if we only want to accept valid dates? We don’t want someone typing in /photos/2023/25/66 and expecting it to work, right? Constraints to the rescue!

get 'photos/:year/:month/:day',
    to: 'photos#show',
    constraints: {
      year: /\d{4}/,
      month: /0[1-9]|1[0-2]/,
      day: /0[1-9]|[12][0-9]|3[01]/
    }

In the above code, we’ve used regular expressions to define valid values for each dynamic segment. Now, a request to /photos/2023/25/66 will not be recognized by this route.

Advanced Constraints with Request Properties

That’s cool, but we can go even further. Did you know you can apply constraints based on other properties of the request? For example, if you want a route to be only accessible for a specific IP:

get '/admin_panel', to: 'admin#dashboard', constraints: { ip: /192\.168\.1\.\d+/ }

This route will only be recognized if the request comes from an IP address in the 192.168.1.* subnet.

Catch-all and Globbing Routes

Lastly, let’s discuss wildcard segments, also known as “catch-all” and “globbing” routes. These are especially handy when dealing with unknown or unexpected request paths.

get '*path', to: 'errors#not_found'

The wildcard segment *path will match any route that hasn’t been matched so far. In this example, it’ll route to the not_found action of ErrorsController.

For security reasons, you may want to monitor such traffic.

get '*path', to: 'monitoring#unmatched_request'

Now, all unmatched requests will be routed to MonitoringController’s unmatched_request action. This will allow you to log and inspect the rogue requests.

Cybersecurity Implications of Routing

Routes, my fellow hackers, can reveal more about an application than you may initially think. They are a window to the app’s inner workings and, if not properly secured, can be exploited.

Information Leakage

Routes often reveal the structure of an application. Consider the route GET /admin/users. It gives away the existence of an admin namespace, along with a users resource. This is a treasure trove for anyone trying to infiltrate your system. Therefore, obscuring route names could be a good first defense line.

# Instead of this
namespace :admin do
  resources :users
end

# Do this
namespace :a1b2c3 do
  resources :x4y5z6
end

The new route GET /a1b2c3/x4y5z6 doesn’t spill any beans about your structure. Of course, you have to balance security with usability here.

Unauthorized Access

Routes must always be authenticated and authorized. Let’s say you have an OrdersController and a destroy action that deletes an order. If it’s not properly authorized, any user could potentially delete any order!

# Before
def destroy
  Order.find(params[:id]).destroy
  redirect_to orders_url, notice: 'Order was successfully destroyed.'
end

# After
def destroy
  current_user.orders.find(params[:id]).destroy
  redirect_to orders_url, notice: 'Order was successfully destroyed.'
end

With the latter example, a user can only delete an order that belongs to them.

Route Injection

Dynamic segments are a blessing and a curse. They make routes flexible but also introduce the potential for injection attacks.

# routes.rb
get 'products/:name', to: 'products#search'

# products_controller.rb
def search
  @products = Product.where("name LIKE '%#{params[:name]}%'")
end

In this case, a savvy attacker could use a SQL Injection through the :name parameter. The solution? Never trust user input and always sanitize it.

# products_controller.rb
def search
  @products = Product.where("name LIKE ?", "%#{params[:name]}%")
end

Analyzing Routing for Vulnerabilities

As you hunt for vulnerabilities, you will often start by enumerating all the available routes. If you have access to the codebase, that’s as simple as running rake routes. If you don’t, it may involve spidering the site or even educated guessing.

Once you have your list, it’s time to put those routes under a microscope. Look for patterns. Are the routes RESTful? Do they use any dynamic segments? What about nested resources?

Armed with this information, you can start your attack. This is where your favorite tools like Burp Suite or OWASP ZAP come into play. You want to see how these routes react under stress.

Does the route leak any information in its response?
Can you access the route without authentication?
Does the route accept verbs it shouldn’t?
Can you manipulate a dynamic segment to gain unauthorized access?

Remember, as a pen tester or a red teamer, you’re looking to probe every nook and cranny of the application.

Securing Routes

In this world of constant threats, it is crucial to ensure your routing does not become an entry point for attacks. Here are a few tips:

Always authenticate and authorize: If a route should only be accessed by a logged-in user, ensure it is so. Rails’ before_action can help here.
Sanitize dynamic segments: As seen earlier, unsanitized dynamic segments can lead to injection attacks. Always sanitize and validate these segments.
Limit HTTP verbs: If a route should only respond to a GET request, ensure it doesn’t accept POST or DELETE.
Obfuscate routes: To prevent information leakage, avoid using too obvious names for your routes.
Keep an eye on the logs: Unusual route requests often precede an attack. Keep an eye on your logs and set up alerts for suspicious activity.

Navigating the routing labyrinth can be complex, but as you delve deeper into Rails’ routing, it becomes an exhilarating journey. It’s a game of cat and mouse between you and potential infiltrators.

Conclusion

Well, fellow code warriors, I hope this deep-dive has given you a better understanding of Rails routing’s power and flexibility. There’s a lot more to routing than meets the eye, and I trust you now have a better grasp of it.

As red teamers and pen testers, you now have more tools in your arsenal. Play around with constraints, explore singular resources, and monitor those wildcard routes. Remember, you’re only as good as your tools.

In our next Programming Thursday, we’ll turn up the heat, talking about HTTP requests in depth - we’re going to dissect them like a frog in a biology class. Until then, happy hacking!

Routing in Rails: The Basics#

Route Customization: Going Beyond The Basics#

Controlling Routes Verbosity#

Nesting Routes#

More Than A Resource: Singular Resources and Non-CRUD Actions#

Advanced Constraints#

Dynamic Segments#

Constraints#

Advanced Constraints with Request Properties#

Catch-all and Globbing Routes#

Cybersecurity Implications of Routing#

Information Leakage#

Unauthorized Access#

Route Injection#

Analyzing Routing for Vulnerabilities#

Securing Routes#

Conclusion#