Security Experts:

Busting Myths: Why SSL ≠ Application Security

A few months ago, I was at a round table luncheon with a few senior-level security and IT folks. I casually asked them what they were doing to secure their Web applications. They replied with full confidence, “We have SSL.” When I described, in detail, how hackers attack via Web applications, and how SSL doesn’t protect them against those attacks, they were shocked. I can understand that small website owners might not have an in-depth knowledge of security issues. But, these were senior executives from pretty large companies.

Attacking Web Applications via InjectionThis is more common than one would imagine or hope. With so many security issues - desktop security, network security, DLP, end-point security, identity management, mobile security, cloud security, application security, etc., security managers are overwhelmed. Except for the financial services sector, where there’s a bigger awareness of application security issues due to the sensitive nature of transactions and the fact that companies in this sector have been hacked the most through Web applications, professionals in other industries are suffering from a lack of knowledge.

There are many myths around application security, which I have dismantled in a series of audio and video podcasts. In this article, I am focusing on the key differences between SSL and Web Application Security.

What is SSL?

Technically, SSL stands for Secure Sockets Layer. In simple terms, typically if you see a seal from VeriSign (part of Symantec now), GoDaddy, etc., or if you see on the URL, https:// instead of http:// without the “s,” it typically implies there is an SSL for that site (although there can be some fake sites using these).

So, what exactly does it do? The SSL technology establishes an encrypted link between a Web server and a browser. When you are conducting transactions on a site (buying books on Amazon, for example), SSL ensures that all data passed between the web server and browsers remain private and not hijacked by a hacker.

To enable this link, a Web server of a business requires an SSL certificate. There are many vendors that can provide these certificates including Symantec, GoDaddy, Comodo, Network Solutions, and others. You will be asked to complete a number of questions about the identity of your website and your company. Your web server then creates two cryptographic keys - a Private Key and a Public Key. The Public Key is placed into a Certificate Signing Request (CSR) - a data file also containing your details. The vendor (also known as Certificate Authority or CA) will issue you an SSL Certificate. Your Web server will match the SSL Certificate with your Private Key which will then enable you to establish an encrypted link between your Web server and consumers’ browsers. Consumers don’t have to worry about the technical complexities, but they can click on the seal displayed on the website to see the details. There have been cases where hackers have copied an image of the Seal and posted it on their fake site. Most consumers don’t know the difference and don’t think about clicking on the image to see if it’s genuine or not. If you click on the seal and no details pop up for the certificate, it’s usually a bad sign. Typically an SSL Certificate contains the business’ domain name, company name, company address, the expiration date of the Certificate and details of the Certificate Authority responsible for the issuance of the Certificate.

With over 2 million sites using SSL, it has become an important element for secure transactions and is generally reliable to ensure that consumers’ data is not stolen. However, there have been recent cases where some of these SSL vendors have been hacked and hackers have been able to issue fake certificates, thereby causing an integrity issue with SSL certificates.

Web Application Security

While SSL is a great technology to ensure that consumers’ browsers are communicating to the businesses’ servers in an encrypted manner, and ensuring that these are legitimate businesses, it doesn’t prevent from the hacking the websites through vulnerabilities in Web applications. With over 97% of Web applications vulnerable, and over 75% of attacks occurring through Web applications (a lot of those sites have SSL), we know there’s a major disconnect.

Websites are basically front-end or user interface for Web applications. While Web browsers allow consumers to communicate with a business, Web applications are programs that allow transactions from simple text information to complex transactions including credit cards, reporting, videos, design, etc. and sit underneath the websites. There are external facing Web applications that allow consumers to interact with businesses like e-commerce transactions to buy various commodities, manage their sales transactions, and perform other complex transactions. On the other hand, many companies don’t realize that they have many internal Web applications focused on HR, Payroll, etc. that enable internal employees to interact for their information easily. And, there are also partner applications where partners integrate with businesses for flow of information like inventory, accounts payable and receivables, etc.

Hackers attack these Web applications by injecting strings through the same forms and fields that consumers use. If the Web applications sitting on the servers do not properly validate the input that’s coming through these forms, they can spit out a lot of confidential information like customer data or provide clues to hackers on the network layout. This allows them to hack deeper. And this hacking happens on all sites – SSL or no SSL. Since most developers have not been trained on how to do secure coding, almost all Web applications have severe vulnerabilities (defects) that can easily be exploited by hackers through the common interfaces. For internal applications, many employees have hacked them through their Web interface to access confidential information on employees like health records, salary information, personal contact etc. This results in severe consequences. Even if the developers are trained on secure coding, they are usually under tremendous pressure to deliver functionality quicker than ever. In an intensely competitive world, “time to market” is key. Security is usually an afterthought. Various social networking sites like Facebook, Twitter, and others are prime examples of this phenomenon. They are finally starting to realize the impact of security weaknesses and are doing something about it.

With over 100 million Web applications out there, most of which are insecure, hackers are having a field day going after this low hanging fruit. While SSL is necessary for a lot of good reasons, it isn’t securing your Web applications. You should educate yourself on Web application security so you can start pushing your organization in the right direction. There is no such thing as 100 percent security. You have to just raise the bar so you are not an easy target. Just like burglars try to avoid breaking into homes with alarm systems, hackers try to avoid hacking sites that are protected.

view counter
Mandeep Khera is the Chief Marketing Officer at LogLogic. Prior to LogLogic, he was at Cenzic, a Web Application Security software and Cloud company, where he served as the CMO for 8 years. He has more than 25 years of diversified experience in marketing, engineering, business development, sales, customer services, finance and general management for companies such as VeriSign, Hewlett-Packard, Unisys, and many start-ups. You can follow him on Twitter at @appsecurity