0

Full disclosure: I inherited the code. I was tasked to fix it. After 9 hours, I am turning to you, the hive mind.

Inside an object (response) is response.Object Object contains HTML code.

$("doodah").html(response.Object)

Coverity doesn't like this. It's vulnerable to a DOM XSS attack. Coverity is complaining about how it is vulnerable to an arbitrary JavaScript statement that can taint respose.Object.

So I tried to REGEX it out. No good. .replace(RegEx_Clear_Scipt_Tags) didn't work. I added RegEx to clear Script tags and in-line JavaScript. Coverity does not like this either.

Fine, so I tried a function that puts the code in a DIV, strips out the Script tags through DOM functions and returns the innerHTML

No good. Coverity didn't like that either.

Does anyone have any suggestions?

Heretic Monkey
  • 11,687
  • 7
  • 53
  • 122
JR.sc
  • 37
  • 6
  • 1
    What is the source of `response`? Coverity isn't perfect, and sometimes you'll just have to ignore it from situation to situation. – code Jun 02 '22 at 23:34
  • ´reponse´ comes from an $.AJAX call. Specifically from.´success´. Coverity is not perfect and neither is the code. The code came from 2014 and no one has touched it until it was assigned to me. – JR.sc Jun 02 '22 at 23:40
  • 1
    This is how the backend was designed. There's nothing you can do about it. – code Jun 02 '22 at 23:51
  • Forget about Coverity. Ship the code. There's nothing wrong with it unless the HTML input is from an untrusted source. – code Jun 02 '22 at 23:55
  • The only possible entrusted sources come from the search window. I looked at those and they are protected through the entire stack. Adding RegEx to the incoming HTML code? Should i still do that? And what do i do about this Stack Overflow entry? – JR.sc Jun 03 '22 at 00:01
  • 1
    I guess you can leave it there and if you find another solution post it. Or maybe someone else has some brilliant idea. – code Jun 03 '22 at 00:03
  • It sounds like you are trying to sanitize user-provided HTML within the client. Have you looked at the question [Sanitize/Rewrite HTML on the Client Side](https://stackoverflow.com/questions/295566/sanitize-rewrite-html-on-the-client-side/430240#430240)? – Scott McPeak Jun 03 '22 at 00:43
  • Would it solve anything on the Coverity side? – JR.sc Jun 03 '22 at 01:00
  • @JR.sc I don't know whether it would out of the box, but Coverity can be configured to understand new sanitizer functions, so there is a path to a solution there. In any case, I'd focus on making the app secure (which, if I understand correctly, it is not) before worrying about making Coverity happy. – Scott McPeak Jun 03 '22 at 01:57
  • Almost every other issue i resolved except for SQL un/pw which is forced on the SQL side making it a non-issue and this stick!in-the-mud which i guess doesnt have a solution at the moment. – JR.sc Jun 03 '22 at 02:05

0 Answers0