I am not going to specifically address the topic of scripted attacks (such as click-jacking, like-jacking, using tools like Selenium, etc) used to game contests. There are just too many variations, and frankly, many of the data analysis concepts here would apply to that scenario as well.

Understand that I Am Not a Lawyer, and am NOT giving you legal advice here. The intended audience for this article is application developers, database architects and product directors, as we discuss some fundamental concepts that must be integrated into your contest application before even a single line of code is written. Many of these concepts can be applied to non-Facebook online contests, but some are Facebook specific.

Also, if you got to this article because you’re trying to learn how to game a Facebook contest, please die in a fucking fire. You are a useless piece of shit, and people like you are what is wrong with the world.

First things first, and a little bit off-topic, if you’re planning on creating a Facebook contest, be sure your contest abides by Facebook’s promotional policy guidelines. They’re a pretty quick read, but failing to read them before deploying a contest on Facebook may result in Facebook disabling your contest for policy violation. You can (and should) read the whole set of guidelines here, but since we’re about to discuss planning your contest app, the ones you really need to be mindful of are:

1. You must not use Facebook features or functionality as a promotion’s registration or entry mechanism. For example, the act of liking a Page or checking in to a Place cannot automatically register or enter a promotion participant.
2. You must not condition registration or entry upon the user taking any action using any Facebook features or functionality other than liking a Page, checking in to a Place, or connecting to your app. For example, you must not condition registration or entry upon the user liking a Wall post, or commenting or uploading a photo on a Wall.
3. You must not use Facebook features or functionality, such as the Like button, as a voting mechanism for a promotion.
4. You must not notify winners through Facebook, such as through Facebook messages, chat, or posts on profiles (timelines) or Pages.

Basically, this means that you can’t use any of the native Facebook platform tools as voting or winning mechanics. You can like-gate an app, requiring the user to like an app or page before being shown the contest sign-up form, but you cannot use the act of liking the app or page as the registration itself. You cannot award points or incentives on a Facebook share, but you CAN award points or incent the conversion. So if your app lets me invite people to your app, you can award me points for every one of my friends that allows the app and participates, but you cannot award me points based on how many people I invite that do not convert to app users or clickthroughs or what have you.

There’s a little bit of nuance to it, but the general rule is just to avoid using the platform for stuff that determines who wins or loses, period. That part has nothing specifically to do with gaming a Facebook contest (or the prevention of gaming a Facebook contest), but it’s pretty important, and will influence some pretty core mechanics in your contest, so don’t gloss over them.

Rule #1 of running a contest: LOG EVERYTHING

Log absolutely everything possible. Require that the user is logged in, and always log their FBID *and* their IP address. Your legal counsel will thank you for it.

You need to be able to run an audit on every action related to potential winning or losing of the contest for your own liability, but also because it is the foundation of putting yourself in a good spot to detect suspicious or fraudulent activity. Seriously.

If ass-wiping influences the contest outcome, you had better be logging every single time the user wipes their ass, complete with IP address, user agent, timestamp, and anything else you can think of that would be specific to that action+session combination. I simply cannot emphasize this enough.

Without extensive logging, you will be left absolutely helpless when a user (or their lawyer) challenges your winner decisions, or when other users claim a specific user is cheating.

Make sure your web server is logging access correctly as well. You may need to correlate your Apache access log to a specific transaction and IP address as well. Test this before your app goes live.

As you analyse your logs, look for inconsistencies in user agent and/or IP address. If their user agent is logged as “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7″ in one log entry and “Mozilla/5.0 (Intel Mac OS X 10_7_2) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7″ in the next, something is up. The differences between those two user agent strings is subtle, but it’s there, and there is no legitimate reason for it to change from action to action in the same session.

Rule #2: Get their email address

It seems intrusive, but if your loot is decent, people won’t mind giving it to you. Once they have allowed your application and granted you email permission through the app allow dialog, you can pre-populate the email address field so they don’t even have to type anything in. You’ll need their email address anyway, to notify them if they won, since Facebook doesn’t allow you to use FB Messages to do that.

You want their email address because users creating fake Facebook profiles (each of which requires a unique email address) to generate bogus votes/points/whatever will generally not be terribly creative (or may be using an automated script or service to do it), so you can use the email addresses as a way to detect patterns in participating users that could imply fraudulent activity. If you see 100 new entries, all with the email pattern of firstname1234lastname@hotmail.com, there’s an excellent chance that those entries are bogus.

Brace yourself for the truth

The cost of winning a Facebook contest by cheating is much lower than you probably imagine – and unsurprisingly, there are businesses online that exist for the sole purpose of helping people win online contests. Right now, on a casual Google search, I can find services that will sell me 10 PVA (Phone Verified Account) Facebook accounts for $20. I can buy 100 non-PVA Facebook accounts for $20, if I think the contest won’t do that much checking for fraudulent activity. If you do a search for “facebook contest” on sites like freelancers and microworkers (I will not link to them), you’ll find hundreds of people with Facebook accounts just itching to get paid to help your potential contestants game your contest.

If you’re giving away a trip worth $3,000 and because of the number of participants, it would cost me $20 to win your contest, you are *going* to get gamed. My risk-to-reward-ratio is just too good for me not to do it. I spend $20 and I get $3,000 worth of prizes? Hell yeah.

In one investigation I performed, I saw bids of $30 accepted for people to get 200 people (real people or fake-but-look-real accounts) to vote x times. That means each one of those Facebook accounts is worth $0.15 to the person renting them out. Consider creating accounts at these microjob sites before your contest is over and check it for openings related to your contest.

Additionally, since there are people and services out there that have created Facebook profiles for exactly this purpose, you can’t rely on Facebook profile creation date as a reliable measure. Many of the fraudulent accounts I’ve come across have been around for over a year prior to the contest. They’re also smart enough to make sure these profiles have friends that look legitimate, so it won’t be as easy as looking for FB accounts that are new and have no friend connections.

It gets worse. There are also online sites that encourage users to do like/vote exchanges. “Vote for me for blah, and I’ll vote for you.” This method tends to be slower than simply buying accounts, but it’s also free. Search Facebook for terms like “vote exchange” and you’ll find pages and groups for the sole purpose of gaming contests.

It’s up to you to decide whether a vote/contest exchange falls under your definition of cheating. It absolutely does in my book, but it really depends on how your contest works. Either way, you need to set the definitions of what exactly qualifies as cheating before your contest even starts, because you’re going to run into more gray areas than you probably would have thought.

Rule #3: NOTHING GETS DELETED. EVER.

If users can submit content as part of the contest, make sure you architect your application in such a way that nothing ever gets deleted, either by moderator or by the users themselves. Instead use a database flag to toggle visibility in the app. Log the deletion (timestamp, IP, user agent, who took the action, etc) and tuck it away, but never, ever delete the data.

Doing so insulates you from users saying “I didn’t delete it!” You will have proof that they did, including all the particulars such as what browser they were using and when. This also allows you to recover from content that is accidentally deleted by a moderator. If “deleting” content is simply toggling that boolean database field, it’s easy to toggle it back on if it gets toggled off by mistake.

Rule #4: Know what counts as cheating up-front

This sounds like a no-brainer. Cheating is cheating, right? But if someone didn’t actually pay for votes, and did a vote exchange or spammed forums and Facebook groups to get votes from people who don’t actually care about the program, is that cheating?

What if the Facebook account that’s participating is “real”, but the person only ever uses it for entering contests? Is that a legitimate user to you, or a cheater? You should figure that out ahead of time.

It’s going to be your choice as to what level of detail you disclose your policies on cheating. My recommendation is to be a little vague. While this goes against my standard policy of transparency in everything, if you give the bad guys an explicit set of rules on how you define cheating, they will be sure to tailor their cheating to specifically avoid the things you outline. If you tell me (as a bad guy) that my votes will be disqualified if too many votes come in from the same IP address, I will be sure to use different IP addresses for each vote to make sure I avoid your detection.

Rule #4: Audit, audit, audit and audit some more

Auditing by eyeball isn’t really going to cut it, but if it’s all you’ve got, it’s better than nothing. A better idea would be to set up a series of heuristics programmatically that flag user activity as being suspicious and requiring additional review. Things like the number of unique users coming from a specific IP address, the time of day that you see the most activity, the kinds of email addresses you see associated with the participating users, etc.

