Session Fixation Checking

[zapbot]

What steps will reproduce the problem?
1.Download Zap
2.Run Zap
3.Scan the web application

What is the expected output? What do you see instead?
Session Fixation issues could be detected by Zap, but currently, Zap offers no functionality
in this area. Session Fixation issues remain un-reported.

What version of the product are you using? On what operating system?
Zap 1.4.0.1 on Linux (Ubuntu 12.04)

Please provide any additional information below.
I propose implementing some functionality to do the following (for a given parameter
and url): 

a) delete the parameter, re-send the url, and check if the server re-sets a value for
the parameter (if so, it may be a sessionid. If the param was not re-set by the server,
there is not much else to do).
b) re-send the url, using the value set by the server in the previous step as the parameter
value.  If the value *is* then re-set to a different value by the server, then the
url + parameter is not vulnerable to session fixation.  If the parameter value is *not*
reset by the server, the url may be subject to session fixation.  This is important
if the url is a login url.  If the url is not a login url, this may still indicate
that a guest user can be tracked by an attacker.

Any suggestions re the design or implementation?

Original issue reported on code.google.com by colm.p.oflaherty on 2012-05-08 08:42:49

[zapbot]

We already recognise commonly used session params, and the user can flag new ones too.
We can then just target those for this sort of check.
Hopefully ZAP will become 'session aware' as a result of the http://code.google.com/p/zaproxy/wiki/GSoC2012
development to add session awareness to the spider, which might help as well.

Original issue reported on code.google.com by psiinon on 2012-05-08 10:26:30

• Labels added: Type-Enhancement
• Labels removed: Type-Defect

[zapbot]

Great. Can you point me at the session params that Zap already recognises, so I can
look at integrating this, rather than simply scanning all params? I'd like to get something
in place in the next few days.  I'm happy to re-work the solution once the GSOC changes
are in.

Original issue reported on code.google.com by colm.p.oflaherty on 2012-05-08 11:11:31

[zapbot]

The default ones are here: http://code.google.com/p/zaproxy/source/browse/trunk/src/org/zaproxy/zap/extension/session/SessionParam.java

Theres a isSessionToken(name) method on ExtensionSession, so adding a getAllSessionTokens
method would allow you to get the list cleanly.
You ok creating a ZAP extension for this?
Let me know if you need any advice & guidance.

Original issue reported on code.google.com by psiinon on 2012-05-08 12:48:05

[zapbot]

Looking at the list of session parameters, I'm slightly concerned that if an application
out in the wild used its own session field name, which differs from the list here,
we would completely miss it. As a pen-tester, I'd prefer the process to be more correct
more of the time (albeit at the cost of speed), rather than missing a session field
completely. I know the user could add the session id field name into the list, but
I doubt it that they actually would, in reality.  It's one more thing to forget to
do, after all. I use about a billion different security tools, and the reason I like
Zap so much is that it does so much, with so little to have to remember by way of command
line and setup options. 

I was in the process of implementing it as a plugin (using the existing SQL Injection
plugins as an example). Is an Extension preferable? I'm noobie to Zap development,
btw, and I don't do much Java/Eclipse coding any more, so yes, any useful advice/guidance
is appreciated.

Original issue reported on code.google.com by colm.p.oflaherty on 2012-05-08 13:20:54

[zapbot]

Yeah, its a tricky balance - usability vs functionality!
I'd like ZAP to be as noobie friendly as possible, hence (in this case) the default
session list.
And then expert pentesters can tweak the list to their exacting requirements.
The other option for your test is to test every param, but I'm worried that might take
too long?
In the future I'd like ZAP to 'detect' likely session params, eg if none of the default
ones are used. But I wanted the first implementation to be as simple as possible.

Yes, this should be an active scanner.
The existing plugins are well worth looking at, but also look at https://code.google.com/p/zap-extensions/
- that includes a cut down active scanner rule.
V happy for your plugin to go in here, then people can easily add it to their existing
ZAP installs.
Happy to answer any questions you have here, but also feel free to use the dev group
- https://groups.google.com/forum/?fromgroups - more people might respond to questions
on that, and also learn from the answers.

Original issue reported on code.google.com by psiinon on 2012-05-08 13:39:24

[zapbot]

Time permitting, I'll get a proof of concept and running first as an active plugin/extension
scanning all GET/POST/Cookie params, and we can see where it goes from there based
on performance, usability, etc. The session "detection" is a nice idea.  If it were
done up-front for each application, it wouldn't incur too heavy a price. 

One thing I've noticed in the migration from the paros plugin namespace to the zap
plugin namespace is that classes like NameValuePair are not public, so I can't use
them in the Zap namespace. Is there a plan to remediate/migrate/replace these? 

Original issue reported on code.google.com by colm.p.oflaherty on 2012-05-08 14:30:42

[zapbot]

I have a cookie based implementation in place. It currently scans all cookie fields
(not just the session id fields named in the options), and it has found its first real
Session Fixation vulnerability on a logon page, which I have confirmed.

There are a couple of things to note here:

The implementation will need to be different for url based session ids than for cookie
based schemes. In the cookie based scheme, we send in a cookie-less request, and get
a cookie set in the response headers. With a Url based session id scheme, we would
send in a request with no session url parameter, and get back a redirect to a different
url, containing some additional &SESSID=123456 parameter.  

I have implemented some logic in this plugin that effectively does "session identification"
on cookies.  This could be poached/refactored into other session aware code, such as
the GSOC.

In addition, the very existence of a url-based session id mechanism (rather than a
cookie based scheme) would likely warrant a separate alert to be raised on the url.

So.. I'll check this code in. Let me know what you think, and if it's worthwhile, I
can look at the url based and form based stuff, as well as possibly putting in an option
to allow the user to choose between scanning all fields, or just named session id fields
(to give the option of choosing between completeness+speed).

Original issue reported on code.google.com by colm.p.oflaherty on 2012-05-09 10:48:05

---

• Attachment: snapshot.png
  

[zapbot]

code stable as an extension

Original issue reported on code.google.com by colm.p.oflaherty on 2012-09-22 00:00:50

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.