I have a plan to develop an online file manager application to manage(add/edit/update/copy/delete) my client's(My business clients) server files. Instead of using Filezila or any such FTP applications. Because there is no such options to track the file changes history in those applications.
My idea is
Placing an agent file in production server (http://example-client-site.com/file-manager-api.php)
Call the agent file (file-manager-api.php) from my project management system, which is hosted online. (http://example-proj-mgmt.com)
So i can access the production server files from my project management system like REST API , without connecting through FTP.
My question is, what are the security issues in the way of access the server through URL REST API method ?
Please give me some idea to overcome the security issues.
Thanks in advance :)
The Concept is good, I only have concerned with security. What you can do is you can keep something like Token or Authorization key or such, where only authorized users can access it, as the concerned is REST API.
Authorization (Tokn key)
Protect Against Cross-site Request Forgery
Insecure Direct Object References
URL Validations
Secure Parsing & Strong Typing
Validate Incoming Content-types
JSON Encoding
Message Integrity
Related
My team has a Web App(Laravel) and Android Application written in Kotlin. Our website has a Registration and Login forms but my problem is everyone can build their own app and call a POST method in registration form.
How can I secure our WebApp so that the only POST METHODS it accepts are just the forms from our own Android App and Web App?
Short answer: you can't.
For web apps, you could restrict origin by allowing specific domains in your CORS config. But since mobile Apps can change their IP there is no 100% secure way to restrict a public endpoint (at least I didn't find it when I faced the same issue).
Anyway, you can try to add an extra security layer by including a request header with some encrypted content that must be decrypted and approved by your API.
But this is not completely secure, Android apps can be decompiled with reverse engineering and they will find how your encrypted header is done.
If Android apps are not public (can't be downloaded from Google play services) you can also try to use the installation_id generated, but it will change when the app is reinstalled. In this way, you can approve or reject requests as per installation ids
You can JWT Tokens to verify the request .
If request is from a legitimate user then return the JSON data otherwise return an error . You can read more about JWT Tokens here
https://jwt.io/introduction
I know that there are many similar questions posted, but none of them refers to an HTML/javascript app where the user can access the code.
I have a private REST API written in nodejs. It is private because its only purpose is to server my HTML5 clients apps (Chrome app and Adobe Air app). So an API key is not a good solution since any user can see the javascript code.
I want to avoid bots creating accounts on my server and consuming my resources.
Is there any way to acomplish this?
An API key is a decent solution especially if you require constraints on the API key's request origin; consider that you should only accept an API key if the originating web request comes from an authorized source, such as your private domain. If a web request comes from an unauthorized domain, you could simply deny processing the request.
You can improve the security of this mechanism by utilizing a specialized encoding scheme, such as a hash-based message authentication code (HMAC). The following resource explains this mechanism clearly:
http://cloud.dzone.com/news/using-api-keys-effectively
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. If you're using Android, you can use the keytool included with the Android SDK for this purpose; if you're using another app platform, similar tools exist for them as well. Then create a self-signed client and deploy that within your application in a custom keystore included in your application as a resource (keytool will generate this as well). 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.
A step-by-step for this is a much longer answer than is warranted here. I would suggest doing this in stages as there are resources on the web about how to deal with self-signed SSL certificate in Android (I'm not as familiar with how to do this on other mobile platforms), both server and client side. There is also a complete walk-through in my book, Application Security for the Android Platform, published by O'Reilly.
I'm working on a user authentication library in PHP. Right now I have both stateful and stateless CSRF protection, everything's secure. My problem is that the API is for remote applications (mobile app, game, etc) and has a public facing script to let a client app perform requests to authorize/log in a user. I would like to include the functionality for creating and removing a user in this API so that the client can do everything itself, but can't figure out a way to make it so that the creation script couldn't just be hit by anybody to flood the database with fake users. When creating a user with the API, I don't require any credentials other than username or password in the request, which means that anyone could hit that script. Does anyone know of a secure solution to this to prevent an attacker from using the API to create/remove users themself?
you could increase obscurity by requiring a secret key. Distribute the key in the client code. However, anyone accessing the client code can see the key and use it. But random people scanning your service wouldn't have the client code, nor the key.
I'm creating a simple web service in PHP to serve data to some of our internal applications.
My question is around authentication/security, the implementation of the actual web service isn't a problem.
For security, I'm planning on providing each application that will be consuming the service with a unique, periodically static authentication code that they use when call into the service. The service code then checks an internal list to see if the authentication code being used is a valid one, and provides access to the data if it is.
E.g.
xxx.xxx.com/ws.php?op=getproductnameslist&authcode=329cj32x21xdd332
The service is being served over HTTPS, so transmission of the actual data should be encrypted.
I'd like some comments on the above in terms security concerns, and if there is a better way to do this.
Securing a WebService is not as simple as passing a get parameter through the URL. Get parameters are logged on HTTP server logs and easily copy/pasted and manipulated.
WebService security is not a simple problem, try to use well know solutions, I would go with OAuth. PHP has a good implementation here http://php.net/manual/es/book.oauth.php
You can also check this post about Web Services security http://www.stormpath.com/blog/secure-your-rest-api-right-way
I am looking to build an API that I can deploy on my servers to monitor system load.
It will report to a central manager server that runs a client to display the information.
The issue I am struggling with is best to secure the API.
What I want is for the client to be the only software that can access the server and retrieve this information but I am unsure how to achieve this using PHP.
I also want the possibility of distributing the API and client for others to use on their servers so I don't want people to be able to access other people data if they are using the API also.
The client is also written in PHP using MySql and has a secure login.
This sounds like you're trying to solve the wrong problem.
I also want the possibility of distributing the API and client for others to use on their servers so I don't want people to be able to access other people data if they are using the API also.
The only right answer to this is authentication. You need to protect your API by giving each user access credentials known only to them.
Your API must never reveal any data that the client isn't allowed to see as per their authentication credentials. Trying to work around this danger by trying to somehow protect the client from prying eyes is not safe - somebody who has access to the client and can observe it running will be able to reverse engineer any traffic between it and the server given enough effort.
If the API is properly secured, it won't matter to you which client tool is used to access it. The requirement to limit API access to a certain program will go away.
if you use SSL, along with authentication (i use 3rd party auth google, fb, etc), create data /reports on the fly and have the data saved in a subdirectory OUTSIDE your web folder (instead of /var/www, /var/myStorage/currentSessionId/), then you basically guarantee the security that you want.
your php will only access a subdir that is named for the session it is running under.