I'm looking for some info about securing a website. The website is actually a kind of management console that can be accesses through a web browser. The console is currently only available on the internal network, but I want to make it accessible through the internet, only for some specific users/devices.
The first problem I faced is that the management console didn't provide authentication at all. To overcome that problem, I've installed apache, which I use as a (reverse?)proxy and in which I enabled basic authentication, so now I have to enter a username and password before I can access the console.
The thing that I want to do next is to prevent the username and password to be send over the line as plain text (I assume that's whats happening now). I think I have to make it a https connection for that, but I find so much information about that so that I'm a bit lost on how to continue. Can I make this work with self signed certificates or do I need to buy certificates somewhere?
You are right about securing passwords through https. I would suggest redirecting everything on your server through https, following this article.
I would suggest testing the whole solution without buying anything. Buying a certificate means that it would be bound to your server. I suppose that when you develop your solution, you use a development server. If you buy a certificate for your development server, then you would have to buy another one for your production server. Therefore, I would use a self-signed certificate for development and when the application is ready to go public, then I would buy a certificate recognized by all browsers.
In order to create a self-signed certificate you could follow this tutorial supposing you work on linux, or this tutorial supposing you work on windows.
Hope I helped!
Related
Here's the scenario:
Website A is served from a public domain example.com via HTTPS.
Website A needs to access a service B via WebSocket. Thus, the websocket also needs to be secure aka wss://.
The service B is currently not secured. I'm trying to secure it and I need to generate a certificate for it.
The service B is only available from the intranet. The WSS URL starts with wss://192.168.x.x (connecting by IP and behind a NAT). Yes, this also means that A can be fully used only from the intranet, although limited functionality is available through the internet. The typical case however is intranet use.
The computers which connect to website A aren't in a windows domain and do not currently trust any certificate authority that can be controlled by us. In other words, we cannot create a certificate that all these computers will trust by default. For that we would need to work with one of the large common authorities that everyone trusts, but I doubt they would issue a certificate for a NAT IP address.
The problem:
Since I cannot create a certificate that all the computers trust by default, I might as well create a self-signed certificate and use that to secure the websocket. However... I'm not really sure what will happen. I think that either the user will be prompted each time they connect, or the connection will fail silently anyway.
I can manually install the certificate on each machine, but that requires visiting them each separately, and if a new person wants to access the website, I need to remember to do it on their machine too. Not nice.
Is there some good solution to this? Can you make a website prompt for permanently trusting the certificate or something?
Most browsers have a built in function for permanently trusting unknown certificates, and, to be frank, I wouldn't trust any website, that tried to circumvent those mechanisms, even if they were intranet sites. If something like that appeared while visiting an intranet site, I would be more inclined to call IT Support and ask, if the website has been tampered with.
I would distribute instructions on how to add the certificate (maybe noting that mindlessly doing this on other websites than yours might be problematic) and deal with the cases that are unable to follow these instructions.
An alternative (although I don't have any personal experience with that) might be getting a free certificate from https://letsencrypt.org/ which, as far as I know, will be accepted in most browsers.
Firefox:
Chrome:
https://www.accuweaver.com/2014/09/19/make-chrome-accept-a-self-signed-certificate-on-osx/
At the moment I'm running towards the same problem only solution I can think about and what I'm trying is that I ask the user to click a button (which creates a pop-up window) with the webserver with the certificate which needs to be accepted. Then they accept the certificate and I ask them to reload (or restart the code by clicking the same button) then it should be able to work. But you will need a page on the w
Is ngrok a safe tool to use? I was reading a tutorial which recommended to use ngrok test API responses that I make to outside services that need to connect to my endpoints also.
There is no source code available for Version 2.0, considering it started as an open source project in 2014. I am suspect of any code that opens a tunnel to my localhost from the cloud. Pretty scary stuff especially without source code!
It opens up a tunnel to your dev machine, which is partially secured by obscurity (a hard to guess subdomain), and can be further secured by requiring a password. But you're still opening yourself up to ngrok itself, and the company is completely opaque (no address, no employees, no business name, no LinkedIn presence; all I can find is that it has 1-10 employees and is private; not even sure what country its based in). On top of that the code is not open-sourced. No reason to think they're not legit, but not a lot of information available to build trust.
You may be able to use ngrok and other local tunnel services with more security by encrypting the traffic. See https://security.stackexchange.com/questions/177280/end-to-end-encryption-for-localtunnel-ngrok-setup/177357#177357 for more information.
I found good rating, but vacuous information here:
http://www.scamadviser.com/is-ngrok.com-a-fake-site.html
The kicker for me is
https://developer.atlassian.com/blog/2015/05/secure-localhost-tunnels-with-ngrok/
where the Atlassian folks recommend it highly.
I think I am going to use it.
If anyone is concerning compromising their development environment, you can use Docker. There are many ngrok/docker projects but here is the one I chose: https://github.com/gtriggiano/ngrok-tunnel
for macOS, use "TARGET_HOST=docker.for.mac.localhost"
They now offer a service where you locally run only ssh, no need to run any of their code on your machine.
You run something like ssh -R 80:localhost:8501 tunnel.us.ngrok.com http. This connects to one of their hosts and forwards connections they receive back to your machine and the service you run on localhost:8501.
This seems secure to me, the only thing is that you don't know what information they collect and who is connecting to your exposed service. They print all connections, but it's their binary that does this and someone might well listen in without you noticing. You can check connections on your end, but you cannot be sure who it is that connects.
Ngrok is a convenient and highly secure utility for creating tunnels to locally hosted applications via a reverse proxy. This is a utility for publishing locally hosted applications on the web. style="letter-spacing: 0px;">Simply put, any locally hosted application provides a publicly accessible web URL to the . H. Either a Spring Boot or Nodejs based web application, or a webhook for a chat application, etc.
Dear StackOverflow community,
======================================
TL;DR VERSION:
Before we proceed further in our relationship with a cloud web portal provider, I'd like to insist that they provide us a secure way to obtain a copy of our data from their web server.
Secure for authenticating ourselves without leaving ourselves vulnerable to having our credentials stolen or spoofed and
Secure for the file in transit on its way back to us.
I suspect I might have to point them in the right direction myself despite my own inexperience in the field. What kinds of simple-yet-secure approaches to authenticating us could I ask them to look into?
======================================
FULL POST
BACKGROUND:
At work, we are evaluating a cloud-based portal through which our current and former customers will be able to network with each other (we have customers who interact with us in cohorts).
The user interface of the portal is well-designed, which is why we're thinking about buying it, but the company providing it is young. So, for example, their idea of "helping us integrate our portal data with SalesForce" was to have a link within the administrative control panel to a page that returns a CSV file containing the entire contents of our database.
"Fetch a CSV" actually is fine, because we already do it with other CSV files from our ERP (pushing to SalesForce with a data loader and scheduled Windows batch scripting on an always-on PC).
I said we could work with it as long as they provided us a way to fetch the CSV file programmatically, without human intervention, at 5AM. They did so, but the solution seems vulnerable to exploitation and I'd like guidance redirecting their efforts.
A DIVERSION ABOUT THE HUMAN UI:
The link one sees as a human using the web interface to the portal under consideration is http://www.OurBrandedDomain.com/admin/downloaddatabase
If you aren't already logged in, you will be redirected http://www.OurBrandedDomain.com/Admin/login?returnUrl=admin/downloaddatabase , and as soon as you log in, the CSV file will be offered to you.
(Yes, I know, it's HTTP and it's customer data ... I'm planning to talk to them about turning off HTTP access to the login/signup forms and to the internals of the site, too. Not the focus of my question, though.)
THEIR PROPOSAL:
So, as I said, I asked for something programmatically usable.
What they gave us was instructions to go to http://www.OurFlavorOfTheirSite.com/admin/fetchdatabase?email=AdminsEmail#Domain.com&password=AdminsPassword
Please correct me if I'm wrong, but this seems like a really insecure way to authenticate ourselves to the web server.
HOW I NEED HELP:
Before we proceed further in our relationship with this portal provider, I'd like to insist that they provide us a secure way to obtain a CSV copy of our data.
Secure for authenticating ourselves without leaving ourselves vulnerable to having our credentials stolen or spoofed and
Secure for the file in transit on its way back to us.
However, I don't get the sense that they've really thought about security much, and I suspect I might have to point them in the right direction myself despite my own inexperience in the field.
What kinds of simple-yet-secure approaches to authenticating us could I ask them to look into, knowing nothing more about the architecture of their servers than can be inferred from what I've just described here?
The solution doesn't have to involve us using a browser to interact with their server. Since we'll be downloading the file in a Windows scripting environment without human intervention, it's fine to suggest solutions that we can only test programmatically (even though that will make my learning curve a bit steeper).
(I suppose the solution could even get away from the server providing the data in the form of a CSV file, though then we'd probably just end up rebuilding a CSV file locally because we have infrastructure in place for CSV->SalesForce.)
Thanks in advance.
Yes, that is insecure.
You should insist on using TLS. For this they need to install a certificate from a Certification Authority to verify that they own the domain OurFlavorOfTheirSite.com. This will enable the URL to use HTTPS which means communication is encrypted, and authenticated (i.e. another website cannot spoof OurFlavorOfTheirSite.com without a browser warning being displayed).
Although the email=AdminsEmail#Domain.com&password=AdminsPassword parameters will be encrypted, these should be submitted via POST rather than GET. The reason is that GET query string parameters are logged in browser history, logged in proxy and server logs by default and can be transmitted in the referer header when resources are included from other domains.
What is the easiest free method of encrypting my web traffic? I'd like to be able to log in to sites on my web server without sending my password in plaintext.
Edit: My web server is running on the LAMP stack , although it is a shared host so I don't have root.
Get an X.509 certificate (for example, generating your own, or getting one free from StartSSL), and use it to set up SSL—a server-specific configuration task.
If you can't configure a new listener in your web server, there's not really a good option. In theory you could do a little hacking with some JavaScript crypto library, like JavaScrypt, and come up with something safe. I've toyed with several options but I don't know enough about it to come up with anything I feel confident about.
I don't know your circumstances, but if it were me, I'd consider another host.
https
Use a self-signed certificate.
Tell us your web server software for a detailed implementation description!
Since you don't have root your best bet is to contact your hosting provider and see what they can do for you. You may already have SSL access (try using https://yourdomain.com) using a self-certified key.
You should be able to talk them into installing a StartSSL key for you. This provides you with SSL encryption and browsers won't complain that it isn't signed by a valid Certificate Authority.
As stated above, publishing your own certification is free, however knowing more about your environment, may get you more specific answers. Are you running IIS? What will you be logging into that needs encryption? Are you using Windows Servers on the back end?
use Digest Authentication. Since you're on LAMP, you can configure it on Apache with mod_auth_digest.
Since you are trying to reduce costs, any ssl solutions will probably not be an option.
First it requires a signed certificate that cost a bit, the free ones is not always included in all web browsers.
Second to be able to utilize an ssl certificate your server ip must be dedicated to you. This is not the case in every cheap web hosting option. There are technologies that in the future will make it possible to host multiple ssl enabled sites on a single ip, but it's not here yet.
As mentioned before Digest Authentication is one option that doesn't require ssl certificate or dedicated ip.
It's a method of authentication that doesn't reveal your password even though everything else in the communication is unprotected.
In Apache this can be applied in individual directories by specific .htaccess files.
I'll repeat the previous link on mod_auth_digest.
This one is usually already installed on most servers so you won't have to ask you web hosting provider.
You don't always require root access to setup Apache to use SSL, but you will likely need to modify config files, which is either done thru your providers interface, or via files via a shell account. Either way you will need a server certificate; either self-signed, from a major company like Verisign, or one of the smaller free places like cacert.org. As noted by others, this does require a dedicated IP to your server or instance on the server.
I would recommend SSL first, but mod_auth_digest isn't a bad backup idea.
I have a WSS installation that's behind basic authentication/SSL (it's hosted at a public web host). I'm creating a sister site in ASP.NET, and am considering just running the credentials through and allowing users to log into the new system providing there is no 401 Not Authorized error returned.
Both are internet-facing applications that will be used by about 20-50 people.
What am I missing? I've never heard of this recommended before, but I don't see why it wouldn't work.
I can't see any major problems with that - you'll obviously want to make sure both servers are using SSL if you've got to send that over the Internet, but other then that it sounds like an elegant way to share credentials between applications.