What is the best approach if I've to use an LDAP authentication - which isn't in my control - but after it's successful I'd like to make some pages available to a set of users? Do I have to store the selected users data somewhere?
It's hard to give concrete advise whithout knowing what you already tried and did. So it's a fairly broad question I can't give a concrete answer to.
But I can give you some hints as to where to look for more information:
You will need to do authentication against LDAP. There are a lot of examples around on the web.Which one you use depends on whether you are using an framework or want to solve it with plain old PHP. One - but by far not the only - example can be found here.
You will need some form of authorization whether the logging in user is allowed to see those pages cor not. You can euther do that by storing a lit of usernames that are allowed to see the pages or by using a certain LDAP-group whose users are allowed see the pages.
Whether you store the user-informations persistent in a database or in the session depends on the use-case. I wouldn't store the user-information persistently but simply in the users session after the user logs in. But as I said, that depends on the use-case.
I hope that helps somehow.
Cheers
Related
I have a dynamic page where it should take data from a db. So the approach I thought of was to create the dynamic page with this php code at the top
<?php $pid = $_GET["pid"]; ?>
Then later in the file it connects to the database and shows the correct content according to the page ID ($pid). So on the home page, I want to add the links to display the correct pages. For example, the data for the "Advertise" page is saved in the database in the row where the pid is 100. So I added the link to the "Advertise" page on the homepage like this:
Advertise</li>
So my question is, anyone can see the value that's send on the link and play around by changing the pid. Is there an easy way to mask this value, or a safer method to send the value to the page.php?
The general concept you're looking for is Access Control. You have a resource (in this case, a page and its content), and you want to control who can access it (users, groups, etc), and probably how they can access it as well (for example, read-only, read-and-write, write-but-only-on-the-first-Monday-of-the-month, etc).
Defining the problem
The first thing you need to decide is which resources you need access control for, and which you don't. It sounds to me like some of these pages are supposed to be "public access" (thus they are listed on some kind of index page), while others are supposed to be restricted in some way.
Secondly, you need to come up with an access policy - this can be informally described for a small project, but larger projects usually have some structured system for defining this policy. For each resource, your policy should answer questions like:
Do you have some kind of user account system, and you only want account holders (or certain types of account holders) to access it? Or, are you going to send links to email addresses, and want to limit access to just those people who have the link?
What kind of access should each user have? Read-only? Should they be able to change the content as well (if your system supports that)?
Are there any other types of restrictions on a users' access? Group membership? Do they need to pay before they get access? Are they only allowed access at specific times?
Implementing your policy
Once you've answered these questions, you can start to think about implementation. As it stands, I think you are mixing up access control with identification. Your pid identifies a page (page 100, for example), but it doesn't do anything to limit access. If your pages are identified with a predictable numbering scheme, anyone can easily modify the number in the request (this is true for both GET requests, such as when you type a URL into an address bar, and POST requests, such as when you submit a form).
To securely control access there needs to be a key, usually a string that is very difficult to guess, which is required before access is granted. In very simple systems, it is perfectly fine for this key to be directly inserted in the URL, provided you can still keep the key secret from unauthorized users. This is exactly how Google Drive's "get a link to share" feature works. More complex systems will use either a server-side session or an API key to control access - but in the end, it's still a secret, difficult-to-guess string that the client (user or user's browser) sends to the server along with their request for the resource.
You can think of identification like your street address, which uniquely identifies your house but is not, and is not meant to be, secret. Access control is the key to your house. Only you and the people you've given a key to can actually get inside your house. If your lock is high quality, it will be difficult to pick the lock.
Bringing it together
Writing code is easy, designing software is hard. Before you can determine the solution best for you, you need to think ahead about the ramifications of what you decide. For example, do you anticipate needing to "change the keys" to these pages in the future? If so, you'll have to give your authorized users (the ones that are still supposed to have access) the new key when that happens. A user-account system decouples page access control from page identification, so you can remove one user's access without affecting everyone else.
On the other hand, you also need to think about the nature of your audience. Maybe your users don't want to have to make accounts? This is something that is going to be very specific to your audience.
I get the sense that you're still fairly new to web development, and that you're learning on your own. The hardest part of learning on one's own is "learning what to learn" - Stack Overflow is too specific, and textbooks are too general. So, I'm going to leave you with a short glossary of concepts that seem most relevant to your current problem:
Access control. This is the name of the general problem that you're trying to solve with this question.
Secrecy vs obscurity. When it comes to security, secrecy == good, obscurity == bad.
Web content management system. You've probably heard of Wordpress, but there are tons of others. I'm not sure what your system is supposed to do, but a content management system might solve these problems for you.
Reinventing the wheel. Good in the classroom, bad in the real world.
How does HTTP work. Short but to the point. A lot of questions I see on SO stem from a fundamental misunderstanding of how websites actually work. A website isn't so much a single piece of software, as a conversation between two players - the client (e.g. the user and their browser), and the server. The client can only say something to the server via a request, and the server can only say something to the client via a response. Usually, this conversation consists of the client asking for some resource (an HTML web page, a Javascript file, etc), to which the server responds. The server can either say "here you go, I got it for you", or respond with some kind of error ("I can't find it", "you're not allowed to see that", "I'm too busy right now", "I'm not working properly right now", etc).
PHP The Right Way. Something I wish I had found when I first started learning web development and PHP, not seven years later ;-)
It is always safer to $_POST when you can, but if you have to use something in the query string, it is safer to use a hash or GUID rather than something that is so obviously an auto-incremental value. It makes it harder to guess what the IDs would be. There are other ways values can be past between pages ($_SESSIONs, cookies etc), but it is really about what you want to achieve.
Sending it to php is not an issue, should be fine.
What php does with it afterwards... that's how you secure.
First thing I'd do is make sure it's an integer.
$pid=(is_int($_GET['pid']))? $_GET['pid'] : 1; //1 is the default pid, change this to whatever you want.
Now that you know you're dealing with an integer, use $pid after that and you should be good to go.
I am designing a web application that is heavy reliant on database tables/records and have already designed the login system. As it stands, the login system creates an element in the session to verify that the user is logged on. This works fine.
However, as I've been coding my application--I have found a constant need to check that my users are authorized to perform certain actions.
For example--I have a feature which allows users to edit their profile at www.mywebsite/account/edit/1 -> 1 being the Id. In terms of future scalability, is it practical to perform a database query to check that the current logged in user has access to edit their information after arriving at that URL?
My concern, of course, is that someone would just put in a random Id to edit another account.
I have also thought about creating a form between every transition to post this data, yet that comes with a load of limitations itself.
I was wondering if anyone had hit the same problems and found an overall solution to this problem?
This is a concern that everyone addresses at some point or another. The way I see it, you're really asking a couple of questions:
How do I make sure a user is authorized to access something? and
Is checking the database every single time really the best way to do it?
With respect to the first question: the approach you're taking is probably the only realistic one. It boils down to this: whenever a user needs to do something, your application needs to check something to see if they're allowed to do it. What is that something? It's called an Access Control List (ACL).
You could hard code the ACL in your application, but that's a really bad idea. So that means you have to store the details of an ACL somewhere. And when we start talking about storing something in our applications, the obvious answer is (almost) always in the database.
Which leads to the second question... a quick check of the database to see if a user has access is generally not going to be a huge bottleneck, provided your database design is sensible. You're going to be doing something like SELECT key FROM acl WHERE key='something' AND user_id='current user ID'; and checking to make sure you get at least one result. It's going to add a little overhead to your application, but what's the alternative? Some sort of hard coded ACL? Loading the full ACL for your application and searching it for the key and user ID in your PHP code?
If you're really concerned about the overhead involved with your ACL stored in MySQL, you could look at some of the other databases like MongoDB or CouchDB which should be faster for simple key/value pair lookups (note that I've looked at both MongoDB & CouchDB, but not used either in applications), but I think you'll find that, for most applications, doing it in MySQL should work just fine.
i have a 'working' login form which validates and uses bound variables.
My site now is almost ready (content wise) to be put online so im now coming back to the login process as i want that 100% before releasing to public.
I want to have a remember me function, but cant find any help / tutorials on going about it via a database. I read a post here while back that said the best way was to store hashed values in DB and check it against a cookie.
I cant find this post anymore and googling returns old code or simple cookies for the function. I can find various posts talking about the area, but no code i can view andtry ti implement.
I want to learn the 'proper' way to do this so just need pointing in the right direction.
As well as this, i will create a delay timer on incorrect attempts and also use some hidden fields. But the remember me comes first.
Thanks, Craig.
Using cookies and checking the value in the database would be the best approach. There are many tutorials of how you can make such a function. this post seems to cover what you need to know.
As mentioned there, you need to remember that a remember-me cookie can't be 100 % secure, so when the user logs in with the cookie and is about to edit some very sensitive information, a re-login should be required.
I am just looking for some advice on the new UK Cookie Law and how it affects PHP sessions. I understand that you do not need the users to opt in when a cookie is "strictly necessary" and the example given is adding an item to a shopping cart.
I am using similar functionality that remembers what you have stored in a contact form, which I feel is strictly necessary use of a session and therefore no opt in is required.
However the confusion for me arises because I have a session_start(); at the top of each page, which means the cookie is set straight away. Some users will not then go to use the contact form, so this means that the cookie is not strictly necessary for them.
I could remove session_start(); from the top of each page, but this functionality is used throughout a number of websites and it would be preferable if we could leave it in.
Could anyone shed any more light on this?
The simple answer is that you're probably going to be okay, the extent to which this law will even be enforced is massively up for debate anyway.
We will enforce the law proportionately. We’ll look at the risks if
and when customers complain to us. If a websites’ cookie and privacy
is a risk to many people, we may then take action.
There is a balance to be struck though, as not all cookies are equal,
and our enforcement approach will bear this in mind.
For example, someone may complain about a cookie placed without their
consent, but if it was just used to remember essential details rather
than to gather information to be used for marketing purposes, then it
may not be appropriate to act.
(Source: The ICO's Dave Evans on EU cookie law compliance)
From what I have heard, the ICO is going to be fairly liberal in the interpretation of the law, the most important thing to do is show that you are making changes to comply with the spirit of the law.
I think that as the form is essential to the site, you don't need to prove that it is essential to 100% of users.
In an ecommerce site it is being taken as read that it's ok to have cookies that relate to shopping bag without asking permission, as it is essential to the function of the site, even if a particular user doesnt actually add anything to their basket.
No, I think the php sessions donot fall under the Cookie Law. There is are a lot of differences between Cookie and Session.
For example, read here:
http://php.about.com/od/learnphp/qt/session_cookie.htm
Also, if you read the law:
http://www.bis.gov.uk/assets/biscore/business-sectors/docs/i/10-1132-implementing-revised-electronic-communications-framework-consultation.pdf
It says,
"The provisions of the amended Article 5(3) refer to any attempt to
store information, or gain access to stored information, in a user’s
equipment" (pg 57)
So you see, it says "user's Equipment" and sessions are not stored there, they are stored at server http://ejvyas.blogspot.com/2010/02/where-is-stored-is-it-in-browser-or-at.html
If you're able to store a PHP session cookie on a user's computer to enable the 'essential' functionality of your website - what stops you then associating additional information with that visitor without their consent/knowledge..? (Apart from it being illegal.)
After all, all the information you store - except the cookie ID which is client side - is kept on the server side and the user can't do anything to view/modify this?
So in short, if the user 'allows' you to store a PHP session cookie on their computer there's nothing to stop you storing lots of other data about their visit? - IP, Browser, OS etc...
Having read GDPR and having knowledge of how sessions work in php I have to tell you this:
1. session_start() in php is called before headers because you cannot send additional headers (as php session does) after the page loads and headers have already finished.
2. Because this happens sessions in php is an essential thing of the language itself for the language to work properly so it is something you need. Not want.
3. A php session stores a cookie in the users machine with the session id to know the connection. Not the user. For example the server says "I have a request from someone. To not mix the requests from everyone keep an id of everyone". The person, ip, geolocation or any other data is not known at the time. To be clear of this session_start() not storing any other data but the session id is how the server side language php and the server itself works and it is not possible to have consent before you initialize it.
4. But: before storing any other data you have to inform. I believe you have to inform when you start doing it, how you do it, how long you do it and what you are storing. So no more tracking on guests. Third parties like google, facebook and other implementations on your page is another story. You should pretty much remove it for guests if third parties don't allready do.
Simple: starting a session before headers is mandatory for php. Storing data needs consent so when the user logs in, registers or any other interaction inform the user and store a consent in the database (for you) and in the cookie itself (for the user to know).
I’m trying to find a lightweight PHP session handling library, i’ve googled and fallen into confusion.
I want a library that stores sessions using MySQL
allows kicking out of logged in user
does ip matching
browser matching
secure to session hacking etc.
Any ideas?
If you're familiar with MySQL and PHP it's rather trivial to write your own session handler.
http://php.net/manual/en/function.session-set-save-handler.php
It may be faster to write a personalized one than searching for exactly what you want.
You could have a look at this article by Chris Shiflett, which describes making changes to session_set_save_handler().
You may want to check out this class that I made a while ago... it does everything that you say expect for kick a user out, but you can mae a function that does that in 5 minutes (just call the delete method with the user id that you want to kick out).
It still needs documentation and some tweeks here and there, but you can give yourself an idea of how is done.
I wouldn't relay on user's IP for security, if they're using rotating IP (some cellphones companies) or they're behind thor or something you're going to have issues, use user_agent instead.