**Introducing a new console experience for AWS WAF** You can now use the updated experience to access AWS WAF functionality anywhere in the console. For more details, see [Working with the console](https://docs.aws.amazon.com/waf/latest/developerguide/working-with-console.html). # AWS WAF Fraud Control account creation fraud prevention (ACFP) This section explains what AWS WAF Fraud Control account creation fraud prevention (ACFP) does. Account creation fraud is an online illegal activity in which an attacker tries to create one or more fake accounts. Attackers use fake accounts for fraudulent activities such as abusing promotional and sign up bonuses, impersonating someone, and cyberattacks like phishing. The presence of fake accounts can negatively impact your business by damaging your reputation with customers and exposure to financial fraud. You can monitor and control account creation fraud attempts by implementing the ACFP feature. AWS WAF offers this feature in the AWS Managed Rules rule group `AWSManagedRulesACFPRuleSet` with companion application integration SDKs. The ACFP managed rule group labels and manages requests that might be part of malicious account creation attempts. The rule group does this by inspecting account creation attempts that clients send to your application's account sign-up endpoint. ACFP protects your account sign-up pages by monitoring account sign-up requests for anomalous activity and by automatically blocking suspicious requests. The rule group uses request identifiers, behavioral analysis, and machine learning to detect fraudulent requests. + **Request inspection** – ACFP gives you visibility and control over anomalous account creation attempts and attempts that use stolen credentials, to prevent the creation of fraudulent accounts. ACFP checks email and password combinations against its stolen credential database, which is updated regularly as new leaked credentials are found on the dark web. ACFP evaluates the domains used in email addresses, and monitors the use of phone numbers and address fields to verify the entries and to detects fraudulent behavior. ACFP aggregates data by IP address and client session, to detect and block clients that send too many requests of a suspicious nature. + **Response inspection** – For CloudFront distributions, in addition to inspecting incoming account creation requests, the ACFP rule group inspects your application's responses to account creation attempts, to track success and failure rates. Using this information, ACFP can temporarily block client sessions or IP addresses that have too many failed attempts. AWS WAF performs response inspection asynchronously, so this doesn't increase latency in your web traffic. **Note** You are charged additional fees when you use this managed rule group. For more information, see [AWS WAF Pricing](https://aws.amazon.com/waf/pricing/). **Note** The ACFP feature is not available for Amazon Cognito user pools. **Topics** + [AWS WAF ACFP components](waf-acfp-components.md) + [Using application integration SDKs with ACFP](waf-acfp-with-tokens.md) + [Adding the ACFP managed rule group to your web ACL](waf-acfp-rg-using.md) + [Testing and deploying ACFP](waf-acfp-deploying.md) + [AWS WAF Fraud Control account creation fraud prevention (ACFP) examples](waf-acfp-control-examples.md) # AWS WAF ACFP components The primary components of AWS WAF Fraud Control account creation fraud prevention (ACFP) are the following: + **`AWSManagedRulesACFPRuleSet`** – The rules in this AWS Managed Rules rule group detect, label, and handle various types of fraudulent account creation activity. The rule group inspects HTTP `GET` text/html requests that clients send to the specified account registration endpoint and `POST` web requests that clients send to the specified account sign-up endpoint. For protected CloudFront distributions, the rule group also inspects the responses that the distribution sends back to account creation requests. For a list of this rule group's rules, see [AWS WAF Fraud Control account creation fraud prevention (ACFP) rule group](aws-managed-rule-groups-acfp.md). You include this rule group in your protection pack (web ACL) using a managed rule group reference statement. For information about using this rule group, see [Adding the ACFP managed rule group to your web ACL](waf-acfp-rg-using.md). **Note** You are charged additional fees when you use this managed rule group. For more information, see [AWS WAF Pricing](https://aws.amazon.com/waf/pricing/). + **Details about your application's account registration and creation pages** – You must provide information about your account registration and creation pages when you add the `AWSManagedRulesACFPRuleSet` rule group to your protection pack (web ACL). This lets the rule group narrow the scope of the requests it inspects and properly validate account creation web requests. The registration page must accept `GET` text/html requests. The account creation path must accept `POST` requests. The ACFP rule group works with usernames that are in email format. For more information, see [Adding the ACFP managed rule group to your web ACL](waf-acfp-rg-using.md). + **For protected CloudFront distributions, details about how your application responds to account creation attempts** – You provide details about your application's responses to account creation attempts, and the ACFP rule group tracks and manages bulk account creation attempts from a single IP address or single client session. For information about configuring this option, see [Adding the ACFP managed rule group to your web ACL](waf-acfp-rg-using.md). + **JavaScript and mobile application integration SDKs** – Implement the AWS WAF JavaScript and mobile SDKs with your ACFP implementation to enable the full set of capabilities that the rule group offers. Many of the ACFP rules use the information provided by the SDKs for session level client verification and behavior aggregation, required to separate legitimate client traffic from bot traffic. For more information about the SDKs, see [Client application integrations in AWS WAF](waf-application-integration.md). You can combine your ACFP implementation with the following to help you monitor, tune, and customize your protections. + **Logging and metrics** – You can monitor your traffic, and understand how the ACFP managed rule group affects it, by configuring and enabling logs, Amazon Security Lake data collection, and Amazon CloudWatch metrics for your protection pack (web ACL). The labels that `AWSManagedRulesACFPRuleSet` adds to your web requests are included in the data. For information about the options, see [Logging AWS WAF protection pack (web ACL) traffic](logging.md), [Monitoring with Amazon CloudWatch](monitoring-cloudwatch.md), and [What is Amazon Security Lake?](https://docs.aws.amazon.com/security-lake/latest/userguide/what-is-security-lake.html). Depending on your needs and the traffic that you see, you might want to customize your `AWSManagedRulesACFPRuleSet` implementation. For example, you might want to exclude some traffic from ACFP evaluation, or you might want to alter how it handles some of the account creation fraud attempts that it identifies, using AWS WAF features like scope-down statements or label matching rules. + **Labels and label matching rules** – For any of the rules in `AWSManagedRulesACFPRuleSet`, you can switch the blocking behavior to count, and then match against the labels that are added by the rules. Use this approach to customize how you handle web requests that are identified by the ACFP managed rule group. For more information about labeling and using label match statements, see [Label match rule statement](waf-rule-statement-type-label-match.md) and [Web request labeling in AWS WAF](waf-labels.md). + **Custom requests and responses** – You can add custom headers to the requests that you allow and you can send custom responses for requests that you block. To do this, you pair your label matching with the AWS WAF custom request and response features. For more information about customizing requests and responses, see [Customized web requests and responses in AWS WAF](waf-custom-request-response.md). # Using application integration SDKs with ACFP We highly recommend implementing the application integration SDKs, for the most efficient use of the ACFP rule group. + **Complete rule group functionality** – The ACFP rule `SignalClientHumanInteractivityAbsentLow` only works with tokens that are populated by the application integrations. This rule detects and manages abnormal human interactivity with the application page. The application integration SDKs can detect normal human interactivity through mouse movements, key presses, and other measurements. The interstitials that are sent by the rule actions CAPTCHA and Challenge can't provide this type of data. + **Reduced latency** – The rule group rule `AllRequests` applies the Challenge rule action to any request that doesn't already have a challenge token. When this happens, the request is evaluated by the rule group twice: once without the token, and then a second time after the token is acquired by means of the Challenge action interstitial. You aren't charged any added fees for only using the `AllRequests` rule, but this approach adds overhead to your web traffic and adds latency to your end user experience. If you acquire the token client-side using the application integrations, before sending the account creation request, the ACFP rule group evaluates the request once. For more information about the rule group capabilities see [AWS WAF Fraud Control account creation fraud prevention (ACFP) rule group](aws-managed-rule-groups-acfp.md). For information about the SDKs, see [Client application integrations in AWS WAF](waf-application-integration.md). For information about AWS WAF tokens, see [Token use in AWS WAF intelligent threat mitigation](waf-tokens.md). For information about the rule actions, see [CAPTCHA and Challenge in AWS WAF](waf-captcha-and-challenge.md). # Adding the ACFP managed rule group to your web ACL This section explains how to add and configure the `AWSManagedRulesACFPRuleSet` rule group. To configure the ACFP managed rule group to recognize account creation fraud activities in your web traffic, you provide information about how clients access your registration page and send account creation requests to your application. For protected Amazon CloudFront distributions, you also provide information about how your application responds to account creation requests. This configuration is in addition to the normal configuration for a managed rule group. For the rule group description and rules listing, see [AWS WAF Fraud Control account creation fraud prevention (ACFP) rule group](aws-managed-rule-groups-acfp.md). **Note** The ACFP stolen credentials database only contains usernames in email format. This guidance is intended for users who know generally how to create and manage AWS WAF protection packs (web ACLs), rules, and rule groups. Those topics are covered in prior sections of this guide. For basic information about how to add a managed rule group to your protection pack (web ACL), see [Adding a managed rule group to a protection pack (web ACL) through the console](waf-using-managed-rule-group.md). **Follow best practices** Use the ACFP rule group in accordance with the best practices at [Best practices for intelligent threat mitigation in AWS WAF](waf-managed-protections-best-practices.md). **To use the `AWSManagedRulesACFPRuleSet` rule group in your protection pack (web ACL)** 1. Add the AWS managed rule group, `AWSManagedRulesACFPRuleSet` to your protection pack (web ACL), and **Edit** the rule group settings before saving. **Note** You are charged additional fees when you use this managed rule group. For more information, see [AWS WAF Pricing](https://aws.amazon.com/waf/pricing/). 1. In the **Rule group configuration** pane, provide the information that the ACFP rule group uses to inspect account creation requests. 1. For **Use regular expression in paths**, toggle this on if you want AWS WAF to perform regular expression matching for your registration and account creation page path specifications. AWS WAF supports the pattern syntax used by the PCRE library `libpcre` with some exceptions. The library is documented at [PCRE - Perl Compatible Regular Expressions](http://www.pcre.org/). For information about AWS WAF support, see [Supported regular expression syntax in AWS WAF](waf-regex-pattern-support.md). 1. For **Registration page path**, provide the path of the registration page endpoint for your application. This page must accept `GET` text/html requests. The rule group inspects only HTTP `GET` text/html requests to your specified registration page endpoint. **Note** Matching for endpoints is case insensitive. Regex specifications must not contain the flag `(?-i)`, which disables case insensitive matching. String specifications must start with a forward slash `/`. For example, for the URL `https://example.com/web/registration`, you could provide the string path specification `/web/registration`. Registration page paths that start with the path that you provide are considered a match. For example `/web/registration` matches the registration paths `/web/registration`, `/web/registration/`, `/web/registrationPage`, and `/web/registration/thisPage`, but doesn't match the path `/home/web/registration` or `/website/registration`. **Note** Ensure that your end users load the registration page before they submit an account creation request. This helps ensure that the account creation requests from the client include valid tokens. 1. For **Account creation path**, provide the URI in your website that accepts completed new user details. This URI must accept `POST` requests. **Note** Matching for endpoints is case insensitive. Regex specifications must not contain the flag `(?-i)`, which disables case insensitive matching. String specifications must start with a forward slash `/`. For example, for the URL `https://example.com/web/newaccount`, you could provide the string path specification `/web/newaccount`. Account creation paths that start with the path that you provide are considered a match. For example `/web/newaccount` matches the account creation paths `/web/newaccount`, `/web/newaccount/`, `/web/newaccountPage`, and `/web/newaccount/thisPage`, but doesn't match the path `/home/web/newaccount` or `/website/newaccount`. 1. For **Request inspection**, specify how your application accepts account creation attempts by providing the request payload type and the names of the fields within the request body where the username, password, and other account creation details are provided. **Note** For the primary address and phone number fields, provide the fields in the order in which they appear in the request payload. Your specification of the field names depends on the payload type. + **JSON payload type** – Specify the field names in JSON pointer syntax. For information about the JSON Pointer syntax, see the Internet Engineering Task Force (IETF) documentation [JavaScript Object Notation (JSON) Pointer](https://tools.ietf.org/html/rfc6901). For example, for the following example JSON payload, the username field specification is `/signupform/username` and the primary address field specifications are `/signupform/addrp1`, `/signupform/addrp2`, and `/signupform/addrp3`. ``` { "signupform": { "username": "THE_USERNAME", "password": "THE_PASSWORD", "addrp1": "PRIMARY_ADDRESS_LINE_1", "addrp2": "PRIMARY_ADDRESS_LINE_2", "addrp3": "PRIMARY_ADDRESS_LINE_3", "phonepcode": "PRIMARY_PHONE_CODE", "phonepnumber": "PRIMARY_PHONE_NUMBER" } } ``` + **FORM\$1ENCODED payload type** – Use the HTML form names. For example, for an HTML form with user and password input elements named `username1` and `password1`, the username field specification is `username1` and the password field specification is `password1`. 1. If you're protecting Amazon CloudFront distributions, then under **Response inspection**, specify how your application indicates success or failure in its responses to account creation attempts. **Note** ACFP response inspection is available only in protection packs (web ACLs) that protect CloudFront distributions. Specify a single component in the account creation response that you want ACFP to inspect. For the **Body** and **JSON** component types, AWS WAF can inspect the first 65,536 bytes (64 KB) of the component. Provide your inspection criteria for the component type, as indicated by the interface. You must provide both success and failure criteria to inspect for in the component. For example, say your application indicates the status of an account creation attempt in the status code of the response, and uses `200 OK` for success and `401 Unauthorized` or `403 Forbidden` for failure. You would set the response inspection **Component type** to **Status code**, then in the **Success** text box enter `200` and in the **Failure** text box, enter `401` on the first line and `403` on the second. The ACFP rule group only counts responses that match your success or failure inspection criteria. The rule group rules act on clients while they have too high a success rate among the responses that are counted, in order to mitigate bulk account creation attempts. For accurate behavior by the rule group rules, be sure to provide complete information for both successful and failed account creation attempts. To see the rules that inspect account creation responses, look for `VolumetricIPSuccessfulResponse` and `VolumetricSessionSuccessfulResponse` in the rules listing at [AWS WAF Fraud Control account creation fraud prevention (ACFP) rule group](aws-managed-rule-groups-acfp.md). 1. Provide any additional configuration that you want for the rule group. You can further limit the scope of requests that the rule group inspects by adding a scope-down statement to the managed rule group statement. For example, you can inspect only requests with a specific query argument or cookie. The rule group will only inspect requests that match the criteria in your scope-down statement and that are sent to the account registration and account creation paths that you specified in the rule group configuration. For information about scope-down statements, see [Using scope-down statements in AWS WAF](waf-rule-scope-down-statements.md). 1. Save your changes to the protection pack (web ACL). Before you deploy your ACFP implementation for production traffic, test and tune it in a staging or testing environment until you are comfortable with the potential impact to your traffic. Then test and tune the rules in count mode with your production traffic before enabling them. See the section that follows for guidance. # Testing and deploying ACFP This section provides general guidance for configuring and testing an AWS WAF Fraud Control account creation fraud prevention (ACFP) implementation for your site. The specific steps that you choose to follow will depend on your needs, resources, and web requests that you receive. This information is in addition to the general information about testing and tuning provided at [Testing and tuning your AWS WAF protections](web-acl-testing.md). **Note** AWS Managed Rules are designed to protect you from common web threats. When used in accordance with the documentation, AWS Managed Rules rule groups add another layer of security for your applications. However, AWS Managed Rules rule groups aren't intended as a replacement for your security responsibilities, which are determined by the AWS resources that you select. Refer to the [Shared Responsibility Model](https://aws.amazon.com/compliance/shared-responsibility-model/) to ensure that your resources in AWS are properly protected. **Production traffic risk** Before you deploy your ACFP implementation for production traffic, test and tune it in a staging or testing environment until you are comfortable with the potential impact to your traffic. Then test and tune the rules in count mode with your production traffic before enabling them. AWS WAF provides test credentials that you can use to verify your ACFP configuration. In the following procedure, you'll configure a test protection pack (web ACL) to use the ACFP managed rule group, configure a rule to capture the label added by the rule group, and then run an account creation attempt using these test credentials. You'll verify that your protection pack (web ACL) has properly managed the attempt by checking the Amazon CloudWatch metrics for the account creation attempt. This guidance is intended for users who know generally how to create and manage AWS WAF protection packs (web ACLs), rules, and rule groups. Those topics are covered in prior sections of this guide. **To configure and test an AWS WAF Fraud Control account creation fraud prevention (ACFP) implementation** Perform these steps first in a test environment, then in production. 1. **Add the AWS WAF Fraud Control account creation fraud prevention (ACFP) managed rule group in count mode** **Note** You are charged additional fees when you use this managed rule group. For more information, see [AWS WAF Pricing](https://aws.amazon.com/waf/pricing/). Add the AWS Managed Rules rule group `AWSManagedRulesACFPRuleSet` to a new or existing protection pack (web ACL) and configure it so that it doesn't alter the current protection pack (web ACL) behavior. For details about the rules and labels for this rule group, see [AWS WAF Fraud Control account creation fraud prevention (ACFP) rule group](aws-managed-rule-groups-acfp.md). + When you add the managed rule group, edit it and do the following: + In the **Rule group configuration** pane, provide the details of your application's account registration and creation pages. The ACFP rule group uses this information to monitor sign-in activities. For more information, see [Adding the ACFP managed rule group to your web ACL](waf-acfp-rg-using.md). + In the **Rules** pane, open the **Override all rule actions** dropdown and choose **Count**. With this configuration, AWS WAF evaluates requests against all of the rules in the rule group and only counts the matches that result, while still adding labels to requests. For more information, see [Overriding rule actions in a rule group](web-acl-rule-group-settings.md#web-acl-rule-group-rule-action-override). With this override, you can monitor the potential impact of the ACFP managed rules to determine whether you want to add exceptions, such as exceptions for internal use cases. + Position the rule group so that it's evaluated after your existing rules in the protection pack (web ACL), with a priority setting that's numerically higher than any rules or rule groups that you're already using. For more information, see [Setting rule priority](web-acl-processing-order.md). This way, your current handling of traffic isn't disrupted. For example, if you have rules that detect malicious traffic such as SQL injection or cross-site scripting, they'll continue to detect and log that. Alternately, if you have rules that allow known non-malicious traffic, they can continue to allow that traffic, without having it blocked by the ACFP managed rule group. You might decide to adjust the processing order during your testing and tuning activities. 1. **Implement the application integration SDKs** Integrate the AWS WAF JavaScript SDK into your browser's account registration and account creation paths. AWS WAF also provides mobile SDKs to integrate iOS and Android devices. For more information about the integration SDKs, see [Client application integrations in AWS WAF](waf-application-integration.md). For information about this recommendation, see [Using application integration SDKs with ACFP](waf-acfp-with-tokens.md). **Note** If you are unable to use the application integration SDKs, it's possible to test the ACFP rule group by editing it in your protection pack (web ACL) and removing the override that you placed on the `AllRequests` rule. This enables the rule's Challenge action setting, to ensure that requests include a valid challenge token. *Do this first in a test environment and then with great care in your production environment.* This approach has the potential to block users. For example, if your registration page path doesn't accept `GET` text/html requests, then this rule configuration can effectively block all requests at the registration page. 1. **Enable logging and metrics for the protection pack (web ACL)** As needed, configure logging, Amazon Security Lake data collection, request sampling, and Amazon CloudWatch metrics for the protection pack (web ACL). You can use these visibility tools to monitor the interaction of the ACFP managed rule group with your traffic. + For information about logging, see [Logging AWS WAF protection pack (web ACL) traffic](logging.md). + For information about Amazon Security Lake, see [What is Amazon Security Lake?](https://docs.aws.amazon.com/security-lake/latest/userguide/what-is-security-lake.html) and [Collecting data from AWS services](https://docs.aws.amazon.com/security-lake/latest/userguide/internal-sources.html) in the *Amazon Security Lake user guide*. + For information about Amazon CloudWatch metrics, see [Monitoring with Amazon CloudWatch](monitoring-cloudwatch.md). + For information about web request sampling, see [Viewing a sample of web requests](web-acl-testing-view-sample.md). 1. **Associate the protection pack (web ACL) with a resource** If the protection pack (web ACL) isn't already associated with a test resource, associate it. For information, see [Associating or disassociating protection with an AWS resource](web-acl-associating-aws-resource.md). 1. **Monitor traffic and ACFP rule matches** Make sure that your normal traffic is flowing and that the ACFP managed rule group rules are adding labels to matching web requests. You can see the labels in the logs and see the ACFP and label metrics in the Amazon CloudWatch metrics. In the logs, the rules that you've overridden to count in the rule group show up in the `ruleGroupList` with `action` set to count, and with `overriddenAction` indicating the configured rule action that you overrode. 1. **Test the rule group's credential checking capabilities** Perform an account creation attempt with test compromised credentials and check that the rule group matches against them as expected. 1. Access your protected resource's account registration page and try to add a new account. Use the following AWS WAF test credential pair and enter any test + User: `WAF_TEST_CREDENTIAL@wafexample.com` + Password: `WAF_TEST_CREDENTIAL_PASSWORD` These test credentials are categorized as compromised credentials, and the ACFP managed rule group will add the `awswaf:managed:aws:acfp:signal:credential_compromised` label to the account creation request, which you can see in the logs. 1. In your protection pack (web ACL) logs, look for the `awswaf:managed:aws:acfp:signal:credential_compromised` label in the `labels` field on the log entries for your test account creation request. For information about logging, see [Logging AWS WAF protection pack (web ACL) traffic](logging.md). After you've verified that the rule group captures compromised credentials as expected, you can take steps to configure its implementation as you need for your protected resource. 1. **For CloudFront distributions, test the rule group's management of bulk account creation attempts** Run this test for each success response criteria that you configured for the ACFP rule group. Wait at least 30 minutes between tests. 1. For each of your success criteria, identify an account creation attempt that will succeed with that success criteria in the response. Then, from a single client session, perform at least 5 successful account creation attempts in under 30 minutes. A user would normally only create a single account on your site. After the first successful account creation, the `VolumetricSessionSuccessfulResponse` rule should start matching against the rest of your account creation responses, labeling them and counting them, based on your rule action override. The rule might miss the first one or two due to latency. 1. In your protection pack (web ACL) logs, look for the `awswaf:managed:aws:acfp:aggregate:volumetric:session:successful_creation_response:high` label in the `labels` field on the log entries for your test account creation web requests. For information about logging, see [Logging AWS WAF protection pack (web ACL) traffic](logging.md). These tests verify that your success criteria match your responses by checking that the successful counts aggregated by the rule surpass the rule's threshold. After you've reached the threshold, if you continue to send account creation requests from the same session, the rule will continue to match until the success rate drops below the threshold. While the threshold is exceeded, the rule matches both successful or failed account creation attempts from the session address. 1. **Customize ACFP web request handling** As needed, add your own rules that explicitly allow or block requests, to change how ACFP rules would otherwise handle them. For example, you can use ACFP labels to allow or block requests or to customize request handling. You can add a label match rule after the ACFP managed rule group to filter labeled requests for the handling that you want to apply. After testing, keep the related ACFP rules in count mode, and maintain the request handling decisions in your custom rule. For an example, see [ACFP example: Custom response for compromised credentials](waf-acfp-control-example-compromised-credentials.md). 1. **Remove your test rules and enable the ACFP managed rule group settings** Depending on your situation, you might have decided that you want to leave some ACFP rules in count mode. For the rules that you want to run as configured inside the rule group, disable count mode in the protection pack (web ACL) rule group configuration. When you're finished testing, you can also remove your test label match rules. 1. **Monitor and tune** To be sure that web requests are being handled as you want, closely monitor your traffic after you enable the ACFP functionality that you intend to use. Adjust the behavior as needed with the rules count override on the rule group and with your own rules. After you finish testing your ACFP rule group implementation, if you haven't already integrated the AWS WAF JavaScript SDK into your browser's account registration and account creation pages, we strongly recommend that you do so. AWS WAF also provides mobile SDKs to integrate iOS and Android devices. For more information about the integration SDKs, see [Client application integrations in AWS WAF](waf-application-integration.md). For information about this recommendation, see [Using application integration SDKs with ACFP](waf-acfp-with-tokens.md). # AWS WAF Fraud Control account creation fraud prevention (ACFP) examples This section shows example configurations that satisfy common use cases for the AWS WAF Fraud Control account creation fraud prevention (ACFP) implementations. Each example provides a description of the use case and then shows the solution in JSON listings for the custom configured rules. **Note** You can retrieve JSON listings like the ones shown in these examples through the console protection pack (web ACL) JSON download or rule JSON editor, or through the `getWebACL` operation in the APIs and the command line interface. **Topics** + [ACFP example: Simple configuration](waf-acfp-control-example-basic.md) + [ACFP example: Custom response for compromised credentials](waf-acfp-control-example-compromised-credentials.md) + [ACFP example: Response inspection configuration](waf-acfp-control-example-response-inspection.md) # ACFP example: Simple configuration The following JSON listing shows an example protection pack (web ACL) with an AWS WAF Fraud Control account creation fraud prevention (ACFP) managed rule group. Note the additional `CreationPath` and `RegistrationPagePath` configurations, along with the payload type and the information needed to locate new account information in the payload, in order to verify it. The rule group uses this information to monitor and manage your account creation requests. This JSON includes the protection pack (web ACL)'s automatically generated settings, like the label namespace and the protection pack (web ACL)'s application integration URL. ``` { "Name": "simpleACFP", "Id": "... ", "ARN": "arn:aws:wafv2:us-east-1:111122223333:regional/webacl/simpleACFP/... ", "DefaultAction": { "Allow": {} }, "Description": "", "Rules": [ { "Name": "AWS-AWSManagedRulesACFPRuleSet", "Priority": 0, "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesACFPRuleSet", "ManagedRuleGroupConfigs": [ { "AWSManagedRulesACFPRuleSet": { "CreationPath": "/web/signup/submit-registration", "RegistrationPagePath": "/web/signup/registration", "RequestInspection": { "PayloadType": "JSON", "UsernameField": { "Identifier": "/form/username" }, "PasswordField": { "Identifier": "/form/password" }, "EmailField": { "Identifier": "/form/email" }, "PhoneNumberFields": [ { "Identifier": "/form/country-code" }, { "Identifier": "/form/region-code" }, { "Identifier": "/form/phonenumber" } ], "AddressFields": [ { "Identifier": "/form/name" }, { "Identifier": "/form/street-address" }, { "Identifier": "/form/city" }, { "Identifier": "/form/state" }, { "Identifier": "/form/zipcode" } ] }, "EnableRegexInPath": false } } ] } }, "OverrideAction": { "None": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "AWS-AWSManagedRulesACFPRuleSet" } } ], "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "simpleACFP" }, "Capacity": 50, "ManagedByFirewallManager": false, "RetrofittedByFirewallManager": false, "LabelNamespace": "awswaf:111122223333:webacl:simpleACFP:" } ``` # ACFP example: Custom response for compromised credentials By default, the credentials check that's performed by the rule group `AWSManagedRulesACFPRuleSet` handles compromised credentials by labeling the request and blocking it. For details about the rule group and rule behavior, see [AWS WAF Fraud Control account creation fraud prevention (ACFP) rule group](aws-managed-rule-groups-acfp.md). To inform the user that the account credentials they've provided have been compromised, you can do the following: + **Override the `SignalCredentialCompromised` rule to Count** – This causes the rule to only count and label matching requests. + **Add a label match rule with custom handling** – Configure this rule to match against the ACFP label and to perform your custom handling. The following protection pack (web ACL) listings shows the ACFP managed rule group from the prior example, with the `SignalCredentialCompromised` rule action overridden to count. With this configuration, when this rule group evaluates any web request that uses compromised credentials, it will label the request, but not block it. In addition, the protection pack (web ACL) now has a custom response named `aws-waf-credential-compromised` and a new rule named `AccountSignupCompromisedCredentialsHandling`. The rule priority is a higher numeric setting than the rule group, so it runs after the rule group in the protection pack (web ACL) evaluation. The new rule matches any request with the rule group's compromised credentials label. When the rule finds a match, it applies the Block action to the request with the custom response body. The custom response body provides information to the end user that their credentials have been compromised and proposes an action to take. ``` { "Name": "compromisedCreds", "Id": "... ", "ARN": "arn:aws:wafv2:us-east-1:111122223333:regional/webacl/compromisedCreds/...", "DefaultAction": { "Allow": {} }, "Description": "", "Rules": [ { "Name": "AWS-AWSManagedRulesACFPRuleSet", "Priority": 0, "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesACFPRuleSet", "ManagedRuleGroupConfigs": [ { "AWSManagedRulesACFPRuleSet": { "CreationPath": "/web/signup/submit-registration", "RegistrationPagePath": "/web/signup/registration", "RequestInspection": { "PayloadType": "JSON", "UsernameField": { "Identifier": "/form/username" }, "PasswordField": { "Identifier": "/form/password" }, "EmailField": { "Identifier": "/form/email" }, "PhoneNumberFields": [ { "Identifier": "/form/country-code" }, { "Identifier": "/form/region-code" }, { "Identifier": "/form/phonenumber" } ], "AddressFields": [ { "Identifier": "/form/name" }, { "Identifier": "/form/street-address" }, { "Identifier": "/form/city" }, { "Identifier": "/form/state" }, { "Identifier": "/form/zipcode" } ] }, "EnableRegexInPath": false } } ], "RuleActionOverrides": [ { "Name": "SignalCredentialCompromised", "ActionToUse": { "Count": {} } } ] } }, "OverrideAction": { "None": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "AWS-AWSManagedRulesACFPRuleSet" } }, { "Name": "AccountSignupCompromisedCredentialsHandling", "Priority": 1, "Statement": { "LabelMatchStatement": { "Scope": "LABEL", "Key": "awswaf:managed:aws:acfp:signal:credential_compromised" } }, "Action": { "Block": { "CustomResponse": { "ResponseCode": 406, "CustomResponseBodyKey": "aws-waf-credential-compromised", "ResponseHeaders": [ { "Name": "aws-waf-credential-compromised", "Value": "true" } ] } } }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "AccountSignupCompromisedCredentialsHandling" } } ], "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "compromisedCreds" }, "Capacity": 51, "ManagedByFirewallManager": false, "RetrofittedByFirewallManager": false, "LabelNamespace": "awswaf:111122223333:webacl:compromisedCreds:", "CustomResponseBodies": { "aws-waf-credential-compromised": { "ContentType": "APPLICATION_JSON", "Content": "{\n \"credentials-compromised\": \"The credentials you provided have been found in a compromised credentials database.\\n\\nTry again with a different username, password pair.\"\n}" } } } ``` # ACFP example: Response inspection configuration The following JSON listing shows an example protection pack (web ACL) with an AWS WAF Fraud Control account creation fraud prevention (ACFP) managed rule group that is configured to inspect origin responses. Note the response inspection configuration, which specifies success and response status codes. You can also configure success and response settings based on header, body, and body JSON matches. This JSON includes the protection pack (web ACL)'s automatically generated settings, like the label namespace and the protection pack (web ACL)'s application integration URL. **Note** ATP response inspection is available only in protection packs (web ACLs) that protect CloudFront distributions. ``` { "Name": "simpleACFP", "Id": "... ", "ARN": "arn:aws:wafv2:us-east-1:111122223333:regional/webacl/simpleACFP/... ", "DefaultAction": { "Allow": {} }, "Description": "", "Rules": [ { "Name": "AWS-AWSManagedRulesACFPRuleSet", "Priority": 0, "Statement": { "ManagedRuleGroupStatement": { "VendorName": "AWS", "Name": "AWSManagedRulesACFPRuleSet", "ManagedRuleGroupConfigs": [ { "AWSManagedRulesACFPRuleSet": { "CreationPath": "/web/signup/submit-registration", "RegistrationPagePath": "/web/signup/registration", "RequestInspection": { "PayloadType": "JSON", "UsernameField": { "Identifier": "/form/username" }, "PasswordField": { "Identifier": "/form/password" }, "EmailField": { "Identifier": "/form/email" }, "PhoneNumberFields": [ { "Identifier": "/form/country-code" }, { "Identifier": "/form/region-code" }, { "Identifier": "/form/phonenumber" } ], "AddressFields": [ { "Identifier": "/form/name" }, { "Identifier": "/form/street-address" }, { "Identifier": "/form/city" }, { "Identifier": "/form/state" }, { "Identifier": "/form/zipcode" } ] }, "ResponseInspection": { "StatusCode": { "SuccessCodes": [ 200 ], "FailureCodes": [ 401 ] } }, "EnableRegexInPath": false } } ] } }, "OverrideAction": { "None": {} }, "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "AWS-AWSManagedRulesACFPRuleSet" } } ], "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "simpleACFP" }, "Capacity": 50, "ManagedByFirewallManager": false, "RetrofittedByFirewallManager": false, "LabelNamespace": "awswaf:111122223333:webacl:simpleACFP:" } ```