Response to Mr. Channell's Test Results

   After examining the interim results and looking over our own statistics, I noticed one major differences between the "test" results themselves as they pertain to each vendor and another more interesting difference in the definition of "detect and/or success" for 30% of the test triggers.

   First, in our experience over the last few years, the vendors that were scored high represent many customers that have switched to SecureLive. We receive many clients who's sites have been hacked using the "high scoring" vendors. Yet to date, none have had any other issues since replacing with SecureLive. We found this to be odd and cause to look further. A casual look reveals some contradiction between our customer experiences vs. these test results.

   We needed to examine the rules and definitions and it was then that we discovered what we believe to be a flaw in the test.

   Just like Google and Yahoo, each has their own philosophical differences. Yahoo focuses on comparative analysis and Google make strong assumptions about "what is good" for the masses. Google operates on a The Tests or the Tester?In our experience over the last few years, the vendors that were scored high represent many customers that have defected to SecureLive. We receive many clients who's sites have been hacked using the "high scoring" vendors. philosophy of "changing the search paradigm" for the betterment of the global society (much more top down than its competitors). Google makes decisions for you based on changes and behaviors of society. Yahoo simply serves results based on a much looser approach. This basic difference between Google and Yahoo is that Yahoo shows 1000's more links, whereas Google is extremely strict about link behaviors and destinations and will only show a fraction. You will always see a vast number of results between these competitors. Which is right, which is wrong, depends on your definition?

   To test this put in any keyword: If you type in "SecureLive" into Google you will receive about 169,000 results. But if you enter the same search term into Yahoo you will receive 341,000 results. The difference is in their definition of what is a good result.

   Just as this example above demonstrates, there are major philosophical differences in the way SecureLive “DEFINES” success against an attack vs. how other vendors view the same. Cases in point are the test triggers #2, #3 and #7.

   SecureLive's programming team, and CEO (Jeff Brown), installed 3 different versions of CMS Software, Drupal, Joomla, and e107, on 4 different servers, alala.securelivehosting.com, ceto.securelivehosting.com, pheobe.securelivehosting.com and demeter.securelive.net. Our results are clearly different and would like to encourage any other party to try the same results. Detailed information on the testing will be provided. Please keep in mind you will be blocked and if you are blocked you will have to contact us, our contact number is (888) 300-4546 Mon - Fri 8am to 12am, Sat 9am - 8pm and Sunday 10am - 8pm. Excluding Major Holidays. All times are US-EST (GMT-5).

Test Trigger #1:
   Adding <?php echo phpinfo(); ?>'"<h1> to the User Agent of the Browser. Using this Utility in Firefox: User Agent Switcher I modified the User Agent to match that exact string. Output result: BLOCKED and BANNED

Test Trigger #2:
   By placing the string: " style="position:absolute;top:0px;left:0px;width:99em;height:99em" onmouseover="location.href=String.fromCharCode(104,116,116,112,58,47,47,106,101,102,102,99,104, 97,110,110,101,108,108,46,99,111,109) into any form field on the site, such as the Forum Textbox, Search box or any other field SecureLive rendered the string harmless by converting characters such as " to $quote;, and removed any key words such as onmouseover, or any other trigger event. As for placing the the string into the URL of the browser the output result: BLOCKED AND BANNED

Test Trigger #3:
   By placing the string: [img]http://j.png?x'/oNeRrOr="/* [/img] eval( */ eval( String.fromCharCode( 97, 108, 101, 114, 116, 40, 34, 88, 83, 83, 34, 41 /*)*/ ) ) //"> into the Forum again like number 2, stripped out the bad trigger events and stripped the code harmless, by placing the string into the URL of the browser the output result: BLOCKED AND BANNED

Test Trigger #4:
   Mr. Channell stated we passed and we agree with his conclusion

Test Trigger #5:
   Mr. Channell stated we passed and we agree with his conclusion

