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.
Related
The browser reports that the connection is insecure, so the certificate hasn't loaded correctly. However, then manually opening the website it loads correctly.
Can anyone tell me how to fix Invalid certificate issue, It's result in to launching the wrong URL.
I tried with "chromeWebSecurity": false in my cypree.json, but no luck.
Please help me to solve this issue.
I haven't done this myself, but Cypress docs say that it's expected: You'll notice Chrome display a warning that the 'SSL certificate does not match'. This is normal and correct.
Note, that Cypress allows you to optionally specify CA / client certificate
https://docs.cypress.io/guides/guides/web-security#Examples-of-what-Cypress-does-under-the-hood.
So if the fake Cypress certificates are causing issues for you, you can try supplying your own certificates.
if it is not your website, you cannot fix it.
what you can do is verify why it is invalid, and decide to accept it and still open an https connection with the server although the certificate isn't valid.
usually the steps are:
click Advanced button
read and understand
click Accept or close the tab
the common reasons for a certificate to be invalid are:
domain name invalid, the certificate is installed for multiple vhost, and you have accessed the service for a domain name not defined in the certificate. www. is required, only * is specified without empty domain. totally wrong domain name. etc.
certificate is expired. check the date, it might be expired and decided if that makes sense to you
certificate isn't trusted, self-signed or using an authority not trusted by your browser.
if it is your website, these are the same reason, so you should be able to replace the certificate with an appropriate one.
by the way, this might not be a question for stackoverflow, maybe more for superuser, but I am happy to answer it anyway.
hope this helps you and others
cheers,
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'm trying to send AJAX requests to the REST API website that uses self-signed certificate.
The problem is that when I first visit that website it is complaining about this certificate issue. When I do an AJAX request (without accepting this certificate first) it fails silently.
The question is what to do in this case? Should I ask the user to go to this website and accept this certificate? Is there a way to do that in elegant way? I know that this certificate should have been signed in the first place, but I don't have an access to that website. Using http is not an option.
I have had this same problem several times. The best I could come up with was something like this: check for a cookie, if they have it, do nothing, if they do not have it, issue a re-direct to the site that generates the cert warning, user accepts the self-signed cert, then the user just needs to go back to your site. If you had any control over the api side, you could probably make it so that you have a bounce back url or something that ends up getting the user back to your site. There really is no elegant way to handle this short of just getting a real SSL cert. On another site, we ended up having to put a link to the service on our page for this very reason, fortunately it was temporary as we had control over the server side too, and planned on replacing the self-signed cert with a real one.
This is security doing its job. It may not being doing a good job as far as handling what the user is supposed to do, but you really should sign your certificate with a valid CA instead.
The Problem:
I am creating a vb6 application that will connect to a particular web service located on a a HTTPS site. The problem is, the HTTPS site I'm accessing requires all request to accept it's certificate policy. (as its a self-signed ssl certificate)
Basically I need the application to accept security certificate dialog boxes automatically. A sample security dialog is shown below:
Cheers in advance.
#EDIT:
I Cant' post an image yet as i am a new user... Please see the url below for a sample image:
http://oit.nd.edu/network/nomad/images/ie_certs.gif
Look for a property named Silent.
You will have to catch some other event, to reply to that dialog box. Although, I am not sure what is the behavior, if you set the Silent to true (i.e does it assume it to be Yes or otherwise?).
Most of HTTPS sites I know use self-signed certificates.
I don't know VB6 APIs for HTTPS, but for example in Java you should provide it a copy of the site certificate beforehand. That is:
export a copy of the certificate, for example from your browser certificate repository (in Firefox: Tools->Options->Advanced->Encryption->View Certificates etc.) - supposing you have have already visited the site with your browser;
detect which certificate repository your HTTPS API points to (there certainly is one)
import certificate into that repository
execute your program