en-US
search-icon

Secure Mobile Access 8.6 Web Application Firewall Feature Guide



Overview

This section provides an introduction to the Web Application Firewall feature. This section contains the following subsections:

What is Web Application Firewall?

Web Application Firewall is subscription-based software that runs on the SonicWall SMA appliance and protects web applications running on servers behind the appliance. Web Application Firewall also provides real-time protection for resources such as HTTP(S) bookmarks, Citrix bookmarks, web applications running on Application Offloading portals, and the SMA management interface and user portal that run on the SonicWall SMA appliance.

The Definitions of Terms table provides definitions of terminology related to SonicWall SMA Web Application Firewall.

 

Definitions of Terms

Term

Definition

Web Application Firewall

Security technology that is placed between a web server and the internet that analyzes layer 7 traffic sessions to protect applications from inbound attacks. A Web Application Firewall determines access permissions based on a pre-defined set of standard and custom rules.

Application Offloading

Application Offloading is the technique of porting part of an application to a nearby server or workstation with more capabilities than the device that will run the application, such as a PDA or mobile phone. Such a server is often public-facing, and may need protection from attacks. Offloaded applications operate in seamless mode in which the URLs in the proxied page are not rewritten by the proxy server.

Reverse Proxy

A proxy server that is deployed between one or more servers (often web servers) and the internet. All connections coming from the internet inbound to one of the web servers are routed through the proxy server, presenting a single interface to external users. The reverse proxy server can fulfill a request itself or pass the request to the main servers.

HTTP(S) Reverse Proxy

This reverse proxy intercepts HTTP(S) requests and responses.

Web Application Firewall provides real-time protection against a whole suite of web attacks such as Cross-site scripting, SQL Injection, OS Command Injection, and many more. The top ten vulnerabilities for web applications are tracked by OWASP, an open source community that focuses its efforts on improving the security of web applications. SonicWall SMA Web Application Firewall protects against these top ten vulnerabilities, defined in 2007 as follows:

 

OWASP Top Ten Vulnerabilities 

Name

Description

A1 - Cross Site Scripting (XSS)

XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute scripts in the victim's browser which can hijack user sessions, deface web sites, and possibly introduce worms.

A2 - Injection Flaws

Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data.

A3 - Malicious File Execution

Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise. Malicious file execution attacks affect PHP, XML and any framework which accepts filenames or files from users.

A4 - Insecure Direct Object Reference

A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization.

A5 - Cross Site Request Forgery (CSRF)

A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks.

A6 - Information Leakage and Improper Error Handling

Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data, or conduct more serious attacks.

A7 - Broken Authentication and Session Management

Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users' identities.

A8 - Insecure Cryptographic Storage

Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud.

A9 - Insecure Communications

Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications.

A10 - Failure to Restrict URL Access

Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly.

Slowloris Protection

In addition to the top ten threats listed above, Web Application Firewall protects against Slowloris HTTP Denial of Service attacks. This means that Web Application Firewall also protects all the backend web servers against this attack. Many web servers, including Apache, are vulnerable to Slowloris. Slowloris is especially effective against web servers that use threaded processes and limit the amount of threading allowed.

Slowloris is a stealthy, slow-acting attack that sends partial HTTP requests at regular intervals to hold connections open to the web server. It gradually ties up all the sockets, consuming sockets as they are freed up when other connections are closed. Slowloris can send different host headers, and can send GET, HEAD, and POST requests. The string of partial requests makes Slowloris comparable to a SYN flood, except that it uses HTTP rather than TCP. Only the targeted web server is affected, while other services and ports on the same server are still available. When the attack is terminated, the web server can return to normal within as little as 5 seconds, making Slowloris useful for causing a brief downtime or distraction while other attacks are initiated. Once the attack stops or the session is closed, the web server logs may show several hundred 400 errors.

For more information about how Web Application Firewall protects against the OWASP top ten and Slowloris types of attacks, see the How Does Web Application Firewall Work? .

Offloaded Web Application Protection

Web Application Firewall can also protect an offloaded web application, which is a special purpose portal created to provide seamless access to a web application running on a server behind the SMA/SRA appliance. The portal must be configured as a virtual host. It is possible to disable authentication and access policy enforcement for such an offloaded host. If authentication is enabled, a suitable domain needs to be associated with this portal and all SonicWall advanced authentication features such as One Time Password, Two-factor Authentication, and Single Sign-On apply to the offloaded host.

