Page 1 of 1

today i discover the security...

Posted: Mon Jan 18, 2010 12:38 pm
by balo
hi to everybody! this is my first post here, and i am really a newbie in php security.
today i try to change the value of some hidden field in my web page with firebug and i try to send the form.
In this silly way i discovered that with firebug, and even if i save the page and change the url of the form, i can send anything i want to my php script!
you can image my shock to discover it!
so, i understand that even the select, that until today i use to be sure of the user input, is not safe. and so on, all the new that i read today.
i had bought as fast as i can my first php security book, architect's Guide to PHP Security by phparch.com, and order another one, ESSENTIAL PHP SECURITY.
but until i read all of them, i have some doubt and i'm asking for help.

first of all, how can i be sure that the $_POST data that i receive came from my page? i read about the editing of the header, so i can't be sure that is not a page save and edit offline.
then, where can i store my important, and secret, data? until today i used the session, but i read about session hacking! so, what can i do?
again, what can i do to use javascript with ajax and be sure that is not change inline?
at last, but not least, how about crypt and ssl?

obviously i don't ask the answer to all this question, i think should be a really big answer, but if somebody can give me some link or reference where i can study and discover the solution, i will be really glad!

thanks a lot for all the help

Giovanni

Re: today i discover the security...

Posted: Mon Jan 18, 2010 1:34 pm
by Apollo
balo wrote:first of all, how can i be sure that the $_POST data that i receive came from my page?
You can't.
then, where can i store my important, and secret, data? until today i used the session, but i read about session hacking! so, what can i do?
The data in sessions is stored on the server only, and can not be read or changed by others. But the session ID is stored as a cookie, and that can can be read or changed by evil hackers.
So, if you are logged in and you set 'elite_admin_rights=true' in your session, and someone manages to read your cookie he can set the same cookie in his own browser, and he's got your elite admin rights.
again, what can i do to use javascript with ajax and be sure that is not change inline?
Ajax is javascript, and javascript is executed client-side, so you have no control over that.
at last, but not least, how about crypt and ssl?
What about it? :)
If you mean SSL encryption (using https://etc), this is to prevent that anyone can intercept or modify your communication. But it doesn't help if your visitor himself has bad intentions.

Re: today i discover the security...

Posted: Tue Jan 19, 2010 2:44 am
by balo
thanks for the answer!
so...
Apollo wrote:
balo wrote:first of all, how can i be sure that the $_POST data that i receive came from my page?
You can't.
i can't set even a poor security on this? i don't know, check if the domain is the same of the corrent page? i understand that a real evil man ( :twisted: ) can change the header but, i hope, it's not so easy on well-know!
Apollo wrote:
balo wrote:again, what can i do to use javascript with ajax and be sure that is not change inline?
Ajax is javascript, and javascript is executed client-side, so you have no control over that.
so, you suggest me to don't use js? i create a nice user interface where i save some data give by js in some hidden field. but with the know that hidden field can be change and that js can be hack, how i have to do that?
in other world, what do you suggest me to do for recording the user input? eg, i have to choose a gallery where to upload photo. i make this by some select that is populate by ajax when the user choose the precedent. so i choose, for example, people and in the second select appear man, woman, child... and when i choose on of this appear another select with "new album" or "add to existent album". if i have to register all this step in session to be a bit more sure, i shoul make a page for each step, and so lose a pretty interaction with the user!
any idea to solve this?

Re: today i discover the security...

Posted: Tue Jan 19, 2010 6:07 am
by Eran
first of all, how can i be sure that the $_POST data that i receive came from my page?
Use session tokens. See example - http://shiflett.org/articles/cross-site ... -forgeries
It's not bulletproof, but it's very effective
so, you suggest me to don't use js? i create a nice user interface where i save some data give by js in some hidden field. but with the know that hidden field can be change and that js can be hack, how i have to do that?
Continue to use Javascript, just don't trust any user input, regardless if it's from visible inputs or hidden ones.

Re: today i discover the security...

Posted: Wed Jan 20, 2010 1:37 am
by kaisellgren
pytrin wrote:
first of all, how can i be sure that the $_POST data that i receive came from my page?
Use session tokens. See example - http://shiflett.org/articles/cross-site ... -forgeries
It's not bulletproof, but it's very effective
Actually that won't do anything if I understood the OP's question. He asked whether it is possible to send POST data from anywhere else than his website which is possible as I don't even need a web browser to do that.
balo wrote:i create a nice user interface where i save some data give by js in some hidden field. but with the know that hidden field can be change and that js can be hack, how i have to do that?
If you are worried about someone altering the data on the hidden input, then why do you even use hidden inputs? Why don't you just store the value on the server (e.g. in a session)?

You can use JavaScript and AJAX as much as your soul can take, but you need to remember that any data your PHP application receives from the user is not to be trusted.

Re: today i discover the security...

Posted: Wed Jan 20, 2010 2:37 am
by Eran
Actually that won't do anything if I understood the OP's question. He asked whether it is possible to send POST data from anywhere else than his website which is possible as I don't even need a web browser to do that.
The OP wanted to know if there's a way to make sure data posted originated from his site. Identifying form submissions using session tokens is an effective way to achieve that.

Re: today i discover the security...

Posted: Wed Jan 20, 2010 3:19 am
by kaisellgren
pytrin wrote:
Actually that won't do anything if I understood the OP's question. He asked whether it is possible to send POST data from anywhere else than his website which is possible as I don't even need a web browser to do that.
The OP wanted to know if there's a way to make sure data posted originated from his site. Identifying form submissions using session tokens is an effective way to achieve that.
I see your point, but I think you missed mine. I think the OP just wanted to know if he can be sure that someone visits his site and posts from there. With tokens, one needs to visit the site once, and later at some point open up telnet and submit full or partial content. So, the data wouldn't be sent "from the site". In reality there are no "sending from a page", but I think he wants the user to actually see the website and interact with it. If this is what he wants, there's nothing he can do (just like with the case of altering hidden inputs and JavaScript).

Basically with tokens, one needs to request the page at least once and then within a certain period (until the GC erases the data) send the POST data (or just some parts of it) the way he wants.

A typical noobie mistake is to build up a page with three important form fields, and then ask "can I make sure my form on this page is used to send the data?". People often ask this because they want to make sure that all three required fields are submitted, but they fail to understand how the web works.

But you are right that tokens are very effective way to make sure the sender has to visit the initial page before he can submit anything legally. This also stops CSRF/XSRF attacks and mitigates (D)DOS attacks as you know.

Re: today i discover the security...

Posted: Wed Jan 20, 2010 3:31 am
by vanguard
Also, something that I dont think anyone mentioned is that you can add relatively effective protection against session hijacking by checking against the user's IP. Heres an example:

Code: Select all

 
<?php
session_start();
if(!isset($_SESSION['IP_IDENTIFIER'])) {
    $_SESSION['IP_IDENTIFIER']=$_SERVER['REMOTE_ADDR'];
} else {
    if($_SESSION['IP_IDENTIFIER']!=$_SERVER['REMOTE_ADDR']) {
        die('Session Compromised!');
    }
}
?>
 
The only problem is that if the user is using DHCP and their IP address refreshes while they are using your site, it will kill their session.

Re: today i discover the security...

Posted: Wed Jan 20, 2010 3:55 am
by Eran
It will also work badly with people using laptops, who could be switching between several networks (/IPs) during the day.

Re: today i discover the security...

Posted: Wed Jan 20, 2010 4:03 am
by vanguard
this is true, but it could be used in conjunction with a request for the user to reenter their password instead of simply killing the session. That would solve the issue.

Re: today i discover the security...

Posted: Thu Jan 21, 2010 3:04 am
by balo
i think to do something like it...
when i connect, i will check if the user and pass is correct (the pass id crypt with md5, it's ok?) and then
1)read the date and the IP of the user
2)create an hash value make by
personal_key+IP+user_id+day+access_level
and then i make the md5 of this string.
3)save this value with login data in a table of the db, to have a history of the user that use the site.
4)save in the session the hash value, the user_id value and the level (i need it for the different option of the user).

when the user surf the page, i will
1)build again the hash value with the IP from $_SERVER['REMOTE_ADDR'], the data from date() and the user id and level from the session value.
2)check if the hash store in the session is the same of this new one. if is correct i give the access, otherway i present again the login page.

could by ok? or is really not safe?

Re: today i discover the security...

Posted: Thu Jan 21, 2010 7:17 am
by vanguard
that is secure, although be mindful of letting user input get into SQL queries without being secured first.
Also, the user's session will break if they are logged on between 11:59 and midnight because of the date() part. You could happily take that part out without compromising security.

Re: today i discover the security...

Posted: Thu Jan 21, 2010 9:46 am
by balo
yes, i clean all the variable that go in the db with

Code: Select all

$testo = trim($testo);
$testo = htmlentities($testo, ENT_QUOTES, "UTF-8");
thanks!!