fast4god

I've been playing around with this quite awhile and hounding the php chat rooms with NULL success. I did discover that the problem only occurs on IE7, not Firefox. (Haven't tested all browsers). Getting rid of the ob_start and ob_end_flush prints it out properly, but does not disconnect the browser. Any help that could be give is much appreciated. Dan

Have been working on a support site for some software I've written. Would appreciate suggestions for how to make the site better. www.boltwire.com Cheers, Dan

I have the following code in my software, but when the output it displayed, the tail end of the page is cut off... No idea why... ob_start(); $out = BOLTmakepage(); $size = ob_get_length($out); header("Content-Type: text/html; charset=utf-8"); header("Content-Length: $size"); header("Connection: close"); print_r($out); ob_end_flush(); flush(); If I just replace all this with print_r(BOLTmakepage()); I get the proper page display. But then I can't get my browser to disconnect and start running my background functions. I'm wondering if this is a multi-byte issue? Thanks in advance for any help that can be given. Cheers, Dan

Hey, Tom Just a quick note to let you know I like this program. I adapted it and used it in my new wiki engine. http://www.fast.st/zapwiki/welcome/index.php?p=solution.1006 It seems to work great though as noted a couple posts up sometimes the results are a little erratic. Let me know if you make any improvements! Cheers, Dan

All right, great Source. Glad to hear it wasn't a vulnerability somewhere. BTW, I just added a really cool "in-wiki" chat engine. You can see a demo at the site (www.zapwiki.org). Along with the shopping cart. Maybe later today I'll add a new profanity filter. And with any luck, next week I'll make some progress on adding wikiwyg... It's coming along nicely, and I really appreciate your help. I hope to release version 1.0 here any day now. Maybe first thing next week. Cheers, Dan

Hi Source! Thanks again for taking a look... First, not sure what you mean by a vector. Can you explain the term? Second if you enter html code into a page it should escape it and show it as regular "harmless" html code. As long as the html is not executed--that would not be a problem. It just did what it's supposed to. Do your remember the page name? I couldn't find it. Third, you are right about the skins--if you have edit permissions you can change it very easily on the fly right within the wiki, and yes the skins are hierarchical. So code.user1.skin would apply to pages like user1, user1.test, and user1.test.alpha, etc. The hierarchical thing is actually very powerful. And it works the same with css, js, and other page zones. Even the action pages! If you edited the skin as the approved editor account ("demo"), all is ok. Editors are supposed to be trusted users. If you were able to edit it as a normal user, then there's either a major problem, or a security settings glitch somewhere. I assume you did it as "demo"... Correct? Cheers, Dan

Source, just wanted to REALLY thank you again! Your help has been invaluable!!! Just repaired this latest vulnerability (I believe) and a couple similar ones. Also did some escaping of ZAPwiki's data handling as a second level of protection, just to be safe. Appreciate your hard work. Let me know if there's anything more I can do to help you find additional holes. Cheers, Dan

Sorry Source--didn't see your post. Thanks for finding the XSS vuln. Fixed now. The logout has been working--unless perhaps you logged in with one of those invalid accounts...? If so that problem should now be fixed. As for the URL always the same, it's just cosmetic. Specially till I get a dedicated webserver account for ZAPwiki... In the mean time, use this URL instead: http://www.fast.st/zapwiki/demo/index.php Cheers, Dan

In one of the posts above, I mentioned I had blocked all but the "test" page group to members, but gave the demo account broad editor permissions. This was to allow the security protections to be checked at both levels... Now I have changed the settings again, allowing members to create pages just about anywhere, except for a "secure" page group, which is something of a challenge location (even to editors) to see if anyone can get something written there. I also changed the view permissions for site.auth.view and site.auth.write to allow you to see the actual system security settings, and try to blast through any of the prohibitions there... I noticed someone exploited a cross site scripting vulnerability in the main ZAPwiki site (not the demo site) which has now been cleaned up, I believe. Thanks, whoever it was! Finally, added filtering to the registration process to block invalid account names. I noticed several such accounts were created--apparently harmless, but now these are blocked from even being created. Thanks again for everyone who has taken a look. Every little bit has helped to make the software just a tad bit stronger! Cheers, Dan

Since beginning this thread I've released several nice upgrades and have the functionality just about where I want it. It also seems the various attacks I've been able to detect were all thwarted properly, so I'm assuming at least that the basic security stuff is in place too. Anyway, I'm planning to release this as 1.0 software first thing next week--so any last minute vulnerabilities, bugs, glitches you can find over the weekend would be greatly appreciated. Thanks again to all how who took the time to check out the software. Hope some folks find it useful! Cheers, Dan

