0

Greetings, everyone:

Firstly, sorry that my Flow description is long winded, but I think it might help with describing the problem.

Background:

Building asp.C# shopping app that is using a hosted payment page to process payments (using posting of data to a hosted payment page). SSL certificate is signed and installed.

Flow:

Prelim) (HTTPS) Users authenticate using asp Login control

1) Users add items to cart.

2) (HTTPS)Users go to checkout page.

3) Users finalize their order, then click pay now after agreeing to T&C.

4) Server gets cart data (from MSSQL2005) and sets a transaction cookie (expiry set to 20 mins).

5) (HTTPS) Server Response.Redirects to an html page (in the same folder as the login protected pages).

6) Html page reads transaction cookie data and generates form fields.

7) (HTTPS) Html page posts data to hosted payment page (php).

8) User enters payment info and clicks pay now.

9) (HTTPS) hosted payment page posts info back to a .aspx page that checks if payment OK.

10a) If payment !OK, redirects to a declined page.

10b) (HTTPS) If payment OK, sets a verification cookie (expiry set to 20 mins). Then redirects to another html page.

11) Html page reads cookie data and generates form fields.

12) (HTTPS) Html page posts data to hosted verification page (php).

13) Verification page verifies (of course), if transaction ok.

14) (HTTPS) verification page posts data to a .aspx page that checks if verification OK.

15) If verification OK, process orders and do receipt stuff.

Issue:

This control flow was tested on an unsigned dev environment. SSL was being enforced, if needed on the unsigned SSL certificate. So we'd get prompts that certificate may be bad, but the control flow worked seamlessly.

However, now live with a signed SSL certificate, going from step 5 to 6, we are encountering a situation where some users (not duplicated every time, but verified that it does occur) when they click pay now and are redirected to the html page, they are forced back to the ~/login.aspx page (as if they were logged out).

Things to note:

a) The session did not time out.

b) The browsers have cookies and javascript enabled.

c) I can process the entire flow seamlessly on the same machine with other accounts, and occasionally, the same account.

So, basically, I'm stumped... Is this a viewstate error? A login control bug that won't let me redirect to an html page because it is now using a real SSL? Anyone have any experience with this kind of deal? I'm at a loss for solutions at this point.

Any help would be greatly appreciated. Kind Regards,

jra

MrFurious
  • 11
  • 3
  • Just to clarify, do the steps where you haven't indicated "(HTTPS)" mean that there is a plain HTTP connection, or is it just about the user-interaction? – Bruno Sep 10 '10 at 14:25
  • User interaction or server processing. Pretty much the entire flow from 2 through 15 is throughs HTTPS. – MrFurious Sep 10 '10 at 14:26
  • It's just that if you let your authentication cookie out on plain HTTP at any time during the flow, you lose the security. Secure cookies are meant to protect against this, and I'm just wondering if there might be a change in configuration in that area. – Bruno Sep 10 '10 at 14:36
  • So, even if redirected to an .html page in the same domain and in the same directory that is protected by a web.config + login-control and being redirected to this html by h ttps://domain/protectedDir/file.html, that since I'm accessing an asp cookie set by Response.Cookies.Add(cookie) using javascript on the .html page, it should fail? But then, why am I able to post from the .html page on some accounts? I'm so lost, but thank you for exploring this! – MrFurious Sep 10 '10 at 14:48
  • If you're using a cookie for authn on HTTPS and it's visible at some point in plain HTTP, an attacker could see it and make subsequent HTTPS requests himself, using it to impersonate the user. (I've written more on this in [this post](http://stackoverflow.com/questions/3092133/tomcat-session-management-url-rewrite-and-switching-from-http-to-https/3094070#3094070). If you really want to mix HTTP and HTTPS, you'd need two distinct sessions/cookies and pay attention to the flow, ask user confirmation over HTTPS for data obtained from plain HTTP, which probably makes the interaction more complex. – Bruno Sep 10 '10 at 14:59
  • After reading your article, I see what you are getting at. So in short, after a user logs in (HTTPS) and they are redirected to any non-sensitive content page (HTTP), that asp authentication cookie becomes invalid? But with non-sensitive content that does not need to be encrypted (such as catalogue data + images), the quick and dirty solution of dropping the entire subdir into https seems extremely unwieldy... – MrFurious Sep 10 '10 at 15:11
  • Yes, or at least they should be invalidated (not all websites do this properly). Some cookies can be flagged as secured in which case the browser doesn't send them over plain HTTP (I'm not sure how this is configured in an ASP/.Net environment). To be honest, I'd stay over HTTPS once you've started an HTTPS session, the overhead of SSL isn't actually that big these days. – Bruno Sep 10 '10 at 15:17
  • Even with catalogs and image content being delivered, it's pref to stay in HTTPS? – MrFurious Sep 10 '10 at 15:34
  • Here is an [interesting article about HTTPS at Google](http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html). I think the main problem you may get is that some browser wipe their local cache for content retrieved over HTTPS when closing the browser on the assumption that it was sensitive content (which is sensible in general): this may cause pages to be reloaded on subsequent visits. – Bruno Sep 10 '10 at 15:47
  • Thanks, Bruno. This help is both really informative and a learning experience... This whole time, I figured the overhead meant we have to pretty much limit its use. But I implemented the changes and will let you know if I encounter it again. – MrFurious Sep 10 '10 at 17:03

1 Answers1

1
It's just that if you let your authentication cookie out on plain HTTP at any time during the flow, you lose the security. Secure cookies are meant to protect against this, and I'm just wondering if there might be a change in configuration in that area. – Bruno Sep 10 at 14:36

Seems this problem has been resolved. Thanks again for your assistance, Bruno!

MrFurious
  • 11
  • 3
  • Quite a few more up to date ways to do this now but marking as resolved. For further reading, see: [how to create HTTP request with POST data in C#](http://stackoverflow.com/questions/19314521/how-to-create-http-post-request) – MrFurious Jan 17 '14 at 13:25