as i already mentioned in this post some time ago,
arbitrary data can be stored in the serialized data field of the user table.
example:
go to my account, save the page local, edit it to send the "post" data to the website and edit an form name to edit[somethingnew] und press save
-> $somethingnew will be saved serialized in the data field
i think the fault is in user_edit (on line 1145) where user_save() is called without checking $edit completely.
however, i 've felt like that's known and tolerated, so i did, the a little bit missunderstood, post above first.
but i think, it's not acceptable to save just everything, what is coming in with the form data... what's if a bad guy saves 1GB of nonesense in my database? furthermore it will be loaded into the memory everytime user_save is called - seems to me to be a nice possibilty for a DOS.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | saveform_0.patch | 4.52 KB | fago |
| #3 | saveform.patch | 4.38 KB | fago |
Comments
Comment #1
moshe weitzman commentedi think apache/php have limits on how much can be posted. if you are worried, perhaps use those settings.
Comment #2
fagoyes, but then it's still possible to inject data in little pieces by using a new name every time.
further you can't limit the size too much, because file uploading should also work.
Comment #3
fagoi've written a patch, so that $edit is checked before.
unfortunately i couldn't see a better method than introducing a new hook type for hook_user 'saveform' for which each module has to return an array of values, which it wants to be saved. as an affect some modules have to be changed to work correctly after applying this patch :(
my patch (for the 4.6 branch) includes the changes for profile.module and contact.module and for the user.module of course.
what do you think about this?
i think something like this is necessary.
consider a module, which introduces profile fields, which can only be edited by administrative users.
and yes of course, i don't like it, if users are able to fill up there user object with additional variables ;)
Comment #4
fagounfortunately i noticed some mistakes in the previous patch.
(module_invoke doesn't reference $edit, but then i patched profile.module to use the saveform hook for saving.)
i've attached a new patch.
Comment #5
killes@www.drop.org commentedWe are currently addressing this issue through a more general rewrite of the form subsystem. For discussion about it see here:
http://lists.drupal.org/archives/drupal-devel/2005-06/msg00091.html
Comment #6
Steve Dondley commentedSuperseded by new forms API