Penetration Testing Results - Some Issues



  • We recently had a pen test conducted against our application, and its ancillary components, and there were three moderate issues raised specifically for the jsreport server (v2.2.0). Please provide any input you can to help us mitigate these:

    Finding 1: Strict Transport Security Misconfiguration: There was no Strict-Transport-Security header in the server response. The HTTP Strict Transport Security policy defines a timeframe where a browser must connect to the web server via HTTPS.

    Is this configurable via the jsreport conf, or docker host?

    Finding 2: Auto-completed Password Fields: The password auto-complete feature allows users to have the browser automatically fill the password field with previously submitted values when a user begins entering the password. Unless specifically disabled, this feature is enabled by default.

    Can you confirm this was fixed in 2.4.0? If so, we will renew our subscription and update to the latest version

    Finding 3: DOM-Based Link Manipulation: DOM-based vulnerabilities arise when a client-side script reads data from a controllable part of the DOM (for example, the URL) and processes this data in an unsafe way. DOM-based link manipulation arises when a script writes controllable data to a navigation target within the current page, such as a clickable link or the submission URL of a form.

    Problem line of code below is: form.action = window.location.pathname + window.location.search;

                var form = document.getElementById("loginForm"); 
                if (window.location.pathname.lastIndexOf("login", 0) === 0) { 
                    form.action = window.location.pathname + window.location.search; 
                } 
                else { 
                    if (window.location.search.indexOf("returnUrl") === -1) { 
                        form.action = "/login?returnUrl=" + 
    encodeURIComponent(window.location.pathname + window.location.hash + 
    window.location.search); 
                    } else { 
                        form.action = "/login" + window.location.search; 
    <SNIP>
    

    This looks to be squarely in your code, and I can't see any mention of a fix in the release notes for versions after v2.2.0. Can you please comment?



  • Finding 1: Strict Transport Security Misconfiguration

    We will check if it is safe to add that header and if it helps something.
    You should be able to add it on your own if you run a web server in front jsreport for now.

    Finding 2: Auto-completed Password Fields:

    This was fixed in jsreport 2.4.0

    Finding 3: DOM-Based Link Manipulation

    We will see what we can do with it.



  • Much appreciated Jan - I'll wait for a follow up!



  • Any news on the DOM-based link manipulation? This came up in a penn test for us as well.


  • administrators

    DOM-Based Link Manipulation: there is nothing we need to do here, the penetration test, in this case, reports a false positive, the vulnerability is described here, we are not vulnerable because we don't generate the dynamic form action value using user input, we use values from window.location which is immutable, and if some script changes it, it causes a page refresh. the vulnerability description also contains a section that mentions that there can be false positives, and this is what is happening for jsreport.

    from the vulnerability description page:

    Burp Suite automatically identifies this issue using static code analysis, which may lead to false positives that are not actually exploitable. The relevant code and execution paths should be reviewed to determine whether this vulnerability is indeed present, or whether mitigations are in place that would prevent exploitation.


  • administrators

    Strict Transport Security Misconfiguration: about this we are going to add a config that will allow to set general response headers for all requests, with that config user will be able to set Strict-Transport-Security header if user wants to enforce https at the jsreport level, although we recommend that such header is configured in nginx (when possible)



  • Thanks for the feedback Boris!



  • When upgrading from version 2.2.0 to 2.4.0 (or later) we get the following red wall of text. What's going wrong here?

    0_1576219601948_12-12-2019 11-44-32 PM.png


  • administrators

    hi! hmm i think this problem is related to a folders migration logic we run when you update to any version > 2.3.0.

    are you storing your templates using fs-store?

    this is a similar topic https://forum.jsreport.net/topic/1262/error-because-of-folder-shortid/6 in which i ask for some help to reproduce the issue so we can fix it, maybe you can help us sharing your original entities (the entities previous the jsreport upgrade to 2.4.0), you can share a zip of your data folder and your config file privately via email if you want to help us to fix this. unfourtunately this is the best way for us to replicate the problem, since we are not able to replicate the same issue, so it probably means that it is only affecting some specific migrations and your case will help to verify this.

    quote from the other topic:

    are you able to replicate the issue every time you upgrade the jsreport? i mean, if you go back to your previous jsreport/jsreport:2.0.0-full image with the same data folder that you have at that time, and then try to upgrade to jsreport/jsreport:2.6.1-full, does the issue continues to happen every time? if this is something you can reproduce every time you try to migrate from jsreport/jsreport:2.0.0-full to jsreport/jsreport:2.6.1-full then best will be that you share with us the data folder that you have on jsreport/jsreport:2.0.0-full so we can inspect what is happening, since the addition of folders entities to jsreport (v2.3.0) there is a migration step that we run at jsreport startup that tries to migrate entities to folders, it can be the case that this migration is causing this issue by duplicating the shortid, however we never saw this before.



  • Hi Boris,

    I can downgrade back to 2.2.0 and the server runs fine. Any time I go to 2.4.0 or greater, this red screen is presented. I've tried every version between 2.6.1 and 2.3.0, and they all show the red screen.

    Yes, we're using fs.

    I have included our config file in the zip (and also the start-up script, as it installs some specific npm modules into the docker container) - where should I email it to?


  • administrators

    I have included our config file in the zip (and also the start-up script, as it installs some specific npm modules into the docker container) - where should I email it to?

    thanks, this will really help to verify the problem. you can send it to bjrmatos@gmail.com


  • administrators

    @izelt i have received the email with the details, we will check the problem and reply here with some news when we find the issue. thanks for the help



  • Any update on this @bjrmatos ?


  • administrators

    not yet, it is added to my work queue so i will get to it soon, sorry for the wait


  • administrators

    @izelt sorry for the long wait. FYI i have sent you email with some notes about the problem and a workaround for your case.



  • That appears to have worked in the lab Boris! Prod soon. Thank you.


Log in to reply
 

Looks like your connection to jsreport forum was lost, please wait while we try to reconnect.