eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Security always comes down to securing applications.
The whole point of firewalls is to hide internally deployed network applications—assumed to have exploitable vulnerabilities somewhere—from the outside world.
The main weakness of firewalls is that they are based on a one-application/one-IP-port model, something that worked in the pre-Web days but is completely inadequate now. These days, most application data flowing through firewalls and over network backbones is on HTTP ports 80 or 443.
Thats why the main burden of security now falls on those who maintain Web sites and on those who write Web-facing applications or Web services. Web applications are highly vulnerable, and since many of them are both one-of-a-kind and internal, there is no vendor testing or patching process to help with the security burden.
Writing secure applications is a matter of understanding the issues and writing defensively to anticipate the kinds of attacks that are possible online.
While there are a number of good books on this topic, my favorite online guide is the Open Web Application Security Project, and its updated compendium of advice and best practices on writing secure Web applications—Version 1.1 came out just a few days ago on Sept. 23.
As eWEEK works on further coverage in this area, Id love to hear about your own experiences with secure or not-so-secure Web applications.
What are the issues that often get forgotten? What parameters werent value-checked? What sneaky things did crackers figure out about your site to be able to find a hole? Id like to share these things with other readers to help everyone learn, and will keep names and companies anonymous if desired.
Web code security woes? Let me know at timothy_dyck@ziffdavis.com.