Hardening Web Apps with Radware AppWall Against SQL Injection
Australian organisations running customer-facing portals in Sydney or Melbourne are under sustained pressure to harden every layer of their stack. The Australian Cyber Security Centre's Essential Eight, APRA CPS 234 for financial services, and the Notifiable Data Breaches scheme under the Privacy Act all push engineering teams toward demonstrable controls on the application edge. A web application firewall sits at the core of that story, and Radware AppWall is one of the more capable options for defending legacy and modern apps against crafted input. Many teams across Brisbane and Perth are pairing it with their existing application delivery stack rather than bolting on a separate appliance.
SQL injection remains the canonical web attack in ACSC threat reports year after year, because parameterised queries are still inconsistent across internal systems. The job of AppWall is to act as a compensating control where developers have not had time to refactor, while still letting legitimate traffic flow. This walkthrough covers preparing the appliance, building the policy set, tuning for false positives, wiring up logging, and keeping the rule base clean over time.
Preparing the AppWall Appliance and Integration Points
Most Australian deployments I see plug AppWall inline behind the existing load balancer, often a Radware Alteon pair hosted at a NextDC or Equanix facility. The first step is confirming the management interface is reachable only on an out-of-band network, since admin access is what an attacker will probe first. Lock the UI to a small allow list of sysadmin jump hosts in Sydney or wherever the SOC operates from.
Out-of-band management removes a class of risk before any rule is even authored. From there, license the application, join it to the management cluster, and pull the current signature pack. AppWall ships with a base set of vendor-curated rules covering the OWASP Top 10, but these will need tailoring to your specific endpoints. Look at the protected hosts, the back-end application stacks, and where the legacy ASP.NET pages still live, because those spots are precisely what motivated the WAF project in the first place.
Building the Core SQL Injection Policy Set
Before authoring anything custom, switch the AppWall engine into learning mode for a short window. A day during business hours is usually enough to capture normal parameter shape. Once logs are flowing, build a SQL injection policy that uses the built-in signatures as the first match tier, then layers behavioural checks for tautologies, UNION SELECT probes, and out-of-band payloads like xp_cmdshell or pg_sleep.
| Detection Approach | Strengths | Trade-offs in Production |
|---|---|---|
| Signature-based matching | Low CPU cost, well-suited to known CVEs | Misses novel or heavily obfuscated payloads |
| Lexical tokenisation | Catches tautologies and UNION variants reliably | Needs clean parameter context to avoid noise |
| Negative regex overrides | Surgical suppression for known good inputs | Easy to over-broaden into a vulnerability |
| Behavioural anomaly scoring | Detects drip-feed probes and time-based attacks | Higher false positive rate on chatty clients |
A practical starting point is to define a default-deny rule that inspects every POST body and query string at the parameter level, not just the URI. AppWall can attach to JSON, XML, and form-encoded bodies, which matters for the API endpoints that often sit next to the legacy pages. Set the policy to block once you are confident the leg of the build under test is not generating noise.
Tuning Signature Sensitivity and False Positive Controls
Every WAF rollout hits the same wall: legitimate traffic looks suspicious. Australian retailers often find that postcode fields look SQL-ish to a naive regex, particularly when customers type SA, WA, or ACT as the state value. The fix is granular: create per-parameter exceptions rather than switching the whole signature off. In AppWall this means moving the rule from the global policy into the specific URL or parameter object, then adding a pattern allow.
Equally important is enabling the challenge response or CAPTCHA action on borderline rules instead of a hard block. That degrades gracefully for end users, so a customer stuck on a checkout in Parramatta never sees a 403 and the request is silently validated. Document every exception in change records that the security team can review, because ACSC and APRA auditors will absolutely ask for them during an assessment.
Monitoring, Logging and Incident Response
Once the policy is live, AppWall should forward events to your SIEM, whether the Sydney-based SOC at your NOC or a managed detection provider. Standard syslog is fine, but the JSON output from the AppWall API gives you per-transaction detail including matched signature ID, source IP, and the parameter that triggered the block. Dashboard the top offenders by source ASN, since a lot of automated SQL tooling now routes through offshore bulletproof hosts.
Wire alerts on repeat offenders into your ticketing queue. A single 403 is noise; ten in a minute from the same subnet is reconnaissance and warrants a block at the ADC layer. AppWall integrates with Alteon for exactly this kind of dynamic blacklisting, which closes the loop without operator intervention.
Ongoing Maintenance and Compliance Reporting
Like any signature-driven tool, AppWall drifts if you ignore it. Schedule monthly signature updates and a quarterly policy review against the latest ACSC advisories. Pull the rule hit report and look for rules that have never fired in production, which are candidates for tightening or removal. Conversely, rules that block legitimate traffic are candidates for narrower exceptions or for escalation back to the dev team to fix the root cause.
For APRA CPS 234 reporting, keep an export of the active policy version, the signature pack revision, and a list of compensating controls. That evidence file is what satisfies the control-effectiveness question auditors almost always ask, and it falls out of AppWall naturally if you have automated the snapshot. The result is a WAF posture that actually defends SQL injection rather than just ticking a box on a spreadsheet.