NodeJS/hapi/2.5.0

Rosetta-Flash JSONP Vulnerability in hapi

This description taken from the pull request provided by Patrick Kettner.

Versions 6.1.0 and earlier of hapi are vulnerable to a rosetta-flash attack, which can be used by attackers to send data across domains and break the browser same-origin-policy.

Recommendation

• Update hapi to version 6.1.1 or later.

Alternatively, a solution previously implemented by Google, Facebook, and Github is to prepend callbacks with an empty inline comment. This will cause the flash parser to break on invalid inputs and prevent the issue, and how the issue has been resolved internally in hapi.

Denial of Service in hapi

All Versions of hapi are vulnerable to Denial of Service. The CORS request handler has a vulnerability which will cause the function to throw a system error if the header contains some invalid values. If no unhandled exception handler is available, the application will exist, allowing an attacker to shut down services.

Recommendation

This package is deprecated and is now maintained as @hapi/hapi. Please update your dependencies to use @hapi/hapi.

Unsafe Merging of CORS Configuration Conflict in hapi

Versions of hapi prior to 11.1.4 are affected by a vulnerability that causes route-level CORS configuration to override connection-level or server-level CORS defaults. This may result in a situation where CORS permissions are less restrictive than intended.

Recommendation

Update hapi to version 11.1.4 or later.

Denial of Service in hapi

Versions of hapi prior to 11.1.3 are affected by a denial of service vulnerability.

The vulnerability is triggered when certain input is passed into the If-Modified-Since or Last-Modified headers.

This causes an 'illegal access' exception to be raised, and instead of sending a HTTP 500 error back to the sender, hapi will continue to hold the socket open until timed out (default node timeout is 2 minutes).

Recommendation

Update to v11.1.3 or later

Incorrect handling of CORS preflight request headers in hapi

Versions of hapi prior to 11.0.0 implement CORS incorrectly, allowing for configurations that at best return inconsistent headers, and at worst allow cross-origin activities that are expected to be forbidden.

If the connection has CORS enabled but one route has it off, and the route is not GET, the OPTIONS prefetch request will return the default CORS headers and then the actual request will go through and return no CORS headers. This defeats the purpose of turning CORS on the route.

Recommendation

Update to version 11.0.0 or later.

Rosetta-Flash JSONP Vulnerability

This description taken from the pull request provided by Patrick Kettner.

Background from the vulnerabilty finder

tl:dr - someone created a alphanum only swf converter, which means that they can in theory use it as a callback at a JSONP endpoint, and as a result, send data across domains.

Prepending callbacks with an empty inline comment breaks the flash parser, and prevents the issue. This is a fairly common solution currently being implemented by Google, Facebook, and Github.

Incorrect handling of CORS preflight request headers

Hapi versions less than 11.0.0 implement CORS incorrectly and allowed for configurations that at best returned inconsistent headers and at worst allowed cross-origin activities that were expected to be forbidden. [1]

'If the connection has CORS enabled but one route has it off, and the route is not GET, the OPTIONS prefetch request will return the default CORS headers and then the actual request will go through and return no CORS headers. This defeats the purpose of turning CORS on the route.' [2]

Denial of service - Potential socket exhaustion

Certain input passed into the If-Modified-Since or Last-Modified headers will cause an 'illegal access' exception to be raised. Instead of sending a HTTP 500 error back to the sender, hapi will continue to hold the socket open until timed out (default node timeout is 2 minutes).

Special thanks to James Halliday for bringing this exception pattern to our attention via the ecstatic advisory which lead to identifying this.

Route level CORS config overrides connection level defaults

When server level, connection level or route level CORS configurations are combined and when a higher level config included security restrictions (like origin), a higher level config that included security restrictions (like origin) would have those restrictions overridden by less restrictive defaults (e.g. origin defaults to all origins *).