Jump to content

Security check for wiki engine


fast4god

Recommended Posts

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.

Link to comment
Share on other sites

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

 

 

Link to comment
Share on other sites

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

 

 

Link to comment
Share on other sites

I know that I am not the first person to find this, because when I went to test my suspicsion, i realized someone added in echo "I hacked"; or w/e

 

But incase they haven't told you: when logged in you can edit any page you want.

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

This is with the Demo account:

 

Right after login in, I renamed "main" into "tutorials", which didn't throw any complaints, but didn't seem to do much either. The renaming didn't happen.

 

So, then I went on to docs.markups and again, renamed it into "tutorials". This is what I got:

 

Warning: rename(pages/docs.markups,pages/tutorials) [function.rename]: No such file or directory in /home/fastst/public_html/zapwiki/barn/commands.php on line 341

Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent by (output started at /home/fastst/public_html/zapwiki/barn/commands.php:341) in /home/fastst/public_html/zapwiki/barn/engine.php on line 562

Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /home/fastst/public_html/zapwiki/barn/commands.php:341) in /home/fastst/public_html/zapwiki/barn/engine.php on line 562

Warning: Cannot modify header information - headers already sent by (output started at /home/fastst/public_html/zapwiki/barn/commands.php:341) in /home/fastst/public_html/zapwiki/barn/engine.php on line 565

Warning: Cannot modify header information - headers already sent by (output started at /home/fastst/public_html/zapwiki/barn/commands.php:341) in /home/fastst/public_html/zapwiki/barn/engine.php on line 566

 

Upon clicking back on the browser, it THEN read "doc.markup could not be renamed".

 

So, to press my luck a little more, I created a new "doc.markup" (no trailing S) page, and then renamed it to "doc.markups" and thus wiping out the Markup documentation (sorry  ;D)... Due to the direct rename attempt failure I assumed the documentation was protected, but I may be wrong and it was editable/rename-able (sic)... so I made no further tampering as this was the Demo account and not very conclusive  :P.

 

I also tried, and succeded in renaming "tutorials" into "sandbox" without warnings... the tutorials page now gives me "Test your markup here..." without textarea (Sorry about that  :-X) that was the only place where I did not encounter some kind of overwritting check though. Maybe some "Are you sure you want to overwritte XXX?" would be nice.

 

Then I registered, and attempted to see this page:

http://www.fast.st/zapwiki/demo/index.php?p=action.all

 

It says it's blocked, and the first entry in the bottom bar is "invalid link".

 

I then created a new "test.one" page (As a registered user I can't rename nor copy pages).

 

I inserted this link:

[[?boguslink|uglylink]]

And got this:

 

Warning: preg_match() [function.preg-match]: Compilation failed: nothing to repeat at offset 1 in /home/fastst/public_html/zapwiki/barn/engine.php on line 437

Warning: preg_match() [function.preg-match]: Compilation failed: nothing to repeat at offset 1 in /home/fastst/public_html/zapwiki/barn/engine.php on line 437

 

 

Also I can edit non existant pages, and upon submiting the edit I get the "missing page" error.

 

Also: (Not really important though):

http://www.fast.st/zapwiki/demo/index.php?p=top

http://www.fast.st/zapwiki/demo/index.php?p=bottom

 

Now,

 

[(math 1/0)] throws:

Warning: Division by zero in /home/fastst/public_html/zapwiki/barn/functions.php(165) : eval()'d code on line 1

 

[(math 0.1.2)] throws:

Parse error: syntax error, unexpected T_DNUMBER in /home/fastst/public_html/zapwiki/barn/functions.php(165) : eval()'d code on line 1

 

[(rand -1 a)] throws:

Warning: preg_match() [function.preg-match]: Empty regular expression in /home/fastst/public_html/zapwiki/barn/engine.php on line 324

Warning: preg_match() [function.preg-match]: Empty regular expression in /home/fastst/public_html/zapwiki/barn/engine.php on line 324

Warning: rand() expects parameter 1 to be long, string given in /home/fastst/public_html/zapwiki/barn/functions.php on line 246

 

Using the [redirect] tag allows me to place text before the page header ( "Welcome to..." ).

Leaving unclosed [t] tags messes the bottom bar's palcement.

 

Finally, I managed to lock the site in an infinite loop by forwarding a page onto itself with [(forward page)].

 

And that's all for now... if I find anything else, i'll post. Hope it helps in some way.

( http://www.fast.st/zapwiki/demo/index.php?p=login.malicioususer for my up to date tampering.  ;D )

 

Cheers and nice work.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

 

8) 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

Link to comment
Share on other sites

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.

8) 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

Link to comment
Share on other sites

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

 

 

Link to comment
Share on other sites

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

 

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.