On Application Security
By efi on Nov 12, 2007
Application security is a one of the most important and constantly misunderstood pieces of the overall challenge of enterprise information security. The Defense in Depth (DiD) Principles mandate the deployment of “multiple, independent, different and mutually – reinforcing security lines of defense” must be extended to applications.
Considering that applications are normally the first line of exposure of an enterprise to a hostile environment, proper application security becomes of utmost importance in the DiD challenge. Information security should not be considered only as a defensive way of protecting assets but also as a business enabler. There are many examples of core security technologies which brought new meaning to the term “doing business online” (for example, the use of cryptography opened the door to e-commerce – just to name one ). In similar way an application is the business enabler of a particular company hence its security must be considered as important as its core functionality.
On the other hand the lack of security may be fatal to a company. The so called “CNN moment”, announcing a security breach, may lead to drastic loss of revenue, customers, etc. The long time consequences of this loss of trust might be very heavy or even fatal for a business.
Traditionally the efforts for bringing security to a company has been focused on the physical elements or the the whole infrastructure on which applications are deployed.
Over the years a number of trends emerged ranging from requiring strong passwords to the inclusion of firewalls on network's edge, but all of them failed to offer the comprehensive protection the companies need. The explanation of this fact is simple – This are point solutions for point problems. They are not implement any form of DiD approach.
More recently companies started to target the infrastructure in more comprehensive way, achieving higher levels of protection by deploying correctly (or trying to) the principles of DiD. Unfortunately this approach is still lacking.
This is because application security issues are still misunderstood and hence neglected, or simply ignored. A highly secured infrastructure can be rendered ineffective, and unauthorized access to services and data achieved if application security is not properly addressed.
A short list of some common yet dangerous assumptions follow:
- Application is deemed secure if access to resources is limited by someform of authentication/authorization scheme.
The traditional use of userid/password schemes have proved to be prone to lot of vulnerabilities historically. But even if the authentication tokens are properly chosen and authorization is enforced an improper session handling may lead to identity theft or tokens disclosure. Attacking techniques, such as Cross Site Scripting [XSS], have proved that this way of securing an application can be easily bypassed.
- Application is deemed secure if it is deployed over multiple tiers and there is some form of traffic filtering between the tiers.
While this is completely true from infrastructure point of view the overall strength of the security of the data and assets provided by an application is as weak as it's logic. Programing or design faults may lead easily to data theft or manipulation even if deployed on a well secured infrastructure. Example of this type of vulnerabilities may be exploited with “SQL Injection” (just to name one) and may lead to direct data manipulation on a repository (Database) positioned on the most protected tier, thus bypassing several infrastructure security technologies.
- Application is deemed secure if the infrastructure software components and middleware, it is deployed on, are properly configured and maintained.
Even if web servers, application servers, vendor portals, servers, network etc. are properly configured same principles as described above apply. Another example we may apply here is vulnerable or badly designed application component (CGI script for example) which may allow direct command execution on the underlying operating system, thus leading to further compromise.
- Application is secure if it uses some form of encryption.
Encryption will normally protect the data in transit and in some cases may even authenticate both parties involved in communication. But the security level brought by the cryptography is as strong as the strength of both trusted ends. Browsers may be really good examples of weak but trusted parties – they terminate the SSL connection but at the same time may execute code provided by the server. On the other hand most of the encryption channels are terminated on specialized devices on the edge of the infrastructure leaving all the traffic in clear and susceptible to hijacking by insiders if no further security controls are deployed.
- Application is secure if it is protected by a firewall.
Firewalls allow specific traffic to the applications (ex. HTTP is open for the web servers) hence traditional packet filters add little or nothing to the application security. Even application firewalls (devices which understand and filter on the application level ex. HTTP) are based on pre-built rules. While such rulesets may mitigate the “traditional” exploitation of a web application they can do little or nothing to avoid the vulnerability brought by badly designed application. Poorly designed session management may lead to session hijacking which by all means is valid communication to both network and application firewall.
Although all of the above can be true, none of them is sufficient ensure that the application is
“secure” or even “securable”. The security of an application also lies deep inside the code
itself, the code deployment, the sustaining procedures and application logic as a whole.