[TIMOB-18709] iOS: Incorrect fallback in Authentication Challenge
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Critical |
Status | Closed |
Resolution | Needs more info |
Resolution Date | 2015-03-24T17:23:29.000+0000 |
Affected Version/s | n/a |
Fix Version/s | n/a |
Components | iOS |
Labels | n/a |
Reporter | Giorgos Papadopoulos |
Assignee | Vishal Duggal |
Created | 2015-03-17T12:21:45.000+0000 |
Updated | 2017-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.
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.
Regarding the code referenced above,
performDefaultHandlingForAuthenticationChallenge
is an optional method in theNSURLAuthenticationChallengeSender
protocol. If the sender implements the protocol, we invoke that method else we invoke the required methodcontinueWithoutCredentialForAuthenticationChallenge
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 thesecurityManager
property on the Ti.Network.HTTPClient object. Appcelerator also provides theappcelerator.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"Closing ticket due to the information that was requested not being provided.