This section provides an introduction to the Web Application Firewall feature. This section contains the following topics:
Web Application Firewall is subscription-based software that runs on the Dell SonicWALL SRA appliance and protects Web applications running on servers behind the SRA. Web Application Firewall also provides real-time protection for resources such as HTTP(S) bookmarks, Citrix bookmarks, offloaded Web applications, and the SRA management interface and user portal that run on the Dell SonicWALL SRA appliance itself.
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. Dell SonicWALL SRA Web Application Firewall protects against these top ten, defined in 2007 as follows:
Table 15. 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.
|
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 How Does Web Application Firewall Work? .
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 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 Dell SonicWALL advanced authentication features such as One Time Password, Two-factor Authentication, and Single Sign-On apply to the offloaded host.
Starting in SRA 5.5, 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 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.
Starting in SRA 5.5, 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 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. See Configuring Cookie Tampering Protection Settings for additional information.
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. See Configuring Information Disclosure Protection for additional information.
Web Site Cloaking prevents guessing the Web server implementation and exploiting its vulnerabilities. See Configuring Web Site Cloaking for additional information.
Starting in SRA 5.5, PDF 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.
Web Application Firewall is secure and can be used in various areas, including financial services, healthcare, application service providers, and e-commerce. Dell SonicWALL SRA uses SSL encryption to encrypt data between the Web Application Firewall and the client. Dell SonicWALL SRA 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 Dell SonicWALL SRA appliance.
Deploying Web Application Firewall at the 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 Dell SonicWALL SRA appliances. Firstly, identity-based policy controls are core to Web Application Firewall and this is easily achievable using SSL VPN technology. Secondly, there are lower latencies due to the existing hardware-based SSL offloading. Most importantly, 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 Dell SonicWALL SRA appliance provides a convenient, cost-effective solution.
Web Application Firewall is easy to configure in the Dell SonicWALL SRA 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.
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 Dell SonicWALL SRA 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 SRA appliances prevent attacks such as Slowloris or those listed in the OWASP top ten, how Web Application Firewall protects against information disclosure, and how other features work:
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 Dell SonicWALL signature database server, providing protection from recently introduced attacks.
Figure 5. How signatures are used to 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. 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.
Figure 6. What happens when no signature is matched
The Web Application Firewall process is outlined in the following flowchart.
Figure 7. 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 SRA management interface. Some administrators may want to customize the HTML contents of this page. Others may not want to present a user friendly page for security reasons. Instead, they may prefer the option to present an HTTP error code such as 404 (Not found) or 403 (Access Denied).
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, typically, hackers targets 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, the Web Application Firewall feature 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.
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.
Beginning in SRA 5.5, Web Application Firewall protects against inadvertent disclosure of credit card and Social Security numbers (SSN) in HTML Web pages.
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.
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. Dell SonicWALL SRA 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.
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. Dell SonicWALL SRA also supports HTTPS with the backend Web server.
Dell SonicWALL SRA 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.
Slowloris attacks can be prevented if there is an upstream device, such as a Dell SonicWALL SRA security appliance, that limits, buffers, or proxies HTTP requests. Web Application Firewall uses a rate-limiter to thwart Slowloris HTTP Denial of Service attacks.
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.
In the report cover, the following information is displayed:
An example is shown below:
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 4 possible values for the status, distinguished by color.
The third column provides comments and details explaining the status rating. If the status is Satisfied, no comments are provided.
SRA appliances protect 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:
|
•
|
Prevent – Strip all the tampered cookies and log them.
|
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.
Allow Client Cookies – The Allow Client Cookies option is enabled by default. In Strict mode, the Allow Client Cookies 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.
The administrator can configure application profiling on the Web Application Firewall > Rules page. Application profiling is performed independently for each portal and can profile multiple applications simultaneously.
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.
Then the SRA 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 SRA 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 SRA learns the following HTTP Parameters:
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 the Overwrite existing Rule Chains for URL Profiles check box 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.
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 the Enable Hit Counters check box 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. The Track Per Remote Address check box enables rate limiting based on the attacker’s remote IP address.
The Track Per Session check box 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 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.
