The Security Mindset

I recently read an interesting blog post by Bruce Schneier on the type of mindset you need to have to develop software/applications with better security.

"Security requires a particular mindset. Security professionals -- at least the good ones -- see the world differently. They can't walk into a store without noticing how they might shoplift. They can't use a computer without wondering about the security vulnerabilities. They can't vote without trying to figure out how to vote twice. They just can't help it.

...

This kind of thinking is not natural for most people. It's not natural for engineers. Good engineering involves thinking about how things can be made to work; the security mindset involves thinking about how things can be made to fail. It involves thinking like an attacker, an adversary or a criminal. You don't have to exploit the vulnerabilities you find, but if you don't see the world that way, you'll never notice most security problems..."

The biggest question is how we prove that the block of code we have written is correct (no security holes what so ever)? Our proof of correctness depends on our curiosity about what might possibly go wrong - have we considered all remote and corner cases? It's more or less analogous to theorem proving in Mathematics; we say a theorem is correct only if we can prove it to be correct for all cases.

I agree with him that the lack of security mindset is a major cause for many security problems we experience today; looking at things from an attacker's perspective and analytical (Math) skills can certainly help!

Is XML worth it?

Every now and then I meet people who hate XML (some of my lab mates are also in the 'XML sucks crowd'). As a person interested in XML related technologies, I thought of looking into this issue and see if XML really sucks or it's just that you cannot satisfy everybody.

One of the criticism is that XML is slow to parse compared to flat files such as CSV files. This fact about the speed is true. However, the comparison is quite flawed as it's like comparing apples with oranges. XML provides a parsable definition of a document structure while CSV's or similar approaches do not. We need to realize that the benefit comes at an extra cost!

In XML-sucks web sites, they deliver the message that XML is hard to deal with in programming paradigm. IMO, this fact was true during the early days when XML was invented about a decade ago where there were only a few libraries and tools to work with. Now, the situation has changed; there are many libraries (both DOM and SAX) for various languages which are not that hard to master once you spend some to learn the basics.

Another criticism is that XML is verbose (use more bandwidth than required to do the job). With the multimedia age, I don't think this addition of markups going to create a huge difference in the bandwidth usage (provided that we judiciously use namespaces). Further, there are compression techniques on XML already available which help reduce the message size. If you are really really concerned about the message sizes and the interoperability or any other cool things about XML are not required, I suggest you don't use XML. In my opinion, the gain we get is well worth the price we pay for the additional
bandwidth, which is after all textual information.

I agree that while XML itself is quite simple, it gets complicated with the proliferation of related technologies. However, complexity is partly under our control as we decide what we want to use along with XML. The trick is to use only those technologies that are absolutely necessary and have matured to become standards.

XML is for hierarchically structured data and can be an overkill for data with no hierarchy. For example, if a property-value file (like in Java) is sufficient for the job, you will not gain anything by using XML but loose for performance. XML-suck groups compare the data of the latter type in XML with other alternatives available and gives a false impression. If your data is not hierarchically structured and do not have a requirement to use a specific document format, I would go for a flat file format.


Some of the cool features of XML that makes it stand out from other approaches:

Addresses the internationalization (i18n for short) issue
If you don't know what encoding the data is in, the data is virtually useless. With the global economy becoming one single market, internationalization (which allows to adapt to various languages and regions without engineering changes) of data becomes necessary. So, the encoding becomes an import factor. An XML document knows what encoding it's in. There's no ambiguity in an XML document which is a sequence of characters and these characters are coded and then encoded in a specific character encoding. The encoding used decides the number of bytes required for the coded characters (for example UTF-8 requires 1 byte). No matter what software you use, it can process any XML document making it ideal for data exchange.

Enforces creating well-formed documents
XML syntax enforces to have properly nested documents which allows you to verify the document is structurely correct to a certain degree.

Can enforce to create valid documents
In addition to proper nesting, you may need to make sure the document includes only certain elements and attributes, their data types, etc. These documents are declared to meet a DTD or XML Schema (successor of DTD). The nice thing about XML Schema is it itself is written in XML and there are a whole bunch of validation tools out there to validate the XML document against the schema.

Promotes syntax-level interoperability
In the software industry, interoperability has been one of the hardest goals to achieve. People initially thought that having well defined API's is the way to go. However, this approach does not work across heterogeneous operating systems. If you look at the success of the Internet and its related technologies, one thing is common; they all have bits-on-the-wire definitions (i.e. syntactic level).

A safe way of keeping data long term
As we all know, information/data outlives technologies we have today. Therefore, keeping data in proprietary formats may not be a good choice especially if the data are anticipated to be used much later down the time line. XML solves this problem as it's an open specification and is not tied to any specific technology.

To sum up, if you use XML only for those tasks for which it is designed to be used, it can pay you off; XML is not a solution to every data problem we encounter.

Main References:
Why XML Doesn't Suck

For a Good Cause

With the rising cost of living, many people in Sri Lanka find it hard to meet their ends. It is unfortunate to see many drop out from schools and universities due to financial difficulties. A small helping hand for those needed can go a long way since the education is the backbone of any country. It can also be a bridge to increase the mutual understanding between people of different ethnic groups in our country. For the last couple of years, Educate Lanka non-profit organization has been working towards achieving this goal. I'm fortunate to be a part of this effort and help some university students continue their studies. They have a well-managed program and support elementary, secondary and university students. You don't need to be super rich to be a sponsor; all it takes is a few bucks per month. Our collective effort can make a difference!

Ubuntu + PHP + MySQL

For a project I've been working on, I wanted to get MySQL (5.x) working with PHP (5.2.x) in Ubuntu (Fiesty Fawn, haven't switched to Hardy Heron yet). I haven't worked with these software for quite some time. I tried to get it working by manual configurations (installing the required packages and editing the php.ini to have the mysql.so extension), but had little luck with it. Fortunately, I found the this reference. I first completely removed apache2, php5 and mysql from my distribution and apt-get installed the following.

sudo apt-get install apache2
sudo apt-get install mysql-server libmysqlclient15-dev
sudo apt-get install php5 php5-common libapache2-mod-php5 php5-gd php5-dev

You can set a root password for MySQL server with the following command (initially the root password is blank).

sudo /etc/init.d/mysql reset-password

Now php should work along with apache2. However, we still need to get it glued with MySQL. Installing phpmyadmin does the trick.

sudo apt-get install phpmyadmin

For PHP to work with MySQL, we need the php5-mysql package. Installing above phpmyadmin package automatically installs php5-mysql for you. Now you should see a section for MySQL in phpinfo(). If you go to http://localhost, you will see a folder called phpmyadmin which provides a web interface to your database server.

If you happen to forget the root password of your MySQL (which happened to me), you can do the following to reset.

First stop the already running MySQL server:
mysql server /etc/init.d/mysql stop

Start MySQL in safe mode with privilege checking switched off:
mysqld_safe --skip-grant-tables

Log into MySQL as root user:
mysql --user=root mysql

Execute the following:
update user set Password=PASSWORD('new-password');
flush privileges;
exit;

Now kill the MySQL daemon started in safe mode and you are all set to work in the regular mode.