Page 14 - [Everyone] Must read Security Notes

Yeah, POST is JUST as easy to spoof using telnet as GET is. Don't think POST is any safer than GET at all.

Good catch, however an easy way of fixing this problem would be to reverse it, especially if you have a hashed/encrypted password which you check.

So instead of

we would have


where $pass value is already changed, so it shouldn't be affected and just spit out an unsuccessful result.

That doesn't fix anything if the security issue of an unescaped $login value is still put in the query. It just changes what value you'd use for $login, because SELECT 0 AND 0 OR 1 is still going to return TRUE.

---John Holmes...

should either strip or escape the following chars from $_GET and $_POST:
<
>
'
"
\
/

re: sepodati

as i said, either strip them or escape them... different versions of php and your db server (oracle, mysql, mssql, postgresql) handle things differently. with my current php 4.1 and mysql 4.1 single quotes in queries are automatically escaped apparently. however on 2 other servers i dev with (php 4.x but 1 mysql one oracle) the single quotes are def not escaped (and oracle even bitches with errors while running the exact same code save changing the db class)

furthermore, wouldnt u have to change the < and > to the html special chars? seems to me like someone could do some nasty stuff with forms right on your page <form action=somepage.php method=get>

however for hacking forms i prefer a better technique of copying their html form and then writing my own form for it

I'm not entirely sure if this has at all been covered, but there was a post regarding username and password snooping with sending them over http and not https. Well why not encrypt the username and password before sending them through any method using javascript....

http://pajhome.org.uk/crypt/md5/

I have never actually tested this script. however the developers site mentions usage on yahoo and vbulletin... so must be worth a look.

Also another pointer i think is fairly secure is to encode your GET values into one reversable encrypted string along with a random string that acts like a digital id to ascertain the strings validity. assign that string to one value for instance

?ENC=YjE3NDQ2YWYwNWQ4aY6X7f0PLewhOndJB0f1xT+EVVV6bQ8WAFfjsQCvNatm5FVUQ8qWcxzOYKXrkrlbJy6aR6ysozSwBHO IxVSCv05flJfms7DQboHIc0d+

instead of

?WELCOME=1&CHECK_SESSION=1&2Zu9dlsd8wh9R7388267=1&GO=../galleries&TASK=browse

note the 2Zu9dlsd8wh9R7388267. This is the would be random digital id you would check for when decoding your ENC value. if it doesn't exist abort the script.

Also you can ignore all other GET properties as they are all contained and hidden in the ENC string.

From my understanding this is fairly secure way of passing important vars. Especially when using a hask key that is in an encoded php file. However please correct me and remove my post if i am wrong. I am still learning security techniques in php and am really still a beginner in these things.

oh dear oh dear oh dear.... having jsut mentioned javascript md5 it appears md5 is now defunct

http://www.schneier.com/blog/archives/2005/03/more_hash_funct.html

while i'm on it....
http://www.schneier.com/blog/archives/2005/02/sha1_broken.html

I would like to add another solution when you set the cookie, set it where username = username and pass = sha1($sitesecret.sha1('password')); then when you get the data back (this could be used even on the cookie that says admin=yes), check it by doing:
if (sha1($sitesecret.sha1($realpass)) == $_COOKIE['pass']) {
that way they cant set it without knowing the $sitesecret (which should be secret)

Hi all,
I 've found this thread very useful since I am just starting with php. I want to ask you if the following strategy is secure for restricting access to pages:

1) In the restricted access pages, first I check if a cookie is set. If it's set I try to login with the username and password (which are stored in the cookie). If login is successfull I set session variables loggedin and accesslevel, accordingly.

2) Check for the above session variables. If they are not set, transfer him to login page. If they are set allow him access to page

Does this sound secure?
Now that I am thinking about it, this solution wouldn't scale well, because for the users who have set a cookie, it would check the database for every page. So are there any suggestions?

Good article on SQL Injection here: http://www.unixwiz.net/techtips/sql-injection.html

Is the security information on this page, since Page 1 up to date? It was started in 2001, and I know PHP itself has evolved since then.

For example, the PHP Injection methods I tried to run on the first page on my own site was not successful (which is good, right?), even though I am not using any strip/addalshes() on sending variables through MySQL to get data added or returned.

So how much of talk about security from the older pages in this topic is still valid to 2005?

Good question. Also - who's going to read all 207 posts in this thread?

--Simon

I read most of it. I tell you what - 99% of it is 100% useless, because it's conversation and not a direct outlined way of handling things, like it began.

I've been working on security as the last step in my v1.0 release.

Here's a checklist - if anyone knows major things I am missing let me know:


1. Control sessioned variables

2. Control (or in my case disallow) anything in $_GET

3. Make sure all forms are submitted from the proper URL

4. Check all form values to be sure they contain only allowed choice

5. Check unique input type=text values with multiple functions - strip slashes, htmlentities etc.. to be sure they are not malicious

6. Use intval and mysql_real_escape_string to further check all values entering into mysql, which have already been checked previously for sanitization.

7. Put single quotes around values going into mysql db - big safety!

I believe that is the major things I'm doing - simply put, i control possible values, and sanitize any value to be sure it is allowed.

If anything comes up as "out of bounds" all the users information is sent to me, with a list of the rules broken and relevant variables, so I can see the problem or know of someone being sneaky


Let me know from there if I've missed major steps, or even little ones. Perhaps I forgot something on the list

THIS TOPIC IS VALUABLE AS HELL. HERE'S MY SUGGESTION

Why don't we make the first post in this - or a new thread - a simplistic outline of major and minor security advisement.

While the thread continues discussion, any valuable security suggestion should always be in the first post.

I can be edited once someone notices that it no longer refers to a valid version

I think again this thread needs lots of attention because it is so valuable!

I will type up explanations of how I dod the above 7 steps to add to it if wanted!

Here's a list of functions often used to sanitize data.

htmlspecialchars()
stripslashes()
trim()
n12br()
htmlentities()
strip_tags()
intval()
mysql_real_escape_string()