Oracle Jet - security by obfuscation - Do not use it

Obfuscation “the action of making something obscure, unclear, or unintelligible” is often used when trying to secure an application. The idea behind obfuscation is to make the technical working of an application so unclear to attackers that it will become very hard to figure out the actual working.  Even though obfuscation might look like a good measure it provides no real security against people who intend to understand the real working of an application. A good example of security by obfuscation is URL obfuscation.

When applying URL obfuscation as a security measure a common practice is to obfuscate the URL parameters in such a way that they are not easily understandable by someone who has not build the application.

A recent example I found is the below URL which ends with details?id=QEREUS where at first instance it appears that the ID is a randomly generated ID. When having a randomly generated ID this will make it harder to build a script which will access the details site. However, in this specific example the result of the URL is a JSON file, when examining the JSON file another ID was shown. In this case the ID in the JSON file was A01049 while the ID in the URL was QEREUS

By examining a number of different detail pages quickly a pattern emerges, for example, all URL IDs started with a Q and only used a specific subset of the alphabet. In this specific example the actual ID, shown in the JSON file, was an A followed by a sequential number where the developer has chosen to use a substitution method to obfuscate the actual ID. The below list shows the selected substitution method:

• 0 - E
• 1 - R
• 2 - T
• 3 - Y
• 4 - U
• 5 - I
• 6 - O
• 7 - P
• 8 - A
• 9 – S

When you take a good look at the letters and take a good look at a QWERTY keyboard layout you can figure out why the developer has selected this set of letters to substitute the numbers.

Why people use obfuscation. 
There are very good reasons why one would like to make it hard for externals to guess ID parameters. When you are able to guess the ID parameter it might become very easy to write a script to scrape a website for information. When looking at more modern web based applications, for example Oracle JET based applications, a javascript will call a REST API, this means that the user will be able to gain access to pure JSON (or XML) based information.

In essence there is nothing wrong with external people accessing this information however there might be very good reasons why you do not want to over-promote the use of the pure JSON data outside of the context of your Oracle JET based application.

A better way to do obfuscation
Besides implementing true randomization and more advanced security than obfuscation there are much better ways to do obfuscation in your URLs. An example would be for example simple encryption would work much (much much much) better. The below examples are rijndael-256 encrypted IDs with a base64 encoding

• A01049 - fiCOcGED9SDiYe9du0XUIu1tsHQNGwWVK9uvI755+fg=
• A01050 - cQbgwi1mnsYloonV4ZhqPMo3C2ie0+ilmsZFr3mBb3A= 
• A01050 - U0xs5e4QP6OIclZBCSLuf34WFNRqs3lbtBgkmMiRvkc=

Opposed to the number substitution shown below for the same IDs:

• A01049 - QEREUS
• A01050 - QEREIE
• A01051 - QEREIR 

Should you use obfuscation?
my personal opinion; no. Main reason for saying no is that it provides a false sense of security. It gives you the idea you are safe while someone who is determined will figure it out at one moment in time. There are better and more structural ways of doing things like preventing people from overly active scrape your website. However, if obfuscation is a part of a wider set of security implementations you should think about a very good way of doing obfuscation and not simply rely on a solution like substitution as it will take a very short amount of time for someone to figure out the substitution algorithm

Oracle Linux - security hardening - CIS control 1.1.2

As part of ensuring you deploy Oracle Linux 7 in a secure way the CIS benchmark van provide a good guidance. Following the CIS benchmark will ensure that most of the important security hardening topics will be considered. As with most general guidelines, the Oracle Linux 7 CIS benchmark, not all will apply on your specific situation. Having stated that, it is good to consider all the points mentioned in the benchmark and apply them with a comply or explain model.

Within this series of posts we will go through all the Oracle Linux 7 CIS benchmark controls and outline them a bit more than might have been done on the actual CIS benchmark.

control : Set nodev option for /tmp Partition

The rationale given by the CIS benchmark is ; Since the /tmp filesystem is not intended to support devices, set this option to ensure that users cannot attempt to create block or character special devices in /tmp.

In more detail, if the nodev option is not set it would allow for mounting the /tmp filesystem on a device. In this sense, a device could be for example a USB drive attached to the machine. When, if this is not prevented, a USB drive is added to the machine a device node will be created under /dev which can be used to mount /tmp on. The nodev option will ensure that this is prevented.  The official man page reads the following on nodev : “Do not interpret character or block special devices on the file system.”

The CIS benchmark documentation provides the below command as a way to verify that the nodev option is given. In reality two possible options are provided however, I feel the one below is providing the most assurance that it is actually actively implemented in the right way.

mount | grep "[[:space:]]/tmp[[:space:]]" | grep nodev 

A more extensive version of this check which will provide a pass/fail response is shown below:

#!/bin/bash
mount | grep "[[:space:]]/tmp[[:space:]]" | grep nodev | wc -l&> /dev/null
if [ $? == 0 ]; then
   echo "fail"
else
   echo "pass"
fi

This provides a easier way to implement an automated check if you want to incorporate this in a wider check for your Oracle Linux installation.