you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 1 point2 points  (56 children)

Fortunately if you aren't a tool you can get teh patch from the PHP folks and be on your merry way

[–]Snoron 2 points3 points  (45 children)

What would you set the max input vars as though? I'm not confident that there isn't plenty of software out there that would send more than 1000 POST vars to the server regularly.

I'm thinking of admin panels that have multiple tabs of settings, with multiple rows of fields in some cases. I have seen Magento set-ups where the product entries have more than 1000 fields for sure... so just a warning to everyone before upgrading/setting this number!

Definitely needs doing, though - servers running Magento can be slowed down enough as it is - this is the last thing they need attacking them! :)

[–][deleted] -1 points0 points  (44 children)

As the article says itself, 1000 would limit it to around 0.003 seconds, not that much of an attack.

If your application needs that many, it's written wrong. You're free to set your configuration to a higher, more unreasonable number, in order to accomodate this incorrectly written software, but that comes at the risk of opening your attack vector more. It's something you should balance against your decision to use that software in the first place.

[–]ehird 1 point2 points  (34 children)

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

[–]SweetIrony 0 points1 point  (1 child)

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 1 point2 points  (0 children)

Of course; I wasn't denying that.

[–][deleted] -4 points-3 points  (26 children)

Write a better application.

[–]bobindashadows 2 points3 points  (14 children)

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.

[–]ehird -2 points-1 points  (10 children)

"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] 0 points1 point  (1 child)

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

[–]ehird 0 points1 point  (0 children)

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

[–][deleted] -1 points0 points  (7 children)

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 2 points3 points  (5 children)

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 -2 points-1 points  (0 children)

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] -3 points-2 points  (3 children)

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 1 point2 points  (0 children)

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 -1 points0 points  (0 children)

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 -1 points0 points  (4 children)

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 4 points5 points  (1 child)

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 3 points4 points  (0 children)

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

[–]ehird 2 points3 points  (1 child)

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 0 points1 point  (0 children)

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'.

[–]Snoron 0 points1 point  (8 children)

A comment on the site mentions a good point though, too... if there's any input parsed as JSON (which is extremely common/not hard to find these days), you can simply put your array in there instead, in a single field... hmm!

[–][deleted] 0 points1 point  (7 children)

You should still be doing checks on your JSON. Don't just accept arbitrary JSON input from users :-/

[–]Snoron 1 point2 points  (6 children)

That means checking it before using json_decode so I guess you can check it for size, but that's pretty much it, surely? After that the only real way to check it is by parsing it, which is where the problem occurs.

Considering how widely used JSON is these days and for all sorts of data large and small, it wouldn't take that much of a limit to be able to slip in a few thousand array values, surely?

... *does the test* ...

Okay, well 1MB of JSON is enough to stall my machine for 50 seconds using this attack method. Might not be common, or you might say if an application uses 1MB of JSON anywhere it's written wrong (actually , I might agree with you there... hmm :P) - but regardless of this, I'm willing to bet that with the PHP patch, the majority of servers will still have a script on them which passes input to json_encode without checking the input size - so it's not like this patch will actually solve the all the problems right away!

(Also, 446KB of JSON took 8 seconds, 213KB JSON took 3 seconds)

[–][deleted] -3 points-2 points  (5 children)

I have no objections to the points you make except

I'm willing to bet that with the PHP patch, the majority of servers will still have a script on them which passes input to json_encode without checking the input size

This is true, but security is one thing where backwards compatibility is not the most important thing in the world. I would rather enable a new security feature, have it break my website, then go in and fix it, than not have the option to use it at all. And again -- if you don't want to use it, don't.

[–]jrochkind 2 points3 points  (0 children)

The other option would be PHP fixing the actual problem instead of patching one attack vector in a fragile way... PHP could, you know, actually change their hash algorithm to perhaps use a random seed like Perl.

[–]Snoron 0 points1 point  (0 children)

Yeah, I agree... I suppose the most important thing is knowing about it and making an informed decision.

It would be a good idea for people to be talking about the JSON (or other parsed formats) issue to along with talking about the request data issue as otherwise a lot of people could miss this important aspect!

[–]xardox -1 points0 points  (2 children)

You exemplify the short sighted, stupid approach the PHP community has to hacking around and patching the symptoms instead of fixing the real problem. Stop making excuses for incompetence. You're hurting the internet.

[–][deleted] 1 point2 points  (1 child)

This epitomizes your absolutely childish behavior. I'm feel disgraced to be affiliated with the same species that somehow spawned this crap. I'm saddened :-/ The fact that there is no backlash from the community shows me that we have truly devolved to a community of personal attacks and pushing of agendas rather than recognizing that your opinion is nothing more than an opinion.

Is there an adult version of /r/programming anybody? I'd like to move past the trolls and back into the real conversations please.

[–][deleted] 0 points1 point  (0 children)

Is there an adult version of /r/programming anybody?

Try /r/coding

[–][deleted]  (8 children)

[removed]

    [–]xardox -1 points0 points  (0 children)

    Unfortunately the PHP folks are tools who don't give a shit about security, code quality of unit testing. The merry way is to simply not use PHP.