Skip to content

Application Security Posts

DIVA Android: Insecure Data Storage

In this post, you will see some of the common insecure methods of storing sensitive data by the Android app. The DIVA app will be used as a demonstration of these issues:

Part 1: Storing in Shared Preferences

First, you try to save a user credentials in the app. After the credentials are saved, now you can look for the location where the data is saved. For Part 1, you will notice that the credentials are saved in the app’s Shared Preferences XML file (also can be verified in the source code).

Now, look for the app’s shared preferences XML file. It should be found under /data/data/<app name>/shared_prefs

Run a cat command on this XML file and you can see the user name and password stored in plain text without any encryption. This is considered as a bad practice and can be avoided by storing the user credentials in the Keystore.

Part 2: Storing unencrypted data in SQLite

Sometimes, developer try to save the credentials or list of sensitive data in the database. This is useful as the structured data will allow faster search result. However, the developer needs to take note that the database in Android is not encrypted. This means that anyone (with root permission) can copy the database and read what is inside.

In the code snippet below, you can see that the data is stored in a database ‘ids2’.

Now, you can copy this database to your local directory (check out this site for more adb commands):

adb pull /data/data/jakhar.aseem.diva/databases/ids2 ids2.db

Open it using DB Browser for SQLite. In the myuser table, you can see the username and password. For good practices, the credentials should be at least encrypted before saving to the database. And the encryption key should be stored in the Keystore.

Part 3: Storing in unencrypted File

A developer might want to temporarily store some sensitive data in a file. If the data is stored in a plaintext file, the data might be leaked easily. It is more secure to encrypt the file if the data needs to be stored in the file.

Part 4: Storing in External Storage

Data stored in external directory can be accessed easily by any party. In addition, if the file and data is not encrypted sufficiently, then any malicious attacker can access the data. In the example, the data is stored as a hidden file ‘uninfo.txt’

You can simply just run a cat command to see this file and the credentials.

DIVA Android: Hardcoding Issues

The following post will demonstrate how to view the source code in an APK file using JADX GUI to solve the Hardcoding issues in DIVA.

First, we pull the APK file into the local directory.

Then, open up JADX GUI and select the base.apk

The APK will be decompiled and you will be able to see the source code. Now to solve the problem, you will need to find the hard-coded value in the code.

Now, for Part 2, it’s not so straightforward. If you read the code carefully, you can see that the developer is trying to compare the user input and a key from the R file. In this case, the developer is trying to store sensitive access code in the R file (which is a bad practice). Once you navigate to the R file, you should look for ‘hc2Key’ for the access code.

How to edit response in Burp Proxy?

In this post, I will show how you can edit the response in Burp Proxy. This is useful in cases where you want to demonstrate that you can inject JavaScript code in the response. I will use the domain “” to illustrate.

1) First, intercept the GET request and then click on Action button. In the menu, select ‘Do intercept’ > ‘Response to this request’.

2) Click Forward to allow the GET request to be made. Then you will notice that you can now see the response from

3) In the response, you can simply perform malicious actions such as tampering the HTML body or inserting JavaScript code into the response.

4) Finally, when you forward the edited response, the alert will appear and the body will show that it is tampered.

SQL Injection Challenge Two

This is a challenge from OWASP Security Shepherd.

In this challenge, you will notice that the application is checking for a valid email address. Once the input is validated as an email, it will use the input as part of a query. Because of this weak defence, once we managed to bypass the email validator, we will be able to perform SQL injection attacks.

The main obstacle is to form an input which is both a valid email and contains malicious value. Let’s use the hint to see how the query looks like.

For a valid email, there should not be any space in between the value. Hence the usual SQLi payload “something’ OR 1=1–” does not work here. The work around is to use || instead of ‘OR’.

Failure to Restrict URL Access Challenge 1

This is a challenge from OWASP Security Shepherd.

If you look at the POST request, there is a parameter “userData”. We can try to brute-force the values in the parameter to see if we can access the data from admin perspective.

After trying this, we will find that this brute-force does not help much as other userData values are invalid. So we need to rethink our strategy. Let’s look at the source-code now to see if we can observe any useful information.

In this snippet code, we can see that there is a submission form that is for a normal user and an admin account. Looking carefully, we can see the URL is different.

Change the URL of the POST request to the URL found in the admin account submission form and we can see that the result key will appear.

Notes on Creative Selection by Ken Kocienda

