PHP can be exclusively accessed by SWF - php

I'm not sure how to describe this, but basically I have a PHP class file:
class HelloHello {
public function getSomeData($input_parameter){
// code to retrieve data from the database
}
public function deleteSomeData($input_parameter){
// code to delete data from the database
}
}
This class is on the server and is part of the backend that connects with a database, and it's meant to be accessed by the frontend SWF only (not to be directly accessed). I've setup Flex to read this class and access it. But how do I make sure that someone doesn't develop a script that can call this php file directly and access its methods? For example using a script to add data in a fast automated way, or use the delete method directly, ouch.
Is this a legitimate concern, or this can't be done?

If a user can view it through your flash application, the user can view it with his application. You could go through the [ugly] mess of trying to "secure" your script by introducing cookies and authentication and the like, but thats messy, and of course, it can be gone around.
Instead of trying to stop others from accessing your php file, focus on making it more secure.

If you know the url where swf runs, can't you just in PHP limit the requests to that url? Disregard all other requests.

You can secure your file by adding security and authentication. If you cannot do that (it is a public application) you should implement some techniques which can prevent specific situations: do not allow calling your script too many times per second from the same IP, add CAPTHCA in order to check that the entered data were from a human and not a machine and maybe another ones.

You could also implement a challenge-reponse security system that makes sure the client you use is actually the intended recpipient of the data. That way, you would embed a secret key into the SWF. The PHP app sends a one-time string, the client does something to it according to its secret and then sends the answer back -- which your server can validate and then continue to run.
For some basic mathematical foundations to this, there's quite some documentation online.

Related

Make a Linux user able to include PHP code but not able to view it?

User A has some PHP library files. User B needs access to the library. Is it possible permission-wise to make user B able to include the PHP file but not able to view the source code?
User A library entry file is lib.php.
User B uses lib.php in his start.php like this:
include path/to/lib.php;
However user B won't be able to view the content of lib.php or any other class files thereof.
Is this possible?
You're trying to find a way to do something that can't be done properly. Maybe in a kind of hackish, definitely dirty way.
You really should consider writing an API for your Application that contains all your logic. Then you could just handle everything else with User permission and so on, perfectly clean and state of the art.
Nobody but the API devs can look into the code, but everyone can use it based on his user permissions.
Every other method could is just to hard to handle and will cause more problems than just writing an API. It's worth the time.
Basically what you ask is not possible. The PHP interpreter needs to be able to read the file in order to include it, and if the PHP process can read it then your untrusted user can write some code that would read it in and dump it back out.
A few options you have are:
1) Use an API. Would allow you to keep you code secret as you'd only expose the API. Might take a few days work to implement though (or might not even be possible - impossible to say without knowing what you are doing), so probably not suitable in your situation.
2) Obsfucate your code. There are a number of PHP code obsfucators out there. It wouldn't stop prying eyes completely but it might be enough for your purposes.
3) Create a stub include file. If what your library includes isn't all critical to the running of the code you could create a cut-down stub library for your client to code against, then replace it with the real thing when they've done.

How to protect controller against direct access?

I'm using codeigniter with jquery and it would be nice if you explain me how to protect the controller from direct access.
For example,
I have view with that standard jquery line:
$('#handler').load('tools/get_stats');
Tools it is my controller with function for loading statistics. If I write direct in browser full address of script http://site.com/tools/get_stats, browser open, of course, that data.
How to protect direct controller access from browser ? I want my data were loaded only in view, not on controller direct access.
The CodeIgniter Input Class has a method called is_ajax_request() for this purpose.
if ($this->input->is_ajax_request())
{
//do something
}
else
{
show_error("No direct access allowed");
//or redirect
}
If you have a dedicated Ajax Controller, you can of course include this logic in the __construct() method, otherwise it may be implemented on a method by method basis within your controllers.
See:
http://ellislab.com/codeigniter/user_guide/libraries/input.html
In general you can't do it in a meaningful way due to the need to provide access and the simplicity of HTTP. Or more basically, you can't deny access to information you need to provide (in this case stateless connection info). The best initial steps are to make sure that the controller only allows access to data that the user should have access to (regardless of how they connect), rather than trying to restrict based on the easily tampered with request information.
That being said, if you have some odd reason to really chase after this, you could use some form of single use token passed with the AJAX request. You could, for instance, generate a random key, persist it somewhere (ideally just in memory in something like a hash table since there should never be a long enough delay to warrant otherwise) and pass it out with the page that will issue the ajax request. The token is passed back with the request and removed, and then that token will no longer be valid. The controller would not be able to be accessed directly since it would need a token.
This would still be able to be worked around since the process could be halted and an issued token used, but it would deter anyone just playing around with curl (so really its not worth the effort).
Long story short, you can't do this in any way that anyone couldn't work around within 10 minutes. Focus on making sure you only expose the data you want no matter how its retrieved.

