CGordon830606 (Community Member) asked a question.

September 19, 2024 at 4:18 PM
What is wrong with this pattern for preventing CWE-80. This same mitigation is used, and even with additional attributes allowed, and its accepted by Veracode. What is different here that this is not recognized as mitigated?

export const el = str => {

// Ensure that str is a string; if not, set content to an empty string

const content = typeof str !== 'string' ? '' : str;

 

// Create a temporary div element

const tmp = document.createElement('div');

 

// Set the innerHTML of the div, with proper sanitization

tmp.innerHTML = DOMPurify.sanitize(content);

 

// Return the first element child of the temporary div

return tmp.firstElementChild;

}

  • 2 answers
  • 394 views

  • CGordon830606 (Community Member)

    This pattern is frustrating, and has played out several times for me. We do it in the suggested way, and there is still a problem. We open cases that lead to engineering tickets because of bugs on the regular. That is not what this is...

     

    Answer from Veracode

     

    "the use of DOMPurify was correct and satisfactory. This flaw is a False Positive as the risk of XSS is sufficiently controlled at this location. That said however, I do not expect other similar usage of DOMPurify to result in flaws being reported. If there are any other occurances where DOMPurify is used in the same way, those can be marked as False Positive. What has happened here for this one specific flaw is that we reached a technical limitation of our scanner, typically due to application size or complexity where we incorrectly raised this flaw out of"

    Expand Post
    Selected as Best

  • RWilliams360614 (Community Member)

    Hello!

     

    Your code uses DOMPurify to sanitize input, which is a good practice for preventing XSS attacks. However, there might be a few reasons why this pattern isn’t recognized as mitigated for CWE-80. Ensure that the sanitization is appropriate for the context in which the content will be used, as different contexts require different types of escaping. Verify that DOMPurify is configured correctly, as default settings might not cover all edge cases. If additional Summit Medical Group attributes are allowed, ensure they are also sanitized properly, as attributes like onload and onclick can introduce vulnerabilities. Veracode might have specific rules or checks that differ from other tools, possibly being more stringent or looking for additional mitigations. Reviewing these aspects can help ensure your mitigation is comprehensive and aligns with Veracode’s requirements.

    Expand Post

  • CGordon830606 (Community Member)

    This pattern is frustrating, and has played out several times for me. We do it in the suggested way, and there is still a problem. We open cases that lead to engineering tickets because of bugs on the regular. That is not what this is...

     

    Answer from Veracode

     

    "the use of DOMPurify was correct and satisfactory. This flaw is a False Positive as the risk of XSS is sufficiently controlled at this location. That said however, I do not expect other similar usage of DOMPurify to result in flaws being reported. If there are any other occurances where DOMPurify is used in the same way, those can be marked as False Positive. What has happened here for this one specific flaw is that we reached a technical limitation of our scanner, typically due to application size or complexity where we incorrectly raised this flaw out of"

    Expand Post
    Selected as Best

Topics (4)

No articles found
Loading

Ask the Community

Get answers, share a use case, discuss your favorite features, or get input from the community.