[WEB SECURITY] Jikto in the wild

[Billy Hoffman]

pdp,

I'll certainly take that under advisement. I guess it all moot because
the code is out now, and you can all see my (poor) last minute attempts
to get XSS to flag in a POST against zero.webappsecurity.com (stupid
deep object copy... )

I also completely agree with you that no serious organization will ever
use Jikto in place of a professional tool. It's limited and passes
everything through a 3rd party web server that you don't control (ie the
proxy site). And sites that have logins or complex state issues aren't
going to work either. However, it does to a good job at finding vulns
against simple, publicly facing websites with basic forms and other
features. And in truth, these are exactly the types of sites a scanner
that's part of an XSS attack would look at to find new injection points
for a cross-domain XSS worm. In fact, coupled with JavaScript's eval()
function, Jikto could be very good are confirming an XSS vuln it finds
actually exists... and SQL Injection... well lets just say hopefully I
see you all at BlackHat :-)

I also think your post contains many good reasons why no one should
panic about Jikto being in the wild. This is by no means the end of the
world (hence my touch-in-cheek preso title invoking doomsday nanobots),
in fact, I hope it encourages more research into what "advanced"
applications can be written in JavaScript.

Take care,
Billy Hoffman
--
Lead Researcher, SPI Labs
SPI Dynamics Inc. - http://www.spidynamics.com
Phone:  678-781-4800
Direct:   678-781-4845

-----Original Message-----
From: pdp (architect) [mailto:pdp.gnucitizen at googlemail.com] 
Sent: Monday, April 02, 2007 4:00 PM
To: Billy Hoffman
Cc: websecurity at webappsec.org; webappsec @OWASP
Subject: Re: [WEB SECURITY] Jikto in the wild

Billy,

I saw Jikto's code probably on the same day when you did your
presentation. The truth is that, although it is possible for someone
to use Jikto to vuln asses a server, at the moment this is very
unlikely. Probably I make too strong statement here but this is what
think. :)

Today, it is a lot easer to scan someone through TOR then using
browser issues. Why? Well, it will take some time for the bad guys to
pick the new ideas and not only that,... but also to create a big
enough infrastructure to support Jikto's mobility.

This is why I believe that Jikto should be made free for everyone to
see. As you mentioned, the code is largely constructed from various
snippets which are available anyway. It took you 24h to assemble the
code... well the bad guys may spend 10 days to do the same but they
will achieve it eventually and I believe that there are already enough
resources out there to simplify the task even more.

So my suggestion is to make it free. I am working myself on something
that may lead to a lot of problems but this is our job after all. We
don't prevent something from happening, we are just messengers. It is
up to the vendors and the community to decide what to do with it.
Although I do consulting for companies and corporations and I making
living out of it, I never sell false ideas such as a service or
product that magically resolves problems. The truth is that if someone
wants to penetrate your organization, they will, and you can do
nothing about it. All we give is a warning, a bit of information that
will make a difference eventually.

That's all I am saying.

On 4/2/07, Billy Hoffman <Billy.Hoffman at spidynamics.com> wrote:
>
>
>
>
> FYI: Jikto's in the wild. You can read about it here:
>
http://portal.spidynamics.com/blogs/spilabs/archive/2007/04/02/Jikto-in-
the-wild.aspx
>
>
>
> I supposed it was only a matter of time. As the post describes, I took
a
> bunch of steps to protect the code during my demo. Even if someone
hadn't
> managed to grab a copy, I image a Jikto clone would have come out
sometime
> this year. In fact, pdp was so close back in October with his web
crawling
> demo. His work heavily influenced Jikto. His solution however used
timer and
> iframe remoting and as I've said before
> (http://www.gnucitizen.org/blog/javascript-remoting-dangers)
> XmlHttpRequest is way faster than iframes.
>
>
>
> Using pdp's idea, all I had to do for Jikto was write ~800 of
JavaScript
> functions to handle response parsing, link scrapping, URL resolution,
and
> some glue code. Most of those things I had already written for other
> projects. Jikto probably only took me < 24 hours to piece together.
>
>
>
> Anyway, the long and short of all of this is that the code to a web
vuln
> scanner written in JavaScript is in the wild now.
>
>
>
> Billy Hoffman
>
> --
>
> Lead Researcher, SPI Labs
>
> SPI Dynamics Inc. - http://www.spidynamics.com
>
> Phone:  678-781-4800
>
> Direct:   678-781-4845
>
>


-- 
pdp (architect) | petko d. petkov
http://www.gnucitizen.org

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]