WP Login Protect Application Awareness

Archive

Login Protect Application Awareness

Login Protect Application Awareness

This week we’re introducing a new application awareness option for our Login Protect two-factor authentication solution. This usability option streamlines integration with popular CMS application by auto-deploying two-factor protection around their administrative areas.

What’s Application Awareness?

Application awareness is the ability to recognize connected applications and optimize our processes for their use.

Application awareness is already supported in our security and acceleration solutions. These rules help us deal with application-specific threats (e.g., JCE and TimThumb vulnerabilities) and improve integration with 3rd party caching and optimization solutions (e.g., W3TC). Starting this week, we will also be using application awareness to support Login Protect CMS integration.

How Does It Work?

Upon enabling Login Protect, Incapsula will auto-detect your CMS platform and provide a basic set of deployment settings for your platform of choice.

For instance, in the case of WordPress, Incapsula will identify the platform and suggest a wildcard rule to protect all pages staring with ‘/wp-admin’. Accepting this will secure the WordPress default admin area, which is where Login Protect is usually needed most.

Login Protect - Two Factor Authentication with Application Awareness - Sample

The ‘Protect Common Application’ button will do the same on-demand, which is useful for those who’ve already activated Login Protect or for those who want to active these rules at a later date.

Currently, the Application Awareness feature supports WordPress, Joomla and phpBB, and we plan to introduce more platforms and rules in the future. The obvious omission of Drupal is due to its administrative area URL structure, which is too dynamic to benefit from generic rule-setting.

Understanding Wildcard Rules

Since its launch in late June, Login Protect has been adopted by many Incapsula users. Guided by their feedbacks and by aggregated user-configurations data, we noticed that our wildcard rules were causing some confusion and weren’t always optimized to the task in-hand.

While our new application-specific default setting will help solve some of the problems, we also wanted to use this opportunity to demonstrate our wildcard URL matching rules using the table below:

Matching Rule String Example Matches Doesn’t Match
URL is /admin /admin /home
/admin/user
/administrator
URL is not /admin /home
/admin/user
/administrator/
/admin
URL starts with /admin /admin
/admin/user
/administrator
/home
/home/admin
/?admin=x
URL ends with jpeg /logo.jpeg
/images/logo.jpeg
/myjpeg
/images
/logo.png
/index.php?jpeg
URL contains admin /admin/images/logo.jpeg
/images/administrator/
/images/myadmin.png
/images
/admi.jpg
/index.php?admin=x
URL does not contain admin /images/
/home/
/index.php?admin=x
/admin/images/logo.jpeg
/images/administrator/
/images/myadmin.png

As evident from the examples above, wildcard matching rules are useful bulk-management tools which can help save a lot of time, while also providing additional control and flexibility. We encourage you to experiment with them, as they will continue to play a role in our upcoming feature releases.