We Keep Coding

MobileApps Security Issue

I've a very compelling question to begin first. But this is not about code level, it's just for me to gauge my understanding. Correct me if i'm wrong, now days MobileApps as per design utilizes the session token method for a request.
Currently, for first time user will pass in their deviceID, pin, and timestamp for an encrypted value from the back-end. Subsequently , the front-end system will send this parameter for request and get a response success. The token has expiration date of 30 minutes.
With a recent event, hackers are able to manipulate the request from a script by spoofing. So the hackers are imitating the same behavior as from mobileapps. How do we cater for this kind of scenario? Is there a way to block these kind of request ?

Token Method
Correct me if i'm wrong, now days MobileApps as per design utilizes the session token method for a request.
I think you are referring to OAUTH2 or OpenID tokens.
OAUTH2
OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices.
OpenID
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
OpenID Connect allows clients of all types, including Web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users. The specification suite is extensible, allowing participants to use optional features such as encryption of identity data, discovery of OpenID Providers, and session management, when it makes sense for them.
Mobile App Identification to the API
Currently, for first time user will pass in their deviceID, pin, and timestamp for an encrypted value from the back-end. Subsequently , the front-end system will send this parameter for request and get a response success. The token has expiration date of 30 minutes.
Normally developers identify the mobile to the API server with a secret that is normally called api-key or some kind of named token *-token. No matter what the convention name used this is identifier is always a secret that sometimes is a simple unique string to identify the mobile app and sometimes is more sophisticated, like in your case.
With a recent event, hackers are able to manipulate the request from a script by spoofing.
The problem is that anything running in the client side can be reverse engineered
easily by an attacker on a device he controls. He will use introspection frameworks like Frida or xPosed to intercept at runtime the running code of the mobile app or will use a proxy tool like MiTM for watching the communications between the mobile app and the API server. Normally their first step in reverse engineer a mobile app will be to use the Mobile Security Framework to reverse engineer the binary of you mobile app to extract all static secrets and to identify attack vectors.
Frida
Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
xPosed
Xposed is a framework for modules that can change the behavior of the system and apps without touching any APKs. That's great because it means that modules can work for different versions and even ROMs without any changes (as long as the original code was not changed too much). It's also easy to undo.
Mobile Security Framework
Mobile Security Framework is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing framework capable of performing static analysis, dynamic analysis, malware analysis and web API testing.
MiTM Proxy
An interactive TLS-capable intercepting HTTP proxy for penetration testers and software developers.
So after using all this tools is possible for an attacker to replay all steps your mobile app does to get the token from the API server and use it afterwards to automate the attacks against the API server.
Possible Solution
So the hackers are imitating the same behavior as from mobileapps. How do we cater for this kind of scenario? Is there a way to block these kind of request?
So anything that runs on the client side and needs some secret to access an API can be abused in different ways and you can learn more on this series of articles about mobile api security techniques. This articles will teach you how API Keys, User Access Tokens, HMAC, TLS Pinning can be used to protect the API and how they can be bypassed.
A better solution can be employed by using a Mobile App Attestation solution to enable the API server to know is receiving only requests from a genuine mobile app.
A Mobile App Attestation service will guarantee at run-time that your mobile app was not tampered or is not running in a rooted/jail broken device by running a SDK in the background(without impacting user experience), that will communicate with a service running in the cloud to attest the integrity of the mobile app and the device is running on.
On successful attestation of the mobile app integrity a short time lived JWT token is issued and signed with a secret that only the API server and the Mobile App Attestation service in the cloud are aware. In the case of failure on the mobile app attestation the JWT token is signed with a secret that the API server does not know.
Now the App must send with every API call the JWT token in the headers of the request. This will allow the API server to only serve requests when it can verify the signature and expiration time in the JWT token and refuse them when it fails the verification.
Once the secret used by the Mobile App Attestation service is not known by the mobile app, is not possible to reverse engineer it at run-time even when the App is tampered, running in a rooted device or communicating over a connection that is being the target of a Man in the Middle Attack.
The Mobile App Attestation service already exists as a SAAS solution at Approov(I work here) that provides SDKs for several platforms, including iOS, Android, React Native and others. The integration will also need a small check in the API server code to verify the JWT token issued by the cloud service. This check is necessary for the API server to be able to decide what requests to serve and what ones to deny. Your current token could be used as a payload claim in the Approov Token to allow the API server to continue using it with the guarantee that was not tampered with.

Rest API security for mobile apps

