No announcement yet.
  • Filter
  • Time
Clear All
new posts

    Information Disclosure on absolute path

    Hi Isomorphic,

    If a user makes a specific POST request on the path ../IDACall, the server replies with a verbose error showing where the application resides.

    Server response:
    //isc_RPCResponseStart-->[{data:"Unable to locate - check to make sure it's available in {full_path_of_server}",status:-1}]//isc_RPCResponseEnd

    Is there a way to disable this feature to not to return the path of the server?

    It is happening in Smart GWT 5.0.


    May I also ask if this issue/vulnerability is fixed in the latest version of the framework Smart GWT 13.1 ?


      Can you please elaborate on how to reproduce this problem? Is this a URL you are typing into a browser address bar, or sending from a REST client, or something else? Can you provide the exact URL that causes the error response? Every simple attempt I have tried to reproduce the response - for example, http://localhost:8080/BuiltInDS/builtinds/../IDACall - just responds with a 404 error


        Hi, so actually we get this issue even when using curl command. Here is the payload:

        transaction=<transaction xmlns:xsi="" xsi:type="xsd:Object"><transactionNum xsi:type="xsd:long">5</transactionNum><operations xsi:type="xsd:List"><elem xsi:type="xsd:Object"><appID>XXXXXXX</appID><className>TEST</className><methodName>downloadWSDL</methodName><arguments xsi:type="xsd:List"><elem></ele...is_ISC_RPC_DMI xsi:type="xsd:boolean">true</is_ISC_RPC_DMI></elem></operations><jscallback>iframe</jscallback></transaction>

        I also found this vulnerability mentioned in page.


          We have now corrected this in all currently supported releases of SmartClient and SmartGWT - back to SC 11.1 / SGWT 6.1. Releases older than that have been out of support for quite some time and should be upgraded.


            Thank you very much for the fix. We are planning to upgrade from 5.0 to 6.1 but it would require some time to complete.
            Is there maybe a workaround we could do on our side to fix this vulnerability in 5.0 version quickly?
            Maybe changing some properties or extending some Java files? Could you please recommend a solution for this?


              This is not a vulernability, it's a minor information leak. It's not worth fixing.

              You should not upgrade to 6.1, which is almost 7 years old and going to be end-of-lifed soon. You should just update to the latest release.