There is a REST-based webservice that has no authentication or authorization whatsoever - anyone that knows an URL of a particular method of this webservice can use it.

However, the URLs of methods are not exposed to public (for example, there is no public documentation that would enumerate API methods, or anything like that). Only place the webservice is being accessed from is an Android application that, obviously, needs to know the URLs to use the webservice (they are hardcoded in it). The app is not published in any public app stores and it's only distributed internally.

Is there a way for a potential attacker to access the webservice outside of the Android app? Of course, one obvious way would be to somehow get hold of the app, decompile it and find out what are the URLs; are there any other, realistic ways except that?

The webservice in question really exists. Right now, I have only a feeling that the whole setup is a recipe for disaster - I need some particular examples to be able to convince my boss that we really need to improve the situation somehow.

  • 1
    Does that webservice contain any private data ? If it just replicates whatever is publicly displayed on your site then I don't see any problem. – user42178 Jan 17 '15 at 16:42
  • @AndréDaniel Yes, it certainly exposes private (and rather sensitive) data that are not available via other means. – user66497 Jan 17 '15 at 16:46
  • 3
    Then yeah it's a disaster waiting to happen. Implement some authentication, given that it's an internal app with no concepts of users and multiple apps, OAuth would be overkill but HTTP basic authentication would be sufficient (and don't forget to make the app use HTTPS to avoid the credentials being stolen by a man in the middle). – user42178 Jan 17 '15 at 16:50
  • @AndréDaniel Thanks, will certainly look into that. However, I'd still like to know if it's really that simple to just scan a network from outside - can really just anyone who simply knows an IP address scan it and find out URLs of all API methods? This seems to be what StackeZZ is talking about in his answer, but it's possible I just misunderstood it. – user66497 Jan 17 '15 at 17:02
  • Just scanning the IP isn't enough to find the URLs (unless you want to go the bruteforce route and try all possible URLs); the attacker usually needs to be in between the app and the server so he can see the traffic (assuming it isn't HTTPS) and the URLs will be right there. – user42178 Jan 17 '15 at 17:04

Here are a couple possible scenarios:

  • an app user connects to Internet via a public WiFi hotspot, and plain HTTP traffic is eavesdropped by a third person. That person is able to get hold of your URLs.
  • app user's mobile Internet provider implements automated harvesting and analysis of user's behaviour in order to create a behavioural profile for ad targeting. If it sounds too far-fetched check out this story about Verizon in US. I've also heard of some Internet providers in Russia implementing a similar solution. Since you didn't specify the country in question, I don't know what applies in your case.
  • mass surveillance by NSA or any other security service.

At the very least, I'd implement HTTPS or encrypt traffic using hard-coded certificate. This will not put away a determined attacker but should thwart "drive-by" eavesdropping.

| improve this answer | |
  • Thanks for that, this is a kind of an answer I was looking for. Unfortunately, my reputation is too low to upvote your answer, otherwise, I would do that as well. – user66497 Jan 17 '15 at 18:17
  • NSA does not care about your android application or webservice. An ISP selling your WebRequests? Yes the government could intervene but again - WHY? – McMatty Jan 29 '18 at 21:00
  • Thanks for updating us on NSA spy list and ISP practicies! I can sleep well now that you've assured me nobody will try to take advantage of my unsecured REST services. :-) – mkalkov Jan 31 '18 at 13:33

you should definitely implement some Authorization, because some one could scan your network and see outbound connections, and see that there is a connection going to this URL, and might want to exploit it.

simplest way to explain it.

tools that can be used:

nmap: scan ports and connections

Wire shark: Hijacking sessions.

droid sheep: hijacking sessions.

since you have no authentication or auths, someone could easily hijack a session.

so many possibilities!

| improve this answer | |
  • Thanks for that. To scan the network, wouldn't the attacker need a physical access to some element of it? The webservice is public facing - would simple knowledge of its IP address be enough to find out URLs of all API methods? Forgive me if my questions are a bit naive; I am quite out of my depth here. – user66497 Jan 17 '15 at 16:45
  • yes, Nmap was with access to the network, and Session hijacking and such can be done where there is no authentications/encryption , i.e in a public network – Ersats Jan 17 '15 at 19:03
  • Nmap will not give your the webservice request URL. Authentication & authorization does not protect your from session hijacking at all. The requirement here would be TLS over the communication channel. Also NO having an IP does not expose all the web api. Only way this could occur is if you are using a well known existing API and it is detected via a scan. Otherwise someone is going to have to try and enumerate your API without knowing its naming scheme. – McMatty Jan 29 '18 at 20:54

I think you are quite mistaken in your assumption here. Because the Android application is making the call doesn't mean this is the only location the request is going to be seen. This is just the origin point of the request.

If this request is going through a network owned by an attacker (cafe wifi, rogue ap) it can be logged or intercept - what if its going out through a proxy?

If I was going to attack your service the first thing I am going to do is proxy the request to see what APIs are being called and what parameters are being used.

If there is not authentication I may start using your webservices in a product of my own with you footing the bill. If your webservices return juicy data well I'm going to enumerate every piece I can or if I'm 15 an angry at the world I may just see what it takes to consume all the resources of your service.

  • Authentication
  • Authorization
  • Monitoring of your API's

These aren't options - these are must haves on any web service

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.