32

I have a ASP application. On click of a particular link, some VB scripts are executed and an ASP page is to be shown, but instead I get a screen that says:

Information Not Available.
The requested URL was rejected. Please consult with your administrator.
Your support ID is: XXXXXXXXXXXXXXXXXXXXXX"

The IIS and event viewer logs do not show any error message.

This happens only for some users, but works fine for other users.

What are the possible causes for this error ?

JLRishe
  • 99,490
  • 19
  • 131
  • 169
suhas
  • 531
  • 1
  • 6
  • 15
  • It sounds like a security issue. Do all users have access to the vb script that the link is executing. – Robert Jan 17 '12 at 14:25
  • Yes, all have access to the VB script...I found the issue. This is a firewall message and an error was occurring in the VB script due to wrong data in database, but the error was not logged/caught properly. – suhas Jan 18 '12 at 23:07
  • 1
    Yeah the annoying thing about this message from F5 is that in my experience it returns HTTP 200 instead of an error status and so is harder to pick out from the 'good' traffic. In my case a particular POST of JSON data was triggering this response from the load balancer / proxy server. – nothingisnecessary Jul 12 '17 at 17:17

7 Answers7

55

Your http is being blocked by a firewall from F5 Networks called Application Security Manager (ASM). It produces messages like:

Please consult with your administrator.
Your support ID is: xxxxxxxxxxxx

So your application is passing some data that for some reason ASM detects as a threat. Give the support id to your network engineer to learn the specific reason.

eric
  • 755
  • 6
  • 11
  • 1
    This may be an old topic, but this is generally the correct answer. The cookies issue is mentioned by others is a byproduct of a misconfigured firewall. Imperva firewalls in particular run in the middle handling of cookies, SSL certificates, and sessions. If they discover something their ruleset doesn't like they will kill the session with this sort of message. – anakaine Jul 30 '20 at 23:39
  • @eric : Just checking in case you know any rule in ASM that I can check ? – marifrahman Aug 12 '20 at 14:09
  • In my case, this issue was due to broken `png` files that I submitted. Issue was solved by creating the required files again. – Kalyan Jan 04 '22 at 13:11
  • I was getting this error due to making a POST with an empty body, but without setting a Content-Length header. Adding Content-Length: 0 got my request past the filter. – johnwayner Nov 14 '22 at 19:43
11

Encountered this issue in chrome. Resolved by cleaning up related cookies. Note that you don't have to cleanup ALL your cookies.

Igal Karlinsky
  • 111
  • 1
  • 4
1

It is not related with Firewall. I had the same issue accessing from office and from mobile. I cleaned the cookies and worked fine. You can read more at https://support.google.com/chromebook/answer/1085581?hl=en

marcanuy
  • 23,118
  • 9
  • 64
  • 113
  • apparently, this can occur for a number of environment scenarios, including firewall. in my situation, this error issued by our firewall with ASM security policies turned-on to block the exposure of personal identifiable information. furthermore, it was not browser dependent. – mobibob Apr 14 '20 at 12:15
1

I was able to resolve my clearing my cookies and cache.

1

I found the issue. This is a firewall message and an error was occurring in the VB script due to wrong data in database, but the error was not logged/caught properly.

suhas
  • 531
  • 1
  • 6
  • 15
0

I have faced the same issue using Google Chrome browser. Same website was opening normally using the incognito mode and different browsers. At first, I cleared cached files and cookies over the past 24 hours, but this didn't help.

I realized that my first visit to the website was during the past 10 days. So, I cleared cached files and cookies over the past 4 weeks and that resolved the problem.
Note: I didn't clear my browsing history data

Rola
  • 1,598
  • 13
  • 12
0

Your request body probably contains content which is flagged as suspicious by a firewall or some other security mechanism (at least that's what the issue was for me). To circumvent this, you can simply encode the request body content as a Base64 encoded text on the client-side, and decode it on the server-side.

For example, if your client is a JavaScript application, I recommend you to use the js-base64 library, as it provides support for UTF-8 characters and it's really light without any dependencies.

I will leave a few examples in some popular web development languages.

JavaScript

import { Base64 } from 'js-base64';

Base64.encode('dankogai'); 
Base64.decode('ZGFua29nYWk=');

Java

public static String base64Encode(String plainText) {
    return Base64.getEncoder().encodeToString(plainText.getBytes());
}

public static String base64Decode(String encodedString) {
    byte[] decodedBytes = Base64.getDecoder().decode(encodedString);
    return new String(decodedBytes);
}

C#

public static string Base64Encode(string plainText) 
{
    var plainTextBytes = System.Text.Encoding.UTF8.GetBytes(plainText);
    return System.Convert.ToBase64String(plainTextBytes);
}

public static string Base64Decode(string base64EncodedData) 
{
    var base64EncodedBytes = System.Convert.FromBase64String(base64EncodedData);
    return System.Text.Encoding.UTF8.GetString(base64EncodedBytes);
}
bezbos.
  • 1,551
  • 2
  • 18
  • 33