Provide argument based alert messages instead of generic

Is your feature request related to a problem? Please describe. Some commercial security tools do provide parametrized messages which are really nice to read for end users when it comes to automated scans.

While implementing SARIF reporting (see https://github.com/zaproxy/zaproxy/issues/6875) I recognized, that the messages available in ReportData/Alert instances are very generic.

The sarif format provides arguments for texts and initially I would tried to provide sarif result messages like:

"message": {
	"text": "Cross Site Scripting (Reflected) found in URI: {0}. Send attack vector {1} and the evidence {2} in the web response shows the attack was successful.",
         "arguments": [ 
             "https://localhost:8081/greeting",
             "</p><script>alert(1);</script><p>",
              "</p><script>alert(1);</script><p>"
      ]
},

But this is not possible, because there is no API. So inside SARIF reporting, the normal description etc. is used instead.

Describe the solution you’d like I would like to have the possibility to access a parameterized user message like

// some pseudo java code for usage explanation
...
Alert alert = fetchTheAlert();
MessageData  messageData = alert.getDescriptionMessage();

String text = null;
if (messageData != null){
   MessageFormat messageFormat =  messageData.getFormat();
   Object[] messageArguments = messageData.geArguments()

   text = messageFormat.format(messageArguments);
}else{
   // no dedicated message found, so fallback to standard text
   text  = fetchStandardText();
}
...

So every report could contain a very details message for the user. The messages could be implemented step by step, so no “BigBang” necessary. Of course this could also be used inside the ZAP UI to provider a better UIX (e.g. for a tooltip when hoovering over an alert)

Describe alternatives you’ve considered

• Improve Sarif/Reporting: The reports shall be “dumb” at my opion and implementing any additional logic here would make no sense there. The logic of those things must handled inside zaproxy (IMHO)
• just provide the generic text (as done in SARIF reporting now)

Would you like to help implementing this feature? Maybe

[kingthorin]

I’d suggest using them to supplement not supplant (concatenate not replace), for my 2 cents.

[thc202]

That’s the purpose of the “other info” (more details about the actual issue), along with attack and evidence.

Edit: With that not saying that all rules do that, but should.