product_type parameter in admin is not validated properly

[zcwilt]

if the GET parameter for product_type is altered to use an out of range value, the code still does the look up but returns a blank hander name. It then attempts to load product handler code based on an incorrect path.

[zcwilt]

Why/where are $_GET params being modified? This is a bigger issue: Encapsulating these globals into a class helps prevent modification and improves quality by providing sanitization and validation. See Aura.Web Request https://github.com/auraphp/Aura.Web/blob/develop-2/README-REQUEST.md (esp. Values.php https://github.com/auraphp/Aura.Web/blob/develop-2/src/Request/Values.php).

The Aura library components are completely decoupled and designed to be drop-in enhancements to legacy projects like ZC to help get them up-to-date. Paul M. Jones http://paul-m-jones.com/ built it and I highly recommend leveraging his library here. Addressing this issue would be a great place to start.

@texdc I think you misunderstand, I was referring to the parameter being changed in the URL, not being modified by code,
Background is that code is pen tested by PA-DSS QSA, automated scanning will manipulate GET/POST params to attempt exploits (XSS/XSRF/SQLi etc). The fact that manipulation of this parameter causes unexpected behaviour can trigger false positives in the pen test.

[scottcwilson]

@zcwilt I have looked through the code and don't see anywhere that this is happening - can you give me the URL that triggered the FP?

[zcwilt]

Let me take a look again. It maybe it was fixed as part of our last PA-DSS round.

[zcwilt]

e.g.
https://zen.local/admin/index.php?cmd=product_free_shipping&page=1&product_type=5&cPath=64&pID=172&action=new_product

change the product_type parameter to 99