I was wondering if there is any way to restrict access to my REST webservices for non ios users. I am using Java and Jersey for my RESTful application.
The aim of this exercise is that since my webservice accepts POSTS of XML data, I would like to restrict the exchanges to an iphone client, to prevent manipulation of xml for security reasons.
the client side is an iphone application developed by us.
(moved to answer from comment by request)
No.
The TCP connection from the iPhone is no different than any other. Anything you receive via that connection as an "identifier" (A User-Agent string, for example) can be generated by any other device capable of making a TCP connection.
From your comment:
is there some kind of validation service, where we could check if the device token is an iphone ie the apple device id?
Even if there were ... you now simply have "security by obscurity"; All I need to do on any other device is send a valid id - you can not tell what is sending it.
Strictly speaking, no - as others have said.
However, since
the client side is an iphone application developed by us.
...you can ship a private key with that application, and hope nobody has enough incentive to bypass whatever security Apple has in place and reverse engineer your app to get their hands on that key.
(Note that this 'security' pattern has failed miserably for DVD encryption, console makers, etc... but if your app is confidential enough and the data you're protecting not worth much, it might be good enough for you).
Once you got that key, you can force authentication in your REST service based on some kind of challenge (initial request, 401 with challenge, client sign challenge with private key and send back with request repeat, server verifies with public key).
It may be helpfull if you make a check of user agent in your code like this :
if(request.getHeader("User-Agent").indexOf("iphone") != -1){
//Execute some code
}
Related
I'm currently developing an android app where the user has to fill out and successfully send the data of a few text fields to a recipient/server, to enable a feature.
The big issue is how to do that in a secure way to be protected against e.g. decompiling. My concern is not the security during the transport but rather the security of the transport medium.
What I've thought/read so far:
I could send the data via mail with the Java Mail API.
First of all, I don't want require that the user has to enter his mail credentials and SMTP server.
That would mean that I have to include the credentials to a mail account in the app, though.
To avoid the situation that somebody decompiles the app and takes over my mail account, I thought of encrypting methods, but even if I would save the aes encrypted version of the password, the attacker could decompile the app and could add a syso to output the decrypted password.
The same applies to OAuth authentication because I have to store an authentication token.
In addition to the mail version, I read something about getting the password with a POST request from a web service, which doesn't seem safer at all.
I could search for free smtp server without the need of credentials, but I want something I can rely on instead of waking up each day and looking if the service still works.
Send the data to a web service.
Okay that would require more work for me, but I would accept that, if there would be a solution without saving the credentials in the app or having a web service which accepts data from everybody.
Have I overlooked something? Or is there no safe method without asking the user for his mail credentials or google account etc. ?
OAuth would probably work. The nice thing about OAuth is that if a token is compromised it can be revoked on the server side.
You could create a web service that accepts TCP connections on some port. You could have some authentication mechanism for example Digest authentication that would be carried out before accepting data.
Another option would be to use an API such as Golgi. Golgi requires a developer key, app key and app instance id to connect to the servers and send data. In the event these credentials somehow get compromised you can simply change the app key and push a new version of the app through the Play Store.
As the diagram suggests, there is one main server and more than one user application. Server in its database, has maintained a set of feeds for each application.In other words, each application will have a set of unique feeds.
How does the client application receive the feeds from the server ? The only problem that has kept me away from implementing this is, how client will ask the server to send its feeds. Even if the client pokes the server about the feed, how will the server send them or how will the client receive it. One way out could be, the server writes all the feeds to a file and then the client knowing the address of the file parse it extracting the relevant data. But it could be a very long process if the there are many clients connected to the server.
Note: The client application is a desktop application
You probably want to identify the client by a unique user string or by authenticating the user. The most common way for implementing this is probably basic authentication (username/password) or a security string.
Basic Auth:
User enters username/password in the client software which is bundled with the feed request using either POST or HTTP-BA.
Security/Identifier string:
User enters a unique string such as hashed user ID or alike, which the client bundles with the feed request. E.g https://feed.domain.com?identity=fed54bd54ae...
There's plenty of ways to differentiate clients. Imagine what you will do when you go to a store. Do you just stand there, waiting for the cashier to give you something? No, you ask for something. How you implement that is up to you. You can use different ports, different URLs, define the protocol so that the client passes the name or id of the wanted resource when it connects.... Nothing really special here.
I'm building an android application which uses a PHP web service (I am building this also).
My question is, how do I prevent unauthorised users using my webservice? For example, could someone get the address of my web service and use it outside of my app (e.g. sending post variables to my service)?
Another related question is how do I prevent spam requests on my webservice? Would it be a case of logging the IP address and limiting the amount of calls?
You can use an HTTPS connection between the Android device and your webservice API endpoint.
Limit you webservice so that it accept only HTTPS connections. You can easily do this using Apache (perhaps using the SSLRequireSSL directive) or directly in your PHP connection handler.
While using an HTTPS transport stream, you can pass specific arguments when making an API call to your webservice to ensure the request has been sent from your application. Nobody will be able to know what specific data are transmitted and will not be able to reproduce an acceptable connection to your remote service.
Regarding your second question, you can indeed limit the number of requests for a given amount of time. Either in PHP or by using specific tools such as fail2ban.
PHP can receive data via POST or GET out of your site and even the internet browser. One of the methods used to do this is by curl.
To what are you referring to this question is known as Cross-site request forgery.
If you are able, you should implement the use of HTTPS in your app and this could solve many security problems.
In case you can not use HTTPS (whether it is expensive or any other problem):
You must verify the information received by POST or GET in your PHP, this language has much ability to solve these "problems"; Take a look at this part of the PHP official documentation.
Suppose you're building a login system:
Also you can add in the login page place a hidden element with secret unique code that can happend only once, save this secret code in session, so, the loging script look in session for this code, compare with what was posted to the script, should same to proceed.
And, if you want to get the IP address of your visitors:
function getRealIpAddr()
{
if (!empty($_SERVER['HTTP_CLIENT_IP'])) //check ip from share internet
{
$ip=$_SERVER['HTTP_CLIENT_IP'];
}
elseif (!empty($_SERVER['HTTP_X_FORWARDED_FOR'])) //to check ip is pass from proxy
{
$ip=$_SERVER['HTTP_X_FORWARDED_FOR'];
}
else
{
$ip=$_SERVER['REMOTE_ADDR'];
}
return $ip;
}
Finally, read this.
EDIT
If you can't pay an HTTPS certificate, (as Halim Qarroum says) you can use:
Self signed SSL certificates,
which are free.
Of course this has its advantages and disadvantages
I know that many has been ask for how to create a SMS server, but there has been been a fragmentation of knowledge because some just ask for a C# or PHP solution. My situation is different:
I need to develop 2 different services:
Receive SMS with a key work of what kind of information the client's client wants, like "FOOTBALL SCHEDULE" and the search in some data-base to send back to the sender's phone something like "12/12 NY X LA at 14:00h \n 13/12 DC X TX at 21:00h";
Client comes to my site and pays for 1000 SMS with message "Merry Christmas to you Girls!" with the possibility to enter the numbers or pick a random set in our own database according to what kind of people he/she wants to inform.
For that I can use:
Delphi or Java for Desktop/Web or Java for Android or PHP for Web;
MySQL or Firebird
A personal server or a Internet 3rd party server;
A SMS API service on the Internet or a personal phone with unlimited SMS sending pack.
So, the options are many. I can use a Android App in a Cell Phone or other kind of App in my PC connected to the Phone via USB. I can also use the Nokia NetBook that comes with a 3G slot and manage it from my App.
I have never made a program to handle any cell phone network services.
What I'd like to know from the unlimited StackOverflow users wisdom is:
Which of these options are the best to practice in the matter of available resources for SMS in these technologies?
Is there any finished community project with these arguments that I can be part of or import any piece of code/knowledge to mine?
Is there an API with these two services already available?
I am trying to avoid to contract a cellphone network provider to do that services. The cost would made it impossible. We are not intend to get a great profit, just to make these kind of services available in my region.
Thank You All!
there are plenty of web to sms gateways available worldwide.
usually they offer a http interface for incoming and outgoing sms.
so the simplest solution would be to find an affordable gateway provider and setup any kind of webserver to listen to the http request from the gateway provider on incoming messages.
this could be done in any environment you're familiar with.
for outgoing messages you would simply call an url of the gateway provider like
http://examplegateway.com/send?msisdn=23443&message=Merry+Christmas+to+you+Girls&secret=somesecrethash
this is easier than to program on the phone directly and usually cheeper, too. at least here in europe.
the contracts to the gateway providers come in as many differenty flavors as there are providers out there. with prepaid, postpaid, bulk-prices, monthly fee, pay-as-you-go you name it.
1 ) IMHO, and for my experience, the option 4 is the best, because this option allows you to have better scalability, and you separate the SMS logic, from you inner logic. Also, you don't need a person for maintain any server.
In the future, maybe you need to create another service, or another app. Using the option 4, you can reuse some code (or only the SMS API). Now you're using Android, but in the future, maybe you wanna create a Java Desktop Client, or iOS, or windows mobile, or.....
2 ) IDK :(...
3 ) IDK 2. I'm from Argentina, and we use a service only available here (Intertron)
I'm working on the Java backend for a Flash webgame - the client and server communicate using Action Message Format (AMF). A few weeks ago, another team in our company had their product hacked by a user who decompiled the Flash client, and used an altered version to flood the backend with bogus requests. We want to prevent this kind of attack in our new game.
(More details: webserver used is Tomcat, AMF client is BlazeDS.)
I'd like to know what the best way to prevent this kind of attack would be. Some ideas I had:
the nginx configuration seemed like the best place to handle rate limiting, but I cant find any resources on how nginx interacts with AMF. Do the AMF requests just get sent straight to Tomcat?
most requests involve a userId param for the relevant user. Rate-limiting requests involving overused userIds might be one approach - however, an attacker who just wants to flood the server could easily spam random userIds.
doing the same as above but using IP addresses in place of userIds could work. However, I can't tell if it's possible to get the IP address from an AMF request.
Your Java application should pass unique identifier to the firewall of host operating system and block that client. With this action you would be able to prevent your application from working on things that it isn't supposed to do (being a firewall).