Web Applications Vulnerability is Everyone’s Responsibility

When organizations worry about their cyber security, they focus on ransomware attacks, employees opening (spear) phishing emails or clicking on malicious banners and links on websites. But there is another danger that is often underestimated – the web applications of your own organization could harbor vulnerabilities and security issues. This happens more often than you think – “bad” coding is still a major concern as the HP Security Research’s Cyber Risk Report 2015 indicates: “The primary causes of commonly exploited software vulnerabilities are consistently defects, bugs, and logic flaws. Security professionals have discovered that most vulnerabilities stem from a relatively small number of common software programming errors. Much has been written to guide software developers on how to integrate secure coding best practices into their daily development work. Despite all of this knowledge, we continue to see old and new vulnerabilities in software that attackers swiftly exploit. It may be challenging, but it is long past the time that software development should be synonymous with secure software development. While it may never be possible to eliminate all code defects, a properly implemented secure development process can lessen the impact and frequency of such bugs.” The report ranks the top five vulnerabilities resulting from bad coding as follows: Privacy violation (74%), insecure storage (71%), insecure transport (66%), insecure deployment (62%), and poor logging practice (47%). Patching vulnerabilities takes on average more than 170 days. As the Acunetix Web Application Vulnerability Report 2016 shows, the numbers for 2016 are not much better: 55% of web applications were shown to contain high-security vulnerabilities such as XSS and SQL injections, and 84% of web applications were susceptible to at least one medium-severity vulnerability such as CSRF. Let’s have a look at the top 3 web application hacks and breaches that made the headlines in 2016.

1. The Panama Papers (more than 11.5 million confidential documents) were leaked when the website of Mossack-Fonseca was hacked by exploiting the failure of CMS security. Not only was the out-of-date image slider plugin on the company’s website exploited, but also several known vulnerabilities in Mossack-Fonseca’s three-year-old version of Drupal.
2. The me website was shown to be vulnerable to being hacked by using a Cross-Site Request Forgery (CSRF). When exploited, a hacker could remove or edit the CSRF token and, in turn update a user’s PayPal profile picture.
3. The Russian Foreign Ministry website spoof. A hacker known as The Jester exploited a cross-site scripting (XSS) vulnerability found in the website. He/she exploited it to post a detailed message for all website visitors to see, without damaging or breaching the site itself.

Bad coding can take several forms, including insecure storage due to insufficient data protection, poor logging practice, weak cryptographic hash, and missing jailbreak detection. How can that happen? For one, companies often build their web applications or APIs with open source components that usually include many millions of lines of code. Security tech company Contrast Security analyzed almost 10,000 applications totaling over 8 billion lines of code. It found that around 76% of the applications contained at least one vulnerability, and 34% contained four or more vulnerabilities. Several times a year, powerful and easy-to-exploit vulnerabilities such as Struts2 appear, which makes them attractive targets for cybercriminals. But patching vulnerabilities in software components is complicated since it required going back to development. This takes a long time, which gives attackers ample opportunity to exploit the vulnerabilities. To illustrate, Symantec discovered that common remote administration tools (RATs), such as Gh0st RAT, Korplug/Plug-X, and XtremeRAT, are full of vulnerabilities that could enable the hackers to become hacked themselves. It is delivered to the victim, and, once it runs on the victim’s machine, the RAT “calls home” to the C&C botnet server. The C&C server, in turn, communicates back to the victim’s machine with instructions on what should happen next, whether it’s data exfiltration or something else. AWS-powered web applications are also vulnerable to application-layer attacks, not in the least due to the popularity of the AWS platform. In the beginning of this year, the Open Web Application Security Project (OWASP) released the Top 10 application flaw categories. On top of the list are injections, followed by broken authentication and session management, cross-site scripting (XSS), broken access control, security misconfiguration, sensitive data exposure, insufficient attack protection, Cross-Site Request Forgery (CSRF), using components with known vulnerabilities, and in last place, we find under-protected APIs. A good start is to have your organization’s developers only work according to known secure coding methodologies and standards such as OWASP Top 10 and ISO 27034. But it is not just the developers’ responsibility to keep applications secure. It’s also the task of IT and security personnel within the organization to provide a holistic and secured framework for the applications. More specifically, IT and security departments should ensure that the architecture is robust, up-to-date, and protected behind security barriers and a Web Application Firewall (WAF). The WAF is the first line of defense for blocking attacks before they can reach the application and perform malicious actions. In short, the WAF is used to monitor, detect and filter malicious behavior before it can impact the application itself. As such, it is highly effective for protection against zero-day exploits, impersonation, and known vulnerabilities and attackers. Through customized inspections, the WAF is also capable of preventing cross-site scripting (XSS) attacks, SQL injection attacks, session hijacking, and buffer overflows, which other traditional security solutions may not be capable of doing. That’s why configuring WAF correctly from day one, and regularly verifying that it is still providing adequate protection from cyber-attacks is important. What can we conclude? Although vulnerabilities on websites are a problem and should not be underestimated, you can take measures to ensure that your web applications are secure – both external to the world wide web and internal to the organization. To find out if your organization’s applications are currently at risk, there are several tools and methods at your disposal. Cymulate’s web application firewall (WAF) assessment can test your WAF security posture to web payloads to ensure that common web application payloads are blocked before they get anywhere near your web application.