Dave Hartley

SQL injection is one of the most devastating vulnerabilities that impact a business, as it can lead to exposure of all of the sensitive information stored in an application’s database, including handy information such as usernames, passwords, names, addresses, phone numbers, and credit card details.

SQL injection it is the vulnerability that results when you give an attacker the ability to influence the Structured Query Language (SQL) queries that an application passes to a back-end database.

SQL injection is not a vulnerability that exclusively affects Web applications; any software that accepts input from an untrusted source and then uses that input to form dynamic SQL statements could be vulnerable (e.g. “fat client” applications in a client/server architecture).

Web applications are becoming more sophisticated and increasingly technically complex. The availability of these systems and the sensitivity of the data that they store and process are becoming critical to almost all major businesses, not just those that have online e-commerce stores.

SQL injection is an attack in which the SQL code is inserted or appended into application/user input parameters that are later passed to a back-end SQL server for parsing and execution. Any procedure that constructs SQL statements could potentially be vulnerable, as the diverse nature of SQL and the methods available for constructing it provide a wealth of coding options. The primary form of SQL injection consists of direct insertion of code into parameters that are concatenated with SQL commands and executed. A less direct attack injects malicious code into strings that are destined for storage in a table or as metadata. When the stored strings are subsequently concatenated into a dynamic SQL command, the malicious code is executed.

When a Web application fails to properly sanitize the parameters which are passed to dynamically created SQL statements (even when using parameterization techniques) it is possible for an attacker to alter the construction of back-end SQL statements. When an attacker is able to modify an SQL statement, the statement will execute with the same rights as the application user; when using the SQL server to execute commands that interact with the operating system, the process will run with the same permissions as the component that executed the command (e.g. database server, application server, or Web server), which is often highly privileged.

There are many ways to exploit SQL injection vulnerabilities to achieve a myriad of goals; the success of the attack is usually highly dependent on the underlying database and interconnected systems that are under attack. Sometimes it can take a great deal of skill and perseverance to exploit a vulnerability to its full potential.

Understanding How It Happens

SQL is the standard language for accessing Microsoft SQL Server, Oracle, MySQL, Sybase, and Informix (as well as other) database servers. Most Web applications need to interact with a database, and most Web application programming languages, such as ASP, C#, .NET, Java, and PHP, provide programmatic ways of connecting to a database and interacting with it. SQL injection vulnerabilities most commonly occur when the Web application developer does not ensure that values received from a Web form, cookie, input parameter, and so forth are validated before passing them to SQL queries that will be executed on a database server. If an attacker can control the input that is sent to an SQL query and manipulate that input so that the data is interpreted as a code instead of as data, the attacker may be able to execute the code on the back-end database.

Each programming language offers a number of different ways to construct and execute SQL statements, and developers often use a combination of these methods to achieve different goals. A lot of Web sites that offer tutorials and code examples to help application developers solve common coding problems often teach insecure coding practices and their example code is also often vulnerable. Without a sound understanding of the underlying database that they are interacting with or a thorough understanding and awareness of the potential security issues of the code that is being developed, application developers can often produce inherently insecure applications that are vulnerable to SQL injection. This situation has been improving over time and now a Google search for how to prevent SQL injection in your language or technology of choice, will usually present with a large number of valuable and useful resources that do offer good advice on the correct way to do things.

Dynamic String Building

Dynamic string building is a programming technique that enables developers to build SQL statements dynamically at runtime. Developers can create general-purpose, flexible applications by using dynamic SQL. A dynamic SQL statement is constructed at execution time, for which different conditions generate different SQL statements. It can be useful to developers to construct these statements dynamically when they need to decide at runtime what fields to bring back from, say, SELECT statements, the different criteria for queries, and perhaps different tables to query based on different conditions.

However, developers can achieve the same result in a much more secure fashion if they use parameterized queries. Parameterized queries are queries that have one or more embedded parameters in the SQL statement. Parameters can be passed to these queries at runtime; parameters containing embedded user input would not be interpreted as commands to execute, and there would be no opportunity for code to be injected. This method of embedding parameters into SQL is more efficient and a lot more secure than dynamically building and executing SQL statements using string-building techniques. One of the issues with building dynamic SQL statements is that if the code does not validate or encode the input before passing it to the dynamically created statement, an attacker could enter SQL statements as input to the application and have his SQL statements passed to the database and executed.

Incorrectly Handled Escape Characters

