Jump to content

How to prevent the from being hacked!


Logical1

Recommended Posts

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.

 

 

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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)

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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).

 

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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;


Link to comment
Share on other sites

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.)

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.