2

i'm using HTTPS in my iPhone app to communicate with my own API.

I've noticed that when i try to do packet sniffing on an HTTPS it won't show any critical information. but when i tried Fiddler2 and installed a trusted certificate on my iPhone (which was issued by Fiddler2) I've been able to see all my HTTPS calls!!! which can cause a serious security problem.

I've tried this with other applications and some of them won't show even anything in Fiddler as if they were protecting themselves somehow!

how can i protect my application?

Thanks


--- Extra information to the selected solution ----

if you are using AFNetworking, starting from version 1.1 you can do the following to solve the issue:

add the following to your PROJECT-Prefix.pch

#define _AFNETWORKING_PIN_SSL_CERTIFICATES_ =1

make sure you have added the security framework then import it in the AFURLConnectionOperation.m file

#import <CommonCrypto/CommonDigest.h>

add this extra function to the file

-(NSString*) sha256:(NSString*)input
{
    const char *cstr = [input cStringUsingEncoding:NSUTF8StringEncoding];
    NSData *data = [NSData dataWithBytes:cstr length:input.length];

    uint8_t digest[CC_SHA256_DIGEST_LENGTH];

    CC_SHA256(data.bytes, data.length, digest);

    NSMutableString* output = [NSMutableString stringWithCapacity:CC_SHA256_DIGEST_LENGTH * 2];

    for(int i = 0; i < CC_SHA256_DIGEST_LENGTH; i++)
        [output appendFormat:@"%02x", digest[i]];

    return output;
}

replace this line

if ([[[self class] pinnedCertificates] containsObject:certificateData])

with this one

if ([[self sha256:[certificateData description]] isEqualToString:SSL_CERTIFICATE_SHA256])

make sure you've calculated the SHA256 of the server's certificate and define the value in your prefix file

#define SSL_CERTIFICATE_SHA256 @"<certificate SHA256 value>"

done!

Kassem
  • 1,481
  • 3
  • 20
  • 42

1 Answers1

3

So you are using Fiddler2 as a proxy for your iPhone. All requests will then pass through fiddler. Fiddler will act like it's the end point and will return the certificate that was trusted by you. Then it will forward the request to the actual url using a new request. Therefore it's able to read the response. Then it will return the data in the original request. If you want to prevent this in your app, then you have to add your own certificate validation. You could check the certificate on binary level or parse the certificate and validate the fields (like issuer)

I found this tutorial with information about testing certificates http://www.inmite.eu/en/blog/20120314-how-to-validate-ssl-certificates-iOS-client Maybe this could also help: http://www.cocoanetics.com/2013/02/rfc-dtcertificateviewer/

You could also add an extra level of security by adding your own encription layer. The server needs to respond with encripted data and you will then decrypt that response.

Edwin Vermeer
  • 13,017
  • 2
  • 34
  • 58
  • 1
    Note that all of this can be defeated by anyone with a jailbroken phone. They can attach a debugger to the app either modify it to not care about the certificate, replace your certificate with their own, or just print out the traffic from within the app. There is no way for you to know that only your application is connecting to your server. If that is a security problem for you, then you need to redesign so that it is not a security problem, or accept that you have a security problem. See http://stackoverflow.com/questions/9181186/secure-https-encryption-for-iphone-app-to-webpage for more. – Rob Napier Mar 08 '13 at 22:03
  • This is not to say that the above is not a reasonable piece of obfuscation to add. It is, and it's good for security for various other reasons. But don't imagine that it is protecting your vulnerable API. (In all this I assume by "security problem" you mean "security of *your* information." That is not solvable if you send that information to the client. If by "security problem" you mean "security of the *user's* information" then there are many good solutions to that problem, all starting with authenticating the user.) – Rob Napier Mar 08 '13 at 22:04