Access Control

[Juxt 0]

I'm going to make a PHP called add.php?item=example&price=999, that will an item and price to a database. I plan to access this page via an external program, but I don't want users to be able to add things into the database.I've thought about using cookies to restrict access, but they can just look at the headers being sent and imitate that cookie. I've also thought about encrypting, which will make it a little harder. Is there an even better way to solve this?

[jlhaslip 4]

First reaction is that the Form method you are using is wrong. Your query string will show in a Link.The solution would be to modify the php Form to use the POST method so the input is more secure.The query string would not display and a normal user would not be able to easily add the data for input into the database.Second, review the Tutorial section here at the Xisto for a Log-in script you understand and can implement.Third, there is a Tutorial about User Permissions for a Log-in script that was written by me. The full package is not yet complete. (got sidetracked)It has several 'Levels' of Users and the intent is to built a system which allows various users consent to perform certain actions as defined by their 'Level'. IE: a member can do more than a guest, a Moderator more than a Member, and an Admin even more things. Interested?In order to use this system, or for the regular Log-in script, you will require knowledge about Sessions so the Login will persist across several hours/days/months. These are typical of the system you describe.Summary: drop the GET Method and the query stringdevelop a Log-in script using Sessionsdefine User levels and permissions on every page in the siteAre you working towards a Commercial Sales Application? If so, you might be better off finding a full eCommerce script that already includes these features.Hope this helps outline the type of script you need to be looking for.

[Juxt 0]

Well, I want to use an outside program to do this, so Sessions wouldn't really work right? And I don't want a login thing, I only want my program to be able to add to this database, rather than certain people.I guess I could use Post, but that would only be slightly more secure since you can just look at the headers.Sorry about the confusion.

[Nabb 0]

I'm going to go under the assumption that you have the intention of getting free hosting here at Xisto. When you do, you will have access to your own cPanel.

You have the option to 'Password Protect Directories'. A simple solution would be to have the file in a subfolder and password protect it. For example, instead of placing the file at /shop/add.php, define an 'admin' folder that is password protected and use /shop/admin/add.php.

 

I've thought about using cookies to restrict access, but they can just look at the headers being sent and imitate that cookie. I've also thought about encrypting, which will make it a little harder. Is there an even better way to solve this?

I don't understand what you're getting at. Who is 'they'?

 

I'll propose one method to secure the system that removes the possibility of access given intercepted data:

 

Define a function f(n) which returns a password.

f(1) is the first password (e.g. add.php?item=pie&price=undefined&password=happy if the password is happy).

f(2) is the second password, which is invalid until after the first password is used.

f(n) is the nth password, which is only valid once, after f(n-1) is used.

 

What you could then do would be to define f(n) recursively.

For example:

f(0) = "9012" (this password is unused, but necessary for the recurrence relation to work)

f(n+1) = g(f(n))

g(n) = sha1(n + "some salt, thanks to whoever brought up this concept to me on some other thread"). (this is an example, feel free to create your own g(n), just as long as it involves a hash of some sort)

 

This generates f(2) = "c3cd2a145b57c55305af29947c0630dd6b738e89", f(3) = "661dbb374be947d4f8e9facf3113b4cc892d531c", etc. (I think..)

 

How this could work is to have stored somewhere in your database the last key used. In the previous example, you would have the key as "9012" before you've added any items, and "c3cd2a145b57c55305af29947c0630dd6b738e89" after adding one item.

When you go to add an item via your program, it will prompt you for the salt. It has the previous key stored, and calculates f(n+1) from the previous key and salt.

The program would then go to the page add.php?item=pie&price=undefined&password=f(n+1). (note that f(n+1) should be actually calculated and the value sent in, instead of the string "f(n+1)".)

The file add.php then parses this data and calculates f(n+1) using the previous key stored in the database and the salt, checking it against the submitted data. If matched: it will return success, add the item, and replace the old key with the new one (e.g. replace "9012" with "c3cd2a145b57c55305af29947c0630dd6b738e89"; otherwise return failure (and potentially store information about the failed attempt).

 

The security in this model is due to the fact that one cannot find the relation between the keys. Given 1000 intercepted passwords, a hacker would most likely be unable to determine a method of entry. This means that one cannot find the next key to be used and thus cannot add arbitrary items to the system.

 

NB: This won't work if the program you're using isn't being made by yourself.

 

[hr=noshade]

Alternate methods are probably possible, this one I just made up. For example you could use a similar method but instead of f(n+1), calculate f(t) (possible problem: lag, a hacker reusing a key quickly (fix: limit additions by time, or remove the possibility of repeated keys))

These security devices have irreversible functions as the primary security method.

[/hr]

[Juxt 0]

I was thinking about something like that. That idea sounds very interesting and I think it'll work. Thanks.