eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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.
eWEEK: What are the top security mistakes your customers make when deploying Web applications?
Microsoft: The top three things customers should do when deploying Web applications are:
1. Plan for security in the original design. This should include developing processes to keep up with the latest service packs and patches.
2. Follow published best practices, including: –Always installing the latest service packs and patches; and –Reducing the surface area exposed to attack by turning off all unnecessary services. In the case of the operating system and Web server, much of this is done for administrators by default in Windows .Net Server 2003. For IIS 5, the IIS Lockdown Tool can help greatly. –Adhere to the principle of least privilege. For example, connections between the Web application and the database do not need to be made in the context of the SA account. The database should not run as LocalSystem; just give it the minimum privileges needed to run. And the Web user should have only the minimum necessary privileges on the database–nothing more. –Ensure that all passwords are complex and non-obvious.
3. Expect failures; practice defense in depth. For example: –It is never enough to perform only client-side validation. All input must be validated on the server prior to being sent to the database. In the same way, never build SQL queries on the fly–using string concatenation is a huge risk, should any malicious input slip through your checks into your queries. Use parameterized stored procedures instead. Finally, all input that cannot be proven to be good should be treated as bad. –Isolate your database. The database should never share a service account with other applications and services. Also, never allow it to be directly accessed by end users. It should be made available only through a mid-tier application, and the entire solution should reside behind a firewall.
Oracle:
1. Leaving default passwords on accounts–this includes the database and operating system.
2. Leaving demo files installed on Web servers. Demo files could provide hackers with a method of accessing the system, operating system, etc.
3. Not removing all unwanted files. It is amazing when you access a “hardened” server and find three versions of Perl installed.
4. Not locking down ports. If a Web application requires only Port 80 and 443, then open just those ports.
5. Holes in application code.
6. Failure to apply latest security fixes.
eWEEK: What aspects of the OpenHack configuration would you most like your customers to emulate for improved security?
Microsoft: See Question 1. All of these are strict requirements for a secure solution. In addition, we would recommend using integrated Windows authentication to access the database, putting the Web content on a volume separate from the system volume and using the IIS Lockdown Tool and URLScan for IIS 5.
Oracle: The following are the key features that clients should consider for their Web and database servers:
1. Remove “code” characters from data fields that could cause issues ( % < > ; + ” ).
2. Always send the user to a generic error page that provides a standard error message (e.g. Static HTML). This can be set up in the HTTPD.CONF file using directives (e.g. errordocument). Record the application error within the logfiles for the administrators, but do not provide the hackers any information (e.g. buffer overflows, etc.)
3. Within the Net Service “Listener,” restrict the nodes that can access the database, set the following lines in the sqlnet.ora
tcp.validnode_checking = yes
tcp.invited_nodes = (Web Server Name or IP Address, IP Address)
4. Harden Web server: Update the httpd.conf, web.xml, etc. Remove all unwanted code, configuration settings. An example of this can be seen in the document that details the environment.
5. Encrypt secure data–even basic encryption is better than none. We used DBMS_OBFUSCATION.
eWEEK: If you could change anything about your OpenHack configuration or code to improve security further, what would those changes be?
Microsoft: For an additional layer of security, we could have stored salted hashed passwords and used a challenge phrase scheme for password recovery or reset.
Oracle:
1. For the secure pages (e.g., once logged in), use a custom user manager. A custom user manager will validate that the user has been authenticated before accessing secure pages. The code required to implement a basic manager is very small.
2. Add in session Challenge Number and validate the page flow. Challenge Number is a method of setting some “Nonce” (random data) into the session state and requesting that the client provide the matching number. In OpenHack, this would be done by setting some “Nonce” in the cookie and session state then when the next request is submitted validating that the Nonce value is the same as expected. (If not[, then send] standard error page ).
3. A more major change is removing the logic from the JSP and adding it into a Bean or Servlet, so all the JSP is performing for the client is UI (User Interface). This means that the module can be built up using shared methods. This has major benefit simpler code and single code fix required and a more structured approach to development. Using tools such as Oracle JDeveloper that has business components as standard is a perfect method.
eWEEK: What have you learned or what do you hope to learn from this test?
Microsoft: We try to spend as much time as possible living inside our customers shoes, looking at our technology from their perspective so that we can make the best possible recommendations when it comes to things like productivity and security. OpenHack 4 was another wonderful opportunity to do this.
In this particular exercise, we found that the easiest way to manage security settings on multiple machines is to establish a baseline set of settings and then have a small delta for each machine type.
Oracle: It was great to see that a major new release (Oracle 9iAS R2) could stand up to 68,000+ attacks. The two successful cross-site scripting attacks were very minor (that is, the hacker still could not break in) and shows that more testing is always required.