0

With standard XSSI, an attacker can include a remote script which contains user-bound secrets across origins, and then read them out.

I have an endpoint which returns sensitive Javascript code, but the request to fetch it is POST-based (the endpoint doesn't accept GET requests).

Is this secure? I assume that it is, and that XSSI isn't possible. But maybe there is some 3xx redirect trick or something else which can be used to exploit this?

6
  • I don't see how the VERB would impact XSSI.... I mean, its just about tricking the client to run your script... the URI is not requered to make that attack possible..
    – LvB
    Commented Nov 23, 2023 at 16:02
  • @LvB The important part of XSSI is including the script cross-origin. That usually/always happens via <script src="https://vuln.com/vuln.js"></script>, so it relies on the endpoint being served via GET (of course it could be included via CORS, but that wouldn't be an XSSI issue). I was just wondering if there's some weird browser behavior or trick to still get XSSI to work with POST.
    – tim
    Commented Nov 23, 2023 at 17:04
  • But…. That would mean your service is serving the bad JavaScript…. Otherwise the attacker would just fuse a GET serving one…. If I understand you correctly.
    – LvB
    Commented Nov 23, 2023 at 18:49
  • the (potentially vulnerable) webpage is returning the javascript. So the attacker doesn't have a choice in method when communicating with that server. It has to be POST.
    – tim
    Commented Nov 23, 2023 at 18:57
  • How does Your web page load the POST retrieved JavaScript? And if that server is the one sending the malicious script tag. How is it executed?
    – LvB
    Commented Nov 23, 2023 at 20:06

0

You must log in to answer this question.

Browse other questions tagged .