As xss worms become more prevelant in web applications so will the need to study and categorise them. Therefore I am proposing a project (to be coded by ourselves) that will provide a centralized storage point for them.

If you are interested in getting involved please post in here so we can start planning.

----------
'Just because you got the bacon, lettuce, and tomato don't mean I'm gonna give you my toast.'

<--very interested

and since the background of each worm, like target site, things it did, and number affected are pretty important .. i think it's probably best to throw them in a wiki format

-maluc

i can code an application that will allow worms to be categories, commented on, and previewed if that will help. I had similar plans for gnucitizen.org/worms

grt idea.
i m intrested in this too..!

- sn|ff

shall we do it than? We need to talk about the interface a bit... like what kind of interactive components should be available.

Great to see so many people wish to get involved.

Couple of things that i wish to put out there at this time.

1. Currently, there is no one single organisation/group as yet doing this. Therefore we should hopefully be the first and providing we do it correctly, it can become "parent" authority on such attacks and the history of them.
2. I envisionage the project being greater then any one person. Thus, eventually we could look to putting this project together under a different domain as opposed to a current one. Would you be happy with that approach, and how would a group obtain a domain name so no single 1 person is in control?
3. As suggested by maluc, we need to collect and record a number of key indicators along with the scripts themselves (also I believe some type of write up/review/breakdown and/or analysis on each worm is also required)
4. As suggested by pdp.gnucitizen we should make the project interactive, thus we could have a sandbox type feature in which users could "test" the worm in real time. Or perhaps even create and or modify the worm itself.
5. We will need to come together and agree to some concrete guidelines for classifications etc.
6. Perhaps (though i doubt it) we could contact some developers of sites that have had xss worms and talk to them about detection methods etc.

... so that is about it. feedback, comments and/or criticisms welcome. but most importantly how should we go be about approaching the project? Where shall we start, do we want a development team, research team etc or do we just want to contribute whatever we can, whereever we can?

----------
'Just because you got the bacon, lettuce, and tomato don't mean I'm gonna give you my toast.'

I'd actually preferr a wiki in a lot of ways. We will probably be building one soon, once our hardware issues are completely resolved. There are lots of other reasons I'd rather use a wiki, but I'll save those for a later date.

- RSnake
Gotta love it. http://ha.ckers.org

ya, i really don't think a blog style setup with comments as the main input would be satisfactory.. and would get real messy real quick

The wiki seems to be the best setup..

-maluc

Alright - I think we can agree that it should be a wiki type style set up. However i would interested to here what pdp.gnucitizen has in mind in relation to interactive components.

So the next questions are
> Where is it going to be hosted?
> How will we adminstrate it?
> Will we code it ourselves?
> What data should we record.

And with that last one, the wiki needs to be able to support retriving and returning specific records from a database. There is no point in having all this data in a free form text field as it can't be analysed. Therefore the wiki we need some type of controlled layout.

----------
'Just because you got the bacon, lettuce, and tomato don't mean I'm gonna give you my toast.'

A wiki is cool, ha.ckers.org wiki. ^^ great!

perhaps wormtra.ckers.org .-.

assuming it were hosted here

-maluc

tra.ckers.org makes sense given the other things I want to do with a wiki. Well I might as well spill the beans to get people's feedback.

There is one thing I got a request for and another thing I have felt has been seriously lacking for many years now. The first query was for a complete attack library. Sort of like the XSS cheat sheet, but more like, "x function can be used for ...." for all the event handlers, for all the browsers, etc... a far far more robust way to keep all the data at our disposal.

The second thing that I've felt has been missing for years is a contact list. Each company name could have an entry that lists both contact information and any known/fixed holes. That way we can keep track of how fast things were closed (if that's interesting) but more importantly it can become a repository for allowing quick disclosure to the companies in question if they are willing to give support/security contact information. What do you guys think?

- RSnake
Gotta love it. http://ha.ckers.org

You are reading my mind :) Security contact information database is something I really wanted to exist. I was thinking about it in context of local, Polish companies, but maybe a good example here will have some positive influence. My vote is definitely for!

