SQL injection - Programmer's challenge

"SQL injection is a code injection technique that exploits a security vulnerability occurring in the database layer of an application. The vulnerability is present when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user input is not strongly typed and thereby unexpectedly executed. It is an instance of a more general class of vulnerabilities that can occur whenever one programming or scripting language is embedded inside another. SQL injection attacks are also known as SQL insertion attacks" - Wikipedia.

Following are some of the good articles that I came across

SQL Injection Attacks by Example

SQL Injection Attacks - Are You Safe?

To sum we can prevent SQL insertion to a greater extent by following the following approaches:

1) Sanitize the input
a) Validate your inputs
b) Get the good content in the input and minimise the bad content

2) Escape/Quote safe the input - Ensure that quotes or escape characters are well handled

3) Use bound parameters or parameterized query statements

4) Use stored procedures for database access

5) Configure error reporting - Errors displayed to the user should not contain database details

6) Limit database permissions and segregate users

Nested Transactions

SQL Server allows you to nest transactions. Basically, this feature means that a new transaction can start even though the previous one is not complete. Transact-SQL allows you to nest transaction operations by issuing nested BEGIN TRAN commands. The @@TRANCOUNT automatic variable can be queried to determine the level of nesting - 0 indicates no nesting , 1 indicates nesting one level deep, and so fourth.

A COMMIT issued against any transaction except the outermost one doesn't commit any changes to disk - it merely decrements the@@TRANCOUNT automatic variable. A ROLLBACK, on the other hand, works regardless of the level at which it is issued, but rolls back all transactions, regardless of the nesting level. Though this is counterintuitive, there's a very good reason for it. If a nested COMMIT actually wrote changes permanently to disk, an outer ROLLBACK wouldn't be able to reverse those changes since they would already be recorded permanently.

When you explicitly begin a transaction, the @@TRANCOUNT automatic variable count increases from 0 to 1; when you COMMIT, the count decreases by one; when you ROLLBACK, the count is reduced to 0. As you see, the behavior of COMMIT and ROLLBACK is not symmetric. If you nest transactions, COMMIT always decreases the nesting level by 1, as you can see illustrated in Figure 1. The ROLLBACK command, on the other hand, rolls back the entire transaction, illustrated in Figure 2. This asymmetry between COMMIT and ROLLBACK is the key to handling errors in nested transactions.

Figure 1: A COMMIT always balances a BEGIN TRANSACTION by reducing the transaction count by one.

Figure 2: A single ROLLBACK always rolls back the entire transaction.

As you can see from Figure 1 and Figure 2, you can nest transactions and use the @@TRANCOUNT automatic variable to detect the level. You also learned that COMMIT and ROLLBACK do not behave symmetrically; COMMIT just decreases the value of @@TRANCOUNT, while ROLLBACK resets it to 0. The implication is that a transaction is never fully committed until the last COMMIT is issued. No matter how deeply you nest a set of transactions, only the last COMMIT has any effect.

Reference: http://www.codeproject.com/KB/database/sqlservertransactions.aspx

Note: All this content is from internet sources.

Association, Aggregation, Composition

Association

When we have only one relationship between objects, that is called Association. Aggregation and Composition both are specialized form of Association. Composition is again specialize form of Aggregation.

Association is a relationship where all object have their own lifecycle and there is no owner. Let’s take an example of Teacher and Student. Multiple students can associate with single teacher and single student can associate with multiple teachers but there is no ownership between the objects and both have their own lifecycle. Both can create and delete independently.

Aggregation

Aggregation is a specialize form of Association where all object have their own lifecycle but there is ownership and child object can not belongs to another parent object. Let’s take an example of Department and teacher. A single teacher can not belongs to multiple departments, but if we delete the department teacher object will not destroy. We can think about “has-a” relationship.

Composition

Composition is again specialize form of Aggregation and we can call this as a “death” relationship. It is a strong type of Aggregation. Child object dose not have their lifecycle and if parent object deletes all child object will also be deleted. Let’s take again an example of relationship between House and rooms. House can contain multiple rooms there is no independent life of room and any room can not belongs to two different house if we delete the house room will automatically delete. Let’s take another example relationship between Questions and options. Single questions can have multiple options and option can not belong to multiple questions. If we delete questions options will automatically delete.

Another example, a university owns various departments (e.g., chemistry) , and each department has a number of professors. If the university closes, the departments will no longer exist, but the professors in those departments will. Therefore, a University can be seen as a composition of departments, whereas departments have an aggregation of professors.

Reference: http://geekswithblogs.net/mahesh/archive/2006/11/03/95960.aspx

The Four Tenets of SOA

John Evdemon has the following to say of SOA in his article with the same title how true is this statement.

'SOA has become a well-known and somewhat divisive acronym. If one asks two people to define SOA one is likely to receive two very different, possibly conflicting, answers. In many ways SOA is a bit like John Godfrey Saxe’s poem about the blind men and the elephant – each of the men describes the elephant a bit differently because each of them are influenced by their individual experiences (e.g. the man touching the trunk believes it’s a snake while the one touching a tusk believes it’s a spear). Mr. Saxe’s elephant is much easier to describe because it exists as a physical entity - SOA, however, is a much harder to describe since design philosophies are not available as a physical manifestation. '

e above is just the begining of wonderful article and it is quite difficult to reproduce the same.

The SOA tenets originally appeared back in 2004 when Don Box published an article on MSDN called "A Guide to developing and Running Connected Systems with Indigo" (Indigo is what's known today as Windows Communication Foundation or WCF for short).

Don continues to define and explain he following 4 tenets:

• Boundaries are explicit
• Services are autonomous
• Services share schema and contract, not class
• Service compatibility is determined based on policy
  

The interesting fact is that Microsoft's Harry Pierson (a.k.a. DevHawk) suggests that Microsoft's own 4 tenets for SOA should be retired because, well, they are, in Harry's opinion, useless - at least they are not useful anymore.

He says, "I would say that the tenets' job is done and it's time to retire them. Once you accept the service-oriented paradigm, what further guidance do the tenets provide? Not much, if any"

If this statement surprises you read the article: Retire Microsoft's Four SOA tenets?

A Performance Comparison of Windows Communication Foundation

Windows Communication Foundation (WCF) is a distributed communication technology that ships as part of the .NET Framework 3.0. The following article concentrates on comparing the performance of WCF with existing .NET distributed communication technologies.

A Performance Comparison of Windows Communication Foundation (WCF) with Existing Distributed Communication Technologies

Here is the conclusion taken from the above article:
To summarize the results, WCF is 25%—50% faster than ASP.NET Web Services, and approximately 25% faster than .NET Remoting. Comparison with .NET Enterprise Service is load dependant, as in one case WCF is nearly 100% faster but in another scenario it is nearly 25% slower. For WSE 2.0/3.0 implementations, migrating them to WCF will obviously provide the most significant performance gains of almost 4x.

WCF vs Remoting

The following blog does the comparison between WCF and Remoting.

WCF vs. Remoting (with DataSet)- performance comparison

Here is the conclusion taken from the above article:
Sending DataSet with .NET Remoting is faster than sending it with WCF. Maybe there is some other way to improve the WCF in case of sending DatSet but I haven't found it yet. I'll post the test project somewhere (maybe on codeproject) so it could be examined.

He further refined his test in the following blog

WCF vs Remoting - adjustments to my results

Here is the conclusion taken from above article:

The WCF and .NET Remoting are really comparable in performance. The differences are so small (measuring client latency) that it does not matter which one is a bit faster. WCF though has much better server throughput than .NET Remoting and WCF does much more than.