Scheme for Unifying Approach to Framework-based Developer Outreach
John Steven
You and I discussed this a few years back and I agree direct
contribution seems to be the highest-value way to impact frameworks. I
don't think it's the only way though and I don't think this means that
we need to stand up, disperse, and begin contributing code tomorrow
though.
It is a big personal/professional choice for individuals/companies to
devote someone's time to this extent to framework improvement. We can
get "force multiplication" from our efforts though. Each of these
frameworks is going to need help on similar key tasks. I think we
should form a cabal of folk (within this mailing list, perhaps) and
unify our approach to tackling each problem.
I diverge in thinking from Wilander on the "how" here though. Rather
than worrying about XSS or Dir Traversal (attack perspective), I've
long-preached we use a "developer scenario" perspective for our
framework.
Think about the following:
* Authenticating subjects
* Authorizing subjects for <action>
* Managing sessions (across containers)
* Connecting to a database
* ...
There are key "scenarios" developers must support in each application.
If you map these onto the frameworks, you can start to see what design
constraints each imposes today based on its existing code base.
I propose that, centrally, within OWASP we ratchet up the specificity
of how we want to help each framework implement each development
scenario. So, for instance we:
1) Each pick a framework to represent (I'd pick Spring 2.5, 3)
2) Decide on a scenario (Say, Authenticating subjects)
3) Break the topic down into specific and workable units (Kevin Wall
has done a good job of this for Authentication, its related workflows
and alternative flows in his blog)
4) Threat model the topic (This is where Wilander's attacks keep us
honest and thorough), define test plan
5) (Like Kevin) Break the development scenario down into constituent
design elements/spec
6) As a group, discuss how each framework perspective affects the
proposed design/elements
7) Assign "key reusable functionality" to an ESAPI module stakeholder
8) Break, going off to implement framework-specific prototypes,
leveraging ESAPI modules where applicable
9) Set points at which to report back, discussing progress,
difficulties, successes
10) Validate attack resistance of each prototype against test plan
I can hear you sighing at the weight of this proposal though my email,
even unsent. I don't mean it to be heavy-weight, just methodical. We'd
perform each of the above steps quickly and informally. The key being
that we should all march in our specific directions with a unified
view of the problem and plan to collaborate to do common tasks once as
a group. This, I believe, will also serve to raise overall
quality/consistence. As I vehemently insisted during the first ESAPI
summit, more modern security-aware frameworks should inform our
retro-fit of previous ones. For instance, a lot of the Spring Security
model can be bolted back onto the MVC architecture of Struts2 ... and
this approach means we have one approach to authn/authz rather than
two.
***Only by bringing each framework perspective to the common design
table BEFORE we march off to code can we avoid fractured approach and
duplication of effort.***
We'll have to conform to each framework's contribution and coding
cultures, but we can manage the (above) process through our own wiki,
so that anyone can publicly observe and participate in our secure
design activities.
Regardless of means, I'm very interested in participating throughout
this outreach and coding process. While I work to align this with my
daily (paid) activities, I only have spare time... but I'm happy to
participate in any way possible.
-jOHN
--
Phone: 703.727.4034
Web: http://goo.gl/Y5d2y
On Thu, Apr 7, 2011 at 5:40 PM, Rohit Sethi <rkl...@gmail.com> wrote:
> I think this is a good approach, however I'm not clear what links
> would be in the cells?
>
> Also, I think one mistake from the manifesto project was to restrict
> to "frameworks" when really there are many open source libraries that
> have a major impact on web application security besides standard MVC
> frameworks. For scoping reasons it may make sense to start with MVC
> but we shouldn't stop there.
>
> On 4/7/11, John Wilander <john.w...@owasp.org> wrote:
>> So, how about a tab each for the active engagements we have in frameworks
>> today. On each tab we get to enter names, contact info, and how we're
>> working with them.
>>
>> The best idea from the initial outreach was in my opinion the frameworks vs
>> security features matrix. Imagine ...
>>
>> _____________ Django | Struts 2 | Spring MVC | .NET MVC | Drupal
>> Injection
>> XSS
>> Sessions
>> Auth
>> Dir traversal
>> CSRF
>>
>> ... and then links in the cells. That would be awesome, don't you think?
>>
>> Regards, John
>>
>>
>> 2011/4/7 Rohit Sethi <rkl...@gmail.com>
>>
>>> Anyone?
>>>
>>>
>>> On Tue, Apr 5, 2011 at 9:53 PM, Rohit Sethi <rkl...@gmail.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Sorry for the slow reply on this. We're still trying to figure out the
>>>> best way to meet the need that Jacob Kaplan-Moss from Django articulated.
>>>> I
>>>> just sent him a message summarizing our current thinking - I'll report
>>>> back
>>>> to this group when I hear back from him.
>>>>
>>>> In the interim we've started some work on adding additional security
>>>> measures to Django's contrib.auth authentication framework as a third
>>>> party
>>>> plugin as well as other security enhancements. We hope to deploy this
>>>> within
>>>> the next month or so as part of a separate Django Security project. If
>>>> the
>>>> code proves popular, we can use that as reason to try and push some of
>>>> the
>>>> features into out-of-the-box Django.
>>>>
>>>> I now fundamentally believe the best way to improve the security of open
>>>> source frameworks / libraries is to just contribute to them. I was
>>>> thinking
>>>> that trying to start a campaign of asking individuals to submit one
>>>> security
>>>> patch / feature to the framework of their choice might be a good way to
>>>> foster real change and build up momentum. I tried to propose something
>>>> similar on the Java project but didn't really get anywhere:
>>>> https://lists.owasp.org/pipermail/java-project/2011-March/000332.html
>>>>
>>>> What do you think? Is this doable, or are we asking for too much of a
>>>> time
>>>> commitment?
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Jim Manico [mailto:jim.m...@owasp.org]
>>>>> Sent: Saturday, April 02, 2011 2:49 PM
>>>>> To: owasp-dev-out...@googlegroups.com
>>>>> Cc: owasp-dev-out...@googlegroups.com; Sethi, Rohit
>>>>> Subject: Re: Dev Outreach: Where do we go from here?
>>>>>
>>>>> Thanks Jim.
>>>>>
>>>>> Rohit is a big part of this: He is working with the Django Framework and
>>>>> is starting to form a cross-organization "think tank" so FOSS Framework
>>>>> teams can approach an expert committee in private to discuss AppSec
>>>>> issues.
>>>>> Several banks have asked for the same kind of private, objective,
>>>>> non-commercial resource.
>>>>>
>>>>> OWASP's mission of "Open" makes it a challenge to make this an official
>>>>> OWASP project which is why I think a "cross-organization committee" is
>>>>> key.
>>>>>
>>>>> -Jim Manico
>>>>> http://manico.net
>>>>>
>>>>> On Mar 31, 2011, at 12:00 PM, JIM BIRD <jim...@shaw.ca> wrote:
>>>>>
>>>>> > I suggest pick one problem where the OWASP community can help and make
>>>>> a real difference, and focus on doing something about it. The number one
>>>>> problem that developers (including me) identified is the lack of secure
>>>>> development frameworks. It makes sense to me to start with what people
>>>>> have
>>>>> said is most important.
>>>>> >
>>>>> > Jim Manico has some ideas on how OWASP can help with this, and knows
>>>>> about people who are working on making frameworks more secure. As Jim
>>>>> explained at the SANS Appsec conference this year, it's not necessary to
>>>>> secure every framework to make a difference. There are a small number of
>>>>> common frameworks; making them more safe to use will make a big
>>>>> difference -
>>>>> and hopefully create a snowball effect, as more people get involved and
>>>>> start understanding the problems and trying to solve them.
>>>>> >
>>>>> > Rohit Sethi and his team are working on helping to helping to secure
>>>>> Django and he has some good ideas on what can be done on secure
>>>>> frameworks.
>>>>> >
>>>>> http://labs.securitycompass.com/index.php/2011/03/11/closing-the-secure-web-application-framework-manifesto-project/
>>>>> >
>>>>> > I am sure there are other people doing good work like this.
>>>>> >
>>>>> > My suggestion is to start by setting up something in the Builders
>>>>> section to track and publicize who is doing what to help make which
>>>>> frameworks secure by default - or at least safer to use.Create some
>>>>> buzz,
>>>>> see who is interested and who is already involved, and build some
>>>>> momentum.
>>>>> And show how OWASP is helping the community, attract more developers to
>>>>> the
>>>>> cause.
>>>>> >
>>>>> > I am sure other people will have more concrete ideas of what to do
>>>>> next.
>>>>> >
>>>>> > Jim Bird
>>>>> >
>>>>> > ----- Original Message -----
>>>>> > From: John Wilander <john.w...@owasp.org>
>>>>> > Date: Sunday, March 27, 2011 4:39 pm
>>>>> > Subject: Dev Outreach: Where do we go from here?
>>>>> > To: OWASP Dev Outreach Discuss <
>>>>> owasp-dev-out...@googlegroups.com>
>>>>> >
>>>>> > > Hi Dev Outreach Discuss!
>>>>> > >
>>>>> > > As said on the steering list we now have an official home for the
>>>>> > > OWASP Builders:
>>>>> > > http://www.owasp.org/index.php/Builders
>>>>> > >
>>>>> > > ... with a tab that summarizes the results of the initial developer
>>>>> > > outreach:
>>>>> > > http://www.owasp.org/index.php/Builders#tab=Developer_Outreach
>>>>> > >
>>>>> > > The questions are many:
>>>>> > > * What conclusions can we draw?
>>>>> > > * How can OWASP engage in the right things ahead?
>>>>> > > * How do we set up a more ambitious outreach using a proper survey
>>>>> > > etc?
>>>>> > >
>>>>> > > Regards, John
>>>>> > >
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Rohit Sethi
>>>> Security Compass
>>>> http://www.securitycompass.com
>>>> twitter: rksethi
>>>>
>>>
>>>
>>>
>>> --
>>> Rohit Sethi
>>> Security Compass
>>> http://www.securitycompass.com
>>> twitter: rksethi
>>>
>>
>>
>>
>> --
>> John Wilander, https://twitter.com/johnwilander
>> Chapter co-leader OWASP Sweden, http://owaspsweden.blogspot.com
>> Conf Comm,
>> http://www.owasp.org/index.php/Global_Conferences_Committee<http://owaspsweden.blogspot.com>
>>
>
> --
> Sent from my mobile device
>
> Rohit Sethi
> Security Compass
> http://www.securitycompass.com
> twitter: rksethi
>
Jim Manico
John++
-Jim Manico
http://manico.net
Rohit Sethi
I generally agree with your approach as well. My gut feel is that the
more disciplined and structured we are the fewer people who will
actually participate because it may not align with their own
motivation. For example, perhaps you, Jim, I and several other people
agree with the "developer-scenario" approach but others might not
agree - and no matter how sound our argument may be they'll simply
lose interest and not participate. That's okay, of course, because as
you mentioned we don't need to restrict ourselves to one approach.
My thought is that we could still push for a "submit 1 patch or bug &
test case" campaign. We could suggest the approach you outline below
as the official, coordinated, efficient approach but still encourage
others to do what they feel is best to achieve the goal. Maybe it
could be 1 patch per team or group of people instead of individual in
order to make the time commitments more realistic. Even if the patch
is rejected for some reason it shows that people care enough about
security to be spending their limited free time on it, which could be
a powerful message to the core developers of any open source library.
On Apr 8, 11:24 am, Jim Manico <jim.man...@owasp.org> wrote:
> I'm 100% in favor of this disciplined and non-duplicated approach. Forgive me for this less than in-depth answer, but I just could not let this go by without stating how much I'm impressed with and support this approach.
>
> John++
>
> >> I think this is a good approach, however I'm not clear what links
> >> would be in the cells?
>
> >> Also, I think one mistake from the manifesto project was to restrict
> >> to "frameworks" when really there are many open source libraries that
> >> have a major impact on web application security besides standard MVC
> >> frameworks. For scoping reasons it may make sense to start with MVC
> >> but we shouldn't stop there.
>
> >>> So, how about a tab each for the active engagements we have in frameworks
> >>> today. On each tab we get to enter names, contact info, and how we're
> >>> working with them.
>
> >>> The best idea from the initial outreach was in my opinion the frameworks vs
> >>> security features matrix. Imagine ...
>
> >>> _____________ Django | Struts 2 | Spring MVC | .NET MVC | Drupal
> >>> Injection
> >>> XSS
> >>> Sessions
> >>> Auth
> >>> Dir traversal
> >>> CSRF
>
> >>> ... and then links in the cells. That would be awesome, don't you think?
>
> >>> Regards, John
>
>
> >>>> Anyone?
>
> >>>>>>> I suggest pick one problem where the OWASP community can help and make
> >>>>>> a real difference, and focus on doing something about it. The number one
> >>>>>> problem that developers (including me) identified is the lack of secure
> >>>>>> development frameworks. It makes sense to me to start with what people
> >>>>>> have
> >>>>>> said is most important.
>
> >>>>>>> Jim Manico has some ideas on how OWASP can help with this, and knows
> >>>>>> about people who are working on making frameworks more secure. As Jim
> >>>>>> explained at the SANS Appsec conference this year, it's not necessary to
> >>>>>> secure every framework to make a difference. There are a small number of
> >>>>>> common frameworks; making them more safe to use will make a big
> >>>>>> difference -
> >>>>>> and hopefully create a snowball effect, as more people get involved and
> >>>>>> start understanding the problems and trying to solve them.
>
> >>>>>>> Rohit Sethi and his team are working on helping to helping to secure
> >>>>>> Django and he has some good ideas on what can be done on secure
> >>>>>> frameworks.
>
> >>>>>>> I am sure there are other people doing good work like this.
>
> >>>>>>> My suggestion is to start by setting up something in the Builders
> >>>>>> section to track and publicize who is doing what to help make which
> >>>>>> frameworks secure by default - or at least safer to use.Create some
> >>>>>> buzz,
> >>>>>> see who is interested and who is already involved, and build some
> >>>>>> momentum.
> >>>>>> And show how OWASP is helping the community, attract more developers to
> >>>>>> the
> >>>>>> cause.
>
> >>>>>>> I am sure other people will have more concrete ideas of what to do
> >>>>>> next.
>
> >>>>>>> Jim Bird
>
> >>>>>>> ----- Original Message -----
> >>>>>>> From:
>
>
> read more »
John Steven
You're right: no unnecessary restrictions on approach(es). A
patch-cycle (identification of certain key tactical limitations, fix
contribution, etc.) can be conducted outside of scheme I proposed in
the short term and might even serve to build credibility with some
framework communities as "act of good faith". Whether this is "one
test/patch" or more, I think, will depend on the OWASP participant's
speed and framework familiarity, as well as how insular or trusting
the particular framework development culture is. The OWASP stakeholder
representing a particular framework can inform the group as to how
much credibility work remains before we're considered same-team. This
is something they should report to the larger group as part of our
discussions.
In the longer term, in my scheme, such patch opportunities would be
evaluated on a case-by-case basis as we became appraised of
vulnerability while "working the larger scheme". In my experience
developing code for clients, this happens all the time: you're working
a large refactoring release (to, say, place a self-protecting data
service on their ESB) and you get side-swiped by a team fighting some
critical need to remediate something related but much smaller (say, CC
exposure on a fielded app -R-I-G-H-T -N-O-W-). Sometimes you stop
everything and fix stuff, sometimes you defer the fire drill, and
sometimes you adjust short/long-term priorities. These side-swipe
situations test the hands-on architect's mettle but in the
hypothetical emergence of this problem we can declare victory: we're
engaged enough in framework evolution that we actually face answering
prioritization questions. Here too, the scheme I proposed helps out:
other OWASPers in our cabal can help keep the OWASP framework PoC on
the right side of the short-/long-term trade offs, providing needed
perspective and potentially remediation air support. Less individual
mettle necessary ;-)
I'd like to address a particularly interesting element of side
conversations I've had with a few participants:
"Does my scheme put an 'ESTAPI' (*1) ahead of other pursuits in priority?"
I don't believe so. If we in fact produced an ESTAPI, this would be a
very mature and formal result. When I speak on threat modeling, I
always refer to the threat model as a sort of "security test plan". My
last email described the process preferences as "informal" and
"quick". I think we can easily describe the problems we're addressing
across frameworks in a 'short-hand' relative to the truly epic
undertaking an ESTAPI would represent. After all, the thing we at
OWASP understand best is the "problem space".
Implementing tests to start (*2), fixates us on very tactical and
local software bugs rather than some of the bigger flaws (such as
Struts' fundamental lack of proper authn/authz scaffolding). I firmly
believe that the Cigital-/Microsoft-observed 50/50 balance between
bugs and flaws will hold (*3) and that we'll need to tackle "a bit of
both" even in "Round 1". My preferred focus on both bugs and flaws is
why I mentioned K. Wall's blog posts as Step #3 (well-suited for
defining an informal spec. with which to tackle flaws) /AND/ J.
Wilander's proposed table as Step #4 (a mechanism for keeping track of
the bugs we want to squash). You'll also note their order: top-down
from design to more local impl. in the process order.
-jOHN
--
Phone: 703.727.4034
Web: http://goo.gl/Y5d2y
(*1) - ESTAPI, So-named by D. Cruz: "(E)nterprise (S)ecurity (T)esting (API)"
(*2) - Though the prescribed approach of T.D.D fans
(*3) - Regardless of how unproductive it is to argue the definition of
'bug' or 'flaw'
On Fri, Apr 8, 2011 at 2:00 PM, Rohit Sethi <rkl...@gmail.com> wrote:
>
> I generally agree with your approach as well. My gut feel is that the
> more disciplined and structured we are the fewer people who will
> actually participate because it may not align with their own
> motivation. For example, perhaps you, Jim, I and several other people
> agree with the "developer-scenario" approach but others might not
> agree - and no matter how sound our argument may be they'll simply
> lose interest and not participate. That's okay, of course, because as
> you mentioned we don't need to restrict ourselves to one approach.
>
> My thought is that we could still push for a "submit 1 patch or bug &
> test case" campaign. We could suggest the approach you outline below
> as the official, coordinated, efficient approach but still encourage
> others to do what they feel is best to achieve the goal. Maybe it
> could be 1 patch per team or group of people instead of individual in
> order to make the time commitments more realistic. Even if the patch
> is rejected for some reason it shows that people care enough about
> security to be spending their limited free time on it, which could be
> a powerful message to the core developers of any open source library.
>
> On Apr 8, 11:24 am, Jim Manico <jim.man...@owasp.org> wrote:
>
> I'm 100% in favor of this disciplined and non-duplicated approach. Forgive me for this less than in-depth answer, but I just could not let this go by without stating how much I'm impressed with and support this approach.
>>
John Wilander
This discussion reminds me of "The Cathedral and the Bazaar" (http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar). Check it out, especially "Guidelines for creating good open source software". In short, you'll be amazed what an unstructured buzzing bazaar can do for software development :).
I like Rohit's idea of starting small with "submit one patch, or one bug+test case". I'm not worried about quality. These frameworks won't accept sub-standard commits and this initiative can give us exactly the reality check we need.
How about I create three tabs to start with?
- Django. Point of contact == Rohit Sethi
- JEE. Point of contact == Jeff Williams
- Spring. Point of contact == John Steven
Regards, John
Rohit Sethi
To underscore John Steven's point, IMHO the most important first goal
should be to build relationships from the various open source teams.
I'd bet that Jeff had to work hard at forging relationships with Java
folks to be involved in shaping Java 7 specs and reference
implementations. I think direct contributions are generally the most
effective way to become a valued member of any open source community.
John Wilander, tabs on the project page sounds like a good start. One
of our devs is looking to help the Snap framework the same we're
working with Django - I'll ask him to throw his name in there. Also,
its probably worth talking to Heiko Webers about Rails security.
How do we get more people involved in this? I think asking around at
mailing lists is one way. Perhaps its a topic we can bring up at owasp
conferences as well?
On 4/10/11, John Wilander <john.w...@owasp.org> wrote:
> Hi all!
>
> This discussion reminds me of "The Cathedral and the Bazaar" (
> http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar). Check it out,
> especially "Guidelines for creating good open source software". In short,
> you'll be amazed what an unstructured buzzing bazaar can do for software
> development :).
>
> I like Rohit's idea of starting small with "submit one patch, or one
> bug+test case". I'm not worried about quality. These frameworks won't accept
> sub-standard commits and this initiative can give us exactly the reality
> check we need.
>
> How about I create three tabs to start with?
>
> 1. Django. Point of contact == Rohit Sethi
> 2. JEE. Point of contact == Jeff Williams
> 3. Spring. Point of contact == John Steven
Rohit Sethi
thought it made sense so he's asked me to post it here for him:
---------
One patch at a time. It's not about massive effort in one shot and then walk
away. It's about continual effort over time. This is how trust is built.
Once months go by and folks see that we are still active, working on this
initiative, and have successes under our belt, folks will want to join more
and more.
- Jim
John Steven
I found myself reading the Cathedral and Bazaar about a week and a
half ago--again. While I don't doubt that my suggestions do leave a
negative connotation in people's mind, I'll make my key suggestion
again and leave [the thing] to grow and evolve as it will: as an
outsider, I'd always been amused at how inconsistent and (often)
incorrect OWASP guidance could be--especially in the realm of
remediation.
>>> > > ***Only by bringing each framework perspective to the common design
>>> > > table BEFORE we march off to code can we avoid fractured approach and
>>> > > duplication of effort.***
While OWASP's maturation has brought more consistency and correctness
to the available remediation advice, there's still a lot to be gained
by getting our sh*t relatively straight as a crew before we dispatch
to the bazaar. This, too, is likely to be informal and unstructured,
with this group--and that's entirely OK.
-jOHN
Jim Manico
I do not think this will scare folks off. In fact, the more we have our act together, the easier it will be to scale this effort to more frameworks in a consistent way.
I'm not saying to stop current efforts. A multi-track approach is acceptable.
But I agree that we need to get basic remediation planning in place so we can ripple that advice out to different Framework remediation teams at scale.
John, have you taken a look at the OWASP cheat-sheet series? Could this knowledge serve to provide "base scenarios"?
Jim Manico
David Rook
you keep it ad-hoc and unstructured I think this is going to be hard
to really point in a direction and progress with.
I also wondered if we will engage with the frameworks first and work
with them rather than appearing to turn up and say "were from OWASP,
we are hear to fix your sh*t". I know we won't have that attitude but
I think a small amount of engagement work upfront can avoid anyone
interpreting our work as being that.
Dave
Jim Manico
My experience says that if we use each frameworks bug tracking system and operate as part of •their• community, all feedback is considered seriously.
So basically I see it like this: we start with a common set of remediation advice and prioritize issues for each framework via threat modeling/risk analysis. Then different individuals can participate in each frameworks development and maintenance as a member of the framework team, not necessarily as an "OWASP rep".
In fact, if our remediation advice is solid enough, it •will• turn into a framework guideline that non-OWASPers could turn to.
Your warning is right on. If we show up as the "OWASP AppSec police" we will be told to F-off, and rightfully so.
Jim Manico
Rohit Sethi
This is the idea behind forging relationships with the framework
developers. We will work together here on common approaches but
ultimately the framework developers themselves will have authority
over which security features make it into a framework and how those
features will be implemented.
Cheers,
Rohit
Abraham Kang
(like JavaOne) to reach out to developers.
If we weren't why aren't we and can we identify conferences to speak at.
Regards,
Abe
JIM BIRD
Subject: Re: Scheme for Unifying Approach to Framework-based Developer Outreach
To: owasp-dev-out...@googlegroups.com, jeff williams <jeff.w...@owasp.org>
> Hi all!
>
> This discussion reminds me of "The Cathedral and the
> Bazaar" (
> http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar).
> Check it out,
> especially "Guidelines for creating good open source software".
> In short,
> you'll be amazed what an unstructured buzzing bazaar can do for
>
> I like Rohit's idea of starting small with "submit one patch, or one
> bug+test case". I'm not worried about quality. These frameworks
> won't accept
> sub-standard commits and this initiative can give us exactly the
>
> How about I create three tabs to start with?
>
> 2. JEE. Point of contact == Jeff Williams
> 3. Spring. Point of contact == John Steven
>
> You can fill out whatever your goals or activities are. Then we
> promote this
> to the OWASP community and ask if there are ongoing
Rohit Sethi
As a head's up we've started to make some progress with a separate security package for Django: https://github.com/sdelements/django-security
We'll be writing more in the coming weeks about this as we add more documentation and spread the word to the Django community. Our goal is to get some of the tools used by the community for eventual inclusion into the framework. At the same time, we realize that there are some features which non-security people are just not going to prioritize as coming "out of the box" (e.g. protection against brute force authentication attacks). In those cases, we hope Django Security will make it easy for the Django users to build in standard controls with little effort.
John, did anything happen with this? I can't find anything on OWASP about who is helping on what frameworks, tand what the next steps are.
--
Rohit Sethi
SD Elements
http://www.sdelements.com
twitter: rksethi
JIM BIRD
What you are working on sounds like it would make a real difference to the Java community. It's good to hear something positive about the Java community process - it's taken a serious hit after Oracle took over, so many Sun people leaving, there's a general negative feeling now about the stewardship of Java and it's future. It sounds like this could be a real success for Java and OWASP. How can people follow what you are doing and how could they help?
----- Original Message -----
From: Jeff Williams <jeff.w...@owasp.org>
Date: Thursday, May 19, 2011 8:09 pm
Subject: RE: Scheme for Unifying Approach to Framework-based Developer Outreach
To: 'JIM BIRD' <jim...@shaw.ca>, owasp-dev-out...@googlegroups.com
> Hi Jim,
>
>
>
> I'm planning to continue my work with Sun/Oracle/Java and would
> love to
> create a better way to focus OWASP's energy in this area.
> They are going to
> be rolling out some new JSRs that will help with some long-
> needed areas in
> Java, but there are a lot more that OWASP could help with.
>
>
>
> --Jeff
> eden.blogspot.com> <http://owaspsweden.blogspot.com>
>
>
Jim Manico
Cheers JimB,
Jim Manico
John Steven
As you can see from the responses, some out-reach has occurred but not
a lot has transpired. I'm actually going to pick up this Spring threat
next week in relative earnest. If you'd like, I can copy you on
whatever mailings I produce, and share documents generated.
Chris Schmidt, who I'm sure you're familiar with, has already begun
roughing in authentication adapters for ESAPI / Spring, with his
contrib project and I definitely plan to expand upon his initial
forays.
-jOHN
--
-jOHN
JIM BIRD
I would be very interested in following your work, I would appreciate you copying me in. Thank you.