Safe Connections for Apps

It isn’t rare that Android Play Store classifies the Apps for maturation time. Fixing application bugs is a constant work. But, we can fix some security bugs when making connections with the server.

Generally the amateur programmers think that no one may try to hack their code because the information isn’t “important”, or because it is simply impossible to hack (for lack of knowledge).

When we create a connection App–API (server), we do internal connections sending data or getting request.

The Representational State Transfer or REST is a type of web development architecture that relies totally on the standard HTTP.

REST allows us to create services and applications that can be used by any device that understand HTTP, so that’s why it is incredibly simple and conventional compared to other alternatives such as, SOAP or XML-RPC.

By using a single REST request header we can develop applications quickly but with  vectors for attack.

An amateur programmer could use basic http request without ssl believing that other people won’t realize, or that it isn’t necessary because the information handle by the app is not private.

If a hacker connects to a net (such as coffee bar net) they can divert the net traffic to their computer.

An attacker enables the router and type to evade the detection of intruders system. Then the attacker can change the ARP table (ARP positioning). When an IP is not found on the table, they send the IP to all devices (broadcast) and the device sends his MAC Address.
Now, the net traffic can pass through the device of the attacker (Man In The Middle), and then send data without the user suspecting it.

The most common hacks are intended to obtain messages, images or log in credentials. If we don’t build a secure application this can affect the application users and impair our business.
If our application doesn’t send credentials and only requests information it doesn’t seem dangerous, but the attacker could know how to operate our API server such as shown on the previous print-screen, the data package shows the Request URL, headers and parameters.
This information can be used to send custom request, and to get data for custom applications, malicious applications (in order to steal information, access the device etc).

Once the attacker is a “Man in the middle”, he can act as a Fake DNS server (or dns spoof),  the DNS is used for a domain name resolution converting for example webstreaming.com.ar to an IP address, 104.236.3.236. By compromising the protocol, the attacker could re direct someone looking for a domain name to his malicious website for example activating an apache server, only to send similar replies obtainecd from the stoled packages.

Depending on how the application is programmed., the hacker can steal information, apply Social Enginne to get personal information, user credentials, install malicious applications etc. If some data is used directly on SQL statement (a serious programing mistake), it can allow SQL injection to update or delete data. Or for example, save data to change our app functionality as redirecting it to another server, the possibilities are tons.

The fake data not only allows to mislead the user but they can also be a vector to detect vulnerabilities, to crash the application, denial of service, or memory corruption among other things.

But once having the information from captured packages (image 2), they can also affect our server to detect vulnerabilities on services, code, etc. One tip to avoid this is not to allow  our API server to support multiple data formats. It might not seem important but for example sometimes a service is programmed to use one format and the server may accept multiple data formats and we do not realize or we did not anticipate it.

For example, the JSON endpoints may allow XXE attacks (or XML External Entity) parsing xml on the server.

POST /api HTTP/1.1
Host: example-server-api.com
Accept: application/json
Content-Type: application/json

We notice that uses application/json on headers  and this sends a Json string. Such as,

{“search”:“name” , “value”:“tester”}

Then we receive

{“id”:“123798” , “url”:“example-server-api.com” ,  “email”:“example@mail.com” ,  “token”: “456d78e11aa127fa7641c”}

But if we change content/type

POST /api HTTP/1.1
Host: example-server-api.com
Accept: application/json
Content-Type: application/xml

{“search”:“name” , “value”:“tester”}

Then we receive something like

{“id”:{“error”:“ParseException: XML document structures must start and end within the same entity.”}…

Now, we know that the server allows xml and an attacker can inject code into xml similar to..

and look for information on the server. It also works the other way around-

To guarantee the transmission of information, we used ssl on httpRest connections, we ensure a secure information travel. And for example if a hacker is re directing the net traffic, they would probably not realize that happens, but on the application would appear a “Handshake exception” (Hey, we could develop a warning message for this).

-1 the request without ssl -2 the request with ssl

Then?

Generally to protect Online Transaction we use a secure data transmission on forms, emails, file transfers. So, by using ssl and preventing errors on the code, we can keep  safe applications.