Insufficient authorization query

[mbaluda]

Relevant sources:

• https://cap.cloud.sap/docs/guides/security/aspects#secure-authorization

• https://cap.cloud.sap/docs/guides/authorization#restrict-annotation

• CWE-862: Missing Authorization

  • The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
  • CWE-425: Direct Request: The web application does not adequately enforce appropriate authorization on all restricted URLs, scripts, or files.

• CWE-842: Placement of User into Incorrect Group

  • Subclass: CWE-286: Incorrect User Management

• CWE-266: Incorrect Privilege Assignment

  • A product incorrectly assigns a privilege to a particular actor, creating an unintended sphere of control for that actor.

[jeongsoolee09]

A standard library query: User-controlled bypass of security check. Related CWEs:

• Common Weakness Enumeration: CWE-807.
• Common Weakness Enumeration: CWE-290.

[jeongsoolee09]

Authorization enforcement in Node.js:

service CustomerService @(requires: 'authenticated-user'){
  entity Orders @(restrict: [
    { grant: ['READ','WRITE'], to: 'admin' },
  ]){/*...*/}
  entity Approval @(restrict: [
    { grant: 'WRITE', where: '$user.level > 2' }
  ]){/*...*/}
}

is equivalent to

const cds = require('@sap/cds')
cds.serve ('CustomerService') .with (function(){
  this.before ('*', req =>
   req.user.is('authenticated') || req.reject(403)
  )
  this.before (['READ', 'CREATE'], 'Orders', req =>
    req.user.is('admin') || req.reject(403)
  )
  this.before ('*', 'Approval', req =>
    req.user.attr.level > 2 || req.reject(403)
  )
})

Note that before registration function is used to intercept the request and check the request parameter for authorization before it gets processed.

[jeongsoolee09]

Sample CDS @restrict annotations scraped from CAPire:

entity Orders @(restrict: [
    { grant: 'READ', to: 'Auditor', where: 'AuditBy = $user' }
]) {/*...*/}

entity Reviews @(restrict: [
    { grant:['READ', 'WRITE'], to: ['Reviewer', 'Customer'] }
]) {/*...*/}

entity Orders @(restrict: [
    { grant: ['READ','WRITE'], to: 'Admin' },
    { grant: 'READ', where: 'buyer = $user' }
]) {/*...*/}

entity Orders @(restrict: [
    { grant: 'READ', to: 'Auditor', where: 'country = $user.country' },
    { grant: ['READ','WRITE'], where: 'CreatedBy = $user' },
]) {/*...*/}

service CatalogService {
    entity Products as projection on db.Products { ... }
    actions {
        @(requires: 'Admin')
        action addRating (stars: Integer);
    }
    function getViewsCount @(restrict: [{ to: 'Admin' }]) () returns Integer;
}

service CustomerService @(requires: 'authenticated-user') {
    entity Products @(restrict: [
        { grant: 'READ' },
        { grant: 'WRITE', to: 'Vendor' },
        { grant: 'addRating', to: 'Customer'}
    ]) {/*...*/}
    actions {
        action addRating (stars: Integer);
    }
    entity Orders @(restrict: [
        { grant: '*', to: 'Customer', where: 'CreatedBy = $user' }
    ]) {/*...*/}
    action monthlyBalance @(requires: 'Vendor') ();
}

Key takeaways:

• @restrict attaches to entities (or function parameters), whereas @requires qualifies actions and services.
• @restrict entries typically contains grant attribute, while where and to can be used as needed.

So checking if the service is protected in terms of authentication requires:

• Authz on Service
  • CDS: check presence of @requires annotation
  • JS: check presence of this.before('*', req => { req.user check or req.reject })
• Authz on Entity
  • CDS: check presence of @restrict annotation
  • JS: check presence of this.before(something, entityName, req => { req.user check or req.reject })
• Authz on Action
  • CDS: check presence of @requires annotation
  • JS: check presence of this.before(actionName, req => { req.user check or req.reject })
• Authz on a Function Parameter
  • CDS: check presence of @restrict annotation
  • JS: check presence of this.before(functionName, optionalBoundEntity?, req => { req.user check or req.reject })

[jeongsoolee09]

My misunderstanding: The difference between @restrict and @requires isn't in the kind of CDL elements they can be attached to; rather, it's in in the granularity. @requires can only specify the roles that are permitted to access the resource, whereas @restrict can also specify the roles with access levels with where.

[jeongsoolee09]

The services / entities / actions / functions can be protected with JS implementation code as well.

Protection with this.before

The conditional here lacks a meaningful success branch. Examples:

this.before("*", (req) => {
  if (!req.user.is("authenticated")) {
    req.reject(403);
  }
});

this.before("*", (req) => {
  req.user.is("authenticated") ? undefined : req.reject(403);
});

this.before("*", (req) => {
  req.user.is("authenticated") && true || req.reject(403);
});

Dual:

this.before("*", (req) => {
  if (req.user.is("authenticated")) {
  } else {
    req.reject(403);
  }
});

this.before("*", (req) => {
  !req.user.is("authenticated") ? req.reject(403) : undefined;
});

this.before("*", (req) => {
  (!req.user.is("authenticated") && req.reject(403)) || false;
});

Protection with this.on

The conditional here has both success branch and failure branch. Examples:

this.on("*", (req) => {
  if (req.user.is("authenticated")) {
    /* Do something */
  } else req.reject(403);
});

this.on("*", (req) => {
  req.user.is("authenticated") ? /* Do something */ true : req.reject(403);
});

this.on("*", (req) => {
  (req.user.is("authenticated") && /* Do something */ true) || req.reject(403);
});

Dual:

this.on("*", (req) => {
  if (!req.user.is("authenticated")) {
    req.reject(403);
  } else {
    /* Do something */
  }
});

this.on("*", (req) => {
  !req.user.is("authenticated") ? req.reject(403) : /* Do something */ true;
});

this.on("*", (req) => {
  (!req.user.is("authenticated") && req.reject(403)) || /* Do something */ true;
});