Adding additonal Security to Website

Question

I am running a Java Spring MVC based Web-Application. It is also based on the Hybris Platform.

Now, the basic functionality in terms of Authentication and Authorization is already implemented. Meaning we do have filters for sessions, a working user-system, etc.

However, we currently have no security measurements against things such as XSS and other kinds of possible attacks that are out there. XSS is probably the biggest concern as it is the most common possible way of attacking.

Now, i wonder ... what steps would be smart to take? I have taken a look around and i have seen that stuff like XSS-Filter exist. Implementing such would be pretty easy, just copy past the source and add it as a in tomcats web.xml.

But i wonder if that is a satisfying amount of security from such filter?

There are also way more bloated solutions, for example i could use the spring-security. However, reading the documentations, i feel like this is very bloated and a large part of it implements what is already implemented ( the two A's, for example). I feel like it would take a lot of work to configure it down to the amount of work that i need it to do. Am i wrong?

And:

How would you say is it recommended to deal with security issues, for example XSS? Do you use a certain predefined framework that suits the needs or is your security "hand-made" by following things like the cheat sheet?

Answer 1

1. Set Anti-XSS Headers (hint: use Spring Security or make your own Interceptor)

   Content-Security-Policy: default-src 'self'   --only allow content from your own site
   
   X-XSS-Protection: 1; mode=block   --prevent some reflective attacks in some browsers
   
   X-Content-Type-Options: nosniff   --can't trick browser into detecting and running js in other content types
   

2. Prevent malicious inbound HTML/JS/CSS

   Use Hibernate Validator (you don't need to use Hibernate ORM to use this) with the @SafeHtml annotation on all user-supplied String fields.

   You could validate all request headers, post params and query params in one Interceptor for simplistic XSS validation.

3. Escape all user-supplied data on output

   Use OWASP's Java Encoder Project <e:forHtml value="${attr}" /> to escape output or JSTL's <c:out value="${attr}"/> and in web.xml set

   <context-param>
       <param-name>defaultHtmlEscape</param-name>
       <param-value>true</param-value>
   </context-param>
   

   They are equally safe if escaping HTML node text, but OWASP is safer for HTML attribute or <script> escaping.

   If you have too many files to edit, consider http://pukkaone.github.io/2011/01/03/jsp-cross-site-scripting-elresolver.html

4. Make your session cookie unreadable by JavaScript. In web.xml:

   <session-config>
       <cookie-config>
           <!-- browser will disallow JavaScript access to session cookie -->
           <http-only>true</http-only>
       </cookie-config>
       <tracking-mode>COOKIE</tracking-mode>
   </session-config>
   

5. If you are hosting user-uploaded files, you need to use a different domain (not subdomain) for download links, so that evil content cannot clobber your session cookie (yes, this can happen even if it's httpOnly)

Answer 2

I'd like to add this answer, as i think it is a simple but important thing to notice:

In my case i realised that i do not need to allow any kind of critical special characters for user input. I analysed the situation and realised that it makes no sense and that there is no need to do so in any of my webpages.

So, instead of having to implement proper styled XSS-safe code on about 60k existing lines of code, i could simply install a filter that would purge out all special characters, that i do not want to allow.

You could see this a little critical in terms of user-friendliness, but it should be OK.

So: If you realise that you do not need to allow any special characters, that are going to be critical in one of the possible contexts (such as JS,HTML,attributes, ... ), then you could safe a lot of work, given that you are in the same situation that i am/was in.

Obviously implementing the steps mentioned by Neil is still proper style if you are doing your work from scratch. If people had known these steps before all the JS and JSP stuff was written they surely would have implemented them, potentially needing them or not shouldnt matter.

Answer 3

Here is a list of things concerning hybris security that I've done on my projects :

First read documentations

Below links are full of resources and details about security in hybris.

• Non fuctional requirement
• Data protection
• Deployment check list
• SAP Commerce Security

XML parser

We often need to import data from xml.

All Sax parser should use below features :

• XMLConstants.FEATURE_SECURE_PROCESSING = true
• http://xml.org/sax/features/external-general-entities = false
• http://xml.org/sax/features/external-parameter-entities = false
• http://apache.org/xml/features/disallow-doctype-decl = true

It allows to

• instructs the implementation to process XML securely. This may set limits on XML constructs to avoid conditions such as denial of service attacks.
• do not include external general entities.
• do not include external parameter entities or the external DTD subset
• throw a fatal error if the incoming document contains a DOCTYPE declaration

JSON

All input must be validated using the OWASP lib json-sanitizer. See https://www.owasp.org/index.php/OWASP_JSON_Sanitizer

Example :

String wellFormedJson = JsonSanitizer.sanitize(jsonData);
try
{
    return new ObjectMapper().readValue(wellFormedJson, JsonNode.class).toString();
}
catch (final IOException ex)
{
     LOG.error("Incorrect json data : " + wellFormedJson, ex);
}

LOG

String coming from outside the application must not be directly logged to prevent log injection.

Controller case

In web context all controllers must extends BaseController. This class contains the method logParam which should be used to log something unknown.

This method uses YSanitizer.sanitize(input).

public class YSanitizer
{
    public static String sanitize(final String input) {
        String output = StringUtils.defaultString(input).trim();
        output = output.replaceAll("(\\r\\n|\\r|\\n)+", " ");
        output = StringEscapeUtils.escapeHtml(output);
        return output;
    }
}

Other case

Calling StringEscapeUtils.escapeJava(valToLog) should be enough.

Protect sensitive data from heap inspection

Because heap can be inspected, sensitive data should not be stored in String objects.

Indeed Strings are immutable and can stay in the heap for a while.

To prevent this issue all sensitive strings must be stored in a char[].

This array should be filled with "0" as soon as possible (when the value is not needed).

Not that this method is not 100% safe but reduced the time window to find the password in the heap.

Cross-Site Scripting (XSS)

Make sure de.hybris.platform.servicelayer.web.XSSFilter is in the filters list of incoming requests

Deployment checks (from Go-Live Checklist)

• Verify that the default passwords for all users have been changed
• Change admin user password for production
• Disable automatic login or pre-populated passwords for
  • Product cockpit
  • CMS cockpit
  • CS cockpit
  • hMC
• Password encoding should be MD5 or better SHA256
• Change default password encoder
• Change SALT for MD5 and SHA256 password encoder
• Verify the database password and the requirement to store them in plain text in local.properties.
• Verify that user account and checkout pages are only accessiable via a secure SSL connection
• Check that a Web application firewall is in place
• Perform a code review to ensure that no sensitive data, like credit card information or passwords, are logged to the log file
• Verify that the hybris application server is not running as root
• Secure the JMX connected