> > This result set name only has limited life. One receipt of a second
> > SRW request to get the next 10 records, the server is perfectly at
> > liberty to respond with a new result set name (at an
> abstraction level
> > this name would be referencing the same result set) i.e.
> this is just
> > a mechanism to maintain state between SRW requests.
> I could send continuous (SOAP is HTTP/1.1 so includes
> pipelining and gzipping, making this even more effective)
> requests to trash random resultset names.
> Regardless of how quickly they disappear, or how obscurely
> they're named, without an identifier which uniquely
> identifies the connection to which the result set belongs,
> they can be subverted.
Yes, but I could send continuous requests to trash random session ids or
client ids too! Or even better sniff the wire for the session ids/client
ids and use those. So introducing a session id in addition to a result
set name just adds complexity without actually solving the problem.
A solution would be for the server to keep tracking of the source IP
Addresses - using that to identify clients and using result set names as
at present for maintaining state. Even that is foolproof since you can
spoof ip addresses.
If you really want more resilience against this attack than you should
use SSL (HTTPS) with client certificates to identify the client.
In any case client identification (if required) is an Out of Band issue
which can be resolved at other layers in the syste and needn't be
included in the SRW spec.