I'm behind a company firewall and have been asked to share my IP address in order for me to be white-listed so can access an API. This is first time I've been asked for this and find it uncommon ? as usually I connect to an API via OAuth or access token, https username password etc. Is this a safe way to access an API, will I creating any security risks though sharing my IP ?
Update :
The API host is asking for my IP.
You give your (external) IP address to every single website you visit. It's ok to let them strengthen access control by IP restriction.
However, if that is the only security measure (as opposed to proper authentication and access control), that's not OK, especially not in a corporate setting, where everybody behind your firewall will have the same external IP address because of NAT (and even if it's not the case, there must be proper authentication on a secure API).
Related
In some countries like Iran or china because of severe Internet censorship, people use a foreign VPN server to bypass government censorship.
Imagine we implement a none-SSL VPN for people who connect their phone to the Internet through this VPN. I want to know if they use a secure application within their phone which is secured by SSL like Instagram or WhatsApp, still, is there any security issue for the transmitted data between their phone and server?
I mean is it possible in this case their data would be sniffed by the government or others? (although the VPN is none-SSL but Instagram is SSL secured)
If I understand the scenario you have described, the VPN does not use SSL when communicating with the user device, but the secure application requires the use of SSL between the server and the client device.
The answer would depend on a few more things. Does the "severe internet censorship" flat out restrict the usage of the application? Take Instagram for example. Is the government banning the use of the application in its entirety or just certain aspects (such as filtering specific tags)? Sometimes the term "internet censorship" is used to mean one of these things but not the other (though most often the former).
Assuming the application is banned in its entirety, and the connection to the VPN is not secured by SSL, then the domain which is being banned would be visible to eavesdroppers at some point prior to the secure channel establishment (with SSL or rather TLS) between the client device and server. For example, it is likely the case that the DNS resolution of the domain is unencrypted (either at the client device level or communicating the query to the VPN). So, the eavesdropper (say, the government) would be able to see this and possibly act on it (say by dropping the request if they have a middlebox unknown to you).
So basically, if the connection to the VPN is not secured by SSL (or TLS) then there would be no benefit in using the VPN with regards to censorship.
I was thinking about how to secure my API and prevent token theft from affecting my users. I thought it would be a good idea to save my users IP if an attacker manages to steal a token and is used by one with a different IP. I'm going to use a middleware or a function to verify if it is in the user ip list and if not I'm going to reject his token and then ask for your credentials in the frontend. If the credentials are correct I will overwrite the IP or store it as a new one.
I don't know exactly what you mean by "is it feasible". Yes, you can do it if you want.
But, there are plenty of potential issues with relying on a user's IP address not changing and forcing them to reauthenticate every time it does change.
1. Mobile devices moving around. As mobile devices move on a cellular network, their IP address can legitimately change.
2. Mobile devices connecting to different networks (such as WiFi). As your phone goes from being in your car and on the cellular network to being at home and on your WiFi network, that phone's IP address in connecting to your service will change.
3. NAT behind some firewall. Nearly every user (even home users) are going through a NAT device and the IP address you're seeing is the IP address of a gateway, not the actual user's IP address. In a larger corporate network, the gateway IP address may not always be the same. And, multiple different users may appear to be from the same gateway IP address so there is not necessarily a one-to-one correspondence between users and IP addresses.
In general, you should just be using https for all connections in which you transmit the JWT so there is little risk of man-in-the-middle attacks stealing the JWT. The user themselves needs to secure their own local storage of the JWT.
An approach used by many modern services is to fingerprint the local device by recording a set of characteristics it has which may even include the presence of some other cookie along with a number of other browser characteristics. Then, you require reauthentication whenever the fingerprint changes by some significant amount. You will see many bank and airline websites doing something like this. The idea here is that even if the credential is stolen, then the fingerprint is unlikely to match when a credential is being used by an attacker.
I want to only allow users from my own IP and two domains which would cover the client's intranet and external secure website. Should I be doing it in web.config? Azure itself?
Thanks for the help :-)
The mechanism to control which referral domains are allowed to access resources in your Azure Web App, or any other HTTP endpoint for that matter, is called Cross-Origin Resource Sharing (CORS).
CORS is an IETF standard (RFC6454) and is supported and configurable for any Web App / App Service. However, it will not help you in what you are trying to achieve.
Web browsers nowadays operate what's referred to as same-origin policy. This is where a browser will only fetch resources from the same domain present in the address bar. Why? It's really a security mechanism designed to protect the user against cross-site scripting (CSS) attacks, where a malicious actor may craft scripts to make calls to websites a victim is currently logged in to, where their cookie will automatically be sent to the server to sign in, thus being able to carry out activities as the victim. CORS allows developers to permit cross-origin requests safely by white-listing particular domains which are allowed to access resources.
CORS should not be used a mechanism to restrict access to a site. Neither should the referrer HTTP header be used when locking down access to a website, since this can easily be spoofed. Further, CORS operates on an honorary basis meaning that, should origin be indeterminable, the request will be allowed, as it is assumed that the request is same-origin, or initial.
What you are looking for is IP restrictions. Azure Web Apps support IP restrictions. In the portal, navigate to your Web App -> Networking -> IP Restrictions. This area will allow you to configure IP addresses or ranges that are allowed to access the application. You will need to create a rule allowing your IP address and addresses relating to the "referral domains" in question, which demands that the users are coming from known addresses.
So, to answer your question, it should be done in the portal, and you should use IP restrictions.
My web app is using a 3rd party tool for storing sensitive data, which has the ability to send events via a callback url (i.e. when something changes it will make a request to the given url). In order to prevent malicious requests the 3rd party tool suggests checking the IP Address of the request to ensure that it came from their server, but this seems like it would be vulnerable to spoofing.
Questions:
Is it safe to validate origin of requests in this way?
Would client certificates be a more reasonable approach for them?
If the 3rd party app is across the internet, then your check would be protected against IP spoofing as the 3 way handshake cannot take place if the IP address is spoofed. (Discounting large scale attacks such as IP hijacking.)
If the 3rd party app is on another server within your local network, then another user on that network could just set their local IP to that of the app to spoof it.
To summarise:
Could a web app which authenticates a client only by IP address be exploited?
No - if the app is internet based, the risk of IP spoofing is very low.
I want users, when they are in the workplace (e.g. on the LAN), to authenticate themselves with their regular username and password. Auto-login is disabled.
However - logging in from outside the LAN should trigger a 2-level authentication (like SMS, mail or similar). How can we get information about the users network when they try to log in to the application from outside the LAN?
NB - it does not matter if you have AD user and pwd. If you are on the outside you have to trigger the 2 level auth.
NB2 - we do not want any client-side scripts running, so this must be something coming with the initial request
Technology: IIS 7, ISA 2006, .Net 4, MS Sql 2008 server.
Question also asked here: https://serverfault.com/questions/354183/what-2-level-authentication-mechanism-is-available-that-can-differentiate-if-the
Information why ISA server remove the information I need: http://www.redline-software.com/eng/support/articles/isaserver/security/x-forwarded-isa-track.php
If it's reasonable, don't expose your web server to anything outside of your LAN -- require VPN access.
If that isn't reasonable, you should be able to use the REMOTE_ADDR variable to determine the source of the request. Whitelist your LAN as single-factor and require everything else to be multi-factor. Depending on the scenario, the server variables will be similar to either
Context.Request.ServerVariables ["REMOTE_ADDR"]
or
Request.UserHostAddress()
If you have a proxy in the way, make the proxy tag the originating IP source in the headers and read the request headers to determine the external IP.