HTTPS ASPX page Redirect to HTML page logs user out - as if session lost - html

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

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!

Related

why is my web browser not sending cookies when I click a link, but it sends them just fine when I type in the url

I am creating a web application in Golang/HTML. I am implementing registration, sessions, email verification, and login.
My code works, however I have noticed some strange browser behavior. When the user registers for the first time, my application will send them an email containing a link with a unique nonce (number used once) in the url. This is to ensure that the user is able to receive email from us at that address and "verify their email", as is standard practice on many web applications.
Please click the following link to verify your account: http://localhost:8080/verify-email/55c17d2c
I noticed that when I receive this email, if I click on the link in the email, the browser will open the link in a new tab as expected, however, it will not send any cookies on requests associated with that tab.
But when I copy and paste the link into a new tab manually and press enter, it sends the cookies just fine. What gives? is this some sort of undocumented security feature? What should I do about this?
I used https://github.com/six-ddc/httpflow to capture a log of the HTTP requests and responses going between my web browser and my server application. I have two separate logs, one of them captured a registration flow where i clicked the link, and the other one captured a registration flow where i copy and pasted the link into a new tab.
Log where link in email was clicked: https://paste.cyberia.club/~forest/2f3fce7dcc71fc095341eeaefb33f20883c79886
Log where link was copy and pasted from email into url bar: https://paste.cyberia.club/~forest/0623f76cfee339e91d2213dd8f4c7710c6fa2797
Please note that I tried this on firefox and google chrome, I also tried it with a real domain and https certificate, got the same behavior in all browsers and setups.
Here are my constraints:
I want the application to work fine with javascript disabled, however, I'm open to javascript-based solutions if they are simple, secure, and make the site more enjoyable to use. For example, I am using a javascript that hashes passwords client side before sending to the server for login. But if javascript is disabled, the raw password will be sent.
I don't want the user to have to log in again after they click the link to verify their email address.
I don't want the link in the email address to represent a "free pass" into the user's account. I want to require the user to be already logged in (or somehow otherwise authenticated) before they can verify their email address. For example, if someone steals that email and clicks that link before the intended user does, I don't want the email thief to be able to take over the account.
OOPS I just figured this out, I wanted Lax SameSite policy on my cookies:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#SameSite_attribute
It takes three possible values: Strict, Lax, and None. With Strict, the cookie is sent only to the same site as the one that originated it; Lax is similar, except that cookies are sent when the user navigates to the cookie's origin site, for example, by following a link from an external site;

Incorrect Referring URLs - What can be the cause?

I am running a website with affiliate links .
When the visitors of mydomain.com/page.php click on such an affiliate link,
they are being sent to a link on a domain owned by the affilate network (network.com/link), and then redirected through the affiliate network, to the relevant page in the store (store.com/page.asp).
Over the last two months, the reports of the affiliate network indicate that about 13,000 clicks that I sent to such links, carried mydomain.com/page.php as the referring URL, as I would expect.
However, about 20 other clicks carried abnormal referring URLs, such as:
http://app.mam.vaccint.com/getapp/CT3297962/mam.html
http://www.store.com/page.asp
http://www.network.com/link
http://apnwidgets.ask.com/widget/everest/radio/4/radio-button.html
http://search.yahoo.com/search
http://www.google.com/webhp
http://www.bing.com/
http://192.168.1.1/spyware/blockpage
Unfortunately, This has led the compliance team of my affiliate network to believe that I have a hidden traffic source apart from my website, they claim that it appears to be as if I am using some kind of a third party software to send traffic to store.com, which is not true of course.
They are holding me accountable for this situation and I am required to provide explanations to this situation.
What could have caused my website visitors to arrive at network.com / store.com while carrying the above referring URLs?
Not sure though, but looking at the referring URL's its quite certain that these pages had your content listed on their webpages. Like:
e.g. google.com/webhp - listing the result content / cache / image result of your webpage
Bing.com - another result related webpage (generally web cache)
192.168.1.1/spyware/blockpage - looks like someone accessed your portal but ended up reaching this firewall custom page. But somehow the affiliate widget got loaded as it would have been permitted by the firewall.
Store.com/page.asp & network.com/link - looks like some internal redirected urls which sent traffic to the relevant page (store.com/page.asp)
(rest other) - all other links also can have a similar story which ended up sending traffic to your affiliate network, but had another URL.
I'm sure if you replicate this case in front of them via Google cache / Bing cache, they would get a better understanding of the issue.
Else, try to identify the source referrer of page: network.com/link, which probably is under their control and they would have access to the logs.

Update a website that already published and always have online users?

