For deFense-in-depth against network threatsdata Loss preVention (dLp)The DLP subscription

prevents data breaches by scanning text and common file types in email, web, and FTP traffic to
detect sensitive information attempting to exit the network. ■A built-in library of over 200 rules
allows IT to quickly create and update corporate DLP policies. ■Built-in sensors are included for
PCI DSS and HIPAA compliance mandates.appLiCation ControL Application Control has
become an essential component of next-generation security. It protects the network and keeps
users on the tasks that matter by blocking unproductive and inappropriate apps. ■Gain control
over 2,000 web and business applications, using more than 2,500 unique signatures. ■Have
complete visibility into applications used, with intuitive monitoring and reporting capabilities.
■Control usage of applications by category, application, or application sub-functions. intrUsion

preVention serViCe (ips)By adding an IPS subscription, your network gains in-line protection
from attacks, including buffer overflows, SQL injections, and cross-site scripting attacks. ■All ports
and protocols are scanned to block network, application, and protocol-based attacks. ■Blocked
sites list saves valuable processing time by dynamically blocking IP addresses that have been
positively identified as the source of an attack. weBBLoCkerURL and content filtering are
indispensable for controlling access to sites that host objectionable material or pose network
security risks. These include known spyware and phishing sites. ■Configure over 100 web
categories to stop the sites and web tools you most want to block, and enable access by user,
group, domain, and need for maximum flexibility ■URL database is hosted in the cloud to simplify
setup and administration. A local install option is also available. gatewaY antiVirUsScans traffic
on all major protocols to stop threats before they can gain access to your servers and execute
their dangerous payloads.■Heuristic analysis identifies viruses and dangerous code that
signatures can’t catch.■Decompresses and scans all common formats,
including .rar, .zip, .gzip, .tar, .jar, .chm, .lha, .cab., .arj, .ace, .bz2, and multiple layers of
compression. repUtation enaBLed deFenseWatchGuard XTM is the only unified threat
management system on the market that includes a powerful, cloud-based reputation lookup
service to ensure faster, safer web surfing. ■Continuous updates keep current with dynamic web
content and changing web conditions. ■Up to 50% of URL scanning can be skipped without
compromising security, resulting in faster browsing times and greater throughput at the
gateway.spaMBLoCkerRely on spamBlocker’s industry-leading Recurrent Pattern Detection
(RPD™) technology to detect spam outbreaks as they emerge for immediate, continuous
protection from unwanted and dangerous email. ■Block spam regardless of the language, format,
or content of the message – even image-based spam that other anti-spam products often miss. ■
RPD identifies and blocks viral payloads for an additional layer of real-time anti-virus protection

Detect

 Breach Detection: Too often, organisations are unaware they have been breached.
Our systems will detect any breach rapidly.
 Intrusion Prevention Solutions: We protect your network’s vulnerabilities.
 PhishNet: A scanning system to protect against phishing attacks.
 Vulnerability Scan: Continuous scanning of Internet-facing systems to protect
against phishing attacks.

Java PreparedStatement
A PreparedStatement represents a precompiled SQL statement that can be executed multiple
times without having to recompile for every execution.

Secure Usage

