[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (ODATA-1033) Interoperability issue when using escaped slash/backslash in URLs
[ https://issues.oasis-open.org/browse/ODATA-1033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Pizzo updated ODATA-1033:
---------------------------------
Proposal:
We already have an implicit cast rule: "Primitive types are cast to Edm.String or a type definition based on it by using the literal representation used in payloads". This means that binary literals are cast to strings containing the base64url-encoded value.
Alternative proposal: both problematic components (Tomcat, .NET client) can deal with plain-text or percent-encoded forward- and backslashes if they appear in the query part of the URL.
This means parameter aliases are sufficient to defer problematic key values to the query part of the URL.
Services that support forward-slash in key values MUST support passing key values as parameters.
Put this issue on "Implementing OData" to add a recommendation for clients and servers on "problematic" infrastructures.
----------------------------------------------------------------
Old, inapplicable proposal:
Add an implicit cast rule that allows binary values in place of string values, where the base64url-encoded binary is the UTF-8 representation of the string value:
GET Categories(binary'Q29tZWR5L011c2ljYWw=')
Services are required to support an implicit cast from binary to string (anywhere). Clients are advised to use this form when passing a string value containing a forwardslash, backslash, and a null character (%5C, %2F, %00)
was:
We already have an implicit cast rule: "Primitive types are cast to Edm.String or a type definition based on it by using the literal representation used in payloads". This means that binary literals are cast to strings containing the base64url-encoded value.
Alternative proposal: both problematic components (Tomcat, .NET client) can deal with plain-text or percent-encoded forward- and backslashes if they appear in the query part of the URL.
This means parameter aliases are sufficient to defer problematic key values to the query part of the URL.
Add parameter aliases for key values to "Minimal conformance" - default parameter aliases for function imports are already in minimal conformance
Put this issue on "Implementing OData" to add a recommendation for clients and servers on "problematic" infrastructures.
----------------------------------------------------------------
Old, inapplicable proposal:
Add an implicit cast rule that allows binary values in place of string values, where the base64url-encoded binary is the UTF-8 representation of the string value:
GET Categories(binary'Q29tZWR5L011c2ljYWw=')
Services are required to support an implicit cast from binary to string (anywhere). Clients are advised to use this form when passing a string value containing a forwardslash, backslash, and a null character (%5C, %2F, %00)
> Interoperability issue when using escaped slash/backslash in URLs
> -----------------------------------------------------------------
>
> Key: ODATA-1033
> URL: https://issues.oasis-open.org/browse/ODATA-1033
> Project: OASIS Open Data Protocol (OData) TC
> Issue Type: Improvement
> Components: URL Conventions
> Affects Versions: V4.0_OS
> Environment: Proposed
> Reporter: Evan Ireland
> Assignee: Ralf Handl
> Priority: Minor
> Fix For: V4.01_CSD02
>
>
> We have encountered issues with Tomcat servers handling %-encoded slashes (and backslashes) in URLs. In particular, even when getting URL using HttpServletRequest.getRequestURI (which shouldn't do URL decoding) a percent-encoded backslash (e.g. in a quoted string within the URL) will appear in the result of getRequestURI as a forward slash.
> Now Tomcat apparently offers an option to permit this, but...
> According to http://stackoverflow.com/questions/9719224/coding-forward-and-backward-slashes-in-tomcat-7
> *Do not enable non-standard parsing of the URI. Disabled by default, but still in the application for backwards compatibility reasons are two system properties, org.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH and org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH, that allow non-standard parsing of the URI. These properties significantly improve your chances of a directory traversal attack and are therefore strongly recommended to avoid using.*
> If correct handling of URLs requires the use of web server configurations that are strongly recommended against for security reasons, we might want to consider what recommendations/accommodations should be made in the OData specification to ensure end-to-end interoperability of strings containing 'special' characters.
--
This message was sent by Atlassian JIRA
(v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]