Model manifest-created UI5 client data models

[mbaluda]

What This PR Contributes

• Models default UI5 client data models created from manifest.json:
  • Recognizes explicitly declared sap.ui.model.json.JSONModel instances.
  • Infers JSON model types from referenced JSON data sources through MaD client-data-model types.
  • Associates each model with the nearest owning UI5 component, including standalone and nested components.
• Tracks path-specific, bidirectional model flow through declarative bindings:
  • Resolves relative paths through nested items binding contexts.
  • Keeps unrelated model paths separate to avoid false-positive flows.
  • Honors setDefaultBindingMode(BindingMode.OneWay) and component, view, control, and ancestor-control model overrides.
  • Represents bindings in .view.json files with synthesized data-flow nodes, enabling manifest-backed Input-to-HTML XSS flows in JSON views.
• Reorganizes UI5 model support into focused libraries:
  • UI5DataModels.qll owns model references, concrete JSON/XML/resource/OData models, manifest model declarations, binding modes, and binding-path resolution.
  • JsonBindingTarget.qll provides local-overlay data-flow nodes for JSON-view property bindings.
  • UI5.qll, UI5View.qll, and RemoteFlowSources.qll retain their component, view, and remote-source responsibilities.
• Adds focused regression coverage for manifest-created models in XML and JSON views, nested components, overrides, one-way binding, and path isolation.
• Demonstrates the detected XSS flows in code scanning:
  • https://github.com/advanced-security/codeql-sap-js/security/code-scanning/7943
  • https://github.com/advanced-security/codeql-sap-js/security/code-scanning/7945

[Copilot]

Copilot review overview

🟡 Changes recommended

One-way flow edges are reversed, and JSON bindings can misclassify unrelated properties as XSS sources or sinks.

Review effort: Balanced
Findings: 1 · 1

Open (2)

• Reverse one-way binding propagation branches · New
• Match JSON binding property names in XSS selectors · New

[Copilot]

Copilot review overview

🔵 Needs a closer look

Manifest model references, inherited binding modes, real JSONView aggregation bindings, and JSON-control locations remain incorrectly modeled.

Review effort: Balanced
Findings: None

Resolved since last review (2)

• Reverse one-way binding propagation branches
• Match JSON binding property names in XSS selectors

Previously missed (4)

In code that hasn't changed since last review

Resolve default manifest model references for imperative property access

javascript/​frameworks/​ui5/​lib/​advanced_security/​javascript/​frameworks/​ui5/​UI5DataModels.qll:45

Default manifest-model references cannot pass this predicate: getModel() has no model name, and getResolvedModel() only follows an explicit setModel call. The existing LocalModelSetPropertyStep/LocalModelGetPropertyStep therefore skip calls such as this.getView().getModel().setProperty("/value", input) for the newly modeled auto-created model, so imperative reads/writes never connect to its declarative bindings. Resolve unmatched default references to the owning DefaultManifestJsonModel and add path-specific flow steps and regression cases for setProperty and getProperty.

Resolve inherited control models before applying binding mode changes

javascript/​frameworks/​ui5/​lib/​advanced_security/​javascript/​frameworks/​ui5/​UI5DataModels.qll:430

Checking only for a setModel call on the exact receiver misclassifies inherited control models. For example, if an ancestor control has a local model, this.byId("child").getModel().setDefaultBindingMode(OneWay) changes that inherited local model, but this predicate associates the call with the manifest model and can disable two-way flow for unrelated manifest bindings elsewhere in the component. Resolve the reference through the same control/view/component hierarchy used by resolveModel before applying its binding mode.

Support object-form JSONView aggregation bindings

javascript/​frameworks/​ui5/​lib/​advanced_security/​javascript/​frameworks/​ui5/​UI5View.qll:176

This only recognizes an items property whose value is directly a binding string. A real JSONView aggregation binding is object-shaped (for example, "items": { "path": "/groups", "template": { ... } }), so Bindings.qll creates no JsonBindingPath for items and descendants in the template never acquire the collection context. The added fixture masks this by using a nonstandard string items property with controls in a separate content array. Support object-form aggregation bindings and test with a valid path/template JSONView so nested relative paths work in deployed applications.

Fix reversed location parameter order in UI5Control.hasLocationInfo

javascript/​frameworks/​ui5/​test/​models/​json_controls/​jsonControlTest.expected:2

These expected locations have line and column positions swapped: the outer object spans 4:5–14:5, and the nested object spans 9:19–12:9 (the file has only 16 lines, so 19:9–9:12 cannot be valid). This exposes the reversed integer parameters in UI5Control.hasLocationInfo; accepting these results preserves incorrect locations for JSON controls and downstream alerts. Change that predicate to the standard (startline, startcolumn, endline, endcolumn) order and regenerate this expected file.

[Copilot]

Copilot review overview

🔵 Needs a closer look

JavaScript-view control model overrides are omitted from the new model hierarchy resolution.

Review effort: Balanced
Findings: None

Previously missed (1)

In code that hasn't changed since last review

Include JavaScript-view controls in model resolution hierarchy

javascript/​frameworks/​ui5/​lib/​advanced_security/​javascript/​frameworks/​ui5/​UI5DataModels.qll:865

JavaScript-view controls are omitted from this hierarchy. JsViewBindingPath.getControlDeclaration() returns an asJsControl(), so a setModel(...) on that control is never considered by getControlSetModelCall or hasDefaultModelOverride; bindings can therefore resolve to a view/component/manifest model instead of the closer control model. Include the JS control itself here (and any representable JS-control ancestry).

[Copilot]

Copilot review overview

🔵 Needs a closer look

Root-array path joining and binding-level mode overrides can currently produce incorrect XSS flow results.

Review effort: Balanced
Findings: None

Previously missed (2)

In code that hasn't changed since last review

Avoid double slash when resolving relative paths from root arrays

javascript/​frameworks/​ui5/​lib/​advanced_security/​javascript/​frameworks/​ui5/​UI5View.qll:55

A valid root-array aggregation uses items="{/}". For a relative child such as {value}, this concatenation produces //value instead of /value, so path-specific model flow no longer matches other bindings to the same runtime property. Normalize the separator when the enclosing absolute path is /.

Honor effective binding mode for reverse edges and source classification

javascript/​frameworks/​ui5/​lib/​advanced_security/​javascript/​frameworks/​ui5/​dataflow/​FlowSteps.qll:18

This reverse edge uses only the model's default mode. A property binding can explicitly set mode: 'OneWay' or OneTime, overriding a TwoWay model; such a binding is still connected back to the model here and is also classified as a remote source in RemoteFlowSources.qll, producing false-positive XSS flow. Compute the effective mode per binding and apply it both here and when classifying source controls.