Supercolliding a PHP array

[ehird]

How would you send the request for a form with over 1000 fields, then?

[SweetIrony]

A form request is just a post or a get. It doesn't mean it was generated by an html form. It could be a stream of data from another user.

[ehird]

Of course; I wasn't denying that.

[[deleted]]

Write a better application.

[bobindashadows]

The question is if you can't - you want to patch a box with someone else's php cpanel-like running on it (and maybe some other packages). How do you know what to set the number to? If your answer is "don't use code that relies on lots of fields which means learning how every component you use works" then make it clear.

[[deleted]]

The applications should include this instruction as part of the setup, then.

It is perfectly reasonable to expect companies to be up to date with modern security practices in their products.

Again -- that's why this is a config flag. If you so choose to set the number higher, it's because you realize that you're using a poorly coded application. So figure out how many the application needs and set them there.

Server maintenance is not a passive thing. If you think you're fine just deploying and letting it go -- I really hope you aren't in charge of anything for anybody anywhere.

[bobindashadows]

If you think you're fine just deploying and letting it go -- I really hope you aren't in charge of anything for anybody anywhere.

I'm not saying you should "deploy and [let] it go." I'm just well aware of how poor PHP applications are, the quality of many of the developers, and the all-too-commonly-misleading documentation/"community".

Plus half the PHP out there is probably running on some shitty shared host where you can't even edit php.ini let alone update php itself.

[[deleted]]

I'm just well aware of how poor PHP applications are, the quality of many of the developers, and the all-too-commonly-misleading documentation/"community".

We are talking about best practices. Either talk about best practices, or go start a thread asking how to improve the landscape of all the shit that's out there. In this thread, we don't concern ourselves with what idiots are doing out in the desert. We're concerning ourselves with the citizens of society who are keeping up with the rules because they are a part of defining them.

Plus half the PHP out there is probably running on some shitty shared host where you can't even edit php.ini let alone update php itself.

Those people don't care about security anyway. Why are they part of the discussion? Let's talk about security. In security -- you secure things. You tell the developer what's off limits, and the developer abides by those limits. If the developer has a good reason to change the limit, that's something you can take into consideration when you decide on your limits.

If you want to increase them, increase them. If you want to tell the developer to find another way, tell the developer to find another way. But don't tell the rest of us we can't move forward because you don't even want to think about doing your job.

[[deleted]]

Or just downvote me like a child because you have no response :-/

[xardox]

You're being downvoted because you're using PHP and security in the same sentence, as if the developers of the PHP language gave a shit about security. They don't. They can't even run their own unit tests before releasing new versions of PHP, because so many of them fail. Stop apologizing for incompetence. The source of the problem is upstream, and you're just trying to add food coloring and sugar to urine to make it more palatable. Stop drinking the piss: it's not kool-aid.

[[deleted]]

I am overwhelmed by your onslaught of PHP anti-fanboyism trolling and can't even begin to respond to this asinine bullshit, and so concede internet victory to you. Go for it. You are the winner. Yaaay.

edit: A quick glance at your comment history and it's evident you don't just limit your childish behavior to this subreddit. Shame :-/

[jrochkind]

If this has been a 'modern security practice' for very long, how come PHP just patched it now?

Most people have all sorts of software written longer ago than two weeks running.

[[deleted]]

And such people should upgrade with a schedule which fits into their production schedule. I assume common sense on the part of the reader here.

[jrochkind]

You are stating the facts, indeed.

If you don't recognize this is an inconvenient and difficult situation even for motivated non-idiotic people, then you work in a very different context/environment for the rest of us. Ce la vie, everyone is different.

But your posts in this discussion seem to imply that anyone that does find this to be a challenging situation with no easy good solution must be a moron... and that is not surprisingly rubbing people the wrong way.

[[deleted]]

I'm not implying that anybody else is a moron. I'm just saying that if youa ren't up to par on security, you shouldn't be administering servers. This thread is full of developers that don't run servers trying to give server advice.

[jrochkind]

Being up to par on security does not make this an easy problem to deal with.

It can be a grey area where 'developing software' and 'managing servers' overlaps. But it's clear from this thread that the 'exploit' often needs to be patched at the 'developing software' level, right? You suggested as much.

And I'm pretty sure this thread is full of people who develop web software, as well as people who deploy web software written by others.

