I am a developer and have a site that has some sensitive information that needs to be online for people in different cities. The data is not of much use for most people (no CC numbers, or marketing plans)
the server has a LAMP stack.
I have used .htaccess on the server and the site has a web based sign in screen as well.
Two questions:
What is the best way to guarantee the data is secure (within reason)?
How can i check there has not been a security breach?
thanks
You can install SSL cert. and redirect all the HTTP calls to HTTPS (using .htaccess or httpd.conf).
There are many possible security breaches such as: code injection, sql injection etc. You can use services like this and this in order to check your site's security.
Related
I'm building a serverless web application. My HTML, CSS and JavaScript are in a public storage location which my domain example.com points towards.
When my users navigate to my domain using their browser, their browser will GET these files from that location and then there is no further communication with example.com. The JavaScript application runs in the browser and communicates with a separate backend via HTTPS (in my case AWS, but could be e.g. Azure, Kinvey, BlueMix or others).
It therefore seems to be that there is no reason to encrypt the communication between my users' web browsers and xyz.com i.e. I don't need to provide https://example.com, and my doing so would provide no security benefit.
Am I correct?
The reason I ask is that I found at least two static hosting services which offer SSL support:
https://www.netlify.com/features#security
https://surge.sh/help/using-https-by-default
I am aware of the reasons for wanting HTTPS (described in the second link above and also at https://levels.io/default-to-https/ ...) but none of this seems to apply to my situation.
I believe this is a serious question because more applications will be built in this manner (the folks at http://serverlessconf.io/ certainly think so), and as long as the channel to the actual backend is secured there is no reason to secure the channel to what is essentially a read-only hard disk.
If you don't secure communication with example.com then a man in the middle attacker (eg a rogue wifi hotspot) could modify the html and JavaScript loaded by users.
One way to use this would be to change the JavaScript so that subsequent API requests are sent to attacker controller servers instead of yours, compromising any credentials or information transferred.
I am currently developing a web application to allow customers to place orders.
The way I have choosed to handle the application structure is to split the app in two sub-applications:
1 backend application (the API) that serves only json content
1 front end application (AngularJS in my case) that takes an API url as configuration and serves user content
Now on the server, what I have done for testing, is creating 2 virtual hosts:
app.com
api.app.com
and linked the API to the frontend app.
The problem is that everything will be served over https and, in the current setup, I will need to buy either 2 SSL certificates, or 1 wildcard certificate.
The second solution would be to create a subdirectory on the frontend app (let's say /api) and copy the backend app into it. The advantage would be to get only one single SSL certificate and have everything on the same directory; the /api would be an .htaccess redirect to the backend api.
I think that the "cleanest" solution would be to split the two apps completely and get a wildcard SSL certificate for both, but I'd like to hear if someone have some experience whether one solution is better than another.
The advantage of combining is that you will get to avoid CORS. CORS isn't that bad, but it's another complication. That being said, if you want to expose this to the outside world (allow other web pages to use it), you might want to go through that process anyway.
If you aren't looking to actually expose your API to third-parties, but just keep your layers separate, than I would either look at combining, or even proxying. I've used this architecture to put my services completely behind the firewall, and use mod_proxy or the like to serve my API through my web server. This is useful as it limits the exposure of your API, and solves CORS issues in one go.
If you really want to use SSL between your web server and your API server, you can do a self-generated client certificate between you web-server and your API server.
is it usually advisable to install a single domain ssl certificate to the main domain --domain.com and use .htaccess to go in and out of ssl or to a subdomain such as --secure.domain.com. I know there are different needs for different sites but I'm asking for the average websites needs. -eg a website owner wants a secure shopping cart for their customers should they use domain.com/secure and force ssl or have ssl on secure.domain.com
I would install it on the main domain name. It sounds better to put it on a sub domain but then you technically have a whole separate website to maintain and this could be a negative rating for search engines. Also, need another SSL certificate if you want anything secure on your main site.
Depending on your back end technology (i.e. - .NET, ASP, PHP), it only takes a couple lines of code to check the page request and redirect the user to the proper page desired. For example, if a user goes to [http://www.domain.com/secure] you can redirect the request to the proper secure page (https://www.domain.com/secure) and vice versa.
.htaccess is an older technology and can be very cumbersome to use.
I'm running a dating site and not using SSL at the moment.
I've noticed major sites like facebook and twitter do not use https for login but just use plain old http, is there really any advantage to https-ing my site or it is only for cc transactions or so ?
thanks in advance.
Actually, facebook does use https for its login:
<form method="POST" action="https://login.facebook.com/login.php?login_attempt=1" id="login_form">
as does twitter:
<form method="post" id="signin" action="https://twitter.com/sessions">
You'll notice they don't use https for the page that displays the signin form. That's because it isn't necessary.
However, it's a good idea to use ssl the login itself if you can, if only because so many users employ the same password for all sites.
One solution, which I'd like to see more sites employ, is using OpenID/OAuth for login instead of requiring a username/password.
SSL encrypts the traffic between the browser and the server. So virtaully anything you want to be secure needs to be ssl'ed. Google search is even doing it so poeople can't have their search terms intercepted.
Its just the case of what YOU want secure, and if not having certain parts of your site secure will keep wanted customers away. I would think a dating site has a lot of personal demographics information that some people might want secure... just my 2 cents.
SSL is used only when transmitting sensitive data between browser and server. It's fine for major sites like facebook and twitter to use http (as long as the data is not sensitive). Most website use SSL for their login page. SSL also used by payment gateway to safely transfer payment information through the wire.
And by the way, http is not "plain old" and https is not new trend either :)
If your users are providing any sensitive data, ssl prevents it from being intercepted by a third party. If you don't use SSL, you should assume that some third party can see everything that every one of your users does on your website. If you are comfortable with them seeing this information, then keep it plain http, but if you don't like that thought, go https.
Another benefit of ssl is that it allows the use of Strict Transport Security, which not only forces https on all site activity, but also prevents a man in the middle from spoofing your site to a user and making them think they are accessing your site. Details here: http://en.wikipedia.org/wiki/Strict_Transport_Security
I work at a major ISP and am infatuated with one of your online members. By sniffing your packets, I can find out when and where she's meeting another member, rewrite the packet to change the location so the other guy doesn't show up, and then make my move.
You decide whether that's acceptable to your users.
Https is useful to protect the credential (user/password) , but it increases the network load and requires more CPU resource (encryption). Thus, it is common to use only for authentication.
Https ,with server certificate protects again phising.
Banks uses end to end application
We have a multi-tenant website where we use a wildcard SSL cert to give people a subdomain to our site. Some of our customers would like to use their own domain, but I'm concerned about how we would manage each customer's certificate as our business grows. Currently the certificate resides on the web server, which means loading all of the certs to each web server as we add them.
I'm aware we could introduce a dedicated SSL device in front of the web servers, but are there other options to improve the management of these certificates?
I'm a Microsoft Technical Evangelist and one of my partners had exactly the same challenge.
I have created a sample source code that automates and manages SSL certificates for multiple domain bindings using a new IIS 8 (Windows Server 2012) feature called SNI, which is a kind of SSL hostheaders.
All you will need to do is to reuse my code (it's quite simple) and upload your custom SSL certificates to the blob storage, or you can write your own provider to fetch custom domains and certificates from your database.
I have posted a detailed explanation and a sample "plug & play" source-code at:
http://www.vic.ms/microsoft/windows-azure/multiples-ssl-certificates-on-windows-azure-cloud-services/
You could make your clients deal with their own certificates and make them run there own https site. They can serve a page containing a single frame with your content (over https). The users will see their domain and their certificate and the browser will load the frame without complaining as long as the frame contents are also loaded over a valid https connection. I created a quick an dirty test page so you can see it in action.
This solution will 'break' the address bar as it will keep the url of the page containing the frame. Depending on the type of site you're running this might be a showstopper.