Logical1 Posted May 28, 2009 Share Posted May 28, 2009 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. Quote Link to comment Share on other sites More sharing options...
KevinM1 Posted May 28, 2009 Share Posted May 28, 2009 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). Quote Link to comment Share on other sites More sharing options...
roopurt18 Posted May 28, 2009 Share Posted May 28, 2009 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) Quote Link to comment Share on other sites More sharing options...
Daniel0 Posted May 28, 2009 Share Posted May 28, 2009 Maybe see this as well: http://www.phpfreaks.com/tutorial/php-security Quote Link to comment Share on other sites More sharing options...
Logical1 Posted May 29, 2009 Author Share Posted May 29, 2009 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 Quote Link to comment Share on other sites More sharing options...
DarkSuperHero Posted May 29, 2009 Share Posted May 29, 2009 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! :-) Quote Link to comment Share on other sites More sharing options...
Logical1 Posted May 29, 2009 Author Share Posted May 29, 2009 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). Quote Link to comment Share on other sites More sharing options...
KevinM1 Posted May 29, 2009 Share Posted May 29, 2009 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 Quote Link to comment Share on other sites More sharing options...
Logical1 Posted May 30, 2009 Author Share Posted May 30, 2009 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 Quote Link to comment Share on other sites More sharing options...
Daniel0 Posted May 30, 2009 Share Posted May 30, 2009 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. Quote Link to comment Share on other sites More sharing options...
Logical1 Posted May 30, 2009 Author Share Posted May 30, 2009 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? Quote Link to comment Share on other sites More sharing options...
jxrd Posted May 30, 2009 Share Posted May 30, 2009 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. Quote Link to comment Share on other sites More sharing options...
corbin Posted May 31, 2009 Share Posted May 31, 2009 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; Quote Link to comment Share on other sites More sharing options...
roopurt18 Posted May 31, 2009 Share Posted May 31, 2009 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.) Quote Link to comment Share on other sites More sharing options...
Daniel0 Posted May 31, 2009 Share Posted May 31, 2009 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.