I'm in the process of designing a mobile application that will need to connect to a server-side process for its business logic and data transactions. I'm writing my server-side code in Java using Spring Boot and I intend to create a Rest API in order for the mobile app to connect to the server.
I'm just doing some research at the moment for the best way to secure the connection between mobile app and server. What I'd like to do is allow the user on the mobile app to log in once they open the app and for them to use the app for as long as they like and for their access to time out after a period of inactivity.
Can anyone recommend any very simple reading on this? I've looked at OAuth2 but that appears to be for logging into web services using another account (like Google, GitHub, etc).
Would it be acceptable to login over https (SSL) by passing username and password to a rest endpoint and returning some sort of token (a GUID?). Then have the client (mobile app) pass that GUID with each subsequent call so the server can verify the call? Is it better to just do everything over SSL in this scenario?
I have done a fair bit of research but I don't seem to be able to find anything that quite matches what I'm trying to do.
Hope someone can help
Thanks

OAUTH2 IS NOT ONLY FOR WEB
Can anyone recommend any very simple reading on this?
I've looked at OAuth2 but that appears to be for logging into web services using another account (like Google, GitHub, etc).
No OAUTH2 is not only for web apps is also for mobile apps and you read this article for a more in depth explanation, but I will leave you with the article introduction:
Like single-page apps, mobile apps also cannot maintain the confidentiality of a client secret. Because of this, mobile apps must also use an OAuth flow that does not require a client secret. The current best practice is to use the Authorization Flow along with launching an external browser, in order to ensure the native app cannot modify the browser window or inspect the contents. If the service supports PKCE, then that adds a layer of security to the mobile and native app flow.
The linked article is very brief, you will need to follow the next chapters to get the full picture.
DO NOT ROLL YOUR OWN AUTHENTICATION / AUTHORIZATION SOLUTION
Would it be acceptable to login over https (SSL) by passing username and password to a rest endpoint and returning some sort of token (a GUID?). Then have the client (mobile app) pass that GUID with each subsequent call so the server can verify the call?
While you can do it I strongly advise you to use an already established OAUTH2 or OPENID connect solution, because they are developed and maintained by experts in the field and battle tested by millions of web and mobile apps using them. This enables to identify ans fix security issues much more quickly that anyone could do in their own in-house solution.
OAuth2
OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 supersedes the work done on the original OAuth protocol created in 2006. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. This specification and its extensions are being developed within the IETF OAuth Working Group.
OpenID Connect
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
OpenID Connect performs many of the same tasks as OpenID 2.0, but does so in a way that is API-friendly, and usable by native and mobile applications. OpenID Connect defines optional mechanisms for robust signing and encryption. Whereas integration of OAuth 1.0a and OpenID 2.0 required an extension, in OpenID Connect, OAuth 2.0 capabilities are integrated with the protocol itself.
So for your authentication/authorization needs I would recommend you to go with an OpenID connect solution, that leverages OAuth2 under the hood.
SSL IS ALWAYS NECESSARY?
Is it better to just do everything over SSL in this scenario?
SSL must be always used for everything, http MUST not be used at all in any situation, because once you allow an http request you are vulnerable to a man in the middle attack and I strongly recommend you to read this article from a well know security researcher, Troy Hunt, to see how even a static website must use https and he goes to a great extent to explain why and names very important attack vectors that can harm an application not using https, like WiFi hot-spots hijacking, DNS Hijeacking, Router Exploits, China great cannon, and others.
IMPROVE SSL WITH CERTIFICATE PINNING
Communicating using https is the way to go for any kind of application but developers must be aware that an attacker in control of device where the application is installed can spy https traffic by doing a man in the middle attack with a custom certificate installed in the device the mobiel app is installed, enabling this way for him to understand how the mobile app communicates with the API server in order to mount automated attacks to abuse from same API.
Certificate Pinning
Pinning is the process of associating a host with their expected X509 certificate or public key. Once a certificate or public key is known or seen for a host, the certificate or public key is associated or 'pinned' to the host. If more than one certificate or public key is acceptable, then the program holds a pinset (taking from Jon Larimer and Kenny Root Google I/O talk). In this case, the advertised identity must match one of the elements in the pinset.
You can read this article, with code sample to see how easy is to implement certificate pinning, how it can be difficult to maintain in the operational side, and with a video to see how an attacker can bypass pass certificate pinning in the client side by using Xposed framework.
xPosed
Xposed is a framework for modules that can change the behavior of the system and apps without touching any APKs. That's great because it means that modules can work for different versions and even ROMs without any changes (as long as the original code was not changed too much). It's also easy to undo.
EDIT:
Nowadays, you can use the Mobile Certificate Pinning Generator to help you with implementing certificate pinning in your mobile app:
That will give you a ready to use pinning configuration for Android and iOS:
RESEARCHING FOR A SOLUTION
Before I point you out to a possible solution I would like to make clear the distinction between 2 concepts that developers frequently are not aware off or take as being the same thing...
The Difference Between WHO and WHAT is Accessing the API Server
The WHO is the user of the mobile app that you can authenticate,authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
Now you need a way to identify WHAT is calling your API server and here things become more tricky than most developers may think. The WHAT is the thing making the request to the API server, is it really your genuine mobile app or is a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
Well to identify the WHAT developers tend to resort to an API key that usually they hard-code in the code of their mobile app and some go the extra mile and compute it at run-time in the mobile app, thus becomes a dynamic secret in opposition to the former approach that is a static secret embedded in the code.
Some Mobile API Security Techniques
I have done a fair bit of research but I don't seem to be able to find anything that quite matches what I'm trying to do.
You can start by read this series of articles about Mobile API Security techniques to understand how Https, Certificate Pinning, APi Keys, HMAC, OAuth2 and other techniques can be used to protect the communication channel between your mobile app and the API serve, and how they can be bypassed.
To solve the problem of WHAT is accessing your mobile app you need to use one or all the solutions mentioned in the series of articles about Mobile API Security Techniques that I mentioned above and accepted that they can only make unauthorized access to your API server harder to bypass but not impossible.
A better solution can be employed by using a Mobile App Attestation solution that will enable the API server to know is receiving only requests from a genuine mobile app.
A POSSIBLE BETTER SOLUTION
The use of a Mobile App Attestation solution will enable the API server to know WHAT is sending the requests, thus allowing to respond only to requests from a genuine mobile app while rejecting all other requests from unsafe sources.
The role of a Mobile App Attestation service is to guarantee at run-time that your mobile app was not tampered or is not running in a rooted device by running a SDK in the background that will communicate with a service running in the cloud to attest the integrity of the mobile app and device is running on.
On successful attestation of the mobile app integrity a short time lived JWT token is issued and signed with a secret that only the API server and the Mobile App Attestation service in the cloud are aware. In the case of failure on the mobile app attestation the JWT token is signed with a secret that the API server does not know.
Now the App must sent with every API call the JWT token in the headers of the request. This will allow the API server to only serve requests when it can verify the signature and expiration time in the JWT token and refuse them when it fails the verification.
Once the secret used by the Mobile App Attestation service is not known by the mobile app, is not possible to reverse engineer it at run-time even when the App is tampered, running in a rooted device or communicating over a connection that is being the target of a Man in the Middle Attack.
This is a positive model where false positives do not occur, thus the API server is able to deny requests with the confidence of not blocking legit users of your mobile app.
The Mobile App Attestation service already exists as a SAAS solution at Approov(I work here) that provides SDKs for several platforms, including iOS, Android, React Native and others. The integration will also need a small check in the API server code to verify the JWT token issued by the cloud service. This check is necessary for the API server to be able to decide what requests to serve and what ones to deny.
CONCLUSION
Properly securing a mobile app and the API server is a task composed of several layers of defense that you must put together in order to protect it.
How many layers to use will depend on the data your are protecting, the value it have for the business, the damage it can cause when leaked in a data breach and how much you may be penalized by law enforcement, like GDPR in Europe.

