vendor package issues

[eywa-saravanan]

Hi,

we face security issue.. need for solution..

issue detail given below

package name : Doctrine DBAL

Package link : https://github.com/doctrine/dbal

issue description :

line numbers :
a) vendor/doctrine/dbal/src/Cache/QueryCacheProfile.php:130

1. An attacker can exploit the weaknesses of SHA-1 to perform collision attacks, potentially leading to data breaches and loss of data integrity.

solution need like this : It is recommended to avoid using SHA-1 for hashing. Instead, opt for stronger hashing algorithms such as SHA-256 to enhance security.

thanks

[derrabus]

Can you elaborate how a collision on a cache key is a possible security threat?

[morozov]

In theory, two queries may produce the same hash (regardless of the hashing algorithm) and thus, the caller of one query may get access to the results produced by another.

From the security-related static analysis standpoint, a proper fix would be to eliminate hashing of the query in the cash and use the full query and parameters as the key.

For instance, in the case of array-backed cash, PHP internally will hash the key but it will also compare the values during array access to avoid collisions. As for all other backends, there may be natural limitations to their key lengths, so again, a theoretically correct solution would be to implement a hash table that would map the queries and their parameters to the external cache key but also would properly handle hash collisions.

At this point, it doesn't look like a practical problem, so I don't think we need to make any changes in the library.

[derrabus]

In theory, two queries may produce the same hash (regardless of the hashing algorithm) and thus, the caller of one query may get access to the results produced by another.

As far as I can tell, we've accounted for that by storing all input to the hash computation with the object that we're caching. So even in the highly unlikely case that cache keys collide, we won't get the result of a different query.

SHA1 is problematic in situations where the original value can be derived or guessed from the hash. From my PoV, this is a non-issue for the query cache because you could recreate all hashes by enumerating the content of the cache. We could even switch to XXH3 for our cache keys which is a very fast algorithm without any ambitions of being cryptographicly secure.

As for all other backends, there may be natural limitations to their key lengths

The limitation would be 64 UTF-8 characters as defined by the PSR-6 standard. Even though many backends do support longer keys, I believe we should not bend the contract here.

At this point, it doesn't look like a practical problem, so I don't think we need to make any changes in the library.

I agree. And given that we haven't heard back from the person who opened the ticket, I believe we can close the issue.