dradis-devel Mailing List for Dradis Framework

Hi all,

I'm happy to announce that we now have a working API layer for Dradis.

This means you'll be able to read/write information in the Dradis
repository from anywhere you want (console scripts, your own tools,
3rd party tools that decide to implement a connector, etc.).

This is very limited and heavily under development extension at the
moment, but since I was able to run a couple of `curl` commands and it
worked, I thought I should let you know about it.

Here is the code:

https://github.com/dradis/dradis-api

Here is the discussion in the forum:

http://discuss.dradisframework.org/t/dradis-http-api/20/3


I'll be around in #dradis at irc.freenode if anyone wants to have a
chat.


Next steps:

* Implement CRUD operations for Notes (possibly Categories too?)
* Create a client library that speaks to the API and abstracts the
* communication so in your tools you can do stuff like:
* `Dradis::Node.new(label: 'My node').save`


Hope you enjoy this. Ideas, pull-requests and feature requests are
more than welcomed (lets use the forum to coordinate though).

Stay well,
Daniel


p.s. this is part of some of the stuff I'll be covering during the
BSidesLondon workshop [i] later this month.


[i]
https://www.securitybsides.org.uk/workshops.html

A while ago I took the plunge and finally set up MediaWiki to run as
my issues library. Rather than try to import all my issues by hand I
wrote a script to automate it. I've just tidied it up and released it
in case it helps anyone else.

http://www.digininja.org/projects/mediawiki_dradis_import.php

Any questions let me know.

Robin

Hi all,

Even though there hasn't been a lot of aparent movement over the last
few months, I've been making some progress on the dradis3.x branch of
the repo. But not a lot.

Last year around Christmas I realised that this was the case and
decided that this year I'm going to start throwing some energy into
the project again.

Thanks to the work done in Dradis Pro, we've got lots of bug fixes and
patches that we can now trickle down to the Community edition. In an
ideal world, all connector plugins will be shared among the editions
so fixing a bug in one will automatically fix it in the other.

Long story short, I've decided that this year, I'm going to bring the
Community edition back to shape. With the improved plugins, an API
interface (and client bindings) and hopefully a new UI as well.

I want to force myself down this route, so:

* I've applied to offer a workshop in BSides London later in April (fingers crossed!)

* I've submitted Dradis to the Rooted Warefare event (think BH
Arsenal). We got accepted and I've put some details on the site:

http://dradisframework.org/events/rootedcon2014.html


Next step: bring back the community forums. Watch this space!


Stay well,
Daniel

Hi Mark,

Thanks for chiming in.

> > * The fact that the Duo Ruby bindings [i] are not compatible with the
> > asset pipeline. This is inconvenient, because I have to extract the
> > .js and add it to my project. And then keep track of when a new
> > version is available. Any chance this will be addressed from Duo's
> > point of view? Alternatively, we could always load the .js from your
> > CDN.
> 
> Could you help enlighten us at to what it would take for that to be made viable for asset pipeline?

I think it's just a matter of rearranging the files in the repo to the
specific structure expected by the asset pipeline with a lib/ and a
vendor/ folder. You also need a rails Engine class to hook into the
framework, which can be an empty class that inherits from Engine.

I don't know if you've got people in-house that are familiar with
this, but I'd be happy to pull-request if there is interest in your side.

It may also be worth considering how do you maintain the .js file
across all language libraries. I've found that the `bootstrap-sass`
gem does a good job on this front (have a look at this [i]) they have
a task to update the gem's .js from the master copy of the .js hosted
elsewhere.


> > * The fact that the lib binds itself to the document.ready event made
> > things trickier in my implementation because Dou.ready() assumes that
> > Duo.init() has already been called to set the iframe's src attribute.
> > I ended up commenting the default .js file to avoid the bind and then
> > in my view:
> > 
> > ```
> > $(function(){
> >  console.log('Duo.init');
> >  Duo.init({
> >    'host': '<%= DUOWEB[:host] %>',
> >    'sig_request': '<%= @sig_request %>',
> >  });
> >  console.log('Duo.ready');
> >  Duo.ready();
> > })
> > ```
> > 
> > Am I missing something here?
> 
> You should just be able to unwrap the code from the document.ready portion, i.e.,
> 
> <iframe id="duo_iframe" width=?620" height=?320" frameborder="0"></iframe>
>  
> <script type="text/javascript">
>   Duo.init({
>     'host': '<%= DUOWEB[:host] %>',
>     'sig_request': '<%= @sig_request %>',
>   });
> </script>
> 
> Does that make sense?

That is the implementation you shared in the original pull request.
However, my comment is regarding the fact that the duo .js triggers
the .ready() method always and for every page when is included. You
solved this by having a conditional block in the layout file that only
includes the duo.js file when a specific controller action is called
[ii], but this again makes it tricky to work with the asset pipeline (where
all assets are compiled together, the idea being you load 1 big
compressed and minimised .JS file for the entire application instead
of many bits and pieces).

