Context
An EAR (Execution After Redirect) occurs when, after a redirect, the web server does not stop its execution and extra information are revealed by mistake
Contributions
- categorize EARs and provide analysis of 9 frameworks susceptible of EARs
- an algorithm to detect EARs in Ruby on Rails applications
- a white-box tool tested on 18127 applications which found 3944 EARs
Approach
Analyzing framework behavior
- Ruby on Rails: the execution is not automatically halted after
redirect_to. Information leakage are impossible on this framework because a controller can either perform a redirect or render a response - Grails: behavior similar to RoR, but the render behavior is less explicit
- Django: Django’s documentation makes it clear that calling Django’s redirect function merely returns a subclass of the HttpResponse object. Thus, there is no reason for the developer to expect the code to halt
- ASP.NET MVC 3.0: similar to Django, prevent EARs by default
- Zend (PHP): not susceptible to EAR vulnerabilities because its redirect methods immediately result in the termination of server-side code, but this default behavior may be disabled
- CakePHP: not susceptible to EAR by default
- CodeIgniter (PHP): very lightweight PHP framework that offer protection against EAR, but only if the redirect function is used correctly
- …
Results of an hacking competition The EAR vulnerability was presented in an hacking competition. Only 12 out of 34 teams discovered the information leaked caused by the EAR
Algorithm for EARs detection The goal of our EAR detector is to find a path in the controller’s CFG (Control Flow Graph) of a SUT (system under test) that contains both a call to a redirect method and code following that redirect method.
- a white-box analysis is performed on the back-end code
- CFG are build for each controller
- redirect methods are found
- infeasible paths are pruned to reduce false positives
- detect EARs by finding a path in the CFG where code is executed after a redirect method is called
- use heuristic to differentiate between benign and vulnerable EARs
Evaluation
- 59255 open source Ruby projects were downloaded from GitHub
- 18127 of these had an app/controller folder, indicating a Ruby on Rails application
- 3944 EARs were found in 1173 projects, 885 were vulnerable
Limits
- The study is from 2011, therefore the default behavior of all the frameworks may be changed a lot
- classic limits of the white-box approach
- Only 60% found were true positive EARs
References
- (Doupe, Boe, et al., 2011)
- Tool available at https://github.com/adamdoupe/find_ear_rails