Security is not my area of expertise. I am working on a lightweight administrative Laravel web app for internal use by company (small) employees:
The app is intended to be used only by the employees
Remote work (from home) is not uncommon
Smartphones and laptops are usually used when working remotely
I would like to secure it as much as possible - beyond authentication, access controls or 2FA. I am trying to think of ways to make it virtually invisible to the public, but still available for the employees. Defining proper rules for crawlers might make it a bit more obscure but I think more could be done. Network based restrictions would limit the employee flexibility.
Based on this I got the idea that the app could be made available only if the request is made by an authorized device. I am not sure however whether or not this is a good approach. Neither do I know how to tackle the problem of authorizing the various devices and making that information available to the server during communication.
i.e. How would I tag a device as authorized so that I only have to do it once and can reliably validate the information in a web app? Regular authentication as well as role based access would still be in place but the app could return a 404 response if the accessing device is not whitelisted.
Is there a way to achieve something like this while not making it too restrictive for the users or painful to set up? Or is there a better method for achieving the same result?
Consider a VPN?
If you are hosting the device on an internal network, you could see if the IT dept. can set up VPN access to work remotely (in most cases, this is already in place) and then it does not need to be accessed over the internet via a URI. Instead you can simply navigate to the internal address once you're in the network through the VPN - no public access and no need to worry about pesky web crawlers!
It also makes it easier to moderate your application. For example, if an employee leaves the company you can simply revoke their VPN access and they'll no longer be able to access the application.
Related
I've read a lot of articles on this subject and they all suggest completely different things that I can't yet structure in my head.
I have one backend app (spring-boot + kotlin). I have nginx and one android (kotlin) mobile app uses backend api and of course Postgres. By the way backend app and postgres are packages in docker containers via docker-compose.
My task is to make the API of my backend service can only be used by this mobile application and no one else. But I also want it to be able to use the API if I have a Web application in the future.
I would be fantastically grateful if you could describe, in a few words, modern technology that could be used to accomplish my task.
For example:
Spring-security: a huge thing that you don't know what to do with, most likely you can use it to solve your problems, but it's overkill. But if you decide to use spring-security, this will help you {...}
...
By the way, I'm not against spring-security, I just really think it's too much for my task. But I'd be happy to hear your opinion.
Your Problem
My task is to make the API of my backend service can only be used by this mobile application and no one else. But I also want it to be able to use the API if I have a Web application in the future.
You have in hands a very hard task to complete. While not impossible it's very hard to accomplish with code written on your own or by trying to leverage security features on your framework of choice.
To understand why it's so hard you first need to understand the difference between who is in the request versus what is doing the request.
The Difference Between WHO and WHAT is Accessing the API Server
I wrote a series of articles around API and Mobile security, and in the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between who and what is accessing your API server, but I will extract here the main takes from it:
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
So think about the who as the user your API server will be able to Authenticate and Authorize access to the data, and think about the what as the software making that request in behalf of the user.
After you understand this idea and it's ingrained in your mindset, you will look into mobile API security with another perspective, and you will be able to see attack surfaces that you never though they could exist.
Possible Solution
I would be fantastically grateful if you could describe, in a few words, modern technology that could be used to accomplish my task.
I recommend you to read this answer I gave to the question How to secure an API REST for mobile app?, especially the sections Hardening and Shielding the Mobile App, Securing the API Server and A Possible Better Solution.
The best approach to solve your problem is to go with a Mobile App Attestation solution suggested in the answer I linked. A Mobile App Attestation needs to be able to work in tandem with your mobile app and backend in order for the backend to have a very high degree of confidence that what is making the request is indeed a genuine version of your mobile app, that hasn't been tampered with statically or at runtime, and it's not under a
MitM Attack
The Manipulator-in-the middle attack (MITM) intercepts a communication between two systems. For example, in an http transaction the target is the TCP connection between client and server. Using different techniques, the attacker splits the original TCP connection into 2 new connections, one between the client and the attacker and the other between the attacker and the server, as shown in figure 1. Once the TCP connection is intercepted, the attacker acts as a proxy, being able to read, insert and modify the data in the intercepted communication.
The MITM attack is very effective because of the nature of the http protocol and data transfer which are all ASCII based. In this way, it’s possible to view and interview within the http protocol and also in the data transferred. So, for example, it’s possible to capture a session cookie reading the http header, but it’s also possible to change an amount of money transaction inside the application context
Be aware that solutions to solve your problem that are specific to the backend or to the mobile app will not be able to achieve a very high degree of confidence in securing your API backend from serving requests not originated from your genuine mobile app, but it's better to have them then nothing.
Do You Want To Go The Extra Mile?
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
For APIS
OWASP API Security Top 10
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
For Mobile Apps
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
The easiest way probably is to define a shared secret on the phone and the backend service.
On the mobile phone, with each request, you send the secret, e.g., as an HTTP header.
On the backend, you need to implement a Filter (e.g., OncePerRequestFilter) that checks the request for the secret and compares it to the value stored in the backend.
We have a Java Spring application with lot's of contacts inside a database. Now we'd like to provide these contacts via CardDAV in order to access them via external devices.
As far as I understood CardDAV, it uses the 'well-known' protocol. Which means, it'll look up http://mydomain.com/.well-known/carddav
This might be a problem, because we have a Tomcat Server running, and multiple applications running on it and each of them should provide a CardDAV server. This means, our URLs look like:
http://mydomain.com/appOne/
http://mydomain.com/appTwo/
http://mydomain.com/appThree/
Each of those applications has a completely different set of users and data. Though each of those CardDAV repositories has to lookup its own data source and has to use its own authentication mechanism.
The question is of course: How can I get multiple different CardDAV servers with a single domain?
Btw: Is there any REAL information about CardDAV (not just WebDAV or is it all the same?!)?
For example I couldn't find anything about multiple repositories / access right restrictions. Maybe I want to have a single CardDAV server with multiple different Users, where each user has an own address book and there are some common address books.
The well-known url is used for clients to automatically discover the root of the carddav server, when a user just types in a domainname. You can only redirect to 1 server per domain, but you could setup multiple domains to redirect to multiple carddav servers.
If you can't use multiple sub-domains, you simply cannot use well-known. Instead, you will have to ask users to fill in a full url to their principal to setup their acccounts.
As to your question if there's 'real' information. rfc6352 is the official documentation. It's definitely a lot more than just WebDAV.
Effectively, iOS only supports well-known. If an iOS device cant connect via well-known it will allow the user to enter a complete principal address, BUT thats only AFTER displaying an error message to the user, at which point most users will give up.
However, the redirect occurs after authentication, so as long as you're able to authenticate at the root (eg with a username scheme that incorporates the sub-site, like 'appOne:brad') then you should be able to do it. Alternatively, as mentioned above, just use subdomains.
I have three client-facing web applications all on different subdomains (one of these web applications actually has 700+ different subdomains that are changing all the time). I've written an oAuth server that I was going to use to allow users to login to each of these systems; this works, but I've begun running into differences between what's happening and what I would like the behavior to actually be when writing the logout code.
Some of my requirements for single sign-on are:
If logged in on one system, you are logged in on all systems (obviously).
If logging out of one system, you are logged out of all systems. Even across subdomains.
If you are logged in on two different machines, for example -- a cellphone and a desktop. When logging out on your cellphone, do NOT logout on your desktop.
We already have written the oAuth provider and we'll be using it for projects not coupled to our domain (API's, etc.), but I'm not entirely convinced that oAuth is the best solution to use to meet the requirements outlined above. I'm thinking that maybe a shared session would be better. The shared session idea would involve a cookie stored on the main domain that has information about the currently logged-in user.
What are the pros and cons of either approach? Are there other approaches you might take? Are there security risks to consider? Concurrency and scalability considerations? Please help!
I would have taken oauth route with a variance.
Oauth :
The approach I would prefer is - access token issued at a device level (User- Application/Device) .
Ie there will be a process for registering your device and granting access for it.
This will result in the generation of an access token specific to the device and stored in it as the case may be. (For eg:- for mobile you may need a longer expiry access token and webpage a lesser duration one).
This way you can decouple the login/log-out across devices.
However the con of this approach is:
More complicated implementation, as it involves device registration
Tracking the action of each user will be difficult as you have two or more access token tied to a user.
Pros :
This is a fairly standard way
The Con 2 can be worked around (Adding access token attributes etc).
Session based SSO management
Pros :
Simpler than OAuth
Cons :
Security constraints around -session/cookie handling
Extendability at later point to add more use-cases is limited
We have a custom Active Directory integrated web app that helps users perform some self-service on their accounts (e.g. update photo, change phone number, reset password etc.) Our app runs on domain-joined servers, as Local System, and is thus able to authenticate to the AD using the server account(s).
We use a service connection point, that the app's clients use to locate an instance of our app. (Our app clients are hard-coded to look for certain keywords which are published on the servie connection point's keywords attribute.)
We recently had a situation wherein someone (we believe accidentally) changed the keywords on one of the service connection points resulting in an outage, since the clients could no longer find our SCP when querying the AD for our keyword(s).
The customer is a bit upset about this and wishes for us to provide them the ability to determine who can change the keywords on our SCPs. This feedback was passed on from our sales guys to us, and now we need to provide some way of helping them figure out who can change the keywords on our SCPs.
So, we're looking for an API to help us to determine Effective Permissions on our Active Directory service connection point objects, so we can alleviate this situation for the customer. We couldn't quite find an Effective Permissions / Access API that could help us list all the users who have effective write access to the keyword and other attributes on our SCPs.
Is there an API/other way that one can use to determine Effective Permissions on an Active Directory object?
It needs to be able to list all the users who have a specified access on a specified set of attributes of an Active Directory object.
This stack overflow post may be able to help you. LINQ to LDAP should also allow you to access the information pretty easily as well.
I want to be able to synchronize several text files on a user's PC in real time from my web application. Basically I want a few data files on the local PC to mirror the state of a user's data in my web application so if the web application or the user's internet connection is lost he can use those data files to get some critical info (possibly using html/javascript code stored in with those files that would run in offline mode on those data files.)
I know that google gears has a lot of interesting tools for working with offline state, but I'd prefer an even simpler application in html/javascript that wouldn't be as reliant on google gears. I'd rather use google gears to just create those files and slowly keep them in synch with the web application's version of data throughout the day.
Update on answers:
PersistJS is a good suggestion I will look into, but I was hoping people would direct me towards really good Google Gears tutorials resources.
You can save data on the browser using PersistJS, which uses the best client-side persistent storage mechanism it can find, supporting:
Flash
Google Gears
HTML 5 storage specs
browser-specific extensions
cookies
When your app reconnects, you can resync. Creating and reading text files is something the browser will generally block your web site from doing.
Risking of stating the obvious; if you want to store user state locally, isn't cookies the standard way?
maybe more then one cookie will be needed, but that sounds like the simplest of ways.
You're going to need to make an ActiveX control and a FireFox plugin to get these permissions. Short of that I agree with orip try using PersistJS
You can ask the user to download a subversion client that is predefined to interface with your subversion server only. Then write your web application to interface with the subversion service from your side only.
There is a good deal of security harm associated with granting access to a user's file system so you will want to lock down all possible points of exploitation. You will want to ensure that the user cannot access the subversion server except through the client that you ask them to install. You will want to ensure the connection between the application server and the subversion server is extremely secure so that the transmission path cannot be compromised and that malicious logic that may be loaded onto the application server cannot access the subversion server. I would say to encrypt the transmission path between those two servers and put the subversion server behind the firewall separating your network DMZ. I would also suggest use a challenge/response mechanism between the application server and the subversion server to prevent malicious code from appearing to be legitimate decisions made on the application server. Also, ensure that data only flows form the application server to the subversion server in a unidirectional fashion only, because if there is malicious logic planted on your application server then any data that comes from the subversion server is compromised without even accessing that server.
you could use the File System Object FSO through javascript, however it is dependant on Microsoft as it is an ActiveX control, it would also require permissions in the browser, or perhaps a HTA (HTML Application).
http://www.webreference.com/js/column71/
Its a real security issue so most avenues are closed down inhrentley.
Inherently the web model was designed not to authorize upstream from server to client. Now things are changing slowly maybe could you do this with Websocket ?