Vendors cite common security mistakes, OpenHack lessons.
After the conclusion of the OpenHack 4 project, eWEEK Labs West Coast Technical Director Timothy Dyck posed questions on enterprise security via e-mail to two of the people who helped harden the test applications: Oracle Corp.s John Abel, principal consultant, Oracle Technical Architecture Group, and Microsoft Corp.s Mike Kass, product manager, .Net Framework.
What are the most common security mistakes IT staffers are apt to make when deploying Web applications?
Failing to plan for security in the original design, including developing processes to keep up with the latest service packs and patches; failing to follow published best practices, such as always installing the latest patches, turning off all unnecessary services, ensuring that all passwords are complex and nonobvious, and adhering to the principle of least privilege; failing to expect failures or to practice defense in depth. For example, it is not enough to perform only client-side validation; all input must be validated on the server prior to being sent to the database.
Leaving default operating system or database passwords on accounts; leaving demonstration files installed on Web servers; not removing all unwanted files. It is amazing when you access a "hardened" server and find, for example, three versions of Perl installed. Also, failing to lock down ports: If a Web application requires only Port 80 and 443, then just open those ports. People also miss bugs in application code that let hackers exploit vulnerabilities and fail to apply the latest security fixes.
What aspects of the OpenHack configuration would you most like your customers to emulate for improved security?
In addition [to the points made in answer to the first question], we would recommend using integrated Windows authentication to access the database, putting the Web content on a separate volume from the system volume and using the Internet Information Services Lockdown Tool and URLScan for IIS 5.
Remove "code" characters from data fields that could cause issues (characters such as %, <, >, ;, + and "); always send the user to a generic static HTML error page whenever any type of error occurs so that youre not providing hackers with any information; set the Oracle Net Service Listener to restrict database connections so they can come only from the Web server; harden the Web server to remove all unwanted code and configuration settings; encrypt secure data.
If you could change anything about your OpenHack configuration or code to further improve security, what would those changes be?
For an additional layer of security, we could have stored salted hashed passwords and used a challenge phrase scheme for password recovery or reset.
For the secure pages (for example, once logged in), we could have used a custom user manager, which would validate that a user has been authenticated before accessing secure pages.
We could have also added in a session challenge number to validate page flow.
A more major change is removing the logic from the JavaServer Pages and adding it into a JavaBean or Java servlet so all the JSPs are doing is generating a user interface. This means that the module can be built up using shared methods, which provides simpler code and a single place to fix problems.