SQL databases interpret the quote character (‘) as the boundary between the code and data. They assume that anything following a quote is a code that it needs to run and anything encapsulated by a quote is data. Therefore, you can quickly tell whether a Web site is vulnerable to SQL injection by simply typing a single quote in the URL or within a field in the Web page or application. The single-quote character is not the only character that acts as an escape character; for instance, in Oracle, the blank space ( ), double pipe (||), comma (,), period (.), (*/), and double-quote characters (“) have special meanings.

Incorrectly Handled Errors

Improper handling of errors can introduce a variety of security problems for a Web site. The most common problem occurs when detailed internal error messages such as database dumps and error codes are displayed to the user or attacker. These messages reveal implementation details that should never be revealed. Such details can provide an attacker with important clues regarding potential flaws in the site. Verbose database error messages can be used to extract information from databases on how to amend or construct injections to escape the developer’s query or how to manipulate it to bring back extra data, or in some cases, to dump all of the data in a database.

Insecure Database Configuration

You can mitigate the access that can be leveraged, the amount of data that can be stolen or manipulated, the level of access to interconnected systems, and the damage that can be caused by an SQL injection attack, in a number of ways. Securing the application code is the first place to start; however, you should not overlook the database itself. Databases come with a number of default users preinstalled.

Microsoft SQL Server uses the infamous “sa” database system administrator account, MySQL uses the “root” and “anonymous” user accounts, and with Oracle, the accounts SYS, SYSTEM, DBSNMP, and OUTLN are often created by default when a database is created. These are not the only accounts, just some of the better-known ones; there are a lot more! These accounts are also preconfigured with default and well-known passwords.

Some system and database administrators install database servers to execute as the root, SYSTEM, or Administrator privileged system user account. Server services, especially database servers, should always be run as an unprivileged user (in a chroot environment, if possible) to reduce potential damage to the operating system and other processes in the event of a successful attack against the database. However, this is not possible for Oracle on Windows, as it must run with SYSTEM privileges. Each type of database server also imposes its own access control model assigning various privileges to user accounts that prohibit, deny, grant, or enable access to data and/or the execution of built-in stored procedures, functionality, or features. Each type of database server also enables, by default, functionality that is often surplus to requirements and can be leveraged by an attacker (xp_cmdshell, OPENROWSET, LOAD_FILE, ActiveX, Java support, etc.).

Application developers often code their applications to connect to a database using one of the built-in privileged accounts instead of creating specific user accounts for their applications needs. These powerful accounts can perform a myriad of actions on the database that are extraneous to an application’s requirement. When an attacker exploits an SQL injection vulnerability in an application that connects to the database with a privileged account, he can execute code on the database with the privileges of that account. Web application developers should work with database administrators to operate a least-privilege model for the application’s database access and to separate privileged roles as appropriate for the functional requirements of the application.

In an ideal world, applications should also use different database users to perform SELECT, UPDATE, INSERT, and similar commands. In the event of an attacker injecting code into a vulnerable statement, the privileges afforded would be minimized. Most applications do not separate privileges, so an attacker usually has access to all data in the database and has SELECT, INSERT, UPDATE, DELETE, EXECUTE, and similar privileges, these excessive privileges can often allow an attacker to jump between databases and access data outside the application’s data store.

When an attacker exploits an SQL injection vulnerability he will often attempt to access database metadata. Metadata is data about the data contained in a database, such as the name of a database or table, the data type of a column, or access privileges. Other terms that sometimes are used for this information are data dictionary and system catalog. The better approach is to operate a least-privilege model for the application’s database access and to separate privileged roles as appropriate for the functional requirements of the application.

Raihan Taher

What are Generics?

In C#, generics are used to create classes, methods, structs and other components that are not specific, but general. This allows us to use the generic component for different reasons. Generics give us some extra power of reusability in our code, which is good for an application as there would be less code which does similar work. Generics are not newly developed; they has been available since C# 2.0.

The angle brackets <>, next to the Price class is the syntax of generics in C#. By putting <> next to the class name, we are telling the compiler that this is a generic class. Furthermore, the T inside <> is a type parameter. A type parameter is like any other parameter in C# programming, except it passes a type instead of a value or reference. We created a generic Price class. To make it generic, we placed next to the class name. Here, the T is a type parameter, but it’s not something fixed that you have to use T with to represent the type parameter you can use anything to represent it. However, it is traditional to use T for the type parameter. If there are more type parameters, V and E are used. There is another popular convention when using two or more parameters, which is to name the parameter something such as TValue and TKey, instead of just V and E,
which is done for better readability. However, as you can see, we have prefixed T before the words Value and Key, which is done to distinguish between a type parameter and a general parameter.

