Web app security is hard, and the more complicated your application becomes, the greater the opportunity to make a mistake.
I’d like to take a look at five of the most common security vulnerabilities web applications are prone to.
Cross-Site Scripting Vulnerability
Considered the single most common vulnerability on the web, cross-site scripting (XSS) vulnerabilities are easy to introduce unless you’re paying close attention to the sanitization of user input. Even worse, it doesn’t have to be your mistake: if you use libraries, frameworks, or even content management systems like WordPress, you may innocently use functions that don’t sanitize input in the way you expect them to.
A typical example of a cross-site scripting attack involves opportunities to submit user-generated content to a site. The attacker will embed their code into a site’s comment section, for example. If the code is not properly sanitized, it will be run by the browser with the same trust level as other content on the site. Attackers can embed code that will send sensitive data, including authentication credentials, to their server.
Developers should be particularly sensitive to the risks of cross-site scripting attacks when building any site feature, including APIs, that allows users to submit data.
Most interactive sites store data in a database. If an attacker can influence the database to run code, they essentially own the site and its data. There are many different vectors for SQL injection attacks, including unescaped and unsanitized input and insecure server authentication. Last month, we wrote about the Chikdos malware, which is inserted into compromised systems via an SQL injection attack that influences MySQL servers to run malicious user-defined functions.
Protecting against SQL injection attacks is a complex topic: this guide from The Open Web Application Security Project is a great place to start.
Not Hashing Passwords
Hopefully I don’t need to explain why this is a bad idea — passwords stored in plain text are only one security slip away from being public knowledge. If your website uses passwords, there’s no excuse not hash, salt, and store them securely.
Poor Encryption Implementation
It doesn’t matter that your site uses the best hashing algorithms and encryption protocols if your developers include a convenience functions that makes it easy to retrieve passwords. That’s what happened in the Ashley Madison attack. The solution is not wholly technological: companies must have processes in place to train developers so they are aware of what’s at stake and oversight to make sure that mistakes are caught quickly.
If a company’s web application has been around for a while, it’s possible that the SSL implementation it relies on is outdated. SSLv3 is used all over the web, in spite of it being common knowledge that SSLv3 is vulnerable. Companies with outdated SSL implementations should upgrade to newer versions of TLS as soon as possible, both because of the security risk and because browser manufacturers are insisting on it.
We’re coming up the start of a new year, which is an arbitrary but useful time to take a good look at your web application’s security with a particular focus on the vulnerabilities we’ve discussed here.