Modern Web pages require scripts to function for rich functionality. Cross-site scripting (XSS) is an attack that targets Web pages that accept scripted input without properly validating them. Here is an example of one such attack:

To protect against XSS attacks

NetScaler AppFirewall when used in front of a Web server, scans all requests looking for potentially risky tags, such as the tag <script>, which indicates that the input is a script. When such a tag is found, depending on the configuration in the profile, it can either block or transform the request to render it harmless.

The following screenshot shows one such blocked attempt:

With regards to how unsafe tags are determined, there exists a predefined list. This list can be seen by navigating to Application Firewall | Signatures | Default Signatures. This list can be modified to suit your Web page's functionality by creating a copy of the original signature and editing the patterns and then applying that signature under the profile.

All e-commerce sites use a database of some form in the backend to be able to process product orders and record them. The Web page that is at the frontend of this database should be able to detect requests that are malicious and catch them before they get to the database layer where the focus is more performance and functionality, rather than security. SQL injection attacks use knowledge of SQL commands and vulnerabilities in SQL software to be able to directly manipulate entries in the database.

Here is an example of a SQL injection attack:

To protect against SQL injection attacks

AppFirewall engine has been coded to recognize SQL commands and keywords so when enabled, it blocks all entries that look like SQL, unless learned and applied as exceptions:

As with XSS protection, SQL injection protection also relies on a set of keywords already predefined on NetScaler, which can be accessed at: Application Firewall | Signatures | Default Signatures and can be adjusted by making a copy of this signature with the necessary changes to the keyword list.

Forceful browsing refers to the approach of manipulating URL paths in the browser directly instead of arriving at them by clicking on the links in the previous page. If the server doesn't prevent these, the Attackers can try to guess the path on the server and access content they are not entitled to.

As an example, consider a fictitious URL: www.example.com/users/aHacker/agenda.

While it might not be intended, the path is predictable for different users, if the name of the User is known. The attacker can try to guess the login name of the User, for example, aUser and try to access their agenda by force browsing to: www.example.com/users/aUser/agenda.

Web-based applications use parameters such as cookies and hidden form fields to track the state information for an ongoing customer order. Unless these fields are being monitored, an Attacker can tamper with cookies or hidden fields to modify the price or a product prior to purchasing, thus potentially buying it for much cheaper than the displayed price. Let's look at a few examples of such attacks.

Cookie tampering

Web applications rely heavily on cookies for functionality. Cookies serve primarily to identify users, thus they are very critical to a site's security. Cookie tampering (also called cookie poisoning) refers to an Attacker being able to modify cookies that denote something important about the transaction, such as the price or the User's identity.

To protect against cookie tampering

When the Server sets a cookie, AppFirewall starts watching it by hashing and signing the cookie and then including that hash as part of each request/response. It will then compare the cookie hash on all subsequent requests from the User to the original value to confirm that the cookie hasn't been tampered with.

In my example, I tried to mess with the PRICEID, a cookie that tracks the price of all items in the shopping cart at the time of checkout. I tried to buy an item of $15000 (HEX 3A98) for a price of $5000 (HEX 1388). AppFirewall detects this modification and rejects the cookie.

The original request is as follows:

Cookie: PRICEID=3A98; citrix_ns_id=5rpTb1eoVvZtoCSBwTLDHMA000; citrix_ns_id_192.168.1.55_%2F_wat=9f?NB2dUnEVUtEB0yS6v7CtO5Q1E9oA#p9WeT3UcPBdPvu/06UwpvPs8KJYA&

The tampered request is as follows:

Cookie: PRICEID=1388; citrix_ns_id=5rpTb1eoVvZtoCSBwTLDHMA000; citrix_ns_id_192.168.1.55_%2F_wat=9f?NB2dUnEVUtEB0yS6v7CtO5Q1E9oA#p9WeT3UcPBdPvu/06UwpvPs8KJYA&

AppFirewall will block the request with cookie PRICEID=1388 since the hash no longer matches after the modification. The log will look like this:

Note

Note that to track the application cookies, AppFirewall groups all the cookies together, hashes, and then signs them. It will generate one wlf cookie to track all persistent application cookies, and one wat cookie to track all application session cookies. CTX131488 discusses this behavior.

Many interactive websites use hidden fields to keep track of User choices such as the item chosen, its price, and so on. These form fields while hidden from the User's view and are still available to see when looking at the source code of a web page, at which point they can also be modified. Attackers can use this property to modify, for example, the price of items before they pay, thereby buying something at a much lower price than advertised by the site.

Here's a quick illustration using WebGoat as the vulnerable site:

The field Price is also present as a hidden field that the server uses to track the final price of the purchase. Fiddler has a hidden fields tab that allows you to see hidden fields and even modify them. In the following screenshot, I lowered the value of hidden field Price from $2999.99 to just $10.99:

If this change isn't detected and blocked, Attacker can purchase the TV for a fraction of its price.

To protect against hidden field tampering

