Please define PHP security...If you think you can!

RedBMedia

Proficient

Posts: 315

3+ Months Ago

So, I have been teaching myself PHP for about a year now and often times I take different scripts that I have created and run them by folks on forums, like this one. One of the things that I always hear is that my scripts are not secure. Ok, fine I am bad at security, I can accept that. But when others on the forums try to point out the actual security flaws in my code, it always turns into a debate over whats secure and what isn't. So, thus I am left with no clue if my scripts are secure or not, and no direction to go in to fix them.

So, my question is: Can anyone define elements of secure PHP code? Can anyone point to articles or examples of PHP security? Does some one want to try to define it in their own words?

Maybe this thread can turn into something beneficial for everyone.

neksus

Mastermind

Posts: 2193

Loc: Canada

3+ Months Ago

That depends what you mean by secure. Are you trying to avoid SQL injections? Are you trying to limit user access?

RedBMedia

Proficient

Posts: 315

3+ Months Ago

neksus wrote:

That depends what you mean by secure. Are you trying to avoid SQL injections? Are you trying to limit user access?

I suppose defining "security" should be our first priority. But that is part of the problem, it seems as if there are so many different ideas about what secure means. Thats why I am posing this question for discussion.

Bogey

Genius

Posts: 8488

Loc: USA

3+ Months Ago

Security is, like you said, a controversial topic where people have different opinions on what secure is and how to make such scripts.

