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.

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?

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.

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.

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?

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 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.