What are the security implications of websites accessing database views instead of using stored procedures? The views in question are only being read from; not written to.
Edit
The applications in question are ASP.Net MVC 2 using the Entity Framework (v.4).
One security implication - probably the biggest: Views leave you open to the same SQL Injection flaws that accessing tables directly does, if you're building your select statement based on user input.
That's about it, and only if you're basing your SQL statement on input. If you just have a view that is static and you never filter or sort based on input, just select fields from the view, you're no safer or less safe with a stored procedure that returns the same results without parameters.
Other than that, using stored procedures is, in my opinion, just a good habit, and in SQL Server you get optimization features from stored procedures, but that's not security related.
Views don't open you to injection attacks at all. Bad code does that. Even if you use stored procedures using concatenated/in-line SQL will do that for you no problem.
Use prepared statements. You will be fine. Views are 100 times easier to work with than debugging ugly stored procedures.
Related
I'm in the planning stages of a Microsoft ASP.NET / SQL Server 2008 based web application and In thinking about database design, I began to think about injection attacks and what strategies I should employ to mitigate the database as a vector for injection attacks.
I've heard from various sources that using stored procedures increases safety, I have also read that these are equally as infective if they are still used with dynamic SQL as this presents an injection point
Question
Is it possible to use a Parametrized Query inside a stored procedure? My thinking is that if I pass the arguments to the stored procedure into the prepared statement the database engine will sanitize those arguments for me.
Yes you can pass Parametrized query inside a store procedure.
but it think it will not use execution plan in the procedure
and work slow as per my knowledge.
First, I am NOT trying to spur yet another debate about LINQ vs. stored procedures.
Assume for this question (for right or wrong) that I'm going to use SQL server stored procedures and will access those stored procedures via LINQ. I am using stored procedures (again, for right or wrong) because I want to enforce security at the stored procedure level vs. on the underlying tables and views. I am using LINQ (once again, for right or wrong) because I want to learn it.
Given the above, my LINQ queries should be relatively simple SELECT statements (obviously just referring to reading data in this question) rather than LINQ queries that contain groupings or calculations or generally other more complex things. This assumption is based on my plan to put this logic in T-SQL. In other words, my LINQ queries will be relatively "dumb". In addition, given my desire to enforce security at the stored procedure level and not allow access to the base tables, I see this approach as being consistent with that goal.
Are there any flaws in my logic in #1?
If I were to use LINQ directly against the base tables, I'd obviously have to enforce security directly on those base tables. This seems obvious but I wanted to confirm.
Any flows in my logic in #2?
LINQ on its own is quite generic, as there is linq-to-objects, linq-to-xml, linq-to-sql, linq-to-EF etc. I guess you're likely going after the Linq-to-Sql functionality (as opposed to, say , Linq-to-EF). By doing that all your sets are provided by stored procedure and interrogate these sets in the application with Linq I would say that you will teach yourself a very skewed way of leveraging the power of Linq in general, and Linq-to-Sql in particular. You will miss much of the know-how that goes into understanding how Linq-to-Sql generates the SQL queries sent to the server, because you'll be able to do only the very basic 'dumb' queries as you say. Eg. you won't even be able to do a join in Linq-to-Sql. And you'll miss the opportunity to properly understand the ORM capabilities of Linq-to-Sql, the caching that goes into DataContexts and the ActiveRecord behavior that allows you to insert/update/delete items from sets.
Although I do not advocate against doing what you're doing (it is a very valid approach to leverage stored procedures and linq together), I would say that is a bad approach for learning Linq. Try getting your feet wet with a straight approach, the kind of data-modeling in Visual Studio with a .dbml file approach advocated by Linq evangelists in 2008. While I reckon that this approach is flawed for deploying large, viable, projects, it is though very good to teaching yourself Linq and Linq-to-Sql in particular. Once you understand how things work, you'll be able to understand how to properly leverage this with a stored procedures for separation of access control (an approach always praised by SQL Server evangelists) and how deal with the issues not solved by the .dbml modeling approach (specifically, the problem of database schema upgrades).
Some may say you should also perhaps keep an eye out for what Entity Framework has to offer, but if you are in the learning stage I whole heartily recommend Linq-to-Sql instead. It is less complex, it works, is sane, is well supported in the VS tool set, and you don't have to learn Entity-SQL...
I am looking to insert and update records in a database using functions and logic that are not available in SQL Server or any other RDBMS for that matter. After Googling around a bit this morning, I have come across the concept of Extended Stored Procedures. As far as I can tell, I should be able to compile my desired functionality into a dll, make a stored proc utilizing that dll to do the inserting/updating.
However, most of the articles and examples I have come across are somewhat dated (~2000). Are extended stored procedures still an acceptable practice? I am far from an expert in this area, so any other suggestions or comments would be greatly appreciated.
If you're using SQL Server 2005 or later, SQL CLR is the area to look at. You can call .NET code from within SQL Server.
This article on MSDN is a good place to start.
Are extended stored procedures still
an acceptable practice?
No, they are officialy deprecated and will be dicontinued in a future release. See Deprecated Database Engine Features in SQL Server 2008 , in the Features Not Supported in a Future Version of SQL Server table:
Extended stored procedure programming: Use CLR Integration instead.
I usually recommend against using CLR procedures, in most cases you can refactor the problem you are facing, into something that Transact Sql can handle.
Of most concern is the procedural approach that often accompanies the use of CLR procedures, when a relation database performs best when performing set based operations.
So the first question I always ask, is there anyway to refactor the problem into a set based operation.
If not, then I ask why would you want to execute the code inside of the database server, instead of in an application layer? Think about the performance impact you might have by placing the logic inside the database. (This might not be an issue if your db server has plenty of extra processing time).
If you do go head with CLR procedures, I think they are best applied to intensive calculations and complex logic.
Linq to SQL and Linq to Entities depend on creating dynamic SQL to do a lot of their work, specially when you have classes represent database tables in some fashion. However if the database(s) does not allow ad hoc SQL queries and everything has to go through stored procedures, I don't see the big value of using L2Q or L2E if the developer has to write all the SP's upfront to do all the work AND know that these are the all SPs that will ever be used in all scenarios in the app.
Views might alleviate the situation but if creating views need DBA permissions, it is still a hassle.
LINQ-to-SQL's stored procedure implementations will still return your entity objects; you don't get the super-incredible filtering capabilities that L2S provides by creating dynamic SQL, but you still can use the extensions to parse through.
Like I said, you can still add your schema and when your stored procs return those entities, you get that object relationship mapped already.
I still think it's handy :)
If you are restricted to stored procedures than your best choice is Linq-to-Sql it works fairly well if your goal is to map classes one to one with result sets from stored procedures.
There are some quirks with the designer for sure but once you get them figured out it works very well for mapping result sets to classes.
There is a big difference between using "stored procedures" for ORM and using a tool like NHibernate and mapping straight to your tables.
Mapping straight to tables gives your all the awesome stuff like lazy loading and the repository pattern.
here is my blog post on setting up linq-to-sql using stored procedures, hope it helps
If I were your dba I too would not allow access through any type of dynamic SQL. It is a bad practice to allow direct permissions to the tables, it makes it far too easy for employees to commit fraud or to steal sensistive data. LINQ2SQl also seems to write inefficent code (at least all the examples of the code it writes that I have seen are code I wouldn't allow in my database) and it is much much easier to performance tune stored procedures.
Be grateful you have a good dba who actually cares about database security and performance.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Is there any alternative to stored procedures, secure and fast as well as stored procs. i know only Hibernate. Is there any other technologies like that?
Stored procedures are a place to put code (SQL) which executes on the database, so I understand the question to mean
"is there any other way to package up the code which runs on the database?"
There are several answers:
There is nothing else that is quite the same as a stored procedure, but there are alternatives which you might consider.
You could write all your SQL as strings inside your client code (java or whatever)
This has various problems (loss of encapsulation, tight coupling -> harder maintenance), however, and is not a good idea.
You could use an ORM such as NHibernate, which inserts a layer between your client logic and the database. The ORM generates SQL to execute on the database. With an ORM, it is harder to express complex business logic than in a stored procedure (sweeping generalisation!).
A kind of halfway house is to define your own data access layer (DAL) in java (or watever you're using) and keep it separate from the main body of client code (separate classes / namespaces / etc.), so that your client makes calls to the DAL, and the DAL interprets these and sends SQL to the database, returning the results from the database back to the client.
Yes. you can use dynamic sql, but I personally like stored procedures better.
1) If you're using MS SQL Server, it will generate a query plan which should enable the stored procedure to execute faster than simple dynamic sql.
2) It can be easier an more effective to fix a bug in a stored procedure, expecially if your application calls that procedure in several spots.
3) I find it's nice to encapsulate database logic in the database rather than in embedded sql or application config file.
4) Creating stored procedure into the database will allow sql server to do some syntax, and validation checks at design time.
Hibernate is an object/relational persistence service.
Stored procedure is a subroutine inside a relational database system.
Not the same thing.
If you want alternative to Hibernate, you can check for iBatis for Spring
You can do dynamic SQL as secure and fast as stored procedures can be, it just takes some work. Of course, it takes some work to make stored procedures secure and fast also.
A stored procedure is a subroutine
available to applications accessing a
relational database system. Stored
procedures (sometimes called a proc,
sproc, StoPro, or SP) are actually
stored in the database data
dictionary.
Typical uses for stored procedures
include data validation (integrated
into the database) or access control
mechanisms. Furthermore, stored
procedures are used to consolidate and
centralize logic that was originally
implemented in applications. Large or
complex processing that might require
the execution of several SQL
statements is moved into stored
procedures, and all applications call
the procedures only.
Stored procedures are similar to
user-defined functions (UDFs). The
major difference is that UDFs can be
used like any other expression within
SQL statements, whereas stored
procedures must be invoked using the
CALL statement
..from Wikipedia
I think you need to read this article and reframe your question. Hibernate has nothing to do with stored procs.
Hmm, seems to me that the obvious alternative to stored procedures is to write application code. Instead of, say, writing a store procedure to post a debit every time a credit is posted, you could write application code that writes both.
Maybe I'm being too simplistic here or missing the point of the question.
It'd help a little more if you said why you are looking for alternatives,
what about stored procs do you not like?
Some databases (eg. PostgreSQL) also allow you to write stored procedures in
different languages. So if you really want to you can write them in Python or
Java or the like, instead of SQL.
I think the OP means that an alternative to writing all his database code directly in his application code is either to call stored procedures or to introduce a layer of separation between his application code and database using an ORM such as Hibernate, but yes they are very different things.
Using stored procedures let you keep your SQL in one place separate from your application code. Using Hibernate allows you to avoid writing SQL completely and provides an object representation of the relational database.
Which way you go depends alot on the application and your own preferences.