I need some pro advice.
I'm working on an iPhone app that sends and receives a reasonable amount of data for one HTTP round trip.
The device sends a POST request to the server
The server responds with the data needed for the device
Initially the server was sending XML back to the device, where the device parsed it and stored it within its sqlite3 database. But I've been thinking... why do I need to encode the data within XML, break it apart, then write a query client-side to store the data. Why can't I use the server to write the queries, and simply execute them on the device?
There may be a security threat here, perhaps, and I would love to hear what exactly that may be, but I'm not convinced that I absolutely need to encode the data in XML; unless I was building an API of some sort.
Anyways, I've been thinking about this problem for quite some time (I'm still very new to programming) and I would absolutely love some expert advice on this.
Thank you for your time,
Rob
You got a couple of options for data transmission:
1) For security you can use SSL via NSURLConnection.
2) You can use JSON instead on XML. Take a look at NSJSONSerialization.
3) Or depending on your server side and app needs, you could just send plain HTML (text).
It's kinda hard to give you more detailed input without knowing some specifics of what you are trying to do.
Related
I am new to the world of programming and I have learnt enough about basic CRUD-type web applications using HTML-AJAX-PHP-MySQL. I have been learning to code as a hobby and as a result have only been using a WAMP/XAMP setup (localhost). I now want to venture into using a VPS and learning to set it up and eventually open up a new project for public use.
I notice that whenever I send form data to my PHP file using AJAX or even a regular POST, if I open the Chrome debugger, and go to "Network", I can see the data being sent, and also to which backend PHP file it is sending the data to.
If a user can see this, can they intercept this data, modify it, and send it to the same backend PHP file? If they create their own simple HTML page and send the POST data to my PHP backend file, will it work?
If so, how can I avoid this? I have been reading up on using HTTPS but I am still confused. Would using HTTPS mean I would have to alter my code in any way?
The browser is obviously going to know what data it is sending, and it is going to show it in the debugger. HTTPS encrypts that data in transit and the remote server will decrypt it upon receipt; i.e. it protects against any 3rd parties in the middle being able to read or manipulate the data.
This may come as a shock to you (or perhaps not), but communication with your server happens exclusively over HTTP(S). That is a simple text protocol. Anyone can send arbitrary HTTP requests to your server at any time from anywhere. HTTPS encrypted or not. If you're concerned about somebody manipulating the data being sent through the browsers debugger tools… your concerns are entirely misdirected. There are many simpler ways to send any arbitrary crafted HTTP request to your server without even going to your site.
Your server can only rely on the data it receives and must strictly validate the given data on its own merits. Trying to lock down the client side in any way is futile.
This is even simpler than that.
Whether you are using GET or POST to transmit parameters, the HTTP request is sent to your server by the user's client, whether it's a web browser, telnet or anything else. The user can know what these POST parameters are simply because it's the user who sends them - regardless of the user's personal involvement in the process.
You are taking the problem from the wrong end.
One of the most important rules of programming is :
Never trust user entries is a basic rule of programming ! Users can and will make mistakes, and some of them will try to damage you or steal from you.
Welcome into the club.
Therefore, you must not allow your code to perform any operation that could damage you in any way if the POST or GET parameters you receive aren't what you expect, be it by mistake or from malicious intents. If your code, by the way it's designed, renders you vulnerable to harm simply by sending specific POST values to one of your pages, then your design is at fault and you should redo it taking that problematic into account.
That problematic being a major issue while designing programs, you will find plenty of documentation, tutorials and tips regarding how to prevent your code to turn against you.
Don't worry, that's not that hard to handle, and the fact that you came up with that concern by yourself show how good you are at figuring things out and how commited you are to produce good code, there is no reason why you should fail.
Feel free to post another question if you are stuck regarding a particular matter while taking on your security update.
HTTPS encrypts in-transit, so won't address this issue.
You cannot trust anything client-side. Any data sent via a webform can be set to whatever the client wants. They don't even have to intercept it. They can just modify the HTML on the page.
There is no way around this. You can, and should, do client side validation. But, since this is typically just JavaScript, it can be modified/disabled.
Therefore, you must validate all data server side when it is received. Digits should be digits, strip any backslashes or invalid special characters, etc.
Everyone can send whatever they want to your application. HTTPS just means that they can't see and manipulate what others send to your application. But you always have to work under the assumption that what is sent to your application as POST, GET, COOKIE or whatever is evil.
In HTTPS, the TLS channel is established before and HTTP data is transfered so, from that point of view, there is no difference between GET and POST requests.
It is encrypted but that is only supposed to protects against mitm attacks.
your php backend has no idea where the data it receives comes from which is why you have to assume any data it receives comes straight from a hacker.
Since you can't protect against unsavoury data being sent you have to ensure that you handle all data received safely. Some steps to take involve ensuring that any files uploaded can't be executed (i.e. if someone uploads a php file instead of an image), ensuring that data received never directly interacts with the database (i.e. https://xkcd.com/327/), & ensuring you don't trust someone just because they say they are logged in as a user.
To protect further do some research into whatever you are doing with the received post data and look up the best practices for whatever it is.
Ok I found a few questions on how to get data from a MYSql database into an iOS app, but I am just asking a few best practices here. I know these can all be separate questions, but I am hoping that they can be answered in a way that they relate to each other.
Am I correct to understand that to be able to get data into an iOS app - I need to first generate a JSON file, have that stored on a server and than have the app download this file??
If the previous answer is NO then does that mean, I can pull in data on the fly?
Lastly I have seen PHP examples to create JSON files, but iOS is in Objective-c. Does this mean I need to load a UIWebView to be able to load the PHP page that generates the file?
What I have:
I have a MYSql database - it is set up through PHPMyAdmin, so I am not familiar enough with the creation process of the database yet. I will look into that.
I can also export the JSON file from PHPMyAdmin, but that is no good to me in a iOS app.
I also have the parsing from a JSON file into an iOS app sorted, but I want to be able to do this on the fly instead of creating potentially hunderds of files.
I hope someone can help me here:-)
I am not necessarily asking for code, but would be mad to ignore it:-)
The problem is that there are not any iOS libraries for directly connecting to a MySQL server; and you really wouldn't want to do that, anyway. So, you need an intermediary server capable of sending data in a format your iOS application can understand. Note, this does not mean the data has to be JSON formatted. But it is very easy to use JSON as the format for your data. Most languages have native support for generating JSON from its native object format(s).
Once you have a server capable of sending data in your preferred format, you need to write some way for your iOS application to retrieve it. You do not have to use a UIWebView for this. As mentioned, the NSURLConnection framework is very easy to use to make such a request. However, there are a lot of other factors to consider when making network requests and others have already done most of the work for you. I like using the AFNetworking framework in conjunction with JSONKit. AFNetworking makes asynchronous calls to remote web services very easy, and JSONKit is nicer than NSJSONSerialization in my opinion.
What I do to retrieve data from MySQL to my iOS app is:
Create a PHP file on your server and prepare it for GET methods (you're going to send data from the iOS app)
Send a request from your iOS app to your php file, like: "www.yourdomain.com/data.php?name=..."
Process the information on your php file and echo the json output.
When connectionDidFinishLoading: convert the NSData to an Array using NSJSONSerialization.
Do whatever you like with the output information
That's just do way I do. I'm not familiar with other approaches.
PHP (and any other server side language) can take the data from the MySQL database and output it to any client as JSON, on the fly. No need to save the JSON to disk beforehand. Of course, from the client's point of view, there really is no fundamental difference (except the data will always be the latest representation of what's in the database).
You also don't have to use a UIWebView. There's a number of ways to make an HTTP request using Objective-C, but you'll likely want to look at something along the lines of NSURLConnection's sendSynchronousRequest:returningResponse:error: method (I prefer using synch methods inside an async block, but that's not the only way). You can find many tutorials on how to do similar things, as well as higher level libraries to simplify the process.
Right now I'm in the middle of a project at college, regarding IPhone-Development.
The project consists of a webserver with mysql database and multiple clients (IPhone Devices).
I'm struggling a bit with the basic cocept, which is the communication (receiving, sending data) between IPhone and Webserver.
I've set up an Webserver with a MYSQL-Database. I also have a PHP-Script that accesses the DB and writes the db-Data into an XML-File.
1)What would be the best way to proceed with the Client (IPhone)?
2)Is it possible to directly access a .php File and download the XML to the IPhone?
3) What will be downloaded to the IPhone? The whole XML-File or the XML-Content?
I would then go on to process the XML-File with a XML-Parser (preferably NSXMLParser).
4) How is it possible to store the received data persistently on the IPhone? NSMutableArray? This feature is required for offline mode if any data is added on the IPhone-device.
This brings me to my last question:
5) How do I send data back to the webserver? Or to be more specific, wich datastructure do I have to use to send data back to the webserver? What would be a reasonable way to do this? For example: creating a new XML-file and sending it back to the webserver?
Best Regards,
Alex
Must the data protocol be XML? I'd opt for JSON as the data protocol!
If it's feasible for you to use JSON then take a look at the lightweight SBJson framework. It's going to be much easier to use JSON over XML for iOS, believe me!
To summarize on the other questions, regarding server communication etc.!
Is it a mandatory precondition for you to write the networking code from scratch or are you allowed to use existing open frameworks for that? If you may use a framework then f.e. take a look at MKNetworkKit! It'll take away almost all the hassles that come with writing or incorporating own network code and it has JSON serialization/deserialization build in already!
If not then go with NSURLConnection, NSURLResponse and probably some NSOperation/NSOperationQueue for asynchronous handling and have some fun! :-)
And don't forget the Reachability.h/m from Apple! ;-)
For data persistence on the device either go with CoreData, which is very powerful but mybe (regarding complexity) to much of overhead for your purpose. Or just store your stuff with/in NSUserDefaults!
I'm making a simple game with Java / .net as client and using php webserver.
Now when someone finishes the level, quit or starts a new game the client sends information on a php Page that stores them in a mysql database.
Now i wouldnt that the users cheat.
To use the game client you need a username and password.
The client sends the number of times that they played the game, which player has defeated, how much points earned. So if i send clear information someone with a sniffer could see which php page I call and copy the information a send to the webserver.
So what's the best security/check system in this case?
I was thinking about use any crypt system that i usable in java vb.net c# and php (like des , md5) but I would like to know if this is the better solution or not.
Update The clients dont use The Web Browser to comunicate with the WebServer. It's WinForm application for example that call php pages to get information and to update data on Mysql DB
Thanks a lot
Some things you should know before continuing:
Everything that is on the client browser can be inspected. This includes all calls you make back to your database server. Encryption doesn't matter for this because, obviously, your javascript code will be the part encrypting/decrypting the data. Javascript can easily be looked at to get the keys.
Even Flash etc can be decompiled by those willing to spend the few minutes working it out.
Don't wait until they have completed all of their games to send info to your database. Do so as the actions occur.
You can only make it a little hard, not impossible, to cheat when using javascript as the game engine in your browser. By "a little hard" I mean it might take an hour for someone with even halfway decent programming skills to defeat... most likely much less.
Regarding sniffers. It doesn't matter if your site is SSL enabled or not. This only protects the information once it leaves the computer. It is not going to do anything about a sniffer located on the client machine.
To sum up: your only real defense here is to make cheating something that is not worth anyone's time to do.
The best option would be to have the application use a webservice and the Client application encrypts the message before sending, but unless you put in some aditional salted data (such as a timestamp to try and mitigate any replay attacks) then you'll still be open to people being able to 'easily' cheat.
.Net has some good WCF service options, and although I've never used WCF with a php endpoint the idea of WCF is to allow cross technology communication, the best bet would be to do some research into that field.
Also to note, MD5 is not an encryption method, it's a Hashing algorithm, meaning that once the data is hashed it can't be recovered.
I have created an iPhone application which fetches data held on a server in an XML file. How do I check that the request for the data is coming from my app and not from some other source such as another iPhone app or a desktop browser since currently you could just trace the iPhone request on your LAN with Wireshark and then use the captured URL to load the data in a desktop browser. I'm thinking I'm going to need to serve the file via PHP or something and use some sort of User Agent validation or a challenge-response sequence. If someone could provide a code sample I'd appreciate it.
Short answer: You can't. But you can indeed make it harder.
Whatever you do, it will be possible to circumvent it - user agent validation is extremely easy to circumvent; challenge-response will require disassembling of your app, but it's still possible.
However, all your nice protections won't help against network sniffing. Unless you also encrypt the transfer someone can simply sniff the plaintext data instead of breaking your "protection".
IMO the main question shouldn't be "How do I protect it" but rather "Why would somebody want to get the raw data? Why shouldn't he get it?"