CODEWITHSUNDEEP
phpjquerycross-domainjsonp
mike
mike

Reputation: 8141

Securing JSONP?

I have a script that uses JSONP to make cross domain ajax calls. This works great but my question is, is there a way to prevent other sites from accessing and getting data from these URL's? I basically would like to make a list of sites that are allowed and only return data if they are in the list. I am using PHP and figure I might be able to use "HTTP_REFERER" but have read that some browsers will not send this info.... ??? Any ideas?

Thanks!

Upvotes: 9

Views: 805

Answers (5)

B.F.
B.F.

Reputation: 477

Working with importScript form the Web Worker is quite the same as jsonp. Make a double check like theAlexPoon said. Main-script to web worker, web worker to sever and back with security query. If the web worker answer to the main script without to be asked or with the wrong token, its better to forward your website to the nirvana. If the server is asked with the wrong token don't answer. Cookies will not be send with an importScript request, because document is not available at web worker level. Always send security relevant cookies with a post request.

But there are still a lot of risks. The man in the middle knows how.

Upvotes: 0

Xandl
Xandl

Reputation: 162

How about using a cookie that holds a token used with every jsonp request? Depending on the setup you can also use a variable if you don't want to use cookies.

Upvotes: 0

rob_james
rob_james

Reputation: 1322

I'm certain you can do this with htaccess -

Ensure your headers are sending "HTTP_REFERER" - I don't know any browser that wont send it if you tell it to. (if you're still worried, fall back gracefully)

Then use htaccess to allow/deny access from the right referer.

# deny all except those indicated here
order deny,allow
deny from all
allow from .*domain\.com.*

Upvotes: -1

easyjo
easyjo

Reputation: 734

Do you have access to the servers/sites that you would like to give access to the JSONP?

What you could do, although not ideal is to add a record to a db of the IP on the page load that is allowed to view the JSONP, then on the jsonp load, check if that record exists. Perhaps have an expiry on the record if appropriate.

e.g.

http://mysite.com/some_page/ - user loads page, add their IP to the database of allowed users

http://anothersite.com/anotherpage - as above, add to database

  • load JSONP, check the IP exists in the database.
  • After one hour delete the record from the db, so another page load would be required for example

Although this could quite easily be worked around if the scraper (or other sites) managed to work out what method you are using to allow users to view the JSONP, they'd only have to hit the page first.

Upvotes: 0

theAlexPoon
theAlexPoon

Reputation: 342

There really is no effective solution. If your JSON is accessible through the browser, then it is equally accessible to other sites. To the web server a request originating from a browser or another server are virtually indistinguishable aside from the headers. Like ILMV commented, referrers (and other headers) can be falsified. They are after all, self-reported.

Security is never perfect. A sufficiently determined person can overcome any security measures in place, but the goal of security is to create a high enough deterrent that laypeople and or most people would be dissuaded from putting the time and resources necessary to compromise the security.

With that thought in mind, you can create a barrier of entry high enough that other sites would probably not bother making requests with the barriers of entry put into place. You can generate single use tokens that are required to grab the json data. Once a token is used to grab the json data, the token is then subsequently invalidated. In order to retrieve a token, the web page must be requested with a token embedded within the page in javascript that is then put into the ajax call for the json data. Combine this with time-expiring tokens, and sufficient obfuscation in the javascript and you've created a high enough barrier.

Just remember, this isn't impossible to circumvent. Another website could extract the token out of the javascript, and or intercept the ajax call and hijack the data at multiple points.

Upvotes: 6

Related Questions