SSL Vulnerable to BEAST attack

A vulnerability exists in SSL 3.0 and TLS 1.0 that could allow information disclosure if an attacker intercepts encrypted traffic served from an affected system. The weakness is down to insufficiently randomised data being used for the Initialisation Vectors (IV) within the CBC-mode encryption algorithms. The exploit can be performed through multiple injection points, both native to the browser’s functionality.

This issue is reduced in risk by the fact that the attacker is required to have a Man-in-the-Middle position for this exploit whereby traffic interception can be performed, and with this position obtained it is generally easier to attack the victim through other methods (SSL-stripping, mixed-scripting [requesting HTTP resources from an HTTPS connection], etc…) which do not require complex cryptanalysis such as BEAST to execute.

TestSSLServer.exe (43.00 kb)


Supported versions:
 SSLv2 SSLv3 TLSv1.0
Deflate compression: no
Supported cipher suites (ORDER IS NOT SIGNIFICANT):
Server certificate(s):
Minimal encryption strength:     strong encryption (96-bit or more)
Achievable encryption strength:  strong encryption (96-bit or more)
BEAST status: vulnerable
CRIME status: protected



Various browsers are introducing or have introduced mitigations for the issue which make exploitation less likely. There are also steps which can be taken on the server side to make exploitation impossible.


Enabling and prioritising TLS 1.1/1.2 would be advised where possible although removing support for TLS1.0 is impractical at this time.

In the short-term due to the lack of wide-scale support by browsers and servers alike, prioritising the use of a stream cipher (such as RC4-SHA) instead of a CBC-mode cipher is recommended in order to maintain compatibility with browsers (see note).

Migration away from TLS 1.0 and below to TLS 1.1/1.2 should considered as a medium-term option for secure applications.

SSL Best Practice Guide:

BEAST attack

On September 23, 2011 researchers Thai Duong and Juliano Rizzo demonstrated a “proof of concept” called BEAST (“Browser Exploit Against SSL/TLS”) using a Java applet to violate same origin policy constraints, for a long-known Cipher block chaining (CBC) vulnerability in TLS 1.0.[44][45] Practical exploits had not been previously demonstrated for this vulnerability, which was originally discovered by Phillip Rogaway[46] in 2002. The vulnerability of the attack had been fixed with TLS 1.1 in 2006, but TLS 1.1 had not seen wide adoption prior to this attack demonstration.

Mozilla updated the development versions of their NSS libraries to mitigate BEAST-like attacks. NSS is used by Mozilla Firefox and Google Chrome to implement SSL. Some web servers that have a broken implementation of the SSL specification may stop working as a result.

Microsoft released Security Bulletin MS12-006 on January 10, 2012, which fixed the BEAST vulnerability by changing the way that the Windows Secure Channel (SChannel) component transmits encrypted network packets.

Users of Windows 7 and Windows Server 2008 R2 can enable use of TLS 1.1 and 1.2, but this work-around will fail if it is not supported by the other end of the connection and will result in a fall-back to TLS 1.0.

Verbose Error Messages

The software generates an error message that includes sensitive information about its environment, users, or associated data. 

Extended Description

The sensitive information may be valuable information on its own (such as a password), or it may be useful for launching other, more deadly attacks. If an attack fails, an attacker may use error information provided by the server to launch another more focused attack. For example, an attempt to exploit a path traversal weakness might yield the full pathname of the installed application. In turn, this could be used to select the proper number of “..” sequences to navigate to the targeted file. An attack using SQL injection might not initially succeed, but an error message could reveal the malformed query, which would expose query logic and possibly even passwords or other sensitive information used within the query.


Suppress these error messages by ensuring that a customised error handler is called in the event of an error. This can produce a generic message which does not hint at the underlying cause of the exception.


OWASP – Error Handling

How to: Display Safe Error Messages

When your application displays error messages, it should not give away information that a malicious user might find helpful in attacking your system. For example, if your application unsuccessfully tries to log in to a database, it should not display an error message that includes the user name it is using.

There are a number of ways to control error messages, including the following:

Configure the application not to show verbose error messages to remote users. (Remote users are those who request pages while not working on the Web server computer.) You can optionally redirect errors to an application page.

Include error handling whenever practical and construct your own error messages. In your error handler, you can test to see whether the user is local and react accordingly.

Create a global error handler at the page or application level that catches all unhandled exceptions and routes them to a generic error page. That way, even if you did not anticipate a problem, at least users will not see an exception page.

To configure the application to turn off errors for remote users

In the Web.config file for your application, make the following changes to the customErrors element:

  • Set the mode attribute to RemoteOnly (case-sensitive). This configures the application to show detailed errors only to local users (that is, to you, the developer).
  • Optionally include a defaultRedirect attribute that points to an application error page.
  • Optionally include <error> elements that redirect specific errors to specific pages. For example, you can redirect standard 404 errors (page not found) to your own application page.

