A breif investigation into the security and suitability of jsreport.

jsreport licensing audit

JSReport, brief licensing audit.

In order to verify if JSReport is suitable for our needs one thing we must check is the licensing because it uses a remote server.


A license key is checked by a remote server, as such we must understand the behavior.
We can't have the software leaking any private information from the report templates/data therein.
The implementation does a post to an https URL.

License verification URL: https://jsreportonline.net/license-key
File: node_modules\jsreport-licensing\lib\licenseing.jsreport

Note: This needs to be allowed through firewall in order to verify the license.

If you add more than 5 templates without a license, then the jsreport instance is put into a 1 month trial this should be suitable for developing a few reports and testing the viability of this reporting solution.


Another concern is, what if the remote URL cannot be accessed in a scenario such as:
 a) It goes down or returns error either temporarily or for good at some point in the future.
 b) The Internet connection stops working but we still want to use jsreport inside our network?

Thankfully in a show of good design/future proofing, the licensing code does appear to have a fall-back to an enterprise license if the verification server is unreachable or sends back a non 200 HTTP status code, this also kicks in after a timeout of 3 seconds, which I am assuming handles a case of slow connection/IO delay or if DNS is down/slow.
This satisfies any concern about the reporting solution being unavailable during network or remote licensing service outage.


From reading the code what I can gather is a license response would look something like this.

HTTP Status 200 OK.

// An invalid license.
// Causes jsreport instance to fail starting.
{
    status: 1,
}


// A successful license validation.
// Type can be either: trial, free, subscription, enterprise
{
    status: 2,
    type: 'enterprise',
    expiresOn: 'assuming date-time',
    license: '???'
}

A security hash is generated from the licensing info JSON and stored over-writing the license JSON file.
This could pose a threat, if malicious code can be injected from the verification server, or by a server posing to be the verification server (MITM attack).

The license JSON file is read in and parsed with JSON.parse.
So long as we can trust JSON.parse not to have an exploit / evaluate or buffer overflow etc, then we should be able to assume a minimal risk from the solution it's self.
Although if report's somehow opened up a LFI, they could in potentially load up the JSON license file, although this is unknown.

I have my concern, but I will consider it a low risk.


JSON.stringify is used when calculating the hash. This assumes that JSON.stringify will always output keys in the same order.
The docs state that for non-array properties, order is not guaranteed.

```
Properties of non-array objects are not guaranteed to be stringified in any particular order. Do not rely on ordering of properties within the same object within the stringification.
```
This could cause verification to fail however, in practice with named keys it appears the v8 engine implementation outputs the keys in canonical order.