4

My web server is returning a 200 OK after submitting a POST request, but it does not seem to be a good idea according to a security team.

It should return a 302 "Object Moved", so that it avoids caching sensitive information.

"If a form posts sensitive data through a POST request, the server should return 302 "Object Moved" response, to redirect users to a different page. This avoids caching sensitive information"

To me returning HTTP status code is really up to the web application and the framework it is using and how it is designed.

Not sure if every POST request should result in 302. If I log into a website instead of doing redirect it is returning 200 OK.

As long as it is doing it through POST request over SSL I am not seeing problem with it. Can you guys enlighten me on this?

Improve this question
7
  • Are you concerned with caching of the POST response data or of the form that was filled in for the POST?
    – Neil Smithline
    Commented Oct 15, 2015 at 20:10
  • "The application does not prevent caching of confidential information. Upon submitting a form, it is possible to hit the back button in the browser, then the refresh button to view the information that was submitted." This is what they said. To me that sounds like the request. I am not sure.
    – DoodleKana
    Commented Oct 15, 2015 at 20:15
  • Hard to respond to the question without understanding exactly what is being attempted. Have you tried a quick mock-up to see how browsers behave? Perhaps you could use that to prove or disprove the security team's idea.
    – Neil Smithline
    Commented Oct 15, 2015 at 20:19
  • 2
    That's not actually the request, that's the browser cacheing of input fields, which is a third kettle of fish yet. You can gently suggest the browser not remember those fields using autocomplete flag in the form or field definitions. However, whether the browser actually listens or not is another question - it's complex, and the answer is "don't depend on it."
    – gowenfawr
    Commented Oct 15, 2015 at 20:21
  • 1
    Using a redirect after post prevents duplicate submissions, but won't prevent the browser from remembering field values.
    – Lie Ryan
    Commented Mar 11, 2017 at 0:01

5 Answers 5

Reset to default
4

The question appeared to deal with the HTTP Response method chosen, and it's impact on caching. See "POST Caching" below for the answer to that question.

Clarifications by the OP in comments suggest that the security team is concerned with the browser remembering values entered into field forms, such that they're accessible to 'back' or 'autocomplete' usage. That is completely unrelated to the HTTP response that the server chooses to issue; even if a redirect is used, that just increases the number of 'back' clicks necessary to return to the information.

The HTML form autocomplete attribute and HTML input autocomplete attribute are used to request that the browser not remember the values entered. However, these are requests, not prohibitions. Browsers can do whatever they want, and have been known to ignore or misinterpret these tags, and to exempt anything they find interesting from being subject to them. Chrome, for example, has had this thing where "off" doesn't work but "false" does.

So - there's things you can do to help it, but not to control it. And a 302 instead of a 200 isn't one of them.

POST Caching

A POST with a 200 response will not be cached unless additional HTTP headers in the response specifically request it. See Is it possible to cache POST methods in HTTP? from StackOverflow; to quote their quote of RFC 2616:

9.5 POST

...

Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields. However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource.

Your security team had a good thought, but failed to ask if the architects of HTTP managed to have the same good thought first.

In practical terms, this is why your browser prompts you when you try to reload a page that was the response to a POST form submission - it tells you the request will be retransmitted to the server, because the browser did not cache the original response.

IE resubmission warning

Improve this answer
5
  • I think @DoodleKana means caching of the POST request.
    – Zonk
    Commented Oct 15, 2015 at 19:51
  • 3
    @Zonk, At the point he's describing possibly using a 302 instead of a 200, he's talking about the response, not the request. Requests don't get numbers :).
    – gowenfawr
    Commented Oct 15, 2015 at 19:52
  • @Zonk and gowenfawr - see recent response on the OP - it's unlcear which is being talked about but likely the request.
    – Neil Smithline
    Commented Oct 15, 2015 at 20:18
  • @gowenfawr Ok if I am understanding this correctly, as long as the response header to POST has no-cache it does not matter whether the response is 200 or 302 since RFC said it will not be cached if it is not 303 or header has caching allowed. Am I right?
    – DoodleKana
    Commented Oct 15, 2015 at 21:37
  • @DoodleKana Correct, the HTTP status code is irrelevant. There is a distinction between Post data and form field data. Post payload is not cached but form field data can be cached. To prevent form field data from being cached, please refer to stackoverflow.com/questions/2699284/…
    – k1DBLITZ
    Commented Oct 16, 2015 at 19:29
