ApacheCON 2008 - Take 1

Finally my first Apache CON conference, I had looked forward to this day for a long time. Practically the newest frontier for open source development. As tremors of excitement ran down my spine I drove down to New Orleans to attend my first ApacheCON conference. The conference was held at the Sheraton in New Orleans, a nice place but a pretty ordinary view except from the front.

And of course i there were some quirky signs that I liked a lot like this for example

Now let me summarize the sessions that I attended, possibly some areas that might lead to potential posts in the future

Apache Security

Apache Server is one of the more reliable HTTP servers. Security of this server is quite an important consideration. Some configuration tips on Apache

• try to write your own configuration files from scratch.
• use CURL/wget and write a test scripts to see if it does what it does.
• Try to avoid conditionals like <IfModule>, if a module is not needed dont enable it
• Limit number of writable directories. tmp can create security loopholes. ChRoot, FreeBSD jail, Solaris Zones can limit what a socket can do. It create a sandbox that is accessible. Netboot servers can be used.
• Block outgoing connections
• minimize incoming connections to port 80 or 443, use bastion and ssh or sftp
• use firewalls. MOD Security is a web application firewall inside apache. It uses Rule based request filtering.
• GRANT ALL PRIVILEGES is a bad word, separate schema definition from application security code

Some reference books for Apache Security

• RYan C Barnett - Preventing Web Attacks with Apache
• Ivan Ristic - apache Security

Web Application Security

This was a great session given by Christian Wenz. Did you know that 9 out of 10 websites have security vulnerabilities? An interesting quote from Christian - “Security is like brushing your teeth”…..funny quote but quite so accurate about security. Security breaches can occur due to the following reasons

• bad advice
• lack of time
• new server API’s provides endpoints with new risks

A traditional model of web applications had both model and controller on the server side, but with AJAX based applications, more area is exposed to risk since now the controller is moved to the client side of things.

An old and persistent problem is Cross Site Scripting or XSS. With Javascript and Ajax, now potential intruders can access user cookies through javascript code, which can result in access to session ids. Login forms can easily result in XSS. The best defense is to handle characters like < > ” ‘ &. The best advice is to not blacklist using all possible combinations of the characters  but rather to try to eliminate all occurences of the previous problematic character set.

Cross site forgeries is another type of security issue that can crop up. HTTP server sends HTTP request that does not happen voluntarily. Victims may be attracted to some website. The website will send you a form and javascript which is similar to some other website. This form is then redirected to some other website so that the attacking website gets a request from a user that can be used to forge the users’s identity. Some solutions are

• users should logout as soon as possible
• never visit unknown sites

As a developer you can do the following to thwart cross site forgery attacks

• request login before critical operations
• include secret/random tokens in the form
• use random names for form elements

Who hasnt heard of SQL Injection, a potentially dangerous form of security attack that can hit the database part of your application really hard. One suggestion to thwart SQL Inejction attack is not to create a blacklist for all combinations of attack patterns, but instead use database specific methods like PreparedStatement to do the same task.

Javascript hijacking is an attack category that has been introduced by the wide spread use of AJAX and Javascript. Server backends many a time return data as JSON format. Sometimes array constructors can be overriden and offensive data can be written into it.  Solutions - use POST API, demand a certain HTTP header like Content-type:application/json.

The two general rules to thwart most security attacks

Rule #1: Validate all inputs

Rule #2: Escape all outputs

This was the core of the security sessions on Day 2. In my next post I will summarize some more sessions that I had the oppurtunity to attend.

Tags: apache con, security