Is it good enough a protection if my site is serving on https with secure session cookie and redirects any attempts for http urls to https?
What kind of security holes can i be exposed in this setup to for which i cannot live without setting the HSTS header?
This strategy protects against passive eavesdropping by making it hard for an attacker to trick your user into using something other than SSL to access your site. It also probably ensures that any bookmarks users store will point to the https URLs, which is good. However, HSTS still offers advantages in the event of a man-in-the-middle attack.
The core of the problem that HSTS tries to solve is that the browser doesn't know whether a given site should be using SSL or not. And most users don't explicitly try SSL first; if they type in a URL, they generally go to the non-SSL http site first, and usually they're just following links. If an attacker can trick your user into going to your site via an http URL and can sit in the middle of the user's traffic (by being their wireless AP, for example), that attacker can launch a man-in-the-middle attack against your site by proxying the user's traffic to your site and presenting the site to the user without SSL (this is a type of downgrade attack). Since the user won't see SSL, their browser won't recognize that the attacker doesn't have a valid certificate for your site and that they're not connecting to your site directly. (A more complicated approach would be to intercept the SSL traffic and present a self-signed or otherwise invalid certificate for your site, but this will normally result in browser warnings.)
In this scenario, redirecting non-SSL users to SSL or setting the secure flag on cookies doesn't actually help you very much. The man-in-the-middle attacker will be connecting to your SSL site (and proxying the user's actions to it), and will just remove the secure flag from your cookies when passing them along to the user.
The attacker can, of course, also remove the HSTS header. The point of the HSTS protocol, however, is that if the user had ever successfully gone directly to your site in the past, their browser will remember that your site sent HSTS. If they then later connect to your site and find that it's not using SSL or that the browser can't verify the certificate, the browser will throw an error and refuse to continue. This will prevent the attacker from downgrading your site to non-SSL if the browser supports HSTS and has your site recorded as requiring SSL.
Wikipedia has a fairly good discussion of this, which I think is somewhat clearer than the discussion in the RFC.
Related
Steps to re-create the issue:
Login with Admin Credentials and copy the session cookie.
Open another browser, Login as another user, paste the session cookie of the admin. Refresh the page. Now, you'll be
logged in as Admin.
How to solve this issue? Any suggestions would be of great help.
Tried using the event subscriber to get the previous session before drupal loads the cookie session, but no luck with it.
This is not a problem, I mean, of course, Session Hijacking is a really big concern - but standard defences are fine.
These are the controls that I know are widely known/used:
Ensure HTTPS is used everywhere,
Only use a securely created random string for the cookie value,
Set the secure flag on all cookies. This will ensure that they are only sent over an SSL connection,
Change the session cookie on each new login attempt.
All of Drupal 8's cookies are secure by default.
The exception is BigPipe's no-JS cookie, see https://www.drupal.org/node/2678628 — but there are no security consequences there.
I know some very sensitive applications may also store - for each session - the following additional information:
SSL Session ID
HTTP User Agent
Remote IP Address
In my point of view, I wouldn't bother with checking the HTTP User Agent or the remote IP address. They don't add that much security and they will break legitimate use in certain scenarios. Checking the SSL session ID (SSL session binding) would be OK from a security perspective, but could be painful to implement, the other defences are fine.
If your concern is Cookie Theft via XSS, the best defence is to use standard methods to avoid XSS bugs in your web application. See OWASP for plenty excellent resources.
You may find a lot of best practices to write secure code for Drupal 8 here: https://www.drupal.org/docs/8/security/writing-secure-code-for-drupal-8
You may also find a pretty old discussion about this on Drupal here: https://www.drupal.org/project/drupal/issues/19845
I have ws working for sending user login details through a websocket. However I know that someone sniffing packets could capture the password, so I wanted to use wss instead. However I now understand, through playing around with my back end, that firstly a certificate is required for it to connect properly, and secondly, if i cause the self signed certificate warning to sho0w, afterwards the websockets will work with wss, but that is not good enoyugh for clients. From googling this issue, I have found that A self signed certificate will probalby not be good enough.
And all I want is to provide a user with a safe way to login.....
So anyway I am now thinking it would be better to avoid having to use wss all together. I could use a conventional servlet for login but that will probably require a certificate too for https and I don't want to have to start paying people loads of money for certificates when my business might not even be that successful.
I have been thinking about other ways I could send the users password securely. One way might be to generate a hash in the browser. I know I could use some king of challenge along with a salt sent to the browser but I am not exactly sure how to do this and how safe this would be. I have the conventional login working with a salt, generating a hash with AES. Any suggestions?
I just want the users login details to be safe and I don't want to go down the route of certificates, it's annoying and unreliable.
Login should always happen through HTTPS. Not only the POST sending the user and password, but also the GET getting the login form, so the client can be sure is getting the right form and that his information will be posted to the right place.
You can send login details either by HTTPS or WSS if you want security. If you use a self-signed certificate you will provide transport security, but as the certificate is not signed by a CA, the client cannot be sure that the server with which is interacting is the right one, and that is why the browser shows a warning.
So, if you want security for your clients, you should get a signed certificate and use it for HTTPS and WSS (you can get them from 10 bucks per year in some places). Anything that you do in the browser is insecure by default, starting by the user not having certainty of being interacting with the right server and not a spoofed one.
Found this blog helpful even though it's directed to the raspberry pi and python/nodejs. http://simplyautomationized.blogspot.com/2015/09/5-ways-to-secure-websocket-rpi.html
Good concepts on security and authentication. I would recommend ALWAYS using ssl and not rolling your own crypto.
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..
We are getting security message like this while executing url:
There is a problem with this website's security certificate. The security certificate presented by this website was not issued by a trusted certificate authority.
Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server. We recommend that you close this webpage and do not continue to this website. Click here to close this webpage. Continue to this website (not recommended).
More information
Same type of security alerts with message like this
This page is accessing information that is not under its control. This poses security rish, DO you want to continue?
How to avoid them through code either javascript, jsp or any way. We can not ask each user to modify their internet options. Please let me know if there is any solutions for this
That's browser behavior that you can't and shouldn't be allowed to modify using JavaScript, or anything else for that matter. In fact, these security alerts are there to warn the user that something is (potentially) wrong. If you could disable them, there would be no point in having them, right?
Fix whatever problems you have with the security certificate and you'll be fine. I'll guess here that your certificates are self-signed - buy one. They are not that expensive.
You need to install a current, valid certificate on your web server.
There is a problem with this website's security certificate could mean you need to check that the clock is set correctly.
Host all content on an https website. not an http one. You do not need a certificate then.
1> The security certificate presented by this website was not issued by a trusted certificate authority.
This message indicates that the page is using a HTTPS-based resource which has a certificate which does not chain to a globally trusted root certificate. If you don't know what resources/URLS are causing this, open the F12 Developer Tools and look at the Console tab, or run Fiddler and watch for the warning popup.
2> This page is accessing information that is not under its control. This poses security risk, DO you want to continue?
This message is shown when you attempt to use an XMLHTTPRequest object to request data from a cross-domain location (e.g. www.domain.com tries to grab data from domain.com). That operation is a violation of Same-Origin-Policy.
By default in IE, this is blocked, but inside the Intranet Zone, this feature is set to Prompt and thus you see this message instead.
To fix this, either change the request URL so that it does not go to a different domain, or use XDomainRequest, or use a serverside proxy page to make the cross-origin data request from the server rather than the client.
I am currently working on the authentication of an AJAX based site, and was wondering if anybody had any reccomendations on best practices for this sort of thing.
My original approach was a cookie based system. Essentially I set a cookie with an auth code, and every data access changed the cookie. As well, whenever there was a failed authentication, all sessions by that user were de-authenticated, to keep hijackers out. To hijack a session, somebody would have to leave themselves logged in, and a hacker would need to have the very last cookie update sent to spoof a session.
Unfortunatley, due to the nature of AJAX, when making multiple requests quickly, they might come back out of order, setting the cookie wrong, and breaking the session, so I need to reimplement.
My ideas were:
A decidedly less secure session based method
using SSL over the whole site (seems like overkill)
Using an iFrame which is ssl authenticated to do secure transactions (I just sorta assume this is possible, with a little bit of jquery hacking)
The issue is not the data being transferred, the only concern is that somebody might get control over an account that is not theirs.
A decidedly less secure session based method
Personally, I have not found using SSL for the entire site (or most of it) to be overkill. Maybe a while ago when speeds and feeds were slower. Now I wouldn't hesitate to put any part of a site under SSL.
If you've decided that using SSL for the entire site is acceptable, you might consider just using the old "Basic Authentication" where the server returns the 401 response which causes the browser to prompt for username/password. If your application can live with this type of login, is works great for AJAX and all other accesses to your site because the browser handles re-submitting requests with appropriate credentials (and it is safe if you use SSL, but only if you use SSL -- don't use Basic auth with plain http!).
SSL is a must, preventing transparent proxy connections that could be used by several users. Then I'd simply check the incoming ip address with the one that got authenticated.
Re-authenticate:
as soon as the ip address changes
on a time out bigger than n seconds without any request
individually on any important transaction
A common solution is to hash the user's session id and pass that in with every request to ensure the request is coming from a valid user (see this slideshow). This is reasonably secure from a CSRF perspective, but if someone was sniffing the data it could be intercepted. Depending on your needs, ssl is always going to be the most secure method.
What if you put a "generated" timestamp on each of the responses from the server and the AJAX application could always use the cookie with the latest timestamp.
Your best bet is using an SSL connection over a previously authenticated connection with something Apache and/or Tomcat. Form based authentication in either one, with a required SSL connection gives you a secure connection. The webapp can then provide security and identity for the session and the client side Ajax doesn't need to be concerned with security.
You might try reading the book Ajax Security,by Billy Hoffman and Bryan Sullivan. I found it changed my way of thinking about security. There are very specific suggestions for each phase of Ajax.