What I usually do is crafting a JSON web token (https://jwt.io/), and handle the sessions on my own.
JWT is really nice, since you only need to define a secret key on the server side. As long as your clients are able to pass the string you crafted (inside the headers for example), and as long as nobody gets to retrieve your secret key, you are sure that every data you push when creating the token was generated by you. (Don't hesitate to use the strongest encryption algorithm)

For a secure connection use HTTPS at level TLS 1.2 level. Then pin the server certificate in the app, that will prevent MITM attacks.
It is safe to pass the user name and password. You can return a time-limited token for further authentication is needed/desired.
With HTTPS everything but the address portion of the URL is encrypted. But be careful with the query string, it may end up in the server logs.

Thanks again for these replies. I've been implementing my service to run under https by using server.ssl.key-store parameters and it looks like it's working okay. I have used keytool.exe to create a trust store and I run my SpringBoot app (with Tomcat embedded) using that trust store. I can open a browser to my REST endpoint (using https this time, not http), the browser asks for authentication and when I enter my user details, it matches them against my db user and allows me to see the response from the server.
One question though, what's the point of having a trust store on the server side (Java) if I can just access the REST endpoint using any old browser and just enter my user name and password? Eventually, this REST endpoint won't be accessed via a browser, it'll be accessed using a mobile app programmatically, so I assume I'll be logging on using that with username and password over https. I thought I'd need to have a certificate of some sort on the client side in order to communicate or does it not work like this?
Thanks again

Use case of increased https security in JAVA

I am writing an application that should ensure secured connection between two parties (call them Client and Server).
Server should restrict which clients can connect using https. For this purpose, server will issue a certain number of certificates that will be checked when a client tries to connect. If the certificate that the client is using is not in trusted list, connection would not be established.
This certificate should be distributed using some kind of usb device. So when Client using my application tries to get something from server using https, application should read that certificate from usb device and USE IT to establish https connection. Private key should be kept secret on the device at all times.
So far I managed to create local keystores on client and server (JKS), add them to each other trusted list and use them to achieve proper connection.
My question is: can client certificates be issued by a server and transported to clients, all together with private key required for https connection? I dont want any data or keystore to be created on the client machine, everything required for establishing https connection should be on that device. Device could have some procedures and api to help this process and ensure secrecy of private key.
Any help will be greatly appreciated :)

can client certificates be issued by a server and transported to
clients, all together with private key required for https connection?
Technically, they can, but you're going to have to authenticate that connection by some other means if you want to make sure that private key only gets to its intended user. As far as your overall scheme is concerned, this doesn't really help. In addition by sending the private key as data to the client, they may be able to extract it one way or another.
If you can physically send a USB device, you can use a hardware cryptographic token that supports PKCS#11. Such tokens tend to have options to store a private key in a way in can't be extracted (it can only be used with the device). They tend to come in to forms: as a smart card (in which case you need a reader) or as a USB token (it looks like a memory stick, but it's not). Depending on the model, the USB token can in fact be a smart card with an embedded reader.
Java supports PKCS#11 keystores, so if this token comes with a PKCS#11 driver/library, it could be used from Java.

The normal client certificate approach to authentication doesn't work well if you don't trust the client to protect their credentials - which seems to be your scenario.
Putting the certificate on the USB device keeps it off the client machine's disk, but doesn't stop the client user from accessing it and distributing it to others. On the other hand, it reduces the risk of 3rd parties stealing the certificate from the client machine "at rest" - but only if the client protects the USB key properly. So you need to be clear about what threats you are trying to defend against, and who you trust.
The only way to make the certificate at all 'private' from the client user is to put it on some kind of tamper-resistant device, and use an approach that does not transmit the certificate to the client machine during authentication.
Compare your approach with those used for internet banking, where the customer is issued a device that can do challenge-response, using their bank card and PIN (two-factor authentication). The card details are protected from casual attack by the card's chip; but the system assumes that the client looks after their card and PIN, and reports thefts promptly (because it's their money at risk!). If the client is not motivated to look after the credentials, then this approach does not make sense.
If you just want to ensure that the client has an unsharable token, you could consider using SecurID devices, or similar, which are an off-the-shelf solution to your problem.

