[JBoss JIRA] Created: (SEAMFACES-26) Implement global protection against XSRF attacks via incremental token-based form fields
5:41 p.m.
Implement global protection against XSRF attacks via incremental token-based form fields
----------------------------------------------------------------------------------------
Key: SEAMFACES-26
URL: https://jira.jboss.org/browse/SEAMFACES-26
Project: Seam Faces
Issue Type: Feature Request
Components: Security
Reporter: Lincoln Baxter III
Fix For: 3.0.0.Alpha4
I'd like to see a way to implement this for ALL pages, not requiring a custom tag.
I believe this could be done easily using the PreRenderViewEvent to add a hidden form
field to store the token in all outbound forms, in combination with a cookie that is sent
to the browser, storing a unique private key for that browser session.
Next, use a phase-listener after Restore_View, comparing the request parameter to the
restored component value or session. Very similar to the <s:token> component, but as
a global solution that could be enabled/disabled via XML config.
The token value increments on each subsequent form submission, and includes a hashed
version of the browser's signature (and corresponding public key for the browser's
cookie-assigned private key.) The token is compared to either a value stored in ViewState
(insecure if using client-side state-saving) or a value stored in the user's session
as (an ordered list that can detect repeat or invalid requests.)
Question: how does this affect the back-button?
Note: In order for any cookie-based public key to be assigned to the browser, one MUST
assume that the server/client are speaking HTTPS, otherwise any communication of
public/private keys will be vulnerable to man-in-the-middle attacks.
"1. When rendered, it assigns a unique identifier to the browser using a cookie that
lives until the end of the browser session. This is roughly the browser's private key.
The <s:token> tag is used inside of an <h:form> and generates a hidden form
field named javax.faces.FormSignature. The form signature is calculated as follows:
"
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:41 p.m.
New subject: [JBoss JIRA] Commented: (SEAMFACES-26) Implement global protection against XSRF attacks via incremental token-based form fields
[
https://jira.jboss.org/browse/SEAMFACES-26?page=com.atlassian.jira.plugin...
]
Lincoln Baxter III commented on SEAMFACES-26:
---------------------------------------------
Details of the initial implementation:
http://seamframework.org/Documentation/CrossSiteRequestForgery
Calling for a global solution:
http://seamframework.org/Community/NewComponentTagStokenAimedToGuardAgain...
Implement global protection against XSRF attacks via incremental
token-based form fields
----------------------------------------------------------------------------------------
Key: SEAMFACES-26
URL: https://jira.jboss.org/browse/SEAMFACES-26
Project: Seam Faces
Issue Type: Feature Request
Components: Security
Reporter: Lincoln Baxter III
Fix For: 3.0.0.Alpha4
I'd like to see a way to implement this for ALL pages, not requiring a custom tag.
I believe this could be done easily using the PreRenderViewEvent to add a hidden form
field to store the token in all outbound forms, in combination with a cookie that is sent
to the browser, storing a unique private key for that browser session.
Next, use a phase-listener after Restore_View, comparing the request parameter to the
restored component value or session. Very similar to the <s:token> component, but as
a global solution that could be enabled/disabled via XML config.
The token value increments on each subsequent form submission, and includes a hashed
version of the browser's signature (and corresponding public key for the browser's
cookie-assigned private key.) The token is compared to either a value stored in ViewState
(insecure if using client-side state-saving) or a value stored in the user's session
as (an ordered list that can detect repeat or invalid requests.)
Question: how does this affect the back-button?
Note: In order for any cookie-based public key to be assigned to the browser, one MUST
assume that the server/client are speaking HTTPS, otherwise any communication of
public/private keys will be vulnerable to man-in-the-middle attacks.
"1. When rendered, it assigns a unique identifier to the browser using a cookie that
lives until the end of the browser session. This is roughly the browser's private key.
The <s:token> tag is used inside of an <h:form> and generates a hidden form
field named javax.faces.FormSignature. The form signature is calculated as follows: "
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:15 p.m.
New subject: [JBoss JIRA] Commented: (SEAMFACES-26) Implement global protection against XSRF attacks via incremental token-based form fields
[
https://jira.jboss.org/browse/SEAMFACES-26?page=com.atlassian.jira.plugin...
]
Dan Allen commented on SEAMFACES-26:
------------------------------------
Please refer to the implementation from Seam 2, the logic from which we can port to Seam
3
http://anonsvn.jboss.org/repos/seam/branches/community/Seam_2_2/ui/src/ma...
http://anonsvn.jboss.org/repos/seam/branches/community/Seam_2_2/ui/src/ma...
http://anonsvn.jboss.org/repos/seam/branches/community/Seam_2_2/ui/src/ma...
http://anonsvn.jboss.org/repos/seam/branches/community/Seam_2_2/src/main/...
Implement global protection against XSRF attacks via incremental
token-based form fields
----------------------------------------------------------------------------------------
Key: SEAMFACES-26
URL: https://jira.jboss.org/browse/SEAMFACES-26
Project: Seam Faces
Issue Type: Feature Request
Components: Security
Reporter: Lincoln Baxter III
Fix For: 3.0.0.Alpha4
I'd like to see a way to implement this for ALL pages, not requiring a custom tag.
I believe this could be done easily using the PreRenderViewEvent to add a hidden form
field to store the token in all outbound forms, in combination with a cookie that is sent
to the browser, storing a unique private key for that browser session.
Next, use a phase-listener after Restore_View, comparing the request parameter to the
restored component value or session. Very similar to the <s:token> component, but as
a global solution that could be enabled/disabled via XML config.
The token value increments on each subsequent form submission, and includes a hashed
version of the browser's signature (and corresponding public key for the browser's
cookie-assigned private key.) The token is compared to either a value stored in ViewState
(insecure if using client-side state-saving) or a value stored in the user's session
as (an ordered list that can detect repeat or invalid requests.)
Question: how does this affect the back-button?
Note: In order for any cookie-based public key to be assigned to the browser, one MUST
assume that the server/client are speaking HTTPS, otherwise any communication of
public/private keys will be vulnerable to man-in-the-middle attacks.
"1. When rendered, it assigns a unique identifier to the browser using a cookie that
lives until the end of the browser session. This is roughly the browser's private key.
The <s:token> tag is used inside of an <h:form> and generates a hidden form
field named javax.faces.FormSignature. The form signature is calculated as follows: "
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:02 a.m.
New subject: [JBoss JIRA] Updated: (SEAMFACES-26) Implement global protection against XSRF attacks via incremental token-based form fields
[
https://issues.jboss.org/browse/SEAMFACES-26?page=com.atlassian.jira.plug...
]
Shane Bryzak updated SEAMFACES-26:
----------------------------------
Fix Version/s: 3.0.0.Beta3
(was: 3.0.0.Beta1)
Implement global protection against XSRF attacks via incremental
token-based form fields
----------------------------------------------------------------------------------------
Key: SEAMFACES-26
URL: https://issues.jboss.org/browse/SEAMFACES-26
Project: Seam Faces
Issue Type: Feature Request
Components: Security
Reporter: Lincoln Baxter III
Fix For: 3.0.0.Beta3
I'd like to see a way to implement this for ALL pages, not requiring a custom tag.
I believe this could be done easily using the PreRenderViewEvent to add a hidden form
field to store the token in all outbound forms, in combination with a cookie that is sent
to the browser, storing a unique private key for that browser session.
Next, use a phase-listener after Restore_View, comparing the request parameter to the
restored component value or session. Very similar to the <s:token> component, but as
a global solution that could be enabled/disabled via XML config.
The token value increments on each subsequent form submission, and includes a hashed
version of the browser's signature (and corresponding public key for the browser's
cookie-assigned private key.) The token is compared to either a value stored in ViewState
(insecure if using client-side state-saving) or a value stored in the user's session
as (an ordered list that can detect repeat or invalid requests.)
Question: how does this affect the back-button?
Note: In order for any cookie-based public key to be assigned to the browser, one MUST
assume that the server/client are speaking HTTPS, otherwise any communication of
public/private keys will be vulnerable to man-in-the-middle attacks.
"1. When rendered, it assigns a unique identifier to the browser using a cookie that
lives until the end of the browser session. This is roughly the browser's private key.
The <s:token> tag is used inside of an <h:form> and generates a hidden form
field named javax.faces.FormSignature. The form signature is calculated as follows: "
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:08 a.m.
New subject: [JBoss JIRA] Commented: (SEAMFACES-26) Implement global protection against XSRF attacks via incremental token-based form fields
[
https://issues.jboss.org/browse/SEAMFACES-26?page=com.atlassian.jira.plug...
]
Brian Leathem commented on SEAMFACES-26:
----------------------------------------
Should we perhaps provide both a custom tag, and a global xml-configured solution? That
way a developer can selectively include the XSRF protection using the custon tag, or they
can turn it on globally with the xml config.
Implement global protection against XSRF attacks via incremental
token-based form fields
----------------------------------------------------------------------------------------
Key: SEAMFACES-26
URL: https://issues.jboss.org/browse/SEAMFACES-26
Project: Seam Faces
Issue Type: Feature Request
Components: Security
Reporter: Lincoln Baxter III
Fix For: 3.0.0.Beta3
I'd like to see a way to implement this for ALL pages, not requiring a custom tag.
I believe this could be done easily using the PreRenderViewEvent to add a hidden form
field to store the token in all outbound forms, in combination with a cookie that is sent
to the browser, storing a unique private key for that browser session.
Next, use a phase-listener after Restore_View, comparing the request parameter to the
restored component value or session. Very similar to the <s:token> component, but as
a global solution that could be enabled/disabled via XML config.
The token value increments on each subsequent form submission, and includes a hashed
version of the browser's signature (and corresponding public key for the browser's
cookie-assigned private key.) The token is compared to either a value stored in ViewState
(insecure if using client-side state-saving) or a value stored in the user's session
as (an ordered list that can detect repeat or invalid requests.)
Question: how does this affect the back-button?
Note: In order for any cookie-based public key to be assigned to the browser, one MUST
assume that the server/client are speaking HTTPS, otherwise any communication of
public/private keys will be vulnerable to man-in-the-middle attacks.
"1. When rendered, it assigns a unique identifier to the browser using a cookie that
lives until the end of the browser session. This is roughly the browser's private key.
The <s:token> tag is used inside of an <h:form> and generates a hidden form
field named javax.faces.FormSignature. The form signature is calculated as follows: "
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:33 a.m.
New subject: [JBoss JIRA] Updated: (SEAMFACES-26) Implement global protection against XSRF attacks via incremental token-based form fields
[
https://issues.jboss.org/browse/SEAMFACES-26?page=com.atlassian.jira.plug...
]
Brian Leathem updated SEAMFACES-26:
-----------------------------------
Fix Version/s: 3.0.0.CR1
(was: 3.0.0.Beta3)
Implement global protection against XSRF attacks via incremental
token-based form fields
----------------------------------------------------------------------------------------
Key: SEAMFACES-26
URL: https://issues.jboss.org/browse/SEAMFACES-26
Project: Seam Faces
Issue Type: Feature Request
Components: Security
Reporter: Lincoln Baxter III
Fix For: 3.0.0.CR1
I'd like to see a way to implement this for ALL pages, not requiring a custom tag.
I believe this could be done easily using the PreRenderViewEvent to add a hidden form
field to store the token in all outbound forms, in combination with a cookie that is sent
to the browser, storing a unique private key for that browser session.
Next, use a phase-listener after Restore_View, comparing the request parameter to the
restored component value or session. Very similar to the <s:token> component, but as
a global solution that could be enabled/disabled via XML config.
The token value increments on each subsequent form submission, and includes a hashed
version of the browser's signature (and corresponding public key for the browser's
cookie-assigned private key.) The token is compared to either a value stored in ViewState
(insecure if using client-side state-saving) or a value stored in the user's session
as (an ordered list that can detect repeat or invalid requests.)
Question: how does this affect the back-button?
Note: In order for any cookie-based public key to be assigned to the browser, one MUST
assume that the server/client are speaking HTTPS, otherwise any communication of
public/private keys will be vulnerable to man-in-the-middle attacks.
"1. When rendered, it assigns a unique identifier to the browser using a cookie that
lives until the end of the browser session. This is roughly the browser's private key.
The <s:token> tag is used inside of an <h:form> and generates a hidden form
field named javax.faces.FormSignature. The form signature is calculated as follows: "
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:15 a.m.
New subject: [JBoss JIRA] Commented: (SEAMFACES-26) Implement global protection against XSRF attacks via incremental token-based form fields
[
https://issues.jboss.org/browse/SEAMFACES-26?page=com.atlassian.jira.plug...
]
Dan Allen commented on SEAMFACES-26:
------------------------------------
Also, refer to recent article by Markus that talks more about a solution (though a
separate approach than what we have done).
http://blog.eisele.net/2011/02/preventing-csrf-with-jsf-20.html
Implement global protection against XSRF attacks via incremental
token-based form fields
----------------------------------------------------------------------------------------
Key: SEAMFACES-26
URL: https://issues.jboss.org/browse/SEAMFACES-26
Project: Seam Faces
Issue Type: Feature Request
Components: Security
Reporter: Lincoln Baxter III
Fix For: 3.0.1
I'd like to see a way to implement this for ALL pages, not requiring a custom tag.
I believe this could be done easily using the PreRenderViewEvent to add a hidden form
field to store the token in all outbound forms, in combination with a cookie that is sent
to the browser, storing a unique private key for that browser session.
Next, use a phase-listener after Restore_View, comparing the request parameter to the
restored component value or session. Very similar to the <s:token> component, but as
a global solution that could be enabled/disabled via XML config.
The token value increments on each subsequent form submission, and includes a hashed
version of the browser's signature (and corresponding public key for the browser's
cookie-assigned private key.) The token is compared to either a value stored in ViewState
(insecure if using client-side state-saving) or a value stored in the user's session
as (an ordered list that can detect repeat or invalid requests.)
Question: how does this affect the back-button?
Note: In order for any cookie-based public key to be assigned to the browser, one MUST
assume that the server/client are speaking HTTPS, otherwise any communication of
public/private keys will be vulnerable to man-in-the-middle attacks.
"1. When rendered, it assigns a unique identifier to the browser using a cookie that
lives until the end of the browser session. This is roughly the browser's private key.
The <s:token> tag is used inside of an <h:form> and generates a hidden form
field named javax.faces.FormSignature. The form signature is calculated as follows: "
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:15 a.m.
New subject: [JBoss JIRA] Updated: (SEAMFACES-26) Implement global protection against XSRF attacks via incremental token-based form fields
[
https://issues.jboss.org/browse/SEAMFACES-26?page=com.atlassian.jira.plug...
]
Dan Allen updated SEAMFACES-26:
-------------------------------
Assignee: Brian Leathem
Implement global protection against XSRF attacks via incremental
token-based form fields
----------------------------------------------------------------------------------------
Key: SEAMFACES-26
URL: https://issues.jboss.org/browse/SEAMFACES-26
Project: Seam Faces
Issue Type: Feature Request
Components: Security
Reporter: Lincoln Baxter III
Assignee: Brian Leathem
Fix For: 3.0.1
I'd like to see a way to implement this for ALL pages, not requiring a custom tag.
I believe this could be done easily using the PreRenderViewEvent to add a hidden form
field to store the token in all outbound forms, in combination with a cookie that is sent
to the browser, storing a unique private key for that browser session.
Next, use a phase-listener after Restore_View, comparing the request parameter to the
restored component value or session. Very similar to the <s:token> component, but as
a global solution that could be enabled/disabled via XML config.
The token value increments on each subsequent form submission, and includes a hashed
version of the browser's signature (and corresponding public key for the browser's
cookie-assigned private key.) The token is compared to either a value stored in ViewState
(insecure if using client-side state-saving) or a value stored in the user's session
as (an ordered list that can detect repeat or invalid requests.)
Question: how does this affect the back-button?
Note: In order for any cookie-based public key to be assigned to the browser, one MUST
assume that the server/client are speaking HTTPS, otherwise any communication of
public/private keys will be vulnerable to man-in-the-middle attacks.
"1. When rendered, it assigns a unique identifier to the browser using a cookie that
lives until the end of the browser session. This is roughly the browser's private key.
The <s:token> tag is used inside of an <h:form> and generates a hidden form
field named javax.faces.FormSignature. The form signature is calculated as follows: "
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:35 p.m.
New subject: [JBoss JIRA] Commented: (SEAMFACES-26) Implement global protection against XSRF attacks via incremental token-based form fields
[
https://issues.jboss.org/browse/SEAMFACES-26?page=com.atlassian.jira.plug...
]
Brian Leathem commented on SEAMFACES-26:
----------------------------------------
We could have global XSRF protection on by default, and allow application developers to
selectively disable it using a ViewConfig annotation.
Implement global protection against XSRF attacks via incremental
token-based form fields
----------------------------------------------------------------------------------------
Key: SEAMFACES-26
URL: https://issues.jboss.org/browse/SEAMFACES-26
Project: Seam Faces
Issue Type: Feature Request
Components: Security
Reporter: Lincoln Baxter III
Assignee: Brian Leathem
Fix For: 3.0.1
I'd like to see a way to implement this for ALL pages, not requiring a custom tag.
I believe this could be done easily using the PreRenderViewEvent to add a hidden form
field to store the token in all outbound forms, in combination with a cookie that is sent
to the browser, storing a unique private key for that browser session.
Next, use a phase-listener after Restore_View, comparing the request parameter to the
restored component value or session. Very similar to the <s:token> component, but as
a global solution that could be enabled/disabled via XML config.
The token value increments on each subsequent form submission, and includes a hashed
version of the browser's signature (and corresponding public key for the browser's
cookie-assigned private key.) The token is compared to either a value stored in ViewState
(insecure if using client-side state-saving) or a value stored in the user's session
as (an ordered list that can detect repeat or invalid requests.)
Question: how does this affect the back-button?
Note: In order for any cookie-based public key to be assigned to the browser, one MUST
assume that the server/client are speaking HTTPS, otherwise any communication of
public/private keys will be vulnerable to man-in-the-middle attacks.
"1. When rendered, it assigns a unique identifier to the browser using a cookie that
lives until the end of the browser session. This is roughly the browser's private key.
The <s:token> tag is used inside of an <h:form> and generates a hidden form
field named javax.faces.FormSignature. The form signature is calculated as follows: "
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:43 p.m.
New subject: [JBoss JIRA] Commented: (SEAMFACES-26) Implement global protection against XSRF attacks via incremental token-based form fields
[
https://issues.jboss.org/browse/SEAMFACES-26?page=com.atlassian.jira.plug...
]
Dan Allen commented on SEAMFACES-26:
------------------------------------
I like it!
Implement global protection against XSRF attacks via incremental
token-based form fields
----------------------------------------------------------------------------------------
Key: SEAMFACES-26
URL: https://issues.jboss.org/browse/SEAMFACES-26
Project: Seam Faces
Issue Type: Feature Request
Components: Security
Reporter: Lincoln Baxter III
Assignee: Brian Leathem
Fix For: 3.0.1
I'd like to see a way to implement this for ALL pages, not requiring a custom tag.
I believe this could be done easily using the PreRenderViewEvent to add a hidden form
field to store the token in all outbound forms, in combination with a cookie that is sent
to the browser, storing a unique private key for that browser session.
Next, use a phase-listener after Restore_View, comparing the request parameter to the
restored component value or session. Very similar to the <s:token> component, but as
a global solution that could be enabled/disabled via XML config.
The token value increments on each subsequent form submission, and includes a hashed
version of the browser's signature (and corresponding public key for the browser's
cookie-assigned private key.) The token is compared to either a value stored in ViewState
(insecure if using client-side state-saving) or a value stored in the user's session
as (an ordered list that can detect repeat or invalid requests.)
Question: how does this affect the back-button?
Note: In order for any cookie-based public key to be assigned to the browser, one MUST
assume that the server/client are speaking HTTPS, otherwise any communication of
public/private keys will be vulnerable to man-in-the-middle attacks.
"1. When rendered, it assigns a unique identifier to the browser using a cookie that
lives until the end of the browser session. This is roughly the browser's private key.
The <s:token> tag is used inside of an <h:form> and generates a hidden form
field named javax.faces.FormSignature. The form signature is calculated as follows: "
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:55 p.m.
New subject: [JBoss JIRA] Updated: (SEAMFACES-26) Implement global protection against XSRF attacks via incremental token-based form fields
[
https://issues.jboss.org/browse/SEAMFACES-26?page=com.atlassian.jira.plug...
]
Brian Leathem updated SEAMFACES-26:
-----------------------------------
Component/s: View Configuration
Implement global protection against XSRF attacks via incremental
token-based form fields
----------------------------------------------------------------------------------------
Key: SEAMFACES-26
URL: https://issues.jboss.org/browse/SEAMFACES-26
Project: Seam Faces
Issue Type: Feature Request
Components: Security, View Configuration
Reporter: Lincoln Baxter III
Assignee: Brian Leathem
Fix For: 3.0.1
I'd like to see a way to implement this for ALL pages, not requiring a custom tag.
I believe this could be done easily using the PreRenderViewEvent to add a hidden form
field to store the token in all outbound forms, in combination with a cookie that is sent
to the browser, storing a unique private key for that browser session.
Next, use a phase-listener after Restore_View, comparing the request parameter to the
restored component value or session. Very similar to the <s:token> component, but as
a global solution that could be enabled/disabled via XML config.
The token value increments on each subsequent form submission, and includes a hashed
version of the browser's signature (and corresponding public key for the browser's
cookie-assigned private key.) The token is compared to either a value stored in ViewState
(insecure if using client-side state-saving) or a value stored in the user's session
as (an ordered list that can detect repeat or invalid requests.)
Question: how does this affect the back-button?
Note: In order for any cookie-based public key to be assigned to the browser, one MUST
assume that the server/client are speaking HTTPS, otherwise any communication of
public/private keys will be vulnerable to man-in-the-middle attacks.
"1. When rendered, it assigns a unique identifier to the browser using a cookie that
lives until the end of the browser session. This is roughly the browser's private key.
The <s:token> tag is used inside of an <h:form> and generates a hidden form
field named javax.faces.FormSignature. The form signature is calculated as follows: "
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4847
days inactive
5137
days old
10 comments
4 participants
participants (4)
-
Brian Leathem (JIRA) -
Dan Allen (JIRA)
-
Lincoln Baxter III (JIRA)
-
Shane Bryzak (JIRA)