> For the complete documentation index, see [llms.txt](https://docs.talsec.app/appsec-articles/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.talsec.app/appsec-articles/articles/how-to-hack-and-protect-flutter-apps-steal-firebase-auth-token-and-attack-the-api.-pt.-3-3.md). # How to Hack & Protect Flutter Apps — Steal Firebase Auth token and attack the API. (Pt. 3/3) *JWT Token, MiTM Attacks and API Protection. Keep them properly protected and don’t put your enterprise at risk.* *Part 1 (*[*link*](/appsec-articles/articles/how-to-hack-and-protect-flutter-apps-simple-and-actionable-guide-pt.-1-3.md)*) ↓* * Disassemble app. * Extract its secrets. *Part 2 (*[*link*](/appsec-articles/articles/how-to-hack-and-protect-flutter-apps-owasp-mas-and-rasp.-pt.-2-3.md)*) ↓* * Make a fake clone. * Check every transmitted JSON. * Inject code. *Part 3 (this article) ↓* * **Steal authentication tokens.** * **and attack the API.**

How to Hack and How to Protect Flutter Apps

### First things first. JSON web tokens. A token is a piece of data that represents a specific identity or authorization. There are different types of tokens, including authentication tokens, which are used to authenticate a user’s identity, and bearer tokens, which grant access to a protected resource. JWT, or JSON web tokens, are types of tokens used for authenticating and authorizing users. These tokens are encoded and signed, allowing the server to verify their authenticity. However, JWT tokens can be vulnerable to certain attacks, such as weak token signing and token tampering. Weak tokens are tokens that have been compromised or are otherwise insecure. This can include tokens with weak or easily guessable signing keys, or tokens that have been stolen or otherwise obtained by an attacker. These weak tokens can be used to gain unauthorized access to a system or a protected resource. The JWT standard allows the non-use of an algorithm (”alg”:”none”) to sign the token. This is of course a very bad practice. A user could change his rights on the fly (from “role”: “user” to “role”: “admin”), without any control by the server. In the same way, if the configuration carried out at the server level accepts different algorithms and the “none” variable, which consists of not having cryptographic functions, it will be possible for an attacker to bypass the integrity verification function to access the data of other users or even of the admin. This can be mitigated by choosing a reliable algorithm (SHA256) and force server to always check algorithm, and therefore reject the “none” variable.

Example of JWT (source: https://jwt.io/introduction)

### Firebase Authentication Firebase Authentication is Flutter Apps’ most favorable authentication service. It allows developers to easily integrate user authentication into their applications using a variety of authentication methods, such as email and password, phone number, or social media accounts like Google, Facebook, and Twitter.

When a user signs up for an account using Firebase Authentication, the service generates an authentication token that is associated with the user’s account. This token is then stored on the user’s device and is used to verify their identity whenever they access the application. When the user attempts to log in to the application, the authentication token is sent to the Firebase Authentication server, where it is verified and then passed back to the application. If the token is valid, the user is granted access to the application.

## How to steal Firebase authentication token Now, if you’ve read the previous section carefully, you already know what we are after: > This token is then stored on the user’s device… I want to emphasize that storing this token is a completely appropriate solution assuming the device’s sandbox and other security measures are intact. ### Step 1: Demo app This hello-world Flutter app is connected to Firebase Authentication. A few widgets, some copy-pasting from the Firebase tutorial, and it was up and running:

Once I registered my new account, I checked the account exists as well in Authentication Dashboard:

Everything works well, I am signed in

### Step 2: Extraction of JWT Sorry, I won’t show you any zero-day vulnerability. I assume there is a vulnerable system at play or a malicious 3rd party library (yes, 3rd party dependencies can interfere with app’s data and [more](https://nakedsecurity.sophos.com/2017/08/15/how-shared-android-libraries-could-be-weaponized-for-data-theft/)), which will steal data **from within your application**.

Locate the app’s data directory `/shared_prefs`, which contains a file named `com.google.firebase.auth(…)` .

The file has the following content:

I moved the content to my computer for easier manipulation. The highlighted text is Firebase Authentication JWT:

TIP: You can use fancy JWT viewer — jwt.io:

And here is the data:

An attacker could misuse this token for an impersonation attack. But to be able to make such an attack, it’s necessary to know the API. Let’s explore the API of the Flutter app. ## Attack the API ### How to do API attacks in a nutshell An API attack is a type of cyberattack in which an attacker exploits vulnerabilities in an API in order to gain unauthorized access to sensitive data or systems. Here are some examples of how a reverse engineer might carry out an API attack: 1. Sniffing: The attacker captures network traffic containing API requests and responses in order to extract sensitive information such as passwords or access tokens. This can be done using tools like Wireshark or Burp Suite. 2. Injection: The attacker modifies the API request in order to inject malicious code into the system. This can be done using techniques like SQL injection or cross-site scripting (XSS). 3. Tampering: The attacker modifies the API request in order to alter the data being transmitted, such as changing the value of a transaction or account balance. 4. Replay: The attacker captures a valid API request and then replays it multiple times in order to cause a denial of service (DoS) attack or gain unauthorized access to the system. These are just a few examples of API attacks that a reverse engineer might carry out. To attack the API of a mobile app, a reverse engineer would need to first identify the API and its associated vulnerabilities. This can typically be done by using a tool to intercept network traffic from the mobile app and analyzing the requests and responses to and from the API. Once the API has been identified, the reverse engineer can attempt to exploit any vulnerabilities that are found. For example, if the API is not properly validated or sanitized, the reverse engineer could try injecting malicious code into the request in order to gain unauthorized access to the system or steal sensitive data. Other tactics that might be used in an API attack on a mobile app include tampering with requests in order to alter data, capturing and replaying requests in order to cause a denial of service (DoS) attack, and sniffing network traffic to extract sensitive information. ### Discover API architecture from Flutter app * **strings** — You can use `strings` command available in many Linux distros to gather string resources from any Flutter app: `$ strings my-flutter-app.apk | grep http` to gather URLs * **GraphQL architecture** — You can find GraphQL queries in the app’s binary ```graphql query { user(id: "123") { name email posts { title content } } } ``` * **REST architecture** — You can use `strings` or Burp Proxy (MITM) again. Common APIs can be found [here](https://github.com/danielmiessler/SecLists/blob/master/Discovery/Web-Content/api/api-endpoints.txt). The web service may also have it’s OpenAPI (Swagger) documentation available. ``` /api/v1/account/user/verify /api/v1/analytics/events /api/v1/articles.json /api/v1/asset/asset /api/v1/asset/assets /api/v1/auth ``` I decided to end this article here as there is a plethora of API hacking tutorials: ## Actionable steps for app owners 1. Check of your Firebase is properly configured: 2. Glance over the **Resources** section of this article and check out one of the provided cheatsheets (the most relevant to your app) 3. IMPORTANT: Majority of network attacks (impersonation, malicious scripts, botnets, JWT stealing, etc.) can be defeated by Talsec’s unique technology [AppiCrypt](https://www.talsec.app/appicrypt). Check it out! Thank you for reading the third part of this guide. I hope the information I’ve provided has been useful and informative! Thank you again for joining me on this journey. *written by Tomáš Soukal, Security Consultant at Talsec* *** ## Resources It would be impossible to provide tutorial for every possible mobile app + web service architecture. Hence, I compiled useful list of OWASP and other resources about web application security. Use the list below to find quickly technologies and guides related to your use-case. ### Latest ASVS {% embed url="" %} ### Pinning {% embed url="" %} ### Injection {% embed url="" %} ### Transaction authorization {% embed url="" %} ### Credential Stuffing Prevention {% embed url="" %} ### REST Security Cheat Sheet {% embed url="" %} ### Authentication Cheat Sheet {% embed url="" %} ### Forgot Password Cheat Sheet {% embed url="" %} ### Session Management Cheat Sheet {% embed url="" %} ### Weak Token {% embed url="" %} ### SSRF {% embed url="" %} ### File Upload Security {% embed url="" %} ### Input Validation Cheat Sheet {% embed url="" %} ### **GraphQL Cheat Sheet** {% embed url="" %} ### Query Parametrization {% embed url="" %} ## AWS Security {% embed url="" %} ### AWS Misconfigurations {% embed url="" %} {% embed url="" %} Firebase security checklist {% embed url="" %} Misconfiguration of Firebase — world readable Exploit tool for this vulnerability: {% embed url="" %} *A simple Python Exploit to Write Data to Insecure/vulnerable firebase databases! Commonly found inside Mobile Apps. If the owner of the app have set the security rules as true for both “read” & “write” an attacker can probably dump database and write his own data to firebase db.*\ [
](https://www.crowdstrike.com/cybersecurity-101/cloud-security/common-aws-misconfigurations/?source=post_page-----8693c2361468--------------------------------)[
](https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/?source=post_page-----8693c2361468--------------------------------)Control Access with Custom Claims and Security Rules | Firebase Authentication {% embed url="" %} Verify ID Tokens | Firebase Authentication {% embed url="" %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.talsec.app/appsec-articles/articles/how-to-hack-and-protect-flutter-apps-steal-firebase-auth-token-and-attack-the-api.-pt.-3-3.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.