I recommend this book to learn about product development from a software engineer and designer who had worked on various important products in Apple such as Safari browser and iPhone. Below are my key takeaways from the books:

  • Demo served as the primary means to turn ideas into software.
  • This push for simplicity had a purpose. Even though he was a high-tech CEO, Steve could put himself in the shoes of customers, people who cared nothing for the ins and outs of the software industry. He never wanted Apple software to overload people, especially when they might already be stretched by the bustle of their everyday life.
  • Steve figured that the best way to answer difficult questions like these was to avoid the need to ask them.
  • Demos were fundamental to our work at Apple. We used them to highlight the potential, explore the concepts, show the progress, prompt the discussion, and drive the decisions for making our products. I started to understand how demos could play all these roles in creative and technical work when I was surprised by a single brilliant demo during my first few weeks at Apple, a moment that gave me my first real view into how the company made its software.
  • Chief among our missteps was failing to conceive of our software as a single product instead of as a set of separate projects. We never figured out how to integrate the pieces.
  • Over time, Don and I began to understand and absorb the model Richard showed us. Look for ways to make quick progress. Watch for project stalls that might indicate the lack of potential. Cut corners to skip unnecessary effort. Remove distractions to focus attention where it needs to be. Start approximating your end goal as soon as possible. Maximize the impact of your most difficult effort. Combine inspiration, decisiveness, and craft to make your demos.
  • Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
  • It represented an important technical insights: When software behavior is mysterious, get more organized.
  • People matter more than programming.
  • Steve said: “I think if you do something and it turns out pretty good, then you should go do something else wonderful, not dwell on it for too long. Just figure out what’s next.”
  • Every major feature on the iPhone started as a demo, and for a demo to be useful for us, it had to be concrete and specific. We need concrete and specific demos to guide our work, since even an unsophisticated idea is hard to discuss constructively without an artifact to illustrate it.
  • The point is that concrete and specific examples make the difference between a discussion that is difficult, perhaps impossible, to have and one that feels like child’s play.
  • We rarely had a brainstorming session.
  • If brainstorms run longer than an hour or so, or if there are more than a handful of people in attendance, or if they’re a common occurrence, they can devolve into a form of sneaky procrastination. Whiteboard discussions feel like work, but often they’re not. It’s difficult to talk productively about ideas in the abstract.
  • Literally, we couldn’t get away with telling. We were required to show. We combined some inspiration, craft, taste, and decisiveness, and we shared our results. We had to work like this, because the team didn’t accept anything unless it is concrete and specific, and a demo showing what we meant. Then we tried out each other’s demos, said what we liked and what we didn’t, and offered suggestions for improvements, which led to more demos and more feedbacks.
  • Over time, I came to the conclusion that designing an excellent user experience was as much about preventing negative experiences as facilitating positives ones. It couldn’t be an even trade-off either. Great products make people happy almost all the time and do the opposite rarely, if at all.
  • Empathy is a crucial part of making great products.
  • As a creative and technical practitioner, I couldn’t open myself to an infinite regress of ideas at every step of accomplishing a task. It’s important to keep making progress and to keep sight of priorities. That doesn’t give product designers the license to ignore philosophy. Rather, in my case, I recognized that I’m not a philosopher myself; I’m closer to a carpenter. As a maker of products, I always turned less to the theoretical and more to the applied.
  • A lack of specific thoughts isn’t a big deal when picking fruits to put on top of breakfast cereal, but such gaps are an issue in creative work. Persist too long in making choices without justifying the, and an entire creative effort might wander aimlessly. The results might be the sum of wishy-washy half decisions.
  • Building trust in a personal refined-like response takes time and practice. It also requires a measuring stick. Studying great work from the past provides the means of comparison and contrast and lets us tap into the collective creativity of previous generations.
  • The past is a source of the timeless and enduring. This is where Kant returns to the discussion, and this notion suggests how his philosophy might figure into creative work. I can use Kant , but only if I know about him, and only to the extent that I’ve internalized what he said and what it means to me.
  • The same goes for the whole scope of creative achievement, from the paintings of Frida Kahlo, the blues music of the Reverend Gary Davis, the theories of Charles Darwin, the philosophy of Lao Tzu, the software optimization ideas of Donald Knuth, or the beliefs and practices of the ancient Greek visitors to the Delphic Oracle. When I study the past, I make a point of deciding what I like, and sometimes this build-up catalog of refined-like response about past works finds a suitable outlet and a natural expression in my present-day work.
  • We used the word ‘heuristics’ to describe aspects of software development that tip toward the liberal arts. Its counterpart, “algorithm”, was its alter ego on the technical side. Heuristics and algorithms are like two sides of the same coin. Both are specific procedures for making software do what it does, taking input, applying an operation, and producing output. Yet each had a different purpose.
  • Algorithms produce quantifiable results, where progress is defined by measurements moving in a predetermined direction, as in the case of the nearly yearlong effort to improve the performance of Safari.
  • Heuristics also have a measurement or value associated with them – the duration for an animation or the red-green-blue values for an onscreen colour, but there isn’t a similar “arrow of improvement” that always points the same way. Unlike evaluating algorithms, heuristics are harder to nail down.
  • Algorithms and heuristics must coordinate to make a great high-tech product.
  • When we got an idea, we cobbled together a first cut on the algorithms and heuristics we would need to illustrate it. Then we pulled together the supporting resources – code, graphics, animations, sounds, icons and more – to produce a demo. After we showed the demo and shared some feedback with each other, we made decisions about changes that might be an improvement. Many times this came down to tuning some heuristics, or modifying how an algorithm and heuristic combined. Whatever it was, the concrete and specific modifications we chose to make led to the actions items that justified making the next demo. Repeat, then repeat again. Doing this over and over again set out projects on the slow path to accumulating positive change. This is how we started with an idea and finished with software for a product.
  • I’d like to end with a note to readers at the beginning of their careers. You might be telling yourself that you want a career in product development. You may have plans to do great things in some other fields. Either way, I have some advice: Get busy. Decide what it means to do great work, and then try to make it happen. Success is never assured, and the effort might not be easy, but if you love what you’re doing, it won’t seem so hard.
  • There weren’t any company handbooks describing these elements. Nobody outlined this list in a new-employee orientation. This list was distilled from the everyday work at Apple.
    • Inspiration: Thinking big ideas and imaging what might be possible
    • Collaboration: Working together well with other people and seeking to combine your complementary strengths
    • Craft: Applying skill to achieve high-quality results and always striving to do better.
    • Diligence: Doing the necessary grunt work and never resorting to shortcuts and half measures.
    • Decisiveness: Making tough choices and refusing to delay or procrastinate.
    • Taste: Developing a refined sense of judgment and finding the balance that produces a pleasing and integrated whole.
    • Empathy: Trying to see the world from other people’s perspectives and creating work that fits into their lives and adapts to their needs.