The following code example shows a typical customErrors block in the Web.config file.

<customErrors mode="RemoteOnly" defaultRedirect="AppErrors/">
   <error statusCode="404" redirect="NoSuchPage/"/>
   <error statusCode="403" redirect="NoAccessAllowed/"/>

Environment issue – Untrusted Certificate

Certificate is singed by an unrecognised certificate authority.  If a browser receives a self-signed certificate, it pops up a warning, and the burden falls to the user to confirm the identity.  Pushing this decision to the user is ultimately what opens up the possibility of a man-in-the-middle (MITM) attack.  The security issue is not with self-signed certificates, but with the way users interact with them in the browser.


Purchase or generate a proper certificate for this service.

Check out, for Mand in the middle

You can purchase SSL certificates from Symantec

Denial Of Service (DoS) attacks via SQL Wildcards should be prevented

SQL Wildcard attacks force the underlying database to carry out CPU-intensive queries by using several wildcards. This vulnerability generally exists in search functionalities of web applications. Successful exploitation of this attack will cause Denial of Service (DoS).

Depending on the connection pooling settings of the application and the time taken for attack query to execute, an attacker might be able to consume all connections in the connection pool, which will cause database queries to fail for legitimate users.

By default in ASP.NET, the maximum allowed connections in the pool is 100 and timeout is 30 seconds. Thus if an attacker can run 100 multiple queries with 30+ seconds execution time within 30 seconds no one else would be able to use the database related parts of the application.


If the application does not require this sort of advanced search, all wildcards should be escaped or filtered.


OWASP Testing for SQL Wildcard Attacks

DoS Attacks using SQL Wildcards

Brief Summary

SQL Wildcard Attacks are about forcing the underlying database to carry out CPU-intensive queries by using several wildcards. This vulnerability generally exists in search functionalities of web applications. Successful exploitation of this attack will cause Denial of Service.

Description of the Issue

SQL Wildcard attacks might affect all database back-ends but mainly affect SQL Server because the MS SQL Server LIKE operator supports extra wildcards such as “[]”,”[^]”,”_” and “%”.

In a typical web application, if you were to enter “foo” into the search box, the resulting SQL query might be:

SELECT * FROM Article WHERE Content LIKE ‘%foo%’

In a decent database with 1-100000 records the query above will take less than a second. The following query, in the very same database, will take about 6 seconds with only 2600 records.

SELECT TOP 10 * FROM Article WHERE Content LIKE ‘%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R”_)][%](%[x])%a][$*”£$-9]_%’

So, if the tester wanted to tie up the CPU for 6 seconds they would enter the following to the search box:


Black Box testing and example

Testing for SQL Wildcard Attacks:

Craft a query which will not return a result and includes several wildcards. You can use one of the example inputs below.

Send this data through the search feature of the application. If the application takes more time generating the result set than a usual search would take, it is vulnerable.