Application Profiling

Application Profiling (Phase 1) allows the administrator to generate custom rules in an automated manner based on a trusted set of inputs. This is a highly effective method of providing security to web applications because it develops a profile of what inputs are acceptable by the application. Everything else is denied, providing positive security enforcement. This results in fewer false positives than generic signatures, which adopt a negative security model. When the administrator places the device in learning mode in a staging environment, the SMA/SRA appliance learns valid inputs for each URL accessed by the trusted users. At any point during or after the learning process, the custom rules can be generated based on the “learned” profiles. Multiple applications can be profiled simultaneously.

Rate Limiting for Custom Rules

It is possible to track the rate at which a custom rule, or rule chain, is being matched. This is extremely useful to block dictionary attacks or brute force attacks. The action for the rule chain is triggered only if the rule chain is matched as many times as configured.

Cookie Tampering Protection

Cookie Tampering Protection is an important item in the Payment Card Industry Data Security Standard (PCI DSS) section 6.6 requirements and part of the Web Application Firewall evaluation criteria that offers strict security for cookies set by the backend web servers. Various techniques such as encryption and message digest are used to prevent cookie tampering.

Credit Card and Social Security Number Protection

Credit Card/SSN protection is a Data Loss Prevention technique that ensures that sensitive information, such as credit card numbers and Social Security numbers are not leaked within web pages. Once such leakage is detected, the administrator can choose to mask these numbers partially or wholly, present a configurable error page, or simply log the event.

PDF Reporting for WAF Monitoring and PCI DSS 6.5 and 6.6 Compliance

SPDF reporting is introduced for Web Application Firewall Monitoring and PCI DSS 6.5 and 6.6 Compliance. You can generate the reports on the Web Application Firewall > Status page. The timeline for generating the data published in the reports is configurable on the Web Application Firewall > Monitoring page.

Benefits of Web Application Firewall

Web Application Firewall is secure and can be used in various areas, including financial services, healthcare, application service providers, and e-commerce. The SonicWall SMA appliance uses SSL encryption to encrypt data between the Web Application Firewall and the client. SMA also satisfies OWASP cryptographic storage requirements by encrypting keys and passwords wherever necessary.

Companies using Web Application Firewall can reduce the development cost required to create secure applications and also cut out the huge turnaround time involved in deploying a newly found vulnerability fix in every web application by signing up for Web Application Firewall signature updates.

Resources accessed over Application Offloaded portals and HTTP(S) bookmarks can be vulnerable due to a variety of reasons ranging from badly designed architecture to programming errors. Web Application Firewall provides an effective way to prevent a hacker from exploiting these vulnerabilities by providing real-time protection to web applications deployed behind the SonicWall Secure Mobile Access/SRA appliance.

Deploying Web Application Firewall at the SMA/SRA appliance lets network administrators use application offloading even when it exposes web applications needing security to internal and remote users. Application offloading avoids URL rewriting, which improves the proxy performance and functionality.

There are several benefits of integrating Web Application Firewall with SonicWall SMA appliances. Firstly, identity-based policy controls are core to Web Application Firewall and this is easily achievable using the SonicWall Secure Mobile Access technology. Secondly, there are lower latencies due to the existing hardware-based SSL offloading. Most importantly, SMA/SRA appliances run web applications and must be protected from such attacks.

As small businesses adopt hosted services to facilitate supplier collaboration, inventory management, online sales, and customer account management, they face the same strict compliance requirements as large enterprises. Web Application Firewall on a SonicWall Secure Mobile Access/SRA appliance provides a convenient, cost-effective solution.

Web Application Firewall is easy to configure in the SonicWall SMA management interface. The administrator can configure Web Application Firewall settings globally, by attack priority, and on a per-signature basis. Once custom configuration settings or exclusions are in place, you can disable Web Application Firewall without losing the configuration, allowing you to perform maintenance or testing and then easily re-enable it.

How Does Web Application Firewall Work?

To use the Web Application Firewall feature, the administrator must first license the software or start a free trial. Web Application Firewall must then be enabled on the Web Application Firewall > Settings page of the SonicWall SMA management interface. Web Application Firewall can be configured to log or block detected attacks arriving from the internet.

