That's a rather broad question. Given you've posted on this mailing
list, I'll answer purely from a security perspective and also only
from the perspective of your App:

Also assuming your App (the fat client) is running on a phone that is
not jailbroken and the App has been obtained via the App Store (and
thus has been analysed and allowed by Apple, so it "shouldn't" allow
easter eggs)...

To mitigate potential man-in-the-middle attacks, pull the JSON data
over a secure channel (HTTP + SSL/TLS = https). iOS won't allow
connections using self-signed certificates, unless you add other
authorities.

The fat client should not trust data from the cloud, so it would be
best to validate data before using it within logic. That's to help
prevent logic attacks.

Then, depending on the context in which the data is to be used you may
need to ensure there's no chance of, say, SQL injection within a SQL
query or XSS in a UIWebView, for examples.

Beyond that, you certainly shouldn't store any sensitive data in
keychains as that data will persist beyond the lifetime of your App
(if your App is ever uninstalled).

Hope that helps,

Linden

Still from a broad security perspective.

The fact that you're writing the application in Objective-C plays for you. Indeed, while JSON by itself is neither safe/secure nor unsafe/unsecure, JSON-manipulation libraries in JavaScript often rely on an [eval()] as a fallback for compatibility with older browsers, and this is a very good place to attack an application. Many JSON-manipulation libraries in other dynamic languages rely on the same kind of tricks ([setattr()], etc.), providing the same kind of attack vector, but without the JavaScript sandbox, which makes them even better candidates for attacks.

Now, afaik, there is no such unsafe/unsecure JSON-manipulation library in Objective-C. However, the usual precautions still apply: don't use [char*] (good candidate for attack), only [NSString] (much more robust, not to mention more convenient), etc. – and ensure that your JSON library does the same.

Hope this helps,
David

On Mar 10, 2011, at 2:45 AM, WebAppSec@CoreForm wrote:

--
David Rajchenbach-Teller
Head of R&D
MLstate

Linden,

I agree with everything you said except the comment you made about
mitigating mobile MiTM attacks by using SSL and the "iOS won't allow
connections using self-signed certificates, unless you add other
authorities" statement.  I have successfully MiTM'd a number of iOS
applications pulling JSON data over HTTPS simply by using a transparent
proxy (e.g. Mallory*).  If you want to stop this then you need to hard
code the certificate check into your iOS application like a number of
banking iOS applications already do so.

*<plug>
http://blog.tomneaves.com/post/3523418896/using-mallory-and-airbase-ng-t
o-mitm-mobile </plug>

Cheers,
Tom

From: websecurity-bounces@lists.webappsec.org
[mailto:websecurity-bounces@lists.webappsec.org] On Behalf Of
WebAppSec@CoreForm
Sent: 10 March 2011 01:45
To: application.secure@gmail.com; websecurity@webappsec.org
Subject: Re: [WEB SECURITY] json, iphone, objectivec

That's a rather broad question. Given you've posted on this mailing
list, I'll answer purely from a security perspective and also only from
the perspective of your App:

Also assuming your App (the fat client) is running on a phone that is
not jailbroken and the App has been obtained via the App Store (and thus
has been analysed and allowed by Apple, so it "shouldn't" allow easter
eggs)...

To mitigate potential man-in-the-middle attacks, pull the JSON data over
a secure channel (HTTP + SSL/TLS = https). iOS won't allow connections
using self-signed certificates, unless you add other authorities.

The fat client should not trust data from the cloud, so it would be best
to validate data before using it within logic. That's to help prevent
logic attacks.

Then, depending on the context in which the data is to be used you may
need to ensure there's no chance of, say, SQL injection within a SQL
query or XSS in a UIWebView, for examples.

Beyond that, you certainly shouldn't store any sensitive data in
keychains as that data will persist beyond the lifetime of your App (if
your App is ever uninstalled).

Hope that helps,

Linden

Verizon UK Limited - registered in England & Wales - registered number 2776038 - registered office at Reading International Business Park, Basingstoke Road, Reading, Berkshire, UK RG2 6DA - VAT number 823 8170 33

On Friday 11 March 2011 14:20:14 Neaves, Tom wrote:

Tim

Tim Brown
mailto:tmb@65535.com