i have a web portal running which involves basic data entry. The issue being that this is highly sensitive data. And the credibility of the data entry personel is very low.
Therefore i have implemented recording of IP when an entry is made.
The Problem i am facing is if this if this person starts forwarding his IP from a proxy server then i am unable to track authenticity of the data.
How do i detect if the IP forwarding is happening/ get the real ip address of the person.
You can't. Not in any reliable fashion.
You will only ever know the IP address of the request sender with 100% certainty. Whether this sender is a proxy or not can't be reliably detected. If it's a proxy, there's no way to get the originating IP address (reliably).
Require user logins with strong passwords or otherwise enhance your authentication mechanism.
The point of some proxy servers is to not reveal the real IP of the user. However, some proxies supply a HTTP header such as "X-Forwarded-For" or "X-Real-IP". But those headers should neither be taken granted nor should they be trusted. A user might as well just put another faked IP in there.
Basically, using the IP address as a user identifier is not reliable.
Another way to identify a user is cookies. The most simple case: You store the user ID into a cookie and store it with the data. Now the user may use browser privacy modes that flush cookies soonishly.
A way around that might be storing the user ID in different places too. See, for example, evercookie. It tries really hard, to never ever loose the user ID. But then again, the user could just change computers and you might not be able to track that. You can't be 100% sure.
You can check the X-Forwarded-For header. However, if they are using an anonymous proxy, you won't be able to retrieve the ip. You might be better off implementing a stronger username/password policy, i.e., forcing password changes often.
Related
I create a PHP/MySQL application that will be used to log in to the user with a username and password, but I need the user login to the system to survive even turning off the browser or restarting the device.
For this reason, I cannot rely on PHP sessions.
Of course I can use browser Cookies, but I'm afraid of being stolen.
I tried to store the generated hash in the cookies and store the login information in the database. Unfortunately, here is a big problem with the potential theft of cookies.
I also tested this hash for security against the browser version and user IP address. Unfortunately, users of the app will mainly use mobile phones (the IP address will change frequently) and hash verification only against the browser version does not seem safe to me.
Is there any way to create a secure long-term login mechanism using HTML/PHP/MySQL/...?
You can think about the problem in abstract terms: You want to recognize a user based on some data. There are two ways you can do this:
You can give some (secret) data to the user they can then show you later
You can gather some data unique to the user
Cookies are an example of 1. - but it doesn't really matter if you use cookies or some other thing like local storage in JavaScript. What you are doing is giving a value to the browser and storing it. All methods have the same risks: The value could be stolen in transit (when not using SSL) or they could be stolen in storage.
For approach 2. there are things like using the user's IP address or other pieces of data they generate "accidentally". These are however not reliable and you're often doing a trade off or a combination of 1. and 2.
For example, you can set a cookie, but on the server side validate that the IP address is the same. This gives you a little bit of additional security, but the user can't use the application on a phone now, since they'd get kicked off each time they switch WiFi / mobile networks.
If you wanted to have something even more secure, you could use an SSL client certificate stored on a HSM. But this is a tradeoff again, since it gets increasingly complex to set up and you have to distribute and manage hardware.
None of these methods help against a compromised client - ie. if the user has a trojan or other malicious software on their machine.
I want to skip a login process and instead save users' server IP with PHP's "$_SERVER['REMOTE_ADDR']" function and keep them in a database for later identification when activities are performed on my site, now to the question...
Will I have to notify users that I am saving this information from them, just like if I would use cookies?
$_SERVER['REMOTE_ADDR'] is
the source IP of the TCP connection and can't be substituted by
changing an HTTP header.
And:
While it is technically possible to bidirectionally spoof IP addresses
on the Internet (by announcing foul routes via BGP), such attacks are
likely to be spotted and not available to the typical attacker -
basically, your attacker must have control over an ISP or carrier.
There are no feasible unidirectional spoofing attacks against TCP
(yet). Bidirectional IP spoofing is trivial on a LAN though.
Reference: Is it safe to trust $_SERVER['REMOTE_ADDR']?
Doing IP address filtering would be a method to reduce surface of attack by having a whitelist of IP addresses, but not doing authentication because it will only authenticate the network address and not the person.
E.g. if somebody else happens to use the same computer, he didn't need to enter any password to get the equivalent features. So you can't enforce accountability at the person level.
However if you used IP filtering in combination of something else, e.g. a PIN number on top of the IP filtering, that's already a bit better.
You don't have to notify. The cookies are notified because of a EU law.
Apache, by default, like most other similar programs keeps access logs, and many other tools you probably have in your server. These all save user-ip addresses, anyway. so you are already saving them. https://httpd.apache.org/docs/2.4/logs.html
the problem with this approach is, people on a mobile connection(an entire area using the same IP), on the same house, or using a different browser will share the same IP. Or people travelling on a mobile device will be constantly changing IP's, people with dynamic IP addresses(there are entire countries like this, this is super common)
Imagine you are using two gmail accounts and regardless of the browser, it just logs you in to the same account. Normally one would expect a site to be "fresh" when run in a different browser, for example.
Check out sessions, it is probably what you want.
Is there any way to validate that a request to my API is coming from a specific domain without the risk of someone tampering with it?
For instance, if I get a request to:
http://www.mydomain.com/api?request=something&key=12345
I can check to be sure that the API key 12345 has been assigned to a user before returning the results. However, I would like to confine that API key 12345 to a specific domain so that only a person from theirdomain.com would be able to send API requests using the key 12345.
I'm not asking how to program that part, I know that. I'm just asking if there's any way to do so (or any other ideas you may have) aside from using $_SERVER['HTTP_REFERER'] (something more secure)?
There is nothing built into HTTP that allows you to detect the "context" of a request, apart from voluntary (and therefore trivially spoofable) information from the client, such as the Referer header.
If this is a server-to-server API (rather than something which will be requested directly by a user's browser), you could check the source IP address, using $_SERVER['REMOTE_ADDR']. This is much trickier to fake, particularly if you're whitelisting rather than blacklisting IPs. (It's easy to find another IP, to avoid a blacklist, but near-impossible to choose your IP, to avoid a whitelist).
This is often used in e-commerce and e-payment APIs, where the owner of an account provides a list of IP addresses on setup, or in a customer control panel, to make it harder for third parties to use a stolen username and password.
A friend of mine had a job interview and was asked few multichoice questions. One of the question was
Which of those can be manipulated on client side:
cookie data, session data, remote ip, user agent
I'd say that session is the only one you cannot mainpulate (I mean, you can hijack it etc but you cannot change it's data as questions suggests)
What do you think?
Cookie data and user agent can obviously be manipulated at will.
Just like you said session data itself can't be manipulated, you can only hijack sessions, steal the cookies used to associate a user with a session,...
Remote IP is a difficult call. Since http is based on TCP you can't fake arbitrary remote IPs. You can hide your real IP using proxies. But to fake another IP you need to be able to receive packets addressed to that IP. And you usually can do that only if you're part of the route to that IP. Related old question Application Security Concerns: How easy is it to fake an IP-Address?
Cookie data and user agent can are fully client-provided, i.e. can be manipulated.
IP address can be spoofed (with local access and/or technical and organizational know-how), but it will always be in a valid format, i.e. never an arbitrary string.
Session data is managed by the server itself, and cannot be manipulated. However, an attacker may associate with a different session, for example by capturing the cookie of another user.
I stored the users IP address when they are registered.After that if they access the site from another Ip address I need to ask some security questions based on the registration.So is it possible to track the IP address.Otherwise the IP will change frequently?.
p.s No need to bother about Proxies and IP spoofing.
$_SERVER['REMOTE_ADDR'] returns the IP address. You know that, since you stored it in the database. When they login, you simply try to match their IP with what you have in the database and popup the questions. I don't see where the problem is. Also, if you didn't, consider using INET_NTOA and INET_ATON ( http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html ) functions of MySQL.
Good luck annoying users!
Unless you can guarantee that each user will have a consistent IP address (which you can't), why bother with this sort of "authentication"?
Short answer is no. There's no way to track the IP address because a user could log on using a different computer, and the IP would be totally unrelated.
In practice many different users from the public internet often use the same IP address via NAT or other IP sharing. DHCP is much more common than it was in days of yore, which means these IP addresses will be released and re-issued daily or at some other frequency. Mobile devices will change IP addresses frequently. So the stability and validity of an IP address varies by networking technology (cellular, cable, DSL, dial-up, etc).
This may be fine, based on your security policies. You should also look at nonces, forced logins, and other security mechanisms based on what your trying to accomplish. You may want to change the session id every N requests or hash the User Agent string with the IP address.