I am building a iPhone web based app for our execs to view sales data. The app goes over SSL with a typical login page that sets a cookie for the day.
Since the info is sensitive and we have a VPN at work I was hoping as a double precaution I could send all communications with this app over our VPN.
Is there a way I can route traffic over the VPN only for a specific URL? Does anyone have any more info on the "Send All Traffic" in the VPN configuration
Thanks
The app has very little control over the VPN. A properly configured HTTPS site (particularly employing bi-directional certificates) will give you the kind of protection you're looking for your application.
That said, I strongly advocate that business users send all data over the VPN in all cases. This eliminates a wide variety of attacks and provides the opportunity for additional monitoring and protection. Thus, I generally recommend using the "Send All Traffic" VPN configuration. This would allow you to move the app entirely internal, so that outsiders cannot access the login page.
Properly done HTTPS should be sufficient. Provision the phone with a client certificate (there's a tool for that) and ensure the server checks them... and use a revocation list on the server side in case of stolen phones.
Making settings and managing the VPN routers and servers in iPhone is not easy. You should to make some HTTPS settings for this. After this, the client will be able to access your computer. Otherwise iphone vpn will lose its goal to run the server.
Related
Am I correct in thinking that a public REST api, such as a registration endpoint can't authenticate a user. For example our endpoints should only accept requests coming from our mobile applications and future web apps.
I am pretty sure it's not logically possible. I think apple and google offer a way (acting like a ca) for the server to identify a request is coming from a registered device however that changes the API to a private one. As authentication is essentially moved to the app store so only owners of app store accounts can use it.
So keeping it completely public the only way to prevent bots attacking it is to use email confirmation with auto deletion if not confirmed in x amount of time, and IP rate limiting.
A contractor suggested we use a unique secret key hard coded in to each app however, that to me sounds illogical and completely wrong. A secret between the app and server is compromised the second a user downloads the application on their device.
So am I correct about the secret key, are there any other ways to secure the endpoint from bots? The only other thing I can think of is using a captcha.
There are 2 separate things here.
Securing Public REST APIs
You are correct that a secret, even an asymmetric one, would be compromised if the attacker downloads and reverse-engineers the application. Attackers can use debuggers, Chrome developer tools, and tools like Wireshark to reverse engineer and find the secret.
In general, an attacker can mimic the behavior of the app or user, i.e. same the same requests in very similar patterns.
The approach to this in today's industry is to filter out as many of those attackers as possible using tools like Web Application Firewalls, and increasingly, Bot Management solutions, which work for web, mobile, and APIs.
The better the tool, the more work the attacker has to do, ergo fewer are attackers willing to do it, ergo smaller chance of being attacked.
Secure Authentication
Authentication is a specific case of the above, however this problem is currently (one of) the biggest problem faced by web applications.
The main solutions employed today is are bot filtering techniques e.g. CAPTCHA (which resourceful attackers can overcome), and Multi-Factor Authentication.
It's quite uncommon these days to be able to register without email, however services such as 10 Minute Mail can be used to overcome this. It's actually not very difficult to set up your own mail server as well.
Login is more difficult because you can't expect people to go through email, and even other MFA methods get quite annoying. You'd be OK with MFA for your bank account, but not with MFA to your Domino's Pizza account.
Because of that, the latest fad in web attacks is Account Takeover.
All those security vendors which offer WAF and bot management also try to protect APIs such as registration & login, with various degrees of success. There are even dedicated products are starting to emerge.
I am currently implementing a Facebook Chat Extension which basically is just a web page displayed in a browser provided by the Facebook Messenger app. This web page communicates with a corporate backend over a REST API (implemented with Python/Flask). Communication is done via HTTPS.
My question: How to secure the communication the Web page and the backend in the sense that the backend cannot be accessed by any clients that we do not control?
I am new to the topic, and would like to avoid making beginners' mistakes or add too complicated protocols to our tech stack.
Short answer: You cant. Everything can be faked by i.e. curl and some scripting.
Slightly longer:
You can make it harder. Non browser clients have to implement everything you do to authenticate your app (like client side certificates and Signet requests) forcing them to reverse engineer every obfuscation you do.
The low hanging fruit is to use CORS and set the Access Allow Origin Header to your domain. Browsers will respect your setting and wont allow requests to your api (they do an options request to determine that.)
But then again a non official client could just use a proxy.
You can't be 100% sure that the given header data from the client is true. It's more about honesty and less about security. ("It's a feature - not a bug.")
Rather think about what could happen if someone uses your API in a malicious way (DDoS or data leak)? And how would he use it? There are probably patterns to recognize an attacker (like an unusual amount of requests).
After you analyzed this situation, you can find more information here about the right approach to secure your API: https://www.incapsula.com/blog/best-practices-for-securing-your-api.html
I'm getting into the world of fullstack development and I'm trying to develop app which front is completely separated from backend (front is being served from node server and backend is java).
Now, the issue - how should I get about securing my app?
I'd like to have many fronts and many backend instances connected through load balancers and I'd like to keep all the state on client, so I can without any issue switch to another backend server and continue as nothing happened.
Currently I'm using OAuth2 tokens but I'm concerned about security and stealing the tokens, which are completely stored in cookie on user side. Also, The app (obviously) stores those tokens somewhere, so another instance of my backend app wouldn't accept the token. In best case scenario I can implement some mechanism that would automatically request a new one and in worst case I'd have to login again. I don't want that to happen.
Also, here I have a problem with social auth. Allright, I'm receiving token from Google on front, but giving it to backend and creating a user there is major pain, I have to write a lot of code manually to create such user and save it.
And again, I'm not certain about security level of this solution.
So the question is basically - currently, what is the best way to secure an app which should have completely separate front and backend, which would have no issue with switch backend server between requests?
As regards tokens being stolen from the Client: you can't do anything about this. It is up to the client to protect themselves. What I mean is, if you need a username and password to access a service, and the Client is infected with a key-logger, and a hacker steals those credentials, there is nothing you can do on the server side to protect against this.
As regards your idea of multiple back-ends, this is a common feature of any system with multiple application servers. For example, if you have multiple web servers and want any request to be routable to any server. For this, you need a central database which stores any information which needs to be shared. It's slower, obviously, but much more resilient.
We're looking to use the UDID to authenticate a user against server-side web services for an iOS application. My one concern is that users will try to brute force access to another user's account by making auth attempts using random UDID values. I can work on things such as throttling their requests, however I was curious if there is a way to make a "signed" request.
Meaning, is there a way I can certify that the client with UDID foo was generated and sent from the device that UDID foo belongs to, and not some random user with access to curl and a ruby script to call my service multiple times?
I think what I'm looking for is a signed http request. I'm not sure where to start building out such support on either the client or server though.
Those GUIDs are huge. The chance of guessing one seems extremely remote. I'd guess it would take several millennia to come across one 'randomly'.
You are almost surely at more risk of someone sniffing an existing one or using their access to the user's device to obtain it.
Honestly, given how easy it would be to obtain a user's udid, I'd be surprised if Apple didn't recommend against using it that way.
All it takes is for me to email one of your users with a link to my "cool new free game" and bam I've got the udid.
Or, sitting in a coffee shop, and sniffing WiFi traffic - waiting for some ad-sponsored game to send the udid over the wireless for tracking purposes.
But...
How about Client SSL Certificates?
How to use Client Certificate Authentication in iOS App
Or Signed XML Documents?
http://en.wikipedia.org/wiki/XML_Signature
Honestly, there is only so much you can do in this regard.
You'll never be able to stop a truly determined bad guy from cracking open your .ipa and extracting a client side ssl cert - or whatever other mechanism you have to thwart someone.
I'm just saying - since you are distributing the application (this isn't an in-house application running point-to-point over the internet) there is really no way to truly secure the client (mobile) side code - and thus, no way to truly ensure only authorized clients are making requests to your service.
Ultimately, the burden of security is on your services.
You should give a try to HTTP authentication
I am looking for some suggestions on how to secure access to a RESTful API which initially be used by an iPhone application, but will have other clients in the future. The data exposed by this API must be kept secure as it may contain health information. All access will be done over HTTPS.
I was thinking that I'd like to require pre-registration of the iphones at setup and then also some type of PIN/Password on each request. So, simply knowing the password without pre-registering the phone/client won't provide access. I was thinking about somehow tying it to the iPhone identifier if that is possible, but not sure it would provide any additional security. The iPhone identifier is just another piece of information and it may not even be that secret.
So, some requirements would be:
Use some type of pin-based solution on the iPhone, but want more security then a simple 4-6 digit pin can provide.
No passwords could be sent in the clear.
Not be subject to reply attacks
Having to pre-exchange some data between client and server when setting up client is OK.
I would think that, if the application contains medical records, you would want to have the user authenticate every time they use the application or, at least, have some way of pushing down a disable message that renders the app useless in the case where it is lost or stolen. The 4-6 character password (pin) would also concern me with respect to HIPAA, if it applies.
You might want to treat it as a standard web app from the server perspective and do session-based authentication and access with a session that times out, perhaps after a long period, and re-authentication on timeout.
You could use SSL with client authentication. If a device gets lost, you can remove the certificate on the server. There are some obstacles though:
It is not entirely clear if/how you can do client authenticated SSL on the iPhone Unfortunately, there is not much documentation about it. Have a look at Certificate, Key, and Trust Services Reference
You have to create a private key for every device
You also have to figure out a secure way to transfer the private key to the device