views:

111

answers:

5
+1  Q: 

Security question

in my cms i have index.php, where client must enter username and password. if they are correct, he'll moove to admin.php, where the cms is.

but now hacker can enter to cms/admin.php, so my security now is awful.


i know, that i can use $_SESSION variable.

index.php - i can give some value to $_SESSION['success']:

$_SESSION['success'] = TRUE, and in admin.php just verify it

admin.php

if($_SESSION['success'] == TRUE)
{
     my script here...
}
else header("Location: index.php");

but i want to rich this effect without SESSION. could you give me an idea, how can i do it?

thanks

+1  A: 

The code you posted is both wrong and non-sense. (should be == true, and why are you allowing him to view your script on error, rather than success?)

More to the point though, why don't you want to use sessions? You need to authenticate the user somehow, and that requires storing some sort of state so that you don't have to force the user to log in every time he changes pages.

Mark
@Mark :) 'error', just name of variable, but you're true, it looks bad by so.i don't want to use SESSION because on my hosting, it doesn't work properly. somethimes, when i header to many pages, it loose it's value, and i can't fix why. so i just want to know other possible solutions
Syom
change host. You can't build a working thing using broken tools, and expect it to be reliable and secure.
Lo'oris
+3  A: 

No, you don't want to do it without sessions. The other ways of doing it, cookies and referrer, are as secure as locking a screen door.

Ignacio Vazquez-Abrams
Errrr… sessions depend on cookies…
David Dorward
Sessions depend on *a* cookie, which is usually decently hashed. They don't depend on a cookie with the name of `isadmin` having a value of `true`.
Ignacio Vazquez-Abrams
sessions depend on more than just cookies, and I think Ignacio is referring to 'stupid' use of cookies and referrer, as opposed to a manual implementation of sessions.
Carson Myers
sessions don't *necessarily* depend on cookies. you can always pass the sessid through GET :)
Mark
+1  A: 

You have two options:

  1. authenticate on every request (use HTTP authentication, which the browser does invisibly in the background)
  2. authenticate once then store some sort of key on the users computer and maintain a reference to it on the server

The first works, but it is less secure and less user-friendly. The second is what a session does; if you try to reimplement it yourself, chances are you will end up with several security holes. Are there any actual reasons you don't want to use sessions?

Tgr
@Tgr yes, somethimes i loose the value of SESSION variable, it happens only somethimes, and i couldn't fix it
Syom
Check your code, it is probably an error on your side; maybe not calling `session_start`. Also you can try setting PHP to use file-based sessions instead of database-based ones (or vice versa).
Tgr
+4  A: 

Web application security goes really really deep. First, you need to use sessions, or an equivalent implementation of sessions.

The user logs in, and you need a session ID and their username to be stored in a cookie and in the database. In the database you also need to store some information about them, such as their user agent, so that you can tell if their session becomes hijacked. Some people store the IP address. This won't work if the user is using your application from a mobile device, as their IP address may refresh frequently.

Every time a user loads an administrative page, verify that they have a session and user cookie that are valid and have permission to use that page. Then verify the request came from the same computer that it started from using the information you stored about that user.

For every form or link you put in the administration page which can lead to an administrative action, add a hidden field or value with a unique identifier. One identifier per item on the page that could lead to administrative action. When you generate these identifiers, store them in the database along with what action they are identifying. This is called a nonce, it will be submitted with each admin request (such as updating records or deleting users or transferring funds from your bank account). When the request is serviced, the server should check that the nonce matches what was stored in the database, and then get rid of it. If it doesn't match, chances are the request was made via a cross-site request forgery attack.

These are just some of the things to keep in mind when interacting with authenticated users, and of course there is a host of other things to watch out for such as XSS.

Security is very hard, and while your web application may not warrant bullet-proof security strategies, you owe it to your users to protect their passwords and personal information. See OWASP for (much) more information.

Carson Myers
+1  A: 

To be able to implement your own security system, you need to be able to track the user across requests, in other words, be able to have user state. Sessions are the way to do this in PHP. You can either use the built in session, or implement a custom one yourself. The later of these two options is more difficult the necessary and is likely not beneficial in your situation.

A key thing to remember about sessions in PHP is that you always have to start them for every request. You should have a global include file somewhere, perhaps some sort of configuration file. I suggest you place your session_start(); near the top of that file to make sure that it executes properly for every request. Remember, the session must be started before any headers are sent, in other words, before any output is sent.

One draw back of using PHP to secure access to a portion of your site is that it only works if the request is to a PHP file. For example, if you have images, documents, or other media that you want protected, unless you are serving it through some sort of a PHP gateway/filter, those files are likely accessible without authentication.

All that said, I suggest you look into basic or digest authentication provided by Apache. For your needs, it will likely provide more than adequate security and is incredibly easy to implement -- no coding required. What's more is that most web hosts have an admin tool to manage this type of authentication and is usually called something like "password protected folder," "locked folder," etc. All you do is choose the folder and set the username and password and you're done.

Justin Johnson