PostNuke
Flexible Content Management System
News
Unauthorized access to modules using BSCI Permissions
There is a bug in the index.php file included with the BSCIpermissions module. A protected module can be accessed by using the old module calling method. For example:
index.php?name=ModName&file=index
The bug exists for both the Xanthia and pnHTML versions of the module. Anyone using version 1.0.4 or earlier should upgrade immediately to prevent unauthorized access to their modules.
An updated version can be found here.
Sorry for the inconvenience.
Chris Miller
index.php?name=ModName&file=index
The bug exists for both the Xanthia and pnHTML versions of the module. Anyone using version 1.0.4 or earlier should upgrade immediately to prevent unauthorized access to their modules.
An updated version can be found here.
Sorry for the inconvenience.
Chris Miller
New Permissions Module for PostNuke
The first version of the BSCI Permissions module wasn't a module at all. The code was written about a year ago to work with PHP-Nuke 6.0 to control access to my production website. After about 3-4 months of using PHP-Nuke I made the switch to PostNuke. At that point in time I re-wrote the code as a PostNuke module. That version of code is currently running on my site. You can see the effects of the code by going to >www.bariatricsupportcenter.com. You will not find any information about this module at that site. You can use it to view the effects of the module but I would request that you only register on the site if you are interested in the topics related to the site. The module itself can be found at >http://noc.postnuke.com/projects/bscipermissions.
The current version of the module is designed to use Xanthia and pnRender. The production site is not currently using Xanthia since it hasn't been officially released yet. You can find Xanthia >here. I would put up a link to my dev box where you could see this latest version, but it is on a dynamic ip address that changes every couple of hours so it is out of the question. The solution....Install it yourself and give it a try.
Access to the various modules is defined by group. Anonymous, Registered User, Admin, or any any other group that you have defined in the Groups module of PostNuke (NS-Groups). If you want a certain group to have access to a module you just go to the BSCIpermissions Administration section and choose the module. Then put a check next to each group that you want to be able to access the module. It's that easy. If you want to temporarily disable access to a module on your site, just remove all the checks for each of the groups for that module. You can set the permissions on a module so that it can only be accessed by an admin. This allows you to install a module and test it's functionality without giving every user access to the module until you know that it works properly.
You may be asking yourself why you would need this module. You may be saying to yourself "PostNuke already has a permission system it doesn't need another one". To that I would suggest that you try and configure your system to not allow anyone but registered users to access the News module on your site. How about any other 3rd party module that hasn't implemented the PostNuke security system. The ability to grant/deny access to a part of your site shouldn't be limited to the ability of the module designer. Do you know they wrote the module correctly? Are you sure they put the appropriate checks in place for each function? What if they didn't? Do you really want to leave that up to the developer? The BSCI Permissions module leaves the control in the hands of the Systems Administrator where it belongs.
Don't get me wrong. I like the flexibility of the current PostNuke permissions system. That is why I wrote this module to work in conjunction with it. The BSCI Permissions module isn't meant to replace the current permission system. It is meant to enhance it. It is meant to plug the holes that exist in the current system since the current system can't be used to allow/block access to all PostNuke modules. (Since all modules don't implement the PostNuke permissions system.) Even if a module correctly implements the PostNuke permission system it is a difficult system to learn to correctly operate as a Systems Administrator. How many posts have we seen in the forums by people who can't figure it out. The BSCI Permissions system has been designed to be simple enough that even someone who is using PostNuke for the first time can figure it out in a matter of minutes.
Download the files, Read the install file and then take control of your site. See for yourself if it is as easy as I say. I personally think it should be part of the Core PostNuke system. What do you think? Install the files, take it for a test drive and post your comments. What would you change? What would you add? Do you agree with me that it should be part of the Core or do you think it is better to be an add-on? Keep in mind that the module requires that you add approximately 11 lines of code to your main index.php file and your modules.php file. In order to protect ALL modules there needs to be code in the files that load the modules. This is why I think it should be part of the Core. The System Admin should be able to use the system without needing to modify their index.php and modules.php files. The overhead of not using the system is a single call to see if the BSCI Permissions module is activated or not.
Test it out. See if it isn't as easy as I say it is. Once you've used it you won't want to go back.
Chris Miller
The current version of the module is designed to use Xanthia and pnRender. The production site is not currently using Xanthia since it hasn't been officially released yet. You can find Xanthia >here. I would put up a link to my dev box where you could see this latest version, but it is on a dynamic ip address that changes every couple of hours so it is out of the question. The solution....Install it yourself and give it a try.
Access to the various modules is defined by group. Anonymous, Registered User, Admin, or any any other group that you have defined in the Groups module of PostNuke (NS-Groups). If you want a certain group to have access to a module you just go to the BSCIpermissions Administration section and choose the module. Then put a check next to each group that you want to be able to access the module. It's that easy. If you want to temporarily disable access to a module on your site, just remove all the checks for each of the groups for that module. You can set the permissions on a module so that it can only be accessed by an admin. This allows you to install a module and test it's functionality without giving every user access to the module until you know that it works properly.
You may be asking yourself why you would need this module. You may be saying to yourself "PostNuke already has a permission system it doesn't need another one". To that I would suggest that you try and configure your system to not allow anyone but registered users to access the News module on your site. How about any other 3rd party module that hasn't implemented the PostNuke security system. The ability to grant/deny access to a part of your site shouldn't be limited to the ability of the module designer. Do you know they wrote the module correctly? Are you sure they put the appropriate checks in place for each function? What if they didn't? Do you really want to leave that up to the developer? The BSCI Permissions module leaves the control in the hands of the Systems Administrator where it belongs.
Don't get me wrong. I like the flexibility of the current PostNuke permissions system. That is why I wrote this module to work in conjunction with it. The BSCI Permissions module isn't meant to replace the current permission system. It is meant to enhance it. It is meant to plug the holes that exist in the current system since the current system can't be used to allow/block access to all PostNuke modules. (Since all modules don't implement the PostNuke permissions system.) Even if a module correctly implements the PostNuke permission system it is a difficult system to learn to correctly operate as a Systems Administrator. How many posts have we seen in the forums by people who can't figure it out. The BSCI Permissions system has been designed to be simple enough that even someone who is using PostNuke for the first time can figure it out in a matter of minutes.
Download the files, Read the install file and then take control of your site. See for yourself if it is as easy as I say. I personally think it should be part of the Core PostNuke system. What do you think? Install the files, take it for a test drive and post your comments. What would you change? What would you add? Do you agree with me that it should be part of the Core or do you think it is better to be an add-on? Keep in mind that the module requires that you add approximately 11 lines of code to your main index.php file and your modules.php file. In order to protect ALL modules there needs to be code in the files that load the modules. This is why I think it should be part of the Core. The System Admin should be able to use the system without needing to modify their index.php and modules.php files. The overhead of not using the system is a single call to see if the BSCI Permissions module is activated or not.
Test it out. See if it isn't as easy as I say it is. Once you've used it you won't want to go back.
Chris Miller
pnFlashgames Beta sites
Footnote: 1
LAWSUIT PENDING ???
Footnote: 1
PostCalendar Security Advisory PCSA 2004-1
RELEVANT RELEASES
4.0.0
DESCRIPTION
PostCalendar is an online events calendar. Allowing for one time or recurring events and calendar sharing with multiple categories and PostNuke topics integration.
Vulnerable versions can be exploited through SQL injection within the search function.
SOLUTION
It is recommended that all admins upgrade their sites to v4.0.1 or apply the latest security fix package for v4.0.1 available right now from the locations listed below.
REFERENCES
No references are currently available on the net.
UPDATED PACKAGES
1. PostCalendar 4.0.1 Fullpackage (.zip format)
http://noc.postnuke.com/download.php/243/postcalendar-4.0.1.zip
MD5 checksum: 85f28144f36b1487366f654f4f800830
2. PostCalendar 4.0.1 fixed files only (.zip format)
http://noc.postnuke.com/download.php/244/postcalendar-4.0.1-fixpackage.zip
MD5 checksum: 4b5fd57053c8577eeefef50cd1d19279
ADDITIONAL INSTRUCTIONS
Just replace the files contained in this patch into your PostCalendar directory to have your PC patched. Remember that a backup/dump is always a good idea prior to any update.
CREDITS
This exploit has been originally found by Klavs Klavsen and the Security Forum Denmark (sikkerhedsforum.dk) and has been reported on 2003-12-10.
4.0.0
DESCRIPTION
PostCalendar is an online events calendar. Allowing for one time or recurring events and calendar sharing with multiple categories and PostNuke topics integration.
Vulnerable versions can be exploited through SQL injection within the search function.
SOLUTION
It is recommended that all admins upgrade their sites to v4.0.1 or apply the latest security fix package for v4.0.1 available right now from the locations listed below.
REFERENCES
No references are currently available on the net.
UPDATED PACKAGES
1. PostCalendar 4.0.1 Fullpackage (.zip format)
http://noc.postnuke.com/download.php/243/postcalendar-4.0.1.zip
MD5 checksum: 85f28144f36b1487366f654f4f800830
2. PostCalendar 4.0.1 fixed files only (.zip format)
http://noc.postnuke.com/download.php/244/postcalendar-4.0.1-fixpackage.zip
MD5 checksum: 4b5fd57053c8577eeefef50cd1d19279
ADDITIONAL INSTRUCTIONS
Just replace the files contained in this patch into your PostCalendar directory to have your PC patched. Remember that a backup/dump is always a good idea prior to any update.
CREDITS
This exploit has been originally found by Klavs Klavsen and the Security Forum Denmark (sikkerhedsforum.dk) and has been reported on 2003-12-10.
Have we forgotten the way PostNuke handles content?
Think of PostNuke allowing us to create content elements and specify what that content element will be like. For news we would specify a title which will be text, for the story we would specify a body and an extended body which will be text as well, a publish date which will be a date and a topic which might be an image. The system would eventually have built-in ways of handling the different types that will make up a content element and will allow more powerful content handling. Think of how it will then be able to extend certain content types like images to allow us uploading or modifying them, documents allowing us to keep different versions, work flow allowing us to specify a working process to manage our content.
What has changed in that part of the system since the fork from PostNuke? Well not much as I see it. I have not heard any plans for that part of the system and this is the main reason I am writing to point out this problem. What I mentioned above would allow us to extend and customize the main functionality PostNuke has out of the box like news, reviews, articles, downloads, links and FAQ. Many will argue that many different modules are around that do just about anything but I don’t mean by using modules or anything but allowing us to customize the way PostNuke holds content. A core content module could replace all those modules and provide the means for creating content elements like them but also allowing us to customize and give more power to the developer and bring PostNuke to another level.
I currently run 2 sites which are built upon PostNuke. www.cyusers.com a Greek localized site for Cypriot computing enthusiasts. www.cygaming.net an English site for Cypriot gaming enthusiasts. And I am concerned on PostNuke’s future and especially the way it handles and allows us to customize content.
What has changed in that part of the system since the fork from PostNuke? Well not much as I see it. I have not heard any plans for that part of the system and this is the main reason I am writing to point out this problem. What I mentioned above would allow us to extend and customize the main functionality PostNuke has out of the box like news, reviews, articles, downloads, links and FAQ. Many will argue that many different modules are around that do just about anything but I don’t mean by using modules or anything but allowing us to customize the way PostNuke holds content. A core content module could replace all those modules and provide the means for creating content elements like them but also allowing us to customize and give more power to the developer and bring PostNuke to another level.
I currently run 2 sites which are built upon PostNuke. www.cyusers.com a Greek localized site for Cypriot computing enthusiasts. www.cygaming.net an English site for Cypriot gaming enthusiasts. And I am concerned on PostNuke’s future and especially the way it handles and allows us to customize content.
ISSHO: Language Filter - Software Release and Call for Development
LanguageFilter Page - Links to demo pages and CVS at SourceForge Chief Developer: Dom GiovannangeliStable branch requires the feed to be compatible with Postnuke API (PostNuke, Envolution, MDPro, etc.). The development branch aims to provide broader support. User can set language preference with checkbox. For use with PostNuke compatible sites feeds. Development branch aims to provide broader support.
- Development Status: Alpha
- License: GNU General Public License (GPL)
- Programming Language: PHP, PL/SQL
Footnote: 1
Page 35 / 277 (341 - 350 of 2763 Total)
