Security exceptions for OutSystems Mobile App by 3rd Party

Hello Everyone,

I did a security analysis for a mobile app that I created using outsystems and I have received the following vulnerability report, would like to understand how this could be fixed (personal environment, OS 10)

1. Set debuggable flag in Andrid Manifest to be set to false

2. App uses insecure Random Number Generator

3. How do I stop all forms of logging - Debug logs, verbose logs etc

4. [MOST IMPORTANT] A hack was attempted to change data as it is being passed between objects using proxy tools (Like BurpSuite) and this was successful - how can I ensure that every retrieval or update has an authorization check (IDOR Vulnarability)

Any help would be appreciated. 


There are only a few points I can answer:

1. An app generated in Release mode would not be debug enabled. That's something you configure in the Native Platforms tab of your application, in Service Center or Service Studio.

3. I think there are a few SILK and Forge Mobile components where console logs were created during development and left there. For those I think you'd have to find and remove the code. I can't be certain here, but I don't think there is any debug logging being done by platform code.

4. From what I read, this vulnerability is caused by the developer and it is entirely dependant on business logic. General security principles apply here: apps should not retrieve data beyond that to which the authenticated user has access, since a user can easily look into the contents of their local storage. When an app tries to get, create or update data, the server must validate all of it against the user's permissions on the server-side, and this goes beyond checking if their role grants them access to a certain screen; code has to be developed explicitly to ensure that a user can't access objects he should not be able to.

Hi Tanveer,

Code analysis tools are great, but you need to know how to use them.

The reports really tell you that "MAYBE the application has this vulnerability". But this is only the starting point. To do a proper analysis of the security of the code, you have to go deeper, e.g. analyzing the code itself.

As an example of this, I have seen the warning about insecure random number generation in OutSystems mobile apps. When you look at the code, you see that this "insecure random number generation" is detected in code that manipulates elements around the screen. 

So, yes it would be "insecure random number generation" if this code was in any way related to encryption. Since it is not the case, this becomes just one more warning that shows the limits of this kind of tools.

Again, the tools are extremely helpful. But you need to know how to use them.