How to prevent the from being hacked!

[Logical1]

I noticed that when we send a variable ($V1=100) from a form (form1.php) to a second page (results.php) it can easily be hacked by typing in:

http://www.-------.com/results.php?V1=400

into the URL box and just bypas going through the form!

 

This becomes a security problem when Session variables ($SVId=2) are supposed to be read and fed into the form:

http://www.-------.com/results.php?V1=400&SVId=5

 

Anybody can fake this and break into the system.

What is the solution against this?  How do you secure your forms?

Thanks in advance.

 

 

[KevinM1]

I noticed that when we send a variable ($V1=100) from a form (form1.php) to a second page (results.php) it can easily be hacked by typing in:

http://www.-------.com/results.php?V1=400

into the URL box and just bypas going through the form!

 

This becomes a security problem when Session variables ($SVId=2) are supposed to be read and fed into the form:

http://www.-------.com/results.php?V1=400&SVId=5

 

Anybody can fake this and break into the system.

What is the solution against this?  How do you secure your forms?

Thanks in advance.

 

Well, my first suggestion would be to stop sending critical information to your system via GET, where anyone could get an idea of what your system is doing merely by looking at the address bar.

 

What are you currently doing to scrub incoming data?  It's hard to get an idea of what you should do without knowing what you're already doing (if you're even doing anything at all).

[roopurt18]

Also keep in mind anything sent via get will likely show up in the web server's access logs, which also tend to get archived and shuffled around on disk.

 

The usual rules apply. 

+ Don't trust any input from the user (i.e. sanitize it all)

+ I'd go as far as to say not to trust data from your own database

+ Use proper encoding when sending output to a browser

+ Don't use global variables

+ Don't allow files uploaded by users to be executed

+ The only PHP file you need to be web accessible is an index.php, everything else could be safely saved outside of your public_html or www directories (JS, CSS, images, and .htaccess excluded)

+ Don't rely on stupid security measures

+ Use encryption / hashing as appropriate

+ Use SSL for really important data

+ Don't save sensitive information in permanent storage (remember this can happen accidentally in the case of archived apache access logs and GET variable)

 

[Daniel0]

Maybe see this as well: http://www.phpfreaks.com/tutorial/php-security

[Logical1]

Thanks for the replies.

This is what I am doing. 

1. At the login stage I save a session variable which contains the username and another one which indicates that the user has logged in.

2. In all pages I read the session variable for name of the user to link his actions (filling forms, etc.) to his records.

3.  All data between pages are passed in forms anot not by link.

 

None the less my little experiment showed me that any first garde can pass variables through URL line and bypass data entered through forms!

Also a clever person (even a dimwit one) can fake a cookies by saving one himself in the cookies folder and laugh at such a security measure!

How would you go about it?

On the other hand if you do not rely on a sesion variable rgistered by a cookie how can you tell that the person has logged in?I apreciate your sugestions whille I am reading the 84 pages in that security thread

L1

[DarkSuperHero]

How about registering it using PHP Sessions....just like cookie's but store on the server (correct me if im wrong)....

 

http://www.tizag.com/phpT/phpsessions.php

 

Are you having users log in during every visit, or want the site to remember them `across` different visits ?

 

Cheers! :-)

[Logical1]

Members are supposed to log in to get to pages where the forms are.  FIll some forms and get some data and log off before leaving (end session).

My objective is :

1.  To make sure unauthorized people can not get into the forms and fill or edit existing data

2. Their actions will be traced to their own account, so no one should be able to edit some data faking the username of another person.

That's why I am using session registration and session variables.  But I always imagined session variables like cookies being writen on the user's computer (and not the server).

 

 

[KevinM1]

Thanks for the replies.

This is what I am doing. 

1. At the login stage I save a session variable which contains the username and another one which indicates that the user has logged in.

2. In all pages I read the session variable for name of the user to link his actions (filling forms, etc.) to his records.

3.  All data between pages are passed in forms anot not by link.

 

None the less my little experiment showed me that any first garde can pass variables through URL line and bypass data entered through forms!

Also a clever person (even a dimwit one) can fake a cookies by saving one himself in the cookies folder and laugh at such a security measure!

How would you go about it?

On the other hand if you do not rely on a sesion variable rgistered by a cookie how can you tell that the person has logged in?I apreciate your sugestions whille I am reading the 84 pages in that security thread

L1

 

Are you using the $_REQUEST super global array to obtain the data that's passed in by the form?  It sounds like you are.  Either that, or your form method is set as get.  In any case, you should use post as your form method and the corresponding $_POST array.

 

As far as sessions go, they use cookies out of the box, but they're safer than normal cookies.  There's a discussion about cookies, sessions, and login systems you may be interested in reading.  I think it may steer you in the right direction: http://www.phpfreaks.com/forums/index.php/topic,254261.0.html

[Logical1]

Thank you for your suggestions.  You suggested also to put only the index file in the root directory and everything else in non-web accessible folders.  What is the advantage in that?  Is there a way to link to them from the index page while stopping direct viewing?

Thanks in advance

 

[Daniel0]

The advantage is that people can only access the files they're supposed to access. Of course if you haven't designed your application so all requests are routed through a single file, this is not easily possible.

[Logical1]

I am not sure how it is suposed to work.

If file 2.php is placed in this folder then it will not be viewable directly (www.---.com/2.php) but if we have a link from index.php which is in the root directory it can open the page 2.php on the browser.  Is that how it works? 

I called the host company and asked how to set up such a folder and they aid it is impossible. 

How would you do it?

[jxrd]

Create a folder outside public_html or htdocs or whatever it's called on your server, and then use include(), file_get_contents(), fopen() or one of the other billions of functions that can open files by a direct method (as in, not over the HTTP protocol) in your accessible file to read the files.

 

That way they're not directly accessible over HTTP protocol, so people can't access them without you allowing them.

[corbin]

If you can't put your files out of your web root (they should be out of your web root if at all possible just in case Apache decides to stop parsing PHP some day), you could always go with a define check.

 

 

index.php:

<?php

define('THROUGH', true);

//... some code here...

include 'includes/' . $page . '.php';

 

 

Then some other file:

 

 

<?php

if(!defined('THROUGH')) exit;

[roopurt18]

Or you could put them inside of:

~/public_html/private

 

And inside private add an .htaccess file:

Order allow,deny
Deny from all

 

If Apache decides to stop parshing PHP corbin, then your solution won't protect against it.  (At least I don't think it will, I'm tired and it's been a long frustrating day.)

[Daniel0]

The problem is just that you can't do none of this at all if you've designed your application so multiple files are accessed directly by the UA. register.php, login.php, index.php, etc.