Question: Customer's of few web projects from scratch (which already completed and launched) want to use HTTPS. Server side guys will install SSL Cert.
Apart from the redirection from HTTP, Do the programmer need to do any changes in programming or forms or database?
Do the programmer need to use any type of data encryption or any parameters during the form submit while using https?
Type of projects migrating from http to https
eCommerce
Vehicle Rental Management
Project Specs
Responsive
PHP, HTML, CSS
MySQL
Jquery
PayPal
References find in SO
https://stackoverflow.com/questions/16200501/http-to-https-apache-redirection
https://stackoverflow.com/questions/2559620/conversion-http-to-https
https://stackoverflow.com/questions/10489895/http-to-https-through-htaccess
But from the above never find an answer to my question.
What you need to change in the webpages:
Scripts (js) and Iframes must be loaded directly from https (whitout redirect): scripts uri must be relative or start with "https://". If not, scripts and iframes will not load
Forms must have an https target to avoid security confirmation
Images and css must be loaded directly from https to avoid loosing the https indicator
More information: https://developers.google.com/web/fundamentals/security/prevent-mixed-content/fixing-mixed-content
See also: HSTS, CSP upgrade-insecure-requests
Do the programmer need to use any type of data encryption or any parameters during the form submit while using https?
HTTPS takes care of everything. It encrypt urls (Note: the domain name is not encrypted), POST and GET data. (It's a best practice to avoid sending confidential data using GET, because they may be logged in various unsecure places)
The best for a migration is to migrate all webpages. Having to maintain http=>https redirects for some and https=>http redirect is complicated, error prone and insecure.
Related
I need to simulate from within an iframe in our site, which uses https and it's loaded only once upon the authentication on our site, the authentication into another site, which only uses http.
How can I do that?
We first tried loading into the iframe a page of our site from which the login form for the remote authentication is automatically submitted with javascript. This cannot be achieved because the http request from the form is blocked by the browser for security reasons. I must clarify that if we use http in our web too, the authentication is done without problems.
I'm not sure if using file_get_contents() will do the trick, because it's not a simple static page what we need to display. We need to keep any data from the remote login (cookies, etc) in the browser so that we can access other parts of the remote web (once I've signed in) from other places of our site. As far as I know, file_get_contents doen't provide any header.
Another alternative I've also considered is curl, using CURLOPT_RETURNTRANSFER=true and CURLOPT_HEADER=true and trying to manually set any cookies I get in the header. I'm not sure if keeping the session implies more actions though.
As the title says, I intend to create a web-app that uses an iframe to lock all my web sessions within the server itself. Thus when accessing from a client, i can still visit other sites, while being in the main browser page.
Since the website itself is making the connection through the page, for security wise, am I technically going through a VPN since the connection goes like
Client -> Server Hosting the Main Webpage -> facebook.com
Will my connection to facebook.com come from the client, or the server?
And is this type of solution even feasible?
Will my connection to facebook.com come from the client, or the
server? And is this type of solution even feasible?
If you're just using an IFrame, then the request will come from the browser.
If you've made a proxy handler on your site which makes a back-end HTTP request, then it will come from the server. E.g. the handler could take a query string parameter like url - http://example.com?url=https://facebook.com.
Three relevant security issues spring to mind with this approach.
Server-side Request Forgery - ensuring an attacker cannot browse to things in your DMZ like http://127.0.0.1 or http://192.168.2.4.
X-Frame-Options - lots of sites use this header, or the new CSP2 frame-ancestors header to prevent themselves from being framed. You could though strip out such headers in your proxy code.
Browser trust. If I'm on your website at http://example.com (or even https://example.com), how do I know I'm logging into Facebook. There is no assurance other than the fact the IFramed page looks like Facebook. Any case, if you're proxying the request to Facebook, how do I know you're not capturing my credentials?
If this is just for yourself, then you can ignore points one and three somewhat, however you have no way of verifying the security yourself using your browser, you'd have to trust your server-side code, and how will you be aware if a MITM downgrades your connection from HTTPS to plain HTTP (sslstrip).
The rest of it is feasible, ignoring the security issues. Handling session cookies and the like will result in some complex code (particularly if you're going to deal with certain cookies being set in JavaScript too because they'll all share an Origin with your main site's domain).
I have a site running WordPress on Apache server and I am attempting to provide both HTTP and HTTPS connections via the same site. I want to allow connections over HTTP without forcing a redirect to HTTPS, unless the client is connecting initially via HTTPS then I want all subsequent HTTP requests to be forwarded to HTTPS to avoid issues with CORS and unsecured content warnings.
I am having some trouble turning up results on how to effectively do this with mod_rewrite alone. Most solutions I find try to force the connections to redirect to HTTPS regardless and will not allow an HTTP connection or vice versa. I have tried a few mod rewrite conditions including making use of the referer string but none seem to work thus far. I must be missing something because I feel that this is indeed possible but I and my search engines alone are stumped.
Maybe I'm just doing something wrong or is this kind of functionality beyond Mod_Rewrite?
I was thinking to use a PHP script but was worried it wouldn't work for some static files since WordPress doesn't handle those requests.
Update:
I have made a php script to detect the version. It sets a cookie which expires in 20 seconds from being set, this is read by Mod_Rewrite and if set it redirects the URLs to HTTPS. This works for most of the subsequent requests of an initial HTTPS request. A few URLs seem to be unaffected by it, not sure exactly why as the cookie hasn't expired by the time of these file requests and the particular rules are before the static file bypass rules in the htaccess file. At any rate that was easy enough to fix by setting the file urls to protocol-less versions.
Some third party sites need domains rewritten though, as they serve https from other domains. On that note I don't think this is actually possible without buffering the whole page and actually re-writing the URLs.
It is possible to detect the initial connection but this must be done using Server Side code, like a PHP script. Then using the detection can be done at Mod_Rewrite level.
Add in the WordPress constraint and things get complicated.
WordPress isn't built to facilitate one install with both protocols allowing access to content. So to accomplish this would require a custom plugin using the detection mentioned earlier, and instead of using Mod_Rewrite to direct requests on the server, we have to buffer WordPress output and logically replace/rewrite URLs in the page before they go to the user if and only if the initial connection for the page is in SSL.
There is only one plugin I have found which does something similar to this, however it doesn't do dynamic detection only gives admin/editors a checkbox option to make a page SSL secured. The plugin is called WordPress HTTPS
Dynamic detection and redirection isn't something SSL was meant for anyways, it's either on or off, and most pages need it that way.
I was originally trying to provide both so I could use a self-signed certificate without worrying that users would get the "warning unsecured connection" messages from their browsers by forcing them to use only SSL connections.
So I'll be purchasing a cert or making a custom plugin.
tkausl is right, you don't really need to do mod_rewrite. You should be able to format links without the protocol and it will automagically select for you.
You can see that google does this with their hosted libraries:
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
*Note the lack of http: or https: this will follow the protocol requested by the user.
I have used SSL to secure my pages, but one of my scripts has stopped working.
I was using on page to show visit count on this website.
It was working fine earlier without SSL but now shows the error message:
blocked insecure content.
When using secure connection, all content should be loaded using secure connections. That includes images, scripts, iframes, stylesheets, swf and other media from both your server as well third-party ones.
Some browsers allows changes in configuration so they can fetch and display this content, but you can't force your users to change their configurations (especially for less secure one).
If this service does not provide it's api through SSL, you may have to change it for another one or resign from this counter on secured pages.
its a deliberate security feature to prevent a page looking secure which then uses resources from less secure sites.
See if you can host the script under your ssl domain, or you could proxy the response if its an api for example.
Be aware though that you are circumventing a security feature and you should be confident that you trust the resource.
This feature was enabled by default in Firefox 23 recently. That's probably the reason it stopped working now (Chrome has been doing this longer), but it's always been bad practice because of several security implications: if the page itself is protected from being tampered, it gives the end user a false sense of security if he sees the connection is encrypted with HTTPS. After all, the insecurely served script could still be tampered with through a MitM attack, and for example introduce password sniffing callbacks, or redirect form postback targets.
I know the general definition but I need more details on how to implement them in general and PHP in specific, and what exactly are the features I gain from them?
SSL stands for "Secure Socket Layer", and it's a method of encrypted HTTP communication (among other things). It encrypts the traffic between a web browser and a server, making it possible to send secure data without fear of eavesdropping.
SSL is a web-server level technology, and has nothing to do with PHP. You can enable any web server with SSL, whether it has PHP on it or not, and you don't have to write any special PHP code in order to make your PHP pages show up over SSL.
There are many, many guides to be found on the internet about how to set up SSL for whatever webserver you might be using. It's a broad subject. You could start here for Apache.
some webservers are configured to mirror the whole site, so you can get every page over http or https, depending on what you prefer, or how the webbrowser sends them around. https is secure, but a bit slower and it puts more strain on your hardware.
so you might implement your site and shop as usual, but decide to put everything from the cart to the checkout, payment and so on under https. to accomplish this, all links to the shopping cart are absolute and prefixed with https:// instead of http://. now, if people click on the shopping cart icon, they're transfered to the secure version, and because all links from there on are relative again, they stay there.
but! they might replace the https with http manually, or go on the unencrypted version using a malicious link, etc.
in this case, you probably might want to check if your script was called over https (_SERVER["SERVER_PROTOCOL"], afaik), and deny the execution if not (good practice). or issue a redirect to the secure site.
on a side note: https is not using ssl exclusivley anymore, tls (the successor to ssl, see rfc2818) is more modern
rule of thumb: users should have the choice if they want http or https in noncritical environments, but forced to use https on the critical parts of your site (login/cart/payment/...) to prevent malicious attacks.