OWASP - User contributions [en]

OWASP Backend Security Project .NET Security Programming

2008-08-01T18:35:18Z

GPederzini: /* .NET Preventing LDAP Injection */

= Overview =

In this section are explained the best solution to avoid two of the most dangerous vulnerabilities of web applications, the sql injection and ldap injection on .NET programming

It will be analized the interactions between a web application written in C# in ASP.NET technology, .NET Framework 2.0 and two kinds of data provider: a SQL Server 2005 data provider and an OpenLdap Server data provider.

For the first interaction imagine a database called “ExampleDB” in which there are some tables. One of these tables is “Users”. From a
web application is possible to query the database to extract information about the users through their name.

For the second interaction imagine an Ldap server called “ExampleLDAP”.

The project is simple and is made by some .aspx page with a textbox in which is possible to insert the name of the user and the program will return the information, reading from ExampleDB (or ExampleLDAP).
It's not important to specify how it's possible to create an aspx page So the focus is on the code that we have to write to interact with the server data provider.

= Description =

== .NET Preventing SQL Injection ==

Two approaches are likely: inline query or stored procedure.

[[Image:owasp_bsp_net_1.jpg]]

=== Case 1: Inline query ===

Inline queries are the queries in which is possible to compose a sql statement through string concatenation. By clicking on the first button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryInline_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%"
+ txtQueryInline.Text + "%'", sqlConnection);
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section of code provides the sqlConnection, reading the connectionString from the Web.Config file. This is an important task for the application because it represents the entry point to the database, the credentials of the user that can authenticate on the ExampleDB.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%" +
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;

In this section is used the SqlCommand class, in which is written the sql code, concatenating with the text to search. The type of the SqlCommand is “Text”, so it's clear that the sql code is provided directly. This code is prone to sql injection, because we can manipulate the statement, injecting in the textbox, for example, the string:

'' '; sql statement -- ''

where sql statement is any sql code (it is possible to drop tables, add users, reconfigure the xp_cmdshell, etc.)

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

The third section is useful to represent the result set of the query. It uses the ADO.NET “Dataset”, and an intermediate class called SqlDataAdapter, that adapts the sql data in a form that can be used by the Dataset Object.

It is possible to improve this query, using the second form of interaction that make use of a stored procedure

=== Case 2: Parametrized query + Stored Procedure vulnerable ===

By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStoredVuln_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStoredVuln.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

CREATE PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This kind of stored procedure are not rare. In this case is possible to compose the statement in many ways using parameters, function and so on.

Altough it is a parametrized query with a stored procedure, as the code shows, it is possible to inject the same string

'' '; sql statement -- ''

to inject a sql statement. Using the SQL Server function REPLACE, it is possible to “patch” the problem without rewrite the store procedure, replacing all the single quote with a couple of single quote.

ALTER PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @Name = REPLACE(@Name,'''','''''')
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This second case explains the fact that the use of parametrized query with stored procedure not always resolve the security flaws caused by sql injection.

=== Case 3: Parametrized query + Stored Procedure not vulnerable ===

It is possible to modify the way to execute the same query, using parametrized query in conjunction with stored procedures. By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStored_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section is the same of the example above.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);

In this section is used the SqlCommand class as above, but, the type of the SqlCommand is “StoredProcedure” , so the sql code is not provided directly, but there is a procedure inside the database that makes the job. This procedure is called USP_SearchUserByNameNotVuln and accept a Varchar(50) parameter called @Name.
The code of the stored is simply:

CREATE PROCEDURE [dbo].[USP_SearchUserByNameNotVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
SELECT
U.Name,
U.Surname,
U.Code
FROM
dbo.Users U
WHERE
U.Name LIKE '''%' + @Name + '%'''
END

Three steps for each parameter passed to the stored procedure are needed to use the SqlParameter class:

* Instantiate the parameter with the right name and type used in the stored procedure
* Assign the value (in this case the value given by the user in the textbox)
* Add the parameter to the SqlCommand

When the sql command is executed, the parameters will be replaced with values specified by the SqlParameter object.

In conclusion, this kind of query is not prone to sql injection, because it is not possibile to build ad hoc sql statements, due to the correct use of Stored Procedure and the SqlParameter class.

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

This section is the same of the example above.

=== Input validation ===

Another point that is important to consider is the validation of the input. For example in a context in which a user has to insert (or select) some data in (or from) the database let’s think about the worst case, that is a user that can digit anything and submit anything to the server. To avoid this the only choiche is to validate the user's input. Two strategies are possible:

1. White list

2. Black list

The first solution answers at the condition: "deny all, except what is explicitly signed in the list".
The second solution answers at the condition: "allow all, except what is explicitly signed in the list".

The best solution for the security of the application is try to implement a validation of the input based on the first case. This comes more simply with numeric input, range input or strings that follow a specific pattern (for example an e-mail or a date). It becomes more difficult for strings with a not specific pattern (for example strings inserted in a search engine) in which often only a solution based on a black list is reasonably possible.

In a Web Application, there are two kinds of input validation:

1. client validations

2. server validations

There are a couple of reasons to use both types of validation summarized in the following points:

* client validations increase performance (the application doesn't postback to the server) but cause a false sense of security (the validation can be bypassed intercepting and manipulating the client request).
* server validations make worse performance but increase the security, because the validation is made by the server.

In ASP.NET to realize these concepts there are the server web control Validators:

* RequiredFieldValidator
* CompareValidator
* RangeValidator
* RegularExpressionValidator
* CustomValidator

Technically these objects realize both type of validations: that is if the client support Javascript, the Validator uses first the client validation, and after that the page is validated on then server side too. If the client doesn't support Javascript, the validation is made only on the server side. In this manner the application validate the input in a progressive mode and the design of the application doesn't follow a '' "Minimum-Denominator-Multiplier" ''.

To explain the concept in code, it's possible to analyze the CustomValidator, that is the higher generalization because it's possible to use a personalized validation logic.

=== CustomValidator ===

We can think symply to a textbox with a button, like the example above, in which it gives the way to search all the suppliers with a specific code (a string of 16 char) For security reasons it is imagined that a specific user can only see the suppliers that have a code in which the first 4 character are "PFHG".

Any other string that doesn't match this pattern has to be exclude from the search (white list approach)

[[Image:owasp_bsp_net_2.jpg]]

The XML part of the page is like that:

<asp:Label ID="lblQuerySearch" runat="server" Text="Digit the first four numbers"></asp:Label>
<asp:TextBox ID="txtQuerySearch" Width="5em" runat="server"></asp:TextBox>
<asp:RequiredFieldValidator ID="RequiredFieldValidatorQuerySearch" runat="server" ErrorMessage="Required Code"
ControlToValidate="txtQuerySearch"></asp:RequiredFieldValidator>
<asp:CustomValidator ID="CustomValidatorQuerySearch" runat="server" ErrorMessage="Wrong code"
ControlToValidate="txtQuerySearch" OnServerValidate="ValidateCode"></asp:CustomValidator>

The control Label and Button are intuitive web controls.
It's clear to see that two Validator have been applied to the textbox whose ID is '' "txtQuerySearch" ''.
The Validators are:

* RequiredFieldValidator: we don't accept an empty textbox when we submit our request to the server
* CustomValidator: we would implement some custom logic to our textbox

In fact the CustomValidator tag has a particular event called "OnServerValidate" that we can hook to a custom callback function, whose code is executed on the server side.
For this example it's like that:

protected void ValidateCode(object source, ServerValidateEventArgs args)
{
try
{
string textToValidate = args.Value;
if (textToValidate.Equals("PFHG"))
args.IsValid = true;
else
args.IsValid = false;
}
catch (Exception ex)
{
args.IsValid = false;
}
}

The function handles the argument "arg" that brings the text inserted by the user.
If this text match with our pattern, the argument is valid and the server executes the code associated to the button, querying the database in the same manner seen above; however the code is now conditioned by the statement "if(Page.IsValid)".

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
if (Page.IsValid)
{
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByCode", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pCode = new SqlParameter("@Code", SqlDbType.VarChar, 4);
pCode.Value = txtQuerySearch.Text;
cmd.Parameters.Add(pCode);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}
}

This is only an example but the use of the Validators can be very important in all the contexts in which the protection of a database from malicious input is needed.

== .NET Preventing LDAP Injection ==

It’s not important here to explain how LDAP works. The focus is explain how it’s possible to avoid the injection of special character, that are responsible of a unpredictable behaviour of the LDAP server.
LDAP search are often made with a distinguished name (DN) and a filter. So if the user input is not properly validated, the user can manipulate the input to craft a malicious filter, to obtain more informations from the server.
LDAP search are made with string, so the best solution to analyze a string searching particular characters is a Regular Expression.
In this example there is the code associated to a event ButtonClick, and two TextBox called "txtUid" and "txtSn" are used to give input to the system

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
string regExString = "^[a-zA-Z_0-9 @.]+$";
RegexStringValidator regEx = new RegexStringValidator(regExString);
if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}
LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;
try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}
}

''' First Section '''

string regExString = "^[a-zA-Z_0-9 @.]+$";
RegexStringValidator regEx = new RegexStringValidator(regExString);

The first section uses a Regular Expression, using the class “RegExStringValidator”, very useful to analyze a string.
The string can contain only alphanumeric characters, @, blank or dot.
Others characters different from the indicated subset are not allowed, according to the white list approach.

''' Second Section '''

if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}

In this section there is the code to check if the strings inserted in the textbox “txtUid” and “txtSn” match the rule of the RegExp or not. There is a try-catch block and the object method "Validate" is used to make the job. If the validation passes, the catch block is not processed.

''' Third Section '''

LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;

The third section is the place for the connection to the server.

''' Fourth Section '''

try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}

Finally it's made the request and the server make the response, giving the number of entries that found

== Web.config Encryption ==

Web.config (and others file with .config extension) could contain sensitive informations that should be protected. For a .NET Web Application tipically the parameters to acces to a database are stored in plain text, in a form like this:

<configuration>
<connectionStrings>
<add name="Connection_SQLServer2005" connectionString="Data Source=WIN2K3\SQLInstance; Initial Catalog=Exampledb;
User Id=user; Password=clgir3s2s;" providerName=""/>
</connectionStrings>
</configuration>

It's possible to notice:

* Name of the server machine
* Name of the instance of SQL Server
* Name of the database
* Username
* Password

Gaining the access to directory of the web application, these informations are freely accessible.
The solution to mantain the confidentiality is always one: encryption.
Because encryption is not costless, it's not a good choice to encrypt the Web.config in its totality. It's better to select only the sensitive informations, that often are stored in the "configuration" sections of the file.
In .NET there are two mode to encrypt configuration section:

* Coding with some classes of the Framework
* Using the command line tool "aspnet_regiis.exe" (located in %SystemRoot%\Microsoft.NET\Framework\versionNumber folder)

In both cases the encryption is potentially provided in three modes:

* Windows Data Protection API Provider (DPAPI)
* RSA Protected Configuration Provider
* Custom Provider

DPAPI is the simplest manner. It uses a machine (or user) level key storage, so it's possible to share the secret with all the applications of the machine or not. Additionally it uses an encryption mode based on the login of the user, storing the information in the registry, so no key creation needed. But if the application is deployed in a Web farm, the better is RSA protected configuration provider due to the ease with which RSA keys can be exported.
So it's confortable to use the command line tool "aspnet_regiis.exe" with RSA provider.
First thing it's necessary to create a key container, for the public key encryption; open the SDK command prompt of the Framework and digit:

aspnet_regiis.exe -pc keycontainer1

in this manner a file with public and private key is stored at the path
%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys
with a unique code. It's possible to recognize the creation's datetime. It's important to know that this file is protected by the NTFS ACL, so only the creator and the SYSTEM account can manipulate it.
So if the web application run with another account (for example MACHINENAME\ASPNET user), it's necessary to grant the read permission for the key container with the command:

aspnet_regiis -pa keycontainer1 MACHINENAME\ASPNET

On the other hand add these lines in the Web.Config:

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<configProtectedData>
<providers>
<add name="NameProvider1"
type="System.Configuration.RsaProtectedConfigurationProvider, System.Configuration,
Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a,processorArchitecture=MSIL"
UseMachineContainer="true"
KeyContainerName="keycontainer1"
/>
</providers>
</configProtectedData>

in which there are references of the name of the provider (NameProvider1) that is based on RSA and key container (keycontainer1) used by the provider.
Now it's possible to encrypt the "connectionStrings" section using the physical path of the directory storing the web.config (and the the web application):

aspnet_regiis -pef connectionStrings C:\Project\BackendSecProj -prov NameProvider1

The result is that the connectionStrings section is comparable to:

<connectionStrings configProtectionProvider="NameProvider1">
<EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<KeyName>Rsa Key</KeyName>
</KeyInfo>
<CipherData>
<CipherValue>XV8DCEfUymYphQaL5GTqCQGhrNoED+/rIKNXS3l44exGiQWx2FH0Rq.....</CipherValue>
</CipherData>
</EncryptedKey>
</KeyInfo>
</EncryptedData>
</connectionStrings>

The application that must access to this section do automatically the decryption, due the read permission for the key container granted to the running user.
In any case it's always possible to decrypt the section with:

aspnet_regiis -pdf connectionStrings C:\Project\BackendSecProj

= References =

* http://msdn.microsoft.com/en-us/library/default.aspx
* http://msdn.microsoft.com/en-us/library/6759sth4.aspx
* http://directoryprogramming.net/
* http://msdn.microsoft.com/en-us/library/system.configuration.regexstringvalidator.aspx
* http://www.ietf.org/rfc/rfc2254.txt
* http://msdn.microsoft.com/en-us/library/az24scfc(VS.80).aspx
* http://msdn.microsoft.com/en-us/library/k6h9cz8h(VS.80).aspx
* http://msdn.microsoft.com/en-us/library/dtkwfdky(VS.80).aspx
* http://blogs.vertigosoftware.com/snyholm/archive/2005/12/16/1746.aspx

OWASP Backend Security Project SQLServer Hardening

2008-07-30T21:51:04Z

GPederzini: /* Authorization */

= Overview =
In this section there are some best practices concerning the security of SQL Server 2005. The operating system under SQL Server is Windows Server 2003.

= Description =

== Installation of the Engine ==
The prerequisites for the installation are:
* .NET Framework 2.0
* Microsoft SQL Native Client
* Microsoft SQL Server 2005 Setup Support Files.

The installation consist of a large amount of services that are shortly descripted:
* SQL Server Database Services (install SQL Server database engine and tools for managing relational and XML data, replication and full text search)
* Analysis Services (install analysis services and tools used to support online analytical procession OLAP and data mining. Install also Integration Services)
* Notification Services (installs notification services a platform for developing and deploying applications that send personalized, timely notifications to a variety of devices or applications)
* Integration Services (install a set of tools and programmable objects for creating and managing packages that extract, transofrm and load data, as well perform task)
* Client Components (install management tools, development tools and legacy components)
* Documentation, samples and sample databases (installs books online documentation, sample databases and sample applications for all sql 2005 components)
During the installation the thing to remind is that from a security point of view, only what is strictly needed must be installed. To install a tipycal minimal configuration, the SQL Server Database Services and some Client Components (Connectivity components and Management Tools) can be installed.
=== Services ===
In SQL Server every service can run under a particular Windows account. The choices for the service's accounts are:

* Local user that is not a Windows administrator
* Domain user that is not a Windows administrator
* Local Service account
* Network Service account
* Local System account
* Local user that is a Windows administrator
* Domain user that is a Windows administrator

There is not only a solution to configure the service's account, but there are two rules to follow that enforce to behave in certain way:
* minimum privileges
* account isolation
Follow this, probably an administrator account (local or domain) has much more privileges than needed, indipendently of the service.
The Local System account has to many privileges and it's not indicated for a service's account
On the other hand Local Service and Network Service have not much privileges, but they are used for more Windows services, so there is no account isolation.

So the more secure solution for the Sql Server Service's Account is to use Local User or Domain User not Administrators.
For example imagine that are installed the trhee main services:
* Sql Server
* Sql Server Agent
* Sql Server Browser
The task is to create three Windows Local User Account, belonging to User Group, protected with password, and assign them to the services.
In this manner there are exactly two concepts: minimum privileges and account isolation.

=== Authentication Mode ===
Sql Server provides two kinds of authentication: SQL Server Authentication and Windows Authentication. During the installation is possible to enable both (Mixed Mode) or only the Windows Authentication (Windows Mode)

If there is an homogeneous Windows environment, the more secure solution is to enable the Windows mode Authentication, because the administration of the logins is made in the Windows Server and the credentials are not passed through the network, because Windows Authentication uses NTLM or Kerberos Protocols.
If there is an heterogeneous environment, for example no domain controller or there are some legacy applications that have to connect to Sql Server, only the Mixed Mode solution is possible. In this second case the administration of the logins is made inside SQL Server and the credentials are necessarily passed through the network.

Is important to say that in a Windows Mode Authentication, the "sa" user (system administrator) is not enabled. In a mixed mode is enabled.
So in an environment with Mixed Mode Authentication, to avoid the attacks against "sa" user, is better to:
* rename "sa" with another name
* use a strong password for the renamed "sa"

=== Processes ===
Every services that is installed in Sql Server could be administrated through the tool "Sql Server Configuration Manager" that is possible to install, enabling the client component of Sql Server.
With this tool is possible to realize the two best practices for the account's services, assigning to every service a specific account protected with password, that authenticates against Windows.
Every service could be started or stopped in a manual or automatic manner, like other Windows Services.

== Configuration tools provided ==

=== Surface Area Reduction (services and connections) ===
The Surface Area Reduction is a powerful tool provided with Sql Server 2005 to configure:
* Services & Connections

'''Services'''

Every Service installed could be rapidly managed. It's posssible in every moment to:
* Manage the status of the service with the possibilities: Start/Stop & Pause/Resume
* Manage the action of the operating system on startup for that service: Automatic, Manual, Disabled.

The concept is to configure automatic start only for those services that are immediately needed, disabling or manually starting others services that are not necessary.

'''Connections'''

For every instance of SQL Server is possible to allow:
* Only local connection to the server
* Local and remote connections to the server
In a distributed environment probably it's necessary to allow both the connection's type, but it's easy to understand that allowing remote connections expose the server more easily.
So for the remote connections Sql Server could allow two kind of protocols:
* TCP/IP
* Named Piped
For the normal use the better thing is to configure only TCP/IP, because Named Pipes need more open port to work.
Additionally there are others two kinds of connections to the server:
* VIA
* Shared Memory
VIA (Virtual Interface Adapter protocol ) works with VIA hardware. Shared Memory is a protocol that is possible to use only by local connections.
Using the Sql Server Configuration Manager the best solution is enable TCP/IP for remote connections and Shared Memory for the local connections.

=== Surface Area Reduction (features) ===
This is a series of interfaces for enabling or disabling many Database Engine, Analysis Services, and Reporting Services features. The most important are the features of the Database Engine:

* Ad hoc distributed queries
* Common language runtime (CLR) integration
* Dedicated administrator connection (DAC)
* Database Mail
* Native XML Web services
* OLE Automation stored procedures
* Service Broker
* SQL Mail
* Web Assistant stored procedures
* xp_cmdshell

'''Ad hoc distributed queries''' (default is disabled)

This feature enable the OPENROWSET and OPENDATASOURCE calls, to connect to an OLE DB data source. To disable this feature launch:

EXEC sp_configure 'Ad Hoc Distributed Queries',0
GO
RECONFIGURE
GO

It's recommended to disable this feature, because in a case of Sql Injection, an attacker could use OPENROWSET to connect to a database.

'''Common language runtime (CLR) integration''' (default is disabled)

This feature give the possibility to write stored procedures, triggers, user defined functions using a .NET Framework language. So if the server is not used with this aim, or if all the databases object are written with T-SQL, there's no reason to enable this. To disable this feature launch:

EXEC sp_configure 'clr enabled',0
GO
RECONFIGURE
GO

'''Dedicated administrator connection (DAC)''' (default is disabled)

This feature enables the possibility to execute diagnostics queries and troubleshoot problems when there are some problems to connect with standard mode to the server.
The uses are tipically:

* Querying some dynamic management views of SQL Server to obtain informations about the "status health"
* Basic DBCC commands (for example DBCC SHRINKDATABASE to cut the log file)
* Kill the PID of processes

But for example is possible to do other works, like add logins with sysadmin privileges or other administrator's tasks
This is an emergency type of connection, that SQL Server can permit every time, reserving an amount of resources during startup. It permits only a user a time, so if there is an user connected via DAC, no others users can connect. It's possible to use it with SQLCMD or Sql Server Management Studio, through the sintax:

Admin:<namepc>\<nameSqlInstance>

So DAC is only another type of connection, and in every time the credentials must be given to the server, but if it's not necessary, disable it.
To disable this feature launch:

EXEC sp_configure 'remote admin connections',0
GO
RECONFIGURE
GO

'''Database mail''' (default is disabled)

The database mail feature enables the possibility to use the Sql Server Instance to send email. If it's a powerful solution to give some advices to a sysadmin, from a security point of view it's a good practice to use the instance with the only aims that needed.
To disable this feature launch:

EXEC sp_configure 'Database Mail XPs',0
GO
RECONFIGURE
GO

'''Native XML Web services''' (default no SOAP endpoints are created)

This feature basically gives the possibility to use SQL Server as a Web Services provider. It's possible to create HTTP Endpoints in Sql Server, associated for example to a result of stored procedure.
A SOAP client could consume a service simply invoking the correct url provided by Sql Server, without others layers (tipically an IIS web server in wich the web services are hosted).
Enabling this feature and create HTTP endpoints goes in the direction to increase the surface of attack. Every client could produce SOAP request, because SOAP grounds on its working to XML and HTTP, two standards.

To use this feature, first thing is to create an HTTP endpoint for SOAP, and then start or stop the service, with the Surface Area Reduction tool.

'''OLE Automation stored procedures''' (default is disabled)

This feature allows access properties and methods of an ActiveX object within SQL Server. If it's necessary to obtain informations inside a DLL that is not available inside SQL Server, it's possible to use some stored procedure to do the work, enabling this feature, but it's better to access the object with the right language, not with T-SQL.
To disable this feature launch:

EXEC sp_configure 'Ole Automation Procedures',0
GO
RECONFIGURE
GO

'''Service Broker''' (default no Service Broker endpoints is created)

Service Broker is a technology in which two or more entities accomplish a task, sending and receiving messages, in a asynchronous mode. As XML Web Services, to use this feature, a Service Broker endpoint must be created.
A Service Broker endpoint listens on a specific TCP port numberm (tipically 4022, but could be configured during the endpoint's creation).
The authentication against Service Broker could be BASIC, DIGEST, NTLM, KERBEROS, INTEGRATED.

To use this feature, first thing is to create a TCP endpoint for SERVICE_BROKER, and then start or stop the service, with the Surface Area Reduction tool.

'''SQL Mail''' (default is disabled)

SQL Mail is a feature for legacy applications, supported for backward compatibility, to send and receive email using MAPI protocol. This is replaced by Database Mail Feature.
To disable this feature launch:

EXEC sp_configure 'SQL Mail XPs',0
GO
RECONFIGURE
GO

'''Web Assistant stored procedures''' (default is disabled)

This feature enable stored procedures to generate HTML report from the data results. It's deprecated because there are others components (like Reporting Services) to present data in a browser.
To disable this feature launch:

EXEC sp_configure 'Web Assistant Procedures',0
GO
RECONFIGURE
GO

'''xp_cmdshell''' (default is disabled)

This feature enable the extended stored procedure "xp_cmdshell". By definition "executes a command string as an operating-system command shell and returns any output as rows of text".
Enabling xp_cmdshell is potentially very dangerous, because it allows a complete interaction with the operating system, so it's possible to give every command. It's better to do administratives tasks not using SQL Server, so mantain disable xp_cmdshell.
To disable this feature launch:

EXEC sp_configure 'xp_cmdshell',0
GO
RECONFIGURE
GO

=== Sql Server Configuration Manager (endpoints and protocols) ===

=== System Stored Procedure ===

Sql Server provides a lot of system stored procedures, to accomplish administratives tasks.
Surface Configuration Area for features for example is a graphical interface that uses, as it's showed, the stored procedure '''sp_configure''' in conjunction with '''RECONFIGURE''' command to modify the server's configuration.
So even if the server is well configurated avoiding every dangerous stored procedure (such as xp_cmdshell), if the application is vulnerable, a sql injection can cause the execution of the script:

EXEC sp_configure 'xp_cmdshell',1
GO
RECONFIGURE
GO

and automatically the xp_cmdshell would be enabled.
The solutions technically could be:
* Dropping the sp_configure
* Configuring in a right manner the LOGIN inside the Sql Server

The first solution is not good, because dropping system stored procedure could cause anomalies when it's time to patching the server with the last updates/upgrades.
So it's better to think in an "administrative manner"
For example, sp_configure with zero or one parameter could be executed by everyone. But sp_configure with two parameters (necessary to re-enable xp_cmdshell) could be executed by users that have ALTER SETTINGS permission.
In SQL Server there are two roles that, after installation, have ALTER SETTINGS permission:
* sysadmin
* serveradmin
So it's necessary that the LOGIN used to connect to a database for an application doesn't belong to these roles, and at the same time doesn't have the ALTER SETTINGS permission.
In this manner, there will be not possible to re-enable, for example, xp_cmdshell.

To look that, there are some system stored procedure used to view roles and permission for a LOGIN. Imagine for example that a web application connect to a database with a SQL Login called 'userToConnect'.
To see if this user belong to sysadmin or serveradmin roles, it's possible to digit:

SELECT * FROM sys.server_role_members x
INNER JOIN sys.server_principals y
ON x.member_principal_id = y.principal_id
WHERE y.name = 'userToConnect'

If there are one o more results, look at the first column. The possibilities for the "role_principal_id" are:
* 3=sysadmin
* 4=securityadmin
* 5=serveradmin
* 6=setupadmin
* 7=processadmin
* 8=diskadmin
* 9=dbcreator
* 10=bulkadmin

So if the 'userToConnect' doesn't have in the results number 3 or 5, doesn't belong to those roles. However it's not sufficient. Another check must be done. So launch

SELECT x.permission_name FROM sys.server_permissions x
INNER JOIN sys.server_principals y
ON x.grantee_principal_id = y.principal_id
WHERE y.name = 'userToConnect'

If the results don't have the permission ALTER SETTINGS, the "userToConnect" can't modify the server settings. Otherwise revoke the permission with:

REVOKE ALTER SETTINGS TO userToConnect

== Database Administration ==

=== Password Policies ===
When it's time to create a new Login on Sql Server, it's very important to use some evalation criteria. A possible script to do that is:

USE [master]
GO
CREATE LOGIN [userName1] WITH PASSWORD=N'password1'
MUST_CHANGE, DEFAULT_DATABASE=[master], CHECK_EXPIRATION=ON, CHECK_POLICY=ON

The relevant things are:

* MUST_CHANGE --> after the first login, the user must change the planned password (in this case "password1"). Applied to SQL Logins
* CHECK_EXPIRATION=ON --> the password must accomplish the expiration policy. Applied to SQL Logins
* CHECK_POLICY=ON --> the password must accomplish the Windows policy. Applied to SQL Logins

When SQL Server 2005 runs on Windows Server 2003 or higher, it can benefit on Windows password policies. These are configured on Control Panel -> Administrative Tools -> Local Security Policy.
On "Account Policies" there are

* Password Policy
* Account Lockout Policy

On the first option, it's important to set:
* Enforce password history (number of password stored for each account, to avoid repeating every time the same password. The range is [0-24])
* Maximum password age (max number of days in which the password is valid. The range is [1-998]. A 0 value indicates no expiration)
* Minimum password age (min number of days in which the password could not be changed The range is [1-998]. A 0 value indicates that the password could be changed in every moment)
* Minimum password length (minimum number of characters. The range is [1-14]. A 0 value indicates no password needed)
* Password must meet complexity requirements (no two consecutive character of account name, minimum 6 character belonging at least at three of the categories [A-Z], [a-z], [0-9], or characters like !, %, #, $ ecc...)

On the second option, it's important to set:
* Account lockout duration: (indicates the number of minutes in which the account is locked. The range is [1-99999]. A 0 value indicates that the account will be blocked until the administrator unlocks it)
* Account lockout threshold (indicates the max number of failed attempts after that the login is blocked. The range is [1-99999]. A 0 value indicates that the account won't be never blocked)
* Reset account lockout counter after (indicates the number of minutes that must elapse before the number of attempts return to zero. The range is [1-99999].)

If an account is locked (for example due of an attempt to brute force that exceed the "Account lockout threshold" or simply for an error), a new password must be created by the administrator. So a good choice is to ALTER the login with a MUST_CHANGE new password, to force the user to modify it during the first login. The script is like that:

USE [master]
GO
ALTER LOGIN [userName1] WITH PASSWORD=N'12345678' UNLOCK MUST_CHANGE
GO

=== Authorization ===

As it's previously defined, in SQL Server 2005 there are 2 types of authentication: Windows Mode or Mixed Mode. In both case the login only authenticates against the server. Every login could belong to one or more "server roles":

* sysadmin
* dbcreator
* diskadmin
* processadmin
* securityadmin
* bulkadmin
* serveradmin
* setupadmin
* public

The full-rights role is "sysadmin" and for a predefined setting three groups and one sql login have this role (assuming the machine is called WIN2K3 and the sql installation SQL2005INSTANCE):

* Windows group BUILTIN\Administrators
* Windows group WIN2K3\SQLServer2005MSSQLUser$WIN2K3$SQL2005INSTANCE (the group of the Sql Server Engine Service Account)
* Windows group WIN2K3\SQLServer2005SQLAgentUser$WIN2K3$SQL2005INSTANCE (the group of the Sql Server Agent Service Account)
* Sql Login "sa"

So if the services Sql Server Engine and Sql Server Agent run under a specific account (as it's mentioned above), it's possible to DROP the group BUILTIN\Administrators to reduce the administration's surface, but first check if there is a "sysadmin account" of which the password is known ("sa" or better renamed "sa" for example). Otherwise create it. After that drop the BUILTIN\Administrators (rembember that it's a reversible operation).

USE [master]
GO
DROP LOGIN [BUILTIN\Administrators]
GO

The same approach is possible also with the others two groups, but it's necessary to create two more logins with sysadmin right. So it's preferred to mantain the two groups, using them only for the respective service account.

=== Roles and Schemas ===
=== Metadata Views ===
=== Linked Servers ===
=== Execution Context ===

== Encryption ==

=== Symmetric ===
=== Asymmetric ===
=== Asymmetric with certificate ===

= References =

OWASP Backend Security Project SQLServer Hardening

2008-07-30T21:45:41Z

GPederzini: /* Authorization */

= Overview =
In this section there are some best practices concerning the security of SQL Server 2005. The operating system under SQL Server is Windows Server 2003.

= Description =

== Installation of the Engine ==
The prerequisites for the installation are:
* .NET Framework 2.0
* Microsoft SQL Native Client
* Microsoft SQL Server 2005 Setup Support Files.

The installation consist of a large amount of services that are shortly descripted:
* SQL Server Database Services (install SQL Server database engine and tools for managing relational and XML data, replication and full text search)
* Analysis Services (install analysis services and tools used to support online analytical procession OLAP and data mining. Install also Integration Services)
* Notification Services (installs notification services a platform for developing and deploying applications that send personalized, timely notifications to a variety of devices or applications)
* Integration Services (install a set of tools and programmable objects for creating and managing packages that extract, transofrm and load data, as well perform task)
* Client Components (install management tools, development tools and legacy components)
* Documentation, samples and sample databases (installs books online documentation, sample databases and sample applications for all sql 2005 components)
During the installation the thing to remind is that from a security point of view, only what is strictly needed must be installed. To install a tipycal minimal configuration, the SQL Server Database Services and some Client Components (Connectivity components and Management Tools) can be installed.
=== Services ===
In SQL Server every service can run under a particular Windows account. The choices for the service's accounts are:

* Local user that is not a Windows administrator
* Domain user that is not a Windows administrator
* Local Service account
* Network Service account
* Local System account
* Local user that is a Windows administrator
* Domain user that is a Windows administrator

There is not only a solution to configure the service's account, but there are two rules to follow that enforce to behave in certain way:
* minimum privileges
* account isolation
Follow this, probably an administrator account (local or domain) has much more privileges than needed, indipendently of the service.
The Local System account has to many privileges and it's not indicated for a service's account
On the other hand Local Service and Network Service have not much privileges, but they are used for more Windows services, so there is no account isolation.

So the more secure solution for the Sql Server Service's Account is to use Local User or Domain User not Administrators.
For example imagine that are installed the trhee main services:
* Sql Server
* Sql Server Agent
* Sql Server Browser
The task is to create three Windows Local User Account, belonging to User Group, protected with password, and assign them to the services.
In this manner there are exactly two concepts: minimum privileges and account isolation.

=== Authentication Mode ===
Sql Server provides two kinds of authentication: SQL Server Authentication and Windows Authentication. During the installation is possible to enable both (Mixed Mode) or only the Windows Authentication (Windows Mode)

If there is an homogeneous Windows environment, the more secure solution is to enable the Windows mode Authentication, because the administration of the logins is made in the Windows Server and the credentials are not passed through the network, because Windows Authentication uses NTLM or Kerberos Protocols.
If there is an heterogeneous environment, for example no domain controller or there are some legacy applications that have to connect to Sql Server, only the Mixed Mode solution is possible. In this second case the administration of the logins is made inside SQL Server and the credentials are necessarily passed through the network.

Is important to say that in a Windows Mode Authentication, the "sa" user (system administrator) is not enabled. In a mixed mode is enabled.
So in an environment with Mixed Mode Authentication, to avoid the attacks against "sa" user, is better to:
* rename "sa" with another name
* use a strong password for the renamed "sa"

=== Processes ===
Every services that is installed in Sql Server could be administrated through the tool "Sql Server Configuration Manager" that is possible to install, enabling the client component of Sql Server.
With this tool is possible to realize the two best practices for the account's services, assigning to every service a specific account protected with password, that authenticates against Windows.
Every service could be started or stopped in a manual or automatic manner, like other Windows Services.

== Configuration tools provided ==

=== Surface Area Reduction (services and connections) ===
The Surface Area Reduction is a powerful tool provided with Sql Server 2005 to configure:
* Services & Connections

'''Services'''

Every Service installed could be rapidly managed. It's posssible in every moment to:
* Manage the status of the service with the possibilities: Start/Stop & Pause/Resume
* Manage the action of the operating system on startup for that service: Automatic, Manual, Disabled.

The concept is to configure automatic start only for those services that are immediately needed, disabling or manually starting others services that are not necessary.

'''Connections'''

For every instance of SQL Server is possible to allow:
* Only local connection to the server
* Local and remote connections to the server
In a distributed environment probably it's necessary to allow both the connection's type, but it's easy to understand that allowing remote connections expose the server more easily.
So for the remote connections Sql Server could allow two kind of protocols:
* TCP/IP
* Named Piped
For the normal use the better thing is to configure only TCP/IP, because Named Pipes need more open port to work.
Additionally there are others two kinds of connections to the server:
* VIA
* Shared Memory
VIA (Virtual Interface Adapter protocol ) works with VIA hardware. Shared Memory is a protocol that is possible to use only by local connections.
Using the Sql Server Configuration Manager the best solution is enable TCP/IP for remote connections and Shared Memory for the local connections.

=== Surface Area Reduction (features) ===
This is a series of interfaces for enabling or disabling many Database Engine, Analysis Services, and Reporting Services features. The most important are the features of the Database Engine:

* Ad hoc distributed queries
* Common language runtime (CLR) integration
* Dedicated administrator connection (DAC)
* Database Mail
* Native XML Web services
* OLE Automation stored procedures
* Service Broker
* SQL Mail
* Web Assistant stored procedures
* xp_cmdshell

'''Ad hoc distributed queries''' (default is disabled)

This feature enable the OPENROWSET and OPENDATASOURCE calls, to connect to an OLE DB data source. To disable this feature launch:

EXEC sp_configure 'Ad Hoc Distributed Queries',0
GO
RECONFIGURE
GO

It's recommended to disable this feature, because in a case of Sql Injection, an attacker could use OPENROWSET to connect to a database.

'''Common language runtime (CLR) integration''' (default is disabled)

This feature give the possibility to write stored procedures, triggers, user defined functions using a .NET Framework language. So if the server is not used with this aim, or if all the databases object are written with T-SQL, there's no reason to enable this. To disable this feature launch:

EXEC sp_configure 'clr enabled',0
GO
RECONFIGURE
GO

'''Dedicated administrator connection (DAC)''' (default is disabled)

This feature enables the possibility to execute diagnostics queries and troubleshoot problems when there are some problems to connect with standard mode to the server.
The uses are tipically:

* Querying some dynamic management views of SQL Server to obtain informations about the "status health"
* Basic DBCC commands (for example DBCC SHRINKDATABASE to cut the log file)
* Kill the PID of processes

But for example is possible to do other works, like add logins with sysadmin privileges or other administrator's tasks
This is an emergency type of connection, that SQL Server can permit every time, reserving an amount of resources during startup. It permits only a user a time, so if there is an user connected via DAC, no others users can connect. It's possible to use it with SQLCMD or Sql Server Management Studio, through the sintax:

Admin:<namepc>\<nameSqlInstance>

So DAC is only another type of connection, and in every time the credentials must be given to the server, but if it's not necessary, disable it.
To disable this feature launch:

EXEC sp_configure 'remote admin connections',0
GO
RECONFIGURE
GO

'''Database mail''' (default is disabled)

The database mail feature enables the possibility to use the Sql Server Instance to send email. If it's a powerful solution to give some advices to a sysadmin, from a security point of view it's a good practice to use the instance with the only aims that needed.
To disable this feature launch:

EXEC sp_configure 'Database Mail XPs',0
GO
RECONFIGURE
GO

'''Native XML Web services''' (default no SOAP endpoints are created)

This feature basically gives the possibility to use SQL Server as a Web Services provider. It's possible to create HTTP Endpoints in Sql Server, associated for example to a result of stored procedure.
A SOAP client could consume a service simply invoking the correct url provided by Sql Server, without others layers (tipically an IIS web server in wich the web services are hosted).
Enabling this feature and create HTTP endpoints goes in the direction to increase the surface of attack. Every client could produce SOAP request, because SOAP grounds on its working to XML and HTTP, two standards.

To use this feature, first thing is to create an HTTP endpoint for SOAP, and then start or stop the service, with the Surface Area Reduction tool.

'''OLE Automation stored procedures''' (default is disabled)

This feature allows access properties and methods of an ActiveX object within SQL Server. If it's necessary to obtain informations inside a DLL that is not available inside SQL Server, it's possible to use some stored procedure to do the work, enabling this feature, but it's better to access the object with the right language, not with T-SQL.
To disable this feature launch:

EXEC sp_configure 'Ole Automation Procedures',0
GO
RECONFIGURE
GO

'''Service Broker''' (default no Service Broker endpoints is created)

Service Broker is a technology in which two or more entities accomplish a task, sending and receiving messages, in a asynchronous mode. As XML Web Services, to use this feature, a Service Broker endpoint must be created.
A Service Broker endpoint listens on a specific TCP port numberm (tipically 4022, but could be configured during the endpoint's creation).
The authentication against Service Broker could be BASIC, DIGEST, NTLM, KERBEROS, INTEGRATED.

To use this feature, first thing is to create a TCP endpoint for SERVICE_BROKER, and then start or stop the service, with the Surface Area Reduction tool.

'''SQL Mail''' (default is disabled)

SQL Mail is a feature for legacy applications, supported for backward compatibility, to send and receive email using MAPI protocol. This is replaced by Database Mail Feature.
To disable this feature launch:

EXEC sp_configure 'SQL Mail XPs',0
GO
RECONFIGURE
GO

'''Web Assistant stored procedures''' (default is disabled)

This feature enable stored procedures to generate HTML report from the data results. It's deprecated because there are others components (like Reporting Services) to present data in a browser.
To disable this feature launch:

EXEC sp_configure 'Web Assistant Procedures',0
GO
RECONFIGURE
GO

'''xp_cmdshell''' (default is disabled)

This feature enable the extended stored procedure "xp_cmdshell". By definition "executes a command string as an operating-system command shell and returns any output as rows of text".
Enabling xp_cmdshell is potentially very dangerous, because it allows a complete interaction with the operating system, so it's possible to give every command. It's better to do administratives tasks not using SQL Server, so mantain disable xp_cmdshell.
To disable this feature launch:

EXEC sp_configure 'xp_cmdshell',0
GO
RECONFIGURE
GO

=== Sql Server Configuration Manager (endpoints and protocols) ===

=== System Stored Procedure ===

Sql Server provides a lot of system stored procedures, to accomplish administratives tasks.
Surface Configuration Area for features for example is a graphical interface that uses, as it's showed, the stored procedure '''sp_configure''' in conjunction with '''RECONFIGURE''' command to modify the server's configuration.
So even if the server is well configurated avoiding every dangerous stored procedure (such as xp_cmdshell), if the application is vulnerable, a sql injection can cause the execution of the script:

EXEC sp_configure 'xp_cmdshell',1
GO
RECONFIGURE
GO

and automatically the xp_cmdshell would be enabled.
The solutions technically could be:
* Dropping the sp_configure
* Configuring in a right manner the LOGIN inside the Sql Server

The first solution is not good, because dropping system stored procedure could cause anomalies when it's time to patching the server with the last updates/upgrades.
So it's better to think in an "administrative manner"
For example, sp_configure with zero or one parameter could be executed by everyone. But sp_configure with two parameters (necessary to re-enable xp_cmdshell) could be executed by users that have ALTER SETTINGS permission.
In SQL Server there are two roles that, after installation, have ALTER SETTINGS permission:
* sysadmin
* serveradmin
So it's necessary that the LOGIN used to connect to a database for an application doesn't belong to these roles, and at the same time doesn't have the ALTER SETTINGS permission.
In this manner, there will be not possible to re-enable, for example, xp_cmdshell.

To look that, there are some system stored procedure used to view roles and permission for a LOGIN. Imagine for example that a web application connect to a database with a SQL Login called 'userToConnect'.
To see if this user belong to sysadmin or serveradmin roles, it's possible to digit:

SELECT * FROM sys.server_role_members x
INNER JOIN sys.server_principals y
ON x.member_principal_id = y.principal_id
WHERE y.name = 'userToConnect'

If there are one o more results, look at the first column. The possibilities for the "role_principal_id" are:
* 3=sysadmin
* 4=securityadmin
* 5=serveradmin
* 6=setupadmin
* 7=processadmin
* 8=diskadmin
* 9=dbcreator
* 10=bulkadmin

So if the 'userToConnect' doesn't have in the results number 3 or 5, doesn't belong to those roles. However it's not sufficient. Another check must be done. So launch

SELECT x.permission_name FROM sys.server_permissions x
INNER JOIN sys.server_principals y
ON x.grantee_principal_id = y.principal_id
WHERE y.name = 'userToConnect'

If the results don't have the permission ALTER SETTINGS, the "userToConnect" can't modify the server settings. Otherwise revoke the permission with:

REVOKE ALTER SETTINGS TO userToConnect

== Database Administration ==

=== Password Policies ===
When it's time to create a new Login on Sql Server, it's very important to use some evalation criteria. A possible script to do that is:

USE [master]
GO
CREATE LOGIN [userName1] WITH PASSWORD=N'password1'
MUST_CHANGE, DEFAULT_DATABASE=[master], CHECK_EXPIRATION=ON, CHECK_POLICY=ON

The relevant things are:

* MUST_CHANGE --> after the first login, the user must change the planned password (in this case "password1"). Applied to SQL Logins
* CHECK_EXPIRATION=ON --> the password must accomplish the expiration policy. Applied to SQL Logins
* CHECK_POLICY=ON --> the password must accomplish the Windows policy. Applied to SQL Logins

When SQL Server 2005 runs on Windows Server 2003 or higher, it can benefit on Windows password policies. These are configured on Control Panel -> Administrative Tools -> Local Security Policy.
On "Account Policies" there are

* Password Policy
* Account Lockout Policy

On the first option, it's important to set:
* Enforce password history (number of password stored for each account, to avoid repeating every time the same password. The range is [0-24])
* Maximum password age (max number of days in which the password is valid. The range is [1-998]. A 0 value indicates no expiration)
* Minimum password age (min number of days in which the password could not be changed The range is [1-998]. A 0 value indicates that the password could be changed in every moment)
* Minimum password length (minimum number of characters. The range is [1-14]. A 0 value indicates no password needed)
* Password must meet complexity requirements (no two consecutive character of account name, minimum 6 character belonging at least at three of the categories [A-Z], [a-z], [0-9], or characters like !, %, #, $ ecc...)

On the second option, it's important to set:
* Account lockout duration: (indicates the number of minutes in which the account is locked. The range is [1-99999]. A 0 value indicates that the account will be blocked until the administrator unlocks it)
* Account lockout threshold (indicates the max number of failed attempts after that the login is blocked. The range is [1-99999]. A 0 value indicates that the account won't be never blocked)
* Reset account lockout counter after (indicates the number of minutes that must elapse before the number of attempts return to zero. The range is [1-99999].)

If an account is locked (for example due of an attempt to brute force that exceed the "Account lockout threshold" or simply for an error), a new password must be created by the administrator. So a good choice is to ALTER the login with a MUST_CHANGE new password, to force the user to modify it during the first login. The script is like that:

USE [master]
GO
ALTER LOGIN [userName1] WITH PASSWORD=N'12345678' UNLOCK MUST_CHANGE
GO

=== Authorization ===

As it's previously defined, in SQL Server 2005 there are 2 types of authentication: Windows Mode or Mixed Mode. In both case the login only authenticates against the server. Every login could belong to one or more "server roles":

* sysadmin
* dbcreator
* diskadmin
* processadmin
* securityadmin
* bulkadmin
* serveradmin
* setupadmin
* public

The full-rights role is "sysadmin" and for a predefined setting three groups and one sql login have this role (assuming the machine is called WIN2K3 and the sql installation SQL2005INSTANCE):

* Windows group BUILTIN\Administrators
* Windows group WIN2K3\SQLServer2005MSSQLUser$WIN2K3$SQL2005INSTANCE (the group of the Sql Server Engine Service Account)
* Windows group WIN2K3\SQLServer2005SQLAgentUser$WIN2K3$SQL2005INSTANCE (the group of the Sql Server Agent Service Account)
* Sql Login "sa"

So if the services Sql Server Engine and Sql Server Agent run under a specific account (as it's mentioned above), it's possible to DROP the group BUILTIN\Administrators to reduce the administration's surface, but first check if there is a "sysadmin account" of which the password is known ("sa" or better renamed "sa" for example). Otherwise create it. After that drop the BUILTIN\Administrators (rembember that it's a reversible operation).

USE [master]
GO
DROP LOGIN [BUILTIN\Administrators]
GO

=== Roles and Schemas ===
=== Metadata Views ===
=== Linked Servers ===
=== Execution Context ===

== Encryption ==

=== Symmetric ===
=== Asymmetric ===
=== Asymmetric with certificate ===

= References =

OWASP Backend Security Project SQLServer Hardening

2008-07-30T21:44:50Z

GPederzini: /* Authorization */

= Overview =
In this section there are some best practices concerning the security of SQL Server 2005. The operating system under SQL Server is Windows Server 2003.

= Description =

== Installation of the Engine ==
The prerequisites for the installation are:
* .NET Framework 2.0
* Microsoft SQL Native Client
* Microsoft SQL Server 2005 Setup Support Files.

The installation consist of a large amount of services that are shortly descripted:
* SQL Server Database Services (install SQL Server database engine and tools for managing relational and XML data, replication and full text search)
* Analysis Services (install analysis services and tools used to support online analytical procession OLAP and data mining. Install also Integration Services)
* Notification Services (installs notification services a platform for developing and deploying applications that send personalized, timely notifications to a variety of devices or applications)
* Integration Services (install a set of tools and programmable objects for creating and managing packages that extract, transofrm and load data, as well perform task)
* Client Components (install management tools, development tools and legacy components)
* Documentation, samples and sample databases (installs books online documentation, sample databases and sample applications for all sql 2005 components)
During the installation the thing to remind is that from a security point of view, only what is strictly needed must be installed. To install a tipycal minimal configuration, the SQL Server Database Services and some Client Components (Connectivity components and Management Tools) can be installed.
=== Services ===
In SQL Server every service can run under a particular Windows account. The choices for the service's accounts are:

* Local user that is not a Windows administrator
* Domain user that is not a Windows administrator
* Local Service account
* Network Service account
* Local System account
* Local user that is a Windows administrator
* Domain user that is a Windows administrator

There is not only a solution to configure the service's account, but there are two rules to follow that enforce to behave in certain way:
* minimum privileges
* account isolation
Follow this, probably an administrator account (local or domain) has much more privileges than needed, indipendently of the service.
The Local System account has to many privileges and it's not indicated for a service's account
On the other hand Local Service and Network Service have not much privileges, but they are used for more Windows services, so there is no account isolation.

So the more secure solution for the Sql Server Service's Account is to use Local User or Domain User not Administrators.
For example imagine that are installed the trhee main services:
* Sql Server
* Sql Server Agent
* Sql Server Browser
The task is to create three Windows Local User Account, belonging to User Group, protected with password, and assign them to the services.
In this manner there are exactly two concepts: minimum privileges and account isolation.

=== Authentication Mode ===
Sql Server provides two kinds of authentication: SQL Server Authentication and Windows Authentication. During the installation is possible to enable both (Mixed Mode) or only the Windows Authentication (Windows Mode)

If there is an homogeneous Windows environment, the more secure solution is to enable the Windows mode Authentication, because the administration of the logins is made in the Windows Server and the credentials are not passed through the network, because Windows Authentication uses NTLM or Kerberos Protocols.
If there is an heterogeneous environment, for example no domain controller or there are some legacy applications that have to connect to Sql Server, only the Mixed Mode solution is possible. In this second case the administration of the logins is made inside SQL Server and the credentials are necessarily passed through the network.

Is important to say that in a Windows Mode Authentication, the "sa" user (system administrator) is not enabled. In a mixed mode is enabled.
So in an environment with Mixed Mode Authentication, to avoid the attacks against "sa" user, is better to:
* rename "sa" with another name
* use a strong password for the renamed "sa"

=== Processes ===
Every services that is installed in Sql Server could be administrated through the tool "Sql Server Configuration Manager" that is possible to install, enabling the client component of Sql Server.
With this tool is possible to realize the two best practices for the account's services, assigning to every service a specific account protected with password, that authenticates against Windows.
Every service could be started or stopped in a manual or automatic manner, like other Windows Services.

== Configuration tools provided ==

=== Surface Area Reduction (services and connections) ===
The Surface Area Reduction is a powerful tool provided with Sql Server 2005 to configure:
* Services & Connections

'''Services'''

Every Service installed could be rapidly managed. It's posssible in every moment to:
* Manage the status of the service with the possibilities: Start/Stop & Pause/Resume
* Manage the action of the operating system on startup for that service: Automatic, Manual, Disabled.

The concept is to configure automatic start only for those services that are immediately needed, disabling or manually starting others services that are not necessary.

'''Connections'''

For every instance of SQL Server is possible to allow:
* Only local connection to the server
* Local and remote connections to the server
In a distributed environment probably it's necessary to allow both the connection's type, but it's easy to understand that allowing remote connections expose the server more easily.
So for the remote connections Sql Server could allow two kind of protocols:
* TCP/IP
* Named Piped
For the normal use the better thing is to configure only TCP/IP, because Named Pipes need more open port to work.
Additionally there are others two kinds of connections to the server:
* VIA
* Shared Memory
VIA (Virtual Interface Adapter protocol ) works with VIA hardware. Shared Memory is a protocol that is possible to use only by local connections.
Using the Sql Server Configuration Manager the best solution is enable TCP/IP for remote connections and Shared Memory for the local connections.

=== Surface Area Reduction (features) ===
This is a series of interfaces for enabling or disabling many Database Engine, Analysis Services, and Reporting Services features. The most important are the features of the Database Engine:

* Ad hoc distributed queries
* Common language runtime (CLR) integration
* Dedicated administrator connection (DAC)
* Database Mail
* Native XML Web services
* OLE Automation stored procedures
* Service Broker
* SQL Mail
* Web Assistant stored procedures
* xp_cmdshell

'''Ad hoc distributed queries''' (default is disabled)

This feature enable the OPENROWSET and OPENDATASOURCE calls, to connect to an OLE DB data source. To disable this feature launch:

EXEC sp_configure 'Ad Hoc Distributed Queries',0
GO
RECONFIGURE
GO

It's recommended to disable this feature, because in a case of Sql Injection, an attacker could use OPENROWSET to connect to a database.

'''Common language runtime (CLR) integration''' (default is disabled)

This feature give the possibility to write stored procedures, triggers, user defined functions using a .NET Framework language. So if the server is not used with this aim, or if all the databases object are written with T-SQL, there's no reason to enable this. To disable this feature launch:

EXEC sp_configure 'clr enabled',0
GO
RECONFIGURE
GO

'''Dedicated administrator connection (DAC)''' (default is disabled)

This feature enables the possibility to execute diagnostics queries and troubleshoot problems when there are some problems to connect with standard mode to the server.
The uses are tipically:

* Querying some dynamic management views of SQL Server to obtain informations about the "status health"
* Basic DBCC commands (for example DBCC SHRINKDATABASE to cut the log file)
* Kill the PID of processes

But for example is possible to do other works, like add logins with sysadmin privileges or other administrator's tasks
This is an emergency type of connection, that SQL Server can permit every time, reserving an amount of resources during startup. It permits only a user a time, so if there is an user connected via DAC, no others users can connect. It's possible to use it with SQLCMD or Sql Server Management Studio, through the sintax:

Admin:<namepc>\<nameSqlInstance>

So DAC is only another type of connection, and in every time the credentials must be given to the server, but if it's not necessary, disable it.
To disable this feature launch:

EXEC sp_configure 'remote admin connections',0
GO
RECONFIGURE
GO

'''Database mail''' (default is disabled)

The database mail feature enables the possibility to use the Sql Server Instance to send email. If it's a powerful solution to give some advices to a sysadmin, from a security point of view it's a good practice to use the instance with the only aims that needed.
To disable this feature launch:

EXEC sp_configure 'Database Mail XPs',0
GO
RECONFIGURE
GO

'''Native XML Web services''' (default no SOAP endpoints are created)

This feature basically gives the possibility to use SQL Server as a Web Services provider. It's possible to create HTTP Endpoints in Sql Server, associated for example to a result of stored procedure.
A SOAP client could consume a service simply invoking the correct url provided by Sql Server, without others layers (tipically an IIS web server in wich the web services are hosted).
Enabling this feature and create HTTP endpoints goes in the direction to increase the surface of attack. Every client could produce SOAP request, because SOAP grounds on its working to XML and HTTP, two standards.

To use this feature, first thing is to create an HTTP endpoint for SOAP, and then start or stop the service, with the Surface Area Reduction tool.

'''OLE Automation stored procedures''' (default is disabled)

This feature allows access properties and methods of an ActiveX object within SQL Server. If it's necessary to obtain informations inside a DLL that is not available inside SQL Server, it's possible to use some stored procedure to do the work, enabling this feature, but it's better to access the object with the right language, not with T-SQL.
To disable this feature launch:

EXEC sp_configure 'Ole Automation Procedures',0
GO
RECONFIGURE
GO

'''Service Broker''' (default no Service Broker endpoints is created)

Service Broker is a technology in which two or more entities accomplish a task, sending and receiving messages, in a asynchronous mode. As XML Web Services, to use this feature, a Service Broker endpoint must be created.
A Service Broker endpoint listens on a specific TCP port numberm (tipically 4022, but could be configured during the endpoint's creation).
The authentication against Service Broker could be BASIC, DIGEST, NTLM, KERBEROS, INTEGRATED.

To use this feature, first thing is to create a TCP endpoint for SERVICE_BROKER, and then start or stop the service, with the Surface Area Reduction tool.

'''SQL Mail''' (default is disabled)

SQL Mail is a feature for legacy applications, supported for backward compatibility, to send and receive email using MAPI protocol. This is replaced by Database Mail Feature.
To disable this feature launch:

EXEC sp_configure 'SQL Mail XPs',0
GO
RECONFIGURE
GO

'''Web Assistant stored procedures''' (default is disabled)

This feature enable stored procedures to generate HTML report from the data results. It's deprecated because there are others components (like Reporting Services) to present data in a browser.
To disable this feature launch:

EXEC sp_configure 'Web Assistant Procedures',0
GO
RECONFIGURE
GO

'''xp_cmdshell''' (default is disabled)

This feature enable the extended stored procedure "xp_cmdshell". By definition "executes a command string as an operating-system command shell and returns any output as rows of text".
Enabling xp_cmdshell is potentially very dangerous, because it allows a complete interaction with the operating system, so it's possible to give every command. It's better to do administratives tasks not using SQL Server, so mantain disable xp_cmdshell.
To disable this feature launch:

EXEC sp_configure 'xp_cmdshell',0
GO
RECONFIGURE
GO

=== Sql Server Configuration Manager (endpoints and protocols) ===

=== System Stored Procedure ===

Sql Server provides a lot of system stored procedures, to accomplish administratives tasks.
Surface Configuration Area for features for example is a graphical interface that uses, as it's showed, the stored procedure '''sp_configure''' in conjunction with '''RECONFIGURE''' command to modify the server's configuration.
So even if the server is well configurated avoiding every dangerous stored procedure (such as xp_cmdshell), if the application is vulnerable, a sql injection can cause the execution of the script:

EXEC sp_configure 'xp_cmdshell',1
GO
RECONFIGURE
GO

and automatically the xp_cmdshell would be enabled.
The solutions technically could be:
* Dropping the sp_configure
* Configuring in a right manner the LOGIN inside the Sql Server

The first solution is not good, because dropping system stored procedure could cause anomalies when it's time to patching the server with the last updates/upgrades.
So it's better to think in an "administrative manner"
For example, sp_configure with zero or one parameter could be executed by everyone. But sp_configure with two parameters (necessary to re-enable xp_cmdshell) could be executed by users that have ALTER SETTINGS permission.
In SQL Server there are two roles that, after installation, have ALTER SETTINGS permission:
* sysadmin
* serveradmin
So it's necessary that the LOGIN used to connect to a database for an application doesn't belong to these roles, and at the same time doesn't have the ALTER SETTINGS permission.
In this manner, there will be not possible to re-enable, for example, xp_cmdshell.

To look that, there are some system stored procedure used to view roles and permission for a LOGIN. Imagine for example that a web application connect to a database with a SQL Login called 'userToConnect'.
To see if this user belong to sysadmin or serveradmin roles, it's possible to digit:

SELECT * FROM sys.server_role_members x
INNER JOIN sys.server_principals y
ON x.member_principal_id = y.principal_id
WHERE y.name = 'userToConnect'

If there are one o more results, look at the first column. The possibilities for the "role_principal_id" are:
* 3=sysadmin
* 4=securityadmin
* 5=serveradmin
* 6=setupadmin
* 7=processadmin
* 8=diskadmin
* 9=dbcreator
* 10=bulkadmin

So if the 'userToConnect' doesn't have in the results number 3 or 5, doesn't belong to those roles. However it's not sufficient. Another check must be done. So launch

SELECT x.permission_name FROM sys.server_permissions x
INNER JOIN sys.server_principals y
ON x.grantee_principal_id = y.principal_id
WHERE y.name = 'userToConnect'

If the results don't have the permission ALTER SETTINGS, the "userToConnect" can't modify the server settings. Otherwise revoke the permission with:

REVOKE ALTER SETTINGS TO userToConnect

== Database Administration ==

=== Password Policies ===
When it's time to create a new Login on Sql Server, it's very important to use some evalation criteria. A possible script to do that is:

USE [master]
GO
CREATE LOGIN [userName1] WITH PASSWORD=N'password1'
MUST_CHANGE, DEFAULT_DATABASE=[master], CHECK_EXPIRATION=ON, CHECK_POLICY=ON

The relevant things are:

* MUST_CHANGE --> after the first login, the user must change the planned password (in this case "password1"). Applied to SQL Logins
* CHECK_EXPIRATION=ON --> the password must accomplish the expiration policy. Applied to SQL Logins
* CHECK_POLICY=ON --> the password must accomplish the Windows policy. Applied to SQL Logins

When SQL Server 2005 runs on Windows Server 2003 or higher, it can benefit on Windows password policies. These are configured on Control Panel -> Administrative Tools -> Local Security Policy.
On "Account Policies" there are

* Password Policy
* Account Lockout Policy

On the first option, it's important to set:
* Enforce password history (number of password stored for each account, to avoid repeating every time the same password. The range is [0-24])
* Maximum password age (max number of days in which the password is valid. The range is [1-998]. A 0 value indicates no expiration)
* Minimum password age (min number of days in which the password could not be changed The range is [1-998]. A 0 value indicates that the password could be changed in every moment)
* Minimum password length (minimum number of characters. The range is [1-14]. A 0 value indicates no password needed)
* Password must meet complexity requirements (no two consecutive character of account name, minimum 6 character belonging at least at three of the categories [A-Z], [a-z], [0-9], or characters like !, %, #, $ ecc...)

On the second option, it's important to set:
* Account lockout duration: (indicates the number of minutes in which the account is locked. The range is [1-99999]. A 0 value indicates that the account will be blocked until the administrator unlocks it)
* Account lockout threshold (indicates the max number of failed attempts after that the login is blocked. The range is [1-99999]. A 0 value indicates that the account won't be never blocked)
* Reset account lockout counter after (indicates the number of minutes that must elapse before the number of attempts return to zero. The range is [1-99999].)

If an account is locked (for example due of an attempt to brute force that exceed the "Account lockout threshold" or simply for an error), a new password must be created by the administrator. So a good choice is to ALTER the login with a MUST_CHANGE new password, to force the user to modify it during the first login. The script is like that:

USE [master]
GO
ALTER LOGIN [userName1] WITH PASSWORD=N'12345678' UNLOCK MUST_CHANGE
GO

=== Authorization ===

As it's previously defined, in SQL Server 2005 there are 2 types of authentication: Windows Authentication or Mixed Mode. In both case the login only authenticates against the server. Every login could belong to one or more "server roles":

* sysadmin
* dbcreator
* diskadmin
* processadmin
* securityadmin
* bulkadmin
* serveradmin
* setupadmin
* public

The full-rights role is "sysadmin" and for a predefined setting three groups and one sql login have this role (assuming the machine is called WIN2K3 and the sql installation SQL2005INSTANCE):

* Windows group BUILTIN\Administrators
* Windows group WIN2K3\SQLServer2005MSSQLUser$WIN2K3$SQL2005INSTANCE (the group of the Sql Server Engine Service Account)
* Windows group WIN2K3\SQLServer2005SQLAgentUser$WIN2K3$SQL2005INSTANCE (the group of the Sql Server Agent Service Account)
* Sql Login "sa"

So if the services Sql Server Engine and Sql Server Agent run under a specific account (as it's mentioned above), it's possible to DROP the group BUILTIN\Administrators to reduce the administration's surface, but first check if there is a "sysadmin account" of which the password is known ("sa" or better renamed "sa" for example). Otherwise create it. After that drop the BUILTIN\Administrators (rembember that it's a reversible operation).

USE [master]
GO
DROP LOGIN [BUILTIN\Administrators]
GO

=== Roles and Schemas ===
=== Metadata Views ===
=== Linked Servers ===
=== Execution Context ===

== Encryption ==

=== Symmetric ===
=== Asymmetric ===
=== Asymmetric with certificate ===

= References =

OWASP Backend Security Project SQLServer Hardening

2008-07-25T07:44:50Z

GPederzini: /* Password Policies */

= Overview =
In this section there are some best practices concerning the security of SQL Server 2005. The operating system under SQL Server is Windows Server 2003.

= Description =

== Installation of the Engine ==
The prerequisites for the installation are:
* .NET Framework 2.0
* Microsoft SQL Native Client
* Microsoft SQL Server 2005 Setup Support Files.

The installation consist of a large amount of services that are shortly descripted:
* SQL Server Database Services (install SQL Server database engine and tools for managing relational and XML data, replication and full text search)
* Analysis Services (install analysis services and tools used to support online analytical procession OLAP and data mining. Install also Integration Services)
* Notification Services (installs notification services a platform for developing and deploying applications that send personalized, timely notifications to a variety of devices or applications)
* Integration Services (install a set of tools and programmable objects for creating and managing packages that extract, transofrm and load data, as well perform task)
* Client Components (install management tools, development tools and legacy components)
* Documentation, samples and sample databases (installs books online documentation, sample databases and sample applications for all sql 2005 components)
During the installation the thing to remind is that from a security point of view, only what is strictly needed must be installed. To install a tipycal minimal configuration, the SQL Server Database Services and some Client Components (Connectivity components and Management Tools) can be installed.
=== Services ===
In SQL Server every service can run under a particular Windows account. The choices for the service's accounts are:

* Local user that is not a Windows administrator
* Domain user that is not a Windows administrator
* Local Service account
* Network Service account
* Local System account
* Local user that is a Windows administrator
* Domain user that is a Windows administrator

There is not only a solution to configure the service's account, but there are two rules to follow that enforce to behave in certain way:
* minimum privileges
* account isolation
Follow this, probably an administrator account (local or domain) has much more privileges than needed, indipendently of the service.
The Local System account has to many privileges and it's not indicated for a service's account
On the other hand Local Service and Network Service have not much privileges, but they are used for more Windows services, so there is no account isolation.

So the more secure solution for the Sql Server Service's Account is to use Local User or Domain User not Administrators.
For example imagine that are installed the trhee main services:
* Sql Server
* Sql Server Agent
* Sql Server Browser
The task is to create three Windows Local User Account, belonging to User Group, protected with password, and assign them to the services.
In this manner there are exactly two concepts: minimum privileges and account isolation.

=== Authentication Mode ===
Sql Server provides two kinds of authentication: SQL Server Authentication and Windows Authentication. During the installation is possible to enable both (Mixed Mode) or only the Windows Authentication (Windows Mode)

If there is an homogeneous Windows environment, the more secure solution is to enable the Windows mode Authentication, because the administration of the logins is made in the Windows Server and the credentials are not passed through the network, because Windows Authentication uses NTLM or Kerberos Protocols.
If there is an heterogeneous environment, for example no domain controller or there are some legacy applications that have to connect to Sql Server, only the Mixed Mode solution is possible. In this second case the administration of the logins is made inside SQL Server and the credentials are necessarily passed through the network.

Is important to say that in a Windows Mode Authentication, the "sa" user (system administrator) is not enabled. In a mixed mode is enabled.
So in an environment with Mixed Mode Authentication, to avoid the attacks against "sa" user, is better to:
* rename "sa" with another name
* use a strong password for the renamed "sa"

=== Processes ===
Every services that is installed in Sql Server could be administrated through the tool "Sql Server Configuration Manager" that is possible to install, enabling the client component of Sql Server.
With this tool is possible to realize the two best practices for the account's services, assigning to every service a specific account protected with password, that authenticates against Windows.
Every service could be started or stopped in a manual or automatic manner, like other Windows Services.

== Configuration tools provided ==

=== Surface Area Reduction (services and connections) ===
The Surface Area Reduction is a powerful tool provided with Sql Server 2005 to configure:
* Services & Connections

'''Services'''

Every Service installed could be rapidly managed. It's posssible in every moment to:
* Manage the status of the service with the possibilities: Start/Stop & Pause/Resume
* Manage the action of the operating system on startup for that service: Automatic, Manual, Disabled.

The concept is to configure automatic start only for those services that are immediately needed, disabling or manually starting others services that are not necessary.

'''Connections'''

For every instance of SQL Server is possible to allow:
* Only local connection to the server
* Local and remote connections to the server
In a distributed environment probably it's necessary to allow both the connection's type, but it's easy to understand that allowing remote connections expose the server more easily.
So for the remote connections Sql Server could allow two kind of protocols:
* TCP/IP
* Named Piped
For the normal use the better thing is to configure only TCP/IP, because Named Pipes need more open port to work.
Additionally there are others two kinds of connections to the server:
* VIA
* Shared Memory
VIA (Virtual Interface Adapter protocol ) works with VIA hardware. Shared Memory is a protocol that is possible to use only by local connections.
Using the Sql Server Configuration Manager the best solution is enable TCP/IP for remote connections and Shared Memory for the local connections.

=== Surface Area Reduction (features) ===
This is a series of interfaces for enabling or disabling many Database Engine, Analysis Services, and Reporting Services features. The most important are the features of the Database Engine:

* Ad hoc distributed queries
* Common language runtime (CLR) integration
* Dedicated administrator connection (DAC)
* Database Mail
* Native XML Web services
* OLE Automation stored procedures
* Service Broker
* SQL Mail
* Web Assistant stored procedures
* xp_cmdshell

'''Ad hoc distributed queries''' (default is disabled)

This feature enable the OPENROWSET and OPENDATASOURCE calls, to connect to an OLE DB data source. To disable this feature launch:

EXEC sp_configure 'Ad Hoc Distributed Queries',0
GO
RECONFIGURE
GO

It's recommended to disable this feature, because in a case of Sql Injection, an attacker could use OPENROWSET to connect to a database.

'''Common language runtime (CLR) integration''' (default is disabled)

This feature give the possibility to write stored procedures, triggers, user defined functions using a .NET Framework language. So if the server is not used with this aim, or if all the databases object are written with T-SQL, there's no reason to enable this. To disable this feature launch:

EXEC sp_configure 'clr enabled',0
GO
RECONFIGURE
GO

'''Dedicated administrator connection (DAC)''' (default is disabled)

This feature enables the possibility to execute diagnostics queries and troubleshoot problems when there are some problems to connect with standard mode to the server.
The uses are tipically:

* Querying some dynamic management views of SQL Server to obtain informations about the "status health"
* Basic DBCC commands (for example DBCC SHRINKDATABASE to cut the log file)
* Kill the PID of processes

But for example is possible to do other works, like add logins with sysadmin privileges or other administrator's tasks
This is an emergency type of connection, that SQL Server can permit every time, reserving an amount of resources during startup. It permits only a user a time, so if there is an user connected via DAC, no others users can connect. It's possible to use it with SQLCMD or Sql Server Management Studio, through the sintax:

Admin:<namepc>\<nameSqlInstance>

So DAC is only another type of connection, and in every time the credentials must be given to the server, but if it's not necessary, disable it.
To disable this feature launch:

EXEC sp_configure 'remote admin connections',0
GO
RECONFIGURE
GO

'''Database mail''' (default is disabled)

The database mail feature enables the possibility to use the Sql Server Instance to send email. If it's a powerful solution to give some advices to a sysadmin, from a security point of view it's a good practice to use the instance with the only aims that needed.
To disable this feature launch:

EXEC sp_configure 'Database Mail XPs',0
GO
RECONFIGURE
GO

'''Native XML Web services''' (default no SOAP endpoints are created)

This feature basically gives the possibility to use SQL Server as a Web Services provider. It's possible to create HTTP Endpoints in Sql Server, associated for example to a result of stored procedure.
A SOAP client could consume a service simply invoking the correct url provided by Sql Server, without others layers (tipically an IIS web server in wich the web services are hosted).
Enabling this feature and create HTTP endpoints goes in the direction to increase the surface of attack. Every client could produce SOAP request, because SOAP grounds on its working to XML and HTTP, two standards.

To use this feature, first thing is to create an HTTP endpoint for SOAP, and then start or stop the service, with the Surface Area Reduction tool.

'''OLE Automation stored procedures''' (default is disabled)

This feature allows access properties and methods of an ActiveX object within SQL Server. If it's necessary to obtain informations inside a DLL that is not available inside SQL Server, it's possible to use some stored procedure to do the work, enabling this feature, but it's better to access the object with the right language, not with T-SQL.
To disable this feature launch:

EXEC sp_configure 'Ole Automation Procedures',0
GO
RECONFIGURE
GO

'''Service Broker''' (default no Service Broker endpoints is created)

Service Broker is a technology in which two or more entities accomplish a task, sending and receiving messages, in a asynchronous mode. As XML Web Services, to use this feature, a Service Broker endpoint must be created.
A Service Broker endpoint listens on a specific TCP port numberm (tipically 4022, but could be configured during the endpoint's creation).
The authentication against Service Broker could be BASIC, DIGEST, NTLM, KERBEROS, INTEGRATED.

To use this feature, first thing is to create a TCP endpoint for SERVICE_BROKER, and then start or stop the service, with the Surface Area Reduction tool.

'''SQL Mail''' (default is disabled)

SQL Mail is a feature for legacy applications, supported for backward compatibility, to send and receive email using MAPI protocol. This is replaced by Database Mail Feature.
To disable this feature launch:

EXEC sp_configure 'SQL Mail XPs',0
GO
RECONFIGURE
GO

'''Web Assistant stored procedures''' (default is disabled)

This feature enable stored procedures to generate HTML report from the data results. It's deprecated because there are others components (like Reporting Services) to present data in a browser.
To disable this feature launch:

EXEC sp_configure 'Web Assistant Procedures',0
GO
RECONFIGURE
GO

'''xp_cmdshell''' (default is disabled)

This feature enable the extended stored procedure "xp_cmdshell". By definition "executes a command string as an operating-system command shell and returns any output as rows of text".
Enabling xp_cmdshell is potentially very dangerous, because it allows a complete interaction with the operating system, so it's possible to give every command. It's better to do administratives tasks not using SQL Server, so mantain disable xp_cmdshell.
To disable this feature launch:

EXEC sp_configure 'xp_cmdshell',0
GO
RECONFIGURE
GO

=== Sql Server Configuration Manager (endpoints and protocols) ===

=== System Stored Procedure ===

Sql Server provides a lot of system stored procedures, to accomplish administratives tasks.
Surface Configuration Area for features for example is a graphical interface that uses, as it's showed, the stored procedure '''sp_configure''' in conjunction with '''RECONFIGURE''' command to modify the server's configuration.
So even if the server is well configurated avoiding every dangerous stored procedure (such as xp_cmdshell), if the application is vulnerable, a sql injection can cause the execution of the script:

EXEC sp_configure 'xp_cmdshell',1
GO
RECONFIGURE
GO

and automatically the xp_cmdshell would be enabled.
The solutions technically could be:
* Dropping the sp_configure
* Configuring in a right manner the LOGIN inside the Sql Server

The first solution is not good, because dropping system stored procedure could cause anomalies when it's time to patching the server with the last updates/upgrades.
So it's better to think in an "administrative manner"
For example, sp_configure with zero or one parameter could be executed by everyone. But sp_configure with two parameters (necessary to re-enable xp_cmdshell) could be executed by users that have ALTER SETTINGS permission.
In SQL Server there are two roles that, after installation, have ALTER SETTINGS permission:
* sysadmin
* serveradmin
So it's necessary that the LOGIN used to connect to a database for an application doesn't belong to these roles, and at the same time doesn't have the ALTER SETTINGS permission.
In this manner, there will be not possible to re-enable, for example, xp_cmdshell.

To look that, there are some system stored procedure used to view roles and permission for a LOGIN. Imagine for example that a web application connect to a database with a SQL Login called 'userToConnect'.
To see if this user belong to sysadmin or serveradmin roles, it's possible to digit:

SELECT * FROM sys.server_role_members x
INNER JOIN sys.server_principals y
ON x.member_principal_id = y.principal_id
WHERE y.name = 'userToConnect'

If there are one o more results, look at the first column. The possibilities for the "role_principal_id" are:
* 3=sysadmin
* 4=securityadmin
* 5=serveradmin
* 6=setupadmin
* 7=processadmin
* 8=diskadmin
* 9=dbcreator
* 10=bulkadmin

So if the 'userToConnect' doesn't have in the results number 3 or 5, doesn't belong to those roles. However it's not sufficient. Another check must be done. So launch

SELECT x.permission_name FROM sys.server_permissions x
INNER JOIN sys.server_principals y
ON x.grantee_principal_id = y.principal_id
WHERE y.name = 'userToConnect'

If the results don't have the permission ALTER SETTINGS, the "userToConnect" can't modify the server settings. Otherwise revoke the permission with:

REVOKE ALTER SETTINGS TO userToConnect

== Database Administration ==

=== Password Policies ===
When it's time to create a new Login on Sql Server, it's very important to use some evalation criteria. A possible script to do that is:

USE [master]
GO
CREATE LOGIN [userName1] WITH PASSWORD=N'password1'
MUST_CHANGE, DEFAULT_DATABASE=[master], CHECK_EXPIRATION=ON, CHECK_POLICY=ON

The relevant things are:

* MUST_CHANGE --> after the first login, the user must change the planned password (in this case "password1"). Applied to SQL Logins
* CHECK_EXPIRATION=ON --> the password must accomplish the expiration policy. Applied to SQL Logins
* CHECK_POLICY=ON --> the password must accomplish the Windows policy. Applied to SQL Logins

When SQL Server 2005 runs on Windows Server 2003 or higher, it can benefit on Windows password policies. These are configured on Control Panel -> Administrative Tools -> Local Security Policy.
On "Account Policies" there are

* Password Policy
* Account Lockout Policy

On the first option, it's important to set:
* Enforce password history (number of password stored for each account, to avoid repeating every time the same password. The range is [0-24])
* Maximum password age (max number of days in which the password is valid. The range is [1-998]. A 0 value indicates no expiration)
* Minimum password age (min number of days in which the password could not be changed The range is [1-998]. A 0 value indicates that the password could be changed in every moment)
* Minimum password length (minimum number of characters. The range is [1-14]. A 0 value indicates no password needed)
* Password must meet complexity requirements (no two consecutive character of account name, minimum 6 character belonging at least at three of the categories [A-Z], [a-z], [0-9], or characters like !, %, #, $ ecc...)

On the second option, it's important to set:
* Account lockout duration: (indicates the number of minutes in which the account is locked. The range is [1-99999]. A 0 value indicates that the account will be blocked until the administrator unlocks it)
* Account lockout threshold (indicates the max number of failed attempts after that the login is blocked. The range is [1-99999]. A 0 value indicates that the account won't be never blocked)
* Reset account lockout counter after (indicates the number of minutes that must elapse before the number of attempts return to zero. The range is [1-99999].)

If an account is locked (for example due of an attempt to brute force that exceed the "Account lockout threshold" or simply for an error), a new password must be created by the administrator. So a good choice is to ALTER the login with a MUST_CHANGE new password, to force the user to modify it during the first login. The script is like that:

USE [master]
GO
ALTER LOGIN [userName1] WITH PASSWORD=N'12345678' UNLOCK MUST_CHANGE
GO

=== Authorization ===
=== Roles and Schemas ===
=== Metadata Views ===
=== Linked Servers ===
=== Execution Context ===

== Encryption ==

=== Symmetric ===
=== Asymmetric ===
=== Asymmetric with certificate ===

= References =

OWASP Backend Security Project SQLServer Hardening

2008-07-24T22:58:48Z

GPederzini: /* Password Policies */

= Overview =
In this section there are some best practices concerning the security of SQL Server 2005. The operating system under SQL Server is Windows Server 2003.

= Description =

== Installation of the Engine ==
The prerequisites for the installation are:
* .NET Framework 2.0
* Microsoft SQL Native Client
* Microsoft SQL Server 2005 Setup Support Files.

The installation consist of a large amount of services that are shortly descripted:
* SQL Server Database Services (install SQL Server database engine and tools for managing relational and XML data, replication and full text search)
* Analysis Services (install analysis services and tools used to support online analytical procession OLAP and data mining. Install also Integration Services)
* Notification Services (installs notification services a platform for developing and deploying applications that send personalized, timely notifications to a variety of devices or applications)
* Integration Services (install a set of tools and programmable objects for creating and managing packages that extract, transofrm and load data, as well perform task)
* Client Components (install management tools, development tools and legacy components)
* Documentation, samples and sample databases (installs books online documentation, sample databases and sample applications for all sql 2005 components)
During the installation the thing to remind is that from a security point of view, only what is strictly needed must be installed. To install a tipycal minimal configuration, the SQL Server Database Services and some Client Components (Connectivity components and Management Tools) can be installed.
=== Services ===
In SQL Server every service can run under a particular Windows account. The choices for the service's accounts are:

* Local user that is not a Windows administrator
* Domain user that is not a Windows administrator
* Local Service account
* Network Service account
* Local System account
* Local user that is a Windows administrator
* Domain user that is a Windows administrator

There is not only a solution to configure the service's account, but there are two rules to follow that enforce to behave in certain way:
* minimum privileges
* account isolation
Follow this, probably an administrator account (local or domain) has much more privileges than needed, indipendently of the service.
The Local System account has to many privileges and it's not indicated for a service's account
On the other hand Local Service and Network Service have not much privileges, but they are used for more Windows services, so there is no account isolation.

So the more secure solution for the Sql Server Service's Account is to use Local User or Domain User not Administrators.
For example imagine that are installed the trhee main services:
* Sql Server
* Sql Server Agent
* Sql Server Browser
The task is to create three Windows Local User Account, belonging to User Group, protected with password, and assign them to the services.
In this manner there are exactly two concepts: minimum privileges and account isolation.

=== Authentication Mode ===
Sql Server provides two kinds of authentication: SQL Server Authentication and Windows Authentication. During the installation is possible to enable both (Mixed Mode) or only the Windows Authentication (Windows Mode)

If there is an homogeneous Windows environment, the more secure solution is to enable the Windows mode Authentication, because the administration of the logins is made in the Windows Server and the credentials are not passed through the network, because Windows Authentication uses NTLM or Kerberos Protocols.
If there is an heterogeneous environment, for example no domain controller or there are some legacy applications that have to connect to Sql Server, only the Mixed Mode solution is possible. In this second case the administration of the logins is made inside SQL Server and the credentials are necessarily passed through the network.

Is important to say that in a Windows Mode Authentication, the "sa" user (system administrator) is not enabled. In a mixed mode is enabled.
So in an environment with Mixed Mode Authentication, to avoid the attacks against "sa" user, is better to:
* rename "sa" with another name
* use a strong password for the renamed "sa"

=== Processes ===
Every services that is installed in Sql Server could be administrated through the tool "Sql Server Configuration Manager" that is possible to install, enabling the client component of Sql Server.
With this tool is possible to realize the two best practices for the account's services, assigning to every service a specific account protected with password, that authenticates against Windows.
Every service could be started or stopped in a manual or automatic manner, like other Windows Services.

== Configuration tools provided ==

=== Surface Area Reduction (services and connections) ===
The Surface Area Reduction is a powerful tool provided with Sql Server 2005 to configure:
* Services & Connections

'''Services'''

Every Service installed could be rapidly managed. It's posssible in every moment to:
* Manage the status of the service with the possibilities: Start/Stop & Pause/Resume
* Manage the action of the operating system on startup for that service: Automatic, Manual, Disabled.

The concept is to configure automatic start only for those services that are immediately needed, disabling or manually starting others services that are not necessary.

'''Connections'''

For every instance of SQL Server is possible to allow:
* Only local connection to the server
* Local and remote connections to the server
In a distributed environment probably it's necessary to allow both the connection's type, but it's easy to understand that allowing remote connections expose the server more easily.
So for the remote connections Sql Server could allow two kind of protocols:
* TCP/IP
* Named Piped
For the normal use the better thing is to configure only TCP/IP, because Named Pipes need more open port to work.
Additionally there are others two kinds of connections to the server:
* VIA
* Shared Memory
VIA (Virtual Interface Adapter protocol ) works with VIA hardware. Shared Memory is a protocol that is possible to use only by local connections.
Using the Sql Server Configuration Manager the best solution is enable TCP/IP for remote connections and Shared Memory for the local connections.

=== Surface Area Reduction (features) ===
This is a series of interfaces for enabling or disabling many Database Engine, Analysis Services, and Reporting Services features. The most important are the features of the Database Engine:

* Ad hoc distributed queries
* Common language runtime (CLR) integration
* Dedicated administrator connection (DAC)
* Database Mail
* Native XML Web services
* OLE Automation stored procedures
* Service Broker
* SQL Mail
* Web Assistant stored procedures
* xp_cmdshell

'''Ad hoc distributed queries''' (default is disabled)

This feature enable the OPENROWSET and OPENDATASOURCE calls, to connect to an OLE DB data source. To disable this feature launch:

EXEC sp_configure 'Ad Hoc Distributed Queries',0
GO
RECONFIGURE
GO

It's recommended to disable this feature, because in a case of Sql Injection, an attacker could use OPENROWSET to connect to a database.

'''Common language runtime (CLR) integration''' (default is disabled)

This feature give the possibility to write stored procedures, triggers, user defined functions using a .NET Framework language. So if the server is not used with this aim, or if all the databases object are written with T-SQL, there's no reason to enable this. To disable this feature launch:

EXEC sp_configure 'clr enabled',0
GO
RECONFIGURE
GO

'''Dedicated administrator connection (DAC)''' (default is disabled)

This feature enables the possibility to execute diagnostics queries and troubleshoot problems when there are some problems to connect with standard mode to the server.
The uses are tipically:

* Querying some dynamic management views of SQL Server to obtain informations about the "status health"
* Basic DBCC commands (for example DBCC SHRINKDATABASE to cut the log file)
* Kill the PID of processes

But for example is possible to do other works, like add logins with sysadmin privileges or other administrator's tasks
This is an emergency type of connection, that SQL Server can permit every time, reserving an amount of resources during startup. It permits only a user a time, so if there is an user connected via DAC, no others users can connect. It's possible to use it with SQLCMD or Sql Server Management Studio, through the sintax:

Admin:<namepc>\<nameSqlInstance>

So DAC is only another type of connection, and in every time the credentials must be given to the server, but if it's not necessary, disable it.
To disable this feature launch:

EXEC sp_configure 'remote admin connections',0
GO
RECONFIGURE
GO

'''Database mail''' (default is disabled)

The database mail feature enables the possibility to use the Sql Server Instance to send email. If it's a powerful solution to give some advices to a sysadmin, from a security point of view it's a good practice to use the instance with the only aims that needed.
To disable this feature launch:

EXEC sp_configure 'Database Mail XPs',0
GO
RECONFIGURE
GO

'''Native XML Web services''' (default no SOAP endpoints are created)

This feature basically gives the possibility to use SQL Server as a Web Services provider. It's possible to create HTTP Endpoints in Sql Server, associated for example to a result of stored procedure.
A SOAP client could consume a service simply invoking the correct url provided by Sql Server, without others layers (tipically an IIS web server in wich the web services are hosted).
Enabling this feature and create HTTP endpoints goes in the direction to increase the surface of attack. Every client could produce SOAP request, because SOAP grounds on its working to XML and HTTP, two standards.

To use this feature, first thing is to create an HTTP endpoint for SOAP, and then start or stop the service, with the Surface Area Reduction tool.

'''OLE Automation stored procedures''' (default is disabled)

This feature allows access properties and methods of an ActiveX object within SQL Server. If it's necessary to obtain informations inside a DLL that is not available inside SQL Server, it's possible to use some stored procedure to do the work, enabling this feature, but it's better to access the object with the right language, not with T-SQL.
To disable this feature launch:

EXEC sp_configure 'Ole Automation Procedures',0
GO
RECONFIGURE
GO

'''Service Broker''' (default no Service Broker endpoints is created)

Service Broker is a technology in which two or more entities accomplish a task, sending and receiving messages, in a asynchronous mode. As XML Web Services, to use this feature, a Service Broker endpoint must be created.
A Service Broker endpoint listens on a specific TCP port numberm (tipically 4022, but could be configured during the endpoint's creation).
The authentication against Service Broker could be BASIC, DIGEST, NTLM, KERBEROS, INTEGRATED.

To use this feature, first thing is to create a TCP endpoint for SERVICE_BROKER, and then start or stop the service, with the Surface Area Reduction tool.

'''SQL Mail''' (default is disabled)

SQL Mail is a feature for legacy applications, supported for backward compatibility, to send and receive email using MAPI protocol. This is replaced by Database Mail Feature.
To disable this feature launch:

EXEC sp_configure 'SQL Mail XPs',0
GO
RECONFIGURE
GO

'''Web Assistant stored procedures''' (default is disabled)

This feature enable stored procedures to generate HTML report from the data results. It's deprecated because there are others components (like Reporting Services) to present data in a browser.
To disable this feature launch:

EXEC sp_configure 'Web Assistant Procedures',0
GO
RECONFIGURE
GO

'''xp_cmdshell''' (default is disabled)

This feature enable the extended stored procedure "xp_cmdshell". By definition "executes a command string as an operating-system command shell and returns any output as rows of text".
Enabling xp_cmdshell is potentially very dangerous, because it allows a complete interaction with the operating system, so it's possible to give every command. It's better to do administratives tasks not using SQL Server, so mantain disable xp_cmdshell.
To disable this feature launch:

EXEC sp_configure 'xp_cmdshell',0
GO
RECONFIGURE
GO

=== Sql Server Configuration Manager (endpoints and protocols) ===

=== System Stored Procedure ===

Sql Server provides a lot of system stored procedures, to accomplish administratives tasks.
Surface Configuration Area for features for example is a graphical interface that uses, as it's showed, the stored procedure '''sp_configure''' in conjunction with '''RECONFIGURE''' command to modify the server's configuration.
So even if the server is well configurated avoiding every dangerous stored procedure (such as xp_cmdshell), if the application is vulnerable, a sql injection can cause the execution of the script:

EXEC sp_configure 'xp_cmdshell',1
GO
RECONFIGURE
GO

and automatically the xp_cmdshell would be enabled.
The solutions technically could be:
* Dropping the sp_configure
* Configuring in a right manner the LOGIN inside the Sql Server

The first solution is not good, because dropping system stored procedure could cause anomalies when it's time to patching the server with the last updates/upgrades.
So it's better to think in an "administrative manner"
For example, sp_configure with zero or one parameter could be executed by everyone. But sp_configure with two parameters (necessary to re-enable xp_cmdshell) could be executed by users that have ALTER SETTINGS permission.
In SQL Server there are two roles that, after installation, have ALTER SETTINGS permission:
* sysadmin
* serveradmin
So it's necessary that the LOGIN used to connect to a database for an application doesn't belong to these roles, and at the same time doesn't have the ALTER SETTINGS permission.
In this manner, there will be not possible to re-enable, for example, xp_cmdshell.

To look that, there are some system stored procedure used to view roles and permission for a LOGIN. Imagine for example that a web application connect to a database with a SQL Login called 'userToConnect'.
To see if this user belong to sysadmin or serveradmin roles, it's possible to digit:

SELECT * FROM sys.server_role_members x
INNER JOIN sys.server_principals y
ON x.member_principal_id = y.principal_id
WHERE y.name = 'userToConnect'

If there are one o more results, look at the first column. The possibilities for the "role_principal_id" are:
* 3=sysadmin
* 4=securityadmin
* 5=serveradmin
* 6=setupadmin
* 7=processadmin
* 8=diskadmin
* 9=dbcreator
* 10=bulkadmin

So if the 'userToConnect' doesn't have in the results number 3 or 5, doesn't belong to those roles. However it's not sufficient. Another check must be done. So launch

SELECT x.permission_name FROM sys.server_permissions x
INNER JOIN sys.server_principals y
ON x.grantee_principal_id = y.principal_id
WHERE y.name = 'userToConnect'

If the results don't have the permission ALTER SETTINGS, the "userToConnect" can't modify the server settings. Otherwise revoke the permission with:

REVOKE ALTER SETTINGS TO userToConnect

== Database Administration ==

=== Password Policies ===
When it's time to create a new Login on Sql Server, it's very important to use some evalation criteria. A possible script to do that is:

USE [master]
GO
CREATE LOGIN [userName1] WITH PASSWORD=N'password1'
MUST_CHANGE, DEFAULT_DATABASE=[master], CHECK_EXPIRATION=ON, CHECK_POLICY=ON

The relevant things are:

* MUST_CHANGE --> after the first login, the user must change the planned password (in this case "password1"). Applied to SQL Logins
* CHECK_EXPIRATION=ON --> the password must accomplish the expiration policy. Applied to SQL Logins
* CHECK_POLICY=ON --> the password must accomplish the Windows policy. Applied to SQL Logins

When SQL Server 2005 runs on Windows Server 2003 or higher, it can benefit on Windows password policies. These are configured on Control Panel -> Administrative Tools -> Local Security Settings.
On "Account Policies" there are

* Password Policy
* Account Lockout Policy

On the first option, it's important to set:
* Enforce password history (number of password stored for each account, to avoid repeating every time the same password. The range is [0-24])
* Maximum password age (max number of days in which the password is valid. The range is [1-998]. A 0 value indicates no expiration)
* Minimum password age (min number of days in which the password could not be changed The range is [1-998]. A 0 value indicates that the password could be changed in every moment)
* Minimum password length (minimum number of characters. The range is [1-14]. A 0 value indicates no password needed)
* Password must meet complexity requirements (no two consecutive character of account name, minimum 6 character belonging at least at three of the categories [A-Z], [a-z], [0-9], or characters like !, %, #, $ ecc...)

On the second option, it's important to set:
* Account lockout duration: (indicates the number of minutes in which the account is locked. The range is [1-99999]. A 0 value indicates that the account will be blocked until the administrator unlocks it)
* Account lockout threshold (indicates the max number of failed attempts after that the login is blocked. The range is [1-99999]. A 0 value indicates that the account won't be never blocked)
* Reset account lockout counter after (indicates the number of minutes that must elapse before the number of attempts return to zero. The range is [1-99999].)

If an account is locked (for example due of an attempt to brute force that exceed the "Account lockout threshold" or simply for an error), a new password must be created by the administrator. So a good choice is to ALTER the login with a MUST_CHANGE new password, to force the user to modify it during the first login. The script is like that:

USE [master]
GO
ALTER LOGIN [userName1] WITH PASSWORD=N'12345678' UNLOCK MUST_CHANGE
GO

=== Authorization ===
=== Roles and Schemas ===
=== Metadata Views ===
=== Linked Servers ===
=== Execution Context ===

== Encryption ==

=== Symmetric ===
=== Asymmetric ===
=== Asymmetric with certificate ===

= References =

OWASP Backend Security Project SQLServer Hardening

2008-07-24T22:09:43Z

GPederzini: /* Password Policies */

= Overview =
In this section there are some best practices concerning the security of SQL Server 2005. The operating system under SQL Server is Windows Server 2003.

= Description =

== Installation of the Engine ==
The prerequisites for the installation are:
* .NET Framework 2.0
* Microsoft SQL Native Client
* Microsoft SQL Server 2005 Setup Support Files.

The installation consist of a large amount of services that are shortly descripted:
* SQL Server Database Services (install SQL Server database engine and tools for managing relational and XML data, replication and full text search)
* Analysis Services (install analysis services and tools used to support online analytical procession OLAP and data mining. Install also Integration Services)
* Notification Services (installs notification services a platform for developing and deploying applications that send personalized, timely notifications to a variety of devices or applications)
* Integration Services (install a set of tools and programmable objects for creating and managing packages that extract, transofrm and load data, as well perform task)
* Client Components (install management tools, development tools and legacy components)
* Documentation, samples and sample databases (installs books online documentation, sample databases and sample applications for all sql 2005 components)
During the installation the thing to remind is that from a security point of view, only what is strictly needed must be installed. To install a tipycal minimal configuration, the SQL Server Database Services and some Client Components (Connectivity components and Management Tools) can be installed.
=== Services ===
In SQL Server every service can run under a particular Windows account. The choices for the service's accounts are:

* Local user that is not a Windows administrator
* Domain user that is not a Windows administrator
* Local Service account
* Network Service account
* Local System account
* Local user that is a Windows administrator
* Domain user that is a Windows administrator

There is not only a solution to configure the service's account, but there are two rules to follow that enforce to behave in certain way:
* minimum privileges
* account isolation
Follow this, probably an administrator account (local or domain) has much more privileges than needed, indipendently of the service.
The Local System account has to many privileges and it's not indicated for a service's account
On the other hand Local Service and Network Service have not much privileges, but they are used for more Windows services, so there is no account isolation.

So the more secure solution for the Sql Server Service's Account is to use Local User or Domain User not Administrators.
For example imagine that are installed the trhee main services:
* Sql Server
* Sql Server Agent
* Sql Server Browser
The task is to create three Windows Local User Account, belonging to User Group, protected with password, and assign them to the services.
In this manner there are exactly two concepts: minimum privileges and account isolation.

=== Authentication Mode ===
Sql Server provides two kinds of authentication: SQL Server Authentication and Windows Authentication. During the installation is possible to enable both (Mixed Mode) or only the Windows Authentication (Windows Mode)

If there is an homogeneous Windows environment, the more secure solution is to enable the Windows mode Authentication, because the administration of the logins is made in the Windows Server and the credentials are not passed through the network, because Windows Authentication uses NTLM or Kerberos Protocols.
If there is an heterogeneous environment, for example no domain controller or there are some legacy applications that have to connect to Sql Server, only the Mixed Mode solution is possible. In this second case the administration of the logins is made inside SQL Server and the credentials are necessarily passed through the network.

Is important to say that in a Windows Mode Authentication, the "sa" user (system administrator) is not enabled. In a mixed mode is enabled.
So in an environment with Mixed Mode Authentication, to avoid the attacks against "sa" user, is better to:
* rename "sa" with another name
* use a strong password for the renamed "sa"

=== Processes ===
Every services that is installed in Sql Server could be administrated through the tool "Sql Server Configuration Manager" that is possible to install, enabling the client component of Sql Server.
With this tool is possible to realize the two best practices for the account's services, assigning to every service a specific account protected with password, that authenticates against Windows.
Every service could be started or stopped in a manual or automatic manner, like other Windows Services.

== Configuration tools provided ==

=== Surface Area Reduction (services and connections) ===
The Surface Area Reduction is a powerful tool provided with Sql Server 2005 to configure:
* Services & Connections

'''Services'''

Every Service installed could be rapidly managed. It's posssible in every moment to:
* Manage the status of the service with the possibilities: Start/Stop & Pause/Resume
* Manage the action of the operating system on startup for that service: Automatic, Manual, Disabled.

The concept is to configure automatic start only for those services that are immediately needed, disabling or manually starting others services that are not necessary.

'''Connections'''

For every instance of SQL Server is possible to allow:
* Only local connection to the server
* Local and remote connections to the server
In a distributed environment probably it's necessary to allow both the connection's type, but it's easy to understand that allowing remote connections expose the server more easily.
So for the remote connections Sql Server could allow two kind of protocols:
* TCP/IP
* Named Piped
For the normal use the better thing is to configure only TCP/IP, because Named Pipes need more open port to work.
Additionally there are others two kinds of connections to the server:
* VIA
* Shared Memory
VIA (Virtual Interface Adapter protocol ) works with VIA hardware. Shared Memory is a protocol that is possible to use only by local connections.
Using the Sql Server Configuration Manager the best solution is enable TCP/IP for remote connections and Shared Memory for the local connections.

=== Surface Area Reduction (features) ===
This is a series of interfaces for enabling or disabling many Database Engine, Analysis Services, and Reporting Services features. The most important are the features of the Database Engine:

* Ad hoc distributed queries
* Common language runtime (CLR) integration
* Dedicated administrator connection (DAC)
* Database Mail
* Native XML Web services
* OLE Automation stored procedures
* Service Broker
* SQL Mail
* Web Assistant stored procedures
* xp_cmdshell

'''Ad hoc distributed queries''' (default is disabled)

This feature enable the OPENROWSET and OPENDATASOURCE calls, to connect to an OLE DB data source. To disable this feature launch:

EXEC sp_configure 'Ad Hoc Distributed Queries',0
GO
RECONFIGURE
GO

It's recommended to disable this feature, because in a case of Sql Injection, an attacker could use OPENROWSET to connect to a database.

'''Common language runtime (CLR) integration''' (default is disabled)

This feature give the possibility to write stored procedures, triggers, user defined functions using a .NET Framework language. So if the server is not used with this aim, or if all the databases object are written with T-SQL, there's no reason to enable this. To disable this feature launch:

EXEC sp_configure 'clr enabled',0
GO
RECONFIGURE
GO

'''Dedicated administrator connection (DAC)''' (default is disabled)

This feature enables the possibility to execute diagnostics queries and troubleshoot problems when there are some problems to connect with standard mode to the server.
The uses are tipically:

* Querying some dynamic management views of SQL Server to obtain informations about the "status health"
* Basic DBCC commands (for example DBCC SHRINKDATABASE to cut the log file)
* Kill the PID of processes

But for example is possible to do other works, like add logins with sysadmin privileges or other administrator's tasks
This is an emergency type of connection, that SQL Server can permit every time, reserving an amount of resources during startup. It permits only a user a time, so if there is an user connected via DAC, no others users can connect. It's possible to use it with SQLCMD or Sql Server Management Studio, through the sintax:

Admin:<namepc>\<nameSqlInstance>

So DAC is only another type of connection, and in every time the credentials must be given to the server, but if it's not necessary, disable it.
To disable this feature launch:

EXEC sp_configure 'remote admin connections',0
GO
RECONFIGURE
GO

'''Database mail''' (default is disabled)

The database mail feature enables the possibility to use the Sql Server Instance to send email. If it's a powerful solution to give some advices to a sysadmin, from a security point of view it's a good practice to use the instance with the only aims that needed.
To disable this feature launch:

EXEC sp_configure 'Database Mail XPs',0
GO
RECONFIGURE
GO

'''Native XML Web services''' (default no SOAP endpoints are created)

This feature basically gives the possibility to use SQL Server as a Web Services provider. It's possible to create HTTP Endpoints in Sql Server, associated for example to a result of stored procedure.
A SOAP client could consume a service simply invoking the correct url provided by Sql Server, without others layers (tipically an IIS web server in wich the web services are hosted).
Enabling this feature and create HTTP endpoints goes in the direction to increase the surface of attack. Every client could produce SOAP request, because SOAP grounds on its working to XML and HTTP, two standards.

To use this feature, first thing is to create an HTTP endpoint for SOAP, and then start or stop the service, with the Surface Area Reduction tool.

'''OLE Automation stored procedures''' (default is disabled)

This feature allows access properties and methods of an ActiveX object within SQL Server. If it's necessary to obtain informations inside a DLL that is not available inside SQL Server, it's possible to use some stored procedure to do the work, enabling this feature, but it's better to access the object with the right language, not with T-SQL.
To disable this feature launch:

EXEC sp_configure 'Ole Automation Procedures',0
GO
RECONFIGURE
GO

'''Service Broker''' (default no Service Broker endpoints is created)

Service Broker is a technology in which two or more entities accomplish a task, sending and receiving messages, in a asynchronous mode. As XML Web Services, to use this feature, a Service Broker endpoint must be created.
A Service Broker endpoint listens on a specific TCP port numberm (tipically 4022, but could be configured during the endpoint's creation).
The authentication against Service Broker could be BASIC, DIGEST, NTLM, KERBEROS, INTEGRATED.

To use this feature, first thing is to create a TCP endpoint for SERVICE_BROKER, and then start or stop the service, with the Surface Area Reduction tool.

'''SQL Mail''' (default is disabled)

SQL Mail is a feature for legacy applications, supported for backward compatibility, to send and receive email using MAPI protocol. This is replaced by Database Mail Feature.
To disable this feature launch:

EXEC sp_configure 'SQL Mail XPs',0
GO
RECONFIGURE
GO

'''Web Assistant stored procedures''' (default is disabled)

This feature enable stored procedures to generate HTML report from the data results. It's deprecated because there are others components (like Reporting Services) to present data in a browser.
To disable this feature launch:

EXEC sp_configure 'Web Assistant Procedures',0
GO
RECONFIGURE
GO

'''xp_cmdshell''' (default is disabled)

This feature enable the extended stored procedure "xp_cmdshell". By definition "executes a command string as an operating-system command shell and returns any output as rows of text".
Enabling xp_cmdshell is potentially very dangerous, because it allows a complete interaction with the operating system, so it's possible to give every command. It's better to do administratives tasks not using SQL Server, so mantain disable xp_cmdshell.
To disable this feature launch:

EXEC sp_configure 'xp_cmdshell',0
GO
RECONFIGURE
GO

=== Sql Server Configuration Manager (endpoints and protocols) ===

=== System Stored Procedure ===

Sql Server provides a lot of system stored procedures, to accomplish administratives tasks.
Surface Configuration Area for features for example is a graphical interface that uses, as it's showed, the stored procedure '''sp_configure''' in conjunction with '''RECONFIGURE''' command to modify the server's configuration.
So even if the server is well configurated avoiding every dangerous stored procedure (such as xp_cmdshell), if the application is vulnerable, a sql injection can cause the execution of the script:

EXEC sp_configure 'xp_cmdshell',1
GO
RECONFIGURE
GO

and automatically the xp_cmdshell would be enabled.
The solutions technically could be:
* Dropping the sp_configure
* Configuring in a right manner the LOGIN inside the Sql Server

The first solution is not good, because dropping system stored procedure could cause anomalies when it's time to patching the server with the last updates/upgrades.
So it's better to think in an "administrative manner"
For example, sp_configure with zero or one parameter could be executed by everyone. But sp_configure with two parameters (necessary to re-enable xp_cmdshell) could be executed by users that have ALTER SETTINGS permission.
In SQL Server there are two roles that, after installation, have ALTER SETTINGS permission:
* sysadmin
* serveradmin
So it's necessary that the LOGIN used to connect to a database for an application doesn't belong to these roles, and at the same time doesn't have the ALTER SETTINGS permission.
In this manner, there will be not possible to re-enable, for example, xp_cmdshell.

To look that, there are some system stored procedure used to view roles and permission for a LOGIN. Imagine for example that a web application connect to a database with a SQL Login called 'userToConnect'.
To see if this user belong to sysadmin or serveradmin roles, it's possible to digit:

SELECT * FROM sys.server_role_members x
INNER JOIN sys.server_principals y
ON x.member_principal_id = y.principal_id
WHERE y.name = 'userToConnect'

If there are one o more results, look at the first column. The possibilities for the "role_principal_id" are:
* 3=sysadmin
* 4=securityadmin
* 5=serveradmin
* 6=setupadmin
* 7=processadmin
* 8=diskadmin
* 9=dbcreator
* 10=bulkadmin

So if the 'userToConnect' doesn't have in the results number 3 or 5, doesn't belong to those roles. However it's not sufficient. Another check must be done. So launch

SELECT x.permission_name FROM sys.server_permissions x
INNER JOIN sys.server_principals y
ON x.grantee_principal_id = y.principal_id
WHERE y.name = 'userToConnect'

If the results don't have the permission ALTER SETTINGS, the "userToConnect" can't modify the server settings. Otherwise revoke the permission with:

REVOKE ALTER SETTINGS TO userToConnect

== Database Administration ==

=== Password Policies ===
When it's time to create a new Login on Sql Server, it's very important to use some evalation criteria. A possible script to do that is:

USE [master]
GO
CREATE LOGIN [userName1] WITH PASSWORD=N'password1'
MUST_CHANGE, DEFAULT_DATABASE=[master], CHECK_EXPIRATION=ON, CHECK_POLICY=ON

The relevant things are:

* MUST_CHANGE --> after the first login, the user must change the planned password (in this case "password1"). Applied to SQL Logins
* CHECK_EXPIRATION=ON --> the password must accomplish the expiration policy. Applied to SQL Logins
* CHECK_POLICY=ON --> the password must accomplish the Windows policy. Applied to SQL Logins

When SQL Server 2005 runs on Windows Server 2003 or higher, it can benefit on Windows password policies. These are configured on Control Panel -> Administrative Tools -> Local Security Settings.
On "Account Policies" there are

* Password Policy
* Account Lockout Policy

On the first option, it's important to set:
* Enforce password history (number of password stored for each account, to avoid repeating every time the same password. The range is [0-24])
* Maximum password age (max number of days in which the password is valid. The range is [1-998]. A 0 value indicates no expiration)
* Minimum password age (min number of days in which the password could not be changed The range is [1-998]. A 0 value indicates that the password could be changed in every moment)
* Minimum password length (minimum number of characters. The range is [1-14]. A 0 value indicates no password needed)
* Password must meet complexity requirements (no two consecutive character of account name, minimum 6 character belonging at least at three of the categories [A-Z], [a-z], [0-9], or characters like !, %, #, $ ecc...)

On the second option, it's important to set:
* Account lockout duration: (indicates the number of minutes in which the account is locked. The range is [1-99999]. A 0 value indicates that the account will be blocked until the administrator unlocks it)
* Account lockout threshold (indicates the max number of failed attempts after that the login is blocked. The range is [1-99999]. A 0 value indicates that the account won't be never blocked)
* Reset account lockout counter after (indicates the number of minutes that must elapse before the number of attempts return to zero. The range is [1-99999].)

=== Authorization ===
=== Roles and Schemas ===
=== Metadata Views ===
=== Linked Servers ===
=== Execution Context ===

== Encryption ==

=== Symmetric ===
=== Asymmetric ===
=== Asymmetric with certificate ===

= References =

OWASP Backend Security Project SQLServer Hardening

2008-07-24T22:04:10Z

GPederzini: /* Password Policies */

= Overview =
In this section there are some best practices concerning the security of SQL Server 2005. The operating system under SQL Server is Windows Server 2003.

= Description =

== Installation of the Engine ==
The prerequisites for the installation are:
* .NET Framework 2.0
* Microsoft SQL Native Client
* Microsoft SQL Server 2005 Setup Support Files.

The installation consist of a large amount of services that are shortly descripted:
* SQL Server Database Services (install SQL Server database engine and tools for managing relational and XML data, replication and full text search)
* Analysis Services (install analysis services and tools used to support online analytical procession OLAP and data mining. Install also Integration Services)
* Notification Services (installs notification services a platform for developing and deploying applications that send personalized, timely notifications to a variety of devices or applications)
* Integration Services (install a set of tools and programmable objects for creating and managing packages that extract, transofrm and load data, as well perform task)
* Client Components (install management tools, development tools and legacy components)
* Documentation, samples and sample databases (installs books online documentation, sample databases and sample applications for all sql 2005 components)
During the installation the thing to remind is that from a security point of view, only what is strictly needed must be installed. To install a tipycal minimal configuration, the SQL Server Database Services and some Client Components (Connectivity components and Management Tools) can be installed.
=== Services ===
In SQL Server every service can run under a particular Windows account. The choices for the service's accounts are:

* Local user that is not a Windows administrator
* Domain user that is not a Windows administrator
* Local Service account
* Network Service account
* Local System account
* Local user that is a Windows administrator
* Domain user that is a Windows administrator

There is not only a solution to configure the service's account, but there are two rules to follow that enforce to behave in certain way:
* minimum privileges
* account isolation
Follow this, probably an administrator account (local or domain) has much more privileges than needed, indipendently of the service.
The Local System account has to many privileges and it's not indicated for a service's account
On the other hand Local Service and Network Service have not much privileges, but they are used for more Windows services, so there is no account isolation.

So the more secure solution for the Sql Server Service's Account is to use Local User or Domain User not Administrators.
For example imagine that are installed the trhee main services:
* Sql Server
* Sql Server Agent
* Sql Server Browser
The task is to create three Windows Local User Account, belonging to User Group, protected with password, and assign them to the services.
In this manner there are exactly two concepts: minimum privileges and account isolation.

=== Authentication Mode ===
Sql Server provides two kinds of authentication: SQL Server Authentication and Windows Authentication. During the installation is possible to enable both (Mixed Mode) or only the Windows Authentication (Windows Mode)

If there is an homogeneous Windows environment, the more secure solution is to enable the Windows mode Authentication, because the administration of the logins is made in the Windows Server and the credentials are not passed through the network, because Windows Authentication uses NTLM or Kerberos Protocols.
If there is an heterogeneous environment, for example no domain controller or there are some legacy applications that have to connect to Sql Server, only the Mixed Mode solution is possible. In this second case the administration of the logins is made inside SQL Server and the credentials are necessarily passed through the network.

Is important to say that in a Windows Mode Authentication, the "sa" user (system administrator) is not enabled. In a mixed mode is enabled.
So in an environment with Mixed Mode Authentication, to avoid the attacks against "sa" user, is better to:
* rename "sa" with another name
* use a strong password for the renamed "sa"

=== Processes ===
Every services that is installed in Sql Server could be administrated through the tool "Sql Server Configuration Manager" that is possible to install, enabling the client component of Sql Server.
With this tool is possible to realize the two best practices for the account's services, assigning to every service a specific account protected with password, that authenticates against Windows.
Every service could be started or stopped in a manual or automatic manner, like other Windows Services.

== Configuration tools provided ==

=== Surface Area Reduction (services and connections) ===
The Surface Area Reduction is a powerful tool provided with Sql Server 2005 to configure:
* Services & Connections

'''Services'''

Every Service installed could be rapidly managed. It's posssible in every moment to:
* Manage the status of the service with the possibilities: Start/Stop & Pause/Resume
* Manage the action of the operating system on startup for that service: Automatic, Manual, Disabled.

The concept is to configure automatic start only for those services that are immediately needed, disabling or manually starting others services that are not necessary.

'''Connections'''

For every instance of SQL Server is possible to allow:
* Only local connection to the server
* Local and remote connections to the server
In a distributed environment probably it's necessary to allow both the connection's type, but it's easy to understand that allowing remote connections expose the server more easily.
So for the remote connections Sql Server could allow two kind of protocols:
* TCP/IP
* Named Piped
For the normal use the better thing is to configure only TCP/IP, because Named Pipes need more open port to work.
Additionally there are others two kinds of connections to the server:
* VIA
* Shared Memory
VIA (Virtual Interface Adapter protocol ) works with VIA hardware. Shared Memory is a protocol that is possible to use only by local connections.
Using the Sql Server Configuration Manager the best solution is enable TCP/IP for remote connections and Shared Memory for the local connections.

=== Surface Area Reduction (features) ===
This is a series of interfaces for enabling or disabling many Database Engine, Analysis Services, and Reporting Services features. The most important are the features of the Database Engine:

* Ad hoc distributed queries
* Common language runtime (CLR) integration
* Dedicated administrator connection (DAC)
* Database Mail
* Native XML Web services
* OLE Automation stored procedures
* Service Broker
* SQL Mail
* Web Assistant stored procedures
* xp_cmdshell

'''Ad hoc distributed queries''' (default is disabled)

This feature enable the OPENROWSET and OPENDATASOURCE calls, to connect to an OLE DB data source. To disable this feature launch:

EXEC sp_configure 'Ad Hoc Distributed Queries',0
GO
RECONFIGURE
GO

It's recommended to disable this feature, because in a case of Sql Injection, an attacker could use OPENROWSET to connect to a database.

'''Common language runtime (CLR) integration''' (default is disabled)

This feature give the possibility to write stored procedures, triggers, user defined functions using a .NET Framework language. So if the server is not used with this aim, or if all the databases object are written with T-SQL, there's no reason to enable this. To disable this feature launch:

EXEC sp_configure 'clr enabled',0
GO
RECONFIGURE
GO

'''Dedicated administrator connection (DAC)''' (default is disabled)

This feature enables the possibility to execute diagnostics queries and troubleshoot problems when there are some problems to connect with standard mode to the server.
The uses are tipically:

* Querying some dynamic management views of SQL Server to obtain informations about the "status health"
* Basic DBCC commands (for example DBCC SHRINKDATABASE to cut the log file)
* Kill the PID of processes

But for example is possible to do other works, like add logins with sysadmin privileges or other administrator's tasks
This is an emergency type of connection, that SQL Server can permit every time, reserving an amount of resources during startup. It permits only a user a time, so if there is an user connected via DAC, no others users can connect. It's possible to use it with SQLCMD or Sql Server Management Studio, through the sintax:

Admin:<namepc>\<nameSqlInstance>

So DAC is only another type of connection, and in every time the credentials must be given to the server, but if it's not necessary, disable it.
To disable this feature launch:

EXEC sp_configure 'remote admin connections',0
GO
RECONFIGURE
GO

'''Database mail''' (default is disabled)

The database mail feature enables the possibility to use the Sql Server Instance to send email. If it's a powerful solution to give some advices to a sysadmin, from a security point of view it's a good practice to use the instance with the only aims that needed.
To disable this feature launch:

EXEC sp_configure 'Database Mail XPs',0
GO
RECONFIGURE
GO

'''Native XML Web services''' (default no SOAP endpoints are created)

This feature basically gives the possibility to use SQL Server as a Web Services provider. It's possible to create HTTP Endpoints in Sql Server, associated for example to a result of stored procedure.
A SOAP client could consume a service simply invoking the correct url provided by Sql Server, without others layers (tipically an IIS web server in wich the web services are hosted).
Enabling this feature and create HTTP endpoints goes in the direction to increase the surface of attack. Every client could produce SOAP request, because SOAP grounds on its working to XML and HTTP, two standards.

To use this feature, first thing is to create an HTTP endpoint for SOAP, and then start or stop the service, with the Surface Area Reduction tool.

'''OLE Automation stored procedures''' (default is disabled)

This feature allows access properties and methods of an ActiveX object within SQL Server. If it's necessary to obtain informations inside a DLL that is not available inside SQL Server, it's possible to use some stored procedure to do the work, enabling this feature, but it's better to access the object with the right language, not with T-SQL.
To disable this feature launch:

EXEC sp_configure 'Ole Automation Procedures',0
GO
RECONFIGURE
GO

'''Service Broker''' (default no Service Broker endpoints is created)

Service Broker is a technology in which two or more entities accomplish a task, sending and receiving messages, in a asynchronous mode. As XML Web Services, to use this feature, a Service Broker endpoint must be created.
A Service Broker endpoint listens on a specific TCP port numberm (tipically 4022, but could be configured during the endpoint's creation).
The authentication against Service Broker could be BASIC, DIGEST, NTLM, KERBEROS, INTEGRATED.

To use this feature, first thing is to create a TCP endpoint for SERVICE_BROKER, and then start or stop the service, with the Surface Area Reduction tool.

'''SQL Mail''' (default is disabled)

SQL Mail is a feature for legacy applications, supported for backward compatibility, to send and receive email using MAPI protocol. This is replaced by Database Mail Feature.
To disable this feature launch:

EXEC sp_configure 'SQL Mail XPs',0
GO
RECONFIGURE
GO

'''Web Assistant stored procedures''' (default is disabled)

This feature enable stored procedures to generate HTML report from the data results. It's deprecated because there are others components (like Reporting Services) to present data in a browser.
To disable this feature launch:

EXEC sp_configure 'Web Assistant Procedures',0
GO
RECONFIGURE
GO

'''xp_cmdshell''' (default is disabled)

This feature enable the extended stored procedure "xp_cmdshell". By definition "executes a command string as an operating-system command shell and returns any output as rows of text".
Enabling xp_cmdshell is potentially very dangerous, because it allows a complete interaction with the operating system, so it's possible to give every command. It's better to do administratives tasks not using SQL Server, so mantain disable xp_cmdshell.
To disable this feature launch:

EXEC sp_configure 'xp_cmdshell',0
GO
RECONFIGURE
GO

=== Sql Server Configuration Manager (endpoints and protocols) ===

=== System Stored Procedure ===

Sql Server provides a lot of system stored procedures, to accomplish administratives tasks.
Surface Configuration Area for features for example is a graphical interface that uses, as it's showed, the stored procedure '''sp_configure''' in conjunction with '''RECONFIGURE''' command to modify the server's configuration.
So even if the server is well configurated avoiding every dangerous stored procedure (such as xp_cmdshell), if the application is vulnerable, a sql injection can cause the execution of the script:

EXEC sp_configure 'xp_cmdshell',1
GO
RECONFIGURE
GO

and automatically the xp_cmdshell would be enabled.
The solutions technically could be:
* Dropping the sp_configure
* Configuring in a right manner the LOGIN inside the Sql Server

The first solution is not good, because dropping system stored procedure could cause anomalies when it's time to patching the server with the last updates/upgrades.
So it's better to think in an "administrative manner"
For example, sp_configure with zero or one parameter could be executed by everyone. But sp_configure with two parameters (necessary to re-enable xp_cmdshell) could be executed by users that have ALTER SETTINGS permission.
In SQL Server there are two roles that, after installation, have ALTER SETTINGS permission:
* sysadmin
* serveradmin
So it's necessary that the LOGIN used to connect to a database for an application doesn't belong to these roles, and at the same time doesn't have the ALTER SETTINGS permission.
In this manner, there will be not possible to re-enable, for example, xp_cmdshell.

To look that, there are some system stored procedure used to view roles and permission for a LOGIN. Imagine for example that a web application connect to a database with a SQL Login called 'userToConnect'.
To see if this user belong to sysadmin or serveradmin roles, it's possible to digit:

SELECT * FROM sys.server_role_members x
INNER JOIN sys.server_principals y
ON x.member_principal_id = y.principal_id
WHERE y.name = 'userToConnect'

If there are one o more results, look at the first column. The possibilities for the "role_principal_id" are:
* 3=sysadmin
* 4=securityadmin
* 5=serveradmin
* 6=setupadmin
* 7=processadmin
* 8=diskadmin
* 9=dbcreator
* 10=bulkadmin

So if the 'userToConnect' doesn't have in the results number 3 or 5, doesn't belong to those roles. However it's not sufficient. Another check must be done. So launch

SELECT x.permission_name FROM sys.server_permissions x
INNER JOIN sys.server_principals y
ON x.grantee_principal_id = y.principal_id
WHERE y.name = 'userToConnect'

If the results don't have the permission ALTER SETTINGS, the "userToConnect" can't modify the server settings. Otherwise revoke the permission with:

REVOKE ALTER SETTINGS TO userToConnect

== Database Administration ==

=== Password Policies ===
When it's time to create a new Login on Sql Server, it's very important to use some evalation criteria. A possible script to do that is:

USE [master]
GO
CREATE LOGIN [userName1] WITH PASSWORD=N'password1'
MUST_CHANGE, DEFAULT_DATABASE=[master], CHECK_EXPIRATION=ON, CHECK_POLICY=ON

The relevant things are:

* MUST_CHANGE --> after the first login, the user must change the planned password (in this case "password1"). Applied to SQL Logins
* CHECK_EXPIRATION=ON --> the password must accomplish the expiration policy. Applied to SQL Logins
* CHECK_POLICY=ON --> the password must accomplish the Windows policy. Applied to SQL Logins

When SQL Server 2005 runs on Windows Server 2003 or higher, it can benefit on Windows password policies. These are configured on Control Panel -> Administrative Tools -> Local Security Settings.
On "Account Policies" there are

* Password Policy
* Account Lockout Policy

On the first option, it's important to set:
* Enforce password history (number of password stored for each account, to avoid repeating every time the same password. The range is [0-24])
* Maximum password age (max number of days in which the password is valid. The range is [1-998]. A 0 value indicates no expiration)
* Minimum password age (min number of days in which the password could not be changed The range is [1-998]. A 0 value indicates that the password could be changed in every moment)
* Minimum password length (minimum number of characters. The range is [1-14]. A 0 value indicates no password needed)
* Password must meet complexity requirements (no two consecutive character of account name, minimum 6 character belonging at least at three of the categories [A-Z], [a-z], [0-9], or characters like !, %, #, $ ecc...)

On the second option, it's important to set:
* Account lockout duration: (indicates the number of minutes in which the account is locked. The range is [1-99999]. A 0 value indicates that the account will be blocked until the administrator unlocks it)
* Account lockout threshold (indicates the max number of failed attempts after that the login is blocked. The range is [1-999]. A 0 value indicates that the account won't be never blocked)
* Reset account lockout counter after (indicates the number of minutes that must elapse before the number of attempts return to zero. The range is [1-99999].)

=== Authorization ===
=== Roles and Schemas ===
=== Metadata Views ===
=== Linked Servers ===
=== Execution Context ===

== Encryption ==

=== Symmetric ===
=== Asymmetric ===
=== Asymmetric with certificate ===

= References =

OWASP Backend Security Project SQLServer Hardening

2008-07-24T21:44:01Z

GPederzini: /* Password Policies */

= Overview =
In this section there are some best practices concerning the security of SQL Server 2005. The operating system under SQL Server is Windows Server 2003.

= Description =

== Installation of the Engine ==
The prerequisites for the installation are:
* .NET Framework 2.0
* Microsoft SQL Native Client
* Microsoft SQL Server 2005 Setup Support Files.

The installation consist of a large amount of services that are shortly descripted:
* SQL Server Database Services (install SQL Server database engine and tools for managing relational and XML data, replication and full text search)
* Analysis Services (install analysis services and tools used to support online analytical procession OLAP and data mining. Install also Integration Services)
* Notification Services (installs notification services a platform for developing and deploying applications that send personalized, timely notifications to a variety of devices or applications)
* Integration Services (install a set of tools and programmable objects for creating and managing packages that extract, transofrm and load data, as well perform task)
* Client Components (install management tools, development tools and legacy components)
* Documentation, samples and sample databases (installs books online documentation, sample databases and sample applications for all sql 2005 components)
During the installation the thing to remind is that from a security point of view, only what is strictly needed must be installed. To install a tipycal minimal configuration, the SQL Server Database Services and some Client Components (Connectivity components and Management Tools) can be installed.
=== Services ===
In SQL Server every service can run under a particular Windows account. The choices for the service's accounts are:

* Local user that is not a Windows administrator
* Domain user that is not a Windows administrator
* Local Service account
* Network Service account
* Local System account
* Local user that is a Windows administrator
* Domain user that is a Windows administrator

There is not only a solution to configure the service's account, but there are two rules to follow that enforce to behave in certain way:
* minimum privileges
* account isolation
Follow this, probably an administrator account (local or domain) has much more privileges than needed, indipendently of the service.
The Local System account has to many privileges and it's not indicated for a service's account
On the other hand Local Service and Network Service have not much privileges, but they are used for more Windows services, so there is no account isolation.

So the more secure solution for the Sql Server Service's Account is to use Local User or Domain User not Administrators.
For example imagine that are installed the trhee main services:
* Sql Server
* Sql Server Agent
* Sql Server Browser
The task is to create three Windows Local User Account, belonging to User Group, protected with password, and assign them to the services.
In this manner there are exactly two concepts: minimum privileges and account isolation.

=== Authentication Mode ===
Sql Server provides two kinds of authentication: SQL Server Authentication and Windows Authentication. During the installation is possible to enable both (Mixed Mode) or only the Windows Authentication (Windows Mode)

If there is an homogeneous Windows environment, the more secure solution is to enable the Windows mode Authentication, because the administration of the logins is made in the Windows Server and the credentials are not passed through the network, because Windows Authentication uses NTLM or Kerberos Protocols.
If there is an heterogeneous environment, for example no domain controller or there are some legacy applications that have to connect to Sql Server, only the Mixed Mode solution is possible. In this second case the administration of the logins is made inside SQL Server and the credentials are necessarily passed through the network.

Is important to say that in a Windows Mode Authentication, the "sa" user (system administrator) is not enabled. In a mixed mode is enabled.
So in an environment with Mixed Mode Authentication, to avoid the attacks against "sa" user, is better to:
* rename "sa" with another name
* use a strong password for the renamed "sa"

=== Processes ===
Every services that is installed in Sql Server could be administrated through the tool "Sql Server Configuration Manager" that is possible to install, enabling the client component of Sql Server.
With this tool is possible to realize the two best practices for the account's services, assigning to every service a specific account protected with password, that authenticates against Windows.
Every service could be started or stopped in a manual or automatic manner, like other Windows Services.

== Configuration tools provided ==

=== Surface Area Reduction (services and connections) ===
The Surface Area Reduction is a powerful tool provided with Sql Server 2005 to configure:
* Services & Connections

'''Services'''

Every Service installed could be rapidly managed. It's posssible in every moment to:
* Manage the status of the service with the possibilities: Start/Stop & Pause/Resume
* Manage the action of the operating system on startup for that service: Automatic, Manual, Disabled.

The concept is to configure automatic start only for those services that are immediately needed, disabling or manually starting others services that are not necessary.

'''Connections'''

For every instance of SQL Server is possible to allow:
* Only local connection to the server
* Local and remote connections to the server
In a distributed environment probably it's necessary to allow both the connection's type, but it's easy to understand that allowing remote connections expose the server more easily.
So for the remote connections Sql Server could allow two kind of protocols:
* TCP/IP
* Named Piped
For the normal use the better thing is to configure only TCP/IP, because Named Pipes need more open port to work.
Additionally there are others two kinds of connections to the server:
* VIA
* Shared Memory
VIA (Virtual Interface Adapter protocol ) works with VIA hardware. Shared Memory is a protocol that is possible to use only by local connections.
Using the Sql Server Configuration Manager the best solution is enable TCP/IP for remote connections and Shared Memory for the local connections.

=== Surface Area Reduction (features) ===
This is a series of interfaces for enabling or disabling many Database Engine, Analysis Services, and Reporting Services features. The most important are the features of the Database Engine:

* Ad hoc distributed queries
* Common language runtime (CLR) integration
* Dedicated administrator connection (DAC)
* Database Mail
* Native XML Web services
* OLE Automation stored procedures
* Service Broker
* SQL Mail
* Web Assistant stored procedures
* xp_cmdshell

'''Ad hoc distributed queries''' (default is disabled)

This feature enable the OPENROWSET and OPENDATASOURCE calls, to connect to an OLE DB data source. To disable this feature launch:

EXEC sp_configure 'Ad Hoc Distributed Queries',0
GO
RECONFIGURE
GO

It's recommended to disable this feature, because in a case of Sql Injection, an attacker could use OPENROWSET to connect to a database.

'''Common language runtime (CLR) integration''' (default is disabled)

This feature give the possibility to write stored procedures, triggers, user defined functions using a .NET Framework language. So if the server is not used with this aim, or if all the databases object are written with T-SQL, there's no reason to enable this. To disable this feature launch:

EXEC sp_configure 'clr enabled',0
GO
RECONFIGURE
GO

'''Dedicated administrator connection (DAC)''' (default is disabled)

This feature enables the possibility to execute diagnostics queries and troubleshoot problems when there are some problems to connect with standard mode to the server.
The uses are tipically:

* Querying some dynamic management views of SQL Server to obtain informations about the "status health"
* Basic DBCC commands (for example DBCC SHRINKDATABASE to cut the log file)
* Kill the PID of processes

But for example is possible to do other works, like add logins with sysadmin privileges or other administrator's tasks
This is an emergency type of connection, that SQL Server can permit every time, reserving an amount of resources during startup. It permits only a user a time, so if there is an user connected via DAC, no others users can connect. It's possible to use it with SQLCMD or Sql Server Management Studio, through the sintax:

Admin:<namepc>\<nameSqlInstance>

So DAC is only another type of connection, and in every time the credentials must be given to the server, but if it's not necessary, disable it.
To disable this feature launch:

EXEC sp_configure 'remote admin connections',0
GO
RECONFIGURE
GO

'''Database mail''' (default is disabled)

The database mail feature enables the possibility to use the Sql Server Instance to send email. If it's a powerful solution to give some advices to a sysadmin, from a security point of view it's a good practice to use the instance with the only aims that needed.
To disable this feature launch:

EXEC sp_configure 'Database Mail XPs',0
GO
RECONFIGURE
GO

'''Native XML Web services''' (default no SOAP endpoints are created)

This feature basically gives the possibility to use SQL Server as a Web Services provider. It's possible to create HTTP Endpoints in Sql Server, associated for example to a result of stored procedure.
A SOAP client could consume a service simply invoking the correct url provided by Sql Server, without others layers (tipically an IIS web server in wich the web services are hosted).
Enabling this feature and create HTTP endpoints goes in the direction to increase the surface of attack. Every client could produce SOAP request, because SOAP grounds on its working to XML and HTTP, two standards.

To use this feature, first thing is to create an HTTP endpoint for SOAP, and then start or stop the service, with the Surface Area Reduction tool.

'''OLE Automation stored procedures''' (default is disabled)

This feature allows access properties and methods of an ActiveX object within SQL Server. If it's necessary to obtain informations inside a DLL that is not available inside SQL Server, it's possible to use some stored procedure to do the work, enabling this feature, but it's better to access the object with the right language, not with T-SQL.
To disable this feature launch:

EXEC sp_configure 'Ole Automation Procedures',0
GO
RECONFIGURE
GO

'''Service Broker''' (default no Service Broker endpoints is created)

Service Broker is a technology in which two or more entities accomplish a task, sending and receiving messages, in a asynchronous mode. As XML Web Services, to use this feature, a Service Broker endpoint must be created.
A Service Broker endpoint listens on a specific TCP port numberm (tipically 4022, but could be configured during the endpoint's creation).
The authentication against Service Broker could be BASIC, DIGEST, NTLM, KERBEROS, INTEGRATED.

To use this feature, first thing is to create a TCP endpoint for SERVICE_BROKER, and then start or stop the service, with the Surface Area Reduction tool.

'''SQL Mail''' (default is disabled)

SQL Mail is a feature for legacy applications, supported for backward compatibility, to send and receive email using MAPI protocol. This is replaced by Database Mail Feature.
To disable this feature launch:

EXEC sp_configure 'SQL Mail XPs',0
GO
RECONFIGURE
GO

'''Web Assistant stored procedures''' (default is disabled)

This feature enable stored procedures to generate HTML report from the data results. It's deprecated because there are others components (like Reporting Services) to present data in a browser.
To disable this feature launch:

EXEC sp_configure 'Web Assistant Procedures',0
GO
RECONFIGURE
GO

'''xp_cmdshell''' (default is disabled)

This feature enable the extended stored procedure "xp_cmdshell". By definition "executes a command string as an operating-system command shell and returns any output as rows of text".
Enabling xp_cmdshell is potentially very dangerous, because it allows a complete interaction with the operating system, so it's possible to give every command. It's better to do administratives tasks not using SQL Server, so mantain disable xp_cmdshell.
To disable this feature launch:

EXEC sp_configure 'xp_cmdshell',0
GO
RECONFIGURE
GO

=== Sql Server Configuration Manager (endpoints and protocols) ===

=== System Stored Procedure ===

Sql Server provides a lot of system stored procedures, to accomplish administratives tasks.
Surface Configuration Area for features for example is a graphical interface that uses, as it's showed, the stored procedure '''sp_configure''' in conjunction with '''RECONFIGURE''' command to modify the server's configuration.
So even if the server is well configurated avoiding every dangerous stored procedure (such as xp_cmdshell), if the application is vulnerable, a sql injection can cause the execution of the script:

EXEC sp_configure 'xp_cmdshell',1
GO
RECONFIGURE
GO

and automatically the xp_cmdshell would be enabled.
The solutions technically could be:
* Dropping the sp_configure
* Configuring in a right manner the LOGIN inside the Sql Server

The first solution is not good, because dropping system stored procedure could cause anomalies when it's time to patching the server with the last updates/upgrades.
So it's better to think in an "administrative manner"
For example, sp_configure with zero or one parameter could be executed by everyone. But sp_configure with two parameters (necessary to re-enable xp_cmdshell) could be executed by users that have ALTER SETTINGS permission.
In SQL Server there are two roles that, after installation, have ALTER SETTINGS permission:
* sysadmin
* serveradmin
So it's necessary that the LOGIN used to connect to a database for an application doesn't belong to these roles, and at the same time doesn't have the ALTER SETTINGS permission.
In this manner, there will be not possible to re-enable, for example, xp_cmdshell.

To look that, there are some system stored procedure used to view roles and permission for a LOGIN. Imagine for example that a web application connect to a database with a SQL Login called 'userToConnect'.
To see if this user belong to sysadmin or serveradmin roles, it's possible to digit:

SELECT * FROM sys.server_role_members x
INNER JOIN sys.server_principals y
ON x.member_principal_id = y.principal_id
WHERE y.name = 'userToConnect'

If there are one o more results, look at the first column. The possibilities for the "role_principal_id" are:
* 3=sysadmin
* 4=securityadmin
* 5=serveradmin
* 6=setupadmin
* 7=processadmin
* 8=diskadmin
* 9=dbcreator
* 10=bulkadmin

So if the 'userToConnect' doesn't have in the results number 3 or 5, doesn't belong to those roles. However it's not sufficient. Another check must be done. So launch

SELECT x.permission_name FROM sys.server_permissions x
INNER JOIN sys.server_principals y
ON x.grantee_principal_id = y.principal_id
WHERE y.name = 'userToConnect'

If the results don't have the permission ALTER SETTINGS, the "userToConnect" can't modify the server settings. Otherwise revoke the permission with:

REVOKE ALTER SETTINGS TO userToConnect

== Database Administration ==

=== Password Policies ===
When it's time to create a new Login on Sql Server, it's very important to use some evalation criteria. A possible script to do that is:

USE [master]
GO
CREATE LOGIN [userName1] WITH PASSWORD=N'password1'
MUST_CHANGE, DEFAULT_DATABASE=[master], CHECK_EXPIRATION=ON, CHECK_POLICY=ON

The relevant things are:

* MUST_CHANGE --> after the first login, the user must change the planned password (in this case "password1"). Applied to SQL Logins
* CHECK_EXPIRATION=ON --> the password must accomplish the expiration policy. Applied to SQL Logins
* CHECK_POLICY=ON --> the password must accomplish the Windows policy. Applied to SQL Logins

When SQL Server 2005 runs on Windows Server 2003 or higher, it can benefit on Windows password policies. These are configured on Control Panel -> Administrative Tools -> Local Security Settings.
On "Account Policies" there are

* Password Policy
* Account Lockout Policy

On the first option, it's important to set:
* Enforce password history (number of password stored for each account, to avoid repeating every time the same password. The range is [0-24])
* Maximum password age (max number of days in which the password is valid. The range is [1-998]. A 0 value indicates no expiration)
* Minimum password age (min number of days in which the password could not be changed The range is [1-998]. A 0 value indicates that the password could be changed in every moment)
* Minimum password length (minimum number of characters. The range is [1-14]. A 0 value indicates no password needed)
* Password must meet complexity requirements (no two consecutive character of account name, minimum 6 character belonging at least at three of the categories [A-Z], [a-z], [0-9], or characters like !, %, #, $ ecc...)

On the second option, it's important to set:

=== Authorization ===
=== Roles and Schemas ===
=== Metadata Views ===
=== Linked Servers ===
=== Execution Context ===

== Encryption ==

=== Symmetric ===
=== Asymmetric ===
=== Asymmetric with certificate ===

= References =

OWASP Backend Security Project .NET Security Programming

2008-07-09T07:48:45Z

GPederzini: /* References */

= Overview =

In this section are explained the best solution to avoid two of the most dangerous vulnerabilities of web applications, the sql injection and ldap injection on .NET programming

It will be analized the interactions between a web application written in C# in ASP.NET technology, .NET Framework 2.0 and two kinds of data provider: a SQL Server 2005 data provider and an OpenLdap Server data provider.

For the first interaction imagine a database called “ExampleDB” in which there are some tables. One of these tables is “Users”. From a
web application is possible to query the database to extract information about the users through their name.

For the second interaction imagine an Ldap server called “ExampleLDAP”.

The project is simple and is made by some .aspx page with a textbox in which is possible to insert the name of the user and the program will return the information, reading from ExampleDB (or ExampleLDAP).
It's not important to specify how it's possible to create an aspx page So the focus is on the code that we have to write to interact with the server data provider.

= Description =

== .NET Preventing SQL Injection ==

Two approaches are likely: inline query or stored procedure.

[[Image:owasp_bsp_net_1.jpg]]

=== Case 1: Inline query ===

Inline queries are the queries in which is possible to compose a sql statement through string concatenation. By clicking on the first button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryInline_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%"
+ txtQueryInline.Text + "%'", sqlConnection);
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section of code provides the sqlConnection, reading the connectionString from the Web.Config file. This is an important task for the application because it represents the entry point to the database, the credentials of the user that can authenticate on the ExampleDB.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%" +
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;

In this section is used the SqlCommand class, in which is written the sql code, concatenating with the text to search. The type of the SqlCommand is “Text”, so it's clear that the sql code is provided directly. This code is prone to sql injection, because we can manipulate the statement, injecting in the textbox, for example, the string:

'' '; sql statement -- ''

where sql statement is any sql code (it is possible to drop tables, add users, reconfigure the xp_cmdshell, etc.)

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

The third section is useful to represent the result set of the query. It uses the ADO.NET “Dataset”, and an intermediate class called SqlDataAdapter, that adapts the sql data in a form that can be used by the Dataset Object.

It is possible to improve this query, using the second form of interaction that make use of a stored procedure

=== Case 2: Parametrized query + Stored Procedure vulnerable ===

By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStoredVuln_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStoredVuln.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

CREATE PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This kind of stored procedure are not rare. In this case is possible to compose the statement in many ways using parameters, function and so on.

Altough it is a parametrized query with a stored procedure, as the code shows, it is possible to inject the same string

'' '; sql statement -- ''

to inject a sql statement. Using the SQL Server function REPLACE, it is possible to “patch” the problem without rewrite the store procedure, replacing all the single quote with a couple of single quote.

ALTER PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @Name = REPLACE(@Name,'''','''''')
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This second case explains the fact that the use of parametrized query with stored procedure not always resolve the security flaws caused by sql injection.

=== Case 3: Parametrized query + Stored Procedure not vulnerable ===

It is possible to modify the way to execute the same query, using parametrized query in conjunction with stored procedures. By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStored_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section is the same of the example above.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);

In this section is used the SqlCommand class as above, but, the type of the SqlCommand is “StoredProcedure” , so the sql code is not provided directly, but there is a procedure inside the database that makes the job. This procedure is called USP_SearchUserByNameNotVuln and accept a Varchar(50) parameter called @Name.
The code of the stored is simply:

CREATE PROCEDURE [dbo].[USP_SearchUserByNameNotVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
SELECT
U.Name,
U.Surname,
U.Code
FROM
dbo.Users U
WHERE
U.Name LIKE '''%' + @Name + '%'''
END

Three steps for each parameter passed to the stored procedure are needed to use the SqlParameter class:

* Instantiate the parameter with the right name and type used in the stored procedure
* Assign the value (in this case the value given by the user in the textbox)
* Add the parameter to the SqlCommand

When the sql command is executed, the parameters will be replaced with values specified by the SqlParameter object.

In conclusion, this kind of query is not prone to sql injection, because it is not possibile to build ad hoc sql statements, due to the correct use of Stored Procedure and the SqlParameter class.

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

This section is the same of the example above.

=== Input validation ===

Another point that is important to consider is the validation of the input. For example in a context in which a user has to insert (or select) some data in (or from) the database let’s think about the worst case, that is a user that can digit anything and submit anything to the server. To avoid this the only choiche is to validate the user's input. Two strategies are possible:

1. White list

2. Black list

The first solution answers at the condition: "deny all, except what is explicitly signed in the list".
The second solution answers at the condition: "allow all, except what is explicitly signed in the list".

The best solution for the security of the application is try to implement a validation of the input based on the first case. This comes more simply with numeric input, range input or strings that follow a specific pattern (for example an e-mail or a date). It becomes more difficult for strings with a not specific pattern (for example strings inserted in a search engine) in which often only a solution based on a black list is reasonably possible.

In a Web Application, there are two kinds of input validation:

1. client validations

2. server validations

There are a couple of reasons to use both types of validation summarized in the following points:

* client validations increase performance (the application doesn't postback to the server) but cause a false sense of security (the validation can be bypassed intercepting and manipulating the client request).
* server validations make worse performance but increase the security, because the validation is made by the server.

In ASP.NET to realize these concepts there are the server web control Validators:

* RequiredFieldValidator
* CompareValidator
* RangeValidator
* RegularExpressionValidator
* CustomValidator

Technically these objects realize both type of validations: that is if the client support Javascript, the Validator uses first the client validation, and after that the page is validated on then server side too. If the client doesn't support Javascript, the validation is made only on the server side. In this manner the application validate the input in a progressive mode and the design of the application doesn't follow a '' "Minimum-Denominator-Multiplier" ''.

To explain the concept in code, it's possible to analyze the CustomValidator, that is the higher generalization because it's possible to use a personalized validation logic.

=== CustomValidator ===

We can think symply to a textbox with a button, like the example above, in which it gives the way to search all the suppliers with a specific code (a string of 16 char) For security reasons it is imagined that a specific user can only see the suppliers that have a code in which the first 4 character are "PFHG".

Any other string that doesn't match this pattern has to be exclude from the search (white list approach)

[[Image:owasp_bsp_net_2.jpg]]

The XML part of the page is like that:

<asp:Label ID="lblQuerySearch" runat="server" Text="Digit the first four numbers"></asp:Label>
<asp:TextBox ID="txtQuerySearch" Width="5em" runat="server"></asp:TextBox>
<asp:RequiredFieldValidator ID="RequiredFieldValidatorQuerySearch" runat="server" ErrorMessage="Required Code"
ControlToValidate="txtQuerySearch"></asp:RequiredFieldValidator>
<asp:CustomValidator ID="CustomValidatorQuerySearch" runat="server" ErrorMessage="Wrong code"
ControlToValidate="txtQuerySearch" OnServerValidate="ValidateCode"></asp:CustomValidator>

The control Label and Button are intuitive web controls.
It's clear to see that two Validator have been applied to the textbox whose ID is '' "txtQuerySearch" ''.
The Validators are:

* RequiredFieldValidator: we don't accept an empty textbox when we submit our request to the server
* CustomValidator: we would implement some custom logic to our textbox

In fact the CustomValidator tag has a particular event called "OnServerValidate" that we can hook to a custom callback function, whose code is executed on the server side.
For this example it's like that:

protected void ValidateCode(object source, ServerValidateEventArgs args)
{
try
{
string textToValidate = args.Value;
if (textToValidate.Equals("PFHG"))
args.IsValid = true;
else
args.IsValid = false;
}
catch (Exception ex)
{
args.IsValid = false;
}
}

The function handles the argument "arg" that brings the text inserted by the user.
If this text match with our pattern, the argument is valid and the server executes the code associated to the button, querying the database in the same manner seen above; however the code is now conditioned by the statement "if(Page.IsValid)".

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
if (Page.IsValid)
{
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByCode", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pCode = new SqlParameter("@Code", SqlDbType.VarChar, 4);
pCode.Value = txtQuerySearch.Text;
cmd.Parameters.Add(pCode);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}
}

This is only an example but the use of the Validators can be very important in all the contexts in which the protection of a database from malicious input is needed.

== .NET Preventing LDAP Injection ==

It’s not important here to explain how LDAP works. The focus is explain how it’s possible to avoid the injection of special character, that are responsible of a unpredictable behaviour of the LDAP server.
LDAP search are often made with a distinguished name (DN) and a filter. So if the user input is not properly validated, the user can manipulate the input to craft a malicious filter, to obtain more informations from the server.
LDAP search are made with string, so the best solution to analyze a string searching particular characters is a Regular Expression.
In this example there is the code associated to a event ButtonClick, and two TextBox called "txtUid" and "txtSn" are used to give input to the system

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);
if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}
LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;
try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}
}

''' First Section '''

string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);

The first section uses a Regular Expression, using the class “RegExStringValidator”, very useful to analyze a string.
The string can contain only alphanumeric characters, @, blank or dot.
Others characters different from the indicated subset are not allowed, according to the white list approach.

''' Second Section '''

if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}

In this section there is the code to check if the strings inserted in the textbox “txtUid” and “txtSn” match the rule of the RegExp or not. There is a try-catch block and the object method "Validate" is used to make the job. If the validation passes, the catch block is not processed.

''' Third Section '''

LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;

The third section is the place for the connection to the server.

''' Fourth Section '''

try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}

Finally it's made the request and the server make the response, giving the number of entries that found

== Web.config Encryption ==

Web.config (and others file with .config extension) could contain sensitive informations that should be protected. For a .NET Web Application tipically the parameters to acces to a database are stored in plain text, in a form like this:

<configuration>
<connectionStrings>
<add name="Connection_SQLServer2005" connectionString="Data Source=WIN2K3\SQLInstance; Initial Catalog=Exampledb;
User Id=user; Password=clgir3s2s;" providerName=""/>
</connectionStrings>
</configuration>

It's possible to notice:

* Name of the server machine
* Name of the instance of SQL Server
* Name of the database
* Username
* Password

Gaining the access to directory of the web application, these informations are freely accessible.
The solution to mantain the confidentiality is always one: encryption.
Because encryption is not costless, it's not a good choice to encrypt the Web.config in its totality. It's better to select only the sensitive informations, that often are stored in the "configuration" sections of the file.
In .NET there are two mode to encrypt configuration section:

* Coding with some classes of the Framework
* Using the command line tool "aspnet_regiis.exe" (located in %SystemRoot%\Microsoft.NET\Framework\versionNumber folder)

In both cases the encryption is potentially provided in three modes:

* Windows Data Protection API Provider (DPAPI)
* RSA Protected Configuration Provider
* Custom Provider

DPAPI is the simplest manner. It uses a machine (or user) level key storage, so it's possible to share the secret with all the applications of the machine or not. Additionally it uses an encryption mode based on the login of the user, storing the information in the registry, so no key creation needed. But if the application is deployed in a Web farm, the better is RSA protected configuration provider due to the ease with which RSA keys can be exported.
So it's confortable to use the command line tool "aspnet_regiis.exe" with RSA provider.
First thing it's necessary to create a key container, for the public key encryption; open the SDK command prompt of the Framework and digit:

aspnet_regiis.exe -pc keycontainer1

in this manner a file with public and private key is stored at the path
%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys
with a unique code. It's possible to recognize the creation's datetime. It's important to know that this file is protected by the NTFS ACL, so only the creator and the SYSTEM account can manipulate it.
So if the web application run with another account (for example MACHINENAME\ASPNET user), it's necessary to grant the read permission for the key container with the command:

aspnet_regiis -pa keycontainer1 MACHINENAME\ASPNET

On the other hand add these lines in the Web.Config:

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<configProtectedData>
<providers>
<add name="NameProvider1"
type="System.Configuration.RsaProtectedConfigurationProvider, System.Configuration,
Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a,processorArchitecture=MSIL"
UseMachineContainer="true"
KeyContainerName="keycontainer1"
/>
</providers>
</configProtectedData>

in which there are references of the name of the provider (NameProvider1) that is based on RSA and key container (keycontainer1) used by the provider.
Now it's possible to encrypt the "connectionStrings" section using the physical path of the directory storing the web.config (and the the web application):

aspnet_regiis -pef connectionStrings C:\Project\BackendSecProj -prov NameProvider1

The result is that the connectionStrings section is comparable to:

<connectionStrings configProtectionProvider="NameProvider1">
<EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<KeyName>Rsa Key</KeyName>
</KeyInfo>
<CipherData>
<CipherValue>XV8DCEfUymYphQaL5GTqCQGhrNoED+/rIKNXS3l44exGiQWx2FH0Rq.....</CipherValue>
</CipherData>
</EncryptedKey>
</KeyInfo>
</EncryptedData>
</connectionStrings>

The application that must access to this section do automatically the decryption, due the read permission for the key container granted to the running user.
In any case it's always possible to decrypt the section with:

aspnet_regiis -pdf connectionStrings C:\Project\BackendSecProj

= References =

* http://msdn.microsoft.com/en-us/library/default.aspx
* http://msdn.microsoft.com/en-us/library/6759sth4.aspx
* http://directoryprogramming.net/
* http://msdn.microsoft.com/en-us/library/system.configuration.regexstringvalidator.aspx
* http://www.ietf.org/rfc/rfc2254.txt
* http://msdn.microsoft.com/en-us/library/az24scfc(VS.80).aspx
* http://msdn.microsoft.com/en-us/library/k6h9cz8h(VS.80).aspx
* http://msdn.microsoft.com/en-us/library/dtkwfdky(VS.80).aspx
* http://blogs.vertigosoftware.com/snyholm/archive/2005/12/16/1746.aspx

OWASP Backend Security Project .NET Security Programming

2008-07-09T07:18:39Z

GPederzini: /* Web.config Encryption */

= Overview =

In this section are explained the best solution to avoid two of the most dangerous vulnerabilities of web applications, the sql injection and ldap injection on .NET programming

It will be analized the interactions between a web application written in C# in ASP.NET technology, .NET Framework 2.0 and two kinds of data provider: a SQL Server 2005 data provider and an OpenLdap Server data provider.

For the first interaction imagine a database called “ExampleDB” in which there are some tables. One of these tables is “Users”. From a
web application is possible to query the database to extract information about the users through their name.

For the second interaction imagine an Ldap server called “ExampleLDAP”.

The project is simple and is made by some .aspx page with a textbox in which is possible to insert the name of the user and the program will return the information, reading from ExampleDB (or ExampleLDAP).
It's not important to specify how it's possible to create an aspx page So the focus is on the code that we have to write to interact with the server data provider.

= Description =

== .NET Preventing SQL Injection ==

Two approaches are likely: inline query or stored procedure.

[[Image:owasp_bsp_net_1.jpg]]

=== Case 1: Inline query ===

Inline queries are the queries in which is possible to compose a sql statement through string concatenation. By clicking on the first button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryInline_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%"
+ txtQueryInline.Text + "%'", sqlConnection);
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section of code provides the sqlConnection, reading the connectionString from the Web.Config file. This is an important task for the application because it represents the entry point to the database, the credentials of the user that can authenticate on the ExampleDB.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%" +
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;

In this section is used the SqlCommand class, in which is written the sql code, concatenating with the text to search. The type of the SqlCommand is “Text”, so it's clear that the sql code is provided directly. This code is prone to sql injection, because we can manipulate the statement, injecting in the textbox, for example, the string:

'' '; sql statement -- ''

where sql statement is any sql code (it is possible to drop tables, add users, reconfigure the xp_cmdshell, etc.)

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

The third section is useful to represent the result set of the query. It uses the ADO.NET “Dataset”, and an intermediate class called SqlDataAdapter, that adapts the sql data in a form that can be used by the Dataset Object.

It is possible to improve this query, using the second form of interaction that make use of a stored procedure

=== Case 2: Parametrized query + Stored Procedure vulnerable ===

By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStoredVuln_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStoredVuln.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

CREATE PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This kind of stored procedure are not rare. In this case is possible to compose the statement in many ways using parameters, function and so on.

Altough it is a parametrized query with a stored procedure, as the code shows, it is possible to inject the same string

'' '; sql statement -- ''

to inject a sql statement. Using the SQL Server function REPLACE, it is possible to “patch” the problem without rewrite the store procedure, replacing all the single quote with a couple of single quote.

ALTER PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @Name = REPLACE(@Name,'''','''''')
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This second case explains the fact that the use of parametrized query with stored procedure not always resolve the security flaws caused by sql injection.

=== Case 3: Parametrized query + Stored Procedure not vulnerable ===

It is possible to modify the way to execute the same query, using parametrized query in conjunction with stored procedures. By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStored_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section is the same of the example above.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);

In this section is used the SqlCommand class as above, but, the type of the SqlCommand is “StoredProcedure” , so the sql code is not provided directly, but there is a procedure inside the database that makes the job. This procedure is called USP_SearchUserByNameNotVuln and accept a Varchar(50) parameter called @Name.
The code of the stored is simply:

CREATE PROCEDURE [dbo].[USP_SearchUserByNameNotVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
SELECT
U.Name,
U.Surname,
U.Code
FROM
dbo.Users U
WHERE
U.Name LIKE '''%' + @Name + '%'''
END

Three steps for each parameter passed to the stored procedure are needed to use the SqlParameter class:

* Instantiate the parameter with the right name and type used in the stored procedure
* Assign the value (in this case the value given by the user in the textbox)
* Add the parameter to the SqlCommand

When the sql command is executed, the parameters will be replaced with values specified by the SqlParameter object.

In conclusion, this kind of query is not prone to sql injection, because it is not possibile to build ad hoc sql statements, due to the correct use of Stored Procedure and the SqlParameter class.

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

This section is the same of the example above.

=== Input validation ===

Another point that is important to consider is the validation of the input. For example in a context in which a user has to insert (or select) some data in (or from) the database let’s think about the worst case, that is a user that can digit anything and submit anything to the server. To avoid this the only choiche is to validate the user's input. Two strategies are possible:

1. White list

2. Black list

The first solution answers at the condition: "deny all, except what is explicitly signed in the list".
The second solution answers at the condition: "allow all, except what is explicitly signed in the list".

The best solution for the security of the application is try to implement a validation of the input based on the first case. This comes more simply with numeric input, range input or strings that follow a specific pattern (for example an e-mail or a date). It becomes more difficult for strings with a not specific pattern (for example strings inserted in a search engine) in which often only a solution based on a black list is reasonably possible.

In a Web Application, there are two kinds of input validation:

1. client validations

2. server validations

There are a couple of reasons to use both types of validation summarized in the following points:

* client validations increase performance (the application doesn't postback to the server) but cause a false sense of security (the validation can be bypassed intercepting and manipulating the client request).
* server validations make worse performance but increase the security, because the validation is made by the server.

In ASP.NET to realize these concepts there are the server web control Validators:

* RequiredFieldValidator
* CompareValidator
* RangeValidator
* RegularExpressionValidator
* CustomValidator

Technically these objects realize both type of validations: that is if the client support Javascript, the Validator uses first the client validation, and after that the page is validated on then server side too. If the client doesn't support Javascript, the validation is made only on the server side. In this manner the application validate the input in a progressive mode and the design of the application doesn't follow a '' "Minimum-Denominator-Multiplier" ''.

To explain the concept in code, it's possible to analyze the CustomValidator, that is the higher generalization because it's possible to use a personalized validation logic.

=== CustomValidator ===

We can think symply to a textbox with a button, like the example above, in which it gives the way to search all the suppliers with a specific code (a string of 16 char) For security reasons it is imagined that a specific user can only see the suppliers that have a code in which the first 4 character are "PFHG".

Any other string that doesn't match this pattern has to be exclude from the search (white list approach)

[[Image:owasp_bsp_net_2.jpg]]

The XML part of the page is like that:

<asp:Label ID="lblQuerySearch" runat="server" Text="Digit the first four numbers"></asp:Label>
<asp:TextBox ID="txtQuerySearch" Width="5em" runat="server"></asp:TextBox>
<asp:RequiredFieldValidator ID="RequiredFieldValidatorQuerySearch" runat="server" ErrorMessage="Required Code"
ControlToValidate="txtQuerySearch"></asp:RequiredFieldValidator>
<asp:CustomValidator ID="CustomValidatorQuerySearch" runat="server" ErrorMessage="Wrong code"
ControlToValidate="txtQuerySearch" OnServerValidate="ValidateCode"></asp:CustomValidator>

The control Label and Button are intuitive web controls.
It's clear to see that two Validator have been applied to the textbox whose ID is '' "txtQuerySearch" ''.
The Validators are:

* RequiredFieldValidator: we don't accept an empty textbox when we submit our request to the server
* CustomValidator: we would implement some custom logic to our textbox

In fact the CustomValidator tag has a particular event called "OnServerValidate" that we can hook to a custom callback function, whose code is executed on the server side.
For this example it's like that:

protected void ValidateCode(object source, ServerValidateEventArgs args)
{
try
{
string textToValidate = args.Value;
if (textToValidate.Equals("PFHG"))
args.IsValid = true;
else
args.IsValid = false;
}
catch (Exception ex)
{
args.IsValid = false;
}
}

The function handles the argument "arg" that brings the text inserted by the user.
If this text match with our pattern, the argument is valid and the server executes the code associated to the button, querying the database in the same manner seen above; however the code is now conditioned by the statement "if(Page.IsValid)".

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
if (Page.IsValid)
{
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByCode", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pCode = new SqlParameter("@Code", SqlDbType.VarChar, 4);
pCode.Value = txtQuerySearch.Text;
cmd.Parameters.Add(pCode);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}
}

This is only an example but the use of the Validators can be very important in all the contexts in which the protection of a database from malicious input is needed.

== .NET Preventing LDAP Injection ==

It’s not important here to explain how LDAP works. The focus is explain how it’s possible to avoid the injection of special character, that are responsible of a unpredictable behaviour of the LDAP server.
LDAP search are often made with a distinguished name (DN) and a filter. So if the user input is not properly validated, the user can manipulate the input to craft a malicious filter, to obtain more informations from the server.
LDAP search are made with string, so the best solution to analyze a string searching particular characters is a Regular Expression.
In this example there is the code associated to a event ButtonClick, and two TextBox called "txtUid" and "txtSn" are used to give input to the system

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);
if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}
LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;
try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}
}

''' First Section '''

string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);

The first section uses a Regular Expression, using the class “RegExStringValidator”, very useful to analyze a string.
The string can contain only alphanumeric characters, @, blank or dot.
Others characters different from the indicated subset are not allowed, according to the white list approach.

''' Second Section '''

if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}

In this section there is the code to check if the strings inserted in the textbox “txtUid” and “txtSn” match the rule of the RegExp or not. There is a try-catch block and the object method "Validate" is used to make the job. If the validation passes, the catch block is not processed.

''' Third Section '''

LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;

The third section is the place for the connection to the server.

''' Fourth Section '''

try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}

Finally it's made the request and the server make the response, giving the number of entries that found

== Web.config Encryption ==

Web.config (and others file with .config extension) could contain sensitive informations that should be protected. For a .NET Web Application tipically the parameters to acces to a database are stored in plain text, in a form like this:

<configuration>
<connectionStrings>
<add name="Connection_SQLServer2005" connectionString="Data Source=WIN2K3\SQLInstance; Initial Catalog=Exampledb;
User Id=user; Password=clgir3s2s;" providerName=""/>
</connectionStrings>
</configuration>

It's possible to notice:

* Name of the server machine
* Name of the instance of SQL Server
* Name of the database
* Username
* Password

Gaining the access to directory of the web application, these informations are freely accessible.
The solution to mantain the confidentiality is always one: encryption.
Because encryption is not costless, it's not a good choice to encrypt the Web.config in its totality. It's better to select only the sensitive informations, that often are stored in the "configuration" sections of the file.
In .NET there are two mode to encrypt configuration section:

* Coding with some classes of the Framework
* Using the command line tool "aspnet_regiis.exe" (located in %SystemRoot%\Microsoft.NET\Framework\versionNumber folder)

In both cases the encryption is potentially provided in three modes:

* Windows Data Protection API Provider (DPAPI)
* RSA Protected Configuration Provider
* Custom Provider

DPAPI is the simplest manner. It uses a machine (or user) level key storage, so it's possible to share the secret with all the applications of the machine or not. Additionally it uses an encryption mode based on the login of the user, storing the information in the registry, so no key creation needed. But if the application is deployed in a Web farm, the better is RSA protected configuration provider due to the ease with which RSA keys can be exported.
So it's confortable to use the command line tool "aspnet_regiis.exe" with RSA provider.
First thing it's necessary to create a key container, for the public key encryption; open the SDK command prompt of the Framework and digit:

aspnet_regiis.exe -pc keycontainer1

in this manner a file with public and private key is stored at the path
%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys
with a unique code. It's possible to recognize the creation's datetime. It's important to know that this file is protected by the NTFS ACL, so only the creator and the SYSTEM account can manipulate it.
So if the web application run with another account (for example MACHINENAME\ASPNET user), it's necessary to grant the read permission for the key container with the command:

aspnet_regiis -pa keycontainer1 MACHINENAME\ASPNET

On the other hand add these lines in the Web.Config:

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<configProtectedData>
<providers>
<add name="NameProvider1"
type="System.Configuration.RsaProtectedConfigurationProvider, System.Configuration,
Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a,processorArchitecture=MSIL"
UseMachineContainer="true"
KeyContainerName="keycontainer1"
/>
</providers>
</configProtectedData>

in which there are references of the name of the provider (NameProvider1) that is based on RSA and key container (keycontainer1) used by the provider.
Now it's possible to encrypt the "connectionStrings" section using the physical path of the directory storing the web.config (and the the web application):

aspnet_regiis -pef connectionStrings C:\Project\BackendSecProj -prov NameProvider1

The result is that the connectionStrings section is comparable to:

<connectionStrings configProtectionProvider="NameProvider1">
<EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<KeyName>Rsa Key</KeyName>
</KeyInfo>
<CipherData>
<CipherValue>XV8DCEfUymYphQaL5GTqCQGhrNoED+/rIKNXS3l44exGiQWx2FH0Rq.....</CipherValue>
</CipherData>
</EncryptedKey>
</KeyInfo>
</EncryptedData>
</connectionStrings>

The application that must access to this section do automatically the decryption, due the read permission for the key container granted to the running user.
In any case it's always possible to decrypt the section with:

aspnet_regiis -pdf connectionStrings C:\Project\BackendSecProj

= References =

* http://msdn.microsoft.com/en-us/library/default.aspx
* http://msdn.microsoft.com/en-us/library/6759sth4.aspx
* http://directoryprogramming.net/
* http://msdn.microsoft.com/en-us/library/system.configuration.regexstringvalidator.aspx
* http://www.ietf.org/rfc/rfc2254.txt
* http://msdn.microsoft.com/en-us/library/az24scfc(VS.80).aspx
* http://msdn.microsoft.com/en-us/library/k6h9cz8h(VS.80).aspx
* http://msdn.microsoft.com/en-us/library/dtkwfdky(VS.80).aspx

OWASP Backend Security Project .NET Security Programming

2008-07-09T07:17:00Z

GPederzini: /* Web.config Encryption */

= Overview =

In this section are explained the best solution to avoid two of the most dangerous vulnerabilities of web applications, the sql injection and ldap injection on .NET programming

It will be analized the interactions between a web application written in C# in ASP.NET technology, .NET Framework 2.0 and two kinds of data provider: a SQL Server 2005 data provider and an OpenLdap Server data provider.

For the first interaction imagine a database called “ExampleDB” in which there are some tables. One of these tables is “Users”. From a
web application is possible to query the database to extract information about the users through their name.

For the second interaction imagine an Ldap server called “ExampleLDAP”.

The project is simple and is made by some .aspx page with a textbox in which is possible to insert the name of the user and the program will return the information, reading from ExampleDB (or ExampleLDAP).
It's not important to specify how it's possible to create an aspx page So the focus is on the code that we have to write to interact with the server data provider.

= Description =

== .NET Preventing SQL Injection ==

Two approaches are likely: inline query or stored procedure.

[[Image:owasp_bsp_net_1.jpg]]

=== Case 1: Inline query ===

Inline queries are the queries in which is possible to compose a sql statement through string concatenation. By clicking on the first button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryInline_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%"
+ txtQueryInline.Text + "%'", sqlConnection);
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section of code provides the sqlConnection, reading the connectionString from the Web.Config file. This is an important task for the application because it represents the entry point to the database, the credentials of the user that can authenticate on the ExampleDB.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%" +
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;

In this section is used the SqlCommand class, in which is written the sql code, concatenating with the text to search. The type of the SqlCommand is “Text”, so it's clear that the sql code is provided directly. This code is prone to sql injection, because we can manipulate the statement, injecting in the textbox, for example, the string:

'' '; sql statement -- ''

where sql statement is any sql code (it is possible to drop tables, add users, reconfigure the xp_cmdshell, etc.)

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

The third section is useful to represent the result set of the query. It uses the ADO.NET “Dataset”, and an intermediate class called SqlDataAdapter, that adapts the sql data in a form that can be used by the Dataset Object.

It is possible to improve this query, using the second form of interaction that make use of a stored procedure

=== Case 2: Parametrized query + Stored Procedure vulnerable ===

By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStoredVuln_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStoredVuln.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

CREATE PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This kind of stored procedure are not rare. In this case is possible to compose the statement in many ways using parameters, function and so on.

Altough it is a parametrized query with a stored procedure, as the code shows, it is possible to inject the same string

'' '; sql statement -- ''

to inject a sql statement. Using the SQL Server function REPLACE, it is possible to “patch” the problem without rewrite the store procedure, replacing all the single quote with a couple of single quote.

ALTER PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @Name = REPLACE(@Name,'''','''''')
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This second case explains the fact that the use of parametrized query with stored procedure not always resolve the security flaws caused by sql injection.

=== Case 3: Parametrized query + Stored Procedure not vulnerable ===

It is possible to modify the way to execute the same query, using parametrized query in conjunction with stored procedures. By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStored_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section is the same of the example above.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);

In this section is used the SqlCommand class as above, but, the type of the SqlCommand is “StoredProcedure” , so the sql code is not provided directly, but there is a procedure inside the database that makes the job. This procedure is called USP_SearchUserByNameNotVuln and accept a Varchar(50) parameter called @Name.
The code of the stored is simply:

CREATE PROCEDURE [dbo].[USP_SearchUserByNameNotVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
SELECT
U.Name,
U.Surname,
U.Code
FROM
dbo.Users U
WHERE
U.Name LIKE '''%' + @Name + '%'''
END

Three steps for each parameter passed to the stored procedure are needed to use the SqlParameter class:

* Instantiate the parameter with the right name and type used in the stored procedure
* Assign the value (in this case the value given by the user in the textbox)
* Add the parameter to the SqlCommand

When the sql command is executed, the parameters will be replaced with values specified by the SqlParameter object.

In conclusion, this kind of query is not prone to sql injection, because it is not possibile to build ad hoc sql statements, due to the correct use of Stored Procedure and the SqlParameter class.

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

This section is the same of the example above.

=== Input validation ===

Another point that is important to consider is the validation of the input. For example in a context in which a user has to insert (or select) some data in (or from) the database let’s think about the worst case, that is a user that can digit anything and submit anything to the server. To avoid this the only choiche is to validate the user's input. Two strategies are possible:

1. White list

2. Black list

The first solution answers at the condition: "deny all, except what is explicitly signed in the list".
The second solution answers at the condition: "allow all, except what is explicitly signed in the list".

The best solution for the security of the application is try to implement a validation of the input based on the first case. This comes more simply with numeric input, range input or strings that follow a specific pattern (for example an e-mail or a date). It becomes more difficult for strings with a not specific pattern (for example strings inserted in a search engine) in which often only a solution based on a black list is reasonably possible.

In a Web Application, there are two kinds of input validation:

1. client validations

2. server validations

There are a couple of reasons to use both types of validation summarized in the following points:

* client validations increase performance (the application doesn't postback to the server) but cause a false sense of security (the validation can be bypassed intercepting and manipulating the client request).
* server validations make worse performance but increase the security, because the validation is made by the server.

In ASP.NET to realize these concepts there are the server web control Validators:

* RequiredFieldValidator
* CompareValidator
* RangeValidator
* RegularExpressionValidator
* CustomValidator

Technically these objects realize both type of validations: that is if the client support Javascript, the Validator uses first the client validation, and after that the page is validated on then server side too. If the client doesn't support Javascript, the validation is made only on the server side. In this manner the application validate the input in a progressive mode and the design of the application doesn't follow a '' "Minimum-Denominator-Multiplier" ''.

To explain the concept in code, it's possible to analyze the CustomValidator, that is the higher generalization because it's possible to use a personalized validation logic.

=== CustomValidator ===

We can think symply to a textbox with a button, like the example above, in which it gives the way to search all the suppliers with a specific code (a string of 16 char) For security reasons it is imagined that a specific user can only see the suppliers that have a code in which the first 4 character are "PFHG".

Any other string that doesn't match this pattern has to be exclude from the search (white list approach)

[[Image:owasp_bsp_net_2.jpg]]

The XML part of the page is like that:

<asp:Label ID="lblQuerySearch" runat="server" Text="Digit the first four numbers"></asp:Label>
<asp:TextBox ID="txtQuerySearch" Width="5em" runat="server"></asp:TextBox>
<asp:RequiredFieldValidator ID="RequiredFieldValidatorQuerySearch" runat="server" ErrorMessage="Required Code"
ControlToValidate="txtQuerySearch"></asp:RequiredFieldValidator>
<asp:CustomValidator ID="CustomValidatorQuerySearch" runat="server" ErrorMessage="Wrong code"
ControlToValidate="txtQuerySearch" OnServerValidate="ValidateCode"></asp:CustomValidator>

The control Label and Button are intuitive web controls.
It's clear to see that two Validator have been applied to the textbox whose ID is '' "txtQuerySearch" ''.
The Validators are:

* RequiredFieldValidator: we don't accept an empty textbox when we submit our request to the server
* CustomValidator: we would implement some custom logic to our textbox

In fact the CustomValidator tag has a particular event called "OnServerValidate" that we can hook to a custom callback function, whose code is executed on the server side.
For this example it's like that:

protected void ValidateCode(object source, ServerValidateEventArgs args)
{
try
{
string textToValidate = args.Value;
if (textToValidate.Equals("PFHG"))
args.IsValid = true;
else
args.IsValid = false;
}
catch (Exception ex)
{
args.IsValid = false;
}
}

The function handles the argument "arg" that brings the text inserted by the user.
If this text match with our pattern, the argument is valid and the server executes the code associated to the button, querying the database in the same manner seen above; however the code is now conditioned by the statement "if(Page.IsValid)".

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
if (Page.IsValid)
{
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByCode", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pCode = new SqlParameter("@Code", SqlDbType.VarChar, 4);
pCode.Value = txtQuerySearch.Text;
cmd.Parameters.Add(pCode);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}
}

This is only an example but the use of the Validators can be very important in all the contexts in which the protection of a database from malicious input is needed.

== .NET Preventing LDAP Injection ==

It’s not important here to explain how LDAP works. The focus is explain how it’s possible to avoid the injection of special character, that are responsible of a unpredictable behaviour of the LDAP server.
LDAP search are often made with a distinguished name (DN) and a filter. So if the user input is not properly validated, the user can manipulate the input to craft a malicious filter, to obtain more informations from the server.
LDAP search are made with string, so the best solution to analyze a string searching particular characters is a Regular Expression.
In this example there is the code associated to a event ButtonClick, and two TextBox called "txtUid" and "txtSn" are used to give input to the system

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);
if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}
LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;
try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}
}

''' First Section '''

string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);

The first section uses a Regular Expression, using the class “RegExStringValidator”, very useful to analyze a string.
The string can contain only alphanumeric characters, @, blank or dot.
Others characters different from the indicated subset are not allowed, according to the white list approach.

''' Second Section '''

if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}

In this section there is the code to check if the strings inserted in the textbox “txtUid” and “txtSn” match the rule of the RegExp or not. There is a try-catch block and the object method "Validate" is used to make the job. If the validation passes, the catch block is not processed.

''' Third Section '''

LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;

The third section is the place for the connection to the server.

''' Fourth Section '''

try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}

Finally it's made the request and the server make the response, giving the number of entries that found

== Web.config Encryption ==

Web.config (and others file with .config extension) could contain sensitive informations that should be protected. For a .NET Web Application tipically the parameters to acces to a database are stored in plain text, in a form like this:

<configuration>
<connectionStrings>
<add name="Connection_SQLServer2005" connectionString="Data Source=WIN2K3\SQLInstance; Initial Catalog=Exampledb;
User Id=user; Password=clgir3s2s;" providerName=""/>
</connectionStrings>
</configuration>

It's possible to notice:

* Name of the server machine
* Name of the instance of SQL Server
* Name of the database
* Username
* Password

Gaining the access to directory of the web application, these informations are freely accessible.
The solution to mantain the confidentiality is always one: encryption.
Because encryption is not costless, it's not a good choice to encrypt the Web.config in its totality. It's better to select only the sensitive informations, that often are stored in the "configuration" sections of the file.
In .NET there are two mode to encrypt configuration section:

* Coding with some classes of the Framework
* Using the command line tool "aspnet_regiis.exe" (located in %SystemRoot%\Microsoft.NET\Framework\versionNumber folder)

In both cases the encryption is potentially provided in three modes:

* Windows Data Protection API Provider (DPAPI)
* RSA Protected Configuration Provider
* Custom Provider

DPAPI is the simplest manner. It uses a machine (or user) level key storage, so it's possible to share the secret with all the applications of the machine or not. Additionally it uses an encryption mode based on the login of the user, storing the information in the registry, so no key creation needed. But if the application is deployed in a Web farm, the better is RSA protected configuration provider due to the ease with which RSA keys can be exported.
So it's confortable to use the command line tool "aspnet_regiis.exe" with RSA provider.
First thing it's necessary to create a key container, for the public key encryption; open the SDK command prompt of the Framework and digit:

aspnet_regiis.exe -pc keycontainer1

in this manner a file with public and private key is stored at the path
%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys
with a unique code. It's possible to recognize the creation's datetime. It's important to know that this file is protected by the NTFS ACL, so only the creator and the SYSTEM account can manipulate it.
So if the web application run with another account (for example MACHINENAME\ASPNET user), it's necessary to grant the read permission for the key container with the command:

aspnet_regiis -pa keycontainer1 MACHINENAME\ASPNET

On the other hand add these lines in the Web.Config:

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<configProtectedData>
<providers>
<add name="NameProvider1"
type="System.Configuration.RsaProtectedConfigurationProvider, System.Configuration, Version=2.0.0.0,Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a,processorArchitecture=MSIL"
UseMachineContainer="true"
KeyContainerName="keycontainer1"
/>
</providers>
</configProtectedData>

in which there are references of the name of the provider (NameProvider1) that is based on RSA and key container (keycontainer1) used by the provider.
Now it's possible to encrypt the "connectionStrings" section using the physical path of the directory storing the web.config (and the the web application):

aspnet_regiis -pef connectionStrings C:\Project\BackendSecProj -prov NameProvider1

The result is that the connectionStrings section is comparable to:

<connectionStrings configProtectionProvider="NameProvider1">
<EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<KeyName>Rsa Key</KeyName>
</KeyInfo>
<CipherData>
<CipherValue>XV8DCEfUymYphQaL5GTqCQGhrNoED+/rIKNXS3l44exGiQWx2FH0Rq.....</CipherValue>
</CipherData>
</EncryptedKey>
</KeyInfo>
</EncryptedData>
</connectionStrings>

The application that must access to this section do automatically the decryption, due the read permission for the key container granted to the running user.
In any case it's always possible to decrypt the section with:

aspnet_regiis -pdf connectionStrings C:\Project\BackendSecProj

= References =

* http://msdn.microsoft.com/en-us/library/default.aspx
* http://msdn.microsoft.com/en-us/library/6759sth4.aspx
* http://directoryprogramming.net/
* http://msdn.microsoft.com/en-us/library/system.configuration.regexstringvalidator.aspx
* http://www.ietf.org/rfc/rfc2254.txt
* http://msdn.microsoft.com/en-us/library/az24scfc(VS.80).aspx
* http://msdn.microsoft.com/en-us/library/k6h9cz8h(VS.80).aspx
* http://msdn.microsoft.com/en-us/library/dtkwfdky(VS.80).aspx

OWASP Backend Security Project .NET Security Programming

2008-07-08T21:35:59Z

GPederzini: /* References */

= Overview =

In this section are explained the best solution to avoid two of the most dangerous vulnerabilities of web applications, the sql injection and ldap injection on .NET programming

It will be analized the interactions between a web application written in C# in ASP.NET technology, .NET Framework 2.0 and two kinds of data provider: a SQL Server 2005 data provider and an OpenLdap Server data provider.

For the first interaction imagine a database called “ExampleDB” in which there are some tables. One of these tables is “Users”. From a
web application is possible to query the database to extract information about the users through their name.

For the second interaction imagine an Ldap server called “ExampleLDAP”.

The project is simple and is made by some .aspx page with a textbox in which is possible to insert the name of the user and the program will return the information, reading from ExampleDB (or ExampleLDAP).
It's not important to specify how it's possible to create an aspx page So the focus is on the code that we have to write to interact with the server data provider.

= Description =

== .NET Preventing SQL Injection ==

Two approaches are likely: inline query or stored procedure.

[[Image:owasp_bsp_net_1.jpg]]

=== Case 1: Inline query ===

Inline queries are the queries in which is possible to compose a sql statement through string concatenation. By clicking on the first button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryInline_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%"
+ txtQueryInline.Text + "%'", sqlConnection);
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section of code provides the sqlConnection, reading the connectionString from the Web.Config file. This is an important task for the application because it represents the entry point to the database, the credentials of the user that can authenticate on the ExampleDB.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%" +
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;

In this section is used the SqlCommand class, in which is written the sql code, concatenating with the text to search. The type of the SqlCommand is “Text”, so it's clear that the sql code is provided directly. This code is prone to sql injection, because we can manipulate the statement, injecting in the textbox, for example, the string:

'' '; sql statement -- ''

where sql statement is any sql code (it is possible to drop tables, add users, reconfigure the xp_cmdshell, etc.)

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

The third section is useful to represent the result set of the query. It uses the ADO.NET “Dataset”, and an intermediate class called SqlDataAdapter, that adapts the sql data in a form that can be used by the Dataset Object.

It is possible to improve this query, using the second form of interaction that make use of a stored procedure

=== Case 2: Parametrized query + Stored Procedure vulnerable ===

By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStoredVuln_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStoredVuln.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

CREATE PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This kind of stored procedure are not rare. In this case is possible to compose the statement in many ways using parameters, function and so on.

Altough it is a parametrized query with a stored procedure, as the code shows, it is possible to inject the same string

'' '; sql statement -- ''

to inject a sql statement. Using the SQL Server function REPLACE, it is possible to “patch” the problem without rewrite the store procedure, replacing all the single quote with a couple of single quote.

ALTER PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @Name = REPLACE(@Name,'''','''''')
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This second case explains the fact that the use of parametrized query with stored procedure not always resolve the security flaws caused by sql injection.

=== Case 3: Parametrized query + Stored Procedure not vulnerable ===

It is possible to modify the way to execute the same query, using parametrized query in conjunction with stored procedures. By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStored_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section is the same of the example above.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);

In this section is used the SqlCommand class as above, but, the type of the SqlCommand is “StoredProcedure” , so the sql code is not provided directly, but there is a procedure inside the database that makes the job. This procedure is called USP_SearchUserByNameNotVuln and accept a Varchar(50) parameter called @Name.
The code of the stored is simply:

CREATE PROCEDURE [dbo].[USP_SearchUserByNameNotVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
SELECT
U.Name,
U.Surname,
U.Code
FROM
dbo.Users U
WHERE
U.Name LIKE '''%' + @Name + '%'''
END

Three steps for each parameter passed to the stored procedure are needed to use the SqlParameter class:

* Instantiate the parameter with the right name and type used in the stored procedure
* Assign the value (in this case the value given by the user in the textbox)
* Add the parameter to the SqlCommand

When the sql command is executed, the parameters will be replaced with values specified by the SqlParameter object.

In conclusion, this kind of query is not prone to sql injection, because it is not possibile to build ad hoc sql statements, due to the correct use of Stored Procedure and the SqlParameter class.

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

This section is the same of the example above.

=== Input validation ===

Another point that is important to consider is the validation of the input. For example in a context in which a user has to insert (or select) some data in (or from) the database let’s think about the worst case, that is a user that can digit anything and submit anything to the server. To avoid this the only choiche is to validate the user's input. Two strategies are possible:

1. White list

2. Black list

The first solution answers at the condition: "deny all, except what is explicitly signed in the list".
The second solution answers at the condition: "allow all, except what is explicitly signed in the list".

The best solution for the security of the application is try to implement a validation of the input based on the first case. This comes more simply with numeric input, range input or strings that follow a specific pattern (for example an e-mail or a date). It becomes more difficult for strings with a not specific pattern (for example strings inserted in a search engine) in which often only a solution based on a black list is reasonably possible.

In a Web Application, there are two kinds of input validation:

1. client validations

2. server validations

There are a couple of reasons to use both types of validation summarized in the following points:

* client validations increase performance (the application doesn't postback to the server) but cause a false sense of security (the validation can be bypassed intercepting and manipulating the client request).
* server validations make worse performance but increase the security, because the validation is made by the server.

In ASP.NET to realize these concepts there are the server web control Validators:

* RequiredFieldValidator
* CompareValidator
* RangeValidator
* RegularExpressionValidator
* CustomValidator

Technically these objects realize both type of validations: that is if the client support Javascript, the Validator uses first the client validation, and after that the page is validated on then server side too. If the client doesn't support Javascript, the validation is made only on the server side. In this manner the application validate the input in a progressive mode and the design of the application doesn't follow a '' "Minimum-Denominator-Multiplier" ''.

To explain the concept in code, it's possible to analyze the CustomValidator, that is the higher generalization because it's possible to use a personalized validation logic.

=== CustomValidator ===

We can think symply to a textbox with a button, like the example above, in which it gives the way to search all the suppliers with a specific code (a string of 16 char) For security reasons it is imagined that a specific user can only see the suppliers that have a code in which the first 4 character are "PFHG".

Any other string that doesn't match this pattern has to be exclude from the search (white list approach)

[[Image:owasp_bsp_net_2.jpg]]

The XML part of the page is like that:

<asp:Label ID="lblQuerySearch" runat="server" Text="Digit the first four numbers"></asp:Label>
<asp:TextBox ID="txtQuerySearch" Width="5em" runat="server"></asp:TextBox>
<asp:RequiredFieldValidator ID="RequiredFieldValidatorQuerySearch" runat="server" ErrorMessage="Required Code"
ControlToValidate="txtQuerySearch"></asp:RequiredFieldValidator>
<asp:CustomValidator ID="CustomValidatorQuerySearch" runat="server" ErrorMessage="Wrong code"
ControlToValidate="txtQuerySearch" OnServerValidate="ValidateCode"></asp:CustomValidator>

The control Label and Button are intuitive web controls.
It's clear to see that two Validator have been applied to the textbox whose ID is '' "txtQuerySearch" ''.
The Validators are:

* RequiredFieldValidator: we don't accept an empty textbox when we submit our request to the server
* CustomValidator: we would implement some custom logic to our textbox

In fact the CustomValidator tag has a particular event called "OnServerValidate" that we can hook to a custom callback function, whose code is executed on the server side.
For this example it's like that:

protected void ValidateCode(object source, ServerValidateEventArgs args)
{
try
{
string textToValidate = args.Value;
if (textToValidate.Equals("PFHG"))
args.IsValid = true;
else
args.IsValid = false;
}
catch (Exception ex)
{
args.IsValid = false;
}
}

The function handles the argument "arg" that brings the text inserted by the user.
If this text match with our pattern, the argument is valid and the server executes the code associated to the button, querying the database in the same manner seen above; however the code is now conditioned by the statement "if(Page.IsValid)".

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
if (Page.IsValid)
{
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByCode", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pCode = new SqlParameter("@Code", SqlDbType.VarChar, 4);
pCode.Value = txtQuerySearch.Text;
cmd.Parameters.Add(pCode);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}
}

This is only an example but the use of the Validators can be very important in all the contexts in which the protection of a database from malicious input is needed.

== .NET Preventing LDAP Injection ==

It’s not important here to explain how LDAP works. The focus is explain how it’s possible to avoid the injection of special character, that are responsible of a unpredictable behaviour of the LDAP server.
LDAP search are often made with a distinguished name (DN) and a filter. So if the user input is not properly validated, the user can manipulate the input to craft a malicious filter, to obtain more informations from the server.
LDAP search are made with string, so the best solution to analyze a string searching particular characters is a Regular Expression.
In this example there is the code associated to a event ButtonClick, and two TextBox called "txtUid" and "txtSn" are used to give input to the system

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);
if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}
LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;
try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}
}

''' First Section '''

string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);

The first section uses a Regular Expression, using the class “RegExStringValidator”, very useful to analyze a string.
The string can contain only alphanumeric characters, @, blank or dot.
Others characters different from the indicated subset are not allowed, according to the white list approach.

''' Second Section '''

if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}

In this section there is the code to check if the strings inserted in the textbox “txtUid” and “txtSn” match the rule of the RegExp or not. There is a try-catch block and the object method "Validate" is used to make the job. If the validation passes, the catch block is not processed.

''' Third Section '''

LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;

The third section is the place for the connection to the server.

''' Fourth Section '''

try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}

Finally it's made the request and the server make the response, giving the number of entries that found

== Web.config Encryption ==

Web.config (and others file with .config extension) could contain sensitive informations that should be protected. For a .NET Web Application tipically the parameters to acces to a database are stored in plain text, in a form like this:

<configuration>
<connectionStrings>
<add name="Connection_SQLServer2005" connectionString="Data Source=WIN2K3\SQLInstance; Initial Catalog=Exampledb; User Id=user;
Password=clgir3s2s;" providerName=""/>
</connectionStrings>
</configuration>

It's possible to notice:

* Name of the server machine
* Name of the instance of SQL Server
* Name of the database
* Username
* Password

Gaining the access to directory of the web application, these informations are freely accessible.
The solution to mantain the confidentiality is always one: encryption.
Because encryption is not costless, it's not a good choice to encrypt the Web.config in its totality. It's better to select only the sensitive informations, that often are stored in the "configuration" sections of the file.
In .NET there are two mode to encrypt configuration section:

* Coding with some classes of the Framework
* Using the command line tool "aspnet_regiis.exe" (located in %SystemRoot%\Microsoft.NET\Framework\versionNumber folder)

In both cases the encryption is potentially provided in three modes:

* Windows Data Protection API Provider (DPAPI)
* RSA Protected Configuration Provider
* Custom Provider

DPAPI is the simplest manner. It uses a machine (or user) level key storage, so it's possible to share the secret with all the applications of the machine or not. Additionally it uses an encryption mode based on the login of the user, storing the information in the registry, so no key creation needed. But if the application is deployed in a Web farm, the better is RSA protected configuration provider due to the ease with which RSA keys can be exported.
So it's confortable to use the command line tool "aspnet_regiis.exe" with RSA provider.
First thing it's necessary to create a key container, for the public key encryption; open the SDK command prompt of the Framework and digit:

aspnet_regiis.exe -pc keycontainer1

in this manner a file with public and private key is stored at the path
%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys
with a unique code. It's possible to recognize the creation's datetime. It's important to know that this file is protected by the NTFS ACL, so only the creator and the SYSTEM account can manipulate it.
So if the web application run with another account (for example MACHINENAME\ASPNET user), it's necessary to grant the read permission for the key container with the command:

aspnet_regiis -pa keycontainer1 MACHINENAME\ASPNET

On the other hand add these lines in the Web.Config:

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<configProtectedData>
<providers>
<add name="NameProvider1"
type="System.Configuration.RsaProtectedConfigurationProvider, System.Configuration, Version=2.0.0.0,Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a,processorArchitecture=MSIL"
UseMachineContainer="true"
KeyContainerName="keycontainer1"
/>
</providers>
</configProtectedData>

in which there are references of the name of the provider (NameProvider1) that is based on RSA and key container (keycontainer1) used by the provider.
Now it's possible to encrypt the "connectionStrings" section using the physical path of the directory storing the web.config (and the the web application):

aspnet_regiis -pef connectionStrings C:\Project\BackendSecProj -prov NameProvider1

The result is that the connectionStrings section is comparable to:

<connectionStrings configProtectionProvider="NameProvider1">
<EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<KeyName>Rsa Key</KeyName>
</KeyInfo>
<CipherData>
<CipherValue>XV8DCEfUymYphQaL5GTqCQGhrNoED+/rIKNXS3l44exGiQWx2FH0Rq.....</CipherValue>
</CipherData>
</EncryptedKey>
</KeyInfo>
</EncryptedData>
</connectionStrings>

The application that must access to this section do automatically the decryption, due the read permission for the key container granted to the running user.
In any case it's always possible to decrypt the section with:

aspnet_regiis -pdf connectionStrings C:\Project\BackendSecProj

= References =

* http://msdn.microsoft.com/en-us/library/default.aspx
* http://msdn.microsoft.com/en-us/library/6759sth4.aspx
* http://directoryprogramming.net/
* http://msdn.microsoft.com/en-us/library/system.configuration.regexstringvalidator.aspx
* http://www.ietf.org/rfc/rfc2254.txt
* http://msdn.microsoft.com/en-us/library/az24scfc(VS.80).aspx
* http://msdn.microsoft.com/en-us/library/k6h9cz8h(VS.80).aspx
* http://msdn.microsoft.com/en-us/library/dtkwfdky(VS.80).aspx

OWASP Backend Security Project .NET Security Programming

2008-07-08T21:35:43Z

GPederzini: /* References */

= Overview =

In this section are explained the best solution to avoid two of the most dangerous vulnerabilities of web applications, the sql injection and ldap injection on .NET programming

It will be analized the interactions between a web application written in C# in ASP.NET technology, .NET Framework 2.0 and two kinds of data provider: a SQL Server 2005 data provider and an OpenLdap Server data provider.

For the first interaction imagine a database called “ExampleDB” in which there are some tables. One of these tables is “Users”. From a
web application is possible to query the database to extract information about the users through their name.

For the second interaction imagine an Ldap server called “ExampleLDAP”.

The project is simple and is made by some .aspx page with a textbox in which is possible to insert the name of the user and the program will return the information, reading from ExampleDB (or ExampleLDAP).
It's not important to specify how it's possible to create an aspx page So the focus is on the code that we have to write to interact with the server data provider.

= Description =

== .NET Preventing SQL Injection ==

Two approaches are likely: inline query or stored procedure.

[[Image:owasp_bsp_net_1.jpg]]

=== Case 1: Inline query ===

Inline queries are the queries in which is possible to compose a sql statement through string concatenation. By clicking on the first button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryInline_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%"
+ txtQueryInline.Text + "%'", sqlConnection);
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section of code provides the sqlConnection, reading the connectionString from the Web.Config file. This is an important task for the application because it represents the entry point to the database, the credentials of the user that can authenticate on the ExampleDB.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%" +
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;

In this section is used the SqlCommand class, in which is written the sql code, concatenating with the text to search. The type of the SqlCommand is “Text”, so it's clear that the sql code is provided directly. This code is prone to sql injection, because we can manipulate the statement, injecting in the textbox, for example, the string:

'' '; sql statement -- ''

where sql statement is any sql code (it is possible to drop tables, add users, reconfigure the xp_cmdshell, etc.)

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

The third section is useful to represent the result set of the query. It uses the ADO.NET “Dataset”, and an intermediate class called SqlDataAdapter, that adapts the sql data in a form that can be used by the Dataset Object.

It is possible to improve this query, using the second form of interaction that make use of a stored procedure

=== Case 2: Parametrized query + Stored Procedure vulnerable ===

By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStoredVuln_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStoredVuln.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

CREATE PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This kind of stored procedure are not rare. In this case is possible to compose the statement in many ways using parameters, function and so on.

Altough it is a parametrized query with a stored procedure, as the code shows, it is possible to inject the same string

'' '; sql statement -- ''

to inject a sql statement. Using the SQL Server function REPLACE, it is possible to “patch” the problem without rewrite the store procedure, replacing all the single quote with a couple of single quote.

ALTER PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @Name = REPLACE(@Name,'''','''''')
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This second case explains the fact that the use of parametrized query with stored procedure not always resolve the security flaws caused by sql injection.

=== Case 3: Parametrized query + Stored Procedure not vulnerable ===

It is possible to modify the way to execute the same query, using parametrized query in conjunction with stored procedures. By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStored_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section is the same of the example above.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);

In this section is used the SqlCommand class as above, but, the type of the SqlCommand is “StoredProcedure” , so the sql code is not provided directly, but there is a procedure inside the database that makes the job. This procedure is called USP_SearchUserByNameNotVuln and accept a Varchar(50) parameter called @Name.
The code of the stored is simply:

CREATE PROCEDURE [dbo].[USP_SearchUserByNameNotVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
SELECT
U.Name,
U.Surname,
U.Code
FROM
dbo.Users U
WHERE
U.Name LIKE '''%' + @Name + '%'''
END

Three steps for each parameter passed to the stored procedure are needed to use the SqlParameter class:

* Instantiate the parameter with the right name and type used in the stored procedure
* Assign the value (in this case the value given by the user in the textbox)
* Add the parameter to the SqlCommand

When the sql command is executed, the parameters will be replaced with values specified by the SqlParameter object.

In conclusion, this kind of query is not prone to sql injection, because it is not possibile to build ad hoc sql statements, due to the correct use of Stored Procedure and the SqlParameter class.

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

This section is the same of the example above.

=== Input validation ===

Another point that is important to consider is the validation of the input. For example in a context in which a user has to insert (or select) some data in (or from) the database let’s think about the worst case, that is a user that can digit anything and submit anything to the server. To avoid this the only choiche is to validate the user's input. Two strategies are possible:

1. White list

2. Black list

The first solution answers at the condition: "deny all, except what is explicitly signed in the list".
The second solution answers at the condition: "allow all, except what is explicitly signed in the list".

The best solution for the security of the application is try to implement a validation of the input based on the first case. This comes more simply with numeric input, range input or strings that follow a specific pattern (for example an e-mail or a date). It becomes more difficult for strings with a not specific pattern (for example strings inserted in a search engine) in which often only a solution based on a black list is reasonably possible.

In a Web Application, there are two kinds of input validation:

1. client validations

2. server validations

There are a couple of reasons to use both types of validation summarized in the following points:

* client validations increase performance (the application doesn't postback to the server) but cause a false sense of security (the validation can be bypassed intercepting and manipulating the client request).
* server validations make worse performance but increase the security, because the validation is made by the server.

In ASP.NET to realize these concepts there are the server web control Validators:

* RequiredFieldValidator
* CompareValidator
* RangeValidator
* RegularExpressionValidator
* CustomValidator

Technically these objects realize both type of validations: that is if the client support Javascript, the Validator uses first the client validation, and after that the page is validated on then server side too. If the client doesn't support Javascript, the validation is made only on the server side. In this manner the application validate the input in a progressive mode and the design of the application doesn't follow a '' "Minimum-Denominator-Multiplier" ''.

To explain the concept in code, it's possible to analyze the CustomValidator, that is the higher generalization because it's possible to use a personalized validation logic.

=== CustomValidator ===

We can think symply to a textbox with a button, like the example above, in which it gives the way to search all the suppliers with a specific code (a string of 16 char) For security reasons it is imagined that a specific user can only see the suppliers that have a code in which the first 4 character are "PFHG".

Any other string that doesn't match this pattern has to be exclude from the search (white list approach)

[[Image:owasp_bsp_net_2.jpg]]

The XML part of the page is like that:

<asp:Label ID="lblQuerySearch" runat="server" Text="Digit the first four numbers"></asp:Label>
<asp:TextBox ID="txtQuerySearch" Width="5em" runat="server"></asp:TextBox>
<asp:RequiredFieldValidator ID="RequiredFieldValidatorQuerySearch" runat="server" ErrorMessage="Required Code"
ControlToValidate="txtQuerySearch"></asp:RequiredFieldValidator>
<asp:CustomValidator ID="CustomValidatorQuerySearch" runat="server" ErrorMessage="Wrong code"
ControlToValidate="txtQuerySearch" OnServerValidate="ValidateCode"></asp:CustomValidator>

The control Label and Button are intuitive web controls.
It's clear to see that two Validator have been applied to the textbox whose ID is '' "txtQuerySearch" ''.
The Validators are:

* RequiredFieldValidator: we don't accept an empty textbox when we submit our request to the server
* CustomValidator: we would implement some custom logic to our textbox

In fact the CustomValidator tag has a particular event called "OnServerValidate" that we can hook to a custom callback function, whose code is executed on the server side.
For this example it's like that:

protected void ValidateCode(object source, ServerValidateEventArgs args)
{
try
{
string textToValidate = args.Value;
if (textToValidate.Equals("PFHG"))
args.IsValid = true;
else
args.IsValid = false;
}
catch (Exception ex)
{
args.IsValid = false;
}
}

The function handles the argument "arg" that brings the text inserted by the user.
If this text match with our pattern, the argument is valid and the server executes the code associated to the button, querying the database in the same manner seen above; however the code is now conditioned by the statement "if(Page.IsValid)".

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
if (Page.IsValid)
{
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByCode", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pCode = new SqlParameter("@Code", SqlDbType.VarChar, 4);
pCode.Value = txtQuerySearch.Text;
cmd.Parameters.Add(pCode);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}
}

This is only an example but the use of the Validators can be very important in all the contexts in which the protection of a database from malicious input is needed.

== .NET Preventing LDAP Injection ==

It’s not important here to explain how LDAP works. The focus is explain how it’s possible to avoid the injection of special character, that are responsible of a unpredictable behaviour of the LDAP server.
LDAP search are often made with a distinguished name (DN) and a filter. So if the user input is not properly validated, the user can manipulate the input to craft a malicious filter, to obtain more informations from the server.
LDAP search are made with string, so the best solution to analyze a string searching particular characters is a Regular Expression.
In this example there is the code associated to a event ButtonClick, and two TextBox called "txtUid" and "txtSn" are used to give input to the system

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);
if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}
LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;
try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}
}

''' First Section '''

string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);

The first section uses a Regular Expression, using the class “RegExStringValidator”, very useful to analyze a string.
The string can contain only alphanumeric characters, @, blank or dot.
Others characters different from the indicated subset are not allowed, according to the white list approach.

''' Second Section '''

if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}

In this section there is the code to check if the strings inserted in the textbox “txtUid” and “txtSn” match the rule of the RegExp or not. There is a try-catch block and the object method "Validate" is used to make the job. If the validation passes, the catch block is not processed.

''' Third Section '''

LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;

The third section is the place for the connection to the server.

''' Fourth Section '''

try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}

Finally it's made the request and the server make the response, giving the number of entries that found

== Web.config Encryption ==

Web.config (and others file with .config extension) could contain sensitive informations that should be protected. For a .NET Web Application tipically the parameters to acces to a database are stored in plain text, in a form like this:

<configuration>
<connectionStrings>
<add name="Connection_SQLServer2005" connectionString="Data Source=WIN2K3\SQLInstance; Initial Catalog=Exampledb; User Id=user;
Password=clgir3s2s;" providerName=""/>
</connectionStrings>
</configuration>

It's possible to notice:

* Name of the server machine
* Name of the instance of SQL Server
* Name of the database
* Username
* Password

Gaining the access to directory of the web application, these informations are freely accessible.
The solution to mantain the confidentiality is always one: encryption.
Because encryption is not costless, it's not a good choice to encrypt the Web.config in its totality. It's better to select only the sensitive informations, that often are stored in the "configuration" sections of the file.
In .NET there are two mode to encrypt configuration section:

* Coding with some classes of the Framework
* Using the command line tool "aspnet_regiis.exe" (located in %SystemRoot%\Microsoft.NET\Framework\versionNumber folder)

In both cases the encryption is potentially provided in three modes:

* Windows Data Protection API Provider (DPAPI)
* RSA Protected Configuration Provider
* Custom Provider

DPAPI is the simplest manner. It uses a machine (or user) level key storage, so it's possible to share the secret with all the applications of the machine or not. Additionally it uses an encryption mode based on the login of the user, storing the information in the registry, so no key creation needed. But if the application is deployed in a Web farm, the better is RSA protected configuration provider due to the ease with which RSA keys can be exported.
So it's confortable to use the command line tool "aspnet_regiis.exe" with RSA provider.
First thing it's necessary to create a key container, for the public key encryption; open the SDK command prompt of the Framework and digit:

aspnet_regiis.exe -pc keycontainer1

in this manner a file with public and private key is stored at the path
%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys
with a unique code. It's possible to recognize the creation's datetime. It's important to know that this file is protected by the NTFS ACL, so only the creator and the SYSTEM account can manipulate it.
So if the web application run with another account (for example MACHINENAME\ASPNET user), it's necessary to grant the read permission for the key container with the command:

aspnet_regiis -pa keycontainer1 MACHINENAME\ASPNET

On the other hand add these lines in the Web.Config:

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<configProtectedData>
<providers>
<add name="NameProvider1"
type="System.Configuration.RsaProtectedConfigurationProvider, System.Configuration, Version=2.0.0.0,Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a,processorArchitecture=MSIL"
UseMachineContainer="true"
KeyContainerName="keycontainer1"
/>
</providers>
</configProtectedData>

in which there are references of the name of the provider (NameProvider1) that is based on RSA and key container (keycontainer1) used by the provider.
Now it's possible to encrypt the "connectionStrings" section using the physical path of the directory storing the web.config (and the the web application):

aspnet_regiis -pef connectionStrings C:\Project\BackendSecProj -prov NameProvider1

The result is that the connectionStrings section is comparable to:

<connectionStrings configProtectionProvider="NameProvider1">
<EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<KeyName>Rsa Key</KeyName>
</KeyInfo>
<CipherData>
<CipherValue>XV8DCEfUymYphQaL5GTqCQGhrNoED+/rIKNXS3l44exGiQWx2FH0Rq.....</CipherValue>
</CipherData>
</EncryptedKey>
</KeyInfo>
</EncryptedData>
</connectionStrings>

The application that must access to this section do automatically the decryption, due the read permission for the key container granted to the running user.
In any case it's always possible to decrypt the section with:

aspnet_regiis -pdf connectionStrings C:\Project\BackendSecProj

= References =

* http://msdn.microsoft.com/en-us/library/default.aspx
* http://msdn.microsoft.com/en-us/library/6759sth4.aspx
* http://directoryprogramming.net/
* http://msdn.microsoft.com/en-us/library/system.configuration.regexstringvalidator.aspx
* http://www.ietf.org/rfc/rfc2254.txt
* http://msdn.microsoft.com/en-us/library/az24scfc(VS.80).aspx
* http://msdn.microsoft.com/en-us/library/k6h9cz8h(VS.80).aspx
* http://msdn.microsoft.com/en-us/library/dtkwfdky(VS.80).aspx
* http://blogs.vertigosoftware.com/snyholm/archive/2005/12/16/1746.aspx

OWASP Backend Security Project .NET Security Programming

2008-07-08T21:29:21Z

GPederzini: /* References */

= Overview =

In this section are explained the best solution to avoid two of the most dangerous vulnerabilities of web applications, the sql injection and ldap injection on .NET programming

It will be analized the interactions between a web application written in C# in ASP.NET technology, .NET Framework 2.0 and two kinds of data provider: a SQL Server 2005 data provider and an OpenLdap Server data provider.

For the first interaction imagine a database called “ExampleDB” in which there are some tables. One of these tables is “Users”. From a
web application is possible to query the database to extract information about the users through their name.

For the second interaction imagine an Ldap server called “ExampleLDAP”.

The project is simple and is made by some .aspx page with a textbox in which is possible to insert the name of the user and the program will return the information, reading from ExampleDB (or ExampleLDAP).
It's not important to specify how it's possible to create an aspx page So the focus is on the code that we have to write to interact with the server data provider.

= Description =

== .NET Preventing SQL Injection ==

Two approaches are likely: inline query or stored procedure.

[[Image:owasp_bsp_net_1.jpg]]

=== Case 1: Inline query ===

Inline queries are the queries in which is possible to compose a sql statement through string concatenation. By clicking on the first button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryInline_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%"
+ txtQueryInline.Text + "%'", sqlConnection);
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section of code provides the sqlConnection, reading the connectionString from the Web.Config file. This is an important task for the application because it represents the entry point to the database, the credentials of the user that can authenticate on the ExampleDB.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%" +
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;

In this section is used the SqlCommand class, in which is written the sql code, concatenating with the text to search. The type of the SqlCommand is “Text”, so it's clear that the sql code is provided directly. This code is prone to sql injection, because we can manipulate the statement, injecting in the textbox, for example, the string:

'' '; sql statement -- ''

where sql statement is any sql code (it is possible to drop tables, add users, reconfigure the xp_cmdshell, etc.)

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

The third section is useful to represent the result set of the query. It uses the ADO.NET “Dataset”, and an intermediate class called SqlDataAdapter, that adapts the sql data in a form that can be used by the Dataset Object.

It is possible to improve this query, using the second form of interaction that make use of a stored procedure

=== Case 2: Parametrized query + Stored Procedure vulnerable ===

By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStoredVuln_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStoredVuln.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

CREATE PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This kind of stored procedure are not rare. In this case is possible to compose the statement in many ways using parameters, function and so on.

Altough it is a parametrized query with a stored procedure, as the code shows, it is possible to inject the same string

'' '; sql statement -- ''

to inject a sql statement. Using the SQL Server function REPLACE, it is possible to “patch” the problem without rewrite the store procedure, replacing all the single quote with a couple of single quote.

ALTER PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @Name = REPLACE(@Name,'''','''''')
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This second case explains the fact that the use of parametrized query with stored procedure not always resolve the security flaws caused by sql injection.

=== Case 3: Parametrized query + Stored Procedure not vulnerable ===

It is possible to modify the way to execute the same query, using parametrized query in conjunction with stored procedures. By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStored_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section is the same of the example above.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);

In this section is used the SqlCommand class as above, but, the type of the SqlCommand is “StoredProcedure” , so the sql code is not provided directly, but there is a procedure inside the database that makes the job. This procedure is called USP_SearchUserByNameNotVuln and accept a Varchar(50) parameter called @Name.
The code of the stored is simply:

CREATE PROCEDURE [dbo].[USP_SearchUserByNameNotVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
SELECT
U.Name,
U.Surname,
U.Code
FROM
dbo.Users U
WHERE
U.Name LIKE '''%' + @Name + '%'''
END

Three steps for each parameter passed to the stored procedure are needed to use the SqlParameter class:

* Instantiate the parameter with the right name and type used in the stored procedure
* Assign the value (in this case the value given by the user in the textbox)
* Add the parameter to the SqlCommand

When the sql command is executed, the parameters will be replaced with values specified by the SqlParameter object.

In conclusion, this kind of query is not prone to sql injection, because it is not possibile to build ad hoc sql statements, due to the correct use of Stored Procedure and the SqlParameter class.

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

This section is the same of the example above.

=== Input validation ===

Another point that is important to consider is the validation of the input. For example in a context in which a user has to insert (or select) some data in (or from) the database let’s think about the worst case, that is a user that can digit anything and submit anything to the server. To avoid this the only choiche is to validate the user's input. Two strategies are possible:

1. White list

2. Black list

The first solution answers at the condition: "deny all, except what is explicitly signed in the list".
The second solution answers at the condition: "allow all, except what is explicitly signed in the list".

The best solution for the security of the application is try to implement a validation of the input based on the first case. This comes more simply with numeric input, range input or strings that follow a specific pattern (for example an e-mail or a date). It becomes more difficult for strings with a not specific pattern (for example strings inserted in a search engine) in which often only a solution based on a black list is reasonably possible.

In a Web Application, there are two kinds of input validation:

1. client validations

2. server validations

There are a couple of reasons to use both types of validation summarized in the following points:

* client validations increase performance (the application doesn't postback to the server) but cause a false sense of security (the validation can be bypassed intercepting and manipulating the client request).
* server validations make worse performance but increase the security, because the validation is made by the server.

In ASP.NET to realize these concepts there are the server web control Validators:

* RequiredFieldValidator
* CompareValidator
* RangeValidator
* RegularExpressionValidator
* CustomValidator

Technically these objects realize both type of validations: that is if the client support Javascript, the Validator uses first the client validation, and after that the page is validated on then server side too. If the client doesn't support Javascript, the validation is made only on the server side. In this manner the application validate the input in a progressive mode and the design of the application doesn't follow a '' "Minimum-Denominator-Multiplier" ''.

To explain the concept in code, it's possible to analyze the CustomValidator, that is the higher generalization because it's possible to use a personalized validation logic.

=== CustomValidator ===

We can think symply to a textbox with a button, like the example above, in which it gives the way to search all the suppliers with a specific code (a string of 16 char) For security reasons it is imagined that a specific user can only see the suppliers that have a code in which the first 4 character are "PFHG".

Any other string that doesn't match this pattern has to be exclude from the search (white list approach)

[[Image:owasp_bsp_net_2.jpg]]

The XML part of the page is like that:

<asp:Label ID="lblQuerySearch" runat="server" Text="Digit the first four numbers"></asp:Label>
<asp:TextBox ID="txtQuerySearch" Width="5em" runat="server"></asp:TextBox>
<asp:RequiredFieldValidator ID="RequiredFieldValidatorQuerySearch" runat="server" ErrorMessage="Required Code"
ControlToValidate="txtQuerySearch"></asp:RequiredFieldValidator>
<asp:CustomValidator ID="CustomValidatorQuerySearch" runat="server" ErrorMessage="Wrong code"
ControlToValidate="txtQuerySearch" OnServerValidate="ValidateCode"></asp:CustomValidator>

The control Label and Button are intuitive web controls.
It's clear to see that two Validator have been applied to the textbox whose ID is '' "txtQuerySearch" ''.
The Validators are:

* RequiredFieldValidator: we don't accept an empty textbox when we submit our request to the server
* CustomValidator: we would implement some custom logic to our textbox

In fact the CustomValidator tag has a particular event called "OnServerValidate" that we can hook to a custom callback function, whose code is executed on the server side.
For this example it's like that:

protected void ValidateCode(object source, ServerValidateEventArgs args)
{
try
{
string textToValidate = args.Value;
if (textToValidate.Equals("PFHG"))
args.IsValid = true;
else
args.IsValid = false;
}
catch (Exception ex)
{
args.IsValid = false;
}
}

The function handles the argument "arg" that brings the text inserted by the user.
If this text match with our pattern, the argument is valid and the server executes the code associated to the button, querying the database in the same manner seen above; however the code is now conditioned by the statement "if(Page.IsValid)".

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
if (Page.IsValid)
{
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByCode", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pCode = new SqlParameter("@Code", SqlDbType.VarChar, 4);
pCode.Value = txtQuerySearch.Text;
cmd.Parameters.Add(pCode);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}
}

This is only an example but the use of the Validators can be very important in all the contexts in which the protection of a database from malicious input is needed.

== .NET Preventing LDAP Injection ==

It’s not important here to explain how LDAP works. The focus is explain how it’s possible to avoid the injection of special character, that are responsible of a unpredictable behaviour of the LDAP server.
LDAP search are often made with a distinguished name (DN) and a filter. So if the user input is not properly validated, the user can manipulate the input to craft a malicious filter, to obtain more informations from the server.
LDAP search are made with string, so the best solution to analyze a string searching particular characters is a Regular Expression.
In this example there is the code associated to a event ButtonClick, and two TextBox called "txtUid" and "txtSn" are used to give input to the system

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);
if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}
LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;
try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}
}

''' First Section '''

string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);

The first section uses a Regular Expression, using the class “RegExStringValidator”, very useful to analyze a string.
The string can contain only alphanumeric characters, @, blank or dot.
Others characters different from the indicated subset are not allowed, according to the white list approach.

''' Second Section '''

if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}

In this section there is the code to check if the strings inserted in the textbox “txtUid” and “txtSn” match the rule of the RegExp or not. There is a try-catch block and the object method "Validate" is used to make the job. If the validation passes, the catch block is not processed.

''' Third Section '''

LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;

The third section is the place for the connection to the server.

''' Fourth Section '''

try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}

Finally it's made the request and the server make the response, giving the number of entries that found

== Web.config Encryption ==

Web.config (and others file with .config extension) could contain sensitive informations that should be protected. For a .NET Web Application tipically the parameters to acces to a database are stored in plain text, in a form like this:

<configuration>
<connectionStrings>
<add name="Connection_SQLServer2005" connectionString="Data Source=WIN2K3\SQLInstance; Initial Catalog=Exampledb; User Id=user;
Password=clgir3s2s;" providerName=""/>
</connectionStrings>
</configuration>

It's possible to notice:

* Name of the server machine
* Name of the instance of SQL Server
* Name of the database
* Username
* Password

Gaining the access to directory of the web application, these informations are freely accessible.
The solution to mantain the confidentiality is always one: encryption.
Because encryption is not costless, it's not a good choice to encrypt the Web.config in its totality. It's better to select only the sensitive informations, that often are stored in the "configuration" sections of the file.
In .NET there are two mode to encrypt configuration section:

* Coding with some classes of the Framework
* Using the command line tool "aspnet_regiis.exe" (located in %SystemRoot%\Microsoft.NET\Framework\versionNumber folder)

In both cases the encryption is potentially provided in three modes:

* Windows Data Protection API Provider (DPAPI)
* RSA Protected Configuration Provider
* Custom Provider

DPAPI is the simplest manner. It uses a machine (or user) level key storage, so it's possible to share the secret with all the applications of the machine or not. Additionally it uses an encryption mode based on the login of the user, storing the information in the registry, so no key creation needed. But if the application is deployed in a Web farm, the better is RSA protected configuration provider due to the ease with which RSA keys can be exported.
So it's confortable to use the command line tool "aspnet_regiis.exe" with RSA provider.
First thing it's necessary to create a key container, for the public key encryption; open the SDK command prompt of the Framework and digit:

aspnet_regiis.exe -pc keycontainer1

in this manner a file with public and private key is stored at the path
%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys
with a unique code. It's possible to recognize the creation's datetime. It's important to know that this file is protected by the NTFS ACL, so only the creator and the SYSTEM account can manipulate it.
So if the web application run with another account (for example MACHINENAME\ASPNET user), it's necessary to grant the read permission for the key container with the command:

aspnet_regiis -pa keycontainer1 MACHINENAME\ASPNET

On the other hand add these lines in the Web.Config:

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<configProtectedData>
<providers>
<add name="NameProvider1"
type="System.Configuration.RsaProtectedConfigurationProvider, System.Configuration, Version=2.0.0.0,Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a,processorArchitecture=MSIL"
UseMachineContainer="true"
KeyContainerName="keycontainer1"
/>
</providers>
</configProtectedData>

in which there are references of the name of the provider (NameProvider1) that is based on RSA and key container (keycontainer1) used by the provider.
Now it's possible to encrypt the "connectionStrings" section using the physical path of the directory storing the web.config (and the the web application):

aspnet_regiis -pef connectionStrings C:\Project\BackendSecProj -prov NameProvider1

The result is that the connectionStrings section is comparable to:

<connectionStrings configProtectionProvider="NameProvider1">
<EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<KeyName>Rsa Key</KeyName>
</KeyInfo>
<CipherData>
<CipherValue>XV8DCEfUymYphQaL5GTqCQGhrNoED+/rIKNXS3l44exGiQWx2FH0Rq.....</CipherValue>
</CipherData>
</EncryptedKey>
</KeyInfo>
</EncryptedData>
</connectionStrings>

The application that must access to this section do automatically the decryption, due the read permission for the key container granted to the running user.
In any case it's always possible to decrypt the section with:

aspnet_regiis -pdf connectionStrings C:\Project\BackendSecProj

= References =

* http://msdn.microsoft.com/en-us/library/default.aspx
* http://msdn.microsoft.com/en-us/library/6759sth4.aspx
* http://directoryprogramming.net/
* http://msdn.microsoft.com/en-us/library/system.configuration.regexstringvalidator.aspx
* http://www.ietf.org/rfc/rfc2254.txt
* http://msdn.microsoft.com/en-us/library/az24scfc(VS.80).aspx
* http://msdn.microsoft.com/en-us/library/k6h9cz8h(VS.80).aspx
* http://msdn.microsoft.com/en-us/library/dtkwfdky(VS.80).aspx

OWASP Backend Security Project .NET Security Programming

2008-07-08T21:18:59Z

GPederzini: /* Web.config Encryption */

= Overview =

In this section are explained the best solution to avoid two of the most dangerous vulnerabilities of web applications, the sql injection and ldap injection on .NET programming

It will be analized the interactions between a web application written in C# in ASP.NET technology, .NET Framework 2.0 and two kinds of data provider: a SQL Server 2005 data provider and an OpenLdap Server data provider.

For the first interaction imagine a database called “ExampleDB” in which there are some tables. One of these tables is “Users”. From a
web application is possible to query the database to extract information about the users through their name.

For the second interaction imagine an Ldap server called “ExampleLDAP”.

The project is simple and is made by some .aspx page with a textbox in which is possible to insert the name of the user and the program will return the information, reading from ExampleDB (or ExampleLDAP).
It's not important to specify how it's possible to create an aspx page So the focus is on the code that we have to write to interact with the server data provider.

= Description =

== .NET Preventing SQL Injection ==

Two approaches are likely: inline query or stored procedure.

[[Image:owasp_bsp_net_1.jpg]]

=== Case 1: Inline query ===

Inline queries are the queries in which is possible to compose a sql statement through string concatenation. By clicking on the first button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryInline_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%"
+ txtQueryInline.Text + "%'", sqlConnection);
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section of code provides the sqlConnection, reading the connectionString from the Web.Config file. This is an important task for the application because it represents the entry point to the database, the credentials of the user that can authenticate on the ExampleDB.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%" +
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;

In this section is used the SqlCommand class, in which is written the sql code, concatenating with the text to search. The type of the SqlCommand is “Text”, so it's clear that the sql code is provided directly. This code is prone to sql injection, because we can manipulate the statement, injecting in the textbox, for example, the string:

'' '; sql statement -- ''

where sql statement is any sql code (it is possible to drop tables, add users, reconfigure the xp_cmdshell, etc.)

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

The third section is useful to represent the result set of the query. It uses the ADO.NET “Dataset”, and an intermediate class called SqlDataAdapter, that adapts the sql data in a form that can be used by the Dataset Object.

It is possible to improve this query, using the second form of interaction that make use of a stored procedure

=== Case 2: Parametrized query + Stored Procedure vulnerable ===

By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStoredVuln_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStoredVuln.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

CREATE PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This kind of stored procedure are not rare. In this case is possible to compose the statement in many ways using parameters, function and so on.

Altough it is a parametrized query with a stored procedure, as the code shows, it is possible to inject the same string

'' '; sql statement -- ''

to inject a sql statement. Using the SQL Server function REPLACE, it is possible to “patch” the problem without rewrite the store procedure, replacing all the single quote with a couple of single quote.

ALTER PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @Name = REPLACE(@Name,'''','''''')
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This second case explains the fact that the use of parametrized query with stored procedure not always resolve the security flaws caused by sql injection.

=== Case 3: Parametrized query + Stored Procedure not vulnerable ===

It is possible to modify the way to execute the same query, using parametrized query in conjunction with stored procedures. By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStored_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section is the same of the example above.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);

In this section is used the SqlCommand class as above, but, the type of the SqlCommand is “StoredProcedure” , so the sql code is not provided directly, but there is a procedure inside the database that makes the job. This procedure is called USP_SearchUserByNameNotVuln and accept a Varchar(50) parameter called @Name.
The code of the stored is simply:

CREATE PROCEDURE [dbo].[USP_SearchUserByNameNotVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
SELECT
U.Name,
U.Surname,
U.Code
FROM
dbo.Users U
WHERE
U.Name LIKE '''%' + @Name + '%'''
END

Three steps for each parameter passed to the stored procedure are needed to use the SqlParameter class:

* Instantiate the parameter with the right name and type used in the stored procedure
* Assign the value (in this case the value given by the user in the textbox)
* Add the parameter to the SqlCommand

When the sql command is executed, the parameters will be replaced with values specified by the SqlParameter object.

In conclusion, this kind of query is not prone to sql injection, because it is not possibile to build ad hoc sql statements, due to the correct use of Stored Procedure and the SqlParameter class.

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

This section is the same of the example above.

=== Input validation ===

Another point that is important to consider is the validation of the input. For example in a context in which a user has to insert (or select) some data in (or from) the database let’s think about the worst case, that is a user that can digit anything and submit anything to the server. To avoid this the only choiche is to validate the user's input. Two strategies are possible:

1. White list

2. Black list

The first solution answers at the condition: "deny all, except what is explicitly signed in the list".
The second solution answers at the condition: "allow all, except what is explicitly signed in the list".

The best solution for the security of the application is try to implement a validation of the input based on the first case. This comes more simply with numeric input, range input or strings that follow a specific pattern (for example an e-mail or a date). It becomes more difficult for strings with a not specific pattern (for example strings inserted in a search engine) in which often only a solution based on a black list is reasonably possible.

In a Web Application, there are two kinds of input validation:

1. client validations

2. server validations

There are a couple of reasons to use both types of validation summarized in the following points:

* client validations increase performance (the application doesn't postback to the server) but cause a false sense of security (the validation can be bypassed intercepting and manipulating the client request).
* server validations make worse performance but increase the security, because the validation is made by the server.

In ASP.NET to realize these concepts there are the server web control Validators:

* RequiredFieldValidator
* CompareValidator
* RangeValidator
* RegularExpressionValidator
* CustomValidator

Technically these objects realize both type of validations: that is if the client support Javascript, the Validator uses first the client validation, and after that the page is validated on then server side too. If the client doesn't support Javascript, the validation is made only on the server side. In this manner the application validate the input in a progressive mode and the design of the application doesn't follow a '' "Minimum-Denominator-Multiplier" ''.

To explain the concept in code, it's possible to analyze the CustomValidator, that is the higher generalization because it's possible to use a personalized validation logic.

=== CustomValidator ===

We can think symply to a textbox with a button, like the example above, in which it gives the way to search all the suppliers with a specific code (a string of 16 char) For security reasons it is imagined that a specific user can only see the suppliers that have a code in which the first 4 character are "PFHG".

Any other string that doesn't match this pattern has to be exclude from the search (white list approach)

[[Image:owasp_bsp_net_2.jpg]]

The XML part of the page is like that:

<asp:Label ID="lblQuerySearch" runat="server" Text="Digit the first four numbers"></asp:Label>
<asp:TextBox ID="txtQuerySearch" Width="5em" runat="server"></asp:TextBox>
<asp:RequiredFieldValidator ID="RequiredFieldValidatorQuerySearch" runat="server" ErrorMessage="Required Code"
ControlToValidate="txtQuerySearch"></asp:RequiredFieldValidator>
<asp:CustomValidator ID="CustomValidatorQuerySearch" runat="server" ErrorMessage="Wrong code"
ControlToValidate="txtQuerySearch" OnServerValidate="ValidateCode"></asp:CustomValidator>

The control Label and Button are intuitive web controls.
It's clear to see that two Validator have been applied to the textbox whose ID is '' "txtQuerySearch" ''.
The Validators are:

* RequiredFieldValidator: we don't accept an empty textbox when we submit our request to the server
* CustomValidator: we would implement some custom logic to our textbox

In fact the CustomValidator tag has a particular event called "OnServerValidate" that we can hook to a custom callback function, whose code is executed on the server side.
For this example it's like that:

protected void ValidateCode(object source, ServerValidateEventArgs args)
{
try
{
string textToValidate = args.Value;
if (textToValidate.Equals("PFHG"))
args.IsValid = true;
else
args.IsValid = false;
}
catch (Exception ex)
{
args.IsValid = false;
}
}

The function handles the argument "arg" that brings the text inserted by the user.
If this text match with our pattern, the argument is valid and the server executes the code associated to the button, querying the database in the same manner seen above; however the code is now conditioned by the statement "if(Page.IsValid)".

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
if (Page.IsValid)
{
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByCode", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pCode = new SqlParameter("@Code", SqlDbType.VarChar, 4);
pCode.Value = txtQuerySearch.Text;
cmd.Parameters.Add(pCode);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}
}

This is only an example but the use of the Validators can be very important in all the contexts in which the protection of a database from malicious input is needed.

== .NET Preventing LDAP Injection ==

It’s not important here to explain how LDAP works. The focus is explain how it’s possible to avoid the injection of special character, that are responsible of a unpredictable behaviour of the LDAP server.
LDAP search are often made with a distinguished name (DN) and a filter. So if the user input is not properly validated, the user can manipulate the input to craft a malicious filter, to obtain more informations from the server.
LDAP search are made with string, so the best solution to analyze a string searching particular characters is a Regular Expression.
In this example there is the code associated to a event ButtonClick, and two TextBox called "txtUid" and "txtSn" are used to give input to the system

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);
if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}
LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;
try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}
}

''' First Section '''

string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);

The first section uses a Regular Expression, using the class “RegExStringValidator”, very useful to analyze a string.
The string can contain only alphanumeric characters, @, blank or dot.
Others characters different from the indicated subset are not allowed, according to the white list approach.

''' Second Section '''

if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}

In this section there is the code to check if the strings inserted in the textbox “txtUid” and “txtSn” match the rule of the RegExp or not. There is a try-catch block and the object method "Validate" is used to make the job. If the validation passes, the catch block is not processed.

''' Third Section '''

LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;

The third section is the place for the connection to the server.

''' Fourth Section '''

try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}

Finally it's made the request and the server make the response, giving the number of entries that found

== Web.config Encryption ==

Web.config (and others file with .config extension) could contain sensitive informations that should be protected. For a .NET Web Application tipically the parameters to acces to a database are stored in plain text, in a form like this:

<configuration>
<connectionStrings>
<add name="Connection_SQLServer2005" connectionString="Data Source=WIN2K3\SQLInstance; Initial Catalog=Exampledb; User Id=user;
Password=clgir3s2s;" providerName=""/>
</connectionStrings>
</configuration>

It's possible to notice:

* Name of the server machine
* Name of the instance of SQL Server
* Name of the database
* Username
* Password

Gaining the access to directory of the web application, these informations are freely accessible.
The solution to mantain the confidentiality is always one: encryption.
Because encryption is not costless, it's not a good choice to encrypt the Web.config in its totality. It's better to select only the sensitive informations, that often are stored in the "configuration" sections of the file.
In .NET there are two mode to encrypt configuration section:

* Coding with some classes of the Framework
* Using the command line tool "aspnet_regiis.exe" (located in %SystemRoot%\Microsoft.NET\Framework\versionNumber folder)

In both cases the encryption is potentially provided in three modes:

* Windows Data Protection API Provider (DPAPI)
* RSA Protected Configuration Provider
* Custom Provider

DPAPI is the simplest manner. It uses a machine (or user) level key storage, so it's possible to share the secret with all the applications of the machine or not. Additionally it uses an encryption mode based on the login of the user, storing the information in the registry, so no key creation needed. But if the application is deployed in a Web farm, the better is RSA protected configuration provider due to the ease with which RSA keys can be exported.
So it's confortable to use the command line tool "aspnet_regiis.exe" with RSA provider.
First thing it's necessary to create a key container, for the public key encryption; open the SDK command prompt of the Framework and digit:

aspnet_regiis.exe -pc keycontainer1

in this manner a file with public and private key is stored at the path
%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys
with a unique code. It's possible to recognize the creation's datetime. It's important to know that this file is protected by the NTFS ACL, so only the creator and the SYSTEM account can manipulate it.
So if the web application run with another account (for example MACHINENAME\ASPNET user), it's necessary to grant the read permission for the key container with the command:

aspnet_regiis -pa keycontainer1 MACHINENAME\ASPNET

On the other hand add these lines in the Web.Config:

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<configProtectedData>
<providers>
<add name="NameProvider1"
type="System.Configuration.RsaProtectedConfigurationProvider, System.Configuration, Version=2.0.0.0,Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a,processorArchitecture=MSIL"
UseMachineContainer="true"
KeyContainerName="keycontainer1"
/>
</providers>
</configProtectedData>

in which there are references of the name of the provider (NameProvider1) that is based on RSA and key container (keycontainer1) used by the provider.
Now it's possible to encrypt the "connectionStrings" section using the physical path of the directory storing the web.config (and the the web application):

aspnet_regiis -pef connectionStrings C:\Project\BackendSecProj -prov NameProvider1

The result is that the connectionStrings section is comparable to:

<connectionStrings configProtectionProvider="NameProvider1">
<EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<KeyName>Rsa Key</KeyName>
</KeyInfo>
<CipherData>
<CipherValue>XV8DCEfUymYphQaL5GTqCQGhrNoED+/rIKNXS3l44exGiQWx2FH0Rq.....</CipherValue>
</CipherData>
</EncryptedKey>
</KeyInfo>
</EncryptedData>
</connectionStrings>

The application that must access to this section do automatically the decryption, due the read permission for the key container granted to the running user.
In any case it's always possible to decrypt the section with:

aspnet_regiis -pdf connectionStrings C:\Project\BackendSecProj

= References =

* http://msdn.microsoft.com/en-us/library/default.aspx
* http://msdn.microsoft.com/en-us/library/6759sth4.aspx
* http://directoryprogramming.net/
* http://msdn.microsoft.com/en-us/library/system.configuration.regexstringvalidator.aspx
* http://www.ietf.org/rfc/rfc2254.txt
* http://msdn.microsoft.com/en-us/library/az24scfc(VS.80).aspx

OWASP Backend Security Project .NET Security Programming

2008-07-08T21:06:23Z

GPederzini: /* Web.config Encryption */

= Overview =

In this section are explained the best solution to avoid two of the most dangerous vulnerabilities of web applications, the sql injection and ldap injection on .NET programming

It will be analized the interactions between a web application written in C# in ASP.NET technology, .NET Framework 2.0 and two kinds of data provider: a SQL Server 2005 data provider and an OpenLdap Server data provider.

For the first interaction imagine a database called “ExampleDB” in which there are some tables. One of these tables is “Users”. From a
web application is possible to query the database to extract information about the users through their name.

For the second interaction imagine an Ldap server called “ExampleLDAP”.

The project is simple and is made by some .aspx page with a textbox in which is possible to insert the name of the user and the program will return the information, reading from ExampleDB (or ExampleLDAP).
It's not important to specify how it's possible to create an aspx page So the focus is on the code that we have to write to interact with the server data provider.

= Description =

== .NET Preventing SQL Injection ==

Two approaches are likely: inline query or stored procedure.

[[Image:owasp_bsp_net_1.jpg]]

=== Case 1: Inline query ===

Inline queries are the queries in which is possible to compose a sql statement through string concatenation. By clicking on the first button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryInline_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%"
+ txtQueryInline.Text + "%'", sqlConnection);
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section of code provides the sqlConnection, reading the connectionString from the Web.Config file. This is an important task for the application because it represents the entry point to the database, the credentials of the user that can authenticate on the ExampleDB.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%" +
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;

In this section is used the SqlCommand class, in which is written the sql code, concatenating with the text to search. The type of the SqlCommand is “Text”, so it's clear that the sql code is provided directly. This code is prone to sql injection, because we can manipulate the statement, injecting in the textbox, for example, the string:

'' '; sql statement -- ''

where sql statement is any sql code (it is possible to drop tables, add users, reconfigure the xp_cmdshell, etc.)

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

The third section is useful to represent the result set of the query. It uses the ADO.NET “Dataset”, and an intermediate class called SqlDataAdapter, that adapts the sql data in a form that can be used by the Dataset Object.

It is possible to improve this query, using the second form of interaction that make use of a stored procedure

=== Case 2: Parametrized query + Stored Procedure vulnerable ===

By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStoredVuln_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStoredVuln.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

CREATE PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This kind of stored procedure are not rare. In this case is possible to compose the statement in many ways using parameters, function and so on.

Altough it is a parametrized query with a stored procedure, as the code shows, it is possible to inject the same string

'' '; sql statement -- ''

to inject a sql statement. Using the SQL Server function REPLACE, it is possible to “patch” the problem without rewrite the store procedure, replacing all the single quote with a couple of single quote.

ALTER PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @Name = REPLACE(@Name,'''','''''')
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This second case explains the fact that the use of parametrized query with stored procedure not always resolve the security flaws caused by sql injection.

=== Case 3: Parametrized query + Stored Procedure not vulnerable ===

It is possible to modify the way to execute the same query, using parametrized query in conjunction with stored procedures. By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStored_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section is the same of the example above.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);

In this section is used the SqlCommand class as above, but, the type of the SqlCommand is “StoredProcedure” , so the sql code is not provided directly, but there is a procedure inside the database that makes the job. This procedure is called USP_SearchUserByNameNotVuln and accept a Varchar(50) parameter called @Name.
The code of the stored is simply:

CREATE PROCEDURE [dbo].[USP_SearchUserByNameNotVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
SELECT
U.Name,
U.Surname,
U.Code
FROM
dbo.Users U
WHERE
U.Name LIKE '''%' + @Name + '%'''
END

Three steps for each parameter passed to the stored procedure are needed to use the SqlParameter class:

* Instantiate the parameter with the right name and type used in the stored procedure
* Assign the value (in this case the value given by the user in the textbox)
* Add the parameter to the SqlCommand

When the sql command is executed, the parameters will be replaced with values specified by the SqlParameter object.

In conclusion, this kind of query is not prone to sql injection, because it is not possibile to build ad hoc sql statements, due to the correct use of Stored Procedure and the SqlParameter class.

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

This section is the same of the example above.

=== Input validation ===

Another point that is important to consider is the validation of the input. For example in a context in which a user has to insert (or select) some data in (or from) the database let’s think about the worst case, that is a user that can digit anything and submit anything to the server. To avoid this the only choiche is to validate the user's input. Two strategies are possible:

1. White list

2. Black list

The first solution answers at the condition: "deny all, except what is explicitly signed in the list".
The second solution answers at the condition: "allow all, except what is explicitly signed in the list".

The best solution for the security of the application is try to implement a validation of the input based on the first case. This comes more simply with numeric input, range input or strings that follow a specific pattern (for example an e-mail or a date). It becomes more difficult for strings with a not specific pattern (for example strings inserted in a search engine) in which often only a solution based on a black list is reasonably possible.

In a Web Application, there are two kinds of input validation:

1. client validations

2. server validations

There are a couple of reasons to use both types of validation summarized in the following points:

* client validations increase performance (the application doesn't postback to the server) but cause a false sense of security (the validation can be bypassed intercepting and manipulating the client request).
* server validations make worse performance but increase the security, because the validation is made by the server.

In ASP.NET to realize these concepts there are the server web control Validators:

* RequiredFieldValidator
* CompareValidator
* RangeValidator
* RegularExpressionValidator
* CustomValidator

Technically these objects realize both type of validations: that is if the client support Javascript, the Validator uses first the client validation, and after that the page is validated on then server side too. If the client doesn't support Javascript, the validation is made only on the server side. In this manner the application validate the input in a progressive mode and the design of the application doesn't follow a '' "Minimum-Denominator-Multiplier" ''.

To explain the concept in code, it's possible to analyze the CustomValidator, that is the higher generalization because it's possible to use a personalized validation logic.

=== CustomValidator ===

We can think symply to a textbox with a button, like the example above, in which it gives the way to search all the suppliers with a specific code (a string of 16 char) For security reasons it is imagined that a specific user can only see the suppliers that have a code in which the first 4 character are "PFHG".

Any other string that doesn't match this pattern has to be exclude from the search (white list approach)

[[Image:owasp_bsp_net_2.jpg]]

The XML part of the page is like that:

<asp:Label ID="lblQuerySearch" runat="server" Text="Digit the first four numbers"></asp:Label>
<asp:TextBox ID="txtQuerySearch" Width="5em" runat="server"></asp:TextBox>
<asp:RequiredFieldValidator ID="RequiredFieldValidatorQuerySearch" runat="server" ErrorMessage="Required Code"
ControlToValidate="txtQuerySearch"></asp:RequiredFieldValidator>
<asp:CustomValidator ID="CustomValidatorQuerySearch" runat="server" ErrorMessage="Wrong code"
ControlToValidate="txtQuerySearch" OnServerValidate="ValidateCode"></asp:CustomValidator>

The control Label and Button are intuitive web controls.
It's clear to see that two Validator have been applied to the textbox whose ID is '' "txtQuerySearch" ''.
The Validators are:

* RequiredFieldValidator: we don't accept an empty textbox when we submit our request to the server
* CustomValidator: we would implement some custom logic to our textbox

In fact the CustomValidator tag has a particular event called "OnServerValidate" that we can hook to a custom callback function, whose code is executed on the server side.
For this example it's like that:

protected void ValidateCode(object source, ServerValidateEventArgs args)
{
try
{
string textToValidate = args.Value;
if (textToValidate.Equals("PFHG"))
args.IsValid = true;
else
args.IsValid = false;
}
catch (Exception ex)
{
args.IsValid = false;
}
}

The function handles the argument "arg" that brings the text inserted by the user.
If this text match with our pattern, the argument is valid and the server executes the code associated to the button, querying the database in the same manner seen above; however the code is now conditioned by the statement "if(Page.IsValid)".

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
if (Page.IsValid)
{
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByCode", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pCode = new SqlParameter("@Code", SqlDbType.VarChar, 4);
pCode.Value = txtQuerySearch.Text;
cmd.Parameters.Add(pCode);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}
}

This is only an example but the use of the Validators can be very important in all the contexts in which the protection of a database from malicious input is needed.

== .NET Preventing LDAP Injection ==

It’s not important here to explain how LDAP works. The focus is explain how it’s possible to avoid the injection of special character, that are responsible of a unpredictable behaviour of the LDAP server.
LDAP search are often made with a distinguished name (DN) and a filter. So if the user input is not properly validated, the user can manipulate the input to craft a malicious filter, to obtain more informations from the server.
LDAP search are made with string, so the best solution to analyze a string searching particular characters is a Regular Expression.
In this example there is the code associated to a event ButtonClick, and two TextBox called "txtUid" and "txtSn" are used to give input to the system

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);
if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}
LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;
try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}
}

''' First Section '''

string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);

The first section uses a Regular Expression, using the class “RegExStringValidator”, very useful to analyze a string.
The string can contain only alphanumeric characters, @, blank or dot.
Others characters different from the indicated subset are not allowed, according to the white list approach.

''' Second Section '''

if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}

In this section there is the code to check if the strings inserted in the textbox “txtUid” and “txtSn” match the rule of the RegExp or not. There is a try-catch block and the object method "Validate" is used to make the job. If the validation passes, the catch block is not processed.

''' Third Section '''

LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;

The third section is the place for the connection to the server.

''' Fourth Section '''

try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}

Finally it's made the request and the server make the response, giving the number of entries that found

== Web.config Encryption ==

Web.config (and others file with .config extension) could contain sensitive informations that should be protected. For a .NET Web Application tipically the parameters to acces to a database are stored in plain text, in a form like this:

<configuration>
<connectionStrings>
<add name="Connection_SQLServer2005" connectionString="Data Source=WIN2K3\SQLInstance; Initial Catalog=Exampledb; User Id=user;
Password=clgir3s2s;" providerName=""/>
</connectionStrings>
</configuration>

It's possible to notice:

* Name of the server machine
* Name of the instance of SQL Server
* Name of the database
* Username
* Password

Gaining the access to directory of the web application, these informations are freely accessible.
The solution to mantain the confidentiality is always one: encryption.
Because encryption is not costless, it's not a good choice to encrypt the Web.config in its totality. It's better to select only the sensitive informations, that often are stored in the "configuration" sections of the file.
In .NET there are two mode to encrypt configuration section:

* Coding with some classes of the Framework
* Using the command line tool "aspnet_regiis.exe" (located in %SystemRoot%\Microsoft.NET\Framework\versionNumber folder)

In both cases the encryption is potentially provided in three modes:

* Windows Data Protection API Provider (DPAPI)
* RSA Protected Configuration Provider
* Custom Provider

DPAPI is the simplest manner. It uses a machine (or user) level key storage, so it's possible to share the secret with all the applications of the machine or not. Additionally it uses an encryption mode based on the login of the user, storing the information in the registry, so no key creation needed. But if the application is deployed in a Web farm, the better is RSA protected configuration provider due to the ease with which RSA keys can be exported.
So it's confortable to use the command line tool "aspnet_regiis.exe" with RSA provider.
First thing it's necessary to create a key container, for the public key encryption; open the SDK command prompt of the Framework and digit:

aspnet_regiis.exe -pc keycontainer1

in this manner a file with public and private key is stored at the path
%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys
with a unique code. It's possible to recognize the creation's datetime. It's important to know that this file is protected by the NTFS ACL, so only the creator and the SYSTEM account can manipulate it.
So if the web application run with another account (for example MACHINENAME\ASPNET user), it's necessary to grant the read permission for the key container with the command:

aspnet_regiis -pa keycontainer1 MACHINENAME\ASPNET

On the other hand add these lines in the Web.Config:

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
<configProtectedData>
<providers>
<add name="NameProvider1"
type="System.Configuration.RsaProtectedConfigurationProvider, System.Configuration, Version=2.0.0.0,Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a,processorArchitecture=MSIL"
UseMachineContainer="true"
KeyContainerName="keycontainer1"
/>
</providers>
</configProtectedData>

in which there are references of the name of the provider (NameProvider1) that is based on RSA and key container (keycontainer1) used by the provider.
Now it's possible to encrypt the "connectionStrings" section using the physical path of the directory storing the web.config (and the the web application):

aspnet_regiis -pef connectionStrings C:\Project\BackendSecProj -prov NameProvider1

The result is that the connectionStrings section has a form like this:

<connectionStrings configProtectionProvider="MyProv">
<EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<KeyName>Rsa Key</KeyName>
</KeyInfo>
<CipherData>
<CipherValue>XV8DCEfUymYphQaL5GTqCQGhrNoED+/rIKNXS3l44exGiQWx2FH0Rq.....</CipherValue>
</CipherData>
</EncryptedKey>
</KeyInfo>
<CipherData>
<CipherValue>2jTQIKfzHOaXcyOYd3kA6Pdvy1v3269fr0OzEsK9DRnxgi9iH8umA....</CipherValue>
</CipherData>
</EncryptedData>
</connectionStrings>

= References =

* http://msdn.microsoft.com/en-us/library/default.aspx
* http://msdn.microsoft.com/en-us/library/6759sth4.aspx
* http://directoryprogramming.net/
* http://msdn.microsoft.com/en-us/library/system.configuration.regexstringvalidator.aspx
* http://www.ietf.org/rfc/rfc2254.txt
* http://msdn.microsoft.com/en-us/library/az24scfc(VS.80).aspx

OWASP Backend Security Project .NET Security Programming

2008-07-08T19:53:56Z

GPederzini: /* Web.config Encryption */

= Overview =

In this section are explained the best solution to avoid two of the most dangerous vulnerabilities of web applications, the sql injection and ldap injection on .NET programming

It will be analized the interactions between a web application written in C# in ASP.NET technology, .NET Framework 2.0 and two kinds of data provider: a SQL Server 2005 data provider and an OpenLdap Server data provider.

For the first interaction imagine a database called “ExampleDB” in which there are some tables. One of these tables is “Users”. From a
web application is possible to query the database to extract information about the users through their name.

For the second interaction imagine an Ldap server called “ExampleLDAP”.

The project is simple and is made by some .aspx page with a textbox in which is possible to insert the name of the user and the program will return the information, reading from ExampleDB (or ExampleLDAP).
It's not important to specify how it's possible to create an aspx page So the focus is on the code that we have to write to interact with the server data provider.

= Description =

== .NET Preventing SQL Injection ==

Two approaches are likely: inline query or stored procedure.

[[Image:owasp_bsp_net_1.jpg]]

=== Case 1: Inline query ===

Inline queries are the queries in which is possible to compose a sql statement through string concatenation. By clicking on the first button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryInline_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%"
+ txtQueryInline.Text + "%'", sqlConnection);
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section of code provides the sqlConnection, reading the connectionString from the Web.Config file. This is an important task for the application because it represents the entry point to the database, the credentials of the user that can authenticate on the ExampleDB.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%" +
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;

In this section is used the SqlCommand class, in which is written the sql code, concatenating with the text to search. The type of the SqlCommand is “Text”, so it's clear that the sql code is provided directly. This code is prone to sql injection, because we can manipulate the statement, injecting in the textbox, for example, the string:

'' '; sql statement -- ''

where sql statement is any sql code (it is possible to drop tables, add users, reconfigure the xp_cmdshell, etc.)

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

The third section is useful to represent the result set of the query. It uses the ADO.NET “Dataset”, and an intermediate class called SqlDataAdapter, that adapts the sql data in a form that can be used by the Dataset Object.

It is possible to improve this query, using the second form of interaction that make use of a stored procedure

=== Case 2: Parametrized query + Stored Procedure vulnerable ===

By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStoredVuln_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStoredVuln.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

CREATE PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This kind of stored procedure are not rare. In this case is possible to compose the statement in many ways using parameters, function and so on.

Altough it is a parametrized query with a stored procedure, as the code shows, it is possible to inject the same string

'' '; sql statement -- ''

to inject a sql statement. Using the SQL Server function REPLACE, it is possible to “patch” the problem without rewrite the store procedure, replacing all the single quote with a couple of single quote.

ALTER PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @Name = REPLACE(@Name,'''','''''')
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This second case explains the fact that the use of parametrized query with stored procedure not always resolve the security flaws caused by sql injection.

=== Case 3: Parametrized query + Stored Procedure not vulnerable ===

It is possible to modify the way to execute the same query, using parametrized query in conjunction with stored procedures. By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStored_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section is the same of the example above.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);

In this section is used the SqlCommand class as above, but, the type of the SqlCommand is “StoredProcedure” , so the sql code is not provided directly, but there is a procedure inside the database that makes the job. This procedure is called USP_SearchUserByNameNotVuln and accept a Varchar(50) parameter called @Name.
The code of the stored is simply:

CREATE PROCEDURE [dbo].[USP_SearchUserByNameNotVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
SELECT
U.Name,
U.Surname,
U.Code
FROM
dbo.Users U
WHERE
U.Name LIKE '''%' + @Name + '%'''
END

Three steps for each parameter passed to the stored procedure are needed to use the SqlParameter class:

* Instantiate the parameter with the right name and type used in the stored procedure
* Assign the value (in this case the value given by the user in the textbox)
* Add the parameter to the SqlCommand

When the sql command is executed, the parameters will be replaced with values specified by the SqlParameter object.

In conclusion, this kind of query is not prone to sql injection, because it is not possibile to build ad hoc sql statements, due to the correct use of Stored Procedure and the SqlParameter class.

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

This section is the same of the example above.

=== Input validation ===

Another point that is important to consider is the validation of the input. For example in a context in which a user has to insert (or select) some data in (or from) the database let’s think about the worst case, that is a user that can digit anything and submit anything to the server. To avoid this the only choiche is to validate the user's input. Two strategies are possible:

1. White list

2. Black list

The first solution answers at the condition: "deny all, except what is explicitly signed in the list".
The second solution answers at the condition: "allow all, except what is explicitly signed in the list".

The best solution for the security of the application is try to implement a validation of the input based on the first case. This comes more simply with numeric input, range input or strings that follow a specific pattern (for example an e-mail or a date). It becomes more difficult for strings with a not specific pattern (for example strings inserted in a search engine) in which often only a solution based on a black list is reasonably possible.

In a Web Application, there are two kinds of input validation:

1. client validations

2. server validations

There are a couple of reasons to use both types of validation summarized in the following points:

* client validations increase performance (the application doesn't postback to the server) but cause a false sense of security (the validation can be bypassed intercepting and manipulating the client request).
* server validations make worse performance but increase the security, because the validation is made by the server.

In ASP.NET to realize these concepts there are the server web control Validators:

* RequiredFieldValidator
* CompareValidator
* RangeValidator
* RegularExpressionValidator
* CustomValidator

Technically these objects realize both type of validations: that is if the client support Javascript, the Validator uses first the client validation, and after that the page is validated on then server side too. If the client doesn't support Javascript, the validation is made only on the server side. In this manner the application validate the input in a progressive mode and the design of the application doesn't follow a '' "Minimum-Denominator-Multiplier" ''.

To explain the concept in code, it's possible to analyze the CustomValidator, that is the higher generalization because it's possible to use a personalized validation logic.

=== CustomValidator ===

We can think symply to a textbox with a button, like the example above, in which it gives the way to search all the suppliers with a specific code (a string of 16 char) For security reasons it is imagined that a specific user can only see the suppliers that have a code in which the first 4 character are "PFHG".

Any other string that doesn't match this pattern has to be exclude from the search (white list approach)

[[Image:owasp_bsp_net_2.jpg]]

The XML part of the page is like that:

<asp:Label ID="lblQuerySearch" runat="server" Text="Digit the first four numbers"></asp:Label>
<asp:TextBox ID="txtQuerySearch" Width="5em" runat="server"></asp:TextBox>
<asp:RequiredFieldValidator ID="RequiredFieldValidatorQuerySearch" runat="server" ErrorMessage="Required Code"
ControlToValidate="txtQuerySearch"></asp:RequiredFieldValidator>
<asp:CustomValidator ID="CustomValidatorQuerySearch" runat="server" ErrorMessage="Wrong code"
ControlToValidate="txtQuerySearch" OnServerValidate="ValidateCode"></asp:CustomValidator>

The control Label and Button are intuitive web controls.
It's clear to see that two Validator have been applied to the textbox whose ID is '' "txtQuerySearch" ''.
The Validators are:

* RequiredFieldValidator: we don't accept an empty textbox when we submit our request to the server
* CustomValidator: we would implement some custom logic to our textbox

In fact the CustomValidator tag has a particular event called "OnServerValidate" that we can hook to a custom callback function, whose code is executed on the server side.
For this example it's like that:

protected void ValidateCode(object source, ServerValidateEventArgs args)
{
try
{
string textToValidate = args.Value;
if (textToValidate.Equals("PFHG"))
args.IsValid = true;
else
args.IsValid = false;
}
catch (Exception ex)
{
args.IsValid = false;
}
}

The function handles the argument "arg" that brings the text inserted by the user.
If this text match with our pattern, the argument is valid and the server executes the code associated to the button, querying the database in the same manner seen above; however the code is now conditioned by the statement "if(Page.IsValid)".

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
if (Page.IsValid)
{
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByCode", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pCode = new SqlParameter("@Code", SqlDbType.VarChar, 4);
pCode.Value = txtQuerySearch.Text;
cmd.Parameters.Add(pCode);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}
}

This is only an example but the use of the Validators can be very important in all the contexts in which the protection of a database from malicious input is needed.

== .NET Preventing LDAP Injection ==

It’s not important here to explain how LDAP works. The focus is explain how it’s possible to avoid the injection of special character, that are responsible of a unpredictable behaviour of the LDAP server.
LDAP search are often made with a distinguished name (DN) and a filter. So if the user input is not properly validated, the user can manipulate the input to craft a malicious filter, to obtain more informations from the server.
LDAP search are made with string, so the best solution to analyze a string searching particular characters is a Regular Expression.
In this example there is the code associated to a event ButtonClick, and two TextBox called "txtUid" and "txtSn" are used to give input to the system

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);
if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}
LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;
try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}
}

''' First Section '''

string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);

The first section uses a Regular Expression, using the class “RegExStringValidator”, very useful to analyze a string.
The string can contain only alphanumeric characters, @, blank or dot.
Others characters different from the indicated subset are not allowed, according to the white list approach.

''' Second Section '''

if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}

In this section there is the code to check if the strings inserted in the textbox “txtUid” and “txtSn” match the rule of the RegExp or not. There is a try-catch block and the object method "Validate" is used to make the job. If the validation passes, the catch block is not processed.

''' Third Section '''

LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;

The third section is the place for the connection to the server.

''' Fourth Section '''

try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}

Finally it's made the request and the server make the response, giving the number of entries that found

== Web.config Encryption ==

Web.config (and others file with .config extension) could contain sensitive informations that should be protected. For a .NET Web Application tipically the parameters to acces to a database are stored in plain text, in a form like this:

<configuration>
<connectionStrings>
<add name="Connection_SQLServer2005" connectionString="Data Source=WIN2K3\SQLInstance; Initial Catalog=Exampledb; User Id=user;
Password=clgir3s2s;" providerName=""/>
</connectionStrings>
</configuration>

It's possible to notice:

* Name of the server machine
* Name of the instance of SQL Server
* Name of the database
* Username
* Password

Gaining the access to directory of the web application, these informations are freely accessible.
The solution to mantain the confidentiality is always one: encryption.
Because encryption is not costless, it's not a good choice to encrypt the Web.config in its totality. It's better to select only the sensitive informations, that often are stored in the "configuration" sections of the file.
In .NET there are two mode to encrypt configuration section:

* Coding with some classes of the Framework
* Using the command line tool "aspnet_regiis.exe" (located in %SystemRoot%\Microsoft.NET\Framework\versionNumber folder)

In both cases the encryption is potentially provided in three modes:

* Windows Data Protection API Provider (DPAPI)
* RSA Protected Configuration Provider
* Custom Provider

DPAPI is the simplest manner. It uses a machine (or user) level key storage, so it's possible to share the secret with all the applications of the machine or not. Additionally it uses an encryption mode based on the login of the user, storing the information in the registry, so no key creation needed. But if the application is deployed in a Web farm, the better is RSA protected configuration provider due to the ease with which RSA keys can be exported.
So it's confortable to use the command line tool "aspnet_regiis.exe" with RSA provider.

1)

= References =

* http://msdn.microsoft.com/en-us/library/default.aspx
* http://msdn.microsoft.com/en-us/library/6759sth4.aspx
* http://directoryprogramming.net/
* http://msdn.microsoft.com/en-us/library/system.configuration.regexstringvalidator.aspx
* http://www.ietf.org/rfc/rfc2254.txt
* http://msdn.microsoft.com/en-us/library/az24scfc(VS.80).aspx

OWASP Backend Security Project .NET Security Programming

2008-07-06T16:29:53Z

GPederzini: /* Web.config Encryption */

= Overview =

In this section are explained the best solution to avoid two of the most dangerous vulnerabilities of web applications, the sql injection and ldap injection on .NET programming

It will be analized the interactions between a web application written in C# in ASP.NET technology, .NET Framework 2.0 and two kinds of data provider: a SQL Server 2005 data provider and an OpenLdap Server data provider.

For the first interaction imagine a database called “ExampleDB” in which there are some tables. One of these tables is “Users”. From a
web application is possible to query the database to extract information about the users through their name.

For the second interaction imagine an Ldap server called “ExampleLDAP”.

The project is simple and is made by some .aspx page with a textbox in which is possible to insert the name of the user and the program will return the information, reading from ExampleDB (or ExampleLDAP).
It's not important to specify how it's possible to create an aspx page So the focus is on the code that we have to write to interact with the server data provider.

= Description =

== .NET Preventing SQL Injection ==

Two approaches are likely: inline query or stored procedure.

[[Image:owasp_bsp_net_1.jpg]]

=== Case 1: Inline query ===

Inline queries are the queries in which is possible to compose a sql statement through string concatenation. By clicking on the first button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryInline_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%"
+ txtQueryInline.Text + "%'", sqlConnection);
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section of code provides the sqlConnection, reading the connectionString from the Web.Config file. This is an important task for the application because it represents the entry point to the database, the credentials of the user that can authenticate on the ExampleDB.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%" +
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;

In this section is used the SqlCommand class, in which is written the sql code, concatenating with the text to search. The type of the SqlCommand is “Text”, so it's clear that the sql code is provided directly. This code is prone to sql injection, because we can manipulate the statement, injecting in the textbox, for example, the string:

'' '; sql statement -- ''

where sql statement is any sql code (it is possible to drop tables, add users, reconfigure the xp_cmdshell, etc.)

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

The third section is useful to represent the result set of the query. It uses the ADO.NET “Dataset”, and an intermediate class called SqlDataAdapter, that adapts the sql data in a form that can be used by the Dataset Object.

It is possible to improve this query, using the second form of interaction that make use of a stored procedure

=== Case 2: Parametrized query + Stored Procedure vulnerable ===

By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStoredVuln_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStoredVuln.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

CREATE PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This kind of stored procedure are not rare. In this case is possible to compose the statement in many ways using parameters, function and so on.

Altough it is a parametrized query with a stored procedure, as the code shows, it is possible to inject the same string

'' '; sql statement -- ''

to inject a sql statement. Using the SQL Server function REPLACE, it is possible to “patch” the problem without rewrite the store procedure, replacing all the single quote with a couple of single quote.

ALTER PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @Name = REPLACE(@Name,'''','''''')
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This second case explains the fact that the use of parametrized query with stored procedure not always resolve the security flaws caused by sql injection.

=== Case 3: Parametrized query + Stored Procedure not vulnerable ===

It is possible to modify the way to execute the same query, using parametrized query in conjunction with stored procedures. By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStored_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section is the same of the example above.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);

In this section is used the SqlCommand class as above, but, the type of the SqlCommand is “StoredProcedure” , so the sql code is not provided directly, but there is a procedure inside the database that makes the job. This procedure is called USP_SearchUserByNameNotVuln and accept a Varchar(50) parameter called @Name.
The code of the stored is simply:

CREATE PROCEDURE [dbo].[USP_SearchUserByNameNotVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
SELECT
U.Name,
U.Surname,
U.Code
FROM
dbo.Users U
WHERE
U.Name LIKE '''%' + @Name + '%'''
END

Three steps for each parameter passed to the stored procedure are needed to use the SqlParameter class:

* Instantiate the parameter with the right name and type used in the stored procedure
* Assign the value (in this case the value given by the user in the textbox)
* Add the parameter to the SqlCommand

When the sql command is executed, the parameters will be replaced with values specified by the SqlParameter object.

In conclusion, this kind of query is not prone to sql injection, because it is not possibile to build ad hoc sql statements, due to the correct use of Stored Procedure and the SqlParameter class.

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

This section is the same of the example above.

=== Input validation ===

Another point that is important to consider is the validation of the input. For example in a context in which a user has to insert (or select) some data in (or from) the database let’s think about the worst case, that is a user that can digit anything and submit anything to the server. To avoid this the only choiche is to validate the user's input. Two strategies are possible:

1. White list

2. Black list

The first solution answers at the condition: "deny all, except what is explicitly signed in the list".
The second solution answers at the condition: "allow all, except what is explicitly signed in the list".

The best solution for the security of the application is try to implement a validation of the input based on the first case. This comes more simply with numeric input, range input or strings that follow a specific pattern (for example an e-mail or a date). It becomes more difficult for strings with a not specific pattern (for example strings inserted in a search engine) in which often only a solution based on a black list is reasonably possible.

In a Web Application, there are two kinds of input validation:

1. client validations

2. server validations

There are a couple of reasons to use both types of validation summarized in the following points:

* client validations increase performance (the application doesn't postback to the server) but cause a false sense of security (the validation can be bypassed intercepting and manipulating the client request).
* server validations make worse performance but increase the security, because the validation is made by the server.

In ASP.NET to realize these concepts there are the server web control Validators:

* RequiredFieldValidator
* CompareValidator
* RangeValidator
* RegularExpressionValidator
* CustomValidator

Technically these objects realize both type of validations: that is if the client support Javascript, the Validator uses first the client validation, and after that the page is validated on then server side too. If the client doesn't support Javascript, the validation is made only on the server side. In this manner the application validate the input in a progressive mode and the design of the application doesn't follow a '' "Minimum-Denominator-Multiplier" ''.

To explain the concept in code, it's possible to analyze the CustomValidator, that is the higher generalization because it's possible to use a personalized validation logic.

=== CustomValidator ===

We can think symply to a textbox with a button, like the example above, in which it gives the way to search all the suppliers with a specific code (a string of 16 char) For security reasons it is imagined that a specific user can only see the suppliers that have a code in which the first 4 character are "PFHG".

Any other string that doesn't match this pattern has to be exclude from the search (white list approach)

[[Image:owasp_bsp_net_2.jpg]]

The XML part of the page is like that:

<asp:Label ID="lblQuerySearch" runat="server" Text="Digit the first four numbers"></asp:Label>
<asp:TextBox ID="txtQuerySearch" Width="5em" runat="server"></asp:TextBox>
<asp:RequiredFieldValidator ID="RequiredFieldValidatorQuerySearch" runat="server" ErrorMessage="Required Code"
ControlToValidate="txtQuerySearch"></asp:RequiredFieldValidator>
<asp:CustomValidator ID="CustomValidatorQuerySearch" runat="server" ErrorMessage="Wrong code"
ControlToValidate="txtQuerySearch" OnServerValidate="ValidateCode"></asp:CustomValidator>

The control Label and Button are intuitive web controls.
It's clear to see that two Validator have been applied to the textbox whose ID is '' "txtQuerySearch" ''.
The Validators are:

* RequiredFieldValidator: we don't accept an empty textbox when we submit our request to the server
* CustomValidator: we would implement some custom logic to our textbox

In fact the CustomValidator tag has a particular event called "OnServerValidate" that we can hook to a custom callback function, whose code is executed on the server side.
For this example it's like that:

protected void ValidateCode(object source, ServerValidateEventArgs args)
{
try
{
string textToValidate = args.Value;
if (textToValidate.Equals("PFHG"))
args.IsValid = true;
else
args.IsValid = false;
}
catch (Exception ex)
{
args.IsValid = false;
}
}

The function handles the argument "arg" that brings the text inserted by the user.
If this text match with our pattern, the argument is valid and the server executes the code associated to the button, querying the database in the same manner seen above; however the code is now conditioned by the statement "if(Page.IsValid)".

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
if (Page.IsValid)
{
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByCode", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pCode = new SqlParameter("@Code", SqlDbType.VarChar, 4);
pCode.Value = txtQuerySearch.Text;
cmd.Parameters.Add(pCode);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}
}

This is only an example but the use of the Validators can be very important in all the contexts in which the protection of a database from malicious input is needed.

== .NET Preventing LDAP Injection ==

It’s not important here to explain how LDAP works. The focus is explain how it’s possible to avoid the injection of special character, that are responsible of a unpredictable behaviour of the LDAP server.
LDAP search are often made with a distinguished name (DN) and a filter. So if the user input is not properly validated, the user can manipulate the input to craft a malicious filter, to obtain more informations from the server.
LDAP search are made with string, so the best solution to analyze a string searching particular characters is a Regular Expression.
In this example there is the code associated to a event ButtonClick, and two TextBox called "txtUid" and "txtSn" are used to give input to the system

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);
if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}
LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;
try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}
}

''' First Section '''

string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);

The first section uses a Regular Expression, using the class “RegExStringValidator”, very useful to analyze a string.
The string can contain only alphanumeric characters, @, blank or dot.
Others characters different from the indicated subset are not allowed, according to the white list approach.

''' Second Section '''

if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}

In this section there is the code to check if the strings inserted in the textbox “txtUid” and “txtSn” match the rule of the RegExp or not. There is a try-catch block and the object method "Validate" is used to make the job. If the validation passes, the catch block is not processed.

''' Third Section '''

LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;

The third section is the place for the connection to the server.

''' Fourth Section '''

try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}

Finally it's made the request and the server make the response, giving the number of entries that found

== Web.config Encryption ==

Web.config (and others file with .config extension) could contain sensitive informations that should be protected. For a .NET Web Application tipically the parameters to acces to a database are stored in plain text, in a form like this:

<configuration>
<connectionStrings>
<add name="Connection_SQLServer2005" connectionString="Data Source=WIN2K3\SQLInstance; Initial Catalog=Exampledb; User Id=user;
Password=clgir3s2s;" providerName=""/>
</connectionStrings>
</configuration>

It's possible to notice:

* Name of the server machine
* Name of the instance of SQL Server
* Name of the database
* Username
* Password

Gaining the access to directory of the web application, these informations are freely accessible.
The solution to mantain the confidentiality is always one: encryption.
Because encryption is not costless, it's not a good choice to encrypt the Web.config in its totality. It's better to select only the sensitive informations, that often are stored in the "configuration" sections of the file.
In .NET there are two mode to encrypt configuration section:

* Coding with some classes of the Framework
* Using the command line tool "aspnet_regiis.exe" (located in %SystemRoot%\Microsoft.NET\Framework\versionNumber folder)

In both cases the encryption is potentially provided in three modes:

* Windows Data Protection API Provider (DPAPI)
* RSA Protected Configuration Provider
* Custom Provider

DPAPI is the simplest manner. It uses a machine (or user) level key storage, so it's possible to share the secret with all the applications of the machine or not. Additionally it uses an encryption mode based on the login of the user, storing the information in the registry, so no key creation needed. But if the application is deployed in a Web farm, the better is RSA protected configuration provider due to the ease with which RSA keys can be exported.

= References =

* http://msdn.microsoft.com/en-us/library/default.aspx
* http://msdn.microsoft.com/en-us/library/6759sth4.aspx
* http://directoryprogramming.net/
* http://msdn.microsoft.com/en-us/library/system.configuration.regexstringvalidator.aspx
* http://www.ietf.org/rfc/rfc2254.txt
* http://msdn.microsoft.com/en-us/library/az24scfc(VS.80).aspx

OWASP Backend Security Project .NET Security Programming

2008-07-06T11:06:41Z

GPederzini: /* Web.config Encryption */

= Overview =

In this section are explained the best solution to avoid two of the most dangerous vulnerabilities of web applications, the sql injection and ldap injection on .NET programming

It will be analized the interactions between a web application written in C# in ASP.NET technology, .NET Framework 2.0 and two kinds of data provider: a SQL Server 2005 data provider and an OpenLdap Server data provider.

For the first interaction imagine a database called “ExampleDB” in which there are some tables. One of these tables is “Users”. From a
web application is possible to query the database to extract information about the users through their name.

For the second interaction imagine an Ldap server called “ExampleLDAP”.

The project is simple and is made by some .aspx page with a textbox in which is possible to insert the name of the user and the program will return the information, reading from ExampleDB (or ExampleLDAP).
It's not important to specify how it's possible to create an aspx page So the focus is on the code that we have to write to interact with the server data provider.

= Description =

== .NET Preventing SQL Injection ==

Two approaches are likely: inline query or stored procedure.

[[Image:owasp_bsp_net_1.jpg]]

=== Case 1: Inline query ===

Inline queries are the queries in which is possible to compose a sql statement through string concatenation. By clicking on the first button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryInline_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%"
+ txtQueryInline.Text + "%'", sqlConnection);
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section of code provides the sqlConnection, reading the connectionString from the Web.Config file. This is an important task for the application because it represents the entry point to the database, the credentials of the user that can authenticate on the ExampleDB.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%" +
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;

In this section is used the SqlCommand class, in which is written the sql code, concatenating with the text to search. The type of the SqlCommand is “Text”, so it's clear that the sql code is provided directly. This code is prone to sql injection, because we can manipulate the statement, injecting in the textbox, for example, the string:

'' '; sql statement -- ''

where sql statement is any sql code (it is possible to drop tables, add users, reconfigure the xp_cmdshell, etc.)

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

The third section is useful to represent the result set of the query. It uses the ADO.NET “Dataset”, and an intermediate class called SqlDataAdapter, that adapts the sql data in a form that can be used by the Dataset Object.

It is possible to improve this query, using the second form of interaction that make use of a stored procedure

=== Case 2: Parametrized query + Stored Procedure vulnerable ===

By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStoredVuln_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStoredVuln.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

CREATE PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This kind of stored procedure are not rare. In this case is possible to compose the statement in many ways using parameters, function and so on.

Altough it is a parametrized query with a stored procedure, as the code shows, it is possible to inject the same string

'' '; sql statement -- ''

to inject a sql statement. Using the SQL Server function REPLACE, it is possible to “patch” the problem without rewrite the store procedure, replacing all the single quote with a couple of single quote.

ALTER PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @Name = REPLACE(@Name,'''','''''')
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This second case explains the fact that the use of parametrized query with stored procedure not always resolve the security flaws caused by sql injection.

=== Case 3: Parametrized query + Stored Procedure not vulnerable ===

It is possible to modify the way to execute the same query, using parametrized query in conjunction with stored procedures. By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStored_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section is the same of the example above.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);

In this section is used the SqlCommand class as above, but, the type of the SqlCommand is “StoredProcedure” , so the sql code is not provided directly, but there is a procedure inside the database that makes the job. This procedure is called USP_SearchUserByNameNotVuln and accept a Varchar(50) parameter called @Name.
The code of the stored is simply:

CREATE PROCEDURE [dbo].[USP_SearchUserByNameNotVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
SELECT
U.Name,
U.Surname,
U.Code
FROM
dbo.Users U
WHERE
U.Name LIKE '''%' + @Name + '%'''
END

Three steps for each parameter passed to the stored procedure are needed to use the SqlParameter class:

* Instantiate the parameter with the right name and type used in the stored procedure
* Assign the value (in this case the value given by the user in the textbox)
* Add the parameter to the SqlCommand

When the sql command is executed, the parameters will be replaced with values specified by the SqlParameter object.

In conclusion, this kind of query is not prone to sql injection, because it is not possibile to build ad hoc sql statements, due to the correct use of Stored Procedure and the SqlParameter class.

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

This section is the same of the example above.

=== Input validation ===

Another point that is important to consider is the validation of the input. For example in a context in which a user has to insert (or select) some data in (or from) the database let’s think about the worst case, that is a user that can digit anything and submit anything to the server. To avoid this the only choiche is to validate the user's input. Two strategies are possible:

1. White list

2. Black list

The first solution answers at the condition: "deny all, except what is explicitly signed in the list".
The second solution answers at the condition: "allow all, except what is explicitly signed in the list".

The best solution for the security of the application is try to implement a validation of the input based on the first case. This comes more simply with numeric input, range input or strings that follow a specific pattern (for example an e-mail or a date). It becomes more difficult for strings with a not specific pattern (for example strings inserted in a search engine) in which often only a solution based on a black list is reasonably possible.

In a Web Application, there are two kinds of input validation:

1. client validations

2. server validations

There are a couple of reasons to use both types of validation summarized in the following points:

* client validations increase performance (the application doesn't postback to the server) but cause a false sense of security (the validation can be bypassed intercepting and manipulating the client request).
* server validations make worse performance but increase the security, because the validation is made by the server.

In ASP.NET to realize these concepts there are the server web control Validators:

* RequiredFieldValidator
* CompareValidator
* RangeValidator
* RegularExpressionValidator
* CustomValidator

Technically these objects realize both type of validations: that is if the client support Javascript, the Validator uses first the client validation, and after that the page is validated on then server side too. If the client doesn't support Javascript, the validation is made only on the server side. In this manner the application validate the input in a progressive mode and the design of the application doesn't follow a '' "Minimum-Denominator-Multiplier" ''.

To explain the concept in code, it's possible to analyze the CustomValidator, that is the higher generalization because it's possible to use a personalized validation logic.

=== CustomValidator ===

We can think symply to a textbox with a button, like the example above, in which it gives the way to search all the suppliers with a specific code (a string of 16 char) For security reasons it is imagined that a specific user can only see the suppliers that have a code in which the first 4 character are "PFHG".

Any other string that doesn't match this pattern has to be exclude from the search (white list approach)

[[Image:owasp_bsp_net_2.jpg]]

The XML part of the page is like that:

<asp:Label ID="lblQuerySearch" runat="server" Text="Digit the first four numbers"></asp:Label>
<asp:TextBox ID="txtQuerySearch" Width="5em" runat="server"></asp:TextBox>
<asp:RequiredFieldValidator ID="RequiredFieldValidatorQuerySearch" runat="server" ErrorMessage="Required Code"
ControlToValidate="txtQuerySearch"></asp:RequiredFieldValidator>
<asp:CustomValidator ID="CustomValidatorQuerySearch" runat="server" ErrorMessage="Wrong code"
ControlToValidate="txtQuerySearch" OnServerValidate="ValidateCode"></asp:CustomValidator>

The control Label and Button are intuitive web controls.
It's clear to see that two Validator have been applied to the textbox whose ID is '' "txtQuerySearch" ''.
The Validators are:

* RequiredFieldValidator: we don't accept an empty textbox when we submit our request to the server
* CustomValidator: we would implement some custom logic to our textbox

In fact the CustomValidator tag has a particular event called "OnServerValidate" that we can hook to a custom callback function, whose code is executed on the server side.
For this example it's like that:

protected void ValidateCode(object source, ServerValidateEventArgs args)
{
try
{
string textToValidate = args.Value;
if (textToValidate.Equals("PFHG"))
args.IsValid = true;
else
args.IsValid = false;
}
catch (Exception ex)
{
args.IsValid = false;
}
}

The function handles the argument "arg" that brings the text inserted by the user.
If this text match with our pattern, the argument is valid and the server executes the code associated to the button, querying the database in the same manner seen above; however the code is now conditioned by the statement "if(Page.IsValid)".

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
if (Page.IsValid)
{
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByCode", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pCode = new SqlParameter("@Code", SqlDbType.VarChar, 4);
pCode.Value = txtQuerySearch.Text;
cmd.Parameters.Add(pCode);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}
}

This is only an example but the use of the Validators can be very important in all the contexts in which the protection of a database from malicious input is needed.

== .NET Preventing LDAP Injection ==

It’s not important here to explain how LDAP works. The focus is explain how it’s possible to avoid the injection of special character, that are responsible of a unpredictable behaviour of the LDAP server.
LDAP search are often made with a distinguished name (DN) and a filter. So if the user input is not properly validated, the user can manipulate the input to craft a malicious filter, to obtain more informations from the server.
LDAP search are made with string, so the best solution to analyze a string searching particular characters is a Regular Expression.
In this example there is the code associated to a event ButtonClick, and two TextBox called "txtUid" and "txtSn" are used to give input to the system

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);
if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}
LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;
try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}
}

''' First Section '''

string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);

The first section uses a Regular Expression, using the class “RegExStringValidator”, very useful to analyze a string.
The string can contain only alphanumeric characters, @, blank or dot.
Others characters different from the indicated subset are not allowed, according to the white list approach.

''' Second Section '''

if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}

In this section there is the code to check if the strings inserted in the textbox “txtUid” and “txtSn” match the rule of the RegExp or not. There is a try-catch block and the object method "Validate" is used to make the job. If the validation passes, the catch block is not processed.

''' Third Section '''

LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;

The third section is the place for the connection to the server.

''' Fourth Section '''

try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}

Finally it's made the request and the server make the response, giving the number of entries that found

== Web.config Encryption ==

Web.config (and others file with .config extension) could contain sensitive informations that should be protected. For a .NET Web Application tipically the parameters to acces to a database are stored in plain text, in a form like this:

<configuration>
<connectionStrings>
<add name="Connection_SQLServer2005" connectionString="Data Source=WIN2K3\SQLInstance; Initial Catalog=Exampledb; User Id=user;
Password=clgir3s2s;" providerName=""/>
</connectionStrings>
</configuration>

It's possible to notice:

* Name of the server machine
* Name of the instance of SQL Server
* Name of the database
* Username
* Password

Gaining the access to directory of the web application, these informations are freely accessible.
The solution to mantain the confidentiality is always one: encryption.
Because encryption is not costless, it's not a good choice to encrypt the Web.config in its totality. It's better to select only the sensitive informations, that often are stored in the "configuration" sections of the file.
In .NET there are two mode to encrypt configuration section:

* Coding with some classes of the Framework
* Using the command line tool "aspnet_regiis.exe"

In both cases the encryption is potentially provided in three modes:

* Windows Data Protection API Provider (DPAPI)
* RSA Protected Configuration Provider
* Custom Provider

DPAPI is the simplest manner. It uses a machine (or user) level key storage, so it's possible to share the secret with all the applications of the machine or not. Additionally it uses an encryption mode based on the login of the user, storing the information in the registry, so no key creation needed. But if the application is deployed in a Web farm, the better is RSA protected configuration provider due to the ease with which RSA keys can be exported.

= References =

* http://msdn.microsoft.com/en-us/library/default.aspx
* http://msdn.microsoft.com/en-us/library/6759sth4.aspx
* http://directoryprogramming.net/
* http://msdn.microsoft.com/en-us/library/system.configuration.regexstringvalidator.aspx
* http://www.ietf.org/rfc/rfc2254.txt
* http://msdn.microsoft.com/en-us/library/az24scfc(VS.80).aspx

OWASP Backend Security Project .NET Security Programming

2008-07-05T16:36:29Z

GPederzini: /* Web.config Encryption */

= Overview =

In this section are explained the best solution to avoid two of the most dangerous vulnerabilities of web applications, the sql injection and ldap injection on .NET programming

It will be analized the interactions between a web application written in C# in ASP.NET technology, .NET Framework 2.0 and two kinds of data provider: a SQL Server 2005 data provider and an OpenLdap Server data provider.

For the first interaction imagine a database called “ExampleDB” in which there are some tables. One of these tables is “Users”. From a
web application is possible to query the database to extract information about the users through their name.

For the second interaction imagine an Ldap server called “ExampleLDAP”.

The project is simple and is made by some .aspx page with a textbox in which is possible to insert the name of the user and the program will return the information, reading from ExampleDB (or ExampleLDAP).
It's not important to specify how it's possible to create an aspx page So the focus is on the code that we have to write to interact with the server data provider.

= Description =

== .NET Preventing SQL Injection ==

Two approaches are likely: inline query or stored procedure.

[[Image:owasp_bsp_net_1.jpg]]

=== Case 1: Inline query ===

Inline queries are the queries in which is possible to compose a sql statement through string concatenation. By clicking on the first button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryInline_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%"
+ txtQueryInline.Text + "%'", sqlConnection);
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section of code provides the sqlConnection, reading the connectionString from the Web.Config file. This is an important task for the application because it represents the entry point to the database, the credentials of the user that can authenticate on the ExampleDB.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%" +
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;

In this section is used the SqlCommand class, in which is written the sql code, concatenating with the text to search. The type of the SqlCommand is “Text”, so it's clear that the sql code is provided directly. This code is prone to sql injection, because we can manipulate the statement, injecting in the textbox, for example, the string:

'' '; sql statement -- ''

where sql statement is any sql code (it is possible to drop tables, add users, reconfigure the xp_cmdshell, etc.)

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

The third section is useful to represent the result set of the query. It uses the ADO.NET “Dataset”, and an intermediate class called SqlDataAdapter, that adapts the sql data in a form that can be used by the Dataset Object.

It is possible to improve this query, using the second form of interaction that make use of a stored procedure

=== Case 2: Parametrized query + Stored Procedure vulnerable ===

By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStoredVuln_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStoredVuln.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

CREATE PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This kind of stored procedure are not rare. In this case is possible to compose the statement in many ways using parameters, function and so on.

Altough it is a parametrized query with a stored procedure, as the code shows, it is possible to inject the same string

'' '; sql statement -- ''

to inject a sql statement. Using the SQL Server function REPLACE, it is possible to “patch” the problem without rewrite the store procedure, replacing all the single quote with a couple of single quote.

ALTER PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @Name = REPLACE(@Name,'''','''''')
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This second case explains the fact that the use of parametrized query with stored procedure not always resolve the security flaws caused by sql injection.

=== Case 3: Parametrized query + Stored Procedure not vulnerable ===

It is possible to modify the way to execute the same query, using parametrized query in conjunction with stored procedures. By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStored_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section is the same of the example above.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);

In this section is used the SqlCommand class as above, but, the type of the SqlCommand is “StoredProcedure” , so the sql code is not provided directly, but there is a procedure inside the database that makes the job. This procedure is called USP_SearchUserByNameNotVuln and accept a Varchar(50) parameter called @Name.
The code of the stored is simply:

CREATE PROCEDURE [dbo].[USP_SearchUserByNameNotVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
SELECT
U.Name,
U.Surname,
U.Code
FROM
dbo.Users U
WHERE
U.Name LIKE '''%' + @Name + '%'''
END

Three steps for each parameter passed to the stored procedure are needed to use the SqlParameter class:

* Instantiate the parameter with the right name and type used in the stored procedure
* Assign the value (in this case the value given by the user in the textbox)
* Add the parameter to the SqlCommand

When the sql command is executed, the parameters will be replaced with values specified by the SqlParameter object.

In conclusion, this kind of query is not prone to sql injection, because it is not possibile to build ad hoc sql statements, due to the correct use of Stored Procedure and the SqlParameter class.

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

This section is the same of the example above.

=== Input validation ===

Another point that is important to consider is the validation of the input. For example in a context in which a user has to insert (or select) some data in (or from) the database let’s think about the worst case, that is a user that can digit anything and submit anything to the server. To avoid this the only choiche is to validate the user's input. Two strategies are possible:

1. White list

2. Black list

The first solution answers at the condition: "deny all, except what is explicitly signed in the list".
The second solution answers at the condition: "allow all, except what is explicitly signed in the list".

The best solution for the security of the application is try to implement a validation of the input based on the first case. This comes more simply with numeric input, range input or strings that follow a specific pattern (for example an e-mail or a date). It becomes more difficult for strings with a not specific pattern (for example strings inserted in a search engine) in which often only a solution based on a black list is reasonably possible.

In a Web Application, there are two kinds of input validation:

1. client validations

2. server validations

There are a couple of reasons to use both types of validation summarized in the following points:

* client validations increase performance (the application doesn't postback to the server) but cause a false sense of security (the validation can be bypassed intercepting and manipulating the client request).
* server validations make worse performance but increase the security, because the validation is made by the server.

In ASP.NET to realize these concepts there are the server web control Validators:

* RequiredFieldValidator
* CompareValidator
* RangeValidator
* RegularExpressionValidator
* CustomValidator

Technically these objects realize both type of validations: that is if the client support Javascript, the Validator uses first the client validation, and after that the page is validated on then server side too. If the client doesn't support Javascript, the validation is made only on the server side. In this manner the application validate the input in a progressive mode and the design of the application doesn't follow a '' "Minimum-Denominator-Multiplier" ''.

To explain the concept in code, it's possible to analyze the CustomValidator, that is the higher generalization because it's possible to use a personalized validation logic.

=== CustomValidator ===

We can think symply to a textbox with a button, like the example above, in which it gives the way to search all the suppliers with a specific code (a string of 16 char) For security reasons it is imagined that a specific user can only see the suppliers that have a code in which the first 4 character are "PFHG".

Any other string that doesn't match this pattern has to be exclude from the search (white list approach)

[[Image:owasp_bsp_net_2.jpg]]

The XML part of the page is like that:

<asp:Label ID="lblQuerySearch" runat="server" Text="Digit the first four numbers"></asp:Label>
<asp:TextBox ID="txtQuerySearch" Width="5em" runat="server"></asp:TextBox>
<asp:RequiredFieldValidator ID="RequiredFieldValidatorQuerySearch" runat="server" ErrorMessage="Required Code"
ControlToValidate="txtQuerySearch"></asp:RequiredFieldValidator>
<asp:CustomValidator ID="CustomValidatorQuerySearch" runat="server" ErrorMessage="Wrong code"
ControlToValidate="txtQuerySearch" OnServerValidate="ValidateCode"></asp:CustomValidator>

The control Label and Button are intuitive web controls.
It's clear to see that two Validator have been applied to the textbox whose ID is '' "txtQuerySearch" ''.
The Validators are:

* RequiredFieldValidator: we don't accept an empty textbox when we submit our request to the server
* CustomValidator: we would implement some custom logic to our textbox

In fact the CustomValidator tag has a particular event called "OnServerValidate" that we can hook to a custom callback function, whose code is executed on the server side.
For this example it's like that:

protected void ValidateCode(object source, ServerValidateEventArgs args)
{
try
{
string textToValidate = args.Value;
if (textToValidate.Equals("PFHG"))
args.IsValid = true;
else
args.IsValid = false;
}
catch (Exception ex)
{
args.IsValid = false;
}
}

The function handles the argument "arg" that brings the text inserted by the user.
If this text match with our pattern, the argument is valid and the server executes the code associated to the button, querying the database in the same manner seen above; however the code is now conditioned by the statement "if(Page.IsValid)".

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
if (Page.IsValid)
{
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByCode", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pCode = new SqlParameter("@Code", SqlDbType.VarChar, 4);
pCode.Value = txtQuerySearch.Text;
cmd.Parameters.Add(pCode);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}
}

This is only an example but the use of the Validators can be very important in all the contexts in which the protection of a database from malicious input is needed.

== .NET Preventing LDAP Injection ==

It’s not important here to explain how LDAP works. The focus is explain how it’s possible to avoid the injection of special character, that are responsible of a unpredictable behaviour of the LDAP server.
LDAP search are often made with a distinguished name (DN) and a filter. So if the user input is not properly validated, the user can manipulate the input to craft a malicious filter, to obtain more informations from the server.
LDAP search are made with string, so the best solution to analyze a string searching particular characters is a Regular Expression.
In this example there is the code associated to a event ButtonClick, and two TextBox called "txtUid" and "txtSn" are used to give input to the system

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);
if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}
LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;
try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}
}

''' First Section '''

string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);

The first section uses a Regular Expression, using the class “RegExStringValidator”, very useful to analyze a string.
The string can contain only alphanumeric characters, @, blank or dot.
Others characters different from the indicated subset are not allowed, according to the white list approach.

''' Second Section '''

if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}

In this section there is the code to check if the strings inserted in the textbox “txtUid” and “txtSn” match the rule of the RegExp or not. There is a try-catch block and the object method "Validate" is used to make the job. If the validation passes, the catch block is not processed.

''' Third Section '''

LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;

The third section is the place for the connection to the server.

''' Fourth Section '''

try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}

Finally it's made the request and the server make the response, giving the number of entries that found

== Web.config Encryption ==

Web.config (and others file with .config extension) could contain sensitive informations that should be protected. For a .NET Web Application tipically the parameters to acces to a database are stored in plain text, in a form like this:

<configuration>
<connectionStrings>
<add name="Connection_SQLServer2005" connectionString="Data Source=WIN2K3\SQLInstance; Initial Catalog=Exampledb; User Id=user;
Password=clgir3s2s;" providerName=""/>
</connectionStrings>
</configuration>

It's possible to notice:

* Name of the server machine
* Name of the instance of SQL Server
* Name of the database
* Username
* Password

Gaining the access to directory of the web application, these informations are freely accessible.
The solution to mantain the confidentiality is always one: encryption.
Because encryption is not costless, it's not a good choice to encrypt the Web.config in its totality. It's better to select only the sensitive informations, that often are stored in the "configuration" sections of the file.
In .NET there are two mode to encrypt configuration section:

* Coding with some classes of the Framework
* Using the command line tool "aspnet_regiis.exe"

In both cases the encryption is potentially provided in three modes:

* Windows Data Protection API Provider (DPAPI)
* RSA Protected Configuration Provider
* Custom Provider

DPAPI is the simplest manner. It uses a machine (or user) level key storage, so it's possible to share the secret with all the applications of the machine or not. But if the application is deployed in a Web farm, the better is RSA protected configuration provider due to the ease with which RSA keys can be exported.

= References =

* http://msdn.microsoft.com/en-us/library/default.aspx
* http://msdn.microsoft.com/en-us/library/6759sth4.aspx
* http://directoryprogramming.net/
* http://msdn.microsoft.com/en-us/library/system.configuration.regexstringvalidator.aspx
* http://www.ietf.org/rfc/rfc2254.txt
* http://msdn.microsoft.com/en-us/library/az24scfc(VS.80).aspx

OWASP Backend Security Project .NET Security Programming

2008-07-05T16:03:14Z

GPederzini: /* Web.config Encryption */

= Overview =

In this section are explained the best solution to avoid two of the most dangerous vulnerabilities of web applications, the sql injection and ldap injection on .NET programming

It will be analized the interactions between a web application written in C# in ASP.NET technology, .NET Framework 2.0 and two kinds of data provider: a SQL Server 2005 data provider and an OpenLdap Server data provider.

For the first interaction imagine a database called “ExampleDB” in which there are some tables. One of these tables is “Users”. From a
web application is possible to query the database to extract information about the users through their name.

For the second interaction imagine an Ldap server called “ExampleLDAP”.

The project is simple and is made by some .aspx page with a textbox in which is possible to insert the name of the user and the program will return the information, reading from ExampleDB (or ExampleLDAP).
It's not important to specify how it's possible to create an aspx page So the focus is on the code that we have to write to interact with the server data provider.

= Description =

== .NET Preventing SQL Injection ==

Two approaches are likely: inline query or stored procedure.

[[Image:owasp_bsp_net_1.jpg]]

=== Case 1: Inline query ===

Inline queries are the queries in which is possible to compose a sql statement through string concatenation. By clicking on the first button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryInline_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%"
+ txtQueryInline.Text + "%'", sqlConnection);
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section of code provides the sqlConnection, reading the connectionString from the Web.Config file. This is an important task for the application because it represents the entry point to the database, the credentials of the user that can authenticate on the ExampleDB.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%" +
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;

In this section is used the SqlCommand class, in which is written the sql code, concatenating with the text to search. The type of the SqlCommand is “Text”, so it's clear that the sql code is provided directly. This code is prone to sql injection, because we can manipulate the statement, injecting in the textbox, for example, the string:

'' '; sql statement -- ''

where sql statement is any sql code (it is possible to drop tables, add users, reconfigure the xp_cmdshell, etc.)

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

The third section is useful to represent the result set of the query. It uses the ADO.NET “Dataset”, and an intermediate class called SqlDataAdapter, that adapts the sql data in a form that can be used by the Dataset Object.

It is possible to improve this query, using the second form of interaction that make use of a stored procedure

=== Case 2: Parametrized query + Stored Procedure vulnerable ===

By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStoredVuln_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStoredVuln.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

CREATE PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This kind of stored procedure are not rare. In this case is possible to compose the statement in many ways using parameters, function and so on.

Altough it is a parametrized query with a stored procedure, as the code shows, it is possible to inject the same string

'' '; sql statement -- ''

to inject a sql statement. Using the SQL Server function REPLACE, it is possible to “patch” the problem without rewrite the store procedure, replacing all the single quote with a couple of single quote.

ALTER PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @Name = REPLACE(@Name,'''','''''')
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This second case explains the fact that the use of parametrized query with stored procedure not always resolve the security flaws caused by sql injection.

=== Case 3: Parametrized query + Stored Procedure not vulnerable ===

It is possible to modify the way to execute the same query, using parametrized query in conjunction with stored procedures. By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStored_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section is the same of the example above.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);

In this section is used the SqlCommand class as above, but, the type of the SqlCommand is “StoredProcedure” , so the sql code is not provided directly, but there is a procedure inside the database that makes the job. This procedure is called USP_SearchUserByNameNotVuln and accept a Varchar(50) parameter called @Name.
The code of the stored is simply:

CREATE PROCEDURE [dbo].[USP_SearchUserByNameNotVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
SELECT
U.Name,
U.Surname,
U.Code
FROM
dbo.Users U
WHERE
U.Name LIKE '''%' + @Name + '%'''
END

Three steps for each parameter passed to the stored procedure are needed to use the SqlParameter class:

* Instantiate the parameter with the right name and type used in the stored procedure
* Assign the value (in this case the value given by the user in the textbox)
* Add the parameter to the SqlCommand

When the sql command is executed, the parameters will be replaced with values specified by the SqlParameter object.

In conclusion, this kind of query is not prone to sql injection, because it is not possibile to build ad hoc sql statements, due to the correct use of Stored Procedure and the SqlParameter class.

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

This section is the same of the example above.

=== Input validation ===

Another point that is important to consider is the validation of the input. For example in a context in which a user has to insert (or select) some data in (or from) the database let’s think about the worst case, that is a user that can digit anything and submit anything to the server. To avoid this the only choiche is to validate the user's input. Two strategies are possible:

1. White list

2. Black list

The first solution answers at the condition: "deny all, except what is explicitly signed in the list".
The second solution answers at the condition: "allow all, except what is explicitly signed in the list".

The best solution for the security of the application is try to implement a validation of the input based on the first case. This comes more simply with numeric input, range input or strings that follow a specific pattern (for example an e-mail or a date). It becomes more difficult for strings with a not specific pattern (for example strings inserted in a search engine) in which often only a solution based on a black list is reasonably possible.

In a Web Application, there are two kinds of input validation:

1. client validations

2. server validations

There are a couple of reasons to use both types of validation summarized in the following points:

* client validations increase performance (the application doesn't postback to the server) but cause a false sense of security (the validation can be bypassed intercepting and manipulating the client request).
* server validations make worse performance but increase the security, because the validation is made by the server.

In ASP.NET to realize these concepts there are the server web control Validators:

* RequiredFieldValidator
* CompareValidator
* RangeValidator
* RegularExpressionValidator
* CustomValidator

Technically these objects realize both type of validations: that is if the client support Javascript, the Validator uses first the client validation, and after that the page is validated on then server side too. If the client doesn't support Javascript, the validation is made only on the server side. In this manner the application validate the input in a progressive mode and the design of the application doesn't follow a '' "Minimum-Denominator-Multiplier" ''.

To explain the concept in code, it's possible to analyze the CustomValidator, that is the higher generalization because it's possible to use a personalized validation logic.

=== CustomValidator ===

We can think symply to a textbox with a button, like the example above, in which it gives the way to search all the suppliers with a specific code (a string of 16 char) For security reasons it is imagined that a specific user can only see the suppliers that have a code in which the first 4 character are "PFHG".

Any other string that doesn't match this pattern has to be exclude from the search (white list approach)

[[Image:owasp_bsp_net_2.jpg]]

The XML part of the page is like that:

<asp:Label ID="lblQuerySearch" runat="server" Text="Digit the first four numbers"></asp:Label>
<asp:TextBox ID="txtQuerySearch" Width="5em" runat="server"></asp:TextBox>
<asp:RequiredFieldValidator ID="RequiredFieldValidatorQuerySearch" runat="server" ErrorMessage="Required Code"
ControlToValidate="txtQuerySearch"></asp:RequiredFieldValidator>
<asp:CustomValidator ID="CustomValidatorQuerySearch" runat="server" ErrorMessage="Wrong code"
ControlToValidate="txtQuerySearch" OnServerValidate="ValidateCode"></asp:CustomValidator>

The control Label and Button are intuitive web controls.
It's clear to see that two Validator have been applied to the textbox whose ID is '' "txtQuerySearch" ''.
The Validators are:

* RequiredFieldValidator: we don't accept an empty textbox when we submit our request to the server
* CustomValidator: we would implement some custom logic to our textbox

In fact the CustomValidator tag has a particular event called "OnServerValidate" that we can hook to a custom callback function, whose code is executed on the server side.
For this example it's like that:

protected void ValidateCode(object source, ServerValidateEventArgs args)
{
try
{
string textToValidate = args.Value;
if (textToValidate.Equals("PFHG"))
args.IsValid = true;
else
args.IsValid = false;
}
catch (Exception ex)
{
args.IsValid = false;
}
}

The function handles the argument "arg" that brings the text inserted by the user.
If this text match with our pattern, the argument is valid and the server executes the code associated to the button, querying the database in the same manner seen above; however the code is now conditioned by the statement "if(Page.IsValid)".

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
if (Page.IsValid)
{
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByCode", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pCode = new SqlParameter("@Code", SqlDbType.VarChar, 4);
pCode.Value = txtQuerySearch.Text;
cmd.Parameters.Add(pCode);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}
}

This is only an example but the use of the Validators can be very important in all the contexts in which the protection of a database from malicious input is needed.

== .NET Preventing LDAP Injection ==

It’s not important here to explain how LDAP works. The focus is explain how it’s possible to avoid the injection of special character, that are responsible of a unpredictable behaviour of the LDAP server.
LDAP search are often made with a distinguished name (DN) and a filter. So if the user input is not properly validated, the user can manipulate the input to craft a malicious filter, to obtain more informations from the server.
LDAP search are made with string, so the best solution to analyze a string searching particular characters is a Regular Expression.
In this example there is the code associated to a event ButtonClick, and two TextBox called "txtUid" and "txtSn" are used to give input to the system

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);
if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}
LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;
try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}
}

''' First Section '''

string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);

The first section uses a Regular Expression, using the class “RegExStringValidator”, very useful to analyze a string.
The string can contain only alphanumeric characters, @, blank or dot.
Others characters different from the indicated subset are not allowed, according to the white list approach.

''' Second Section '''

if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}

In this section there is the code to check if the strings inserted in the textbox “txtUid” and “txtSn” match the rule of the RegExp or not. There is a try-catch block and the object method "Validate" is used to make the job. If the validation passes, the catch block is not processed.

''' Third Section '''

LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;

The third section is the place for the connection to the server.

''' Fourth Section '''

try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}

Finally it's made the request and the server make the response, giving the number of entries that found

== Web.config Encryption ==

Web.config (and others file with .config extension) could contain sensitive informations that should be protected. For a .NET Web Application tipically the parameters to acces to a database are stored in plain text, in a form like this:

<configuration>
<connectionStrings>
<add name="Connection_SQLServer2005" connectionString="Data Source=WIN2K3\SQLInstance; Initial Catalog=Exampledb; User Id=user;
Password=clgir3s2s;" providerName=""/>
</connectionStrings>
</configuration>

It's possible to notice:

* Name of the server machine
* Name of the instance of SQL Server
* Name of the database
* Username
* Password

Gaining the access to the virtual directory of the web application, these informations are freely accessible.
The solution to mantain the confidentiality is always one: encryption.
Because encryption is not costless, it's not a good choice to encrypt the Web.config in its totality. It's better to select only the sensitive informations, that often are stored in the "configuration" sections of the file.
In .NET there are two mode to encrypt configuration section:

* Coding with some classes of the Framework
* Using the command line tool "aspnet_regiis.exe"

In both cases the encryption is potentially provided by two elements:

* Windows Data Protection API Provider (DPAPI)
* RSA Protected Configuration Provider

= References =

* http://msdn.microsoft.com/en-us/library/default.aspx
* http://msdn.microsoft.com/en-us/library/6759sth4.aspx
* http://directoryprogramming.net/
* http://msdn.microsoft.com/en-us/library/system.configuration.regexstringvalidator.aspx
* http://www.ietf.org/rfc/rfc2254.txt
* http://msdn.microsoft.com/en-us/library/az24scfc(VS.80).aspx

OWASP Backend Security Project .NET Security Programming

2008-07-05T15:47:35Z

GPederzini: /* Web.config Encryption */

= Overview =

In this section are explained the best solution to avoid two of the most dangerous vulnerabilities of web applications, the sql injection and ldap injection on .NET programming

It will be analized the interactions between a web application written in C# in ASP.NET technology, .NET Framework 2.0 and two kinds of data provider: a SQL Server 2005 data provider and an OpenLdap Server data provider.

For the first interaction imagine a database called “ExampleDB” in which there are some tables. One of these tables is “Users”. From a
web application is possible to query the database to extract information about the users through their name.

For the second interaction imagine an Ldap server called “ExampleLDAP”.

The project is simple and is made by some .aspx page with a textbox in which is possible to insert the name of the user and the program will return the information, reading from ExampleDB (or ExampleLDAP).
It's not important to specify how it's possible to create an aspx page So the focus is on the code that we have to write to interact with the server data provider.

= Description =

== .NET Preventing SQL Injection ==

Two approaches are likely: inline query or stored procedure.

[[Image:owasp_bsp_net_1.jpg]]

=== Case 1: Inline query ===

Inline queries are the queries in which is possible to compose a sql statement through string concatenation. By clicking on the first button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryInline_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%"
+ txtQueryInline.Text + "%'", sqlConnection);
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section of code provides the sqlConnection, reading the connectionString from the Web.Config file. This is an important task for the application because it represents the entry point to the database, the credentials of the user that can authenticate on the ExampleDB.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%" +
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;

In this section is used the SqlCommand class, in which is written the sql code, concatenating with the text to search. The type of the SqlCommand is “Text”, so it's clear that the sql code is provided directly. This code is prone to sql injection, because we can manipulate the statement, injecting in the textbox, for example, the string:

'' '; sql statement -- ''

where sql statement is any sql code (it is possible to drop tables, add users, reconfigure the xp_cmdshell, etc.)

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

The third section is useful to represent the result set of the query. It uses the ADO.NET “Dataset”, and an intermediate class called SqlDataAdapter, that adapts the sql data in a form that can be used by the Dataset Object.

It is possible to improve this query, using the second form of interaction that make use of a stored procedure

=== Case 2: Parametrized query + Stored Procedure vulnerable ===

By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStoredVuln_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStoredVuln.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

CREATE PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This kind of stored procedure are not rare. In this case is possible to compose the statement in many ways using parameters, function and so on.

Altough it is a parametrized query with a stored procedure, as the code shows, it is possible to inject the same string

'' '; sql statement -- ''

to inject a sql statement. Using the SQL Server function REPLACE, it is possible to “patch” the problem without rewrite the store procedure, replacing all the single quote with a couple of single quote.

ALTER PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @Name = REPLACE(@Name,'''','''''')
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This second case explains the fact that the use of parametrized query with stored procedure not always resolve the security flaws caused by sql injection.

=== Case 3: Parametrized query + Stored Procedure not vulnerable ===

It is possible to modify the way to execute the same query, using parametrized query in conjunction with stored procedures. By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStored_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section is the same of the example above.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);

In this section is used the SqlCommand class as above, but, the type of the SqlCommand is “StoredProcedure” , so the sql code is not provided directly, but there is a procedure inside the database that makes the job. This procedure is called USP_SearchUserByNameNotVuln and accept a Varchar(50) parameter called @Name.
The code of the stored is simply:

CREATE PROCEDURE [dbo].[USP_SearchUserByNameNotVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
SELECT
U.Name,
U.Surname,
U.Code
FROM
dbo.Users U
WHERE
U.Name LIKE '''%' + @Name + '%'''
END

Three steps for each parameter passed to the stored procedure are needed to use the SqlParameter class:

* Instantiate the parameter with the right name and type used in the stored procedure
* Assign the value (in this case the value given by the user in the textbox)
* Add the parameter to the SqlCommand

When the sql command is executed, the parameters will be replaced with values specified by the SqlParameter object.

In conclusion, this kind of query is not prone to sql injection, because it is not possibile to build ad hoc sql statements, due to the correct use of Stored Procedure and the SqlParameter class.

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

This section is the same of the example above.

=== Input validation ===

Another point that is important to consider is the validation of the input. For example in a context in which a user has to insert (or select) some data in (or from) the database let’s think about the worst case, that is a user that can digit anything and submit anything to the server. To avoid this the only choiche is to validate the user's input. Two strategies are possible:

1. White list

2. Black list

The first solution answers at the condition: "deny all, except what is explicitly signed in the list".
The second solution answers at the condition: "allow all, except what is explicitly signed in the list".

The best solution for the security of the application is try to implement a validation of the input based on the first case. This comes more simply with numeric input, range input or strings that follow a specific pattern (for example an e-mail or a date). It becomes more difficult for strings with a not specific pattern (for example strings inserted in a search engine) in which often only a solution based on a black list is reasonably possible.

In a Web Application, there are two kinds of input validation:

1. client validations

2. server validations

There are a couple of reasons to use both types of validation summarized in the following points:

* client validations increase performance (the application doesn't postback to the server) but cause a false sense of security (the validation can be bypassed intercepting and manipulating the client request).
* server validations make worse performance but increase the security, because the validation is made by the server.

In ASP.NET to realize these concepts there are the server web control Validators:

* RequiredFieldValidator
* CompareValidator
* RangeValidator
* RegularExpressionValidator
* CustomValidator

Technically these objects realize both type of validations: that is if the client support Javascript, the Validator uses first the client validation, and after that the page is validated on then server side too. If the client doesn't support Javascript, the validation is made only on the server side. In this manner the application validate the input in a progressive mode and the design of the application doesn't follow a '' "Minimum-Denominator-Multiplier" ''.

To explain the concept in code, it's possible to analyze the CustomValidator, that is the higher generalization because it's possible to use a personalized validation logic.

=== CustomValidator ===

We can think symply to a textbox with a button, like the example above, in which it gives the way to search all the suppliers with a specific code (a string of 16 char) For security reasons it is imagined that a specific user can only see the suppliers that have a code in which the first 4 character are "PFHG".

Any other string that doesn't match this pattern has to be exclude from the search (white list approach)

[[Image:owasp_bsp_net_2.jpg]]

The XML part of the page is like that:

<asp:Label ID="lblQuerySearch" runat="server" Text="Digit the first four numbers"></asp:Label>
<asp:TextBox ID="txtQuerySearch" Width="5em" runat="server"></asp:TextBox>
<asp:RequiredFieldValidator ID="RequiredFieldValidatorQuerySearch" runat="server" ErrorMessage="Required Code"
ControlToValidate="txtQuerySearch"></asp:RequiredFieldValidator>
<asp:CustomValidator ID="CustomValidatorQuerySearch" runat="server" ErrorMessage="Wrong code"
ControlToValidate="txtQuerySearch" OnServerValidate="ValidateCode"></asp:CustomValidator>

The control Label and Button are intuitive web controls.
It's clear to see that two Validator have been applied to the textbox whose ID is '' "txtQuerySearch" ''.
The Validators are:

* RequiredFieldValidator: we don't accept an empty textbox when we submit our request to the server
* CustomValidator: we would implement some custom logic to our textbox

In fact the CustomValidator tag has a particular event called "OnServerValidate" that we can hook to a custom callback function, whose code is executed on the server side.
For this example it's like that:

protected void ValidateCode(object source, ServerValidateEventArgs args)
{
try
{
string textToValidate = args.Value;
if (textToValidate.Equals("PFHG"))
args.IsValid = true;
else
args.IsValid = false;
}
catch (Exception ex)
{
args.IsValid = false;
}
}

The function handles the argument "arg" that brings the text inserted by the user.
If this text match with our pattern, the argument is valid and the server executes the code associated to the button, querying the database in the same manner seen above; however the code is now conditioned by the statement "if(Page.IsValid)".

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
if (Page.IsValid)
{
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByCode", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pCode = new SqlParameter("@Code", SqlDbType.VarChar, 4);
pCode.Value = txtQuerySearch.Text;
cmd.Parameters.Add(pCode);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}
}

This is only an example but the use of the Validators can be very important in all the contexts in which the protection of a database from malicious input is needed.

== .NET Preventing LDAP Injection ==

It’s not important here to explain how LDAP works. The focus is explain how it’s possible to avoid the injection of special character, that are responsible of a unpredictable behaviour of the LDAP server.
LDAP search are often made with a distinguished name (DN) and a filter. So if the user input is not properly validated, the user can manipulate the input to craft a malicious filter, to obtain more informations from the server.
LDAP search are made with string, so the best solution to analyze a string searching particular characters is a Regular Expression.
In this example there is the code associated to a event ButtonClick, and two TextBox called "txtUid" and "txtSn" are used to give input to the system

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);
if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}
LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;
try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}
}

''' First Section '''

string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);

The first section uses a Regular Expression, using the class “RegExStringValidator”, very useful to analyze a string.
The string can contain only alphanumeric characters, @, blank or dot.
Others characters different from the indicated subset are not allowed, according to the white list approach.

''' Second Section '''

if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}

In this section there is the code to check if the strings inserted in the textbox “txtUid” and “txtSn” match the rule of the RegExp or not. There is a try-catch block and the object method "Validate" is used to make the job. If the validation passes, the catch block is not processed.

''' Third Section '''

LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;

The third section is the place for the connection to the server.

''' Fourth Section '''

try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}

Finally it's made the request and the server make the response, giving the number of entries that found

== Web.config Encryption ==

Web.config (and others file with .config extension) could contain sensitive informations that should be protected. For a .NET Web Application tipically the parameters to acces to a database are stored in plain text, in a form like this:

<configuration>
<connectionStrings>
<add name="Connection_SQLServer2005" connectionString="Data Source=WIN2K3\SQLInstance; Initial Catalog=Exampledb; User Id=user;
Password=clgir3s2s;" providerName=""/>
</connectionStrings>
</configuration>

It's possible to notice:

* Name of the server machine
* Name of the instance of SQL Server
* Name of the database
* Username
* Password

Gaining the access to the virtual directory of the web application, these informations are freely accessible.
The solution to mantain the confidentiality is always one: encryption.
Because encryption is not costless, it's not a good choice to encrypt the Web.config in its totality. It's better to select only the sensitive informations, that often are stored in the "configuration" sections of the file.
In .NET there are two mode to encrypt configuration section:

* Coding with some classes of the Framework
* Using the command line tool "aspnet_regiis.exe"

= References =

* http://msdn.microsoft.com/en-us/library/default.aspx
* http://msdn.microsoft.com/en-us/library/6759sth4.aspx
* http://directoryprogramming.net/
* http://msdn.microsoft.com/en-us/library/system.configuration.regexstringvalidator.aspx
* http://www.ietf.org/rfc/rfc2254.txt
* http://msdn.microsoft.com/en-us/library/az24scfc(VS.80).aspx

OWASP Backend Security Project .NET Security Programming

2008-07-05T14:00:01Z

GPederzini: /* Web.config Encryption */

= Overview =

In this section are explained the best solution to avoid two of the most dangerous vulnerabilities of web applications, the sql injection and ldap injection on .NET programming

It will be analized the interactions between a web application written in C# in ASP.NET technology, .NET Framework 2.0 and two kinds of data provider: a SQL Server 2005 data provider and an OpenLdap Server data provider.

For the first interaction imagine a database called “ExampleDB” in which there are some tables. One of these tables is “Users”. From a
web application is possible to query the database to extract information about the users through their name.

For the second interaction imagine an Ldap server called “ExampleLDAP”.

The project is simple and is made by some .aspx page with a textbox in which is possible to insert the name of the user and the program will return the information, reading from ExampleDB (or ExampleLDAP).
It's not important to specify how it's possible to create an aspx page So the focus is on the code that we have to write to interact with the server data provider.

= Description =

== .NET Preventing SQL Injection ==

Two approaches are likely: inline query or stored procedure.

[[Image:owasp_bsp_net_1.jpg]]

=== Case 1: Inline query ===

Inline queries are the queries in which is possible to compose a sql statement through string concatenation. By clicking on the first button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryInline_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%"
+ txtQueryInline.Text + "%'", sqlConnection);
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section of code provides the sqlConnection, reading the connectionString from the Web.Config file. This is an important task for the application because it represents the entry point to the database, the credentials of the user that can authenticate on the ExampleDB.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%" +
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;

In this section is used the SqlCommand class, in which is written the sql code, concatenating with the text to search. The type of the SqlCommand is “Text”, so it's clear that the sql code is provided directly. This code is prone to sql injection, because we can manipulate the statement, injecting in the textbox, for example, the string:

'' '; sql statement -- ''

where sql statement is any sql code (it is possible to drop tables, add users, reconfigure the xp_cmdshell, etc.)

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

The third section is useful to represent the result set of the query. It uses the ADO.NET “Dataset”, and an intermediate class called SqlDataAdapter, that adapts the sql data in a form that can be used by the Dataset Object.

It is possible to improve this query, using the second form of interaction that make use of a stored procedure

=== Case 2: Parametrized query + Stored Procedure vulnerable ===

By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStoredVuln_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStoredVuln.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

CREATE PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This kind of stored procedure are not rare. In this case is possible to compose the statement in many ways using parameters, function and so on.

Altough it is a parametrized query with a stored procedure, as the code shows, it is possible to inject the same string

'' '; sql statement -- ''

to inject a sql statement. Using the SQL Server function REPLACE, it is possible to “patch” the problem without rewrite the store procedure, replacing all the single quote with a couple of single quote.

ALTER PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @Name = REPLACE(@Name,'''','''''')
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This second case explains the fact that the use of parametrized query with stored procedure not always resolve the security flaws caused by sql injection.

=== Case 3: Parametrized query + Stored Procedure not vulnerable ===

It is possible to modify the way to execute the same query, using parametrized query in conjunction with stored procedures. By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStored_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section is the same of the example above.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);

In this section is used the SqlCommand class as above, but, the type of the SqlCommand is “StoredProcedure” , so the sql code is not provided directly, but there is a procedure inside the database that makes the job. This procedure is called USP_SearchUserByNameNotVuln and accept a Varchar(50) parameter called @Name.
The code of the stored is simply:

CREATE PROCEDURE [dbo].[USP_SearchUserByNameNotVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
SELECT
U.Name,
U.Surname,
U.Code
FROM
dbo.Users U
WHERE
U.Name LIKE '''%' + @Name + '%'''
END

Three steps for each parameter passed to the stored procedure are needed to use the SqlParameter class:

* Instantiate the parameter with the right name and type used in the stored procedure
* Assign the value (in this case the value given by the user in the textbox)
* Add the parameter to the SqlCommand

When the sql command is executed, the parameters will be replaced with values specified by the SqlParameter object.

In conclusion, this kind of query is not prone to sql injection, because it is not possibile to build ad hoc sql statements, due to the correct use of Stored Procedure and the SqlParameter class.

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

This section is the same of the example above.

=== Input validation ===

Another point that is important to consider is the validation of the input. For example in a context in which a user has to insert (or select) some data in (or from) the database let’s think about the worst case, that is a user that can digit anything and submit anything to the server. To avoid this the only choiche is to validate the user's input. Two strategies are possible:

1. White list

2. Black list

The first solution answers at the condition: "deny all, except what is explicitly signed in the list".
The second solution answers at the condition: "allow all, except what is explicitly signed in the list".

The best solution for the security of the application is try to implement a validation of the input based on the first case. This comes more simply with numeric input, range input or strings that follow a specific pattern (for example an e-mail or a date). It becomes more difficult for strings with a not specific pattern (for example strings inserted in a search engine) in which often only a solution based on a black list is reasonably possible.

In a Web Application, there are two kinds of input validation:

1. client validations

2. server validations

There are a couple of reasons to use both types of validation summarized in the following points:

* client validations increase performance (the application doesn't postback to the server) but cause a false sense of security (the validation can be bypassed intercepting and manipulating the client request).
* server validations make worse performance but increase the security, because the validation is made by the server.

In ASP.NET to realize these concepts there are the server web control Validators:

* RequiredFieldValidator
* CompareValidator
* RangeValidator
* RegularExpressionValidator
* CustomValidator

Technically these objects realize both type of validations: that is if the client support Javascript, the Validator uses first the client validation, and after that the page is validated on then server side too. If the client doesn't support Javascript, the validation is made only on the server side. In this manner the application validate the input in a progressive mode and the design of the application doesn't follow a '' "Minimum-Denominator-Multiplier" ''.

To explain the concept in code, it's possible to analyze the CustomValidator, that is the higher generalization because it's possible to use a personalized validation logic.

=== CustomValidator ===

We can think symply to a textbox with a button, like the example above, in which it gives the way to search all the suppliers with a specific code (a string of 16 char) For security reasons it is imagined that a specific user can only see the suppliers that have a code in which the first 4 character are "PFHG".

Any other string that doesn't match this pattern has to be exclude from the search (white list approach)

[[Image:owasp_bsp_net_2.jpg]]

The XML part of the page is like that:

<asp:Label ID="lblQuerySearch" runat="server" Text="Digit the first four numbers"></asp:Label>
<asp:TextBox ID="txtQuerySearch" Width="5em" runat="server"></asp:TextBox>
<asp:RequiredFieldValidator ID="RequiredFieldValidatorQuerySearch" runat="server" ErrorMessage="Required Code"
ControlToValidate="txtQuerySearch"></asp:RequiredFieldValidator>
<asp:CustomValidator ID="CustomValidatorQuerySearch" runat="server" ErrorMessage="Wrong code"
ControlToValidate="txtQuerySearch" OnServerValidate="ValidateCode"></asp:CustomValidator>

The control Label and Button are intuitive web controls.
It's clear to see that two Validator have been applied to the textbox whose ID is '' "txtQuerySearch" ''.
The Validators are:

* RequiredFieldValidator: we don't accept an empty textbox when we submit our request to the server
* CustomValidator: we would implement some custom logic to our textbox

In fact the CustomValidator tag has a particular event called "OnServerValidate" that we can hook to a custom callback function, whose code is executed on the server side.
For this example it's like that:

protected void ValidateCode(object source, ServerValidateEventArgs args)
{
try
{
string textToValidate = args.Value;
if (textToValidate.Equals("PFHG"))
args.IsValid = true;
else
args.IsValid = false;
}
catch (Exception ex)
{
args.IsValid = false;
}
}

The function handles the argument "arg" that brings the text inserted by the user.
If this text match with our pattern, the argument is valid and the server executes the code associated to the button, querying the database in the same manner seen above; however the code is now conditioned by the statement "if(Page.IsValid)".

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
if (Page.IsValid)
{
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByCode", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pCode = new SqlParameter("@Code", SqlDbType.VarChar, 4);
pCode.Value = txtQuerySearch.Text;
cmd.Parameters.Add(pCode);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}
}

This is only an example but the use of the Validators can be very important in all the contexts in which the protection of a database from malicious input is needed.

== .NET Preventing LDAP Injection ==

It’s not important here to explain how LDAP works. The focus is explain how it’s possible to avoid the injection of special character, that are responsible of a unpredictable behaviour of the LDAP server.
LDAP search are often made with a distinguished name (DN) and a filter. So if the user input is not properly validated, the user can manipulate the input to craft a malicious filter, to obtain more informations from the server.
LDAP search are made with string, so the best solution to analyze a string searching particular characters is a Regular Expression.
In this example there is the code associated to a event ButtonClick, and two TextBox called "txtUid" and "txtSn" are used to give input to the system

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);
if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}
LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;
try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}
}

''' First Section '''

string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);

The first section uses a Regular Expression, using the class “RegExStringValidator”, very useful to analyze a string.
The string can contain only alphanumeric characters, @, blank or dot.
Others characters different from the indicated subset are not allowed, according to the white list approach.

''' Second Section '''

if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}

In this section there is the code to check if the strings inserted in the textbox “txtUid” and “txtSn” match the rule of the RegExp or not. There is a try-catch block and the object method "Validate" is used to make the job. If the validation passes, the catch block is not processed.

''' Third Section '''

LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;

The third section is the place for the connection to the server.

''' Fourth Section '''

try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}

Finally it's made the request and the server make the response, giving the number of entries that found

== Web.config Encryption ==

Web.config (and others file with .config extension) could contain sensitive informations that should be protected. For a Web Application tipically the parameter configuration to acces to a database are stored in plain text, in a form like this:

<configuration>
<connectionStrings>
<add name="Connection_SQLServer2005" connectionString="Data Source=WIN2K3\SQLInstance; Initial Catalog=Exampledb; User Id=user;
Password=clgir3s2s;" providerName=""/>
</connectionStrings>
</configuration>

= References =

* http://msdn.microsoft.com/en-us/library/default.aspx
* http://msdn.microsoft.com/en-us/library/6759sth4.aspx
* http://directoryprogramming.net/
* http://msdn.microsoft.com/en-us/library/system.configuration.regexstringvalidator.aspx
* http://www.ietf.org/rfc/rfc2254.txt
* http://msdn.microsoft.com/en-us/library/az24scfc(VS.80).aspx

OWASP Backend Security Project .NET Security Programming

2008-07-05T13:57:41Z

GPederzini: /* Web.config Encryption */

= Overview =

In this section are explained the best solution to avoid two of the most dangerous vulnerabilities of web applications, the sql injection and ldap injection on .NET programming

It will be analized the interactions between a web application written in C# in ASP.NET technology, .NET Framework 2.0 and two kinds of data provider: a SQL Server 2005 data provider and an OpenLdap Server data provider.

For the first interaction imagine a database called “ExampleDB” in which there are some tables. One of these tables is “Users”. From a
web application is possible to query the database to extract information about the users through their name.

For the second interaction imagine an Ldap server called “ExampleLDAP”.

The project is simple and is made by some .aspx page with a textbox in which is possible to insert the name of the user and the program will return the information, reading from ExampleDB (or ExampleLDAP).
It's not important to specify how it's possible to create an aspx page So the focus is on the code that we have to write to interact with the server data provider.

= Description =

== .NET Preventing SQL Injection ==

Two approaches are likely: inline query or stored procedure.

[[Image:owasp_bsp_net_1.jpg]]

=== Case 1: Inline query ===

Inline queries are the queries in which is possible to compose a sql statement through string concatenation. By clicking on the first button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryInline_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%"
+ txtQueryInline.Text + "%'", sqlConnection);
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section of code provides the sqlConnection, reading the connectionString from the Web.Config file. This is an important task for the application because it represents the entry point to the database, the credentials of the user that can authenticate on the ExampleDB.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("select Name,Surname,Code from dbo.Users where Name LIKE '%" +
txtQueryInline.Text + "%'", sqlConnection);
cmd.CommandType = CommandType.Text;

In this section is used the SqlCommand class, in which is written the sql code, concatenating with the text to search. The type of the SqlCommand is “Text”, so it's clear that the sql code is provided directly. This code is prone to sql injection, because we can manipulate the statement, injecting in the textbox, for example, the string:

'' '; sql statement -- ''

where sql statement is any sql code (it is possible to drop tables, add users, reconfigure the xp_cmdshell, etc.)

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

The third section is useful to represent the result set of the query. It uses the ADO.NET “Dataset”, and an intermediate class called SqlDataAdapter, that adapts the sql data in a form that can be used by the Dataset Object.

It is possible to improve this query, using the second form of interaction that make use of a stored procedure

=== Case 2: Parametrized query + Stored Procedure vulnerable ===

By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStoredVuln_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStoredVuln.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

CREATE PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This kind of stored procedure are not rare. In this case is possible to compose the statement in many ways using parameters, function and so on.

Altough it is a parametrized query with a stored procedure, as the code shows, it is possible to inject the same string

'' '; sql statement -- ''

to inject a sql statement. Using the SQL Server function REPLACE, it is possible to “patch” the problem without rewrite the store procedure, replacing all the single quote with a couple of single quote.

ALTER PROCEDURE [dbo].[USP_SearchUserByNameVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
DECLARE @StrSQL varchar(max)
SET @Name = REPLACE(@Name,'''','''''')
SET @StrSQL =
'SELECT U.Name,U.Surname,U.Code
FROM dbo.Users U
WHERE U.Name LIKE ' + '''%'+ @Name+ '%'''
EXEC (@StrSql)
END

This second case explains the fact that the use of parametrized query with stored procedure not always resolve the security flaws caused by sql injection.

=== Case 3: Parametrized query + Stored Procedure not vulnerable ===

It is possible to modify the way to execute the same query, using parametrized query in conjunction with stored procedures. By clicking on the second button, the execution of the OnClick event is generated, doing the following:

protected void btnQueryStored_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if(sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}

''' First Section: '''

DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);

This section is the same of the example above.

''' Second Section: '''

sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByNameNotVuln", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pName = new SqlParameter("@Name", SqlDbType.VarChar, 50);
pName.Value = txtQueryStored.Text;
cmd.Parameters.Add(pName);

In this section is used the SqlCommand class as above, but, the type of the SqlCommand is “StoredProcedure” , so the sql code is not provided directly, but there is a procedure inside the database that makes the job. This procedure is called USP_SearchUserByNameNotVuln and accept a Varchar(50) parameter called @Name.
The code of the stored is simply:

CREATE PROCEDURE [dbo].[USP_SearchUserByNameNotVuln]
@Name varchar(50)
AS
BEGIN
SET NOCOUNT ON;
SELECT
U.Name,
U.Surname,
U.Code
FROM
dbo.Users U
WHERE
U.Name LIKE '''%' + @Name + '%'''
END

Three steps for each parameter passed to the stored procedure are needed to use the SqlParameter class:

* Instantiate the parameter with the right name and type used in the stored procedure
* Assign the value (in this case the value given by the user in the textbox)
* Add the parameter to the SqlCommand

When the sql command is executed, the parameters will be replaced with values specified by the SqlParameter object.

In conclusion, this kind of query is not prone to sql injection, because it is not possibile to build ad hoc sql statements, due to the correct use of Stored Procedure and the SqlParameter class.

''' Third Section: '''

DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();

This section is the same of the example above.

=== Input validation ===

Another point that is important to consider is the validation of the input. For example in a context in which a user has to insert (or select) some data in (or from) the database let’s think about the worst case, that is a user that can digit anything and submit anything to the server. To avoid this the only choiche is to validate the user's input. Two strategies are possible:

1. White list

2. Black list

The first solution answers at the condition: "deny all, except what is explicitly signed in the list".
The second solution answers at the condition: "allow all, except what is explicitly signed in the list".

The best solution for the security of the application is try to implement a validation of the input based on the first case. This comes more simply with numeric input, range input or strings that follow a specific pattern (for example an e-mail or a date). It becomes more difficult for strings with a not specific pattern (for example strings inserted in a search engine) in which often only a solution based on a black list is reasonably possible.

In a Web Application, there are two kinds of input validation:

1. client validations

2. server validations

There are a couple of reasons to use both types of validation summarized in the following points:

* client validations increase performance (the application doesn't postback to the server) but cause a false sense of security (the validation can be bypassed intercepting and manipulating the client request).
* server validations make worse performance but increase the security, because the validation is made by the server.

In ASP.NET to realize these concepts there are the server web control Validators:

* RequiredFieldValidator
* CompareValidator
* RangeValidator
* RegularExpressionValidator
* CustomValidator

Technically these objects realize both type of validations: that is if the client support Javascript, the Validator uses first the client validation, and after that the page is validated on then server side too. If the client doesn't support Javascript, the validation is made only on the server side. In this manner the application validate the input in a progressive mode and the design of the application doesn't follow a '' "Minimum-Denominator-Multiplier" ''.

To explain the concept in code, it's possible to analyze the CustomValidator, that is the higher generalization because it's possible to use a personalized validation logic.

=== CustomValidator ===

We can think symply to a textbox with a button, like the example above, in which it gives the way to search all the suppliers with a specific code (a string of 16 char) For security reasons it is imagined that a specific user can only see the suppliers that have a code in which the first 4 character are "PFHG".

Any other string that doesn't match this pattern has to be exclude from the search (white list approach)

[[Image:owasp_bsp_net_2.jpg]]

The XML part of the page is like that:

<asp:Label ID="lblQuerySearch" runat="server" Text="Digit the first four numbers"></asp:Label>
<asp:TextBox ID="txtQuerySearch" Width="5em" runat="server"></asp:TextBox>
<asp:RequiredFieldValidator ID="RequiredFieldValidatorQuerySearch" runat="server" ErrorMessage="Required Code"
ControlToValidate="txtQuerySearch"></asp:RequiredFieldValidator>
<asp:CustomValidator ID="CustomValidatorQuerySearch" runat="server" ErrorMessage="Wrong code"
ControlToValidate="txtQuerySearch" OnServerValidate="ValidateCode"></asp:CustomValidator>

The control Label and Button are intuitive web controls.
It's clear to see that two Validator have been applied to the textbox whose ID is '' "txtQuerySearch" ''.
The Validators are:

* RequiredFieldValidator: we don't accept an empty textbox when we submit our request to the server
* CustomValidator: we would implement some custom logic to our textbox

In fact the CustomValidator tag has a particular event called "OnServerValidate" that we can hook to a custom callback function, whose code is executed on the server side.
For this example it's like that:

protected void ValidateCode(object source, ServerValidateEventArgs args)
{
try
{
string textToValidate = args.Value;
if (textToValidate.Equals("PFHG"))
args.IsValid = true;
else
args.IsValid = false;
}
catch (Exception ex)
{
args.IsValid = false;
}
}

The function handles the argument "arg" that brings the text inserted by the user.
If this text match with our pattern, the argument is valid and the server executes the code associated to the button, querying the database in the same manner seen above; however the code is now conditioned by the statement "if(Page.IsValid)".

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
DbHelper dbHelper = new DbHelper();
string connectionString = dbHelper.returnConnectionString();
SqlConnection sqlConnection = new SqlConnection(connectionString);
if (Page.IsValid)
{
try
{
sqlConnection.Open();
SqlCommand cmd = new SqlCommand("USP_SearchUserByCode", sqlConnection);
cmd.CommandType = CommandType.StoredProcedure;
SqlParameter pCode = new SqlParameter("@Code", SqlDbType.VarChar, 4);
pCode.Value = txtQuerySearch.Text;
cmd.Parameters.Add(pCode);
DataSet ds = new DataSet();
SqlDataAdapter sqlDataAdapter = new SqlDataAdapter(cmd);
sqlDataAdapter.Fill(ds, "ResultTable");
gridresult.DataSource = ds;
gridresult.DataBind();
}
catch (SqlException ex)
{
throw ex;
}
finally
{
if (sqlConnection != null)
sqlConnection.Close(); //close the connection
}
}
}

This is only an example but the use of the Validators can be very important in all the contexts in which the protection of a database from malicious input is needed.

== .NET Preventing LDAP Injection ==

It’s not important here to explain how LDAP works. The focus is explain how it’s possible to avoid the injection of special character, that are responsible of a unpredictable behaviour of the LDAP server.
LDAP search are often made with a distinguished name (DN) and a filter. So if the user input is not properly validated, the user can manipulate the input to craft a malicious filter, to obtain more informations from the server.
LDAP search are made with string, so the best solution to analyze a string searching particular characters is a Regular Expression.
In this example there is the code associated to a event ButtonClick, and two TextBox called "txtUid" and "txtSn" are used to give input to the system

protected void btnQuerySearch_OnCLick(object sender, EventArgs e)
{
string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);
if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}
LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;
try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}
}

''' First Section '''

string regExString = "[a-zA-Z_0-9 @.]+";
RegexStringValidator regEx = new RegexStringValidator(regExString);

The first section uses a Regular Expression, using the class “RegExStringValidator”, very useful to analyze a string.
The string can contain only alphanumeric characters, @, blank or dot.
Others characters different from the indicated subset are not allowed, according to the white list approach.

''' Second Section '''

if (regEx.CanValidate(txtUid.Text.GetType()))
try
{
regEx.Validate(txtUid.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong uid");
return;
}
if (regEx.CanValidate(txtSn.Text.GetType()))
try
{
regEx.Validate(txtSn.Text);
}
catch (ArgumentException argExec)
{
// Validation failed.
Response.Write("wrong sn");
return;
}

In this section there is the code to check if the strings inserted in the textbox “txtUid” and “txtSn” match the rule of the RegExp or not. There is a try-catch block and the object method "Validate" is used to make the job. If the validation passes, the catch block is not processed.

''' Third Section '''

LdapConnection connection = new LdapConnection ("192.168.1.36");
connection.AuthType = AuthType.Anonymous;
string DN = "uid=john,ou=people,dc=example,dc=com";
LdapSessionOptions options = connection.SessionOptions;
options.ProtocolVersion = 3;

The third section is the place for the connection to the server.

''' Fourth Section '''

try
{
Response.Write("\r\nPerforming a simple search ...");
// create a search filter to find all objects
string ldapSearchFilter = "(&(uid=" + txtUid.Text + ")(sn=" + txtSn.Text + "))";
DirectoryRequest searchRequest = new SearchRequest
(DN,
ldapSearchFilter,
System.DirectoryServices.Protocols.SearchScope.Base,
null);
//cast the returned directory response as a SearchResponse object
DirectoryResponse response;
response = (SearchResponse)connection.SendRequest(searchRequest);
SearchResponse searchResponse =
(SearchResponse)connection.SendRequest(searchRequest);
Response.Write("\r\nSearch Response Entries " + searchResponse.Entries.Count);
// enumerate the entries in the search response
foreach (SearchResultEntry entry in searchResponse.Entries)
{
Response.Write("indexof , DN " + searchResponse.Entries.IndexOf(entry) + entry.DistinguishedName);
}
}
catch (Exception ex)
{
throw ex;
}

Finally it's made the request and the server make the response, giving the number of entries that found

== Web.config Encryption ==

Web.config (and others file with .config extension) could contain sensitive informations that should be protected. For a Web Application tipically the parameter configuration to acces to a database are stored in plain text, in a form like this:

<configuration>
<appSettings>
<add key="webRefFromSql.ProvaSql1" value="http://win2k3/ProvaSQL/ProvaSQL1"/>
</appSettings>
<connectionStrings>
<add name="SQLServer2005Express" connectionString="Data Source=localhost\SQLEXPRESS; Initial Catalog=Exampledb; User Id=user;
Password=clgir3s2s;" providerName=""/>
</connectionStrings>
<system.web>
<compilation debug="true">
</compilation>
<authentication mode="Windows"/>
</system.web>
</configuration>

= References =

* http://msdn.microsoft.com/en-us/library/default.aspx
* http://msdn.microsoft.com/en-us/library/6759sth4.aspx
* http://directoryprogramming.net/
* http://msdn.microsoft.com/en-us/library/system.configuration.regexstringvalidator.aspx
* http://www.ietf.org/rfc/rfc2254.txt
* http://msdn.microsoft.com/en-us/library/az24scfc(VS.80).aspx

OWASP Backend Security Project SQLServer Hardening

2008-06-30T21:23:03Z

GPederzini: /* System Stored Procedure */

= Overview =
In this section there are some best practices concerning the security of SQL Server 2005. The operating system under SQL Server is Windows Server 2003.

= Description =

== Installation of the Engine ==
The prerequisites for the installation are:
* .NET Framework 2.0
* Microsoft SQL Native Client
* Microsoft SQL Server 2005 Setup Support Files.

The installation consist of a large amount of services that are shortly descripted:
* SQL Server Database Services (install SQL Server database engine and tools for managing relational and XML data, replication and full text search)
* Analysis Services (install analysis services and tools used to support online analytical procession OLAP and data mining. Install also Integration Services)
* Notification Services (installs notification services a platform for developing and deploying applications that send personalized, timely notifications to a variety of devices or applications)
* Integration Services (install a set of tools and programmable objects for creating and managing packages that extract, transofrm and load data, as well perform task)
* Client Components (install management tools, development tools and legacy components)
* Documentation, samples and sample databases (installs books online documentation, sample databases and sample applications for all sql 2005 components)
During the installation the thing to remind is that from a security point of view, only what is strictly needed must be installed. To install a tipycal minimal configuration, the SQL Server Database Services and some Client Components (Connectivity components and Management Tools) can be installed.
=== Services ===
In SQL Server every service can run under a particular Windows account. The choices for the service's accounts are:

* Local user that is not a Windows administrator
* Domain user that is not a Windows administrator
* Local Service account
* Network Service account
* Local System account
* Local user that is a Windows administrator
* Domain user that is a Windows administrator

There is not only a solution to configure the service's account, but there are two rules to follow that enforce to behave in certain way:
* minimum privileges
* account isolation
Follow this, probably an administrator account (local or domain) has much more privileges than needed, indipendently of the service.
The Local System account has to many privileges and it's not indicated for a service's account
On the other hand Local Service and Network Service have not much privileges, but they are used for more Windows services, so there is no account isolation.

So the more secure solution for the Sql Server Service's Account is to use Local User or Domain User not Administrators.
For example imagine that are installed the trhee main services:
* Sql Server
* Sql Server Agent
* Sql Server Browser
The task is to create three Windows Local User Account, belonging to User Group, protected with password, and assign them to the services.
In this manner there are exactly two concepts: minimum privileges and account isolation.

=== Authentication Mode ===
Sql Server provides two kinds of authentication: SQL Server Authentication and Windows Authentication. During the installation is possible to enable both (Mixed Mode) or only the Windows Authentication (Windows Mode)

If there is an homogeneous Windows environment, the more secure solution is to enable the Windows mode Authentication, because the administration of the logins is made in the Windows Server and the credentials are not passed through the network, because Windows Authentication uses NTLM or Kerberos Protocols.
If there is an heterogeneous environment, for example no domain controller or there are some legacy applications that have to connect to Sql Server, only the Mixed Mode solution is possible. In this second case the administration of the logins is made inside SQL Server and the credentials are necessarily passed through the network.

Is important to say that in a Windows Mode Authentication, the "sa" user (system administrator) is not enabled. In a mixed mode is enabled.
So in an environment with Mixed Mode Authentication, to avoid the attacks against "sa" user, is better to:
* rename "sa" with another name
* use a strong password for the renamed "sa"

=== Processes ===
Every services that is installed in Sql Server could be administrated through the tool "Sql Server Configuration Manager" that is possible to install, enabling the client component of Sql Server.
With this tool is possible to realize the two best practices for the account's services, assigning to every service a specific account protected with password, that authenticates against Windows.
Every service could be started or stopped in a manual or automatic manner, like other Windows Services.

== Configuration tools provided ==

=== Surface Area Reduction (services and connections) ===
The Surface Area Reduction is a powerful tool provided with Sql Server 2005 to configure:
* Services & Connections

'''Services'''

Every Service installed could be rapidly managed. It's posssible in every moment to:
* Manage the status of the service with the possibilities: Start/Stop & Pause/Resume
* Manage the action of the operating system on startup for that service: Automatic, Manual, Disabled.

The concept is to configure automatic start only for those services that are immediately needed, disabling or manually starting others services that are not necessary.

'''Connections'''

For every instance of SQL Server is possible to allow:
* Only local connection to the server
* Local and remote connections to the server
In a distributed environment probably it's necessary to allow both the connection's type, but it's easy to understand that allowing remote connections expose the server more easily.
So for the remote connections Sql Server could allow two kind of protocols:
* TCP/IP
* Named Piped
For the normal use the better thing is to configure only TCP/IP, because Named Pipes need more open port to work.
Additionally there are others two kinds of connections to the server:
* VIA
* Shared Memory
VIA (Virtual Interface Adapter protocol ) works with VIA hardware. Shared Memory is a protocol that is possible to use only by local connections.
Using the Sql Server Configuration Manager the best solution is enable TCP/IP for remote connections and Shared Memory for the local connections.

=== Surface Area Reduction (features) ===
This is a series of interfaces for enabling or disabling many Database Engine, Analysis Services, and Reporting Services features. The most important are the features of the Database Engine:

* Ad hoc distributed queries
* Common language runtime (CLR) integration
* Dedicated administrator connection (DAC)
* Database Mail
* Native XML Web services
* OLE Automation stored procedures
* Service Broker
* SQL Mail
* Web Assistant stored procedures
* xp_cmdshell

'''Ad hoc distributed queries''' (default is disabled)

This feature enable the OPENROWSET and OPENDATASOURCE calls, to connect to an OLE DB data source. To disable this feature launch:

EXEC sp_configure 'Ad Hoc Distributed Queries',0
GO
RECONFIGURE
GO

It's recommended to disable this feature, because in a case of Sql Injection, an attacker could use OPENROWSET to connect to a database.

'''Common language runtime (CLR) integration''' (default is disabled)

This feature give the possibility to write stored procedures, triggers, user defined functions using a .NET Framework language. So if the server is not used with this aim, or if all the databases object are written with T-SQL, there's no reason to enable this. To disable this feature launch:

EXEC sp_configure 'clr enabled',0
GO
RECONFIGURE
GO

'''Dedicated administrator connection (DAC)''' (default is disabled)

This feature enables the possibility to execute diagnostics queries and troubleshoot problems when there are some problems to connect with standard mode to the server.
The uses are tipically:

* Querying some dynamic management views of SQL Server to obtain informations about the "status health"
* Basic DBCC commands (for example DBCC SHRINKDATABASE to cut the log file)
* Kill the PID of processes

But for example is possible to do other works, like add logins with sysadmin privileges or other administrator's tasks
This is an emergency type of connection, that SQL Server can permit every time, reserving an amount of resources during startup. It permits only a user a time, so if there is an user connected via DAC, no others users can connect. It's possible to use it with SQLCMD or Sql Server Management Studio, through the sintax:

Admin:<namepc>\<nameSqlInstance>

So DAC is only another type of connection, and in every time the credentials must be given to the server, but if it's not necessary, disable it.
To disable this feature launch:

EXEC sp_configure 'remote admin connections',0
GO
RECONFIGURE
GO

'''Database mail''' (default is disabled)

The database mail feature enables the possibility to use the Sql Server Instance to send email. If it's a powerful solution to give some advices to a sysadmin, from a security point of view it's a good practice to use the instance with the only aims that needed.
To disable this feature launch:

EXEC sp_configure 'Database Mail XPs',0
GO
RECONFIGURE
GO

'''Native XML Web services''' (default no SOAP endpoints are created)

This feature basically gives the possibility to use SQL Server as a Web Services provider. It's possible to create HTTP Endpoints in Sql Server, associated for example to a result of stored procedure.
A SOAP client could consume a service simply invoking the correct url provided by Sql Server, without others layers (tipically an IIS web server in wich the web services are hosted).
Enabling this feature and create HTTP endpoints goes in the direction to increase the surface of attack. Every client could produce SOAP request, because SOAP grounds on its working to XML and HTTP, two standards.

To use this feature, first thing is to create an HTTP endpoint for SOAP, and then start or stop the service, with the Surface Area Reduction tool.

'''OLE Automation stored procedures''' (default is disabled)

This feature allows access properties and methods of an ActiveX object within SQL Server. If it's necessary to obtain informations inside a DLL that is not available inside SQL Server, it's possible to use some stored procedure to do the work, enabling this feature, but it's better to access the object with the right language, not with T-SQL.
To disable this feature launch:

EXEC sp_configure 'Ole Automation Procedures',0
GO
RECONFIGURE
GO

'''Service Broker''' (default no Service Broker endpoints is created)

Service Broker is a technology in which two or more entities accomplish a task, sending and receiving messages, in a asynchronous mode. As XML Web Services, to use this feature, a Service Broker endpoint must be created.
A Service Broker endpoint listens on a specific TCP port numberm (tipically 4022, but could be configured during the endpoint's creation).
The authentication against Service Broker could be BASIC, DIGEST, NTLM, KERBEROS, INTEGRATED.

To use this feature, first thing is to create a TCP endpoint for SERVICE_BROKER, and then start or stop the service, with the Surface Area Reduction tool.

'''SQL Mail''' (default is disabled)

SQL Mail is a feature for legacy applications, supported for backward compatibility, to send and receive email using MAPI protocol. This is replaced by Database Mail Feature.
To disable this feature launch:

EXEC sp_configure 'SQL Mail XPs',0
GO
RECONFIGURE
GO

'''Web Assistant stored procedures''' (default is disabled)

This feature enable stored procedures to generate HTML report from the data results. It's deprecated because there are others components (like Reporting Services) to present data in a browser.
To disable this feature launch:

EXEC sp_configure 'Web Assistant Procedures',0
GO
RECONFIGURE
GO

'''xp_cmdshell''' (default is disabled)

This feature enable the extended stored procedure "xp_cmdshell". By definition "executes a command string as an operating-system command shell and returns any output as rows of text".
Enabling xp_cmdshell is potentially very dangerous, because it allows a complete interaction with the operating system, so it's possible to give every command. It's better to do administratives tasks not using SQL Server, so mantain disable xp_cmdshell.
To disable this feature launch:

EXEC sp_configure 'xp_cmdshell',0
GO
RECONFIGURE
GO

=== Sql Server Configuration Manager (endpoints and protocols) ===

=== System Stored Procedure ===

Sql Server provides a lot of system stored procedures, to accomplish administratives tasks.
Surface Configuration Area for features for example is a graphical interface that uses, as it's showed, the stored procedure '''sp_configure''' in conjunction with '''RECONFIGURE''' command to modify the server's configuration.
So even if the server is well configurated avoiding every dangerous stored procedure (such as xp_cmdshell), if the application is vulnerable, a sql injection can cause the execution of the script:

EXEC sp_configure 'xp_cmdshell',1
GO
RECONFIGURE
GO

and automatically the xp_cmdshell would be enabled.
The solutions technically could be:
* Dropping the sp_configure
* Configuring in a right manner the LOGIN inside the Sql Server

The first solution is not good, because dropping system stored procedure could cause anomalies when it's time to patching the server with the last updates/upgrades.
So it's better to think in an "administrative manner"
For example, sp_configure with zero or one parameter could be executed by everyone. But sp_configure with two parameters (necessary to re-enable xp_cmdshell) could be executed by users that have ALTER SETTINGS permission.
In SQL Server there are two roles that, after installation, have ALTER SETTINGS permission:
* sysadmin
* serveradmin
So it's necessary that the LOGIN used to connect to a database for an application doesn't belong to these roles, and at the same time doesn't have the ALTER SETTINGS permission.
In this manner, there will be not possible to re-enable, for example, xp_cmdshell.

To look that, there are some system stored procedure used to view roles and permission for a LOGIN. Imagine for example that a web application connect to a database with a SQL Login called 'userToConnect'.
To see if this user belong to sysadmin or serveradmin roles, it's possible to digit:

SELECT * FROM sys.server_role_members x
INNER JOIN sys.server_principals y
ON x.member_principal_id = y.principal_id
WHERE y.name = 'userToConnect'

If there are one o more results, look at the first column. The possibilities for the "role_principal_id" are:
* 3=sysadmin
* 4=securityadmin
* 5=serveradmin
* 6=setupadmin
* 7=processadmin
* 8=diskadmin
* 9=dbcreator
* 10=bulkadmin

So if the 'userToConnect' doesn't have in the results number 3 or 5, doesn't belong to those roles. However it's not sufficient. Another check must be done. So launch

SELECT x.permission_name FROM sys.server_permissions x
INNER JOIN sys.server_principals y
ON x.grantee_principal_id = y.principal_id
WHERE y.name = 'userToConnect'

If the results don't have the permission ALTER SETTINGS, the "userToConnect" can't modify the server settings. Otherwise revoke the permission with:

REVOKE ALTER SETTINGS TO userToConnect

== Database Administration ==

=== Password Policies ===
=== Authorization ===
=== Roles and Schemas ===
=== Metadata Views ===
=== Linked Servers ===
=== Execution Context ===

== Encryption ==

=== Symmetric ===
=== Asymmetric ===
=== Asymmetric with certificate ===

= References =

OWASP Backend Security Project SQLServer Hardening

2008-06-30T21:19:23Z

GPederzini: /* System Stored Procedure */

= Overview =
In this section there are some best practices concerning the security of SQL Server 2005. The operating system under SQL Server is Windows Server 2003.

= Description =

== Installation of the Engine ==
The prerequisites for the installation are:
* .NET Framework 2.0
* Microsoft SQL Native Client
* Microsoft SQL Server 2005 Setup Support Files.

The installation consist of a large amount of services that are shortly descripted:
* SQL Server Database Services (install SQL Server database engine and tools for managing relational and XML data, replication and full text search)
* Analysis Services (install analysis services and tools used to support online analytical procession OLAP and data mining. Install also Integration Services)
* Notification Services (installs notification services a platform for developing and deploying applications that send personalized, timely notifications to a variety of devices or applications)
* Integration Services (install a set of tools and programmable objects for creating and managing packages that extract, transofrm and load data, as well perform task)
* Client Components (install management tools, development tools and legacy components)
* Documentation, samples and sample databases (installs books online documentation, sample databases and sample applications for all sql 2005 components)
During the installation the thing to remind is that from a security point of view, only what is strictly needed must be installed. To install a tipycal minimal configuration, the SQL Server Database Services and some Client Components (Connectivity components and Management Tools) can be installed.
=== Services ===
In SQL Server every service can run under a particular Windows account. The choices for the service's accounts are:

* Local user that is not a Windows administrator
* Domain user that is not a Windows administrator
* Local Service account
* Network Service account
* Local System account
* Local user that is a Windows administrator
* Domain user that is a Windows administrator

There is not only a solution to configure the service's account, but there are two rules to follow that enforce to behave in certain way:
* minimum privileges
* account isolation
Follow this, probably an administrator account (local or domain) has much more privileges than needed, indipendently of the service.
The Local System account has to many privileges and it's not indicated for a service's account
On the other hand Local Service and Network Service have not much privileges, but they are used for more Windows services, so there is no account isolation.

So the more secure solution for the Sql Server Service's Account is to use Local User or Domain User not Administrators.
For example imagine that are installed the trhee main services:
* Sql Server
* Sql Server Agent
* Sql Server Browser
The task is to create three Windows Local User Account, belonging to User Group, protected with password, and assign them to the services.
In this manner there are exactly two concepts: minimum privileges and account isolation.

=== Authentication Mode ===
Sql Server provides two kinds of authentication: SQL Server Authentication and Windows Authentication. During the installation is possible to enable both (Mixed Mode) or only the Windows Authentication (Windows Mode)

If there is an homogeneous Windows environment, the more secure solution is to enable the Windows mode Authentication, because the administration of the logins is made in the Windows Server and the credentials are not passed through the network, because Windows Authentication uses NTLM or Kerberos Protocols.
If there is an heterogeneous environment, for example no domain controller or there are some legacy applications that have to connect to Sql Server, only the Mixed Mode solution is possible. In this second case the administration of the logins is made inside SQL Server and the credentials are necessarily passed through the network.

Is important to say that in a Windows Mode Authentication, the "sa" user (system administrator) is not enabled. In a mixed mode is enabled.
So in an environment with Mixed Mode Authentication, to avoid the attacks against "sa" user, is better to:
* rename "sa" with another name
* use a strong password for the renamed "sa"

=== Processes ===
Every services that is installed in Sql Server could be administrated through the tool "Sql Server Configuration Manager" that is possible to install, enabling the client component of Sql Server.
With this tool is possible to realize the two best practices for the account's services, assigning to every service a specific account protected with password, that authenticates against Windows.
Every service could be started or stopped in a manual or automatic manner, like other Windows Services.

== Configuration tools provided ==

=== Surface Area Reduction (services and connections) ===
The Surface Area Reduction is a powerful tool provided with Sql Server 2005 to configure:
* Services & Connections

'''Services'''

Every Service installed could be rapidly managed. It's posssible in every moment to:
* Manage the status of the service with the possibilities: Start/Stop & Pause/Resume
* Manage the action of the operating system on startup for that service: Automatic, Manual, Disabled.

The concept is to configure automatic start only for those services that are immediately needed, disabling or manually starting others services that are not necessary.

'''Connections'''

For every instance of SQL Server is possible to allow:
* Only local connection to the server
* Local and remote connections to the server
In a distributed environment probably it's necessary to allow both the connection's type, but it's easy to understand that allowing remote connections expose the server more easily.
So for the remote connections Sql Server could allow two kind of protocols:
* TCP/IP
* Named Piped
For the normal use the better thing is to configure only TCP/IP, because Named Pipes need more open port to work.
Additionally there are others two kinds of connections to the server:
* VIA
* Shared Memory
VIA (Virtual Interface Adapter protocol ) works with VIA hardware. Shared Memory is a protocol that is possible to use only by local connections.
Using the Sql Server Configuration Manager the best solution is enable TCP/IP for remote connections and Shared Memory for the local connections.

=== Surface Area Reduction (features) ===
This is a series of interfaces for enabling or disabling many Database Engine, Analysis Services, and Reporting Services features. The most important are the features of the Database Engine:

* Ad hoc distributed queries
* Common language runtime (CLR) integration
* Dedicated administrator connection (DAC)
* Database Mail
* Native XML Web services
* OLE Automation stored procedures
* Service Broker
* SQL Mail
* Web Assistant stored procedures
* xp_cmdshell

'''Ad hoc distributed queries''' (default is disabled)

This feature enable the OPENROWSET and OPENDATASOURCE calls, to connect to an OLE DB data source. To disable this feature launch:

EXEC sp_configure 'Ad Hoc Distributed Queries',0
GO
RECONFIGURE
GO

It's recommended to disable this feature, because in a case of Sql Injection, an attacker could use OPENROWSET to connect to a database.

'''Common language runtime (CLR) integration''' (default is disabled)

This feature give the possibility to write stored procedures, triggers, user defined functions using a .NET Framework language. So if the server is not used with this aim, or if all the databases object are written with T-SQL, there's no reason to enable this. To disable this feature launch:

EXEC sp_configure 'clr enabled',0
GO
RECONFIGURE
GO

'''Dedicated administrator connection (DAC)''' (default is disabled)

This feature enables the possibility to execute diagnostics queries and troubleshoot problems when there are some problems to connect with standard mode to the server.
The uses are tipically:

* Querying some dynamic management views of SQL Server to obtain informations about the "status health"
* Basic DBCC commands (for example DBCC SHRINKDATABASE to cut the log file)
* Kill the PID of processes

But for example is possible to do other works, like add logins with sysadmin privileges or other administrator's tasks
This is an emergency type of connection, that SQL Server can permit every time, reserving an amount of resources during startup. It permits only a user a time, so if there is an user connected via DAC, no others users can connect. It's possible to use it with SQLCMD or Sql Server Management Studio, through the sintax:

Admin:<namepc>\<nameSqlInstance>

So DAC is only another type of connection, and in every time the credentials must be given to the server, but if it's not necessary, disable it.
To disable this feature launch:

EXEC sp_configure 'remote admin connections',0
GO
RECONFIGURE
GO

'''Database mail''' (default is disabled)

The database mail feature enables the possibility to use the Sql Server Instance to send email. If it's a powerful solution to give some advices to a sysadmin, from a security point of view it's a good practice to use the instance with the only aims that needed.
To disable this feature launch:

EXEC sp_configure 'Database Mail XPs',0
GO
RECONFIGURE
GO

'''Native XML Web services''' (default no SOAP endpoints are created)

This feature basically gives the possibility to use SQL Server as a Web Services provider. It's possible to create HTTP Endpoints in Sql Server, associated for example to a result of stored procedure.
A SOAP client could consume a service simply invoking the correct url provided by Sql Server, without others layers (tipically an IIS web server in wich the web services are hosted).
Enabling this feature and create HTTP endpoints goes in the direction to increase the surface of attack. Every client could produce SOAP request, because SOAP grounds on its working to XML and HTTP, two standards.

To use this feature, first thing is to create an HTTP endpoint for SOAP, and then start or stop the service, with the Surface Area Reduction tool.

'''OLE Automation stored procedures''' (default is disabled)

This feature allows access properties and methods of an ActiveX object within SQL Server. If it's necessary to obtain informations inside a DLL that is not available inside SQL Server, it's possible to use some stored procedure to do the work, enabling this feature, but it's better to access the object with the right language, not with T-SQL.
To disable this feature launch:

EXEC sp_configure 'Ole Automation Procedures',0
GO
RECONFIGURE
GO

'''Service Broker''' (default no Service Broker endpoints is created)

Service Broker is a technology in which two or more entities accomplish a task, sending and receiving messages, in a asynchronous mode. As XML Web Services, to use this feature, a Service Broker endpoint must be created.
A Service Broker endpoint listens on a specific TCP port numberm (tipically 4022, but could be configured during the endpoint's creation).
The authentication against Service Broker could be BASIC, DIGEST, NTLM, KERBEROS, INTEGRATED.

To use this feature, first thing is to create a TCP endpoint for SERVICE_BROKER, and then start or stop the service, with the Surface Area Reduction tool.

'''SQL Mail''' (default is disabled)

SQL Mail is a feature for legacy applications, supported for backward compatibility, to send and receive email using MAPI protocol. This is replaced by Database Mail Feature.
To disable this feature launch:

EXEC sp_configure 'SQL Mail XPs',0
GO
RECONFIGURE
GO

'''Web Assistant stored procedures''' (default is disabled)

This feature enable stored procedures to generate HTML report from the data results. It's deprecated because there are others components (like Reporting Services) to present data in a browser.
To disable this feature launch:

EXEC sp_configure 'Web Assistant Procedures',0
GO
RECONFIGURE
GO

'''xp_cmdshell''' (default is disabled)

This feature enable the extended stored procedure "xp_cmdshell". By definition "executes a command string as an operating-system command shell and returns any output as rows of text".
Enabling xp_cmdshell is potentially very dangerous, because it allows a complete interaction with the operating system, so it's possible to give every command. It's better to do administratives tasks not using SQL Server, so mantain disable xp_cmdshell.
To disable this feature launch:

EXEC sp_configure 'xp_cmdshell',0
GO
RECONFIGURE
GO

=== Sql Server Configuration Manager (endpoints and protocols) ===

=== System Stored Procedure ===

Sql Server provides a lot of system stored procedures, to accomplish administratives tasks.
Surface Configuration Area for features for example is a graphical interface that uses, as it's showed, the stored procedure '''sp_configure''' in conjunction with '''RECONFIGURE''' command to modify the server's configuration.
So even if the server is well configurated avoiding every dangerous stored procedure (such as xp_cmdshell), if the application is vulnerable, a sql injection can cause the execution of the script:

EXEC sp_configure 'xp_cmdshell',1
GO
RECONFIGURE
GO

and automatically the xp_cmdshell would be enabled.
The solutions technically could be:
* Dropping the sp_configure
* Configuring in a right manner the LOGIN inside the Sql Server

The first solution is not good, because dropping system stored procedure could cause anomalies when it's time to patching the server with the last updates/upgrades.
So it's better to think in an "administrative manner"
For example, sp_configure with zero or one parameter could be executed by everyone. But sp_configure with two parameters (necessary to re-enable xp_cmdshell) could be executed by users that have ALTER SETTINGS permission.
In SQL Server there are two roles that, after installation, have ALTER SETTINGS permission:
* sysadmin
* serveradmin
So it's necessary that the LOGIN used to connect to a database for an application doesn't belong to these roles, and at the same time doesn't have the ALTER SETTINGS permission.
In this manner, there will be not possible to re-enable, for example, xp_cmdshell.

To look that, there are some system stored procedure used to view roles and permission for a LOGIN. Imagine for example that a web application connect to a database with a SQL Login called 'userToConnect'.
To see if this user belong to sysadmin or serveradmin roles, it's possible to digit:

SELECT * FROM sys.server_role_members x
INNER JOIN sys.server_principals y
ON x.member_principal_id = y.principal_id
WHERE y.name = 'userToConnect'

If there are one o more results, look at the first column. The possibilities for the "role_principal_id" are:
* 3=sysadmin
* 4=securityadmin
* 5=serveradmin
* 6=setupadmin
* 7=processadmin
* 8=diskadmin
* 9=dbcreator
* 10=bulkadmin

So if the 'userToConnect' doesn't have in the results number 3 or 5, doesn't belong to those roles. However it's not sufficient. Another check must be done. So launch

SELECT x.permission_name FROM sys.server_permissions x
INNER JOIN sys.server_principals y
ON x.grantee_principal_id = y.principal_id
WHERE y.name = 'userToConnect'

If the results don't have the permission ALTER SETTINGS, the "userToConnect" can't modify the server settings.

== Database Administration ==

=== Password Policies ===
=== Authorization ===
=== Roles and Schemas ===
=== Metadata Views ===
=== Linked Servers ===
=== Execution Context ===

== Encryption ==

=== Symmetric ===
=== Asymmetric ===
=== Asymmetric with certificate ===

= References =

OWASP Backend Security Project SQLServer Hardening

2008-06-30T20:36:14Z

GPederzini: /* System Stored Procedure */

= Overview =
In this section there are some best practices concerning the security of SQL Server 2005. The operating system under SQL Server is Windows Server 2003.

= Description =

== Installation of the Engine ==
The prerequisites for the installation are:
* .NET Framework 2.0
* Microsoft SQL Native Client
* Microsoft SQL Server 2005 Setup Support Files.

The installation consist of a large amount of services that are shortly descripted:
* SQL Server Database Services (install SQL Server database engine and tools for managing relational and XML data, replication and full text search)
* Analysis Services (install analysis services and tools used to support online analytical procession OLAP and data mining. Install also Integration Services)
* Notification Services (installs notification services a platform for developing and deploying applications that send personalized, timely notifications to a variety of devices or applications)
* Integration Services (install a set of tools and programmable objects for creating and managing packages that extract, transofrm and load data, as well perform task)
* Client Components (install management tools, development tools and legacy components)
* Documentation, samples and sample databases (installs books online documentation, sample databases and sample applications for all sql 2005 components)
During the installation the thing to remind is that from a security point of view, only what is strictly needed must be installed. To install a tipycal minimal configuration, the SQL Server Database Services and some Client Components (Connectivity components and Management Tools) can be installed.
=== Services ===
In SQL Server every service can run under a particular Windows account. The choices for the service's accounts are:

* Local user that is not a Windows administrator
* Domain user that is not a Windows administrator
* Local Service account
* Network Service account
* Local System account
* Local user that is a Windows administrator
* Domain user that is a Windows administrator

There is not only a solution to configure the service's account, but there are two rules to follow that enforce to behave in certain way:
* minimum privileges
* account isolation
Follow this, probably an administrator account (local or domain) has much more privileges than needed, indipendently of the service.
The Local System account has to many privileges and it's not indicated for a service's account
On the other hand Local Service and Network Service have not much privileges, but they are used for more Windows services, so there is no account isolation.

So the more secure solution for the Sql Server Service's Account is to use Local User or Domain User not Administrators.
For example imagine that are installed the trhee main services:
* Sql Server
* Sql Server Agent
* Sql Server Browser
The task is to create three Windows Local User Account, belonging to User Group, protected with password, and assign them to the services.
In this manner there are exactly two concepts: minimum privileges and account isolation.

=== Authentication Mode ===
Sql Server provides two kinds of authentication: SQL Server Authentication and Windows Authentication. During the installation is possible to enable both (Mixed Mode) or only the Windows Authentication (Windows Mode)

If there is an homogeneous Windows environment, the more secure solution is to enable the Windows mode Authentication, because the administration of the logins is made in the Windows Server and the credentials are not passed through the network, because Windows Authentication uses NTLM or Kerberos Protocols.
If there is an heterogeneous environment, for example no domain controller or there are some legacy applications that have to connect to Sql Server, only the Mixed Mode solution is possible. In this second case the administration of the logins is made inside SQL Server and the credentials are necessarily passed through the network.

Is important to say that in a Windows Mode Authentication, the "sa" user (system administrator) is not enabled. In a mixed mode is enabled.
So in an environment with Mixed Mode Authentication, to avoid the attacks against "sa" user, is better to:
* rename "sa" with another name
* use a strong password for the renamed "sa"

=== Processes ===
Every services that is installed in Sql Server could be administrated through the tool "Sql Server Configuration Manager" that is possible to install, enabling the client component of Sql Server.
With this tool is possible to realize the two best practices for the account's services, assigning to every service a specific account protected with password, that authenticates against Windows.
Every service could be started or stopped in a manual or automatic manner, like other Windows Services.

== Configuration tools provided ==

=== Surface Area Reduction (services and connections) ===
The Surface Area Reduction is a powerful tool provided with Sql Server 2005 to configure:
* Services & Connections

'''Services'''

Every Service installed could be rapidly managed. It's posssible in every moment to:
* Manage the status of the service with the possibilities: Start/Stop & Pause/Resume
* Manage the action of the operating system on startup for that service: Automatic, Manual, Disabled.

The concept is to configure automatic start only for those services that are immediately needed, disabling or manually starting others services that are not necessary.

'''Connections'''

For every instance of SQL Server is possible to allow:
* Only local connection to the server
* Local and remote connections to the server
In a distributed environment probably it's necessary to allow both the connection's type, but it's easy to understand that allowing remote connections expose the server more easily.
So for the remote connections Sql Server could allow two kind of protocols:
* TCP/IP
* Named Piped
For the normal use the better thing is to configure only TCP/IP, because Named Pipes need more open port to work.
Additionally there are others two kinds of connections to the server:
* VIA
* Shared Memory
VIA (Virtual Interface Adapter protocol ) works with VIA hardware. Shared Memory is a protocol that is possible to use only by local connections.
Using the Sql Server Configuration Manager the best solution is enable TCP/IP for remote connections and Shared Memory for the local connections.

=== Surface Area Reduction (features) ===
This is a series of interfaces for enabling or disabling many Database Engine, Analysis Services, and Reporting Services features. The most important are the features of the Database Engine:

* Ad hoc distributed queries
* Common language runtime (CLR) integration
* Dedicated administrator connection (DAC)
* Database Mail
* Native XML Web services
* OLE Automation stored procedures
* Service Broker
* SQL Mail
* Web Assistant stored procedures
* xp_cmdshell

'''Ad hoc distributed queries''' (default is disabled)

This feature enable the OPENROWSET and OPENDATASOURCE calls, to connect to an OLE DB data source. To disable this feature launch:

EXEC sp_configure 'Ad Hoc Distributed Queries',0
GO
RECONFIGURE
GO

It's recommended to disable this feature, because in a case of Sql Injection, an attacker could use OPENROWSET to connect to a database.

'''Common language runtime (CLR) integration''' (default is disabled)

This feature give the possibility to write stored procedures, triggers, user defined functions using a .NET Framework language. So if the server is not used with this aim, or if all the databases object are written with T-SQL, there's no reason to enable this. To disable this feature launch:

EXEC sp_configure 'clr enabled',0
GO
RECONFIGURE
GO

'''Dedicated administrator connection (DAC)''' (default is disabled)

This feature enables the possibility to execute diagnostics queries and troubleshoot problems when there are some problems to connect with standard mode to the server.
The uses are tipically:

* Querying some dynamic management views of SQL Server to obtain informations about the "status health"
* Basic DBCC commands (for example DBCC SHRINKDATABASE to cut the log file)
* Kill the PID of processes

But for example is possible to do other works, like add logins with sysadmin privileges or other administrator's tasks
This is an emergency type of connection, that SQL Server can permit every time, reserving an amount of resources during startup. It permits only a user a time, so if there is an user connected via DAC, no others users can connect. It's possible to use it with SQLCMD or Sql Server Management Studio, through the sintax:

Admin:<namepc>\<nameSqlInstance>

So DAC is only another type of connection, and in every time the credentials must be given to the server, but if it's not necessary, disable it.
To disable this feature launch:

EXEC sp_configure 'remote admin connections',0
GO
RECONFIGURE
GO

'''Database mail''' (default is disabled)

The database mail feature enables the possibility to use the Sql Server Instance to send email. If it's a powerful solution to give some advices to a sysadmin, from a security point of view it's a good practice to use the instance with the only aims that needed.
To disable this feature launch:

EXEC sp_configure 'Database Mail XPs',0
GO
RECONFIGURE
GO

'''Native XML Web services''' (default no SOAP endpoints are created)

This feature basically gives the possibility to use SQL Server as a Web Services provider. It's possible to create HTTP Endpoints in Sql Server, associated for example to a result of stored procedure.
A SOAP client could consume a service simply invoking the correct url provided by Sql Server, without others layers (tipically an IIS web server in wich the web services are hosted).
Enabling this feature and create HTTP endpoints goes in the direction to increase the surface of attack. Every client could produce SOAP request, because SOAP grounds on its working to XML and HTTP, two standards.

To use this feature, first thing is to create an HTTP endpoint for SOAP, and then start or stop the service, with the Surface Area Reduction tool.

'''OLE Automation stored procedures''' (default is disabled)

This feature allows access properties and methods of an ActiveX object within SQL Server. If it's necessary to obtain informations inside a DLL that is not available inside SQL Server, it's possible to use some stored procedure to do the work, enabling this feature, but it's better to access the object with the right language, not with T-SQL.
To disable this feature launch:

EXEC sp_configure 'Ole Automation Procedures',0
GO
RECONFIGURE
GO

'''Service Broker''' (default no Service Broker endpoints is created)

Service Broker is a technology in which two or more entities accomplish a task, sending and receiving messages, in a asynchronous mode. As XML Web Services, to use this feature, a Service Broker endpoint must be created.
A Service Broker endpoint listens on a specific TCP port numberm (tipically 4022, but could be configured during the endpoint's creation).
The authentication against Service Broker could be BASIC, DIGEST, NTLM, KERBEROS, INTEGRATED.

To use this feature, first thing is to create a TCP endpoint for SERVICE_BROKER, and then start or stop the service, with the Surface Area Reduction tool.

'''SQL Mail''' (default is disabled)

SQL Mail is a feature for legacy applications, supported for backward compatibility, to send and receive email using MAPI protocol. This is replaced by Database Mail Feature.
To disable this feature launch:

EXEC sp_configure 'SQL Mail XPs',0
GO
RECONFIGURE
GO

'''Web Assistant stored procedures''' (default is disabled)

This feature enable stored procedures to generate HTML report from the data results. It's deprecated because there are others components (like Reporting Services) to present data in a browser.
To disable this feature launch:

EXEC sp_configure 'Web Assistant Procedures',0
GO
RECONFIGURE
GO

'''xp_cmdshell''' (default is disabled)

This feature enable the extended stored procedure "xp_cmdshell". By definition "executes a command string as an operating-system command shell and returns any output as rows of text".
Enabling xp_cmdshell is potentially very dangerous, because it allows a complete interaction with the operating system, so it's possible to give every command. It's better to do administratives tasks not using SQL Server, so mantain disable xp_cmdshell.
To disable this feature launch:

EXEC sp_configure 'xp_cmdshell',0
GO
RECONFIGURE
GO

=== Sql Server Configuration Manager (endpoints and protocols) ===

=== System Stored Procedure ===

Sql Server provides a lot of system stored procedures, to accomplish administratives tasks.
Surface Configuration Area for features for example is a graphical interface that uses, as it's showed, the stored procedure '''sp_configure''' in conjunction with '''RECONFIGURE''' command to modify the server's configuration.
So even if the server is well configurated avoiding every dangerous stored procedure (such as xp_cmdshell), if the application is vulnerable, a sql injection can cause the execution of the script:

EXEC sp_configure 'xp_cmdshell',1
GO
RECONFIGURE
GO

and automatically the xp_cmdshell would be enabled.
The solutions technically could be:
* Dropping the sp_configure
* Configuring in a right manner the LOGIN inside the Sql Server

The first solution is not good, because dropping system stored procedure could cause anomalies when it's time to patching the server with the last updates/upgrades.
So it's better to think in an "administrative manner"
For example, sp_configure with zero or one parameter could be executed by everyone. But sp_configure with two parameters (necessary to re-enable xp_cmdshell) could be executed by users that have ALTER SETTINGS permission.
In SQL Server there are two roles that, after installation, have ALTER SETTINGS permission:
* sysadmin
* serveradmin
So it's necessary that the LOGIN used to connect to a database for an application doesn't belong to these roles, and at the same time doesn't have the ALTER SETTINGS permission.
In this manner, there will be not possible to re-enable, for example, xp_cmdshell.

To look that, there are some system stored procedure used to view roles and permission for a LOGIN. Imagine for example that a web application connect to a database with a SQL Login called 'userToConnect'.
To see if this user belong to sysadmin or serveradmin roles, it's possible to digit:

SELECT * FROM sys.server_role_members x
INNER JOIN sys.server_principals y
ON x.member_principal_id = y.principal_id
WHERE y.name = 'userToConnect'

== Database Administration ==

=== Password Policies ===
=== Authorization ===
=== Roles and Schemas ===
=== Metadata Views ===
=== Linked Servers ===
=== Execution Context ===

== Encryption ==

=== Symmetric ===
=== Asymmetric ===
=== Asymmetric with certificate ===

= References =

OWASP Backend Security Project SQLServer Hardening

2008-06-30T18:47:19Z

GPederzini: /* System Stored Procedure */

= Overview =
In this section there are some best practices concerning the security of SQL Server 2005. The operating system under SQL Server is Windows Server 2003.

= Description =

== Installation of the Engine ==
The prerequisites for the installation are:
* .NET Framework 2.0
* Microsoft SQL Native Client
* Microsoft SQL Server 2005 Setup Support Files.

The installation consist of a large amount of services that are shortly descripted:
* SQL Server Database Services (install SQL Server database engine and tools for managing relational and XML data, replication and full text search)
* Analysis Services (install analysis services and tools used to support online analytical procession OLAP and data mining. Install also Integration Services)
* Notification Services (installs notification services a platform for developing and deploying applications that send personalized, timely notifications to a variety of devices or applications)
* Integration Services (install a set of tools and programmable objects for creating and managing packages that extract, transofrm and load data, as well perform task)
* Client Components (install management tools, development tools and legacy components)
* Documentation, samples and sample databases (installs books online documentation, sample databases and sample applications for all sql 2005 components)
During the installation the thing to remind is that from a security point of view, only what is strictly needed must be installed. To install a tipycal minimal configuration, the SQL Server Database Services and some Client Components (Connectivity components and Management Tools) can be installed.
=== Services ===
In SQL Server every service can run under a particular Windows account. The choices for the service's accounts are:

* Local user that is not a Windows administrator
* Domain user that is not a Windows administrator
* Local Service account
* Network Service account
* Local System account
* Local user that is a Windows administrator
* Domain user that is a Windows administrator

There is not only a solution to configure the service's account, but there are two rules to follow that enforce to behave in certain way:
* minimum privileges
* account isolation
Follow this, probably an administrator account (local or domain) has much more privileges than needed, indipendently of the service.
The Local System account has to many privileges and it's not indicated for a service's account
On the other hand Local Service and Network Service have not much privileges, but they are used for more Windows services, so there is no account isolation.

So the more secure solution for the Sql Server Service's Account is to use Local User or Domain User not Administrators.
For example imagine that are installed the trhee main services:
* Sql Server
* Sql Server Agent
* Sql Server Browser
The task is to create three Windows Local User Account, belonging to User Group, protected with password, and assign them to the services.
In this manner there are exactly two concepts: minimum privileges and account isolation.

=== Authentication Mode ===
Sql Server provides two kinds of authentication: SQL Server Authentication and Windows Authentication. During the installation is possible to enable both (Mixed Mode) or only the Windows Authentication (Windows Mode)

If there is an homogeneous Windows environment, the more secure solution is to enable the Windows mode Authentication, because the administration of the logins is made in the Windows Server and the credentials are not passed through the network, because Windows Authentication uses NTLM or Kerberos Protocols.
If there is an heterogeneous environment, for example no domain controller or there are some legacy applications that have to connect to Sql Server, only the Mixed Mode solution is possible. In this second case the administration of the logins is made inside SQL Server and the credentials are necessarily passed through the network.

Is important to say that in a Windows Mode Authentication, the "sa" user (system administrator) is not enabled. In a mixed mode is enabled.
So in an environment with Mixed Mode Authentication, to avoid the attacks against "sa" user, is better to:
* rename "sa" with another name
* use a strong password for the renamed "sa"

=== Processes ===
Every services that is installed in Sql Server could be administrated through the tool "Sql Server Configuration Manager" that is possible to install, enabling the client component of Sql Server.
With this tool is possible to realize the two best practices for the account's services, assigning to every service a specific account protected with password, that authenticates against Windows.
Every service could be started or stopped in a manual or automatic manner, like other Windows Services.

== Configuration tools provided ==

=== Surface Area Reduction (services and connections) ===
The Surface Area Reduction is a powerful tool provided with Sql Server 2005 to configure:
* Services & Connections

'''Services'''

Every Service installed could be rapidly managed. It's posssible in every moment to:
* Manage the status of the service with the possibilities: Start/Stop & Pause/Resume
* Manage the action of the operating system on startup for that service: Automatic, Manual, Disabled.

The concept is to configure automatic start only for those services that are immediately needed, disabling or manually starting others services that are not necessary.

'''Connections'''

For every instance of SQL Server is possible to allow:
* Only local connection to the server
* Local and remote connections to the server
In a distributed environment probably it's necessary to allow both the connection's type, but it's easy to understand that allowing remote connections expose the server more easily.
So for the remote connections Sql Server could allow two kind of protocols:
* TCP/IP
* Named Piped
For the normal use the better thing is to configure only TCP/IP, because Named Pipes need more open port to work.
Additionally there are others two kinds of connections to the server:
* VIA
* Shared Memory
VIA (Virtual Interface Adapter protocol ) works with VIA hardware. Shared Memory is a protocol that is possible to use only by local connections.
Using the Sql Server Configuration Manager the best solution is enable TCP/IP for remote connections and Shared Memory for the local connections.

=== Surface Area Reduction (features) ===
This is a series of interfaces for enabling or disabling many Database Engine, Analysis Services, and Reporting Services features. The most important are the features of the Database Engine:

* Ad hoc distributed queries
* Common language runtime (CLR) integration
* Dedicated administrator connection (DAC)
* Database Mail
* Native XML Web services
* OLE Automation stored procedures
* Service Broker
* SQL Mail
* Web Assistant stored procedures
* xp_cmdshell

'''Ad hoc distributed queries''' (default is disabled)

This feature enable the OPENROWSET and OPENDATASOURCE calls, to connect to an OLE DB data source. To disable this feature launch:

EXEC sp_configure 'Ad Hoc Distributed Queries',0
GO
RECONFIGURE
GO

It's recommended to disable this feature, because in a case of Sql Injection, an attacker could use OPENROWSET to connect to a database.

'''Common language runtime (CLR) integration''' (default is disabled)

This feature give the possibility to write stored procedures, triggers, user defined functions using a .NET Framework language. So if the server is not used with this aim, or if all the databases object are written with T-SQL, there's no reason to enable this. To disable this feature launch:

EXEC sp_configure 'clr enabled',0
GO
RECONFIGURE
GO

'''Dedicated administrator connection (DAC)''' (default is disabled)

This feature enables the possibility to execute diagnostics queries and troubleshoot problems when there are some problems to connect with standard mode to the server.
The uses are tipically:

* Querying some dynamic management views of SQL Server to obtain informations about the "status health"
* Basic DBCC commands (for example DBCC SHRINKDATABASE to cut the log file)
* Kill the PID of processes

But for example is possible to do other works, like add logins with sysadmin privileges or other administrator's tasks
This is an emergency type of connection, that SQL Server can permit every time, reserving an amount of resources during startup. It permits only a user a time, so if there is an user connected via DAC, no others users can connect. It's possible to use it with SQLCMD or Sql Server Management Studio, through the sintax:

Admin:<namepc>\<nameSqlInstance>

So DAC is only another type of connection, and in every time the credentials must be given to the server, but if it's not necessary, disable it.
To disable this feature launch:

EXEC sp_configure 'remote admin connections',0
GO
RECONFIGURE
GO

'''Database mail''' (default is disabled)

The database mail feature enables the possibility to use the Sql Server Instance to send email. If it's a powerful solution to give some advices to a sysadmin, from a security point of view it's a good practice to use the instance with the only aims that needed.
To disable this feature launch:

EXEC sp_configure 'Database Mail XPs',0
GO
RECONFIGURE
GO

'''Native XML Web services''' (default no SOAP endpoints are created)

This feature basically gives the possibility to use SQL Server as a Web Services provider. It's possible to create HTTP Endpoints in Sql Server, associated for example to a result of stored procedure.
A SOAP client could consume a service simply invoking the correct url provided by Sql Server, without others layers (tipically an IIS web server in wich the web services are hosted).
Enabling this feature and create HTTP endpoints goes in the direction to increase the surface of attack. Every client could produce SOAP request, because SOAP grounds on its working to XML and HTTP, two standards.

To use this feature, first thing is to create an HTTP endpoint for SOAP, and then start or stop the service, with the Surface Area Reduction tool.

'''OLE Automation stored procedures''' (default is disabled)

This feature allows access properties and methods of an ActiveX object within SQL Server. If it's necessary to obtain informations inside a DLL that is not available inside SQL Server, it's possible to use some stored procedure to do the work, enabling this feature, but it's better to access the object with the right language, not with T-SQL.
To disable this feature launch:

EXEC sp_configure 'Ole Automation Procedures',0
GO
RECONFIGURE
GO

'''Service Broker''' (default no Service Broker endpoints is created)

Service Broker is a technology in which two or more entities accomplish a task, sending and receiving messages, in a asynchronous mode. As XML Web Services, to use this feature, a Service Broker endpoint must be created.
A Service Broker endpoint listens on a specific TCP port numberm (tipically 4022, but could be configured during the endpoint's creation).
The authentication against Service Broker could be BASIC, DIGEST, NTLM, KERBEROS, INTEGRATED.

To use this feature, first thing is to create a TCP endpoint for SERVICE_BROKER, and then start or stop the service, with the Surface Area Reduction tool.

'''SQL Mail''' (default is disabled)

SQL Mail is a feature for legacy applications, supported for backward compatibility, to send and receive email using MAPI protocol. This is replaced by Database Mail Feature.
To disable this feature launch:

EXEC sp_configure 'SQL Mail XPs',0
GO
RECONFIGURE
GO

'''Web Assistant stored procedures''' (default is disabled)

This feature enable stored procedures to generate HTML report from the data results. It's deprecated because there are others components (like Reporting Services) to present data in a browser.
To disable this feature launch:

EXEC sp_configure 'Web Assistant Procedures',0
GO
RECONFIGURE
GO

'''xp_cmdshell''' (default is disabled)

This feature enable the extended stored procedure "xp_cmdshell". By definition "executes a command string as an operating-system command shell and returns any output as rows of text".
Enabling xp_cmdshell is potentially very dangerous, because it allows a complete interaction with the operating system, so it's possible to give every command. It's better to do administratives tasks not using SQL Server, so mantain disable xp_cmdshell.
To disable this feature launch:

EXEC sp_configure 'xp_cmdshell',0
GO
RECONFIGURE
GO

=== Sql Server Configuration Manager (endpoints and protocols) ===

=== System Stored Procedure ===

Sql Server provides a lot of system stored procedures, to accomplish administratives tasks.
Surface Configuration Area for features for example is a graphical interface that uses, as it's showed, the stored procedure '''sp_configure''' in conjunction with '''RECONFIGURE''' command to modify the server's configuration.
So even if the server is well configurated avoiding every dangerous stored procedure (such as xp_cmdshell), if the application is vulnerable, a sql injection can cause the execution of the script:

EXEC sp_configure 'xp_cmdshell',1
GO
RECONFIGURE
GO

and automatically the xp_cmdshell would be enabled.
The solutions technically could be:
* Dropping the sp_configure
* Configuring in a right manner the LOGIN inside the Sql Server

The first solution is not good, because dropping system stored procedure could cause anomalies when it's time to patching the server with the last updates/upgrades.
So it's better to think in an "administrative manner"
For example, sp_configure with zero or one parameter could be executed by everyone. But sp_configure with two parameters (necessary to re-enable xp_cmdshell) could be executed by users that have ALTER SETTINGS permission.
In SQL Server there are two roles that have ALTER SETTINGS permission:
* sysadmin
* serveradmin
So it's necessary that the LOGIN used to connect to a database for an application doesn't belong to these roles, and at the same time doesn't have the ALTER SETTINGS permission.
In this manner, there will be not possible to re-enable, for example, xp_cmdshell.

== Database Administration ==

=== Password Policies ===
=== Authorization ===
=== Roles and Schemas ===
=== Metadata Views ===
=== Linked Servers ===
=== Execution Context ===

== Encryption ==

=== Symmetric ===
=== Asymmetric ===
=== Asymmetric with certificate ===

= References =

OWASP Backend Security Project SQLServer Hardening

2008-06-30T18:42:01Z

GPederzini: /* Surface Area Reduction (features) */

= Overview =
In this section there are some best practices concerning the security of SQL Server 2005. The operating system under SQL Server is Windows Server 2003.

= Description =

== Installation of the Engine ==
The prerequisites for the installation are:
* .NET Framework 2.0
* Microsoft SQL Native Client
* Microsoft SQL Server 2005 Setup Support Files.

The installation consist of a large amount of services that are shortly descripted:
* SQL Server Database Services (install SQL Server database engine and tools for managing relational and XML data, replication and full text search)
* Analysis Services (install analysis services and tools used to support online analytical procession OLAP and data mining. Install also Integration Services)
* Notification Services (installs notification services a platform for developing and deploying applications that send personalized, timely notifications to a variety of devices or applications)
* Integration Services (install a set of tools and programmable objects for creating and managing packages that extract, transofrm and load data, as well perform task)
* Client Components (install management tools, development tools and legacy components)
* Documentation, samples and sample databases (installs books online documentation, sample databases and sample applications for all sql 2005 components)
During the installation the thing to remind is that from a security point of view, only what is strictly needed must be installed. To install a tipycal minimal configuration, the SQL Server Database Services and some Client Components (Connectivity components and Management Tools) can be installed.
=== Services ===
In SQL Server every service can run under a particular Windows account. The choices for the service's accounts are:

* Local user that is not a Windows administrator
* Domain user that is not a Windows administrator
* Local Service account
* Network Service account
* Local System account
* Local user that is a Windows administrator
* Domain user that is a Windows administrator

There is not only a solution to configure the service's account, but there are two rules to follow that enforce to behave in certain way:
* minimum privileges
* account isolation
Follow this, probably an administrator account (local or domain) has much more privileges than needed, indipendently of the service.
The Local System account has to many privileges and it's not indicated for a service's account
On the other hand Local Service and Network Service have not much privileges, but they are used for more Windows services, so there is no account isolation.

So the more secure solution for the Sql Server Service's Account is to use Local User or Domain User not Administrators.
For example imagine that are installed the trhee main services:
* Sql Server
* Sql Server Agent
* Sql Server Browser
The task is to create three Windows Local User Account, belonging to User Group, protected with password, and assign them to the services.
In this manner there are exactly two concepts: minimum privileges and account isolation.

=== Authentication Mode ===
Sql Server provides two kinds of authentication: SQL Server Authentication and Windows Authentication. During the installation is possible to enable both (Mixed Mode) or only the Windows Authentication (Windows Mode)

If there is an homogeneous Windows environment, the more secure solution is to enable the Windows mode Authentication, because the administration of the logins is made in the Windows Server and the credentials are not passed through the network, because Windows Authentication uses NTLM or Kerberos Protocols.
If there is an heterogeneous environment, for example no domain controller or there are some legacy applications that have to connect to Sql Server, only the Mixed Mode solution is possible. In this second case the administration of the logins is made inside SQL Server and the credentials are necessarily passed through the network.

Is important to say that in a Windows Mode Authentication, the "sa" user (system administrator) is not enabled. In a mixed mode is enabled.
So in an environment with Mixed Mode Authentication, to avoid the attacks against "sa" user, is better to:
* rename "sa" with another name
* use a strong password for the renamed "sa"

=== Processes ===
Every services that is installed in Sql Server could be administrated through the tool "Sql Server Configuration Manager" that is possible to install, enabling the client component of Sql Server.
With this tool is possible to realize the two best practices for the account's services, assigning to every service a specific account protected with password, that authenticates against Windows.
Every service could be started or stopped in a manual or automatic manner, like other Windows Services.

== Configuration tools provided ==

=== Surface Area Reduction (services and connections) ===
The Surface Area Reduction is a powerful tool provided with Sql Server 2005 to configure:
* Services & Connections

'''Services'''

Every Service installed could be rapidly managed. It's posssible in every moment to:
* Manage the status of the service with the possibilities: Start/Stop & Pause/Resume
* Manage the action of the operating system on startup for that service: Automatic, Manual, Disabled.

The concept is to configure automatic start only for those services that are immediately needed, disabling or manually starting others services that are not necessary.

'''Connections'''

For every instance of SQL Server is possible to allow:
* Only local connection to the server
* Local and remote connections to the server
In a distributed environment probably it's necessary to allow both the connection's type, but it's easy to understand that allowing remote connections expose the server more easily.
So for the remote connections Sql Server could allow two kind of protocols:
* TCP/IP
* Named Piped
For the normal use the better thing is to configure only TCP/IP, because Named Pipes need more open port to work.
Additionally there are others two kinds of connections to the server:
* VIA
* Shared Memory
VIA (Virtual Interface Adapter protocol ) works with VIA hardware. Shared Memory is a protocol that is possible to use only by local connections.
Using the Sql Server Configuration Manager the best solution is enable TCP/IP for remote connections and Shared Memory for the local connections.

=== Surface Area Reduction (features) ===
This is a series of interfaces for enabling or disabling many Database Engine, Analysis Services, and Reporting Services features. The most important are the features of the Database Engine:

* Ad hoc distributed queries
* Common language runtime (CLR) integration
* Dedicated administrator connection (DAC)
* Database Mail
* Native XML Web services
* OLE Automation stored procedures
* Service Broker
* SQL Mail
* Web Assistant stored procedures
* xp_cmdshell

'''Ad hoc distributed queries''' (default is disabled)

This feature enable the OPENROWSET and OPENDATASOURCE calls, to connect to an OLE DB data source. To disable this feature launch:

EXEC sp_configure 'Ad Hoc Distributed Queries',0
GO
RECONFIGURE
GO

It's recommended to disable this feature, because in a case of Sql Injection, an attacker could use OPENROWSET to connect to a database.

'''Common language runtime (CLR) integration''' (default is disabled)

This feature give the possibility to write stored procedures, triggers, user defined functions using a .NET Framework language. So if the server is not used with this aim, or if all the databases object are written with T-SQL, there's no reason to enable this. To disable this feature launch:

EXEC sp_configure 'clr enabled',0
GO
RECONFIGURE
GO

'''Dedicated administrator connection (DAC)''' (default is disabled)

This feature enables the possibility to execute diagnostics queries and troubleshoot problems when there are some problems to connect with standard mode to the server.
The uses are tipically:

* Querying some dynamic management views of SQL Server to obtain informations about the "status health"
* Basic DBCC commands (for example DBCC SHRINKDATABASE to cut the log file)
* Kill the PID of processes

But for example is possible to do other works, like add logins with sysadmin privileges or other administrator's tasks
This is an emergency type of connection, that SQL Server can permit every time, reserving an amount of resources during startup. It permits only a user a time, so if there is an user connected via DAC, no others users can connect. It's possible to use it with SQLCMD or Sql Server Management Studio, through the sintax:

Admin:<namepc>\<nameSqlInstance>

So DAC is only another type of connection, and in every time the credentials must be given to the server, but if it's not necessary, disable it.
To disable this feature launch:

EXEC sp_configure 'remote admin connections',0
GO
RECONFIGURE
GO

'''Database mail''' (default is disabled)

The database mail feature enables the possibility to use the Sql Server Instance to send email. If it's a powerful solution to give some advices to a sysadmin, from a security point of view it's a good practice to use the instance with the only aims that needed.
To disable this feature launch:

EXEC sp_configure 'Database Mail XPs',0
GO
RECONFIGURE
GO

'''Native XML Web services''' (default no SOAP endpoints are created)

This feature basically gives the possibility to use SQL Server as a Web Services provider. It's possible to create HTTP Endpoints in Sql Server, associated for example to a result of stored procedure.
A SOAP client could consume a service simply invoking the correct url provided by Sql Server, without others layers (tipically an IIS web server in wich the web services are hosted).
Enabling this feature and create HTTP endpoints goes in the direction to increase the surface of attack. Every client could produce SOAP request, because SOAP grounds on its working to XML and HTTP, two standards.

To use this feature, first thing is to create an HTTP endpoint for SOAP, and then start or stop the service, with the Surface Area Reduction tool.

'''OLE Automation stored procedures''' (default is disabled)

This feature allows access properties and methods of an ActiveX object within SQL Server. If it's necessary to obtain informations inside a DLL that is not available inside SQL Server, it's possible to use some stored procedure to do the work, enabling this feature, but it's better to access the object with the right language, not with T-SQL.
To disable this feature launch:

EXEC sp_configure 'Ole Automation Procedures',0
GO
RECONFIGURE
GO

'''Service Broker''' (default no Service Broker endpoints is created)

Service Broker is a technology in which two or more entities accomplish a task, sending and receiving messages, in a asynchronous mode. As XML Web Services, to use this feature, a Service Broker endpoint must be created.
A Service Broker endpoint listens on a specific TCP port numberm (tipically 4022, but could be configured during the endpoint's creation).
The authentication against Service Broker could be BASIC, DIGEST, NTLM, KERBEROS, INTEGRATED.

To use this feature, first thing is to create a TCP endpoint for SERVICE_BROKER, and then start or stop the service, with the Surface Area Reduction tool.

'''SQL Mail''' (default is disabled)

SQL Mail is a feature for legacy applications, supported for backward compatibility, to send and receive email using MAPI protocol. This is replaced by Database Mail Feature.
To disable this feature launch:

EXEC sp_configure 'SQL Mail XPs',0
GO
RECONFIGURE
GO

'''Web Assistant stored procedures''' (default is disabled)

This feature enable stored procedures to generate HTML report from the data results. It's deprecated because there are others components (like Reporting Services) to present data in a browser.
To disable this feature launch:

EXEC sp_configure 'Web Assistant Procedures',0
GO
RECONFIGURE
GO

'''xp_cmdshell''' (default is disabled)

This feature enable the extended stored procedure "xp_cmdshell". By definition "executes a command string as an operating-system command shell and returns any output as rows of text".
Enabling xp_cmdshell is potentially very dangerous, because it allows a complete interaction with the operating system, so it's possible to give every command. It's better to do administratives tasks not using SQL Server, so mantain disable xp_cmdshell.
To disable this feature launch:

EXEC sp_configure 'xp_cmdshell',0
GO
RECONFIGURE
GO

=== Sql Server Configuration Manager (endpoints and protocols) ===

=== System Stored Procedure ===

Sql Server provides a lot of system stored procedures, to accomplish administratives tasks.
Surface Configuration Area for features for example is a graphical interface that uses, as it's showed, the stored procedure '''sp_configure''' in conjunction with '''RECONFIGURE''' command to modify the server's configuration.
So even if the server is well configurated avoiding every dangerous stored procedure (such as xp_cmdshell), if the application is vulnerable, a sql injection can cause the execution of the script:

EXEC sp_configure 'xp_cmdshell',1
GO
RECONFIGURE
GO

and automatically the xp_cmdshell would be enabled.
The solutions technically could be:
* Dropping the sp_configure
* Configuring in a right manner the LOGIN inside the Sql Server

The first solution is not good, because dropping system stored procedure could cause anomalies when it's time to patching the server with the last updates/upgrades.
So it's better to think in an "administrative manner"
For example, sp_configure with zero or one parameter could be executed by everyone. But sp_configure with two parameters (necessary to re-enable xp_cmdshell) could be executed by users that have ALTER SETTINGS permission.

== Database Administration ==

=== Password Policies ===
=== Authorization ===
=== Roles and Schemas ===
=== Metadata Views ===
=== Linked Servers ===
=== Execution Context ===

== Encryption ==

=== Symmetric ===
=== Asymmetric ===
=== Asymmetric with certificate ===

= References =

OWASP Backend Security Project SQLServer Hardening

2008-06-29T15:51:02Z

GPederzini: /* System Stored Procedure */

= Overview =
In this section there are some best practices concerning the security of SQL Server 2005. The operating system under SQL Server is Windows Server 2003.

= Description =

== Installation of the Engine ==
The prerequisites for the installation are:
* .NET Framework 2.0
* Microsoft SQL Native Client
* Microsoft SQL Server 2005 Setup Support Files.

The installation consist of a large amount of services that are shortly descripted:
* SQL Server Database Services (install SQL Server database engine and tools for managing relational and XML data, replication and full text search)
* Analysis Services (install analysis services and tools used to support online analytical procession OLAP and data mining. Install also Integration Services)
* Notification Services (installs notification services a platform for developing and deploying applications that send personalized, timely notifications to a variety of devices or applications)
* Integration Services (install a set of tools and programmable objects for creating and managing packages that extract, transofrm and load data, as well perform task)
* Client Components (install management tools, development tools and legacy components)
* Documentation, samples and sample databases (installs books online documentation, sample databases and sample applications for all sql 2005 components)
During the installation the thing to remind is that from a security point of view, only what is strictly needed must be installed. To install a tipycal minimal configuration, the SQL Server Database Services and some Client Components (Connectivity components and Management Tools) can be installed.
=== Services ===
In SQL Server every service can run under a particular Windows account. The choices for the service's accounts are:

* Local user that is not a Windows administrator
* Domain user that is not a Windows administrator
* Local Service account
* Network Service account
* Local System account
* Local user that is a Windows administrator
* Domain user that is a Windows administrator

There is not only a solution to configure the service's account, but there are two rules to follow that enforce to behave in certain way:
* minimum privileges
* account isolation
Follow this, probably an administrator account (local or domain) has much more privileges than needed, indipendently of the service.
The Local System account has to many privileges and it's not indicated for a service's account
On the other hand Local Service and Network Service have not much privileges, but they are used for more Windows services, so there is no account isolation.

So the more secure solution for the Sql Server Service's Account is to use Local User or Domain User not Administrators.
For example imagine that are installed the trhee main services:
* Sql Server
* Sql Server Agent
* Sql Server Browser
The task is to create three Windows Local User Account, belonging to User Group, protected with password, and assign them to the services.
In this manner there are exactly two concepts: minimum privileges and account isolation.

=== Authentication Mode ===
Sql Server provides two kinds of authentication: SQL Server Authentication and Windows Authentication. During the installation is possible to enable both (Mixed Mode) or only the Windows Authentication (Windows Mode)

If there is an homogeneous Windows environment, the more secure solution is to enable the Windows mode Authentication, because the administration of the logins is made in the Windows Server and the credentials are not passed through the network, because Windows Authentication uses NTLM or Kerberos Protocols.
If there is an heterogeneous environment, for example no domain controller or there are some legacy applications that have to connect to Sql Server, only the Mixed Mode solution is possible. In this second case the administration of the logins is made inside SQL Server and the credentials are necessarily passed through the network.

Is important to say that in a Windows Mode Authentication, the "sa" user (system administrator) is not enabled. In a mixed mode is enabled.
So in an environment with Mixed Mode Authentication, to avoid the attacks against "sa" user, is better to:
* rename "sa" with another name
* use a strong password for the renamed "sa"

=== Processes ===
Every services that is installed in Sql Server could be administrated through the tool "Sql Server Configuration Manager" that is possible to install, enabling the client component of Sql Server.
With this tool is possible to realize the two best practices for the account's services, assigning to every service a specific account protected with password, that authenticates against Windows.
Every service could be started or stopped in a manual or automatic manner, like other Windows Services.

== Configuration tools provided ==

=== Surface Area Reduction (services and connections) ===
The Surface Area Reduction is a powerful tool provided with Sql Server 2005 to configure:
* Services & Connections

'''Services'''

Every Service installed could be rapidly managed. It's posssible in every moment to:
* Manage the status of the service with the possibilities: Start/Stop & Pause/Resume
* Manage the action of the operating system on startup for that service: Automatic, Manual, Disabled.

The concept is to configure automatic start only for those services that are immediately needed, disabling or manually starting others services that are not necessary.

'''Connections'''

For every instance of SQL Server is possible to allow:
* Only local connection to the server
* Local and remote connections to the server
In a distributed environment probably it's necessary to allow both the connection's type, but it's easy to understand that allowing remote connections expose the server more easily.
So for the remote connections Sql Server could allow two kind of protocols:
* TCP/IP
* Named Piped
For the normal use the better thing is to configure only TCP/IP, because Named Pipes need more open port to work.
Additionally there are others two kinds of connections to the server:
* VIA
* Shared Memory
VIA (Virtual Interface Adapter protocol ) works with VIA hardware. Shared Memory is a protocol that is possible to use only by local connections.
Using the Sql Server Configuration Manager the best solution is enable TCP/IP for remote connections and Shared Memory for the local connections.

=== Surface Area Reduction (features) ===
This is a series of interfaces for enabling or disabling many Database Engine, Analysis Services, and Reporting Services features. The most important are the features of the Database Engine:

* Ad hoc distributed queries
* Common language runtime (CLR) integration
* Dedicated administrator connection (DAC)
* Database Mail
* Native XML Web services
* OLE Automation stored procedures
* Service Broker
* SQL Mail
* Web Assistant stored procedures
* xp_cmdshell

'''Ad hoc distributed queries''' (default is disabled)

This feature enable the OPENROWSET and OPENDATASOURCE calls, to connect to an OLE DB data source. To use this feature launch:

EXEC sp_configure 'Ad Hoc Distributed Queries',1
GO
RECONFIGURE
GO

It's recommended to disable this feature, because in a case of Sql Injection, an attacker could use OPENROWSET to connect to a database.

'''Common language runtime (CLR) integration''' (default is disabled)

This feature give the possibility to write stored procedures, triggers, user defined functions using a .NET Framework language. So if the server is not used with this aim, or if all the databases object are written with T-SQL, there's no reason to enable this. To use this feature launch:

EXEC sp_configure 'clr enabled',1
GO
RECONFIGURE
GO

'''Dedicated administrator connection (DAC)''' (default is disabled)

This feature enables the possibility to execute diagnostics queries and troubleshoot problems when there are some problems to connect with standard mode to the server.
The uses are tipically:

* Querying some dynamic management views of SQL Server to obtain informations about the "status health"
* Basic DBCC commands (for example DBCC SHRINKDATABASE to cut the log file)
* Kill the PID of processes

But for example is possible to do other works, like add logins with sysadmin privileges or other administrator's tasks
This is an emergency type of connection, that SQL Server can permit every time, reserving an amount of resources during startup. It permits only a user a time, so if there is an user connected via DAC, no others users can connect. It's possible to use it with SQLCMD or Sql Server Management Studio, through the sintax:

Admin:<namepc>\<nameSqlInstance>

So DAC is only another type of connection, and in every time the credentials must be given to the server, but if it's not necessary, disable it.
To use this feature launch:

EXEC sp_configure 'remote admin connections',1
GO
RECONFIGURE
GO

'''Database mail''' (default is disabled)

The database mail feature enables the possibility to use the Sql Server Instance to send email. If it's a powerful solution to give some advices to a sysadmin, from a security point of view it's a good practice to use the instance with the only aims that needed.
To use this feature launch:

EXEC sp_configure 'Database Mail XPs',1
GO
RECONFIGURE
GO

'''Native XML Web services''' (default no SOAP endpoints are created)

This feature basically gives the possibility to use SQL Server as a Web Services provider. It's possible to create HTTP Endpoints in Sql Server, associated for example to a result of stored procedure.
A SOAP client could consume a service simply invoking the correct url provided by Sql Server, without others layers (tipically an IIS web server in wich the web services are hosted).
Enabling this feature and create HTTP endpoints goes in the direction to increase the surface of attack. Every client could produce SOAP request, because SOAP grounds on its working to XML and HTTP, two standards.

To use this feature, first thing is to create an HTTP endpoint for SOAP, and then start or stop the service, with the Surface Area Reduction tool.

'''OLE Automation stored procedures''' (default is disabled)

This feature allows access properties and methods of an ActiveX object within SQL Server. If it's necessary to obtain informations inside a DLL that is not available inside SQL Server, it's possible to use some stored procedure to do the work, enabling this feature, but it's better to access the object with the right language, not with T-SQL.
To use this feature launch:

EXEC sp_configure 'Ole Automation Procedures',1
GO
RECONFIGURE
GO

'''Service Broker''' (default no Service Broker endpoints is created)

Service Broker is a technology in which two or more entities accomplish a task, sending and receiving messages, in a asynchronous mode. As XML Web Services, to use this feature, a Service Broker endpoint must be created.
A Service Broker endpoint listens on a specific TCP port numberm (tipically 4022, but could be configured during the endpoint's creation).
The authentication against Service Broker could be BASIC, DIGEST, NTLM, KERBEROS, INTEGRATED.

To use this feature, first thing is to create a TCP endpoint for SERVICE_BROKER, and then start or stop the service, with the Surface Area Reduction tool.

'''SQL Mail''' (default is disabled)

SQL Mail is a feature for legacy applications, supported for backward compatibility, to send and receive email using MAPI protocol. This is replaced by Database Mail Feature.
To use this feature launch:

EXEC sp_configure 'SQL Mail XPs',1
GO
RECONFIGURE
GO

'''Web Assistant stored procedures''' (default is disabled)

This feature enable stored procedures to generate HTML report from the data results. It's deprecated because there are others components (like Reporting Services) to present data in a browser.
To use this feature launch:

EXEC sp_configure 'Web Assistant Procedures',1
GO
RECONFIGURE
GO

'''xp_cmdshell''' (default is disabled)

This feature enable the extended stored procedure "xp_cmdshell". By definition "executes a command string as an operating-system command shell and returns any output as rows of text".
Enabling xp_cmdshell is potentially very dangerous, because it allows a complete interaction with the operating system, so it's possible to give every command. It's better to do administratives tasks not using SQL Server, so mantain disable xp_cmdshell.
To use this feature launch:

EXEC sp_configure 'xp_cmdshell',1
GO
RECONFIGURE
GO

=== Sql Server Configuration Manager (endpoints and protocols) ===

=== System Stored Procedure ===

Sql Server provides a lot of system stored procedures, to accomplish administratives tasks.
Surface Configuration Area for features for example is a graphical interface that uses, as it's showed, the stored procedure '''sp_configure''' in conjunction with '''RECONFIGURE''' command to modify the server's configuration.
So even if the server is well configurated avoiding every dangerous stored procedure (such as xp_cmdshell), if the application is vulnerable, a sql injection can cause the execution of the script:

EXEC sp_configure 'xp_cmdshell',1
GO
RECONFIGURE
GO

and automatically the xp_cmdshell would be enabled.
The solutions technically could be:
* Dropping the sp_configure
* Configuring in a right manner the LOGIN inside the Sql Server

The first solution is not good, because dropping system stored procedure could cause anomalies when it's time to patching the server with the last updates/upgrades.
So it's better to think in an "administrative manner"
For example, sp_configure with zero or one parameter could be executed by everyone. But sp_configure with two parameters (necessary to re-enable xp_cmdshell) could be executed by users that have ALTER SETTINGS permission.

== Database Administration ==

=== Password Policies ===
=== Authorization ===
=== Roles and Schemas ===
=== Metadata Views ===
=== Linked Servers ===
=== Execution Context ===

== Encryption ==

=== Symmetric ===
=== Asymmetric ===
=== Asymmetric with certificate ===

= References =

OWASP Backend Security Project SQLServer Hardening

2008-06-29T15:50:35Z

GPederzini: /* System Stored Procedure */

= Overview =
In this section there are some best practices concerning the security of SQL Server 2005. The operating system under SQL Server is Windows Server 2003.

= Description =

== Installation of the Engine ==
The prerequisites for the installation are:
* .NET Framework 2.0
* Microsoft SQL Native Client
* Microsoft SQL Server 2005 Setup Support Files.

The installation consist of a large amount of services that are shortly descripted:
* SQL Server Database Services (install SQL Server database engine and tools for managing relational and XML data, replication and full text search)
* Analysis Services (install analysis services and tools used to support online analytical procession OLAP and data mining. Install also Integration Services)
* Notification Services (installs notification services a platform for developing and deploying applications that send personalized, timely notifications to a variety of devices or applications)
* Integration Services (install a set of tools and programmable objects for creating and managing packages that extract, transofrm and load data, as well perform task)
* Client Components (install management tools, development tools and legacy components)
* Documentation, samples and sample databases (installs books online documentation, sample databases and sample applications for all sql 2005 components)
During the installation the thing to remind is that from a security point of view, only what is strictly needed must be installed. To install a tipycal minimal configuration, the SQL Server Database Services and some Client Components (Connectivity components and Management Tools) can be installed.
=== Services ===
In SQL Server every service can run under a particular Windows account. The choices for the service's accounts are:

* Local user that is not a Windows administrator
* Domain user that is not a Windows administrator
* Local Service account
* Network Service account
* Local System account
* Local user that is a Windows administrator
* Domain user that is a Windows administrator

There is not only a solution to configure the service's account, but there are two rules to follow that enforce to behave in certain way:
* minimum privileges
* account isolation
Follow this, probably an administrator account (local or domain) has much more privileges than needed, indipendently of the service.
The Local System account has to many privileges and it's not indicated for a service's account
On the other hand Local Service and Network Service have not much privileges, but they are used for more Windows services, so there is no account isolation.

So the more secure solution for the Sql Server Service's Account is to use Local User or Domain User not Administrators.
For example imagine that are installed the trhee main services:
* Sql Server
* Sql Server Agent
* Sql Server Browser
The task is to create three Windows Local User Account, belonging to User Group, protected with password, and assign them to the services.
In this manner there are exactly two concepts: minimum privileges and account isolation.

=== Authentication Mode ===
Sql Server provides two kinds of authentication: SQL Server Authentication and Windows Authentication. During the installation is possible to enable both (Mixed Mode) or only the Windows Authentication (Windows Mode)

If there is an homogeneous Windows environment, the more secure solution is to enable the Windows mode Authentication, because the administration of the logins is made in the Windows Server and the credentials are not passed through the network, because Windows Authentication uses NTLM or Kerberos Protocols.
If there is an heterogeneous environment, for example no domain controller or there are some legacy applications that have to connect to Sql Server, only the Mixed Mode solution is possible. In this second case the administration of the logins is made inside SQL Server and the credentials are necessarily passed through the network.

Is important to say that in a Windows Mode Authentication, the "sa" user (system administrator) is not enabled. In a mixed mode is enabled.
So in an environment with Mixed Mode Authentication, to avoid the attacks against "sa" user, is better to:
* rename "sa" with another name
* use a strong password for the renamed "sa"

=== Processes ===
Every services that is installed in Sql Server could be administrated through the tool "Sql Server Configuration Manager" that is possible to install, enabling the client component of Sql Server.
With this tool is possible to realize the two best practices for the account's services, assigning to every service a specific account protected with password, that authenticates against Windows.
Every service could be started or stopped in a manual or automatic manner, like other Windows Services.

== Configuration tools provided ==

=== Surface Area Reduction (services and connections) ===
The Surface Area Reduction is a powerful tool provided with Sql Server 2005 to configure:
* Services & Connections

'''Services'''

Every Service installed could be rapidly managed. It's posssible in every moment to:
* Manage the status of the service with the possibilities: Start/Stop & Pause/Resume
* Manage the action of the operating system on startup for that service: Automatic, Manual, Disabled.

The concept is to configure automatic start only for those services that are immediately needed, disabling or manually starting others services that are not necessary.

'''Connections'''

For every instance of SQL Server is possible to allow:
* Only local connection to the server
* Local and remote connections to the server
In a distributed environment probably it's necessary to allow both the connection's type, but it's easy to understand that allowing remote connections expose the server more easily.
So for the remote connections Sql Server could allow two kind of protocols:
* TCP/IP
* Named Piped
For the normal use the better thing is to configure only TCP/IP, because Named Pipes need more open port to work.
Additionally there are others two kinds of connections to the server:
* VIA
* Shared Memory
VIA (Virtual Interface Adapter protocol ) works with VIA hardware. Shared Memory is a protocol that is possible to use only by local connections.
Using the Sql Server Configuration Manager the best solution is enable TCP/IP for remote connections and Shared Memory for the local connections.

=== Surface Area Reduction (features) ===
This is a series of interfaces for enabling or disabling many Database Engine, Analysis Services, and Reporting Services features. The most important are the features of the Database Engine:

* Ad hoc distributed queries
* Common language runtime (CLR) integration
* Dedicated administrator connection (DAC)
* Database Mail
* Native XML Web services
* OLE Automation stored procedures
* Service Broker
* SQL Mail
* Web Assistant stored procedures
* xp_cmdshell

'''Ad hoc distributed queries''' (default is disabled)

This feature enable the OPENROWSET and OPENDATASOURCE calls, to connect to an OLE DB data source. To use this feature launch:

EXEC sp_configure 'Ad Hoc Distributed Queries',1
GO
RECONFIGURE
GO

It's recommended to disable this feature, because in a case of Sql Injection, an attacker could use OPENROWSET to connect to a database.

'''Common language runtime (CLR) integration''' (default is disabled)

This feature give the possibility to write stored procedures, triggers, user defined functions using a .NET Framework language. So if the server is not used with this aim, or if all the databases object are written with T-SQL, there's no reason to enable this. To use this feature launch:

EXEC sp_configure 'clr enabled',1
GO
RECONFIGURE
GO

'''Dedicated administrator connection (DAC)''' (default is disabled)

This feature enables the possibility to execute diagnostics queries and troubleshoot problems when there are some problems to connect with standard mode to the server.
The uses are tipically:

* Querying some dynamic management views of SQL Server to obtain informations about the "status health"
* Basic DBCC commands (for example DBCC SHRINKDATABASE to cut the log file)
* Kill the PID of processes

But for example is possible to do other works, like add logins with sysadmin privileges or other administrator's tasks
This is an emergency type of connection, that SQL Server can permit every time, reserving an amount of resources during startup. It permits only a user a time, so if there is an user connected via DAC, no others users can connect. It's possible to use it with SQLCMD or Sql Server Management Studio, through the sintax:

Admin:<namepc>\<nameSqlInstance>

So DAC is only another type of connection, and in every time the credentials must be given to the server, but if it's not necessary, disable it.
To use this feature launch:

EXEC sp_configure 'remote admin connections',1
GO
RECONFIGURE
GO

'''Database mail''' (default is disabled)

The database mail feature enables the possibility to use the Sql Server Instance to send email. If it's a powerful solution to give some advices to a sysadmin, from a security point of view it's a good practice to use the instance with the only aims that needed.
To use this feature launch:

EXEC sp_configure 'Database Mail XPs',1
GO
RECONFIGURE
GO

'''Native XML Web services''' (default no SOAP endpoints are created)

This feature basically gives the possibility to use SQL Server as a Web Services provider. It's possible to create HTTP Endpoints in Sql Server, associated for example to a result of stored procedure.
A SOAP client could consume a service simply invoking the correct url provided by Sql Server, without others layers (tipically an IIS web server in wich the web services are hosted).
Enabling this feature and create HTTP endpoints goes in the direction to increase the surface of attack. Every client could produce SOAP request, because SOAP grounds on its working to XML and HTTP, two standards.

To use this feature, first thing is to create an HTTP endpoint for SOAP, and then start or stop the service, with the Surface Area Reduction tool.

'''OLE Automation stored procedures''' (default is disabled)

This feature allows access properties and methods of an ActiveX object within SQL Server. If it's necessary to obtain informations inside a DLL that is not available inside SQL Server, it's possible to use some stored procedure to do the work, enabling this feature, but it's better to access the object with the right language, not with T-SQL.
To use this feature launch:

EXEC sp_configure 'Ole Automation Procedures',1
GO
RECONFIGURE
GO

'''Service Broker''' (default no Service Broker endpoints is created)

Service Broker is a technology in which two or more entities accomplish a task, sending and receiving messages, in a asynchronous mode. As XML Web Services, to use this feature, a Service Broker endpoint must be created.
A Service Broker endpoint listens on a specific TCP port numberm (tipically 4022, but could be configured during the endpoint's creation).
The authentication against Service Broker could be BASIC, DIGEST, NTLM, KERBEROS, INTEGRATED.

To use this feature, first thing is to create a TCP endpoint for SERVICE_BROKER, and then start or stop the service, with the Surface Area Reduction tool.

'''SQL Mail''' (default is disabled)

SQL Mail is a feature for legacy applications, supported for backward compatibility, to send and receive email using MAPI protocol. This is replaced by Database Mail Feature.
To use this feature launch:

EXEC sp_configure 'SQL Mail XPs',1
GO
RECONFIGURE
GO

'''Web Assistant stored procedures''' (default is disabled)

This feature enable stored procedures to generate HTML report from the data results. It's deprecated because there are others components (like Reporting Services) to present data in a browser.
To use this feature launch:

EXEC sp_configure 'Web Assistant Procedures',1
GO
RECONFIGURE
GO

'''xp_cmdshell''' (default is disabled)

This feature enable the extended stored procedure "xp_cmdshell". By definition "executes a command string as an operating-system command shell and returns any output as rows of text".
Enabling xp_cmdshell is potentially very dangerous, because it allows a complete interaction with the operating system, so it's possible to give every command. It's better to do administratives tasks not using SQL Server, so mantain disable xp_cmdshell.
To use this feature launch:

EXEC sp_configure 'xp_cmdshell',1
GO
RECONFIGURE
GO

=== Sql Server Configuration Manager (endpoints and protocols) ===

=== System Stored Procedure ===

Sql Server provides a lot of system stored procedures, to accomplish administratives tasks.
Surface Configuration Area for features for example is a graphical interface that uses, as it's showed, the stored procedure '''sp_configure''' in conjunction with '''RECONFIGURE''' command to modify the server's configuration.
So even if the server is well configurated avoiding every dangerous stored procedure (such as xp_cmdshell), if the application is vulnerable, a sql injection can cause the execution of the script:

EXEC sp_configure 'xp_cmdshell',1
GO
RECONFIGURE
GO

and automatically the xp_cmdshell would be enabled.
The solutions technically could be:
* Dropping the sp_configure
* Configuring in a right manner the LOGIN inside the Sql Server

The first solution is not good, because dropping system stored procedure could cause anomalies when it's time to patching the server with the last updates/upgrades.
So it's better to think ina a "administrative manner"
For example, sp_configure with zero or one parameter could be executed by everyone. But sp_configure with two parameters (necessary to re-enable xp_cmdshell) could be executed by users that have ALTER SETTINGS permission.

== Database Administration ==

=== Password Policies ===
=== Authorization ===
=== Roles and Schemas ===
=== Metadata Views ===
=== Linked Servers ===
=== Execution Context ===

== Encryption ==

=== Symmetric ===
=== Asymmetric ===
=== Asymmetric with certificate ===

= References =

OWASP Backend Security Project SQLServer Hardening

2008-06-29T15:18:58Z

GPederzini: /* System Stored Procedure */

OWASP Backend Security Project SQLServer Hardening

2008-06-29T14:12:25Z

GPederzini: /* System Stored Procedure */

OWASP Backend Security Project SQLServer Hardening

2008-06-29T13:19:41Z

GPederzini: /* System Stored Procedure */

OWASP Backend Security Project SQLServer Hardening

2008-06-29T13:12:16Z

GPederzini: /* System Stored Procedure (xp_cmdshell) */

OWASP Backend Security Project SQLServer Hardening

2008-06-29T12:21:19Z

GPederzini: /* Surface Area Reduction (features) */

OWASP Backend Security Project SQLServer Hardening

2008-06-29T12:12:16Z

GPederzini: /* Surface Area Reduction (features) */

OWASP Backend Security Project SQLServer Hardening

2008-06-29T11:58:00Z

GPederzini: /* Surface Area Reduction (features) */

OWASP Backend Security Project SQLServer Hardening

2008-06-29T11:10:19Z

GPederzini: /* Surface Area Reduction (features) */

OWASP Backend Security Project SQLServer Hardening

2008-06-29T11:07:05Z

GPederzini: /* Surface Area Reduction (features) */

OWASP Backend Security Project SQLServer Hardening

2008-06-29T09:55:29Z

GPederzini: /* Surface Area Reduction (features) */

OWASP Backend Security Project SQLServer Hardening

2008-06-29T09:28:04Z

GPederzini: /* Surface Area Reduction (features) */

OWASP Backend Security Project SQLServer Hardening

2008-06-29T08:21:32Z

GPederzini: /* Surface Area Reduction (features) */

OWASP Backend Security Project SQLServer Hardening

2008-06-29T08:20:43Z

GPederzini: /* Surface Area Reduction (features) */

OWASP Backend Security Project SQLServer Hardening

2008-06-28T15:23:22Z

GPederzini: /* Surface Area Reduction (features) */

OWASP Backend Security Project SQLServer Hardening

2008-06-28T15:03:01Z

GPederzini: /* Surface Area Reduction (features) */

OWASP Backend Security Project SQLServer Hardening

2008-06-28T14:37:13Z

GPederzini: /* Surface Area Reduction (features) */

OWASP Backend Security Project SQLServer Hardening

2008-06-28T14:07:08Z

GPederzini: /* Surface Area Reduction (features) */

OWASP Backend Security Project SQLServer Hardening

2008-06-28T13:42:05Z

GPederzini: /* Surface Area Reduction (features) */