Month: October 2007

Posted on

Should I use SPF?

Should I use SPF? What is SPF? Will SPF reduce the amount of spam that I get to my domain? There’s a lot of talk about SPF as a means of preventing spam these days and though it was originally designed to do that I’d have to put it down as a miserable failure at spam prevention. Does that mean that you shouldn’t use it? The juries still out on that one.

SPF stands for Sender Policy Framework. It’s a means of specifying where mail from a specific domain will come from. The implementation is an ugly kludge that overloads DNS TXT records. Through the overloaded records a remote server which is receiving a mail that claims to be from your domain can determine if it is real or a forgery… …maybe. It turns out that mailing lists that forward mail without rewriting the envelope headers as well as older mailers like mutt which still have a bounce forwarding feature will most likely false positive (e.g. receive an SPF fail).

SPF probably won’t reduce the amount of spam you receive. In fact don’t be surprised if you start to receive or are currently receive quite a bit of spam that passes the SPF tests. Many of the “more reputable” spammers, the ones sending spam using real mailservers and not hijacked windows machines on a botnet, use SPF to fool your spam filter into thinking that a piece of spam is a legitimate mail.

Should you use SPF? That depends on what you want. If you want a spam free inbox then look elsewhere. Under no circumstances should you ever assume that a piece of mail that is marked SPF fail is spam. In fact you are better off ignoring it when you test to determine the level of spammyness of your inbound mail stream. SPF does have one big positive and this is big enough that I recommend that people use it if they can.

It turns out that if you do enable SPF on your domain then spammers will no longer be able to forge messages from you as spam. To the postmaster of the domain this means that a large chunk of the those bounce messages from tens of thousands of people who don’t exist don’t get sent to you. You know what I mean the mail from postmaster@yahoo.com that says that mail from johnbigbooty@example.com to drlizardo1287341@yahoo.com failed because there is no drlizardo128341. If you enable SPF the smarter spammers will not put your domain into the from field of an outgoing spam since then people can tell it’s a forgery.

Posted on

Lil’ Bobby Tables

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.