Your approach should be two-fold:
- Various escape sequences (e.g. \x00, %s, \\, etc.)
- Unicode tricks (e.g. multi-byte characters that end in 0x22 to produce a ")
- Alternative XSS methods (e.g.
<img src=0 onerror=alert(1) /> instead of
- Various nasties (e.g. XSS, SQL injection) inside of cookies and HTTP headers - often WAFs miss these!
Ensure that the client understands that a WAF is just a sticking plaster, and cannot fix a broken limb. If the application is broken in an exploitable way, a WAF may prevent the attack or mitigate some of the impact, but there is no way to be sure if it will be effective.
One additional point I'd like to make: if the test is aimed at the web-app, and not specifically aimed at the WAF solution they have deployed, then I would highly recommend asking the client to disable the WAF on their staging site for the duration of the test. Leaving it on makes it much harder for you to give them a reasonable estimate of the security posture of the application, and that means they get less value from the test. If they're really interested in testing the WAF, they could do an additional test day afterwards that compares the exploitability of the found issues with and without the WAF being enabled.