nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

OTCSTicket Help

BrandonL

I have noticed a few things about OTCSTICKET and REST that I find to be strange and was wondering if anyone had insight on these issues.

I can make an auth called to our Content Server environment and pass in a totally fake user name and password. For example: username=testuser;password=testpassword. When I do this, an OTCSTICKET is granted successfully. I can then use this OTCSTICKET to upload or manipulate files within a specific Content Server folder that this fake user obviously does not have permissions to (since the user does not really exist). This is obviously really unsecure. Is that a bug or is this how it is supposed to work?
I have also noticed that if I request an OTCSTICKET from one machine using something like POSTMAN, I am not able to then use that OTCSTICKET to make subsequent calls from another machine. If I do, I get 401 errors. In this scenario, the calling user would be 2 different people on 2 different machines, but both trying to use the same OTCSTICKET. If I request an individual OTCSTICKET in each environment, subsequent calls will work just fine, as long as they originate from the same environment. I cannot figure out why this is exactly as it doesn't make a lot of sense. Does Content Server only accept the request if the account hitting the REST API is the same that requested the ticket?

Find more posts tagged with

Comments

Ferdinand Prantl

Ad 1. I cannot reproduce it.

Ad 2. OTCSTicket shares security settings with LLCookie. By default, it can be used only from the IP address where it was requested. See "Client IP Address" in the CS Security Parameters.

BrandonL

2 makes sense. Thanks.

1 is definitely happening in my environment. Here are screenshots showing the request. I can assure there is no user named this in our environment.

enter image description here

BrandonL

Also. this ticket can be used to upload to any directory in Content Server using REST API. Clearly this is a security issue.

Ferdinand Prantl

I don't know about the "testuser". I have a access to CS 10.5 2014/09 and latest, which are clean (nobody tampered with them), and I'm getting (the correct) "Invalid username/password specified.".

Pete_Oliver

Hi Brandon,

Is your environment configured for Integrated Windows Authentication (IWA) at all, or some other SSO solution?

Cheers!
Pete.

BrandonL

We are using IWA. Any chance it is accepting the credentials based on the logged in user who is making the request (and not really the username/password combo sent in with the form)?

Pete_Oliver

@Brandon, that's my thinking - yes. I have little experience with the CS REST API, so cannot be definitive about that.

Breemer_Rick

Hi Brandon, it should be easy to find for which user the ticket was obtained by checking CS to see which user has uploaded those documents.

Also, if you're using Postman, make sure you don't have any credentials under the authentication tabs (Basic Auth, Digest Auth...)

Ferdinand Prantl

Enabling IWA on a virtual directory has not been foreseen. The REST API is supposed to be accessible from any environment; not only from a Windows authenticated session. If IWA wins over the OTCSTicket, is it a bug? If it proves right, it would have to be tested and discussed first before this scenario is described.

So far, I recommend using the rest API on plain anonymous virtual directory.

UPDATE: THE CS REST API should be used via a virtual directory with the anonymous access enabled and with any integrated authentication disabled.

BrandonL

We created a separate virtual directory and only enabled anon access in IIS. That seems to have taken care of the perceived security risk. It appears that windows auth does in fact take over the anonymous auth when making REST calls, but in this scenario the calling user would still need to have permissions to the directory to upload something, even if they OTCSTICKET they paired into the call did not have the permissions.

BrandonL

Ferdinand Prantl

I filed an internal issue to solve this problem. The user identity behind the request must be clear. We have to take a stand to this type of configuration and either make it usable or prevent it.