We can precompile our (ASP.NET) websites and can publish only the IL code, so that the source code is not available to the customer.
But how do we do it for stored procedures written in SQL Server. I mean, when we give the customer the DB, he could see all my stored procedures and can modify the same... How could I protect it.
Thanks
Raja
An old problem. Here are a few answers I've picked up here and there:
Encrypt the stored procedures. As has
already been pointed out twice, this
doesn't really work, as 5 minutes of
Googling will find several hacks.
Write the stored procedures as CLR
procedures. Harder to hack than
"regular" stored procedures, probably
a lot more effort to produce and
support.
Submit all queries dynamically from
your compiled IL code. I understand
it can be done reasonably secure from
SQL injection attack, but make darn
sure before you release. (Maybe use Linq to do this?)
Convert all database object names
(tables, columns, procedures) to
guids or random gibberish. They could
read it, but that wouldn't help much.
I am not totally conversant on encryption within SQL 2005 and up. I really don't think you can use it on code-based objects (procedures, functions, etc.), but maybe you can?
But by and large, once you give a copy of your database to someone with SysAdmin rights, they can do pretty much anything they want with it.
use WITH ENCRYPTION
example
CREATE PROCEDURE prTest
WITH ENCRYPTION
AS
SELECT GETDATE()
Keep in mind that it can be cracked and also make sure you have the unencrypted source code backed up
CREATE PROCEDURE ... WITH ENCRYPTION
However note that this encryption is really more like obfuscation, and there are several ways to bypass it if your vendor is determined, including the DAC connection, some 3rd party products (including RedGate SQL Prompt), and code samples you can readily find online.
Related
I'd like to know the best architecture.
We have a web application running different domains. Each domain has its own MySQL database but the db structure is the same for all of them.
We have a web application for the visible part of the application.
We have a dataLogic project
We have a dataEntities project
We have a dataAccess that contains only the methods to connect to the data base.
Before we called stored procedures on a database. But we had to change it because the performance was bad. Also, the problem was that every change we made we had in a stored procedure we had to copy to every database.
We are thinking in using a WebService to retrieve the data. Every domain can call the web service with a connection string and connect its database to retrieve data. This way when we change a SQL query we only have to compile the webService and change it, we don't have to change versions on multiples domains.
Also, what do you think about the SQL queries? Since we don't want to keep using stored procedures, what is the best way to do it? Directly from code?
Thanks
T
If you have multiple Database servers you will have to make Structural changes from one DB to another one way or another. There are many tools to change Database structures. These tools will look for differences between Schema, and will either generate the SQL code for you, or do the changes by itself (it depends a lot in the tool, there are powerful ones and not so powerful ones). Please do take a look at Toad for MySql. Now, for the Data changes, you may want to replicate the data from one Database to another. This is done through Replication.
We are thinking in using a WebService to retrieve the data. Every
domain can call the web service with a connection string and connect
its database to retrieve data.
This sounds like a good idea and since you already have "dataAccess" and "dataLogic" projects, it should not be too hard to make the services.
Also, what do you think about the SQL queries? Since we don't want to
keep using stored procedures, what is the best way to do it? Directly
from code?
I don't think it is a good practice to have the SQL queries directly into your code, but it depends in a lot of things, so I would suggest Stored Procedure vs Hard-Coding the queries, or LinQ (Entity Framework 4.1).
Good luck with your project and I will take a look at this thread frequently to see what you end up doing.
Have fun!
Hanlet
I am only starting with Entity Framework and I appreciate the direct mapping of code to the tables in my database. What I do not see just yet is the practicality of having to use EF over stored procedures and I would appreciate anyone's opinion about this. I am not being lazy and I am searching this myself at the moment. Thought I can post the question and hear from others as well.
My case is EF being an ORM is most suited to mapping in the tables in my database. But in a live web server many requests can happen at one time that may be taxing the database in having to compile the text queries prior to executing them compared to just simply executing stored procedure which are pre-compiled already. EF can also map to SPs but I feel that this is somewhat diminishing the value of ORM.
I would really appreciate an eye-opener in this case.
You might find Jeff's commentary on the subject helpful: http://www.codinghorror.com/blog/2005/05/stored-procedures-vs-ad-hoc-sql.html.
His point is basically that stored procedure's can be seen as a kind of premature optimization, and you really should make sure this is the performance bottleneck in your application before going that route. For instance, there are frameworks available to mock up 1000's of simultaneous web requests to see how your database will really perform under load in one situation versus the other.
Just because EF isn't using sprocs, it doesn't mean that the parameterised queries it runs won't get compiled and cached. SQL Server has got a lot more clever about that over the years.
One possible approach:
- dynamic sql for single objects
- SPs for parameterized lists and orders
The value of the ORM is usually its simplicity in creating the object model. One approach is described here: http://www.codeproject.com/Articles/362034/Populating-a-business-logical-layer-from-stored-pr
I want to use an ORM, and have been looking at EF 4. Is this platform scalable. I see a lot of stuff on the web, but everything looks very biased in one way or the other. Anyone know of benchmarks or non-subjective information.
On that point, does EF prevent SQL injection or XSS. I know that it used parametrized queries, but is that enough?
Any help is appreciated.
Okay so i see two questions here.
Is EF Scalable
Very difficult (and subjective) to answer, but IMO yes.
Here's a few reasons why:
Utilizes a common querying language (LINQ)
Allows for multiple providers (SqlServer, Oracle, etc)
Allows bi-directional mapping (code first, model first, database first)
Includes "classic ADO.NET" support (stored procedures, Entity-SQL)
The main real benefit in scalability is how the framework is built on LINQ-to-Entities. When you write queries, you are not writing against SQL Server or Oracle, you are writing against the Model. Depending on what Provider you have setup (in web.config), EF will translate these model queries into the appropriate T-SQL (or P-SQL).
Therefore (theoretically), you could write code against SQL Server, then change the web.config provider to Oracle, and your code should work. Obviously this isn't the case for Entity-SQL though (as you are writing T-SQL, not LINQ).
Does EF prevent SQL injection or XSS
No ORM tool can really "prevent" SQL Injection attacks - they can only provide the developer with the tools to prevent it.
As with classic ADO.NET where you use parameterized queries, Entity Framework has Entity-SQL, which allows to to execute pre-generated SQL, stored procedures, etc.
In this scenario, you need to use parameterized queries to prevent SQL injection. For most EF work, you will be writing queries with LINQ, which is a lot safer because it gets hydrated through a lot of stages before it becomes SQL.
XSS is exploited on the client-side via things like injected JavaScript, dodgy emails, etc. Has nothing to do with Entity Framework. Prevention of XSS is done on the client-side with things like HTML encoding.
No. ORMs are not a panacea for scalability. There is such a things called the impedance mismatch of objects and databases which has been around for many years. ORMS try to solve this by providing magic code generation/mapping solutions that give the appearance of just working with objects.
In a multi-tier environment with many client programs and a single/many server scenario, for every change that has to be committed to the database, checks need to be performed to make sure that your not over writing someone elses change on the data, or trying to update data that has been removed. This is not a new problem introduced by ORMs but one which appears many many times throughout the ages of updating databases in N-Tier environments. ORMS do not solve this problem. In some cases, if the ORM is the single entry to the Database, the ORM becomes a bottle neck. This means that to create a scalable architecture using an ORM becomes problematic as having DB checks performed on the ORM means that the update anomaly checks could be by passed if your using an N-Tier ORM solution where you have duplicate ORM tiers.
For the reasons above, this is why we use stored procedures. But if your using stored procedures, which naturally obfuscate the underlying data structures of the database then this increases the impedance mismatch of objects and database entities. One thing about using stored procedures and relying on table locking/row rocking, some of the update scenarios are solved, as we shift the bottle neck to the performance of the underlying database design.
So whats the answer. Don't use objects for databases. Object are great for analysis, bad for code design when interacting with RDBMS databases.
If your really thinking SQL and RDBMS data solutions are a problem, which in some scenarios they are, take a look at some of the NOSQL solutions out there. Still not a panacea for all problems, but in some cases they provide a better solution than a straight SQL solution.
Objects are not the answer to all problems. Step back from your code, take a look at what your trying to do, and think if an object is the right approach.
As for security, no ORMS do not aid security. Although they do help prevent some forms of injection attacks.
Is it somehow possible to create a stored procedure when using SQLite?
SQLite has had to sacrifice other characteristics that some people find useful, such as high concurrency, fine-grained access control, a rich set of built-in functions, stored procedures, esoteric SQL language features, XML and/or Java extensions, tera- or peta-byte scalability, and so forth
Source : Appropriate Uses For SQLite
Answer: NO
Here's Why ... I think a key reason for having stored procs in a database is that you're executing SP code in the same process as the SQL engine. This makes sense for database engines designed to work as a network connected service but the imperative for SQLite is much less given that it runs as a DLL in your application process rather than in a separate SQL engine process. So it makes more sense to implement all your business logic including what would have been SP code in the host language.
You can however extend SQLite with your own user defined functions in the host language (PHP, Python, Perl, C#, Javascript, Ruby etc). You can then use these custom functions as part of any SQLite select/update/insert/delete. I've done this in C# using DevArt's SQLite to implement password hashing.
Chris Wolf made a prototype implementation of SQLite with stored procedures. You can find the details at his blog post: Adding Stored Procedures to SQLite
Yet, it is possible to fake it using a dedicated table, named for your fake-sp, with an AFTER INSERT trigger. The dedicated table rows contain the parameters for your fake sp, and if it needs to return results you can have a second (poss. temp) table (with name related to the fake-sp) to contain those results. It would require two queries: first to INSERT data into the fake-sp-trigger-table, and the second to SELECT from the fake-sp-results-table, which could be empty, or have a message-field if something went wrong.
No, but you can :
Write long multi-statement scripts
Create temporary one-row tables called e.g. Vars to hold variables
Create a View over a Recursive CTE to program arbitrary functions in pure SQL queries.
So you can do most things you would normally do with stored procs.
For how to program functions in a SQL View see https://www.cafe-encounter.net/p3300/pretending-that-sqlite-has-stored-procedures-and-functions.
Alternatively you can:
Compile short single-page C programs to program arbitrary functions
This is easier and less work than you might think!
A step-by-step guide is at https://www.cafe-encounter.net/p3244/installing-and-using-sqlite-extensions-on-macos-and-maybe-windows-linux-too . This does add some deployment work: you will have to deploy the additional dll/so/dylib files with your application.
I've come across this question myself. I think stored procedures are supported in PHP PDO, but that module is handling it and building normal SQL queries to send to SQLite. So, in PHP, possible to write stored procedures in your code, but no performance gain from using them.
Correct me if I'm wrong, please.
I'm wondering how SQLite implements it. Is it based on file-locking? Surely the entire DB isn't locked for every user that accesses it; that would be extremely inefficient. Is it based on multiple files or just one big file?
Would be nice if someone could give a short overview of how synchronization and locking is done in sqlite, or, of course, provide a link to one.
Have a look at the SQL Lite FAQ and this on locking. Hope this helps.