How to secure Android App that pulls data from OAuth protected resource

My company is building a RESTful API that will return moderately sensitive information (i.e. financial information, but not account numbers). I have control over the RESTful API code/server and also am building the Android app. I've setup the API to use OAuth 2 with authorization code grant flow (with client ID and secret), and I auto-approve users without them having to approve the client since we own both client and provider. We use CAS for SSO and I am using this for the Authorization server as part of the OAuth 2 process when the user logs in to retrieve the token.
I am contemplating various ways to secure the data on the Android app. I've concluded that storing the client id and secret on the device is definitely not going to happen, but am thinking that storing the auth token might work, since it is only risk to the individual user (and really only if they happen to have a rooted phone).
Here are two options I have thought of. They both require me to have a sort of proxy server that is CAS protected, does the dance with the API server, and returns the auth token. This gets rid of the need for storing the client id and secret in the app code.
Here are what I've come up with:
1) Require the user to enter their password to access data each time they startup the App. This is definitely the most foolproof method. If this were done, I'd probably want to save the userID for convenience, but in that case couldn't use the CAS login (since it's web-based). I might be able to use a headless browser on the backend to log the user into CAS and retrieve the token based on what they enter in the Android form, but this seems hacky. Saving the userID is similar to what the Chase app does (if you happen to use this one) - it saves the userID but not your password between sessions.
2) Store the auth token on the Android device. This is a little less secure, but almost foolproof. When the user starts the app for the first time, open the webpage to the CAS login of the proxy server that returns the token (similar to https://developers.google.com/accounts/docs/MobileApps). After the user logs in and the token is returned to the app, encrypt it and store it private to the application. Also, use ProGuard to obfuscate the code, making the encryption algorithm more difficult to reverse engineer. I could also work in a token refresh, but I think this would be more of a false sense of security.
3) Don't use CAS but come up with another way to get an auth token for the service.
Any advice of how others have implemented similar scenarios (if it's been done)?
Thanks.

Well the reason why standards like OAuth are developed is that not everyone has to rethink the same attack vectors again and again. So most often it is your best choice to stick to something already available instead of baking your own thing.
The first problem with clients that are not capable of secretly storing data is that the user's data could be accessed by some attacker. As it is technically not possible to prevent this (code obfuscation won't help you against an expert attacker), the access token in OAuth 2 typically expires after short time and doesn't give an attacker full access (bounded by scope). Certainly you shouldn't store any refresh token on such a device.
The second problem is client impersonation. An attacker could steal your client secret and access your API in his own (maybe malicious) app. The user would still have to login there himself. The OAuth draft there requires the server to do everything it can to prevent this, but it is really hard.
The authorization server MUST authenticate the client whenever possible. If the authorization server cannot authenticate the client due to the client's nature, the authorization server MUST require the registration of any redirection URI used for receiving authorization responses, and SHOULD utilize other means to protect resource owners from such potentially malicious clients. For example, the authorization server can engage the resource owner to assist in identifying the client and its origin.
I think Google are the first to try another approach to authenticate a client on such devices, by checking the signature of the application, but they are not yet ready for prime time. If you want more insight into that approach, see my answer here.
For now, your best bet is to stay on the OAuth way, i.e. having the access token, client ID and client secrect (when using the authorization code grant flow) on the device, and configure your server to do additional checks. If you feel more secure obfuscating these, just do it, but always think of it as if these values were publicly available.