1PreparedStatement stmt = connection.prepareStatement("SELECT * FROM users

WHERE userid=? AND password=?");
2stmt.setString(1, userid);
3stmt.setString(2, password);
4ResultSet rs = stmt.executeQuery();

This code is not vulnerable to SQL Injection because it correctly uses parameterized queries.
By utilizing Java's PreparedStatement class, bind variables (i.e. the question marks) and the
corresponding setString methods, SQL Injection can be easily prevented.

Vulnerable Usage

1// Example #1
String query = "SELECT * FROM users WHERE userid ='"+ userid + "'" + " AND
2
password='" + password + "'";
3Statement stmt = connection.createStatement();
4ResultSet rs = stmt.executeQuery(query);

This code is vulnerable to SQL Injection because it uses dynamic queries to concatenate
malicious data to the query itself. Notice that it uses the Statement class instead of the
PreparedStatement class.

1// Example #2
String query = "SELECT * FROM users WHERE userid ='"+ userid + "'" + " AND
2
password='" + password + "'";
3PreparedStatement stmt = connection.prepareStatement(query);
4ResultSet rs = stmt.executeQuery();

This code is also vulnerable to SQL Injection. Even though it uses the PreparedStatement
class it is still creating the query dynamically via string concatenation.

Java CallableStatement

Java CallableStatement class is used to execute SQL stored procedures. Invoking a stored
procedure or a function using CallableStatement in itself is not vulnerable to SQL Injection;
however, the underlying database code could be vulnerable. Refer to the Database Code
section of this guide to see how to write secure database code.
How to Fix Cross-Site Scripting (XSS) Using Microsoft .Net Web Protection
Library

HTML Encoding

The purpose of HTML encoding dynamic data is to prevent malicious HTML/Script from
being injected into the web page and later executed by the browser.

Secure Usage

1HTML Encode Binding Shortcut

2<td><%#: Item.Address %></td>

3 

4HTML Encode Render Shortcut

5<td><%: Item.Address %></td>

The above code is not vulnerable to XSS because the dynamic Address property is being
HTML encoded before being written to a HTML context. In ASP .NET 4.5, the HTML
encode binding shortcut (<%#:) was introduced to allow developers to HTML encode
dynamic values being bound in the HTML markup. Additionally, in ASP .NET 4.0 the
HTML encode render shortcut (<%:) also added to allow developers to automatically HTML
encoded content being rendered directly to the page.

Vulnerable Usage

1HTML Binding
2<td><%# Item.Address %></td>

3 

4HTML Render

5<td><%= Item.Address %></td>

The above code is vulnerable because the dynamic Address property is written to the browser
without HTML encoding. If an attacker had the ability to edit the address field, then a
malicious value, such as alert(document.cookie);, could be entered to inject content into the
page.

Secure Usage

1ASPX:
<td><asp:Label id='lblAddress' runat='server'></asp:Label></td>
2
 
3
ASPX.CS:
4
lblName.Text =
5Microsoft.Security.Application.Encoder.HtmlEncode(Request['Address']);

The above code is not vulnerable to XSS because the Address request parameter is being
HTML encoded with the Microsoft Web Protection Library (WPL) before being written to a
HTML context. It should be noted that in ASP .NET 4.5, the Web Protection Library is the
default encoding library.

Vulnerable Usage

1ASPX:

2<td><asp:Label id='lblAddress' runat='server'></asp:Label></td>

3 

4ASPX.CS:

5lblName.Text = Request['Address'];

The above code is vulnerable because the Label.Text property does not automatically HTML
encode its contents, and the dynamic Address request parameter is written to the browser
without HTML encoding. This could allow an attacker to set the address request parameter to
a malicious value, such as alert(document.cookie);, and inject content into the page.

For a complete listing of the ASP .NET controls and their default encoding, please see the
following: http://blogs.msdn.com/b/sfaust/archive/2008/09/02/which-asp-net-controls-
automatically-encodes.aspx

JavaScript Encoding

The purpose of JavaScript encoding dynamic data is to prevent malicious script from being
injected into the JavaScript being executed in the browser.

Secure Usage

<a onclick='<%# string.Format('ConfirmDelete({0})',

1Microsoft.Security.Application.Encoder.JavaScriptEncode(Item.Name))
%>'>Delete</a>

The above code is not vulnerable to XSS because the dynamic Name property is being
JavaScript encoded with the Microsoft Web Protection Library (WPL) before being written
into the JavaScript context. In this case, the JavaScriptEncode method must be used over the
HTML binding shortcut (<%#:) because the shortcut only works for HTML contexts. Also, it
should be noted that the JavaScriptEncode method returns the dynamic value properly
encoded and wrapped in tick marks. For example, if the name were Bob O'Neill, the return
value would be 'Bob Ox27Neill'.

Vulnerable Usage

<a onclick='<%# string.Format('ConfirmDelete('{0}')', Item.Name)

1%>'>Delete</a>

The above code is vulnerable because the dynamic Name property is not JavaScript encoded
before being written into the JavaScript context. If an attacker had the ability to edit the name
field, then a malicious value, such as ');alert(document.cookie);//, could be used to break out
of the intended JavaScript function and execute additional commands in the browser.

URL Encoding

The purpose of URL encoding dynamic data is to prevent malicious script from being
injected into a URL.

Secure Usage
 <a href=<%# Microsoft.Security.Application.Encoder.UrlEncode(Item.Url)
1%>>View Details</a>

The above code is not vulnerable to XSS because the dynamic Url property is being URL
encoded with the Microsoft Web Protection Library (WPL) before being written to the href
attribute. In this case, the UrlEncode method must be used over the HTML binding shortcut
(<%#:) because the shortcut only works for HTML contexts.

Vulnerable Usage

1<a href=<%# Item.Url %>>View Details</a>

The above code is vulnerable because the dynamic Url property is not URL encoded before
being written into the URL context. If an attacker had the ability to edit the url field, then a
malicious value, such as javascript:alert(document.cookie), could be used to execute script in
the browser.

Contributors

James Jardine

How To Fix Cross-Site Request Forgery (CSRF) using Microsoft .Net

ViewStateUserKey and Double Submit Cookie

Overview

Cross-Site Request Forgery is an attack where a user is forced to execute an action in a web
site without knowing the action ever took place. If a web site is vulnerable, an attacker can
capture a well-known action and craft a malicious link duplicating the action. By luring a
victim via email or another public web site to a web page that contains the malicious link, the
action may be executed on the victim's behalf if they have an authenticated session in the
vulnerable site.

To mitigate this vulnerability, a random nonce (one time token) should be added to the
parameters required to execute each action and validated prior to execution. If this solution
were implemented in our example above, the malicious link crafted by the attacker would
contain a token that is no longer valid. As a result, the action requested on the victimâs behalf
would be rejected without a valid token.

ViewStateUserKey & Double Submit Cookie

Starting with Visual Studio 2012, Microsoft added built-in CSRF protection to new web
forms application projects. To utilize this code, add a new ASP .NET Web Forms
Application to your solution and view the Site.Master code behind page. This solution will
apply CSRF protection to all content pages that inherit from the Site.Master page.
The following requirements must be met for this solution to work:

 All web forms making data modifications must use the Site.Master page.
 All requests making data modifications must use the ViewState.
 The web site must be free from all Cross-Site Scripting (XSS) vulnerabilities. See how to fix
Cross-Site Scripting (XSS) using Microsoft .Net Web Protection Library for details.

1 public partial class SiteMaster : MasterPage

2 {

3     private const string AntiXsrfTokenKey = "__AntiXsrfToken";

4     private const string AntiXsrfUserNameKey = "__AntiXsrfUserName";

5     private string _antiXsrfTokenValue;

6  

7     protected void Page_Init(object sender, EventArgs e)

    {
8
        //First, check for the existence of the Anti-XSS cookie
9
        var requestCookie = Request.Cookies[AntiXsrfTokenKey];
10
        Guid requestCookieGuidValue;
11
 
12
        //If the CSRF cookie is found, parse the token from the cookie.
13
        //Then, set the global page variable and view state user
14        //key. The global variable will be used to validate that it
matches in the view state form field in the Page.PreLoad
15
        //method.
16
        if (requestCookie != null
17
        && Guid.TryParse(requestCookie.Value, out
18requestCookieGuidValue))

19        {
            //Set the global token variable so the cookie value can be
20
            //validated against the value in the view state form field in
21
            //the Page.PreLoad method.
22
            _antiXsrfTokenValue = requestCookie.Value;
23
 
24
25            //Set the view state user key, which will be validated by the

26            //framework during each request

            Page.ViewStateUserKey = _antiXsrfTokenValue;
27
        }
28
        //If the CSRF cookie is not found, then this is a new session.
29
        else
30
        {
31
            //Generate a new Anti-XSRF token
32            _antiXsrfTokenValue = Guid.NewGuid().ToString("N");

33 

34            //Set the view state user key, which will be validated by the

35            //framework during each request

36            Page.ViewStateUserKey = _antiXsrfTokenValue;

37 

38            //Create the non-persistent CSRF cookie

            var responseCookie = new HttpCookie(AntiXsrfTokenKey)
39
            {
40
                //Set the HttpOnly property to prevent the cookie from
41
                //being accessed by client side script
42
                HttpOnly = true,
43
 
44
                //Add the Anti-XSRF token to the cookie value
45                Value = _antiXsrfTokenValue

46            };

47 

48            //If we are using SSL, the cookie should be set to secure to

49            //prevent it from being sent over HTTP connections

50            if (FormsAuthentication.RequireSSL &&

            Request.IsSecureConnection)
51
52            responseCookie.Secure = true;

53 

54            //Add the CSRF cookie to the response

            Response.Cookies.Set(responseCookie);
55
        }
56
 
57
            Page.PreLoad += master_Page_PreLoad;
58
        }
59
 
60
        protected void master_Page_PreLoad(object sender, EventArgs e)
61
        {
62            //During the initial page load, add the Anti-XSRF token and
user
63
            //name to the ViewState
64
            if (!IsPostBack)
65
            {
66
                //Set Anti-XSRF token
67                ViewState[AntiXsrfTokenKey] = Page.ViewStateUserKey;

68 

69                //If a user name is assigned, set the user name

70                ViewState[AntiXsrfUserNameKey] =

71                Context.User.Identity.Name ?? String.Empty;

72            }
            //During all subsequent post backs to the page, the token
73
value from
74            //the cookie should be validated against the token in the
view state
75
            //form field. Additionally user name should be compared to
76the

77            //authenticated users name

78            else
79

80            {

81                //Validate the Anti-XSRF token

82                if ((string)ViewState[AntiXsrfTokenKey] !=
_antiXsrfTokenValue
83
                || (string)ViewState[AntiXsrfUserNameKey] !=
84
                (Context.User.Identity.Name ?? String.Empty))
85
            {
86            throw new InvalidOperationException("Validation of

87            Anti-XSRF token failed.");

88            }

89        }
    }
90
}
91

92

Note that the above code example is auto-generated by Visual Studio 2012. But, it can be
implemented as outlined above in prior versions of Visual Studio to provide the same
protection against CSRF attacks.

Contributors

James Jardine