Yes, but they don't parameterize the sort order on every sortable table, or the limits used in pagination, or the custom join expressions ORM developers inevitably write.
Thanks for helping make my point about real-world dev vs. on-paper dev.
But, to be clear, you don't often create tables with dynamic names (though you will sometimes; for instance, to repeatedly load huge datasets, which comes up in time-series apps)... but you very often need to select which table to use at runtime based on user inputs. Again, in real-world apps.
For what it's worth, I believe the same quote_name() mistake pops up with column names too. But you probably don't dynamically select those based on inputs either.
I most certainly won't create tables named after web input.
ORMs are there to shield you from database details. I don't care whether the underlying database is a MySQL instance running on Amazon's cloud, an Oracle RAC down our datacenter or even a non-relational animal we use for very high volume operations. I don't care if the data is in tables or a tree. The kind of stunt you are trying to convince us is reasonable should never be done on top of the ORM, but under it, or, better, by its side. If you have a humongous dataset to load, don't do it through the ORM - do it directly on the datastore.
On a side note, I find your tendency to rely on name-calling and insinuations most disturbing and quite inappropriate for a place like HN.
All I can tell you is what I see other people's apps doing, routinely, with a variety of different ORMs. You claimed ORMs are a better answer to SQL Injection than stored procedures. I'm sorry it upsets you to hear this, but that's simply incorrect.
The apps that I've seen do best against SQLI had an enforced policy that front-end devs couldn't write queries, that their access to the database was restricted through stored procedures, and that access was further restricted with database permissions. Stored procedures aren't a panacea either, but they're definitely more reliable than the Django ORM.
By themselves, stored procedures are not going to prevent SQLI. You will also have to lock down the database. You should also use parametrized queries to call those procedures, or else you would be able to inject something to get some information you shouldn't have access to or, at least, do something that can bring down the server (like looping around the stored procedure in a DoS attack).
My problem with stored procedures is that when you go that way, your business logic will end-up inside the database or, worse, scattered through layers of application and database (ever tried to do version control on stored procedures?), something really bad when you need to know what is going on with the server or when you need to move to a different database.
If you check your ORM thoroughly (I never did that as thoroughly as I wish I had with Django) and you never, ever, write SQL in your business logic (something you really should go for) you will be in better shape than if you write SQL code that calls stored procedures. It's easier for the DBA to slip up in a your-business-specific way than for the ORM maintainer. Also, with the DBA, only a few people will have access to catch the mistakes whereas lots of people read (and abuse) ORM code regularly.
I think the most important point you mentioned is not the stored procedure, but the lock down. If the app isn't allowed to mangle the data it should not mangle, you are mostly good. The best part is that locking down the database can happen without touching the ORM and is more or less portable across different databases.
Same can be said for sprocs. Any popular ORM will have proper handling for parameters. In both cases you can't rely on the tool, you have to know what you're doing.
It's true that stored procedures can be injectable, but it's extremely rare, and you can find the 0.1% of them that might be with a simple grep regex, unlike ORMs.
Can anyone give me a technical reason to deploy on a IIS and ASP platform instead of Apache/Nginx and one of the dozens of open source solutions for deploying a web application? From where I'm sitting, it seems to me the reasoning is "I drank the Microsoft Kool-Aid". Surely there's a better reason than that.
That's not necessarily true. Microsoft lobbyists specifically target middle and upper management, and using arguments from authority, convince them that they must stay on Windows/IIS because it has better ROI.
Substitute whatever you want for Rails, and ASP.NET will still have a better ROI for any given single application, and potentially (probably, in fact) for all their apps even if you artificially ignore switching costs.
We don't build apps in ASP.NET. We use Ruby. But we do a lot of security work for people with ASP.NET, are knee-deep in a lot of ASP.NET dev teams, and the things ASP.NET does for enterprise apps are not "kool-aid".
It's probably more accurate to say that they're hiring people who are willing to use MS tech to pull a salary, regardless of their personal preferences.
ASP.NET is an extremely full-featured, well-tested, and carefully designed enterprise web stack.
What you're really asking is, why would you deploy on an enterprise stack as opposed to a modern app framework. There's lots of reasons, none of which will be congenial to you:
* A much larger pool of available developers
* Better enterprise integration features (depending on your platform, J2EE or ASP.NET may be predetermined for you)
* A preexisting deployment platform that new ASP or J2EE apps can be rolled out onto.
There is really no good reason to do a web startup on ASP.NET or J2EE. So the short answer to your question is, "no, none of us should be using it." But there are lots of valid reasons for businesses to use it.
Is this a real question or a silly jab at Microsoft? I think you're underestimating the number of existing businesses who have .NET at their core, in which case the question is what justifies moving off of .NET? In my experience .NET can be - while not as hip - a very solid framework.
Yes it was a real question, and I note that you've failed to answer it.
>I think you're underestimating the number of existing businesses who have .NET at their core, in which case the question is what justifies moving off of .NET? In my experience .NET can be - while not as hip - a very solid framework.
I wanted to know why you'd deploy on that platform initially. Of course if you're already fucking using it, you're probably not going to switch.
Sorry, I thought you were being intentionally daft by stating the only reason to deploy on IIS would be "Kool-Aid" etc. In any case, you quoted my short answer to what I thought was not really a question to begin with ("a very solid framework").
You use IIS because you want to use ASP. You can't replace ASP with Nginx, it's an entire development stack, not just a webserver. And I actually like ASP. It's fast, easy to develop with, easy to deploy and there's great library support.
If you're deploying an app in to an enterprise that is already running an AD environment with other Microsoft products like SharePoint, Exchange, Office, and Microsoft Dynamics, it makes a lot of sense. I'm a Mac user and our startup is a kool-aid drinkin' Ruby on Rails shop, but I have administered enough large networks to see the power and value of Microsoft in the enterprise. Like it or not, the integration between Windows clients, Windows servers, and Microsoft applications is pretty incredible.
Good ms office integration. Thats interesting for many customers. Many customers also have IIS-Servers because office integrates good into these.
Good ms product integration in gereral should also be a valid point.
Also if a company has gotten into the above some time back, when asp on iis servers was the only way(?) for enterprise office integration for large reporting systems, it's
easier to let the asp developers learn asp.net and integrate the old enterpise systems with the new. When the old systems are rewritten, asp.net is the way to go, because the customer already has large parts of the infrastructure.
41 comments
[ 6.0 ms ] story [ 80.9 ms ] threadhttp://isc.sans.edu/diary.html?storyid=8935
http://nsmjunkie.blogspot.com/2010/06/anatomy-of-latest-mass...
According to the articles, more than 100k sites hacked.
Hint: Use SPs for all your data access and don't give your app direct access to the tables. Makes stuff like this infinitely less likely to work.
Better to use an ORM.
But, to be clear, you don't often create tables with dynamic names (though you will sometimes; for instance, to repeatedly load huge datasets, which comes up in time-series apps)... but you very often need to select which table to use at runtime based on user inputs. Again, in real-world apps.
For what it's worth, I believe the same quote_name() mistake pops up with column names too. But you probably don't dynamically select those based on inputs either.
ORMs are there to shield you from database details. I don't care whether the underlying database is a MySQL instance running on Amazon's cloud, an Oracle RAC down our datacenter or even a non-relational animal we use for very high volume operations. I don't care if the data is in tables or a tree. The kind of stunt you are trying to convince us is reasonable should never be done on top of the ORM, but under it, or, better, by its side. If you have a humongous dataset to load, don't do it through the ORM - do it directly on the datastore.
On a side note, I find your tendency to rely on name-calling and insinuations most disturbing and quite inappropriate for a place like HN.
The apps that I've seen do best against SQLI had an enforced policy that front-end devs couldn't write queries, that their access to the database was restricted through stored procedures, and that access was further restricted with database permissions. Stored procedures aren't a panacea either, but they're definitely more reliable than the Django ORM.
My problem with stored procedures is that when you go that way, your business logic will end-up inside the database or, worse, scattered through layers of application and database (ever tried to do version control on stored procedures?), something really bad when you need to know what is going on with the server or when you need to move to a different database.
If you check your ORM thoroughly (I never did that as thoroughly as I wish I had with Django) and you never, ever, write SQL in your business logic (something you really should go for) you will be in better shape than if you write SQL code that calls stored procedures. It's easier for the DBA to slip up in a your-business-specific way than for the ORM maintainer. Also, with the DBA, only a few people will have access to catch the mistakes whereas lots of people read (and abuse) ORM code regularly.
I think the most important point you mentioned is not the stored procedure, but the lock down. If the app isn't allowed to mangle the data it should not mangle, you are mostly good. The best part is that locking down the database can happen without touching the ORM and is more or less portable across different databases.
If your boss says you must use IIS then not much you can do.
If you pick and choose the other side of the comparison, you can may anything have a better ROI than anything else.
A better comparison would be Windows/IIS/.NET vs. Linux/Apache/<Insert Java Framework Here>
We don't build apps in ASP.NET. We use Ruby. But we do a lot of security work for people with ASP.NET, are knee-deep in a lot of ASP.NET dev teams, and the things ASP.NET does for enterprise apps are not "kool-aid".
What you're really asking is, why would you deploy on an enterprise stack as opposed to a modern app framework. There's lots of reasons, none of which will be congenial to you:
* A much larger pool of available developers
* Better enterprise integration features (depending on your platform, J2EE or ASP.NET may be predetermined for you)
* Better security controls (single signon, LDAP integration, permissioning, etc)
* A preexisting deployment platform that new ASP or J2EE apps can be rolled out onto.
There is really no good reason to do a web startup on ASP.NET or J2EE. So the short answer to your question is, "no, none of us should be using it." But there are lots of valid reasons for businesses to use it.
I've never hired anyone, so I wouldn't know. Is the pool of MS devs really that much bigger than, say, your PHP users?
So, in essence, they are compounding one silly mistake (having .NET at their core) with a second one (using IIS)
Yes. This was a somewhat silly jab, but I couldn't resist.
>I think you're underestimating the number of existing businesses who have .NET at their core, in which case the question is what justifies moving off of .NET? In my experience .NET can be - while not as hip - a very solid framework.
I wanted to know why you'd deploy on that platform initially. Of course if you're already fucking using it, you're probably not going to switch.
Good ms product integration in gereral should also be a valid point.
Also if a company has gotten into the above some time back, when asp on iis servers was the only way(?) for enterprise office integration for large reporting systems, it's easier to let the asp developers learn asp.net and integrate the old enterpise systems with the new. When the old systems are rewritten, asp.net is the way to go, because the customer already has large parts of the infrastructure.
This helped me a couple of times and once when a hack on my wordpress blog only showed different page links to the google bot!