My question is on how to preserve data during the redirect when using the PRG Pattern on my forms. Specifically, I’m wanting to use this in an ecommerce application. I have three options of storing the data over the redirect, and I have concerns with each. I’m hoping you guys may be able to help me work through this issue:
1.) Store Data in URL String
I can store the data as an encrypted string passed in the URL. This is great in that I don’t have to store credit card information, but my worry is that (and maybe I’m wrong) Google Analytics might cause the credit card information, though encypted, to be indexed and show up in search results. Hopefully I am wrong in this concern and can use this method, since it’s the easiest.
2.) Store Data in Sessions
I could store the data in a session, but I’m worried some users won’t be able to use sessions because of cookies being disabled, which would limit the usefulness of the application. Additionally, I would be storing encrypted credit card information in the session and PCI Compliance says that I am not allowed to store the CVV under any circumstances.
3.) Store Data in Database
I could store the data in a database, which would solve the compatibility concern I have with sessions — but I’m still left with the problem of not being allowed to store CVV numbers under any circumstances.
It seems that passing information through the URL is the best method when using the PRG pattern. I’m just worried that Google Analytics in the page might index the query string in the URL. Even though the query would be an encrypted and unreadable form of the credit card information, I still wouldn’t want that to show up on anything. Hopefully I am incorrect in thinking Analytics would store and index that information.
Please advise, thanks for your help.
Ley’s say you pass the credit card information through the URL.
The only way crawlers could index a page with the CVV is if the URL the user was redirected to after post submissions somehow leaked. You say you encrypt the credit card information passed in the URL, but the details of how this is done are crucial.
If you just encrypt everything with the same key and just decrypt the URL information when the page is requested and show it to the user for confirmation, it’s certainly not enough. It would still not be enough to e.g. allow that confirmation page to be displayed only once – since there are not that many CVV numbers, any user can trivially try all the combinations and see what they encrypt to. So I’m not even considering complex cryptanalisys solutions.
A possible way I see this could be done would be to generate a long random key (or as long as the information you’re encrypting; since it’s not that much data and you can use symmetric encryption in that case), encrypt the data with that key, and set that key as a secure and short-lived cookie on the client (all over https, of course). That way, even if the URL leaks, only that user will be able to decrypt the credit card information.
This also solves the problem that you may be logging the requests in your web server; since very rarely are cookies logged, an examination of logs will also be insufficent to retrieve the credit card information.