Author: Christopher

A while back I found xkcd. I found it through a mailing list but this post grabbed my attention. Here’s a recent comic which made me think about the way that popular web applications use SQL databases. If you don’t get it the
Mom in the comic executed a classic SQL injection attack against her son’s school. (BTW I didn’t want to spoil the joke. You can see the previous sentence by highlighting it with your mouse.) In any case this is a common attack method against many current web applications and it shows just how naively many of the programmers are of SQL in general. There are two practical ways to defend against this attack. The most obvious is to validate your SQL before you pass it to the database engine. One that requires a little more thought would be to disallow the web database user from being able to DROP TABLES in the first place. Any real web application should expect a database with at least two users, root, or dba and webuser, or www. Root should be allowed to do anything to the database but his credentials need to be protected. If your web application has grown to the point where you’ve split your database server from your webserver for performance purposes. Allowing the root or dba level of access from localhost only is a good start. Webuser should be able to SELECT on your applications tables. He should be able to INSERT, UPDATE, and DELETE on a limited subset of tables as your database will allow. He may need to be able to CREATE a temporary table and possible DROP the same but that’s a job that’s really better done by a stored procedure. E.g. create a stored procedure that does the needed manipulation and then allow the webuser the privilege to call the stored. Obviously what you can do here depends on your database. I know that Postgresql can grant these very fine grained security settings. If I recall correctly MySQL is a little more course but is still workable.

I’ve been scratching my head on this one for far too long. I have a query under Postgresql which retrieves the distance between too points given the knowledge of their zipcodes. This work because I have an incomplete table of mileages between arbitrary three digit zipcode pairs. Each time I use this table my queries take a long time and I could never understand why. It has to do with the type that postgresql assigns to computed text fields. I was doing something like this:

SELECT * FROM worklist INNER JOIN partial_zipcode_mileage ON SUBSTRING(worklist.origin_zipcode, 1, 3) = partial_zipcode_mileage.origin_partial_zipcode...

The issue here is the type of the expression: SUBSTRING(worklist.origin_zipcode, 1, 3) as compared to the type of the field partial_zipcode_mileage.origin_partial_zipcode. The latter is a SQL CHAR(3) since it will always hold 3 characters. Postgresql assignes the first expression a type of TEXT since it has know way to know how bit a field you actually want. This prevents the postgresql engine from using the index and this, my query takes along time. Substitute SUBSTRING(worklist.origin_zipcode, 1, 3)::char(3) in the statement and all is happy.

Learned a new trick with postgresql stored procedures today. This will probably appear to be obvious but it’s new to me. You can do exception trapping in pl/pgsql by you can also ignore some errors. The form is:


BEGIN
DROP TABLE foo;
EXCEPTION
WHEN undefined_table THEN NULL;
WHEN OTHERS THEN
RAISE NOTICE, ('Notice: ' || SQLSTATE || ' - ' || SQLERRM);
END;


Most MTA’s should offer Opportunistic TLS by default

I think that the time has come for most SMTP MTA servers to offer STARTTLS session protection by default. I see two reasons for doing this. Firstly, it takes a short amount of extra time and a little more CPU horsepower and that’s a resource that spammers cannot control. Secondly, opportunistic TLS brings email security a little more in line with the security model that most users expect.

Spammers

The majority of spammers out there are relying on stealing CPU time on machines that they don’t own. I don’t see them moving to TLS at the client side anytime soon. On the other hand legitimate email senders usually aren’t sending mail in such bulk that the cost of encrypting the session would be an onorous penalty. The practical end result of this would be differentiation of mail at the inbox. We would get mail from servers that used TLS to encrypt the session and mail from servers that didn’t. Assuming that the MTA server flagged the mail on this axis by adding a header, the end result is a hook for a statistical spam filter to use.

Users expectation

The second advantage would be a little added security in email during the transport from client MTA to server MTA. If everyone adopted opportunistic TLS encryption of the wire then sending email would better approximate the users expectations for security. Compared to physical mail email without TLS is like sending a postcard. No one sends postcards where security is a requirement because it’s obvious that everyone between the point where you drop the mail in the postbox and  the point of delivery  can just read the mail. Most users don’t expect that this is the case with email right now.

The advantage of opportunisticaly encrypting the mail is that we have a situation that we can grow into. If some server doesn’t do TLS in transport the mail still gets delivered.

I’m using greylisting to filter spam. It works quite well. If you aren’t of the technique this is how it works. Greylisting filters spam by testing the RFC compliance of the server that is trying to send mail to you. RFCs 2821 and 821 describe the meat and potatoes of sending email on the internet. The RFCs both specify that the receiver may tell the sender to queue the message and retry later because the receiver is temporarily out of resources. Greylisting exploits this to sift spam from legitimate email because many Spam sending programs cannot queue mail. As a method of spam detection Greylisting is great because it takes almost no resources on the receiving side to filter. Other methods of filtering are not so resource friendly. I find that Greylisting is rejecting over my inbound 90% of the spam. I used to say that it did this with 0 false positives but after reading these two threads I’m not so sure:

• Greylisting and MS Exchange problems;
• MS Exchanges behaviour on receiving a Temporary failure error.

Leave it to Microsoft to rain on the parade.

I’m not going to stop Greylisting. It’s just been too effective at spam removal for me to even consider going without. I’m also aware of several people who are using Exchange to contact me who have not run across this problem. For me the solution to this potential problem is to contact some of the people who I know that are running Exchange and see what their awareness is on this problem.

I haven’t been writing in a while. It’s not because I don’t love it, I’ve been ramping up on a couple of projects and quite frankly that’s what I’ll be doing in about 10 minutes.

Among other things I’ve been using the Gimp to generate a new template for Vindaloo.com. I need to give credit where it’s due here. The person to talk to about this is Al Gordon. Vindaloo will be moving to Joomla soon. I’m writing a white paper on spam prevention and a few other things. I want to have a common theme for both this site and my Joomla site so I need to learn templating for both Joomla and WordPress. For Joomla the best thing seems to be PhotoShop and Dreamweaver. for the Open Source Developer who is on a budget. You can trade more time for less money and use the Gimp and Nvu. Nvu has a Mambo/Joomla Template Generator which is okay. If you are using FreeBSD and nvu make sure to get the latest copy of the port. I submitted a patch a month or so ago to enable Cascades, nvu’s CSS editor which is okay. Software:

• Nvu
• Open4G mambo/Joomla Template Builder for nvu

Tutorials:

• WordPress Template building tutorial