Godless development: how to find and avoid God Objects

Have you ever written or encountered a class that does too many things? A class that takes care of almost everything and you can make an object from it and use it in various aspects of application development. Yes, you found a God Object:

In object-oriented programming, a God object is an object that knows too much or does too much. The God object is an example of an anti-pattern.

act-of-god-insurance

Usually, you can see these ani-pattern codes from the work of less-experienced programmers who believe that one big class can help them complete their tasks more quickly and less work is needed to change a single class compared to be forced to change a couple of them.

Below is the example of a God Object:

public class UserInfo {

public Long userId() {}
public String fullName() {/*getter & setter*/}
public LocalDate birthday() {/*getter & setter*/}
public String email() {/*getter & setter*/}
public String userName() {/*getter & setter*/}
public String password() {/*getter & setter*/}
public String maritalStatus() {/*getter & setter*/}
public String gender() {/*getter & setter*/}
// and so on ...

// some validators to validate user info before saving to DB
private boolean validateUsername(String userName) {}
private boolean validateEmail(String email) {}
private boolean validatePassword(String password) {}
private boolean isRegisteredBefore(String userName) {}
private LocalDate convertDate(String birthday) {}

public void saveUserInfo() {}
public List<Map<String, String>> fetchUserInfo(){}
public JSONObject exportUserInfoToJSON() {}
public void exportUserInfoToCSV() {}
public void importUserDataFromCSV() {}
public void deActivateUser() {}

}

As you can see from the example above, the UserInfo class is responsible for various pieces of the program’s functionality such as inserting and retrieving data to database, exporting and bulk importing user information, validation, and so on. In other words, the programmer has many reasons to change the codes of this class which is a vivid violation of the Single Responsibility Principle. But, let’s take a look at what problems these kinds of codes can make:

God Object drawbacks:

  • Difficult to write unit tests
  • Increases complexity and makes the development difficult and costly
  • Increases tight coupling
  • Takes more resources and is very expensive in memory usuage.
  • Doesn’t follow the SOLID principle.

Therefore, how to avoid god objects to occur in the first place?

The first you can do is to stop writing very large methods. Then, try to write unit tests for each method. And, last but not least, start learning about design patterns and object-oriented paradigm because following OOP principles save you a considerable amount of development time in the long run. It will increase the readability of codes and will make the final application more reliable and adapted to future changes.

What is Unvalidated Redirects vulnerability and how to secure the Liferay Portal to prevent it?

Let’s start with a quick definition of  Unvalidated Redirects vulnerability.

Another name for Unvalidated Redirect is Open Redirect which is a security flaw in web applications (or web pages) and occurs when an attacker can redirect users to an untrusted site while they are clicking on a link on a trusted website. To have a better understanding of this attack, take a look at the sample below:

A HTTP GET request has been sent to a locally installed Liferay portal version 7 by using Insomnia application. The only change in this request is the Host parameter in the request Header which has been set to attacker.com.



When you look at the source code on the response body, you will find out that the hostname for many anchors, link and script tags have been changed to attacker.com. Consequently, if a user clicks on any of these links, he will redirect to the attacker’s website which he did not expect.


open-redirect-2

Therefore, in order to protect the Liferay Portal from these types of vulnerabilities, you need to configure portal-ext.properties which is located under the path below;

/tomcat-[VERSION]/webapps/ROOT/WEB-INF/classes/portal-ext.properties

And the configuration is:

# Input a list of comma-delimited valid domains and IPs that the portal is
# allowed to use.
#
virtual.hosts.valid.hosts=localhost,127.0.0.1,mysite.com