Also, for applications where Duo is going to be an optional thing
(e.g. up to the user to decide if they want it or not), having it load
all the time or affect 'core' components such as the layout may not be
the best alternative.

My current solution is to patch your .js to prevent the mandatory
.ready() call, and then in the specific view that shows the Duo iframe
(which is only reached if Duo is enabled by the user) have my .init()
and .ready() calls. This allows for a clean layout and less clutter
during the application init.

 
> Thanks for taking a look at doing this, I can certainly try and allocate engineering resources to help the cause on our end as able so just let me know (or others on the list) what that may involve.

I think I've found a solution to the optional integration problem by
now. I'm still giving it a try, but it looks like the way forward is
to use Warden [iii] a Rack middleware that supports multiple
authentication *strategies*, meaning you can try to authenticate the
user in a number of different ways (e.g. username and password OR
twitter OR duo...). The library is very lightweight, flexible and
well-written.

However I'm trying to bend the rules a bit because I need my
strategies to collaborate with each other (i.e. I need my
username/password strategy to authenticate the user and then my Duo
strategy to do the 2FA) which means they work as an AND chain instead
of an OR chain, but I think it's just a matter of playing around a bit
more.

I'll be happy to share this once I can make it work, and I reckon it
would be valuable to other Duo users if you shared a reference Warden
strategy in your documentation. At the end of the day, Warden is the
secret sauce of Devise one of the most popular authentication
libraries in ruby, so that could make adoption easier.

The added benefit is that once we shift to Ward, we'll be on the path
to truely pluggable authentication meaning we can add more strateggies
in the future (e.g. LDAP, CAS, etc.).

Thanks for your help on this Mark.

Stay well,
Daniel



[i]
https://github.com/twbs/bootstrap-sass#upstream-converter

[ii]
https://github.com/mstanislav/dradisframework/blob/749cbfdc252e3f9b8a126522e292aca3960382fb/app/views/layouts/banner.html.erb#L7-L15

[iii]
https://github.com/hassox/warden

Hey Daniel, 

I’ll inline a few answers below…

On Feb 19, 2014, at 8:38 AM, Daniel Martin <et...@no...> wrote:

> Hi all,
> 
> I'm looking at possible implementations of 2FA and in particular Duo
> Security / Duo Web, similar to [i] with a twist.
> 
> I know that Mark (@markstanislav) from Duo is on the list, so hopefully we
> can get some answers!
> 
> I have a big problem and a couple of implementation details. The big
> problem is that I'm not sure how to make this 2FA an optional
> component. Ideally I'd like for it to be separate Engine that plugs
> into the framework that you can turn on and off quite easily.
> 
> This means that the Engine would somehow need to hook into our login
> process (via SessionsController) but at the same time
> SessionsController should work as well when 2FA is not present. Maybe
> the best way to do would be to always hook up to an Engine either 2FA
> or DB-backed authentication (similar to what Devise does).
> 
> For the hard-core Rubyists in the list, any thoughts would be
> appreciated.
> 
> As for the implementation issues there are a few things that I'm not
> too comfortable with:
> 
> * The fact that the Duo Ruby bindings [i] are not compatible with the
> asset pipeline. This is inconvenient, because I have to extract the
> .js and add it to my project. And then keep track of when a new
> version is available. Any chance this will be addressed from Duo's
> point of view? Alternatively, we could always load the .js from your
> CDN.

Could you help enlighten us at to what it would take for that to be made viable for asset pipeline?

> * The fact that the lib binds itself to the document.ready event made
> things trickier in my implementation because Dou.ready() assumes that
> Duo.init() has already been called to set the iframe's src attribute.
> I ended up commenting the default .js file to avoid the bind and then
> in my view:
> 
> ```
> $(function(){
>  console.log('Duo.init');
>  Duo.init({
>    'host': '<%= DUOWEB[:host] %>',
>    'sig_request': '<%= @sig_request %>',
>  });
>  console.log('Duo.ready');
>  Duo.ready();
> })
> ```
> 
> Am I missing something here?

You should just be able to unwrap the code from the document.ready portion, i.e.,

<iframe id="duo_iframe" width=“620" height=“320" frameborder="0"></iframe>
 
<script type="text/javascript">
  Duo.init({
    'host': '<%= DUOWEB[:host] %>',
    'sig_request': '<%= @sig_request %>',
  });
</script>

Does that make sense?

