Hello Steven,
On 6/21/2013 8:50 AM, Steven Siebert wrote:
Great, thanks to all.
I don't mean to defend our auditors, because they are a PITA, but they do
appear to be decently knowledgeable in general - but they aren't, not can
they be expected to, be specific application-level experts - otherw
Tanks for responding Johan.
I am indeed looking for MySQL session ID's, not an HTTP session ID. I'm
doing a defense in depth audit and reviewing potential threats to each
remote connection - in this case session fixation. I know I can set
various session timeout properties that help mitigate fix
Great, thanks to all.
I don't mean to defend our auditors, because they are a PITA, but they do
appear to be decently knowledgeable in general - but they aren't, not can
they be expected to, be specific application-level experts - otherwise, the
number of auditors we would be required to hire woul
Steven,
Am 21.06.2013 13:35, schrieb Steven Siebert:
If the TCP connection is lost...is the effectively session over and
can not be re-established on another socket?
Yes.
In a mysql client sense, I
would need to re-establish a connection and set my session variables again
rather than just r
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
p
Am 21.06.2013 12:48, schrieb Steven Siebert:
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.
There is no attack vector opening up by knowing a session ID. A
"sess
On 21.06.2013 13:35, Steven Siebert wrote:
> 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-establi
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 ... h
- Original Message -
> From: "Steven Siebert"
> Subject: Re: Session ID Generation
> I am indeed looking for MySQL session ID's, not an HTTP session ID.
> I'm doing a defense in depth audit and reviewing potential threats
> to each remote connection
Mysql assigns its session IDs sequentially as they come in. I suspect, however,
that you're looking for session IDs as used by websites -generation of those is
entirely not a mysql issue, it is only a potential store for them.
Steven Siebert wrote:
>Hello all,
>
>I've looked though, what I beli
10 matches
Mail list logo
