[6.x] Limit expected bindings v2

[KaneCohen]

Update for recent security fix taking into account @mpyw comment here: #35865 (comment)

PR cleans inputs in case if passed values include nested arrays.

[mpyw]

@KaneCohen I'll appreciate for your quick fix! Thanks

[u01jmg3]

@KaneCohen: thanks for this. One thing I noticed, whereDay() and whereYear() don't make use of your new method scalarValue() but whereMonth() does. Was this on purpose?

[KaneCohen]

@u01jmg3 updated. Looks like I've missed those when was porting code from 8.x branch.

Thanks for spotting.

[limingxinleo]

I think the following code is more reasonable

    /**
     * Returns scalar type value from an unknown type of input.
     *
     * @param  mixed  $value
     * @return mixed
     */
    protected function scalarValue($value)
    {
        if(is_array($value)){
           throw new \Exception(); 
       }
        return $value;
    }

[KaneCohen]

@limingxinleo I think primary reason why this was not done in the first place is that throwing an exception might unnecessarily break existing applications which pass arrays as a value.

[u01jmg3]

Is this necessary as we are casting to an integer? I guess it could still help if an array is provided.

[KaneCohen]

I can’t really say. Casting an array into integer returns 1 - so there’s that. Really depends on what’s expected when one passes an array there.

[jaylinski]

@taylorotwell It would be nice if you could update this advisory accordingly: GHSA-3p32-j457-pg5x 🙏

[driesvints]

Existing advisories can't be altered in GitHub unfortunately.

[DavidPrevot]

That’s fair: a CVE has already been assigned anyway. On the other hand, adding another advisory to document that new fix would be nice (as well as requesting another CVE for the incomplete previous fix).

[naderman]

@driesvints @taylorotwell I see that you did publish a follow up blog post at https://blog.laravel.com/security-laravel-62012-7303-released, after the issue which got a CVE, because of a tagging problem. However the related(?) fix from this PR appears to only be in 6.20.14/7.30.4/8.24.0 - can you clarify whether you consider this part of the same issue and which versions should correctly be identified as vulnerable on packagist.org, github and other security scanning sites relying on the FriendsOfPHP/security-advisories database? The PR by @jaylinski there currently references a third party blog as the source, but I'd much rather reference an official blog post of yours if you could update it with the corresponding information? FriendsOfPHP/security-advisories#532 Thanks!

[stof]

@naderman https://blog.laravel.com/security-laravel-62012-7303-released is not about the fix in this PR. It is about the fact that the previous fix does not properly appear in the releases of illuminate/database before 7.30.3 (while it does for laravel/framework). This PR is a separate topic.
So I think we actually need 3 sets of advisories in FriendsOfPHP/security-advisories:

• the existing one for CVE-2021-21263 applied on both laravel/framework and illuminate/database and the original blog post
• one for illuminate/database only referencing https://blog.laravel.com/security-laravel-62012-7303-released due to the tagging issue
• one for laravel/framework and illuminate/database for this second fix applied in newer versions.

[driesvints]

I'm currently checking if we can do a new security advisory. Please stay tuned.

[driesvints]

@naderman @stof we published a second advisory for this specific fix: GHSA-x7p5-p2c9-phvg

[naderman]

@driesvints thank you!