> 
> * The fact that the integration with the external Duo service requires
> a `skip_before_filter :verify_authenticity_token` makes my spidey
> sense tingle. I dediced to move the Duo step altogether to a separate
> controller action, and then disable CSRF just for that (instead of
> disabling it for the general Sessions#create action). See:
> 
> https://gist.github.com/etdsoft/9092081
> 
> Is there anything obviously wrong with this approach (as opposed to
> using the #create action)?
> 

I’ll let someone else speak to this who may have stronger opinions...

> 
> These days I'm finding myself with more time to spend on the project,
> but moving our entire plugin architecture to the Engine world is quite
> a challenge, hopefully there will be more movement soon.
> 
> In any case, thoughs on architecture/approach/pointers to
> implementations will be very appreciated.
> 
> Stay well,
> Daniel

Thanks for taking a look at doing this, I can certainly try and allocate engineering resources to help the cause on our end as able so just let me know (or others on the list) what that may involve.

Best,

-Mark

> 
> 
> [i]
> https://github.com/dradis/dradisframework/pull/70
> 
> [ii]
> https://github.com/duosecurity/duo_ruby
> 
> [iii]
> https://github.com/duosecurity/duo_ruby/blob/master/js/Duo-Web-v1.js#L322-L324
> 
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> dradis-devel mailing list
> dra...@li...
> https://lists.sourceforge.net/lists/listinfo/dradis-devel

Hi all,

I'm looking at possible implementations of 2FA and in particular Duo
Security / Duo Web, similar to [i] with a twist.

I know that Mark (@markstanislav) from Duo is on the list, so hopefully we
can get some answers!

I have a big problem and a couple of implementation details. The big
problem is that I'm not sure how to make this 2FA an optional
component. Ideally I'd like for it to be separate Engine that plugs
into the framework that you can turn on and off quite easily.

This means that the Engine would somehow need to hook into our login
process (via SessionsController) but at the same time
SessionsController should work as well when 2FA is not present. Maybe
the best way to do would be to always hook up to an Engine either 2FA
or DB-backed authentication (similar to what Devise does).

For the hard-core Rubyists in the list, any thoughts would be
appreciated.

As for the implementation issues there are a few things that I'm not
too comfortable with:

* The fact that the Duo Ruby bindings [i] are not compatible with the
asset pipeline. This is inconvenient, because I have to extract the
.js and add it to my project. And then keep track of when a new
version is available. Any chance this will be addressed from Duo's
point of view? Alternatively, we could always load the .js from your
CDN.

* The fact that the lib binds itself to the document.ready event made
things trickier in my implementation because Dou.ready() assumes that
Duo.init() has already been called to set the iframe's src attribute.
I ended up commenting the default .js file to avoid the bind and then
in my view:

```
$(function(){
  console.log('Duo.init');
  Duo.init({
    'host': '<%= DUOWEB[:host] %>',
    'sig_request': '<%= @sig_request %>',
  });
  console.log('Duo.ready');
  Duo.ready();
})
```

Am I missing something here?

* The fact that the integration with the external Duo service requires
a `skip_before_filter :verify_authenticity_token` makes my spidey
sense tingle. I dediced to move the Duo step altogether to a separate
controller action, and then disable CSRF just for that (instead of
disabling it for the general Sessions#create action). See:

https://gist.github.com/etdsoft/9092081

Is there anything obviously wrong with this approach (as opposed to
using the #create action)?


These days I'm finding myself with more time to spend on the project,
but moving our entire plugin architecture to the Engine world is quite
a challenge, hopefully there will be more movement soon.

In any case, thoughs on architecture/approach/pointers to
implementations will be very appreciated.

Stay well,
Daniel


[i]
https://github.com/dradis/dradisframework/pull/70

[ii]
https://github.com/duosecurity/duo_ruby

[iii]
https://github.com/duosecurity/duo_ruby/blob/master/js/Duo-Web-v1.js#L322-L324

Hi K41Zen,

> I've followed the steps in the article:
> http://guides.dradisframework.org/word_reports.html but when I save my
> template Word reports an error saying that the document contains custom
> xml which is no longer supported. Reading this article
> http://support.microsoft.com/kb/2445062 it states that since January
> 2010 this has been removed due to a US court case ruling.
>  
> Have I read this correctly and is there any way of getting this working
> without purchasing the Pro version?

Is there any chance you can get your hands on an older version of Word
(maybe 2003)?

I wasn't aware of the XML incompatibility with Word you mentioned. The
last update on the custom XML reporter was from 2 years ago [i]

The problem with the approach was that by creating custom XML tags we
were pretty much replicating the XSLT language: for instance we'd like
to have tags to repeat a section of the template, tags to perform "if"
conditions, etc. It didn't make a lot of sense to continue to develop
our own custom XML meta language and this is why this development line
halted.

In Pro we're using Word's native Content Controls to create the template
which has proven a more natural / easier to use solution.

In terms of evolving the reporting engine without using custom XML I
think that your better option would be to do XSLT stylesheets using the
Nokogiri library. The bright side is that you'll get all the power of
XSLT with <xsl:for-each />, etc. The down side is that you'll have to
become familiar with Word's internal XML. There is a good introduction
to the topic on this article:

http://securityroots.com/dradispro/support/guides/reports_xslt.html

You can use any XSLT processor for this, but right there in Chapter3
you've got the ruby code to apply a transform to a template.
(Disclaimer: this option is also bundled with Pro).


Hope this helps,
Daniel



[i]
https://github.com/dradis/dradisframework/tree/master/vendor/plugins/word_export

Can someone help me please?
 
I've followed the steps in the article: http://guides.dradisframework.org/word_reports.html but when I save my template Word reports an error saying that the document contains custom xml which is no longer supported. Reading this article http://support.microsoft.com/kb/2445062 it states that since January 2010 this has been removed due to a US court case ruling.
 
Have I read this correctly and is there any way of getting this working without purchasing the Pro version?
 
Grateful for any help.
 		 	   		  

Hi Robin,

> In the issues section, the "Import new issue" feature allows import
> from MediaWiki versions 1.14 and 1.15. I want to install MediaWiki and
> have a play but the latest version is 1.21, has anyone tried this
> version and if so, is it compatible with the 1.15 import?

This is fixed in Pro [i], expect the update to trickle down to Community
soon.

Cheers,
Daniel



[i]
https://groups.google.com/forum/?fromgroups#!topic/dradis-pro/nmschNiRA20

On 29 May 2013 11:10, Daniel Martin <et...@no...> wrote:
> Hey Robin,
>
>> Have you thought of adding DokuWiki to the list? I run that for all my
>> notes as I never got on well with MediaWiki.
>
> As you know, it's not matter of not thinking about possibilities, just a
> matter of having the time to implement and maintain all plugins. Are you
> volunteering? It must be your lucky day as there was a recent workshop
> on how to create Dradis plugins!
>
> http://dradisframework.org/slides/bsides2013/

It would have been my lucky day if I hadn't been stuck in the room next door!

I will definitely look at it but will try to get an older MediaWiki
working first just as a reference point.

Robin

> ;)
>
> -Daniel
>
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> dradis-devel mailing list
> dra...@li...
> https://lists.sourceforge.net/lists/listinfo/dradis-devel

Hey Robin,

> Have you thought of adding DokuWiki to the list? I run that for all my
> notes as I never got on well with MediaWiki.

As you know, it's not matter of not thinking about possibilities, just a
matter of having the time to implement and maintain all plugins. Are you
volunteering? It must be your lucky day as there was a recent workshop
on how to create Dradis plugins!

http://dradisframework.org/slides/bsides2013/

;)

-Daniel

Hi
It depends on how well report writing goes this week. I'm trying very
hard not to get distracted and play with fun things instead but it may
happen.

Have you thought of adding DokuWiki to the list? I run that for all my
notes as I never got on well with MediaWiki.

Robin

On 29 May 2013 11:04, Daniel Martin <et...@no...> wrote:
> Hi Robin,
>
>
>> In the issues section, the "Import new issue" feature allows import
>> from MediaWiki versions 1.14 and 1.15. I want to install MediaWiki and
>> have a play but the latest version is 1.21, has anyone tried this
>> version and if so, is it compatible with the 1.15 import?
>
> I got a support email yesterday about this very issue. It seems that the
> queries run fine with the latest MediaWiki but there may be some issue
> with the formatting of the wiki content (e.g. Dradis fields aren't being
> properly picked up from the wikitext). I still need to give it a try,
> but if you do it first, it would be great if you could share your
> results with the list.
>
> Thanks!
> Daniel
>
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> dradis-devel mailing list
> dra...@li...
> https://lists.sourceforge.net/lists/listinfo/dradis-devel

Hi Robin,


> In the issues section, the "Import new issue" feature allows import
> from MediaWiki versions 1.14 and 1.15. I want to install MediaWiki and
> have a play but the latest version is 1.21, has anyone tried this
> version and if so, is it compatible with the 1.15 import?

I got a support email yesterday about this very issue. It seems that the
queries run fine with the latest MediaWiki but there may be some issue
with the formatting of the wiki content (e.g. Dradis fields aren't being
properly picked up from the wikitext). I still need to give it a try,
but if you do it first, it would be great if you could share your
results with the list.

Thanks!
Daniel

Hi
In the issues section, the "Import new issue" feature allows import
from MediaWiki versions 1.14 and 1.15. I want to install MediaWiki and
have a play but the latest version is 1.21, has anyone tried this
version and if so, is it compatible with the 1.15 import?

Robin

Hi all,

I'm quite happy with the results of yesterday's workshop. We covered
pretty much everything that I wanted to cover. There was enough time to
see how every type of plugin (Import/Export/Upload) works.

The slides are fairly comprehensive and you can them at:

http://dradisframework.org/slides/bsides2013/


And the code for the new plugins is already on GitHub:

https://github.com/dradis/dradis-brakeman
https://github.com/dradis/dradis-csv
https://github.com/dradis/dradis-cve


It was good to catch up and finally put a face to some of the
contributors in the list. Thanks for coming guys.

Stay well,
Daniel

On 14 March 2013 09:55, Daniel Martin <et...@no...> wrote:

> Hi Robin,
>
> > This line should use github.com <http://github.com> instead of
> etdsoftgit
> >
> > git clone git@etdsoftgit:dradis/dradisframework.git dradis3
>
>
> You're right of course, the trouble of having too many github accounts!
>
> > After this you need to change to the dradis3 directory before doing the
> > checkout. That then means the next cd you do is just to core as you are
> > already in the dradis3 directory.
>
> I've updated the instructions
>
>
> > The rest worked till I tried to create the new instance, that failed
> > with an error about a missing javascript runtime. Which one do you
> > recommend and can you install it as part of the rest of the install
> process?
> >
> > You also need to do a bit more checking when creating a new instance as
> > it doesn't notice that things are failing because of the javascript and
> > thinks it has completed successfully. I've included the trimmed down
> > output from the failed install in case it helps you spot how to detect
> > the failure.
>
> Not sure what is going on here, to get past the error `gem install
> therubyracer` should do the trick.
>
>
That didn't help, I installed therubyracer, deleted the directory and tried
a new install but that failed in the same way. I checked the gem list just
in case but it definitely shows version 0.11.4 installed.

Robin


> As to why it's failing, need to figure that one out, we're piggybacking
> on Rails application creation process, so not sure what's going on. I
> think that Rails defaults to "not force you to install" a JS runtime,
> and this is causing an error. Maybe we can trigger a check for it and
> present the user with the option (e.g. some people would rather use
> NodeJS than therubyracer). And if the user doesn't know what to do, just
> default to installing 'therubyracer'.
>
> HTH,
> Daniel
>
>

Hi Robin,

> This line should use github.com <http://github.com> instead of etdsoftgit
> 
> git clone git@etdsoftgit:dradis/dradisframework.git dradis3


You're right of course, the trouble of having too many github accounts!

> After this you need to change to the dradis3 directory before doing the
> checkout. That then means the next cd you do is just to core as you are
> already in the dradis3 directory.

I've updated the instructions


> The rest worked till I tried to create the new instance, that failed
> with an error about a missing javascript runtime. Which one do you
> recommend and can you install it as part of the rest of the install process?
> 
> You also need to do a bit more checking when creating a new instance as
> it doesn't notice that things are failing because of the javascript and
> thinks it has completed successfully. I've included the trimmed down
> output from the failed install in case it helps you spot how to detect
> the failure.

Not sure what is going on here, to get past the error `gem install
therubyracer` should do the trick.

As to why it's failing, need to figure that one out, we're piggybacking
on Rails application creation process, so not sure what's going on. I
think that Rails defaults to "not force you to install" a JS runtime,
and this is causing an error. Maybe we can trigger a check for it and
present the user with the option (e.g. some people would rather use
NodeJS than therubyracer). And if the user doesn't know what to do, just
default to installing 'therubyracer'.

HTH,
Daniel

I'm working through the instructions but hit a couple of mistakes then the
install failed.

This line should use github.com instead of etdsoftgit

git clone git@etdsoftgit:dradis/dradisframework.git dradis3

After this you need to change to the dradis3 directory before doing the
checkout. That then means the next cd you do is just to core as you are
already in the dradis3 directory.

The rest worked till I tried to create the new instance, that failed with
an error about a missing javascript runtime. Which one do you recommend and
can you install it as part of the rest of the install process?

You also need to do a bit more checking when creating a new instance as it
doesn't notice that things are failing because of the javascript and thinks
it has completed successfully. I've included the trimmed down output from
the failed install in case it helps you spot how to detect the failure.

Robin

Your bundle is complete! Use `bundle show [gemname]` to see where a bundled
gem is installed.
        rake    db:create
rake aborted!
Could not find a JavaScript runtime. See
https://github.com/sstephenson/execjs for a list of available runtimes.
/usr/local/rvm/gems/ruby-1.9.3-p392/gems/execjs-1.4.0/lib/execjs/runtimes.rb:51:in
`autodetect'
/usr/local/rvm/gems/ruby-1.9.3-p392/gems/execjs-1.4.0/lib/execjs.rb:5:in
`<module:ExecJS>'
/usr/local/rvm/gems/ruby-1.9.3-p392/bin/ruby_noexec_wrapper:14:in `<main>'
(See full trace by running task with --trace)
    generate    dradis:install new dradis-instance
/usr/local/rvm/gems/ruby-1.9.3-p392/gems/execjs-1.4.0/lib/execjs/runtimes.rb:51:in
`autodetect': Could not find a JavaScript runtime. See
https://github.com/sstephenson/execjs fo                r a list of
available runtimes. (ExecJS::RuntimeUnavailable)
        from
/usr/local/rvm/gems/ruby-1.9.3-p392/gems/execjs-1.4.0/lib/execjs.rb:5:in
`<module:ExecJS>'
        from script/rails:6:in `require'
        from script/rails:6:in `<main>'

=== ACTION REQUIRED ===
Now you can launch your Dradis webserver using:

cd dradis-instance
bundle exec rails server

This will launch the built-in webserver at port 3004.



On 13 March 2013 11:27, Robin Wood <ro...@di...> wrote:

> I'll give it a try as soon as I get chance.
>
> Robin
>
>
> On 13 March 2013 11:23, Daniel Martin <et...@no...> wrote:
>
>> Robin,
>>
>> I put together some instructions in the wiki:
>>
>> https://github.com/dradis/dradisframework/wiki/Developers-and-contributors
>>
>>
>> See the 'Dradis Framework 3.x' section.
>>
>>
>> In the 3.x branch the idea is that we'll take care of the dependencies
>> and setup for our users. No more `bundle` this, `reset.sh` that. You'll
>> install the 'dradis' gem, and run:
>>
>> $ dradis new whatever-folder-name
>>
>>
>> And a new Dradis instance will be created into that folder. The DB will
>> be initialised and all Ruby dependencies installed (similar to what
>> happens when you create a vanilla Rails app).
>>
>>
>> We're not there yet, however we're close. If you follow along the
>> instructions you should be able to clone the repo, generate a local .gem
>> file and install it in your system and run the `dradis` command line
>> tool to create a fresh Dradis 3.0.0.beta instance.
>>
>> Hopefully I didn't miss any steps.
>>
>>
>> Even though there is a lot of stuff that still hasn't been ported to 3.x
>> (e.g. adding nodes works, but adding notes doesn't). If you can get past
>> the login screen and see the familiar dradis interface, that will be a
>> good sign.
>>
>> And then we can start implementing the API from there.
>>
>>
>> Give it a try and let me know how it goes.
>>
>>
>> Regards,
>> Daniel
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar
>> _______________________________________________
>> dradis-devel mailing list
>> dra...@li...
>> https://lists.sourceforge.net/lists/listinfo/dradis-devel
>>
>
>

I'll give it a try as soon as I get chance.

Robin

On 13 March 2013 11:23, Daniel Martin <et...@no...> wrote:

> Robin,
>
> I put together some instructions in the wiki:
>
> https://github.com/dradis/dradisframework/wiki/Developers-and-contributors
>
>
> See the 'Dradis Framework 3.x' section.
>
>
> In the 3.x branch the idea is that we'll take care of the dependencies
> and setup for our users. No more `bundle` this, `reset.sh` that. You'll
> install the 'dradis' gem, and run:
>
> $ dradis new whatever-folder-name
>
>
> And a new Dradis instance will be created into that folder. The DB will
> be initialised and all Ruby dependencies installed (similar to what
> happens when you create a vanilla Rails app).
>
>
> We're not there yet, however we're close. If you follow along the
> instructions you should be able to clone the repo, generate a local .gem
> file and install it in your system and run the `dradis` command line
> tool to create a fresh Dradis 3.0.0.beta instance.
>
> Hopefully I didn't miss any steps.
>
>
> Even though there is a lot of stuff that still hasn't been ported to 3.x
> (e.g. adding nodes works, but adding notes doesn't). If you can get past
> the login screen and see the familiar dradis interface, that will be a
> good sign.
>
> And then we can start implementing the API from there.
>
>
> Give it a try and let me know how it goes.
>
>
> Regards,
> Daniel
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> dradis-devel mailing list
> dra...@li...
> https://lists.sourceforge.net/lists/listinfo/dradis-devel
>

Robin,

I put together some instructions in the wiki:

https://github.com/dradis/dradisframework/wiki/Developers-and-contributors


See the 'Dradis Framework 3.x' section.


In the 3.x branch the idea is that we'll take care of the dependencies
and setup for our users. No more `bundle` this, `reset.sh` that. You'll
install the 'dradis' gem, and run:

$ dradis new whatever-folder-name


And a new Dradis instance will be created into that folder. The DB will
be initialised and all Ruby dependencies installed (similar to what
happens when you create a vanilla Rails app).


We're not there yet, however we're close. If you follow along the
instructions you should be able to clone the repo, generate a local .gem
file and install it in your system and run the `dradis` command line
tool to create a fresh Dradis 3.0.0.beta instance.

Hopefully I didn't miss any steps.


Even though there is a lot of stuff that still hasn't been ported to 3.x
(e.g. adding nodes works, but adding notes doesn't). If you can get past
the login screen and see the familiar dradis interface, that will be a
good sign.

And then we can start implementing the API from there.


Give it a try and let me know how it goes.


Regards,
Daniel

On 11 March 2013 12:26, Daniel Martin <et...@no...> wrote:

> Robin,
>
> What programming language are you using for this?
>
> The first tool I was thinking of implementing this with would be dnsrecon
( https://github.com/darkoperator/dnsrecon ) which is Python then also
adding the facility to the recon-ng framework (
https://bitbucket.org/LaNMaSteR53/recon-ng/ ), again Python.

Ruby would help as well as I'd definitely consider adding support to any of
my own tools and I generally write stuff in Ruby.


> I'd be happy to start a 'dradis-logger' gem to support your efforts, but
> that would only be useful if you're doing Ruby stuff.
>
> If you're using something else, you'll have to use a simple HTTP calls.
> Unfortunately this is not going to be as straightforward as I thought. I
> wanted to give you a couple of curl commands to get you started, but I'm
> being stopped by the CSRF protection.
>
> Read works with HTTP Basic auth:
>
> $ curl -u "etd:dradis" -i https://dradis:3004/nodes.json?node=root-node
>
>
> But write fails due to CSRF:
>
> $ curl -u "etd:dradis" -i -d "{'label': 'from API'}"
> https://dradis:3004/nodes.json
>
> -> HTTP/1.1 500 Internal Server Error
>
> (log reveals it's a CSRF issue)
>
>
I can see why that is a problem. We could use a technique I use to bypass
CSRF when on tests which is to do a GET first then extract the token and
use that in the POST. Its a hack and not the right way to do it but always
fun to bypass protections.


>
> I think we should have a proper REST/json API, but would be inclined to
> add it to the 3.0 branch to try to start moving away from 2.x. There is
> a great railscast on implementing a proper versioned API:
>
> Agreed, no point in doing it badly then regretting it later. Just make
sure that when you do add it you don't lose any of the security features
you've already got.


> http://railscasts.com/episodes/350-rest-api-versioning
>
>
> The 3.x branch is not moving as fast as I'd like but if we start working
> on this and some other features we may get to a release candidate
> version fairly soon.
>

I'll have a look at the video. I really need to learn Rails, just never had
the time or reason to.

Robin


>
> Is anyone else interested in participating in this?
>
> Regards,
> Daniel
>
> On 09/03/2013 22:23, Robin Wood wrote:
> > Has anyone got any good examples of using the API to inject data into
> > Dradis? I've got a few tools I'd like to wrap so push their results
> > directly in.
> >
> > Robin
> >
> >
> >
> ------------------------------------------------------------------------------
> > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> > endpoint security space. For insight on selecting the right partner to
> > tackle endpoint security challenges, access the full report.
> > http://p.sf.net/sfu/symantec-dev2dev
> >
> >
> >
> > _______________________________________________
> > dradis-devel mailing list
> > dra...@li...
> > https://lists.sourceforge.net/lists/listinfo/dradis-devel
> >
>
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> dradis-devel mailing list
> dra...@li...
> https://lists.sourceforge.net/lists/listinfo/dradis-devel
>

Ok,

Lets go the proper route using a language independent API endpoint with
plain json over HTTP.

I'll lay the groundwork in the 3.x branch and send some pointers with
documentation to the list and we can take it from there.

The basic node/note operations are already working in 3.x so as long as
we don't get too fancy, the minimum functionality should be there and
ready to be API-enabled.

Watch this space.

-Daniel

On 11/03/2013 12:33, Robin Wood wrote:
> On 11 March 2013 12:26, Daniel Martin <et...@no...
> <mailto:et...@no...>> wrote:
> 
>     Robin,
> 
>     What programming language are you using for this?
> 
> The first tool I was thinking of implementing this with would be
> dnsrecon ( https://github.com/darkoperator/dnsrecon ) which is Python
> then also adding the facility to the recon-ng framework (
> https://bitbucket.org/LaNMaSteR53/recon-ng/ ), again Python.
> 
> Ruby would help as well as I'd definitely consider adding support to any
> of my own tools and I generally write stuff in Ruby.
>  
> 
>     I'd be happy to start a 'dradis-logger' gem to support your efforts, but
>     that would only be useful if you're doing Ruby stuff.
> 
>     If you're using something else, you'll have to use a simple HTTP calls.
>     Unfortunately this is not going to be as straightforward as I thought. I
>     wanted to give you a couple of curl commands to get you started, but I'm
>     being stopped by the CSRF protection.
> 
>     Read works with HTTP Basic auth:
> 
>     $ curl -u "etd:dradis" -i https://dradis:3004/nodes.json?node=root-node
> 
> 
>     But write fails due to CSRF:
> 
>     $ curl -u "etd:dradis" -i -d "{'label': 'from API'}"
>     https://dradis:3004/nodes.json
> 
>     -> HTTP/1.1 500 Internal Server Error
> 
>     (log reveals it's a CSRF issue)
> 
> 
> I can see why that is a problem. We could use a technique I use to
> bypass CSRF when on tests which is to do a GET first then extract the
> token and use that in the POST. Its a hack and not the right way to do
> it but always fun to bypass protections.
>  
> 
> 
>     I think we should have a proper REST/json API, but would be inclined to
>     add it to the 3.0 branch to try to start moving away from 2.x. There is
>     a great railscast on implementing a proper versioned API:
> 
> Agreed, no point in doing it badly then regretting it later. Just make
> sure that when you do add it you don't lose any of the security features
> you've already got.
>  
> 
>     http://railscasts.com/episodes/350-rest-api-versioning
> 
> 
>     The 3.x branch is not moving as fast as I'd like but if we start working
>     on this and some other features we may get to a release candidate
>     version fairly soon.
> 
> 
> I'll have a look at the video. I really need to learn Rails, just never
> had the time or reason to.
> 
> Robin
>  
> 
> 
>     Is anyone else interested in participating in this?
> 
>     Regards,
>     Daniel
> 
>     On 09/03/2013 22:23, Robin Wood wrote:
>     > Has anyone got any good examples of using the API to inject data into
>     > Dradis? I've got a few tools I'd like to wrap so push their results
>     > directly in.
>     >
>     > Robin
>     >
>     >
>     >
>     ------------------------------------------------------------------------------
>     > Symantec Endpoint Protection 12 positioned as A LEADER in The
>     Forrester
>     > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice"
>     in the
>     > endpoint security space. For insight on selecting the right partner to
>     > tackle endpoint security challenges, access the full report.
>     > http://p.sf.net/sfu/symantec-dev2dev
>     >
>     >
>     >
>     > _______________________________________________
>     > dradis-devel mailing list
>     > dra...@li...
>     <mailto:dra...@li...>
>     > https://lists.sourceforge.net/lists/listinfo/dradis-devel
>     >
> 
>     ------------------------------------------------------------------------------
>     Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
>     Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
>     endpoint security space. For insight on selecting the right partner to
>     tackle endpoint security challenges, access the full report.
>     http://p.sf.net/sfu/symantec-dev2dev
>     _______________________________________________
>     dradis-devel mailing list
>     dra...@li...
>     <mailto:dra...@li...>
>     https://lists.sourceforge.net/lists/listinfo/dradis-devel
> 
> 

Robin,

What programming language are you using for this?

I'd be happy to start a 'dradis-logger' gem to support your efforts, but
that would only be useful if you're doing Ruby stuff.

If you're using something else, you'll have to use a simple HTTP calls.
Unfortunately this is not going to be as straightforward as I thought. I
wanted to give you a couple of curl commands to get you started, but I'm
being stopped by the CSRF protection.

Read works with HTTP Basic auth:

$ curl -u "etd:dradis" -i https://dradis:3004/nodes.json?node=root-node


But write fails due to CSRF:

$ curl -u "etd:dradis" -i -d "{'label': 'from API'}"
https://dradis:3004/nodes.json

-> HTTP/1.1 500 Internal Server Error

(log reveals it's a CSRF issue)


I think we should have a proper REST/json API, but would be inclined to
add it to the 3.0 branch to try to start moving away from 2.x. There is
a great railscast on implementing a proper versioned API:

http://railscasts.com/episodes/350-rest-api-versioning


The 3.x branch is not moving as fast as I'd like but if we start working
on this and some other features we may get to a release candidate
version fairly soon.

Is anyone else interested in participating in this?

Regards,
Daniel

On 09/03/2013 22:23, Robin Wood wrote:
> Has anyone got any good examples of using the API to inject data into
> Dradis? I've got a few tools I'd like to wrap so push their results
> directly in.
> 
> Robin
> 
> 
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
> endpoint security space. For insight on selecting the right partner to 
> tackle endpoint security challenges, access the full report. 
> http://p.sf.net/sfu/symantec-dev2dev
> 
> 
> 
> _______________________________________________
> dradis-devel mailing list
> dra...@li...
> https://lists.sourceforge.net/lists/listinfo/dradis-devel
> 

Has anyone got any good examples of using the API to inject data into
Dradis? I've got a few tools I'd like to wrap so push their results
directly in.

Robin

Hi guys,

I forgot to mention I'll be attending this year's RootedCON in Madrid
(it has already started, [i]).

If anyone is around and would like to catch up, please ping me off list
and we can grab a coffee or drink.

Cheers,
Daniel




[i]
http://www.rootedcon.es/