OpenHack 4 was designed to test the strength of Web application development techniques. To illustrate these techniques, eWeek Labs asked Oracle Corp. and Microsoft Corp. to recode an application we built, with each vendor using the programming techniques and security mechanisms it recommends to its customers.
The application—the user-facing part of eWeeks eXcellence Awards Web site—has been used in production for the last two years. The application is complex enough to require a variety of security-hardening techniques while still small enough to be understood quickly.
The application, as originally developed by eWeek Labs, was written in JavaServer Pages. It runs on The Apache Software Foundations Tomcat application server and stores data in IBMs DB2 Universal Database 7.2. (Both the application server and database ran on Red Hat Inc.s Red Hat Linux.)
Oracle chose to deploy the application on its Oracle9i Application Server Release 2. Since this is a Java 2 Enterprise Edition-based application server, Oracle was able to use our code directly as a base for its efforts. (For full network topology, see diagram.) Oracle used Oracle9i Database Release 2 as its database and deployed the Web application and database servers on Red Hat Linux Advanced Server 2.1.
Microsoft developed its version of our application using C# and deployed it using ASP (Active Server Pages) .Net and Microsofts IIS (Internet Information Services) Web server with .Net Framework libraries installed.
Microsoft used Microsoft SQL Server 2000 as its database and deployed the Web application and database servers on Windows 2000 Advanced Server.
Reading the Oracle and Microsoft source code side by side provides a very interesting contrast between the Java and .Net Web programming architectures; well compare specific parts of the code online after completion of the test (at OpenHack.com).
When we provided our code to Oracle and Microsoft, we already considered it quite secure, although both companies added further security improvements.
However, just in case something unexpected comes up, we wont be starting this years eXcellence Awards process until after the OpenHack project is complete. Given the auditing and testing the eXcellence Awards application will have received at that point, it should be one of the most secure Web applications on the planet.
Oracle Techniques
Oracle Techniques
Oracle staffers did an audit and penetration test on our code when they received it and were satisfied with the parameter validation and user authentication code we had written.
They made three other important security changes to the application.
First, they configured the copy of Apache HTTP Server that is included with Oracle9i Application Server as well as the application server itself to display the same generic error page whenever any kind of error is encountered. This way, crackers probing for application flaws dont get any information-rich error messages that might hint where they should direct future activities.
Second, Oracle staff added an HTML sanitization routine to outgoing e-mail content to prevent a form of server-side scripting attack through e-mail. Since many e-mail clients automatically render HTML tags, e-mail becomes one more attack vector if it includes any user-supplied data.
Third, Oracle wrote a stored procedure that controls access to credit card and user account password data. The stored procedure uses the Triple Data Encryption Standard encryption routines shipped with Oracles database to ensure that this data is stored on disk in encrypted form. “Its more difficult to invoke a PL/SQL procedure because you have to know the parameters,” said John Abel, in Reading, England, the Oracle consultant who wrote the application. “It protects against SQL injection as well as a [database administrator] having a look around.”
Abel also used Oracle9i Databases stored procedure wrap function to obfuscate the source code of the stored procedure itself, so that anyone who was able to access the database wouldnt be able to view the encryption code.
Abel also used Oracle9i Databases stored procedure wrap function to obfuscate the source code of the stored procedure itself, so that anyone who was able to access the database wouldnt be able to view the encryption code.
The Oracle test application can be accessed at www.oracle.openhack.com/openhack/index.jsp.
Microsoft Techniques
Microsoft Techniques
While Oracle used a SQL scrubbing procedure to ensure commands sent to the database were safe, Microsoft went one step further. In addition to a SQL validation class, Microsoft staffers encapsulated every database query and command needed by the application into separate stored procedures.
“The Web user has no access to the base tables,” said Erik Olson, program manager, Microsoft .Net Framework team, in Redmond, Wash., and the person who did most of the coding on the Microsoft application. “Theres probably 20 [stored procedures] altogether. Every time there was some unit of work to be done, we broke that down into a stored procedure. There are two primary reasons: Its a lot easier to guard against SQL injection attacks because the database strongly types the data. The other thing is you tend to get a little bit better performance.”
Microsoft chose to use C# as the language for the application. For parameter validation and user authentication, Microsoft used ASP .Nets built-in forms validation and user authentication manager, respectively.
Microsoft staffers also used encryption for user passwords and credit card data. They did this job in application server code using Windows built-in encryption APIs and stored the encryption key in the registry. The key was further protected by registry access controls so that only the Web application user account and administrator accounts had access to the key.
Microsoft also configured IIS and ASP .Net to return a generic error page if an error occurs.
Microsoft also configured IIS and ASP .Net to return a generic error page if an error occurs.
The Microsoft test application can be accessed at www.ms.openhack.com/default.aspx.
Web Application Security Best
Practices”> Web Application Security Best Practices
- Dont use C or any language that doesnt have automatic protection against buffer overflows. Java, a Web scripting language or a .Net language are all safe choices.
- Validate incoming parameters in four ways before using them: their presence or absence, required length, required data type, and range within a set of permissible values. This also applies to variable data coming from cookies because they can be faked.
- Use a generic error page to avoid leaking application or site configuration information.
- Use a log-in manager or write standard code that ensures that every page requiring a user log-in checks to see that a log-in token exists in the server session.
- All HTML output should go through an HTML validation checker that will filter out HTML control characters such as < and > or replace them with matching HTML escape sequences such as < and >. Dont forget to do this for e-mail as well because HTML-enabled e-mail clients are just Web browsers in disguise.
- All parameters passed to the database should go through a SQL validation checker to escape special SQL characters such as a single quote.
- Database access controls on base tables should restrict the Web application log-in to the bare-minimum functionality needed to run the application. Stored procedures that wrap application database calls provide safer ways to wrap application commands and automatic parameter type checking.
- Encrypt sensitive application data such as user passwords and credit card data so that information loss will be limited if database security is breached.