You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by karthik kn <ke...@gmail.com> on 2016/12/19 10:44:05 UTC
Reg vulnerability for Server State saving
Hi,
I am using myfaces-1.1.5 and using the following state saving method
<context-param><param-name>javax.faces.STATE_SAVING_METHOD</param-name><param-value>server</param-value></context-param>
However,i see that the object identifier is being sent to the server as
following
<input type="hidden" name="javax.faces.ViewState"
id="javax.faces.ViewState"
value="rO0ABXVyABNbTGphdmEubGFuZy5PYmplY3Q7kM5YnxBzKWwCAAB4cAAAAAN0AAEzcHQAJi9qc3AvaGxyL2FjX3N1YnNjcmliZXIvY3J0U2luZ2xlQUMuanNw"
/></form>
This is the serialized object identifier sent over the network
We are using only https and not http.
Does sending this serialized object identifier without encrypting open any
vulnerability which the attacker could use to his/her advantage ?
--
-------------------------
Thanks & Regards
Karthik.K.N
Re: Reg vulnerability for Server State saving
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
It is in the wiki page. See org.apache.myfaces.ALGORITHM.IV web config
param for details.
If you want to take a look at the class where the encryption happens, see
org.apache.myfaces.shared.util.StateUtils in
http://svn.apache.org/repos/asf/myfaces/core/trunk/shared/src/main/java/org/apache/myfaces/shared/util/StateUtils.java
regards,
Leonardo Uribe
2017-01-29 23:39 GMT-05:00 karthik kn <ke...@gmail.com>:
> Any thoughts on the below ?
>
> On Fri, Jan 27, 2017 at 10:57 AM, karthik kn <ke...@gmail.com> wrote:
>
> > Hi All,
> > We were able to update the jsf version to the lates and randomly generate
> > the enc key as mentioned in
> > https://wiki.apache.org/myfaces/Secure_Your_Application
> >
> > However, the Initialization vector for CBC needs to be mentioned. Can we
> > not generate it randomly ?
> >
> > Is this a bug in JSF ?
> >
> > If i could generate the Enc key, then the IV should have been generated
> > randomly.
> >
> > Please let know
> >
> > On Fri, Dec 23, 2016 at 3:54 PM, Thomas Andraschko <
> > andraschko.thomas@gmail.com> wrote:
> >
> >> Hi,
> >>
> >> i don't think there is any other way to configure it but you can still
> >> check the sources: http://svn.apache.org/viewvc/m
> >> yfaces/core/branches/1.1.x/
> >>
> >> Regards,
> >> Thomas
> >>
> >> 2016-12-23 11:21 GMT+01:00 karthik kn <ke...@gmail.com>:
> >>
> >> > Hi All,
> >> > Any thoughts on the below ?
> >> >
> >> > On Wed, Dec 21, 2016 at 10:22 AM, karthik kn <ke...@gmail.com>
> >> wrote:
> >> >
> >> > > Hi,
> >> > > If i use a new key in web.xml as SECRET, it could be still exposed
> to
> >> > the
> >> > > Administrator on accessing the system.
> >> > >
> >> > > Wont this cause a vulnerability ? Is there any other mechanism of
> >> storing
> >> > > the secret ?
> >> > >
> >> > > On Tue, Dec 20, 2016 at 6:52 PM, Moritz Bechler <be...@agno3.eu>
> >> > wrote:
> >> > >
> >> > >> Hi,
> >> > >>
> >> > >> > Thank you for clarification. Using the secret mentioned in the
> >> below
> >> > >> page
> >> > >> > would suffice or there is some mechanism to generate the SECRET ?
> >> > >> >
> >> > >>
> >> > >> You must not use the keys specified on this page but generate your
> >> own
> >> > >> secret ones. An attacker using the same key can then produce a
> valid
> >> > >> ViewState token containing an exploit. Also, as noted on the
> security
> >> > >> page and by Leonardo, version up to and including 1.1.7, 1.2.8,
> 2.0.0
> >> > >> are vulnerable to padding oracle attacks (I haven't had a close
> look
> >> but
> >> > >> I would be pretty sure that also applies to server side state
> >> saving).
> >> > >> That means that an attacker may be able to create such tokens
> without
> >> > >> the knowledge of the key - again allowing for the same exploits.
> >> > >>
> >> > >> So I guess there is no way to be really safe without upgrading.
> >> > >>
> >> > >>
> >> > >> Moritz
> >> > >>
> >> > >> PS: you also might want to consider using something stronger than
> >> DES.
> >> > >>
> >> > >>
> >> > >> --
> >> > >> AgNO3 GmbH & Co. KG, Sitz Tübingen, Amtsgericht Stuttgart HRA
> 728731
> >> > >> Persönlich haftend:
> >> > >> Metagesellschaft mbH, Sitz Tübingen, Amtsgericht Stuttgart HRB
> >> 744820,
> >> > >> Vertreten durch Joachim Keltsch
> >> > >>
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > -------------------------
> >> > > Thanks & Regards
> >> > >
> >> > > Karthik.K.N
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > -------------------------
> >> > Thanks & Regards
> >> >
> >> > Karthik.K.N
> >> >
> >>
> >
> >
> >
> > --
> > -------------------------
> > Thanks & Regards
> >
> > Karthik.K.N
> >
>
>
>
> --
> -------------------------
> Thanks & Regards
>
> Karthik.K.N
>
Re: Reg vulnerability for Server State saving
Posted by karthik kn <ke...@gmail.com>.
Any thoughts on the below ?
On Fri, Jan 27, 2017 at 10:57 AM, karthik kn <ke...@gmail.com> wrote:
> Hi All,
> We were able to update the jsf version to the lates and randomly generate
> the enc key as mentioned in
> https://wiki.apache.org/myfaces/Secure_Your_Application
>
> However, the Initialization vector for CBC needs to be mentioned. Can we
> not generate it randomly ?
>
> Is this a bug in JSF ?
>
> If i could generate the Enc key, then the IV should have been generated
> randomly.
>
> Please let know
>
> On Fri, Dec 23, 2016 at 3:54 PM, Thomas Andraschko <
> andraschko.thomas@gmail.com> wrote:
>
>> Hi,
>>
>> i don't think there is any other way to configure it but you can still
>> check the sources: http://svn.apache.org/viewvc/m
>> yfaces/core/branches/1.1.x/
>>
>> Regards,
>> Thomas
>>
>> 2016-12-23 11:21 GMT+01:00 karthik kn <ke...@gmail.com>:
>>
>> > Hi All,
>> > Any thoughts on the below ?
>> >
>> > On Wed, Dec 21, 2016 at 10:22 AM, karthik kn <ke...@gmail.com>
>> wrote:
>> >
>> > > Hi,
>> > > If i use a new key in web.xml as SECRET, it could be still exposed to
>> > the
>> > > Administrator on accessing the system.
>> > >
>> > > Wont this cause a vulnerability ? Is there any other mechanism of
>> storing
>> > > the secret ?
>> > >
>> > > On Tue, Dec 20, 2016 at 6:52 PM, Moritz Bechler <be...@agno3.eu>
>> > wrote:
>> > >
>> > >> Hi,
>> > >>
>> > >> > Thank you for clarification. Using the secret mentioned in the
>> below
>> > >> page
>> > >> > would suffice or there is some mechanism to generate the SECRET ?
>> > >> >
>> > >>
>> > >> You must not use the keys specified on this page but generate your
>> own
>> > >> secret ones. An attacker using the same key can then produce a valid
>> > >> ViewState token containing an exploit. Also, as noted on the security
>> > >> page and by Leonardo, version up to and including 1.1.7, 1.2.8, 2.0.0
>> > >> are vulnerable to padding oracle attacks (I haven't had a close look
>> but
>> > >> I would be pretty sure that also applies to server side state
>> saving).
>> > >> That means that an attacker may be able to create such tokens without
>> > >> the knowledge of the key - again allowing for the same exploits.
>> > >>
>> > >> So I guess there is no way to be really safe without upgrading.
>> > >>
>> > >>
>> > >> Moritz
>> > >>
>> > >> PS: you also might want to consider using something stronger than
>> DES.
>> > >>
>> > >>
>> > >> --
>> > >> AgNO3 GmbH & Co. KG, Sitz Tübingen, Amtsgericht Stuttgart HRA 728731
>> > >> Persönlich haftend:
>> > >> Metagesellschaft mbH, Sitz Tübingen, Amtsgericht Stuttgart HRB
>> 744820,
>> > >> Vertreten durch Joachim Keltsch
>> > >>
>> > >
>> > >
>> > >
>> > > --
>> > > -------------------------
>> > > Thanks & Regards
>> > >
>> > > Karthik.K.N
>> > >
>> >
>> >
>> >
>> > --
>> > -------------------------
>> > Thanks & Regards
>> >
>> > Karthik.K.N
>> >
>>
>
>
>
> --
> -------------------------
> Thanks & Regards
>
> Karthik.K.N
>
--
-------------------------
Thanks & Regards
Karthik.K.N
Re: Reg vulnerability for Server State saving
Posted by karthik kn <ke...@gmail.com>.
Hi All,
We were able to update the jsf version to the lates and randomly generate
the enc key as mentioned in
https://wiki.apache.org/myfaces/Secure_Your_Application
However, the Initialization vector for CBC needs to be mentioned. Can we
not generate it randomly ?
Is this a bug in JSF ?
If i could generate the Enc key, then the IV should have been generated
randomly.
Please let know
On Fri, Dec 23, 2016 at 3:54 PM, Thomas Andraschko <
andraschko.thomas@gmail.com> wrote:
> Hi,
>
> i don't think there is any other way to configure it but you can still
> check the sources: http://svn.apache.org/viewvc/
> myfaces/core/branches/1.1.x/
>
> Regards,
> Thomas
>
> 2016-12-23 11:21 GMT+01:00 karthik kn <ke...@gmail.com>:
>
> > Hi All,
> > Any thoughts on the below ?
> >
> > On Wed, Dec 21, 2016 at 10:22 AM, karthik kn <ke...@gmail.com> wrote:
> >
> > > Hi,
> > > If i use a new key in web.xml as SECRET, it could be still exposed to
> > the
> > > Administrator on accessing the system.
> > >
> > > Wont this cause a vulnerability ? Is there any other mechanism of
> storing
> > > the secret ?
> > >
> > > On Tue, Dec 20, 2016 at 6:52 PM, Moritz Bechler <be...@agno3.eu>
> > wrote:
> > >
> > >> Hi,
> > >>
> > >> > Thank you for clarification. Using the secret mentioned in the below
> > >> page
> > >> > would suffice or there is some mechanism to generate the SECRET ?
> > >> >
> > >>
> > >> You must not use the keys specified on this page but generate your own
> > >> secret ones. An attacker using the same key can then produce a valid
> > >> ViewState token containing an exploit. Also, as noted on the security
> > >> page and by Leonardo, version up to and including 1.1.7, 1.2.8, 2.0.0
> > >> are vulnerable to padding oracle attacks (I haven't had a close look
> but
> > >> I would be pretty sure that also applies to server side state saving).
> > >> That means that an attacker may be able to create such tokens without
> > >> the knowledge of the key - again allowing for the same exploits.
> > >>
> > >> So I guess there is no way to be really safe without upgrading.
> > >>
> > >>
> > >> Moritz
> > >>
> > >> PS: you also might want to consider using something stronger than DES.
> > >>
> > >>
> > >> --
> > >> AgNO3 GmbH & Co. KG, Sitz Tübingen, Amtsgericht Stuttgart HRA 728731
> > >> Persönlich haftend:
> > >> Metagesellschaft mbH, Sitz Tübingen, Amtsgericht Stuttgart HRB 744820,
> > >> Vertreten durch Joachim Keltsch
> > >>
> > >
> > >
> > >
> > > --
> > > -------------------------
> > > Thanks & Regards
> > >
> > > Karthik.K.N
> > >
> >
> >
> >
> > --
> > -------------------------
> > Thanks & Regards
> >
> > Karthik.K.N
> >
>
--
-------------------------
Thanks & Regards
Karthik.K.N
Re: Reg vulnerability for Server State saving
Posted by Thomas Andraschko <an...@gmail.com>.
Hi,
i don't think there is any other way to configure it but you can still
check the sources: http://svn.apache.org/viewvc/myfaces/core/branches/1.1.x/
Regards,
Thomas
2016-12-23 11:21 GMT+01:00 karthik kn <ke...@gmail.com>:
> Hi All,
> Any thoughts on the below ?
>
> On Wed, Dec 21, 2016 at 10:22 AM, karthik kn <ke...@gmail.com> wrote:
>
> > Hi,
> > If i use a new key in web.xml as SECRET, it could be still exposed to
> the
> > Administrator on accessing the system.
> >
> > Wont this cause a vulnerability ? Is there any other mechanism of storing
> > the secret ?
> >
> > On Tue, Dec 20, 2016 at 6:52 PM, Moritz Bechler <be...@agno3.eu>
> wrote:
> >
> >> Hi,
> >>
> >> > Thank you for clarification. Using the secret mentioned in the below
> >> page
> >> > would suffice or there is some mechanism to generate the SECRET ?
> >> >
> >>
> >> You must not use the keys specified on this page but generate your own
> >> secret ones. An attacker using the same key can then produce a valid
> >> ViewState token containing an exploit. Also, as noted on the security
> >> page and by Leonardo, version up to and including 1.1.7, 1.2.8, 2.0.0
> >> are vulnerable to padding oracle attacks (I haven't had a close look but
> >> I would be pretty sure that also applies to server side state saving).
> >> That means that an attacker may be able to create such tokens without
> >> the knowledge of the key - again allowing for the same exploits.
> >>
> >> So I guess there is no way to be really safe without upgrading.
> >>
> >>
> >> Moritz
> >>
> >> PS: you also might want to consider using something stronger than DES.
> >>
> >>
> >> --
> >> AgNO3 GmbH & Co. KG, Sitz Tübingen, Amtsgericht Stuttgart HRA 728731
> >> Persönlich haftend:
> >> Metagesellschaft mbH, Sitz Tübingen, Amtsgericht Stuttgart HRB 744820,
> >> Vertreten durch Joachim Keltsch
> >>
> >
> >
> >
> > --
> > -------------------------
> > Thanks & Regards
> >
> > Karthik.K.N
> >
>
>
>
> --
> -------------------------
> Thanks & Regards
>
> Karthik.K.N
>
Re: Reg vulnerability for Server State saving
Posted by karthik kn <ke...@gmail.com>.
Hi All,
Any thoughts on the below ?
On Wed, Dec 21, 2016 at 10:22 AM, karthik kn <ke...@gmail.com> wrote:
> Hi,
> If i use a new key in web.xml as SECRET, it could be still exposed to the
> Administrator on accessing the system.
>
> Wont this cause a vulnerability ? Is there any other mechanism of storing
> the secret ?
>
> On Tue, Dec 20, 2016 at 6:52 PM, Moritz Bechler <be...@agno3.eu> wrote:
>
>> Hi,
>>
>> > Thank you for clarification. Using the secret mentioned in the below
>> page
>> > would suffice or there is some mechanism to generate the SECRET ?
>> >
>>
>> You must not use the keys specified on this page but generate your own
>> secret ones. An attacker using the same key can then produce a valid
>> ViewState token containing an exploit. Also, as noted on the security
>> page and by Leonardo, version up to and including 1.1.7, 1.2.8, 2.0.0
>> are vulnerable to padding oracle attacks (I haven't had a close look but
>> I would be pretty sure that also applies to server side state saving).
>> That means that an attacker may be able to create such tokens without
>> the knowledge of the key - again allowing for the same exploits.
>>
>> So I guess there is no way to be really safe without upgrading.
>>
>>
>> Moritz
>>
>> PS: you also might want to consider using something stronger than DES.
>>
>>
>> --
>> AgNO3 GmbH & Co. KG, Sitz Tübingen, Amtsgericht Stuttgart HRA 728731
>> Persönlich haftend:
>> Metagesellschaft mbH, Sitz Tübingen, Amtsgericht Stuttgart HRB 744820,
>> Vertreten durch Joachim Keltsch
>>
>
>
>
> --
> -------------------------
> Thanks & Regards
>
> Karthik.K.N
>
--
-------------------------
Thanks & Regards
Karthik.K.N
Re: Reg vulnerability for Server State saving
Posted by karthik kn <ke...@gmail.com>.
Hi,
If i use a new key in web.xml as SECRET, it could be still exposed to the
Administrator on accessing the system.
Wont this cause a vulnerability ? Is there any other mechanism of storing
the secret ?
On Tue, Dec 20, 2016 at 6:52 PM, Moritz Bechler <be...@agno3.eu> wrote:
> Hi,
>
> > Thank you for clarification. Using the secret mentioned in the below page
> > would suffice or there is some mechanism to generate the SECRET ?
> >
>
> You must not use the keys specified on this page but generate your own
> secret ones. An attacker using the same key can then produce a valid
> ViewState token containing an exploit. Also, as noted on the security
> page and by Leonardo, version up to and including 1.1.7, 1.2.8, 2.0.0
> are vulnerable to padding oracle attacks (I haven't had a close look but
> I would be pretty sure that also applies to server side state saving).
> That means that an attacker may be able to create such tokens without
> the knowledge of the key - again allowing for the same exploits.
>
> So I guess there is no way to be really safe without upgrading.
>
>
> Moritz
>
> PS: you also might want to consider using something stronger than DES.
>
>
> --
> AgNO3 GmbH & Co. KG, Sitz Tübingen, Amtsgericht Stuttgart HRA 728731
> Persönlich haftend:
> Metagesellschaft mbH, Sitz Tübingen, Amtsgericht Stuttgart HRB 744820,
> Vertreten durch Joachim Keltsch
>
--
-------------------------
Thanks & Regards
Karthik.K.N
Re: Reg vulnerability for Server State saving
Posted by Moritz Bechler <be...@agno3.eu>.
Hi,
> Thank you for clarification. Using the secret mentioned in the below page
> would suffice or there is some mechanism to generate the SECRET ?
>
You must not use the keys specified on this page but generate your own
secret ones. An attacker using the same key can then produce a valid
ViewState token containing an exploit. Also, as noted on the security
page and by Leonardo, version up to and including 1.1.7, 1.2.8, 2.0.0
are vulnerable to padding oracle attacks (I haven't had a close look but
I would be pretty sure that also applies to server side state saving).
That means that an attacker may be able to create such tokens without
the knowledge of the key - again allowing for the same exploits.
So I guess there is no way to be really safe without upgrading.
Moritz
PS: you also might want to consider using something stronger than DES.
--
AgNO3 GmbH & Co. KG, Sitz T�bingen, Amtsgericht Stuttgart HRA 728731
Pers�nlich haftend:
Metagesellschaft mbH, Sitz T�bingen, Amtsgericht Stuttgart HRB 744820,
Vertreten durch Joachim Keltsch
Re: Reg vulnerability for Server State saving
Posted by karthik kn <ke...@gmail.com>.
Hi,
Thank you for clarification. Using the secret mentioned in the below page
would suffice or there is some mechanism to generate the SECRET ?
https://wiki.apache.org/myfaces/Secure_Your_Application
<context-param>
<param-name>org.apache.myfaces.SECRET</param-name>
<param-value>MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIz</param-value>
</context-param> <context-param>
<param-name>org.apache.myfaces.ALGORITHM</param-name>
<param-value>AES</param-value> </context-param> <context-param>
<param-name>org.apache.myfaces.ALGORITHM.PARAMETERS</param-name>
<param-value>CBC/PKCS5Padding</param-value> </context-param>
<context-param>
<param-name>org.apache.myfaces.ALGORITHM.IV</param-name>
<param-value>NzY1NDMyMTA3NjU0MzIxMA==</param-value>
</context-param>
On Tue, Dec 20, 2016 at 4:34 PM, Moritz Bechler <be...@agno3.eu> wrote:
> Hi,
>
> > Currently we are not in a position to update to 1.1.8 as the change would
> > require a upgrade of legacy software.
> >
> > With just 1.1.5,based on the below, it has been mentioned that it is ok
> to
> > use "Server" for state saving. Based on this, can you clarify that
> > encryption is not required for server state saving.
> >
>
> No, unfortunately this is very unsafe - one should never use myfaces
> with unencrypted ViewState. An attacker can exploit the (useless, as
> it's a simple string) deserialization of a crafted ViewState token that
> MyFaces performs. This is almost certainly exploitable for remote code
> execution (<https://issues.apache.org/jira/browse/MYFACES-4021>).
>
>
> regards
>
> Moritz
>
> --
> AgNO3 GmbH & Co. KG, Sitz Tübingen, Amtsgericht Stuttgart HRA 728731
> Persönlich haftend:
> Metagesellschaft mbH, Sitz Tübingen, Amtsgericht Stuttgart HRB 744820,
> Vertreten durch Joachim Keltsch
>
--
-------------------------
Thanks & Regards
Karthik.K.N
Re: Reg vulnerability for Server State saving
Posted by Moritz Bechler <be...@agno3.eu>.
Hi,
> Currently we are not in a position to update to 1.1.8 as the change would
> require a upgrade of legacy software.
>
> With just 1.1.5,based on the below, it has been mentioned that it is ok to
> use "Server" for state saving. Based on this, can you clarify that
> encryption is not required for server state saving.
>
No, unfortunately this is very unsafe - one should never use myfaces
with unencrypted ViewState. An attacker can exploit the (useless, as
it's a simple string) deserialization of a crafted ViewState token that
MyFaces performs. This is almost certainly exploitable for remote code
execution (<https://issues.apache.org/jira/browse/MYFACES-4021>).
regards
Moritz
--
AgNO3 GmbH & Co. KG, Sitz T�bingen, Amtsgericht Stuttgart HRA 728731
Pers�nlich haftend:
Metagesellschaft mbH, Sitz T�bingen, Amtsgericht Stuttgart HRB 744820,
Vertreten durch Joachim Keltsch
Re: Reg vulnerability for Server State saving
Posted by karthik kn <ke...@gmail.com>.
Hi,
Currently we are not in a position to update to 1.1.8 as the change would
require a upgrade of legacy software.
With just 1.1.5,based on the below, it has been mentioned that it is ok to
use "Server" for state saving. Based on this, can you clarify that
encryption is not required for server state saving.
However, in the wiki I see the following
Security configuration for Myfaces Core 1.1.7, 1.2.8, 2.0.0 and earlier
When using client side state saving, the UI object model is serialized and
rendered with the response. This is behavior controlled by the following
context parameter.
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value> </context-param>
One consequence of client side state saving is that anyone with a decoder
and some time to kill can reconstruct the UI object model on the client
side. This can be a problem for those of us who make use of the excellent
t:saveState <http://myfaces.apache.org/tomahawk/uiSaveState.html> tag.
*Users of myfaces core version 1.1.7, 1.2.8, 2.0.0 and earlier MUST use
server side state saving instead to prevent padding oracle attack on view
state.*
Enabling encryption is as easy as putting the following context parameter
in your deployment descriptor. There are two things to note here. First,
this uses the default encryption algorithm, DES
<http://www.itl.nist.gov/fipspubs/fip46-2.htm>, so the secret must have a
size of eight. Second, although the secret is actually "76543210", we do
not put this directly in the deployment descriptor. Instead, we place it's
base 64 encoded value. This annoying extra step in the process is required
so that secrets are not limited to printable character values.
On Mon, Dec 19, 2016 at 10:05 PM, Leonardo Uribe <lu...@gmail.com> wrote:
> Hi
>
> 1.1.5 is too old. Please update to 1.1.8 or upper versions.
>
> See https://wiki.apache.org/myfaces/Secure_Your_Application for details.
>
> regards,
>
> Leonardo Uribe
>
> 2016-12-19 5:44 GMT-05:00 karthik kn <ke...@gmail.com>:
>
> > Hi,
> > I am using myfaces-1.1.5 and using the following state saving method
> >
> > <context-param><param-name>javax.faces.STATE_SAVING_
> > METHOD</param-name><param-value>server</param-value></context-param>
> >
> > However,i see that the object identifier is being sent to the server as
> > following
> >
> > <input type="hidden" name="javax.faces.ViewState"
> > id="javax.faces.ViewState"
> > value="rO0ABXVyABNbTGphdmEubGFuZy5PYmplY3Q7kM5YnxBzKWwCAAB4cAAAAAN0
> > AAEzcHQAJi9qc3AvaGxyL2FjX3N1YnNjcmliZXIvY3J0U2luZ2xlQUMuanNw"
> > /></form>
> >
> > This is the serialized object identifier sent over the network
> >
> > We are using only https and not http.
> >
> > Does sending this serialized object identifier without encrypting open
> any
> > vulnerability which the attacker could use to his/her advantage ?
> >
> > --
> > -------------------------
> > Thanks & Regards
> >
> > Karthik.K.N
> >
>
--
-------------------------
Thanks & Regards
Karthik.K.N
Re: Reg vulnerability for Server State saving
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
1.1.5 is too old. Please update to 1.1.8 or upper versions.
See https://wiki.apache.org/myfaces/Secure_Your_Application for details.
regards,
Leonardo Uribe
2016-12-19 5:44 GMT-05:00 karthik kn <ke...@gmail.com>:
> Hi,
> I am using myfaces-1.1.5 and using the following state saving method
>
> <context-param><param-name>javax.faces.STATE_SAVING_
> METHOD</param-name><param-value>server</param-value></context-param>
>
> However,i see that the object identifier is being sent to the server as
> following
>
> <input type="hidden" name="javax.faces.ViewState"
> id="javax.faces.ViewState"
> value="rO0ABXVyABNbTGphdmEubGFuZy5PYmplY3Q7kM5YnxBzKWwCAAB4cAAAAAN0
> AAEzcHQAJi9qc3AvaGxyL2FjX3N1YnNjcmliZXIvY3J0U2luZ2xlQUMuanNw"
> /></form>
>
> This is the serialized object identifier sent over the network
>
> We are using only https and not http.
>
> Does sending this serialized object identifier without encrypting open any
> vulnerability which the attacker could use to his/her advantage ?
>
> --
> -------------------------
> Thanks & Regards
>
> Karthik.K.N
>