I have an application built on laravel. I needed to enable https on my system and I used the cloudfront and Certificate Manager.
I was able to configure everything! Except that the laravel authentication system stopped working. Apparently the session in laravel does not work with cloudFront (CDN).
The system shows no errors. It simply does not authenticate the user.
I suspect the reason is the cloudFront. Because the cloudFront is between the browser and the EC2 server. Anyone know if there is a laravel authentication problem with cloudFront and Certificate Manager
my system: https://loja2.softshop.com.br/login
credentials:
login: teste#sandbox.pagseguro.com.br
password: tim140
the laravel validation also does not show the error messages.
For web distributions, you can choose whether you want CloudFront to forward cookies to your origin and to cache separate versions of your objects based on cookie values in viewer requests.
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Cookies.html
By default, no cookies are forwarded by CloudFront. Since most web sites providing any kind of dynamic content use cookies for managing state and authentication, the default configuration usually needs to be modified for dynamic sites.
Note the caveats on the same page of the documentation -- you generally only want to forward cookies to your origin on requests where the origin actually needs to them, so you may want to create separate Cache Behaviors without cookies enabled for static resources, in order to maintain a reasonable cache hit ratio for those static resources.
Related
I have a Webapp (HTML, JS, PHP) on an Amazon cloud server which is integrated in our companies network. Lets say the servers name is
dev-myapp.cloud.myentity.mycompany.com
This app is using the companies global SSO login by getting an oauth token from the SSO login page and then sending client, secret and callback (as usual). If Login is successful, the SSO login redirects to my callback (which in that case is my apps url above)
The SSO login creates many cookies in the browser. Most of them are flagged as secure but also some are not. For all of this cookies I now get an error
Cookie "xxx" will be soon treated as cross-site cookie against "path_to_any_of_my_sources" because the scheme does not match
I get this error for every script which is loaded (HTML, js, PHP, css) with FireFox.
The domain of the created cookies is
mycompany.com
so there should be no cross site at all.
What can I do to remove this hundreds of warnings, which makes debugging really annoying
If you need more information please let me know. Please understand I cannot provide you with real data from my company.
I was able to fix this same problem by clearing my cookies in the browser.
I have 2 Asp.Net Core 2.2 applications and I want to share session between them.
I've set up session in a SQL database and both connect ok.
They are on different sub domains.
I understand that I can set the Cookie.Domain the startup file, which would solve the problem at a basic level, so each application would create the cookie such that it can be accessed.
e.g.
Domain 1. "www.website.com"
Domain 2. "dashboard.website.com"
At present these sites can't access each others session cookie.
If I set the domain cookie to ".website.com", both should be able to access this.
The problem is that we have multiple domains that use this website, so it could be:
www.domain1.com
dashboard.domain1.com
www.domain2.com
dashboard.domain2.com
www.domain3.com
dashboard.domain3.com
I need to be able to inject the current host name into the startup cookie domain, in order to have it dynamically set, depending on the domain of the active website.
Is this at all possible?
Thanks in advance,
David
No, it's not possible. Cookies are domain-bound. You can set a wildcard for the subdomain portion on the cookie, which would then allow it to be seen by example.com, www.example.com, foo.example.com, etc. but you can cannot share with an entirely different domain altogether, such as example2.com.
Your only option in this case is an Identity provider like IdentityServer, Auth0, Azure AD, etc. The way these work is that the auth cookie is set at the provider, and then each individual app is authorized against that provider. As such, they can receive the user principal from the provider, without having the actual auth cookie or their own login functionality.
UPDATE
If you just need to share between sites on the same primary domain, then follow the instructions in the docs. That's focused on auth cookies. If you need to share sessions as well, the same procedure applies, but you must additionally have a true distributed cache setup (Redis, SQL Server, etc.). There's a distributed memory cache, but that's just a default implementation, and it's not actually distributed.
I have an api deployed to Heroku. It is currently open for everyone to see. I only want known android phones to be able to modify and access the api.
I don't want the user to have to login every time they use the app.
Can I add some sort of certificate to the phone to verify that it is credible?
Is OAuth the best approach for this?
Is there a better way to do this so the user doesn't have to login every time?
This is a fairly broad question (and hence there are several approaches). Without knowing the language/framework you are using it's also hard to give specific advice, but:
Your server can issue a cookie or token that the client can store locally for a duration. These tokens should include a timestamp and be authenticated (use a library that does HMAC authentication) to prevent clients from modifying tokens.
Clients should present this token or cookie on each request to your server via a HTTP header or the standard Cookie header.
You will need a login system to support the initial issue of the token/cookie.
Clients could also OAuth against your server (complex) or against an external service (GitHub/Facebook/Google/Twitter), but you will still need a way to track that state on the client (hence a token/cookie).
Cookie support should be included with the standard Android HTTP client, and most server side frameworks have support (or a library for) authenticated cookies.
I'm building a Sinatra app which needs to use a session variable for one very specific thing. The session variable is set when the user is looking at an SSL enabled page.
I'm using Heroku's piggyback SSL, so the SSL url is something like https://myapp.heroku.com
However, the app itself is hosted at my url, myapp.com
Is there a way to make my session variable, which is set while on the ssl / heroku domain name, available to my app while while on my domain name?
Unfortunately no, since the cookie is tied to the domain. What you'll have to do is either allow authenticated users to use the https://foo.heroku.com domain, and reserve your nice domain for the landing page & other unauthenticated pages.
That, or pay $20 for heroku's SSL add-on.
(I ran into this exact problem in http://appkickstand.com and I chose to just deal with the heroku url for logged in users)
You should look for cross-domain cookies manuals, check this.
But i don't see many reason in setting cookie through secured channel and transmitting it later via raw HTTP, where everyone could sniff it.
I have read on some blog (sorry for not mentioning the reference but I can't find it anymore) that you will lose all your work on securing your site if you redirect a user from an https page to an http page.
So, could someone please explain to me if I am right or wrong here in the following scenario:
Is it right practice to use https on the login page then redirect him to Admin Page with http, or will this will create a security issue like Session Fixation hijacking, stealing session, etc.?
Or must I keep the Admin Page also in https?
Another side of the question is: will https allow caching of static files?
I have read other articles here but I am still confused as some say 'yes' and some say 'no'; also some say it depends on browser.
In your instance (in only securing the login page with HTTPS) while login details will be protected (e.g. username/password), your users will be susceptible to Session Hijacking.
Whether you use a mixture of HTTP/HTTPS or full HTTPS depends on your situation. Amazon for instance, will use HTTPS for the login, but you'll browse the site with HTTP, but as soon as you go to a sensitive area (Order details screen, change account/password details etc.) it switches to HTTPS and asks you to re-authenticate. Re-Authenticating the user after switching from HTTP to HTTPS is the key to stop Session Hijacking because you're effectively issuing a new Session token. So if a user steals the session token, they still don't have your username/password and can't access your account section.
If the admin area is particularly sensitive then just HTTPS the whole thing. Google found the overhead from using full HTTPS was between 1-5% overhead on the CPU, hardly anything basically.
As for caching static files on HTTPS I'm not sure, but this SO post suggest it'll cache as normal Will web browsers cache content over https
Everything must be used with https. If you switch over to http, everybody can see the content being sent, which means those security issues you mentioned will emerge.
The reason is that you have to identify your client in order to assign access rights in your admin site. One possibility to do so, is sending back a token (some hash or whatever). Depending on the token you know if it's an authenticated client or not. But everybody else does see this token => security issue.
Of course you could use the previous https session to exchange a private key. And use it to encrypt your http stuff somehow. But this is a bad idea, since https does this much more conveniently..