When we run the preceding code, the type that we pass in the class will be the type of the object ob. Consequently, we can say that T is a placeholder, which will be replaced with some other concrete C# types (int, double, string, or any other complex type) in the runtime.

In the constructor, we passed a parameter of the T type and then assigned the value of the passed parameter, o, to the local variable, ob. We can do this assignment as the parameter passed in the constructor is also the T type.

Why do we need generics?

The object type can be used for any type in C#, and the preceding example can be achieved through the use of an object type. Yes, the preceding example can be achieved through the use of the object type, but there won’t be any typesafety. In contrast, generics ensure that the type-safety is there when the code gets executed. Type safety actually refers to keeping the type secure or unchangeable when executing any task in the program. This helps us reduce runtime errors.

Different constraints of generics?

There are different types of constraints available in C# generics:

Base class constraints: The idea of this constraint is that only the classes that extend a base class can be used as generic type. For example, if you have a class named Person and you use this Person class as a base for the Generic constraint, only the Person class or any other class that inherits the Person class can be used as the type argument for that generic class.

Interface constraints: Similar to the Base class constraint, we see the interface constraint when your generic class constraint is set as an Interface. Only those classes can be used in the generic method that implements that interface.

Reference type and value type constraints: When you want to differentiate between your generic class and reference types and value types, you need to use this constraint. When you use a Reference type constraint, the generic class will only accept the Reference type objects.
To achieve that, you have to extend your generic class with a class keyword. Furthermore, when you want to use a value type, you have to extend your generic class with a ‘value type’ keyword. So, when you make a value type constraint, this means that the generic will only work for value types such as int or double. No reference type, such as string or any other custom class, will work.

Generic methods

Like the Generic class, there can be generic methods, and a generic method does not necessarily have to be inside a generic class. A generic method can be inside a non generic class as well. To create a generic method, you have to place the type parameter next to the method name and before the parenthesis. The general form is given here:

access-modifier return-type method-name<type-parameter>(params)

Here, we can see that the Hello class is not a Generic class. However, the Larger method is a generic method. This method takes two parameters and compares them, returning the larger value. This method has also implemented a constraint, which is IComparable. In the main method, we have called this generic method several times, once with int values and once with double values. In the output, we can see that the method was successfully able to compare and return the larger value.

In this example, we have used only one type of parameter, but it is possible to have more than one parameter in a generic method. We have also created a static method in this example code, but a generic method can be non static as well.

The Compiler is getting smarter, the previous code is an example of a type-inferencing in a generic method. Type-inferencing means calling a generic method without specifying the type parameter, and letting the compiler identify which type to use. This is because the compiler used type inferences to figure out the type of arguments that were passed in the methods and executed the method as if the parameter type was already given to the compiler. Because of that, when you use a type inference, it’s not allowed to provide different types of arguments in a generic method. If you need to pass different types of arguments, you should explicitly do that. You can also apply the constraints on a method that can be applied on the classes as well.

Covariance and contravariance in generics

However, from C# 4, these are also available for generic interfaces and delegates, the concepts of covariance and contravariance in generics is almost the same as it is in delegates.

Covariance: This means that the generic interface that has a T type parameter can return T or any class that is derived from T. To achieve this, the parameter should be used with the out keyword.

access-modifier interface-name<out T>

Contravariance: The word “Contravariance” might sound a little complex, but the concept behind it is very simple. Normally, when creating a generic method, the argument we pass to it is the same type as T. If you try to pass another type of argument, it will give you a compile-time error. However, when using contravariance, you can pass the base class, which the type parameter implements. In addition, to use contravariance, there is a special syntax we have to follow.

access-modifier interface interface-name<in T>

We will see that we have created an Interface named IFood, which uses contravariance, this means that if this interface is implemented in a generic class, that class will allow the base class of the provided type parameter. The T in the IFood interface method signature is used as a parameter in the method. Now, a class named HealthyFood implements the interface, and the method that is implemented in the class only prints a string. Then, we created two classes: Vegetable and Carrot. Carrot extends Vegetable. Both classes override the ToString() method, and return Carrot if the class is Carrot or Vegetable if the class is Vegetable.

In the main method, we create an object of the Carrot class and an object of the Vegetable class. Both of these are kept in the IFood variable. The interesting part here is that the mySelf2 variable is of the IFood type, but it holds an object of the HealthyFood type. This is only possible because of contravariance. If you remove the in keyword and try to run the program again, you will fail and the compiler will throw an error to say that this is not possible. It was only possible to run the code because of contravariance.

