With so much of today’s business conducted over the Internet, websites are a prime target for cybercriminals. Although the Web attacks used are often relatively well-known, protecting against them remains elusive for many companies and they’re still a common source of compromise. The complexity of the Web, compounded with holes in the infrastructure, makes many websites vulnerable, and the threat is only increasing. According to Symantec’s latest Internet Security Threat Report there were 6,787 vulnerabilities disclosed in 2013, compared with 5,291 in 2012. Even more concerning, one in eight sites had critical, unpatched, known vulnerabilities, with 67 percent of web sites used to distribute malware identified as legitimate, yet compromised.
Over the past few years, the volume of malware on the Web has grown dramatically and much of this is due to the use of automation and exploit kits. Hackers use pre-packaged software that contains a myriad of malicious programs and exploits to carry out automated ‘drive-by’ attacks to spread malware and infect unsuspecting hosts. With exploit kits, cybercriminals can easily scale their attacks and try multiple hacking tactics to exploit identified vulnerabilities.
The pervasiveness of these toolkits can be seen in the average number of malicious websites blocked each day. Exploit kits’ growing popularity is not only creating a lower barrier to entry for attackers, but a higher bar for companies to protect their web infrastructure as well.
Today any website may be compromised by cybercriminals and used to attack your data. Here are five of the most common attack methods that continue to be the scourge of many websites. Tip of the hat to the Open Web Application Security Project (OWASP) for the detailed descriptions provided in the links below:
SQL injection is a code injection technique that inputs malicious SQL statements into an entry field for execution which causes a web server to return information that it shouldn’t. As a result, the web server provides access to information that should be secure, such as user names and passwords.
Cross Site Scripting is the most prevalent web application security flaw which occurs when an application takes untrusted data and sends it to a web browser without proper validation or escaping. This allows attackers to execute scripts in victims’ browsers when they visit a website, which can hijack user sessions, vandalize websites or redirect the user to malicious sites.
A CSRF attack steals a victim’s session cookie and other authentication information used to login to a vulnerable website. Once complete, the attacker can take control of the victim’s session, for instance on a banking site, and have complete control over the account. However, because the website believes a legitimate user is logged in, it’s very hard to detect when this attack is successful.
Components, such as libraries, frameworks, and other software modules that have known vulnerabilities have become low hanging fruit for attackers. However, as we saw with the recent HeartBleed bug, effective patch management and secure coding can be difficult, especially for complex web applications. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts.
The man-in-the middle attack intercepts the communication between two systems. For example, in an http transaction the target is the TCP connection between client and server. In some circumstances, we’ve seen sites transferring sensitive information without strong enough encryption.
These common web vulnerabilities exist largely due to a lack of safeguards within the web application code itself. In theory, this means they are largely preventable with the implementation of security best practices in the Software Development Life Cycle (SDLC). However, the rate of change and demanding nature of emerging business requirements cause many organizations to struggle with implementing security into their SDLC until it’s too late.
For many enterprises security continues to be reactive, often applied after an attacker has already done the damage. We recommend that enterprises build security into the actual development process itself so that it is designed into the web application from the start. The cost of a potentially slower development process to produce secure code outweighs the risks of waiting until you’re in the headlines as the victim of an advanced campaign targeting your confidential data.
Additionally, it is recommended that both the development and production environments are both monitored against outside threats. Most of these common attacks have established IDS/IPS signatures, making their detection easy for Symantec Managed Security Services to alert and escalate for quick remediation.