Josh More – Starmind Blog

Let's start with some basic assumptions:

1. You must have a website to do business in today's world.
2. Your customers have to be able to post content, either on your website or on a shared thirdparty site that you have to use to communicate with them (twitter, Facebook or LinkedIn.
3. That communication method will be attacked.

So, you have two scenarios.  Your own website or a third party website.

If it's your own website, you have a bit more control.  There are techniques that you can use to limit cross site scripting.  The common advice is to use a whitelist of "good" characters, and filter out everything else.  That's not hard to do, actually.  However, the problem has to be solved at every possible entrypoint, which if you don't design it into the system can be very difficult.

However, if it's on a third party website, your options are a trifle more limited.  You don't know what they allow or disallow.  You don't know what other users are going to post, or even who they may be.  What you do know, though, is that there will be attacks.  Do you trust them?

Odds are that the answer is "no".

The good news is that there is a simple test that works on both your own website and the third party systems.  Just log in and find what of your data you can see.  If an attacker gets in, they will run attacks as you.  If your local workstation is protected, you can probably assume that the attack will be limited to the context of the website itself.  Thus, you can limit what an attacker can get to by simply controling the data that you allow online.

So here are two good rules of thumb:

1. If you don't need to put pieces of data online, don't.
2. If the site requires information that you don't want to give, either don't use the site or make something up.

Related posts

• Small Business Attack – Cross Site Scripting (0)

On September 23rd, LiveJournal was attacked. The attackers used flash. When the flash file was loaded, it ran within the context of the user who was logged in and made changes to recent posts. This allowed the attack to spread friend-to-friend. It also harvested email addresses.

Doesn't sound like much, does it? After all, it's basically a flash virus that steals email addresses, right? What's new there?

Well, let's look at the one thing that makes LiveJournal a successful site. At it's core, it allows users to post content and share links with one another. In order to block the attack, the admins had to effectively break the site until they tracked it down. The one thing that LiveJournal requires is the same thing that the attacker was able to use to get in. In fact, given what it does, there may not be a way to secure the system and still give users what they want.

OK, then, suppose you accept the fact that you're going to be successfully attacked. How do you protect yourself?

It's interesting to note that the attackers just wanted email addresses. Odds are that they could have gotten other things too. However, since many people publish their list of friends, it would be trivial to link those email addresses to other email addresses. Now, if you have a database of email addresses and the email addresses of people that are their friends, you have just what you need to run a phishing attack.

Do you allow your customers to post content on your website? Do you use any websites that allow you or your associates to post content? How are you protecting your data?

Note: since I wrote this post, but before it was posted, Reddit was similarly attacked.

Related posts

• Small Business Defense – Cross Site Scripting (0)