显示标签为“approach”的博文。显示所有博文
显示标签为“approach”的博文。显示所有博文

2012年3月27日星期二

Flaw in SQL Server Report Services Security

While I wouldn't take this approach in a hostile environment, Reporting Serv
ices exposes a security flaw in the way parameters are parsed.
To see this, follow the walk through for adding a parameter to a report, but
instead of setting "Available Values" to "From Query", set it to "Non-Query
"
The help file tells you to set up your SQL string as so:
="SELECT FirstName, LastName, Title FROM Employee" & IIf(Parameters!Departme
nt.Value = 0,""," WHERE (DepartmentID = " & Parameters!Department.Value &
")") & " ORDER BY LastName"
Then when you deploy the report you will see a prompt that says Department a
nd a text box.
If you enter a Department ID in the box everything works great. But, instead
if you enter something like:
'; Drop table Employee --
And click run report, say goodbye to your employee table.
While I would never use concatenated queries in a production environment, wi
th all of the talk about the security that went into this product, I would h
ave thought that something would have been done to prevent such a common sec
urity flaw.
LeeI haven't gotten around to testing RS yet, but are you connecting the user
as an admin? You must be otherwise they wouldn't be able to execute the
drop statement. This is just sql injection. All user access should be
restricted to stored procedures.
Eric
"Lee" <anonymous@.discussions.microsoft.com> wrote in message
news:5A570020-575D-4B5F-A775-FC9F45416D50@.microsoft.com...
quote:

> While I wouldn't take this approach in a hostile environment, Reporting

Services exposes a security flaw in the way parameters are parsed.
quote:

> To see this, follow the walk through for adding a parameter to a report,

but instead of setting "Available Values" to "From Query", set it to
"Non-Query"
quote:

> The help file tells you to set up your SQL string as so:
> ="SELECT FirstName, LastName, Title FROM Employee" &

IIf(Parameters!Department.Value = 0,""," WHERE (DepartmentID = " &
Parameters!Department.Value & ")") & " ORDER BY LastName"
quote:

> Then when you deploy the report you will see a prompt that says Department

and a text box.
quote:

> If you enter a Department ID in the box everything works great. But,

instead if you enter something like:
quote:

> '; Drop table Employee --
> And click run report, say goodbye to your employee table.
> While I would never use concatenated queries in a production environment,

with all of the talk about the security that went into this product, I would
have thought that something would have been done to prevent such a common
security flaw.
quote:

> Lee

Flaw in SQL Server Report Services Security

While I wouldn't take this approach in a hostile environment, Reporting Services exposes a security flaw in the way parameters are parsed.
To see this, follow the walk through for adding a parameter to a report, but instead of setting "Available Values" to "From Query", set it to "Non-Query
The help file tells you to set up your SQL string as so
="SELECT FirstName, LastName, Title FROM Employee" & IIf(Parameters!Department.Value = 0,""," WHERE (DepartmentID = " & Parameters!Department.Value & ")") & " ORDER BY LastName
Then when you deploy the report you will see a prompt that says Department and a text box.
If you enter a Department ID in the box everything works great. But, instead if you enter something like
'; Drop table Employee -
And click run report, say goodbye to your employee table
While I would never use concatenated queries in a production environment, with all of the talk about the security that went into this product, I would have thought that something would have been done to prevent such a common security flaw
LeeI haven't gotten around to testing RS yet, but are you connecting the user
as an admin? You must be otherwise they wouldn't be able to execute the
drop statement. This is just sql injection. All user access should be
restricted to stored procedures.
Eric
"Lee" <anonymous@.discussions.microsoft.com> wrote in message
news:5A570020-575D-4B5F-A775-FC9F45416D50@.microsoft.com...
> While I wouldn't take this approach in a hostile environment, Reporting
Services exposes a security flaw in the way parameters are parsed.
> To see this, follow the walk through for adding a parameter to a report,
but instead of setting "Available Values" to "From Query", set it to
"Non-Query"
> The help file tells you to set up your SQL string as so:
> ="SELECT FirstName, LastName, Title FROM Employee" &
IIf(Parameters!Department.Value = 0,""," WHERE (DepartmentID = " &
Parameters!Department.Value & ")") & " ORDER BY LastName"
> Then when you deploy the report you will see a prompt that says Department
and a text box.
> If you enter a Department ID in the box everything works great. But,
instead if you enter something like:
> '; Drop table Employee --
> And click run report, say goodbye to your employee table.
> While I would never use concatenated queries in a production environment,
with all of the talk about the security that went into this product, I would
have thought that something would have been done to prevent such a common
security flaw.
> Leesql

