2015 State of Application Security: Closing the Gap

Although published in mid 2015, SANS “2015 State of Application Security: Closing the Gap” provides interesting insights into:

  • Application Security Standards in Use
  • Overlap Between Development and Security Focus
  • Popular Languages and Their Perceived Risks
  • Top Challenges for Builders and Defenders
  • Defenders’ Emphasis for Application Security Management Resources
  • Useful Security Practices for Application Defenders




BSIMM in its 4th incarnation is here

The BSIMM4 came out on 09/17 and the BSIMM4 document is now available for download here.

BSIMM (pronounced “bee simm”) is short for Building Security In Maturity Model. The BSIMM is a study of real-world software security initiatives organized so that you can determine where you stand with your software security initiative and how to evolve your efforts over time.

Encoding notes around MvcHtmlString Class and <%: %>/@Model.<…> code syntax

The MvcHtmlString class:
Represents an HTML-encoded string that should not be encoded again. This class contains some interesting methods from security perspective like:

Create Creates an HTML-encoded string using the specified text value.
ToHtmlString Returns an HTML-encoded string that represents the current object.

The MvcHtmlString.Create method:
The Create method of the MvcHtmlString class in System.Web.Mvc namespace creates an HTML-encoded string using the specified text value in the parameter.

The method signature for the Create method is:


The <%: %> code syntax for the MVC ASPX engine:
<%: %> is a new syntax for HTML Encoding output in ASP.NET 4 and ASP.NET MVC 2. This syntax renders output like <%= %> blocks do, but at the same time, also automatically HTML encodes it before rendering.

Considering that ASP.NET 4 introduced a new IHtmlString interface (along with a concrete implementation: HtmlString) that a developer can implement on types to indicate that its value is already properly encoded for displaying as HTML, and that therefore the value should not be HTML-encoded again, a possibility of Double Encoding arises when <%:%> and instances of IHtmlString are used together.

To avoid this, <%: %> code-nugget syntax checks for the presence of the IHtmlString interface implementation and will not HTML encode the output of the code expression if its value implements this interface.

The @model.<…> syntax for the MVC Razor engine:
This syntax automatically encodes value that is represented by <…>. Only exceptions will be when <…> is of MvcHtmlString type.

Possible permutations:

<%: MvcHtmlString %> <%:%> will not encode the MvcHtmlSTring to avoid double encoding as this is assumed to be already encoded
<%: NormalString %> <%:%> will Html encode the NormalString before rendering the same.
@model. <somethingNonMvcHtmlString> This will be HTML encoded and rendered.
@model. <somethingMvcHtmlString> This will be not get HTML encoded as this is assumed to be already encoded somethingMvcHtmlString is already assumed to be encoded.

So why document these when these details are already available in MSDN/TechNet/web?
Because MvcHtmlString.Create method is not generating an HTML-encoded string as documented. And when these strings gets rendered within the <%:%> or @model.<…> syntax, they are not encoded and as a result a non-encoded string gets rendered into the browser.


A small MVC 3 application is created just to check the workings of the Create method of MvcHtmlString class.
The application takes a user string and renders it into the browser. It provides us an option to render as a normal string or as a HtmlMvcString. The UI looks as below:


Once I click on Test, the content entered is rendered as below:


The view code that handles this rendering part is:

image The strUserString is a normal string object.
The data model to which this view is bound has the following code:


Now to check the encoding behaviour, we pass some script values and try to render it in the browser.
Behaviour for Normal String:


This text is encoded and rendered as below:


Now the same text is rendered as an MvcHtmlString type:


The output looks as below:


The MvcHtmlString.Create method did not encode the string as documented. This needs to be taken care of during code reviews particularly when values of type MvcHtmlString is rendered within the <%: %> code nugget expressions or in @Model.<…> in ASP.NET 4 and ASP.NET MVC 2 onwards.
<%: %> and @Model.<…> will NOT automatically encode an object of type MvcHtmlString.

Some points to keep in mind when reviewing ASP.NET 4 and ASP.NET MVC onwards:
1. Check for <%: %> and MvcHtmlString usage.
2. Check for @Model.XXXX and MvcHtmlString usage
3. If found, check the type of value that is being rendered between the <%: %> code nugget expressions. Same for @Model.XXXX
4. If the type is normal string, <%: %>/@Model.XXXX will HTML encode the value. But if the type is MvcHtmlString then the value rendered within <%: %> will not be encoded. So if you see <%: %> in code do not assume that every value within it is encoded by default.

