You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "bphillips@ku.edu" <bp...@ku.edu> on 2012/02/21 15:09:51 UTC
Security Vulnerability When Using SessionAware and Best Practice
For Mitigating It
I was researching the SessionAware interface as I'm planning on adding a
tutorial on how to use the HTTP Session object from within a Struts Action
class to the tutorials at:
https://cwiki.apache.org/confluence/display/WW/Getting+Started
https://cwiki.apache.org/confluence/display/WW/Getting+Started .
I ran across this
http://codesecure.blogspot.com/2011/12/struts-2-session-tampering-via.html
blog post and https://issues.apache.org/jira/browse/WW-3631 Struts 2 JIRA
issue that discuss a security vulnerability when using SessionAware.
I'd like to include in the tutorial the best practices for mitigating this
vulnerability. Here is what I think programmers who use SessionAware in
their Action class should do to mitigate this vulnerability:
1. Do not create a public Map<String, Object> getSession() method in the
Action class
2. Also implement the ParameterNameAware interface and override its
acceptableParameterName method as follows:
public boolean acceptableParameterName(String parameterName) {
boolean allowedParameterName = true ;
if ( parameterName.contains("session") ||
parameterName.contains("request") ) {
allowedParameterName = false ;
}
return allowedParameterName;
}
I'd certainly appreciate any feedback on best practices to follow when
implementing the SessionAware interface and how to mitigate the security
vulnerability.
Thank You,
Bruce Phillips
--
View this message in context: http://struts.1045723.n5.nabble.com/Security-Vulnerability-When-Using-SessionAware-and-Best-Practice-For-Mitigating-It-tp5502292p5502292.html
Sent from the Struts - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Security Vulnerability When Using SessionAware and Best
Practice For Mitigating It
Posted by "bphillips@ku.edu" <bp...@ku.edu>.
Lukasz:
Good idea on letting struts 2 developers know that instead of implementing
the ParameterNameAware interface that they can change the excludeParams
value as part of the package setup.
So I'll add to my code example:
<package name="basicstruts2" extends="struts-default">
<interceptors>
<interceptor-stack name="appDefault">
<interceptor-ref name="defaultStack">
true
ERROR
dojo\..*,^struts\..*,^session\..*,^request\..*,^application\..*,^servlet(Request|Response)\..*,parameters\...*
</interceptor-ref>
</interceptor-stack>
</interceptors>
<default-interceptor-ref name="appDefault" />
and include in the tutorial text both options.
Thanks for the help.
--
View this message in context: http://struts.1045723.n5.nabble.com/Security-Vulnerability-When-Using-SessionAware-and-Best-Practice-For-Mitigating-It-tp5502292p5525787.html
Sent from the Struts - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Security Vulnerability When Using SessionAware and Best Practice
For Mitigating It
Posted by Łukasz Lenart <lu...@googlemail.com>.
2012/2/28 bphillips@ku.edu <bp...@ku.edu>:
> Lukasz - I agree with you, but until a new version of Struts 2 is released
> that includes a fix for this vulnerability, I'd like to tell Struts 2
> developers what to do when implementing the SessionAware interface to
> mitigate the vulnerability.
>
> If you could look over what I wrote in the initial post and provide any
> feedback on that I'd certainly appreciate your comments.
Your proposal is fair enough, and maybe adding also a note about
changing excludeParams (as in WW-3631) to solve the problem
completely, as it's better to make a change in one place and not to
implement the same interface over and over (ParameterNameAware)
Regards
--
Łukasz
Mobile +48 606 323 122
Office +27 11 0838747
http://www.lenart.org.pl/
Warszawa JUG conference - Confitura http://confitura.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Security Vulnerability When Using SessionAware and Best
Practice For Mitigating It
Posted by "bphillips@ku.edu" <bp...@ku.edu>.
Lukasz - I agree with you, but until a new version of Struts 2 is released
that includes a fix for this vulnerability, I'd like to tell Struts 2
developers what to do when implementing the SessionAware interface to
mitigate the vulnerability.
If you could look over what I wrote in the initial post and provide any
feedback on that I'd certainly appreciate your comments.
--
View this message in context: http://struts.1045723.n5.nabble.com/Security-Vulnerability-When-Using-SessionAware-and-Best-Practice-For-Mitigating-It-tp5502292p5523338.html
Sent from the Struts - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Security Vulnerability When Using SessionAware and Best Practice
For Mitigating It
Posted by Łukasz Lenart <lu...@googlemail.com>.
I think we should simply implemented what was mentioned in WW-3631 to
solve that potential vulnerability
Kind regards
--
Łukasz
Mobile +48 606 323 122
Office +27 11 0838747
http://www.lenart.org.pl/
Warszawa JUG conference - Confitura http://confitura.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Security Vulnerability When Using SessionAware and Best
Practice For Mitigating It
Posted by "bphillips@ku.edu" <bp...@ku.edu>.
I appreciate your comments, but what I'd like to accomplish is what
instructions should we provide in our tutorial on using the SessionAware
interface in order to best mitigate the security vulnerabilities introduced
when using SessionAware given how the Struts 2 framework works today.
I don't think using only immutable objects in the session reduces the
vulnerability. String is immutable, but as I understand the security
vulnerability of using SessionAware, a hacker could change the String value
I've stored in the session.
When using SessionAware what do experienced Struts 2 developers do to reduce
as much as possible the vulnerability identified in my original post? I'd
like to include these practices in the SessionAware tutorial.
Thank you for the feedback.
--
View this message in context: http://struts.1045723.n5.nabble.com/Security-Vulnerability-When-Using-SessionAware-and-Best-Practice-For-Mitigating-It-tp5502292p5519824.html
Sent from the Struts - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Security Vulnerability When Using SessionAware and Best Practice
For Mitigating It
Posted by Greg Lindholm <gr...@gmail.com>.
You can still do this with immutable objects, instead of changing the value
of a session object you just replace it with a new object with the changed
value. A few years back I encountered problems with clustered application
servers where if you changed an object in the sessions those changes were
not always replicated to the other servers in the cluster. Using only
immutable objects solved the problem then and It's saved me on a couple
other issues since, hence I consider it a "best practice".
On Mon, Feb 27, 2012 at 10:50 AM, Gabriel Belingueres <belingueres@gmail.com
> wrote:
> I don't know if storing only immutable state in session is a "Best
> Practice" (if there exists such a thing as a best practice).
>
> Consider frameworks like JBoss Seam or Spring Web Flow with their
> support for conversations, which is basically mutable state stored in
> session scope.
>
> The case seems to be that people are using those sensible, managed by
> the framework, dependency injected objects (with their XXXAware
> interfaces) as first class properties of their actions (by
> implementing their corresponding getter). Combined with the power of
> the parameters interceptor, those unwanted aliases gets hard to
> manage.
>
> One way to solve the problem would require avoid getting direct
> references to those framework objects, however this requires that the
> framework do more stuff for us.
>
> For example, JBoss Seam has those @In @Out annotation for injection
> and outjection. These are handy because you no longer need to have the
> actual scope object reference in your actions.
>
> 2012/2/27 Greg Lindholm <gr...@gmail.com>:
> > A Best Practice for the Session is to only store Immutable object in the
> > session. This would eliminate the SessionAware issue plus it can also be
> > important for clustered servers.
> >
> >
> > On Tue, Feb 21, 2012 at 9:09 AM, bphillips@ku.edu <bp...@ku.edu>
> wrote:
> >
> >> I was researching the SessionAware interface as I'm planning on adding a
> >> tutorial on how to use the HTTP Session object from within a Struts
> Action
> >> class to the tutorials at:
> >> https://cwiki.apache.org/confluence/display/WW/Getting+Started
> >> https://cwiki.apache.org/confluence/display/WW/Getting+Started .
> >>
> >> I ran across this
> >>
> http://codesecure.blogspot.com/2011/12/struts-2-session-tampering-via.html
> >> blog post and https://issues.apache.org/jira/browse/WW-3631 Struts 2
> >> JIRA
> >> issue that discuss a security vulnerability when using SessionAware.
> >>
> >> I'd like to include in the tutorial the best practices for mitigating
> this
> >> vulnerability. Here is what I think programmers who use SessionAware in
> >> their Action class should do to mitigate this vulnerability:
> >>
> >> 1. Do not create a public Map<String, Object> getSession() method in
> the
> >> Action class
> >>
> >> 2. Also implement the ParameterNameAware interface and override its
> >> acceptableParameterName method as follows:
> >>
> >> public boolean acceptableParameterName(String parameterName) {
> >>
> >> boolean allowedParameterName = true ;
> >>
> >> if ( parameterName.contains("session") ||
> >> parameterName.contains("request") ) {
> >>
> >> allowedParameterName = false ;
> >>
> >> }
> >>
> >> return allowedParameterName;
> >> }
> >>
> >> I'd certainly appreciate any feedback on best practices to follow when
> >> implementing the SessionAware interface and how to mitigate the security
> >> vulnerability.
> >>
> >> Thank You,
> >>
> >> Bruce Phillips
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://struts.1045723.n5.nabble.com/Security-Vulnerability-When-Using-SessionAware-and-Best-Practice-For-Mitigating-It-tp5502292p5502292.html
> >> Sent from the Struts - User mailing list archive at Nabble.com.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: user-help@struts.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: Security Vulnerability When Using SessionAware and Best Practice
For Mitigating It
Posted by Gabriel Belingueres <be...@gmail.com>.
I don't know if storing only immutable state in session is a "Best
Practice" (if there exists such a thing as a best practice).
Consider frameworks like JBoss Seam or Spring Web Flow with their
support for conversations, which is basically mutable state stored in
session scope.
The case seems to be that people are using those sensible, managed by
the framework, dependency injected objects (with their XXXAware
interfaces) as first class properties of their actions (by
implementing their corresponding getter). Combined with the power of
the parameters interceptor, those unwanted aliases gets hard to
manage.
One way to solve the problem would require avoid getting direct
references to those framework objects, however this requires that the
framework do more stuff for us.
For example, JBoss Seam has those @In @Out annotation for injection
and outjection. These are handy because you no longer need to have the
actual scope object reference in your actions.
2012/2/27 Greg Lindholm <gr...@gmail.com>:
> A Best Practice for the Session is to only store Immutable object in the
> session. This would eliminate the SessionAware issue plus it can also be
> important for clustered servers.
>
>
> On Tue, Feb 21, 2012 at 9:09 AM, bphillips@ku.edu <bp...@ku.edu> wrote:
>
>> I was researching the SessionAware interface as I'm planning on adding a
>> tutorial on how to use the HTTP Session object from within a Struts Action
>> class to the tutorials at:
>> https://cwiki.apache.org/confluence/display/WW/Getting+Started
>> https://cwiki.apache.org/confluence/display/WW/Getting+Started .
>>
>> I ran across this
>> http://codesecure.blogspot.com/2011/12/struts-2-session-tampering-via.html
>> blog post and https://issues.apache.org/jira/browse/WW-3631 Struts 2
>> JIRA
>> issue that discuss a security vulnerability when using SessionAware.
>>
>> I'd like to include in the tutorial the best practices for mitigating this
>> vulnerability. Here is what I think programmers who use SessionAware in
>> their Action class should do to mitigate this vulnerability:
>>
>> 1. Do not create a public Map<String, Object> getSession() method in the
>> Action class
>>
>> 2. Also implement the ParameterNameAware interface and override its
>> acceptableParameterName method as follows:
>>
>> public boolean acceptableParameterName(String parameterName) {
>>
>> boolean allowedParameterName = true ;
>>
>> if ( parameterName.contains("session") ||
>> parameterName.contains("request") ) {
>>
>> allowedParameterName = false ;
>>
>> }
>>
>> return allowedParameterName;
>> }
>>
>> I'd certainly appreciate any feedback on best practices to follow when
>> implementing the SessionAware interface and how to mitigate the security
>> vulnerability.
>>
>> Thank You,
>>
>> Bruce Phillips
>>
>>
>>
>> --
>> View this message in context:
>> http://struts.1045723.n5.nabble.com/Security-Vulnerability-When-Using-SessionAware-and-Best-Practice-For-Mitigating-It-tp5502292p5502292.html
>> Sent from the Struts - User mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@struts.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Security Vulnerability When Using SessionAware and Best Practice
For Mitigating It
Posted by Greg Lindholm <gr...@gmail.com>.
A Best Practice for the Session is to only store Immutable object in the
session. This would eliminate the SessionAware issue plus it can also be
important for clustered servers.
On Tue, Feb 21, 2012 at 9:09 AM, bphillips@ku.edu <bp...@ku.edu> wrote:
> I was researching the SessionAware interface as I'm planning on adding a
> tutorial on how to use the HTTP Session object from within a Struts Action
> class to the tutorials at:
> https://cwiki.apache.org/confluence/display/WW/Getting+Started
> https://cwiki.apache.org/confluence/display/WW/Getting+Started .
>
> I ran across this
> http://codesecure.blogspot.com/2011/12/struts-2-session-tampering-via.html
> blog post and https://issues.apache.org/jira/browse/WW-3631 Struts 2
> JIRA
> issue that discuss a security vulnerability when using SessionAware.
>
> I'd like to include in the tutorial the best practices for mitigating this
> vulnerability. Here is what I think programmers who use SessionAware in
> their Action class should do to mitigate this vulnerability:
>
> 1. Do not create a public Map<String, Object> getSession() method in the
> Action class
>
> 2. Also implement the ParameterNameAware interface and override its
> acceptableParameterName method as follows:
>
> public boolean acceptableParameterName(String parameterName) {
>
> boolean allowedParameterName = true ;
>
> if ( parameterName.contains("session") ||
> parameterName.contains("request") ) {
>
> allowedParameterName = false ;
>
> }
>
> return allowedParameterName;
> }
>
> I'd certainly appreciate any feedback on best practices to follow when
> implementing the SessionAware interface and how to mitigate the security
> vulnerability.
>
> Thank You,
>
> Bruce Phillips
>
>
>
> --
> View this message in context:
> http://struts.1045723.n5.nabble.com/Security-Vulnerability-When-Using-SessionAware-and-Best-Practice-For-Mitigating-It-tp5502292p5502292.html
> Sent from the Struts - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>