Imagine the following network infrastructure scenario: A corporate LAN is connected to the Internet via a router that denies all incoming traffic except TCP Port 80 (HTTP). Behind this router is a firewall that proxies HTTP requests to an internal DMZ firewall. The DMZ firewall translates the IP address via NAT (Network Address Translation) and sends it to the final Web server destination. The Web server is allowed to make database connections to a database server that's situated behind a third firewall, which allows only database traffic between the Web server and the database server to pass through it. This gives us four firewall/filtering devices, composing a secure (yet complex) infrastructure security solution. The administrators of this LAN sleep easy at night, knowing their architecture is secure.
That is, until one night when an attacker comes along and takes advantage of poor coding in the custom application running on the Web server, which lets the intruder retrieve entire tables of sensitive data. Why didn't the complex secure network infrastructure stop this? Simple: The attack happened on an application level, not a network level. Assuming you want your Web server to be accessible from the Internet, there's already a clear path straight to the server on an application level (HTTP). Furthermore, if your Web server is set up to manipulate data in a database server, your database server is implicitly allowing connections from the Web server. An attacker doesn't need to spend extra time guessing database logins and passwords--the Web server has the required information and connects on the attacker's behalf.
A look through security-vulnerability archives will yield many examples of poorly coded CGI applications that can be leveraged against the Web server. Current CGI vulnerability scanners check for as many as 200 vulnerable CGIs. All these CGIs suffer from the same problem: poor Web application coding.
Many developers don't realize they play as vital a role in an organization's infrastructure as that organization's firewall. When you analyze an attack, you'll realize it's the receiving application that lets the attacker breach security; the firewall merely limits an outsider's access to that application.
Web Application Development Assumptions
Security in a Web application isn't hard to implement, but it has to be an ongoing design consideration and not merely an afterthought for it to work right. Security should provide the base and direction of the Web application, rather than be added after initial development is completed.
Most vulnerable Web applications are vulnerable because they trust incoming user data in one way or another. The principal "philosophy" of security is simply that you can't trust anyone or anything. In extreme cases, it's arguable that you can't even trust the IP address the connection comes from, since the IP address may be spoofed as well--though that's a much harder technical feat than sending some bogus Cookie, Referer and User-Agent headers.
REPORTS
Analyize In-Line NAC strategies and products.
ANALYTICS Plan and design your enterprise blade server deployments
2009 IT Salary Survey: Meager Raises, Solid Prospects
Though raises are notably smaller than a year ago, and job security’s shrinking, IT careers are looking safer than many others in this economic downturn. Get all the findings in InformationWeek's 2009 IT Salary Survey. Available FREE for a limited time.
A look through security-vulnerability archives will yield many examples of poorly coded CGI applications that can be leveraged against the Web server. Current CGI vulnerability scanners check for as many as 200 vulnerable CGIs. All these CGIs suffer from the same problem: poor Web application coding.
REPORTS
ANALYTICS
Follow 
