Initially, we must validate our URI templates do not expose sensitive data. If they do not, there are no concerns. However, if your URI templates expose sensitive data we must preserve their integrity and confidentiality. An example of an insecure URI template may look like:
http://rest.com/account/{account_id}.
If this URI template exposes a clear text account ID we have a security gap. If a security gap exists, we must implement a solution to preserve the integrity and confidentiality of the insecure URIs. Three solutions exist to secure RESTful links:
Hashing
Hashing is an ideal solution if you need to expose data parameters in clear text and want to preserve data integrity. Integrity is the assertion that the data was not altered by the consumer or a man-in-the-middle. With a hash-based solution the RESTful link may look like:http://rest.com/account?account_id=123456&digest=83r/grjAxjcqe5FE42xRgD6YF00q4DmsJALlfA==
This solution will preserve integrity but it does not provide confidentiality. If the consumer or malicious user alters the account ID a server-side integrity check against the hash algorithm will fail. The JUnit below demonstrates the creation of the digest (hash) and the assertion to validate the integrity of the clear text and digest have been preserved:
@Test
public void testJasyptsHashAlgorithm() {
/*
* By default the standard digester uses the RandomSaltGenerator and runs the hash
* algorithm 1000 times. These are configurable for greater security.
*/
StandardStringDigester digester = new StandardStringDigester();
digester.setAlgorithm("SHA-1");
final String clearText = "123456";
final String digest = digester.digest(clearText);
Assert.assertTrue("Integrity has been violated!", digester.matches(clearText, digest));
}
Encryption
Encryption is an ideal solution if you want to preserve integrity and confidentiality. For example, an encryption-based RESTful link may look like:http://rest.com/account/kNddGYRn3KAWK5nYJ/5jrA==
The JUnit below demonstrates the creation of the encrypted text and the assertion to validate the integrity of the encrypted text has been preserved:
@Test
public void testJasyptsEncryptionAlgorithm() {
StandardPBEStringEncryptor encryptor = new StandardPBEStringEncryptor();
encryptor.setPassword("password");
encryptor.setAlgorithm("PBEWithMD5AndTripleDES");
final String clearText = "123456";
String encryptedText = encryptor.encrypt(clearText);
String decryptedText = null;
try {
decryptedText = encryptor.decrypt(encryptedText);
} catch (EncryptionOperationNotPossibleException e) {
Assert.fail("Integrity has been violated!");
}
Assert.assertEquals(clearText, decryptedText);
}
Do not expose sensitive data
The ideal solution is to not expose any sensitive information. Alternatively, instead of exposing a sensitive primary key expose an associative key or index that has no identifying relationship to the entity. A common scenario occurs when consumers need to search and maintain records. Consider the following use case:- User performs a search
- The server-side executes the search and stores the list of authorized search results within session
- The server only exposes the indexes of the entities the consumer is allowed to maintain: http://rest.com/account/{index_id}