SEC-29: Save POST request parameters before redirect about spring-security

[spring-projects-issues]

Ben Alex said:

Switch to 1.0.0, as this change will not affect backward compatibility.

[spring-projects-issues]

Scott McCrory said:

Andrey, just so I understand it right – is this patch to allow an Acegi-protected application to essentially process the original request after it forces the user to reauthenticate? In other words, could you call it “resume after authentication” or something that facilitates “deep linking” into an application?

Thanks,
Scott

[spring-projects-issues]

Andrey Grebnev said:

Scott, YES this patch allows to resume original request (inlcuding simple POST fields) after FORM-based (re)authentication.

[spring-projects-issues]

Scott McCrory said:

Great! I’ll be glad to integrate this one for 1.0.0. End users love this sort of thing, especially when they get interupted in the middle of a several-page wizard series. Good idea Andrey!

[spring-projects-issues]

Scott McCrory said:

Andrey, in SavedRequest.java, you have “FIXME – Currently, this object has no mechanism to save or restore the data content of the request, although it does save request parameters so that a POST transaction can be faithfully duplicated.” Can you summarize the impact of not being able to restore data contents and a recommended resolution for it?
Thanks, Scott

[spring-projects-issues]

Andrey Grebnev said:

Scott, this solution cannot save binary data of uploaded file, it can only save simple string POST parameters On one hand it is badly to lose such type of data. But on the other hand we cannot store it in session because the data can be very big and this solution can open big security problem (overloading by sending big data to restricted resource).

[spring-projects-issues]

Scott McCrory said:

Andrey, OK, understood & thanks. We can leave that for someone else to implement if they need it (one could add a variable limiting the amount of data allowed). In the meanwhile I’ll remove the “FIXME” tag and just comment its limitations. I don’t think many apps would need to support upload resumption after reauthentication anyway. My only concern would be that users might expect auto-resumption across the board.

[spring-projects-issues]

Scott McCrory said:

FYI I merged the code into Acegi’s sandbox package for Ben to review. Looks pretty functional to me, but there might be an opportunity to fold in the FastHttpDateFormat and Enumerator classes since they’ll likely be limited in their reuse.

[spring-projects-issues]

Ben Alex said:

I can see how SecurityEnforcementFilter saves the SavedHttpServletRequest. Except how does that saved request ever get fired again? I don’t see the role of SecurityContextHolderAwareRequestWrapper. Not everyone uses this, so the redirection functionality ideally shouldn’t depend on or require it.

Given this code would modify the way in which requests are processed, I think we should leave this out of 1.0.0 and ensure some unit tests get written that prove the behaviour. I’d also like to see SecurityEnforcementFilter no longer need to store the ACEGI_SECURITY_TARGET_URL_KEY, and instead just store the SavedHttpServletRequest.

[spring-projects-issues]

Matt Raible said:

Is it possible to get this fixed for 1.0? It’s causing issues with Roller and could really upset some folks if they lose their posts.

http://opensource2.atlassian.com/projects/roller/browse/ROL-936

[spring-projects-issues]

Ben Alex said:

I’ll take a look and see if it’s easy to do this for 1.0.0 final. If it blocks the release, I’ll have to postphone it until a later release. We really need unit tests to include features.

[spring-projects-issues]

Ben Alex said:

Refactored and checked into SVN. Tests pass. Also tested with Contacts Sample. For those interested in doing a test:
1. Build the JAR from SVN, build Contacts-filter, and deploy to Tomcat
2. Click “manage” and login
3. Click “add” so you see the new page
4. Right click “home” and “open in a new tab” (assume FireFox)
5. Click “logout” in the newly-opened tab
6. Go back to the first tab and fill in the form, clicking “add”
7. You will be prompted to login, so do that
8. The POST will succeed, and the list of contacts (with your new contact at the bottom) will appear

[spring-projects-issues]

Paul Benedict said:

I see two limitations in the current implementation.
1. Data sent by POST should be re-generated as a POST. Most applications prefer POST for semi-sensitive data because the data is not written into server logs. UrlUtils.buildFullRequestUrl() simply turns this into a GET, which should make some security-minded folks think twice about this approach.
2. Instead of a redirect, there should be an option to forward the saved request. The request intercepted is most likely to do another forward to generate the view after the processing the data. There is no need to redirect in these cases. For those who know this is how their applications are structured, it’s better to just get the request dispatcher and forward the original request along.