Security Tips

[norNerd]

Hello people, I have a few questions i want to ask you guys.1. When I dont host my site at my own server, is my hoster "responsible" for makeing it hard to etc hack into my FTP, MySQL server?2. What can i do to improve my mysql_connect script if it is like the w3schools connection script?3. Is there any other "totally open" ways into my SQL db then with Injections?4. Is it "wrong" of me to use basic mysql_fetch_object or mysql_num_rows? Should i do something else to improve security? or is there no ways?5. I understand that spam-bots and password-bots are a big problem today, so is captcha the only way to prevent this, or have some of you genius'es come up with something else? :)6. Guess i dont have asked enough questions now, so if there is something more you want to tip me about, please do it? :)Be open and share your goodies with us :)Hope this post will be usefull for others too when answers are posted ;)Have a nice day fellow nerds :)norNerd

[PHPiSean]

1. When I dont host my site at my own server, is my hoster "responsible" for makeing it hard to etc hack into my FTP, MySQL server?

Sometimes it's you; not keeping your SQL and FTP information secure. Make sure you have hard to find usernames and passwords unlike 1234.

[norNerd]

Sometimes it's you; not keeping your SQL and FTP information secure. Make sure you have hard to find usernames and passwords unlike 1234.

Understand :)Allways use characters, special characters and numbers in my passwords and ftp/sql usernames

[justsomeguy]

1. When I dont host my site at my own server, is my hoster "responsible" for makeing it hard to etc hack into my FTP, MySQL server?

Depends on the account you have with them. At a minimum, unless you have an unmanaged server, they're responsible for keeping the software on the server up to date and locked down, but that doesn't have anything to do with the applications you write or install yourself. In other words, they will make sure that someone can't attack Apache, but they aren't going to audit your PHP code to look for SQL injections.

2. What can i do to improve my mysql_connect script if it is like the w3schools connection script?

That's a little vague.

3. Is there any other "totally open" ways into my SQL db then with Injections?

Depends how they have the database server set up. If they allow remote connections that's a security issue, or if there's any way for someone to get their own PHP scripts uploaded to the server and executed then they can pretty much do whatever they want (including possibly making their own SQL user).

4. Is it "wrong" of me to use basic mysql_fetch_object or mysql_num_rows? Should i do something else to improve security? or is there no ways?

Security isn't really an issue with reading data from the database, security implications come into play more with mysql_query than they do with mysql_fetch_*.

5. I understand that spam-bots and password-bots are a big problem today, so is captcha the only way to prevent this, or have some of you genius'es come up with something else?

I prefer to use randomized form field names with hidden "honeypot" fields with the regular names. That doesn't require the user to do anything extra, and it weeds out the vast majority of bots. I've got an example of that posted here somewhere.

[norNerd]

Depends on the account you have with them. At a minimum, unless you have an unmanaged server, they're responsible for keeping the software on the server up to date and locked down, but that doesn't have anything to do with the applications you write or install yourself. In other words, they will make sure that someone can't attack Apache, but they aren't going to audit your PHP code to look for SQL injections.That's a little vague.Depends how they have the database server set up. If they allow remote connections that's a security issue, or if there's any way for someone to get their own PHP scripts uploaded to the server and executed then they can pretty much do whatever they want (including possibly making their own SQL user).Security isn't really an issue with reading data from the database, security implications come into play more with mysql_query than they do with mysql_fetch_*.I prefer to use randomized form field names with hidden "honeypot" fields with the regular names. That doesn't require the user to do anything extra, and it weeds out the vast majority of bots. I've got an example of that posted here somewhere.

Perfect :)Thanks for great answers :)Kris

[norNerd]

Perfect :)Thanks for great answers :)Kris