Mass Infection of IIS/ASP Sites

Post by rbanffy » Thu, Jun 10, 2010, 3:32 AM UTC

tptacek wrote: post #40

rbanffy wrote: post #39

Earlier quoted context omitted.

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…

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 s…

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.

Post by thrdOriginal » Thu, Jun 10, 2010, 3:55 PM UTC

jgg wrote: post #34

thrdOriginal wrote: post #11

Earlier quoted context omitted.

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…

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").

Re: Mass Infection of IIS/ASP Sites

Re: Mass Infection of IIS/ASP Sites