Jump to content

Recommended Posts

I have read through PHPFreaks security thread, never understood some bits.

However, this is what I've done.

 

Put all $_POST and $_GET's to mysql_real_escape_string

For errors, I put error reporting on via php.ini, at the moment its set for off, as I'm not doing development at the moment.

For error reporting, I have removed all "Or die(mysqlerror());" and had it set so that it gives an error but doesn't kill the code. Same for methods like "die("message here");"

 

I'm on a shared hosting, but I have changed the session folder to my own page. (Is it safe in public_html?)

 

I have put in form validation too, and I've used Trim, and addslashes.

 

Is there anything else I could do, and please could you suscribe it too just incase I don't understand. I'd like to protect my php as much as possible.

Link to comment
https://forums.phpfreaks.com/topic/182060-any-tips-for-security/
Share on other sites

Don't put anything in public_html that doesn't have to be, such as the sessions.

 

You only need to use mysql_real_escape_string() when inserting into a MySQL database.  Using it on values not going into the database is wasteful.

 

addslashes() is probably unnecessary if you're using mysql_real_escape_string().

 

trim() doesn't have anything to do with security.

 

Other security tips:

* Don't store passwords in plain-text.

* Encode your files.

* Don't perform development and production on the same box (it sounds like you are from what you said about error_reporting).

* Create a hash-map (for lack of a better term) of your deployed application and its directories.  Compare regularly (using cron) with a known-good configuration to detect if someone is changing your files or directories (think root-kits).

I was told that Trim gets rid of HTML text?

 

I use mysql_real_escape_string for posting to a database, I just included it with everything.

 

Passwords are md5.

 

What do you mean about Encoding your files?

Also, what do you mean by Don't perform development and production on the same "box" ?

Explain a bit more about hashmap, or provide a link to it.

 

Maq, That link is what I meant, not thread.  :)

 

Thanks.

- Sanitize data. Don't even trust your own data, let alone data from third-party.

- Hash passwords + salt.

- Don't store passwords in cookies.

- Don't pass passwords or any sensitive data like credit card numbers in URL. You would at least want HTTPS for the latter if you even hope to get people to give out their CC numbers.

- Don't use or die.

I was told that Trim gets rid of HTML text?

 

Nope.  Trim just removes extra whitespace from a string (see: trim).  What you're looking for is htmlentities.

 

Also, what do you mean by Don't perform development and production on the same "box" ?

 

Don't do your development work on the same server as where your live site is.  You should have an environment for site development, and one for where the final produced site resides.

I was told that Trim gets rid of HTML text?

It does not.  Read the appropriate entry in the PHP manual to see what trim() does.

 

There are third party programs that will encode your PHP scripts.  Essentially your PHP scripts become random garbage that can only be run with the appropriate decoder.  Let's say I create a nice PHP product and I want to sell it.  I don't want my customers to easily reverse engineer my code so I will provide them with encoded files.  This way my property is protected and they can use the program.  It also helps with support requests because it is unlikely that your customers have tampered with your encoded files since they will be just garbage in their text editor.

 

Also, what do you mean by Don't perform development and production on the same "box" ?

By "box" I mean server.  You should develop your code locally on a PC or server designed for development.  When you're ready to release your code, you should upload it to your production server.  Once it's on the production server, you stop tampering with it.

 

There is no such term as hash-map that I'm aware of; I made it up strictly for that post.  Anyways, what I meant was you should take means to detect when your production code has been altered or tampered with.  You could, using a PHP program, create an md5 hash of every file in your application and a map of the files and directories.  You create this data set before deploying your application; this is your known-good configuration.  On the production server you should set up a cron script that checks the current production hashes against the known-good configuration.  If something doesn't match up, then someone has tampered with your files.

I do my work on dreamweaver, and if I cannot find an error, and I dont get a display, I use notepad++ and check for syntax

 

What would I use to test it live, if I use it as it is now, I dont have a php server for it, because it doesn't recognise PHP.

I tried this.

 

Can you provide a link to a cron script? I tried looking but I'm not sure what I'm looking for

I think you're having trouble understanding the distinct between development and production.

 

development is the box you develop your code on.  It might your local PC, i.e. the one literally sitting next to you.  It might be a remote PC in your office, i.e. it's down the hall.  This box will have a web server, PHP, and likely a database server installed on it (depending on your application's needs).  The PHP environment will likely have error_reporting turned on at the most paranoid level.

 

You perform all of your coding and testing on this server.

 

production is the computer provided to you by your web host.  The only thing you do on this box is upload your code to it.  You don't edit code on this box.  You don't test code on this box.  You don't add new features on this box.  You touch this box as little as possible.

 

It sounds to me like your dreamweaver is configured to edit files in a remote location, i.e. on your production box.  If this is the case, then you are busy editing files while people are also trying to use them (by browsing the site).  This creates an extremely unstable environment.

 

cron is a linux utility for running programs on a schedule.  I don't know of any pre-built cron script that does what I described; you'd have to write your own.

I know the difference between Production and Development.

 

EG: If I made a notepad file = file.html

Double click the file in my docs, it opens up with my files in the browser, this is what I mean.

Dreamweaver is not connected to FTP, I use a seperate client for that. I often do the piece of code I need to do, upload it and check for errors that way.

 

However, if I saved a file = file.php, double click it, it opens up but just prints the PHP as text. It doesn't recognise it. Which Is what I need the help with to get it to recognise PHP.

Dreamweaver is not connected to FTP, I use a seperate client for that. I often do the piece of code I need to do, upload it and check for errors that way.

So what you're saying is you're using your production server to find errors, which essentially means you're using your production server as your development server.

 

If you want to develop and test locally, then you need to install apache, php, and mysql locally.

 

There are a great many tutorials on doing this so I won't provide any instructions.  XAMPP is a pre-built installation you can use.

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.