So as I sit and write this I am fully aware of the potential backlash that this may (or may not) cause. After some serious consideration I obviously decided to write this. I first want to make a couple points perfectly clear. First, I am not an expert in the security field. My points are merely observations on some things I have recently seen. Also, I am in no way attempting to discredit or diminish the work done by others. I believe that people are well intended until, well, they aren't.

Recently at my employ our system went through another security audit. This audit was more in depth than any before. For this audit we had to turn over all the code to the system to the audit firm. The scope of the audit was to examine the source code and look for security vulnerabilities. Then, using what was found in the source, try and exploit any vulnerabilities found. To our horror, a few major issues were found. Mostly dealing with SQL injection, scripting form submissions, and cross site scripting.

As a result of the audit I became hyper aware of security for sites. I now have a completely different perspective then I had a year ago. Now, every time I write code my first thought is "how can someone break into this?". I now try and think like a hacker and see what I can do to stop them before they try. This can get very tedious and challenging but at the same time necessary.

I am also lucky to have on staff a person that we call our "security expert". He used to work for a security firm that did audits so he has a good idea on how to try and break stuff. Lately he has been writing pearl scripts to try and get past form submission protection methods we are testing. Unfortunately, has been able to get around almost everything we tried. We were not trying to reinvent the wheel we were using publicized methods to thwart these types of attacks.

Before I go further, I think it is important to briefly explain the scope of our work. We were working to protect 2 parts of our system. Both are form submission fields that don't require a login to submit. The homepage of the system is a login screen so all other forms in the system are protected and we always know who the submitter is. Our goal was not to stop spammers but to stop brute force bots from trying to mass submit our exposed forms.

After a bunch of trial and error we started looking at cfformprotect (CFFP). It had some fancy tools to try and make sure the submitter was an actual person. So, we read the docs on it and thought it would work. We installed it in a test scenario and tried to get around it. Our initial attempts all failed. CFFP stopped the fake submissions as expected. So, we then passed it off to our security guy. We didn't tell him what was in-place to stop him. His mandate was to get around the protection.

So, our security guy looked at it and said to me; "I'll get around it in about 10 minutes". I told him he was crazy and went back to my office. I almost wanted to bet him. About 15 minutes later he sent me a message that he got around it. First I was pissed that he did get around it, because I could have lost a bet. Then I got pissed that he was correct on the time frame. Then I started thinking how can something designed to stop attackers be compromised so easily. Once explained to me the answer to my question was obvious.

I am only sharing this as a warning to others on how easy this was. This is not intended to discredit the hard work that went into creating CFFP. I feel it is important for people to know if these types of tools actually work. I must also state that we found this about 2 weeks ago and didn't post this till we contacted the author of CFFP.

What was in place to stop him? Well, we enabled 4 parts of CFFP: mouseMovement, usedKeyboard, timedFormSubmission, hiddenFormField. We also set the failure limit to 1 so that any test failure would result in it reporting back a submission failure. We were also looking at http referrer as well as a cookie that we set.

So, how did we get past it? It was quite simple actually. First, our security expert examined the code in the browser. He was quickly able to determine that it was looking for mouse movement and if the keyboard was used. He then attempted to get a successful submission. Once that was achieved he then tried to get a submission to fail. Once that happened he started comparing data. Using a program called WireShark he was able to trap the form submission and analyze it. He was able to quickly determine what was needed to submit the form. He then created a pearl script to simulate the submission. The script created http headers, cookies, and other parts to mimic the good test submission. Once he got the script correct he was able to mass submit hundreds of entries in mere seconds.

What we learned from this is that CFFP will not stop "smart" bots. Those being bots that are custom built for a specific form. It will however stop casual spammers and "dumb" bots. For us this was not acceptable. Because of the nature of the system we are working with we get lots of smart bots.

There were some emails that went back and forth between me and the writer of CFFP. Personally, I did not like his response. It came across as very blasé and that he seemed to not care that we got around CFFP. He even went on to tell me that CFFP is not 100% full proof. Granted, standard disclaimer applies that the creator of CFFP accepts no responsibility if the software does not work. However, there should be a level of confidence that it will work. If you read the info on on it you would get the impression, as I did, that it would work.

The moral of the story, make sure your level of protection matches what you are protecting. Make sure the solution you put in place works. Don't rely on any client data to stop spammers/bots as anything that is on the client can be spoofed of altered. In extreme cases, you will probably have to use multiple methods on the same form to protect the submission. But, as I always say; if they want in, and have the time and motivation, they will get in.

Till next time...