I've used Parse to create an application for iOS using the iOS SDK downloaded from the Parse.com website.
In order to create this kind of application the ApplicationID and ClientID keys are both embedded in the iOS app and sent from the app to the server when the application is used. This essentially puts the ApplicationID and ClientID in plain sight so any user can write a small program which would repeatedly call the various Parse apis of my application.
I have followed all the security advise in the parse tutorials and all the data has appropriate roles and ACLs.
HOWEVER a single unsophisticated user could bring down my entire application simply by calling the login api of my parse app more than 30 times per second.
Am I missing something or is this a FATAL flaw in using Parse.com as a backend from an iOS app?
Does anyone have a solution to this problem?
You can always reduce the chance substantially by applying
Security by Obscurity ;-)
You can encrypt your keys and place decryption function right inside your JavaScript. You can further make it harder to find by hiding that function in the middle of a large nasty script that nobody would enjoy, and then minify your JavaScript (which you should be doing anyway). I am sure it is possible to get even "more creative" and reach some reasonable perfection :-)
It remains, however, possible, in principle, for a sufficiently motivated hacker to reverse-engineer your program and get the keys. Still you can make it hard enough, so the hacker will likely look for easier targets, of which there is plenty as we know ;-)
See also here
for more ideas.
Related
This may seem like an odd question, but I'm in the middle of creating an iOS app, and was wondering if there is a way to, in the future, roll out changes to the app without requiring all of the users to download an update.
I've noticed that Snapchat can do this with their filters - new filters are added regularly, without me updating the app.
I've read into 'Cloud code', something Parse had that apparently let you accomplish this. Obviously that's no longer an option.
Also, do Apple even allow this? Seeing as they need to approve every app before letting it onto the App Store, it would seem like they would need to approve any changes first too.
I've thought of strange things like storing a function in a database, then getting the app to download that function and run it - naturally if I were to now change the function in the database, it would change on all users devices instantly. Just how ridiculous is that idea? Thanks!
Depends on how much flexibility you want.
For example, Spotify does this for UI mainly - backend-driven UI, as they call it. They send a kind of layout from the server and convert it to a real iOS layout, based of a predefined mapping. You can find pretty more details in the Spotify's presentation.
Slides: http://www.slideshare.net/JohnSundell/backenddriven-native-uis
Video (more details): http://www.downvids.net/backend-driven-native-uis-john-sundell-and-diego-cristina-ca--777281.html
So actions can also be divided in similar pieces and abstractions, received from the server and interpreted - sort of scripting is needed. You can't compile and run arbitrary functions on the fly.
Hope it'll give you some ideas you can think of.
See Apple's app store review guidelines: https://developer.apple.com/app-store/review/guidelines/ section 2.4.5 (iv). Apps are not supposed to download code or resources to add functionality or significantly change the app from what Apple sees during the review process. And executable memory isn't even writable by sandboxed apps, which makes downloading compiled functions fairly useless. But downloading Javascript that complies with the above guidelines seems to be allowed.
I'm new to iOS development and working on a small iOS mobile app that stores sensitive information of users. Initially I thought of using custom AES encryption to encrypt/decrypt all the data. I also want the encrypted data to be synced with iCloud. After reading more I came to know from iPhone 3GS each device has a built-in AES-256 crypto engine. From the XCode, I observed that I can turn on an option called "Data Protection" for the mobile app to secure data. Based on my analysis I've below questions:
To use data protection for iPhone 3GS (uses iOS 6.1) do I need to set passcode?
Without setting passcode for the device how can I use the built-in crypto engine to encrypt my data?
The information are very sensitive and so in this case do I need to implement custom encryption?
RNCryptor is very useful, but it's basically just a wrapper for Apple's own CommonCrypto functionality (that makes implementing it pretty easy). It's useful if you want to encrypt data on the device that even the user cannot get ahold of.
Regarding your specific questions:
Data protection encrypts your app data using Apple's device-level encryption (you do not password protect it yourself). This has its uses - it will keep a 3rd party from being able to access data on a device if they are unable to unlock it - but does not prevent (for example) a user from getting access to data on their an unlocked device. Using RNCryptor and CommonCrypto which it is built upon you can AES256 encrypt content using a password of your choosing.
Apple details this here. Basically, from the end user's perspective they just set a password for their device as normal. You do not use a password of your own choosing.
You can set this up for your app using the following instructions:
https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/AddingCapabilities/AddingCapabilities.html#//apple_ref/doc/uid/TP40012582-CH26-SW30
This depends on how sensitive the data is and what threats you foresee (Who are you trying to keep it away from? Are there any laws/regulations you intend to comply with? How much work do you want to take upon yourself to protect this data?). There are a lot of trade-offs and caveats that can apply in certain situations.
If you have a small amount of data, you might consider just storing it in the iOS keychain. Otherwise, I'd recommend giving RNCryptor a try. It's fairly easy to integrate.
I hope this helps.
UPDATE: Another thing to consider... There are potential export control ramifications that might come up if you implement your own encryption, even using RNCryptor/CommonCrypto. Depending on how much paperwork and/or delay you're willing to deal with, this may influence your decision. You can learn more about this from Apple's site, here:
https://itunesconnect.apple.com/WebObjects/iTunesConnect.woa/wo/20.0.0.13.7.2.7.9.3.1.2.3.3.1.5.7.1
This really depends on how many scenarios you are trying to protect against. Pretty much any scenario you can possibly create will be broken given enough time and effort. However to address a few points:
1) Yes you need to set a passcode for this feature to become active.
2) You can make use of the CommonCrypto library (or a wrapper around it like RNCryptor)
3) This is a bad idea for the simple reason that developing a secure algorithm is insanely hard. The slightest flaw will leak out all of the data and people have devoted years of their lives to sniffing out these flaws (although I may have misunderstood what you meant by "custom encryption")
If you want to be as secure as possible you will have to do this: Send your file to a server for processing (via HTTPS). It is much harder to hack into a server then it is to hack into an iOS application. If you simply use RNCryptor it is pretty trivial to rip apart the app looking for the password, or how you obtain the password. Basically if the app can do it then BlackHat can do it too.
EDIT I forgot about one thing! If you generate a random password for each install and store it in the keychain then this will help, but it is not foolproof (There is a small chance that the iOS keychain contents can be retrieved from a jailbroken device, especially if the user has a week passcode). However this will make the user's data non-recoverable if they wipe the OS for any reason.
very very very simple : https://github.com/RNCryptor/RNCryptor
I was used it for a chat application it so good.
I'm trying to add a bit security to my app. I have a server that the app connects to and I am thinking of sending a checksum of the binary when making a connection. If the checksum does not match with what I want. The server wont alow any connection.
I´ve read a couple of articles of how you can increase security of your app and many mention checksuming your binary but haven´t found any code explaining how you actually checksum your binary during runtime.
This one for example
http://www.seoxys.com/3-easy-tips-to-prevent-a-binary-crack/#ptrace
Other than that, from what I have understood, there is no way of knowing the exact checksum before hand since Apple will sign when submitting? I could however disable the check on my server when submitting a new version, then reenable the check when I know the checksum. Not a perfect solution but what solution is?
Anyone that can point me to the right direction?
In short, this is a very difficult thing to do. The reason why, is that you don't control the client code once it leaves your hands. Even if you get everything working perfectly with the checksum, and attacker could still take a checksum of the binary, modify it, and then have it submit the previous checksum instead of the new one, by modifying that code. In fact you would probably make it easy for him/her by using a function like _getBinaryChecksum() that he can just change :-)
If you are going to do this, use a cryptographically strong hashing algorithm like SHA-256. You are right that Apple signing it will change the hash, so you will need to program the server with the hash of the file after Apple signs it. Also keep in mind that any change at all to the app will greatly affect the hash, so you need to keep a historical list of previous hashes so you don't shut out customers who haven't upgraded yet.
You may want to check out these StackOverflow question, as it sounds like you are trying to do something similar:
Security When Using REST API in an iPhone Application
https://stackoverflow.com/questions/15390354/api-key-alternative/15390892#15390892
I'm working on the requirements & specifications for a new iOS app intended for use by certain professionals working "in the field". All day long for weeks on end, these folks have a sizable reporting burden to their superiors using standardized forms that track all different kinds of information. Traditionally, those forms are in PDF, and are simply printed and filled out in ink and then shared with the dozens to hundreds of others working the same operation. Sometimes they'll use a PDF with form fields so the data can be typed and then printed as part of the form. Either way, given their workflow, time and stress pressures, and other factors, it's not a very productive way to get the standardized reporting forms done.
The app we're spec'ing would offer an iOS (and Android, if possible -- but secondary or even tertiary requirement at this point) user interface for tracking the data they enter in the field, organizing it in a logical manner for each individual user, and with the press of a button, take all that data and automatically create a PDF file of it using the standardized form.
Of course, the forms are STRICTLY and rigidly standardized in this industry, and any deviation in format, structure, or presentation is simply not tolerable.
So I was approaching the project by thinking the app would maintain an internal repository of the original standardized forms from the accrediting organization, with each possible data area defined as a field. The app would:
open the necessary PDF form for the task at hand;
parse its dictionary to identity the specific data fields;
for every single field, identify the relevant data from the iOS app's own user interface and data tables, and assign that data to the corresponding field from the PDF/dictionary
export the PDF to a NEW PDF file, which the app would either email or store through iCloud, Dropbox, or some other form of file sharing.
The catch with #4 is that that PDF file must remain editable by standard PDF applications on Windows and Mac (Acrobat, Preview, etc.), so all the fields need to remain. And the PDF should be viewable just the same on either Windows or Mac.
Now, at NO time will the PDF (neither the original nor the exported final document) EVER need to be displayed inside the iOS app, nor would it make much sense to be able to do so.
I don't know if any of this is possible. This is our first iOS project, and we've been leaning towards building the app using Moai or Corona or some other framework to save development time and make porting across platforms easier. That said, if it cannot be done using Lua and one of these frameworks (I remain skeptical...they seem HIGHLY geared towards games), we're not opposed to doing it directly in Objective C and building an Android version some time down the road.
But either way, I'm at a loss in assessing whether this is even a practical undertaking. Our requirements are clear, and frankly if this can't be done, the project won't be pursued any further. But I could definitely use some help from you folks in identifying what my options are, whether I can do it in Lua, and what SDK(s) would be most useful in accomplishing this.
Based on what you've said, it seems that there is little reason to do the PDF-based part of the work on the mobile device itself since:
you don't need to display it on the ipad
you plan to email it or store it in the cloud
if you write this for iOS you will have to write again for Android as you've mentioned
Can you simplify the mobile part of your requirement by focusing on the data-collection and validation, then firing off to a server to do the document production? That will give you a lot more flexibility in the tools that you can use to merge the data into PDF docs. If so you could look at creating PDFs or populating the fields from code using something like iText (C# or Java). If you don't want to build your own back end server you could try something like Docmosis Cloud - but that might not allow you to get your precise layouts.
Certainly the catch you mentioned - needing to keep the PDFs editable with their fields is a significant gotcha in all cases. If you could convince the stakeholders that it is better to generate the final documents from your system (generate draft, review, update data, generate again etc) - rather than generating editable documents that you then lose control and tracability over, then you will be miles ahead.
Hope that helps.
Did you consider just generating a new pdf using an image of the form as the background to the pdf and just writing the user's data into the required areas over the form image. Would reduce the complexity of trying to parse the original form PDFs.
That's a point of worthwhile discussion, but one we don't have an ideal answer on. I tend to think of that as the almost perfect scenario -- it'd be considerably easier to develop. There are two key issues with this approach that have made us table it except as a very last resort:
The users of this product would be working in the field. That field could be quite literally anywhere--the streets of Manhattan, a disaster-stricken area with infrastructure that's been severely damaged or even destroyed, or the most war-ravaged third world country. If it were the streets of, say, Manhattan, there's no problem--their iOS or Android device will have 3G or Wi-Fi access just about anywhere they go. In the latter two scenarios (which are arguably more common in this industry), that connectivity may be very limited. The concern is whether the end user's ability to be productive or to see and share data with their colleagues will be too greatly restricted if they don't have a decent signal. To be fair though, even today they often aren't even using mobile devices, forcing them to go back to a headquarters type location or use radios to share information, effectively negating my point here. But if we're not going to significantly increase their productivity in the field, it just gives us pause to think through whether or not we have enough of a value proposition to ask them to fairly significantly change their methods of doing things.
To your latter point, no there's no convincing the stakeholders that this new system is the better approach. Even if there were, it would take years to do so. These forms are a part of a well-defined, decades-old standard used by literally thousands of organizations.
I have a Rails 3 app that I'm looking to create in-house analytics for. The items I need to track are impressions (and unique impressions), clicks that come from those impressions, and conversions that come from those clicks. And these are all user-specific so each user can see how many impressions, clicks, and conversions they've received.
What is the best way to go about this? Should I create a separate rails app and call it with pixels? Or should I include all the analytics code in the same app?
Also, are there any analytics platforms already out there that I can customize to meet my needs?
Thanks!
Tim
Before you start re-inventing the wheel, Google Analytics provide a developer API (via OAuth, among other choices) that may provide you with the ability to do what you need (provide each user with a view of their own data).
http://code.google.com/apis/analytics/docs/gdata/home.html
Building your own, while it may seem like an initially basic thing to do, could have serious performance implications further down the line, and Google provide a very detailed view of the the data.
If you really want to write your own, I would strongly urge you not to hit the database for each request you want to track. Keep the data in Redis, or one of the alternatives and periodically persist it to the database via a background task.
If, however, you don't want to put your data into the clutches of our Google Overlord :) then you might indeed consider rolling your own. I have twice before - and I'm doing it again right now: better this time, of course!
If your traffic is not very high and you're running on any decent server platform then adding a tracking system is not going to tax your Rails app noticeably (I know that depends on what 'decent server platform' means but this stuff is pretty cheap these days). Writing to a database is typically very fast - you'd have to have shedloads of clicks to not want to do this straightaway. You can probably bypass most if not all of your before_filters and so on to get a lightning response. One app that runs 2.3.9 uses Metal to do this, for example.
In my new tracking system I have an STI table that goes with models derived from an Activity model; in here you can record both impressions and clicks. Impressions are recorded as the page is built and clicks are recorded using AJAX.
I'm not going to bother with fancy graphs and so on - I'm happy with raw numbers - but these could be added, of course.
At the moment my system is just in the usual app/ folder but I'll probably move it to an engine so I can re-use it more easily.
Hope that helps!
BTW I use Google Analytics as well for a range of sites and it's OK - I just like to do this bit myself.
Depending on how you are going to associate Google Analytics data with a specific user then you might need to double-check the privacy implications. Google doesn't allow their data to be associated with any identifying information about the users being tracked.
If there is a problem then you could try out Piwik as it's open source and you can do what you like with it. It's written in PHP, not Ruby so that might be an issue. As #d11wtq mentions, tracking systems can have performance issues if not built in the right way so you'd be better off starting from something that's already proven to work if possible.