Menu
▾
▴
phpwebsite-developers
|
From: Richard S. <ri...@ri...> - 2003-05-13 05:59:58
|
I think there should be a configuration option to set up 3 SQL users. One user that has the ability to create and drop databases, one user who has the ability to read/insert/update/delete rows from tables, and another user who has the ability to create/drop tables. The reason for this is what is malicious user where to type into a form field SQL code to drop a table? Even better yet, drop a database! That wouldn't be very fun... So my suggestion is when using the core's sqlInsert function for example should use the user account that can read/insert/and only update tables. When installing a mod and usually using sqlImport function should call upon the user who can only create and drop databases. Of course since some people on their hosting providers can only have one SQL user on databases like MySQL that has full control over their database which means the system should automatically check if the other users exist and if not, use the the default user account provided. Many companies practice this as a security rule of thumb and I think this CMS should do so also. Let me know you feed back :-) Best Regards, Richard Sumilang |
|
From: Don S. <do...@se...> - 2003-05-13 12:18:23
|
I don't think this is really necessary. If phpWebSite is somehow tricked into entering SQL code that is entered into a form, then that is the real problem and we need to capture that and exit the save function and give a stern error to the user. Don. On Mon, 12 May 2003, Richard Sumilang wrote: > I think there should be a configuration option to set up 3 SQL users. > One user that has the ability to create and drop databases, one user > who has the ability to read/insert/update/delete rows from tables, and > another user who has the ability to create/drop tables. The reason for > this is what is malicious user where to type into a form field SQL code > to drop a table? Even better yet, drop a database! That wouldn't be > very fun... So my suggestion is when using the core's sqlInsert > function for example should use the user account that can > read/insert/and only update tables. When installing a mod and usually > using sqlImport function should call upon the user who can only create > and drop databases. Of course since some people on their hosting > providers can only have one SQL user on databases like MySQL that has > full control over their database which means the system should > automatically check if the other users exist and if not, use the the > default user account provided. Many companies practice this as a > security rule of thumb and I think this CMS should do so also. > > Let me know you feed back :-) > > Best Regards, > > Richard Sumilang > > > > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise solutions > www.enterpriselinuxforum.com > > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > > > |
|
From: Richard S. <ri...@ri...> - 2003-05-13 15:45:02
|
I think it would be more efficient for people who have access to create more than one SQL user to stop the process from the SQL server rather than taking up any more resources with php. It will be more work to create another function to make sure you don't feature that code in your queries however it's a good idea for people who just have one possible SQL user. Regards, Richard Sumilang. On Tuesday, May 13, 2003, at 05:17 AM, Don Seiler wrote: > I don't think this is really necessary. If phpWebSite is somehow > tricked > into entering SQL code that is entered into a form, then that is the > real > problem and we need to capture that and exit the save function and > give a > stern error to the user. > > Don. > > On Mon, 12 May 2003, Richard Sumilang wrote: > >> I think there should be a configuration option to set up 3 SQL users. >> One user that has the ability to create and drop databases, one user >> who has the ability to read/insert/update/delete rows from tables, and >> another user who has the ability to create/drop tables. The reason for >> this is what is malicious user where to type into a form field SQL >> code >> to drop a table? Even better yet, drop a database! That wouldn't be >> very fun... So my suggestion is when using the core's sqlInsert >> function for example should use the user account that can >> read/insert/and only update tables. When installing a mod and usually >> using sqlImport function should call upon the user who can only create >> and drop databases. Of course since some people on their hosting >> providers can only have one SQL user on databases like MySQL that has >> full control over their database which means the system should >> automatically check if the other users exist and if not, use the the >> default user account provided. Many companies practice this as a >> security rule of thumb and I think this CMS should do so also. >> >> Let me know you feed back :-) >> >> Best Regards, >> >> Richard Sumilang >> >> >> >> ------------------------------------------------------- >> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara >> The only event dedicated to issues related to Linux enterprise >> solutions >> www.enterpriselinuxforum.com >> >> _______________________________________________ >> Phpwebsite-developers mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers >> >> >> > > > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise > solutions > www.enterpriselinuxforum.com > > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > > |
|
From: <ad...@tu...> - 2003-05-13 17:33:46
|
A big issue with creating multiple database users to access different database functions is the fact that a lot of our users host with hosting companies that only allow them one database/user/pass. The core's PHPWS_TExt::parseInput function could be updated to check for submitted sql queries and remove them without too much fuss and it's already in place on most input fields. This would allow ALL users to take advantage of this added security. Just my 2 cents. Adam > I think it would be more efficient for people who have access to create > more than one SQL user to stop the process from the SQL server rather > than taking up any more resources with php. It will be more work to > create another function to make sure you don't feature that code in > your queries however it's a good idea for people who just have one > possible SQL user. > > Regards, > > Richard Sumilang. > > On Tuesday, May 13, 2003, at 05:17 AM, Don Seiler wrote: > >> I don't think this is really necessary. If phpWebSite is somehow >> tricked >> into entering SQL code that is entered into a form, then that is the >> real >> problem and we need to capture that and exit the save function and >> give a >> stern error to the user. >> >> Don. >> >> On Mon, 12 May 2003, Richard Sumilang wrote: >> >>> I think there should be a configuration option to set up 3 SQL users. >>> One user that has the ability to create and drop databases, one user >>> who has the ability to read/insert/update/delete rows from tables, and >>> another user who has the ability to create/drop tables. The reason for >>> this is what is malicious user where to type into a form field SQL >>> code >>> to drop a table? Even better yet, drop a database! That wouldn't be >>> very fun... So my suggestion is when using the core's sqlInsert >>> function for example should use the user account that can >>> read/insert/and only update tables. When installing a mod and usually >>> using sqlImport function should call upon the user who can only create >>> and drop databases. Of course since some people on their hosting >>> providers can only have one SQL user on databases like MySQL that has >>> full control over their database which means the system should >>> automatically check if the other users exist and if not, use the the >>> default user account provided. Many companies practice this as a >>> security rule of thumb and I think this CMS should do so also. >>> >>> Let me know you feed back :-) >>> >>> Best Regards, >>> >>> Richard Sumilang >>> >>> >>> >>> ------------------------------------------------------- >>> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara >>> The only event dedicated to issues related to Linux enterprise >>> solutions >>> www.enterpriselinuxforum.com >>> >>> _______________________________________________ >>> Phpwebsite-developers mailing list >>> Php...@li... >>> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers >>> >>> >>> >> >> >> ------------------------------------------------------- >> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara >> The only event dedicated to issues related to Linux enterprise >> solutions >> www.enterpriselinuxforum.com >> >> _______________________________________________ >> Phpwebsite-developers mailing list >> Php...@li... >> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers >> >> > > > > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise solutions > www.enterpriselinuxforum.com > > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > -- Adam Morton Developer - Electronic Student Services http://phpwebsite.appstate.edu Founder - Appalachian Linux Users Group http://alug.appstate.edu |
|
From: Eloi G. <el...@re...> - 2003-05-15 22:40:01
|
Hey all!
While working on TalkBox (I finally named it!) I again ran into a conceptual
problem of how to implement group-based display authorizations. The
string-based approach causes a severe memory problem when you have to load
10,000 rows of _id and _groups and then start unset()ing the unauthorized
ones.
As a test, I reconfigured ArticleManager to utilize a lookup table-based
system. It worked a lot better in terms of memory outlay. However, there
was still a problem in how other modules like FatCat and TalkBox would be
able to access the group restrictions for all other modules in 1 sql
statement.
The solution I came up with is a central table with 3 columns:
# --------------------------------------------------------
# TABLE DESCRIPTION:
# A summary table listing all groups that are authorized to
# access a specific module's item.
# If all groups can access/view a particular item then
# no entry will exist in this table for that item_id
# & module_title.
#
# NORMAL USAGE:
# group_id is compared against a string containing
# comma-delimited group ids.
#
# EXAMPLE SQL:
# 'WHERE item_id='.$item.' AND module_title='.$module
# .'AND group_id IN ('
# .implode(',', array_keys($_SESSION['OBJ_user']->groups))
# .')'
#
CREATE TABLE mod_authgroups (
group_id int unsigned NOT NULL default '0',
module_title varchar(20) NOT NULL default '',
item_id int unsigned NOT NULL default '0',
key (item_id),
key (group_id)
);
This way, if any module needs to access the group requirements of any other
module, they'll automatically know where to look and they won't have to
generate a separate sql query for each module scanned. copies of Group
strings won't have to get stored in fatcat or approval or whatever else
comes down the road.
Approval? Criticism? Any thoughts?
-Eloi George-
|
|
From: Jeremy A. <ja...@tu...> - 2003-05-13 17:40:03
|
One point i would like to add. Even a restricted user can cause problems. With what is proposed, the account would still have delete options. Any malicious user can just have it cycle through and delete all the content. True it is harder but you get a false seance of security even with a restricted sql user. Bots can batch attack and you are still out of luck. The code should be the main line of security not the sql user. This doesn't mean you should not separate different sites to restricted users. Each not allowed to see/use each other. > I think there should be a configuration option to set up 3 SQL users. > One user that has the ability to create and drop databases, one user > who has the ability to read/insert/update/delete rows from tables, and > another user who has the ability to create/drop tables. The reason for > this is what is malicious user where to type into a form field SQL code > to drop a table? Even better yet, drop a database! That wouldn't be > very fun... So my suggestion is when using the core's sqlInsert > function for example should use the user account that can > read/insert/and only update tables. When installing a mod and usually > using sqlImport function should call upon the user who can only create > and drop databases. Of course since some people on their hosting > providers can only have one SQL user on databases like MySQL that has > full control over their database which means the system should > automatically check if the other users exist and if not, use the the > default user account provided. Many companies practice this as a > security rule of thumb and I think this CMS should do so also. > > Let me know you feed back :-) > > Best Regards, > > Richard Sumilang > > > > ------------------------------------------------------- > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara > The only event dedicated to issues related to Linux enterprise solutions > www.enterpriselinuxforum.com > > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > -- Jeremy Agee phpWebSite Development Team (http://phpwebsite.appstate.edu) Appalachian State University SF.net id: jagee or 94756 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X