Upcoming Events

Cloud Connect
Santa Clara
Feb 13-16, 2012

Cloud Connect brings together the entire cloud eco-system to better understand the transformation we're experiencing and promises to be the defining event of the cloud computing industry. Learn about the latest cloud technologies and platforms from thought leaders in Cloud Connect’s comprehensive conference.

Register Now!


	W O R K S H O P

Maintaining Secure Web Applications March 20, 2000 By Jeff Forristal 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.
PAGE: 1 I 2 I 3 I 4 I 5 I NEXT PAGE

Video