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.
Related
I was trying to migrate from Another RDBMS to cockroachDB but I think there is no such functionality like stored procedures in Cockroach. So what is the best alternative to make a stored procedure in cockroachDB ?
CockroachDB does not support stored procedures and the best alternative would depend on the problem you are trying to solve. A few examples:
If the stored procedure contains business logic, we'd recommend moving that logic to the application.
Simple stored procedures that contain a single DML statement should be moved into the application's DataAccess logic.
More complex stored procedures that contain explicit transactions or error code should be moved to the application-level transactions.
EDIT: Stored Procedures as a Litmus Test, an article by Joe Emison, compares Stored Procedures to other solutions. It may be helpful in understanding alternatives.
CockroachDB is distributed SQL and natively suits serverless patterns. As a stored proc is just a way to ensure procedural consistency, you could probably get by using serverless functions (whatever flavor). The idea is the serverless function is a proxy for the stored procedure.
While it is possible for a procs to call other procs, common advice is to avoid having serverless functions call each other. It would be reasonable to develop a cloud library (JavaScript, for example) which models all the DB constraints. Then each serverless function becomes an endpoint (proc) and the library provides the means to reuse/shared logic.
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.
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.
I have a SQL Server stored procedure which has been in use for years. This stored procedure calls lots of other procedures. I would like to extract each inside procedure one at a time and implement its business logic to a .NET Class project.
In order to do that, I have to call .NET assembly from parent stored procedure and the returned result will be used by parent procedure. Since SQL Server 2005 and higher has CLR integration, so I think, executing .NET assembly inside stored procedure [or any Database objects] should not be a big deal, can you please point me some references where i can find examples or article to implement it?
Thank you very much for your help .
I really feel that this would be an inappropriate use of SQL CLR. The purpose of CLR integration is to support complex data types and operations that are normally very hard to do in pure SQL (such as sequences, regular expressions, hierarchy, geospatial, etc.) Not to implement a domain model in your database.
Domain models and business logic are separate from relational/data models. They should be in a proper business tier of some sort. Don't hack them into a database using the CLR.
(Note: I use SQLCLR a fair bit. I am not railing on CLR integration. I just don't think that this question reflects a wise design decision.)
MSDN
Building my First SQL Server 2005 CLR
An Intro to CLR Integration in SQL Server 2005
For loads more ;)
I think you should use SQL Server Integration Services (SSIS). As far as I understand, it solves this case, to orchestrate the procedure calls and gives you much more too..
I'm not too sure if moving this decision outside the db layer is a good decision.
Hope it helps..
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.