adam121 - Fotolia
In light of various major security breaches, it seems that IT and security professionals are often acting defensively,...
instead of proactively, when it comes to web security.
Those in charge of web security at organizations of all types and sizes, including CIOs and other executives, can be quick to respond that their websites and applications are scanned periodically. Some say their applications are part of ongoing penetration testing efforts, and feel that the security box has been checked. Still others claim that managing web security vulnerabilities falls out of the scope of their responsibility because the websites and applications are hosted in the cloud.
I understand the first two approaches, but the third is inexcusable. Organizations need to focus security efforts, especially security assessments, specifically on their web environments in order to ensure proper results, regardless of where they are hosted.
This glaring hole in countless information security programs can be resolved. First off, there are some very good online resources for boosting your web security posture, such as the OWASP Top 10 and the OWASP WebGoat Project, which track some of the top web security vulnerabilities in the industry.
That said, I still come across people who have never heard of OWASP, and who are not aware of the value it can bring to an information security program. Regardless, if you're looking to boost your web security posture, for starters, I would recommend you check out the OWASP Top 10, as well as the other resources OWASP has on its website. The OWASP Top 10 is still in its 2013 version, but a new version is currently in the public comment phase, with plans for it to be released by August 2017.
The Foundstone software application security services tools, such as Hacme Bank, are great for learning what web security vulnerabilities for which to look. They're dated, but still legitimate. Keep these resources and other free tools on your radar.
It's one thing to learn, but quite another to actually understand how your own web systems are at risk. In the context of web security, you cannot fix the web flaws about which you don't know. Testing for web security vulnerabilities should be thought of as a stand-alone initiative -- at least for core or critical applications. By this I mean you need to test individual applications as stand-alone projects.
I've seen too many scans (often performed with generic network vulnerability scanners) and penetration tests that gloss over the important parts of enterprise web applications. Given the visibility of your web systems, along with the high potential risk, quality and a quantity of time should be spent testing your applications, both with and without user authentication. Look for the obvious low-hanging fruit and the not-so-obvious gotchas lurking in your code that can get you into a real bind.
Top web security vulnerabilities
The following are the top web security vulnerabilities that are continually found across both in-house and cloud-based applications, marketing sites and their accompanying content management systems, as well as the often overlooked web interfaces on network infrastructure systems and the multitude of internet of things devices scattered about the network.
- Cross-site scripting, which could facilitate client-side exploits.
- SQL injection, which could permit direct database connections and remote command prompts.
- Weak or default passwords and weak password policies, including no intruder lockout, which could facilitate password cracking.
- Poorly designed password reset functions that can be manipulated or used to create unnecessary password exposures.
- User session management weaknesses, such as using cookies that are not changed upon initial login and after logout, which could be exploited through man-in-the-middle attacks or local browser manipulation.
- Open proxies -- both external and internal -- that allow people to use your network for web access or to bypass internal security controls.
- Input validation flaws that facilitate HTTP redirection and frame injection.
- A lack of CAPTCHAs on web forms, which can create email denial-of-service attacks.
Although it's not directly related, missing OS and application patches can cause web security issues, so be sure to test for those, as well.
Resolve web security issues
The goal with web security is not to find every flaw in every system. Instead, you need to focus on finding the urgent web security vulnerabilities in your important applications and systems. When you focus on the urgent and the important, you address the 80/20 rule by finding and resolving 20% of the flaws that are creating 80% of your problems.
Once you have that under control, look further into your network for all of the web systems that are present. Do a port scan using a tool such as Nmap or SoftPerfect Network Scanner to find sites and applications running on the usual ports, such as 80, 443 and 8080. You'll find a ton of systems of which you probably weren't aware. Scan those systems and see what vulnerabilities they're introducing. Even something as seemingly benign as web interfaces on multifunction printers and copiers can create tangible business risks. If you don't find anything, you're not looking hard enough, or you're not using the right tools (i.e., dedicated web vulnerability scanners, such as Netsparker and Acunetix Web Vulnerability Scanner).
If you don't treat web security from development and quality assurance, all the way to testing and ongoing oversight, as a core component of your overall security program, you'll continue to have risks that external attackers, rogue employees and malware can exploit.
Stop lumping web security testing into your generic scanning and testing initiatives -- it's that important. You'll not only find more flaws, but you'll be in a better position to truly know your network, so you can address the risks that matter most.
Learn how security testing and firewalls can resolve web application vulnerabilities
Find out how to rank and manage vulnerabilities in your enterprise network
Add HTTP security headers to enterprise servers