The Need for Web Application Scanning
Any application developed by a human is very likely (albeit certainly) to have some type of vulnerability in it. This becomes even more of an issue when the software being developed does not have any IT or security functionality at all, causing the developers assigned to the project to typically not have deep experience in secure coding practices. Although this issue occurs in any application, from the lowest embedded assembly code to the highest level .NET interpreted code, one location seems to have the least amount of secure coding practices with the maximum exposed surface: web applications.
There are numerous examples of how web applications have caused innumerable amounts of damage to companies. SQL injections reveal customer information; XSS breakdown customer reliability in the vendor; remote file include vulnerabilities allow attackers to take over the web server. It would only take a few minutes on any news website searching for web breaches to realize that this new “frontier” may actually be the most dangerous frontier thus far in our computer evolution.
With the rise of “Web 2.0” applications, we are seeing a large trend towards EaaS (Everything as a Service). Every major software company right now likely has a project to enable previously console applications to have some sort of web-based front-end. Customers are driving this evolution, wanting fewer applications installed in their desktops and more hosted in a “secure” and stable offsite location from the vendor. Although we cannot disagree that this is a very cool evolution of software, we are again seeing the rapid advancement of technology move a bit quicker than the security practices surrounding it.
Web developers often times are focused on providing a very interactive experience to the end user. Especially in the “Web 2.0” world, many of the applications being developed have their contact purely developed by end-users. As was the case with all of the different vulnerabilities seen within desktop and server applications, user-input is typically the entry point of an attacker to deliver an exploit for a vulnerability. The modern-day web developers typically do not understand vulnerabilities, security issues, or the attackers that are trying to exploit their applications. Instead, they consistently focus on ensuring that: 1 – the product is very powerful, cool, or innovative; 2 – the product works. Rarely do you see the mandatory other step adopted recently by so many large desktop/server developers being 3 – is the product secure?
Commonly VERSA articles are meant to show the InfoSec warriors how to protect themselves. However, in this case, many of the VERSA readers are unlikely to be the main developers of web applications. Therefore, the call to action will shift from a “protect” to an “evangelize” need. Those that know security must drive the protection of web applications until the web developer community starts commonly practices secure coding practices.
There are a few processes and tools that can help security evangelists and web application developers ensure that their applications are properly secured from the most common vulnerabilities.
Knowledge – As was the case with standard memory-based vulnerabilities a decade ago, developers are not privy to all of the different types of vulnerabilities that are exposed within web applications and how to ensure that their code does not allow them to be exploited. This knowledge can be derived from many resources including: Web Application secure development books, security conference briefings, and tools being deployed by attackers. One notable place to learn a great deal is the OWASP initiative, a conglomeration of web-based application security tools and documentation.
Testing
Perhaps the most powerful way to get through to a developer with the implications of a vulnerability is to show them with a demonstration attack. There are many different web-application scanning tools on the market (some being better and more robust than others of course) that can scan a web application for vulnerabilities, and actually demonstrate the vulnerability at the end. For the large web-app testing, there are secure exploit toolkits available as well that can help to identify the potential result of the attack, such as the data that might have been revealed during a SQL injection attack. If testing for vulnerabilities is done during the development lifecycle, developers will become much more familiar with what web application vulnerabilities have the potential to do, while also ensuring that they learn better practices for future development projects.
Constant Verification
The web application vulnerability realm is a rather young one, and new types of vulnerabilities and exploits are being discovered often. Because some legacy web applications might not have been scanned for the latest and greatest vulnerabilities, it is very important that security teams regularly test web applications from the outside point of view (similar to a penetration test) with a cutting-edge web application scanner to verify that no newly discovered threats were pre-existing on their applications. Some companies of course offer this as a service to keep the weight off of the internal security teams as well.
Web applications are rapidly becoming the most powerful delivery method of content for the future. Unfortunately, many security vulnerabilities are being discovered that could cause issues for developers if they do not ensure that they understand and test for vulnerabilities within their web applications. This is a quickly emerging issue that will gain even more importance as the emergence of web applications continues.
Source: Andre Derek Protas, Director of Research and Preview Services |
News & Articles
Announcements
Tech Talk
Reader Q&A
Etcetera