Blocking Response Pages¶
Overview¶
The Application Security Manager has a default blocking response page that it returns to the client when the client request, or the web server response, is blocked by the security policy. The system also has a login response page for login violations. You can change the way the system responds to blocked logins or blocked requests.
The system issues response pages only when the enforcement mode is set to Blocking. A security policy can respond to blocked requests in these ways:
Option | Response to Blocked Request |
---|---|
Default Response | The response returns the system-supplied response page in HTML. |
Custom Response | The response returns a response page with HTML code that you define. |
Redirect URL | The response redirects the user to a specified web page. |
The system uses default pages in response to a blocked request or blocked login. If the default pages are acceptable, you do not need to change them and they work automatically. However, if you want to customize the response or include AJAX formatting in the blocking responses, you need to enable the blocking behavior first.
All default response pages contain a variable <%TS.request.ID()%>
that WAF replaces with a support ID number when it issues the page. Customers can use the support ID to identify the request when making inquiries.
Adding AJAX blocking and login response behavior¶
Normal policy blocking and login response behavior could interfere with applications that use AJAX. If you want to display a message or redirect traffic without interfering with the user experience while browsing to an AJAX-featured web application, you need to enable AJAX blocking behavior (JavaScript injection). You can implement blocking and login response behavior for applications that use AJAX with JSON or XML for data transfer.
You can implement AJAX blocking behavior only for applications developed using one of the following frameworks:
Microsoft ASP.NET
jQuery
Prototype
MooTools
By default, if you enable AJAX blocking behavior, when an AJAX request results in a violation that is set to Block, WAF performs the default AJAX response page action. The system presents a login response if the application user sends an AJAX request that attempts to directly access a URL that should only be accessed after logging in.
Prerequisites¶
Verify any attached application services to ensure proper security after changes are deployed.
You need to have a user role of Security Manager or Administrator to manage a WAF policy.
WAF policy enforcement mode is set to Blocking. Although this is not required, the responses will not be returned to a violation unless the setting is set to Blocking.
How to configure blocking response pages¶
Configure custom responses to blocked requests¶
Configure the blocking web response that is sent to the user when the security policy blocks a client request.
Click the workspace icon next to the F5 icon, and click Security.
Select the name of the policy.
From the panel menu, click Response Pages.
The panel displays the Blocking Page response message body. If you have not yet changed the defaults, the blocking page is a Web Response type with the following body:The requested URL was rejected. Please consult with your administrator. <br><br>Your support ID is: <%TS.request.ID()%><br><br> <a href='javascript:history.back();'>[Go Back]</a></body></html>```
For Response Type select Web Response.
Note: Web Response is the default option.
To create a custom response modify the default text:
For the Response Body type or paste the text you want to send to a client in response to an illegal blocked request. Use standard HTTP syntax.
Click Preview to the far right of the editor to view the user response.
Click Response Header to customize the default header.
Click Save.
If you have completed your changes to the policy, click Deploy to update associated BIG-IP Next instance(s).
To confirm the deployment, click Deploy.
The updated web response is added to the policy’s blocking response page.
Add custom redirect URLs from blocked requests¶
Direct the user to a specified URL. The URL should be for a page that is not within the web application itself. In addition, it is recommended to add a URL with a support ID, to ensure that a valid, blocked user can request support.
Click the workspace icon next to the F5 icon, and click Security.
Select the name of the policy.
From the panel menu, click Response Pages.
By default, the panel displays the Blocking Page response message body.
For Response Type select Redirect URL.
In the Redirect URL field, type the URL to which the system redirects the user, for example,
http://www.myredirectpage.com
.To redirect the blocking page to a URL with a support ID in the query string, type the URL and the support ID in the following format:
http://www.myredirectpage.com/block_pg.php?support_id= <%TS.request.ID()%>
The WAF policy replaces<%TS.request.ID%>
with the relevant support ID so that the blocked request is redirected to the URL with the relevant support ID.Click Save.
If you have completed your changes to the policy, click Deploy to update associated BIG-IP Next instance(s).
To confirm the deployment, click Deploy.
The updated web response is added to the policy’s blocking response page. Blocked users are redirected to the provided URL.
Restore default response pages¶
For the response web page, you can restore the default settings.
Click the workspace icon next to the F5 icon, and click Security.
Select the name of the policy.
From the panel menu, click Response Pages.
By default, the panel displays the Blocking Page response message body.
Select either the Blocking Page or AJAX Blocking Page tab.
If you selected the Blocking Page: From the top left of the editor, for either Response Body or Response Header, click Restore Default.
If you select AJAX Blocking Page: From the top left of the editor, for either Popup Message or Custom Response types, click Restore Default.
Confirm the restore settings.
Click Save.
If you have completed your changes to the policy, click Deploy to update associated BIG-IP Next instance(s).
To confirm the deployment, click Deploy.
The response is restored to WAF policy default settings.
Configure AJAX blocking page¶
Normal policy blocking and login response behavior could interfere with applications that use AJAX. If you want to display a message or redirect traffic without interfering with the user experience while browsing to an AJAX-featured web application, you need to enable AJAX blocking behavior (JavaScript injection). You can implement blocking and login response behavior for applications that use AJAX with JSON or XML for data transfer.
When the enforcement mode of the security policy is set to blocking and a request triggers a violation (that is set to block), the system displays the AJAX blocking response according to the action set that you define. If a login violation occurs when requesting the login URL, the policy sends a login response page, or redirects the user.
Click the workspace icon next to the F5 icon, and click Security.
Select the name of the policy.
From the panel menu, click Response Pages.
By default, the panel displays the Blocking Page response message body.
Select the AJAX Blocking Page tab.
Note: By default the response type is disabled.
Ensure the Blocking Page is Enabled.
Select a Response Type:
Popup message displays text in a popup window (default text is included). Click Preview to view the response.
Custom Response lets you specify HTML text to use as a replacement for the frame or browser page that generated the AJAX request. Include the text, then click Preview to view the response.
Redirect URL redirects the user to the URL you specify.
Add the Redirect URL. You can also include the support ID. For example:
http://www.example.com/blocking_page.php?support_id=<%TS.request.ID()%>
.
Click Save.
If you have completed your changes to the policy, click Deploy to update associated BIG-IP Next instance(s).
To confirm the deployment, click Deploy.
Resources¶
Response page management using the policy Editor¶
Edit the WAF policy JSON declaration directly through the WAF policy editor.