The following sections describe how Web Application Firewall and SonicWall SMA prevent attacks such as Slowloris or those listed in the OWASP top ten, and how Web Application Firewall protects against information disclosure, and other capabilities:

How are Signatures Used to Prevent Attacks?

For Cross Site Scripting, Injection Flaws, Malicious File Execution, and Insecure Direct Object Reference vulnerabilities, the Web Application Firewall feature uses a black list of signatures that are known to make web applications vulnerable. New updates to these signatures are periodically downloaded from a SonicWall signature database server, providing protection from recently introduced attacks.

How signatures prevent attacks

When input arrives from the internet, Web Application Firewall inspects HTTP/HTTPS request headers, cookies, POST data, query strings, response headers, and content. It compares the input to both a black list and a white list of signatures. If pattern matching succeeds for any signature, the event is logged and/or the input is blocked if so configured. If blocked, an error page is returned to the client and access to the resource is prevented. The threat details are not exposed in the URL of the error page. If configured for detection only, the attack is logged but the client can still access the resource. If no signature is matched, the request is forwarded to the web server for handling.

What happens when no signature is matched

The Web Application Firewall process is outlined in the following flowchart.

Web Application Firewall process

In the case of a blocked request, the following error page is returned to the client:

This page is customizable under Web Application Firewall > Settings in the SMA management interface. Some administrators might want to customize the HTML contents of this page. Others might not want to present a user friendly page for security reasons. Instead, they might prefer the option to present an HTTP error code such as 404 (Not found) or 403 (Access Denied).

How is Cross-Site Request Forgery Prevented?

CSRF attacks are not detected with signature matching. Using this vulnerability, a hacker disguised as the victim can gain unauthorized access to application even without stealing the session cookie of a user. While a victim user is authenticated to a web site under attack, the user may unwittingly load a malicious web page from a different site within the same browser process context, for instance, by launching it in a new tab part of the same browser window. If this malicious page makes a hidden request to the victim web server, the session cookies in the browser memory are made part of this request making this an authenticated request. The web server serves the requested web page as it assumes that the request was a result of a user action on its site. To maximize the benefits, hackers typically target actionable requests such as data updates to carry out this attack.

To prevent CSRF attacks, every HTTP request within a browser session needs to carry a token based on the user session. To ensure that every request carries this token, Web Application Firewall rewrites all URLs contained in a web page similarly to how they are rewritten by the Reverse Proxy for HTTP(S) Bookmarks feature. If CSRF protection is enabled, this is also performed for Application Offloading.

CSRF protection is provided for anonymous mode as well. If CSRF protection is enabled, then an idle timeout set to the global idle timeout is enforced for anonymous access. If the session times out, an error message is displayed, forcing the user to revisit the site in a new window. If authentication is enforced for the portal, then the user is redirected to the login page for the portal.

How is Information Disclosure Prevented?

Web Application Firewall prevents Information Disclosure and Improper Error Handling by providing a way for the administrator to configure text containing confidential and sensitive information so that no web site accessed through the Web Application Firewall reveals this text. These text strings are entered on the Web Application Firewall > Settings page.

Beside the ability to pattern match custom text, signatures pertaining to information disclosure are also used to prevent these types of attacks.

Web Application Firewall protects against inadvertent disclosure of credit card and Social Security numbers (SSN) in HTML web pages.

* 
NOTE: Only text or HTML pages, and only the first 512K bytes are inspected for credit card or SSN disclosure.

Web Application Firewall can identify credit card and SSN numbers in various formats. For example, a SSN can be specified as XXX XX XXXX or XXX-XX-XXXX. Web Application Firewall attempts to eliminate false-positives by filtering out formats that do not conform to the credit card or SSN specification. For example, credit cards follow the Luhn’s algorithm to determine if an n-digit number could be a credit card number or not.

The administrator can set an appropriate action, such as detect (log), prevent, or just mask the digits that can reveal the user identity. Masking can be done fully or partially, and you can select any of the following characters for masking: #, *, -, x, X, ., !, $, and ?. The resulting masked number is similar to the appearance of credit card numbers printed on an invoice.