I am going to develop an asp.net website. My problem is think that now my site is published on the internet. 100 Users are already logged to my website. And they opened customer registration form in the website. So we know that when user log to a website he is sending a get request for the specific page. Then the server is sending that page in HTML format and it destroy the page from the server side.
So think that after server sent the customer registration form to the user I am going to do a update to my website. What I am doing is removing some input fields from the customer registration form. So imagine that at the user's end he can see 10 textboxes but my updated version will only contain 5 textboxes. So now what? What is going to happen? Is this lead to an error?
I just took a small example. Think that this situation occur in the middle of a transaction.
What is the scenario that use to update a website that already published and always have online users?.
Just Recycle the Application pool, this will make a new request for the online users. Like a fresh start.

Cookie: basic info and queries

I read this in Wiki:
A cookie, also known as an HTTP cookie, web cookie, or browser cookie, is usually a small piece of data sent from a website and stored in a user's web browser while a user is browsing a website. When the user browses the same website in the future, the data stored in the cookie can be retrieved by the website to notify the website of the user's previous activity.[1] Cookies were designed to be a reliable mechanism for websites to remember the state of the website or activity the user had taken in the past. This can include clicking particular buttons, logging in, or a record of which pages were visited by the user even months or years ago.
Now I want to know who creates cookies. Is it the browser or can every site create a cookie on its own? Who controls what information has to be saved in cookie and how can all the form field data be saved in cookie?
I think "Setting a cookie" section will help you a lot.
http://en.wikipedia.org/wiki/HTTP_cookie
The website creates the cookie, whether front end (Javascript cookie) or back end (PHP cookie)
The website developer controls what is stored in the cookie.
The website developer gets the information from a form, processes it, then stores it in the cookie.
COOKIES are created by site owner. cookies are actually client side sessions.
Now I want to know who creates cookies. Is it the browser or can every site create a cookie on its own? Who controls what information has to be saved in cookie and how can all the form field data be saved in cookie?
Cookies are created on the client machine by the web server. cookies are initiated using php sessions the browser on the client side stores this cookie as phpsession id which identify s the user the php on the server can then recognize the user by the cookie which is sent from the client to the server. (via the browser).
The creator of the website will control what data is contained in the cookie, for example
`<? php
session_start();
if($_SESSION['logged_in'] == "")
{
header("Location: login.php");
}
?>`
for example the above code would check if the user had the value 'logged_in' if they had not logged in they were redirected to the login page. else they could continue to view the page.
" THanks you , could please let me know can one site access cookies of other site and read information from it and make sense out of it – Vinayjava 1 hour ago"
Yes one website is able to grab information from another website this is known as Cross site request forgeryand is most often performed via XSS injection etc, it can be used to steal user cookies..
any other questions about cookies message me i should be able to help

Email and Reusable Token URLs

I'm building a site that offers functionality to users without requiring them to register. The idea is to send an email to the specified address containing a link with a token. That way the user would could this link anytime they want to make changes to the functionality.
While I realize that there is no way to truly secure such a concept, I'm looking for options to minimize the visibility of the token. In its current state, soon as the user clicks on the link it is added to their browser history, available to anyone who has access to the computer.
In most cases I would over come this with a simple form so that the token could be passed through with a POST request, but forms aren't really supported in emails.
So the question is, does anyone know of an alternative way to hide a token in such an email?
I'm sure you've thought of this, but you could send them a password and a link to a URL where they'd need to enter that password. If the emailed URL contained another password, it would be a smaller compromise to security than usual to make the user-entered password quite short, like a PIN number, say.
You could resend a new token every time the user wants to log in. Have them plop in their email address and send them a new token, while setting previous tokens to 'expired.' Or, if the server detects that an old link/token was used, it could automatically send a new one to the associated email address and ask the user to check their email for a new link.
That would require keeping track of old, expired tokens and the associated email addresses, but still requires no registration - just that a user check their mail every time they want to log in. You'd essentially be piggy backing on their email authentication.
It'd also be counter-intuitive for users.
This would turn the token into a cryptographic nonce, which is primarily used to prevent the replay attack you mentioned.
Another answer, perhaps more useful:
Some browsers (like Chrome) do not record 301 "Moved Permanently" redirects in the browser history. Firefox does, but there's a proposal to change that:
https://wiki.mozilla.org/Browser_History:Redirects
For example, in Chrome, if you navigate directly to
amazon.com
it will follow a 301 Redirect to
www.amazon.com
If you then check your browser history, it will only show
www.amazon.com
Thus, if your server returns a 301 redirect from the login link, the server could record the token, remove it from the redirect link, and the user's browser would only record the redirect link.
(this is my first time responding on stack overflow - let me know if my writing is unclear or if I'm missing other etiquette)