Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-18709] iOS: Incorrect fallback in Authentication Challenge

GitHub Issuen/a
TypeBug
PriorityCritical
StatusClosed
ResolutionNeeds more info
Resolution Date2015-03-24T17:23:29.000+0000
Affected Version/sn/a
Fix Version/sn/a
ComponentsiOS
Labelsn/a
ReporterGiorgos Papadopoulos
AssigneeVishal Duggal
Created2015-03-17T12:21:45.000+0000
Updated2017-03-22T22:35:18.000+0000

Description

It seems like the implementation of the authentication challenge on https://github.com/appcelerator/APSHTTPClient/blob/master/APSHTTPClient/APSHTTPRequest.m is not done properly. Specifically in this part:
if (!handled) {
        if ([challenge.sender respondsToSelector:@selector(performDefaultHandlingForAuthenticationChallenge:)]) {
            [challenge.sender performDefaultHandlingForAuthenticationChallenge:challenge];
        } else {
            [challenge.sender continueWithoutCredentialForAuthenticationChallenge:challenge];
        }
    }
Whenever an error occurs by the validation (for example when the server gives back a wrong certificate), Titanium fallbacks to the standard certificate checks bypassing the desired and given certificate pinning. This bug has successfully reproduced by installing our own CA-certificate in a test device and thus bypassing the check with the certificate of the server and being able to perform a man in the middle attack.

Comments

  1. Vishal Duggal 2015-03-17

    Is the appcelerator.https module being used? The https module is specifically designed to check server certificates during the ServerTrust handshake to prevent the Man In Middle attack.
  2. Vishal Duggal 2015-03-24

    Regarding the code referenced above, performDefaultHandlingForAuthenticationChallenge is an optional method in the NSURLAuthenticationChallengeSender protocol. If the sender implements the protocol, we invoke that method else we invoke the required method continueWithoutCredentialForAuthenticationChallenge in the sender which attempts (but does not guarantee) to continue downloading without authentication. I believe this is implementation is correct. Regarding the test scenario presented here, by installing the certificate on the device the developer has explicitly asked the OS to trust that particular certificate. The system will not differentiate between self signed certificates and certificates from established CA authorities. It is upto the developer to perform checks to ensure that the certificate presented by the server is trust worthy. To that end we have exposed the securityManager property on the Ti.Network.HTTPClient object. Appcelerator also provides the appcelerator.https module that implements server certificate pinning and can be used with the HTTPClient object. The developer is of course free to implement their own module and use it with the HTTPClient object. It is unclear from the description of the bug what the setup is or if the module was even used. If the bug is filed against the HTTPClient object, then I believe that this is an invalid issue. If this is filed against the module and claims that the module is not behaving as expected, then we need sample code that demonstrates the issue. Either ways we have very little to move forward on. Resolving this as "Needs More Info"
  3. Lee Morris 2017-03-22

    Closing ticket due to the information that was requested not being provided.

JSON Source