Monday, December 25, 2017
Header injection in Sinatra Rack
Header injection in Sinatra Rack
Try to run this simple app:
require sinatra
get / do
redirect params[:to] if params[:to].start_with? http://host.com/
end
Lets load /?to=http://host.com/?%0dX-Header:1 and see a new "injected" X-Header in Chrome (not in FF) because %0d aka is considered by Chrome as a valid headers delimiter (dont really agree with this feature). OK, bad news are: Rack is the root of the problem. It uses internally as a delimiter for "arrays of cookies" so it blocks -based injections, but -based are working fine.
This means all web ruby software relying on Rack headers validation is vulnerable to header injection. Technically even Rails, they have "monkey patch" removing from "Location" header, but the rest of headers stay untouched.
Timeline
Reported to rkh from sinatra on 5 Jan. Under investigation, proposed fix was Rack Protection module.
Reported to Rails (not filtering non-Location headers), WontFix.
Lets talk about header injection
Now it is not useful, IMO. Yes you can create some new headers and such, but what can you do with it finally? Set-Cookie to mess with session_id/csrf_token is only option, am I right?
Overall it is a low-severity issue which can only insert new cookies. When browser sees non-empty Location it ignores all other headers but Set-Cookie. All you can do is BOMBIN
