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

[Daniel Brzozowski]

Exactly - agree with the REST idea to be a separate project. Actually it's a
bit hard for me to imagine zed, burp, webscarab etc having its own webserver
with REST webservice, it's just seem to me a bit overkill, at least at
the beginning.

>From the higher perspective I see this format as an option in any supported
tool to export/import something to OWASP DEF - imho it's the easiest way for
us to go. So this will be somehow represented as files, right?
Why we rejected the idea of XML files? Did we? :) If filesize is the issue
we can do the same thing as MS does with *.docx (
http://en.wikipedia.org/wiki/Office_Open_XML)


On 24 July 2011 17:49, Ferruh Mavituna <ferruh at mavituna.com> wrote:

> I might not have the background in here, but I think REST should be
> completely considered as a completely separate project / extension.
> Secondly why not simply come up with an XSD (*which is completely designed
> for this purpose*) and leave it there, wouldn't that be enough?
>
> On 24 July 2011 12:05, psiinon <psiinon at gmail.com> wrote:
>
>>  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
>>>
>>>
>>
>> _______________________________________________
>> Owasp-data-exchange-format mailing list
>> Owasp-data-exchange-format at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-data-exchange-format
>>
>>
>
>
> --
> .fm
>
> _______________________________________________
> Owasp-data-exchange-format mailing list
> Owasp-data-exchange-format at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-data-exchange-format
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-data-exchange-format/attachments/20110725/7dfb4990/attachment-0001.html