How are Broken Authentication Attacks Prevented?

The requirement for Broken Authentication and Session Management requires Web Application Firewall to support strong session management to enhance the authorization requirements for web sites. SonicWall SMA already has strong authentication capabilities with the ability to support One Time Password, Two-factor Authentication, Single Sign-On, and client certificate authentication.

For Session Management, Web Application Firewall pops up a session logout dialog box when the user portal is launched or when a user logs into an application offloaded portal. This feature is enabled by default when Web Application Firewall is licensed and can be disabled from the Web Application Firewall > Settings page.

The Web Application Firewall > Settings page also allows the administrator to configure the global idle session timeout. It is highly recommended that this timeout value is kept as low as possible.

How are Insecure Storage and Communications Prevented?

Insecure Cryptographic Storage and Insecure Communications are prevented by encrypting keys and passwords wherever necessary, and by using SSL encryption to encrypt data between the Web Application Firewall and the client. SonicWall SMA also supports HTTPS with the backend web server.

How is Access to Restricted URLs Prevented?

SonicWall SMA supports access policies based on host, subnet, protocol, URL path, and port to allow or deny access to web sites. These policies can be configured globally or for users and groups.

How are Slowloris Attacks Prevented?

Slowloris attacks can be prevented if there is an upstream device, such as a SonicWall SMA appliance, that limits, buffers, or proxies HTTP requests. Web Application Firewall uses a rate-limiter to thwart Slowloris HTTP Denial of Service attacks.

What Type of PCI Compliance Reports Are Available?

Payment Card Industry Data Security Standard (PCI DSS) 6.5 (Version 2.0) and PCI DSS 6.6 (Version 1.2) are covered in PCI reporting. The administrator can configure Web Application Firewall to satisfy these PCI requirements.

You can generate and download the PCI report file on the Web Application Firewall > Status page.

* 
NOTE: This is not an official PCI Compliance report. It is for your self-assessment only.

Two tables are dynamically generated in the PCI compliance report to display the status of each PCI requirement. The format of the table is shown in the example below:

The first column describes the PCI requirement.

The second column displays the status of the PCI requirement under current Web Application Firewall settings. There are four possible values for the status, distinguished by color.

Satisfied (Green)
Partially Satisfied (Orange)
Unsatisfied (Red)
Unable to determine (Black)

The third column provides comments and details explaining the status rating. If the status is Satisfied, no comments are provided.

How Does Cookie Tampering Protection Work?

The SonicWall Secure Mobile Access/SRA appliance protects important server-side cookies from tampering. There are two kinds of cookies:

Server-Side Cookies – These cookies are generated by backend web servers. They are important and have to be protected. They have optional attributes like Path, Domain, Secure, and HttpOnly.

Client-Side Cookies – These cookies are created by client side scripts in user browsers. They are not safe, and can be easily tampered with.

This feature is found on the Web Application Firewall > Settings page.

This page contains the following options:

Portals – A list of all application offloading portals. Each portal will have its own setting. The item Global is the default setting for all portals.

Tamper Protection Mode – Three modes are available:

Disabled – Cookie tamper protection is disabled.
Detect only – Log the tampered cookies only.
Prevent – Strip all the tampered cookies and log them.
Inherit Global – Use the global setting for this portal. This option is not available when Global is selected in the Portals drop-down list.

Encrypt Server Cookies – Choose to encrypt name and value separately. This affects client-side script behavior because it makes cookie names or values unreadable. Only server-side cookies are encrypted by these options.

Cookie Attributes – The attributes HttpOnly and Secure are appended to server-side cookies if they are enabled.

The attribute HttpOnly prevents the client-side scripts from accessing the cookies, which is important in mitigating attacks such as Cross Site Scripting and session hijacking. The attribute Secure ensures that the cookies are transported only in HTTPS connections. Both together add a strong layer of security for the server-side cookies.

* 
NOTE: By default, the attribute Secure is always appended to an HTTP connection even if Cookie Tampering Protection is disabled. This behavior is a configurable option, and can be turned off.

Client Cookies – The Client Cookies Allow option is enabled by default. In Strict mode, the Allow option is disabled. When disabled, client-side cookies are not allowed to be sent to the backend systems. This option does not affect server-side cookies.

