[Owasp-data-exchange-format] DEF Strawman characteristics

[psiinon]

Ah, yes, I should really explain the 'REST' interface a bit more:)
And, thinking about it, a few use cases wouldnt go amiss!

My plan for the strawman was to define a hierarchical structure for
representing pentest data, covering all of the types of objects in the data
model (hosts, ports, sites (host:port), urls, issues, requests/responses).
However all of the objects will be optional, as it really depends on whats
generating it and how the data is going to be used.
So, you might want to export everything regarding a pentest session from
burp, in which case a massive file might be generated.
Or you might want to just export a single request to feed into JBroFuzz.
The file format should allow these 2 extremes and pretty much anything
inbetween.
Products could either prompt the user as to what they want to export, or in
some cases just ignore the parts that dont apply.

However I also really like the idea of defining an API, which I know is not
really in the spirit of a data format.
Maybe this could be a separate but related doc?

To support the REST API products would expose a base URL, eg
http://localhost:1234/myproduct/owasp-def1.0/
There would be a standard set of REST endpoints under that which would allow
other products to retrieve selected objects.
So if your do a GET on (for example)
http://localhost:1234/myproduct/owasp-def1.0/sitemap
you would get back a summary of all of the URLs the product has discovered.
You could then do a GET on
http://localhost:1234/myproduct/owasp-def1.0/reqresp?id=1234
to get the full request/response pair for that request using the app
specific id, which would have been returned with the URL details.
All of the data returned will (or course) be in DEF format.

Not all products would support all objects, so the top level URL would
essentially list which objects (or endpoints) are supported.

That a bit clearer?

And, more importantly, should it be part of the DEF, related but separate or
am I being too ambitious and therefore should it be put on hold or scrapped?

Re the parameters and cookies - I was thinking that they would just be part
of the request/response data.
But I can see that sometimes it might be really useful to be able to refer
to them directly.
Definitely one to think about!

Cheers,

Simon


On Sat, Jul 23, 2011 at 5:01 PM, Martin Holst Swende <
martin.holst_swende at owasp.org> wrote:

>  ----- Ursprungsmeddelande -----
> > I've updated the Strawman tab on the project page (
> >
> https://www.owasp.org/index.php/OWASP_Data_Exchange_Format_Project#tab=Strawman)
>
> > with some proposed characteristics:
> >
> >      - The format will be JSON (to make it as simple as possible)
>
> great!
>
> >      - Products can generate and/or consume DEF
> >      - Products will be able to generate DEF via a defined REST interface
>
>
> could you please explain this a bit? Not sure I understand...
>
> >      and/or simple files - products can choose
> >      - Products which consume DEF must support both REST and file options
>
> >      - There will be minimal security (but REST based services can limit
> > by IP    addr)
> >      - The data model will cover: hosts, ports, sites (host:port), urls,
> >      issues, requests/responses
>
> How about parameters? E.g if a certain param or field is vulnerable or
> should be exported as fuzzer-target? Cookies? Perhaps also http header
> fields.
>
> >      - Products can generate a subset of DEF, the level support will be
> >      described in the DEF
> >
> > What do you think??
> >
> > Let me know if I've been too terse!
> >
> > Simon
>
> sounds good so far! Keep it up!
> Regards,
> Martin from n900
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-data-exchange-format/attachments/20110724/624ad548/attachment.html