1

My webpage has a need to fetch data in a client-side-initiated way from domains which may (sometimes**) be untrusted/attacker-controlled.

Does JavaScript allow to [safely] fetch data* from a domain which may be untrusted or attacker-controlled?

If so, what function is this?


Clarifications / Addendums / "inb4"s / P.S.:

*The data fetch protocol/format is not [yet] defined; not even as far as HTTP GET vs POST. I have no preference on the data format and may choose+implement it as required/appropriate, inclusive even of plaintext/delimited formats. There is no requirement to use JSON.

**Technically, the domains (which may be arbitrary/user-defined!) must sometimes be loaded over HTTP; this threat model is isomorphic to fetching data from adversarial servers, especially in the context of roaming non-VPN'd network connections. (And, yes, the safe-handling of said untrusted data afterwards is out-of-scope of this question)

XY Problem "X": the driving project here is a web browser homepage/app which will load content (ranging from preferences and trivial widgets to outright content) from sources which may be user-controlled and may (at the user's option) reside on even non-ICANN domains (such as local domains, OpenNIC domains, etc.) It is entirely within-scope and expected/acceptable that some of this content will only be served via TLS, and may serve a variety of purposes ranging from "canaries" (of both MITM presence, and mere network configuration checking) to outright location-specific data. TLS connections may or may not be available due to the aforementioned suite of reasons [that the domains are not pre-defined]; and there is content which must/ought/will be loaded even despite this case.

This is not a duplicate of #29022794. I have no requirement to use JQuery, and that question only asks whether $.getJSON() is safe to use on untrusted URLs (which, a. it does NOT seem to be; and b. even if it were, this question would be asking after the underlying function [that JQuery is calling], rather than asking how to use JQuery per se).

  • Maybe you can set up a server which will you'll trust of course. Your server then can verify if the payload of the untrusted party is 'good' or 'bad'... according to your standards. – p3sn Oct 30 '19 at 15:17
  • Whenever I read questions starting with "Can Javascript safely..." I already know the answer. – connexo Oct 30 '19 at 15:18

2 Answers2

1

Penciling in a circumstantial yes: XMLHttpRequest appears to be safe to call on untrusted domains.

Justifications:

See OWASP's page on AJAX vulnerabilities:

  • Makes no mention of threats posed to a client by [this sort of] maliciously crafted server response; the only client-side risk(s) listed are injections of one sort or another.

See also this similar question on Security Stack Exchange

  • OP's very question (whether it is safe to parse an XMLHttpRequest to an attacker-controlled server as JSON) necessarily assumes that it's safe to receive such.
  • Two users commented several times on the issue, discussing the implications of parsing said response, and at no point questioned this underlying assumption, only commenting on similar XSS injection attacks to those discussed by OWASP.
    • ThoriumBR (>5y member, 99.8th-percentile 2019 Information Security Stack Exchange user)
    • Ry (>8y member, Stack Overflow moderator)

While it's very hard to "prove" a negative, especially with security issues, the fact that there's an ocean of content online discussing risks involved in parsing potentially malicious responses (XSS injection prevention), dealing with the risks to the servers of such (CORS), etc.; without, apparently, even one scrap of discussion on this, means it's probably not one of the risks.

Community
  • 1
  • 1
-1

No. You cannot do it in a browser due to CORS security protection. If you ever found one, it is a bug and the browser will fix it.

You can, however, do it on server side with fetch API

Dennis C
  • 24,511
  • 12
  • 71
  • 99
  • (I tagged this question with the client-side `javascript` rather than the server-side `node.js`, and [I'm not particularly considering Node, either](https://itnext.io/no-way-to-prevent-this-says-only-development-community-where-this-regularly-happens-8ef59e6836de), so I'm not sure why you'd have mentioned it [rather than e.g., PHP](https://web.archive.org/web/20191030151711/https%3A//w3techs.com/technologies/overview/programming_language/all);) but, more to the point: this project will hopefully/ideally be useable over "dumb" HTTP servers as well as simply local files. – JamesTheAwesomeDude Oct 30 '19 at 15:43
  • That page on CORS looks quite relevant, though preliminarily it's looking like `You cannot do it in a browser due to CORS` is *the opposite of* the case: “Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to tell browsers to give a web application running at one origin, access to selected resources from a different origin…These are the same kinds of cross-site requests that web content can already issue” ([Mozilla](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS)) – JamesTheAwesomeDude Oct 30 '19 at 15:46
  • but, more specifically, "CORS" is just *the HTTP header security procedures around* cross-domain requests; what I am asking about is *the JavaScript client functions* to execute such; specifically, whether they allow a page on domain A to get *data* from domain B (with webmaster B's consent), without giving webmaster B *code execution access* on page A. – JamesTheAwesomeDude Oct 30 '19 at 15:53
  • @JamesTheAwesomeDude - Do you expect other involved domains to grant you CORS allowance? – PM 77-1 Oct 30 '19 at 16:06
  • @PM77-1 the "other involved domains", which will be serving a to-be-defined data structure, over a to-be-defined HTTP method, will certainly be able to implement any to-be-defined HTTP headers deemed necessary. – JamesTheAwesomeDude Oct 30 '19 at 16:17
  • but the scope of this question was *never the access control methods* to allow server B to serve data to A; the scope of this question was *how to prevent server B from having execution-control on page A, within the context of XDR*. If there's any way I could have been clearer about that in my question, please let me know. – JamesTheAwesomeDude Oct 30 '19 at 16:20