Look for patterns that don’t make sense. Examine the Facebook pages of the folks you suspect of cheating. Do they have any wall posts? Any photos? Do they have friends? Click on their friends profiles – do their profiles also have no wall posts and no photos? Look for generic “hot babe” profile photos. Look at the pages and topics the user has “liked”. Do they seem a little too demographically on-point, as if they were created to appeal to a specific contest demographic? Is there a pattern in the things they’re liking? (All contest pages, etc.) This part can’t be automated.

Give yourself the time between the end of the contest and the announcement of the winner to be thorough and audit all of your top contenders. Hold off notifying anyone that they won until you’ve had a chance to comb through this data and you feel confident that it’s legitimate.

You have a cheater. Now what?

When you find someone cheating, how are you going to handle it? Revoke their points/votes/etc? Disqualify them? Whatever your decision, know what you’re going to say to them in advance, because if the stakes are high enough, there’s a good chance they will be loud and public about how you wronged them. Once again I advise not showing too much of your hand.

If you decide to confront them and allow them to offer explanations, hold specifics back. If you user claims, for example, that they got most of their votes from their friends at a high school using their own computer (which would explain the same IP address), but the timestamps on the votes are at 1AM, 2AM, etc, that should raise some eyebrows. If you tell them too much about what you’re basing your decision on, a decent cheater will come up with excuses to explain them that they would have mentioned earlier if the story was legitimate.

It’s rare to find a smoking gun in these cases. Instead, it’s going to require a some judgement calls and a preponderance of evidence. It’s very like you won’t find *one* thing that makes you *sure* someone is cheating. Instead you’ll find a half-dozen things that, when combined, form an equation that just doesn’t add up.

One option, upon finding a cheater, is to disqualify just the votes that seem fraudulent. In the case of a contest where the user submits an entry and other people vote on it to determine a winner, be cautious of disqualifying the entry based on fraudulent activity. Knowing how inexpensive it is to buy Facebook profiles, if I were a particularly bad guy who had also submitted an entry, I might consider spending some money to game my opponent’s entry in a way that was obviously fraudulent to get their entry disqualified.

If I knew you would kick anyone out if you detected any fraudulent behavior on their entry, I might go out of my way to make sure you found some on the other guy’s entry to increase my chances of winning by kicking them out of the running. This technique, similar to joe jobbing in the spam world, isn’t one I’ve seen often, but it’s only a matter of time.

Make a decision and be prepared to stick with it. Feel confident that your decision was the right one, and don’t back down. The bad PR from the folks you disqualify will be better than the bad PR from the rest of the contestants claiming that your contest is rigged or allowed fraud. Your legal department will make sure you have a TOS that basically says that you don’t owe anyone an explanation, and it’s up to your discretion to disqualify anyone for any reason.

Running a (good) contest is an incredibly laborious process. The technical aspects of creating the app are honestly the least complicated, least time-consuming part of the whole thing. Make sure you have the appropriate resources to handle it. If you half-ass it, you will regret it.

Nailed it.

Not quite. Honestly, there is almost no fool-proof way of detecting all fraud activities – partly because some of this fraud is being conducted by actual people, not machines. They’ve invested the time into creating profiles that look real.

You’ll be able to find the ones that do a crap job of it, but a few of the more sophisticated folks will have profiles that have current wall posts about things other than contest spamming. They’ll have photos uploaded, lots of friends, and profiles that weren’t recently created. Fortunately for you, those kinds of profiles tend to be more expensive to buy, since they require more work to upkeep to look legitimate.

Maintaining believability in a friend network that large requires a lot of time, so examining the friend profiles associated with your top contestants is absolutely critical. If you poke around enough, you’re bound to find something that doesn’t fit. Examining their entire footprint on the social graph will give you a much clearer picture than a specific profile.

Also check out:

Note: this article is long, but that’s only because I’m trying to explain in some degree of detail, and call out specific gotchas that you may run into. I promise you that setting these two up is incredibly easy, and shouldn’t take you more than a twenty minutes or so to have both up and running.

Advanced Policy Firewall (APF) is an iptables based firewall system that’s easy to set up and administer, and works hand in hand with Brute Force Detection (BFD).

BFD is a modular shell script for parsing application logs and checking for authentication failures. It does this using a rules system where application specific options are stored including regular expressions for each unique auth format.

Together, they provide a simple but effective way to handle locking out brute force login attempts. Using APF, you could actually take it a step further and deny ALL SHH requests except those originating from a set of whitelisted IP addresses. This may not be feasible – or a good idea – if you do not have access to a static IP address, however, since you could end up locked out of your own box. We get into restricted whitelisting a little further down the page.

The basic gist is this: Someone tries to brute force their way into your server via SSH. Since they do not actually have a valid username+password combination, the login attempt will fail, assuming you don’t use shitty passwords that can be easily guessed, in which case they login successfully, and you’re pwned. After x failed attempts (where you define x in the configuration file), BFD will automagically tell APF to add the IP address of the offending attacker to the APF blacklist for a certain amount of time (also configurable in the config file). All services will be denied to that IP address, so they will no longer even be able to see your website.

The purpose of this is pretty obvious, but (for those of you who took the short bus in) one of the primary benefits is the ability to easily mitigate automated brute force attacks on your server, where a script is being used to try various combinations of usernames and passwords until they successfully login.

If you think your server is too insignificant for an attacker to bother with, you’re wrong. If you have an IP address that is visible to the rest of the world, you will end up being brute-forced at some point. Whether or not the attack is successful is up to you.

There are other firewall+brute-force-detection combinations out there, including the very popular Fail2ban, that also work very well. I’m not endorsing one over the other, I’m just more familiar with APF+BFD.

Anyway – let’s get to the good stuff. Note that you will need root/sudo access to your server in order to continue.

Setting Up Advanced Policy Firewall (APF)

Before moving forward, it should be noted that you are installing an iptables-based firewall. This means that if you screw something up, you could lock yourself out of the server, deny all traffic to your server resulting in a downed website, etc. Be careful, and don’t make these kinds of configurations on a production machine during peak site traffic hours. To test that your configuration is working properly, you’ll want to have access to SSH from another IP address that you can safely lock out without limiting your ability to administer the server.

1. [root@server]# cd /root/downloads (or any other temporary folder)
2. [root@server]# wget http://www.rfxnetworks.com/downloads/apf-current.tar.gz
3. [root@server]# tar -xvzf apf-current.tar.gz
4. [root@server]# cd apf-9.7-1 (or whatever the latest version is)
5. Run the install file: [root@server]# ./install.sh
6. You will receive a message saying it has been installed.
   Installing APF 9.7-1: Completed.

Installation Details:
Install path: /etc/apf/
Config path: /etc/apf/conf.apf
Executable path: /usr/local/sbin/apf
DShield Client Parser: /etc/apf/extras/dshield/

Now configure the firewall: [root@server]# vi /etc/apf/conf.apf

Make sure DEVEL_MODE="1" is set until you’ve gotten everything working. This will allow you to get back into your server if you cock something up and get locked out, as it tells the script to clear the cron settings every 5 minutes. Once you’ve got APF tested and working as expected, set DEVEL_MODE="0" here.

The majority of the default options in the config can (and should) be left alone unless you know what you’re doing. As you go further into the config file, you’ll see stuff like this:

##
# [Remote Rule Imports]
##
# Project Honey Pot is the first and only distributed system for identifying
# spammers and the spambots they use to scrape addresses from your website.
# This aggregate list combines Harvesters, Spammers and SMTP Dictionary attacks
# from the PHP IP Data at: http://www.projecthoneypot.org/list_of_ips.php
DLIST_PHP="0"

DLIST_DSHIELD_URL="feeds.dshield.org/top10-2.txt"
DLIST_DSHIELD_URL_PROT="http"

All of the above are optional and allow you to implement additional resources such as DShield and Spamhaus to block known spammy or suspicious IPs from being able to access your server. You can leave them off if you’d like (they are off by default) or turn them on for additional protection. (You’ll need to install the DShield scripts, but I’ll get to that in a moment.)

Configuring Ports:

