不使用常规表单提交的ASP.Net页面能否抵御Bot攻击？

Let's break down your questions and walk through practical, actionable solutions:

Can Bots Discover Your Web Service Endpoint? #

Absolutely. Any bot that crawls your page's source code will easily spot the url variable in your JavaScript (https://www.abc123.com/issueservice/save). Even minified or obfuscated JS can be decompiled, so hiding endpoints in client-side code isn't a viable defense.

What Happens If Bots Abuse the Service? #

Once bots have your endpoint, they can:

• Flood your database with hundreds/thousands of fake issue entries, polluting data and increasing server load.
• Launch brute-force or denial-of-service (DoS) attacks to overwhelm your service.
• Attempt injection attacks (SQL, XSS) if your backend skips input validation.

Is Your Proposed "firstName" Parameter Solution Effective? #

No, this approach is too weak to stop determined bots. They can either:

• Parse your JavaScript to identify required parameters and send dummy values, or
• Guess common parameter names and submit arbitrary data.

This trick won't meaningfully protect your service—you need stronger, layered defenses.

Practical, Effective Protection Measures #

Here are steps to secure your AJAX endpoint:

1. Use ASP.NET's Built-In Anti-Forgery Tokens #

This is the most straightforward first line of defense. It ensures only requests from your legitimate page can trigger the service:

• Add the token to your page (inside the <form> tag):

  <%= AntiForgery.GetHtml() %>
  

• Modify your AJAX call to include the token in request headers:

  var token = $('input[name="__RequestVerificationToken"]').val();
  $.ajax({
    type: "POST",
    url: url,
    headers: { "__RequestVerificationToken": token },
    data: JSON.stringify(data),
    // ... rest of your AJAX configuration
  });
  

• Add the validation attribute to your ASMX service method:

  [WebMethod]
  [ValidateAntiForgeryToken]
  public void Save(IssueData data)
  {
      // Your save logic here
  }
  

2. Implement Rate Limiting #

Limit how many requests a single IP address can make in a given window (e.g., 5 requests per minute). You can do this via:

• ASP.NET middleware like IPRateLimitMiddleware (for classic ASP.NET, use IIS modules or third-party libraries).
• Your web server (IIS/Apache) configuration.
• A reverse proxy (like Cloudflare) that offers built-in rate limiting.

3. Add CAPTCHA Verification #

Integrate a CAPTCHA (like Google reCAPTCHA v2/v3) to block automated submissions:

• For reCAPTCHA v2: Users solve a visual challenge before submitting.
• For reCAPTCHA v3: Runs in the background and assigns a trust score—block requests with low scores.
  Critical: Always verify the CAPTCHA response on your backend, not just the frontend.

4. Strict Input Validation & Sanitization #

Never rely solely on client-side checks—validate all inputs in your ASMX method:

• Ensure issueName, issueDescription, and issueSeverity are not empty and meet length/format rules.
• Sanitize text inputs to prevent XSS attacks (use HttpUtility.HtmlEncode or similar tools).
• Validate issueSeverity against allowed values (l, m, h, v) to reject invalid entries.

5. Validate Request Origin (As a Secondary Layer) #

Check the Referer header in your service to ensure requests come from your Issue.aspx page. Note that this can be spoofed, so use it as an extra guard, not your primary defense.

6. Require Authentication (If Applicable) #

If only logged-in users should submit issues, add ASP.NET authentication (Forms Auth, etc.) to your service. This limits access to authenticated users only.

Final Takeaway #

Your empty code-behind doesn't protect the service endpoint itself. The "firstName" parameter trick won't stop bots—invest in the stronger measures above, starting with anti-forgery tokens and input validation, then adding rate limiting and CAPTCHA for extra security.

内容的提问来源于stack exchange，提问作者Sunil