Syslifters / sysreptor

A customizable and powerful penetration testing reporting platform for offensive security professionals. Simplify, customize, and automate your pentest reports with ease.
https://docs.sysreptor.com
Other
1.48k stars 141 forks source link

Referencable Finding IDs #352

Open jgirlich-iteratec opened 1 week ago

jgirlich-iteratec commented 1 week ago

We assign IDs to our findings so they can be referenced inside the report like this: (see Finding 24-13:12) or even in other reports Finding 24-7:10 was fixed in this release.

I would love to have a way in sysreptor to generate a unique ID for each finding and then use that ID to reference a finding by it. As of now we generate it like this in the template:


        <h2 :id="finding.id" class="in-toc numbered">
            Finding: {{ report.report_number }}:{{ findings.indexOf(finding) + 1}} - {{ finding.title }}
        </h2>
-```
MWedl commented 1 week ago

Currently that's a bit tricky to achieve. Internally, SysReptor uniquely identifies findings via UUIDs. These UUIDs are available via finding.id and can also be used to reference findings in markdown via [](#finding-id). The design's CSS can be used to customize the appearance of references. Changing the reference format, however, is tricky to get right. Please check if following code works for you.

<div v-for="(finding, findingIndex) in findings">
  <h2 
    :id="finding.id" 
    class="in-toc finding-title" 
    :data-finding-prefix="`Finding 24-7:${ findingIndex + 1 }`" 
    :data-toc-title="`Finding 24-7:${findingIndex + 1} - ${finding.title}`"
  > - {{ finding.title }}</h2>
/* copy content from attribute to ::before pseudo-element to be able to reference it via targe-text() */
.finding-title::before {
    content: attr(data-finding-prefix);
}

/* prepend finding number to references */
.markdown .ref.ref-heading::before {
    content: target-text(attr(href), before);
}
/* hide title in references */
.markdown .ref.ref-heading .ref-title {
    display: none;
}

Remark about finding number generation: using the finding index to generate finding numbers might not be optimal. For example when the order of findings changes or a new finding is inserted (e.g. during a retest), the finding index and thus the finding number changes. When findings number just have to unique inside a single report that is not updated once the PDF is generated and sent to the customer, this should be fine.