Bug 733984 - Apply Location wrappers for same-origin cross-compartment wrapping. r=mrbkap

This isn't an issue right now, since it can't ever happen outside of sandboxes, which content can't use. But if it could, it could get a pure CrossCompartmentWrapper to a Location object, which is bad.
This commit is contained in:
Bobby Holley 2012-03-23 14:59:23 -07:00
parent a8eb45af36
commit a41865ae59

View File

@ -351,12 +351,23 @@ WrapperFactory::Rewrap(JSContext *cx, JSObject *obj, JSObject *wrappedProto, JSO
ExposedPropertiesOnly>::singleton; ExposedPropertiesOnly>::singleton;
} }
} else if (AccessCheck::isSameOrigin(origin, target)) { } else if (AccessCheck::isSameOrigin(origin, target)) {
// Same origin we use a transparent wrapper, unless the compartment asks // For the same-origin case we use a transparent wrapper, unless one
// for an Xray or the wrapper needs a SOW. // of the following is true:
// * The wrapper is a Location object.
// * The wrapper is flagged as needing a SOW.
// * The context compartment specifically requested Xray vision into
// same-origin compartments.
//
// The first two cases always require a security wrapper for non-chrome
// access, regardless of the origin of the object.
bool proxy; bool proxy;
if (AccessCheck::needsSystemOnlyWrapper(obj)) { if (AccessCheck::needsSystemOnlyWrapper(obj)) {
wrapper = &FilteringWrapper<CrossCompartmentSecurityWrapper, wrapper = &FilteringWrapper<CrossCompartmentSecurityWrapper,
OnlyIfSubjectIsSystem>::singleton; OnlyIfSubjectIsSystem>::singleton;
} else if (IsLocationObject(obj)) {
typedef XrayWrapper<CrossCompartmentSecurityWrapper> Xray;
usingXray = true;
wrapper = &FilteringWrapper<Xray, LocationPolicy>::singleton;
} else if (targetdata && targetdata->wantXrays && CanXray(obj, &proxy)) { } else if (targetdata && targetdata->wantXrays && CanXray(obj, &proxy)) {
if (proxy) { if (proxy) {
wrapper = &XrayProxy::singleton; wrapper = &XrayProxy::singleton;