dmxAppConnect.js SAST vulnerability

I’m going through a CASA assessment for my app, and this vulnerability for dmxAppConnect.js was found. Can anything be done to resolve it?

Vulnerability description

Direct parsing from localStorage data without any previous validation could lead to injection attacks in desktop-app-v4/www/dmxAppConnect/dmxAppConnect.js

App Connect doesn’t get any data from localStorage, the only code where data from localStorage is used within dmxAppConnect.js is in the flow actions getStorage.

We do no validation since we don’t determine which data is being inserted. I’m not aware of any injection attack with JSON.parse which is used to parse the data from the localStorage.When your App doesn’t use the flow action getStorage it will never be called.

Do they give more information about the vulnerability and some solution for it?

They are pointing to this as the issue (Line 9 Col 81053) and categorizing it as a “Lack of data validation - Trust boundary violation

This is the one blocker that I’m unable to resolve easily to pass the CASA Tier 2 Assessment. Hopefully, there is some type of permanent fix that can be implemented. Otherwise, I may need to modify AppConnect to proceed with launching my app.

GPT provides the following guidance.


Here’s what you can do to improve the security of this code:

  1. Validate Key and Value : Ensure that the key and value used with localStorage are validated against expected formats or whitelisted values.
  2. Catch JSON Parsing Errors : When parsing JSON from localStorage , use a try...catch block to handle parsing errors gracefully. This helps to prevent issues if the data is not valid JSON.
  3. Sanitize Values : If the values retrieved from localStorage are used in the DOM or in a way that could execute code (like eval or innerHTML), sanitize these values to remove any executable code.

Here is an updated version of the code with added error handling for JSON parsing and a hypothetical sanitize function for the values:

setStorage(e) {
    const t = this.parse(e.key);
    const s = this.parse(e.value);
    if (typeof t !== 'string') throw new Error("setStorage: key must be a string");
    localStorage.setItem(t, JSON.stringify(s));
    return s;
},
getStorage(e) {
    const t = this.parse(e.key);
    if (typeof t !== 'string') throw new Error("getStorage: key must be a string");
    try {
        const item = localStorage.getItem(t);
        const parsedItem = JSON.parse(item);
        // Sanitize the parsedItem here if it's used in the DOM or evaluates code
        return parsedItem;
    } catch (err) {
        console.error('Error parsing JSON from localStorage', err);
        // Handle the error, perhaps return a default value
    }
},
removeStorage(e) {
    const t = this.parse(e.key);
    if (typeof t !== 'string') throw new Error("removeStorage: key must be a string");
    localStorage.removeItem(t);
    return true;
}

For the sanitize function, you will need to implement it based on how the data is used in your application. There are libraries like DOMPurify that help with sanitizing HTML content, but for other uses, you might need custom validation/sanitization logic.

2 Likes

Thanks Keith, great examples @patrick will check them out.

For html a custom app connect sanitizer might be required indeed.

1 Like

The flow actions already have error handling, it is done in the flow component that is calling the action methods. Also the sanitize is done on most places where values are used in the DOM, only the dmx-html attribute allows to insert unsafe html, all other DOM bindings are safe.

Do you use values from localStorage in the DOM and how do you bind them? We could include the DOMPurify for the dmx-html attribute. I know there are developers who do insert html with JavaScript and App Connect Components using the dmx-html attribute, so we should probably have the option to enable unsafe html for those developers. I think having it safe by default is the best way.

In the project that I submitted for the CASA assessment, I’m only storing one value for dark mode, but this is more about the potential vulnerability than immediate use in my project. Since App Connect is a core part of everything I’ve built, it appears I will need to prove that it’s not a vulnerability.

To be frank, the entire process of going through the assessment is challenging. Google and the assessors do not provide any advice on ways to work around the findings or how to explain that it handles validation like you mentioned above, only that “you must pass all 73 requirements” and App Connect code shows that “direct parsing from localStorage data without any previous validation could lead to injection attacks”.