1

We're talking to a 3rd party to include some of their data on a website of ours, they want to do it either through an iframe which I don't prefer because of responsiveness reasons.

The other options they offer is the inclusion of a javscript file which will take a parameter to know what DOM element to put the results in.

Basically this gives them access to the javascript scope of our website in which if they wanted can do stuff like hide dom objects etc.

My question is, are there any security things I have to think off? Can they in their javascript for example write malacious code that in the end reads .php files from our server and get passwords from config files etc? Or is the only thing they can do DOM related?

Jebble
  • 266
  • 1
  • 11
  • 1
    well, exactly how do you "read" a php file remotely? If your server is correctly configured, hitting ANY php file via http executes the file, and you only ever see the OUTPUT of the script. If you get php source, then you really should fire whoever set up your server in the first place. And if critical config files are stored in/under your site's document root, then you should set fire to that person as you're firing them. – Marc B Dec 01 '15 at 14:40

4 Answers4

2

They could:

  1. Take control of users' cookies, including reading and modifying them.

  2. Redirect the user to any site they would like.

  3. Embed any code they would like into the page.

They can't:

  1. Access php files directly.
  2. Access any server files directly.

Javascript runs in the browser and not on the server.

HNA
  • 307
  • 1
  • 10
2

You're essentially giving them trusted XSS privileges.
If you can do something in a web browser (make posts, "browse" a page, etc), you can automate it using JavaScript. They won't be able to upload/modify your PHP files unless you (or your users) can.

To the user, you're giving them to capability to impersonate you.
To you, you're giving them the capability to impersonate users.

Community
  • 1
  • 1
Mr. Llama
  • 20,202
  • 2
  • 62
  • 115
2

Can they in their javascript for example write malacious code that in the end reads .php files from our server and get passwords from config files etc?

They can do anything in the JavaScript code you're including on your page for them that you can do in JavaScript code on that page. So that could be just about anything you can do client-side. It includes (for instance) grabbing session information that's exposed to your page and being able to send that information elsewhere.

If you don't trust them not to do that, don't include their JavaScript in your page.

We're talking to a 3rd party to include some of their data on a website of ours

Have them make that information available as data, not code, you request via ajax, and have them enable Cross-Origin Resource Sharing for the URL in question for requests from your origin. Then, you know you're just getting their data, not letting them run code.

Note that using JSONP instead of CORS will enable them to run code again, so it would have to be true ajax with CORS if you don't trust them.

T.J. Crowder
  • 1,031,962
  • 187
  • 1,923
  • 1,875
  • Sadly they refuse to grant us access from our servers and also refuse to write an API just for us. Our client wants their data on his website and simply said it's either this or an iframe. – Jebble Dec 01 '15 at 14:48
  • @Jebble: Sounds like your choices are either use an iframe, or trust them. – T.J. Crowder Dec 01 '15 at 14:51
  • That's clear, 99% trust is still not enough trust so an iframe it is. Thanks – Jebble Dec 01 '15 at 14:55
1

You shouldn't have to worry about PHP files, or config files but stealing session cookies or other XSS-style attacks could definitely be an issue.

Why can't/won't they provide data in the form of an API?

Simon Poole
  • 493
  • 1
  • 6
  • 15
  • The ajax requests have to come from their server because that server uses HTTP Access Control headers which will ignore access from our servers – Jebble Dec 01 '15 at 14:44
  • @Jebble Unfortunately, both of the methods you describe in your post will also have that issue. Easiest method is for them to add you into their ACL whitelist. – Simon Poole Dec 01 '15 at 14:48
  • I've tried that, simply not gonna happen sadly. According to them because the ajax call is made from their server and the result is simply shown in our website the access won't be declined by their server. That stealing cookies part: It's possible for them to save all the cookies from logged in users and in the end use that to pose as a logged in user correct? – Jebble Dec 01 '15 at 14:54
  • Yes, that's correct. In essence they could pose as any existing session, which obviously has major security implications. – Simon Poole Dec 01 '15 at 14:57