[FALSE REPORT] Security vulnerabilities reported in v12.1p_2021-07-12 version

[kzkondoh]

Using burpsuite and foxyproxy plug-in to capture all of the communication between the browser and the core server.

Sending arbitrary xml request -> get a verbose response which discloses information about the server – e.g. that it is running on Windows
＝＝＝＝＝

//isc_RPCResponseStart-->[{affectedRows:0,data:[{upl_filepath:"E:\\pleiades\\tikal\\Platform\\TikalPlatform\\temp\\core\\c0acb385-52ae-46f9-90d1-33c8b222babb\\xxx.json",
upl_filecontent:"{\n\t"web": {,upl_filecleanuppath:"E:\\pleiades\\tikal\\Platform\\TikalPlatform\\temp\\core\\c0acb385-52ae-46f9-90d1-33c8b222babb\\xxx.json"}],
endRow:1,invalidateCache:false,isDSResponse:true,operationType:"add",queueStatus:0,startRow:0,status:0,totalRows:1}]//isc_RPCResponseEnd

＝＝＝＝＝
question:
No1:

// isc_RPCResponseStart-> [...] // isc_RPCResponseEnd

Is there a way to remove or hide this content (log) from the bucket?

No2:
If you can't do No1, do you have any ideas so that you don't understand Windows when uploading files?

[Isomorphic]

It looks like you may have captured something from an application that you have built based on SmartClient, not from a standard SmartClient feature. The path is being disclosed under the name "upl_filepath", which is not a property name we use in the framework.

If you disagree, and you think that our product is disclosing this information rather than just your application code doing it, then please show a minimal, ready-to-run test case that demonstrates the claimed information disclosure, in a fully patched version of our product.

[kzkondoh]

Hi Isomorphic:

Thank you for your info and answers.
---------------

//isc_RPCResponseStart-->[{data:"Received non-DMI RPCRequest in IDACall - ignoring. To send generic RPCRequests, you should override the actionURL property either on the RPCRequest or globally via RPCManager.actionURL.",status:-1}]//isc_RPCResponseEnd

---------------

[{data:"Received non-DMI RPCRequest in IDACall - ignoring. To send generic RPCRequests, you should override the actionURL property either on the RPCRequest or globally via RPCManager.actionURL.",status:-1}]

I think this part is a debug log, but is there a way to prevent it from appearing or hide it ?
In other words, is there a way to prevent debug information from appearing or hide it ?

[Isomorphic]

This doesn’t contain any sensitive information, it’s just an error message, and an end user would never see it.

[kzkondoh]

Hi Isomorphic:

Thank you for your info and answers.

>This doesn’t contain any sensitive information, it’s just an error message, and an end user would never see it.

I agree about this.
also,I want know this any way can hide this([{data:"Received non-DMI RPCRequest in IDACall - ignoring. To send generic RPCRequests, you should override the actionURL property either on the RPCRequest or globally via RPCManager.actionURL.",status:-1}]).

[Isomorphic]

So just to make it clear.. there is no purpose whatsoever in hiding this. It does not expose sensitive information and end users will not see it.

Having said that, perhaps you are dealing with a requirement from people who are impervious to rational thought. If so, where are you seeing this text that you are trying to suppress?

If it's an HTTP response, you could install a filter servlet in front of IDACall, so that if this specific response is issued, your filter servlet would stop it from being delivered to the browser. Again, this is useless and in fact will hamper performance.. but it would "work" to suppress this response, or any other that is found to be objectionable.

[kzkondoh]

Hi Isomorphic:
Thank you for your answers and countermeasures. I will think about it( filter servlet).

[kzkondoh]

Hi Isomorphic:
I'm sorry to ask you a question again.
Is any way to hide this log (debug log?) in smartgwt?

[Isomorphic]

What specifically are you asking about?

We have already explained that:

1) the first error response, from your post #1, which revealed information about file paths, is not coming from the SmartGWT framework. It is from your application code. We cannot change this for you, because it is not coming from our software - it is coming from software that you wrote, not us. To change it, you must change your own code. We can't do that for you.

2) the second error response, mentioned in your #5 post, does not reveal any information. There is no reason to change it. There is no security issue here, no information leakage, nothing at all to fix.

3) If you did want to modify the second error response (which again is a completely useless effort, and has no security impact whatsoever), you can do so, and we have already explained how.

So what problem are you trying to solve, and what can we do to help?