Handling Confidential Data in OData URLs
SAP Gateway supports the use of $batch for protecting sensitive data that can be exposed in URLs, and where the URL gets too long.
OData URLs can contain sensitive data that is assumed to be protected using HTTPS.
The following is an example scenario for protecting sensitive data contained in an OData URL.
Example Using HTTPS Connection:
An OData service for banking, offers an EntitiySet ‘CreditCards’ which is a collection of the Entity ‘CreditCard’.
The minimal information of the credit card consists of an ID (key property), and the properties cardNumber, validThru, CardOwnerName.
For a GET request using the URL https://odata.example.org/OData/Banking.svc/CreditCards(guid'12345678-examplea-exampleb-examplec-examplef')
No URL information is visible in an HTTPS communication, except the information of the server and the port number.
The following is the expected flow:
TLS connection is established between the client application, for example, browser-based or a native mobile application and odata.example.org on a standard HTTPS port 443 (see also http://tools.ietf.org/html/rfc2818#section-2.
1)This looks like:
REQUEST: CONNECT odata.example.org:443 HTTP/1.1
Host: odata.example.org
Proxy-Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.122 Safari/534.30
RESPONSE: HTTP/1.1 200 Connection established
Over the TLS connection, the encrypted application data is sent:
REQUEST: GET /OData/Banking.svc/CreditCards(guid'12345678-examplea-exampleb-examplc-examplef') HTTP/1.1
Host: odata.example.org
Connection: Keep-Alive
The server sends the response in encrypted form.
The Web server typically uses log files to log all the traffic, in such logs, you can find the request URLs and some header fields (make sure that access to the log files is secured).
A browser typically stores URLs in the browser history and also sends URLs around in the “Referer” header field. This is a standard behavior and cannot be avoided or influenced, except where you write your own native application to control it at that end of the connection.
For the above reason, it is strongly recommended not to use any sensitive data as key fields in OData entities.
In the example above, a GUID was used as key, which is acceptable. However, refrain from using a secret or sensitive data as key, such as, the credit card number.
Example Using $batch Functionality
For a GET request using the URL: https://odata.example.org/OData/Banking.svc/CreditCards?$filter=CardNumber eq ‘1234 5432 1234 6543‘?
In this case, you cannot avoid supplying a secret in the URL. However, it is a Query, so the solution is to use the $batch endpoint of the service and send the following over the TLS connection:
POST /OData/Banking.svc/$batch HTTP/1.1
Host: odata.example.org
Content-Type: multipart/mixed; boundary=batch_36522ad7-fc75-4b56-8c71-56071383e77b --batch_36522ad7-fc75-4b56-8c71-56071383e77b
Content-Type: application/http
Content-Transfer-Encoding: binary
GET CreditCards?$filter=CardNo eq '1234 5432 1234 6543'
Host: odata.example.org --batch_36522ad7-fc75-4b56-8c71-56071383e77b--
REQUEST: POST /OData/Banking.svc/CreditCards HTTP/1.1
Host: odata.example.org
Connection: Keep-Alive
Content-Type: application/x-www-form-urlencoded X-HTTP-Method:
GET $filter=CardNo eq ‘1234 5432 1234 6543‘
The GET request is redirected as a POST request to the $batch endpoint, so that there is no sensitive or secret content in the URL.
The server response is essentially the same:
REQUEST GET /OData/Banking.svc/CreditCards?$filter=CardNo eq ‘1234 5432 1234 6543‘ HTTP/1.1 Host: odata.example.org Connection: Keep-Alive
The response is only wrapped in a multipart envelope.
Note that a CSRF token protection is required for the POST request, as SAP Gateway ensures the token protection on the REST layer, even non modifying$batch implementation requires a CSRF token.