The APF config file will come with some default ports pre-set, but you’ll want to check and make sure everything you need is covered. You will also want to determine whether or not you’re using any uncommon port numbers (for example, for a hosting control panel) that should be added to the configuration file. Please don’t ask me what port numbers your specific hosting control panel uses. I don’t know, but I’m sure Google does.

# Common inbound (ingress) TCP ports
#IG_TCP_CPORTS="22,80,443"
IG_TCP_CPORTS="21,22,25,53,80,443,110,143"

# Common outbound (egress) UDP ports
EG_UDP_CPORTS="20,21,53"

If you restart the firewall and something is down but no errors are thrown, there’s a good chance you missed a port number here. Make sure to account for SSL ports (443) if you’re running an SSL certificate, etc.

Once you’ve made all of your tweaks, save the config file and start the firewall:
/usr/local/sbin/apf -s

If you’re satisfied that everything looks okay and all services are responding as they should, go back into the APF config and change DEVEL_MODE="1" to DEVEL_MODE="0" and flush the firewall: /usr/local/sbin/apf -f

Common APF Commands

Start: /usr/local/sbin/apf -s
Restart (flush and load): /usr/local/sbin/apf -r
Flush: /usr/local/sbin/apf -f
List Chain Rules: /usr/local/sbin/apf -l
Status: /usr/local/sbin/apf -st

Manually Whitelisting/Blacklisting IP Addresses

For the commands below, replace HOST with an IP or FQDN (Fully Qualified Domain Name) and COMMENT with your comments (no spaces) as to why you’re manually allowing or blocking an IP.

Add to allowed hosts (whitelist) and load new rule: /usr/local/sbin/apf -a HOST COMMENT
Add to denied hosts (blacklist) and load new rule: /usr/local/sbin/apf -d HOST COMMENT

To autostart apf on reboot, run this:
[root@server]# chkconfig --level 2345 apf on

To remove it from autostart, run this:
[root@server]# chkconfig --del apf

Using DShield

If you’re interested in using DShield with APF, you will need to install it first from the extras directory:

[root@server]# cd /etc/apf/extras/dshield
[root@server dshield]# ./install
Installation completed.
Binary: /usr/local/sbin/dshield
Config: /usr/local/dshield/dshieldpy.conf
Cronjob: /etc/cron.daily/ds

Warning: Running the binary from command line will send reports to dshield.org;
repeated execution may result in your IP being banned from the service.

Now you can edit the DShield configuration file, including turning on email alerts, database logging and other stuff. Again, leave this alone (or leave it uninstalled) if you’re not sure what you’re doing. Your APF will function just fine without it:
[root@server]# vi /usr/local/dshield/dshieldpy.conf

Setting Up Brute Force Detection (BFD)

First things first, you MUST have APF installed. BFD was written specifically to work with APF, so you have to start with APF and then install BFD.

1. [root@server]# cd /root/downloads (or any other temporary folder)
2. [root@server]# wget http://www.rfxnetworks.com/downloads/bfd-current.tar.gz
3. tar -xvzf bfd-current.tar.gz
4. [root@server]# cd bfd-1.4 (or whatever the current version is)
5. Run the install file: [root@server]# ./install.sh
6. You will receive a message saying it has been installed
   .: BFD installed
Install path: /usr/local/bfd
Config path: /usr/local/bfd/conf.bfd
Executable path: /usr/local/sbin/bfd

Now let’s take a look at the configuration file:
[root@server]# vi /usr/local/bfd/conf.bfd

What you’ll see is a short file that starts like this:

# how many failure events must an address have before being blocked?
# you can override this on a per rule basis in /usr/local/bfd/rules/
TRIG="10"

# executable command to block attacking hosts
BAN_COMMAND="/etc/apf/apf -d $ATTACK_HOST {bfd.$MOD}"


These options are pretty straightforward. TRIG is the number of tries a user is allowed before they trip the BFD deny trigger. For PCI compliance or other strict environments, this number is usually pretty low – but it’s important to keep things practical. Security must always be a balance between making things safe and keeping them useable by the people who need to use them. If you had a lockout policy that after one try, a user is locked out for a day, odds are excellent that you’d be crippling your admins/devs. Who hasn’t fatfingered a password? These measures should be as unobtrusive to the users who legitimately need to be there as possible.

The very concept of a brute force password attack is one where the attacker doesn’t have either a valid username, a valid password or both. The odds of an attacker randomly guessing a username and password combination within 10 tries, or 20 tries, or even 100 tries is pretty low. Brute force attacks generally exploit things like default admin passwords, very common passwords (like ’123456′ or ‘password’ or ‘fuckyou’), or they are a more prolonged attack consisting of thousands and thousands of random login attempts. The attacker is literally trying to brute force their way in, since they have no other means by which to access your server that way.

Making the tolerance threshold very low doesn’t keep you safer from a brute force attack and will only serve to frustrate your users and create more work for yourself, since you’ll have to manually release the lock once they’ve boned their password a few times. So keep this number reasonable, and remember what it’s there for, or you’ll be making yourself and everyone who needs to access your server miserable.

Enable Email Alerts

You may or may not want to be alerted when someone has tripped the brute force detection script and has been added to the APF deny rules. If you’re on a frequently hit server, these emails could be overwhelming (or could even arguably help create a denial of service situation) but in general, I find it helpful to leave these on. I have filters set up in my email so they don’t flood my inbox. If you’re using a log analyzer/alert system like Splunk, you probably don’t need to turn on email alerts, but that’s up to you.

Find: ALERT_USR="0" CHANGE TO: ALERT_USR="1"
Find: EMAIL_USR="root" CHANGE TO: EMAIL_USR="your@yourdomain.com"

VERY IMPORTANT! Prevent locking yourself out!

You will want to make sure you’ve whitelisted your own trusted IP addresses pretty early on in this process. If your office has a static IP address or range of IP addresses, you’ll want to add these right away. By whitelisting these IPs, you prevent the possibility of locking yourself out of your own server by fatfingering your own password.

To add IPs to the ignored host list:

[root@server]# vi /usr/local/bfd/ignore.hosts

… and add your own trusted IPs, one per line.

Once you’ve got BFD configured to your liking, start it up!
[root@server]# /usr/local/sbin/bfd -s

Test the System

Once you think you’ve got everything working, try logging in from a non-whitelisted IP. If you have another server with it’s own IP address, for example, you could SSH into that server, and from that server SSH into your now-hardened server, using a username and password combination that you know is not valid.

While doing that, tail the APF logs, so make sure the attempts are being logged and the lockout works as expected:

[root@server]# tail -f /var/log/apf_log

Once you pass the number of attempts specified in the BFD config file, you should see the apf_log record that the offending IP address has been added to the denied hosts file.

Allowing Only Whitelisted IPs to Access SSH

If you’ve got static IP addresses and you want to lock your server down even more, you can skip BFD and simply deny ALL SSH requests coming from unknown IP addresses. This is easy to do, but also easy to forget additional IPs that legitimately require access (remote backup systems, managed hosting company support, etc) so be sure to think through everything that legitimate needs access, and be prepared to tweak the IP list if you discover things you broke.

1. Open the allowed hosts file: [root@server]# vi /etc/apf/allow_hosts.rules
2. Scroll down until after the last comment in the file with the ##
3. Add the following:
   tcp:in:d=22:s=YOURHOMEIPHERE
out:d=22:d=YOURHOMEIPHERE

   The d=22 is the port, since you’re specifically addressing SSH which usually runs on port 22. You can repeat for other services as well to limit other connections by port if you like.

4. Open the denied hosts file: [root@server]# vi /etc/apf/deny_hosts.rules
5. Scroll down until the last default comment ## then below it add the following:

   tcp:in:d=22:s=0/0
   out:d=22:d=0/0

6. Restart APF: [root@server]# /usr/local/sbin/apf -r

You wouldn’t use IP whitelisting restrictions in combination with BFD, since the process of whitelisting your internal IPs will override the BFD protection. In other words, with whitelisting restrictions, any user who isn’t on an authorized IP address won’t even be

Test the System

Testing this one should be pretty easy. Simply try to connect via SSH from any IP address that isn’t one that you whitelisted in step 3 above. What you should see is a connection attempt timeout or connection refusal. Try a new SSH connection from a whitelisted IP and you should get the SSH password prompt.

Two-Factor Authentication

