[
https://issues.apache.org/jira/browse/PLUTO-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Neil Griffin closed PLUTO-768.
------------------------------
Resolution: Fixed
Fixed in commit
[c4fe79759f189de8694a9369743ef44d9aee07ec|https://github.com/apache/portals-pluto/commit/c4fe79759f189de8694a9369743ef44d9aee07ec]
> Introduce CSRF protection for the ACTION_PHASE via Spring Security
> ------------------------------------------------------------------
>
> Key: PLUTO-768
> URL: https://issues.apache.org/jira/browse/PLUTO-768
> Project: Pluto
> Issue Type: New Feature
> Components: portal driver, portlet container
> Reporter: Neil Griffin
> Assignee: Neil Griffin
> Priority: Major
> Fix For: 3.0.2
>
>
> This feature will add Cross-Site Request Forgery
> [CSRF|https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)]
> protection for the {{ACTION_PHASE}} of the portlet lifecycle via Spring
> Security.
> Specifically, it will ensure that the Spring Security {{_csrf}} parameter is
> added to every {{javax.portlet.ActionURL}} generated by Pluto's portlet
> container. It will also utilize the "springSecurityFilterChain" in order to
> verify that the value of the {{_csrf}} parameter is the correct value before
> invoking the {{ACTION_PHASE}} of the portlet lifecycle.
> This feature does *not* secure any other phases of the portlet lifecycle
> (such as the {{RESOURCE_PHASE}}). It is important to note that if a portlet
> developer uses an XmlHttpRequest (XHR) to submit a form via HTTP POST with a
> {{javax.portlet.ResourceURL}}, then it is still incumbent upon the portlet
> developer to leverage some kind of CSRF protection.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
