Adding additonal Security to Website
Asked Answered
M

3

7

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?

Mitziemitzl answered 12/3, 2015 at 14:12 Comment(1)
Let me add a Comment: Consider you have huge amounts of JSP/JS already and now have to protect them against various forms of XSS. How would you act? Installing a Filter seems to be insufficient. At least my researched have shown that these always seem to have a lot of vulnurabilites towards well crafted attacks. I feel like the only way would be escaping every input that is injected into the page. But its not possible to do so without rewriting basically every JSP and Js file, is it?Mitziemitzl
M
6
  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)

Means answered 12/3, 2015 at 16:50 Comment(8)
Thanks for the answer :) I have had quite some research the last hour and i do recognize a few hints but there are also a few new, cool :) To 1.) Is this needed along the other 2? It feels a little redundant with the other 2 points implemented? To 2.) Backend validation is actually the way i am aiming to go. Consider that i have around 60k lines of JSP/JS code ... following the rules of the cheat-sheet i posted in in the orginal post would take a lot of work. To 3.) Is JSTLs out method as safe as using the appropiate ESAPI function call? So, is c:out guaranteed to be safe?Mitziemitzl
And for the context-param thing .... These only work for spring-induced form-elements though, right? It will have no security effect if i put untrusted data inside of a <div> element, right? --- Overall, i think backend-validation is way to go for my case, as it is the least work and i can rightfully asume that a request containing weird characters is not friendly. I have no userinput that is justified to use any special character, so i might as well reject requests with parameters that contain any. I will mark your answer as accepted as you nicely displayed the most common options, thanks :)Mitziemitzl
@Mitziemitzl 1) you should use all the techniques for max protection. Redundant or Defense in Depth? 3) ESAPI is safer than JSTL out except for HTML node text in which case they are the sameMeans
@Mitziemitzl context-param turns on HTML Escape for Spring Forms AND jstl out.Means
Acceptable, i guess the redundancy wont hurt indeed :) To 3) So one should consider what to use, meaning i will have to look carefully through the JSP/JS code and decide accordingly. I understand, yea. I am already setting the httpOnly property to cookies in the backend, but good point! But AFAIK it doesnt prevent them from being read, only from being written? I just saw the link you edited ... sounds incredibly promising! I will take a look at it, thanks a lot :)Mitziemitzl
Alright, had wrong information then, my bad! The git-repo you provided sounds like it could save me a lot of work. A LOT. I will try to implement that listner tomorrow and the coming days and i will definitely report back with the results. If i get it to work in the way it promises to work that would easily save countless hours of work. Thanks againMitziemitzl
I implemented the Listener and it indeed does all the encoding to HTML automatically. Sweet stuff! However, as far as i understood HTML encoding is only sufficient for putting it into HTML tags, etc. Is it sufficient for html attributes? And its not sufficient for putting it into JS, is it? Now, an important question: If there is no reason to allow any special character for a certain field .... Using a Filter that simply purges any none [a-z][A-Z] or space character will be absolutely safe, right?Mitziemitzl
Correction, httpOnly prevents JavaScript read. You can "clobber" an httpOnly cookie (essentially you can delete it and create a new one by creating 150+ cookies w same name, root domain to overflow cookie jar)Means
S
1

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.

XML parser

We often need to import data from xml.

All Sax parser should use below features :

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
Sinless answered 18/12, 2018 at 13:37 Comment(0)
M
0

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.

Mitziemitzl answered 15/3, 2015 at 18:43 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.