Information Disclosure in Error Message

[ekaku]

Hi　Team:

If I change the subscribedChannels value to %7Bar (malformed json format) and send it to the server side, I get "com.jsomorphic.js.parser.ParseException..." in the response.

In a browser or send the following request using an intercepting proxy or similar software:
Request：

GET
/xxxx/xxxx/messaging?&connectionID=foo&subscribedChannels=%7Bbar&eventStream=true
HTTP/1.1
...

Response

HTTP/1.1 200 OK
Connection: close
Date: Mon, 31 Oct 2022 09:30:32 GMT
Content-Type: text/html;charset=utf-8
Set-Cookie: JSESSIONID=node08az8l4l85tojahrpt6matg5a463.node0;Path=/;Secure
Expires: Mon, 31 Oct 2022 09:30:32 GMT
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 158
parse failure: <BR>com.isomorphic.js.parser.ParseException: Encountered "&lt;EOF&gt;"
at line 1, column 21.<BR>Was expecting:<BR>&nbsp; ":" ...<BR>&nbsp;

The error message discloses the JSON parser class com.isomorphic.js.parser, which is part of the Isomorphic
SmartClient framework.

[Isomorphic]

Hello Ekaku, just to clarify, the complaint here is that the error message includes the fully qualified className of the Java class that is involved in the error, correct?

So as far as an actual exploit, the idea if that, knowing this className, someone could potentially use this information to craft an exploit?

We ask because, there are many simple ways of knowing that a given deployment is a SmartClient deployment, which would imply the presence of this class. It's very easy, in general, to know what framework is responding on the server side (e.g. Spring or other server-side frameworks).

Given that, there does not appear to be a security issue here, would you agree?

[ekaku]

Hi Isomorphic

Thank you for the quick reply.
[HTML]

Hello Ekaku, just to clarify, the complaint here is that the error message includes the fully qualified className of the Java class that is involved in the error, correct?

[/HTML]

The problem is Two points.

1st The problem is that the attacker can see the details of the error.(Here is ParseException: Encountered)
2nd The problem is that you can see that the attacker can nkow the ours framework is works with SmartClient.

[Isomorphic]

Hello,

It's not possible to hide the fact that you are using SmartClient, because the SmartClient framework is downloaded to the browser as part of the loading of your application. There are many, many other ways in which it can be determined as well: URL patterns, etc.

Are there any security problems we can help with?

[ekaku]

Hi Isomorphic.

I can understand your point.
By the way, do Isomorphic team have any plans to fix the fact that you can check detailed error messages?(For example: ParseException: Encountered -> Access denied)

[Isomorphic]

Sorry, what error message did you have in mind, for what scenaria, and what's the issue with it?

Is this another concern about information disclosure?

[ekaku]

HI Isomorphic.
Sending a request like '/xxxx/xxxx/messaging?&connectionID=foo&subscribedChannels=%7Bbar&eventStream=true' will give you an error message detailing where and what went wrong.
Detail message like :' failure: <BR>com.isomorphic.js.parser.ParseException: Encountered "&lt;EOF&gt;" ' .
This will give the attacker a hint.
We would prefer a simple message like 'access denied' message instead of detailed error messages.
What do team think.

[Isomorphic]

What is the hint being given here?

As previously explained, there is no feasible way to hide that the application is SmartClient, since using the application literally downloads code from SmartClient. This is true of all web application frameworks, by the way.

Given that an attacker knows he is dealing with a SmartClient application, the JavaDoc for the SmartClient backend is just a Google away. This is true of every possible application framework, for example, Spring, Hibernate, etc.

So what can possibly be hidden here?

Note that Isomorphic's founding team included two security professionals. So we do understand what you have in mind regarding information leakage - if the sole external way to access a system is, for example, a single SSH endpoint, then it can make sense to try to hide the nature of the system. This involves not just that SSH endpoint, but trying to mask every single way in which the machine might respond over the network, at the IP or even physical level - you need to take into account things like pings, DNS lookups and even ARP caches to do this properly, because an APT can use something as subtle as ARP cache expiry latency to determine what OS is in use.

At a military security level, this can be done and we've done it.

But when you are talking about a web application using a well-known framework whose code is literally downloaded into the browser... there is no feasible way of hiding what system is being used.

If you want to pay attention to security, all of your efforts should be directed to other areas of risk. And we can help with this if you want - we have services such as our Architecture Review that can help you with security risk assessment.