Jiwa

Hi guys,

One of our clients has been pinged during a security audit due to the Jiwa API. They have requested that we lock down the metadata endpoint.

It appears from https://docs.servicestack.net/auth/restricting-services#hiding-services-from-metadata that while not removing it completely, it is possible to remove all the content from the /metadata endpoint, however this would involve adding [ExcludeMetadata] decorations throughout the Rest API plugin, which would be clobbered with your next update.

Am I missing that you have already catered for this programmatically? If not, 1) is there a solution I can implement now that doesn't alter the Rest API plugin, and 2) could you add a future feature to handle this programmatically, preferably tied to the existing REST API / Debug Mode setting?

Cheers,
Neil

neil.interactit wrote:They have requested that we lock down the metadata endpoint.

It appears from https://docs.servicestack.net/auth/restricting-services#hiding-services-from-metadata that while not removing it completely, it is possible to remove all the content from the /metadata endpoint, however this would involve adding [ExcludeMetadata] decorations throughout the Rest API plugin, which would be clobbered with your next update.

Am I missing that you have already catered for this programmatically? If not, 1) is there a solution I can implement now that doesn't alter the Rest API plugin, and 2) could you add a future feature to handle this programmatically, preferably tied to the existing REST API / Debug Mode setting?

We don't have a way of not exposing the metadata.

Before we consider the best way to do this, I want to first understand why the metadata would be of concern. Knowing what the DTO's look like and which routes exist isn't disclosing anything sensitive and does not give any advantage to a potential attacker.

Is the API needed to be exposed publicly? If not, then why not employ network level restrictions on access to the API.

Hi Mike,

I tend to side with you on this, but this is an external security audit carried out by consultants engaged by the board (of I'm guessing you know who). The independence of this process is such that we can't really question them, it's more a case of not getting a tick if we don't comply ... which won't go down well!

And yes the API is required externally by SalesForce. I am pursuing having this external access locked down to specific IP addresses (if SF can nominate a range they will access from), but as I understand it, even with this, locking down the metadata is still required.

Cheers,
Neil.

This is from the documentation found here https://docs.servicestack.net/metadata-page

Code: Select all

SetConfig(new HostConfig {
    EnableFeatures = Feature.All.Remove(Feature.Metadata)
});


or more accurately in a plugin configure method

Code: Select all

AppHost.SetConfig(new HostConfig {
    EnableFeatures = Feature.All.Remove(Feature.Metadata)
});


Thanks Stuart.

Hi Mike,

That works. I have tested by adding a line after line 742 in REST API:

Code: Select all

            Feature disableFeatures = Feature.Jsv | Feature.Soap;
            if (!debugMode) disableFeatures = disableFeatures | Feature.Metadata; //Disable metadata if not debugMode


(2nd line added).

Would it be possible to bake this in?

Cheers,
Neil

Development ticket created https://jiwa.atlassian.net/browse/DEV-10351

neil.interactit wrote:Would it be possible to bake this in?

Things like this we prefer people to use their own plugin to change the behavior - particularly in the absence of a compelling reason.

Attached is one which does what you need - no metadata page - you may want to modify the enabled features as I was stingy and only enabled json and nothing else.

Great, thanks Mike!