Raihan Taher

What is a delegate?

A delegate is a proxy, an alternative, or a representative of someone else. For example, we may read in the newspaper that a delegate from another country is coming to our country to meet a high official. This person is a delegate because they have come to our country to represent their own country. They could be a representative for the president, prime minister, or any other high official of that country. Let’s imagine that the delegate is representing the president of a country. Maybe the president was unable to attend this meeting in person for some reason, and that is why a delegate was sent on their behalf. This delegate will do the same work that the president was supposed to do on the trip and make decisions on behalf of the president. The delegate is not a fixed individual; could be any qualified person that the president chooses.

The concept of a delegate is similar in software development. We can have a functionality where a method doesn’t do the actual work that it was ask to do, but rather, it will call another method to execute that work. Furthermore, in programming, the method that doesn’t do the actual work, but passes it to another method, is called a delegate. Consequently, a delegate will actually hold a reference of a method. When the delegate is called, the referenced method will actually be called and executed. Now, you may ask, “Why should I call a delegate if it is going to call another method? Why don’t I just call the method directly?”. Well, we do this because if you directly call the method, you lose your flexibility by making your code coupled. You are hard coding the method name in your code so that, whenever that line of code will run, that method will be executed. However, with a delegate, you can decide which method to call at runtime instead of compile time.

At he very top, we can see the declaration of the delegate, the delegate keyword indicate to the compiler that we are declaring a delegate. Then we set the return type to int and named the delegate MathFunc, we also passed two int parameters in this delegate. After that we have two methods in addition to the main method, one is Add and the other is Sub, if you pay close attention to these methods, you will see that they have the same signature as the delegate, this is done deliberately, because a method can use a delegate when the method has the same signature as the delegate.

Method Group Conversion

In the previous example, we saw how can create an object of a delegate and pass the method name in the constructor, now we will look a another way of achieving the same thing. With method group conversion, you don’t need to initialize the delegate object, but you can directly assign the method to it.

We can see that instead of passing the method name in the constructor, we directly assign the method to it.

Using the static and instance methods as delegates

In the previous examples, we used static methods in the delegates, however you can also use instance methods in delegates.

To use those methods in delegates, we first have to create an object of that class and simply assign the methods to a delegate using the object instance.


With multicasting, you can assign more than one method to a delegate. When that delegate is executed, it runs all the methods that were assigned one after another. Using the + or += operator, you can add methods to a delegate. There is also a way to remove added methods from the delegate. To do this, you have to use the – or -= operator.

Here, we can see how our delegate executed the two methods one after the other. We have to keep in mind that it works like a queue, so the first method you add will be the first method to get executed.

Covariance and Contravariance

In the previous examples the return type and the parameters of the method and the delegate have to be the same. However, with the use of the concepts of covariance and contravariance, you can actually register methods to a delegate that don’t have the same return types or parameters. The delegate will then be able to execute them when called. Covariance is when you assign a method to a delegate that has a return type that is a derived type of the delegate’s return type. For example, if class B is derived from class A, and if the delegate returns class A, then a method can be registered to the delegate that returns class B.

On the other hand, contravariance is when a method is passed to a delegate and the parameters of the method don’t match the parameters of the delegate. Here, we have to keep in mind that the parameter type of the method has to be at least derived from the parameter type of the delegate.


You can think of an event as a kind of method that gets executed in some circumstances and notifies handlers or delegates about that incident. You can also create different event handlers and assign those event handlers to an event so that, whenever that event gets fired, it will notify all the registered handlers that will perform their work.

Multicasting Events

You can multicast events in the same way that you can in a delegates. This means that you can register multiple event handlers (methods that have subscribed to the event) to an event and all of them will be executed one by one when the event gets fired. To multicast, you have to use the += sign to register event handlers to the event. You can also remove event handlers from the event by using the -= operator. When you apply multicast, the first event handler that was registered will get executed first, then the second, and so on. By multicasting, you can easily extend or reduce event handlers in your application without doing much work.

Event Guidelines From .NET

For better stability, .NET Framework has provided some guidelines for using events in C#. It’s not that you absolutely must follow these guidelines, but following these guidelines will certainly make your program more productive. Now let’s see what guidelines we need to follow.

  • The reference to the object that generated the event.
  • The type of EventArgs that will hold other important information needed by the event handlers.