1) Fixed the rename code to work properly with system pages. 2) Made messages global in the skin. Still configurable but much better for noob's to the software. 3) Fixed links to blocked pages. 4) Improved regex check for ugly links. 5) Fixed the edit action to check authorization before showing edit box. 6) Fixed the random function to avoid errors on bad input. 7) Fixed the weird redirect problem. Turns out it was triggering the table row markup. Fixed the forward to self loop. Updated the site (both ZAPwiki and demo), and released a new code upgrade. Shop is open again for new torture tests! Thanks again to all for your help... Cheers, Dan

Ok, Aeglos, just want to thank you again for spending some time at ZAPwiki, and for your feedback. Very helpful. 1) The first behavior was expected. You can only rename a page to a name that does not yet exist, and you only get messages when you have the [messages] directive on a page, so you would not necessarily get an alert that your renaming was denied. Just depends how the forms are set up. I should reset the site to have global messages. 2) The problem with the rename error message just needs a line to check when a page exists in the system folder rather than the local pages folder. I'll fix up the code for that. 3) The problem with the docs was not that it was protected (it wasn't), just that the default documentation is stored in the system folder, which gives the error you noticed. The nice thing is, to restore the site, you just delete all the local pages, and the system pages then pop back into place. Kind of neat. 4) Action.all is blocked to members, but not editors. That's also why the view link is disabled. I must figure out a better way to handle that... I also note the links get messed up in the action bar when the page is blockd. Another problem. Thanks! 5) That's a strange error message from the uglylink. I'll try and track that one down and somehow block it. Needs a better regex I guess for the links. 6) Your observation about being able to edit pages outside the test group is a good one. Not sure how or whether to fix, but I'll look into it. Basically, if you can view the page, you can call up the edit screen and prefill the source code. But if cannot write to it, your changes are ignored. I could check the write auth in the edit form to do this automatically without having to change the code. Also the create and new page forms. 7) I don't know any way to easily fix the math function, and may just have to trust editors to come up with valid expressions. No way to do a test on the eval function... Suggestions welcome. I'll add a pattern matching check to the random function to return blank if there's a problem in the input. The redirect problem is very weird. I'll look into that, but have no clue why it's happening. Thanks for spotting that. 9) Yes tables can mess up the display. As probably divs could also. Not sure how to fix it easily and may just have to rely on the editors to keep things clean. Again, suggestions welcome. 10) I'll fix the forward loop. Thanks! Good observation... Your experiments were extremely helpful! Just the kind of things I was looking for. Should keep me busy for the next couple hours! Cheers, Dan

Source: I noticed a page was created named index.php, but that was not the same file as the main index.php that calls the wiki engine. It is in a subdirectory called pages, and is therefore completely seperate. I noticed someone had created it... And the contents. But such pages are first escaped (so there's no valid php tags in there), seconds it's access protected (so it cannot be called), and third it's not executed (when loaded). So while you can put php code in a page, it will display like any other text, safely. If you know a way to edit the real index.php page that calls the engine, I would like to know how to do that, as it would be a MAJOR security flaw. And that is exactly the kind of flaw I'm hoping someone will point out... Or better, hope is not there! Aeglos: I'll get back to you post in a few hours when I get some time to analyze it more carefully... Appreciate both of you taking a good look at things... Cheers Dan

Sorry -- was away from my computer yesterday... But I appreciate the comment. First, I'm not sure what you meant by "in echo" but it is true, members can edit pages. Generally wiki's are open edit environments. The settings of course can be changed for any page or group of pages, limiting viewing or editing to any user or user group you desire. I only had editing of important system pages blocked. For testing purposes, however, I just changed the permissions on the ZAPwiki demo site so that members can now only edit pages in the test group, as in test.one or test.a.b.c. To login as a member, create your own account and use it. If you can edit any other page, that would now be a security flaw. Editors still have broad edit permissions, to give you a chance to tinker with other aspects of the code (like action forms, etc). Generally editors would be considered trusted users, so you CAN do damage with this to the demo site. But I'm allowing it as there's no other way to give you access to some of the things that really should be tested. You will have editor permissions if you login as demo/demo. I was surprized someone tried to hack in a script that would have deleted my entire site directory. I think doing something like print_r("You've been hacked"); would have been sufficient... Fortunately, ZAPwiki was secure on at least three levels against that particular attack. Finally, while I'm not much of a security expert, it seems ZAPwiki is holding up thus far against the various attacks people have tried. If no one can spot anything else, I guess I'll consider releasing it some time this week as an official beta. Thanks to all who have taken a peek. Cheers, Dan

Stealth, it looks like you have been tinkering with the site. I see your tracks in my log file... : ) Any success finding holes, or does it seem to pass at least your initial inspection? Thanks! Cheers, Dan

