Insert a proxy in between that reads "Set-Cookie: " and changes it to
whatever you want.

I have a tool called "Mangle" which can do this. (based on httpush)

Shout if you want it.

Rogan

> -----Original Message-----
> From: vertigo [mailto:vertigopanix.com]
> Sent: 06 February 2002 06:29
> To: Security Coordinator
> Cc: owaspowasp.org; webappsecsecurityfocus.com
> Subject: Re: OWASP How to test cookie manipulation
>
>
> That's a solution to the problem, but how does one change
> the values of non-persistent cookies?
>
> vert
>
>
>
> On Wed, 6 Feb 2002, Security Coordinator wrote:
>
> > On Wednesday 06 February 2002 01:10, The Owasp Project wrote:
> > > There was some great debate about how to test for
> > > Cross Site Scripting and I know Dennis Groves is
> > > capturing the relevant bits.
> > >
> > > This week we wanted to start some discussion around
> > > testing for cookie manipulation. We thought Unicode
> > > canonicalization can wait a week or two ;-)
> > >
> > > So how do you test for cookie manipulation ? Here
> > > are a few sampler questions we asked oursleves.
> >
> > You mean how does the server test for cookie manipulation
> at the client end?
> > Here's a scenario for having a "secure cookie".
> >
> > User Authenticates herself to my site, I assign a
> sessionid. I store the
> > sessionid, date, time, userid, and a random string in my
> session database.
> > I hash all the above information SHA1 or MD5, attach the
> sessionid to it, and
> > pass it back to the client as a non-persistent cookie.
> > Client goes to a page, presents the cookie, I look it up by
> the sessionid in
> > my database, and verify that the hash matches the original.
> > Now I can store other information in the cookie itself if I
> want to. Its
> > generally better to use one cookie for stuff you want to
> let the client
> > change in javascript, and leave the other one signed.
> > If you don't want to save session state on the server side,
> you don't really
> > have to do so, you can save just one server-wide private
> key that you sign
> > every cookie with, GPG would work fine for that.
> > You also have the option of either accepting the same
> cookie back multiple
> > times, or rehashing it after every page submission with new
> times etc (then
> > you can implement session inactivity timeouts).
> > You can also use a persistent cookie and have an auto-logon
> feature if you
> > like, just retire inactive session state to a more
> efficient storage and if
> > you get back an OLD cookie go look there to see who they
> were last time you
> > saw them and recreate their session.
> >
> > The main point is that as long as you mix some data into
> the cookie hash that
> > the client CAN'T know, you should have a signature they
> can't forge and it
> > isn't too computationaly intensive to do an MD5 (twice
> actually due MD5's
> > quirks) for every login.
> > >
> > > Do you need to know about Base 64 encoding ?
> > > How do you modify a non-persistent cookie ?
> > > How do you systematically change cookie values and
> > > test the results ?
> > > Whats the max size of values to try in cookies ?
> > > How do you look for delimiting values in cookies ?
> > > What values should you change and when should you
> > > not bother ?
> > > Hoiw can you figure our what cookie does what as
> > > well as what cookie value does what ?
> > > What type of tools can you use ?
> > > What payloads can you put into cookies ?
> > >
> > > To name but a few....
> >
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]