feat: upload textproto for Ofbiz_CVE_2023_51467

[W0ngL1]

Hi @tooryx, @leonardo-doyensec,

It's the templated plugin for Ofbiz_CVE_2023_51467, whick linked to #388.
Here is the testbed PR: google/security-testbeds#168.

I found a small but practical issue when testing Apache OFBiz: after deployment OFBiz treats localhost as a trusted host by default, so requests that use any other IP trigger a “host not trusted” error. To work around this I added a Host: localhost header in my vulnerability plugin requests, but in real scans the trusted host can get changed by the configuration, which makes reliable reproduction harder.
I considered using the built-in T_NS_HOSTNAME variable, but that doesn’t match the local deployment behavior I want to reproduce (it’s inconvenient to force a scanner to use the machine’s hostname as Host).
A few ideas that might help:
Add an explicit option to the scanner/plugin to force a custom Host header (e.g. force_host: "localhost") so tests can reliably reproduce host-based checks even when proxying or using different target IPs.

[giacomo-doyensec]

Hi @W0ngL1, thanks for your contribution!
Is there a particular reason you are not testing the RCE with an OOB interaction? As long as it's possible to implement, it would be the preferred option.

[W0ngL1]

Hi @giacomo-doyensec,

In this PoC, I chose to use a direct response-based detection method instead of an OOB channel. The main reason is that if the target environment is unable to initiate outbound network requests, OOB-based detection will fail. In contrast, using an in-band response makes the PoC more straightforward, easier to verify, and more compatible across different deployment environments — especially those with restricted egress traffic.

[giacomo-doyensec]

Hello @W0ngL1,

Adding a fallback to response-based detection would definitely be useful when egress filtering blocks OOB callbacks. The ideal flow would be: if CBS is configured, run OOB detection first; if that fails or CBS isn’t configured, fall back to response-based detection. The templating engine doesn’t appear to support this natively, but @tooryx might know whether there’s a practical workaround with the current capabilities or if this is planned for future support.

That said, having a dedicated workflow for OOB detection is still the preferred approach. For now, keep the current logic as a fallback only when CBS is not configured, following the guidance here: https://google.github.io/tsunami-security-scanner/howto/new-detector/templated/06-callback-server.

[W0ngL1]

Hi @giacomo-doyensec,

Thanks for the detailed guidance — that makes sense from a framework design perspective.

Just to share the reasoning from a practical penetration-testing standpoint: we typically prioritize detection methods based on the vulnerability behavior itself. If a vulnerability provides a direct in-band response, that's usually preferred because it’s faster, more reliable, and leaves no dependency on outbound connectivity — which also makes it more stealthy and less intrusive. OOB is generally used when no direct response can be observed.

That said, I understand the preference to standardize on OOB-first workflows within the Tsunami framework. If it's required that future detectors always default to OOB first, I can certainly follow that convention.

However, for this particular vulnerability, given that the response-based indicator is explicit and deterministic, I still believe it makes sense for it to be the primary detection method.

Happy to adjust if needed — just let me know your final expectation.