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
Related
I am trying to simulate a response from a web server login confirmation to a windows application. I have the captured packets that detail the conversation between the server and the application for successful login already as it is my application, this is for debugging and MIME simulation to test application and network security. communications create what I hope can be a custom foolproof way to prevent a MIME but I dont have a way to test it, so here I am to ask for guidance.
How would I go about simulating the response from the server to the application?
I have some idea in the direction I would possibly need to go to achieve my desired outcome:
Utilizing my network:
I have a Linux machine set up as a dynamic router, dhcp, routing, and my Linksys router just acts as an access point and ethernet switch.
1: Set up web server on Linux machine.
2: redirect traffic from application port to Linux server.
3: run server-side script to respond to application request using packets captured to establish replay successful login to server.
So, I am kinda new to using Linux tools. I have setup a Linux router, captured basic information utilizing Wireshark, and am able to program in VB, javascript, some java. I have not done much network-oriented programming other than some simple communication for authentication I have successfully established.
Any information to point me in the right direction I am grateful for!
Most logins use encryption (https / TLS) so capturing the packets won't help.
If not, the packets will form a http request, and you should be able to see the format of the request, whether the login credentials are part of the URL for GET or part of the http body for POST. It is not hard to create your own http request.
How are parameters sent in an HTTP POST request?
Each http request will be followed by an http response from the server, and the format of the headers or body will contain the login result (http requests and responses are similar in format, but the headers are not the same).
More sophisticated logins may involve a series of requests/responses.
You will need to write a simpler server to receive the requests and send the responses. Java is probably your best choice, given the languages you know, plus there will be plenty of examples online. With JS it may be possible but for the most part JS is used in browsers, so not a great choice. VB is a Windows language not supported on Linux.
I am looking for some guidelines as to how to secure requests from android client to server
How can i prevent un autenthic (users which initiate requests not from the android app) requests to be accepted and processed by the server?
Waybe generate token at user registration and use it somehow at each call?
My server is a lite instance and performance is top issue in the implementation of the server client communication.
Appreciate any help!
You could use Google Cloud Messaging as a via medium to make sure messages that reach your server are from the app, without getting too involved in details. Check the documentation here:
https://developer.android.com/google/gcm/index.html
Or else, as you said, create a unique id on registration and send it back to the client. Store it at both client and server. Now with each request from the client, add an extra field in the request and send the id also. Check this id serverside and make sure it is valid (this check could eventually become heavy on time).
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
}
I am concerned that the data that is being sent from our remote database to the java based client software is not being sent securely as it is using http tunneling with RMI rather than https.
The problem is I need to prove the vunerability to my boss before he takes it up with the IT company.
How can I send and receive data to an RMI cgi serverlet to test this theory?
I have used wireshark to see the packets and I can see the url that the data is POSTed to but have no idea of an easy way to replicate the RMI protocol (without writing a whole Java app).
I believe that you can create special method with simple signature like
String foo(String);
Now try to call this method with your mechanism and user wireshark to catch packets. I think that if the data is not encrypted you will be able to see the parameter and return value in clear text.
I have java web application to which I'd like to add emailing capabilities, however, I'm unsure what is needed to accomplish this. Specifically I want my app to be able to:
Send emails confirming sign-up
Allow users to send emails to one another, using my app's domain i.e. dan#my-app.com
From my research it seems I'll need a mail transfer agent (MTA) like Postfix and possibly a IMAP server like Courier; but I don't understand the need for the IMAP server.
Thanks.
You need code inside your web app to create and dispatch the email into the SMTP-world. Usually JavaMail is used for this, and you can either enclose it in your web application or (preferred) have the web container provide a correctly configured instance through JNDI. This is vendor specific.
If you do not have a SMTP-server for JavaMail to connect to (frequently this is Exchange for Windows shops), you can either get one running (ask your IT administrator) or use Google Mail or Hotmail or others if it is ok for your web application to send mail through them. It is a bit tricky to use GMail as a SMTP-server, but when set up correctly works very well.
You will need the SMTP-server, as it handles all the boring details regarding MX records and resending if the SMTP-server does graylisting, etc. etc.
Oh, and IMAP is for getting delivered mail, not sending mail. You don't need it.
If it's a Java web app, then the server part is a servlet. Given an email message sent from a client form, your server needs to send that text off as an email.
There's code in the Java EE stack to do this, or you can specifically download JavaMail. This will allow your programs to act as mail clients.
Your MTA receives messages from your servlet and sends them to the users. So far so good.
But you also need a postbox, i.e. the equivalent of a mail in-box for your users. Postfix, QMail and others offer a basic "flat" mailbox model, where mail is simply stored until the client picks it up, and then (usually) deleted. Access is via POP3. IMAP offers a lot more organizational capability, i.e. the ability to specify hierarchies of nested mailboxes, to transfer mails between them and so on. You probably won't want to create a GUI front end to all that complexity, so I'd guess you don't really need an IMAP server. You do, however, want a relatively simple POP3 server to allow your servlet to access the mailboxes via TCP/IP. This is usually part of the "standard" email server packages.
To have your own domain known to the world, you need access to the MX records of your DNS service, i.e. you have to set up one or two of your hosts, on an Internet-facing address, to be your post office.
Finally, if you want to save yourself a lot of trouble, be very careful in configuring your MTA (SMTP server) such that there is no chance for it being used as an open relay. i.e. it should not be possible for your users to send mail to the outside world in general (or hackers will find a way to abuse your Web interface to do this), and mail from the Internet should not reach your users. Most importantly, there should be no way for mail from the Internet to be forwarded to someplace else in the Internet. Find an open relay testing service (they're free) on the 'net and get one to run a test on your configuration once you think you're done.
EDIT:
Looking at Thorbjorn's answer, I realized you probably don't want your users receiving their mail through your app; they probably already have email providers and accounts of their own. In that case, you don't need to worry about inbox capability or a POP3 server. You could consider offering full email services at your domain but that's a very thankless job and if you have any choice, leave that dirty work to GMail, Yahoo, Hotmail and their ilk. Whatever service you provide will never please your customers enough, and you'll be fighting spam and other crime every day.
For starters your server has to have mailing abilities. In linux land sendmail is usually what this will be.
Additionally, check out javaMail.
http://www.oracle.com/technetwork/java/index-jsp-139225.html