In general, by the time someone is my fiancee (or even serious significant other--I'll admit I've never actually been engaged to anyone), they've built up a substantial stock of evidence against being an idiot, something that it would probably take more than one non-cataclysmic incident to destroy. I must admit that I have difficulty seeing the value in acting otherwise, provided non-idiocy is important to you.
Oh, I totally agree with you. Thats why I know, 100% sure, that my fiancee will never do something that dumb. But if she was defy all logic and do it, It would be one step toward making me feel I was wrong for all these years (a single event wouldn't be enough. You're right).
Its kind of like if you're someone for 10 years, then they cheat on you. Would make one reconsider everything they thought during that decade. (Fortunatelly, I never was in that situation).
As long as you put the right info (like application name) in your connection string, your DBAs will stay happy, no worries.
And there is NOOOOOOOOTHING you can do in a SP that you can't do in a param query. Nothing. None. ZERO. The only performance benefit you'll get is the bandwidth (if you run a long query 1000000 times in a row, its a lot of data going).
The rest is a decent argument, but one that only holds water in simple applications. In complex enterprise apps, you have a billion datasources. Probably 5-6 different RDBMS, ETL data sources, EDI, Biztalk, flat files from legacy system, integration of all the junk MS Word document from before you got hired and started smacking people, CLR queries, etc etc... So in the end the handful of T-SQL that would actually be benefitial (for example, a write-only query that stores sensitive information on a table that NO ONE has read access to, because of laws and stuff) just end up being an integral part of your service layer, like everything else. If your stored procedures are treated specially enough that mixing them with other data access methods becomes inconsistant, your app is way, way too tightly coupled with the domain model, and thats a future maintenance nightmare.
If its a smaller application that won't have to do any integration, like most stand-alone apps, then it can make sense I suppose, depending on your architecture.
Yeah, that always seem to be the missing link in the equation. Its a bit like ethanol... As soon as it started becoming more mainstream, corn and such skyrocketed. Useful!::cough::
If its mostly from texting, it IS stupid, because there are many, many alternatives. If its raising a 200$ bill from talking with their parent who's oversea in a country that just got nailed by a bomb, crashing the communication systems, etc, thats something else altogether.
Its not about the money, its just about the stupidity. If my fiancee did something that dumb, I'd consider ditching her too (and she knows that, and would do the same straight back to me if the situations were reversed).
Is it that weird to have certain expectations from the people you live with? Mistakes happen, and thats no biggy, but that? Ugh.
Thats still fine with IN Statements: you concatenate strings, yes, but from a trusted source (your own!) to add the parameter placeholders, and then loop to add the parameters to the collections. So its completly safe, and still ends up as a prepared statement.
Another way that I like, is (for DBMS that supports it) pass as a parameter an XML document with (if i'm paranoid) a schema, then pivot it as a table, and use the IN on that. Works pretty good.
Its not the language that makes it so you use ? or @name for the parameters, but the access layer and/Or the DBMS itself. For example, using ODBC or OLEDB, even if you connect to SQL Server with C#, you'll end up using the ? way of doing things. Just a side note:)
Btw, what cracks me up is, bringing Visual Studio to the table, then talking about most database engines taking advantage of SPs for query plans...then forgetting...
One of the database engine thats the most used in tandem with Visual Studio, does NOT. In SQL Server, the execution plan is not pre-prepared. Its made at runtime, and cached. What does that mean? That dynamic sql (using prepared statements ONLY!), and stored procedures, have the same performance advantage, so that argument falls flat. I know not ALL RDBMS are like that, and wouldn't be able to give you a list, but at the very least for a large portion of Visual Studio users, that argument is a poor one.
Added to that, that the "SPs forever!" thing is a mostly Microsoft-world way of designing applications (keep in mind that I'm a.NET developer, and I love it, so I'm certainly not biaised AGAINST microsoft when saying that). In the rest of the world, SPs are part of the architecture and design decisions, like everything else, and that very, very often, they are not the right choice. An enterprise level application without any is probably designed wrong, I'll agree, but a lot of enterprise class java/unix/whatever apps use ORMs like hibernate or llblgen, and they are secure, scale perfectly fine, and perform quite well.
The SP-only thing comes from the VB6 world if anything.
While stored procedures are good, using dynamic sql inside the stored proc is (almost) as vulnerable as using normal dynamic sql.
The truly secure methods are:
1) Use stored procedure, with no dynamic sql whatsoever. 2) Use prepared statements: this make dynamic sql just as secure as stored procedure, and in the more advanced RDBMS, allows query plan to be cached (aka: it is virtually exactly as fast as stored procedures. SPs being used for performance reasons is a myth folks, at least with the better RDBMSs) 3) Use dynamic sql inside stored procedures, using prepared statements (I know at least T-SQL and PL/SQL let you do that, don't know about the others, never had to use it)
Basically, it comes down to: use a method that allows the RDBMS to cache the query plan, and just think of it as being for performance reasons. The security will come on its own, that way you won't have to think about it. If the RDBMS can't cache the plan, there's chances of potential holes.
Yup, but its a local exploit. Otherwise, that would be like saying that if there's such an exploit in, let say, Open Office that could somehow in an alternate dimention allow you to get root, that its a remote exploit because a poorly managed VNC access would let you do it remotly.
As pointed by many, the thing you showed isn't remotely exploitable. You need another mean of access to the machine, with freagin write access, to put code in a folder where it has script execute permission. Basically, you need a freagin account on the box. Not quite it.
People already answered, but just to confirm (since i'm canadian, but my fiancee is american, get to see both sides on a near daily basis...)
Basically, in the US, when you get a "debit card" from your bank, almost invariably, it also has a "visa" or "mastercard" logo on it. So you can go around using it like a debit card (exactly like our Interac thingy), but if you were to get it swiped as a credit card, or, let say, input the number on an e-Commerce web site that only takes credit cards, it will -also- work, but instead, will work exactly like your Visa or mastercard credit card works. Basically, the same number can be used for both.
In Canada, the two are totally separated, but in many places in the US, especially big cities, the idea of a debit card thats NOT the same as a credit card, often will get you a big "huh?", because it really doesn't make sense to them. 1 card, can either use money you already have, or a credit card account. When you think about it, the US way makes a lot more sense, in my opinion.
In other news, RDBMS are full of "bloat" when all you want is persist a simple string of text to disk, what nonsense! No such problem with plain text files!
Considering Vista 32 bit runs -almost- everything, and people cry like crazy about bad backward compatibility, can you imagine the rampage if they had dropped 32 bit? Microsoft employees would get burned on stakes in public places.
IIS 7 is incredible from a development's perspective, thats why its useful on a workstation, even if its not for everyone. If you think IE on XP and IE on Vista are two completly different beasts when it comes to security, which was my point.
I quite doubt that MSDN subscriptions count, since they're not "legit" licenses, in the sense you can't use an MSDN software for anything beyond testing, except for the dev tools and office (with MSDN universal). Also, you actually only get 1 license, but it can be installed on 10 PC (but still is only "one", as in only one person can use it per MSDN subscription)
Media center integrated in non-OEM boxes, a version of IIS thats miles ahead of IIS6,.NET 3.0 built in, a UI API thats much more powerful, the ability to make much more apps work as a standard user (a lot of system paths are mapped using links-type thingnies to user paths, so an app that normally would use admin priviledge can sometime runs without), a version of IE you can actually use without getting used, all of the Ready*whatever technologies to use more hardware, Direct X 10, much better file system encryption tools, of course the nicer UI, the bazillion of things that MS stole from MAC (yeah, I went there...), better app caching (so my RAM is actually used for something...useful), far better diagnostic and journal tools.
There's more, but thats just on top of my mind, and a lot of it is stuff for developers to leverage. So much more than XP (except for the kernel, which I'll admit was totally amazingly huge, though meant -NOTHING- if you came from Windows 2000, which at first was miles ahead of XP). Once devs (of both software and hardware) start using the new APIs, the difference will be greater: for example the hard drives with built in flash for readyboost.
I'm not saying that Vista is the best thing in the world: it really isn't. It has, however, as much, or more potential than XP had at release.
Thats my point. In that regardless of how doomed people said MS was when XP came out, its now quite the success. Vista today is doing better than XP without SP did. A -lot- better.
Also, SPs had very little to do with driver support and performance, which is what most people complain about when talking about Vista: for example, Vista runs virtually every (recent) game you can throw at it right now. Those that don't, will soon.
With XP however? some games that came out just months before STILL don't work. So no, I didn't forget anything. If XP didn't end up a failure, Vista won't either: it is, without any SP, miles ahead of what XP was at release, relatively.
Slashdot Mirror
Oh, I totally agree with you. Thats why I know, 100% sure, that my fiancee will never do something that dumb. But if she was defy all logic and do it, It would be one step toward making me feel I was wrong for all these years (a single event wouldn't be enough. You're right).
Its kind of like if you're someone for 10 years, then they cheat on you. Would make one reconsider everything they thought during that decade. (Fortunatelly, I never was in that situation).
As long as you put the right info (like application name) in your connection string, your DBAs will stay happy, no worries.
And there is NOOOOOOOOTHING you can do in a SP that you can't do in a param query. Nothing. None. ZERO. The only performance benefit you'll get is the bandwidth (if you run a long query 1000000 times in a row, its a lot of data going).
The rest is a decent argument, but one that only holds water in simple applications. In complex enterprise apps, you have a billion datasources. Probably 5-6 different RDBMS, ETL data sources, EDI, Biztalk, flat files from legacy system, integration of all the junk MS Word document from before you got hired and started smacking people, CLR queries, etc etc... So in the end the handful of T-SQL that would actually be benefitial (for example, a write-only query that stores sensitive information on a table that NO ONE has read access to, because of laws and stuff) just end up being an integral part of your service layer, like everything else. If your stored procedures are treated specially enough that mixing them with other data access methods becomes inconsistant, your app is way, way too tightly coupled with the domain model, and thats a future maintenance nightmare.
If its a smaller application that won't have to do any integration, like most stand-alone apps, then it can make sense I suppose, depending on your architecture.
Yeah, that always seem to be the missing link in the equation. Its a bit like ethanol... As soon as it started becoming more mainstream, corn and such skyrocketed. Useful! ::cough::
If its mostly from texting, it IS stupid, because there are many, many alternatives. If its raising a 200$ bill from talking with their parent who's oversea in a country that just got nailed by a bomb, crashing the communication systems, etc, thats something else altogether.
Its not about the money, its just about the stupidity. If my fiancee did something that dumb, I'd consider ditching her too (and she knows that, and would do the same straight back to me if the situations were reversed).
Is it that weird to have certain expectations from the people you live with? Mistakes happen, and thats no biggy, but that? Ugh.
Thats still fine with IN Statements: you concatenate strings, yes, but from a trusted source (your own!) to add the parameter placeholders, and then loop to add the parameters to the collections. So its completly safe, and still ends up as a prepared statement.
Another way that I like, is (for DBMS that supports it) pass as a parameter an XML document with (if i'm paranoid) a schema, then pivot it as a table, and use the IN on that. Works pretty good.
Its not the language that makes it so you use ? or @name for the parameters, but the access layer and/Or the DBMS itself. For example, using ODBC or OLEDB, even if you connect to SQL Server with C#, you'll end up using the ? way of doing things. Just a side note :)
You mean like, someone for who english is a third language? Geez, sorry my brain has limitations, sir!
Btw, what cracks me up is, bringing Visual Studio to the table, then talking about most database engines taking advantage of SPs for query plans...then forgetting...
.NET developer, and I love it, so I'm certainly not biaised AGAINST microsoft when saying that). In the rest of the world, SPs are part of the architecture and design decisions, like everything else, and that very, very often, they are not the right choice. An enterprise level application without any is probably designed wrong, I'll agree, but a lot of enterprise class java/unix/whatever apps use ORMs like hibernate or llblgen, and they are secure, scale perfectly fine, and perform quite well.
One of the database engine thats the most used in tandem with Visual Studio, does NOT. In SQL Server, the execution plan is not pre-prepared. Its made at runtime, and cached. What does that mean? That dynamic sql (using prepared statements ONLY!), and stored procedures, have the same performance advantage, so that argument falls flat. I know not ALL RDBMS are like that, and wouldn't be able to give you a list, but at the very least for a large portion of Visual Studio users, that argument is a poor one.
Added to that, that the "SPs forever!" thing is a mostly Microsoft-world way of designing applications (keep in mind that I'm a
The SP-only thing comes from the VB6 world if anything.
While stored procedures are good, using dynamic sql inside the stored proc is (almost) as vulnerable as using normal dynamic sql.
The truly secure methods are:
1) Use stored procedure, with no dynamic sql whatsoever.
2) Use prepared statements: this make dynamic sql just as secure as stored procedure, and in the more advanced RDBMS, allows query plan to be cached (aka: it is virtually exactly as fast as stored procedures. SPs being used for performance reasons is a myth folks, at least with the better RDBMSs)
3) Use dynamic sql inside stored procedures, using prepared statements (I know at least T-SQL and PL/SQL let you do that, don't know about the others, never had to use it)
Basically, it comes down to: use a method that allows the RDBMS to cache the query plan, and just think of it as being for performance reasons. The security will come on its own, that way you won't have to think about it. If the RDBMS can't cache the plan, there's chances of potential holes.
Seinfeld, yeah.
If someone was to restrict access to Heroes episodes though, I definately WOULD die.
Yup, but its a local exploit. Otherwise, that would be like saying that if there's such an exploit in, let say, Open Office that could somehow in an alternate dimention allow you to get root, that its a remote exploit because a poorly managed VNC access would let you do it remotly.
As pointed by many, the thing you showed isn't remotely exploitable. You need another mean of access to the machine, with freagin write access, to put code in a folder where it has script execute permission. Basically, you need a freagin account on the box. Not quite it.
People on Slashdot seems to care a WHOOOOOOOOOOOOLE lot when the news is abotu Vista -NOT- selling, though...
People already answered, but just to confirm (since i'm canadian, but my fiancee is american, get to see both sides on a near daily basis...)
Basically, in the US, when you get a "debit card" from your bank, almost invariably, it also has a "visa" or "mastercard" logo on it. So you can go around using it like a debit card (exactly like our Interac thingy), but if you were to get it swiped as a credit card, or, let say, input the number on an e-Commerce web site that only takes credit cards, it will -also- work, but instead, will work exactly like your Visa or mastercard credit card works. Basically, the same number can be used for both.
In Canada, the two are totally separated, but in many places in the US, especially big cities, the idea of a debit card thats NOT the same as a credit card, often will get you a big "huh?", because it really doesn't make sense to them. 1 card, can either use money you already have, or a credit card account. When you think about it, the US way makes a lot more sense, in my opinion.
Funny, my version of Word has a "Save as PDF", that was provided by MS no less. OH! You meant the -previous- versions. Oupsies.
My understanding is, even with 32 bit app support, there are compatibility issues, like with games, drivers, etc, no?
In other news, RDBMS are full of "bloat" when all you want is persist a simple string of text to disk, what nonsense! No such problem with plain text files!
Considering Vista 32 bit runs -almost- everything, and people cry like crazy about bad backward compatibility, can you imagine the rampage if they had dropped 32 bit? Microsoft employees would get burned on stakes in public places.
Totally agree. Man, I can just imagine whats next. Dating sites not allowed to discriminate by gender! That would be AWESOME. /sarcasm.
IIS 7 is incredible from a development's perspective, thats why its useful on a workstation, even if its not for everyone.
If you think IE on XP and IE on Vista are two completly different beasts when it comes to security, which was my point.
I was replying to a post that only spoke of the technical aspects, refering to service packs, etc. Not about sales rate.
I quite doubt that MSDN subscriptions count, since they're not "legit" licenses, in the sense you can't use an MSDN software for anything beyond testing, except for the dev tools and office (with MSDN universal). Also, you actually only get 1 license, but it can be installed on 10 PC (but still is only "one", as in only one person can use it per MSDN subscription)
So either way, I really doubt it.
Media center integrated in non-OEM boxes, a version of IIS thats miles ahead of IIS6, .NET 3.0 built in, a UI API thats much more powerful, the ability to make much more apps work as a standard user (a lot of system paths are mapped using links-type thingnies to user paths, so an app that normally would use admin priviledge can sometime runs without), a version of IE you can actually use without getting used, all of the Ready*whatever technologies to use more hardware, Direct X 10, much better file system encryption tools, of course the nicer UI, the bazillion of things that MS stole from MAC (yeah, I went there...), better app caching (so my RAM is actually used for something...useful), far better diagnostic and journal tools.
There's more, but thats just on top of my mind, and a lot of it is stuff for developers to leverage. So much more than XP (except for the kernel, which I'll admit was totally amazingly huge, though meant -NOTHING- if you came from Windows 2000, which at first was miles ahead of XP). Once devs (of both software and hardware) start using the new APIs, the difference will be greater: for example the hard drives with built in flash for readyboost.
I'm not saying that Vista is the best thing in the world: it really isn't. It has, however, as much, or more potential than XP had at release.
Thats my point. In that regardless of how doomed people said MS was when XP came out, its now quite the success. Vista today is doing better than XP without SP did. A -lot- better.
Also, SPs had very little to do with driver support and performance, which is what most people complain about when talking about Vista: for example, Vista runs virtually every (recent) game you can throw at it right now. Those that don't, will soon.
With XP however? some games that came out just months before STILL don't work. So no, I didn't forget anything. If XP didn't end up a failure, Vista won't either: it is, without any SP, miles ahead of what XP was at release, relatively.