I would like to set up some end-to-end tests to make sure my Google Sign In button is working. I'd like to use tools such as:
Cypress web tests
Datadog live monitoring
Mobile E2E tests
to ensure my set-up works.
Is it possible to whitelist certain requests from Google's bot detection? Either by IP or header etc?
I believe with Cypress there is a way of mocking the responses to fix this issue, but with more 'black-box' testing like the other approaches, this isn't possible.
Related
I've read a lot of articles on this subject and they all suggest completely different things that I can't yet structure in my head.
I have one backend app (spring-boot + kotlin). I have nginx and one android (kotlin) mobile app uses backend api and of course Postgres. By the way backend app and postgres are packages in docker containers via docker-compose.
My task is to make the API of my backend service can only be used by this mobile application and no one else. But I also want it to be able to use the API if I have a Web application in the future.
I would be fantastically grateful if you could describe, in a few words, modern technology that could be used to accomplish my task.
For example:
Spring-security: a huge thing that you don't know what to do with, most likely you can use it to solve your problems, but it's overkill. But if you decide to use spring-security, this will help you {...}
...
By the way, I'm not against spring-security, I just really think it's too much for my task. But I'd be happy to hear your opinion.
Your Problem
My task is to make the API of my backend service can only be used by this mobile application and no one else. But I also want it to be able to use the API if I have a Web application in the future.
You have in hands a very hard task to complete. While not impossible it's very hard to accomplish with code written on your own or by trying to leverage security features on your framework of choice.
To understand why it's so hard you first need to understand the difference between who is in the request versus what is doing the request.
The Difference Between WHO and WHAT is Accessing the API Server
I wrote a series of articles around API and Mobile security, and in the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between who and what is accessing your API server, but I will extract here the main takes from it:
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
So think about the who as the user your API server will be able to Authenticate and Authorize access to the data, and think about the what as the software making that request in behalf of the user.
After you understand this idea and it's ingrained in your mindset, you will look into mobile API security with another perspective, and you will be able to see attack surfaces that you never though they could exist.
Possible Solution
I would be fantastically grateful if you could describe, in a few words, modern technology that could be used to accomplish my task.
I recommend you to read this answer I gave to the question How to secure an API REST for mobile app?, especially the sections Hardening and Shielding the Mobile App, Securing the API Server and A Possible Better Solution.
The best approach to solve your problem is to go with a Mobile App Attestation solution suggested in the answer I linked. A Mobile App Attestation needs to be able to work in tandem with your mobile app and backend in order for the backend to have a very high degree of confidence that what is making the request is indeed a genuine version of your mobile app, that hasn't been tampered with statically or at runtime, and it's not under a
MitM Attack
The Manipulator-in-the middle attack (MITM) intercepts a communication between two systems. For example, in an http transaction the target is the TCP connection between client and server. Using different techniques, the attacker splits the original TCP connection into 2 new connections, one between the client and the attacker and the other between the attacker and the server, as shown in figure 1. Once the TCP connection is intercepted, the attacker acts as a proxy, being able to read, insert and modify the data in the intercepted communication.
The MITM attack is very effective because of the nature of the http protocol and data transfer which are all ASCII based. In this way, it’s possible to view and interview within the http protocol and also in the data transferred. So, for example, it’s possible to capture a session cookie reading the http header, but it’s also possible to change an amount of money transaction inside the application context
Be aware that solutions to solve your problem that are specific to the backend or to the mobile app will not be able to achieve a very high degree of confidence in securing your API backend from serving requests not originated from your genuine mobile app, but it's better to have them then nothing.
Do You Want To Go The Extra Mile?
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
For APIS
OWASP API Security Top 10
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
For Mobile Apps
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
The easiest way probably is to define a shared secret on the phone and the backend service.
On the mobile phone, with each request, you send the secret, e.g., as an HTTP header.
On the backend, you need to implement a Filter (e.g., OncePerRequestFilter) that checks the request for the secret and compares it to the value stored in the backend.
I have recently started using JMeter and I'm still trying to get to grips with it. I am trying to use JMeter to performance test Dynamics CRM. I have created a test plan and included a thread group with the HTTP authorization manager. I have added an HTTP Request and set the path to the 'homepage'. This appears to be working, but when I try some other requests I am getting the following response body :
'Important: Microsoft Dynamics CRM makes extensive use of your Web browser's client-side abilities. You either have one of these features turned off or your security settings are set so high that they prevent these features from being used. To enable these features, change your browser settings to allow the Microsoft Dynamics CRM site to run JavaScript. '
My question is how can I configure JMeter to avoid this error? As far as I understand, JMeter it does not make use of a browser unless you're recording a test script so I'm unsure how I can change settings.
It seems that Dynamics uses a lot of browser-side JavaScript. JMeter has a plugin which can execute this JavaScript.
However...you will need to be fairly sophisticated in what you measure. The performance of the JavaScript will depend on your test hardware, and won't represent what "normal" users see - you're testing the performance of JavaScript in a browser, rather than the Dynamics server.
An alternative would be to look at the calls the JavaScript makes to server-side resources, and capture those as JMeter calls. This does mean reverse-engineering the application logic to understand how the Dynamics client-side application interacts with the server.
I have developed a bot that I want to test.
Due to few discussions (Conversations.SendToConversationAsync crashes on Unit testing) it seems that an approach is to make use of Direct Line. The bot must be hosted locally, so that the sent messages can be captured and evaluated on the bot. On this point, I am not sure about two aspects.
Isn’t there any alternative way to do functional test?
I was planning to do the functional test on the localhost using Emualtor and Visual Studio. Checking this github page (https://github.com/Microsoft/AzureBot/tree/master/AzureBot.Tests) I understand that a test case can be converted into a code in an easy way writing down an action and its expected reply.
However I don’t understand the requirement and benefits of using Direct Line for the functional test?
So you want to test your bot:
you want to automate your tests, and this is possible with Direct Line as you can write your own test client and define your own test logic. This is what https://botmonkey.io is doing, they can connect to your bot via Direct Line and run tests.
I don't think you can write automated tests via Skype channel or via other channels other than Direct Line.
Off topic but with Direct Line you can develop your own bot client using your own web stack or mobile stack. You can also send custom payloads and render your own cards with your own data and not be limited with bot framework's hero cards which accept only limited number of properties: (title, subtitle, text, image)
We have been writing our mobile app tests with Calabash/Xamarin.UITest for a while using backdoor methods to redirect our app's base api url to a mock HTTP server to make tests repeatable without incurring unnecessary server costs.
As Xamarin has announced they are phasing out Calabash (and Xamarin.UITest with it, as it relies on the Calabash server component) we have been working on migrating our test suite to Appium to comply with Xamarin's recommendations. Our simpler tests were migrated easily but a lot of our testing relies on said mock HTTP server with backdoor configuration which Appium does not seem to support, rendering our tests impossible to port without a way to recompile our app with the mock HTTP server address built in, which quite frankly, sucks.
Anyone knows an alternative to said backdoor method? Or an alternative to the whole mock HTTP server overall?
We want our tests to run in parallel in the Xamarin Test Cloud service so issuing a QA/Test environment for this is completely undesirable.
Helow
Is it possible to use Jmeter to make a performance test on a mobile app which doesn´t connect to internet, such as calendar or calculator; an app that doesn´t use http protocol?
Thank you.
No.
JMeter acts on protocol level, it doesn't actually clicks links or buttons, it sends requests over variety of supported protocols (not limited to HTTP) and records response times.
If your application doesn't have a backend, i.e. it is completely standalone, you normally don't need to load test it as it won't have more than one user. The only thing you can do is to check resources impact like CPU or RAM usage, battery consumption, most long running code parts, etc. Check out the following materials:
Android Performance Profiling Tools
iOS App Performance: Instruments & beyond
Performance Profiling on Windows Phone 8.1 with Visual Studio
For more detailed explanation of the concept of simulating multiple non-browser applications users check out How to Run Performance Tests of Desktop Applications Using JMeter guide.
You don't need internet connection in order to test like a local website, service or app. And yes, it is possible.
If your app is locally then the app will be available on a localhost port ( db, api, website). If you plan to test from the UI perspective a mobile or desktop app then you are using the wrong tool and you should use other tools like Ranorex or Test Complete.