Asgard Magic Importer
Make report writing great again. Copy a drafted finding, click once, and every field lands in the ███████████ Asgard New Finding form — Overview, Background, Recommendations, References, Affected Items, and each Evidence record saved individually.
██ files hidden
Download
- Chrome 110+, Edge, Brave, or any Chromium browser
- Developer mode enabled
- No Node, npm, or build step
Please provide the password by simply typing it on your keyboard to access the extension.
(Hint: Timelog)
Internal tooling — not on the Chrome Web Store. It is loaded unpacked on purpose so you can
read every line before granting it access to
█████████████████████.
Install in your browser
-
1
Download and unzip
Unzip
asgard-magic-importer.zipsomewhere you'll keep it — the browser loads the folder from disk every launch, so don't delete it afterwards. -
2
Open the extensions page
Chromechrome://extensionsEdgeedge://extensionsBravebrave://extensions -
3
Turn on Developer mode
Toggle it in the top-right corner of that page.
-
4
Load unpacked
Click Load unpacked and select the unzipped
asgard-magic-importerfolder — the one containingmanifest.json, not its parent. -
Done
The wand icon appears in your toolbar. Pin it if you want the popup; the floating button shows up on its own once you open a finding form.
Updating later? Replace the folder contents, then hit Reload on the extension card. If you moved the folder, remove the entry and load unpacked again.
How to use
-
1
Copy your drafted finding
Select the whole finding and press
Ctrl+C. The extension only ever reads your clipboard — it never opens or touches your notes app. -
2
Open the Asgard New Finding form
Keep that tab active. A green Import Clipboard button appears at the bottom-right by itself.
-
3
Click it and watch
A progress bar tracks the real position in the plan and names the record being written. The results log lists every field and record, then closes itself after 10 seconds — hover it to keep it open, or hit copy to grab the log.
What goes where
| Your draft | Asgard |
|---|---|
| Title · Category · CVE/CWE · Severity · CVSS4 | Overview fields |
| Description | Details → Background, one record per paragraph |
| Recommendations | Details → Recommendation, one record per item |
| References | Evidence tab → Reference, one record each |
| Evidence · Steps to Reproduce · Request / Response / Result <ID> · Note | Evidence — one record each, in the order you wrote them, headings kept. Evidence prose splits per paragraph. |
| Affected | Additional → Affected Items |
Every Evidence record is saved individually with Type = Text,
and only the last one ends with a blank line. Repeated
Request 1 / Response 1 / Request 160 / Response 160 pairs each get
their own record instead of collapsing into one.
Format your finding like this
The importer reads your draft by its section labels, so the closer your finding sticks to the shape below, the less it has to guess. Put each label on its own line ending in a colon, with its content underneath:
Optional, and each may repeat with an ID —
Request 1, Response 1,
Request 160 — every one becoming its own Evidence record:
Example report Stored XSS · click to expand
Title:
Stored Cross-Site Scripting (XSS) in User Profile Bio
Severity:
High
Category:
Input Validation / Cross-Site Scripting (XSS)
CVE/CWE:
N/A CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-Site Scripting')
CVSS4:
AV:N/AC:L/AT:N/PR:L/UI:R/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:U - 4.6
Affected:
https://example.com/profile/edit
Description:
Stored Cross-Site Scripting (XSS) vulnerabilities occur when an application accepts untrusted user input without proper validation or sanitization and stores it permanently in a database or data store. This data is later retrieved and rendered to other users or administrators without appropriate contextual output encoding.
In this instance, the application permits authenticated users to inject arbitrary JavaScript payloads into their profile biography field. When another user or administrative account views the affected profile, the malicious script executes within the context of their active browser session.
Successful exploitation of this vulnerability can allow an attacker to hijack user sessions, steal session cookies, perform unauthorized actions on behalf of the victim, or deface application pages viewed by other users.
References:
https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
Recommendations:
• Implement robust contextual output encoding for all user-supplied data prior to rendering it within the HTML document (e.g., HTML body encoding, attribute encoding).
• Enforce strict input validation on the server side using allow-lists for expected input formats and character sets.
• Deploy a secure Content Security Policy (CSP) headers configuration to restrict the execution of unauthorized inline scripts and limit script sources.
Evidence:
During testing, inserting a test script payload into the profile biography field was successfully accepted and stored by the backend. When navigating to the public-facing profile page, the payload executed automatically in the browser, demonstrating stored execution across user sessions.
Steps to Reproduce:
1. Log in to the application using a standard user account.
2. Navigate to the profile settings page (/profile/edit).
3. Input a test payload (e.g., <script>alert(document.cookie)</script>) into the "Biography" field and click Save.
4. Log in as a separate user or administrator and navigate to the modified user's public profile page.
5. Observe that the script executes immediately, triggering an alert dialog containing session data.
Request:
POST /profile/edit HTTP/1.1
Host: example.com
Cookie: session_id=abc123xyz
Content-Type: application/x-www-form-urlencoded
bio=%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E&submit=Save
Response:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
<html>
<head><title>Profile Updated</title></head>
<body>
<div class="bio-section">
<script>alert(document.cookie)</script>
</div>
</body>
</html>
Labels are matched case-insensitively and a missing section is simply skipped, so a shorter finding still imports — you just get fewer records.
Prefer the keyboard? Alt
+ Shift
+ N
runs the same import. If Chrome blocks clipboard access, the panel offers a box to paste into instead.
How it detects things
The page
The content script runs only on █████████████████████ and
mounts the floating button only while the URL is a
/finding/form/ route. Asgard is a single-page app, so the
route is re-checked continuously and the button re-attaches if React removes it.
Your sections
Headings are matched by keyword plus an optional ID or annotation, so
input fields is recognised.
A heading must both start with a keyword and end with a colon, so
Host: or Content-Type:
inside a captured request are never mistaken for one.
The form controls
Each Evidence record opens its own + Add, selects Type = Text from inside that dialog only, pastes, and saves before the next one starts. Severity is normalised too — Informative and Informational both select Info.
Bounded by your clipboard
The whole plan is computed from the copied text before the page is touched, and the importer refuses to add more records than that plan — so it cannot keep going after your content has been imported. There is a time limit as a backstop.
Always review the finding before saving it in Asgard. The importer fills the form; it does not submit the finding for you.