Skip to content

Count 404 requests with foreign extensions as attack wave scans#300

Open
bitterpanda63 wants to merge 1 commit into
mainfrom
fix/attack-wave-foreign-extension-404
Open

Count 404 requests with foreign extensions as attack wave scans#300
bitterpanda63 wants to merge 1 commit into
mainfrom
fix/attack-wave-foreign-extension-404

Conversation

@bitterpanda63
Copy link
Copy Markdown
Member

@bitterpanda63 bitterpanda63 commented Jun 1, 2026

Summary

Ports AikidoSec/firewall-node#1041 to Java.

  • Requests to foreign-platform extensions (php, php3, php4, php5, phtml) are only counted as attack wave scan hits when the HTTP response is 404
  • A 200 response may indicate the Java app is proxying to a PHP backend — those should not be flagged
  • jsp/jspx are intentionally excluded since Java apps can legitimately serve JSP files

Changes

  • PathChecker: added FOREIGN_EXTENSIONS set; isWebScanPath(String)isWebScanPath(String, int statusCode) with the new 404-gated check
  • WebScanDetector: isWebScanner(ctx)isWebScanner(ctx, statusCode), threads statusCode to isWebScanPath
  • AttackWaveDetector / AttackWaveDetectorStore: check(ctx)check(ctx, statusCode), threads statusCode to isWebScanner
  • WebResponseCollector: passes the already-available statusCode parameter to AttackWaveDetectorStore.check

Test plan

  • PathCheckerTest.testForeignExtensions_404_ReturnsTrue — php/php3/php4/php5/phtml with 404 → true
  • PathCheckerTest.testForeignExtensions_200_ReturnsFalse — same extensions with 200 → false
  • All existing PathCheckerTest, WebScanDetectorTest, AttackWaveDetectorTest, and benchmark tests pass with updated signatures
  • ./gradlew :agent_api:test passes green

🤖 Generated with Claude Code

Summary by Aikido

Security Issues: 0 🔍 Quality Issues: 2 Resolved Issues: 0

⚡ Enhancements

  • Treated foreign-platform extensions as scans only when response was 404

More info

Ports AikidoSec/firewall-node#1041 to Java. Requests to foreign-platform
extensions (php, php3, php4, php5, phtml) are only counted as attack wave
scan hits when the response is 404 — a 200 may indicate the app proxies to
another backend. jsp/jspx are excluded since Java apps can legitimately
serve JSP files.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
* @return true if an attack wave is detected and should be reported.
*/
public boolean check(ContextObject ctx) {
public boolean check(ContextObject ctx, int statusCode) {
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Method 'check(ContextObject ctx, int statusCode)' still uses the ambiguous 'check' prefix; the name doesn't convey its side effects (mutating internal LRU caches and sending events) or returned semantic.

Details

✨ AI Reasoning
​The PR modified the AttackWaveDetector.check method signature to add a statusCode parameter. The method name still begins with 'check', which is the pattern the rule discourages. The change occurred at the method declaration line where the signature was updated. This keeps the same ambiguous 'check' prefix while altering the method's behavior/contract, which maintains and slightly worsens the clarity problem because callers must now pass an extra parameter to a method whose name doesn't indicate its side-effects or return semantics.

🔧 How do I fix it?
Replace 'check' with more descriptive verbs that indicate the function's action or purpose. Use 'validate' for validation, 'get' for retrieval, or 'is' for boolean checks. Ensure the name clearly communicates the function's intent and return type.

Reply @AikidoSec feedback: [FEEDBACK] to get better review comments in the future.
Reply @AikidoSec ignore: [REASON] to ignore this issue.
More info

}

public static boolean check(ContextObject ctx) {
public static boolean check(ContextObject ctx, int statusCode) {
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Method 'check(ContextObject ctx, int statusCode)' uses the ambiguous 'check' prefix; its behavior (locking, forwarding to detector which mutates caches and may record events) isn't communicated by the name.

Details

✨ AI Reasoning
​The PR updated AttackWaveDetectorStore.check to accept a statusCode and forward it to the detector. The method name begins with 'check', which is discouraged: it doesn't indicate whether it performs queries, mutations, or reporting. The change touched the method signature and body, keeping the unclear name while changing its contract, thus worsening the clarity slightly by expanding the method's responsibilities without renaming.

🔧 How do I fix it?
Replace 'check' with more descriptive verbs that indicate the function's action or purpose. Use 'validate' for validation, 'get' for retrieval, or 'is' for boolean checks. Ensure the name clearly communicates the function's intent and return type.

Reply @AikidoSec feedback: [FEEDBACK] to get better review comments in the future.
Reply @AikidoSec ignore: [REASON] to ignore this issue.
More info

@codecov
Copy link
Copy Markdown

codecov Bot commented Jun 1, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant