You seem confused the concepts of Same Origin Policy, CSRF, and what can be done with HTML forms; and you aren't alone! The Web a complex mix of many technologies developed without sufficient security evaluation, with subtly different policies.
An interactive website can provide different content to different users, using tokens sent by the browser and sometimes the IP address. The Same Origin Policy is the foundation of the security of websites with access control, but it is neither simple, nor well understood, nor easy to explain, nor easy to reason about.
The Same Origin Policy doesn't restrict the inclusion of elements from another origin, such a images, in a page; but the site won't be able to "see" the images (but it can detect its size, an exception to the simplified policy as stated above).
The Web model, since the old times (remember the NCSA Mosaic browser?), does not restrict cross-site requests:
Simply including an IMG element will cause a GET request; if the browser has any HTTP cookies in it's current "cookie jar", the request will be made with these cookies (also, HTTP login/password authentication will be sent if the browser has stored some - but who used HTTP authentication today?). "Cookies" (not just HTTP cookies) can be used to prove a level of authorisation. The HTTP GET request will be "authenticated" by the browser. (Also, the request will come from the IP address of the user, and IP addresses are something used for access control.)
An HTML FORM element can any domain for its submit URL. It can use either the GET or the POST method.
Web pages can also be framesets with frames from different origins, or use inline frames (IFRAME element). In both cases, the outer page cannot mess with the content of inner page: it can't read it, it can't modify its elements. But the outer page can be hostile and misrepresent the inner page, by providing a ridiculously small area, by hiding borders, confusing the user about what is what, thus creating security issues because the user only see one origin in the address bar. Ad-hoc defenses were designed after the fact (as usual, lack of complete security analysis for web technologies).
There are exceptions to the policy as stated above: a Web page can import scripts (JS) and style sheets (CSS) from other domains. These HTTP objects must have the appropriate MIME types, or the browser must block the use of the resource (not doing so would be a violation of the SOP). The scripts will run in the security context of the importing website, but they were retrieved by the web browser with the cookies of the domain hosting the script. This means that you cannot include a secret in a script or a CSS (protected by origin).
And HTTP cookies don't even follow a simple "Same Origin" model. HTTP cookies have their own special, potentially unsafe rules for setting cookies on other origins: cookies can be scoped by "origin" or domain (like *.example.com), and be "secure" or not, "HTTP-only" or not... (Lack of proper security analysis at design time, again.)
HTTP cookies carry auth token linked to a domain, not a particular window; the web browser uses it for any request on the domain (it is called "ambient authority"). By default (that is unless some obscure Google Chromium command line option is used) any other website could try to abuse this authority. CSRF tokens are a defense against that.
CSRF are not a defense against a broken web browser, such as the Android Web Browser (not to be confused with Google Chrome!) before version 4.4 (see CVE-2014-6041).
About authority by cookies, see also http://tools.ietf.org/html/rfc6265#section-8.2
8.2. Ambient Authority
security vulnerabilities because some user agents let remote
parties issue HTTP requests from the user agent (e.g., via HTTP
redirects or HTML forms). When issuing those requests, user agents
attach cookies even if the remote party does not know the contents
of the cookies, potentially letting the remote party exercise
authority at an unwary server.
Although this security concern goes by a number of names (e.g.,
cross-site request forgery, confused deputy), the issue stems from
cookies being a form of ambient authority. Cookies encourage server
operators to separate designation (in the form of URLs) from
authorization (in the form of cookies). Consequently, the user agent
might supply the authorization for a resource designated by the
attacker, possibly causing the server or its clients to undertake
actions designated by the attacker as though they were authorized by