[Owasp-leaders] More cheating

John Steven John.Steven at owasp.org
Mon Aug 15 09:02:36 EDT 2011


"Agreed" on the proposed break-down (topic areas/versions) and
priority. The scope needs appreciably expanded beyond validation, IMO.
Are we OK having a 5-7 page cheat 'sheet' on Struts? Or, do we want a
knowledge architecture that cuts the onion thus: "Here's a sheet on
validation." And "here's a "technology specific leaflet on validation
in Struts 2.x"? I prefer the former because when a developer sits down
to program, they select the controller framework early-on and then
discern what its controller architecture handles for them and more
importantly: what they'll have to rough in on top of it. To me, when
you search for a cheat sheet on Struts, you'd be disappointed if
instead of listing that full set of TODOs it fixated on IV.

Along that vein, remember as a controller framework, the following
things fall within Struts' responsibilities:

* Dispatching any (*1) request authentication
* Filtering/validating input
* Authorizing any (*1) request before sub-controller/action dispatch
* Dispatching appropriate actions
* Maintaining action state-transition information

My Threat Modeling slides [TM] cover these points but there's
unfortunately almost no additional info present. Summarizing, I've
selected (basically) the controller's responsibilities and left
model/view out of the equation. Arshan produced a Gap Analysis of
Application Security [GS] and added the following responsibilities to
the scope of his analysis: (overlapping items omitted)

• Anti-caching controls (see Appendix C)
• CSRF controls (see Appendix D)
• Uncaught exception handling (see Appendix E)
• Enforcing SSL requirements (see Appendix F)
• Regenerating session IDs (see Appendix G)

While I don't recommend this gap analysis as a framework for
considering Struts security any cheat sheet produced without treating
his scope explicitly would, in my opinion, lack quite a bit. I suggest
the following:

1) Cover those items above supported (at least partially) by the
framework, simple use of underlying JavaEE framework (in keeping with
the Struts idioms), or optionally provided by the application
container itself:

* Dispatching any (*1) request authentication
* Filtering/validating input
* Authorizing any (*1) request before sub-controller/action dispatch
* Dispatching appropriate actions
• Regenerating session IDs (see Appendix G)
• Anti-caching controls (see Appendix C)
• Uncaught exception handling (see Appendix E)

2) Leave detailed treatment of those concepts requiring "heavy
lifting" to port to a Struts app, such as:

• CSRF controls (see Appendix D)
• Enforcing SSL requirements (see Appendix F)
* Output encoding

One might argue that one or two items belong in list 2 as opposed to
list 1, or vice versa. I based list membership on my experience
applying remediation to larger banking apps. This is obviously one
context of many valid within the OWASP ecosystem.

Phone: 703.727.4034
Rss: http://feeds.feedburner.com/M1splacedOnTheWeb

* [TM] - https://www.owasp.org/images/7/79/AppSecEU09_OWASP_EU_Threat_Modeling.ppt
Slides 12, 13
* [GS] - https://www.owasp.org/images/b/be/A_Gap_Analysis_of_Application_Security_in_Struts2.pdf
Page 4
* (1) - I'm a firm believer that for the Fortune 1000, there's not a
lot of value in pretending that a Struts-based application isn't
integrated with a URL-based AuthN package, such as CA's SiteMinder. In
these cases, our programmatic/declarative advice on AuthN/AuthZ seems
silly (see pages 25-26 in [GS]) in absence of a proper adapter to that
oft-ignored "Enterprise-class" product. I plan to address this
limitation, at least superficially, in the cheat sheet.

On Mon, Aug 15, 2011 at 7:23 AM, Eoin <eoinkeary at gmail.com> wrote:
> Cover off as John said:
> Struts 1.x (pre-1.3)
> Struts 2.x (including 1.3) first.
> Including commons validator etc
> Moving onto Spring
> Need to keep short (2 pages it is a cheat sheet).
> Focusing on connecting up a form field to the validator etc.
> thoughts?
> On 14 August 2011 13:38, Jim Manico <jim.manico at owasp.org> wrote:
>> An "input validation cheat-sheet" in general would be a huge win.
>> Love it! If you send me your outline I'll iterate with you. I'd like
>> to see the tough stuff like canonicalization, char-set normalization,
>> file-upload input file validation, and some of the tough edge cases
>> when validating for redirect features in there.
>> We can "cheat" and still cover the tough topics. Cool "The Irish Guy" ?
>> On Aug 14, 2011, at 8:32 AM, Eoin Keary <eoinkeary at gmail.com> wrote:
>> > Far from being ambitious but cheat sheets for input validation for most
>> > popular frameworks would be compelling?
>> > I have some struts stuff done already in the code review guide but it
>> > needs to be re-jigged a little to reflect cheer sheet convention.
>> >
>> >
>> > On 14 Aug 2011, at 13:04, John Steven <John.Steven at owasp.org> wrote:
>> >>
>> >> I suggest Struts 1.x (pre-1.3) and then Struts 2.x (including 1.3
>> >> paradigm shift) first. They all implement MVC which will be easier
>> >> than the IoC Spring implements.
>> >>
>> >> For Spring, I'd suggest skipping 1.x but treating 2.x and 3.x
>> >> separately.
>> >>
>> >> Can I write a skeleton? Yes. Will do.

More information about the OWASP-Leaders mailing list