Test Trigger #6:
   PHP File upload - SecureLive does agree with Mr. Channell's failed to detect. SecureLive is used on production sites, we built SecureLive to be as powerful as possible without being invasive with your site's configuration. If you have a closed site and you can trust the uploads of your members, then our product shouldn't block something that isn't an attack. With that said, just about any competent webmaster and programmer will know that if you allow uploads on your site and it is open to the public, restricting the uploads is the upload script's responsibility. Relying on other Security Measures will only hinder the site and cause problems for some.

Test Trigger #7:
   By using the SQL Injection string in the URL of the browser: ?option=com_aceversions&view=category&catid=-1 union select 1,2,3,4,5,6,7,8,9,10,11,12,13 -- you may ask ANY of our existing customers they see an attack like that multiple times per day, not only did we re-test, but we also verified with several of our attack reports and our monitor staff if these types of strings come in and are still being block. This test will ALWAYS return and output of: BLOCKED and BANNED

Test Trigger #8:
   Near a duplicate of test #7, again by placing the string: http://domain.com/1')and(if((select(username)from(jos_users)where(gid)like(25))like(0x61646d696e),benchmark(5000000,md5(1)),1)--' into the URL of ANY SecureLive protected site will ALWAYS return the output of: BLOCKED and BANNED

Test Trigger #9:
   Unable to post an example, but you may see an example here: CSRF Example. SecureLive has methods of blocking this from happening simply by adding an Access Word to your Administration Panel. Also with country blocking and IP blocking, you can prevent this from happening even without the CSRF attack being activated. With the Access Word in place, the hacker EVEN with your cookies will receive the output of: BLOCKED - Will not be banned

Test Trigger #10:
   Mr. Channell stated we passed and we agree with his conclusion

“failed to detect” score It is our opinion that unless the definition of “detect” is modified to include the more intelligent blocking decisions SecureLive executes, the test will not be true. It remains an apple to oranges test.    As SecureLive developed from 1.0 to 8.x, behavioral, and philosophical decisions have played greater roles during its maturity. The emphasis has always been on balance. Security without balance is crude and could be counterproductive. For example; you must allow 100,000 visitors access but deny just "one" potential intruder. This realization has been our greatest achievement. So much so, that SecureLive has an entire coding section devoted to maintaining "page rank" and preserving "SEO" value of the property and not interfering with your business. In this test, SecureLive was scored as "failed to detect" on the above triggers. This is actually false, the test’s outcome was based on whether a 404 was served or not, not very sophisticated. This is easily accomplished and demonstrates the "run-of-the-mill" approach and treats everyone suspect in “all” cases. SecureLive uses a checkpoint philosophy and strips the suspected visitor harmless and allows harmless code to pass “giving safe, benefit of the doubt”

   If you define “success” as merely blocking anyone that may purposely or inadvertently set off a block, then yes SecureLive does not “DUMB” block. In contrast to this, SecureLive takes an intelligent approach, by analyzing the code one more step, it is capable of allowing a disarmed harmless passage. This may sound foolish at first. But it is a highly intelligent approach, and here is why:

• It allows the majority a trouble free visit.
• Punishes only the ill intent.
• Reduces security noise (annoyances).
• Protects the property in stealth mode.
• Is not intrusive but strict.

   SecureLive was given the “failed to detect” score. It is my opinion that unless the definition of “detect” is modified to include the more intelligent blocking decisions SecureLive executes, the test will not be true. It remains an apple to oranges test.

   Finally, the last topic to discuss is more of just a mere technical situation, with the test unbeknown to the SecureLive team, we believe that there may be some tests that were performed outside of the Joomla environment, if this is the case, then the version of SecureLive you have installed will not block. We have several versions to choose from, Joomla, Drupal, e107, WordPress and finally our Server Edition which will protect ALL PHP. For the tests that you were performing, Joomla has 3 states of load values, BeforeOnLoad, OnInitialize, AfterOnLoad. SecureLive wedges itself between the OnInitalize and AfterOnLoad so that it is running before all templates, modules and components.
With that said, if you created an index.php file in a subfolder with the contents of , then the Joomla version of SecureLive will never interact with that file, please evaluate with our Server edition.