Attackers are relentlessly looking to find and exploit any vulnerabilities that exist within web applications. Every web application has value for some criminal element. Cyber Crime syndicates value established web, site\u2019s customers\u2019 credit card data which is often improperly stored in many e-commerce sites. The target of opportunity is typically sites with a large customer base.<\/p>\n
They will use the site as a distribution platform, booby-trapping the sites with exploit kits, malware or malicious scripts. One of the most common modes of attack is to inject malicious code into legitimate JavaScript already present on the compromised websites. This perpetuates the spread of a large percentage of malware.<\/p>\n
\u201cThe JavaScript is automatically loaded by the HTML webpages and inherits the reputation of the main site and the legitimate JavaScript. If the illicit source code is detected by software, many times it is discarded as a false positive. If Administrators manually check their site\u2019s source code, the malicious code is easily spotted.<\/p>\n
It only takes a few moments as an Administrator to look over your web page and check for suspicious elements:<\/p>\n
Hacktivists may want to knock your site offline with a denial of service attack. Diverse groups have diverse end goals but they all share the common methodology of relentlessly enumerating and exploiting weaknesses in target web infrastructures.<\/p>\n
You\u2019re most prudent course of action is finding and fixing all your vulnerabilities before the bad guys do. There are different methods and tools to identify web application vulnerabilities, each with varying degrees of accuracy and coverage. The first technique uses static analysis tools that inspect the applications source code, or you can use dynamic analysis tools that interact with the live, running web application in it\u2019s normal environment. The ideal remediation strategy from an accuracy and coverage perspective would be for organizations to identify and correct vulnerabilities within the source code of the web application itself. Unfortunately, in several real-world business scenarios, modifying the source code of a web application is not easy, expeditious or cost effective. You can place web applications in two main development categories: internal and external (which includes both commercial and open source applications). These development categories directly impact the time-to-fix metrics for remediating vulnerabilities.<\/p>\n
Here is a look at some of the most common roadblocks found in the two main categories for updating web application source code.<\/p>\n
Internally Developed Applications<\/strong><\/p>\n The top challenge with remediating identified vulnerabilities for internally developed web applications is a simple lack of resources. Again, business owners must weigh the potential risk of an application compromise against the tangible cost of initiating a new project to remediate the identified vulnerabilities. When weighing these two options against each other, many organizations choose to gamble and not fix code issues and hopes no one exploits the vulnerabilities.<\/p>\n Many organizations come to realize that the cost of identifying the vulnerabilities often pales in comparison to that of actually fixing issues. This is especially true when vulnerabilities are found (not early in the design or testing phases but rather) after an application is already in production. In these situations, an organization usually decides that it is just too expensive to recode the application.<\/p>\n Externally Developed Applications<\/strong><\/p>\n If a vulnerability is identified within an externally developed web application (either commercial or open source), the user most likely will be unable to modify the source code. In this situation, the user is essentially at the mercy of vendors, because he or she must wait for official patches to be released. Vendors usually have rigid patch release dates, which means an officially supported patch may be unavailable for an extended period of time.<\/p>\n Even in a situation where an official patch is available, or a source code fix could be applied, the normal patching process of most organizations is extremely time-consuming. This is usually due to the extensive regression testing required after code changes. It is not uncommon for these testing gates to be measured in weeks and months.<\/p>\n Another common scenario is when an organization is using a commercial application and the vender has gone out of business, or it is using a version that the vender no longer supports. In these situations, legacy application code can\u2019t be patched. A common reason for an organization to use outdated vendor code is that in-house custom-coded functionality has been added to the original vender code. This functionality is often tied to a mission-critical business application, and prior upgrade attempts may break functionality.<\/p>\n Virtual Patching<\/strong><\/p>\n The term virtual patching was coined by intrusion prevention system (IPS) vendors a number of years ago. The term is not application specific and it can be applied to other protocols. It is generally used as a term for Web Application firewalls (WAF). Virtual patching is a security policy enforcement layer that prevents the exploitation of a known vulnerability.<\/p>\n The virtual patch works because the security enforcement layer analyzes transactions and intercepts attacks in transit, so malicious traffic never reaches the web application. The result is that the application\u2019s source code is not modified, and the exploitation attempt does not succeed.<\/p>\n Virtual patching\u2019s aim is to reduce the exposed attack surface of the vulnerability. Depending on the vulnerability type, it may or may not be possible to completely remediate the flaw. For more complicated flaws, the best that can be done with a virtual patch is to identify if or when someone attempts to exploit the flaw. The main advantage of using the virtual patch is the speed at risk reduction. It provides quick risk reduction until a more complete source code fix is pushed into production.<\/p>\n The use of virtual patching in your remediation strategy has many benefits but it shouldn\u2019t be used as a replacement for fixing vulnerabilities in the source code. Virtual patching is an operational security process used as a temporary mitigation option.<\/p>\n It can be compared to military battlefield triage. When Marines, Soldiers, Sailors or Airmen are injured in combat, Corpsmen or Medics (and sometime their buddies) attend to them quickly. Their purpose is to treat the injury, stabilize the subject and keep the subject alive until the subject can be transported to a full medical facility for comprehensive care. In this analogy the Corpsman or Medic is the virtual patch. If your web application has a vulnerability, you need to take the application to the \u201chospital\u201d and have the developers fix the root cause. You wouldn\u2019t send your troops into battle without medical support. The medical staff serves an important purpose on the battle field and the virtual patch serves an important purpose in your web production environment.<\/p>\n","protected":false},"excerpt":{"rendered":" Attackers are relentlessly looking to find and exploit any vulnerabilities that exist within web applications. Every web application has value for some criminal element. Cyber Crime syndicates value established web, site\u2019s customers\u2019 credit card data which is often improperly stored … Continue reading