[Owasp-leaders] More cheating

Abraham Kang abraham.kang at owasp.org
Mon Aug 15 21:29:58 EDT 2011


Hi John,

I think this is a great start but I would like to suggest a few
additional topics related to Struts 2.


Disabling dev mode in production:
------------------------------------------------

<struts> <constant name="struts.devMode" value="false"/>  ... </struts>


Over exposure of Action methods through
-----------------------------------------------------------

struts.enable.DynamicMethodInvocation = true

and URLs like   /ActionName!exposedAdminMethod.action



File Upload in Struts 2
--------------------------------

<package name="mytest" extends="struts-default">
<action name="File">
<result>/jsp/Upload.jsp</result>
</action>

<action name="File_Upload" class="tempPackage.SingleFileUploadAction"
method="upload">
<interceptor-ref name="fileUpload">
<param name="maximumSize">100000</param>
<param name="allowedTypes"> image/gif,image/jpeg,image/png </param>
</interceptor-ref>
<interceptor-ref name="basicStack"/>
<result name="input">/jsp/Upload.jsp</result>
<result>/jsp/Upload.jsp</result> </action>
</package>

Tested this and found it worked decently well.  Tried file names like
%2e%2e%5cfileTest.jpeg, %2e%2e%5cfileTest.bmp.  (Many a PHP server can
be owned with this one).

Correctly disallowed *.bmp files.  I also tried uploading text files
(Having script code) having the extension .gif and the files were
correctly disallowed.  I don't know how they are validating the file
type.

The only thing that is missing is a way to hook in virus scanning of
the uploaded files.


Proper File Download in Struts2
---------------------------------------------

I figured out how to do file downloads:

<package name="myTest" extends="struts-default">

<action name="inlineAndMoreDangerous" class="mypackage.FileDownloadAction">
<result name="success" type="stream">
<param name="inputName">inputStream</param>
<param name="contentType">correct/value</param>
<param name="contentDisposition"> filename="someFile.ext"</param>
<param name="allowCaching">false</param>
<param name="bufferSize">2048</param>
<param name="cacheContol"> no-transform</param>   <!--This doesn't
exist but needs to -->
</result> </action>

<action name="asAttachmentSoUGetPrompted2SaveOrRun"
class="mypackage.FileDownloadAction">
<result name="success" type="stream">
<param name="inputName">inputStream</param>
<param name="contentType"> application/octet-stream </param>
<param name="contentDisposition"> attachment;filename="someFile.ext" </param>
<param name="allowCaching">false</param>
<param name="bufferSize">2048</param>
<param name="cacheContol"> no-transform</param>     <!--This doesn't
exist but needs to -->
</result> </action>
</package>

The second result is the safer way to do file downloads.


Issues related to using ORM objects as auto-bound objects.
------------------------------------------------------------------------------

This is an issue which Dinis Cruz brought up a while ago but needs to
be explored further in relation to Struts 2.
Allows for a type of SQL Injection attacker even if the app is using
request parameters.


Issues related to Spring Integration
------------------------------------------------

Race conditions caused by Spring managed Action having their "scope"
attribute defaulted to singleton or not setting the value to
prototype.

Also auto-binding of Spring associated beans and their attributes by
request parameters when the Spring is managing the Actions and the
Action objects have non-trivial instance variables.

Exposure of sensitive objects as Action attributes


Issues related to Security Anti-patterns including implementing
RequestAware and SessionAware
---------------------------------------------------------------------------------------------------------------------------------------------

Highlight issues related to how attackers can attack requests
attributes and session attributes through request parameters when
developers do not implement these interfaces correctly.

Highlight the problem of shadow variables on the Struts 2 value stack
even then the RequestAware and SessionAware are implemented correctly.


Configuring a Global Exception Handler
--------------------------------------------------------


Open Questions:
------------------------

1.  What characters are encoded by the Struts 2 form tags? This will
determine if certain code instances are still vulnerable to XSS for
example:

The <s:property value="nullExample" default="A default value."/> will
HTML encode output by default.

What characters are encoded.

The <s:property> tag also has an "escapeJavaScript" attribute which if
set to true escapes ' (single quote) and " (double quote) according to
the documentation that I read.

 However that won't help you in the following situation:


<script>

var x = callFunction('<s:property value="var1"
escapeJavaScript="true"/>', '<s:property value="var2"
escapeJavaScript="true" />');

</script>

If the attacker makes var1 = "somevalue\" then the second single quote
is escaped and the attacker can deliver their payload in var2.


This is off the top of my head.  I know there are other
vulnerabilities related to Struts 2 that I am forgetting.


Regards,
Abraham Kang



On Mon, Aug 15, 2011 at 6:02 AM, John Steven <John.Steven at owasp.org> wrote:
>
> Eoin,
>
> "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.
>
> Thoughts?
> -jOHN
> --
> 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.
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders


More information about the OWASP-Leaders mailing list