If you really want to lock things down, you may want to consider adding two-factor authentication to your login. SSH keys would be something you have – plus a password as something you know – but for some reason it’s still not possible to require a password with SSH keys (to my knowledge – please correct me if I’m wrong). So instead of two-factor, you end up with a different one-factor (something you have instead of something you know).

Years ago, setting yourself up with true two-factor authentication was prohibitively expensive, so not a lot of smaller folks were doing it. These days, Citrix key fobs are being replaced by a new generation of more affordable and practical tokenless two-factor authentication systems, such as PhoneFactor and DuoSecurity.

Both of these options are pretty cool, and reasonably easy to implement. I’m in the process of setting up a few of our boxes with DuoSecurity (can’t beat the price), with the help of this fantastic tutorial by Jeremy L. Gaddis over at EvilRouters.

Also check out:

So the user gets a notification “John Smith has made you an administrator of XYZ page”. The user clicks on the page to see what they’ve just been made an admin of, and the poisoned default page tab kicks on, busting them out of the Facebook site and into a standalone page offering promises of free iPads and various other too-good-to-be-true freebies.

In this particular case, the scammers were using the extremely popular – and from what I can tell, legitimate – application Static HTML IFRAME, which simply allows people to create their own IFRAME tabs to add to their Facebook page without the hassle of creating their own application, hosting content, etc.

The IFRAME page that loads in the Facebook page points to s3.amazonaws.com/statichtmlplus/page/160281910702810.html – so it seems that the Static HTML IFRAME app just saves the content that their users add to their custom IFRAMEs into a static HTML file and serve it accordingly.

In the case of this scam, the IFRAME page hosted by the Static HTML IFRAME app contains another, hidden IFRAME inside of it that forces the browser to redirect to the scam website.

This is a combination of social engineering (taking advantage of the fact that the new administrator will obviously want to know what it is they’ve been made an admin of, thus getting them to look at a page they would otherwise never have found or cared about), and very basic technical jiggery pokery to bust out of the frames and take the unsuspecting admin to a third-party site.

The third party site in this case was a survey/iPad 2 giveaway scam (ipad2-test-and-keep.com), but this method could just as easily be used to serve malware or phishing pages.

Imagine how easily this would flow if if the frame-buster page instead took the user to a page that looks just like the Facebook login page. They think they’ve somehow been logged out, they fill in the login form to log back in, and now the bad guys have their Facebook credentials – which statistically are likely to be the same credentials they use for banking and other things.

The IP address of the scam site the IFRAME sends the user to, 92.241.169.80, tracks back to a Russian web hosting company, 2×4.ru.

We’ve already reported this scam page to Facebook using the normal routes and through the Preferred Developer Consultant avenues, but I’d be willing to bet we’re going to start to see a lot more of this kind of thing because it’s incredibly effective and very simple to execute.

Thanks to @uberbrady for seeing this for what it was when it happened to him, and bringing it to our attention.

Don’t forget to “like” our special Social Media Scam Alert page on Facebook and follow @scamdb on Twitter for more updates like this.

Also check out:

We’re finally at a point where someone who spends a reasonable amount of time at a server command line can actually get real work done, and I gotta say, it’s pretty cool. Just last night I was discussing an obscure Apache config issue with a friend at a bar, and rather than working from memory, I busted out the iPad and my Bluetooth keyboard, and 5 minutes later, the configuration issue was solved.

Having the freedom to go to the park to read for a bit but knowing I have the ability to handle an emergency should it come up is very freeing. Yes, I have become that douchebag at Starbucks – and you know what? I fucking love it.

Anyway. Point is, the iPad (or iPhone) can be used for more than just porn now (which is good, because the folks at Starbucks get surprisingly upset when you try adding your own “cream” to your latte), and I’ve spent some time and money to try out some of the most promising apps in the app store that allow you to do actual work, and edge the iPad closer to being a viable option for a netbook replacement.

I didn’t address any design/mockup/mindmapping apps in this list, but that may be a topic for another post sometime. This list isn’t meant to be all-inclusive, and doesn’t reflect the totality of what is available in the app store – it’s a short list of personal recommendations of products I actually use and like.

Disclosure: Some of the links below are hooked into the iTunes affiliate program so that I might get a penny or two if you decide to buy, however the recommendations are legit, and I wouldn’t recommend something unless I had used it. Click through on the affiliate links or don’t – but do leave me a comment if you’ve fallen in love with something I haven’t mentioned here.

Code Editors/FTP

There are quite a few nice code editors for iPad in the app store, but I won’t consider any that only offer FTP instead of SFTP and neither should you. I am just as likely to use vi in an SSH app on my iPad as I am to use a code editor, but for handling multiple open files at one time, sometimes an editor is kinda nice. Unfortunately, 90% of the code editors in the app store are complete and utterly shit-tastic garbage. Seriously. Even if you don’t pick one of my recommendations, make sure you read the comments on the code editor apps before you buy so you don’t get burned.

Textastic

I think Textastic might be my new favorite code editor for iPad. The interface is very clean, it supports FTP and SFTP, integrates with Dropbox and WebDav (if you’re into that sort of thing) and comes with syntax highlighting for around 80 different languages. It’s a little pricier than some of the other options, but I think it’s well worth the investment. I want to make sweet ASCII love to it all the time.
In iTunes: Buy Now ($9.99)
Developer: Alexander Blach

Gusto

Gusto is pretty sexy and has come pretty far in a short time. (When it first appeared in the app store, there was no SFTP support.) It supports projects, one-touch uploading, background processing so your state doesn’t get lost when you have to switch apps, pretty Coda-like site thumbnails, tabbed editing, and remove and local preview support. Three obvious features that are missing are syntax highlighting, line-wrapping and public-key authentication, but it’s a great start and a solid option for busting out quick changes on the road.
In iTunes: Buy Now ($6.99)
Developer: Horse and the Rook

An alternative to Gusto that’s an app to watch would be Markup for iPad, but I’ve heard such crap things (crashy, no SFTP) about it that I haven’t tried it. Sounds like it’s worth keeping an eye on, but not ready for prime time yet and not worth the $10 pricetag until it’s a bit more stable and can handle SFTP.

FTP on the Go (Pro)

Feature-packed FTPS app. Honestly, too many spiffy features to list – the best FTP app I’ve come across so far. Comes with a built in FTP Server and Web Server allow viewing and adding files to the iPhone or iPod touch. Browse files on your iPhone from your computer with a web browser. Madness. Madness, I say!
In iTunes: Buy Now ($9.99)
Developer: Headlight Software

MySQL

MySQL Database Client

Small, simple MySQL client for iPad and iPhone. Supports stored profiles and custom queries, but don’t go too nuts. It can handle basic queries, but more complicated stuff like JOINS will return unpredictable results. Still, it’s $0.99, and is worth at least that much, contrary to the cheesedick who “wants a refund” in the reviews. Seriously. It’s a buck. Get over it, kid.
In iTunes: Buy it Now ($0.99)
Developer: Kyle Hankinson

MySQL Editor Pro

A much more full-featured app with a price tag that reflects it, MySQL Editor Pro is the real deal. If the cost doesn’t scare you off, this is well worth the month for such a strong db admin app.
In iTunes: Buy it Now ($14.99)
Developer: Pasha Topchiyev

SSH/VNC

Prompt

