I noticed a table named 'd99_tmp' in my SQL Server 2000 db. I nor
anyone on my team creatd the this table. The fields are
'subdirectory', 'depth' and 'file'. It contains basically the entire
file structure of the D: drive on the server.
The table has the permissions of the web application that uses that
SQL Server database.
This appears to be a SQL Injection attack and I know that there is
some dynamic SQL used in the application.
Any suggestions (other than removing all of the public facing dynamic
SQL)?
Thanks!Hi
"gdunnjr" wrote:
> I noticed a table named 'd99_tmp' in my SQL Server 2000 db. I nor
> anyone on my team creatd the this table. The fields are
> 'subdirectory', 'depth' and 'file'. It contains basically the entire
> file structure of the D: drive on the server.
> The table has the permissions of the web application that uses that
> SQL Server database.
> This appears to be a SQL Injection attack and I know that there is
> some dynamic SQL used in the application.
> Any suggestions (other than removing all of the public facing dynamic
> SQL)?
> Thanks!
>
Check out http://www.sommarskog.se/dynamic_sql.html#SQL_injection and the
rest of the article about dynamic SQL. Make sure that overall you have
tightened up permissions so the minimum access is granted to provide the
functionality required. You could run Best Practice Analyser
http://www.microsoft.com/downloads/...&displaylang=en and the Microsoft Security Assessment
Tool https://www.securityguidance.com/faq.htm reading the Windows Server
2003 Security Guide may also help
http://www.microsoft.com/downloads/...&displaylang=en
John|||"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:172DFD61-F6D1-496A-B591-79B4B3F1EF0A@.microsoft.com...
> Hi
> "gdunnjr" wrote:
>
Exactly that. :-)
But also make sure the user doesn't have DDL permissins like that.
Won't prevent all SQL Injection attacks, but if the user can't
create/drop/alter tables (or execute xp_cmdshell) you'll be a lot better
off.
[vbcol=seagreen]
> Check out http://www.sommarskog.se/dynamic_sql.html#SQL_injection and the
> rest of the article about dynamic SQL. Make sure that overall you have
> tightened up permissions so the minimum access is granted to provide the
> functionality required. You could run Best Practice Analyser
> http://www.microsoft.com/downloads/...&displaylang=en
> and the Microsoft Security Assessment
> Tool https://www.securityguidance.com/faq.htm reading the Windows Server
> 2003 Security Guide may also help
> http://www.microsoft.com/downloads/...&displaylang=en
> John
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||Thanks for the information. I verified that the application user does
not have access to xp_cmdshell.
But the application user is assigned the role "db_owner". I would like
to remove that role and assign the roles: db_reader and db_writer.
I know that db_owner lets you execute DDL statements, but what are the
other major priviliges the user lose and/or risks of changing the user
from db_owner to db_reader and db_writer?
On Apr 12, 9:56 am, "Greg D. Moore \(Strider\)"
<mooregr_deletet...@.greenms.com> wrote:
> "John Bell" <jbellnewspo...@.hotmail.com> wrote in message
> news:172DFD61-F6D1-496A-B591-79B4B3F1EF0A@.microsoft.com...
>
>
>
>
>
>
>
>
> Exactly that. :-)
> But also make sure the user doesn't have DDL permissins like that.
> Won't prevent allSQLInjectionattacks, but if the user can't
> create/drop/alter tables (or execute xp_cmdshell) you'll be a lot better
> off.
>
>
>
>
> --
> Greg MooreSQLServer DBA Consulting Remote and Onsite available!
> Email:sql (at) greenms.com [url]http://www.greenms.com/sqlserver.html-[/url
] Hide quoted text -
> - Show quoted text -|||"gdunnjr" <gdunnjr@.gmail.com> wrote in message
news:1176467724.629968.31880@.y5g2000hsa.googlegroups.com...
> Thanks for the information. I verified that the application user does
> not have access to xp_cmdshell.
> But the application user is assigned the role "db_owner". I would like
> to remove that role and assign the roles: db_reader and db_writer.
> I know that db_owner lets you execute DDL statements, but what are the
> other major priviliges the user lose and/or risks of changing the user
> from db_owner to db_reader and db_writer?
Make sure the user has all stored procs, functions execution privileges (at
least all it should.)
> On Apr 12, 9:56 am, "Greg D. Moore \(Strider\)"
> <mooregr_deletet...@.greenms.com> wrote:
>
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html
Showing posts with label team. Show all posts
Showing posts with label team. Show all posts
Friday, February 17, 2012
d99_tmp
I noticed a table named 'd99_tmp' in my SQL Server 2000 db. I nor
anyone on my team creatd the this table. The fields are
'subdirectory', 'depth' and 'file'. It contains basically the entire
file structure of the D: drive on the server.
The table has the permissions of the web application that uses that
SQL Server database.
This appears to be a SQL Injection attack and I know that there is
some dynamic SQL used in the application.
Any suggestions (other than removing all of the public facing dynamic
SQL)?
Thanks!
Hi
"gdunnjr" wrote:
> I noticed a table named 'd99_tmp' in my SQL Server 2000 db. I nor
> anyone on my team creatd the this table. The fields are
> 'subdirectory', 'depth' and 'file'. It contains basically the entire
> file structure of the D: drive on the server.
> The table has the permissions of the web application that uses that
> SQL Server database.
> This appears to be a SQL Injection attack and I know that there is
> some dynamic SQL used in the application.
> Any suggestions (other than removing all of the public facing dynamic
> SQL)?
> Thanks!
>
Check out http://www.sommarskog.se/dynamic_sql.html#SQL_injection and the
rest of the article about dynamic SQL. Make sure that overall you have
tightened up permissions so the minimum access is granted to provide the
functionality required. You could run Best Practice Analyser
http://www.microsoft.com/downloads/details.aspx?FamilyId=B352EB1F-D3CA-44EE-893E-9E07339C1F22&displaylang=en and the Microsoft Security Assessment
Tool https://www.securityguidance.com/faq.htm reading the Windows Server
2003 Security Guide may also help
http://www.microsoft.com/downloads/details.aspx?FamilyID=8A2643C1-0685-4D89-B655-521EA6C7B4DB&displaylang=en
John
|||"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:172DFD61-F6D1-496A-B591-79B4B3F1EF0A@.microsoft.com...[vbcol=seagreen]
> Hi
> "gdunnjr" wrote:
Exactly that. :-)
But also make sure the user doesn't have DDL permissins like that.
Won't prevent all SQL Injection attacks, but if the user can't
create/drop/alter tables (or execute xp_cmdshell) you'll be a lot better
off.
> Check out http://www.sommarskog.se/dynamic_sql.html#SQL_injection and the
> rest of the article about dynamic SQL. Make sure that overall you have
> tightened up permissions so the minimum access is granted to provide the
> functionality required. You could run Best Practice Analyser
> http://www.microsoft.com/downloads/details.aspx?FamilyId=B352EB1F-D3CA-44EE-893E-9E07339C1F22&displaylang=en
> and the Microsoft Security Assessment
> Tool https://www.securityguidance.com/faq.htm reading the Windows Server
> 2003 Security Guide may also help
> http://www.microsoft.com/downloads/details.aspx?FamilyID=8A2643C1-0685-4D89-B655-521EA6C7B4DB&displaylang=en
> John
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html
|||Thanks for the information. I verified that the application user does
not have access to xp_cmdshell.
But the application user is assigned the role "db_owner". I would like
to remove that role and assign the roles: db_reader and db_writer.
I know that db_owner lets you execute DDL statements, but what are the
other major priviliges the user lose and/or risks of changing the user
from db_owner to db_reader and db_writer?
On Apr 12, 9:56 am, "Greg D. Moore \(Strider\)"
<mooregr_deletet...@.greenms.com> wrote:
> "John Bell" <jbellnewspo...@.hotmail.com> wrote in message
> news:172DFD61-F6D1-496A-B591-79B4B3F1EF0A@.microsoft.com...
>
>
>
>
>
> Exactly that. :-)
> But also make sure the user doesn't have DDL permissins like that.
> Won't prevent allSQLInjectionattacks, but if the user can't
> create/drop/alter tables (or execute xp_cmdshell) you'll be a lot better
> off.
>
>
>
> --
> Greg MooreSQLServer DBA Consulting Remote and Onsite available!
> Email:sql (at) greenms.com http://www.greenms.com/sqlserver.html- Hide quoted text -
> - Show quoted text -
|||"gdunnjr" <gdunnjr@.gmail.com> wrote in message
news:1176467724.629968.31880@.y5g2000hsa.googlegrou ps.com...
> Thanks for the information. I verified that the application user does
> not have access to xp_cmdshell.
> But the application user is assigned the role "db_owner". I would like
> to remove that role and assign the roles: db_reader and db_writer.
> I know that db_owner lets you execute DDL statements, but what are the
> other major priviliges the user lose and/or risks of changing the user
> from db_owner to db_reader and db_writer?
Make sure the user has all stored procs, functions execution privileges (at
least all it should.)
> On Apr 12, 9:56 am, "Greg D. Moore \(Strider\)"
> <mooregr_deletet...@.greenms.com> wrote:
>
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html
anyone on my team creatd the this table. The fields are
'subdirectory', 'depth' and 'file'. It contains basically the entire
file structure of the D: drive on the server.
The table has the permissions of the web application that uses that
SQL Server database.
This appears to be a SQL Injection attack and I know that there is
some dynamic SQL used in the application.
Any suggestions (other than removing all of the public facing dynamic
SQL)?
Thanks!
Hi
"gdunnjr" wrote:
> I noticed a table named 'd99_tmp' in my SQL Server 2000 db. I nor
> anyone on my team creatd the this table. The fields are
> 'subdirectory', 'depth' and 'file'. It contains basically the entire
> file structure of the D: drive on the server.
> The table has the permissions of the web application that uses that
> SQL Server database.
> This appears to be a SQL Injection attack and I know that there is
> some dynamic SQL used in the application.
> Any suggestions (other than removing all of the public facing dynamic
> SQL)?
> Thanks!
>
Check out http://www.sommarskog.se/dynamic_sql.html#SQL_injection and the
rest of the article about dynamic SQL. Make sure that overall you have
tightened up permissions so the minimum access is granted to provide the
functionality required. You could run Best Practice Analyser
http://www.microsoft.com/downloads/details.aspx?FamilyId=B352EB1F-D3CA-44EE-893E-9E07339C1F22&displaylang=en and the Microsoft Security Assessment
Tool https://www.securityguidance.com/faq.htm reading the Windows Server
2003 Security Guide may also help
http://www.microsoft.com/downloads/details.aspx?FamilyID=8A2643C1-0685-4D89-B655-521EA6C7B4DB&displaylang=en
John
|||"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:172DFD61-F6D1-496A-B591-79B4B3F1EF0A@.microsoft.com...[vbcol=seagreen]
> Hi
> "gdunnjr" wrote:
Exactly that. :-)
But also make sure the user doesn't have DDL permissins like that.
Won't prevent all SQL Injection attacks, but if the user can't
create/drop/alter tables (or execute xp_cmdshell) you'll be a lot better
off.
> Check out http://www.sommarskog.se/dynamic_sql.html#SQL_injection and the
> rest of the article about dynamic SQL. Make sure that overall you have
> tightened up permissions so the minimum access is granted to provide the
> functionality required. You could run Best Practice Analyser
> http://www.microsoft.com/downloads/details.aspx?FamilyId=B352EB1F-D3CA-44EE-893E-9E07339C1F22&displaylang=en
> and the Microsoft Security Assessment
> Tool https://www.securityguidance.com/faq.htm reading the Windows Server
> 2003 Security Guide may also help
> http://www.microsoft.com/downloads/details.aspx?FamilyID=8A2643C1-0685-4D89-B655-521EA6C7B4DB&displaylang=en
> John
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html
|||Thanks for the information. I verified that the application user does
not have access to xp_cmdshell.
But the application user is assigned the role "db_owner". I would like
to remove that role and assign the roles: db_reader and db_writer.
I know that db_owner lets you execute DDL statements, but what are the
other major priviliges the user lose and/or risks of changing the user
from db_owner to db_reader and db_writer?
On Apr 12, 9:56 am, "Greg D. Moore \(Strider\)"
<mooregr_deletet...@.greenms.com> wrote:
> "John Bell" <jbellnewspo...@.hotmail.com> wrote in message
> news:172DFD61-F6D1-496A-B591-79B4B3F1EF0A@.microsoft.com...
>
>
>
>
>
> Exactly that. :-)
> But also make sure the user doesn't have DDL permissins like that.
> Won't prevent allSQLInjectionattacks, but if the user can't
> create/drop/alter tables (or execute xp_cmdshell) you'll be a lot better
> off.
>
>
>
> --
> Greg MooreSQLServer DBA Consulting Remote and Onsite available!
> Email:sql (at) greenms.com http://www.greenms.com/sqlserver.html- Hide quoted text -
> - Show quoted text -
|||"gdunnjr" <gdunnjr@.gmail.com> wrote in message
news:1176467724.629968.31880@.y5g2000hsa.googlegrou ps.com...
> Thanks for the information. I verified that the application user does
> not have access to xp_cmdshell.
> But the application user is assigned the role "db_owner". I would like
> to remove that role and assign the roles: db_reader and db_writer.
> I know that db_owner lets you execute DDL statements, but what are the
> other major priviliges the user lose and/or risks of changing the user
> from db_owner to db_reader and db_writer?
Make sure the user has all stored procs, functions execution privileges (at
least all it should.)
> On Apr 12, 9:56 am, "Greg D. Moore \(Strider\)"
> <mooregr_deletet...@.greenms.com> wrote:
>
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html
d99_tmp
I noticed a table named 'd99_tmp' in my SQL Server 2000 db. I nor
anyone on my team creatd the this table. The fields are
'subdirectory', 'depth' and 'file'. It contains basically the entire
file structure of the D: drive on the server.
The table has the permissions of the web application that uses that
SQL Server database.
This appears to be a SQL Injection attack and I know that there is
some dynamic SQL used in the application.
Any suggestions (other than removing all of the public facing dynamic
SQL)?
Thanks!Hi
"gdunnjr" wrote:
> I noticed a table named 'd99_tmp' in my SQL Server 2000 db. I nor
> anyone on my team creatd the this table. The fields are
> 'subdirectory', 'depth' and 'file'. It contains basically the entire
> file structure of the D: drive on the server.
> The table has the permissions of the web application that uses that
> SQL Server database.
> This appears to be a SQL Injection attack and I know that there is
> some dynamic SQL used in the application.
> Any suggestions (other than removing all of the public facing dynamic
> SQL)?
> Thanks!
>
Check out http://www.sommarskog.se/dynamic_sql.html#SQL_injection and the
rest of the article about dynamic SQL. Make sure that overall you have
tightened up permissions so the minimum access is granted to provide the
functionality required. You could run Best Practice Analyser
http://www.microsoft.com/downloads/details.aspx?FamilyId=B352EB1F-D3CA-44EE-893E-9E07339C1F22&displaylang=en and the Microsoft Security Assessment
Tool https://www.securityguidance.com/faq.htm reading the Windows Server
2003 Security Guide may also help
http://www.microsoft.com/downloads/details.aspx?FamilyID=8A2643C1-0685-4D89-B655-521EA6C7B4DB&displaylang=en
John|||"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:172DFD61-F6D1-496A-B591-79B4B3F1EF0A@.microsoft.com...
> Hi
> "gdunnjr" wrote:
>> I noticed a table named 'd99_tmp' in my SQL Server 2000 db. I nor
>> anyone on my team creatd the this table. The fields are
>> 'subdirectory', 'depth' and 'file'. It contains basically the entire
>> file structure of the D: drive on the server.
>> The table has the permissions of the web application that uses that
>> SQL Server database.
>> This appears to be a SQL Injection attack and I know that there is
>> some dynamic SQL used in the application.
>> Any suggestions (other than removing all of the public facing dynamic
>> SQL)?
Exactly that. :-)
But also make sure the user doesn't have DDL permissins like that.
Won't prevent all SQL Injection attacks, but if the user can't
create/drop/alter tables (or execute xp_cmdshell) you'll be a lot better
off.
>> Thanks!
> Check out http://www.sommarskog.se/dynamic_sql.html#SQL_injection and the
> rest of the article about dynamic SQL. Make sure that overall you have
> tightened up permissions so the minimum access is granted to provide the
> functionality required. You could run Best Practice Analyser
> http://www.microsoft.com/downloads/details.aspx?FamilyId=B352EB1F-D3CA-44EE-893E-9E07339C1F22&displaylang=en
> and the Microsoft Security Assessment
> Tool https://www.securityguidance.com/faq.htm reading the Windows Server
> 2003 Security Guide may also help
> http://www.microsoft.com/downloads/details.aspx?FamilyID=8A2643C1-0685-4D89-B655-521EA6C7B4DB&displaylang=en
> John
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||Thanks for the information. I verified that the application user does
not have access to xp_cmdshell.
But the application user is assigned the role "db_owner". I would like
to remove that role and assign the roles: db_reader and db_writer.
I know that db_owner lets you execute DDL statements, but what are the
other major priviliges the user lose and/or risks of changing the user
from db_owner to db_reader and db_writer?
On Apr 12, 9:56 am, "Greg D. Moore \(Strider\)"
<mooregr_deletet...@.greenms.com> wrote:
> "John Bell" <jbellnewspo...@.hotmail.com> wrote in message
> news:172DFD61-F6D1-496A-B591-79B4B3F1EF0A@.microsoft.com...
>
>
> > Hi
> > "gdunnjr" wrote:
> >> I noticed a table named 'd99_tmp' in mySQLServer 2000 db. I nor
> >> anyone on my team creatd the this table. The fields are
> >> 'subdirectory', 'depth' and 'file'. It contains basically the entire
> >> file structure of the D: drive on the server.
> >> The table has the permissions of the web application that uses that
> >>SQLServer database.
> >> This appears to be aSQLInjectionattack and I know that there is
> >> some dynamicSQLused in the application.
> >> Any suggestions (other than removing all of the public facing dynamic
> >>SQL)?
> Exactly that. :-)
> But also make sure the user doesn't have DDL permissins like that.
> Won't prevent allSQLInjectionattacks, but if the user can't
> create/drop/alter tables (or execute xp_cmdshell) you'll be a lot better
> off.
>
> >> Thanks!
> > Check outhttp://www.sommarskog.se/dynamic_sql.html#SQL_injectionand the
> > rest of the article about dynamicSQL. Make sure that overall you have
> > tightened up permissions so the minimum access is granted to provide the
> > functionality required. You could run Best Practice Analyser
> >http://www.microsoft.com/downloads/details.aspx?FamilyId=B352EB1F-D3C...
> > and the Microsoft Security Assessment
> > Toolhttps://www.securityguidance.com/faq.htmreading the Windows Server
> > 2003 Security Guide may also help
> >http://www.microsoft.com/downloads/details.aspx?FamilyID=8A2643C1-068...
> > John
> --
> Greg MooreSQLServer DBA Consulting Remote and Onsite available!
> Email:sql (at) greenms.com http://www.greenms.com/sqlserver.html- Hide quoted text -
> - Show quoted text -|||"gdunnjr" <gdunnjr@.gmail.com> wrote in message
news:1176467724.629968.31880@.y5g2000hsa.googlegroups.com...
> Thanks for the information. I verified that the application user does
> not have access to xp_cmdshell.
> But the application user is assigned the role "db_owner". I would like
> to remove that role and assign the roles: db_reader and db_writer.
> I know that db_owner lets you execute DDL statements, but what are the
> other major priviliges the user lose and/or risks of changing the user
> from db_owner to db_reader and db_writer?
Make sure the user has all stored procs, functions execution privileges (at
least all it should.)
> On Apr 12, 9:56 am, "Greg D. Moore \(Strider\)"
> <mooregr_deletet...@.greenms.com> wrote:
>> "John Bell" <jbellnewspo...@.hotmail.com> wrote in message
>> news:172DFD61-F6D1-496A-B591-79B4B3F1EF0A@.microsoft.com...
>>
>>
>> > Hi
>> > "gdunnjr" wrote:
>> >> I noticed a table named 'd99_tmp' in mySQLServer 2000 db. I nor
>> >> anyone on my team creatd the this table. The fields are
>> >> 'subdirectory', 'depth' and 'file'. It contains basically the entire
>> >> file structure of the D: drive on the server.
>> >> The table has the permissions of the web application that uses that
>> >>SQLServer database.
>> >> This appears to be aSQLInjectionattack and I know that there is
>> >> some dynamicSQLused in the application.
>> >> Any suggestions (other than removing all of the public facing dynamic
>> >>SQL)?
>> Exactly that. :-)
>> But also make sure the user doesn't have DDL permissins like that.
>> Won't prevent allSQLInjectionattacks, but if the user can't
>> create/drop/alter tables (or execute xp_cmdshell) you'll be a lot better
>> off.
>>
>> >> Thanks!
>> > Check outhttp://www.sommarskog.se/dynamic_sql.html#SQL_injectionand the
>> > rest of the article about dynamicSQL. Make sure that overall you have
>> > tightened up permissions so the minimum access is granted to provide
>> > the
>> > functionality required. You could run Best Practice Analyser
>> >http://www.microsoft.com/downloads/details.aspx?FamilyId=B352EB1F-D3C...
>> > and the Microsoft Security Assessment
>> > Toolhttps://www.securityguidance.com/faq.htmreading the Windows Server
>> > 2003 Security Guide may also help
>> >http://www.microsoft.com/downloads/details.aspx?FamilyID=8A2643C1-068...
>> > John
>> --
>> Greg MooreSQLServer DBA Consulting Remote and Onsite available!
>> Email:sql (at) greenms.com
>> http://www.greenms.com/sqlserver.html- Hide quoted text -
>> - Show quoted text -
>
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html
anyone on my team creatd the this table. The fields are
'subdirectory', 'depth' and 'file'. It contains basically the entire
file structure of the D: drive on the server.
The table has the permissions of the web application that uses that
SQL Server database.
This appears to be a SQL Injection attack and I know that there is
some dynamic SQL used in the application.
Any suggestions (other than removing all of the public facing dynamic
SQL)?
Thanks!Hi
"gdunnjr" wrote:
> I noticed a table named 'd99_tmp' in my SQL Server 2000 db. I nor
> anyone on my team creatd the this table. The fields are
> 'subdirectory', 'depth' and 'file'. It contains basically the entire
> file structure of the D: drive on the server.
> The table has the permissions of the web application that uses that
> SQL Server database.
> This appears to be a SQL Injection attack and I know that there is
> some dynamic SQL used in the application.
> Any suggestions (other than removing all of the public facing dynamic
> SQL)?
> Thanks!
>
Check out http://www.sommarskog.se/dynamic_sql.html#SQL_injection and the
rest of the article about dynamic SQL. Make sure that overall you have
tightened up permissions so the minimum access is granted to provide the
functionality required. You could run Best Practice Analyser
http://www.microsoft.com/downloads/details.aspx?FamilyId=B352EB1F-D3CA-44EE-893E-9E07339C1F22&displaylang=en and the Microsoft Security Assessment
Tool https://www.securityguidance.com/faq.htm reading the Windows Server
2003 Security Guide may also help
http://www.microsoft.com/downloads/details.aspx?FamilyID=8A2643C1-0685-4D89-B655-521EA6C7B4DB&displaylang=en
John|||"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:172DFD61-F6D1-496A-B591-79B4B3F1EF0A@.microsoft.com...
> Hi
> "gdunnjr" wrote:
>> I noticed a table named 'd99_tmp' in my SQL Server 2000 db. I nor
>> anyone on my team creatd the this table. The fields are
>> 'subdirectory', 'depth' and 'file'. It contains basically the entire
>> file structure of the D: drive on the server.
>> The table has the permissions of the web application that uses that
>> SQL Server database.
>> This appears to be a SQL Injection attack and I know that there is
>> some dynamic SQL used in the application.
>> Any suggestions (other than removing all of the public facing dynamic
>> SQL)?
Exactly that. :-)
But also make sure the user doesn't have DDL permissins like that.
Won't prevent all SQL Injection attacks, but if the user can't
create/drop/alter tables (or execute xp_cmdshell) you'll be a lot better
off.
>> Thanks!
> Check out http://www.sommarskog.se/dynamic_sql.html#SQL_injection and the
> rest of the article about dynamic SQL. Make sure that overall you have
> tightened up permissions so the minimum access is granted to provide the
> functionality required. You could run Best Practice Analyser
> http://www.microsoft.com/downloads/details.aspx?FamilyId=B352EB1F-D3CA-44EE-893E-9E07339C1F22&displaylang=en
> and the Microsoft Security Assessment
> Tool https://www.securityguidance.com/faq.htm reading the Windows Server
> 2003 Security Guide may also help
> http://www.microsoft.com/downloads/details.aspx?FamilyID=8A2643C1-0685-4D89-B655-521EA6C7B4DB&displaylang=en
> John
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||Thanks for the information. I verified that the application user does
not have access to xp_cmdshell.
But the application user is assigned the role "db_owner". I would like
to remove that role and assign the roles: db_reader and db_writer.
I know that db_owner lets you execute DDL statements, but what are the
other major priviliges the user lose and/or risks of changing the user
from db_owner to db_reader and db_writer?
On Apr 12, 9:56 am, "Greg D. Moore \(Strider\)"
<mooregr_deletet...@.greenms.com> wrote:
> "John Bell" <jbellnewspo...@.hotmail.com> wrote in message
> news:172DFD61-F6D1-496A-B591-79B4B3F1EF0A@.microsoft.com...
>
>
> > Hi
> > "gdunnjr" wrote:
> >> I noticed a table named 'd99_tmp' in mySQLServer 2000 db. I nor
> >> anyone on my team creatd the this table. The fields are
> >> 'subdirectory', 'depth' and 'file'. It contains basically the entire
> >> file structure of the D: drive on the server.
> >> The table has the permissions of the web application that uses that
> >>SQLServer database.
> >> This appears to be aSQLInjectionattack and I know that there is
> >> some dynamicSQLused in the application.
> >> Any suggestions (other than removing all of the public facing dynamic
> >>SQL)?
> Exactly that. :-)
> But also make sure the user doesn't have DDL permissins like that.
> Won't prevent allSQLInjectionattacks, but if the user can't
> create/drop/alter tables (or execute xp_cmdshell) you'll be a lot better
> off.
>
> >> Thanks!
> > Check outhttp://www.sommarskog.se/dynamic_sql.html#SQL_injectionand the
> > rest of the article about dynamicSQL. Make sure that overall you have
> > tightened up permissions so the minimum access is granted to provide the
> > functionality required. You could run Best Practice Analyser
> >http://www.microsoft.com/downloads/details.aspx?FamilyId=B352EB1F-D3C...
> > and the Microsoft Security Assessment
> > Toolhttps://www.securityguidance.com/faq.htmreading the Windows Server
> > 2003 Security Guide may also help
> >http://www.microsoft.com/downloads/details.aspx?FamilyID=8A2643C1-068...
> > John
> --
> Greg MooreSQLServer DBA Consulting Remote and Onsite available!
> Email:sql (at) greenms.com http://www.greenms.com/sqlserver.html- Hide quoted text -
> - Show quoted text -|||"gdunnjr" <gdunnjr@.gmail.com> wrote in message
news:1176467724.629968.31880@.y5g2000hsa.googlegroups.com...
> Thanks for the information. I verified that the application user does
> not have access to xp_cmdshell.
> But the application user is assigned the role "db_owner". I would like
> to remove that role and assign the roles: db_reader and db_writer.
> I know that db_owner lets you execute DDL statements, but what are the
> other major priviliges the user lose and/or risks of changing the user
> from db_owner to db_reader and db_writer?
Make sure the user has all stored procs, functions execution privileges (at
least all it should.)
> On Apr 12, 9:56 am, "Greg D. Moore \(Strider\)"
> <mooregr_deletet...@.greenms.com> wrote:
>> "John Bell" <jbellnewspo...@.hotmail.com> wrote in message
>> news:172DFD61-F6D1-496A-B591-79B4B3F1EF0A@.microsoft.com...
>>
>>
>> > Hi
>> > "gdunnjr" wrote:
>> >> I noticed a table named 'd99_tmp' in mySQLServer 2000 db. I nor
>> >> anyone on my team creatd the this table. The fields are
>> >> 'subdirectory', 'depth' and 'file'. It contains basically the entire
>> >> file structure of the D: drive on the server.
>> >> The table has the permissions of the web application that uses that
>> >>SQLServer database.
>> >> This appears to be aSQLInjectionattack and I know that there is
>> >> some dynamicSQLused in the application.
>> >> Any suggestions (other than removing all of the public facing dynamic
>> >>SQL)?
>> Exactly that. :-)
>> But also make sure the user doesn't have DDL permissins like that.
>> Won't prevent allSQLInjectionattacks, but if the user can't
>> create/drop/alter tables (or execute xp_cmdshell) you'll be a lot better
>> off.
>>
>> >> Thanks!
>> > Check outhttp://www.sommarskog.se/dynamic_sql.html#SQL_injectionand the
>> > rest of the article about dynamicSQL. Make sure that overall you have
>> > tightened up permissions so the minimum access is granted to provide
>> > the
>> > functionality required. You could run Best Practice Analyser
>> >http://www.microsoft.com/downloads/details.aspx?FamilyId=B352EB1F-D3C...
>> > and the Microsoft Security Assessment
>> > Toolhttps://www.securityguidance.com/faq.htmreading the Windows Server
>> > 2003 Security Guide may also help
>> >http://www.microsoft.com/downloads/details.aspx?FamilyID=8A2643C1-068...
>> > John
>> --
>> Greg MooreSQLServer DBA Consulting Remote and Onsite available!
>> Email:sql (at) greenms.com
>> http://www.greenms.com/sqlserver.html- Hide quoted text -
>> - Show quoted text -
>
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html
Cyrstal Report
Hi,
Nittu here...i am at enty level of crystal reports...i am into support team.
i am facing a problem in most of the reports related to grp by.
viz : i have a table called ward charges...
wardid wardname charges
1 ac room 1950
2 room #1 1400
3 room #2 1400
i need to calculate charges for patient admitted in room#1...
in report since they have groped by wardid...always
1950 is fetched for calculating the ward charges
i want 1400 instead
ward charges = charges * no. of days
same probm i facing in many other places due to grp by..
plz help me hw to sort it out.
from,
nittuIf you are grouping by wardid, then create a formula and place that formula in your group header.
Formula: ({Charges * no.ofdays}) \\ Place this in wardid group header
This will give the calculation for each wardid.
Hope that is what you are after.
GJ
Nittu here...i am at enty level of crystal reports...i am into support team.
i am facing a problem in most of the reports related to grp by.
viz : i have a table called ward charges...
wardid wardname charges
1 ac room 1950
2 room #1 1400
3 room #2 1400
i need to calculate charges for patient admitted in room#1...
in report since they have groped by wardid...always
1950 is fetched for calculating the ward charges
i want 1400 instead
ward charges = charges * no. of days
same probm i facing in many other places due to grp by..
plz help me hw to sort it out.
from,
nittuIf you are grouping by wardid, then create a formula and place that formula in your group header.
Formula: ({Charges * no.ofdays}) \\ Place this in wardid group header
This will give the calculation for each wardid.
Hope that is what you are after.
GJ
CVS - Columns not exporting when Visibility>Hidden has a parameter in it
Hi there,
I am using SQL 2005, with Reporting Services 2005 and Visual Studio
2005 Team Suite.
I have a report which uses 52 parameters to determine which columns are
shown.
Each of the columns have a value in the visibilty>hidden field of
something like '=IIF(Parameters!showname.Value,False,True)' where
showname is a boolean parameter.
It displays perfectly in html & pdf - if the parameter is false, the
column is hidden, if the parameter is true, the column is hidden.
When i try to export to csv, it doesn't show the column at all. Even
if the expression is changed to '=IIF(1=1,False,True)' - the only way I
can get the column to show in the csv output is by setting the hidden
value to 'False' which means that its shown regardless of the
parameter.
Any ideas?I got a reply from a MS contact on msdn. Here is his reply for anyone
else with the same problem...
John,
You can't conditionally hide and show data in data renderers (CSV,
XML). This is by design. If you have an expression in the Hidden field
and 'Auto' in DataOutput tab for text boxes in the column, your data
will not be rendered into CSV or XML.
You can set DataElementOutput to Output for textboxes in the cells and
in the header, and the coulmn will always be in the output file.
Thanks!
----
- DenisL (SQL RS Team)
johnburns007@.gmail.com wrote:
> Hi there,
> I am using SQL 2005, with Reporting Services 2005 and Visual Studio
> 2005 Team Suite.
> I have a report which uses 52 parameters to determine which columns are
> shown.
> Each of the columns have a value in the visibilty>hidden field of
> something like '=IIF(Parameters!showname.Value,False,True)' where
> showname is a boolean parameter.
> It displays perfectly in html & pdf - if the parameter is false, the
> column is hidden, if the parameter is true, the column is hidden.
> When i try to export to csv, it doesn't show the column at all. Even
> if the expression is changed to '=IIF(1=1,False,True)' - the only way I
> can get the column to show in the csv output is by setting the hidden
> value to 'False' which means that its shown regardless of the
> parameter.
> Any ideas?
I am using SQL 2005, with Reporting Services 2005 and Visual Studio
2005 Team Suite.
I have a report which uses 52 parameters to determine which columns are
shown.
Each of the columns have a value in the visibilty>hidden field of
something like '=IIF(Parameters!showname.Value,False,True)' where
showname is a boolean parameter.
It displays perfectly in html & pdf - if the parameter is false, the
column is hidden, if the parameter is true, the column is hidden.
When i try to export to csv, it doesn't show the column at all. Even
if the expression is changed to '=IIF(1=1,False,True)' - the only way I
can get the column to show in the csv output is by setting the hidden
value to 'False' which means that its shown regardless of the
parameter.
Any ideas?I got a reply from a MS contact on msdn. Here is his reply for anyone
else with the same problem...
John,
You can't conditionally hide and show data in data renderers (CSV,
XML). This is by design. If you have an expression in the Hidden field
and 'Auto' in DataOutput tab for text boxes in the column, your data
will not be rendered into CSV or XML.
You can set DataElementOutput to Output for textboxes in the cells and
in the header, and the coulmn will always be in the output file.
Thanks!
----
- DenisL (SQL RS Team)
johnburns007@.gmail.com wrote:
> Hi there,
> I am using SQL 2005, with Reporting Services 2005 and Visual Studio
> 2005 Team Suite.
> I have a report which uses 52 parameters to determine which columns are
> shown.
> Each of the columns have a value in the visibilty>hidden field of
> something like '=IIF(Parameters!showname.Value,False,True)' where
> showname is a boolean parameter.
> It displays perfectly in html & pdf - if the parameter is false, the
> column is hidden, if the parameter is true, the column is hidden.
> When i try to export to csv, it doesn't show the column at all. Even
> if the expression is changed to '=IIF(1=1,False,True)' - the only way I
> can get the column to show in the csv output is by setting the hidden
> value to 'False' which means that its shown regardless of the
> parameter.
> Any ideas?
Subscribe to:
Posts (Atom)