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.
Related
I have several questions about SESSIONS and COOKIES, I read in internet and all people recommend use SESSIONS (for security) but.. Not is same save the ID login in one session (phpsessid) that save in one cookie?
I tested this:
I copied my PHPSESSID ID (cookie) from my login account from a website
( in chrome) and insert my PHPSESSID (cookie) in another browser (in
opera) with VPN and I can access in this account.
What is the security here? if anyone can guess or hijack my cookie PHPSESSID ID is same if I use a Cookie to saving the login id, or not?
My question is.. Dont is more secure use a secure cookie ID like in wordpress, encrypting ID and checking in DB the IP and USER_AGENT ?
Now, I using this:
I create a random ID and save in one cookie (when the user login is success)
And check if this ID exist in the DB, check if the IP (saved in DB) and USER_AGENT (saved in DB) is equal. if not, login another time
Anyone can me guide a little? Thx you for read.
You should ask yourself this: "How easy is it to guess the randomly generated random id?".
If your answer to this question is "very easy" you should make it harder to guess. Use a UUID or some other form of securely random ID.
If you answer is "quite hard" you should not have to worry about this. The only attack vector you are offering is to be able to guess a randomly generated id.
You can read more about "guessing the PHPSESSID" here.
In general it should not be necessary to check the IPs of the user (as a side note, you open up yourself to all the stuff in the GDPR by doing this) or their User-Agent as both things might change during the sessions lifetime.
The key point about sessions is that they are a server-side storage. In other words, your program writes whatever it sees fit and it reads back exactly what it wrote before because information cannot be tampered by clients as it happens with cookies. Additionally, the information remains hidden to client's eyes so it can store confidential or just internal uninteresting information. Last but not least, a PHP session allows to store most data types supported by PHP. A cookie can only store plain text.
The weak link in sessions is that HTTP is a stateless protocol so the client needs to identify itself on every request (unlike it happens in other network protocols as FTP, SSH or SMTP). Earlier implementations would transmit the session ID in the URL itself. It was later improved to only use cookies and cookies can be configured to be restricted to encrypted connections. But, yes, if something intercepts your HTTP traffic and finds out your session ID he can easily impersonate you because most sites don't care about implementing further checks. However, that's why HTTPS is encouraged nowadays.
I have a question regarding usage of cookies for standard login purposes. Say my php script saves a cookie into a users computer each time he logs in. The cookie value is say "Mike" after his username at the website. Can that user somehow manipulate that cookie in his browser to change the value to say "Admin" so suddenly he has access to administration of the website?
If this could happen how to solve such security risk?
--
Additionally... What if someone was to copy cookies from my browser, either he would stare at my computer screen and copy cookies and values into his computer or such intruder could steal cookies from my browser via JavaScript.
How is that taken care of?
Yes, that is a security problem, which extends to any information provided by the client.
Cookies are stored on the user's machine. They can be modified in any way. In fact, the cookies can just be created on the fly and sent via several utilities for making HTTP requests. It isn't even a browser problem.
Never trust any data that comes from the client.
Yes, a user can manipulate cookies if they're stored on their computer.
Use a session.
A 'session' is the server-side storage of connection-relative information that is linked to the user through a variable which is passed back and forth, most often a cookie, however logically, anywhere will do if both your client and server can handle it.
This 'session' is often represented by an integer which the client and server both know.
The problem is, if another client has a session open on the server, we (as a client) could 'hi-jack' this session by replacing our given id with a random id until one is found. The server would now believe we are in fact the other use and could give us access to their private informatin.
For this reason, we have 'keys'. A key is a unique, often alphanumeric, code which is changed on each request-response pair with the server, ensuring that only those who have the latest key are able to gain access.
YES
They can manipulate, edit, modify, create and delete cookies.
You should only store a hash key that you use on the server to look up in a database anything that should be secure.
Yes, users can manipulate cookies. The best way to handle it is to not store user credentials in such a manner that they can gain admin access by changing their user name.
The specifics on how to do this are pretty deep, but a good start would be to just store the users's session identifier instead. That has its own issues, but won't let people break things quite so easily.
Cookies are clientside which means that they can be read, write and delete by the client. A cookie manager plugin makes it easier to change the cookie value.
http://www.ehow.com/how_7149468_edit-cookies-computer.html
Yes a user can easily manipulate the cookies by just going to cooking option which all popular browser provide
I've made a website which has registration/login. I can see the PHPSESSID cookie in Chrome's Developer Tools, so I'm wondering how can I use this session id value to hijack into the account I'm logged, from let's say a different browser, for simplicity's sake?
Should a secure website be able to determine that this session is being hijacked and prevent it?
Also, how come other big sites that use PHP (e.g. Facebook) do not have PHPSESSID cookies? Do they give it a different name for obscurity, or do they just use a different mechanism altogether?
Lots of good questions, and good on you for asking them.
First.. a session is just a cookie. A 'session' is not something that's part of the HTTP stack. PHP just happens to provide some conveniences that make it easy to work with cookies, thus introducing sessions. PHP chooses PHPSESSID as a default name for the cookie, but you can choose any you want.. even in PHP you can change the session_name.
Everything an attacker has to do is grab that session cookie you're looking at, and use it in its own browser. The attacker can do this with automated scripts or for instance using firebug, you can just change the current cookie values.
So yes, if I have your id.. I can steal your session if you didn't do anything to prevent it.
However.. the hardest part for an attacker is to obtain the cookie in the first place. The attacker can't really do this, unless:
They have access to your computer
They somehow are able to snoop in on your network traffic.
The first part is hard to solve.. there are some tricks you can do to identify the computer that started the session (check if the user agent changed, check if the ip address changed), but non are waterproof or not so great solutions.
You can fix the second by ensuring that all your traffic is encrypted using HTTPS. There are very little reasons to not use HTTPS. If you have a 'logged in' area on your site, do use SSL!!
I hope this kind of answers your question.. A few other pointers I thought of right now:
Whenever a user logs in, give them a new session id
Whenever a user logs out, also give them a new session id!
Make sure that under no circumstances the browser can determine the value of the session cookie. If you don't recognize the cookie, regenerate a new one!
If you're on the same IP and using the same browser, all you have to do is duplicating the session ID (and maybe other cookie values: not really sure if browser specific things like its agent string is tracked/compared; this is implementation dependant).
In general, there are different ways to track users (in the end it's just user tracking). For example, you could use a cookie or some hidden value inside the web page. You could as well use a value in HTTP GET requests, a Flash cookie or some other method of authentication (or a combination of these).
In case of Facebook they use several cookie values, so I'd just assume they use one of these values (e.g. 'xs').
Overall, there's no real 100% secure way to do it (e.g. due to man-in-the-middle attacks), but overall, I'd do the following:
Upon logging in, store the user's IP address, his browser agent string and a unique token (edit due to comment above: you could as well skip he IP address; making the whole thing a bit less secure).
Client side store the user's unique id (e.g. user id) and that token (in a cookie or GET value).
As long as the data stored in first step matches, it's the same user. To log out, simply delete the token from the database.
Oh, and just to mention it: All these things aren't PHP specific. They can be done with any server side language (Perl, PHP, Ruby, C#, ...) or server in general.
Someone sniffs the session ID cookie and sets it for a subsequent request. If that's the only thing authenticated a user, they're logged in.
Most sites will use authentication based on cookies in some form. There are several ways to make this more secure such as storing info about the user's browser when they log in (e.g. user agent, IP address). If someone else naively tries to copy the cookie, it won't work. (Of course, there are ways around this too.) You'll also see session cookies being regenerated periodically to make sure they aren't valid for a particularly long time.
Check out Firesheep for a Firefox extension that performs session hijacking. I'm not suggesting you use it, but you may find the discussion on that page interesting.
I've been googling this for some hours but everyone handles it in a different way.
So I'm wondering how to handle the informations when someone logs in.
I thought that I'll save the user ID, name and user-agent-data in the session. But what if someone steals the cookie content and replaces his own cookie with the stolen one?
And yeah, that's actually my question. How can I "protect" the user? Checking the IP as well? Anything else?
Thanks,
Albin.
Not to have a session id or cookies in general stolen is a task the browser has to handle. There are some conceptual means to prevent 3rd parties to learn the contents of your cookies like the same origin policy.
You can help the browser by setting the http-only flag for cookies. See the argument $httponly for setcookie. If a cookie is marked as http-only, the browser will not make it accessable for scripts like javascript. The cookie will only be transferred in the original http-header. this will practically eliminate the risk of XSS-based session capturing, as they usually use javascript.
Another big attack is the man in the middle attack. An attacker has access to the traffic between your client and your server. He now can read the http headers, therefore the cookies and imitate the request. He could even spoof your client's IP address. To protect against this kind of attacker, you will need an encrypted connection. Most websites use HTTPS for this purpose.
If you only need authentication, you can also use HTTP's digest authentication. There is a working example for digest auth using PHP here.
Testing if the IP stays the same would be one way. However it's better to test wether it matches a given subnet mask (e.g. 255.255.0.0), because some users might have dynamical IPs.
Another "protection" measurement is testing wether the user agent of the browser is the same that was used to log in, but of course that's pretty easy to bypass.
Make sure you set the cookies only for your domain or subdomain, and also make sure to check your code not to allow any XSS flaws, as these often can be used to steal cookies.
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.