WL.Client.InvokeProcedure is an internal API and used by Worklight Framework, however, you can call this API after connecting a device in Debug mode with Google Chrome. How can we restrict the access to WL.Client.invokeProcedure so that a user is not able to Exploit this call?
Steps to replicate (for Exploitation Only):
1. unpack an APK built by Worklight
2. Set the android:debuggable=true (also check how WL Adapters are being called in JS files)
3. Rebuild the APK
4. Install the APK in mobile
5. Start the Application and connect through Chrome://inspect
6. Authenticate as a "normal" user
7. Go to Developer Console
8. Invoke WL.Client.invokeProcedure for any adapter you are authenticated, but with unauthorized User Data
I think the test is a bit misleading since "you" as an attacker will have several prerequisites: have the technical skill of manipulate code, invoking code and know what is a "normal" user.
That said:
In the upcoming MobileFirst Platform v7.0 you will be able to obfuscate the code of a mobile app (iOS, Android and so on). You can also do this manually now.
Already now you can enable the Application Authenticity Protection feature as well as the webResourcesChecksumTest and webResourcesEncryption features. See the security element section in the Application Descriptor user documentation topic.
The above will add several layers of protection to your application, either preventing tampering with the application code, not allowing to use the app if its checksum has change and verify the application identity.
Related
I'm currently working on fixing a connection between a MVC4 application and IBM Cognos 11 application.
Previously, when moving between the MVC app and Cognos 10.2, we would redirect the user with their authentication within the URL. This wasn't desired but was how the system was set up initially when our team received the project.
Our team has now upgraded to Cognos 11. In doing so, we've lost the usage of this previous redirect (we get an error and the user isn't authenticated into Cognos).
My question is, is there a way to authenticate a user without installing the Cognos SDK (we have it but have yet to integrate it)? I was looking into the REST URL that it uses but it appears that to consume it, I need to have the SDK to do so.
It sounds like the Mashup Service may be what you want, that's a REST-oriented interface that supports authentication and doesn't require you to install the SDK. Here's a link that discusses how to login to Mashup Service:
http://www-01.ibm.com/support/docview.wss?uid=swg21660206
I tried the URL in that technote to get a description of required credentials on a Cognos 11 environment, and found that I had to tweak it because we aren't using a gateway web server. I found I needed to add a port, and omit /ibmcognos, so the URL that worked for me was more like
http://[ServerName]:[Port]/bi/v1/disp/rds/auth/logon?xmlData=
Finally, for more doc on Mashup Service, go to
https://www.ibm.com/support/knowledgecenter/en/SSEP7J_11.0.0/com.ibm.swg.ba.cognos.ca_dg_cms.doc/c_rass_gs.html
How can i use MFP (8.0) adapter based authentication without installing mfp client sdk / libs.
Is it possible to make REST call to the adpater (login) directly from the client application (mobile) without the client sdk.
Updates:
I have tried confidential client option , but i need individual user details instead of pre-defined client id.
You can't make Adapter Based Authentication in your Client Application without MobileFirst SDK.
However this is possible only with unprotected adapter endpoint.
Security check adapters cannot be accessed via REST calls. You can protect your resources with scopes mapped to these securitychecks and they get invoked when the resources are accessed. At the client, uou handle the challenges that come from the securitychecks. This needs the MFP Client SDK to be in place. You cannot access the securitycheck adapters directly without MFP client SDK.
There are two ways for you to avoid invoking a securitycheck:
Do not mark the resource with any security. In this case default security scopes get applied. However you still need MFP client SDK to handle the OAuth handshakes.
The only other way to avoid invoking security check adapters is to explicitly mark your resources un-protected ( disable OAuth security for that resource). This will prevent any challenge answer mechanism and you can access the resource without MFP client SDK. Do note that your resources (via REST endpoints) will be open to attack - there will not be any security applied on it.
I've been looking everywhere for an answer to this, it says it goes something like server > GCM > client, the client must register and then it sends the registration token back to the server, but the 'client' part im confused about, does this only work on applications on the device? or can the app be on a website too? so for example if my app is a website, can I have the registration process on a website instead of an actual app on the device?
Yes, the currently listed client apps are Chrome, Android and iOS. Fortunately, you can use Progressive Web Apps to handle push notifications to websites.
The usual prerequisites are listed there, such as creating the Google Developer Console project, and other PWA fundamental configurations (add, register, and install Service Workers). The succeeding steps are PWA-specific implementations for you to have push notification implemented on the web page.
Happy coding!
I am using IBM MobileFirst platform 7 to develop a hybrid application for one of my clients. I am using the below environment setting to protect the app so that on app launch when it connects to the MobileFirst server, app will receive a security challenge from the server.
<iphone bundleId="com.AppTest" version="1.0" securityTest="mobileTests">
The app handles the challenge by showing the login screen to the user. I am using adapter based authentication for the app. This is working fine.
Problem with the above setup: There is a 'New user sign-up' link in the login screen that redirect the user to a sign-up screen. On load of the user sign-up screen, app is invoking an adapter procedure to get some data. The adapter procedure invoked from the sign-up screen is not protected with any security test.
Even though the adapter procedure is unprotected, the above setup doesn't allow the app to invoke the procedure before a successful user authentication. Server is throwing a challenge back to the app when the user clicks on the registration link and he stays on the login screen.
Does MobileFirst authentication framework provide any option to explicitly bypass the security check for specific resources while using environment level protection? I have gone through the platform documentation and couldn't find any such options. If anyone faced a similar problem and resolved it, could you share your suggestions on handling this please. Thanks.
The adapter procedure invoked from the sign-up screen is not
protected with any security test.
Does that mean that the specific procedure has no securityTest assigned to it? If so, you can try setting it as securityTest="wl_unprotected". Even if not explicitly setting a securityTest, there still default security assigned internally. To disable that try the mentioned wl_unprotected suggestion.
Read more here: Understanding predefined Worklight authentication realms and security tests
Setting securityTest value to wl_unprotected means that the resource
will not be protected by any of Worklight platform security
mechanisms. This security test cannot be used to protect application
environments and event sources as they both require user and device
identities. Usually this security test is used to protect adapter
procedures that should be publicly accessible without any
authentication requirements.
I've set my authenticationConfig.xml to work with LTPAAuthentication in this way:
It works well with application where i require LTPA Authentication.
But there are some apps deployed on the WL Console that not need any authentication, they just call adapters. From browser (PReview common resource) they work as well as before, but if i run them from my android i get those error on Logcat:
...................................... (all the login.html page)
It returns me the entire login.html page as it does with application that requires LTPA mobile test, here you can see the application-descriptor.xml that highlight no need of security tests:
Any suggestion?
EDIT: this is the adapter, it doesn't require security tests
So it looks like you have an adapter that you have protected using WASLTPA security that you want to be accessible by all devices regardless of whether or not they have been authenticated by the WASLTPARealm. I think the solution is to re-design how your security and adapters behave.
If you wish for an adapter to be called from an application that does not need to be authenticated, then don't protect the adapter using a security realm. If being logged into the WASLTPARealm is not a requirement for accessing the resources that this adapter is exposing, then there is no point in using the realm to protect it.
For the apps that do require login, you should separate the authentication logic from the adapter calls. You can still require the client to login in order to use the app and call adapters without having to protect the adapter with the security test. There are APIs to check if a user is logged in and to prompt them to login to a realm. You don't have to use the challenge sent back from adapter to prompt a login.
An adapter should be protected by a security test only if being logged into that realm defined by the security test is a requirement for using that adapter. From reading your post, it does not seem to be a requirement.
From browser (PReview common resource) they work as well as before, but if i run them from my android i get those error on Logcat
I have a strong feeling that in your browser you have an LTPA token which is why this is working from an app that hasn't logged in to the LTPA realm. Try clearing your cookies and trying to do this again to confirm.