Clientside information leakage: ds.xml mail-definitions trough DataSourceLoader

[Blama]

Hi Isomorphic,

if you load a .ds.xml with <mail>-tags in the operation bindings, this information is available on the client trough the DataSourceLoader response as well (from, to, bcc, templatename etc).
I don't think that it is needed on the clientside(?) and think it should not be there.

Additionally:
If I don't want some .ds.xml files to be available on the client (information leakage + IDACall should not be able to use those .ds.xml), how would I do this?
I would need a serverDS directory and a sharedDS directory, where DataSourceLoader can only load from the sharedDS-dir and IDACall only processes requests for these .ds.xml.
Currently a malicious user could try to best-guess (server only)-DataSource-Ids, try to load them and with this information try to access IDACall.

I'm using current 5.0p.

Best regards
Blama

[Isomorphic]

Hi Blama,
We will look into why the 'mail' tags aren't being stripped out. We agree those should not be made available client-side.


On the other question about ds.xml files -- you can use declarative security - for example dataSource.requiresAuth - to make a dataSource unable to be called from the client. This mechanism will still allow the DS to be invoked directly from the server, but not from unauthorized / unathenticated requests coming in from the client [and there's no need to make any requests authenticated!]

This will not prevent the dataSource definition from being served to the client if they hit the hit the dataSourceLoader servlet. In terms of real exploitable security holes, this should not matter - the information contained in the DataSource definition would be essentially a set of fieldNames and data types only as we strip out the server-side configuration tags / embedded server scripts, etc before serving the file.

However - having discussed this internally, it seems like an explicit "serverOnly" attribute on the dataSource would have some value, so we plan to add this.
The new flag will both prevent the dataSource definition being picked up by the dataSourceLoader servlet, and suppress all operations that come from the client without the need for explicit requires/requiresAuth configuration.

We'll follow up with details on this new feature (and the issue with "mail" tags) when we have more information for you.

Regards
Isomorphic Software

[Blama]

Hi Isomorphic,

that's great news. Looking forward to it.

Best regards
Blama

[Isomorphic]

This has now been resolved and will be available in the next 5.0p build. This includes both the exclusion of the mail tag and the addition of a new datasource config attribute "serverOnly" which can be used to indicate that a datasource should not have it's definition exposed by the DataSourceLoader. This feature is still undocumented though.

[Blama]

Hi Isomorphic,

the mail tag problem is solved for me using today's nightly. I'll test the "serverOnly"-attribute soon.

Thanks again
Blama

[Blama]

Hi Isomorphic,

However - having discussed this internally, it seems like an explicit "serverOnly" attribute on the dataSource would have some value, so we plan to add this.
The new flag will both prevent the dataSource definition being picked up by the dataSourceLoader servlet, and suppress all operations that come from the client without the need for explicit requires/requiresAuth configuration

I can see that this works as expected - data for a ds.xml with serverOnly="true" is not transferred, thanks a lot!
I wasn't able to see that the IDACall servlet stopped working with those blocked datasources ("and suppress all operations that come from the client" is not working yet), though.

I started my application with all DataSources allowed, opened it, changed one .ds.xml in the webserver directory and tried to access the DS - this still works.
I also tried to restart the webserver afterwards, log-in in a different browser-tab and then try to access the DS in the 1st tab, which also still works.

Could you have a look?

Best regards
Blama

[Blama]

Hi Isomorphic,

I tried to implement it myself in my IDACall subclass. Is it as simple as this inside my handleDSRequest() override?

public DSResponse handleDSRequest(DSRequest dsRequest, RPCManager rpc, RequestContext context) throws Exception {
    String serverOnlyProperty = ((BasicDataSource) dsRequest.getDataSource()).getProperty("serverOnly");
    // Block access to serverOnly DataSources
    if ("true".equals(serverOnlyProperty))
        return new DSResponse().setDataSource(dsRequest.getDataSource()).setFailure(
                I18n.getString("accessToServerOnlyDSNotAllowed", dsRequest.getHttpServletRequest()));

Best regards
Blama

[Isomorphic]

Hello Blama,

Thanks for letting us know about this. It was clearly missed out while implementing the serverOnly attribute. We are resolving this now, please bare with us.

The solution you have implemented looks good and is pretty much the way we will be implementing it as well. However we're not sure if there is any value in returning a specific error code to advertise a protected DataSource. Do you need to know this client side?

Regards,
Isomorphic Software

[Isomorphic]

Hello Blama,

This has now been implemented and back ported to 10.0 as well. Please give the next nightly a go.

Regards,
Isomorphic Software

[Blama]

Hi Isomorphic,

thanks a lot! I'll remove my own code then.
I do not need the error message in my application - at least not for the users. Reason for it was that I have DataSources I use on the server only so far.
Sometimes I need to migrate one to server+client usage, and I thought that this would help then spotting the error of a not-removed "serverOnly="true"" Now thinking about it, the DS would not be loaded in the 1st place and trying to obtain the DataSource on the client with DataSource.get("name") would already fail. So no, I don't need the information on the client.

Thank you & Best regards
Blama

[Blama]

Hi Isomorphic,

FYI: I just noticed that the attribute is not in the docs, yet. Is the feature supported in a way, that you do want to add it to the docs?

Best regards
Blama

[Blama]

Hi Isomorphic,

I just saw that it is in the docs now.

Thank you
Blama