I have a form for name, address, bank account, iban on my website.
When the user clicks the submit button, the data gets sent to my server via PHP and is stored in my MySQL database.
How can I prevent someone from grabbing the data while it is sent from the browser to my server?
Is an SSL certificate the right way? And if so, is an SSL certificate enough?
I found this website: www.selfsignedcertificate.com. You can create a certificate for free. What's the difference between a paid and a free SSL certificate?
How can I prevent somebody grabs the data while they get send from the
browser to my server?
SSL prevents MITM (Man in the middle) attacks nicely.
Is a SSL certificate the right way? And if, is an SSL certificate enough?
SSL certificate is the right way to provide a layer of security. BUT it is not enough. SQL Injection attacks are still possible. (Many other attacks also)
I found this website: www.selfsignedcertificate.com. You can create a certificate for free. What's the difference between a paid and a free SSL certificate?
SSL certificates are generated by a signing authority. So these signing authorities charge you to verify that you really own the domain you're claiming. When you yourself become the signing authority, the certificate becomes free, (because you dont charge yourself to verify that you are you :P). And, the 'free' SSL cert will show a red bar on all browsers, because the browser does not trust the signing authority, that is you. More on this here : https://www.globalsign.com/en/ssl-information-center/what-is-an-ssl-certificate/
I've just answered a very similar question a few minutes ago.
SSL is the standard. It provides:
Confidentiality: the data is encrypted between the client and the server and cannot be read by an attacker. Typically uses the RSA
algorithm.
Integrity: an attacker cannot tamper with the messages sent between the client and the server. Typically implemented using
HMAC
Authentication: the browser is able to check that the server it is talking to is actually yours, and not an attacker. Basically, the
server shows to the browser a certificate signed by the Certificate
Authority having issued the SSL certificate (e.g. VeriSign), that
proves its identity.
All that is assuming SSL is configured properly on the server's side:
up-to-date ciphers, no support for outdated ones, proper key length
(2048 bits or higher), etc.
You can use SSL Labs to check if your SSL configuration looks
secure. Also, be sure to enforce your users to use SSL, for instance
by automatically redirecting http:// URLs to https:// ones.
SSL Certificate is the best option to prevent someone from grabbing data traveling between browser and server. But Self-signed certificate is not a solution as it won't be trusted by most of web browsers because it is not issued Trusted Certificate Authority. To overcome from this issue, I suggest you to get SSL issued by trusted CA. You will have to pay few dollars but it is worth investment. Big downside of self-signed certificate is, browsers will not consider it valid and will blow warning message to the users. It will not create great impression in users' mind.
As per the CAB Forum guidelines, certificate issued by CA should have minimum 256-bit encryption but you will not have such high encryption in the case of self-signed certificate. Paid SSL will be a good option instead of opting self-signed certificate. You can read this SSL FAQs to solve more doubts on SSL Certificates.
<form name='form1' method="post" action="nextpage.php">
<input type="text" name="t1" value="firstname">
<input type="text" name="t2" value="secondname">
<input type="submit" name="submit1">
</form>
nextpage.php
<?php
echo $_POST['t1'];
echo $_POST['t2'];
?>
Related
I deal a lot with self-signed SSL certificates as I deploy the systems in offline environments. The problem is that for example Chrome users has to deal with "dangerous site errors" etc, also if I want to even use GuzzleHttp library for connecting to any other service I have to setting secure to none. What's the best way to deal with it?
If you have a Selfsigned certificate this can be made trusted to the specific system that you use. If others from your office uses it then they may need to add this Selfsigned certificate as trusted by adding it to their system certificate store to make this trusted.
When it comes to office environment it is better to contact the Administrator and add the certificate to all the systems (certlm.msc in run for local machine / certmgr.msc for current user) so your colleagues won't get this dangerous site errors.
I have a SSL enabled eCommerce website which uses cURL for payment processing. Everything is running well but recently I learned about "CA Public Certification Bundle for cUrl" that its a good idea to use it for cURL connections.
If this is true than can someone tell me how or how is it better/different than using the standard SSL?
Doesn't the SSL already provide some kind of certification for all connections?
Any HTTPS client connected to an HTTPS server will get its certificate (in fact, it can be a certificate chain). This server certificate must then verified by the client to authenticate the server.
This is normally done by using a number of CA certificates that are configured on the client as trust anchors (i.e. this is what you trust in advance, before encountering the server certificate). The client tries build a chain between the last element of the server chain and one of the CA certificates in its trust anchors. If there is such a valid chain the server certificate is trusted.
A "CA certificate bundle" would be a set of trust anchors. You can build your own by looking for CAs you're willing to trust, or you can use an existing bundle. Most OSes or browser come with an existing bundle. cURL in itself doesn't but it can rely on a pre-defined location (set at compile time) or it also suggests to use the Firefox bundle (via a conversion mechanism). (You can override default setting via extra options, on the command line or via the API.)
Certificate Pinning (which you also mention) has nothing to do with a CA cert bundle. In fact, it's almost the opposite. Instead of relying on 3rd party trust anchors (the certification authorities), you explicitly "pin" a set of server certificates you know as directly trusted. They're not used to verify other certificates, instead, you compare the certificate you get with the exact certificate you're expecting for that host (or at least you compare public keys). This is more like having a reference mapping from server name to certificate (or to public key) and comparing what you get from that host with the reference you have. Of course, this can only work for a reasonably small set of certificates in practice, unlike the CA (PKI) approach which is designed to let you authenticate parties you have never encountered before (via a 3rd party: the CA).
How is it better/different than using the standard SSL?
Doesn't the SSL already provide some kind of certification for all connections?
Using a CA certificate bundle isn't different than using "standard SSL", it is what's commonly used for SSL/TLS connections. You often don't see it because that CA bundle is often supplied with your client (or with the OS).
Note that strictly speaking, this is orthogonal to SSL/TLS itself, which mainly just says you should authenticate the server. Certificate verification (the PKI way, via CA certificates) is defined in a different specification, also complemented by a specification on how to verify the name in the certificate (and the HTTPS specification of course).
Found a great answer here. The comment above really helped. The exact keyword I was looking for was "Certificate Pinning".
Using this page: Wamp2 and "The ordinal 942 could not be located in the dynamic link library LIBEAY.dll"
I was able to setup SSL on my wamp. It works nice, especially after I provide the server certificate (server.crt) to an user. If not, they will have an "certificate not trusted" error. It is possible to reject those who are not using SSL certificate?
Thank you!
If the client displays a "server certificate is not trusted" message, that's because the server certificate you have installed is not signed by any authority the client knows about. Likely you're using a self-signed certificate. When you add this certificate to the trusted certificate store on your client, the client now trusts this certificate and does not display the warning anymore. It's not that "the client uses a certificate", it's that the client doesn't complain about the server's certificate.
You have no influence over this process at all. The server offers its certificate, and the client trusts it or doesn't. The server doesn't know this. If the client continues its conversation with the server, that pretty much implies that it trusts the offered certificate. Whether that is because the user approved it manually or because the client trusts the certificate otherwise, the server doesn't know.
There's also the concept of client certificates, in which a client identifies itself to the server using a certificate. This is badly supported in todays client software though and probably not what you're looking for.
Is it possible to authenticate a web browser using an ssl certificate.
Say i store a private key in my application, is there any way to read a key from a browser and try to authenticate based on that?
You can authenticate a browser/user using SSL/TLS client-certificate authentication.
The client certificate must be requested by the server, so you'd need access to the server configuration (not just installing some PHP code on a shared server). This is done at the SSL/TLS layer (in fact, the mechanism is not specific to HTTPS): the server requests the client-certificate during the SSL/TLS handshake (sometimes via a renegotiated handshake). In Apache Httpd, this is typically done via SSLVerifyClient (although you'll need to specify other options too).
The server will then verify the certificate against the CAs you've configured it with (possibly your own, and possibly independent of the CAs used for the server certificate itself). (Alternatively, you could disable certificate verification at the server level in some cases, and have the PHP application do it, but this is a bit more advanced and you'd need to know what you're doing.)
You can access the client certificate from your application and obtains its Subject DN (or alternative names), to identify the client.
It's not clear whether you're after identifying a browser or a user. In the end, everything goes through the browser anyway, but client certificates tend to be allocated to users. Users would have to install that certificate into their browser.
EDIT: For further details, it would help if you could clarify your question and what you intend to do with this.
Is it possible to authenticate a web browser using an ssl certificate.
Say i store a private key in my application, is there any way to read
a key from a browser and try to authenticate based on that?
Firstly, strictly speaking, there's no such thing as an "SSL certificate", since multiple types of certificates can be used for SSL/TLS, and some of these same certificates can also be used for other purposes than SSL/TLS. Typically, "SSL certificate" means "X.509 certificate in the context of SSL/TLS".
Therefore, authenticating a web browser using an SSL certificate implies doing it at the SSL/TLS layer. (There have been attempts to implement message-level security using X.509 certificates at the HTTP layer, but they're not widely supported by browsers.)
Secondly, the private key is held by the remote party that you authenticate. The local party that authenticates the remote party doesn't see any private key. If you (as a server) want to authenticate a web browser, it's the browser that needs to have the private key, not your (presumably PHP) application. In this context, it's not quite clear why your (PHP?) application would have/need a private key if it's the browser that you want to authenticate.
What your verifying application may need (if it's not done by the server itself) is a CA certificate to be able to verify the client certificate it is presented with (or at least some form of trust anchors with which to verify the client certificate). There's no private key required here, just public keys and certificates, unless you want your application to be a CA too.
Indeed, you could have your application be a mini CA. It could make the browser generate a key-pair and send a certificate request to the server (there are mechanisms to have a web page make the browser do all that). Then the server would generate the certificate and make the browser import it back against its private key. Subsequently, the browser could use this certificate for authentication with that server (or other servers that would recognise these certificates).
No, you cannot do that.
There is some development going on, and a few day ago W3C has made a proposal for a encryption standard.
You can however put a key in a cookie and use that to identify. This is the default PHP session id behavior.
Quick question. Does SSL totally prevent session hijacking/fixation? Thanks.
No. Hijacking may be done for example in these scenarios:
Hacked CA root signs invalid certificates. The certificate may be used to stage man-in-the-middle attacks.
Hacked domain owner e-mail inbox makes it possible for the hacker to buy a domain-validated certificate.
Bad key policies may make it possible for an attacker to gain the private key for the certificate.
A local attack on the client computer may make it possible to see what's going on in the system, including reading session cookies, intercepting SSL traffic, injecting false CA root certificates in the systems keychain and so on.
An intrusion by an attacker on the server may be used in any number of ways to intercept traffic, reroute packets or read important system files.
The client library must validate the SSL certificate and deny sessions with invalid or expired certificates, otherwise it's as trivial to intercept the HTTP traffic as if it where in plain text.
It may be possible with an XSS attack which gives the cookie away. Web browsers should try to protect against this but you never know if all components works as expected.