android ensuring safety

I am making app, which would send value to php script. Then php script would conncect to Mysql database and return JSON array. And then the app would read it. How to ensure safety? For now I am not using any safety measures.

It depends, this is such a huge topic that a true answer would take a books worth of material.
What 'safety measures' are you asking about?
If you're talking about involving a web server, then you first need to secure your web server and build an API that is smart enough to protect against most common methods of attack. You need to make sure that other people - just by entering something in URL - cannot do the same thing your intended user can do. This means that you need to validate the user before giving them access to API.
Most common method of doing this is sharing a 'secret key' that only the server and client knows. So your user, with a phone, has a specific key and server has a key. Now user sends data to the server and also sends a validation hash (like sha1(KEY+DATA)). Server then receives data and makes sure that the hash is the same. Never send the key itself together with the request.
Another thing you need to test for are replay attacks. If someone listens in on the communication, then you have to limit the damage. This is usually done by you also sending a timestamp with the request and the server checking if the timestamp is within accepted range, so if someone sends that same request again later, it would fail due to timestamp being different. Server checks for this since timestamp is also taken into account for input data validation.
Then you have to make sure that the data returned from server is correct. So server will ALSO build a validation hash that your phone will check, making sure that someone didn't change the data while it was sent back to your phone.
As an added layer, you can also encrypt data that is sent (and received from API) with a heavy cryptography algorithm like AES/Rijndael 256bit encryption. This will encrypt data with a key that is required to open the data. If phone and server know the key and no one else does, then data can be sent securely.
Then the connection should be HTTPS/SSL, which helps protect communication from being listened in. But this does not help if someone already has access to your phone, so it is recommended to use the other mentioned methods as well.
As for your phone, it is pretty secure by itself as long as you don't have apps installed on it that might compromise that security. Also, if you think you can secure your web server less, thinking that since only phones communicate with it that it is safe, then a hacker can easily listen in on communication on their own phone and figure out the basics of your web service API and then open all the doors. So make sure your security layers go from biggest to smallest: web server is by far the biggest entity in your system.
As you can see, this is a MASSIVE topic that can take a long time to learn. But without knowing what exactly you were asking about, I cannot really help you any further.