Jump to content

Recommended Posts

Hi there, I have just recently started coding in PHP for a club of mine, and I've got some questions to ask. Please bear with me as I do have little experience in both PHP and CSS, therefore would not understand many of the more complex terms.

 

So basically, this website it just to show the latest news and events that are happening at the club. The club council members and website admins (eg me) are able to log in, add, edit or delete news and events from the website. All data is stored in SQL.

 

What I did was basically have all my code in one PHP file, eg index.php. What happens when the site loads is it shows the home page. But whenever I want to switch pages (eg to go to the events page) all I do is create a link back to the page with a variable in it, showing which page it goes to. (eg from www.test.com?page=home to www.test.com?page=events). The code in the page scans for the variable, and outputs the correct code depending on which page it is supposed to be. ( I use if statements)

 

Now, is this a good coding standard? I am basically shoving all code into one single PHP file, and I would assume that would lead to security concerns. I am unsure if I should proceed with the current way I am doing it or redoing it all over again.

 

Another problem I have was the security of the site. I do not want it to be easily hacked, so what I did was have 2 different databases, one for the data for the site and another for the user list. (I will be attempting to hash it with MD5 soon, just to make it secure). When the user attempts to log on, the server would check it to the user list, and if it is correct, allow access to the other database with all news and event data on it. What I did was that if it was a correct password, it would set a session variable to true (eg isPasswordCorrect = 1) and use that as another way of determining what page would show up (eg if the user was logged in, everything would be shown but if the user is not, access to the DB would be denied and the Login page would show).

 

So how would I protect my user list? In order to access it, there should be a single account in SQL made to access it, and if that is compromised, would allow the hacker access to all my usernames and password. Would MD5 hashing stop that? How can I make the site more secure?

 

Thanks for reading. I appreciate your help and advice.

-Make sure you sanitize any user input that runs through the mysql queries (ie username, password, etc) with something like mysql_real_escape_string()

-Use an external file to connect to the database and keep it above the webroot.

-Make sure to check the users permissions for each page displayed (probably just store their permission level in a session) so they cant modify the url and get wherever they want.

 

Just a couple things to keep in mind.  I might be wrong, but switch statements might be more efficient over if statements for how you decide which page is displayed. 

Say the root for www.silverblade.com is /htdocs/web/silverblade then you would want to keep your script to connect to the database above /silverblade.  So you would just do include("../db_connect.php"); if you have it in /htdocs/web.  Hope that makes more sense.

Having all of your code in one page is no more of a security concern than having separate pages. For that type of format, I prefer to use Switch/Case statements and each page in a separate function. It makes maintaining the separate pages a bit easier than IF branches. We separate off into separate scripts per page for ease of coding, but it really doesn't affect security. In fact, for newbies, passing variables between separate pages can many times cause a lot of problems and introduce security issues.

 

On that topic, security is a VAST discussion. It requires a lot of experience and even a little luck thrown in for good measure. Form elements are the things that need to be focused on, and each different type of form element requires its own measure of security. This is where experience comes into play. Many newbies to PHP go overkill on trying to secure the smallest thing, and then almost completely ignore the bigger things. You can only learn by taking each one and discussing it with other programmers, and doing a whole bunch of trial and error. 'Unexpected Input' is the buzzword here. It's easy to get a script to react correctly to expected input, and even erroneous input (spelling errors, format errors, etc.). The other side of the coin is special characters, injection code, or flat out malicious attempts to break your script by introducing unexpected input. It's what you didn't expect someone to try that will usually break a query or generate a fatal PHP error.

 

Hope some of that helps... = )

 

PhREEEk

Chris, yes, that makes perfect sense. However, as I am going to be hosting the site on a different server, it would be quite impossible for me to put the connect script above the webroot right?

 

And Phreek, thanks for that, I will convert the if statements to switch cases. And thanks for that, I will just do as much as I can and once it is finished, I'll post a link on the forums here for people to test.

 

Thank you all for your help so far.

What you do is say your host gives you webspace.  Then say you have www.silverblade.com.  you would put the site in /mywebsites/silverblade and point your domain to that folder.  So the webroot of the site is /mywebsites/silverblade Then your database connection script will be in just /mywebsites.

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

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.