Persisting / saving ZAP sessions

[psiinon]

I think theres still a lot of confusion around persisting/saving ZAP sessions.

ZAP sessions are _always_ recorded to disk in a HSQLDB database.
However when you start ZAP they are saved in a default set of files starting "session/untitled1" under the default ZAP user directory.
If you dont 'persist' the session then the files will be deleted when you exit.

When you persist a session all of the db files are copied to the location you specify.
You then dont need to save again, which is why the 'Persist session...' button is disabled once its been used and the 'Snapshot session' is enabled.
Copying big session files can take a long time, so if you know you want to save the session then you would be much better off persisting it as soon as you start ZAP instead of waiting until you've finished your pentest.

Would it be worth us having an option to always persist session files using a timestamp, in the similar way we name snapshots?
Should this be the default option, with an explicit 'Exit and delete the session' option?
Or should we always being up the 'Persist Session' dialog when ZAP starts?
Should we handle the saving/persisting of sessions in a different way?
How can we do a better job of explaining how this works?

Cheers,

Simon

[Cosmin Stefan-Dobrin]

Hi,

One thing that has been somewhat annoying to me in the past is the fact that I could not find any way to do the following:

1. set everything up (contexts, authentication, session management, some base urls)
2. persist the session
3. create a snapshot (or something similar) to go back to
4. any changes after loading/opening the snapshot will not alter the snapshot

This would help as it would allow me to save (and load) the Session with some initial configuration and, later, no matter what I do (explore random sites, do some testing, mess up some configuration), I could go back to a clean one, without needing to spend the time to set it up again.

Regarding always persisting the session, I don't think it would be useful for most of the users, as the people who want to persist a session can do it in just 2 clicks and, because it was their explicit action, they are aware of its existence and we don't risk to end up with hundreds of old and useless sessions.

Cosmin

--
You received this message because you are subscribed to the Google Groups "OWASP ZAP Developer Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zaproxy-devel...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[psiinon]

Oh, thats _exactly_ how the snapshot mechanism is supposed to work :/
I've just tested it by:

1. Starting ZAP
2. Accessing some urls
3. Persisting the session (eg as test)
   
4. Accessing some more urls
5. Snapshoting the session
6. Accessing some new urls
7. Loading the snapshot (eg test-20140129-152827)
8. ZAP now everything prior to the snapshot, ie not including the 'new urls'

Is this what you wanted?

If so, how can we make this more obvious?

Cheers,

Simon

[Cosmin Stefan-Dobrin]

Hi,

Yes, up to this point everything is ok. However, if I add steps:

      9. do some changes again (navigate, change contexts etc.)

    10. load the snapshot again

it will not return to the original intended state. Basically, loading a snapshot once is ok, but it can't be loaded more times so as it could be used as a reset point. This happens as, from what I've noticed, once the snapshot is loaded, it's loaded as a _normal_ session and everything that is subsequently changed is persisted in it.

Has this explanation made my problem a bit more clear?

Thanks,

Cosmin

[Cosmin Stefan-Dobrin]

The hacky solution right now is to create a new snapshot as soon as the snapshot is loaded. But this is kind of annoying (at least for me). On way in which we could change it would be to make some changes as follows:

1. if a session is just persisted, when loaded everything is saved in it, as it happens now
   
2. if a snapshot is created, when loaded, the snapshot is used just as a 'copy source' for creating a new anonymous/temporary/untitled session which acts as a completely new session (i.e. can be persisted, etc.)

Another idea would be to keep the Persist and Snapshot as now and just add the new behaviour as a new option for users.

I'm not sure if such a change would be trivial. Or if it would be beneficial for all the users, but, _for me_, it would seem a bit more natural that when I snapshot something, it stays as a snapshot forever.

Cheers,

Cosmin

[psiinon]

Ah, yes, that makes much more sense :)

Yes, a snapshot is just a normal session, once you load it then any new requests you make after loading will be persisted.
Copying snapshots into the untitled session which acts as a new one would make sense - although this could be a pain for large sessions if thats not what you want.
But then we could have a non default option to load the snapshot as a 'real' session and carry on.

Cheers,

Simon

[Colm O'Flaherty]

What about the option to load a session (such as a snapshot, but not limited to snapshots) in "read-only" mode?  

1) You save a snapshot

2a) At some subsequent point, you load the snapshot in read-only mode, and nothing you do changes it.

or..

2b) At some subsequent point, you load the snapshot in read-write mode, and everything you do changes it.

That's basically the way you already use applications such as Word/LibreOffice etc,so it should be intuitive.

Colm

[psiinon]

Hum, I suspect there are loads of places in the code that assume we have a db to write to.
I think (am pretty sure;) that a _lot_ of things would break in very nasty ways if we make it read-only...

Simon

[Colm O'Flaherty]

You might be right there alright.

I've run Zap in the past using read-only session files on the file-system, in order to ensure the session didn't get corrupted/modified.  It worked well enough for my purposes at the time, but don't ask me what version it was!

Colm

[psiinon]

I like the idea of a 'read-only' mode - I've raised an issue for it: http://code.google.com/p/zaproxy/issues/detail?id=1008

I think it should be _fairly_ straight-forward to implement, but there will probably be a lot of changes right across the code base.

I probably wont have time to implement it for 2.3 but if anyone else fancies giving it a go then go for it :)

[Cosmin Stefan-Dobrin]

Hi,

If there are so many changes that need to be done throughout the codebase (thus having an increased chance of breaking something), wouldn't it be easier and safer (at least for us, developers) to implement the copying of the data from a snapshot to a new, anonymous session and follow the scenario mentioned by Simon above? This would provide a solution to the problem the 'read-only' session is trying to solve, but it's faster for us to make. Of course, it might be slow to load a snapshot, but we can make the plausible assumption that people will snapshot things that are just at the beginning (e.g. after configuration, before actual scanning) and, if not, we can somehow warn users that it might take some time.

It's just a thought, as I don't know the inner details of the sessions system, so ignore me if I'm completely off. :)

Cosmin

[Colm O'Flaherty]

That option already exists by copying the files on the filesystem, after the snapshot is taken, or after persisting, with low risk, and zero dev effort.

We also do not know for sure what effort is involved, one way or the other for the 'read only' option. One way to get a better idea would be to write protect the files on the filer, and load the session in zap. We should see broken functionality or exceptions in functionality that relies on writing to the files. It it turns out to be either really easy or really hard work, that that might answer the question for us!

The read-only option strikes me as more intuitive than having the application make copies of stuff. It's just simpler to think about, because its a very basic use case in standard tools that people use every day.

All of this is IMHO, by the way.  What does everyone else think?
Colm

[Surya narayana]

HI Simon,

I want to know where the "Snapshot Session" will store in the system . 

Thanks

Surya

[psiinon]

In the same directory that the original session is located.
If you manually persist a session then you get to choose the directory, and this directory is used as the default for future persists (which you can again change via a manual persist).

Cheers,

Simon

[Rochana Atapattu]

Hi,

Is it possible to persist the scan progress with a snapshot? it would be nice to persist (snapshot time to time) the progress of long scans to avoid redoing from beginning if the scan is interrupted for some reason.

thank you,

[psiinon]

This is a question for the ZAP User Group: https://groups.google.com/group/zaproxy-users

And its always better to start a new thread rather than adding to one from 2015...