Nov 4, 2021 2:46:04 PM Thomas Dumont

Points of attention in terms of security code

In order to secure the application code against malicious attacks, there are a number of points of vigilance to counter the different types of vulnerability below.

Cross Scripting

This type of attack consists of adding HTML code and especially executable JavaScript from input data (ex: query parameter). These attacks do not threaten the integrity of the server, but can cause serious harm to users. They are therefore to be treated with the utmost vigilance.

Lutece has two filters, one on the Front Office (jsp / site / *), the other on the Back Office (jsp / admin / *), allowing to ban the list of characters used for this type of attack.

Any other access to WebApp resources must be secure.

The SecurityUtil class of Lutece offers several verification methods

• containsCleanParameters (HttpServletRequest request) controls all parameters of a request
• containsXssCharacters (request, strValue): Controls whether a value contains characters used by XSS attacks.

In the negative, these two methods trace all the information of the request (IP address, parameters, ...) in a security.log file. The evoked filters, using these methods, therefore also plot any attack attempt.

Open Redirect

This type of attack allows a redirection to a malicious site from input data.

All redirections made by an application must therefore verify that the destination URI is verified and that in any case it comes from an uncontrolled parameter.

Bean Manipulation

This is a vulnerability of the Apache BeanUtils library BEANUTILS-463 corrected version 1.9.2. Version 5.1.2 of Lutece uses this version 1.9.2. Version 6.0.x of Lutece uses this version 1.9.3. This correction nevertheless requires an additional configuration provided in versions 5.1.6 and 6.0.1 https://dev.lutece.paris

In addition, this vulnerability is blocked by Tomcat from versions 6.0.48, 7.0.73, 8.0.39, 8.5.8 as indicated on the form: CVE-2016-6816

Path Manipulation

This type of attack consists of modifying the path to a file from input data of a query. The characters used are "..", "/" "\" thus allowing to navigate in the tree structure of a filesystem.

Starting with Lutece 5.1.6 or 6.0.1 a containsPathManipulationChars method of the SecurityUtil class can detect any path manipulation attempts from input data. Attempts are logged in the security.log file.

Log Forging

This type of attack consists of the possibility of adding the writing of false information in the logs by adding them to input data that would be logged.

Any input data that you wish to log into a non-DEBUG log must be reported as user-generated data.

AppLogService.error ("User data:" + strUserData);

must be secured as follows:

AppLogService.error ("User data:" + SecurityUtil.logForgingProtect (strUserData));

XML External Entity Injection

The XmlUtil utility class is secure against this type of attack from Lutece 5.1.6 and 6.0.1.

Unsafe Deserialization

This type of attack consists of the modification of a serialized object (by the standard mechanisms of serialization of Java) which has the effect of being executed at the time of deserialization of the object by the readObject method.

To guard against this type of attack, it is necessary to check that the deserialized classes are the ones expected. This can be realized thanks to the ValidatingObjectInputStream class proposed by Apache Commons by indicating to it the list of accepted classes as in the following example.

ObjectInputStream objectInputStream = new ObjectInputStream (inputStream);
                ValidatingObjectInputStream objectInputStream = new ValidatingObjectInputStream (inputStream);
                objectInputStream.accept (MyObject.class);
                myObject = (MyObject) objectInputStream.readObject ();
                objectInputStream.close ();

Unreleased Resource

If some system resources are not properly released, an attacker can perform a Denial Of Service (DOS) attack.

All resources must be properly closed, especially when an exception interrupts processing. To do this, either use the finally clause or the try-with-resource

finally
{
         if (stream! = null)
         {
             try
             {
                 stream.close ();
             }
             catch (IOException ex)
             {
                 AppLogService.error ("Error closing the stream:" + ex.getMessage (), ex);
             }
         }
}

or from Lutece 6.0.1

finally
{
       safeClose (stream);
}

or

try (ACloseableStream stream = ...)
{
  ...
}