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;
Related
I have received a mail from noreply-apps-developer#google.com with the subject “[Action Required] Submit your app(s) for Restricted Scopes OAuth verification”. In the email body, there is a link to the Google API Console. After I am in the Google API Console, under the tab named “Credentials” 2 fields are highlighted.
Following is the screenshot of the same.
Link to screenshot
I would like to know the reason for the error “Invalid domain”. Also, would be great if you can help me resolve the issue.
Please note: In the sections highlighted in red color, the site URL is present. I have removed it from the screenshot for security concerns.
Edit1:
As suggested, I have added the links for privacy policy, domain, etc. When I click on the "Submit for verification" button, a modal appears. I am unable to identify what information I need to add here. The details are as follows:
link for the screenshot of the modal which appears when I click on the submit button.
The application interacts with gmail in 2 instances:
1. Sending emails.
2. Reading emails received (emails having a particular subject line) and accessing the attachments present in it.
There is not other use of the gmail connectivity.
I am confused whether I should mark the application as "Internal" or should I submit it for verification. If I have to submit it for verification, then what details should I insert in the modal that appears on click of the "submit for verification" button (screenshot has been shared).
Request you to help me resolve the issue.
All URLs in your project must match one of your Authorized Domains. But your screenshot shows this field to be blank. You will need to tell Google which domains your app is allowed to run on.
For example, let's assume your homepage is at https://www.example.com/ and your privacy policy is at https://www.example.com/privacy. You'll need to include example.com in the first field under Authorized Domains.
In this screenshot below, I've added a matching Authorized Domain and the errors are resolved.
Check the "Learn more". It was stated in bold text that:
Add your Authorized Domains before you add your redirect or origin URIs, your homepage URL, your terms of service URL, or your privacy
policy URL.
Looking into your screenshot, something is missing and it is your Authorized domains.
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.
We have an MVC/AngularJS system with a Web API back-end that uses Azure ACS and AAD to authenticate our users. The authentication works well, and when the user first authenticates the claims from ACS are passed in in the token.
We override the ClaimsPrincipal Authenticate method and verify that this user is a user of our system and add role claims here too.
After this the user is directed to the home page and the next step of the process requires the user to select an item from a list (e.g. their current location).
This selection determines how certain settings are applied in the web application. When the user makes this selection we make an ajax call to the Web Api back-end and here we add another three claims to the token, reflecting the user's selection.
Now if I refresh the page after this selection has been made the whole process starts again, but different browsers behave differently.
For Chrome and Opera the 'ClaimsPrincipal Authenticate' is called again, the roles are added again and the user need to make the selection again to add the three claims (i.e. when the page is refreshed a copy of the token before our code modified it is used).
For Firefox and IE the refresh passes in a token with all the claims that we added programatically, so it didn't revert the token to the initial state.
The latter behaviour is what I would have expected and what I would prefer. Is there any documentation on this, and for Chrome and Opera is there a way to ensure the current token is used when the page is refreshed?
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
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)