AJAX security and user managment

I am working on a web application that will be hosted on a server that is "on the internet", not a LAN.
The app uses quite a bit of AJAX calls and has about 12 ajax handler files for the functions.
My question is instead of asking anybody here to write a tutorial on AJAX security, does anybody know of any good resources (website, book, whatever) that can help me with securing these files.
Right now, as long as you know the variable name its looking for you can freely get data from the database.
I was thinking maybe session validation, or something along those lines for the logged in user.
Anyways if you have any good resources I'll do the homework myself.
Thanks
AJAX calls are generally used to access web services, which is what it seems you are using them for here. If that is the case then what you need to be concerned about is the security layer that you have provided in the server-side scripting language you are using (looks like you are using PHP as per your question's tags).
The same way that you do authentication and protection for other pages on your site that aren't accessed via AJAX calls you can implement for your web services. For instance, if you require authentication for your application then you can store the user's ID in $_SESSION. From there you can check to make sure the user is logged in via $_SESSION whenever one of your web services is requested.
I've often seen AJAX calls that check the X-REQUESTED-WITH HTTP header to "verify" that the request originated from AJAX. Depending on how you're sending your AJAX calls (with XmlHttpRequest or a JS library), you can either use the standard value for this header, or set it to a custom value. That way, you can do something similar to this in PHP to check if the page was requested with AJAX:
http://davidwalsh.name/detect-ajax
if( !empty($_SERVER['HTTP_X_REQUESTED_WITH']) &&
strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest')
It is important to note that since it's an HTTP header, it can be spoofed, so it is by no means full-proof.
Here is a good resource. Securing Ajax Applications: Ensuring the Safety of the Dynamic Web
However a very simple method is to use a MD5 hash with a private key. e.g. USER_NAME+PRIVATE_KEY. If you know the users name on the website/login you can provide that key in an MD5 hash set to a javascript variable. Then simply pass the users name in your AJAX request and the REST service can just take the same private key plus the users name and compare the two hashes. You're simply sending across a hash, and the user name then. It's simple and effective. Virtually impossible to reverse too unless you have a simple private key.
So in your javascript you might have this set:
var user='username';
var hash='925c35bae29a5d18124ead6fd0771756'
Then, when you send your request you send something like this:
myService.php?user=username&hash=925c35bae29a5d18124ead6fd0771756&morerequests=goodthings
When you check it, in the service you would do something like this
<?php
if(md5($_REQUEST['user']."_privatekey")==$_REQUEST['hash']){
echo 'passed validation';
}else{
echo 'sorry charlie';
}?>
Obviously you would need to use PHP or something else to generate the hash with the private key, but I think you get the general idea. _privatekey should be something complex in the event you do have a troll that tries to hack it.

How to deny direct access to files in AJAX directory

I have several pages that call in content via jQuery .ajax. I dont want the content visible on the page so thats why I went with .ajax and not showing/hiding the content. I want to protect the files inside the AJAX directory from being directly accessible through the browser url. I know that PHP headers can be spoofed and dont know if it is better to use an "access" key or try doing it via htaccess.
My question is what is the more reliable method? There is no logged on/non logged user status, and the main pages need to be able to pull in content from the pages in the AJAX directories.
thx
Make a temporary time-coded session variable. Check the variable in the php output file before echoing the data.
OR, if you don't want to use sessions.. do this:
$key = base64encode(time().'abcd');
in the read file:
base64decode
explode by abcd
read the time. Allow 5 seconds buffer. If the time falls within 5 seconds of the stamped request. You are legit.
To make it more secure, you can change your encrypting / decrypting mechanism.
I would drop this idea because there is no secure way to do it.
Your server will never be able to tell apart a "real" Ajax request from a "faked" one, as every aspect of the request can be forged on client side. An attacker will just have to look into a packet filter to see what requests your page makes. It is trivial to replicate the requests.
Any solution you work out will do nothing but provide a false sense of security. If you have data you need to keep secret, you will need to employ some more efficient protection like authentication.
Why not have the content be outside the webserver directory, and then have a php script that can validate if the person should see it, and then send it to them.
So, you have getcontent.php, and you can look at a cookie, or a token that was given to the javascript page and it uses to do the request, and then it will just fetch the real content, set the mime types and stream it to the user.
This way you can change your logic as to who should have access, without changing any of the rest of your application.
There is no real difference to having http://someorg.net/myimage.gif and http://someorg.net/myscript.php?token=887799&img_id=ddtw88 to the browser, but obviously it will need to work with GET so a time limited value is necessary as the user can see reuse it.

Single entry point for a PHP app through the web and on the desktop

I'm trying to create a login process. But it seems impossible to create one process that will work with a desktop app and a standard website.
Instead I have the login function in Usermanagement.php (which is a class, icyntk) but then in another php file (api/login.php) I have:
<?php
require_once '../usermanagement.php';
$m = new usermanage();
echo $m->login($_POST['username'], $_POST['password']);
?>
And then I will still need to make another login.php just to be used with the login form on the website. As I can't see anyway to get the result (the echo) of the api/login.php script from the index.php file (where the login form is, it only has HTML in though).
Is there anyway I can simplify this so I only need one login.php?
As I understand you, what you want is:
a website/webapp having a login
a desktop app (not in PHP!) logging in using the same login method
One way is to export the login method using the same API in both your website and the remote application, so you would be using JavaScript on client-side to access the API from there (AJAX/JSON). You will want to use some framework for that like jQuery for client-side simplification of AJAX (among many other uses) and maybe the JSON module in PHP (to use json_encode; beware that the module may not be available on some webspaces so if that's out of control don't use it). Of course you do not need to use XML or JSON in your API responses but it's easier to open the API to other (including desktop) applications without the need to manually implement a lot of parsing functions to process the response in your interface classes.
Keep in mind that your website/webapp will not work without JavaScript if you do it this way! On non-public parts of a website that's okay, as is for a webapp used by a known user group, but you should not depend on client-side scripting for public parts of a website.
Another solution to simplify that is by using a PHP framework, so you can write the server-side frontend easier. This will basically enable you to give a button a serverside function which is simply calling your login method and acting accordingly by setting a redirect or replace some panel or whatever you like to continue with after the login.
Of course you can do all that by yourself but this will usually result in either a lot of messy code or an implementation of your own framework. If you want to do it on your own, start by posting the form to the same PHP file instead of an extra login.php and add a hidden field like:
<input type="hidden" name="action" value="login"></input>
In PHP, check $_POST['action']=='login' and call the login method.
Edit: While your website will work with a PHP session or a cookie, you may want to track login status with an own session token which you can pass to your desktop app so it can be used for consecutive calls to the API, so you don't need to handle cookies. These tokens should also be bound to the IP and maybe other "individual" information of the client; that information should ideally be hashed into the token or the token encrypted (client-side won't have to "decrypt" that, just return it for authentication). Tokens should also time out after inactivity.
Also, having read your older question, I fear you could be trying to do something bad like sending a hash over the network and simply check that hash with your user table because JS side encoding was discussed there. If you like to implement some encryption algorithm on client-side, either make sure it's secure (difficult to do that unless you are into cryptography) or resort to SSL.
As the data from your Desktop App is unlikely to be sent via the $_POST array, I would say no. Websites and Desktop Apps are two completely different types of applications, and it would be unrealistic to think you could share much of the front-end code between the two.
I would try to abstract as much of the functionality as you can into core classes, and then create two separate front-end implementations that utilize the core, each in their own way.
I'm going to get really "limby" and go out on a freaking huge limb and say that this is what you're trying to do:
<?php
if(isset($_POST['username'])) {
require_once '../usermanagement.php';
$m = new usermanage();
echo $m->login($_POST['username'], $_POST['password']);
}else{
?>Put your login form HTML here<?php
}
This way you only need one login.php file.

Categories