When Form Field Consistency check is enabled, AppFirewall keeps track of the hidden fields and what their values were at each step in the session. When the same modification is repeated with AppFirewall Form Field Consistency (which is the name of the protection that enables this) enabled, the change in Hidden Field value during one of the requests is detected and blocked. Following is a log entry of a block:

All programs use buffers, that is, memory allocations to which parts of the program can be moved to for editing/manipulating before it's executed. Buffer sizes are finite.

During a buffer overflow attack, an attacker forces the application to accept more data than its buffers are designed to handle. By pushing the buffers past their limits, the Attacker can overwrite memory areas related to other functions, and in the process change the return address of those functions.

Return addresses are how a program knows the next instructions to process. So effectively, the attacker can change the application's flow of processing through a buffer overflow attack. For example, they can cause the authentication function to be bypassed.

To protect against buffer overflow attacks

AppFirewall can be configured to limit input values for URLs, Headers, and Cookies. The following is a block seen when the URL length exceeds what has been configured as allowed on AppFirewall:

Cross Site Request Forgery (CSRF) attack, as its name suggests, relies on the Attacker forging requests, such as bank transfers via a victim who is logged in to their account when the attack happens. The logged-in is important here, as this is important for the attack to succeed:

To protect against CSRF attacks

AppFirewall uses two key mechanisms:

• CSRF Form Tagging
• Referer Header Validation

With CSRF Form Tagging enabled, all forms sent by the server (such as forms for funds transfers) are tagged with a Form ID (fid), which is a randomly generated code.

Form IDs are embedded within the HTML source of the page. Here is what they look like when examining using fiddler:

When the User returns the completed form, NetScaler checks to see if the returned form contains the Form ID provided to the User earlier. This way even if the Attacker manages to get the victim to unknowingly generate a request with all the necessary cookies, the transfer will fail since the form to be used was never seen being served by the server. Here is an example of an attempt blocked by AppFirewall due to the Form ID being missing in the returned form:

Note

Note that the Integrated Caching feature and CSRF form tagging are not compatible.

The referer header is used to provide information to the server on the origin of the current request, that is, what site the User was previously on before being redirected to the current page. For example, if you visited http://www.example1.com/ and were redirected to http://example2.com/, the referer header on the redirect, if present, will show Referer: https://example.com.

The referer header can only be generated by the browser and cannot be forced by an attacker, which makes it a formidable mechanism in protecting against CSRF attacks. It means that the AppFirewall (through appropriate configuration) can restrict which redirect-based requests are admitted and which ones are dropped, based on the domain name of the original site.

Enabling the referer header validation is done in the Start URL Settings since both protections rely on this check:

On enabling referer header validation, NetScaler looks to see if the value of the referer header matches any of the exceptions configured in the start URL whitelist. If not, the request is rejected.

The following screenshot is an example of a block due to referer header mismatch:

Referer mismatch

Note

Note that some browsers may not present referer headers or this might be turned off for privacy reasons, so an option to validate only if present is also available.

In the current e-commerce landscape, web services serve a very important purpose, allowing application servers to talk to each other over the Internet. XML, using HTTP as the transport protocol, is a core component of Web Services and as such, needs to be protected.

Web services share some of the same vulnerabilities as HTML applications, which is why you see some of the protections offered to be the same, such as XML, XSS, and XML SQL injection protections. However, XML does have its uniqueness that is a result of how XML requests are structured.

Security offered by AppFirewall for XML mainly takes the form of understanding this structure and inspecting requests for XML well-formedness. XML is a lot stricter than HTML in terms of how the tags (called elements in XML) are used. If a poorly formed XML request is not caught, it can cause the XML Parser to crash and result in a denial of service.

The following is a simple example of a malformed request; here the poorly formed request has a mismatch between the opening and closing tags.

On seeing the mismatched tag, AppFirewall throws an XML Format check failed error, as shown in the following screenshot:

The error is not necessarily the most intuitive to follow, as it doesn't tell you what tag to correct. But this is where the knowledge of well-formedness rules comes in handy. The main rules to consider for well formedness are:

Source: http://www.w3schools.com/tags/tag_doctype.asp

Signatures use knowledge of known vulnerabilities, but also allow you to create your own rules using the current signature as a template.

To understand what each rule in the signature looks for, you can click into the signature and look at the Rule Patterns. The following is a random example I picked for demonstration.

This rule protects against a vulnerability that existed in the PCCS MySql database admin tool, where, by simply browsing to the path in the Match column, anyone could get a hold of the Admin password. To use signatures correctly, you need to know what your servers are in terms of OS and applications they are running, and based on this knowledge, you choose the rules that form the signature.

You can also customize each signature, using expressions, which gives you the flexibility of the NetScaler policy engine or writes Regex for maximum flexibility. A recommendation here is to use the fastmatch option where possible, which greatly reduces CPU overhead when looking for patterns. This option is available when adding a new Signature Rule, under the Rule Patterns page.