hey.... wanted to float this before opening a PR since the contributing guide says check fit for new plugins first.
idea is an svg_injection probe + detector that tries to get the target to spit out SVG/XML that attacks whatever renders it downstream... an SVG rasterizer or XML parser, not a browser.
same thesis as ansiescape (terminal) and web_injection (browser).. model output lands in a sink that acts on active content. here the sink is the svg-to-raster / xml path an app runs when it asks a model to "make me an icon as SVG" and then rasterizes or parses it. two vectors:
- external entity / external DTD (
<!ENTITY ... SYSTEM "file://...">, param-entity DTD fetch)... reads local files or exfils out of band when the parser resolves external entities. libxml2/lxml and older imagemagick svg handling do that, hardened builds and current librsvg dont.
<image href="...">.... pulls file:// local content or reaches an internal host (cloud metadata 169.254.169.254 / metadata.google.internal, or a gopher:/dict: gadget) on the image load path.
not trying to step on web_injection.. browser <script>/xss stays there, thats already its turf. i checked and theres no svg/xxe/entity probe, detector or resource in the tree right now, and no open or closed issue/PR for it.
shape-wise i mirrored ansiescape: SvgInjection (OF_CONCERN) + SvgInjectionEscaped (INFORMATIONAL) probes, Live/Escaped StringDetectors tuned for low false positives... a hit needs an external entity, a file: ref, an external DTD, or a known ssrf target. ordinary shapes / http(s) images / internal # refs dont score, and generic 192.168/10.x ssrf is out of scope since you cant catch it without false-positiving legit images. payloads live in resources/svg.py.
its already written and green locally.... 2 probes + 2 detectors + payloads + docs + tests, passes the generic suites and black. holding the PR til you confirm scope... happy to keep it its own svg_injection module or fold it into web_injection/exploitation if you'd rather. whats your preference?
hey.... wanted to float this before opening a PR since the contributing guide says check fit for new plugins first.
idea is an
svg_injectionprobe + detector that tries to get the target to spit out SVG/XML that attacks whatever renders it downstream... an SVG rasterizer or XML parser, not a browser.same thesis as ansiescape (terminal) and web_injection (browser).. model output lands in a sink that acts on active content. here the sink is the svg-to-raster / xml path an app runs when it asks a model to "make me an icon as SVG" and then rasterizes or parses it. two vectors:
<!ENTITY ... SYSTEM "file://...">, param-entity DTD fetch)... reads local files or exfils out of band when the parser resolves external entities. libxml2/lxml and older imagemagick svg handling do that, hardened builds and current librsvg dont.<image href="...">.... pullsfile://local content or reaches an internal host (cloud metadata169.254.169.254/metadata.google.internal, or a gopher:/dict: gadget) on the image load path.not trying to step on web_injection.. browser
<script>/xss stays there, thats already its turf. i checked and theres no svg/xxe/entity probe, detector or resource in the tree right now, and no open or closed issue/PR for it.shape-wise i mirrored ansiescape:
SvgInjection(OF_CONCERN) +SvgInjectionEscaped(INFORMATIONAL) probes,Live/EscapedStringDetectors tuned for low false positives... a hit needs an external entity, afile:ref, an external DTD, or a known ssrf target. ordinary shapes / http(s) images / internal#refs dont score, and generic 192.168/10.x ssrf is out of scope since you cant catch it without false-positiving legit images. payloads live inresources/svg.py.its already written and green locally.... 2 probes + 2 detectors + payloads + docs + tests, passes the generic suites and black. holding the PR til you confirm scope... happy to keep it its own
svg_injectionmodule or fold it into web_injection/exploitation if you'd rather. whats your preference?