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

  • RedBMedia
  • Proficient
  • Proficient
  • User avatar
  • Posts: 315

Post 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.
  • Anonymous
  • Bot
  • No Avatar
  • Posts: ?
  • Loc: Ozzuland
  • Status: Online

Post 3+ Months Ago

  • neksus
  • Mastermind
  • Mastermind
  • User avatar
  • Posts: 2194
  • Loc: Canada

Post 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
  • Proficient
  • User avatar
  • Posts: 315

Post 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
  • Genius
  • Bogey
  • Posts: 8388
  • Loc: USA

Post 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 :lol:).

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
  • Proficient
  • User avatar
  • Posts: 315

Post 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 :lol:).

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
  • Mastermind
  • User avatar
  • Posts: 2194
  • Loc: Canada

Post 3+ Months Ago

Error trap your if statements :)
  • may
  • Proficient
  • Proficient
  • User avatar
  • Posts: 328
  • Loc: Holland [NL]

Post 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
  • Mastermind
  • User avatar
  • Posts: 2194
  • Loc: Canada

Post 3+ Months Ago

May is pretty good when it comes to security ;)
  • RedBMedia
  • Proficient
  • Proficient
  • User avatar
  • Posts: 315

Post 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
  • Proficient
  • User avatar
  • Posts: 328
  • Loc: Holland [NL]

Post 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
  • Graduate
  • User avatar
  • Posts: 157

Post 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
  • Proficient
  • User avatar
  • Posts: 315

Post 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!

Post Information

  • Total Posts in this topic: 12 posts
  • Users browsing this forum: No registered users and 3 guests
  • You cannot post new topics in this forum
  • You cannot reply to topics in this forum
  • You cannot edit your posts in this forum
  • You cannot delete your posts in this forum
  • You cannot post attachments in this forum
 
cron
 

© 1998-2014. Ozzu® is a registered trademark of Unmelted, LLC.