PHP Security question

I'm relatively new to PHP, and I just wanted to pick the brains of you more experienced PHP developers out there. Imagine this scenario:

1) When a person logs in successfully, a variable with a value is set in the session, like maybe $_SESSION['key'] = '8asdf3134jdfk;"; only upon a successful login will this occur, nowhere else.

2) From this point on, at the very beginning of EVERY page will be PHP code that checks for the presence of a session AND the presence of this 'key' variable and its value.

So I'm thinking, even if a hacker managed to fabricate a session, he won't have this 'key', and hence, any PHP in my application simply won't run.

Is this a valid security strategy? If not, please explain. Thanks.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

First, nobody can really "fabricate" a session (if they had the access to do so, they'd already be far enough into the system that they wouldn't need to do it).

A session is very much like a safety deposit box. Basically, the client (the end user's browser) is given a cookie with a unique ID / key. That cookie identifies the user's session ID and acts like a key to unlocking the box that holds all the contents of a session.

When the browser requests a PHP page from the server, it also provides the session ID stored in that cookie. The server then takes the session ID and looks for a corresponding file in the area of the server that stores all the session data. If it finds a corresponding file, it will take the data from inside that file and then populate the $_SESSION array with it.

The end user / browser will never be exposed to the contents of $_SESSION (unless you write code to display the contents) - all the browser knows is its session ID that it has in that cookie.

As mentioned before, a hacker can't really fabricate a session because a session requires a combination of both the session file on the server and the corresponding cookie on the browser. So assuming that a hacker doesn't have access to create session files, then all he/she can do is create a cookie and hope that the session ID is valid.

Given the complexity and length of the session ID, it's virtually impossible to simply guess a valid session ID, since they're random values and sessions are only valid for a short period of time. However, if a hacker had access to an end user's computer who already had a session going, then that hacker could theoretically copy the cookie onto his/her own machine and instantly impersonate their victim. The browser, nor the server, would know the difference.

You can reduce the chance of that happening by rotating session IDs frequently (so if a hacker DOES get a hold of a valid one, then it might not work by the time he/she tries to use it).

All that said, I'll admit that it's unusual to hear of a "key" stored in the session like that for running an application. I'm not saying it's wrong - just unusual. If you can expand on the details, we may be able to provide some more advice.
Dave BaldwinFixer of ProblemsCommented:
That's basically the way I control logins.  Check username and password and then set a $_SESSION variable that identifies them as logged in.  And #2 is Essential.  And of course, Ray has an article all about this.

"fabricate a session"?  Since the session info and the $_SESSION variables exist only on the server, it is difficult for an outside user to create a fake session.  It could be done if someone broke into the server but that would not be thru your PHP code.  What is much more likely and the center of most security problems is that the unwanted person has gained access to a valid username and password.  

Believe it or not, most of the time it is because the legitimate user gave it to them.  That's the primary method Edward Snowden used to gain access to 'protected' files is by asking people who did have legitimate access to give him their access codes.  And they did.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
elepilAuthor Commented:
Thanks to gr8gonzo and Dave for responding.

I just thought of this scheme, and I'm glad to hear Dave is doing it, and neither of you are denouncing it as ineffective. I feel very relieved that there is no hacker counter defense against this.

When I said "fabricate", I thought that was what some other users meant when they said hackers can spoof the browser header information. I just used that word based on my very little understanding of how hackers break into sites.

But are you both in agreement that applying what I had just described will make ALL the rest of my PHP pages safe, and that the only real risk then would be a hacker who has a valid username and password?
HTML5 and CSS3 Fundamentals

Build a website from the ground up by first learning the fundamentals of HTML5 and CSS3, the two popular programming languages used to present content online. HTML deals with fonts, colors, graphics, and hyperlinks, while CSS describes how HTML elements are to be displayed.

Dave BaldwinFixer of ProblemsCommented:
Yes and that is almost impossible to defend against because it is valid.  There are a variety of schemes for enforcing higher security.  Facebook and other sites track where you are logging in from both IP address and whether the appropriate cookie is set.  It think Facebook may also track the 'User Agent' to get some idea of the device you're using.
elepilAuthor Commented:
Thanks to both of you for responding.

Dave, if that's the case, protecting my site isn't that hard after all.

In one of my earlier posts, I had described the scenario of a Get Customer PHP script, and I was asking how to stop someone from writing his own page with a loop and incrementing the custID by one and pulling in all customers until he has them all. So that means I can stop him with this method since presumably, he would not have a valid login/password info. He would then be halted by this technique we're talking about.
Dave BaldwinFixer of ProblemsCommented:
If that is the AJAX request you were asking about, someone would normally have to be already logged in to try that method.  Note that even 'background' pages need to be protected.  The example I gave about checking the referrer was a page that was not visible in the browser but was the 'action' page for a form.  

It's the details that matter.  Note that hackers will scan your site looking for 'action' pages in particular.  I have a search function on a couple of sites and it gets break-in attempts fairly often.  But in that code, I never use the input directly.  It always gets processed into something that can't be used for SQL Injection.
elepilAuthor Commented:
Would using prepared statements provide 100% protection against SQL injections? Because that's all I use.
Dave BaldwinFixer of ProblemsCommented:
I don't know because I don't use them.  Ray is fond of saying "accept only known good inputs".  I suppose that might be difficult sometimes but it is the best idea.  On my search pages, I strip out characters that I know are not in the search tables.  In particular, ';' always must go because that is the 'end of statement' character in MySQL.  That is used to 'end' the current statement and start a new one.
I'd suggest opening that as a different question (the prepared inputs one). Remember, part of the whole Q&A process is creating searchable answers from Google, so someone might have that specific question, too.
I'm a little troubled whenever I hear anyone suggest that security isn't "hard" after all. To me, security IS always and SHOULD always be hard. Basic security is easy, but basic security only shuts out the laziest of hacking attempts. Thorough security is harder because you have to adopt a completely different mindset. You have to think like a hacker who is willing to fill your database with garbage if it means exposing a vulnerability. A skilled hacker isn't going to go after just the low-hanging fruit. He or she will consider many options:
- Vulnerabilities within your web server or PHP build
- Accessing the database directly
- Attempting to access known / common script vulnerabilities
- Testing for SQL injection
- Testing for parameter manipulation
- Testing for XSS vulnerability
- Testing for data exposure during network requests / AJAX calls
...and more. Any single vulnerability can often lead to a full compromise of the system.

Regarding your other note about incrementing a parameter (customer ID) to get to information that they're not allowed to access, it can be good to have a session value used instead of a parameter like that, but customer ID will likely not be the only parameter you have to deal with.

It can be useful to simply use checksums or keyed hashes to "validate" the parameter values. See the "ID MANIPULATION" section of my article for a very very simple example:

You can secure all your parameters this way, even if a session cookie is compromised.

Note that the article is about 6 years old now, so there's probably at least some things a little outdated.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.