Enterprise Architecture: From Incite comes Insight...

This is part four of a seven part analysis of Liferay Portal and its security model. I previously covered authentication, authorization and services. Today, I will focus on the problem space of automation...




The most popular method of preventing automation attacks in many web sites is to leverage a Completely Automated Public Turing test to tell Computers and Humans Apart otherwise known as CAPTCHA. Liferay provides the ability to raise a CAPTCHA challenge at registration time, but doesn't provide any additional configurable opportunities to leverage this mechanism in other parts of the portal lifecycle.

One could envision that at some level, the notion of a CAPTCHA could be incorporated into authorization where it may be useful to know that a given identity is actually controlled by a human and not automation. This is especially useful if the access is via the portal and not the services interface. Another usage scenario would be to require CAPTCHA for all administrative access that occurs from non-trusted IP addresses.

It is important to note that over time CAPTCHA as a mechanism is getting weaker. It's common knowledge that Captchas are fundamentally unable to fully guarantee application security, but they do protect against certain threats. Currently, using tools such as DeCaptcha, attackers can gain anywhere up to 70% automation success in breaking many forms of Captcha so alternative mechanisms are needed.

Insufficient Anti-automation occurs when a web application permits an attacker to automate a process that was originally designed to be performed only in a manual fashion, i.e. by a human web user.

Web application functionality that is often a target for automation attacks may include (comments in Red):

• Application login forms – attackers may automate brute force login requests in an attempt to guess user credentials (Limited to account lockout. No ability to throttle requests or to automate blocking of IP address/range)
• Service registration forms – attackers may automatically create thousands of new accounts (Same as above)
• Email forms – attackers may exploit email forms as spam relays or for flooding a certain user’s mailbox (Same as above)
• Account maintenance – attackers may perform mass DoS against an application, by flooding it with numerous requests to disable or delete user accounts
• Account information forms – attackers may perform mass attempts to harvest user personal information from a web application (Roles provide some protection)
• Comment forms / Content Submission forms – these may be used for spamming blogs, web forums and web bulletin boards by automatically submitting contents such as spam or even web-based malware (only protection is moderation)
• Forms tied to SQL database queries - these may be exploited in order to perform a denial of service attack against the application. The attack is performed by sending numerous heavy SQL queries in a short period of time, hence denying real users from service.
• eShopping / eCommerce - eShopping and eCommerce applications that do not enforce human-only buyers, can be exploited in order to buy preferred items in large amounts, such as sporting events tickets. These are later sold by scalpers for higher prices. (Shopping cart portlet does not adequately protect this scenario)
• Online polls - polls and other types of online voting systems can be automatically subverted in favor of a certain choice.
• Web-based SMS message sending - attackers may exploit SMS message sending systems in order to spam mobile phone users (No ability to throttle or configure a quota)

Anyway, I hope that the Liferay community will consider making improvements in this regard. The next topic will be a security analysis of passwords and other misc functionality...