Security Frame: Input Validation | Mitigations
Disable XSLT scripting for all transforms using untrusted style sheets
| Title | Details |
|---|---|
| Component | Web Application |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | XSLT Security, XsltSettings.EnableScript Property |
| Steps | XSLT supports scripting inside style sheets using the <msxml:script> element. This allows custom functions to be used in an XSLT transformation. The script is executed under the context of the process performing the transform. XSLT script must be disabled when in an untrusted environment to prevent execution of untrusted code. If using .NET: XSLT scripting is disabled by default; however, you must ensure that it has not been explicitly enabled through the XsltSettings.EnableScript property. |
Example
XsltSettings settings = new XsltSettings();
settings.EnableScript = true; // WRONG: THIS SHOULD BE SET TO false
Example
If you are using MSXML 6.0, XSLT scripting is disabled by default; however, you must ensure that it has not been explicitly enabled through the XML DOM object property AllowXsltScript.
doc.setProperty("AllowXsltScript", true); // WRONG: THIS SHOULD BE SET TO false
Example
If you are using MSXML 5 or below, XSLT scripting is enabled by default and you must explicitly disable it. Set the XML DOM object property AllowXsltScript to false.
doc.setProperty("AllowXsltScript", false); // CORRECT. Setting to false disables XSLT scripting.
Ensure that each page that could contain user controllable content opts out of automatic MIME sniffing
| Title | Details |
|---|---|
| Component | Web Application |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | IE8 Security Part V - Comprehensive Protection |
| Steps | For each page that could contain user controllable content, you must use the HTTP Header Each type of file delivered from a web server has an associated MIME type (also called a content-type) that describes the nature of the content (that is, image, text, application, etc.) The X-Content-Type-Options header is an HTTP header that allows developers to specify that their content should not be MIME-sniffed. This header is designed to mitigate MIME-Sniffing attacks. Support for this header was added in Internet Explorer 8 (IE8) Only users of Internet Explorer 8 (IE8) will benefit from X-Content-Type-Options. Previous versions of Internet Explorer do not currently respect the X-Content-Type-Options header Internet Explorer 8 (and later) are the only major browsers to implement a MIME-sniffing opt-out feature. If and when other major browsers (Firefox, Safari, Chrome) implement similar features, this recommendation will be updated to include syntax for those browsers as well |
Example
To enable the required header globally for all pages in the application, you can do one of the following:
- Add the header in the web.config file if the application is hosted by Internet Information Services (IIS) 7
<system.webServer>
<httpProtocol>
<customHeaders>
<add name=""X-Content-Type-Options"" value=""nosniff""/>
</customHeaders>
</httpProtocol>
</system.webServer>
- Add the header through the global Application_BeginRequest
void Application_BeginRequest(object sender, EventArgs e)
{
this.Response.Headers[""X-Content-Type-Options""] = ""nosniff"";
}
- Implement custom HTTP module
public class XContentTypeOptionsModule : IHttpModule
{
#region IHttpModule Members
public void Dispose()
{
}
public void Init(HttpApplication context)
{
context.PreSendRequestHeaders += newEventHandler(context_PreSendRequestHeaders);
}
#endregion
void context_PreSendRequestHeaders(object sender, EventArgs e)
{
HttpApplication application = sender as HttpApplication;
if (application == null)
return;
if (application.Response.Headers[""X-Content-Type-Options ""] != null)
return;
application.Response.Headers.Add(""X-Content-Type-Options "", ""nosniff"");
}
}
- You can enable the required header only for specific pages by adding it to individual responses:
this.Response.Headers[""X-Content-Type-Options""] = ""nosniff"";
Harden or Disable XML Entity Resolution
| Title | Details |
|---|---|
| Component | Web Application |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | XML Entity Expansion, XML Denial of Service Attacks and Defenses, MSXML Security Overview, Best Practices for Securing MSXML Code, NSXMLParserDelegate Protocol Reference, Resolving External References |
| Steps | Although it is not widely used, there is a feature of XML that allows the XML parser to expand macro entities with values defined either within the document itself or from external sources. For example, the document might define an entity "companyname" with the value "Microsoft," so that every time the text "&companyname;" appears in the document, it is automatically replaced with the text Microsoft. Or, the document might define an entity "MSFTStock" that references an external web service to fetch the current value of Microsoft stock. Then any time "&MSFTStock;" appears in the document, it is automatically replaced with the current stock price. However, this functionality can be abused to create denial of service (DoS) conditions. An attacker can nest multiple entities to create an exponential expansion XML bomb that consumes all available memory on the system. Alternatively, he can create an external reference that streams back an infinite amount of data or that simply hangs the thread. As a result, all teams must disable internal and/or external XML entity resolution entirely if their application does not use it, or manually limit the amount of memory and time that the application can consume for entity resolution if this functionality is absolutely necessary. If entity resolution is not required by your application, then disable it. |
Example
For .NET Framework code, you can use the following approaches:
XmlTextReader reader = new XmlTextReader(stream);
reader.ProhibitDtd = true;
XmlReaderSettings settings = new XmlReaderSettings();
settings.ProhibitDtd = true;
XmlReader reader = XmlReader.Create(stream, settings);
// for .NET 4
XmlReaderSettings settings = new XmlReaderSettings();
settings.DtdProcessing = DtdProcessing.Prohibit;
XmlReader reader = XmlReader.Create(stream, settings);
Note that the default value of ProhibitDtd in XmlReaderSettings is true, but in XmlTextReader it is false. If you are using XmlReaderSettings, you do not need to set ProhibitDtd to true explicitly, but it is recommended for safety sake that you do. Also note that the XmlDocument class allows entity resolution by default.
Example
To disable entity resolution for XmlDocuments, use the XmlDocument.Load(XmlReader) overload of the Load method and set the appropriate properties in the XmlReader argument to disable resolution, as illustrated in the following code:
XmlReaderSettings settings = new XmlReaderSettings();
settings.ProhibitDtd = true;
XmlReader reader = XmlReader.Create(stream, settings);
XmlDocument doc = new XmlDocument();
doc.Load(reader);
Example
If disabling entity resolution is not possible for your application, set the XmlReaderSettings.MaxCharactersFromEntities property to a reasonable value according to your application's needs. This will limit the impact of potential exponential expansion DoS attacks. The following code provides an example of this approach:
XmlReaderSettings settings = new XmlReaderSettings();
settings.ProhibitDtd = false;
settings.MaxCharactersFromEntities = 1000;
XmlReader reader = XmlReader.Create(stream, settings);
Example
If you need to resolve inline entities but do not need to resolve external entities, set the XmlReaderSettings.XmlResolver property to null. For example:
XmlReaderSettings settings = new XmlReaderSettings();
settings.ProhibitDtd = false;
settings.MaxCharactersFromEntities = 1000;
settings.XmlResolver = null;
XmlReader reader = XmlReader.Create(stream, settings);
Note that in MSXML6, ProhibitDTD is set to true (disabling DTD processing) by default. For Apple OSX/iOS code, there are two XML parsers you can use: NSXMLParser and libXML2.
Applications utilizing http.sys perform URL canonicalization verification
| Title | Details |
|---|---|
| Component | Web Application |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | N/A |
| Steps | Any application that uses http.sys should follow these guidelines:
|
Ensure appropriate controls are in place when accepting files from users
| Title | Details |
|---|---|
| Component | Web Application |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | Unrestricted File Upload, File Signature Table |
| Steps | Uploaded files represent a significant risk to applications. The first step in many attacks is to get some code to the system to be attacked. Then the attack only needs to find a way to get the code executed. Using a file upload helps the attacker accomplish the first step. The consequences of unrestricted file upload can vary, including complete system takeover, an overloaded file system or database, forwarding attacks to back-end systems, and simple defacement. It depends on what the application does with the uploaded file and especially where it is stored. Server side validation of file uploads is missing. Following security controls should be implemented for File Upload functionality:
|
Example
For the last point regarding file format signature validation, refer to the class below for details:
private static Dictionary<string, List<byte[]>> fileSignature = new Dictionary<string, List<byte[]>>
{
{ ".DOC", new List<byte[]> { new byte[] { 0xD0, 0xCF, 0x11, 0xE0, 0xA1, 0xB1, 0x1A, 0xE1 } } },
{ ".DOCX", new List<byte[]> { new byte[] { 0x50, 0x4B, 0x03, 0x04 } } },
{ ".PDF", new List<byte[]> { new byte[] { 0x25, 0x50, 0x44, 0x46 } } },
{ ".ZIP", new List<byte[]>
{
new byte[] { 0x50, 0x4B, 0x03, 0x04 },
new byte[] { 0x50, 0x4B, 0x4C, 0x49, 0x54, 0x55 },
new byte[] { 0x50, 0x4B, 0x53, 0x70, 0x58 },
new byte[] { 0x50, 0x4B, 0x05, 0x06 },
new byte[] { 0x50, 0x4B, 0x07, 0x08 },
new byte[] { 0x57, 0x69, 0x6E, 0x5A, 0x69, 0x70 }
}
},
{ ".PNG", new List<byte[]> { new byte[] { 0x89, 0x50, 0x4E, 0x47, 0x0D, 0x0A, 0x1A, 0x0A } } },
{ ".JPG", new List<byte[]>
{
new byte[] { 0xFF, 0xD8, 0xFF, 0xE0 },
new byte[] { 0xFF, 0xD8, 0xFF, 0xE1 },
new byte[] { 0xFF, 0xD8, 0xFF, 0xE8 }
}
},
{ ".JPEG", new List<byte[]>
{
new byte[] { 0xFF, 0xD8, 0xFF, 0xE0 },
new byte[] { 0xFF, 0xD8, 0xFF, 0xE2 },
new byte[] { 0xFF, 0xD8, 0xFF, 0xE3 }
}
},
{ ".XLS", new List<byte[]>
{
new byte[] { 0xD0, 0xCF, 0x11, 0xE0, 0xA1, 0xB1, 0x1A, 0xE1 },
new byte[] { 0x09, 0x08, 0x10, 0x00, 0x00, 0x06, 0x05, 0x00 },
new byte[] { 0xFD, 0xFF, 0xFF, 0xFF }
}
},
{ ".XLSX", new List<byte[]> { new byte[] { 0x50, 0x4B, 0x03, 0x04 } } },
{ ".GIF", new List<byte[]> { new byte[] { 0x47, 0x49, 0x46, 0x38 } } }
};
public static bool IsValidFileExtension(string fileName, byte[] fileData, byte[] allowedChars)
{
if (string.IsNullOrEmpty(fileName) || fileData == null || fileData.Length == 0)
{
return false;
}
bool flag = false;
string ext = Path.GetExtension(fileName);
if (string.IsNullOrEmpty(ext))
{
return false;
}
ext = ext.ToUpperInvariant();
if (ext.Equals(".TXT") || ext.Equals(".CSV") || ext.Equals(".PRN"))
{
foreach (byte b in fileData)
{
if (b > 0x7F)
{
if (allowedChars != null)
{
if (!allowedChars.Contains(b))
{
return false;
}
}
else
{
return false;
}
}
}
return true;
}
if (!fileSignature.ContainsKey(ext))
{
return true;
}
List<byte[]> sig = fileSignature[ext];
foreach (byte[] b in sig)
{
var curFileSig = new byte[b.Length];
Array.Copy(fileData, curFileSig, b.Length);
if (curFileSig.SequenceEqual(b))
{
flag = true;
break;
}
}
return flag;
}
Ensure that type-safe parameters are used in Web Application for data access
| Title | Details |
|---|---|
| Component | Web Application |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | N/A |
| Steps | If you use the Parameters collection, SQL treats the input is as a literal value rather then as executable code. The Parameters collection can be used to enforce type and length constraints on input data. Values outside of the range trigger an exception. If type-safe SQL parameters are not used, attackers might be able to execute injection attacks that are embedded in the unfiltered input. Use type safe parameters when constructing SQL queries to avoid possible SQL injection attacks that can occur with unfiltered input. You can use type safe parameters with stored procedures and with dynamic SQL statements. Parameters are treated as literal values by the database and not as executable code. Parameters are also checked for type and length. |
Example
The following code shows how to use type safe parameters with the SqlParameterCollection when calling a stored procedure.
using System.Data;
using System.Data.SqlClient;
using (SqlConnection connection = new SqlConnection(connectionString))
{
DataSet userDataset = new DataSet();
SqlDataAdapter myCommand = new SqlDataAdapter("LoginStoredProcedure", connection);
myCommand.SelectCommand.CommandType = CommandType.StoredProcedure;
myCommand.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 11);
myCommand.SelectCommand.Parameters["@au_id"].Value = SSN.Text;
myCommand.Fill(userDataset);
}
In the preceding code example, the input value cannot be longer than 11 characters. If the data does not conform to the type or length defined by the parameter, the SqlParameter class throws an exception.
Use separate model binding classes or binding filter lists to prevent MVC mass assignment vulnerability
| Title | Details |
|---|---|
| Component | Web Application |
| SDL Phase | Build |
| Applicable Technologies | MVC5, MVC6 |
| Attributes | N/A |
| References | Metadata Attributes, Public Key Security Vulnerability And Mitigation, Complete Guide to Mass Assignment in ASP.NET MVC, Getting Started with EF using MVC |
| Steps |
|
Encode untrusted web output prior to rendering
| Title | Details |
|---|---|
| Component | Web Application |
| SDL Phase | Build |
| Applicable Technologies | Generic, Web Forms, MVC5, MVC6 |
| Attributes | N/A |
| References | How to prevent Cross-site scripting in ASP.NET, Cross-site Scripting, XSS (Cross Site Scripting) Prevention Cheat Sheet |
| Steps | Cross-site scripting (commonly abbreviated as XSS) is an attack vector for online services or any application/component that consumes input from the web. XSS vulnerabilities may allow an attacker to execute script on another user's machine through a vulnerable web application. Malicious scripts can be used to steal cookies and otherwise tamper with a victim's machine through JavaScript. XSS is prevented by validating user input, ensuring it is well formed and encoding before it is rendered in a web page. Input validation and output encoding can be done by using Web Protection Library. For Managed code (C#, VB.NET, etc.), use one or more appropriate encoding methods from the Web Protection (Anti-XSS) Library, depending on the context where the user input gets manifested: |
Example
* Encoder.HtmlEncode
* Encoder.HtmlAttributeEncode
* Encoder.JavaScriptEncode
* Encoder.UrlEncode
* Encoder.VisualBasicScriptEncode
* Encoder.XmlEncode
* Encoder.XmlAttributeEncode
* Encoder.CssEncode
* Encoder.LdapEncode
Perform input validation and filtering on all string type Model properties
| Title | Details |
|---|---|
| Component | Web Application |
| SDL Phase | Build |
| Applicable Technologies | Generic, MVC5, MVC6 |
| Attributes | N/A |
| References | Adding Validation, Validating Model Data in an MVC Application, Guiding Principles For Your ASP.NET MVC Applications |
| Steps | All the input parameters must be validated before they are used in the application to ensure that the application is safeguarded against malicious user inputs. Validate the input values using regular expression validations on server side with an allowed list validation strategy. Unsanitized user inputs / parameters passed to the methods can cause code injection vulnerabilities. For web applications, entry points can also include form fields, QueryStrings, cookies, HTTP headers, and web service parameters. The following input validation checks must be performed upon model binding:
|
Sanitization should be applied on form fields that accept all characters, e.g, rich text editor
| Title | Details |
|---|---|
| Component | Web Application |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | Encode Unsafe Input, HTML Sanitizer |
| Steps | Identify all static markup tags that you want to use. A common practice is to restrict formatting to safe HTML elements, such as Before writing the data, HTML-encode it. This makes any malicious script safe by causing it to be handled as text, not as executable code.
The page-in the references disables ASP.NET request validation by setting HtmlSanitizer is a .NET library for cleaning HTML fragments and documents from constructs that can lead to XSS attacks. It uses AngleSharp to parse, manipulate, and render HTML and CSS. HtmlSanitizer can be installed as a NuGet package, and the user input can be passed through relevant HTML or CSS sanitization methods, as applicable, on the server side. Please note that Sanitization as a security control should be considered only as a last option. Input validation and Output Encoding are considered better security controls. |
Do not assign DOM elements to sinks that do not have inbuilt encoding
| Title | Details |
|---|---|
| Component | Web Application |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | N/A |
| Steps | Many JavaScript functions don't do encoding by default. When assigning untrusted input to DOM elements via such functions, may result in cross site script (XSS) executions. |
Example
Following are insecure examples:
document.getElementByID("div1").innerHtml = value;
$("#userName").html(res.Name);
return $('<div/>').html(value)
$('body').append(resHTML);
Don't use innerHtml; instead use innerText. Similarly, instead of $("#elm").html(), use $("#elm").text()
Validate all redirects within the application are closed or done safely
| Title | Details |
|---|---|
| Component | Web Application |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | The OAuth 2.0 Authorization Framework - Open Redirectors |
| Steps | Application design requiring redirection to a user-supplied location must constrain the possible redirection targets to a predefined "safe" list of sites or domains. All redirects in the application must be closed/safe. To do this:
|
Implement input validation on all string type parameters accepted by Controller methods
| Title | Details |
|---|---|
| Component | Web Application |
| SDL Phase | Build |
| Applicable Technologies | Generic, MVC5, MVC6 |
| Attributes | N/A |
| References | Validating Model Data in an MVC Application, Guiding Principles For Your ASP.NET MVC Applications |
| Steps | For methods that just accept primitive data type, and not models as argument,input validation using Regular Expression should be done. Here Regex.IsMatch should be used with a valid regex pattern. If the input doesn't match the specified Regular Expression, control should not proceed further, and an adequate warning regarding validation failure should be displayed. |
Set upper limit timeout for regular expression processing to prevent DoS due to bad regular expressions
| Title | Details |
|---|---|
| Component | Web Application |
| SDL Phase | Build |
| Applicable Technologies | Generic, Web Forms, MVC5, MVC6 |
| Attributes | N/A |
| References | DefaultRegexMatchTimeout Property |
| Steps | To ensure denial of service attacks against badly created regular expressions, that cause a lot of backtracking, set the global default timeout. If the processing time takes longer than the defined upper limit, it would throw a Timeout exception. If nothing is configured, the timeout would be infinite. |
Example
For example, the following configuration will throw a RegexMatchTimeoutException, if the processing takes more than 5 seconds:
<httpRuntime targetFramework="4.5" defaultRegexMatchTimeout="00:00:05" />
Avoid using Html.Raw in Razor views
| Title | Details |
|---|---|
| Component | Web Application |
| SDL Phase | Build |
| Applicable Technologies | MVC5, MVC6 |
| Attributes | N/A |
| References | N/A |
| Step | ASP.NET WebPages (Razor) perform automatic HTML encoding. All strings printed by embedded code nuggets (@ blocks) are automatically HTML-encoded. However, when HtmlHelper.Raw Method is invoked, it returns markup that is not HTML encoded. If Html.Raw() helper method is used, it bypasses the automatic encoding protection that Razor provides. |
Example
Following is an insecure example:
<div class="form-group">
@Html.Raw(Model.AccountConfirmText)
</div>
<div class="form-group">
@Html.Raw(Model.PaymentConfirmText)
</div>
</div>
Do not use Html.Raw() unless you need to display markup. This method does not perform output encoding implicitly. Use other ASP.NET helpers e.g., @Html.DisplayFor()
Do not use dynamic queries in stored procedures
| Title | Details |
|---|---|
| Component | Database |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | N/A |
| Steps | A SQL injection attack exploits vulnerabilities in input validation to run arbitrary commands in the database. It can occur when your application uses input to construct dynamic SQL statements to access the database. It can also occur if your code uses stored procedures that are passed strings that contain raw user input. Using the SQL injection attack, the attacker can execute arbitrary commands in the database. All SQL statements (including the SQL statements in stored procedures) must be parameterized. Parameterized SQL statements will accept characters that have special meaning to SQL (like single quote) without problems because they are strongly typed. |
Example
Following is an example of insecure dynamic Stored Procedure:
CREATE PROCEDURE [dbo].[uspGetProductsByCriteria]
(
@productName nvarchar(200) = NULL,
@startPrice float = NULL,
@endPrice float = NULL
)
AS
BEGIN
DECLARE @sql nvarchar(max)
SELECT @sql = ' SELECT ProductID, ProductName, Description, UnitPrice, ImagePath' +
' FROM dbo.Products WHERE 1 = 1 '
PRINT @sql
IF @productName IS NOT NULL
SELECT @sql = @sql + ' AND ProductName LIKE ''%' + @productName + '%'''
IF @startPrice IS NOT NULL
SELECT @sql = @sql + ' AND UnitPrice > ''' + CONVERT(VARCHAR(10),@startPrice) + ''''
IF @endPrice IS NOT NULL
SELECT @sql = @sql + ' AND UnitPrice < ''' + CONVERT(VARCHAR(10),@endPrice) + ''''
PRINT @sql
EXEC(@sql)
END
Example
Following is the same stored procedure implemented securely:
CREATE PROCEDURE [dbo].[uspGetProductsByCriteriaSecure]
(
@productName nvarchar(200) = NULL,
@startPrice float = NULL,
@endPrice float = NULL
)
AS
BEGIN
SELECT ProductID, ProductName, Description, UnitPrice, ImagePath
FROM dbo.Products where
(@productName IS NULL or ProductName like '%'+ @productName +'%')
AND
(@startPrice IS NULL or UnitPrice > @startPrice)
AND
(@endPrice IS NULL or UnitPrice < @endPrice)
END
Ensure that model validation is done on Web API methods
| Title | Details |
|---|---|
| Component | Web API |
| SDL Phase | Build |
| Applicable Technologies | MVC5, MVC6 |
| Attributes | N/A |
| References | Model Validation in ASP.NET Web API |
| Steps | When a client sends data to a web API, it is mandatory to validate the data before doing any processing. For ASP.NET Web APIs which accept models as input, use data annotations on models to set validation rules on the properties of the model. |
Example
The following code demonstrates the same:
using System.ComponentModel.DataAnnotations;
namespace MyApi.Models
{
public class Product
{
public int Id { get; set; }
[Required]
[RegularExpression(@"^[a-zA-Z0-9]*$", ErrorMessage="Only alphanumeric characters are allowed.")]
public string Name { get; set; }
public decimal Price { get; set; }
[Range(0, 999)]
public double Weight { get; set; }
}
}
Example
In the action method of the API controllers, validity of the model has to be explicitly checked as shown below:
namespace MyApi.Controllers
{
public class ProductsController : ApiController
{
public HttpResponseMessage Post(Product product)
{
if (ModelState.IsValid)
{
// Do something with the product (not shown).
return new HttpResponseMessage(HttpStatusCode.OK);
}
else
{
return Request.CreateErrorResponse(HttpStatusCode.BadRequest, ModelState);
}
}
}
}
Implement input validation on all string type parameters accepted by Web API methods
| Title | Details |
|---|---|
| Component | Web API |
| SDL Phase | Build |
| Applicable Technologies | Generic, MVC 5, MVC 6 |
| Attributes | N/A |
| References | Validating Model Data in an MVC Application, Guiding Principles For Your ASP.NET MVC Applications |
| Steps | For methods that just accept primitive data type, and not models as argument,input validation using Regular Expression should be done. Here Regex.IsMatch should be used with a valid regex pattern. If the input doesn't match the specified Regular Expression, control should not proceed further, and an adequate warning regarding validation failure should be displayed. |
Ensure that type-safe parameters are used in Web API for data access
| Title | Details |
|---|---|
| Component | Web API |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | N/A |
| Steps | If you use the Parameters collection, SQL treats the input is as a literal value rather then as executable code. The Parameters collection can be used to enforce type and length constraints on input data. Values outside of the range trigger an exception. If type-safe SQL parameters are not used, attackers might be able to execute injection attacks that are embedded in the unfiltered input. Use type safe parameters when constructing SQL queries to avoid possible SQL injection attacks that can occur with unfiltered input. You can use type safe parameters with stored procedures and with dynamic SQL statements. Parameters are treated as literal values by the database and not as executable code. Parameters are also checked for type and length. |
Example
The following code shows how to use type safe parameters with the SqlParameterCollection when calling a stored procedure.
using System.Data;
using System.Data.SqlClient;
using (SqlConnection connection = new SqlConnection(connectionString))
{
DataSet userDataset = new DataSet();
SqlDataAdapter myCommand = new SqlDataAdapter("LoginStoredProcedure", connection);
myCommand.SelectCommand.CommandType = CommandType.StoredProcedure;
myCommand.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 11);
myCommand.SelectCommand.Parameters["@au_id"].Value = SSN.Text;
myCommand.Fill(userDataset);
}
In the preceding code example, the input value cannot be longer than 11 characters. If the data does not conform to the type or length defined by the parameter, the SqlParameter class throws an exception.
Use parameterized SQL queries for Azure Cosmos DB
| Title | Details |
|---|---|
| Component | Azure Document DB |
| SDL Phase | Build |
| Applicable Technologies | Generic |
| Attributes | N/A |
| References | Announcing SQL Parameterization in Azure Cosmos DB |
| Steps | Although Azure Cosmos DB only supports read-only queries, SQL injection is still possible if queries are constructed by concatenating with user input. It might be possible for a user to gain access to data they shouldn't be accessing within the same collection by crafting malicious SQL queries. Use parameterized SQL queries if queries are constructed based on user input. |
WCF Input validation through Schema binding
| Title | Details |
|---|---|
| Component | WCF |
| SDL Phase | Build |
| Applicable Technologies | Generic, NET Framework 3 |
| Attributes | N/A |
| References | MSDN |
| Steps | Lack of validation leads to different type injection attacks. Message validation represents one line of defense in the protection of your WCF application. With this approach, you validate messages using schemas to protect WCF service operations from attack by a malicious client. Validate all messages received by the client to protect the client from attack by a malicious service. Message validation makes it possible to validate messages when operations consume message contracts or data contracts, which cannot be done using parameter validation. Message validation allows you to create validation logic inside schemas, thereby providing more flexibility and reducing development time. Schemas can be reused across different applications inside the organization, creating standards for data representation. Additionally, message validation allows you to protect operations when they consume more complex data types involving contracts representing business logic. To perform message validation, you first build a schema that represents the operations of your service and the data types consumed by those operations. You then create a .NET class that implements a custom client message inspector and custom dispatcher message inspector to validate the messages sent/received to/from the service. Next, you implement a custom endpoint behavior to enable message validation on both the client and the service. Finally, you implement a custom configuration element on the class that allows you to expose the extended custom endpoint behavior in the configuration file of the service or the client" |
WCF- Input validation through Parameter Inspectors
| Title | Details |
|---|---|
| Component | WCF |
| SDL Phase | Build |
| Applicable Technologies | Generic, NET Framework 3 |
| Attributes | N/A |
| References | MSDN |
| Steps | Input and data validation represents one important line of defense in the protection of your WCF application. You should validate all parameters exposed in WCF service operations to protect the service from attack by a malicious client. Conversely, you should also validate all return values received by the client to protect the client from attack by a malicious service WCF provides different extensibility points that allow you to customize the WCF runtime behavior by creating custom extensions. Message Inspectors and Parameter Inspectors are two extensibility mechanisms used to gain greater control over the data passing between a client and a service. You should use parameter inspectors for input validation and use message inspectors only when you need to inspect the entire message flowing in and out of a service. To perform input validation, you will build a .NET class and implement a custom parameter inspector in order to validate parameters on operations in your service. You will then implement a custom endpoint behavior to enable validation on both the client and the service. Finally, you will implement a custom configuration element on the class that allows you to expose the extended custom endpoint behavior in the configuration file of the service or the client |