Name | Type |
---|---|
12.x to 13.x upgrade: "Plugin execution pending approval" on http://doc.tiki.org/Menu | tracker item |
Wiki cache & plugins: WYSIWYCA problem when admin visits the page (and creates the cache) | tracker item |
13.0 Beta: File integrity security check: several false positives | tracker item |
snarlydwarf
Contributors |
tracker item |
File gallery: Virus checker
maybe http://www.clamav.net/ which has php plugin |
tracker item |
Instantaneous visual feedback of password strength
"Password Strength Checker is an application that is designed to assess the strength of password strings. The instantaneous visual feedback provides the user a means to improve the strength of their passwords, with a hard focus on breaking the typical bad habits of faulty password formulation. Since no official weighting system exists, Password Strength Checker has created its own formulas to assess the overall strength of a given password." http://www.webappers.com/2008/03/17/integrate-password-strength-checker-into-registration-forms/ We would need something like this, but LGPL |
tracker item |
Change Crypt passwords method
#check who did it #decide new default setting Are upgrades affected? |
tracker item |
19.x themes.tiki.org Possible cross-site request forgery (CSRF, or "sea surfing") detected. Operation blocked. | tracker item |
TikiWiki 2.0: Odd Tags get Inserted into HTML Code
This is actually related to two other bugs reported by SEWilco, and discussed in IRC: http://dev.tikiwiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=1910 http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1911 On August 6, 2008, we upgraded to TikiWiki 2.0 using the latest and greatest code from SVN. Following this, I noticed one very odd behavior: Basically, an 'x' bracketed by < and > is inserted randomly into various words whenever I went to edit / preview a page in the Wiki. It mainly happens on the words 'style' and 'mouseover' but I am sure there are many others affected similarly. I did the following 1. Login to the Wiki 2. Click the "Edit" / pencil icon at the upper right hand corner of the home-page 3. Click the "preview" button Here is a sample of the code that gets created (brackets removed ) '' table stxyle="width:100%;" tr td stxyle="width:43%;border: thin solid #000000; border-width: 1px 1px 1px 1px" bTable of Contents/bbr {maketoc} /td td stxyle="width:2%" /td td stxyle="width:55%;vertical-align:top;border: thin solid #000000;background-color:#eaeaea; border-width: 1px 1px 1px 1px"'' I understand that this is done to prevent dangerous HTML insertion. However, allowing HTML to our site is essential, as it gives us a lot more flexibility in formatting than does the limited Wikitext markup. Is there any workaround for this, or a proposed fix? |
tracker item |
20 or more unsuccessful login attempts have been made but I can still login as usual? | tracker item |
TikiWiki 2.0: SearchBox Not Displaying for Anonymous Users
I am having issues displaying the "search_box" module to Anonymous Users. The box does appear for Registered Users, however. I have done the following: 1. Login as an admin 2. Clicked "Admin Home" link > clicked the "Look and Feel" icon > clicked the "General Layout" tab > 5. Verified that a. "always" is selected in the "Left column" pulldown menu b. "never" is selected in the "Right column" pulldown menu 6. Clicked the "Modules" link 7. Verified that the following groups are assigned to "search_box:" Anonymous Registered See attached .gif for clarification. {img src=show_image.php?id=53} Any reasons why the search_box would not appear to Anonymous users who have not logged into the site, especially when all the configurations are in place? |
tracker item |
2FA/MFA and using a password manager would be an important addition to https://security.tiki.org/tiki-index.php | tracker item |
Tiki Wiki CMS Groupware Security Vulnerability Notification
Hello, High-Tech Bridge Security Research Lab has discovered a security vulnerability in your product - Tiki Wiki CMS Groupware. Developers can contact us by email advisory (at) htbridge.ch for details. Preview: [http://www.htbridge.ch/advisory/xss_in_tiki_wiki_cms_groupware.html|http://www.htbridge.ch/advisory/xss_in_tiki_wiki_cms_groupware.html] For any questions related to this notification email - please visit our General Information & Disclosure Policy page: http://www.htbridge.ch/advisory/disclosure_policy.html |
tracker item |
Built it TPL editor removes Javascript from the Templates
This is intended as a security feature. However, it is causing lots of support requests. How can we maintain security but make it easier for admins? |
tracker item |
Add "tiki_p_admin_structures" permission
Can anybody explain me, why there is no permission tiki_p_admin_structures? Users with tiki_p_edit_structures can do everything they want with my structures. But I only want them to add new pages. Every other feature of TW has two main perms: tiki_p_admin_xyz and tiki_p_edit_xyz. But structures only have tiki_p_edit_structures, which allows users with this right to even delete the structure of our corporate wiki. Please add this perm! Maybe even for TW 3.0? Thanks in advance. |
tracker item |
Add New User - Gen Password - Validate By Email is Broken in 4.1 and 4.2
~~#c00:UPDATE 1-APR-2010 - An out-of-the box TW 4.2 install no changes to login parameters leads to a non-functional validate-by-email feature when adding users. The user receives an email with a link containing the user name in plain text and an encrypted password that appears to be invalid. Oddly, if the user clicks the "I forgot my password" link, then they are permited to choose a new password, without having to submit (or even know) the original password. Tiki 3.3 and 3.5 are working great with respect to emailing links to new users, then logging them in with the encrypted (tiki-generated) password, then forcing them to select their own password. With respect to 3.3 I have made changes to the login configurations. With respect to 3.5, however, I have not changed anything, but it still works great emailing the first-time-user a link with an encrypted password, and having that password work.~~ See the attached document for a step-by-step recreation of the problem. New 4.1 install, only minor configuration of login - requires both letters and numbers in password. Add new user with generated password, and user must change password uupon first login leads to error when user attempts to do so. User Email Confirmation: Confirming or not confirming the user's email address has no effect on this bug. Minimum password length: password length (tried 1 and 6) has no effect on this bug. Password - letters or letters and numbers: seems to have no effect on this bug. |
tracker item |
Add SRI hash for sub resources from CDNs | tracker item |
Adding some Tiki built-in login authentication methods | tracker item |
Admin or team shouldn't wait 120s to post in tiki.org forum | tracker item |
An XSS vulnerability in installation | tracker item |
anti hammering is a nice security feature against flooding
Bugs & Wish list |
tracker item |
Approving a user logs the admin as that user | tracker item |
arbitrary file read vulnerability | tracker item |
Authenticated RSS
Maybe http://user:password@domain.com/tiki-blogs_rss.php should work. It's not super safe because passwords are flying around... |
tracker item |
Auto setting security group when creating wiki pages | tracker item |
Automatic SVN commit of secdb and syncdb
This one should be run every time a php file is changed: doc/devtools/tiki-create_md5.php This should be automatic. Is there a way to this with SVN? |
tracker item |
Banning IP addresses regex not saving correctly | tracker item |
Banning users ( tiki-admin_banning.php ) doesn't work for me at doc.tw.o
banning user doesn't work for me at doc.tw.o. (using 1.9.7, I guess) I've just made a trial with my user (common registered user, "xavi") at doc.tw.o from my admin account there(xavidp). || Rule title | xavi trial Username regex matching: | xavi IP regex matching: . . .| ''(empty)'' Banned from sections: | wiki checkbox Rule activated by dates | checked Rule active from | 1 june 2007 Rule active until | 10 june 2007 Custom message to the user | trial xavi || Btw, the rule was saved, and after that, I could see a line in the rules list showing my new rule: || Title | User/IP |Sections | Action xavi trial | xavi | wiki | X another one (krisna) ... another one (anonymous - IP)... || After that, I logged in on another browser to check if my user xavi was banned indeed, but I could login with no problems, and open a page for editing. (what kind of behavior was banning suppose to give?) I the main browser (still as user xavidp), I changed language, went back to this url (by writing its url directly on the browser http://doc.tikiwiki.org/tiki-admin_banning.php ), Changed language to English, and suddenly, my new rule for xavi user was not there any more! ¿¿¿¿???? There were only the ohter two rules... || Title | User/IP |Sections | Action another one (krisna) ... another one (anonymous - IP)... || I guess some bug is around, behind that naughty behavior... ;-) |
tracker item |
Better protection against accidental site breakage with improper use of code in modules + template
One of the nice things about Tiki is that, once setup, all the configuration is done Web-based. No FTP access is necessary. However, it can happen that a Tiki admin breaks his site and locks him/herself out. This can happen in Site Identity as well. For example, if you use the following code {CODE()} {show_image.php?id=13} {CODE} in a module, you will get: {CODE(wrap=>1)} Fatal error: Smarty error: [in evaluated template line 1]: syntax error: unrecognized tag: show_image.php?id=13 (Smarty_Compiler.class.php, line 436) in lib/smarty/libs/Smarty.class.php on line 1088 {CODE} and the site will be broken and you will be locked out of your Tiki site. (You need to go via phpmyadmin to delete the offending module) I just added a warning to BRANCH-1-9 for modules but it would be much better that Tiki wouldn't break in this case. More background info/ideas below {CODE(wrap=>1)} (01:17:27) marclaporte: I am wondering if there would be a way to avoid people locking themselves out of a Tiki site when putting invalid content in modules... (01:22:27) chibaguy: One way of coping would be to include an admin_modules page (php and tpl files) that has no side columns, so people could input that URL admin their modules without the activated modules being displayed. (01:23:28) chibaguy: Of course it would be more direct if the bad module just displayed without content when the content is bad, but is this possible? (01:28:23) marclaporte: depends how bad I guess (01:28:31) marclaporte: How about a test module page (01:28:53) marclaporte: So you can test even before assigning (01:29:18) chibaguy: Yes, if it opened in a new page, it wouldn't kill the main site. (01:29:24) marclaporte: Some guy locked himself out using {show_image.php?id=13} (01:29:42) marclaporte: It is very natural for the person to try this syntax (01:31:27) marclaporte: instead he's locked out Fatal error: Smarty error: [in evaluated template line 1]: syntax error: unrecognized tag: show_image.php?id=13 (Smarty_Compiler.class.php, line 436) in lib/smarty/libs/Smarty.class.php on line 1088 (01:32:52) chibaguy: It does make sense to have a safe test zone for modules before they are assigned. (01:33:17) chibaguy: Where failure doesn't lock up the site. (01:33:38) chibaguy: Could that replace "preview"? (01:33:52) chibaguy: Or "preview" be enhanced? (01:37:17) marclaporte: where is preview? (01:38:54) chibaguy: On Admin Modules page under "Assign new module" there's a "preview" button that displays the module in the center of the page. (01:39:50) marclaporte: woah (01:40:01) marclaporte: I never noticed that (01:40:11) marclaporte: 4 years (01:40:20) marclaporte: and I still discover stuff (01:40:23) marclaporte: :-) (01:40:33) chibaguy: Heh. Well, Tiki's got a lot of stuff. (01:41:41) chibaguy: I'm not sure offhand how preview handles fatal error modules. With Opera, I just hit the back button and have the admin modules page again. (01:41:56) marclaporte: I just tested (01:42:03) marclaporte: it crashes (01:42:11) chibaguy: Ouch (01:42:31) chibaguy: What if preview previewed in another page or a popup? (01:42:57) chibaguy: The user would still have control, I think. (01:43:01) marclaporte: it crashes but just one page (01:43:10) marclaporte: the site is still accessible (01:43:17) chibaguy: OK. (01:43:45) chibaguy: So users should be sure to preview first. (01:44:29) chibaguy: Maybe Admin Modules needs some large warning messages. (02:13:46) CIA-9: marclaporte BRANCH-1-9 * tiki/templates/tiki-admin_modules.tpl: Warning message about possibly breaking a Tiki site by improprer use of Smarty Syntax in modules (02:13:48) marclaporte: incoming {CODE} --- Added on 2007-08-17: Idea for modules: Maybe tiki-admin_modules.php shouldn't show modules. So you could always get access to your Tiki to remove/fix modules. And it should offer a login box, when not logged in. tiki-admin_modules.php could have some like (this doesn't work because modules are evaluated even in left & right columns are off, since a module could be in a wiki page): {img src=images/code.png}%%% {CODE()} $smarty->assign('feature_left_column', 'n'); $smarty->assign('feature_right_column', 'n'); {CODE} But it is nice to see the result of what you are doing. We could have &showmodule=y in the URL (with a link next to assign module/left modules/right modules/etc __Same thing when you use tiki-edit_templates.php__ -> If I don't close an if, I get: {img src=images/code.png}%%% {CODE()} Fatal error: Smarty error: [in evaluated template line 1]: syntax error: unclosed tag {if} (opened line 1). (Smarty_Compiler.class.php, line 317) in lib/smarty/libs/Smarty.class.php on line 1095 {CODE} Would there be a way that a Smarty error doesn't break Tiki completely? Here again, there could be a light version of tiki-edit_templates.php which has nothing which can break in a module. Maybe everything is hard-coded and it doesn't take any theme into account. And it shouldn't be possible to edit the tpl of tiki-edit_templates.tpl via tiki-edit_templates.php?template=tiki-edit_templates.tpl __Maybe useful?__ Smarty validation class http://www.phpriot.com/d/code/smarty/smarty-validator/index.html Here is another very famous error: "Fatal error: Allowed memory size of 8388608 bytes exhausted" http://tikiwiki.org/art82 And they often cause blank pages. How can we can catch them and render a simple & descriptive error page (not enough memory) instead of a blank page? __Related:__ dynamic contents in userdefined modules crashes tiki http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=851 |
tracker item |
binddb and bindpw not used when binding to LDAP
TikiWiki 1.9.8, 1.9.9, 1.9.10, 1.9.11 does not provide binddn and bindpw, when initializing LDAP auth object in userslib.php. So Tiki can't use authorized LDAP requests... |
tracker item |
Captcha setting/preference in admin => login | tracker item |
Categorisation permission issue with Calendars and Trackers
This may be a more general Categorisation issue, but with the Calendar function if a Group is given just view permissions for calendars and calendar events, and an individual calendar is categorised where the Category is defined with this same Group given "view categories" and "view categorised" - then the Group can then add new events and change existing events even though they do not have these base permissions. This behaviour is similar to that seen with Trackers and posted to the Features/Usability Forum [http://tikiwiki.org/tiki-view_forum_thread.php?comments_parentId=31343&topics_offset=184&topics_sort_mode=lastPost_desc&forumId=4|here] where a Categorisation overrides a base permission level. This problem can be avoided by not using Categorisation and instead setting detailed Permissions for the individual Calendar but this is obviously more complex and makes it difficult to impose a systematic security policy across the whole site. This bug has been tagged against Security since other users may not realise this issue exists and their site security policies may be broken and not realised. Very old bug now fixed with improved categorisation |
tracker item |
Category plugin lists objects even without perms
The CATEGORY{} plugin does not check for perms when listing objects, so objects where user has no perms are displayed anyway. If you click these links you get an error because the pages themselves are protected. However, you should not be able to see the list. |
tracker item |
#1496
Bugs & Wish list |
tracker item |
#1497
Bugs & Wish list |
tracker item |
CRYPT_BLOWFISH | wiki |
CSRF Protection
Approach to CSRF protection |
wiki |
CVE-2006-6457 tikiwiki vulnerable
Could you please see if tikiwiki version 1.9.7 is affected by CVE-2006-6457? In addition, tiki-wiki_rss.php may suffer from an XSS vulnerability (the affected site claims to run the 1.0 CVS version, though): http://tikiwiki/tiki-wiki_rss.php?ver=555555555%3Cb%3E22362623 Thank you in advanced. |
tracker item |
default tiki setup vulnarable to subfolder links
try www.yourdomain.com/a/a a may not exist on dev.tiki.org it works on my localhost and on luciash's kincwood it also does not work |
tracker item |
dev.tiki.org delivered garbage, possibly crashed | tracker item |
dynamic contents in userdefined modules crashes tiki
If you define a {MODULE} - Tag in a dynamic content element and add the dynamic content to a user module ( with use of wiki parser ). Tiki shows a blank page. |
tracker item |
Easy way to deal with SSL when using external images or scripts
Tiki already handles nicely SSL (With the Yes, No, Automatic choice for HTTPS Server: in tiki-admin.php?page=general). This is for Tiki generated content. But what about external images or scripts? Probably no need to code anything. Just better documentation on how to use a variable to use different links. Example: {img src=images/code.png}%%% {CODE()} if($_SERVER['HTTPS']) { $google_analytics_url = "https://ssl.google-analytics.com/urchin.js"; } else { $google_analytics_url = "http://www.google-analytics.com/urchin.js"; } echo " _uacct = 'ACCT_ID_GOES_HERE'; urchinTracker(); "; {CODE} |
tracker item |
Enhance mail delivery | tracker item |
Enhancement: Use .htpasswd / .htgroup for user access & control
TWiki has the ability to refer to an Admin specified .htpassword file for user control. This is highly useful for having a single point of administration. The tough part is that TWiki doesn't manage the user experience (password changing, etc) very well. For a TikiWiki enhancement, I would have the following wish: (1) For the login/authorization, when set to WEB, admin should be allowed to set the path to the apache password file (typically a .htpasswd but names are arbitrary). (2) Should allow the optional use of .htgroup settings as a means of setting member group. This would then override or augment TikiWiki's groups -- or better yet tikiwiki would manage the .htgroup file in this case. Benefits of this enhancement: (1) This would greatly streamline multiple tiki's on a single hosted site (like a corporate intranet). (a) Single location for user entry for all tiki's that look to the same .htpasswd file (b) Single location for group entry for all tiki's that look to the same .htgroup file (b) No mess trying to setup InterTiki (2) Might also simplify setting up of MultiTikis on a single site by clarifying and simplifying user and group setup. (3) Would clarify user setup using the Web Authorization method (a) Right now, one needs to add the user to the .htpasswd file to give them authorization (Locked Area Lite works well for this) and then ALSO add the user to the TikiWiki. The problem is if there are multiple TikiWiki's, then it could be a lot of work adding a username and their groups to each of the TikiWiki's. (b) The process above (3a) is pretty unclear and takes some figuring out for a newbie tikiwiki admin like myself. |
tracker item |
Error: Request could not be completed due to problems encountered in the security check. | tracker item |
Errors when trying to change access rights
______As soon as I want to change something about security (access rights), I have these messages: ______ {CODE(wrap="0",ishtml="0",ln="0",wiki="0",rtl="0",cpy="0")}Notice: Undefined index: forumId in /home/rimqnet/public_html/wiki2/lib/core/lib/Perms.php on line 185 Notice: Undefined index: forumId in /home/rimqnet/public_html/wiki2/lib/core/lib/Perms.php on line 185 Notice: Undefined index: forumId in /home/rimqnet/public_html/wiki2/lib/core/lib/Perms.php on line 185 Notice: Undefined index: forumId in /home/rimqnet/public_html/wiki2/lib/core/lib/Perms.php on line 185 Notice: Undefined index: forumId in /home/rimqnet/public_html/wiki2/lib/core/lib/Perms.php on line 185 Notice: Undefined index: forumId in /home/rimqnet/public_html/wiki2/lib/core/lib/Perms.php on line 229 Notice: Undefined index: forumId in /home/rimqnet/public_html/wiki2/lib/core/lib/Perms.php on line 229 Notice: Undefined index: forumId in /home/rimqnet/public_html/wiki2/lib/core/lib/Perms.php on line 229 Notice: Undefined index: forumId in /home/rimqnet/public_html/wiki2/lib/core/lib/Perms.php on line 229 Notice: Undefined index: forumId in /home/rimqnet/public_html/wiki2/lib/core/lib/Perms.php on line 229{CODE} __ Any idea about what is going wrong ? In the mean time, should I stop using the system because of a possible security problem __? Thanks Gaston |
tracker item |
false positive at tikiwiki security error report
I have this settings at tiki-admin_security.php : {QUOTE()} || Tikiwiki settings Tiki variable | Setting | Risk Factor | Explanation fgal_use_dir | ../tiki_filegals/ | unsafe | The Path to store files in the filegallery should be outside the tiki root directory || {QUOTE} However, that folder it outsite the tiki root directory, and outside htdocs. |
tracker item |
Fatal error: Call to undefined TikiDb_Adodb::setAttribute() in ..\lib\tikisession-pdo.php on line 18
Setting session storage location to database results in this fatal error: Fatal error: Call to undefined TikiDb_Adodb::setAttribute() in ..\lib\tikisession-pdo.php on line 18 Temporary work-around is to disable calling that feature: UPDATE `tiki_preferences` SET `value` = '' WHERE `tiki_preferences`.`name` = 'session_storage' LIMIT 1 ; |
tracker item |
Feature request: Global invalidation of passwords | tracker item |
FOAAgain | tracker item |
Forum security issue: Ref: H56
Please refer with the Security squad for details: http://security.tikiwiki.org/tiki-contact.php |
tracker item |
Generate password should respect password preferences | tracker item |
Get status update on @tiki.org server | tracker item |
HTMLpurifier no longer permits to use Paypal buttons (starting in Tiki4)
In Tiki 3.x, it worked fine. Upon upgrade, when there is an edit, some of the HTML is stripped. {CODE()} <form action="https://www.paypal.com/cgi-bin/webscr" method="post"> <input type="hidden" name="cmd" value="_s-xclick"> <input type="hidden" name="hosted_button_id" value="10235687"> <input type="image" src="https://www.paypal.com/fr_XC/i/btn/btn_paynowCC_LG.gif" border="0" name="submit" alt="PayPal - la solution de paiement en ligne la plus simple et la plus sécurisée !"> <img alt="" border="0" src="https://www.paypal.com/fr_XC/i/scr/pixel.gif" width="1" height="1"> </form> {CODE} This is caused by HTML Purifier (in Admin > Security) |
tracker item |
Image attachements are not saved unique
When uploading images to a wiki page, the image is stored by name on the upload directory. However, names are not unique. Therefore it's possible by different wiki page to overwrite (by accident) an image of a different page, by just uploading an image with the same name. |
tracker item |
image gallery: sort_mode=filesize causes mysql error and path disclosure
You can see one here: http://marclaporte.com/tiki-browse_image.php?galleryId=11&sort_mode=filesize_desc&imageId=431&scalesize=640 Please see here for a better description of how to duplicate: http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1399 |
tracker item |
Improve account approval mechanism | tracker item |
Incorrect permission verification in tiki-upload_file.php
User is unable to upload file even if the permission tiki_p_upload_files is assign to his group on the file gallery. User gets "Permission denied" when clicking the "Upload file" in the gallery. tiki-upload_file.php (at line [http://tikiwiki.svn.sourceforge.net/viewvc/tikiwiki/branches/3.0/tiki-upload_file.php?view=markup#l_160|160]) wrongly assumes request parameter "galleryId" to be an array with a single element when checking for permission. However, it can a string. For example if a user call ...upload_file.php?galleryId=30, the permission for gallery with id 3 will be considered. |
tracker item |
Increasing Tiki Security NOW, with a view to enticing future large customers | tracker item |
Security check fail if file directory storage path is relative | tracker item |
Is there an issue with passwords? | tracker item |
Need stronger CAPTCHA
On the www.wiki-translation.com site, anonymous users can post comments but they have to go through a CAPTCHA test to prove that they are not a machine. In spite of that, several spam comments are being posted (selling viagra, sort of thing) each week, presumably by robots. I for one (Alain Désilets) can't believe that there are humans who actually do this manually. I suspect that the problem is that spamming robots have become better at dealing with simple CAPTCHA tests like the one used in Tiki. The Tiki CAPTCHA test only uses numbers (no alpha chars), and the graphical distortion of those numbers is very minimal (the vertical alignment of the numbers is just perturbed slightly). I might be worth it to update the CAPTCHA library used by Tiki, to provide a more difficult test. |
tracker item |
security issue: Multiple XSS
XSS SECURITY ISSUE :: This has been reported to Security Team. Best Regards, sschurtz (s.schurtz@infoserve.de) |
tracker item |
PHP Code Injection Vulnerability
Hi, my name is Egidio Romano (aka EgiX) and I found a vulnerability that could allow execution of arbitrary PHP code. I've sended an e-mail to security(at)tikiwiki.org which explains this flaw. Regards, EgiX |
tracker item |
Persistent Cross Site Scripting in Tiki Wiki 8.2
Hello, there is a failure "XSS" persistent in Tiki Wiki 8.2. I'm reporting to security email now. Regards, Mario |
tracker item |
webdav
Bugs & Wish list |
tracker item |
Critical security vulnerability
Hi, my name is Egidio Romano (aka EgiX) and I found a vulnerability that could allow execution of arbitrary PHP code. I've sended an e-mail to security(at)tikiwiki.org which explains this flaw. Regards, EgiX |
tracker item |
Add a virtual keyboard
Similar to the special character tool (which it could replace) , this is useful when you are away from your usual keyboard... (or just have a mouse!) Good against keyloggers, so it could part of the login screen too Here is a BSD-licensed one: http://www.greywyvern.com/code/javascript/keyboard Dokuwiki has a plugin http://www.dokuwiki.org/plugin:vkeyboard |
tracker item |
MEbneter
Contributors |
tracker item |
"protect all sessions" conflicts other https preferences
If HTTPS login is disabled and "protect all sessions" is activated, no one can login anymore. Others to watch: * Users can choose to stay in SSL mode after an HTTPS login * Users can switch between secured or standard mode at login |
tracker item |
"Ignore individual object permissions" not working for Lucene Engine
Having the Lucene Search Engine enabled, "Ignore individual object permissions" is not available! Searching as user with restricted permissions, it is possible to see the "preview" of forbidden pages when searching for a search string included in this page. |
tracker item |
LDAP Admin Password Stored as Plain Text In System Logs
When you change the LDAP admin password, and look at the logs in tiki-syslog.php, it is displayed as plain text. Scary man! Working on a solution, so if I figure it out, I'll post, but I'm not to php savvy, so we'll see. --- edit: All password fields in the admin area are saved as plaintext in the logs. |
tracker item |
Registration vulnerability
Just to be sure that I'm not posting any vulnerability details, please contact me for more information: marja *at* svi *dot* nl. Thanx! |
tracker item |
temp/.htaccess breaks antibot image serving
I have a new Tiki 9.0 install. Testing the user registration process, the antibot capcha image is not visible. So no-one can register! I cut the image URL out of the webpage, and viewed it in isolation. It has a path in the form "/temp/public/<UUID>.capcha.png". I get a "403 access denied". I am not logged in, obviously. My temp/.htaccess file has: {CODE()} <FilesMatch ".*"> order deny,allow deny from all </FilesMatch> {CODE} Whereas temp/public/.htaccess has: {CODE()} <FilesMatch ".*"> order deny,allow allow from all </FilesMatch> {CODE} These are as installed by Tiki. If I delete temp/.htaccess, I can view the image. So it seems to be this which is disallowing files in temp/public from being served, and this implies temp/public/.htaccess isn't actually doing anything useful. Refreshing my memory of how these things work, I read these: http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html#order http://drupal.org/node/93865 Admittedly it's a bit subtle. But it looks to me like the <FilesMatch ".*"> and 'allow from all'/'deny from all' directives are redundant and might not do what they seem to do. Ignoring what Tiki 9.0 has installed for me, I think what sounds like a correct configuration would be to make use of the fact that .htaccess is inside an implicit <Directory> section, and simply have: temp/.htaccess: {CODE()} # deny access to this dir and children by default. Order allow, deny {CODE} temp/public/.htaccess: {CODE()} # allow access to this dir and children by default Order deny, allow {CODE} And if I put those in, it seems to work for me. I can access temp/public/<blah>.captcha.png, but not temp/README in my browser. This *does* seem to be at odds with the fact that this prevents new user registrations and that if the Tiki-installed defaults didn't work, it's likely someone would immediately notice that! However I've asked on the devel and user lists, but no-one seems able to comment. http://article.gmane.org/gmane.comp.cms.tiki.user/3256 Note, one possibly relevant fact is that my shared hosting (Eleven2) doesn't actually use Apache, they use Litespeed (which is meant to respect .htaccess and supports the usual Apache configs). So far I've not noticed any funny behaviour which suggests that it doesn't behave just like Apache. |
tracker item |
CLI search index maintenance conflicts with "Protect all sessions with HTTPS"
Tiki version 9.1 Executing the search index maintenance (e.g. php lib/search/shell.php rebuild with cron) on the command line produces the following error if "Protect all sessions with HTTPS" is set on tiki-admin.php?page=security: PHP Notice: Undefined index: HTTP_HOST in /path/to/install/tiki-setup_base.php on line 74 PHP Notice: Undefined index: REQUEST_URI in /path/to/install/tiki-setup_base.php on line 74 |
tracker item |
OpenPGP support for emails to users
It'd be a nice feature and enhancement of users' privacy and security, if users can drop an OpenPGP public key into their accounts and receive emails encrypted. Actually anyone can initiate a forgotten password request and will be able to take over an account if he or she manages to eavesdrop a user's email traffic. More generally spoken, OpenPGP support opens a second auth channel in case users need to change certain settings semi automatic or are in environments with a higher security level which require more than just a password. Using an installed GnuPG software instance by PHP scripts should not be a license issue despite GnuPG is GPL and not LGPL. But this is an issue I'll check. |
tracker item |
Smarter handling of HTTPS/SSL for included elements that are in HTTP (especially JavaScript)
{CODE(caption="How Piwik handles http/https" colors="htmlmixed")}<!-- Piwik --> <sc var pkBaseURL = (("https:" == document.location.protocol) ? "https://piwik.tiki.org/" : "http://piwik.tiki.org/"); document.write(unescape("%3Cscript src='" + pkBaseURL + "piwik.js' type='text/javascript'%3E%3C/script%3E")); </script><sc try { var piwikTracker = Piwik.getTracker(pkBaseURL + "piwik.php", 2); piwikTracker.trackPageView(); piwikTracker.enableLinkTracking(); } catch( err ) {} </script><noscript><p><img src="http://piwik.tiki.org/piwik.php?idsite=2" style="border:0" alt="" /></p></noscript> <!-- End Piwik Tag --> {CODE} For all the included JavaScript in Tiki, it should switch to HTTPS version when available. ((doc:MathJax)) is an example of a different HTTP/HTTPS URL so ((doc:PluginJS)) should have a param for alternate location of HTTPS version. Tiki could try https by default... |
tracker item |
fmg
Contributors |
tracker item |
9.1, trackers, security: hidden user selector type field keeps listing all the users as options
Hidden: if the plugin has a 1 (creator) or 2 (modifier) parameter, then the field will become hidden. {CODE(caption="the generated html" colors="htmlmixed")}<span style="display:none;"><select name="ins_9" id="user_selector_9" style=""><option value="admin" selected="selected" >admin</option><option value="user135" >user135@user135.com</option> ...{CODE} |
tracker item |
CSRF in tiki wiki 10.2
Different ajax functions located in the same file suffer from Cross Site Request forgery vulnerability. This makes execute unwanted actions on a web application in which the victim is currently authenticated. The details has been described and sent in a encrypted email to the security team. |
tracker item |
Security
Features Classification |
tracker item |
jCapture doesn't work via SSL when SSL is not valid (rest of Tiki is OK) | tracker item |
koth
Contributors |
tracker item |
Login at workflow.tw.o and info.tw.o fails with XMLRPC Error: 5
Login works fine at tw.o, dev.tw.o and doc.tw.o though... The error message on both sites : XMLRPC Error: 5 - Didn't receive 200 OK from remote server. (HTTP/1.0 500 Internal Server Error) |
tracker item |
Login issues to dev.tiki.org | tracker item |
Login Problems / Security | tracker item |
Logout fails to work when web authorization is selected
When using WebAuth as the security mode, a user is unable to actually "Logout". This creates an interesting problem, in that a user would be unable to switch to an Admin account if need be. This problem was discovered when I accidentally locked myself out of a TikiWiki 3.0 install (read below). How the lockout occurred. (1) Setup .htpasswd file for the parent directory (2) Installed TikiWiki (3) Passed through apach authorization into twiki directory and began setting up twiki directory with username admin, password admin (4) Clicked on Security settings and selected Web Auth and hit apply (5) Suddenly, I was locked out of Twiki Admin. Turns out my .htpasswd username was not "admin" and Twiki simply did not recognize me. |
tracker item |
Lost changes when you mistype antibot code | tracker item |
Password will not be accepted when using @ > or < in the password string (with or without LDAP) | tracker item |
mail-in provides no security
The mail-in functionality is great, but provides no security when in "non anonymous" mode. I consider this a bug, as the docs say nothing about user permissions not being applicable with mail-in. Examples: 1. Users that are in a group that cannot post may add or append via mail-in 2. Users that cannot see pages in a particular category can do a GET This is a serious security problem - I'm glad I tested as I had no idea? Any way to add permission checking to the mail-in code? It seems like it would be easy for someone who knows how to do it. I realize it can't be 100 percent secure - someone could always spoof an email sender. |
tracker item |
Make optional the display of BOTH realname and login, since in some LDAP scenarios you don't want to disclose user ID | tracker item |
many errors when attempting to enter & after login dev.t.o | tracker item |
Menu can't be completed due to security check | tracker item |
ModSecurity | wiki |
Modules do not work when called from within wiki pages
Using Release 3.3 I get the following message while trying to embed any module into the body of a wiki page: An error occured in a database query! Context: File tiki-editpage.php Url tiki-editpage.php?page=sandbox Query: INSERT INTO tiki_plugin_security (fingerprint, status, added_by, last_objectType, last_objectId) VALUES(?, ?, ?, ?, ?) Values: 0 module-81051bcc2cf1bedf378224b0a93e2877-f8f6beaaede11aa9a40d17002adee815-200000-107000 1 pending 2 admin 3 wiki page 4 sandbox Message: Built query was probably: INSERT INTO tiki_plugin_security (fingerprint, status, added_by, last_objectType, last_objectId) VALUES('module-81051bcc2cf1bedf378224b0a93e2877-f8f6beaaede11aa9a40d17002adee815-200000-107000', 'pending', 'admin', 'wiki page', 'sandbox') |
tracker item |
Modules, Security; There is (now) a security error when using the plugin LIST in a custom module | tracker item |
Multimedia Flash unusable due to XSS protection
The "Multimedia" feature requires a "urâ€l" parameter, which is damaged to ~np~url~/np~ by XSS protection. TikiWiki has no way to play MP3 files (XSPF mod seems nonfunctional in 2.1). ~np~{FLASH(movie=>"tikimovies/multiplayer.swf?url=http://yoururl/file.mp3&MODE=AUDIO")}{FLASH}~/np~ |
tracker item |
Multiple ip banning from user registrations list fails to pass ip numbers (from action log still possible) | tracker item |
My site totally dead: Warning: ini_set() has been disabled for security reasons
And a quick search shows that many Tiki sites are down because of this setting which is changed after the install. Any suggestions for a workaround? Even better something we can use for Tiki 1.9.8 Warning: ini_set() has been disabled for security reasons in lib/init/initlib.php on line 69 Warning: ini_set() has been disabled for security reasons in lib/init/initlib.php on line 69 Warning: ini_set() has been disabled for security reasons in tiki-setup_base.php on line 20 Warning: ini_set() has been disabled for security reasons in tiki-setup_base.php on line 24 Warning: ini_set() has been disabled for security reasons in tiki-setup_base.php on line 37 Warning: ini_set() has been disabled for security reasons in tiki-setup_base.php on line 38 Warning: ini_set() has been disabled for security reasons in tiki-setup_base.php on line 39 Warning: ini_set() has been disabled for security reasons in lib/init/initlib.php on line 69 Warning: ini_set() has been disabled for security reasons in lib/init/initlib.php on line 69 Warning: main(adodb.inc.php) [function.main]: failed to open stream: No such file or directory in db/tiki-db.php on line 85 Warning: main() [function.include]: Failed opening 'adodb.inc.php' for inclusion (include_path='.:/usr/share/php:/usr/share/pear') in db/tiki-db.php on line 85 Warning: main(adodb-pear.inc.php) [function.main]: failed to open stream: No such file or directory in db/tiki-db.php on line 89 Warning: main() [function.include]: Failed opening 'adodb-pear.inc.php' for inclusion (include_path='.:/usr/share/php:/usr/share/pear') in db/tiki-db.php on line 89 Fatal error: Call to undefined function: adonewconnection() in db/tiki-db.php on line 120 |
tracker item |
natokpe | tracker item |
Need stronger CAPTCHA
On the www.wiki-translation.com site, anonymous users can post comments but they have to go through a CAPTCHA test to prove that they are not a machine. In spite of that, several spam comments are being posted (selling viagra, sort of thing) each week, presumably by robots. I for one (Alain Désilets) can't believe that there are humans who actually do this manually. I suspect that the problem is that spamming robots have become better at dealing with simple CAPTCHA tests like the one used in Tiki. The Tiki CAPTCHA test only uses numbers (no alpha chars), and the graphical distortion of those numbers is very minimal (the vertical alignment of the numbers is just perturbed slightly). I might be worth it to update the CAPTCHA library used by Tiki, to provide a more difficult test. |
tracker item |
Need to restart browser after accessing a closed site | tracker item |
No access permission on articles----articles accessible by articleID for any group
This is how I get the issue:--- As Administrator I made 2 user groups (grpA & grpB). I want that users in grpA should not be able to read articles that are meant only for grpB and vice-versa. Using the Menu option as admin I make different Menus (using tiki-read_article.php?articleId=133, and changing the article ID for different article.) for these two groups, so that grpA sees the list of articles which only he is suppose to see, and same for grpB. [using the Group: option in Menus] Now I log in as a user in grpA and read some article, say http://mytikisite.org/tiki/tiki-read_article.php?articleId=133 Now if I go to the address bar and change the article ID, to say, 150 (which is actually meant for grpB only), I can see the article... http://mytikisite.org/tiki/tiki-read_article.php?articleId=150 How do I solve this access issue??? |
tracker item |
No spam protection for shoutbox users
The user's email address is clearly visible in the html source. Interestingly, user gern22000 is affected, admin is not: http://www.vic-fontaine.com/forum/ Test user and password (if required): smarty |
tracker item |
on |
tracker item |
open redirect vulnerability on banner_click.php | tracker item |
Optional disabling on javascript stripping protection
Tiki, be default, strips all javascript from all text box entries. This is meant as a security protection. While most of the time, this is a good thing, sometimes, it is appropriate to use this javascript. For example, an add placed in a dynamic content module. |
tracker item |
Password manager
Teams collaborate on various things. Data is shared. But what about passwords? This would be useful in Tiki community to share control of twitter account, mailing list admin password, etc. The data would need to be encrypted in the database, only to be revealed to users with the proper credentials. Examples of services: https://online.roboform.com/ https://lastpass.com/ http://passpack.com/ Open Source software http://keepass.info/ http://passwordsafe.sourceforge.net/ Open Source with hosted version available: http://www.clipperz.com/open_source/clipperz_community_edition |
tracker item |
Password shown in clear under some circumstances | tracker item |
Path disclosure bug in trackers
Details sent to security squad. |
tracker item |
PHPIDS (PHP-Intrusion Detection System) | tracker item |
Plugin html should have security, and pass code exactly as is
1- not strip object, javascript, codebase, etc tags 2- not to treat line changes as br (like wiki syntax does and sometimes causes issues. If this should be optional, default should be to treat as is. |
tracker item |
Plugin validation does not work, TW50B1
~np~ Put a {BACK()/} in page A, and put a {include page="A"} in page B. It does not work because of some other issue with added an if( $_SERVER['REQUEST_METHOD'] == 'POST' && isset( $_POST['plugin_fingerprint'] ) && $_POST['plugin_fingerprint'] == $fingerprint the fingerprints did not match. I am also not sure if the _SERVER['REQUEST_METHOD'] was not there at all. It corrupted the tiki_plugin_security db table, when used for an included page in TW5.0B1. | html-b933b386d5a6f404b361915877be6d01-4041452f21ab9509ffec254939fca6ea-321000-250000 | pending | admin | NULL | 2010-08-15 11:46:03 | wiki page | A | | html-48f4de6e43c09f3cf74cd255f805f7c7-4041452f21ab9509ffec254939fca6ea-321000-250000 | pending | admin | NULL | 2010-08-15 11:47:32 | wiki page | A | | html-49a30ce7af772042003eeed65cff768f-4041452f21ab9509ffec254939fca6ea-321000-250000 | pending | admin | NULL | 2010-08-15 12:03:58 | wiki page | A | | html-485a9a9f59efca1240cea872edd17f15-4041452f21ab9509ffec254939fca6ea-321000-250000 | pending | admin | NULL | 2010-08-15 12:08:13 | wiki page | B | | html-76d0f2549b4f3021f9e5d1cb85b90f89-4041452f21ab9509ffec254939fca6ea-321000-250000 | pending | admin | NULL | 2010-08-15 12:08:30 | wiki page | B | | html-f70217acf0461d1edb3c81e9e60553c9-4041452f21ab9509ffec254939fca6ea-321000-250000 | pending | admin | NULL | 2010-08-15 12:12:32 | wiki page | B | +----------------------------------------------------------------------------------------+---------+-------+-------------+---------------------+-----------------+--------------+ It generates a different fingerprint every time, it seems. Haven't check trunk. Would someone do that? ~/np~ |
tracker item |
Plugin VIMEO needed to be rewritten to vimeo to prevent < x> to show up in the url param at edition time | tracker item |
PluginMediaPlayer should use own copy of flash file and not call the web (added to composer) | tracker item |
Plugins admin interface to activate/deactivate plugins
All plugins are on by default. I may or may not want that. I think we should have an admin panel which lists the plugins which are installed on the server. The admin can then activate as needed. Related: WYSIWYCA for module administration http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1294 |
tracker item |
Possible XSS vulnerability in tiki-ajax_services.php | tracker item |
post install perms on db/local.php | tracker item |
potential security hole related to managing users
See message on the security list related to user administration |
tracker item |
Profiles Repository URLs Are Not Connect
I have installed TikiWiki 3.3 in RHEL 4. Everything works are successfull excepted only Profiles Repository updates. When I click 'list' buton at Profiles Admin pages, the 'Data Channels' are not updated. I think it related with proxy setting. The newly installed TikiWiki is setted up inside network of proxy server. That is the TikiWiki be affected on proxy. My question is that how to set up proxy information within Tikiwiki to successful communicate with 'http://profiles.tikiwiki.org/profiles'? |
tracker item |
Redirect plugin: add wiki= so we can use this plugin without a validation at each page
Redirect plugin can be unsafe when redirecting to any URL. So we have to have an extra validation step. This can be annoying, especially when upgrade large sites or importing hundreds of pages. adding wiki=PageName as a possible parameter would have a result of only needing the admin to validate the plugin once. |
tracker item |
Registration Page does not display and password suggestion does not consider security settings.
Password security requirements (length, letters, numbers, etc.) can be specified in Login-Settings, but they are neither displayed on the registration page, nor considered by the password sugestion box. This is more than an annoyance, since it repells users from registration when they have to re-enter and re-choose a password several times and the sugested passwords don't work either. |
tracker item |
Restrict possible characters in usernames
To be discussed the exact list, but not all characters should be permitted when creating a username. Maybe restrict to the same rules as the prefix in emails. http://www.remote.org/jochen/mail/info/chars.html __Example of problems.__ 1- Do I want a user Stéphane and another stephane? This can create confusion in who is who in forums, etc 2- Apostrophe: http://tikiwiki.org/tiki-user_information.php?userId=11351 This doesn't work everywhere. Related: [http://dev.tikiwiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=195|Username case sensitiveness] [http://dev.tikiwiki.org/tiki-view_tracker_item.php?trackerId=5&itemId=265|Username can't have space in it for messageing system Bug] Notes: __Self-register vs admin vs import__ At one point (not sure if it's still true) it was possible to create a username with a space as admin (tiki-adminusers.php) but not when self-registering (tiki-register.php) To be discussed if the restrictions should be the same. Some could argue that they should be less restrictive for admins. Please also see next point. __Integrating with external authentication system.__ In Tiki, it is not possible to create a username with a space. However, when authenticating against an external system like LDAP, the other system may permits space. How do we handle this? __International use__ What about characters in languages like Hebrew, Mandarin, and Arabic? __Usernames in a URL__ Sometimes, the username is used in a URL (in an email for example). So the simpler it is the less risk there is. UserID vs username I think the trend is to use the userID more & more (in 1.10) vs username. Maybe this makes it simpler, more robust. __ Respecting the environment__ We have to figure how to handle existing Tiki installation with these now invalid usernames. Maybe we just tell the admins to correct manually. Or maybe we just solve "from now on" |
tracker item |
Review .htaccess from HTML5 Boilerplate for security and performance | tracker item |
RSS Calendar Security problem - anonymous users allowed access to secured calendar via RSS link
Preface: This is my first bug entered and I am also *very* new to TikiWiki. With that disclaimer out of the way: The problem is that the RSS calendar link at the bottom of the default install seems that it bypasses or overrides the security. I had set up a restricted category and a restricted calendar tied to that category. I created a user with access and it worked fine. I logged in as a test user to make sure it was working correctly. I could see the public calendar and the public topics but not the restricted ones. I thought this is great. Then, when I was not even logged in as any user, I clicked on the RSS feed at the bottom of the screen and guess what? It showed me all the contents of the restricted calendar and the public calendar, too. Thanks. |
tracker item |
SCRAM-SHA-1(-PLUS) + SCRAM-SHA-256(-PLUS) + SCRAM-SHA-512(-PLUS) + SCRAM-SHA3-512(-PLUS) supports | tracker item |
Secdb automatic check with cron job
SecDB is very useful to check which files have changed and to detect suspicious files. http://doc.tikiwiki.org/Security+Admin Next step would be to run on a cron-job (or pseudo cron-job) and to send an email to the admin (with an easy way for the admin to report the issue to the tikiwiki security team) when it detects the presence of a new file. Related: [tiki-view_tracker_item.php?itemId=1410|Secdb for all files (not just php)] |
tracker item |
Secdb for all files (not just php)
SecDB is very useful to check which files have changed and to detect suspicious files. http://doc.tikiwiki.org/Security+Admin It is also useful when I upgrade a Tiki to see what has been altered or added. It would be nice to have this for all files (images, tpl, etc) Related: Secdb automatic check with cron job http://dev.tikiwiki.org/tiki-view_tracker_item.php?itemId=1354 |
tracker item |
Security
Intrusions, site breakage, lost data |
wiki |
Security bug which bypasses directory site validation.
Have installed 1.9.4 and have found someone able to bypass directory site validation. I was originally at 1.9.1 when I noticed that this was happening and brought everything up to 1.9.4 which seemed to stop the bypass. today they were sucessful again. I have the text that they insert into the directory description entry box. It is very long. In any event, the site becomes a valid site and then shows up in the rss feed. Text not shown here for obvious reasons. |
tracker item |
Security DB and mods don't work together
If I install a mods, it is recognized as a suspicious file (or files) by security DB. |
tracker item |
Security issue in a module
In the hands of the security team. Reported by Gerasan. |
tracker item |
security issue: login issue
First of all thanks for tikiwiki Major SECURITY ISSUE :: This has been reported to security.tikiwiki.org |
tracker item |
Security overview | wiki |
Security problem with sophisticated google hack on local.php (how to clean up after an intrusion)
Intruder injected code into local.php .. not sure whether they were able to actually log into server and change the file manually or were able to get scripts to do it. But the change had these characteristics: 1. when viewing the site directly, everything seems fine 2. on doing a google search on the site, links appear normal but... 3. when you click on the link, it hits the site and the modified TW returns a redirect to something like a random selection of porn servers or whatever. since the addition is in local.php an upgrade does not overwrite it. The hack checks for user agent and if it detects you came in from Google (or other search engines) it does the redirect. Otherwise it just exits. (I've saved a copy of the code and will email to security team if they are interested) |
tracker item |
Security Ticket (admin) timeout | tracker item |
Security Ticket warning when attempting to login | tracker item |
Security:Active XSS in URI allows remote exploitation of user browser
http://www.securityfocus.com/archive/1/501702 Application: TikiWiki Version: 2.2 (latest) Website: www.tikiwiki.org Bug: Active XSS in URI Exploitation: Remote Date: 12 Mar 2009 Discovered by: iliz Author: iliz Contact: e-mail: iliz-z(at)yandex(dot)ru Bug Description: TikiWiki version 2.2 and later uses URI in html response body and fails to sanitize it. Is therefore prune to Active XSS attack. PROOF OF CONCEPT: /tiki-galleries.php/>"><sc /tiki-list_file_gallery.php/>"><sc /tiki-listpages.php/>"><sc /tiki-orphan_pages.php/>"><sc The javascript code will be executed in the context of the victim's browser, this can be exploited to steal cookies and escalate privileges to administrator. Tested with TikiWiki 2.2, Apache 2.2, Mozilla Firefox 3.0.6, InternetExplorer 7, Opera 9.65 -- Verified on http://orionrobots.co.uk running 2.2 using Firefox 3.0.6. |
tracker item |
SecurityDataFlow | wiki |
Setting admin password in the installer, with option to force change at first login
nyloth: in my opinion, a password for admin should be asked inside the installer, no password change should be asked after that, and user should be already logged as admin just after the last step of the installer. marclaporte: I agree but can we have a checkbox, like in admin-users to force admin user to change password at first run? So I deploy snapshot-copies of a lot of Tikis, I am sure that they don't all have same password. |
tracker item |
Should there be two security categories on dev.tiki.org? | tracker item |
site based on 2.2 + tikipedia attacked at tiki-browse_image.php from galleries
See parallel security report through secturity.tw.o with a similar title to: "site based on 2.2 + tikipedia attacked at tiki-browse_image.php from galleries" Site has been disabled by sys admin due to performance issues at the shared hosting due to this attack. I'm upgrading to latest 2.2svn and disabling image galleries in the mean time. --- Update from April 18th 2009 Well, there has not been any other issue after that attack, that seemed to affect this and other x.tw.o sites. There is no evidence of any infection of the tiki sites, and the only problem seemed to be the work load of the server coping with the attack. Thus, I close this bug report. |
tracker item |
smarty_security and tiki_cdn cause Icons missing when using own content delivery network | tracker item |
Social networking complications
First I'll say I am skirting some lines in classification as the "SocialNetworking" feature is not listed in this tracker's options. I selected security because that is an indirect concern. I work for a 200K plus employee tech company and am consulting to another company of similar size. I have been working with TikiWiki to run my department page for the last six years and have been working to promote it elsewhere in these companies. Company size is relevant as an indicator of their data security concern magnitude. I am finally getting traction in making my counterparts at both companies aware of TikiWiki and it's benefits, but with the advent of the external social networking interaction I can guarantee the data security team will see this as a data containment nightmare. Even making social networking available to be turned on by an admin will be seen as problematic and will threaten any further use of TikiWiki. I rated this as a priority 7 because it threatens the my ability to continue running TikWiki at all. Emotional response would have me put it at a 9, however that should be reserved for technically inoperative systems. I chose "bug (usability)" because the presence of the feature threatens the ability to use Tikiwiki at all. I see no problem with the internal social networking aspect features and use them currently to promote a collaborative environment. |
tracker item |
ssl_error_rx_record_too_long when using "Require Secure (HTTPS) login" (CPANEL self-signed cert.)
When using "Reguire Secure (HTTPS) login" you may see this error: An error occurred during a connection to <domain>. SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long) |
tracker item |
Strangely Profile Preview changes button just added the groups from the profile to my freshly installed Tiki | tracker item |
styles/transitions/2.1to3.0.css file vandalized
Apparently, the site http://www.penaoz.org got vandalized, in its file styles/transitions/2.1to3.0.css The practical result is my users getting a warning signal from their antivirus. Which of course drives them away. I am writing this on 24 sept 2009. I will leave the site as such until 26, the time for the hosting provider to see the problem, check logs and so on. |
tracker item |
Take in account the Apache option "AccessFileName"
Hello, Apache offers the option : "AccessFileName" with default value ".htaccess" It would be appropriate to use the option parameter real value either than the default one. This particularly with windows, as it is not possible to rename manually a ".htaccess" file neither save as. The name ".htaccess" is not a valid filename for windows. So, although it is normally red, it is better to use another name. For my own I use often on windows "access.htaccess". The change don't generates an important job and would be opportunely enhanced with a check of the current value of the parameter. trebly ref : trebly:B00805-02 |
tracker item |
Tiki 6.1 and later do not work under IIS 6, while 6.0 did
Using the same IIS web site: *You can install 6.0 and successfully login as admin. *Install 6.1 and 6.2 but neither of them are able to login as admin. Additional details, as per forum post (http://tiki.org/tiki-view_forum_thread.php?comments_parentId=40416&topics_sort_mode=lastPost_desc&forumId=6): Trying to use TW on our IIS web site. Have followed all references I could find but have not been able to get 6.1 going. As a test, I have managed to get 6.0 going, so not sure why 6.1 and 6.2 has issues. Any guidance on how to debug this is appreciated. Thanks. Details are: - Win2003 SP2 and IIS6 - MySQL 5.1 (tried both local and remote server) - PHP 5.2.17 - Firefox 3.6 - No tildes in the URL - Tried placing TW in the root of the web site and as a virtual directory - Have granted the EVERYONE user READ,WRITE & MODIFY access to the web root and all sub folders. - No PHP errors recorded in the PHP error log Symptoms: - Install proceeds successfully. - DB install states that is is successful (both local and remote DB scenarios) - Prompted with admin change password screen and successfully change the password. - Prompted with the Home page, then login as admin and new password, only to be presented with the Home page again, which states: "Congratulations This is the default homepage for your Tiki. If you are seeing this page, your installation was successful. You can change this page after logging in. Please review the wiki syntax(external link) for editing details." - Try clearing cookies, then logging in and are presented with "You have to enable cookies to be able to login to this site". |
tracker item |
tiki_p_search makes users "admin"
Hello if i have tiki_p_search-permission so i have all "tiki"-perms too :-( How can i configure a group (or all users / anonymous) that they can use "search" (most important function of a wiki, i think) whithout make them admin? |
tracker item |
tikiwiki version 1.9.5 (CVS) -Sirius- mysql password disclosure & xss
there's a critical security bug in tikiwiki version 1.9.5 (CVS) -Sirius- a anonymous user can dump the mysql user & passwd just by creating a mysql error with the "sort_mode" var , with those following links : /tiki-listpages.php?offset=0&sort_mode= /tiki-lastchanges.php?days=1&offset=0&sort_mode= /messu-archive.php?sort_mode= /messu-mailbox.php?sort_mode= /messu-sent.php?sort_mode= /tiki-directory_add_site.php?sort_mode= /tiki-directory_ranking.php?sort_mode= /tiki-directory_search.php?sort_mode= /tiki-forums.php?sort_mode= /tiki-view_forum.php?forumId= /tiki-friends.php?sort_mode= /tiki-list_blogs.php?sort_mode= /tiki-list_faqs.php?sort_mode= /tiki-list_trackers.php?sort_mode= /tiki-list_users.php?sort_mode= /tiki-my_tiki.php?sort_mode= /tiki-notepad_list.php?sort_mode= /tiki-orphan_pages.php?sort_mode= /tiki-shoutbox.php?sort_mode= /tiki-usermenu.php?sort_mode= /tiki-webmail_contacts.php?sort_mode= i did install tikiwiki 1.9.5 the 31 october 2006 , i did try this on my dedicated server & in local on my computer . a proof of concept is disponible here : http://cockor.free.fr/PoC.swf there's also a xss here : /tiki-featured_link.php?type=f&url=" ></iframe>alert('XSS') <!-- regards , securfrog |
tracker item |
topic permissions not working in tiki-list_articles.php
Upgraded from 1.8 -> 1.9 -> 2.0 -> 2.2. In version 2.0 and above, anonymous users can list all articles despite topic permissions that should restrict listing to topicID of 0 or "public". |
tracker item |
Trackback pings should not use fopen to open urls.
Bloglib uses fopen to get data from a url. This should be avoided due to security and environments where the tiki server is secured (firewall/proxy), where fopen will not work. Affected function: function send_trackbacks($id, $trackbacks) |
tracker item |
Tracker field password or tracker field text enhancement (require visibility fix permissions) | tracker item |
Trackers: ratings fake vote by URL
{img src=show_image.php?id=9 } |
tracker item |
Update https://doc.tiki.org/General-Security re risky preferences | tracker item |
Upgrade to rel 4 : No permissions for user "admin"
Hello, got this message during database upgrade: "Category permissions have been revamped in version 4. If you have been using category permissions, note that they may not work properly after upgrading to version 4, and it will be necessary to reconfigure them." I am not using Categories at all. On both my websites which I upgraded from 3.1 to 4.1, after upgrade the Admin-user has no permisssions at all! I had to go back to rel 3 since I cannot find any instructions on your website. Peter peter@peter5.com |
tracker item |
URL_ID replaced in a link
well i encountered a problem with a link from http://portal.unesco.org/ if you want to link to a page there like http://portal.unesco.org/en/ev.php-url_ID=32886&URL_DO=DO_TOPIC&URL_SECTION=201.html the URL part of the link will be replaced with ~np ur this destroys the link used tw2.0 |
tracker item |
User information becomes public when set to private
If the user information is set to be Private, the user information is shown in tooltip to Anonymous users. Anonymous users also get a link to the user information, but it tells the user that he/she is not logged in. If the user information is set to public, no tooltip is shown and link is active. Environment: TikiWiki 3.1, danish translation |
tracker item |
User Information Page shows non-public wiki page titles
Wiki Pages that are in non-public categories (or are otherwise not accessible by anonymous) should not be viewable. This error has been fixed in other places (like RSS). However, this page: http://www.michaelrisch.com/tiki/tiki-user_information.php?userId=XXX shows non-publicly accessible wiki page names. Clicking on the name (thankfully) raises the security error, but the name shouldn't be visible in the first place. This is in 3.x - not sure if it is a problem in 1.9 or 2.x, though I would suspect so. |
tracker item |
User w/o page Viewing permission can still edit & view the page, and lock others out. | tracker item |
Using preg_replace with /e modifier
Tikiwiki is using preg_replace with /e modifier. On some systems this feature is disabled. You can neither access the installscript nor will there be any emails sent. The email-script simple dies with no further information. |
tracker item |
Validation | tracker item |
Vulnerability in registrating
Tiki Version 1.9.7. Not disclosing the vulnerability here, please contact me asap. URGENT !!! onno.paap@gmail.com |
tracker item |
Warning: is_dir(): Stat failed for ./img/wiki_up/tiki1/... intiki-admin_security.php?check_files
When calling this url: http://uniwiki.ourproject.org/tiki-admin_security.php?check_files on an updated (today 6th sept. 2006) 1.10cvs site, I get this warning on top: ^ Warning: is_dir(): Stat failed for ./img/wiki_up/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun/ecofun (errno=40 - Too many levels of symbolic links) in /var/lib/gforge/chroot/home/groups/uniwiki/htdocs/tiki-admin_security.php on line 153 ^ And the display is kind of weird (the page is displayed). This site is a multitiki installation, but "ecofun" is not the domain in which I was running the tiki site, but another (ecofun would have been: http://uniwiki.ecofun.ourproject.org/tiki-admin_security.php?check_files , and I was not on that tiki site). I wonder if this is important, and security check is working fine or not (I'm wondering if I have more intruder's files, as some which I deleted manually yesterday) |
tracker item |
Web Auth Needs Some Fine Tuning
With Web Auth there are some issues with conflicting features and the User Administration Process. 1) FEATURE REQUEST: Should be able to point to the relevant file that contains the .htpasswd information. It would be outstanding if TikiWiki could parse/edit this file so it can also act as a front end for user password control and distribution. TWiki does this. 2) BUG/CONFLICT When adding users to TikIWiki, the username naturally has to match the username already set for the .htpasswd file. However, one is not allowed to set a 0-length password for that user. This appears to force the admin to enter _something_ but it also appears that this something has no effect<?> The user who logs in to the htpasswd protected realm will naturally be logged into the TikiWiki account with the same name (as described) but the different password is irrelevant. |
tracker item |
Web site search page XSS Vulnerability
Hello, This flaw was found in the search page "TIKI WIKI," which allows XSS attacks when a User is an argument in the variable "words" with a code for XSS. The failure occurs on the search page when it tries to recover the value passed in the variable "words", the server tries to redirect to tags <a> some links in the value paced past. But the server does not check the value and allows the execution of JavaScript code with a code like this. http://info.tiki.org/tiki-searchresults.php?searchLang=en&words=111%22%20on Vulnerable code in HTML code: <span class="button"><a href="http://doc.tiki.org/tiki-searchresults.php?words=111" on <span class="button"><a href="http://www.google.com/search?q=tikiwiki+111" on <span class="button"><a href="http://www.google.com/search?q=site:tiki.org 111" on I could see how we can add an event "on Kind Regards, Mario Gomes. |
tracker item |
Wiki cache & plugins: WYSIWYCA problem when admin visits the page (and creates the cache)
Please see screenshot attached. (10:37:49) marclaport1: I tried turning on the wiki cache feature, but the problem is that if an editor or an admin last visited the page, the edit buttons are show to anonymous (ex.: in wiki plugin articles is in a wiki page to show last 3 articles) (10:38:15) marclaport1: Shouldn't wiki cache feature just cache what anonymous people see? (10:38:41) marclaport1: Anonymous is normally the largest "group" of visitors. (10:41:09) sylvieg: marclaport: you need to turn ogg the cache for page with plugin? Is it waht you mean? (10:41:24) marclaport1: sylvieg: yes (10:41:58) marclaport1: sylvieg: or even (I think) a wiki page which uses group permission plug |
tracker item |
wiki-edit: footnotes allows html
the footnotes feature allows html. i was able to embedf an javascript into a href element. |
tracker item |
xavi
Contributors |
tracker item |
XSS vulnerability issue B96
We found a cross-site scripting vulnerability. Details have been sent to security.tikiwiki.org |
tracker item |
You cannot have 2 forms using wikiplugin with captcha for anonymous on the same page | tracker item |
Affects BRANCH-1-9 and HEAD (1.10)
(10:37:49) marclaport1: I tried turning on the wiki cache feature, but the problem is that if an editor or an admin last visited the page, the edit buttons are show to anonymous (ex.: in wiki plugin articles is in a wiki page to show last 3 articles)
(10:38:15) marclaport1: Shouldn't wiki cache feature just cache what anonymous people see?
(10:38:41) marclaport1: Anonymous is normally the largest "group" of visitors.
(10:41:09) sylvieg: marclaport: you need to turn ogg the cache for page with plugin? Is it waht you mean?
(10:41:24) marclaport1: sylvieg: yes
(10:41:58) marclaport1: sylvieg: or even (I think) a wiki page which uses group permission plug
See attached screenshot.
Trackerlist plugin can have a few weird side effects:
*Ratings (different people have different votes)
*Sorting (if the person before you sorted by "Lastmod by", that's what you see)
*Related: [bug1137]
((doc:PluginInclude)) can causes issues as well.
Possible solution: only anonymous users can create a cached version of a page (per language). It is very rare that the number of logged in users could saturate a server. However, a large number of anonymous users is frequent. On the other hand, trackerlist plugin cache on dev.tikiwiki.org makes things faster for logged in users as well...