oslc-op / oslc-specs

OSLC OP specifications and notes
https://open-services.net/specifications/
24 stars 9 forks source link

OSLC GET with selective properties should also support POST #591

Open jamsden opened 1 year ago

jamsden commented 1 year ago

CWE-598: Use of GET Request Method With Sensitive Query Strings suggests that REST services that use GET with query parameters that may expose sensitive information in the URL should also support POST so that the query parameters can be included in an entity request body instead.

This is a broader HTTP security issue that can be partially resolved by using TLS. But there may be cases where certain URLs have to be sent unencrpted to get through various proxies, etc. Or decrypted GET URLs could be stored in a user's browser where they could be exposed to hackers. TLS only addresses secure transition of HTTP requests, it does not address security of the content of those resources once they are consummed by a client or server.

OSLC Query already supports GET and POST for query strings. The only other GET in OSLC that might expose information is GET with selective properties. This would only expose property names, not values. However, CWE-598 explicity uses an example of exposing database column names which would be similar to exposing RDF resource property URLs.

OSLC Core 3.0 should be updated to support POST when using selective properties.

jamsden commented 1 year ago

The OSLC Core section on Selective Properties does not currently mention GET or POST. A conformance clause should be added indicating Selective Properties can be used with GET or POST in order to handle potentially large HTTP query strings, or secure sensitive information.

DavidJohnHoney commented 1 year ago

A oslc.properties parameter value is a URL encoded list of property Qnames. These will be mostly standard vocabulary terms such as dcterms:title, oslcLshortId etc. Most of these should not be sensitive. Users who define custom vocabularies should avoid exposing sensitive data in public facing proiperty URIs, such as in owl:sameAs.

I disagree with the proposal. We already have URI patterns where a GET on a specific URI gets data, and a POST to the same URI would create data. LDPCs are an example. See the OSLC Configuration Management specification. The proposal would be a breaking change.