[OWASP_PHPSEC] Daily Report - 23 July, 2013

Abbas Naderi abiusx at owasp.org
Thu Jul 25 01:01:07 UTC 2013


Hi again,
I'm assuming you got me wrong.

Let me provide a scenario. What percentage of application developers use two loggers? I say less than 20. What percentage use one logger, and not even a lot of that one? I say more than 70%. Now if you require them to go through a tutorial and learn different loggers and choose one to use, you are assuring that a good chunk of those 70% are never going to use logging at all (after all, they won't die without it).

But, if you have a simple functionality, like phpsec\Log(…), you're making sure all the noobies and people new to logging will use that. If more advanced users are out there, let them instance the library! You're not limiting the instantiation, you're just providing easy-to-use convenient wrappers, that most of the users will use.

It's just like providing a phpsec\SQL function that does SQL, instead of requiring the user to instantiate an object, set a million properties, and call two or three methods. The latter assures that developers will go around this convention when they want just a quick fix, and get themselves contaminated with flaws.

Of course conventions exist for a reason, but PHP conventions set by Java people exist for the wrong reason. I've been around PHP since it came around as a biggie, and have done everything possible with it. I can assure you following PSR-3 will just turn us into yet another ESAPI, no PHP developer will use us. If they want the hassle and following all the strict standards, they can use Java.

On top of that, we're not forcing people, and we are not breaking compliance. Logging is not essential, and is neither security critical. If someone doesn't like our ways, they can jsut use log4php or any other library, and hook them to our means. That's why I'm insisting on minimal observer pattern practices in our libraries, to make them flexible. Maybe someone has a weird SQL functionality in place, and is comfortable using that one, we'd have to make them able to at least report back to us via hooks when they do SQL (for dependencies).

If HTTP and HTML were not cumbersome, why would one bother with PHP instead of using Perl or C-CGIs? PHP is for rapid development, we should not shackle the developers, cuz PHP guys hate that and will discard us if it happens.

Its not a commendment, I'm just stating my experience.

Thanks
-Abbas
______________________________________________________________
Notice: This message is digitally signed, its source and integrity are verifiable.
If you mail client does not support S/MIME verification, it will display a file (smime.p7s), which includes the X.509 certificate and the signature body.  Read more at Certified E-Mail with Comodo and Thunderbird in AbiusX.com

On Mordad 3, 1392, at 4:28 AM, Chris White <cwhite at remarinc.com> wrote:

> By going the static route you are limiting the developer to one logger. Let’s say a developer wants to write to two different sources, but any one library does not write to both. In this case he/she will have to use two different libraries to achieve their goal.
>  
> Example:
> $monologLog = new phpsec\Log($monolog);
> $log4phpLog = new phpsec\Log($log4php);
>  
> Sure, you can add a Log::addLogger($logger) method and iterate through the array of loggers, but what if they only want to send information to one of the loggers? A library needs to be flexible. These scenarios might seem a bit farfetched, but plausible none the less.
>  
> Conventions exist for a reason. They allow a developer to assume something will work as expected without having to learn something new. It also adds to the portability of code. Giving a developer a PSR-3 compliant logger and if they have used other loggers then they are immediately comfortable with phpsec. Have to integrate the library? PSR-0 provides a seamless way so you don’t have to include anything extra. Perhaps, it is burdensome and at times constricting, but the benefits are there. It can be argued that HTML, HTTP, TCP/IP, and pretty much anything else is a convention (specification). They allow people to assume how something works.
>  
> Chris White
> Network Administrator
> Remar, Inc.
> Work: 615-449-0231
> Cell: 615-948-1388
>  
>  
> From: Abbas Naderi [mailto:abiusx at owasp.org] 
> Sent: Wednesday, July 24, 2013 6:22 PM
> To: Chris White
> Cc: owasp_php_security_project at lists.owasp.org
> Subject: Re: [OWASP_PHPSEC] Daily Report - 23 July, 2013
>  
> Hi,
> Thats exactly what I meant, with one difference.
> Instantiating a class without a state, and then calling its methods is meaningless. Why not just use static methods for that purpose?  I want to reduce all unnecessary things. PHP developers hate to be treated like Java devs. PHP is not Java, its for smart rapid people.
>  
> PSR compliances are much Java like, and we are following a similar, but difference convention.
> Thanks
> -Abbas 
> ______________________________________________________________
> Notice: This message is digitally signed, its source and integrity are verifiable.
> If you mail client does not support S/MIME verification, it will display a file (smime.p7s), which includes the X.509 certificate and the signature body.  Read more at Certified E-Mail with Comodo and Thunderbird in AbiusX.com
>  
> On Mordad 3, 1392, at 1:53 AM, Chris White <cwhite at remarinc.com> wrote:
> 
> 
> You can keep from forcing any one library by creating a simple wrapper and use dependency injection. This allows you to evade any licensing issues. I see two ways of implementing this…
>  
> At instantiation:
>  
> $phpsecLog = new phpsec\Log($monolog);
> $phpsecLog->addError(‘oops’);
>  
> Method:
>  
> $phpsecLog = new phpsec\Log();
> $phpsecLog->setLogger($monolog);
> $phpsecLog->addError(‘oops’);
>  
> Requiring a PSR-3 compliant logger allows $phpsecLog->addError(‘whatever’) to look like this:
>  
> public function addError($string, array $additionalData = array())
> {
>                 $this->sanitizeData($string);
>                 $this->sanitizeData($additionalData);
>                 $this->logger->addError($string, $additionalData);
> }
>  
> On the method based injection I suggest defaulting to a null logger. All of the functions are accessible, but do nothing.
>  
> Chris White
> Network Administrator
> Remar, Inc.
> Work: 615-449-0231
> Cell: 615-948-1388
>  
> From: Abbas Naderi [mailto:abiusx at owasp.org] 
> Sent: Wednesday, July 24, 2013 2:54 PM
> To: Chris White
> Cc: owasp_php_security_project at lists.owasp.org
> Subject: Re: [OWASP_PHPSEC] Daily Report - 23 July, 2013
>  
> Great point Chris,
> Let us check Monolog.
> We have to check it for security issues as well, and we need a fairly easy to use final logging facility.
>  
> On top of that, keep in mind that we don't want to force any 3rd parties (license issues and etc.), so we have to provide a bare minimum on ourselves, something as simple as appending to a file.
> -Abbas
> ______________________________________________________________
> Notice: This message is digitally signed, its source and integrity are verifiable.
> If you mail client does not support S/MIME verification, it will display a file (smime.p7s), which includes the X.509 certificate and the signature body.  Read more at Certified E-Mail with Comodo and Thunderbird in AbiusX.com
>  
> On Mordad 3, 1392, at 12:14 AM, Chris White <cwhite at remarinc.com> wrote:
> 
> 
> 
> This may have been addressed already, but I strongly endorse the use of Monolog (https://github.com/Seldaek/monolog) as a logging utility.  Not only does it follow RFC 5425 log levels (http://tools.ietf.org/html/rfc5424), but also the PSR-3 (https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-3-logger-interface.md) logging standard.  Using libraries that follow this standard decouples the logging library used from PHPSEC.  At the very least, I suggest following the suggested standards if you decide to build a proprietary logging library.  The best approach might be to create a wrapper for other logging libraries that fulfills security considerations.
>  
> Example of Monlog instantiation and use:
> // create a log channel
> $log = new Logger('name');
> $log->pushHandler(new StreamHandler('path/to/your.log', Logger::WARNING));
>  
> // add records to the log
> $log->addWarning('Foo');
> $log->addError('Bar');
>  
> Chris White
> Network Administrator
> Remar, Inc.
> Work: 615-449-0231
> Cell: 615-948-1388
>  
> From: owasp_php_security_project-bounces at lists.owasp.org [mailto:owasp_php_security_project-bounces at lists.owasp.org] On Behalf Of Abbas Naderi
> Sent: Wednesday, July 24, 2013 7:21 AM
> To: rahul chaudhary
> Cc: owasp_php_security_project at lists.owasp.org
> Subject: Re: [OWASP_PHPSEC] Daily Report - 23 July, 2013
>  
> Hi Rahul,
> Congrats on ur exam.
> The approach with the log lib is not what we're looking for.
> We need something simple, flexible and scalable, no config files and 20 lines of initiating the library before using it.
> We don't want PHPSEC to be yet another ESAPI, with all the bloat that made it drown. Make everything as simple and working as possible. If somebody needs more features, either they will expand it or they will ask us to make a more thorough version.
> Thanks
> -Abbas
> ______________________________________________________________
> Notice: This message is digitally signed, its source and integrity are verifiable.
> If you mail client does not support S/MIME verification, it will display a file (smime.p7s), which includes the X.509 certificate and the signature body.  Read more at Certified E-Mail with Comodo and Thunderbird in AbiusX.com
>  
> On Mordad 2, 1392, at 12:12 PM, rahul chaudhary <rahul300chaudhary400 at gmail.com> wrote:
> 
> 
> 
> 
> Hello All,
>  
> So as you all know, I tool leave for sunday and monday. Now I am back. You would be glad to know that I have passed my test. Tomorrow (Tuesday) I am having an HR round and possibly after that I will have technical rounds.
>  
> Before my report, please add me in the contributor list. I am not able to push my codes.
>  
> So here's my tuesday report.
>  
> Today I worked on the "logs" library. I added support for storing logs in files and in DB.
> I also created a template that makes user define in what format they want their logs to be stored in.
>  
> Our logs work like this:
> You create an instance of log and then you pass it a configuration file. From that configuration file, the logger will collect all the settings and do all the necessary works. This conf file will contain the type of storing mode such as Db, file etc. It will also tell table name, filename, which mode to open file in etc etc. Once this has been done, the developer can call the log function to store their logs using logger->log("mylogmessage"); They can also specify additional details such as file where the error was generated, type of error, priority of error etc.
>  
> With our logs library, the developers can also make their own template if they would like to store additional data such as which class generated the error. To do this, they would just have to make minor changes in code.
>  
> Currently the configuration file just supports arrays. Later I will add XML support also.
>  
> Since I am not familiar with XML, I am reading it now. once I do this, then we can also store logs in XML format (if desired). Abbas also told me to store logs in syslogs....I do not know what that is...so I have to read it...that might take time....I am also working on functions such as mailing of important logs to admins.....and searching for 1 or multiple entries in logs.
> 
>  
> --
> Regards,
> Rahul Chaudhary
> Ph - 412-519-9634
> _______________________________________________
> OWASP_PHP_Security_Project mailing list
> OWASP_PHP_Security_Project at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp_php_security_project
>  
> _______________________________________________
> OWASP_PHP_Security_Project mailing list
> OWASP_PHP_Security_Project at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp_php_security_project
>  
> _______________________________________________
> OWASP_PHP_Security_Project mailing list
> OWASP_PHP_Security_Project at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp_php_security_project
>  
> _______________________________________________
> OWASP_PHP_Security_Project mailing list
> OWASP_PHP_Security_Project at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp_php_security_project

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp_php_security_project/attachments/20130725/ac1a1803/attachment-0001.html>


More information about the OWASP_PHP_Security_Project mailing list