For security purposes, I have not fully quote everything in this post, but have made a few quick comments. Generally it is best to send security notices directly to the software creator, to give them a chance to fix things before it goes public. But special thanks to Danny for helping us highlight these problems, and a more serious problem I was alerted to offlist.
On Tue, Dec 29, 2009 at 7:09 AM, Danny <[email protected]> wrote: > PART 2 > ------------------------------------------ > > 1) Above all, the login command has an auto value that enables a > member to login without checking password. This is true, but of course only a trusted "editor" could take advantage of this. should probably be relegated to a plugin than the core as it does weaken security. I suspect this feature will be removed in the next release. Let me know if you are using it and I will generate a plugin of some sort. I think I use it on one of my sites, so I will probably have to do this anyway. > 2) When saving data via a form, the system does not properly check > auth.data In my test this seems to work either way. If I am mistaken, send me an offlist email with more specifics. > 3) Another leak is that saving a multi-line data is available Ok this is fixed. > Besides, only the first line of a multiline data will be stored in > the index. This does not make security concerns but just annoying. > Thus this problem should be investigated further. This is intentional--to keep the index size to a minimum. So it basically does not fully index multiline data values. Thinking more, I wonder if we should even have multiline data variables? Shouldn't they be saved as a separate page, or an anchored section or something? What would happen if we limited all data variables to one line? > 4) To improve the security and to prevent the users from > accidentally or intentionally sending commands by [text] or other non- > [session] form fields, I modified several lines in markups.php and > engine.php. Now, only [session] would be regarded as commands, and any > form fields with duplicated name will be ignored. For example: > > [form][text msg_1 'test'][text msg_2 'test2'][submit][session msg_1 > 'blah'][form] This was actually on my to do list for this very round of releases. I have not done it yet for time constraints, and because the biggest problem is going to be checking and likely updating all existing forms in BoltWire. But, as it is on the to do list, if you could send me your patches it will save me some time when we do make the switch. Soon. > 5) Also, the Crypt plugin in the solutions of official site adds a > new group called "change_password". I think if you look at the code, it only adds that capability if 1) they are editing their own profile page, and 2) you specifically enable that group to change passwords in your site auth system. So it does not open any security vulnerabilities unless you choose to open them. Email me offlist if I am missing something here. Also, I'm not opposed to discussing plugins (esp for security) but plugins are always use at your own risk. Of course BoltWire is too for that matter. But we try! :) > 2. I don't know if locking superadmins in auth.commands/functions is > what you meant to. But this is dangerous if someone creates a > site.auth.commands without setting something like *: @admin, and he > locks himself from the site. Also, if no group.* pages exists, > superadmins are not considered to be in group admin and editor so that > they cannot pass the auth check of *: @admin. I've just fixed the commands/function auth system so it works independently of the user id. So perhaps your comments no longer are valid. Actually, looking at BOLTauth again, shouldn't the third line read like this: if (strpos(" ,$BOLTadmin,", ",$BOLTid,") && $BOLTadmin != '') return true; With BOLTid rather than $find? I've just made that change. Let me know if I missed something. > Anyway, I modified BOLTFmemberships in functions.php so that > superadmins always have admin,editor,member,guest memberships. It > would be more resonable, I think. Discussed in other post. I do not generally thing this is necessary. > 3. Fixed a missense line in initialization routine in engine.php so > that config blackList works correctly without whitelist set: > > old: if ($BOLTwhiteList != '' && strpos(BOLTloadpage > ($BOLTblackList), $BOLTvar['$ip']) !== false) {print_r > ($IPblockedHTML);die();} > new: if ($BOLTblackList != '' && strpos(BOLTloadpage > ($BOLTblackList), $BOLTvar['$ip']) !== false) {print_r > ($IPblockedHTML);die();} Thanks! Fixed... > However I still think it's not good to write it this way, which may > lock the superadmin himself. Good point. Seems the easiest way is to wrap the whole little routine in if (BOLTingroup('admin') === false) { } > 4. Fixed a missense line in markup so that /* */ do not delete a > following char after it. Thanks! I had noticed that. Appreicate you fixing it. > 5. Fixed a missense in system page action.search so that it shows the > last query input after submitting the form. I also simplified the > param name from myquery to q. Actually I am planning to fix this a different way. The idea is to keep the query cached for speed. But keep it connected to a specific user and page. > 6. Added a BOLTescape to BOLTMstyles so that <a href="http:// > www.google.com.tw">something</a> no more displayed mistakingly: > > if (! isset($args['href'])) $args['href'] = $args[1]; > $args['href'] = BOLTescape($args['href'],false); //added Thank you! > 7. Modified search functions BOLTcheckNest1 - 3 to allow several > complicated searching patterns: > > 1) with '(' started: (aaa && bbb) || ccc > 2) with ')' ended: aaa && bbb))) > 3) multi-bracket: ((aaa && bbb)) > 4) space-seperated (it ought to be but there's a missense bug): aaa > bbb ccc Please share your fixes. I thought this was mostly working but perhaps I've missed something. Your example 2 doesn't make sense to me. I'm not sure 3 is needed. > However I think the alogrithm could be more improved, such as > loading index as a cache instead loading for each matching word, and > to allow a pattern like "aaa && bbb || ccc" with 'or' prior than 'and' > or so... Agreed. As soon as you share the changes you made, I'll change the code to cache the index. I'm doing that with a separate query system I've been developing and it definitely improves speed! > 8. Added more system messages to messages and language file. Please list? > 9. Changed code.script back to site.script and the related scripts. > Also fixed several missenses so that [(script)] works properly. What is currently wrong with the script function? > 10.Fixed a mistake of 3.3.2f while parsing [messages] before getting > zones so that function messages are not showed. I think function messages are supposed to be shown... > # OTHER NOTICES > > 1. Besides, I made one more mistake. I found that site.auth.commands/ > functions list pages with membergroup and/or available commands/ > functions. Very special huh? I have reworked this somewhat differently. > 2. The return value of Xvalidate seems unreasonable. I thought it > should be just like Xif. What do you mean? > 3. It seems unreasonable that Xrename multi-in and single-out, we > could not rename multi-pages into a single page could we? You can use page shortcuts. Of those, the only useful one is the # symbol I guess. You are correct, it might be simpler and clearer to use some kind of search routine as you have suggested, or a custom plugin for renaming multiple pages. We should delete this functionality, and keep the code simpler. Thanks again for all the great suggestions. I'll try and get a first release out with these changes later today. It may not be final, but we can at least clear some of these nice suggestions out. Cheers, Dan -- You received this message because you are subscribed to the Google Groups "BoltWire" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/boltwire?hl=en.