That Apache configuration issue I was having? Solved in 5 minutes using Prompt. It’s made by the same folks that make the super-sexy Coda code editing app for Mac. The UI is pretty nice, and it supports special characters and keystrokes like CTRL which one ends up using frequently in a shell. Prompt supports DSA/RSA keys, automagically remembers your frequently used commands, runs in the background so screen-switching won’t disconnect you, and you can map commonly used keystrokes easily for speedy access. An added bonus – it’s a universal app, so you buy it once and it works on your iPhone and your iPad. (Given my horrible typing on the iPhone and the iPhones even more horrible auto-correction, I don’t know that I’d want to use it on my phone much, but it’s nice to know it’s an option.
In iTunes: Buy it Now ($4.99)
Developer: Panic, Inc.

iSSH

Less sexy than Prompt but still one helluvan app is iSSH. iSSH boasts a pretty impressive feature set, including a tunneled VNC client, tunneled X server, the fact that SSH, telnet and VNC all work via EDGE, WiFi and 3G, transparent keyboard, Bluetooth keyboard mapping, RSA and DSA key generation and exchange, tons of keyboard customizations and holy shit a lot more. It’s a solid client, and a universal app, so you can buy it once and use it on your iPhone, iPad, iPod touch, etc. Even works with older iPhones running iOS 3.0.
In iTunes: Buy it Now ($9.99)
Developer: Zingersoft

Network Tools & Miscellaneous Hackery

IT Tools

Puts a whole handful of diagnostics just a tap or two away, with DNS, Ping, Route, ARP, active sockets and Interface tools. 45 supported DNS record types, including A, AAAA, CNAME, LOC, MX, NS, SRV, TXT – and it come with a database of MAC addresses so you can look up manufacturers of devices on your network. All of these things can be done through SSH if you’ve already got a terminal running, but this app makes it so much easier.
In iTunes: Buy it Now ($4.99)
Developer: Kevin Koltzau

Server Admin Remote (Mac OSX Server)

Called a Swiss army-knife for the mobile Mac OS X admin, with Server Admin Remote IT administrators can monitor the alive status of Mac OS X Server services, start/stop services and observe the services’ logs (Mac OS X Snow Leopard, Mac OS X Leopard Server and Mac OS X Tiger Server). Works on EDGE, WiFi and 3G connections. No further installation on your Mac OS X Server needed, since Server Admin Remote uses the same interface as Mac OS X Server Admin.
In iTunes: Buy it Now ($11.99)
Developer: Harlekins

Rackspace Cloud

If you’ve got a Rackspace Cloud Servers account, this app is the shit. Reboot, rename, resize, and rebuild your Cloud Servers, spin up a new server or delete an existing one, change your root password, bootstrap Cloud Servers with Chef from your Chef server or the Opscode Platform, open and manage Cloud Files assets and control your CDN settings for Cloud Files containers, play Cloud Files audio and video over Airplay to your Apple TV (iOS 4.3 and up) – a ton more. It’s not a complete replacement for their control panel, but you can do a heck of a lot with it.
In iTunes: Download Now (FREE)
Developer: Rackspace

Vtrace

Simple visual traceroute (or TracerT, if you’re this kid) that uses your current location to take you down the bunny trail to whatever IP or hostname you’re looking up.
In iTunes: Download Now (FREE)
Developer: Vlad Alexa

iAccess for Nagios

Mobile Nagios client that gives you direct access to the /nagios dashboard. (Obviously, you need a Nagios server configured for this to work.)
In iTunes: Buy Now ($3.99)
Developer: ASION IT Services

Flame for Bonjour

Flame is a browser for Bonjour network services. It lists the services advertised on your wireless network and you can browse them by server or by service type. When selecting a service, its advertised details are displayed. If an application on your iPhone or iPod touch can handle any of the advertised services, a command to open it right away is provided.
In iTunes: Download Now (FREE)
Developer: Tom Insam

Ping A Majig

Handy app that lets you check the ping status of multiple hostnames at one time. It’s a bit handier as a monitoring tool than the other apps that include ping as an available tool, since the at-a-glance view lets you see if any of your hosts are in trouble on one screen.
In iTunes: Buy Now ($0.99)
Developer: Pingysoft

RBL Status

Simple but effective Real Time Blacklist looker-upper.
In iTunes: Buy Now ($1.99)
Developer: Pavel Ahafonau

iPortscan Pro

iPortScan PRO is a port scanner for your IPhone or IPodTouch. It does not feature any network discovery; however, this tool is useful for sysadmins checking what services are listening on a known system. This is very handy for the system admin who can use this tool to quickly portscan all of their systems to make sure nothing is open that shouldn’t be.
In iTunes: Buy Now ($1.99)
Developer: Whiteside Solutions LLC

Default Logins

This app contains a database of over 300 common and uncommon manufactures and the usernames and passwords they pre-configure their devices with (which there are 1,000 + in the database). Can come in handy for more nefarious reasons (if you’re that kinda person), but also super useful for fixing a relative’s biffed router when they ask you to come over and fix their internets.
In iTunes: Buy Now ($1.99)
Developer: anthony lamantia

So that’s my list – for now. Did I miss any that you love? Leave me a note in the comments.

PS – yes, that’s a photo of my actual license plate at the top of the post. And yes, that makes me more awesome than you.

Also check out:

According to the blog entry, this feature would be opt-in, and canvas application developers would need to provide an SSL url for the “Secure Canvas URL”.

If a user who has opted into the SSL-only version of Facebook attempts to access a Facebook Application that doesn’t have a Secure Canvas URL set, the user will evidently be shown a message (which will likely be confusing and scary, not because Facebook will purposefully make it so, but because most users don’t really understand SSL) that will give them the option to switch from HTTPS to HTTP. From the post:

If you do not provide a secure Canvas URL, we will display a confirmation page to let HTTPS users switch to HTTP and continue to your app.

This currently affects CANVAS apps only – not application tabs – although that may very well change once Facebook pushes the IFRAME version of tabs out some time in Q1.

HTTPS is slower and more server intense than HTTP, and it’s one more cost/timeline issue that has to be factored in. For some clients, I set up the hosting environment (which would include DNS, SSL, etc) – for others, their IT department provisions web space and handles DNS, and they often require a mountain of paperwork and a week to process.

For the latter scenario, the cost of the certificate is negligible, but for a highly-trafficked app, the increase in server load could have serious financial impact. It could mean the difference between needing one server and several.

For smaller companies, stepping up to SSL would mean buying a certificate and potentially paying extra for the dedicated IP address it will need, and if the app takes off, a much heftier hosting bill for running everything over SSL.

If the above would actually, truly improve the safety of the users in some significant way, I’d probably still be on-board.

Security is something I take very seriously, and in 2010, Firesheep showed the world how easy it was to hijack a user’s Facebook session and essentially pwn their account because the session data was being transmitted unencrypted and was sniffable over public wifi. To be fair, it wasn’t just Facebook that was affected, but if you’re logging into websites on an unencrypted public wifi, odds are your email accounts and everything else are at risk too.

That said, this seems like it will give naive users a false sense of security and not actually provide that much value for the effort involved by the app developers.

“Oh, this application must be safe – I’m using HTTPS, and the S stands for *secure*!”

Phishing, rogue apps and malware are already horrendous problems on social media websites, Facebook especially. I would much rather see Facebook (and others) improve their session handling before going in this direction. Reputable companies who are collecting any kind of PII are already running data submission over HTTPS, and non-reputable companies aren’t going to become more honest just by forcing them to encrypt the data they’re mining from your profile.

The net result is a lot of extra work for developers and companies for not a lot of benefit to not a lot of users, with the side effect of confusing people into thinking that SSL = trustworthy, or that a non-SSL app is malicious and trying to eat their souls.

IMHO, the much bigger threat to Facebook users is their own poor judgment on what to click on. Social engineering rules social networks, and no amount of encryption is going to fix that. As the fabulous shirt from Jinx says “there is no patch for human stupidity”.

Until people start being more critical of what they’re clicking on and what apps they’re allowing access to their profile, they’ve got a lot more to worry about than SSL. It’s the same false sense of security that users running antivirus programs often suffer from.

“I don’t need to worry about what I click on – I’m running antivirus! My virus definitions are up to date, so I am safe and protected and nothing can harm me.”

In 2008, Symantec had to write new virus signatures every 20 seconds to keep up with the onslaught of malware that was released. This was increased to every 8 seconds by 2009. [Source: Gray Hat Hacking The Ethical Hackers Handbook, 3rd Edition]

To prove my point, I’ve created FB Profile Spy. It’s still a work in progress, but it’s a better-security-through-humiliation project, similar to my better-behavior-through-humiliation project socialmediadouchebag.net. It’s completely safe – and not even hooked up to the Facebook API at all (but of course please feel free to use NoScript and check it out thoroughly before interacting with the links. I have nothing to hide.) Click through and “allow” the “app”. I need to tighten up the javascript slideshow lecture at the end and I need to sync up the layout with the new profile design, but it’s coming along.

What do you think? Am I just being a whine-ass lazy developer? Am I being a slacker security pundit? Let me know in the comments.

NOTE: This article first appeared on FBMHell.Com.

Also check out:

Note: This will be a quick one long and rambling, because my Macbook Pro is in the shop and I’m using an old 13″ Macbook to write this, and it makes me want to punch babies that’s how I roll.

RockMelt is a new browser that puts more emphasis on your own social network of friends, backed by the some of the guys behind the Netscape browser. If you’ve been living under a rock and haven’t heard of it, watch their promo video below:

That video is pretty much all their website has to offer curious onlookers right now, and it sure makes you feel good watching it. Until you realize that the warm fuzzies Toby is talking about have more to do with his involvement in social networks and being connected to his friends in general than they do with those connections being integrated into your browsing experience.

Personally, I think the toolbars of your Facebook friends and applications looks nice, but after using it for five minutes, I wanted to hide them. I like my screen real-estate, and it’s creepy to have a dozen of my friends and family staring at me from the sidebar while I’m spanking it to my favorite Brazilian transvestite pr0n.

If I hide that toolbar, I’m hiding the very feature that sets RockMelt apart from other browsers, so while it’s great that you can hide it, what you’re left with at that point is a very vanilla browser that is exactly the same as every other browser.

One thing that actually really pissed me me off is that when I connected RockMelt to my Facebook account (which it prompts you to do immediately upon first-time launch), it set my online status to “online” automatically. I never show myself as online, because if you don’t have my real chat client names (Gtalk, AIM, etc), I probably don’t want to talk to you anyway. It took me a minute or two to figure out how to turn it back to “offline”. I don’t know if that’s RockMelt’s fault or Facebook’s, but given how creepy-uncle Facebook has been over the last year, that did not make a stellar first impression.

Speaking of Facebook – am I the only one that’s creeped out by the fact that Facebook is one of the backbones of this browser? For all they have done to betray my trust over the past year, the LAST thing I want to do is facilitate them knowing what I’m doing online more than they already do.

Do I think RockMelt has formed an unholy union with Facebook to spy on me? No – but RockMelt doesn’t tell you much of anything right now (and Facebook never does), so my lack of understanding about what data is being collected and stored by Facebook by way of RockMelt makes me very uncomfortable.

Also, it’s pretty clear by the way Facebook integration stands apart from the other social networks like Twitter that RockMelt is focusing primarily on Facebook. Considering how often Facebook’s API changes (read: breaks) and how much they are moving forward with their own agendas, I’m not sure this is a good long-term plan. One article on TechReview comments: “It’s not a generic ‘social browser.’ It’s a Facebook browser.”

Considering how Facebook is already trying to re-invent the web, I don’t know what that means for RockMelt in the future.

There are some nice features to RockMelt though. The right-side sidebar gives easy access to twitter with a simple but elegant UI, however it doesn’t really seem to be optimized for people with a large number of followers/following.

Also in that right sidebar, you can add RSS feeds to keep track of your favorite websites. They’re displayed beautifully, with a square site icon (based on the site’s favicon) and an unread count badge. If you’re on a site that has a detectable RSS feed, the “add feed” button turns green.

I think this could actually work to help people who don’t know or care what RSS feeds are learn to use them more. The one-click nature of subscribing when you’re on a page with an RSS feed makes the whole process cleaner and more clear than traditional RSS subscriptions, where the process is slightly more technical and deliberate.

On other browsers, even if a non-technical user can decipher what “Subscribe to RSS” means, they still have to do some work to access those feeds. RockMelt makes it a no-brainer – the user doesn’t need to know what RSS is for them to immediately see the benefit of subscribing – however it also simplifies it to the point where it could potentially be useless for people who already know and love RSS, and are subscribed to many feeds.

I subscribe to over 100 RSS feeds, so RockMelt is clearly not going to be of much help there. Maybe one solution would be to sync with Google Reader (please?) and let you pick your top five that you want to have in your sidebar.

That right-side toolbar references “Apps and Feeds”. I wonder if some sort of Facebook application integration is on their roadmap, which would be great, because then the useless jackholes that spend all day playing Farmville at the office won’t even need to switch browser windows to annoy the living shit out of everyone they know.

Another nice feature is the “Share” button built into the browser, that puts Twitter and Facebook sharing just a click away.

Of course there are already bookmarklets for all that already, and most websites now have share functionality built into their content, but for the less tech-savvy who might not know they exist, this makes it easy for people to share what they’re looking at in a way that uses a consistent UI on every single page they visit.

One UI irritation I ran across is that if you have the share pop-up activated and switch apps, it can be easy to forget that it has focus, so when you switch back to RockMelt, and go to type something in the url bar, the comments box in the share popup still has focus, which could lead to some embarrassing moments when you meant to pull up your favorite pr0n site but ended up accidentally sharing it with your Facebook wall. (I only accidentally shared the RockMelt website. This time.)

Ultimately, other than perhaps a morbid sense of curiosity, whenever a new browser comes out, I’m more worried than excited. If it becomes remotely popular, that’s one more browser I have to test on, one more variable thrown into the standards mix.

It’s not as bad these days as it used to be. Most current browsers have some semblance of standards-compliance, and display differences are minimal. (If you don’t believe me, you haven’t been in the industry as long as I have. Trust me on this one. It used to be so, so much worse.)

I’m pleased to say that RockMelt’s rendering seems fine, and while I haven’t had a chance to do any complicated DOM-tomfoolery with it yet, all of my initial tests showed layout and javascript working exactly as expected, and exactly as it would appear in any other browser. So that’s good news.

It may seem like I’m hating on RockMelt – I’m actually not.

Is it a browser for the power user? I’d say not.

Is there a market for it? I think so.

Most of the tech site reviews have been neutral at best, or condemning this browser to failure before it’s even open to the public, but I think that’s a symptom of who has been given access to review it. Naturally, the techies are going to be the ones with the first-look. In fact, they’re normally the only ones that care about a first-look. And techies are exactly the audience this browser will not fly for. At least not at this point.

But it’s important to remember that there people out there that aren’t as tech savvy – who wouldn’t know a Firefox addon if it bit them in the ass, and have no desire to know more. I look at my biological father, who only recently got an email account and joined Facebook. He doesn’t know or care about computers, and the only reason he finally broke down and got an email account was to stay in touch with my sister and I. As he uses the internet more, I expect him to find more things he likes (pr0n), but he just doesn’t care about how or why it works, and won’t go to great lengths to figure stuff out.

To techies, Facebook may be an aggravation – something we put up with because it’s part of our jobs or because it’s so ubiquitous that it’s hard to leave. But people spend more time on Facebook than on any other site on the web, so clearly, there are plenty of folks (and by plenty, I mean *millions*) that love it and use it constantly.

RockMelt’s tagline is “Your browser. Re-imagined.” So far, it’s more like “Your browser. With some integration that’s already totally possible with plugins, for people not savvy enough to use plugins.” But it’s early yet, and I’m curious to see where it goes.

Also? Dumbest name ever. Seriously guys. WTF.

Also check out:

I’m at the very early stages of writing a book about how to secure, monitor and un-hack WordPress. This book will be the culmination of everything I know about keeping WordPress hardened against attacks, how to keep an eye on your install so that you’re the first to know if something has happened, and how to handle the situation if you bought the book too late and got pwned anyway.

Can I absolutely guarantee that you’ll never get hacked if you do everything in this book? Of course not – new exploits emerge all the time. However I can promise you that you’ll be a lot less likely to get hacked if you follow these instructions, and if you do get hacked, you’ll be a far better place to recovery quickly and completely – and if that’s not worth $5 to you, you deserve what you get.

I can also promise that if there is enough interest in this book, I will keep it updated and release new revisions for free for those people who have already purchased it. I don’t believe in having to re-purchase a book just because a paragraph or two was added. It pisses me off when I have to do it, and I’m sure it pisses you off, too.

How much?
Right now, I’m toying with a $5-$10 price range, depending on how long and detailed it ends up being. It will not be more than $10, regardless of how long it is.

Are you doing advanced sales?
YES! If you’d like to pre-order, check out the page on GoFundMe. There are a few different options for pre-ordering, so it’s worth a look.

Why an e-book instead of a “real” book?
I might make this available in hardcopy through Lulu or some such service – but there are several reasons I went with e-book. First, I’ve written “real” books before. The process is frustrating, and there’s not a lot of money in it, in tech books anyway. By self-publishing, more of the money ends up in my pocket where it belongs. Second, as a recent convert to e-books (thanks to my iPad), I prefer to give folks the option of printing if they need to, but spare the trees for those that don’t. And third, stuff changes all the time in technology. Paper books have never seemed like a great way to cover tech topics, since half the book will be obsolete within a year or two, my own previous books included. Self-publishing via e-book means I can update the information as needed, and not feel like a jackass for making people buy a new edition of the book.

What qualifies you to write this book anyway?
I’ve been working with WordPress since 2005, and have spent a considerable amount of time over the past several years doing forensic and recovery work on hacked WordPress blogs. For some idea of the type of content you can expect to find here, check out this blog post from Jan 2010. I’ve helped folks like Chris Brogran, Scott Stratten, the Crave Network and others quickly recovery from a hack, and lock down their installs so they are less vulnerable to future attacks. Ask them – they’ll tell you.

How much swearing will there be?
Probably less than you expect. My goal is that this can be something some of you can recommend to your clients (the ones that won’t pay you to secure their sites), and as tempting as it is, that might not fly for the general public. I will, however, try to keep it entertaining in my own way.

What’s the title going to be?
NFC. Suggestions welcome.

How can I stay updated on the book’s progress?
I’ll be updating the official book website as new developments arise. Check it out here.

I have another question!
Tag me on Twitter at @snipeyhead or leave a comment below and ask away.

Also check out:

I’ll start with the obvious candidates that you probably already have installed if you’re a developer. I’ve also added a few that are useful for post-hack diagnostics and recovery.

General

Firebug – Firebug is great for web development in general, but the debugging tools can help track down calls to rogue javascript on external servers, among many other things.

Web Developer Toolbar – Another great web dev tool, the Web Developer Toolbar makes it easy to turn javascript and cookies on and off selectively, view form fields and disable restrictions and much, much more.

DNS Cache – simple addon that lets you clear or disable Firefox’s DNS cache. Not specifically for pen testing, but useful nonetheless.

Notable - love this addon, which lets you do a full-page screenshot with annotations over at notableapp.com. As you’re testing, there’s a good chance you’re going to need to show your other devs or account managers a screenshot so they can see the vulnerability being exploited. While something simple like Fireshot would work fine (or native screenshots), I like using Notable for complex situations that require explanations on multiple points on the page. Exports to annotated PDF.

Groundspeed – simple form toolkit that allows you to edit form fields (hidden to text, etc), remove length restrictions, change/remove javascript event handlers, and change form target so that it opens in a new tab.

Code Injection

SQL Inject Me – helps test for SQL injection vulnerabilities.

XSS Me – used to test for reflected Cross-Site Scripting (XSS). It does NOT currently test for stored XSS.

Access Me – used to test some access vulnerabilities related to web applications. The tool works by sending several versions of the last page request. A request with the session removed will be sent. A request using the HTTP HEAD verb and a request using a made up SECCOM verb will be sent. A combination of session and HEAD/SECCOM will also be sent.

JS Deobfuscator – many attacks inject obfuscated javascript into a page so that it becomes harder for you to simply grep the source for something obvious, like the domain name to which the bad script is redirecting the user. This addon helps deobfuscate the javascript so you can see what’s really going on.

Hackbar – helps with testing sql injections, XSS holes and site security. Ugly as sin, but it works well.

Header and URL Monitoring/Tampering

Note that some of these addons do similar things – try them and stick with whichever one you like best.

HttpFox – monitors and analyzes all incoming and outgoing HTTP traffic between the browser and the web servers.

Live HTTP Headers – view HTTP headers of a page and while browsing.

Modify Headers – add, modify and filter http request headers. You can modify the user-agent string, add headers to spoof a mobile request (e.g. x-up-calling-line-id) and much more.

Tamper Data – use tamperdata to view and modify HTTP/HTTPS headers and post parameters, trace and time http response/requests and security test web applications by modifying POST parameters.

User Agent Switcher – allows you to easily toggle between pre-set user agent strings, or set your own.

Environment Detection

Header Spy – lightweight addon that displays information about the website’s server in your statusbar. This is not as useful for pen testing as it is for impressing the crap out of clients who don’t know what server they’re running.

Host Spy – integrated shortcut to show you who a website’s IP neighbors are on shared hosting.

ShowIP – Small addons that shows the IP address of the website in your statusbar and a link to some additional tools.

URL Flipper – quickly and easily increment and decrement numbers and strings in URLs for navigating through URL sequences (for example, user ids or session info in the query string.)

Wappalyzer – uncovers the technologies used on websites. It detects CMS and e-commerce systems, message boards, JavaScript frameworks, hosting panels, analytics tools and several more.

Searching

Offensive Security Exploit Database – this adds the excellent database of exploits at exploit-db.com as one of your search engine options.

I’ve also just created a search plugin for XSSed.Com, but it’s pending approval at Mozilla, so not sure when that will be ready for you which can be downloaded here. It’s not exactly rocket science to add a new search site to your browser search bar, but I figured it was quick and easy to whip up. Feel free to check out the source code for the plugin here.

Too Many Addons Got You Down?

If you’re finding your plugins are slowing down Firefox too much, you might want to create a separate Firefox profile specifically for testing, and switch to that profile when you’re ready to start hammering away. Also bear in mind that you might need to tweak some settings on these, or only enable them right before you use them, as the toolbars and sidebars can be a bit bulky.

Also keep in mind that the Net option on the web developers toolbar, or any of the header analyzer addons can be very helpful in general testing between dev and live environments (load the page on live and make sure nothing is being pulled from the dev address) and also to make sure your SSL requests are being handled correctly.

Some Additional Thoughts…

When folks ask me how I do penetration testing – whether I use software, or do it by hand – the best way I can answer is “both”. Software will only ever get you so far, but it’s a critical tool in helping you figure out where the vulnerabilities are. It’s not unlike using a metal detector to find treasure. When the metal detector is doing its job, it finds, well, metal. Not necessarily treasure, although fancier metal detectors have additional software that helps try to identify the buried object by shape and size. You still have to physically dig up the item and rely on your knowledge and experience to determine whether or not it really is treasure, or just junk. The metal detector simply finds something that meets a basic set of requirements, to save you from having to dig up every square inch of the beach.

When testing web applications for vulnerabilities, software does very much the same thing. It simply automates tasks that you could do by hand but that would take an unreasonable amount of time, but ultimately when it finds something, you still need to know enough about what you’re looking at to determine how big a threat it actually is. Most of the time the software will attempt the to try the lowest-level exploit, for example, the ability to execute arbitrary javascript in a page. Your testing tools may demonstrate that you can create a javascript alertbox on the page, but it’s your knowledge and experience that will help you determine the full extent of the vulnerability, for example whether that arbitrary javascript could be used to redirect a user to a new page, hijack the user’s session data, etc.

The reason I ended this post with a long-winded ramble is because I wanted to make it clear that just having the tools isn’t enough. Actually using them, and knowing what to do with the results are important. Understanding the basic mechanics of how exploits work is the only way you can make sure your applications are written to mitigate them. Having the tools installed but never understanding or using them is like buying a metal detector and keeping in the closet and then wondering why you haven’t found anything valuable yet.

If you’re interested in learning more about web application penetration testing and security, check out the following books:

• The Web Application Hacker’s Handbook: Discovering and Exploiting Security Flaws
• Web Security Testing Cookbook: Systematic Techniques to Find Problems Fast
• Foundations of Security: What Every Programmer Needs to Know
• Ninja Hacking: Unconventional Penetration Testing Tactics and Techniques

How Do You XSS?

These addons are not obviously meant to be a replacement for more capable and thorough penetration testing tools such as metaploit, netsparker, etc. They’re just meant to be a convenient way for developers to test code during and after development.

There is a more comprehensive collection of addons listed here, but this is what I use. If you’ve got a favorite that I’ve missed, please be sure to share in the comments!

Also check out:

It’s literally just been launched, so I’m looking for your help. I’ll be going through some older posts and rounding up the questions that seem to come up often and writing up answers for the new site, but if there’s a burning question you’ve had for a while and haven’t been able to find an answer for, let me know in the comments.

One that comes up often is whether or not you can include an IFRAME in a tab, so don’t ask that one It’s already on deck.

I’m looking for all kinds of questions, ranging from the complicated to the more basic, so don’t be afraid to ask. More complicated tutorials (similar to what I’ve posted in the past regarding app development and complex mini-sites on tabs) will take a little longer, so be patient, and remember to subscribe to the RSS feed so you’ll get all the latest posts.

Categories will be added as content demands, of course.

I really want this site to be a great resource for everyone (including myself, as a repository of stuff I know works), so I’m looking forward to your feedback!

Also keep your eyes peeled for the launch of FBMLWizard, a drag+drop Facebook fan page tab builder.  I’ll update you here when it’s ready.

Also check out:

I had tossed that idea around a lot over the past year, since I run several websites that run on WordPress, but I had heard from enough people who ran into plugin/MU conflict issues that made things go ‘splody ‘splody that I opted not to. So instead, every time a new version of WordPress came out, I’d end up upgrading around 20 installs. Blech.

With version 3.0 of WordPress, the ability to create multiple sites using one install of WordPress is built right into the core, so no need to fool around with WPMU. The temptation was too great this time, so I decided to give it a whack. It was not what I would call a smooth process, but it wasn’t terrible either.

STOP: If you are already running WPMU and you just want to figure out how to upgrade your existing WPMU sites to WordPress 3.0, you’re reading the wrong article. Try this one instead.

Goals

What I wanted to get out of this was to have one main core install, but run multiple sites on their own domains that all pulled from that main core, so upgrading to later versions would mean upgrading one core instead of a dozen or two. These properties remaining at their current separate domain names (such as www.crankyhaiku.com, www.geekhaiku.com etc) was critical, both because of search engine optimization and for branding reasons.

Upgrading

The normal upgrade part was flawless, as WordPress upgrades tend to be these days. Automatic upgrade has never quite worked for me, so I always do a manual upgrade. It takes longer to upload the files, but it’s a pretty painless process. So to upgrade to 3.0, I did the usual:

• backup (which I didn’t actually have to do, since I automatically backup to the Amazon Cloud every night using Automatic WordPress Plugin) but I’m paranoid
• delete the wp-admin directory
• delete the wp-includes directory
• upload everything in the WordPress package – except for wp-content – to the web root
• hit the upgrade script to trigger the database updates

Flawless, as usual. Not so much as a hiccup. Now came the trickier part – adding the “Network” functionality previously available in WPMU to start to consolidate sites.

Creating a Multi-Site Network

I can’t speak for how easy or difficult this normally was with WPMU, so unfortunately I can’t tell you how this process compares to a normal WPMU setup. It wasn’t awful, but it was definitely buggy.

The WordPress documentation on Creating a Network walks through the basics well enough, so I suggest you start there so you know what to expect.

Note: You will not be able to go through the wizard in your WordPress admin until you deactivate ALL of your plugins. You can obviously re-enable them later, but I found that many of them did not keep their original settings.

I suspect this might be because I chose “network activate” instead of just plain “activate”. I had wanted to make those plugins available for all sites in the network, and didn’t realize that it would wipe out my existing snipe.net settings when I did so. Oh well. (Incidentally, that explains why you might see some weird stuff on the site until I have a chance to go through everything one by one. Double “related posts” bits at the end of the articles, Apture wasn’t working, etc.) All of the settings are fixable, but it may take you a little time to figure out what’s been lost, and what you have to do to set it back to the way it was before.

Editing Your wp-config.php

Beyond the setup in your WordPress admin, you’ll need to make a few changes to your wp-config.php file and your htaccess file. I hadn’t updated my wp-config for several versions, so I decided to use the wp-config-sample.php file and just pull my existing database variables over. Whether you use your old wp-config.php or start fresh with the stock WordPress sample, you’ll need to add the following to your wp-config.php, just above the comment that says “/* That’s all, stop editing! Happy blogging. */”

define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', true );
$base = '/';
define( 'DOMAIN_CURRENT_SITE', 'www.yoursite.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

If you followed my suggestion and read the WordPress documentation on creating a network (you did read that, right?), you’ll see that you have two choices for how your network will be set up: sub-domain (blah1.yourdomain.com, blah2.yourdomain.com) or directory-based (yourdomain.com/blah1, yourdomain.com/blah2). Make sure you think this one through before you get started, since there doesn’t seem to be an easy way to switch between the two.

As I mentioned, I didn’t want my sites to live at subdomain.snipe.net, or snipe.net/blogname – I wanted them to live at their own urls. I also didn’t want a bunch of crap littering up my document root. The easiest way to do this on Rackspace Cloud Sites is through a combination of setting up a site alias, and using mod_rewrite to handle domains:

• Set up a domain alias, like secondblog.com, and point it to originalblog.com
• Modify the mod_rewrite rules in your htaccess access file
• In your site preferences, point the blog url to the aliased domain name

If you’re not on Rackspace Cloud Sites, you can just follow the directions in the WordPress documentation.

Tweaking Your .htaccess

You’ll need to make sure the bit below is in your htaccess file – but your WordPress Network Setup wizard will point that out to you anyway

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule . index.php [L]

One thing to look out for besides having to reset your plugin preferences: when I created my Network, setting this site as the default, it automatically tried to set the url as snipe.net/blog. I’m not sure why it did this, and I’m certain I didn’t add it anywhere, but when I committed the changeover to Network, all of my urls were broken (since snipe.net/blog/ doesn’t exist). It was a quick change that you can handle via the Settings menu, but watch out for it and be sure to test your links once you’ve made the switch.

Importing Blogs

Now that you’ve got a Network set up, you have actually add them to the Network so that they’re using the same core. I expected this to be a much bigger pain in the ass than it ended up being. All I had to do was go to the original admin, go to TOOLS > EXPORT and download the XML file. Then go into my WordPress 3.0 admin, select the site I wanted to admin, and go to TOOLS > IMPORT > WORDPRESS, and upload the XML file. Worked perfectly, so far as I can tell.

Security Notes

Consolidating all of your WordPress sites into one multi-site install has many benefits, the most obvious one being that it’s easier to maintain one core install than updating every single instance of WordPress you run. That said, you may want to consider a few things:

While one install is probably more “secure” than multi-installs in the real world simply because you’re more likely to keep one site updated than dozens, there are a few things to consider.

If you run multiple WordPress blogs under the same user (the same account, in Rackspace Cloud Sites), all of the files are owned by the same linux user and group. This means that if one of your WordPress installs ends up compromised, either because you forgot to upgrade one of them, or because of a vulnerability in your hosting company, once an attacker has access to one of your blog installs, they have access to any other files owned by that user. Which means all of your other blogs, even the ones that are running current WordPress versions.

Along this same line of thought, if you’re running multiple WordPress installs under different users and you end up consolidating them to take advantage of the multi-site functionality, do so understanding that in this scenario, all of your blogs will be owned by the same user/group in the same webspace, so one vulnerability could easily turn into a much bigger problem.

Conversely, tracking down backdoors and maliciously modified files could potentially be easier, since you have fewer installs to search through.

WordPress has been much better about quickly patching holes, and being proactive about finding vulnerabilities. If your site ends up getting hacked, these days it’s more likely to be a vulnerable plugin, an outdated install you forgot all about, or a PC virus that added your FTP login to a botnet – not the core WordPress install itself. I say this with a certain amount of confidence, since I have restored at least two-dozen hacked WordPress sites (not mine) since the beginning of the year, and have therefore spent countless hours investigating the attack, identifying the vector, and writing up summaries to post to badwarebusters.org in an effort to help other people facing the same hack.

To be clear, running a multi-site install isn’t any riskier than running multiple blogs under the same user. But if you’re currently running your blogs under different users, you should at least be aware of how that could potentially impact you.

Final Thoughts

My thought is that it might have been smarter to install WPMU, and then upgrade to 3.0, since the upgrade process for a WPMU setup to 3.0 seems like it was a little less wonky, but I don’t really know.

I’ve really only just started playing with this during the fragment of free time I had today (work has been brutal for the past month or so). So far, pulling the theme in has been as simple as downloading them from their respective old WordPress installs and uploading them to the new 3.0 themes directory and activating them so that they’re available to the rest of the sites in the network.

And certainly, if you’ve found an easier way to get this done, please let me know in the comments.

Also check out: