Re^4: Cookie->fetch problem

Hi:

It is setting the cookie with the session name as CGISESSID name and and the unique SID such as 08b6bf0fc7723abbc134fb0f1a09c5e8he SID generated with an MD5 hash using the username and password. This is done in the login iframe form and that hash is sent back to the server for verification. That sid is stored in the sessions table

Comment on Re^4: Cookie->fetch problem

Replies are listed 'Best First'.
Re^5: Cookie->fetch problem by huck (Prior) on Mar 09, 2017 at 23:49 UTC
and the unique SID such as 08b6bf0fc7723abbc134fb0f1a09c5e8he SID generated with an MD5 hash using the username and password. This is done in the login iframe form and that hash is sent back to the server for verification. That sid is stored in the sessions table OH NO!!!!!!!!!! you are talking about that as an hidden input field of the login form. Lets see what happens if you call `$session = new CGI::Session("driver:MySQL", $sid, {Handle=>$dbh, LockHandle=>$dbh});` with that "handmade" SID. it probably doesnt match a current session because CGI::Session uses some other method to compute its session ids, maybe even a md5 of the time+salt, so CGI::Session creates a new session and hands back ITS computed sessionid via `$session->id` that it uses internally. BUT you dont use that CGI::Session sessionid to set the cookie with, (which is used to call `new CGI::Session` the next time), instead you set the cookie to a value you (kinda) just made up it is fair to use your MD5 hash to check against a login table as a password, but that is not the sessionid CGI::Session wants to see. You need to set the cookie with $session->id instead so the next time thru CGI::Session can find the same session.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^5: Cookie->fetch problem
by huck (Prior) on Mar 09, 2017 at 23:49 UTC

and the unique SID such as 08b6bf0fc7723abbc134fb0f1a09c5e8he SID generated with an MD5 hash using the username and password. This is done in the login iframe form and that hash is sent back to the server for verification. That sid is stored in the sessions table

OH NO!!!!!!!!!!

you are talking about that as an hidden input field of the login form. Lets see what happens if you call $session = new CGI::Session("driver:MySQL", $sid, {Handle=>$dbh, LockHandle=>$dbh}); with that "handmade" SID. it probably doesnt match a current session because CGI::Session uses some other method to compute its session ids, maybe even a md5 of the time+salt, so CGI::Session creates a new session and hands back ITS computed sessionid via $session->id that it uses internally. BUT you dont use that CGI::Session sessionid to set the cookie with, (which is used to call new CGI::Session the next time), instead you set the cookie to a value you (kinda) just made up

it is fair to use your MD5 hash to check against a login table as a password, but that is not the sessionid CGI::Session wants to see. You need to set the cookie with $session->id instead so the next time thru CGI::Session can find the same session.

[reply]
[d/l]
[select]