I am interested in using DreamFactory to help build APIs that will serve our IOS and ANDROID apps. However, my colleague (who is actually much more of an expert in the app development field then me) feels the approach of Dreamfactory is fundamentally not that secure for the following reason >>>
’REST API’s are not good for mobile application as the requested address is not encrypted this means a MITM (“Man In The Middle”) attack can see what URL’s are end points the point of using JSON-RPC means all requests hit the same endpoint. and the called method is then encrypted by the SSL Certificate.'
How would people respond to this?
DreamFactory supports the use of both secure and unsecured urls. When you setup your production server, set it up with SSL encryption and you won’t have to worry about MITM attacks.
Dave Weiner | Sr. Software Engineer | DreamFactory | @dfsoftwareinc
Thanks for the reply Dave. Forgive my ignorance, but I am not 100% clear. Just yet…
I know in secured URLs (HTTPS) that the contents of the page are encrypted and so secure. But is the URL itself encrypted also?
As I dimly recall from the mists of time when I last looked at my web server logs I could see both HTTP and HTTPS entries logged.
Therefore I can see (and any intervening routers in the journey to my website) what HTTS page URL was requested, though not the contents of that page.
Hence if the URL itself gives clues to the endpoint by virtue of its name and any URL parameters - is not that something for a “Man in the Middle” to start getting ideas about?
For example: I want to edit the description of my personal profile on my dating app. The description is encrypted in the HTTPS document. However, would (by virtue of the URL) people know I was calling an “Update Profile” page and perhaps the MemberId of my membership also?
I think this is perhaps what my colleague is getting at. In Json rpc - he suggests absolutely everything gets dumped at the same endpoint - hence the method/task is also obscured from Man in the Middle as it is within the body of the HTTPS.
IMHO, I don’t think it’s a problem to everyone knows the URL and endpoint, cause you will control all access of you application with session, cookie and SSL.
IF someone stolen all that information (cookie, session, etc), the problem is not with DF or any other REST API, the problem is with your private security, like malware or fishing.
Thanks Kimpatro,
Two thoughts spring to mind
-
You are presuming we have sessions setup which involve a cookie and user logging in with their username and password (at somre previous point). But what if some tasks are to be done without logging in? E.g. just requesting a list of data. Are we saying we can/should only be using REST with logged in state and not for tasks that can get done without session login?
-
Even if user has logged in with session, cookies, etc. Let’s imagine a scenario where where someone - let’s call him “Honest Andy” - has produced a Dating App for their Dating Site. As well as this they have their own member profile on the system with memberid=1.
Now, “Honest Andy” has a twin brother “Evil Andy” who has a profile on the system also with memberid=2. Evil Andy has long since been booted out from being tech admin of the dating site due to basically being evil.
However, Evil Andy has managed to compromise the router at the ISP that the dating site uses and sets himself up as a “Man in the Middle”. He observers a URL request to “ViewProfile” for someone wanting to look at memberid=1. He simply changes the request to memberid=2 in URL (Leaving the HTTPS encrypted body of message intact) and sends this on to the server. When the server replies he forwards the reply back to the originator.
Therefore the originator - let’s call her Sally Strawberry - has clicked on a link from the site who emailed her “Click here to see your super special match of the month - ‘Honest Andy’” and ends up being shown page of Evil Andy. Ha ha ha ha …now is that an honest laugh…or an evil one? 
If the thing was RPC then Evil Andy would not have a clue as to what tasks were incoming to the dating server as all URLs would be the same. No?
Well man, if someone is sniffing your ISP the problem really don’t is your app.
You’re having problem with the security of your server and hosting.
About thought one, “requesting a list of data”: you could use temporary token.
About thought two: maybe you could have a CSRF problem.
PS: Quick search on google and found this (about ISP):
Protect your privacy: secure your network | Macworld
ISP and network tracking
The risk: Internet service providers, or whoever manages the network you’re using to connect to the Internet, can see all of your traffic. A number of ISPs now track their customers’ browsing and sell aggregated information to market analysis firms. As with other privacy violations, this is more creepy than dangerous.
How to protect yourself:
If your ISP tracks activity, you might be able to opt out on its Website. As with opting out of advertising networks, opting out of ISP tracking means setting a cookie in your browser telling them to ignore your traffic. Remember that if you clear that cookie, the ISP will go right back to tracking, and it is often impossible to fully opt out of their monitoring.
If you are worried about your ISP or network provider sniffing your traffic, the only way to protect yourself is to encrypt the traffic using the techniques discussed above, or to use an anonymization service such as Tor. Tor encrypts your connection and routes it through a number of random servers on the Internet. Your traffic is still visible at the exit node, but Tor protects you from local network or ISP monitoring. Unfortunately Tor significantly slows down browsing and other activities.
1 Like