I am pretty sure that similar questions have been asked before but I didn't manage to find any (maybe I am using the wrong terms).
I have an unsecure web app (built in Laravel). All communication between the frontend and the backend goes through http. Now, I want to switch to https. As far as I know, there are two ways I can do this.
The first is to configure the server (the one that hosts the app) to accept only https requests. If I do it this way, the communication between the client and the server will be encrypted and I won't have to change anything in my app (is this correct ?).
The second way is to configure my app to accept only https requests. If I do it this way I will have to make some changes to my application code.
Now I want to ask, are both ways equally secure ? Which way is prefered and why ?
Several things are mixed up here I'm afraid.
You can only turn on SSL on your web server (Apache, Nginx, etc). You need a server certificate, and you have to configure your web server to be able to receive https (ssl) connections. As for how exactly to do that is beyond the scope of this answer, but there are lots of tutorials you can find. You have to do this first.
When your web server is configured to support SSL, you want your web application to only be accessible over HTTPS and not plain HTTP. The purpose is that on the one hand, users who don't know the difference are still safe, and on the other hand that attackers can't downgrade a users connection to insecure plain HTTP.
Now as for how you want to enforce HTTPS for your application, you really do have two choices. You can have your web server handle plain HTTP requests and redirect them to SSL, this is an easy configuration both in Apache and Nginx. Or you can add redirects to your application to handle the scenario when it's accessed over plain HTTP and redirect your user with something like a Location header to HTTPS.
Security-wise, it doesn't really matter whether it's the webserver or the application that makes the redirect, from the client's perspective it's the same (mostly indistinguishable, actually). Choose the option that you like best. There may be for example maintainability reasons to choose one or the other. (Do you want to maintain redirection in your application code, or have your server operations add the redirect headers, etc.)
Note though, that either way, your application may still be vulnerable to an attack called SSL Stripping, and to prevent that you should always send a HSTS response header.
Related
Is it possible to use the same nodeJS server for two/three different domains (aliases)? (I don't want to redirect my users. I want them to see the exact URL they typed in the address bar. However, all three domains are exactly the same!)
I want my users to be logged in on all three domains at the same time, in order to avoid any confusion.
What is the simplest way to do this and avoid cross-domain issues?
Thanks!
If you mean that all domains will serve the same nodejs app then Yes you can do that.
but if each domain should open a different application then you must have a reverse proxy running on the server to handle and manage the sites/vhosts.
You may install nginx and use it as reverse proxy server or look for http-proxy a library for nodejs.
If you would like to manage the vhosts in your app you can look for vhost middleware for nodejs and use it
Choose one of:
Use some other server (like nginx) as a reverse proxy.
Use node-http-proxy as a reverse proxy.
Use the vhost middleware if each domain can be served from the same Connect/Express codebase and node.js instance.
This is a very broad question. Moreover, it is generally a pretty bad idea, SEO-wise, to have multiple independent domains that each serve the same content.
Logging in is generally either done through Cookies, or through extra parameters in the URL. Cookies are always domain-specific, for obvious security reasons. If you want to ensure folks will be logged in to all the domains at once, you can create an internal purpose-driven domain to handle authentication (without such domain showing in URL bar, and only being used for HTTP redirects, effectively); such domain will store the login state for all the rest, and the rest would pick up the login state through such purpose-driven domain (through HTTP redirects).
In general, however, this sounds like too much trouble. Consider that, perhaps, some users specifically want to use different domains for different accounts, so, you'll effectively break their usage if you mandate that a single login be used for all of them. And, back to the original point, doing this is pretty bad for SEO, so, just don't do it.
I am making a self-hosted app, and I would like to require HTTPS since sensitive informations might be sent. How can I tell if client is using a secure connection ?
I could use javascript in the browser, but this wouldn't be secure (since an attacker could just bypass this)
The node server might be running as HTTP, but behind a secure nginx/apache proxy.
Optionnally, I would need to enforce this rule every time someone is making a request.
Well you can configure your web server so it redirects the user to the HTTPS url from a HTTP url. Apache htaccess is commonly used ensure that a website is accessible only over HTTPS. See this link for more information: http://www.askapache.com/htaccess/ssl-example-usage-in-htaccess/#redirect-http-to-https
I have a node.js app.
I have it configured to redirect everything to https from http.
but i was thinking if the extra work to make the normal pages visible on http and the logged in pages only visible via https, would be worth the effort.
does having both in my app expose any security holes?
Yes multiple, including:
Cookies are shared between the two sites unless you remember to include the "secure" attribute each time you set a cookie.
You are vulnerable to MITM attacks (e.g. replacing a "login" link on http to either keep you on http or redirect you to another site instead).
Resources need to be loaded over https on the secure site or you will get mixed security warnings. It's easy to miss this when running mixed sites.
Users will not know whether pages should be secure or not.
Can forget to renew cert and/or see cert errors but this should be more obvious if whole site is https.
Cannot use advanced security features like HSTS.
And that's just off the top of my head.
Go https everywhere and redirect all http traffic to https. Unless you've a good reason not to.
There are other benefits too (user confidence, looks more professional, small SEO boast, Google sees this as two sites, easier management of sites, Chrome will soon block access to some features like location tracking on http, cannot upgrade to HTTP/2 until you implement https... etc.).
I have a CppCMS based application and I cant use IIS's FastCGI connector as
it is broken for my use thus I want to try to
use the internal HTTP server designed for debug purposes behind IIS.
I it is quite simple web server for an application that handles basic HTTP/1.0 requests
and does not care too much about security like DoS, file serving and more.
So I'd like to know if it is possible to use IIS in front of such application such that
it would:
Sanitize all requests - ensure that they are proper HTTP
Handle all DoS issues like timeouts
Serve the static files.
Is this something that can be configured and done at all?
I would suggest this is the wrong way of doing this. I would use a web server like Nginx to proxy the requests through to backend server. It is very configurable and you will find a lot of articles with doing it to Apache.
We just did something like this. You want the URL Rewriter module. You can use it to sanitize the URLs, however, it isn't going to sanitize the payload. Which is to say, you can make sure that the URLs that hit your box are very specific ones, e.g. not attempts to hits CGI, but you can't use it to make sure that the contents of an upload are safe.
ModSecurity is out for IIS now, it can handle lots of the security related issues.
my question is related to hypertext protocol.
what is the requirements from my side to be able to use HTTPS instead of HTTP in the areas where a user will enter confident information or when there is a registration process.
Thank you.
You need a certificate (you can buy one, which are usually identified by browsers, or create a self-signed certificate, which will trigger a warning on browsers) and a server able to run HTTPS. HTTPS capable servers allow you to define which pages are served via HTTP and which via HTTPS.
HTTPS IS NOT authentication, by the way, it only encrypts communications to prevent eavesdroppers reading what's being sent between the server and client.
You can use any authentication method over HTTPS, but you need to provide it (be it HTTP Auth or something in your application.)
There isn't much more to say given your ambiguous question.
Primarily, you need to configure your webserver to use https; this in turn requires that you have a server certificate. You can either create your own server certificate, or you can buy one from one of the Certificate Authorities. The latter will cause browsers to trust that your site is genuine (whereas in the case of one that you created yourself, a man-in-the-middle or phishing attack might happen from the viewpoint of the browser).
How to configure your server precisely should be discussed on serverfault.