Basic Hands-on with iOS App Development

Before performing source code review, you should get some hands-on experience with developing an iOS application. In this post, I will show you some of the possible steps to get started. You will spend roughly 30 hours on developing some iOS applications and learning some of the common libraries in Swift 5.

Initial Readings – 6 hours

Read App Development with Swift

Build a Simple iOS application – 4 hours

Now it is time to write some code. The purpose of this exercise is to understand the basic structure of an iOS application such as:
– Learn how to link UI objects (e.g. UIImage, Buttons, Sliders etc.) in the Main Board to the View Controller
– Learn how the function in the ViewController can update the UI objects values.
– Naming UI objects
– Uploading images into Assets.xcassets directory
– Learn to initialise variables in Swift.
– Differentiate between ‘var’ and ‘let’ declaration (var is used to initialise the mutables while let is used for declaring constant)

Example of a simple Dice app (that changes randomly on every roll) from iOS Boot Camp

Build an intermediate iOS application – 8 hours

Build an application which stores data locally. The types of data should also include sensitive data such as username and password.

Purpose of UserDefaults. The data is saved as plist. This is not a database. Just use it to learn small kb of data and not for large amount of data.

Data Storage Methods:
1. UserDefaults
2. Encode Data into plists
3. Keychain (An API to store sensitive data (e.g. username, password etc.) securely
4. SQLite
5. Core Data (Object Oriented Database)
6. Realm

Build another intermediate iOS application – 12 hours

Recommended Resources:


Intro to iOS Application Security

<Draft version>
The purpose of this blog series is to help an Application Security engineer to learn enough about iOS application security in order to perform source code review. The posts will also require hands-on testing as this will increase understanding of the vulnerabilities.


  • iOS Application Security
  • iOS Hacker’s Handbook
  • Advanced Apple Debugging & Reverse Engineering
  • Mac OS X and iOS Internals
    • Volume I: User Mode (v1.3)
    • Volume II: Kernel Mode
    • Volume III: Security & Insecurity
  • The Mobile Application Hacker’s Handbook
  • OWASP Mobile Application Security Verification Standards (MASVS)
  • OWASP Mobile Security Testing Guide (MSTG)
  • Apple Secure Coding

Blog On Application Security

This blog will cover related topics in Application Security such as:

  • iOS Application Security
  • Android Application Security
  • Web Security
  • Cloud-related topics to Appsec
  • IoT-related topics to Appsec
  • Bug Bounty
  • DevSecOps
  • Security Testing Tools
  • Network Security Related topics to Appsec
  • Python related topics to Appsec