is this a secure way

[bluetoother]

i heard that some hackers can write their own session valuesin any web site if it is not secured by SSL authentication.//correct me if iam wrongi thought about some way to give sessions to userswith values generated by some encryption algorithm.and every web page in my web site should check if that value in the sessioncan be a key for the same algorithm so i can make check if the given is not generated using my algorithmi think many sites use such way, by giving a key to the uses, that can be seen in the url.// another issueis the hacker able to reach the folder that contain my web site php filesso he can see the algorithm and generate keys to act as admin in my web site for example.

[boen_robot]

is the hacker able to reach the folder that contain my web site php files

Possibly, if the server has not forbidden users from seeing this folder AND doesn't provide an index file. But he still wouldn't be able to see their source code, as when he downloads or starts the page, the PHP engine will start and (s)he'll only see the result.

so he can see the algorithm and generate keys to act as admin in my web site for example.

If the algoritm is in another, non protected file, yes. It's possible. But if it's embedded in the PHP file, the only way he would be able to see the source file (and thus the algoritm) would be for YOU to accidently disable PHP support at some point OR for him to get access to your FTP account somehow.

i heard that some hackers can write their own session valuesin any web site if it is not secured by SSL authentication.

True. I can even tell you a program that will allow you to send arbirary requests: fiddler. It's a great debugging and analyses program AND a newbie hacker's best friend.

i think many sites use such way, by giving a key to the uses, that can be seen in the url.

I haven't worked with sessions much, but I think you're right.

[Skemcin]

Session hijacking is possible but very hard to do - but nonetheless possible.The session identifiers that ColdFusion uses can be configured to be a random GUID created by the server (not sure how php or asp does it). This, typically, is enough unless you've left other holes in your application (which is often the case and easier to manipulate and do not warrant the hacker time to play with sessions). You could add more processes on the server side of things to encrypt and decrypt the session ID with each page request. Just be sure to monitor the performance foot print when doing so. You can use a couple plugins for Firefox to do this. YSlow is a great extension to the FireBug plug in.Hope that helps.

[justsomeguy]

The session ID is usually stored in a cookie, so you might be able to require that the cookie be sent over SSL but that's about it. I can't really think of a way that a user could alter the session, does anyone know how that can be done? The server should be storing the session data in a location that is not accessible to the web, so people should not have direct access to anything in the session. Also, I'm not sure what type of request you would forge in order to cause the server to modify the session, it would seem to me that if PHP doesn't alter its own session then nothing else can.How have people heard the session being hacked? I've never heard of it. Someone can hijack a session if they are using a network traffic analyzer and use someone else's session ID to gain access to their session, but I'm not aware of a way to change session data on any server. Articles like this one:http://www.net-security.org/article.php?id=925talk about ways that session can get hijacked and how to prevent that. But I don't think this is true:

i heard that some hackers can write their own session values

Where did you hear that?

[zppblood]

