You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So Rack::Session::Redis#generate_unique_sid's unique session key generation logic does not work.
Reproduction
I checked with the following code, which is prone to session key collisions.
require"bundler/inline"gemfiledosource"https://rubygems.org"gem"sinatra","2.2.0"gem"webrick","1.7.0"gem"redis-rack","2.1.4"endrequire"sinatra"require"redis-rack"# Returns a counted-up value for each invocation since the process was startedclassCountupdefself.hex(len)@count ||= 0@count += 1sprintf("%0#{len}d",@count)endendenable:sessionsset:sessions,secure_random: Countupset:session_store,Rack::Session::Redisget"/"dosession[:access] ||= 0session[:access] += 1"sid: #{session.id}, access: #{session[:access]}"endSinatra::Application.run!
Procedure
Launch above application with ruby app.rb
Access by browser (sid: 00000000000000000000000000000001)
session[:access] increases with each access.
Kill ruby app.rb application and relaunch.
Access by secret browser (sid: 00000000000000000000000000000001)
session[:access] is initialized.
session is shared with first browser and secret browser.
The above situation occurs even with correct random number generation logic, although the collisions are fewer.
How to fix
Revert #37 is easy way, maybe.
If you want to avoid that, it would require a more complicated modification.
The text was updated successfully, but these errors were encountered:
@hogelog Given one uses the default SecureRandom.hex, and doesn't circumvent the logic for actually generating a random value, how often could a session ID collision happen?
@hogelog Given one uses the default SecureRandom.hex, and doesn't circumvent the logic for actually generating a random value, how often could a session ID collision happen?
Unfortunately, I don't know exactly how often ID collisions happen, as I noticed it while looking at the code.
SHA256 is hash function digesting to 256 bits. If SHA256 is a perfect hash function without bias, then a 256-bit input would be hashed to a 256-bit value without collision.
Ofcource there are no perfect random generator and hash function algorightms, real collision rate would be more often. But, in any case, collision rate would be not so high.
Rack::Session::Redis#generate_unique_sid
is a method that generates new unique session key that it does not conflict with an existing session key.But it seems does not work well after #37 PR.
session.empty?
.session
is always empty hash.Reproduction
I checked with the following code, which is prone to session key collisions.
Procedure
ruby app.rb
session[:access]
increases with each access.ruby app.rb
application and relaunch.session[:access]
is initialized.session
is shared with first browser and secret browser.The above situation occurs even with correct random number generation logic, although the collisions are fewer.
How to fix
Revert #37 is easy way, maybe.
If you want to avoid that, it would require a more complicated modification.
The text was updated successfully, but these errors were encountered: