Is there a list of safe ways to use PHP?

[frik]

Hello,

 

I've noticed that there are services that I can pay to have my code

checked for possibly unsafe / insecure code.

But I'd rather audit the code myself, as my code is not meant to make money.

Is there a list of safe ways to use PHP?

 

Also is there any automatic way to do this that is free?

For instance is there a code checker?

 

I've noticed there are a number of ways to do PHP wrongly

that can be easy to overlook. Is there a list of common PHP pitfalls?

 

Thanks.

[requinix]

List of safe things to do? If there was it would be way too long.

Something automatic? Not that can't be fooled.

Common pitfalls? Sure. But it'd help to know the nature of the code so we wouldn't have to rattle off everything we can think of.

 

Sounds like you're talking about someone checking for bugs or security vulnerabilities, and while there's some amount of automation that can catch easy ones, the best method is to get trained eyes on it. But that generally means paying for it. However if there's not much code then you can post it somewhere, like here, and get a lot of people looking at it for free.

Edited February 3, 2015 by requinix

[scootstah]

There are some tools, but they're not 100%.

 

Here's a couple good resources off the top of my head:

https://www.owasp.org/index.php/PHP_Security_Cheat_Sheet

http://www.phptherightway.com/

[frik]

|  But it'd help to know the nature of the code so we wouldn't have to rattle off everything we can think of.

 

Common things I'm doing are:

• Parsing GET and POST variables to make sure no simple exploits are attempted.
• Doing SQL accesses that sometimes incorporate these variables.
• Removing HTML tags from user text-- without using regex.
• Storing text in my database in base64 format to prevent users from doing SQL injection.

It's the 2nd item that I feel is the riskiest. I've heard I should not be constructing SQL commands

but using stored procedues.

 

 

 

 

[NotionCommotion]

 

|  But it'd help to know the nature of the code so we wouldn't have to rattle off everything we can think of.

 

Common things I'm doing are:

• Parsing GET and POST variables to make sure no simple exploits are attempted.
• Doing SQL accesses that sometimes incorporate these variables.
• Removing HTML tags from user text-- without using regex.
• Storing text in my database in base64 format to prevent users from doing SQL injection.

It's the 2nd item that I feel is the riskiest. I've heard I should not be constructing SQL commands

but using stored procedues.

 

Mostly, you should be concerned about user inputs.  And while there are many more, some of the most notorious are:

1. SQL injection.  You could use stored procedures, but if you are a one man shop, don't bother but be religious with PDO prepared statements.
2. Similarly, when passing arguments to shell commands, use the appropriate escaping functions.  A template engine such as Twig could make things easier.
3. When presenting content to your users, make sure everything is properly escaped to prevent XSS.  Typically, I don't remove/escape this from being in the DB, but only when presenting.
4. Validate your incoming data always serverside, and sometimes also client side if you want to improve the UX.

Again, there are more and it could sometimes be rather daunting.  While many will disagree with me, I think a risk assessment approach should be used to determine how far you should go (but always do the three I listed and surely several others as well).

[scootstah]

I've heard I should not be constructing SQL commands

but using stored procedues.

That's silly. As long as you escape input or use prepared statements, you can't have SQL injection.

 

 

• Removing HTML tags from user text-- without using regex.

 

This isn't really necessary, and still doesn't completely protect you from XSS in all cases. You should be escaping HTML on output, not input. You don't (necessarily) need to use strip_tags (although you can if you want), you just need to use htmlspecialchars.

 

 

• Storing text in my database in base64 format to prevent users from doing SQL injection.

 

Well, that's a new one. And terribly wrong. You need to be escaping input, not encoding it.

[NotionCommotion]

That's silly. As long as you escape input or use prepared statements, you can't have SQL injection.

 

 

This isn't really necessary, and still doesn't completely protect you from XSS in all cases. You should be escaping HTML on output, not input. You don't (necessarily) need to use strip_tags (although you can if you want), you just need to use htmlspecialchars.

 

 

Well, that's a new one. And terribly wrong. You need to be escaping input, not encoding it.

 

I am not sure using stored procedures is silly if you have someone else creating those stored procedures for the application programmer.

 

And your second and third comment appear to contradict, but I think we both agree and I am misreading it.  Escape inputs for SQL injections, and escape outputs for XSS.

[scootstah]

I am not sure using stored procedures is silly if you have someone else creating those stored procedures for the application programmer.

I don't mean that stored procedures is silly, just the notion that you must use them to be safe.

 

And your second and third comment appear to contradict, but I think we both agree and I am misreading it.  Escape inputs for SQL injections, and escape outputs for XSS.

You're right, I should have been more specific.

[NotionCommotion]

I don't mean that stored procedures is silly, just the notion that you must use them to be safe.

 

I agree one doesn't need to use them, but then again, I am NotionCommotion

[frik]

You need to be escaping input, not encoding it.

 

I was under the impression that any functions in PHP for escaping inputs were meant for

purposes like building URLs, not for protecting against SQL injection.

Can you point me to the correct function for doing that?