Ok, good idea. I just created an account with user name "demo" and password "demo" and assigned it editor permissions so you can see and test quite a bit more. Once you login, you will get a nice toolbar along the bottom, that gives a better idea how ZAPwiki works. Normally I would not give this much permission to the general public, but there's not much to debug if you can't do anything! You can also register your own account to see what a member's permissions look like. You won't get the editor's toolbar even though you can still create and edit pages if you know how. Actually, I should (will) add a simplified member's toolbar... Also, I should note that bullet proofing ZAPwiki is esp daunting for me because it's capabilities are so intertwined--it strikes me a bit like spaghetti! So feel free to look at the source code or try tinkering with a form or whatever. The tutorials are not exhaustive, but concise and useful. I'm hoping trial and error will disclose its glitches before they are found by the bad guys... Thanks again for the input! Helpful so far... Cheers, Dan

Thanks AgentSteal! I'll turn the reporting off before the final release. But will leave it on for now. I fixed this error. Cheers, Dan

Just completed a new wiki engine with several nice features including flat files, hierarchical pages, indexing and search, simple and intuitive markup and many other features. It also has a powerful forms processor that can handle uploads, emails, page creation/editing, logs, data handling, login/logout, and much more. The engine can be tapped into using using simple forms on what I call action pages--which allows you essentially to build your wiki engine within the wiki. Very flexible--and yet a tiny download! You can also edit skins, css, and js right within the wiki. Anyway, I've been debugging and testing it now for over a month, and think it is getting close to ready for release. It works pretty well, but as this is my first major php project, and security is not my strong suit--I'd really appreciate help with bullet proofing that side of it. Security is especially important in this project considering just how many things the forms processor can do... The software can be downloaded at http://www.fast.st/zapwiki/welcome/index.php. I also set up a fresh, vanilla install at http://www.fast.st/zapwiki/demo/index.php if you would like to hammer around a bit. My sincere appreciation to anyone who finds a bug or a vulnerability. Oh, and please let me know how it installs for you as one or two have complained of installation problems I can't replicate... Cheers, Dan PS. AgentSteal--I hope you'll look into this one... I am amazed at your work.

Sorry the question was unclear. Am just trying to understand what the risks could be of using the backtick as a delimiter. Specifically, if php is parsing a string that contains it, could something malicious be executed? Actually I've gone through and changed all the code, so it's not so critical now. But I am really trying to understand security and was hoping for a clearer explanation of how this works. I mean is this something that could cause problems in a simple forms input field? Or does it only work in certain restricted situations. I noticed htmlspecialchars() does not seem to escape this character. But then again, of course it's not a html special char, its a php special char! Cheers, Dan

*bump*

I've just written a new application (a wiki) and I want to make it as self-installing as possible. My server is using suexec.php, and it works great under that, but some beta testers complained it won't install at all on regular apache. It's an ownership/permissions puzzle I'd love some help sorting out. The initial upload looks like this --Main Folder ----Code Folder ------Script 1.php ------Script 2.php ------etc One of the scripts is setup.php. When you run it, it's supposed to create this: --Main Folder ----Code Folder ------Script 1.php ------Script 2.php ------.htpasswd file (new) ----Wiki Folder ------index.php (config file, main url) ------Pages Folder --------Various wiki pages ------ Uploads Folder ------ Other Misc Folders I need to have maximum security, but all necessary functionality. Can someone suggest the right permissions? I'm guessing the account holder needs to give the main folder 777 permissions initially and then the setup folder needs to chmod the folders and files it creates to a tighter level. Someone also said making the index.php file owned by the webserver (ie created when the browser runs setup.php) is itself a major security risk. Is that true? If so I could have the individual manually create the index file. Finally I'd like to have the admin make as few changes as necessary, so to avoid having to reset the code folder's permission it may be better to put the .htpasswd in the main folder. Anyway, any input anyone can give would be appreciated! Cheers, Dan

Well, it's a bit complex. And I use it in several places. For example I create indexes that look like: SomePage: field1=data`field2=moredata AnotherPage: field1=data`field2=moredata ... Also the engine converts [if equal a b]some text [if] to `true equal a b`some text`true` and then immediately converts that to 'some text' or '' depending on the condition--so the backtick doesn't appear in the final output. But it is parsed by the script. And finally I set up hidden data values on wiki pages (for database like functions) that looks like Main page text... `data` field=data ` field2=more data ` These are all just raw text files parsed by the script engine and it never shows up in the final html output, but these text strings do get manipulated by the php scripts that produce the output... I could switch to some other syntax as I've only JUST released this as pre-beta software, but wanted to understand how it all works, if possible. Cheers, Dan

I am kind of new to php but recently put together a script using the backtick operator for certain kinds of data delimiters, only to discover it has special meaning in php. Can someone explain exactly what it does, what cautions I should observe in using it in data formatting (I'm thinking security), and whether or not I should just scrap the whole idea and use something different? Thanks in advance Dan