2012年3月22日星期四

Flat file Import performance question

Hi there,

I have a question regarding 2 approaches importing data from a flat text file. I'm taking the approach suggested by Phil Brammer to use a checksum to see whether a row has exists, and if it does check whether it has changed.

http://www.ssistalk.com/2007/03/09/ssis-using-a-checksum-to-determine-if-a-row-has-changed

I would like to hear some opinions on 2 approaches:

1) Importing the data int a temp table first then do the data processing from the temp table.
Or
2) Importing the data by doing the data processing direcly from the text file without placing it in a temp table first.

A hunch told me that it will be faster doing approach 1 but I would like to hear some experienced opinions first Smile

Best regards
Mike

I would think #2 would be *slightly* faster just because there are less components at work.

With that said, I prefer #1 always because it quickly loads the data to a table which I can then use SQL to get the data out. This might be advantageous for sorting the data, filtering the data, joining the data to another table, etc... Basically I like to push as much work off to the database engine that I can. Sure, SSIS can merge (join) data sets together, but the database engine will do a much better job. Also, having the data staged will help me to restart the process should it fail, work in batches (perhaps) by loading more than one file to the table if needed, and guarantee that the data will be there when I need it in an environment that might not guarantee that the file will always be around for use.

|||Thanks Phil,

I really appreciate your valuable input.

Best regards
Mike
|||

If you can afford, I would suggest to test both approaches, in your own environment, and then base your decisions on that way collected (real) data.

Thanks,

Bob

sql

Flat file Import performance question

Hi there,

I have a question regarding 2 approaches importing data from a flat text file. I'm taking the approach suggested by Phil Brammer to use a checksum to see whether a row has exists, and if it does check whether it has changed.

http://www.ssistalk.com/2007/03/09/ssis-using-a-checksum-to-determine-if-a-row-has-changed

I would like to hear some opinions on 2 approaches:

1) Importing the data int a temp table first then do the data processing from the temp table.
Or
2) Importing the data by doing the data processing direcly from the text file without placing it in a temp table first.

A hunch told me that it will be faster doing approach 1 but I would like to hear some experienced opinions first Smile

Best regards
Mike

I would think #2 would be *slightly* faster just because there are less components at work.

With that said, I prefer #1 always because it quickly loads the data to a table which I can then use SQL to get the data out. This might be advantageous for sorting the data, filtering the data, joining the data to another table, etc... Basically I like to push as much work off to the database engine that I can. Sure, SSIS can merge (join) data sets together, but the database engine will do a much better job. Also, having the data staged will help me to restart the process should it fail, work in batches (perhaps) by loading more than one file to the table if needed, and guarantee that the data will be there when I need it in an environment that might not guarantee that the file will always be around for use.

|||Thanks Phil,

I really appreciate your valuable input.

Best regards
Mike
|||

If you can afford, I would suggest to test both approaches, in your own environment, and then base your decisions on that way collected (real) data.

Thanks,

Bob

2012年3月19日星期一

FK for tables out of the publication.

Hi ,
I would like to know what is the base approach for FK for tables out of the
publication.
I have several situations that I would like to add FK from tables out of
publication ( tables that do not replicate at all – historical tables or
replicate by different publication) to a table in live publication. This
actually can be done, but when I have to initialize the publication and apply
new snapshot the agent will fail because it does not able to drop the table
/delete rows due to the FK. I thought that define the FK as “not for
replication” will solve it but it doesn’t.
I have the problem on SQL 2000 enterprise edition SP3 and SP4.
Eyal
Eyal,
you can use pre-snapshot and post-snapshot scripts to handle FKs outside of
the publication.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||What you need to do is change the article properties to keep the existing
table intact. Right click on your publication, select properties, click on
the articles tab, and then select the snapshot tab, and select keep existing
table unchanged. Note that this might duplicate data, so you may need to use
the delete data option and have cascading deletes on the subscriber.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"? ??" <nospameyalSchapira@.hotmail.com> wrote in message
news:D207B0D7-8ADA-4BB1-98AC-962DE0778AD2@.microsoft.com...
> Hi ,
> I would like to know what is the base approach for FK for tables out of
> the
> publication.
> I have several situations that I would like to add FK from tables out
> of
> publication ( tables that do not replicate at all - historical tables or
> replicate by different publication) to a table in live publication.
> This
> actually can be done, but when I have to initialize the publication and
> apply
> new snapshot the agent will fail because it does not able to drop the
> table
> /delete rows due to the FK. I thought that define the FK as "not for
> replication" will solve it but it doesn't.
> I have the problem on SQL 2000 enterprise edition SP3 and SP4.
> Eyal
>