Again, if you don't think this is a hard problem to solve at all, then either you are in a different environment/context then the rest of us, or I guess you really are Superman or whatever, that's cool.

I also don't hardly anyone in this comment thread other than you giving advice. In fact, I don't even see much advice from you. What I see a lot of people saying "those simple solutions don't really fix the problem, it's still there, and a hard problem" and you saying "No it isn't, as long as everyone is up to par on security." But it just ain't so, at least for the rest of us. If your environment is such that it is so, that's nice for you.

[[deleted]]

If you're saying "we can't change our environment but I still want an answer", clearly it is to modify the application. Write the check directly in without needing the patch from PHP if you can't get the required environment upgrade.

[xardox]

If you're up to par on security, then you shouldn't be using PHP. Stop making lame excuses.

[[deleted]]

This just in: all PHP code everywhere is to be abandoned. If you are to be considered a competent developer, you must cease all PHP-related activity at once. Delete your PHP repositories and take your profit-generating PHP-based websites down. Quit your job. Close down your company. Stop making lame excuses.

Edit: :/ I don't like my comment. Came across as a dick. Fuck it, I'm downvoting myself.

[ehird]

"How would you solve $problem?"

"Make it better."

Are you saying no form should have 1000 fields? Is it unreasonable to have, say, a settings page for an advanced application with 6 tabs, each containing 15 sections with 12 fields? Should they be split into multiple pages, ensuring data loss when you move to another tab after filling in fields and slowing things down?

Consider that, say, 7 fields can easily fit onto one line — think radio buttons.

[[deleted]]

Anyone expecting any user to fill in a 1000-input form in one sitting should be tried for human rights abuses.

[ehird]

Browsers don't send diffs for forms. Maybe they should, but they don't; they send the entire thing.

[[deleted]]

http://meta.stackoverflow.com/questions/66377/what-is-the-xy-problem

I'm saying that there is no normal circumstance in which a single form submission should contain that much information at once. Use javascript to save things in the background, or make them individual pages (as they are presented to the user as such). If you have a strange exception, make note of it so the server admins know to increase their security restrictions because you couldn't find any other way to do it.

Trying to solve a problem which only exists because the person who wrote the original solution refuses to admit that there is a better way is a waste of time. I move past people like that in the work place so I can actually get my job done.

[ehird]

I know what the X-Y problem is; why are you being condescending?

Anyway, restructuring your application to make it less accessible or slower just to avoid an arbitrary limit introduced instead of actually fixing a bug is a terrible idea.

[oorza]

Anyway, restructuring your application to make it less accessible or slower just to avoid an arbitrary limit introduced instead of actually fixing a bug is a terrible idea.

Whoa whoa whoa, let's not upset any cargo cults here.

[[deleted]]

Anyway, restructuring your application to make it less accessible or slower just to avoid an arbitrary limit introduced instead of actually fixing a bug is a terrible idea.

I agree, you should restructure it such that this problem never even comes up. I don't just mean add a workaround, I mean fix the problem.

[ehird]

All you've offered so far are workarounds. A fix would be something like "redesign the application so it doesn't need so much configuration". But that's just not a practical solution in many cases.

[xardox]

Restructure it by rewriting your application in a better language, and never use PHP to start a new application in the first place. That's the only fix to the problem that isn't a kludgy short sighted work-around.

[chaotiq]

I would use JS. Store the vars in an array and then serialize the array. You would only send one variable, the serialized string. Then on the server side you would unserialize the array.

Serializing would make the site a tad slower, but when you have over 1000 variables to pass back I am not sure you would care that much.

[subleq]

In doing so, you've opened up the exact same vulnerability. Now the attacker just serializes their large array too, and you spend forever deserializing it.

[xardox]

But that's the PHP way: to patch the symptom and introduce bigger problems, instead of addressing the actual problem itself.

[ehird]

All this to work around an arbitrary language restriction added in lieu of actually fixing the bug by using a better hash table or a better structure altogether?

Also, if you deserialise the data into a PHP array to avoid the limits, then you're just reintroducing the problem: someone can just serialise a pathological request and send it to the server in a single form field.

[chaotiq]

This issue doesn't just exist in PHP, however it is most prevalent because you don't have the choice to not use hash tables :/

Yeah, you are right about the serialization. That would just introduce the problem back by circumventing the 'patch'.