SSL Implementation Security FAQ is about implementing SSL in web and desktop applications. This FAQ doesn’t cover issues directly related with SSL/TLS. Only covers issues related with implementing SSL in applications.
Most of these are common mistakes during the implementation of SSL in the applications. These recommendations are especially critical for e-banking, e-commerce and similar websites.
No it is not. All communication during the authentication and after authentication should be over SSL.
There are several reasons:
- After login authenticated pages might include private information;
- To able to keep you logged application should use some sorts of session cookie. This can be over URL or in HTTP Headers but it doesn’t matter where it is an attacker can see it and use it. Which will cause an attacker to hijack active session and use. This can be done in several ways. If application uses a session hijacking protection XSS Tunnelling can help an attacker to bypass this protection.
- An attacker can change responses in the authenticated section and can show a login screen and may require user to enter they password again and steal their passwords. This can be done by injecting a JavaScript to HTTP responses.
Previously this mistake has been done by Google Gmail.
No, that’s just a terrible idea and almost pointless. This is common mistake has been done by several major websites such as Godaddy.
- An attacker can modify response before arrives to user and then inject a piece of JavaScript code to steal credentials before user submits it. MITM possibilities are endless there are several ways to do nasty stuff in this situation.
- User will not know that they are sending the form to HTTPS URL thus they might believe something is wrong or even worse they might get used to it and fall for any phising attack over HTTP.
- Website users should stick with one URL to login and form URL and the target URL should be over SSL.
Disable HTTP access to the domain, don’t even redirect or link it to SSL. Just inform the users this website is not accessible over HTTP and they have to access it over SSL.
This is the best practice against MITM and phising attacks. This way your users will be educated that application never accessible over HTTP and when they come across to a phising or MITM attack they will know something is wrong.
One of the best ways to protect your application against MITM attacks and phising attacks is educating your users.
You should always mark your cookies as secure. Otherwise you’ve got a big security risk. Marking cookies as secure will prevent browsers to sending cookies over non SSL connections.
An attacker can force someone to do a connection over HTTP to steal their cookies and generally cookies carries of session critical information such as Session ID. Thus preventing this attack and marking cookies as secure is quite important.
Your application should not trust non-valid certificates, if you allow this MITM attacks will be successful against your application. Depending application features and requirements this can lead Remote Code Execution easily.
I’ve seen this problem in many of bespoke applications. Generally developers leave support for non-valid certificates for testing purposes and deploy it like that. By default many of the underlying API won’t accept connections to non-validated certificated applications, it’s a good idea to keep it like that.
Yes you should, depending on the functionality it’s quite possible to do remote code execution because of non SSL connections.
Two following actions are highly vulnerable to this problem:
· Auto-update functionality of the application,
· Rendering a remote HTML in local-zone with Web Browser Control or in a similar control. Don’t forget every application is vulnerable to Cross-site Scripting if they are not over SSL!
Firefox was vulnerable to this, another similar one identified in a Vista Gadget.
You might think putting a simple order form without a submit but designed to print and post over non-SSL could be secure, but guess what it’s not secure at all!
An attacker can inject a piece of JavaScript to this request, can log every single keystroke and send them to attacker’s website automatically. Thus you shouldn’t put an order form or any similar form which requires private information such Credit Card details, address, phone numbers etc.
In a similar way putting an offline order form such as PDF file to over non-SSL URL is another bad practice since attack can send this PDF file on the fly and modify post address or similar information to get benefit out of it.
This is common problem with banking websites where they provide these kind of forms over non-SSL connections.
No you should not. Main reason behind of supporting these ciphers is supporting old browsers but supporting old browsers is a terrible idea since the internet is full client-side exploits for old browser.
Which means a user with an old browser is potentially infected by a malware already. Remove support for weak ciphers from your web server.
Paypal announced that they don’t support old browsers any more.
No you should not do that. This is a process where web server supports connection with weak ciphers but application informs that user can not continue unless they change their browser and come establish a new connection with a stronger cipher.
These ciphers are called as “Weak Ciphers” because they feasible crackable with a decent computing power. Basically a data transmitted over weak ciphers are highly vulnerable to cracking. Therefore an attack can sniff this data then crack and view transmitted data later.
This is dangerous because depending on the application, it might transfer cookies in these weak cipher used connections, (obviously including cookies those marked as secure). Even though application will inform to user that they can not keep using application this first request will send HTTP request over non-SSL connection and an attacker can see this request.
An attacker can be for victim to do this first request over another website in many different ways such as iframe. It’s enough for an attacker to modify one HTTP response on the fly to accomplish this.
If your application requires a custom ActiveX and if your ActiveX allows you to do something more privileged than normal a browser such as reading local files, executing certain OS commands then you should limit your ActiveX execution to only your domain.
If you limit your ActiveX only for your domain but not only for your domain and HTTPS access then an attacker can do MITM attack and can call this ActiveX over your domain and can use all functionality of the ActiveX. Obviously this can lead vulnerabilities such as arbitrary file reading from local file system, code execution or information leakage.
You should restrict your custom ActiveX applications to your own domain and SSL. This will stop this attack.
There of lots websites providing hash signatures of files, this is good for especially confirming the integrity of file against file corruption and similar issues. But if you put your files over HTTP then you should know that those hash based signatures are meaningless from security point of view.
An attacker can change file as well as the hash signatures on the fly.
Some web applications require adding them to users Internet Explorer’s Trusted Zone list. This allows them to do more privileged actions such as installing ActiveX controls or writing local file system.
This is bad practice anyway and you shouldn’t do this unless you have to. If you have to this you should inform users that they should add your website to the trusted list with HTTPS not HTTP.
Any user with an HTTP entry in their Internet Explorer Trusted Sites list is vulnerable to remote code execution attacks. It should be noted that since IE 7 Trusted Zone a lot more secure than IE 6 and may not allows remote code execution by default.
HTTP/1.1 RFC 2616 clearly states that clients should not include HTTP Referrers to connections over SSL:
Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
Reasons are:
- Leaking sessions over URLs - critical;
- Leaking private information in URLs.
- Some 3rd party add-ins for browsers such as Not Public Yet leaks SSL URLs by sending current URLs to their server over HTTP. This is not the very same thing but exactly very same affect.
This means when a user browses a web application over HTTPS, this add-on will send current SSL URL to their server over HTTP. Therefore attackers can see this URL and this is clear breach of URL privacy in SSL.
Browsers pops up a warning box when a page calls HTTP resources over an HTTPS URL. This generally happens if you try to include external JavaScript or Flash resources from an HTTP URL. This is bad because an attacker can do MITM to HTTP content and execute JavaScript in the same domain. This is very simple especially if this warning causes because of an external JavaScript resource.
Depends on the details on the warning, but simply No you should not. This generally indicates one of the following problems;
- SSL Certificate is self-signed;
- SSL Certificate is expired;
- SSL Certificate has been changed;
- Someone is doing MITM attack, which causes you to get not correctly signed SSL Certificate;
- Some of the content in the same page coming over a non-SSL channel.
All of these are not good and you shouldn’t trust them.
No, if you consider the transmitted data between you and the visitors as private you should use SSL.
Most of the following component should always be over SSL:
- Authentication and after authentication pages;
- Contact Forms;
- Search forms and result pages.
Search and results pages maybe looks like overkill to you but imagine you open all of your google searches to public. I bet you don’t want to know people about your deep obsessions, health status, your applications error messages, your home address (google maps), your phone number etc.
No, it’s also about identification. You can use SSL to prove who you are by getting certificate from a trusted CA by common browsers. Therefore your visitors can check your company name and details by looking into the details of your certificate.
Even though this is not bullet proof solution because of social engineering someone else can come with similar domain name and valid certificate and can carry out a phising or similar attack, even though this is another layer to protect your application against phising or similar attacks.
Also you can use SSL to identify a client to the server.
Yes you should, this is the best practice you can do in SSL usage. Disable port 80/HTTP access to your web server. It helps to prevent phising attacks, will educate users to stick with SSL all the time and will protect you against several wrong SSL implementations pitfalls.
Yorumlar
Insecure Trends in Web 2.0
Siteyi takip edenlerdenseniz yakın dönemde 
Cuma ve Cumartesi RIATalk's
