Hartmut/Denis - Great information, thank you! I was unaware that mysql bound the session id to the socket in such a way that it would not permit that session id to be provided on other socket. This was the missing piece.
Hartmut - if the session Id is not a meaningful part of the client/server protocol, is the session managed my the transport layer rather than the app layer? If the TCP connection is lost...is the effectively session over and can not be re-established on another socket? In a mysql client sense, I would need to re-establish a connection and set my session variables again rather than just reconnect using the session ID from the "dropped" connection? I apologize about these basic mysql-mechanics questions - I need to satisfy our auditors, so I need to understand =) Thanks, S On Fri, Jun 21, 2013 at 7:13 AM, Hartmut Holzgraefe <hart...@skysql.com>wrote: > On 21.06.2013 12:48, Steven Siebert wrote: > > > You stated these IDs are sequential...do you know if there is any way to > > modify this to utilize a "random" generation? Sequential session IDs are > > an avenue to session hijacking. > > as a MySQL client session is bound to a specific TCP connection ... how > would being able to predict a session ID help with hijacking that TCP > session? Even more so as the session ID is not really part of the > communication protocol between client and server at all and more like > an identifier for SHOW PROCESSLIST (that would most likely be visible > to an internal attacker anyway) and KILL (which requires SUPER > privileges on the database anyway, and at that point you've already > lost to an attacker ...) > > -- > Hartmut Holzgraefe <hart...@skysql.com> > Principal Support Engineer (EMEA) > SkySQL AB - http://www.skysql.com/ > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/mysql > >