Security in general, is keeping others from making anything that effects the other group negatively. If you think SQL Injections is bad for you, than you would want to make some protection against such act. (I'm sure SQL Injections are bad ).

To get a bit more technical with the definition of PHP Security we have to think about the other people and what they think of it and put a compromising definition that benefits both and/or all groups of people with different definitions.

So far, coming from me, definition of PHP Security is - Keeping people from effecting anyone by anyone in any way through your script.

Maybe that definition is too broad or too general, I don't know. But that is what I try to do. If someone, using my PHP can do something to another person's portfolio or something to my site, I'm going to be worried about my PHP security and thinking maybe it's not secure enough.

RedBMedia

Proficient

Posts: 315

3+ Months Ago

Bogey wrote:

Security is, like you said, a controversial topic where people have different opinions on what secure is and how to make such scripts.

Security in general, is keeping others from making anything that effects the other group negatively. If you thing SQL Injections is bad for you, than you would want to make some protection against such act. (I'm sure SQL Injections are bad ).

To get a bit more technical with the definition of PHP Security we have to think about the other people and what they think of it and put a compromising definition that benefits both and/or all groups of people with different definitions.

So far, coming from me, definition of PHP Security is - Keeping people from effecting anyone by anyone in any way through your script.

Maybe that definition is too broad or too general, I don't know. But that is what I try to do. If someone, using my PHP can do something to another person's portfolio or something to my site, I'm going to be worried about my PHP security and thinking maybe it's not secure enough.

Excellent definition Bogey! I wonder if it might be more proactive if we talk about different specific threats such as SQL Injections and define them, talk about how they are executed, and how to defend against them. Anyone else have any thoughts to get started?

neksus

Mastermind

Posts: 2193

Loc: Canada

3+ Months Ago

Error trap your if statements

may

Proficient

Posts: 328

Loc: Holland [NL]

3+ Months Ago

Sorry for saying so, I dont want to claim that some programmers are "short-sighted". But i do think that it all depends on your approach on the subject.

As a programmer from new-york explained in his blog, there are prob. two types of programmers. Idealists and Pragmatists, if you consider all code from the Idealistic point of view without taking the "functional" side of the code in consideration most code that uses a html form might be considered a security risk.

From the pragmatist point of view i would first ask you what you would like the code to do eventually and then consider the options your code gives me to do different things then the declared functionality. For instance,

If you want me only to be able to sign-in using your form, and i am able to do this from a different location. I might consider this either a security flaw, or an undocumented feature.

If you dont want anyone to get "admin" status without the use of your carefully written admin pannel, and i am able to do this from your site without using the carefully written admin pannel, I might consider this again a security flaw or an undocumented feature...

I guess it all depends on your final functional demands and what you allow people to do by writing strong or weaker code in some points.

-Regards,

neksus

Mastermind

Posts: 2193

Loc: Canada

3+ Months Ago

May is pretty good when it comes to security

RedBMedia

Proficient

Posts: 315

3+ Months Ago

may wrote:

Sorry for saying so, I dont want to claim that some programmers are "short-sighted". But i do think that it all depends on your approach on the subject.

As a programmer from new-york explained in his blog, there are prob. two types of programmers. Idealists and Pragmatists, if you consider all code from the Idealistic point of view without taking the "functional" side of the code in consideration most code that uses a html form might be considered a security risk.

From the pragmatist point of view i would first ask you what you would like the code to do eventually and then consider the options your code gives me to do different things then the declared functionality. For instance,

If you want me only to be able to sign-in using your form, and i am able to do this from a different location. I might consider this either a security flaw, or an undocumented feature.

If you dont want anyone to get "admin" status without the use of your carefully written admin pannel, and i am able to do this from your site without using the carefully written admin pannel, I might consider this again a security flaw or an undocumented feature...

I guess it all depends on your final functional demands and what you allow people to do by writing strong or weaker code in some points.

-Regards,

I agree with you on defining your approach - idealist/pragmatist. However, I don't think security is (or should be) that ambiguous.

Using your example:

may wrote:

If you dont want anyone to get "admin" status without the use of your carefully written admin pannel, and i am able to do this from your site without using the carefully written admin pannel, I might consider this again a security flaw or an undocumented feature...

IMHO, you, as a person that is trying to execute an exploit, it doesn't matter what you "consider". From the author of the code's view point your consideration went out the window when you by passed the admin panel. Therefore whether or not you view the weak code as an opportunity or "undocumented feature" is irrelevant because you are not the author of the code and now have admin "status" when not normally allowed.

The goal of this thread is to discuss PHP security with specific examples of strong secure code. Not to take the view of an opportunistic view of weak code.

may

Proficient

Posts: 328

Loc: Holland [NL]

3+ Months Ago

Sorry for the gabs that allow this side road. But the whole principle of Penetration Testing (CEH) is based on breaking code / architectures / systems, compared to what these are supposed to be doing. Wich in turn defines strong or weak code. And offer us the knowledge to make it better or protect it all toghether.

Again, this is still my opinion, sure you can agree or not thats your free choice and i wont try to convince you there...

But what i was trying to point out is that where ever there is some type of interaction between systems either code, network based or otherwise there will be "risks".And while dealing with them someone has to make a choice how to deal with it.

Concerning your highlighted example, A developer might acknowledge this "Risk" is true due to a software flaw in the PHP engine, and might next make the choice to either write the code accepting this risk or not write it at all and find a different more secure way of managing the application. At the end someone will be held responsible for the risk, either let the business decide if the risk is acceptable and leave them with the responsibility or take it yourself...

-Regards,

cipher

Graduate

Posts: 157

3+ Months Ago

may wrote:

Concerning your highlighted example, A developer might acknowledge this "Risk" is true due to a software flaw in the PHP engine, and might next make the choice to either write the code accepting this risk or not write it at all and find a different more secure way of managing the application. At the end someone will be held responsible for the risk, either let the business decide if the risk is acceptable and leave them with the responsibility or take it yourself...

Well said, that's what it always boils down to. I'm from the pragmatic school . Regarding the form let's say you are checking every field on the server side for unwanted characters, you can take the risk of not performing this check on the data from a select box because the user does not enter anything (just selects) but someone can take firebug or some dom editor and change the value in the select box, then you're in trouble. So like may said, it's all about the risk.

RedBMedia, I'd say use http://devzone.zend.com/tag/Security_Tips as a guideline. Naturally you'll formulate your own approach given time, especially if you have a tester that you work with that gets to break your code.

RedBMedia

Proficient

Posts: 315

3+ Months Ago

cipher wrote:

may wrote:

Concerning your highlighted example, A developer might acknowledge this "Risk" is true due to a software flaw in the PHP engine, and might next make the choice to either write the code accepting this risk or not write it at all and find a different more secure way of managing the application. At the end someone will be held responsible for the risk, either let the business decide if the risk is acceptable and leave them with the responsibility or take it yourself...

Well said, that's what it always boils down to. I'm from the pragmatic school . Regarding the form let's say you are checking every field on the server side for unwanted characters, you can take the risk of not performing this check on the data from a select box because the user does not enter anything (just selects) but someone can take firebug or some dom editor and change the value in the select box, then you're in trouble. So like may said, it's all about the risk.

RedBMedia, I'd say use http://devzone.zend.com/tag/Security_Tips as a guideline. Naturally you'll formulate your own approach given time, especially if you have a tester that you work with that gets to break your code.

cipher, thank you for this: http://devzone.zend.com/tag/Security_Tips - these are the types of resources I intended to pull out of this thread!