Exclusion List – If the Exclusion List is enabled and contains a cookie, the cookie is passed as usual and is not protected. You can exclude server-side cookies and client-side cookies.

Exclusion list items are case sensitive, and in the format ‘CookieName@CookiePath’. Cookies with the same name and different paths are treated as different cookies. ‘CookiePath’ can be left empty to represent any path.

Import Global – Application Offloading portals can import the Global exclusion list.

How Does Application Profiling Work?

The administrator can configure application profiling on the Web Application Firewall > Rules page. Application profiling is performed independently for each portal.

After selecting the portal, you can select the type of application content that you want to profile. You can choose HTML/XML, Javascript, CSS, or All, which includes all content types such as images, HTML, and CSS. HTML/XML content is the most important from a security standpoint, because it typically covers the more sensitive web transactions. This content type is selected by default.

* 
NOTE: Content types can be saved for applications currently being profiled.

Then the SonicWall SMA appliance is placed in learning mode by clicking on the Begin Profiling button (the button then changes to End Profiling). The profiling should be done while trusted users are using applications in an appropriate way. The SMA records inputs and stores them as URL profiles. The URL profiles are listed as a tree structure on the Web Application Firewall > Rules page in the Application Profiling section.

Only the URLs presented as hyperlinks are accessible URLs on the backend server. You can click on the hyperlink to edit the learned values for that URL if the values are not accurate. You can then generate rules to use the modified URL profile.

The SMA learns the following HTTP Parameters:

Response Status Code
Post Data Length – The Post Data Length is estimated by learning the value in the Content-Length header. The maximum size is set to the power of two that is closest to and higher than this value. This accommodates the amount of memory that may have been allocated by the backend application. For example, for a Content Length of 65, the next power of two greater than 65 is 128. This is the limit configured in the URL profile. If the administrator determines that this is not accurate, the value can be modified appropriately.
Request Parameters – This is the list of parameters that a particular URL can accept.

When an adequate amount of input has been learned, you can click the End Profiling button and are ready to generate the rules from the learned input. You can set one of the following as a default action for the generated rule chains:

Disabled – The generated rules will be disabled rather than active.
Detect Only – Content triggering the generated rule will be detected and logged.
Prevent – Content triggering the generated rule will be blocked and logged.

If a rule chain has already been generated from a URL profile in the past, then the rule chain will be overwritten only if Overwrite existing Rule Chains for URL Profiles is selected. When you click the Generate Rules button, the rules are generated from the URL profiles. If a URL profile has been modified, those changes are incorporated.

How Does Rate Limiting for Custom Rules Work?

The administrator can configure rate limiting when adding or editing a rule chain from the Web Application Firewall > Rules page. When rate limiting is enabled for a rule chain, the action for the rule chain is triggered only when the number of matches within a configured time period is above the configured threshold.

This type of protection is useful in preventing Brute Force and Dictionary attacks. An example rule chain with a Rule Chain ID of 15002 is available in the management interface for administrators to use as reference.

The associated fields are exposed when Enable Hit Counters is selected at the bottom of the New Rule Chain or Edit Rule Chain screen.

Once a rule chain is matched, Web Application Firewall keeps an internal counter to track how many times the rule chain is matched. The Max Allowed Hits field contains the number of matches that must occur before the rule chain action is triggered. If the rule chain is not matched for the number of seconds configured in the Reset Hit Counter Period field, then the counter is reset to zero.

Rate limiting can be enforced per remote IP address or per user session or both. Track Per Remote Address enables rate limiting based on the attacker’s remote IP address.

Track Per Session enables rate limiting based on the attacker’s browser session. This method sets a cookie for each browser session. Tracking by user session is not as effective as tracking by remote IP if the attacker initiates a new user session for each attack.

The Track Per Remote Address option uses the remote address as seen by the SMA/SRA appliance. In the case where the attack uses multiple clients from behind a firewall that is configured with NAT, the different clients effectively send packets with the same source IP address and will be counted together.

Supported Platforms

Web Application Firewall is available on the following SMA/SRA appliances:

SMA 200
SMA 400
SRA 1600
SRA 4600
SMA 500v Virtual Appliance
 
* 
NOTE: Application profiling is supported only on the SMA 400, SRA 4600, and SMA 500v Virtual Appliance.