Private API and lazy programmers

Whenever I get curious about some website or service that provides some kind of an application for a phone Android or Iphone. I get a little bit curious on how did they design their API, how does their application communicate with their services, and so on. What I found out in many curious tests is that programmers suck, they are usually lazy. They tend to get lazy fast, and do the easiest ways which are not necessarly the right way. So Yestarday I used some website which also provides an Android and an Iphone application. I got curious. Downloaded the Android version, unpacked it and started reverse engineering and undertsanding classes.dex file and how the implemented the communication to their private API. I'm sure that the programmers are either really bad or just got lazy since they thought who will want to reverse engineer our phone application and find flaws in our API? Well... me ^_^.

So we start by getting a general idea of how their code works. I usually start by seeing who calls the function that does a general communication something that sends stuff to somewhere. It's always a good place since this is what their application do. Send stuff, and get stuff from somewhere.

I find that they used AsyncHttpClient a lot so we look at who calls AsyncHttpClient.get and to get a general idea of how things look.



So those two functions are called from one place AppRestClient as AppRestClient.get for GET requests, and .post for POST requets. Anyway now we look at who calls for example to see who sends stuff and what stuff are sent and how?


This is the path to all functions doing POST requet. Let us take a look at how for example the UploadManager does uploading of images by communicating with the API.

The above simply says that the function creates a JSON object this object contains a product ID, and an imageuri. The product Id is of type int the imageuri is of two types. If the user provided an image then the image is converted to base64 and added to that json object, otherwise then it's a link that is added to the json object. Also the json object contain another member called product is a main image which is a int that acts as a boolean which specifices some property of the image, that it's a main image or whatever. Anyway this processed to the communicating with the API part. It converts the json object to a string and sends it to the api as POST data with content-type: application/json and does not check if it was sucessful or a failure. So here's the problem that I see many times. The programmer enforces rules and restrictions inside the application but the API is free to do anything. That's because the programmer is lazy or gives no shit about security. Just on this part of the API we could just encode any base64 string sends it and it will upload the data to the server no checking no ownership. So we could for example iterate over all product ids sending our own image as main page and in couple seconds we'll change all images on the server. :< that's bad. Well, what's worse is that every feature the api is capabile of that I have checked are vulnerable since it doesn't matter who owns what or who can or can't do what. The design is bad and many people who write such code doesn't care for any kind of security. I have seen this many times on many sites and apps.

This specific application uses 12 api commands all of which doesn't enforce or check the authentication of the user, but any kind of checking or whatever is happend on the application level and not on the api level.

What I have learned is that programmers don't secure the things that they assume no one will use or find out :).

Proxied content from gemini://
Get a proper gemini browser and visit!

Gemini request details:

Original URL
Status code