Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have developed an MVC web app. Right now, the client using this app in office area. The client has requested that no one should use this app on any device except the office's PC/tablets.

Now problem is, it's a web app, so how can I put restrictions that nobody can use this app from the outside of the office or with devices other with than office's PC/Tablets?

share|improve this question
Will never be possible! This question has been asked over 9,000 times, and everyone who asks it doesn't understand even the most basic concepts of security. – rook May 18 '13 at 5:55

There's a couple of things you can do to help restrict the use of the application to a specific office location and specific devices, although as other answers point out none of them are absolute protection

  • Setup a firewall in front of the application to restrict the IP addresses allowed to access the application to the clients external IP address range. Most companies will have static IP addresses on their Internet facing routers and if you set the application only to be accessible by those IP addresses it would be harder for an unauthorised person to get access to it unless he is in their office. TBH this sounds like the approach that will work best for your customers requirement
  • You could also use client Certificates on authorised devices. As @adnan points out it may be possible to move those to another machine but that would require the attacker to either be a staff member of to have unuthorised access to one of their systems
  • perhaps as a detective control you could combine this with browser fingerprinting (e.g. panopticlick ). Create a list of devices and their finger print, then if the client cert is used on a device which doesn't match the fingerprint you can block it.

As I say these aren't absolutes but then nothing in security is. If all your customer is looking for is to stop people from outwith the company seeing their site, I'd go with the source IP address filter approach.

share|improve this answer

You just have to host the web app on a server on the intranet that is not connected to the internet.

Proper routing and firewall measure should ensure that no one that is not connected to the local network has access to the web app.

If people outside the network needs access to the web app, have them setup a VPN connection to your local network.

share|improve this answer
Sorry, I have explain it more briefly... Only office people should this web app. they might be use on tablet out side office. – bnil May 18 '13 at 5:16
@user1650894 Updated. – Terry Chia May 18 '13 at 5:17
what abt client side certificate ? – bnil May 18 '13 at 5:23

What you're trying to achieve is not possible. HTTP isn't designed to provide hardware-specific identifiers, the only "identifier" is the User-Agent which isn't identifying at all, and it can be spoofed, so the browsers don't even access that information.

Even with a client certificate, it just can be exported from the browser to another device.

Tell your client it's not technically possible.

share|improve this answer

How secure do you need to go?

This is probably as "secure" as you can make it. It's not technically safe. As Rook said, there are still things here than can be exploited. These are a few steps you can take to try and harden the system:

  1. Setup the web server on a physical server on the office LAN. Do NOT use NAT to connect any outside traffic to the webserver. If the server is used for other sites they should be on a different server or VM.

  2. Setup an SSL VPN firewall (Cisco comes to mind). Cisco has apps for iPads that can be used to setup a "secure" tunnel with the router.

  3. Once you've authenticated via VPN (remotely) you would assign a local IP address within a certain specified range (this depends on the number of clients connecting to the server). Depending on the router you can assign rules. Because you can't control the network on the other end of the VPN (let's say the user's home network) then this is a potential attack vector.

  4. Local traffic and VPN traffic would need to have different IP ranges for tracking. Local traffic should have static IP addresses assigned by MAC address (spoofable) by the DHCP server which are all logged. This will help you check for collisions and spoofed IP addresses and MAC addresses.

  5. On the firewall on the webserver you would setup a subnet of addresses that can connect to the web server. This would include the VPN range assigned in the router for the users and the whitelisted internal static IP addresses.

  6. Then on the web server itself you can restrict access to the website via the whitelisted ip addresses (IIS 7 and Apache) you've setup in the DHCP server and in the local firewall (this is redundant in the event someone finds an exploit for altering iptables in a *Nix box).

If you use a corporate after market software firewall like Kaspersky (on a Windows or Linux box) you can block traffic that way too.

To make changes to this system: 1. the ip address lists would need to be updated on the internal DHCP server 2. in the webserver's firewall 3. and in the webserver config

So that "locks down" the access to the actual web server...

Next you'll need to run SSL on the webserver and require a specific username and password for the user. The password should be at least 16 characters.

Once the user authenticates on the webserver, then you would send them a message, either via SMS or e-mail that contains a single-use or one-time password that allows the user to be whitelisted for some set amount of time on the server. (If anyone has access to the user's cell phone this might be compromised). If the user closes the browser window they have to be reauthenticated (and this should terminate the session). You can set a keep-alive script that runs in a language like Javascript that expects a transmission from the client within a certain range of time. If the client doesn't answer, then kill the session. (This prevents disabling javascript for access. Also it helps with people closing their browsers and trying to open new sessions before their old session has expired.) They should only be able to login from one location at a time.

You should prevent the user from storing their passwords on their devices. (This can be bypassed with plugins in browsers like Firefox.)

To make things more strict you could even go as far as requiring the tablets to login to a virtual terminal via something like VNC or RDP (Not ideal on a phone). Then they would have to use the web client on the virtual machine. This VM would be restored to clean on the next run or connection.

Anyone who knows the system can exploit it. Anyone outside the system would have to spend a lot of time trying to get in and they would need to know the system existed.

All aspects would need to be documented. If someone had the documentation they could try to find a weakness in the system.

Again this comes down to people. Anyone with access to the information over time could store copies of all of the information (screenshots with a cell phone, texted PDFs of office documents, etc.) SSL is also crackable, so even encrypted "secure" connections can be read by the right people.

share|improve this answer

Who owns the code? How likely is it that someone else would want to use the app? How serious would the consequences be if someone else used the app? What types of device? Is the access to be restricted to static IP addresses? These are just some of the questions you should have answered in your post before asking for design recommendations.

VPNs IP addresses and client certs have already been mentioned, but client certs can be tricky to install on some devices. Static IPs are only going to work within a well managed LAN. A VPN would require tight integration between the server, network and application config.

Storing a simple token in a persistent cookie (without appropriate permissions and process around the device registration) is a simple solution, but not very resistant to reverse engineering/spoofing.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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