Hi all, I’m here to talk about a little known web vulnerability that Bryce Boe already touched on. Execution After Redirects are logic flaws in web applications that can lead to Information Disclosure and Broken Access Controls.
What’s an EAR?
Well, an Execution After Redirect (EAR) flaw is when a developer causes an HTTP redirect to occur, typically via a web framework. The developer assumes that execution stops after the redirect, however, execution continues.
Let’s look at a Ruby on Rails example (names have been changed to hide the guilty):
class TopicsController < ApplicationController def update @topic = Topic.find(params[:id]) unless current_user.is_admin? redirect_to "/" end if @topic.update_attributes(params[:topic]) flash[:notice] = "Topic updated!" end end end
It appears that if the current user is not an admin, they are redirected to “/”, the web site root. In fact, if you access the update controller using a browser while not an admin, it will redirect you to the web site root like expected. However, if an attacker who is not an admin makes a request with topic parameters, she will be able to update your topic without being an admin!
How do I fix it?
The fix is pretty simple, always
return after a redirect!
EARs can be more complicated. For example, there’s a controller that calls a method that calls a redirect. The real fix is to know where your redirects are, and what they’re for, especially if you use a redirect during authentication.
What else is vulnerable?
Web application frameworks differ on if they stop execution after a redirect. Check your web framework’s documentation to see if the redirect method stops execution.
What am I doing about it?
Bryce Boe and I are writing a paper studying this problem in depth. However, since I am alerting developers to potential EARs in their code, I wanted to have this informational blog post giving an overview. In addition, I developed a tool to staticially detect EARs in Ruby on Rails. Look for more blog posts in the future about the tool.