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
Related
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;
I built a Chrome Extension, where a login form is displayed as a side bar using content scripts injection. I do not want the user to see this login form if the user is already logged in on the website and vice versa if the user logs in on the Chrome Extension and then visits the website, user should automatically log in.
I am returning tokens from the backend when a user successfully logs in.
My question is, what is the best way to store these tokens so both the content scripts in my extension and the website have access to the token to check to see if the user is already logged in.
As far as I understand I have localStorage, ChromeStorage but I do not know if they are shared between the tabs of the browser and the extension.
Any direction is highly appreciated.
Thank you.
If you're returning tokens, a reasonable way to do it would be to inject a content script into pages that match the callback URL containing the token, extract it and save into chrome.storage. It is shared between the content script and all other extension contexts.
Do note: chrome.storage is not exactly secure: it's not encrypted on disk, and can be snooped upon with Dev Tools. Then again, the token is normally stored in the cookie store, which can be likewise examined even without access to the (slightly) more secure password storage.
Perhaps the only more secure way to keep the token in the extension is chrome.identity API, but then you have to login separately, defeating your goal.
I'm building a webapp specifically for iOS and Android devices which requires user to sign in with their Facebook or Twitter accounts. I have it setup so that initially they're redirected to the appropriate login page and upon successful completion my provided calllback url is triggered.
Because I want to implement a single sign on, I will be storing on the user's device the access token that I received so they can easily access the webapp without having to sign in again next time.
My question is this: is it better to store it as an html4 cookie from the server side? Or is it better to insert it as a hidden input in the home page and have javascript on the client grab it and store it with the new local/sessionStorage? And if the latter, which type of storage would be better for this type of data that I would like to save?
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!
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)