1

I have heard of the issue and yes this is something you can observe at many web applications using live HTTP header extension. They do in fact return 302 instead of 200 as status code. However, there are also other controls that should be used in combination, the HTTP cache-control headers.

Regarding SSL; You are right when you refer to the point that there is no additional risk in observing the credentials in transit. The issue that this solution solves is at an earlier stage - the browser itself. There was a time where you could logout of a web application and hit the return button to re-login. This even worked, if the web application destroyed the session, because the browser cache contained the authentication credentials and re-authenticated. Therefore the problem this solves is that none using the browser can authenticate with previously used and cached credentials.

Improve this answer
1

A redirect to a different site does not make the browser forget the data entered into the form. If you go back in history then they can still be resubmitted. Trying to "clear" the browser from sensitive data is probably questionable anyway, since the attacker would need to be deep inside the browser to get access to these data and in this case (s)he could have captured the data already when they were entered into the page or sent to the server, which probably needs less effort.

Improve this answer
1

It is my understanding that the finding reported by the security team is valid. Lets walk through the scenario they likely reported as I too have seen this on manual application assessments.

Scenario 1: Take for example the login page of an application, or better yet, a credit card application form. After all of the form fields are filled out and the 'Submit' button clicked, the client sends that sensitive data in a POST request to the server. If the server response is a '200 OK' the browser will keep the POST data in browser memory allowing for replay attacks. As stated in an earlier response, one could hit the 'back' button, then 'Forward', and then 'Refresh' in which the browser will resend the sensitive POST data again. You will often receive a pop-up message from your browser letting you know that it is about to resend data previously sent.

Scenario 2: The same data is sent via a POST request to the server. This time, the server responds back with some 300-type status code, likely a 302 redirect which sends the client to whatever the next page is. The client browser however having received a 300-type response does NOT maintain or cache the POST'ed data in browser memory. You CANNOT repeat the back, forward, refresh experiment and hope to see the previously POST'ed data replayed. This is all dependent on the server response.

You can test this for yourself if you have access to a local proxy such as Burp. Set up the browser to point to your proxy. Access the vulnerable web page. Fill out the fields, hit submit, and look at the request that was send in your proxy tool. You should see the various form fields containing sensitive data in the data section of the POST request. Assuming the server response was a '200 OK' move to the next step. On the browser, hit the back button, then forward, then refresh. You should get the pop up message from your browser alerting you its about to resend previously sent data. Hit OK. Now look at that last request in your proxy tool. It will have resent the POST request and the same sensitive data from earlier. NOW, try this same experiment on a website that returns 302 redirects to POST'ed data. You will NOT be able to get the browser to replay the posted data.

So, whats the risk or threat you may ask? First and foremost are replay attacks. Your biggest concern should be malware. Your second biggest threat vector would be a shared device. The concern is that either malware or a person with access to the device could 'replay' the request and then be able to see the sensitive data that was sent in the POST request. Malware will just read the data straight out of browser memory. A person would have to use a tool to see the POST request again.

***A few caveats:

*Using Autocomplete=off only prevents data from being stored in form field storage containers. It is independent of and has no bearing on this issue. I would suggest however ensuring that any form fields accepting sensitive information should have autocomplete set to 'off'. Malware frequently looks for and reads saved form field data as it usually contains juicy info.

**Using cache-control headers also has no bearing on this issue as that is for pages that are cached to disk (temp internet directories). Again, you should utilize cache-control directives and prevent sensitive data from being stored in clear text on your system.

*** '200 OK' response on data POST'ed in a json request is a non-issue. Its about the only scenario off the top of my head that I can think of where you can't perform the replay attack when the server responds back with a '200 OK'.

Hope this helps. I'm sure its not listed as a high rated vulnerability due to the limitations of the attack vector. Its just 1 of countless layers in the security onion though!

Improve this answer
0

As other answers have stated, replying to a POST with a redirect will not do anything to prevent the form contents from being remembered. However, it does solve a different problem - if the server responds with a 200 "OK", then the user clicks a link on the page and then clicks the back button, the browser may silently resubmit the entire form. If the server replied to the POST with a redirect, then this won't happen (the browser will reload the page that it was redirected to instead).

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .