API Vulnerabilites and their mitigation in Apigee ...

Report Inappropriate Content · ‎03-07-2016

Note:

This is not a comprehensive list. The threats outlined here had been reported during security vulnerability scan reports generated by APIGEE customers. Necessary corrective actions have been taken and these vulnerabilities have been mitigated. This blog is an attempt to list down common vulnerabilities that needs to be taken care of esp when building web app based solutions.

THREATS

1. Threat Name: Cross Site Tracing (XST)

Details:

HTTP methods like TRACE,TRACK allows the clients to see what is being received at the other end of the request chain. These methods are usually used for data testing or diagnostic information. These methods, while apparently harmless, can be successfully leveraged in some scenarios to steal legitimate user's credentials.

In a nut shell the real outcome of XST is that it exposes HTTP headers that are usually inaccessible to Javascript.

Rating: LOW-MEDIUM

Sample Use-Case:

Request:

curl TRACE http://test.in -H "Host: test.in"

Response:

200 OK HTTP/1.1

Host:"test.in"

Authorization: Basic "xyz"

cookie: sessionId=test;

Mitigation:

1.) Do not expose undocumented methods (TRACE,TRACK)

Apigee Policies for mitigation:

Sanitize response headers (either java script or using AssignMessage policy)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

</Headers>

<Set>

<Header name="Server">something</Header>

</Headers>

<Payload>{// PAYLOAD

}</Payload>

<StatusCode>{STATUS CODE}</StatusCode>

<ReasonPhrase>{response phrase}</ReasonPhrase>

</Set>

</AssignMessage>

2. Threat Name: Cross Site Scripting (XSS)

Details:

In XSS an attacker injects a client side code to the remote server. Of the several types of XSS two types majorly used are:

a) non-persistant xss

Also known as reflective XSS , this usually occurs when the web server reflects attacker's payload scripts ,such as in an error message , or a part of search result etc where some or all of the input is sent to the server as a part of the request.

b) persistant xss

This is similar to non-persistant xss with the difference being that the attacker's payload script is permanently stored in target application(example within a comment field of a blog etc ).so when the victim navigate to the afected page , he inadvetantly ends-up executing the payload script ,once the page is viewed in the browser

Sample Use-Cases:

Lets say we have a simple server side script (say for a blogging site) which stores/display's the user's comments .

print "<html>"

print "Latest comment:"

print database.latestComment

print "</html>"

The script assumes that the comments consists of text only .However an attacker could submit the below in the comments field :"<script>......malicious script....</script>". So any user visting the page will recieve the following response

<html>

latest comments:

</html>

Rating: MEDIUM-HIGH

Mitigation:

1) Have secure input handling by encoding

Ensure that the input characters are appropriately escaped. For example the most recogonizable form of encoding is HTML escaping, whcih converts characters like "<" and ">" into < and > respectively

2) Input handling by validation

Validate the type and data of input that is provided in the requests. Also there are situations where encoding becomes inadequate. In such cases encoding has to be complemented with validation.

3) Usually encoding and validation are sufficient in most of the cases to prevent XSS. As a third line of defense use of CSP (Content Security Policy) is recommended. CSP is used to constrain the browser viewing a web page so that it can only use resources (script/stylesheet etc) loaded from a trusted site. To enable CSP ,the HTTP response should be served with an additional "Content‑Security‑Policy" Header.

Apigee Policies for mitigation:

Input validation and Ecoding can be done in APIGE by using a combination of "extract Varibles" and Javascript policy.

CSP can be added in HTTP/HTTPS response bby using java script or "AssignMessage" policy.

<AssignTo createNew="true" type="request">request1</AssignTo>

<Set>

<Header name="Content-Security-Policy">default-src 'self'</Header>

</Headers>

</Set>

<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>

</AssignMessage>

3. Threat Name: Cross Site Reference Attack (CSRF or XSRF) or 'Sea Surf' ,Session Riding attacks

Details:

In this attack a malicious website will send a request to a web application that a user is already authenticate against from another website. This way the attacker can target the web application via victim's already authenticated web browser.

It is different form XSS in that while in XSS the attacker exploits the trust that the user has for a web site , in this case the attacker exploits the trust teh website has for a user.

Rating: MEDIUM-HIGH

Sample Use-Cases:

Assuming the victim is already authenticated in his banking website , the attacker can include a link or script in a third-party website that the victim visits. For instance, in a chat forum, an attacker posts a message that contains an image tag or an HTML image element. However, the source of the image contains a link which performs an action on a victim’s bank website account. So, instead of an image file the attacker has included a link that performs a bank transaction. Below is an example of the image tag containing a rogue URL.

Mitigations:

1) Use Tokens

It is always going to be difficult for a attacker to guess a token.

Use of Apigee Edge OAuth V2 policies can be use to manage the tokens

2) Add a per-request nonce to the URL and all forms in addition to the standard session

3) Checking for 'referer' Header can help mitigate this attack , by ensuring that the HTTP request has come from the original site

Apigee Policies for mitigation:

In APIGEE edge one way of achieving this is to have a conditional check(conditional referencing) on out of the box system variable(request.headers.referer) value and take appropriate actions.

Sample:

<Condition>request.header.referer != "abc.com"</Condition>

<TargetEndpoint>RaiseFault</TargetEndpoint>

</RouteRule>

4. Threat Name: Broken Authorization - session management exploits

Details:

This is particularly important for web apps. Attackers, both internal and external, can take advantage of these flaws to steal accounts from others and impersonate users. One of the more prominant flavor of the above exploit is the "Session fixation" exploit. In such exploit the attacked "fixes" the session id even before the user logs into the target server

Rating: LOW-MEDIUM

Sample Use-Cases:

A typical use case is the ability to retrieve the response using the browser's "BACK" button. For example for a 3 legged Oauth , with an improper implementation of the Authorization Code grant flow , the access token can be retrieved multiple time ,by hitting the back button in the browser

Apigee Policies for mitigation:

1) Cache-Control:no-cache & Pragma:no-cache headers are set in every response to the web app

In APIGEE Edge using the OOTB policy "Assign Message" the above headers can be added to response.

<Set>

<Header name="Cache-Control">no-cache</Header>

</Headers>

</Set>

</AssignMessage>

2) Ensure that SSL is used for all the authentication parts of the application

In APIGEE edge the application proxy must be exposed on a secure virtual host(port 443)

5. Threat Name: Insecure HTTP Redirect and covert redirect vulnerability

Details:

In correct and insecure 301 http redirection has sever security ramification , as it would allow a malicious attacker to persistently alter and remote control the way the application functions.

Rating: LOW-MEDIUM

Sample Use-Cases:

Consider two cases .

Case 1: An 301 redirection from https to http

In a few implementations of OAuth (3-legged), which required user authorization, it was observed that the redirection would happen from HTTPS to HTTP web page. It exposes the user data (that is captured on http) to be vulnerable to Man-In-Middle attack

Case 2: An 301 redirection form http to https

Since we are doing a 301 redirect over HTTP, someone could man-in-the-middle that connection and redirect the request anywhere they wanted - in particular they could actually not redirect at all, and instead get between the computer and the server(say http://example.com) , monitoring the connection and serving its contents under the name (http://example.com) instead.

Apigee Policies for mitigation:

One way to mitigate these threats is to use the HSTS HTTP header. This header tells the browser or browser like applications to load the pages only in HTTPS until some date in future. To cover the edge cases of the attack (case where the exploiter MITM the redirect even before HSTS is read by the browser), one can add the domain to the HSTS preload list.

Additionally ensure that every response over HTTPS has the below security headers.

Strict-Transport-Security

X-XSS-Protection

X-Content-Type-Options

X-Frame-Options

In Apigee Edge this can be achieved by using the "Assign Message" policy attached at the "post flow" response path of Client end point.

Sample code:

<Set>

<Header name="Strict-Transport-Security">max-age=31536000; includeSubDomains</Header>

<Header name="X-XSS-Protection">1; mode=block</Header>

<Header name="X-Content-Type-Options">nosniff</Header>

</Headers>

</Set>

</AssignMessage>

6. Threat Name: HTTP PARAMETER POLLUTION(HPP)

Details:

This vulnerability belongs to "injection" class of vulnerabilities. Under this attack, the attacker supplies multiple HTTP parameters with the same name. One consequence is that the attacker can potentially override existing hard-coded HTTP parameters to modify the behavior of an application, bypass input validation checkpoints, and access and possibly exploit variables that may be out of direct reach.

The consequence depends on the application's logic and can vary from a irritant to complete corruption of applications behavior.

Rating: LOW-MEDIUM

Sample Use-Cases:

Consider the below sample request

http://www.test.com/employee?id=-1+UNION+SELECT+username,password+FROM+users

Typically any server implemention remediation for SQL injection attack would reject the above request. But using HPP we can by pass this injection check.

http://www.test.com/employee?id=-1+UNION+SELECT+username&id=password+FROM+users

Depending on how the application is implemented, the resultant request.QueryString["id"] might be a glued value of the split parameters .

Apigee Policies for mitigation:

Ensure that an informed decision is been taken on handling of multiple occurrences of query parameters.

Also w.r.t APigee Edge , where ever we are adding a new parameter / modifying any existing query parameter ,ensure that the query param is first "removed" and then we "set" the new parameter.

Sample code:

<AssignTo createNew="true" type="request">request1</AssignTo>

</QueryParams>

</Remove>

<Set>

<QueryParam name="address">{value}</QueryParam>

</QueryParams>

</Set>

<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>

</AssignMessage>

7. Threat Name: Response splitting

Details:

The essence of HTTP Response Splitting is the attacker's ability to send a single HTTP request that forces the web server to form an output stream, which is then interpreted by the target as two HTTP responses instead of one response

Here the attacker completely controls the second response. HTTP Response Splitting attacks take place where the server script embeds user data in HTTP response headers. A very common use is in redirection URL.

Rating: LOW-MEDIUM

Sample Use-Cases:

Consider a request

http://www.example.com/index.jsp?lang=en

The parameter value for "lang" is coming from the end user.

For this request ,lets say that the typical response is a 302 redirect

Request:

http://www.example.com/index.jsp?lang=en

Response:

HTTP/1.1 302 Moved Temporarily

Date: xxxxxxxx

Location: http://example.com/by_lang.jsp?lang=eng

Server: xxxxxxxxxx

Content-Type: text/html

Attack scenario:

Now say the attacker send a malicious request in the below format

Request:

http://example.com/index.jsp?lan=foobar%0d%0aContentLength:%200%0d%0d%0a%0aHTTP/1.1%20200%20OK%0d

%0aContent-Type:%20text/html%0d%0aContent-Length:%2019%0d%0a%0d%0a<html>Attack</html>

This results in teh following response

HTTP/1.1 302 Moved Temporarily

Date: Wed, 24 Dec 2003 15:26:41 GMT

Location: http://10.1.1.1/by_lang.jsp?lang=foobar

Content-Length: 0

HTTP/1.1 200 OK

Content-Type: text/html

Content-Length: 19

<html>Shazam</html>

Server: xxxxxxxxxxxxxxxx

271009 with

Content-Type: text/html

The target parses this response as follows, A first HTTP response, which is a 302 (redirection) response.. A second HTTP response, which is a 200 response, with a content comprising of 19 bytes of HTML. Superfluous data - everything beyond the end of the second response is superfluous, and does not conform to the HTTP standard.

This exploit can be used to

-- take over a user's browser

-- redirect to a different host/web page

-- It can poison the cache

-- can lead to XSS

Mitigation:

1) If there are values beyond the trust boundaries that are used in HTTP messages ,validate the values by white listing 2)Remove all hazardous characters before embedding data into any HTTP response headers 3) In event the parameter are allowed to to contain a CR/LF,URL encode all data in HTTP headers with HTML entity reference

Apigee Policies for mitigation: In APIGEE Edge parameter values can be accessed using system variables in request/response flow(request.queryparams.{parmetername}/request.headers.{header-name}) Assignmessage Policy can be used to overwrite the values of existing parameters

Sample code: <AssignMessage name="AssignMessage-3"> <AssignTo createNew="true" type="request">request1</AssignTo> <Set> <QueryParams> <QueryParam name="address">{sanatized value}</QueryParam> </QueryParams> <Headers> <Header name="Location">{sanatized value}</Header> </Headers> </Set> <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables> </AssignMessage> The same can be achieved using the get/set methods via javascript

Report Inappropriate Content · ‎06-22-2017

Hi, I'd like to try and clarify this - there you say "Necessary corrective actions have been taken and these vulnerabilities have been mitigated." are you saying that (for example with (1)) that we don't need to take these actions because Apigee (Edge for Private Cloud in our case) already takes them, or are these the actions that we still need to take?

API Vulnerabilites and their mitigation in Apigee Edge