RSnake, there is an Attack library for Web Related Attacks and it is getting quite big and stable now. May I bring everyone’s attention to AttackAPI (http://www.gnucitizen.org/projects/attackapi/). So far, it has quite a lot of features and others are coming. I am currently doing some quite interesting stuff that will be part of AttackAPI. I don't mind if you start another Attack library, actually it is a great news, however, don't you think that it is a bit like reinventing the wheel. We can improve on what we have now. Anyway, some great stuff are coming on this forum.

I have started a Worm repository a couple of months ago. You can preview it here: http://www.gnucitizen.org/topics/myspace-worms

This GNUCITIZEN Topic is about AJAX worms in general. If you discover an AJAX worm and you like to share it, please do so. It will be a good idea to keep some kind of source repository for these worms. There is a subversion for it on http://www.gnucitizen.org/svn but you won't be able to see it for now cuz I am currently doing some dev stuff.

digi7al64, you have some cool ideas my man. :)

Other then that, I believe that this project can be hosted anywhere. You don't need to buy domains and build some kind of organizational structure for it. After all, this is just a project. You don't want to become a slave of your own project, do you? :)

I wanted to put it on GNUCITIZEN mainly because it will fit into GNUCITIZEN practice to release applications and services for free to the public. The members of the project will also be able to contribute with articles for the blog, which I believe is cool since others can have their say too. I am currently deploying a multi user blogging system. There still will be guest bloggers, one per month. :)

rsnake Wrote:
-------------------------------------------------------
> tra.ckers.org makes sense given the other things I
> want to do with a wiki. Well I might as well
> spill the beans to get people's feedback.
>
> There is one thing I got a request for and another
> thing I have felt has been seriously lacking for
> many years now. The first query was for a
> complete attack library. Sort of like the XSS
> cheat sheet, but more like, "x function can be
> used for ...." for all the event handlers, for
> all the browsers, etc... a far far more robust
> way to keep all the data at our disposal.
>
> The second thing that I've felt has been missing
> for years is a contact list. Each company name
> could have an entry that lists both contact
> information and any known/fixed holes. That way
> we can keep track of how fast things were closed
> (if that's interesting) but more importantly it
> can become a repository for allowing quick
> disclosure to the companies in question if they
> are willing to give support/security contact
> information. What do you guys think?

I've seen AttackAPI before, and although I think it's a good project, it's actually very heavyweight because it does literally too many things. Most of the time I just want one function or two at most. Slicing up AttackAPI into it's base components is really more what I'm talking about. I don't think we'd be re-inventing the wheel, because what I am talking about is far more wide reaching than a simple module. I'm talking about every JavaScript function mapped out from an attacker's perspective. The concept of a library is more than just "here it is" mentality. It's "here's how it's built" "here's why it works" "here's the sites it has worked on" blah blah.

Further, and more interesting for the wiki is common answers to questions we have to repeat all the time. I don't know how many times I've explained why POST vs GET doesn't secure people, but I still have to explain it again. A wiki is ideal for that. It's not ideal for giving someone an API to do attacks (like you have built) but it is a very versatile learning/teaching tool.

- RSnake
Gotta love it. http://ha.ckers.org

going out of track ! (possibly)

- sn|ff

RSnake wrote -
> There is one thing I got a request for and another
> thing I have felt has been seriously lacking for
> many years now. The first query was for a
> complete attack library. Sort of like the XSS
> cheat sheet, but more like, "x function can be
> used for ...." for all the event handlers, for
> all the browsers, etc... a far far more robust
> way to keep all the data at our disposal.


Would you be demonstrating a Proof of concept for these as well?

Cheers -

Anurag Agarwal
SEEC - Application Security Search Engine (http://www.myappsecurity.com)
http://www.attacklabs.com
blog - http://myappsecurity.blogspot.com

I've started something like this here:
http://www.gnucitizen.org/topics/atom-database

You know what might be helpful? If someone sets up a test site, like a site with profiles or something, and some basic XSS filters. Just for a proof-of-concept/challenge.

i have a sample shopping cart site on my local machine which i use...i can put it on the server for everyone to test it

Cheers -

Anurag Agarwal
SEEC - Application Security Search Engine (http://www.myappsecurity.com)
http://www.attacklabs.com
blog - http://myappsecurity.blogspot.com

That might be useful.

@Spikeman, Mmkay what you're saying is to put up a server with real holes in it. Yeah could be done, but I guess into a protected/sandboxed area that is :)

Exactly, I was thinking a free webhost. Or just a sandbox type thing on a normal server.