Jump to content
xisto Community
Feelay

Safety Anyone who knows a tutorial

Recommended Posts

Hey!Anyone who know a tutorial where they teach you how to protect your scripts from danger (hacks and stuff)? I think I need to start to think about theese stuff now.

Share this post


Link to post
Share on other sites

A lot of it can depend on what you do (sql, sockets, user data) and what php version you use (php5 has oop, mysqli).Mostly, its mysqli and *escape*, php.net is good for both of these.

Share this post


Link to post
Share on other sites

I think that Safety is a very large topic and there exists a lot of sites that offers related information about it, and some are very good ones, so, i hope that the following links helps you:

PHP: Security - Manual: Complete chapter at the Official PHP online manual of security issues.

PHP Security Consortium: Secure programming practices promoted by a group of international PHP experts.

PHP Security Consortium - Library: Links to a lot of resources approved by the PHP Security Consortium.

NYPHP - PHundamentals: Some best practices compiled by the New York PHP website.

Sql Injection Prevention (passing Numerical Data Across Pages): This topic contains some useful links not only related to Database security.

Best regards,

Share this post


Link to post
Share on other sites

Thanks. Long time I opened this thread. But now I know for sure exactly the things I need, I think :mellow:

I need very basic information on how I can protect sessions. I need to know what is safest to use? sessions, or cookies, or is it possible to use both (maybe "melt them"?), and if yes, then how?
I need to know about the most common session/database hacks, and how I can defend myself, and the users viewing my pages, against them.
I think that defending my sessions/cookies/database are the most important things, but if there is more I should think about, I would like to know.

I have been searching for some days now.. I've found some things, but I do need a tutorial, or something like it, that explains it a little more basic. OFC I need the best protection, but if possible, like I said, explained in a way, that even a 10 year old could understand.

I also want to know about this:

some people use this:

$this->query (or $db->query)
instead of this:
mysql_query


whats the difference? how do I use "$this->" and is it safer than mysql_query?

I also want to know about this:

some people use this:
mysql_query("SELECT username FROM table WHERE username = ?")

instead of this:

mysql_query("SELECT username FROM table WHERE username = $username")

lets say I want to check the username that was submitted by a user in a login script.
Why do they use "?" instead of the variable name? is it safer? if yes, how do I use it? when do I use it?

I've also been reading some things about storing sessions without cookies. What's the difference? I've always been doing it this way:

$_SESSION['user']=$_POST['username'];
is that storing it with, or without cookies? if with, is it safer to store it without, and if yes, how to I store it without cookies?
more questions may come.

Thank you //Feelay
Edited by Feelay (see edit history)

Share this post


Link to post
Share on other sites

Hey Freelay, it's a good thing you're considering securing your applications.

$db->query()

This method is part of a class, what the class is, I am uncertain about. Some classes worth mentioning though is MySQLi and also PEAR's DB module. Both have put in an effort to prevent SQL attacks and it is quite strong in this respect, they are definitely worth considering, especially using PEAR:: DB with MySQLi.

If you use the class above, then the rest of the things you mention would not apply as they have different methods for doing the same thing. I'm not familiar with the WHERE = ? query, and would probably need more information on that as I've never used it myself.

Sessions by default create cookies, and the information you store inside the cookies should not be privileged information, like their password, there should be no reason to store their password inside a cookie so I don't even recommend one way hashing it (md5, sha1... etc), so find an alternative way for this type of information.

Using without a cookie just means it won't be left on the computer that the user was using (good if it's not their computer they are using) and you would maintain the session yourself by sending the session id via POST (can use GET but not safe as it could be stored in the URL and history) and keeping your own time expiration of it. It also helps against session hijacking.

There's a lot more to security than this though, keeping your application secure is a starter, but ensuring your server is secure and other applications you make use of is another thing.

Cheers,

MC

Share this post


Link to post
Share on other sites