1. http://weblogs.asp.net/scottgu/archive/2010/04/06/new-lt-gt-syntax-for-html-encoding-output-in-asp-net-4-and-asp-net-mvc-2.aspx
2. http://stevesmithblog.com/blog/default-encoding-of-strings-in-asp-net-mvc-2/

The latest Cyber Risk Report from HP DVLabs

The latest Cyber Risk Report from HP DVLabs –

Good findings that analyzes:

  • The number of Web application vulnerabilities that are reported differs significantly from the number that actually exist.

  • Web application attacks are on the rise, despite the lack of new vulnerabilities being disclosed.

  • Web application vulnerabilities are easy to exploit with a variety of attack techniques and tools.

Secure File upload best practices

Secure file uploads are critical to applications that support this feature.

It is important that the files adhere to the best practices of secure file upload listed below:

  1. DO NOT RELY on client side validation. Whatever you do on the client side ALL the following checks MUST be implemented on the server side.
  2. Check for the SIZE OF THE FILE UPLOADED – absolutely critical must do. If you need very large files to be uploaded go back to the white board and see what alternatives can be explored. Generally any file upload should not be more than 4 MB.
  3. Ensure that only a set of known good file extensions/types are allowed to be uploaded– USE A WHITELIST of allowed extensions. DO NOT use a list of bad extensions to be avoided – NO BLACKLIST`ing.
  4. Generate the file names; DO NOT USE/AVOID files names that are provided by the end user.
  5. Upload the file to a location decided by the application WITHOUT any end user influence. DO NOT let the user have a say in where the file is uploaded.
  6. Upload in a location that is a NON SYSTEM drive.
  7. AVOID uploading the file to the WEB ROOT.
  8. ALWAYS DO a Virus scan on the uploaded files.
  9. Run a MIME check on the allowed MIME types. Note this can be manipulated by any user and by no means should be the only mechanism to secure a file upload. <<Adding some more to the original list>>
  10. Check “Magic Numbers” rather than just checking the file extensions. Check what a Magic Number is here.
  11. Pay attention to the decompression of compressed files.
  12. Ensure that the file upload is Audited.
  13. Refrain from overwriting of a uploaded file.
  14. Do not allow execute permissions on folder where the file is uploaded.

The validateFileToUpload class implements the three checks below using ASP.Net:

  • CHECK #1   Check for the file size
  • CHECK #2   Check for the file extension and map it to a white list of allowed extensions
  • CHECK #3   MIME Type Validation
public void validateFileToUpload(FileUpload objFile)
int MAX_FILE_SIZE = (4 * 1024 * 1024); //5 MB file size limit
//CHECK #1
//You can set the httpRunTime maxRequestLength to the required
//file size in the web.config file too
int fileSize = objFile.PostedFile.ContentLength;
if (fileSize > MAX_FILE_SIZE)
returnMessage = “File size exceeds the safe file size limit.  Reduce the file size.”;
return returnMessage;
//CHECK #2
//Check with a white list of extension
string chosenFileExtension = System.IO.Path.GetExtension(objFile.FileName);
string[] allowedExtensions = { “.doc”, “.xls”, “.ppt”, “.pptx”, “.txt” };
if (!allowedExtensions.Contains(chosenFileExtension))
returnMessage = “Upload Failed: Files with ” + chosenFileExtension + ” extensions are not allowed.”;
return returnMessage;
//CHECK #3
//Check with a white list of MIME types
string[] allowedMimeTypes = { “text/plain”, “text/xml” };
string chosenFileMiMeType = objFile.PostedFile.ContentType;
if (!allowedMimeTypes.Contains(chosenFileMiMeType))
returnMessage = “Upload Failed: Files with ” + chosenFileMiMeType + ” MIME types are not allowed.”;
return returnMessage;
There are some additional checks that needs to be kept in mind in addition to the 9 checks listed above like double extension files, filename checks for files coming from different operating systems (#4 kind of handles this though).Learnt to keep these checks in mind in a VERY HARD way today :’((