Re: [PHP-DEV] Increase maximum size of an uploaded file to 50Mbyte
2MB is probably too low and it can be set at something like 20MB, but from my understanding setting it low enough will help prevent DoS attacks. If we change it to something larger, I'm not sure exactly what would be the effect of changing this default for mass-hosting providers where they can have thousands of Wordpress/Drupal/etc. setups on a single node. Changing from 2MB to 20MB for all requests may have quite an effect if there is an attack. Surely all those providers have teams dedicated to setting the right limit, but that shouldn't stop us from using a safe default. What is unpractical with upload_max_filesize and post_max_size though is that we can't set the limit for each script, because it affects how PHP is parsing the POST body before the script is even parsed. Unless at one point we provide some kind of option to set ini literals from within a script file before the request is processed (eg. declare(post_max_size=256M) or something like that), the only option is to use the web server to change the setting. That way most endpoints will benefit from a low limit, and only the targeted scripts or directories will have a higher limit. For example with Apache something like that will only change the limit for the parts of the admin where it's needed, and when the HTTP client has a cookie: php_value post_max_size 256M php_value upload_max_filesize 256M I commented with this snippet on relevant documentation pages, hopefully it will help people looking for that kind of info to do something a bit better than to set this limit for the whole server. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Error behaviour for max_input_vars
Hi On 9/14/22 21:58, Mel Dafert wrote: Thank you, this makes a lot of sense to me. I assume that this rules out that option, at least for now, unless someone makes the relevant changes to the hashing. You are assuming correctly. That limit was specifically introduced to protect against this attack and is specifically documented as such in https://www.php.net/manual/en/info.configuration.php#ini.max-input-vars: > Use of this directive mitigates the possibility of denial of service attacks which use hash collisions. It *might* be feasible to raise the default value nowadays, because of increased processing power moving the point where it "gets bad" further upwards. - But this also means that aborting the request would be just as effective at protecting such an attack as truncating. Yes. It might or might not be worse with regard to user experience, though (not that the truncating behavior is any good either). See also my reply to Jordan's email. Would aborting instead of truncating introduce any new attack surface? I don't see how that would add to the attack surface if implemented correctly. The only thing I could think of would be a DoS vector, but I believe there are a lot of ways you can get a server to instantly abort your request... If you are only able to abort processing of your own request, then it's not even a DoS vector, as you don't affect other users and processing a regular request certainly is going to be more expensive on the server (database connections and similar) compared to aborting before your script starts executing. Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Error behaviour for max_input_vars
On 14 September 2022 21:39:36 CEST, "Tim Düsterhus" wrote: >Hi > >On 9/13/22 19:58, Mel Dafert wrote: >> - Deciding that `max_input_vars` is not relevant anymore and should be >> handled by the likes of Apache and NGINX, thus changing the default to >> `0` and removing the setting >> over a deprecation period. > >This would be my preferred option, but my understanding is that the limit >still is relevant to protect against attacks on the hash table implementation. >The web server can't really protect against this type of attack, because the >payload required to execute the attack is fairly small. Protecting against the >attack without some arbitrary cut-off limit would require making the hash >algorithm used for the superglobals dependent on a randomly generated >per-request seed value. I can't comment on how easy or hard that would be to >change, but I believe that this should be the ultimate goal here. It's also >what other programming languages do. > >Best regards >Tim Düsterhus Thank you, this makes a lot of sense to me. I assume that this rules out that option, at least for now, unless someone makes the relevant changes to the hashing. But this also means that aborting the request would be just as effective at protecting such an attack as truncating. Would aborting instead of truncating introduce any new attack surface? The only thing I could think of would be a DoS vector, but I believe there are a lot of ways you can get a server to instantly abort your request... Regards, Mel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Error behaviour for max_input_vars
Hi On 9/14/22 21:38, Jordan LeDoux wrote: the ML, since I'm not suggesting there is a problem, I'm mostly just wondering if someone with more expertise can confirm that it isn't an issue. As indicated by the phrasing in my previous email, this knowledge does not enable an attacker to do anything that they wouldn't be able to do otherwise. I would also expect that at least the value of the INI setting is going to be the default value of 1000 for the vast majority of installations out there. This is primarily an issue of user experience: A user's input data might not be correctly processed without the user or the PHP application being aware of it. This incorrect processing might have security implications, e.g. when an application uses checkboxes to remove users from a group with elevated permissions, the admin checks more than 1000 users and the application does not remove the excess users from the group, despite the user making extra sure to double check that they checked all the users. Thus to answer Larry's question, a reasonable action the script could take is: Show a non-technical well-styled error message to the human, instead of aborting the request with a 500 or silently causing "data corruption". Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Error behaviour for max_input_vars
Hi On 9/13/22 19:58, Mel Dafert wrote: - Deciding that `max_input_vars` is not relevant anymore and should be handled by the likes of Apache and NGINX, thus changing the default to `0` and removing the setting over a deprecation period. This would be my preferred option, but my understanding is that the limit still is relevant to protect against attacks on the hash table implementation. The web server can't really protect against this type of attack, because the payload required to execute the attack is fairly small. Protecting against the attack without some arbitrary cut-off limit would require making the hash algorithm used for the superglobals dependent on a randomly generated per-request seed value. I can't comment on how easy or hard that would be to change, but I believe that this should be the ultimate goal here. It's also what other programming languages do. Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Error behaviour for max_input_vars
On Wed, Sep 14, 2022 at 12:33 PM Tim Düsterhus wrote: > Hi > > On 9/14/22 20:44, Jordan LeDoux wrote: > > Honestly, another question I'm thinking about at the moment is whether > it's > > possible to construct an attack against known script behavior if you also > > are able to determine the ini config at which partial form data would > make > > it to the script with the script thinking it has full form data. To be > > clear, I haven't been able to think of one, but I also recognize that I'm > > not nearly as clever at those sorts of things as some attackers are. > > Maybe I misunderstood what you are thinking about, but can't you just … > not send all the fields to achieve exactly the same results as an attacker? > > Best regards > Tim Düsterhus > Yes, probably. That's why I was saying, I know I'm not as clever with that space. I think those would be equivalent cases, but I'm not sure if there are any edgecases there either. Maybe that thought wasn't appropriate for the ML, since I'm not suggesting there is a problem, I'm mostly just wondering if someone with more expertise can confirm that it isn't an issue. Jordan
Re: [PHP-DEV] Error behaviour for max_input_vars
Hi On 9/14/22 20:44, Jordan LeDoux wrote: Honestly, another question I'm thinking about at the moment is whether it's possible to construct an attack against known script behavior if you also are able to determine the ini config at which partial form data would make it to the script with the script thinking it has full form data. To be clear, I haven't been able to think of one, but I also recognize that I'm not nearly as clever at those sorts of things as some attackers are. Maybe I misunderstood what you are thinking about, but can't you just … not send all the fields to achieve exactly the same results as an attacker? Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Error behaviour for max_input_vars
On Wed, Sep 14, 2022 at 11:38 AM Larry Garfield wrote: > > I think the key question here is if there is a reasonable action the > developer could take if an over-sized request came in. PHP itself can dump > that to the log, but is there anything reasonable beyond that the developer > could do, if they could detect it? > > And is anyone doing that now? > > --Larry Garfield > > Honestly, another question I'm thinking about at the moment is whether it's possible to construct an attack against known script behavior if you also are able to determine the ini config at which partial form data would make it to the script with the script thinking it has full form data. To be clear, I haven't been able to think of one, but I also recognize that I'm not nearly as clever at those sorts of things as some attackers are. I suppose that would depend on both the form and the script though. Jordan
Re: [PHP-DEV] Error behaviour for max_input_vars
On Wed, Sep 14, 2022, at 12:07 PM, Mel Dafert wrote: > On 14 September 2022 16:44:33 CEST, Thomas Nunninger > wrote: >>Hi, >> >>> In summary, I believe this can only be solved inside of PHP itself, by >>> allowing to configure a way for `max_input_vars` to abort the request >>> instead of truncating the input. >>> The options I see feasible are: >>> - A new ini setting `max_input_vars_abort` (default to 0), which, if set to >>> 1, will abort the request if there are more input variables than allowed. >>> - A method to reliably detect whether the input vars were truncated (eg. >>> `function has_post_been_truncated(): bool`), so the application can decide >>> whether to abort or not. >>> - Deciding that `max_input_vars` is not relevant anymore and should be >>> handled by the likes of Apache and NGINX, thus changing the default to `0` >>> and removing the setting >>> over a deprecation period. >>> >>> I am leaning towards the first option, but would be open to either outcome. >> >>I'd prefer that PHP aborts such requests. Then data loss/inconsistency is >>prevented for everybody and people can fix their applications. (So no need >>for an ini setting that allows acting in "danger mode".) >> >>If you'd like to give developers more options to choose from, I'd go for >>max_input_vars_abort (default 1) plus has_post_been_truncated(): That way the >>behavior is safe from the start. And people who opt in for "danger mode" can >>reliably detect if there was some data loss and can deal with it. >> >>Regards >>Thomas >> > > That's a fourth option that I had overlooked: Just changing the > behaviour to always abort, without the option to truncate. > This would certainly be acceptable to me. > Is there anyone relying on the truncating behavior? It's hard for me to > imagine such a situation. > This question also determines whether this would be acceptable to go > into 8.3, or if we would need to wait for 9. Is something like this > considered a breaking change? > > This reasoning would also affect your second proposal - changing the > default is similarly a breaking change if there are people relying on > it, albeit a little easier to fix. > > If people think it would be okay, then I would strongly prefer option > 4, as then there's no need for bikeshedding on ini settings or new > global functions. > > Regards, > Mel I think the key question here is if there is a reasonable action the developer could take if an over-sized request came in. PHP itself can dump that to the log, but is there anything reasonable beyond that the developer could do, if they could detect it? And is anyone doing that now? --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Poll] Asymmetric Visibility and Accessor syntax
On Sat, Sep 3, 2022, at 5:38 PM, Larry Garfield wrote: > In case some people didn't see it in the previous thread, I am bumping > this poll: > > https://docs.google.com/forms/d/e/1FAIpQLSefq15VvGNIXSnQaMTl3RW451w0E8oesny8c4PLqmKl8HhQ-Q/viewform > > This is an informal poll on behalf of Ilija and I to determine the > syntax pattern we end up using for both Asymmetric Visibility and > Property accessor hooks. We in particular want to get feedback from > RFC voters, because as we all know "discussion on the list" is > frequently highly unrepresentative of the actual voter sentiment, and > finding out "I like the idea just not that particular syntax" after a > vote fails, well, sucks for everyone. > > If you are planning to vote at all on either RFC, please take a few > moments to read the question being asked and give us feedback so we can > produce something acceptable to the broadest number of people. Hi folks. I've now closed the previous poll regarding asymmetric visibility and have some results. Total responses: 33 Voter responses: 11 ## Question 1 This question asked people to scale-rate between Swift-style (1) and C# style (7). The final counts were: 1: 6 2: 7 3: 4 4: 4 5: 3 6: 3 7: 6 Which roughly translates as "opinions are very split and all over the map, *but* there is a notable lean toward Swift-style." In particular, there were 13 "Strongly or very strongly Swift" responses to 9 "Strongly or very strongly C#" responses, and the middle responses also leaned slightly Swift-style. Looking at the text responses people gave (thanks!), there were a sizable number of supporters of either model that said it "just felt better" or "feels more natural" for subjective reasons. Much of the C# support came from the fact that more PHP developers seem to also have C# experience than Swift experience, so there was simply a familiarity question at play. (Which is relevant, to be clear.) Among the non-feel comments, most were critical of the added user-facing complexity of C# style in PHP (because of references), and therefore favored Swift. If we restrict the results to just people with voting access, we get an average rating of 3.909, or almost a perfect tie. (Figures.) Based on the above, Ilija and I plan to continue on with Swift-style syntax. Although it is not universally preferred, it does seem to have somewhat stronger support and more cleanly separates the two features syntactically, as they are orthogonal to each other. ## Question 2 The next question was what syntax to use for the set-visibility, which was conducted with an RCV model. I computed the results using a slightly modified version of Derick's counter that is used for RFC votes. (I just tweaked it to take in data from the Google Form rather than the Wiki's output format. The counting engine is unchanged.) I was really surprised at the results. In the first round, `private(set)` had a plurality lead over `public(set: private)` in second place: Candidate 'private(set)': 12 → 1 2 4 8 12 13 22 25 27 28 29 30 Candidate '(set: private)': 9 → 3 10 17 19 20 21 24 26 31 Candidate 'public private': 5 → 7 9 14 16 23 Candidate 'private:set': 3 → 0 5 6 Candidate 'public:private': 3 → 11 15 18 I really expected `private:set` to do better, given how many people seemed to be anti-parentheses, yet the top two responses were the ones with parentheses. From examining the votes, `public(set: private)` was very much a "love it or hate it" response. The rest of the rounds confirmed the same results: Round 2: Candidate 'private(set)': 12 → 1 2 4 8 12 13 22 25 27 28 29 30 Candidate '(set: private)': 9 → 3 10 17 19 20 21 24 26 31 Candidate 'public private': 6 → 7 9 14 16 23 15 Candidate 'private:set': 5 → 0 5 6 11 18 Round 3: Candidate 'private(set)': 13 → 1 2 4 8 12 13 22 25 27 28 29 30 6 Candidate '(set: private)': 11 → 3 10 17 19 20 21 24 26 31 5 18 Candidate 'public private': 8 → 7 9 14 16 23 15 0 11 Round 4: Candidate 'private(set)': 20 → 1 2 4 8 12 13 22 25 27 28 29 30 6 7 9 14 16 15 0 11 Candidate '(set: private)': 12 → 3 10 17 19 20 21 24 26 31 5 18 23 And so the consensus result is indeed `private(set)`, much to my surprise. Running the count on just voters gave the same end result. Looking at the comments, there were again a plethora of entirely subjective responses supporting, well, everything. Several people did note that the explicit options (that had the word `set` in them somewhere) were better, because explicitness, and because it allows them to be abbreviated and/or used in an arbitrary order. We are therefore going to proceed with `public private(set)`, the same syntax as Swift and the current RFC text use. Thank you everyone for your participation. The results clearly show that not everyone is going to be happy with the outcome no matter what, but I hope that going through this poll and sharing this level of transparency ensures that at least most people feel heard
Re: [PHP-DEV] RFC: StreamWrapper Support for glob()
Hi Timmy, Good suggestion. This seems like a no brainer, and definitely good to add streams support for glob filepaths. You're right, we currently have to work around this in userland. Your code example workaround is super ugly :) I'm intersted to know, from others, if there are deeper technical reasons why this wouldn't be a good idea, because I'm not it Unless my memory is wrong, Sara was heavily involved in the initial streams API, and might be good to see what she thinks too, from an implementation POV :) Many thanks, Paul On Wed, 14 Sep 2022, 17:59 Timmy Almroth, wrote: > Hello everyone. I would like to announce that the RFC for "StreamWrapper > Support for glob()" is now ready for Discussion. > > RFC > https://wiki.php.net/rfc/glob_streamwrapper_support > > Feature Request and Discussions > https://github.com/php/php-src/issues/9224 > > Regards, > > Tim >
Re: [PHP-DEV] Error behaviour for max_input_vars
On 14 September 2022 16:44:33 CEST, Thomas Nunninger wrote: >Hi, > >> In summary, I believe this can only be solved inside of PHP itself, by >> allowing to configure a way for `max_input_vars` to abort the request >> instead of truncating the input. >> The options I see feasible are: >> - A new ini setting `max_input_vars_abort` (default to 0), which, if set to >> 1, will abort the request if there are more input variables than allowed. >> - A method to reliably detect whether the input vars were truncated (eg. >> `function has_post_been_truncated(): bool`), so the application can decide >> whether to abort or not. >> - Deciding that `max_input_vars` is not relevant anymore and should be >> handled by the likes of Apache and NGINX, thus changing the default to `0` >> and removing the setting >> over a deprecation period. >> >> I am leaning towards the first option, but would be open to either outcome. > >I'd prefer that PHP aborts such requests. Then data loss/inconsistency is >prevented for everybody and people can fix their applications. (So no need for >an ini setting that allows acting in "danger mode".) > >If you'd like to give developers more options to choose from, I'd go for >max_input_vars_abort (default 1) plus has_post_been_truncated(): That way the >behavior is safe from the start. And people who opt in for "danger mode" can >reliably detect if there was some data loss and can deal with it. > >Regards >Thomas > That's a fourth option that I had overlooked: Just changing the behaviour to always abort, without the option to truncate. This would certainly be acceptable to me. Is there anyone relying on the truncating behavior? It's hard for me to imagine such a situation. This question also determines whether this would be acceptable to go into 8.3, or if we would need to wait for 9. Is something like this considered a breaking change? This reasoning would also affect your second proposal - changing the default is similarly a breaking change if there are people relying on it, albeit a little easier to fix. If people think it would be okay, then I would strongly prefer option 4, as then there's no need for bikeshedding on ini settings or new global functions. Regards, Mel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] RFC: StreamWrapper Support for glob()
Hello everyone. I would like to announce that the RFC for "StreamWrapper Support for glob()" is now ready for Discussion. RFC https://wiki.php.net/rfc/glob_streamwrapper_support Feature Request and Discussions https://github.com/php/php-src/issues/9224 Regards, Tim
Re: [PHP-DEV] Error behaviour for max_input_vars
On Tue, Sep 13, 2022 at 4:01 PM Derick Rethans wrote: > On 13 September 2022 19:36:15 BST, juan carlos morales < > dev.juan.mora...@gmail.com> wrote: > >El mar., 13 de septiembre de 2022 15:33, juan carlos morales < > >dev.juan.mora...@gmail.com> escribió: > > > >> > >> > >> El mar., 13 de septiembre de 2022 14:58, Mel Dafert > >> escribió: > >> > >>> > >>> In summary, I believe this can only be solved inside of PHP itself, by > >>> allowing to configure a way for `max_input_vars` to abort the request > >>> instead of truncating the input. > >>> The options I see feasible are: > >>> - A new ini setting `max_input_vars_abort` (default to 0), which, if > set > >>> to 1, will abort the request if there are more input variables than > >>> allowed. > >>> - A method to reliably detect whether the input vars were truncated > (eg. > >>> `function has_post_been_truncated(): bool`), so the application can > >>> decide whether to abort or not. > >>> - Deciding that `max_input_vars` is not relevant anymore and should be > >>> handled by the likes of Apache and NGINX, thus changing the default to > >>> `0` and removing the setting > >>> over a deprecation period. > >>> > >>> I am leaning towards the first option, but would be open to either > >>> outcome. > >>> > >> > >> > >> We should not delete the ini setting "max_input_vars"... Is a breaking > >> change very hard. > >> > >> I Am in favour of adding More flexibility about how to handle this > >> situation... And I also think that options 1 and 2 can coexist smoothly. > >> > >> I suggest you write and RFC for this and continue the discussion on this > >> e-mail list but with the RFC already created. > >> > > > > > >Check this out > > > >https://wiki.php.net/rfc/howto > > That's quite a condescending thing to say, considering that Mel has > already successfully passed an RFC ( > https://wiki.php.net/rfc/intldatetimepatterngenerator). > > cheers > Derick > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > I didn't know that either! That also makes my comment about version inclusion a bit condescending. Sorry Mel! Jordan
Re: [PHP-DEV] Error behaviour for max_input_vars
Hi, In summary, I believe this can only be solved inside of PHP itself, by allowing to configure a way for `max_input_vars` to abort the request instead of truncating the input. The options I see feasible are: - A new ini setting `max_input_vars_abort` (default to 0), which, if set to 1, will abort the request if there are more input variables than allowed. - A method to reliably detect whether the input vars were truncated (eg. `function has_post_been_truncated(): bool`), so the application can decide whether to abort or not. - Deciding that `max_input_vars` is not relevant anymore and should be handled by the likes of Apache and NGINX, thus changing the default to `0` and removing the setting over a deprecation period. I am leaning towards the first option, but would be open to either outcome. I'd prefer that PHP aborts such requests. Then data loss/inconsistency is prevented for everybody and people can fix their applications. (So no need for an ini setting that allows acting in "danger mode".) If you'd like to give developers more options to choose from, I'd go for max_input_vars_abort (default 1) plus has_post_been_truncated(): That way the behavior is safe from the start. And people who opt in for "danger mode" can reliably detect if there was some data loss and can deal with it. Regards Thomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Error behaviour for max_input_vars
Hello, Le mardi 13 septembre 2022, 19:58:42 CEST Mel Dafert a écrit : > Hi internals, > > I recently ran into issues with the ini setting `max_input_vars`. > By default, it will truncate input variables in `$_POST` etc. to the > first 1000, and issue a E_WARNING. I also ran into this a few years ago and it is really annoying. I agree we need a reliable way of catching this error. > In summary, I believe this can only be solved inside of PHP itself, by > allowing to configure a way for `max_input_vars` to abort the request > instead of truncating the input. > The options I see feasible are: > - A new ini setting `max_input_vars_abort` (default to 0), which, if set > to 1, will abort the request if there are more input variables than allowed. > - A method to reliably detect whether the input vars were truncated (eg. > `function has_post_been_truncated(): bool`), so the application can decide > whether to abort or not. > - Deciding that `max_input_vars` is not relevant anymore and should be > handled by the likes of Apache and NGINX, thus changing the default to > `0` and removing the setting > over a deprecation period. All 3 solutions seems a nice improvement from current situation. Côme signature.asc Description: This is a digitally signed message part.