I can't really say much as the others I'm sure summed it all up. If you allow session ids through the URL, a hacker can create their own session by just entering a random string that's replaces the one you assigned to them, and send the URL with their session id to someone else, have them log in, and then check the URL and will see what the user would see when logged in if it's not protected (you can check user's IP, what browser they are using, etc.)

[bluetoother]

i use another way to make it harded for the hacker to know what type of value he has to enter to act as a member in my web site or simply be an administrator ,,iam giving each user a session with user's ID i the databaseand another one showing the group that the user belong tolike this :

$_SESSION['user_group']=1; // for admins$_SESSION['user_group']=2; // for normal users

is this way good ?

[justsomeguy]

If it does what you want then it's good. Again, I don't think anyone can write values to the session. If you disagree, point to something that shows otherwise.

[jhecht]

if you go to youtube, and you type in [insert coding system name here] hack, you come up with lots of stuff. It involves people with loads of time and alot of pre-knowledge of how windows(or mac) works. In one you see the guy physically ALTER his cookie information to gain access to the administration panel of some forum board, i believe phpBB 1.5 or the 2.0(back when it was beta/new). i preffer not to use sessions that rely on cookies, or allow any form of un-restricted FTP access to my site, simply because those are giant holes. Cookies are stored client-side, meaning someone good enough can alter them. i preffer to use databases and other things that are solely SERVER oriented. but perhaps my way of coding isn't all that safe either. Given enough free time, anyone can hack ANYTHING. It's just a matter of how much free time do you want them to need to hack your system?

[justsomeguy]

In one you see the guy physically ALTER his cookie information to gain access to the administration panel of some forum board, i believe phpBB 1.5 or the 2.0(back when it was beta/new). i preffer not to use sessions that rely on cookies

That's still just hijacking the session though. Depending on the specific forum and how it does authentication, he might have been able to change a username and password stored in a cookie, or set a variable in a cookie to give him access or whatever. If he can do that and gain access then the system isn't very secure, it's a terrible idea to keep a variable in a cookie like "admin_login=1" or something, and it's also not very good to store a username and password, unless you want someone to be auto-logged in when they come back, or unless you are encrypting everything. Or, he might have gotten someone else's session ID and updated his cookie with someone else's session ID to use that person's session.But changing values in the cookie is not the same as changing values in the session. I've changed cookie values myself while I've been working on sites just because it's quicker then going through the site and having the browser change the cookie, that's easy to do myself. Opera makes it very easy to do something like that (Tools -> Advanced -> Cookies -> Edit). But I've never been able to change a value in the session.Also, cookies are the best and most secure way to use sessions. If you aren't using cookies with the session, then the only other alternative is to pass the session ID through every URL, and that is not secure at all. It's too easy for someone to log in somewhere and copy and paste a link to someone with their session ID in it and have that person be logged in when they click on the link. That's why cookies are used, so that situation is not a problem. The server might store the session in a database or somewhere more secure then a world-readable temp directory, but the client still needs a way to send the server the session ID, and cookies are the best way to do that. Most servers have the session.use_only_cookies option enabled to stop the session ID from appearing in URLs if the user has cookies disabled. In that case people without cookies simply aren't able to use the session. There are also several session cookie options you can set to get session cookies to behave how you want to. You can set the lifetime of the cookie, you can make the cookie HTTP-only and inaccessible to Javascript which avoids cross-site scripting attacks, and you can specify that the cookie should only be sent over a secure connection so that eavesdroppers can't intercept it.So, my question still stands. Does anyone know of any ways to change a value in the session? Given this script:

<?phpsession_start();if (!isset($_SESSION['testvar']))  $_SESSION['testvar'] = '';echo $_SESSION['testvar'];?>

Is there any method that someone can use to modify the value of $_SESSION['testvar'] without FTP or shell access to the server?

[jhecht]

What I'm saying, justsomeguy, is that yes, sessions are good. Knowing who's logged in and when is a very good idea. However, COOKIES are stored upon a clients machine, so i try to avoid them if at all possible. The only cookies i set in systems are auto-login cookies that are, even then, checked very thoroughly. I'm saying i preffer sessions stored server-side, as they cannot be browsed to by the user like cookies can be to anyone who knows where they're kept. And The answer, very simply to your question, physically, no, someone could not forcibly change the file itself without(as in the code where the PHP setting the variable) is, but they could find loopholes and tricks which make it very possible.As already said: Anything in the world is hackable given enough time. The question is, how much time do you want someone to have to take to hack it?

[justsomeguy]

Right, I agree that it is a much better idea to store sensitive information in the session instead of in a cookie. I'm not trying to argue that point, I'm responding to this:

i heard that some hackers can write their own session valuesin any web site if it is not secured by SSL authentication.//correct me if iam wrong

I think that *is* wrong. I've never heard a case of a client modifying a session variable without FTP or shell access to the server, in any language.

[jhecht]

It is but it isn't. A good enough hacker could figure out tricks to write their own session information, yes. Would SSL stop them necesarily? No.

[justsomeguy]

A good enough hacker could figure out tricks to write their own session information, yes.

I just don't agree with that. I can't find a single example of that happening, but there are hacking tutorials all over the place for changing cookie or post values. If someone was able to figure out a way to compromise the session I think there would be quite a bit of discussion about it, both in hacker circles and in software development circles.

[jhecht]

You've never met my friend Mitch. It's how he makes a good deal of his money is the fact that he is a white-hat hacker and tells people that he can fix the security holes for a small fee.It is possible. Not saying its all that easy. But it is possible.

[justsomeguy]

OK, ask your friend Mitch then if he has ever heard of anyone doing something like this.Both PHP and LISP are Turing-complete languages, so it's technically possible that someone could implement PHP using LISP, or they could implement LISP using PHP. It's completely impractical to do that and no one ever would, but it's technically possible. It doesn't matter if it is technically possible for someone to write values into the session if it's not practical to do so. Something being prohibitively impractical and impossible is almost the same thing. If the exploit is not in the wild, then it doesn't matter if it's only theoretically possible to do. The OP was asking if he needs to go overboard on anti-hacking measures in the session. I would not tell him to do that just because it's theoretically possible if there is not even a proof-of-concept out there.I'm not wondering whether it is theoretically possible to do this, I'm wondering if people are doing it.

[jhecht]

If nubes are "smart" enough to store things the wrong way in sessions, I'm sure you could find stories of hackers who did it, Mitch more than likely being the hacker in those cases.

[justsomeguy]

Well yeah, an insecure system is an insecure system regardless of the language or platform. But that's not what I'm talking about, I'm talking about a properly-used session like I pasted above, I would put $50 on it that a "normal" use of a session like that using at least PHP 5.2.4 cannot be compromised so that anyone, Mitch or not, can change the value of the testvar session variable without FTP or shell access to the server.I just don't think it can be done. If anyone can prove otherwise I've got $50 for them, no joke.