[ 
https://issues.apache.org/jira/browse/SLING-5824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15370355#comment-15370355
 ] 

Amit Gupta commented on SLING-5824:
-----------------------------------

>so for the GETs you're bypassing the protection
No. Current Mechanism for Search does not bypass protection. In fact, when it 
start using POST instead of GET, then it needs to follow rules for CSRF i.e. 
pass a csrf token along side. For GET it is not needed.

If a POST can be tunneled as GET, then you open the door for CSRF protection 
bypass. But not if you only allow GET to be tunneled as POST. 

> Servlet Filter to do POST tunnelling to GET
> -------------------------------------------
>
>                 Key: SLING-5824
>                 URL: https://issues.apache.org/jira/browse/SLING-5824
>             Project: Sling
>          Issue Type: Improvement
>          Components: Servlets
>            Reporter: Christanto
>
> Sometimes there is a case where the request URL is very long. For example, 
> during advanced search where there are many fields.
> To accommodate this, the request is tunneled through POST, such that the 
> client do a POST request and then the server convert it to GET, so that the 
> other code in the chain only knows about GET.
> So far the custom POST handler needs to be created specifically for this:
> {code}
> slingRequest.getRequestDispatcher(resource).forward(new 
> HttpServletRequestWrapper(request) {
>     @Override
>     public String getMethod() {
>         return "GET";
>     }
> }, response);
> {code}
> Since this is generic and to avoid creating a custom POST handler every time 
> for this, it makes sense to implement this in Sling using Servlet Filter. For 
> example, a special parameter can be introduced for this purpose named 
> "\_method\_". So the filter will check for this parameter and wrap the 
> request accordingly (also remove the "\_method\_"). This is similar to 
> "\_charset\_" parameter for encoding.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to