Javascript Ajax (More)

How do you link to an Ajax page?

(or indeed to any Javascript-modified page, Ajax or not)

If the page changes without changing the URL, it can be difficult to give the user a URL to link to, if they want to bookmark / link to a certain configuration of the page.
Changing the URL without refreshing page
Manipulating the browser history
The problem is: Not enough to change URL. This URL needs to mean something to the Javascript when you re-load it. On load, Javascript must parse URL and go to that configuration.
Examples:
1. Google Maps. Make 5 drag moves West. Page contents change 5 times. URL changes 5 times. But not actual 5 new page loads.
2. GeoHive. Does not change URL. Cannot link to any map view.

Security - Same origin policy

XMLHttpRequest Level 1 (XHR)
Same origin policy - Basic security scheme is that JS must make Ajax requests only to server it came from.
Why is this needed?
Consider my site:
- Login to ancientbrain.com (AB).
- Then client sends session credentials to AB with each request.
- Pages can use JS to make Ajax calls to do things, such as Edit, Save and Delete resources.
- Each request is allowed since it comes with session credentials.
So can you set up a 3rd party web page to make "delete" JS Ajax calls to AB?
- If JS on third-party sites could make Ajax calls, then yes you could.
- User clicks on site, JS runs, makes Ajax "delete" call, sent to AB with my session credentials (because I am logged in to AB and have the correct session credentials). So the "delete" call works. Simply clicking on the rogue site means my AB files are deleted.
- Same-origin policy stops this. Ajax call to AB can only be made by JS on AB webpages.
- Same-origin policy is essential for logins. Without it, can't have safe logins and Ajax commands to do things.
More on my example:
- My site has a further twist: I actually allow users upload JS. You run pages with other users' JS in it. You do that anyway on the Web, but here I am allowing it on ancientbrain.com, where you are logged in.
- So how do I stop that JS making server calls to Delete your files?
- Answer: Two servers. Logged in pages run on 1st server ancientbrain.com. User-submitted pages run on 2nd server run.ancientbrain.com and cannot make Ajax calls to 1st server.

Elsewhere - JSONP as workaround to same-origin policy

JSONP - Workaround to same-origin policy using JSON.
Bit of a hack. Server must co-operate. JSON format only.
More suitable for distributing feeds of content than for making logged in read/write calls.
JSONP is not using XMLHttpRequest at all. It is just old-fashioned "Load some JS through <script"

Security - CSRF

Cross-site request forgery (CSRF)
How does this attack work?
PHP endpoints:
- Consider a site with login, like ancientbrain.com (AB)
- Each user logs in using a PHP session.
- The server has PHP programs to handle the various read-write Ajax JS requests that pages make.
- These PHP "endpoints" can be addressed directly with a HTTP link like:
```
 https://ancientbrain.com/delete.file.php?file=myfile.txt 
```
- The JS normally makes an Ajax call to this URL. But do not need to use any JS. Could call the URL directly with HTTP.
- Now the call will not work without my session credentials. So the hacker cannot make the call himself.
CSRF attack: Trick the victim into making the HTTP call.
- Hacker sets up a link (say in email) for victim to click. When clicked by the victim it sends HTTP request to PHP to Delete files. Victim is logged in. Files are deleted.
- In fact, on ancientbrain.com it is trivially easy to get user to click your links. This happens all the time. It is how the site is designed - you interact with uploaded programs.
How to stop CSRF:
- What we want: Delete request has to come from a Delete button on the AB page. It cannot come independently. How to do this?
- Solution: CSRF tokens. Logged in pages are sent secret tokens (e.g. long ID numbers) in the JS. Token is unguessable - must be different for each user, and change regularly. These tokens are returned when JS on page makes Ajax call. The HTTP link the hacker sets up to click does not have the token and so does not work.
- If hacker studies the site he will see the tokens, but his tokens will be different to yours, so his tokens will not work on the link you click.
- Need two unique IDs: CSRF token and Session ID. The latter is not enough, since that is always sent to server when the logged-in user clicks a link.

CORS - Cross-origin Ajax

XMLHttpRequest Level 2 (XHR2)
Cross-origin resource sharing (CORS) - Standard for allowing controlled cross-origin Ajax.
Server must co-operate. Server returns HTTP response headers.
(e.g. PHP can output a response header before payload.)

Allow one site:

Access-Control-Allow-Origin: http://allowedsite.com

Allow all sites:

Access-Control-Allow-Origin: *

CORS vs JSONP. XHR2 with CORS probably better solution than JSONP. Can retrieve any data format. Better error handling.
Need server to send headers though. e.g. At time of writing, Flickr does not.

CORS proxies

Even if the server does not cooperate, you can use a CORS proxy like corsproxy.io to fetch arbitrary resources off the Internet:

var url  = ...   // some resource on a normal website  

var curl = "https://corsproxy.io/?" + encodeURIComponent ( url );   // CORS-enabled URL 

$.get ( curl, function ( data ) 
{
  // we have got the data 
});

Basically, CORS and same-origin policy are about the type of client, not about the servers.
You can wget the resource from the site, no problem.
But you cannot fetch it from non-site JS in your browser, because otherwise there are issues with your browser sending site credentials in a transaction controlled by non-site JS.
The browser could at any time send calls to the server with credentials and the server would obey them. It would not know where they came from. But the browser won't do this. People use browsers that are safe.
The browser asks the server if non-site JS call is ok. If not, it won't do it.
This is enforced by the browser, not by the servers. People use browsers that are safe.
Same origin enforcement is because of the very specific environment of the browser, where you are running JS written by other people all the time, without knowing what it is doing. This is not the same environment as, say, running a trusted program on the command line.
This is why you can get around it with running the HTTP request from the command line or from another environment like the CORS proxy.
So the CORS proxy can make a regular HTTP call like wget. No credentials are sent.
Your browser will send no credentials to the CORS proxy. It just looks like a normal site.