SysReptor Documentation

While not officially supported by Vue, you can define helper functions, variables, and computed properties within a template by assigning values to them inside inline JavaScript expressions. This is typically done at the start of a template inside a hidden element (e.g., <div v-show="false">).

Common patterns:

• Helper Functions: {{ myFunc = (arg) => arg + 1 }}
• Variables: {{ myVar = 'some value' }}
• Computed Properties: {{ myComputed = computed(() => ... ) }}

Warning: This is a workaround. Use it sparingly for logic that is difficult to express with standard template syntax, such as complex multi-language translation tables.

<div v-show="false"> 
  <!-- Simple helper functions -->
  {{ helperFunction = function() {
    return report.title + ' processed by helper function';
  } }}
  {{ calculateCustomScore = (finding) => finding.exploitability * finding.impact }}

  <!-- Variables and computed properties -->
  {{ helperVariable = 'Helper variable' }}
  {{ computedProperty = computed(() => report.title + ' processed by computed property') }}

  <!-- Complex helper function for translation -->
  {{ tr = function (label, options = undefined) {
    const translations = {
      'en': { example: 'Example', fallback: 'Fallback value' },
      'de': { example: 'Beispiel' },
      'fr': { example: 'exemple' },
    };
    const translationFallback = translations['en'];
    const lang = (options?.lang || document.documentElement.getAttribute('lang'))?.split('-')?.[0];

    if (!lang || !translations[lang]) {
      const msg = `Language "${lang}" not defined in the design's translation table`;
      console.warn(msg, { message: 'Translation not defined', details: msg });
    } else if (!(label in translations[lang])) {
      const msg = `Translation for "${label}" is not defined in translation table for language "${lang}"`;
      console.warn(msg, { message: 'Translation not defined', details: msg });
    }

    return translations[lang]?.[label] ?? translationFallback[label] ?? '';
  } }}
</div>
<div>
  Call helper function: {{ helperFunction() }}<br>
  Call helper function with args: {{ calculateCustomScore(report.findings[0]) }}<br>
  Use helper variable: {{ helperVariable }}<br>
  Use computed property: {{ computedProperty.value }}<br>
  Call translation function: {{ tr('example') }}<br>
</div>

SysReptor uses server-side rendering for PDF reports, which intentionally allows for template injection. To mitigate the risk of an attacker breaking out of the rendering environment, SysReptor employs sandboxing:

Cloud Environment

In the SysReptor cloud, the Chromium process is isolated in a dedicated Kubernetes pod. It receives jobs via RabbitMQ and shuts down after completion. An attacker breaking out of Chromium could prevent the pod from shutting down until a timeout occurs, but they cannot receive further rendering jobs.

Self-Hosted Environment

By default, the Chromium process runs as an isolated process within the web application's Docker container. A breakout could potentially compromise the web application.

Advanced Isolation: You can outsource the rendering process into dedicated Docker containers to improve security. This requires two additional containers:

1. Chromium
2. RabbitMQ

Note: In this custom setup, the Chromium process remains active and can receive further rendering jobs (unlike the cloud setup). This configuration is not used in the standard installation due to resource considerations.

XSS vulnerabilities are categorized by how the malicious script is delivered to the victim's browser:

• Stored XSS: The most critical type. The attacker places malicious JavaScript directly on the web server (e.g., in a database or comment field). The script executes in the browsers of any users who visit the affected page.
• Reflected XSS: The attacker lures a user to a crafted link (often via phishing). The malicious script is included in the HTTP request (e.g., as a URL parameter) and is "reflected" back to the user by the web application in its response due to insufficient validation.
• DOM-based XSS: The vulnerability exists in the client-side code rather than the server-side code. The application's JavaScript insecurely processes data from untrusted sources and writes it to the Document Object Model (DOM) at runtime. Because the processing happens in the browser, these attacks can sometimes bypass server-side security filters.