October 3, 2008 at 10:59 am
This kind of applies to both SQL 2000 and 2005 because they are both possible solutions to our problem so I'm posting it in the more active forum.
On our main SQL Server 2000 server we have triggers that fire when a record falls into a certain category. That populates another table with the updated information.
Third party wants that data sent to a URL in the form of a query string.
Web service that polls the table would work but it's frowned upon. Can it all be contained in SQL Server and how? We have a 2005 box that could possibly do some of the work if it's necessary.
I've found a little info but nothing I feel real groovy about yet.
MCITP, Database Administrator
A hodgepodge of Information Technology and Life
LinkedIn Profile
My Twitter
October 3, 2008 at 11:14 am
This would be a textbook case for a "man in the middle" attack. Passing large amounts of data using a URL is essentially leaving yourself VERY open to any number of vulnerabilities.
In my book - that one would be a big "no".
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
October 3, 2008 at 11:18 am
Matt Miller (10/3/2008)
This would be a textbook case for a "man in the middle" attack. Passing large amounts of data using a URL is essentially leaving yourself VERY open to any number of vulnerabilities.In my book - that one would be a big "no".
well, that's how they want it and not how we'd like to give it. And isn't it true that it opens them up to vulnerabilities and not us. We are just passing it to them.
It's not a large amount, it's basically updated info for that row.
MCITP, Database Administrator
A hodgepodge of Information Technology and Life
LinkedIn Profile
My Twitter
October 3, 2008 at 11:38 am
Jason Crider (10/3/2008)
Matt Miller (10/3/2008)
This would be a textbook case for a "man in the middle" attack. Passing large amounts of data using a URL is essentially leaving yourself VERY open to any number of vulnerabilities.In my book - that one would be a big "no".
well, that's how they want it and not how we'd like to give it. And isn't it true that it opens them up to vulnerabilities and not us. We are just passing it to them.
It's not a large amount, it's basically updated info for that row.
True - but it then comes down to what the business significance this might have. Since it's a URL - it's "wide open", with no way for them to verify who it came from. If they then take actions based on what is submitted - what is the downside of someone else submitting a URL string as if they were you? For that matter - once someone find this open door, who's to say someone doesn't get creative and come up with a destructive URL wiping out their data, again - looking as if they were you?
The biggest part of this all boils down to - if they're this sloppy and careless with this process, then how careful could they possibly be with ANYTHING they do. This kind of stuff was a bad idea in the 90's, so someone suggesting it now is, well - something I wouldn't say in mixed company.
Just this example would be something I would march directing in to my CIO and say "we don't want to be doing business with these Yahoo's". Harsh perhaps, but I have my own org to protect.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
October 3, 2008 at 11:41 am
seeing that it's internal and being a firewall does that change what you are saying?
MCITP, Database Administrator
A hodgepodge of Information Technology and Life
LinkedIn Profile
My Twitter
October 3, 2008 at 11:50 am
Jason Crider (10/3/2008)
seeing that it's internal and being a firewall does that change what you are saying?
No. It might weaken my argument in my management's eyes, but I would have the same objections no matter what.
Security in depth would dictate securing each and every step along the way. In other words - don't rely on the firewall to be the only line of defense.
Bottom line is - there are lot of ways to do this today, all of which would likely be more secure and more reliable than this. This would not be the right way to do this in my mind.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
October 3, 2008 at 2:01 pm
All the security issues aside because I would like to present an option when they say there is no other way.
Is there a way to do this in T-SQL, DTS, SSIS, or anywhere in SQL.
MCITP, Database Administrator
A hodgepodge of Information Technology and Life
LinkedIn Profile
My Twitter
October 3, 2008 at 2:17 pm
A web service you pass parameters to, which then builds the query or executes the query on the remote end is a viable option. or - a CLR asembly. Or - a Service broker messaging service might work depending on what is needed.
Note that at very least in those scenarios - the data is validated AFTER transit, and the query is built securely on the "remote" end. Just about anything that involves sending a query string which is executed "sight unseen" is a loaded gun just waiting to be found.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
October 3, 2008 at 5:36 pm
Jason Crider (10/3/2008)
Third party wants that data sent to a URL in the form of a query string.
So, create a chunk of code that will make a set of SELECT/UNION ALL statements in a fashion similar that identified in the article in my signature line. Base it on the content of the INSERTED trigger table in the trigger.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply