Announcement

**Isomorphic** · 22 Jun 2021, 20:37

SmartGWT 4.1 is very far past end-of-life, so if you need help with it, you need to purchase Consulting hours.

However, this may not be necessary, as SmartGWT does not have built-in support for LDAP, so there is no possibility of this being an issue with SmartGWT - if there is a security flaw here, it's in your application code that accesses LDAP, not with SmartGWT.

Regardless, given that you have posted this here, you almost certainly can benefit from some consulting help, so feel free to purchase hours and we will help you sort through what is wrong, and assist you with upgrading to a version that isn't end-of-lifed.

**myoshida** · 6 Jul 2021, 15:40

The reply was late, but thank you for your reply.

Following the advice, I updated my SmartGWT to the latest 12.1, and then tried the vulnerability tool again.
However, it was detected as an Injection again.

I contacted the vulnerability tool maker because our application doesn't have LDAP functionality.
According to the tool maker, although it is not LDAP, the following link corresponds to the same injection vulnerability.
https://support.hcltechsw.com/csm?id...icle=KB0011480

The request and its response in the vulnerability tool are as follows.

【Normal】
Request：
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
isc_tnum=5&_transaction=<transaction xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance" xsi:type="xsd:Object">
<transactionNum xsi:type="xsd:long">5</transactionNum><operations xsi:type="xsd:List"><elem xsi:type="xsd:Object">
<appID>box_setting_connector</appID><className>BoxSettingDispatcher</className><methodName>getBoxDateSetting</methodName>
<arguments xsi:type="xsd:List"></arguments><is_ISC_RPC_DMI xsi:type="xsd:boolean">true</is_ISC_RPC_DMI></elem></operations>
</transaction>&protocolVersion=1.0

Response：
HTTP/1.1 200 OK

【Vulnerable】
Request：
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
isc_tnum=5&_transaction=<transaction xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance" xsi:type="xsd:Object">
<transactionNum xsi:type="xsd:long">5</transactionNum><operations xsi:type="xsd:List"><elem xsi:type="xsd:Object">
<appID>box_setting_connector</appID><className>BoxSettingDispatcher</className><methodName>getBoxDateSetting</methodName>
<arguments xsi:type="xsd:List">))(|(objectclass=*</arguments><is_ISC_RPC_DMI xsi:type="xsd:boolean">true</is_ISC_RPC_DMI>
</elem></operations></transaction>&protocolVersion=1.0

Response：
HTTP/1.1 200 OK

”200/OK” is being responded to the request including injection.

Will this vulnerability affect SmartGWT?

**Isomorphic** · 6 Jul 2021, 16:25

This is not a security vulnerability. Frankly, this report makes no sense at all.

1) you are inexplicably reporting "HTTP/1.1 200 OK" as proof of a vulnerability - this is just a standard HTTP response, it does not indicate a vulnerability

2) you are now linking to a vulnerability report for another product which is a SQL injection but you are using LDAP syntax not SQL. Your LDAP syntax is not valid SQL and even if it made it into a SQL DB it would just be rejected

3) you are claiming a SQL injection but you haven't shown anything at all related to SQL, table structure, columns or what data could be injected

4) this isn't even how SQL DB access looks in SmartGWT. This isn't even a DataSource call. It's an RPC DMI which calls your application logic NOT SmartGWT's SQL engine

Please do not make a third attempt at posting about a "vulnerability" - what you need is not a fix for a vulnerability, but hands-on help with understanding what a security vulnerability is and how to analyze the output from your tool. We can provide that help, via Consulting. Start here.

**Isomorphic** · 6 Jul 2021, 16:45

Another way to explain:

You are using a security scanner tool and it's reporting a problem in your application.

That application consists partly of our technology and partly of code your company wrote, and the flaw, if its real, could be in either place.

Everything about your report strongly suggests that the problem is in your application code. You need to go talk to the developers who built the application, and have them analyze this report.

If those developers ultimately think there is a problem with our framework, then you can file a vulnerability report with us, showing the specific API call being made to our product, and explaining what our product is doing wrong, by referencing our documentation. And note, IDACall is not an API call, it is a servlet. In this case, it calls your application code first.

If you contacted us directly because your company has completely lost all the knowledge about how this application works, and you need help, then we can rescue you by reverse-engineering what you've built and fixing it - but that's Consulting, not Support. Use the link provided in the previous post to get started on that.

Announcement

About the vulnerability related to the injection attack on IDACall.

Comment

Comment

Comment

Comment