My platform uses AJAX to make communication with internal structure (API's and others). All AJAX requests are sent to a single file called globalAPI.php (POST Method) and there he communicates with other php files (this was done to hide the internal structure).
Assuming a user discovered how it works and make a request starting from his server. We can conclude that it would generate results without even being logged in my platform.
So how can you protect this file to external access?
I believe I could use a .htaccess file with Allow from 127.0.0.1, but what if the user change his ip to 127.0.0.1, he would have access to this file?
Have another way to protect this file?
You should implement an authentication system in all your API calls if you want to restrict their access.
Basically, you cannot prevent a user from opening the Network tab from the Devtools and watching the requests that your client makes to the server API: an advanced user can see the parameters sent at each request and resend the request with the same or different parameters.
If this file is accessible through AJAX, it is accessible for the client anyway: what you have to do is make sure that the user cannot access more things than the AJAX calls allow him. To do that, secure your API, e.g. requesting a user token for every call: the server would know which user accesses the API and you can handle authorization from that point.
Related
I've built a Slack App for our team.
I was able to create a Slack Button and used that to authorize the app with oauth.access
My Slack App adds a Slash Command to a channel in Slack
So far so good.
The Slash Command needs a Request URL which is simply the page that will receive the slash command payload and optionally, send a response back to the Slack channel.
Here's the rub, the server that host the page I need to use for the Request URL is on our internal network and only accessible to users on our VPN.
Our main site accessible to the world at, https://example.com
The server on which this page is hosted is at, https://slack.example.com which is only accessible to users on our VPN (both are apache 2.4 servers)
Anyone not on the VPN that requests slack.example.com is instead served https://example.com
It is not possible for me to move the php page to a server that is accessible outside our VPN (it's part of a larger application that can't be moved) but I can add a php page the serve that hosts https://example.com.
I'm thinking that I might be able to add a php page to example.com that could act as a proxy recieving messages from slack.com, passing them to slack.example.com then getting the response from slack.example.com and sending that response back to slack.com.
Is this possible, and if so, how would I go about it? I'm open to other solutions as well, possibly using Apache to do the proxying?
I would run the request page on a separate server in your DMZ functioning as proxy to the internal application server. Here is a brief description:
The php script for the request url (=request page) needs to be accessible to the public internet, so that Slack can call it. I would put it on a separate server and I would put that server in the DMZ of your company. That is usually the best place for servers that need to be accessible from the outside, but also need to access servers on the inside of your company. Make sure to use SSL and the verification token to secure your calls from Slack.
The request page can run on a small server and will need to have a webserver (e.g. apache) and php. If you planning to have more complex requests you may also need a database. It will also need to run SSL, so you will need a certificate. You can also use your existing webserver to the outside (example.com) if is meets these requirements.
The request page needs to have access to your application server, e.g. via VPN. It would need to function as proxy: receive the request from Slack, make requests to the application server based on the specifics of the slash command and then return the info back to Slack.
Another important point is user authentication. I read from your question that not all users on your Slack team should have access to the application server, so your request script needs to have a method to distinguish which users are allowed access and which are not. It would be easiest, if these users could be identified by membership of a specific Slack group. In any case you probably would need an additional bot that ensures mapping of Slack users to VPN users.
I know about guards and I am using them.
However, guards are client side code which the user could manipulate so they could access the guarded route anyway, thus bypass the guard.
My entire Angular2 application has a PHP backend so I'm thinking of using that with AJAX somehow but I can't figure out a solution where they can't modify the AJAX response and access the guarded route.
No, you cannot prevent the user from accessing a part of the UI, nor from requesting or submitting data from/to arbitrary URLs on your server, nor inspecting the network traffic in detail.
Client side routing guards and permissions checks are basically a UX concern, to only provide the user with the UI elements for the functionality they are allowed to perform.
It is the server application's job to "really" implement data security and deny access to perform sensitive functions and access sensitive data, using authentication tokens, roles and permissions, and the like.
The result is that if a user accesses the guarded route by bug or by trickery, this route's component will request the secure data from the server (this data must not be included in the angular2 component), or attempt to perform a restricted action, but the request will fail because the user's security token has insufficient permissions.
You can't hide ajax calls being made in a browser. All popular browsers let you inspect network traffic.
As far as I know, you can't modify the response of an Ajax call unless you have a middle man between the browser and the server. However, you can't stop the user from modifying ajax requests.
They can make the same requests (made by the browser) through curl, wget, Postman, etc. So, if you want to have restrictions on a private route, make them login and check credentials on the server side.
I use a JSON API to get data for a website. I am aware of various methods that I could make it secure, but my situation is different from common methods.
Because of cross domain issues, I had to create an API folder with various PHP files that do cURL requests to the REStful API. I then request these local PHP files through AJAX on my site. On the next release it should be JSONP to avoid this issue.
Many of these JSON requests contain sensitive information so the first thing I did was check for the HTTP Referrer so people don't just grab the URL when inspecting the JavaScript code and try to run it on their browser. This is obviously not safe nor should I rely on it.
Any data I may try to post to the request will be through JavaScript so something like an API key or token would be visible and would defeat the whole purpose.
Is there a way I can prevent these PHP files to be run outside the website or something? Basically make them inaccesible for visitors?
This does not have to do anything with REST. You have a server side REST client, in which you call the REST service with cURL and the browser cannot see anything of this process. Until you don't want to build your own REST service for this AJAX client this is just a regular webapplication (from the perspective of the browser and the AJAX client ofc.). As Lorenz said in the comment, you should use sessions as you would do normally. That's all. If you want to restrict access to certain pages, you can use an access control solution, e.g. role based access control is very common.
I have a facebook application, and some functionalities require some sripts running via ajax. Is there a way to ensure that the script is only called from inside my app? I use jquery for the ajax calls like this:
$.post('script.php', {var1: val1, var2: val2}, function(data){...});
.
The code inside script.php runs some sql queries and just check that all requested variables are passed through the ajax call.
What else should i check so that the script can only execute if called from my app and not by explicit calls?
Thanks in advance.
There are very few ways that you can make sure with 100% certainty that the Ajax request is being called from your app. If that was a mission-critical (high-security) requirement, then I would secure it the same way that I would secure any particular web resource:
Use SSL
Require a login gateway to establish a session
Check the validity of that session before allowing the request to process
If you don't want to go through the hassle of establishing a session, then there are less certain, but still quite helpful means of preventing access (causal access, that is):
Check for the presence of two request headers: Referrer and X-Requested-With. Referrer should contain the URL of your base page, and X-Requested-With should contain XMLHttpRequest. These can be faked, but it would require a much more determined "attacker" than someone simply browsing to the URL directly.
What you want to do is employ mutually-authenticated SSL, so that your server will only accept incoming connections from your app and your app will only communicate with your server.
Here's the high-level approach. Create a self-signed server SSL certificate and deploy on your web server. Then create a self-signed client and deploy that within your application in a custom keystore included in your application as a resource. Configure the server to require client-side SSL authentication and to only accept the client certificate you generated. Configure the client to use that client-side certificate to identify itself and only accept the one server-side certificate you installed on your server for that part of it.
If someone/something other than your app attempts to connect to your server, the SSL connection will not be created, as the server will reject incoming SSL connections that do not present the client certificate that you have included in your app.
Note that this depends on how well your app can protect the client-side certificate and the associated private key.
I don't think you can completely eliminate all calls outside the context of your page.
You can't base it off the source of the request if it is callable from any machine
You can't base it off the contents of the request as that can be network-sniffed and forged
If you can restrict to specific machines/IPs, then simply do that. Keep a list of white-listed machines server-side, and make sure the request comes from one of those.
The best you could do besides this is require authentication, in which case you could throttle request volume per-account.
Well a rotating public/private key would help ensure identification, maybe encrypt the data stream using a private key.
On some of my more secure applications i assign a public key to a specific IP address. If that IP does not provide that key in the request stream, I treat it as an illegal request and ignore it.
To go one step further you can lock down your requests at the server level for that path to that specific ip/host name.
It just really comes down to how secure/usable do you want your web service to be.
If I call a single PHP file that in turn uses GET's and POST's to build the HTML page as well as process other data and store it in SESSION, do I need to mirror the entire site into an HTTPS capable directory or does only the page being called need to be in the directory?
So for example my computer sends my name via POST to the server and specifically Index.php.
If the address of Index.php is is the data secure going to the server?
Is the data returning, most specifically the SESSION data, also secure?
Also I apologize if this quest has been answered a hundred times, for some reason I could not think of the proper search terms to find the answer.
do I need to mirror the entire site into an HTTPS capable directory or does only the page being called need to be in the directory?
No. Webserver can be set up so it watches to the same directory for both http and https
If the address of Index.php is is the data secure going to the server?
If it is a https protocol specified in the url - then all the traffic (request from client to server and response from server to client) between client and serever is crypted.
Is the data returning, most specifically the SESSION data, also secure?
Session data is never sent to client. It is stored on the server.