They are user made OOP's. I'm still not convinced OOP is better than procedural. In this case, it would be a mysql class which logs in, auto gives some data and some from input, and safely puts data in, etc.That session = post is quite risky. It's often said to assume the worst of your users, so when one does come along it does no harm. At the very least, escape/add slashes/remove special characters. People often add salts to sessions, as I don't think the user ever sees it and it's the most secure way of knowing you're working with the same browser session.

Share this post


Link to post
Share on other sites

About the session:

 

I found this code on a page:

 

<?php #################### # The following code is part of a file included in every viewable page. #################### // Start session off session_start(); // Encrypt a finger print: $setword = "SomethingAboutThisSite"; // Include: IP,	Browser, Username, //					Setword - Make sure this finger print is unique to this site. //					User Active - incase a user is deactivated during their session by a higher user. $setfinger = md5($_SERVER['HTTP_USER_AGENT'].$_SERVER['REMOTE_ADDR'].$setword.$_SESSION['user'].$_SESSION['user_active']); #################### # The following takes place after sucessfull completion of username and password # in a login script. #################### $_SESSION['user_finger'] = md5($_SERVER['HTTP_USER_AGENT'].$_SERVER['REMOTE_ADDR'].$setword.$username.$user_active); // Username, as entered. User_active is taken from the DB. #################### # Each page has multiple purposes, guests, users and higher users, this is how its checked: #################### // Check if the user is authenticated: if (($_SESSION['user_finger'] == $setfinger) & ((time() - $_SESSION['login_time']) < 3600 )) { 	if ($_SESSION['user_level'] == "higher") 	{ 		// Whatever a higher powered user can do on this page. 	} 	else 	{ 		// Whater a normal user can do on this page. 	} else { 	// What ever a guest can do on this page. } #################### # Each page has a footer which tidies up some script and formatting of the page #################### // Included is some code to extend the log in time, so as long as they are // active they stay logged in. // There is also some code which adds details to a database to show when the user // was last active and what page they were viewing. // This is so higher users can see who is currently logged in and what they are // doing. // Any entry past the sessions expiry time is removed from the database. // A log is also made against the users details of their last activity time, which // remains till their next login. ?>

Is that a safe way to store a session?

 

 

About the database:

 

I still need to know more about that =/

Share this post


Link to post
Share on other sites

Not sure how secure my site is with my methods, but every way I could think to hack it wont work (you would be surprised how often websites make simple mistakes to make them completely vulnerable). Recently I used a few large sites which were probably the most insecure sites I have ever used. It used java script to check fields (a common mistake). Sessions? Why? - I secure my site by first running a random string that when a use logs in. The string contains A-Za-z0-9 and +-_ est. and is set to a minimum of 15 characters long. Now this is far more secure then you need for sessions as it take over 400 hours to hack a password with the above characters and that are 8 letters long. I store that data on the server and in a cookie. I also use an IP check. When the use visits the site, my site finds the cookie and IP then checks if it is logged in. Possible threats may be if you use a proxy and someone finds your session ID and logs in as you, this is a major threat but there isn't much we could loose on the server.MD5 - You should protect all your server passwords with md5 and simply compare md5's when logging in.Preg-Replace - Check EVERYTHING that comes into your server. Even the slightest error can cause massive injections and really mess up your server. An injection occurs when a hacker (usually the newbies that don't realize most programmers know this glitch) attempt to login using MySQL such as " OR ""="" this would run in MySQL as Where password="" OR ""="". It is possible to exploit it to delete date and even tables. This is what happened with PHPBB (another reason not to use it).Max errors / Attempts: Set up your server to check the number of errors / login attempts and put it in MySQL using the IP. Now IPs can be changed but it takes a lot more time (in comparison) to change an IP then to delete a cookie. This will stop bruit force or people just guessing.Avoid IP banning: Doesn’t work, don’t use it. If they are actually a hacker then could simple change there IP anyway…This should give you the basics to making your secure website.Thanks,Sparkx

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | 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.