Re: Preventing Injection - Client Side
From: David Gugick (david.gugick-nospam_at_quest.com)
Date: 11/10/05
- Next message: Dan Guzman: "Re: Preventing Injection - Client Side"
- Previous message: Howard Hoffman: "Re: SQL Server 2005 - Start Up Error 17113"
- In reply to: willy: "Preventing Injection - Client Side"
- Next in thread: Dan Guzman: "Re: Preventing Injection - Client Side"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 9 Nov 2005 18:49:04 -0500
willy wrote:
> Tables - Create Drop Read Write
> SPs -- Create Execute
>
> In addition the program needs to read from
>
> system_user
> db_name()
>
> information_schema.tables
> Information_schema.columns
> sysobjects
Who is the owner of these tables? Are they owned by "dbo"? If so, all
users would have to be aliased as the dbo in the database, which means
they probably have too many rights. They could be limited to creating
tables under their user names (e.g. Joe.MyTable), but this would not
give other users access to these tables. Creating and Dropping tables is
generally a system admin or database owner function and not normal for
an application. Unless, of course, you mean temp tables.
To perform DML operations on tables, I would use stored procedures. You
can use them for SELECT statements as well, but some users choose to
embed SQL in the app (I prefer SPs all around).
The other objects/functions are available to all users.
Maybe you could explain the need to create/drop tables a little more.
Same for stored procedures.
-- David Gugick Quest Software www.imceda.com www.quest.com
- Next message: Dan Guzman: "Re: Preventing Injection - Client Side"
- Previous message: Howard Hoffman: "Re: SQL Server 2005 - Start Up Error 17113"
- In reply to: willy: "Preventing Injection - Client Side"
- Next in thread: Dan Guzman: "Re: Preventing Injection - Client Side"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|