elepil
asked on
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.
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.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
ASKER
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, 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.
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.
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.
ASKER
Would using prepared statements provide 100% protection against SQL injections? Because that's all I use.
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:
https://www.experts-exchange.com/articles/1263/5-Steps-to-Securing-Your-Web-Application.html
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.
- 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:
https://www.experts-exchange.com/articles/1263/5-Steps-to-Securing-Your-Web-Application.html
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.
ASKER
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?