Example Attack Inputs to send

    ‘%64_[^!_%65/%aa?F%64_D)_(F%64)_%36([)({}%33){()}£$&N%55_)$*£()$*R”_)][%55](%66[x])%ba][$*”£$-9]_%54’ bypasses modsecurity
    _[r/a)_ _(r/b)_ _(r-d)_
    %_[aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[! -z]@$!_%

Result Expected

If the application is vulnerable, the response time should be longer than usual.

SQL Wildcard attacks force the underlying database to carry out CPU-intensive queries by using several wildcards. This vulnerability generally exists in search functionalities of web applications. Successful exploitation of this attack will cause Denial of Service.

Here, it was possible to search by keying in a value for the forename/firstname field as M__E (i.e. M underscore underscore E) and the search returned results treating the two underscores as wildcards for any two characters.

This may still exist on the current code base so it’s a case of going through the forms and ensuring that it doesn’t occur / fix it if the vulnerability exists.

DoS Attacks Using SQL Wiltcards.pdf (567.23 kb)

Check the solution I have produced to prevent this Removing and Cleaning search content to prevent DoS attacks

HTTP Header Disclosure

Vulnerability overview/description

Due to unsanitized user input it is possible to inject arbitrary HTTP header values in certain HTTP responses of the Satellite Server. This can be exploited, for example, to perform session fixation and malicious redirection attacks via the Set-Cookie and the Refresh headers. Moreover, the Satellite Server caches these HTTP responses with the injected HTTP header resulting in all further requests to the same resource being served with the poisoned HTTP response, while these objects remain in cache.

Information Disclosure

Information disclosure enables an attacker to gain valuable information about a system. Therefore, always consider what information you are revealing and whether it can be used by a malicious user. The following lists possible information disclosure attacks and provides mitigations for each. 

Message Security and HTTP

If you are using message-level security over an HTTP transport layer, be aware that message-level security does not protect HTTP headers. The only way to protect HTTP headers is to use HTTPS transport instead of HTTP. HTTPS transport causes the entire message, including the HTTP headers, to be encrypted using the Secure Sockets Layer (SSL) protocol. 

Environment change

The web application returned information about itself in the HTTP header that could aid an attacker.  Default web server installations often include the vendor and version details of the web application, and possibly further information about scripting services also installed

User Enumeration – Login failure messages shouldn’t give out any information that results in vulnerabilities.

Is it possible to enumerate user account details within the Web application via the logon page?

Where an application requires account details to retrieve other information, it may be possible to enumerate the details based on the error message returned by the application.

In this case it was also possible to determine the state of the user account


Messages which allow an attacker to enumerate account details should be removed. A generic error message which does not disclose information about account information should be used.


OWASP Testing for user enumeration


  • Enumeration is the first attack on target network, enumeration is the process to gather the information about a target machine by actively connecting to it.
  • Enumeration means to identify the user account, system account and admin account. Enumerating windows active directory to find out these stuffs.
  • Discovering NetBIOS name enumeration with NBTscan.
  • Establishing null sessions and connections. Null sessions tools like Dumpsec, Winfo and Sid2User or more, may used to perform this attack.

The login failure messages can give away too much information and it would be possible to enumerate user details via the log-on page. It reports on whether an account exists/not and if an account is locked out or not etc.

There should ideally be just one generic message that’s of no use to a potential hacker.

– See more at:

Other Considerations

You’ll need to log somewhere in your application the actual reasons why the user could not login, this could be that the account is locked, suspened, deleted etc. 

By logging this information a system adminstrator or the like can see why a user could not get access to the application through the login page.

PenTest where to start

I would like to secure up an MVC application, and one way of insuring a secure application is to run through pentesting, Penetration Testing, but what is pentesting?


A penetration test, occasionally pentest, is a method of evaluating computer and network security by simulating an attack on a computer system or network from external and internal threats. The process involves an active analysis of the system for any potential vulnerabilities that could result from poor or improper system configuration, both known and unknown hardware or software flaws, or operational weaknesses in process or technical countermeasures. This analysis is carried out from the position of a potential attacker and can involve active exploitation of security vulnerabilities.

Pentests should performed be by someone who has no involvement in the application lifecycle process, someone or some group of people who are independent and will try and penetrate the application.  They will uncover security issues through penetration tests which are presented to the system’s owner. Effective penetration tests will couple this information with an accurate assessment of the potential impacts to the application and outline a range of technical and procedural countermeasures to reduce risks.

Penetration tests are valuable for several reasons:

  1. Determining the feasibility of a particular set of attack vectors
  2. Identifying higher-risk vulnerabilities that result from a combination of lower-risk vulnerabilities exploited in a particular sequence
  3. Identifying vulnerabilities that may be difficult or impossible to detect with automated network or application vulnerability scanning software
  4. Assessing the magnitude of potential business and operational impacts of successful attacks
  5. Testing the ability of network defenders to successfully detect and respond to the attacks
  6. Providing evidence to support increased investments in security personnel and technology

In a series of blogs I will be going over everything that I find and document down how to overcome such vulnerabilities.

Elmah or Microsoft Enterprise Library for Exception logging


Enterprise Library Logging Application Block

The Enterprise Library Logging Application Block simplifies the implementation of common logging functions. You can use the Logging Application Block to write information to a variety of locations:


·         The event log

·         An e-mail message

·         A database

·         A message queue

·         A text file

·         A Windows® Management Instrumentation (WMI) event

·         Custom locations using application block extension points


·         Multiple targets can be configured

·         Enterprise Library Configuration Console available for easy configuration

·         Large number of options to be configured may make it a bit daunting to start with

·         Invasive – requires code change to implement logging

·         Logs all kinds of events/information, not just for error logging

·         Formatters available for formatting the event message

·         Log filters allow filtering of log messages

·         Facilities for WCF integration



·         It will take you a bit to get up to speed with Enterprise Library – it’s not a 5 second install.

·         There’s a lot of configuration to do in the app.config/web.config file just to make it work. That said, once you understand it, it easier on other projects.

·         You must implement the Logging Block, not just the Exception Handling Block to log the information somewhere (event log, flat file, database, etc.)

·         It’s not just for logging exceptions. For example, you may want to get log events for when a user logs in or logs out of an application.

·         You can use the configuration file to change how logging works depending on the environment (i.e. Log exceptions for Production, log everything for Dev, etc.).

·         It’s not just for web, but for all kinds of applications.





ELMAH (Error Logging Modules and Handlers) is an application-wide error logging facility that is completely pluggable. It can be dynamically added to a running ASP.NET web application, or even all ASP.NET web applications on a machine, without any need for re-compilation or re-deployment.


Once ELMAH has been dropped into a running web application and configured appropriately, you get the following facilities without changing a single line of your code:


    Logging of nearly all unhandled exceptions.

    A web page to remotely view the entire log of recoded exceptions.

    A web page to remotely view the full details of any one logged exception, including coloured stack traces.

    In many cases, you can review the original yellow screen of death that ASP.NET generated for a given exception, even with customErrors mode turned off.

    An e-mail notification of each error at the time it occurs.

    An RSS feed of the last 15 errors from the log.


Runs using the Apache License (open source)



Comparison with ELMAH


Logging Application Block



  • True enterprise level exception handling framework, across layers, tiers, processes and services (in tandem with Exception Handling Application Block)
  • Logs all kinds of events, not just exceptions
  • Lightweight logging framework with extension points for ASP.NET web applications
  • By default logs unhandled exceptions
  • Error signaling allows handled exceptions to be logged
  • No support for non-error messages

Targets supported

  • The event log
  • An e-mail message
  • A database (supports multiple)
  • A message queue
  • A text file
  • A Windows® Management Instrumentation (WMI) event
  • Custom locations using application block extension points
  • Microsoft SQL Server
  • Oracle (OracleErrorLog)
  • SQLite (version 3) database file
  • Microsoft Access (AccessErrorLog)
  • Loose XML files
  • RAM (in-memory)
  • SQL Server Compact Edition
  • MySQL
  • PostgreSQL


No. Requires careful configuration and implementation in code

Fully pluggable out of the box, requires only configuration for basic features


  • XML configuration in the app.config/web.config as applicable
  • Enterprise Library Configuration Console tool available for ease in configuration

XML configuration in the web.config


Requires code change for implementation

No code change required for basic features


  • Easily extensible with multiple points for extensibility
  • Easy to extend for log message formatting and contextual information
  • No source code change required
  • Requires change to source code for any kind of extensibility
  • Error message formatting and contextual information addition requires source code changes


  • Easily scales for small to medium sized applications
  • Not enough data available for large sized applications

Requires more research



The Logging Application block beats ELMAH hands down in comprehensiveness. It can be used for logging all kinds of messages from all layers of various kinds of applications including ASP.NET, windows forms, WCF services etc. It can also be used for tracing for performance and debugging purposes.

On the other hand ELMAH is a light-weight framework for logging exceptions in ASP.NET applications.

ELMAH is very easy to configure and use. It is fully pluggable. Whereas implementation of the Logging Application block requires careful planning, configuration and is intrusive as it requires changes to code wherever logging is required.

One of the biggest benefits of the Enterprise Library is that it works in tandem with the Exception Handling block to implement a consistent strategy for processing exceptions in all the architectural tiers of an enterprise application including WCF Services.

While ELMAH is perfect for ASP.NET applications, for enterprise applications the Enterprise Library fulfils the comprehensiveness required.

Singleton Pattern the right way

The singleton pattern is used in almost all modern day programming languages, so why do I keep finding it written incorrectly in so many applications, so lets start with the right way

public sealed class SimpleNoLockLazy
        static readonly SimpleNoLockLazy instance = new SimpleNoLockLazy();

        // Explicit static constructor to tell C# compiler
        // not to mark type as beforefieldinit
        static SimpleNoLockLazy()


        public static SimpleNoLockLazy Instance
                return instance;

So why this implementation?   The reason for using a Singleton is for performance in a multi-threaded environment and this pattern is not only simple, but it is the fastest.  I have attached a benchmark application, which is based on Jon Skeet’s benchmark, but testing using a Parallel processes. (9.98 kb)

I found Jon Skeet’s article very useful

Encrypting Web.config for the website

Security is always high for installation to customer so is it not about time you encripted the connection string in your web.config file?

This is how it looks like before encrypting:

  <add name="Pubs" connectionString="Server=localhost;Integrated Security=True;Database=Pubs"
    providerName="System.Data.SqlClient" />
  <add name="Northwind" connectionString="Server=localhost;Integrated Security=True;Database=Northwind"
    providerName="System.Data.SqlClient" />

We can encrypt any section of your Web.config file on-the-fly and programatically. If you have full access to your Web server, you can encrypt your connection strings with this single command-line located in the in the %windows%\Microsoft.NET\Framework\versionNumber folder:

aspnet_regiis -pe "connectionStrings" -app "/SampleApplication"

Now, the section in your Web.config file will look like this:


If you can’t execute commands in your web server, for example, when using shared hosting, you still can encrypt it programatically:

Configuration config = Configuration.GetWebConfiguration(Request.ApplicationPath);
ConfigurationSection section = config.Sections["connectionStrings"]; 
section.ProtectSection ("DataProtectionConfigurationProvider"); 

References: Encrypting Web.Config Values in ASP.NET 2.0