-
☆ A M B ☆
- 24,524 Posts
What would be the recommended way to handle security in an external .php file used for AJAX processes?
Specifically, I'm using a very nice jQuery-based file browser called leFinder. In the javascript initialization, the path to the .php connector is specified. Any web page from anywhere with the path to this file can run the file browser. I've added the code to the connector to load an instance of MODx, but I'm not sure where to go from there to deny access to any javascript that isn't on a page from the site.
If it's Revolution, you can put the file under the core directory and move the core outside the web root.
-
☆ A M B ☆
- 24,524 Posts
Not everybody will even be able to have their core outside the web root. My question specifically refers to how to add something to the external .php file so that it can only be run from a MODx page request. I've solved my immediate problem by putting the code into a snippet in a protected resource, but that still doesn't answer the root question of how best to secure an external executable file. The Manager solves this by checking for user status or some such MODx-generated value, but external AJAX processors or third-party add-ons won't have access to these values.
There have been security issues caused by third-party add-ons with insecure files; a recent example that comes to mind involves phpthumb. And there were some problems with AjaxSearch some time ago. That's the sort of thing I want to learn how to avoid in my own code or secure in third-party application.
-
☆ A M B ☆
- 24,524 Posts
That would do the job, yes. I was also considering some way to establish a value that has to be passed to the .php file, but since these processors are called from the javascript any "secret" value (such as the site ID or session name) passed on via the AJAX request would be clearly visible in the page's HTML, which is something one certainly doesn't want to do.
I was especially wondering if there were some way to have the external .php file check the SESSION. But I suppose that a really determined intruder could spoof that in some way as well. So actually protecting the file itself does look like the best way to secure these things.
Your controller-connector method (making a snippet to connect to the controller) works better than making the AJAX application's controller into a snippet simply because it's upgrade-safe. Making the controller itself into a snippet does secure it, but it means that any time you want to upgrade the application you have to re-write your snippet.