Applies To:

Show Versions Show Versions

Manual Chapter: Protecting XML Applications
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

11 
Because XML is used as a data exchange mechanism, it is important to inspect, validate, and protect XML transactions. With XML security, you can protect the following applications:
You implement XML security by creating an XML profile for a security policy. The XML profile can protect XML applications in the following ways:
Does the application use validation files, for example, an XML schema or WSDL document?
If yes, you must obtain these files.
For web services, do the clients support secure web services with encryption and decryption capabilities?
If so, you can configure web services security to handle the decryption and encryption of XML data.
Does the application use XML digital signatures for signing and verification?
Web services security can verify requests and sign responses.
What applications are on the back end?
There can be more than one, for example, an Expat XML parser and an Oracle® database server.
Do you want to use encryption for SOAP messages?
If yes, you must obtain the certificate files.
You must have already created a security policy for a web application using the Deployment wizard by following the steps in Creating a Security Policy for XML Transactions in the BIG-IP® Application Security Manager: Getting Started Guide.
Figure 11.1 shows an overview of the tasks for configuring XML security.
To configure security for SOAP web services, the security policy needs to have an XML profile. An XML profile defines the XML properties that a security policy enforces for XML applications. You must associate the XML profile with a URL or with a parameter.
Some web services have a WSDL or XML schema document to describe the language that the application uses to communicate with its remote users and systems. The XML profile can validate whether the incoming traffic complies with the WSDL or XML schema document. However, neither a WSDL nor an XML schema file is required to configure a security policy for web services. Traffic that does not comply causes an XML data does not comply with schema or WSDL document violation if the violation is set to Alarm or Block.
Note: Creating an XML profile requires external network access to verify the XML schema link. The time needed to create an XML profile varies, depending on the size of the WSDL document or XML schema file, and your connection speed.
If you used the Deployment wizard to create a security policy by selecting the Create a policy for XML and web services manually scenario, you already have a security policy with an XML profile. You can go to Content Profiles: XML Profiles and click the profile you created to review its settings with the following procedure, or skip to Implementing web services security to configure encryption and signing.
1.
On the Main tab, expand Application Security, point to Content Profiles, and click the create icon () next to XML Profiles.
The Create New XML Profile screen opens.
3.
In the Profile Name field, type a name for the XML profile.
4.
If you plan to implement web services security, for the Web Services Security setting, select Enabled, and refer to Implementing web services security, for details about additional tasks that you should perform.
5.
In the XML Firewall Configuration area, for the Configuration Files setting, if your web service uses a WSDL or XML schema file, perform steps a and b, then proceed to step 6. Otherwise, skip to step 8.
a)
For the File option, click Browse, and navigate to the .wsdl or .xsd file.
Note: The file you upload must use UTF-8 character encoding.
b)
Click Upload.
The system uploads the file and lists its contents on the screen.
Important: When a WSDL or XML schema document refers to another WSDL or XML schema document, the system gives you the option of importing it. If circular dependencies exist in the files (for example, schema 1 refers to schema 2, which refers back to schema 1) import schema 1, then schema 2, then schema 1 again. This creates a mapping between the files.
6.
If you specified a referenced file type (in step 5), in the Import URL field, type the appropriate URL:
7.
For the system to attempt to locate and use files referenced in the WSDL or XML schema document, ensure that the Follow Schema Links setting is enabled.
To use this setting, make sure the DNS server is on the DNS lookup server list, and configure the DNS server on the BIG-IP system (System > Configuration > Device > DNS).
Tip: If you disable this setting and the uploaded file refers to other XML schemas, the system lists the referenced files in an error message at the top of the screen.
8.
To permit SOAP messages to contain attachments, enable the Allow Attachments in SOAP Messages setting.
a)
For the system to verify the SOAPAction header, enable the Validate SOAPAction Header setting. The system automatically enables this setting when you upload a WSDL file.
b)
Review the Valid SOAP Methods; to disable any of them, clear the Enabled check box. For details, see Managing SOAP methods.
10.
In the Defense Configuration area, for Defense Level, select High, Medium, or Low.
To customize defense settings, see Fine-tuning XML defense configuration.
11.
12.
To mask sensitive XML data, click Sensitive Data Configuration and then add namespaces. For details on this task, see Masking sensitive XML data.
13.
Click the Create button.
The system adds the XML profile to the security policy.
Web services security adds another level of protection to XML-based web applications by embedding security-related data within SOAP messages. For web services that Application Security Manager protects, you can use web services security to enable:
XML digital signatures ensure the integrity of the message data, and can authenticate the identity of the document signer. The system uses certificates as follows:
Server Certificates: To decrypt SOAP messages from a web client to a web service, or sign SOAP messages from a web service back to a web client.
Client Certificates: To encrypt SOAP messages from a web service to a web client, or verify SOAP messages from a web client to a web service.
If you want to use features, such as encryption, you can add web services security to an XML profile. Before you configure web services security, you must complete the following tasks:
To use web services security for encryption, decryption, and digital signature signing and verification, you must upload client and server certificates onto the Application Security Manager. The system uses these certificates to process Web Services Security markup in SOAP messages within requests and responses to and from web services.
You must import both client and server certificates to perform encryption and decryption on the Application Security Manager. The certificates you import can be used for any web applications.
1.
On the Main tab, expand Application Security, point to Options, then click Certificates Pool.
The Certificates Pool screen opens.
Note: The server and client certificates must be .PEM files in x509v3 format. Also, the server certificate should contain the servers private key.
a)
Click Add.
The Create New Certificate screen opens.
b)
For Name, type a name for the certificate.
c)
For Type, select Client or Server.
d)
For the .PEM File setting, select Upload File, then browse to and upload a certificate, or select Paste text to paste a copy of the certificate in the field.
e)
To store the certificate even if it is expired or untrusted, enable the Save Expired/Untrusted Certificate setting.
f)
Click Add.
You can use web services security features of Application Security Manager to off load encryption and decryption of SOAP messages from the application server. Web services security can also handle verification of digital signatures and digital signing of SOAP messages.
1.
On the Main tab, expand Application Security, point to Content Profiles, then click XML Profiles.
2.
In the XML Profiles list, click the name of the XML profile for which you want to configure web services security, or create a new profile.
The XML Profile Properties screen opens.
3.
For the Web Services Security setting, select Enabled.
4.
Click Web Services Security Configuration.
The XML Profile Properties screen displays Web Services Security Configuration options.
On the XML Profile Properties screen, in the Credentials area of the Web Services Security Configuration, configure the certificates the system uses to process SOAP messages in requests and responses.
Tip: Click the Certificates Pool link (next to Credentials) if you need to upload certificates.
1.
For Server Certificate, select one server certificate from the list.
The system uses the server certificate to decrypt SOAP messages from a web client to a web service, or sign SOAP messages from a web service back to a web client.
2.
For Client Certificates, select names from the Available list and then move them into the Members list.
The system uses the client certificates to encrypt SOAP messages from a web service to a web client, or to verify SOAP messages from a web client to a web service.
On the XML Profile Properties screen, in the Web Services Security Configuration, a Request area appears after you specify the certificates. Indicate here how you want the system to handle requests.
1.
For Action, select the action you want the system to perform on SOAP message requests:
Verify and Decrypt decrypts and verifies digitally signed SOAP messages. We recommend that you use this value.
Decrypt decodes encrypted SOAP messages.
Verify validates digitally signed SOAP messages. This option is available only if you imported client certificates, but no server certificate.
2.
For Role/Actor, select a role to determine which security headers you want the system to process:
Do not check role/actor: Process all security headers regardless of the role. This is the default setting.
Custom role/actor: Process security headers that contain the role you type in the adjacent box.
next: Process security headers that contain the role next or http://www.w3.org/2003/05/soap-envelope/role/next.
none: Process security headers that contain the role none or http://www.w3.org/2003/05/soap-envelope/role/none.
ultimateReceiver: Process security headers that contain the role ultimateReceiver or http://www.w3.org/2003/05 /soap-envelope/role/ultimateReceiver.
3.
Select the Enforce And Verify Defined Elements check box to confirm that elements, defined in the Namespaces and Elements area of the screen and contained in the request, are signed and verified. It also enforces the options SOAP Body in Request Must Be Signed and Verified and Enforce Timestamp In Request.
On the XML Profile Properties screen, in the Response area of the Web Services Security Configuration, configure how you want the system to handle responses. You need to have added client and server certificates to the system before you can configure web services security responses.
1.
In the Response area, for Action, select the action you want the system to perform on SOAP message responses:
Encrypt encrypts, in the response, the elements defined in the Namespaces and Elements area of the screen.
Sign digitally signs, in the response, the elements defined in the Namespaces and Elements area of the screen.
Sign, Then Encrypt first digitally signs and then encrypts, in the response, the elements defined in the Namespaces and Elements area of the screen. We recommend that you use this value.
Encrypt, Then Sign first encrypts, then digitally signs, in the response, the elements defined in the Namespaces and Elements area of the screen.
Note: For the action to occur, you must also check Apply Action To Defined Elements.
Enable the Add Timestamp setting.
Type the length of time (in seconds) the timestamp should be valid. The default is 300 seconds. If you want the timestamp to be valid for an unlimited amount of time, enter 0. The maximum value is 100,000,000 seconds.
3.
For Role/Actor, select a role to insert into the security header of SOAP messages:
Do not assign role/actor: If the document contains a security header without a role/actor, the system inserts the cryptographic information into the security header. This is the default setting.
Assign custom role/actor: If the document contains a security header with a custom role/actor, the system inserts the cryptographic information into the existing security header. In the field, type the custom role/actor attribute.
next: If the document contains a security header with the next role/actor, the system inserts the cryptographic information into that security header.
none: If the document contains a security header with the none role/actor, the system inserts the cryptographic information into that security header.
ultimateReceiver: If the document contains a security header with the ultimateReceiver role/actor, the system inserts the cryptographic information into that security header.
4.
If the response action includes sign, for Signature Algorithm, select the type of signature algorithm used to sign parts of SOAP messages in responses that match the response elements that you configure in the Namespaces and Elements area of the screen. Select one of the following:
RSA-SHA-1 (the default value) uses the RSA public cryptosystem for encryption and authentication with the SHA-1 hash function.
HMAC-SHA-1 uses secret-key hashing with the SHA-1 hash function.
Tip: Be sure your clients support this type of encryption.
5.
If the response action includes encryption, for Encryption Algorithm, select the type of encryption used for responses that match the response elements that you configure in the Namespaces and Elements area of the screen. Select one of the following:
6.
If the response action includes encryption, for Key Transport Algorithm, select the type of encryption to use for encrypting and decrypting keys (RSA-1.5 or RSA-OAEP).
7.
Enable the Apply Action To Defined Elements setting to perform the action you selected in the Action setting on responses containing the elements defined in the Namespaces and Elements area of the screen.
On the XML Profile Properties screen, in the Namespaces and Elements area of the Web Services Security Configuration, specify which parts of the XML document you want the system to process.
1.
For Namespace Mappings, specify the namespace mappings the system uses for XPath queries:
a)
For Prefix, type the namespace prefix.
b)
For Namespace, type the URL that the prefix is mapped to.
c)
Click Add to add the namespace to the list.
2.
Enable the SOAP Body In Request Must Be Signed And Verified setting to verify that the message contains a SOAP body, the SOAP body is digitally signed, and the digital signature is verified. If not, the system issues a Verification Error violation.
Note: For this setting to work, you must also select the Enforce and Verify Defined Elements setting in the earlier Request area.
3.
Enable the Enforce Timestamp In Request setting to verify that the SOAP message contains a valid timestamp, the timestamp is not expired, and the digital signature is verified. If the request has no timestamp, the Missing Timestamp violation occurs. If the timestamp is expired, the system issues the Expired Timestamp violation.
Note: For this setting to work, you must also check Enforce and Verify Defined Elements.
4.
Enable the Apply Action to Entire Response Body Value setting to apply the response action you selected to the whole SOAP message (/soapenv:Envelope/soapenv:Body). If not checked, the action occurs only on the elements that are configured on this screen.
5.
For the Elements setting, perform these steps for each element you want the system to process in responses:
a)
For Apply to, select Response.
b)
For XPath, type an XPath expression to specify which parts of the XML document to encrypt. For details, see Writing XPath queries.
c)
For Encryption Method, select whether to encrypt the markup and the text (With markup) or the text only (Value only).
d)
Click Add.
Note: To process these elements, you must also check Apply Action To Defined Elements.
6.
For the Elements setting, perform these steps for each element you want the system to process in requests:
a)
For Apply to, select Request.
b)
For XPath, type an XPath expression to specify which parts of the XML document to encrypt. For details, see Writing XPath queries.
c)
Click Add.
Note: To process these elements, you must also check Enforce and Verify Defined Elements.
1.
On the XML Profile Properties screen, click the Update button.
The system updates the XML profile to include the web services security configuration.
2.
In the editing context area, click the Apply Policy button and confirm to activate the updated security policy.
You have finished configuring web services security on the security policy using the default defense configuration settings. If you want to adjust the settings, refer to Fine-tuning XML defense configuration.
If you want to process specific elements in the XML document, you must write an XPath expression that indicates which parts to process. You specify the XPath in the Web Services Security Configuration area of the XML profile.
When writing XPath queries, you use a subset of the XPath syntax described in the XML Path Language (XPath) standard at http://www.w3.org/TR/xpath. Application Security Managers XPath syntax allows only expressions that correspond to element values.
Use wildcards as needed (use * for elements and namespaces); for example, //emp:employee/*.
Table 11.1 summarizes the syntax for XPath expressions.
Selects nodes in the document from the current node that match the selection, no matter where they are.
Table 11.2 shows examples of XPath queries.
Table 11.2 XPath examples 
Selects all b elements no matter where they are in the document.
Selects any element in a namespace bound to prefix b, which is a child of the root element a.
Selects elements in the namespace of element c, which is bound to prefix b, and is a child of element a.
When you upload a WSDL document, the system automatically populates a list of SOAP methods in the validation configuration of the XML profile. Additionally, the system adds the SOAP methods as URLs in the security policy, and automatically associates the XML profile with the URLs.
The system configures into the policy all relevant URLs that it finds in the WSDL and designates them as valid SOAP methods. By default, all methods are enabled, which means that the security policy allows those methods. If you disable a SOAP method, and a request contains that method, the system issues the SOAP method not allowed violation, and blocks the request if the enforcement mode is blocking.
Note: Before you can start this task, you must have already uploaded a WSDL document in the XML profile. Refer to To create an XML profile for SOAP web services, if you have not performed this task.
1.
On the Main tab, expand Application Security, point to Content Profiles, and click XML Profiles.
The XML Profiles screen opens.
3.
Click the name of the profile for which you want to enable or disable one or more SOAP methods.
The XML Profile Properties screen opens.
4.
In the Validation Configuration area, the Valid SOAP Methods table lists the SOAP methods used by the WSDL file you uploaded previously. Select or clear the Enabled check box for each method that you want to enable (allow) or disable (not allow).
5.
Below the Defense Configuration area, click the Update button.
The screen refreshes, and displays the XML Profiles screen.
6.
To put the changes into effect immediately, click Apply Policy and confirm.
The system applies the updated security policy.
Some XML applications include an XML schema that describes the structure of the XML content. The XML profile can validate whether the incoming traffic complies with that XML schema.
If the XML schema refers to other XML schemas, you must load the main schema first, then the referenced schema.
If XML schemas refer to each other, you must upload the main schema twice: first as the main schema, and second as the referenced schema.
1.
On the Main tab, expand Application Security, point to Content Profiles, and click the create icon () next to XML Profiles.
The Create New XML Profile screen opens.
3.
In the Profile Name field, type a name for the XML profile.
4.
For the Configuration Files setting, if the application uses an XML schema, perform steps a and b, then continue on to steps 5 and 6. Otherwise, skip to step 7.
a)
For the File option, click Browse and navigate to the .xsd file.
Note: The file you upload must be encoded with UTF-8 character encoding.
b)
Click Upload.
The screen lists the uploaded file.
Important: When an XML schema refers to another XML schema, the system gives you the option of importing it. If circular dependencies exist in the files (for example, schema 1 references schema 2, which contains a reference to back to schema 1) import schema 1, then schema 2, then schema 1 again. This creates a mapping between the files.
5.
If you selected a referenced file type, in the Import URL field, type the URL defined in the schemaLocation directive.
6.
To attempt to locate and use files referenced in the XML schema document, ensure that the Follow Schema Links setting is enabled.
To use this setting, make sure the DNS server is on the DNS lookup server list, and configure the DNS server on the BIG-IP system (System > Configuration > Device > DNS).
Tip: If you disable this setting and the uploaded file refers to other XML schemas, the system lists the referenced files in an error message at the top of the screen.
7.
To permit SOAP messages to contain attachments, enable the Allow Attachments in SOAP Messages setting.
When selected, the Inspect SOAP Attachments setting appears.
To have the system use an ICAP server to inspect attachments for viruses, enable the Inspect SOAP Attachments setting.
Note: For this option to work, you must configure the Application Security Manager to act as an ICAP client (Application Security > Options > Anti-Virus Protection).
9.
To mask sensitive XML data, click Sensitive Data Configuration and then add namespaces. For details on this task, see Masking sensitive XML data.
10.
In the Defense Configuration area, for Defense Level, select High, Medium, or Low.
To customize defense settings, see Fine-tuning XML defense configuration.
11.
Click the Create button.
The system adds the new XML profile to the configuration, and the screen refreshes to display the new profile on the XML Profiles list screen.
12.
To put the changes into effect immediately, click Apply Policy and then click OK to confirm.
The system applies the updated security policy.
You have finished configuring a security policy for a web application with XML content using the default defense configuration settings. If you want to adjust the settings, refer to Fine-tuning XML defense configuration.
You can configure the system to send an XML response page when the security policy blocks a client request that contains XML content that does not comply with the settings of an XML profile configured in the security policy. Refer to Configuring the response to blocked XML requests.
The defense configuration provides formatting and attack pattern checks for the XML data. The defense configuration complements the validation configuration to provide comprehensive security for XML data and web services applications.
In the defense configuration, the defense level determines the granularity of the security inspection for the XML application. You can choose High, Medium, or Low and let the system determine the defense level settings. Or you can set the level, then adjust any of the settings to create a Custom defense level. The defense level settings, described in Table 11.3, specify the valid properties of the actual XML data or the web services application.
A trade-off occurs between ease of configuration and defense level. The higher the defense level, the more you may need to refine the security policy. For example, if you accept the default defense level of High, the XML security is optimal; however, when you initially apply the security policy, the system may generate false-positives for some XML violations.
1.
On the Main tab, expand Application Security, point to Content Profiles, and click XML Profiles.
The XML Profiles screen opens.
2.
In the XML Profiles list, click the name of the XML profile for which you want to modify the advanced defense configuration settings.
The XML Profile Properties screen opens.
3.
Optionally, configure attack signatures, meta characters, or sensitive data for this XML profile on the appropriate tabs.
4.
On the XML Firewall Configuration, from the Defense Configuration list, select Advanced.
The screen displays additional defense configuration settings.
5.
For the Defense Level setting, select the protection level you want for the application.
6.
Adjust the defense configuration settings as required by your application and traffic. For details, see Table 11.3.
7.
Click the Update button.
The system commits any changes you may have made.
8.
To put the changes into effect immediately, click Apply Policy then click OK to confirm.
The system applies the updated security policy.
Table 11.3, describes the defense configuration settings. The Defense Level setting (step 5, in the previous procedure) determines the default values for the settings. A value of 0 in the table indicates unlimited; that is, up to the boundaries of an integer type.
Default Value: High
Default Value: Low
Specifies the level of protection that the system applies to XML documents, applications, and services. If you change any of the default settings, the system automatically changes the defense level to Custom.
Specifies, when enabled, that the XML document can contain Document Type Definitions (DTDs).
Specifies, when enabled, that the XML document is allowed to list external references using operators, such as schemaLocation and SYSTEM.
Specifies, when enabled, that leading white spaces at the beginning of an XML document are acceptable.
Specifies, when enabled, that the close tag format </>, which is used in the XML encoding for Microsoft® Office Outlook® Web Access, is acceptable.
Specifies, when enabled, that the entity and namespace names can start with an integer (0-9). Note that this is a compatibility option for use with Microsoft® Office Outlook® Web Access.
Allow Processing Instructions
Specifies, when enabled, that the system allows processing instructions in the XML request. If you upload a WSDL file that references valid SOAP methods, this setting is inactive.
Specifies, when enabled, that the system permits the existence of character data (CDATA) sections in the XML document part of a request.
Specifies, in bytes, the largest acceptable document size.
Specifies the maximum number of elements that can be in a single document.
Specifies, in bytes, the maximum acceptable length for element and attribute names.
Specifies, in bytes, the maximum acceptable length for attribute values.
Specifies the maximum acceptable number of child elements for each parent element.
Specifies the maximum number of attributes for each element.
Specifies the maximum number of namespace declarations allowed in a single document.
Specifies the largest allowed size for a namespace prefix in the XML part of a request.
The system checks requests that contain XML data to be sure that the data complies with the various document limits defined in the defense configuration of the security policy's XML profile. The system generally examines the message for compliance to boundaries such as the message's size, maximum depth, and maximum number of children. When the system detects a problem in an XML document, it causes the XML data does not comply with format settings violation, if the violation is set to Alarm or Block.
You can have the system perform attack signature checks on XML or JSON profiles. In addition, you can override the security policy settings so that the system checks or avoids checking specific attack signatures for a particular content profile.
1.
On the Main tab, expand Application Security, point to Content Profiles, and click XML Profiles or JSON Profiles.
2.
In the profiles list, click the name of the content profile for which you want to specify attack signature checks.
The profile properties screen opens.
4.
Make sure that the Check attack signatures check box is selected if you want the system to perform attack signature checking for the content profile.
5.
In the Global Security Policy Settings list, review the attack signatures that are assigned to the security policy, and which are enabled and enforced for the content profile.
6.
From the Global Security Policy Settings list, move any attack signatures that you want to override for this content profile into the Overridden Security Policy Settings list.
The attack signature is set to Disabled in the overridden settings list. The system does not issue a violation even when part of the request matches the attack signature.
Tip: In the Overridden Security Policy Settings list, click an attack signature link to display details about the attack signature.
8.
To put the changes into effect immediately, click Apply Policy and then click OK to confirm.
The system applies the updated security policy.
You can override global security policy settings for meta characters in content profiles. For example, if a meta character is allowed in general by the security policy, you can make it disallowed for a particular JSON or XML content profile.
If the system discovers a request with a disallowed meta character in an XML or JSON value, the system learns, logs, or blocks the request, depending on which settings are enabled for the Illegal meta character in value violation on the Blocking Policy screen.
1.
On the Main tab, expand Application Security, point to Content Profiles, and click XML Profiles or JSON Profiles.
2.
In the profiles list, click the name of the content profile for which you want to specify attack signature checks.
The profile properties screen opens.
For JSON profiles, select the Check characters check box to have the system check for meta characters in JSON data.
For XML profiles, select Check element value characters to check meta characters in XML elements, and select Check attribute value characters to check meta characters in XML attributes.
5.
In the Global Security Policy Settings list, review the meta characters that are assigned to the security policy, and which are allowed and disallowed for the content profile.
6.
From the Global Security Policy Settings list, move any meta characters that you want to override for this content profile into the Overridden Security Policy Settings list.
Set the meta character to Allow or Disallow in the overridden settings list (the opposite from the global setting).
7.
Click Update to save your changes to the profile.
8.
To put the changes into effect immediately, click Apply Policy and then click OK to confirm.
The system applies the updated security policy.
You can mask sensitive XML data so that it does not appear in the interface or logs. You set this up in the XML profile of a security policy.
1.
On the Main tab, expand Application Security, point to Content Profiles, and click XML Profiles.
The XML Profiles screen opens.
2.
In the XML Profiles list, click the name of the XML profile for which you want to mask sensitive XML data.
The XML Profile Properties screen opens.
3.
Click Sensitive Data Configuration.
The screen displays Sensitive Data Configuration settings.
4.
For Namespace, select one of the options:
Any Namespace specifies that sensitive data can appear in any namespace prefix.
Custom specifies that the name of the namespace prefix that you type can contain sensitive data.
No Namespace specifies that no default namespace prefix has an element or attribute whose value contains sensitive data.
5.
For Name,
a)
Select Element or Attribute to indicate whether the sensitive data appears as a value of an XML element or an attribute.
b)
In the field, type the XML element or attribute whose value contains the sensitive data. Entries in this field are case-sensitive.
6.
Click Add to add the information you entered in the Namespace and Name fields to the Sensitive Data table and to the XML profile configuration.
7.
Click the Update button.
The system adds the sensitive data information to the XML profile.
8.
To put the changes into effect immediately, click Apply Policy then click OK to confirm.
The system applies the updated security policy.
You can associate XML profiles with explicit URLs and wildcard URLs. When the system receives a request that contains the URL, the system applies the associated XML profile, and generates, if applicable, an XML violation. You can configure the system to verify all requests, or only those requests whose header name and value match a configurable string.
1.
On the Main tab, expand Application Security and click URLs.
The Allowed URLs screen opens.
3.
In the Allowed URLs List area, click the name of the URL to which you want to assign an XML profile.
The Allowed URL Properties screen opens.
4.
From the Allowed URL Properties list, select Advanced.
The screen displays additional options.
5.
In the Header-Based Content Profiles setting, specify how the system should enforce requests for this URL:
a)
In the Request Header Name field, type the explicit header name that must appear in requests for this URL. This field is not case-sensitive.
b)
In the Request Header Value field, type the pattern string for the header value to find in requests for this URL, for example, *xml*, xml_method?, or method[0-9]. This field is case-sensitive.
c)
From the Parsed As list, select XML so the system checks XML data in URL requests that match the header name and value:
d)
For Profile Name, select the XML profile to use when checking XML in requests for this URL, and click Add.
Tip: If you have not created the XML profile, you can click the create button (+) to create one. The system redirects you back to the URL Properties screen when you are done.
6.
Click the Update button.
The screen displays the Allowed URLs screen.
7.
Click the Apply Policy button (in the editing context area) to immediately put those changes into effect.
You can associate an XML profile with a parameter whose value is XML-formatted. When the system receives a request that contains the parameter, the system applies the XML profile to the parameter value, and if applicable, generates one or more XML violations.
1.
On the Main tab, expand Application Security and click Parameters.
The Parameters List screen opens.
3.
In the Parameters List area, click the name of the parameter to which you want to assign an XML profile.
The Parameter Properties screen opens.
4.
In the Edit Parameter area, for the Parameter Value Type, select XML value.
The screen refreshes, and displays XML profile settings.
5.
In the XML Profile area, for the XML Profile setting, specify a profile to use; either:
Note: When you navigate to the Create New XML Profile screen using the create button (+), the system redirects you to the Parameter Properties screen when you finish creating the new XML profile.
6.
Click the Update button to save any changes you may have made.
7.
To put the changes into effect immediately, click Apply Policy then click OK to confirm.
The system applies the updated security policy.
You can easily make any necessary changes to the profile, and then apply the updated security policy so that the changes take effect immediately.
1.
On the Main tab, expand Application Security, point to Content Profiles, and click XML Profiles.
The XML Profiles screen opens.
3.
In the XML Profiles list, in the Profile Name column, click the name of the XML profile that you want to update.
The XML Profile Properties screen opens.
4.
Make any necessary changes to the profile properties, and then click the Update button.
The system saves any changes you may have made.
5.
To put the changes into effect immediately, click Apply Policy then click OK to confirm.
The system applies the updated security policy.
If you no longer need a specific XML profile, you can remove it entirely from the configuration. F5 Networks recommends that before you delete an XML profile, you remove the profile from any URLs or parameters with which the profile is associated.
1.
On the Main tab, expand Application Security, point to Content Profiles, and click XML Profiles.
The XML Profiles screen opens.
3.
In the XML Profiles area, in the Select column (far left), select the box next to the profile that you want to remove, and then click the Delete button.
The system displays a popup confirmation screen.
4.
To put the changes into effect immediately, click Apply Policy then click OK to confirm.
The system applies the updated security policy.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)