Why is Net::HTTP's set_debug_output dangerous if used in production?
There is a very useful method in Net::HTTP
library that gives ability to debug HTTP requests.
Here is what documentation says about that:
set_debug_output(output)
WARNING This method causes serious security hol开发者_运维技巧e. Never use this method in production code.
Set an output stream for debugging.
http://ruby-doc.org/stdlib/libdoc/net/http/rdoc/classes/Net/HTTP.html#M001371
What security hole is mentioned here?
Looking at the code, there is no other security hole, except for the fact that everything in the HTTP protocol is passed to the stream you provide. If you don't take care and the output is put somewhere you don't suspect it, this could expose the internal workings of you application.
IMHO, the statement in the documentation is pretty hard and doesn't provide a good explanation regarding the security hole. I think the comment should read something along the lines of:
Be careful and sit on your hands before you type, since setting a debug_output will expose the complete HTTP protocol (including possible sensitive information) to the stream that is passed in.
Long story short: there is no "hidden" security hole.
set_debug_output(output)
could expose sensitive user data.
At lines https://github.com/ruby/ruby/blob/trunk/lib/net/protocol.rb#L159 and https://github.com/ruby/ruby/blob/trunk/lib/net/protocol.rb#L196 all traffic is returned to whatever output
is provided and that could expose session ids, login credentials, credit card information, etc...
In the following example, the SENSITIVE DATA could be exposed to either $stdout
or $stderr
even when using SSL
require "net/https"
require "uri"
uri = URI.parse("https://ssltest7.bbtest.net/")
http = Net::HTTP.new(uri.host, uri.port)
http.use_ssl = true
http.verify_mode = OpenSSL::SSL::VERIFY_NONE
#SECURITY HOLE
http.set_debug_output($stdout)
request = Net::HTTP::Post.new(uri.request_uri)
request.set_form_data({"SENSITIVE" => "DATA"})
response = http.request(request)
More Net::HTTP examples
It could be due to the fact that setting debug on would allow your site to leak more information to an attacker. If someone was trying to break in, they could see exactly the errors they are causing, and thus make it easier to reverse engineer how your site works.
Beyond the exposure of information there are a couple other possible vulnerabilities.
You could use the fact that there is a file stream open that can be written to as a vector for injecting code. Dropping a payload via post requests.
You could also quickly fill a disk, compromising the availability of the logs.
You could take advantage of a vulnerability in a log parser/file viewer you know is going to be used to view the log by injecting an exploit into the file it's going to read.
There's likely a few more vectors I can't think of, but that's enough that I wouldn't want to do it unless it was very temporary and you'd have to convince me there was no other way in production.
精彩评论