[JIRA] Created: (STS-918) All parameters encrypted/decrypted with the same secret

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[JIRA] Created: (STS-918) All parameters encrypted/decrypted with the same secret

JIRA jira@stripesframework.org
All parameters encrypted/decrypted with the same secret
-------------------------------------------------------

                 Key: STS-918
                 URL: http://www.stripesframework.org/jira/browse/STS-918
             Project: Stripes
          Issue Type: Bug
            Reporter: Xiaoyong Wu


Hi,
I have been looking at the stripes framework and specifically on CryptoUtil class usage. It looks to me that all the parameters as encrypted/decrypted with the same secret, such as "s:password" repopulation, "__fp", "_sourcePage" internal parameters. Depending on implementation details on different sites, this makes the sites vulnerable to replay attack, such as copying encrypted password to "__fp", copying a known redirect resolution page to "_sourcePage" and etc.
It would be great if the framework can use different secrets derived from the configured one and use with different parameters, fields and other different intentions

-Xiaoyong

--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Stripes-development mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-development
Reply | Threaded
Open this post in threaded view
|

[JIRA] Resolved: (STS-918) All parameters encrypted/decrypted with the same secret

JIRA jira@stripesframework.org

     [ http://www.stripesframework.org/jira/browse/STS-918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ben Gunter resolved STS-918.
----------------------------

    Resolution: Not a Bug

Encrypted parameters are only intended to assure that a value that is sent to the client is returned to the server unmodified. They also serve the purpose of obscuring things like identifiers that might allow an attacker to guess other identifiers based on a pattern (e.g. a serial column in a database). Thus the security provided by encrypted parameters is that they prevent attackers from injecting values into requests; they do not prevent reuse of valid values.

> All parameters encrypted/decrypted with the same secret
> -------------------------------------------------------
>
>                 Key: STS-918
>                 URL: http://www.stripesframework.org/jira/browse/STS-918
>             Project: Stripes
>          Issue Type: Bug
>            Reporter: Xiaoyong Wu
>
> Hi,
> I have been looking at the stripes framework and specifically on CryptoUtil class usage. It looks to me that all the parameters as encrypted/decrypted with the same secret, such as "s:password" repopulation, "__fp", "_sourcePage" internal parameters. Depending on implementation details on different sites, this makes the sites vulnerable to replay attack, such as copying encrypted password to "__fp", copying a known redirect resolution page to "_sourcePage" and etc.
> It would be great if the framework can use different secrets derived from the configured one and use with different parameters, fields and other different intentions
> -Xiaoyong

--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Stripes-development mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-development
Reply | Threaded
Open this post in threaded view
|

[JIRA] Commented: (STS-918) All parameters encrypted/decrypted with the same secret

JIRA jira@stripesframework.org
In reply to this post by JIRA jira@stripesframework.org

    [ http://www.stripesframework.org/jira/browse/STS-918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13076#comment-13076 ]

Xiaoyong Wu commented on STS-918:
---------------------------------

I am still considering this as a security issue. Let's assume we have a password field that repopulates user password in encrypted format. In that case, the attacker would have control over the encryption and generate forward point he wants. Now, he can try a password as "/WEB-INF/web.xml" which in most cases are not accessible from the server and get an encrypted format "BASE64_ENCRYPTED_WEBXML" and pass that in for "_sourcePage". The getSourcePageResolution() would be happy to forward the request and the attacker has access to the web.xml.


> All parameters encrypted/decrypted with the same secret
> -------------------------------------------------------
>
>                 Key: STS-918
>                 URL: http://www.stripesframework.org/jira/browse/STS-918
>             Project: Stripes
>          Issue Type: Bug
>            Reporter: Xiaoyong Wu
>
> Hi,
> I have been looking at the stripes framework and specifically on CryptoUtil class usage. It looks to me that all the parameters as encrypted/decrypted with the same secret, such as "s:password" repopulation, "__fp", "_sourcePage" internal parameters. Depending on implementation details on different sites, this makes the sites vulnerable to replay attack, such as copying encrypted password to "__fp", copying a known redirect resolution page to "_sourcePage" and etc.
> It would be great if the framework can use different secrets derived from the configured one and use with different parameters, fields and other different intentions
> -Xiaoyong

--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Stripes-development mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-development
Reply | Threaded
Open this post in threaded view
|

[JIRA] Commented: (STS-918) All parameters encrypted/decrypted with the same secret

JIRA jira@stripesframework.org
In reply to this post by JIRA jira@stripesframework.org

    [ http://www.stripesframework.org/jira/browse/STS-918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13077#comment-13077 ]

Ben Gunter commented on STS-918:
--------------------------------

I suppose this might be possible if you encrypt a user-supplied value, which is one reason why you're not supposed to do that. As I stated, the intent is to ensure that a value you that the *server* sends to the *client* gets returned unchanged. You should never encrypt a user-supplied field; the user wouldn't be able to change the value.

More specifically, the scenario you describe wouldn't work for the attacker. If they enter an unencrypted value in a password field that is tied to an encrypted ActionBean property, the server will reject it outright, and it won't be repopulated.

> All parameters encrypted/decrypted with the same secret
> -------------------------------------------------------
>
>                 Key: STS-918
>                 URL: http://www.stripesframework.org/jira/browse/STS-918
>             Project: Stripes
>          Issue Type: Bug
>            Reporter: Xiaoyong Wu
>
> Hi,
> I have been looking at the stripes framework and specifically on CryptoUtil class usage. It looks to me that all the parameters as encrypted/decrypted with the same secret, such as "s:password" repopulation, "__fp", "_sourcePage" internal parameters. Depending on implementation details on different sites, this makes the sites vulnerable to replay attack, such as copying encrypted password to "__fp", copying a known redirect resolution page to "_sourcePage" and etc.
> It would be great if the framework can use different secrets derived from the configured one and use with different parameters, fields and other different intentions
> -Xiaoyong

--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Stripes-development mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-development