[OWASP_PHPSEC] Daily Report - 23 July, 2013

rahul chaudhary rahul300chaudhary400 at gmail.com
Thu Jul 25 07:29:16 UTC 2013


Abbas,

I have forked the repo...you can see the logs codes in here:
https://github.com/rash805115/phpsec

inside logs folder...


On Thu, Jul 25, 2013 at 2:57 AM, rahul chaudhary <
rahul300chaudhary400 at gmail.com> wrote:

> *Hello Abbas and Chris,*
>
> I think what Abbas said about using other libraries is true. The whole
> purpose of this project is to make libraries such that any of them can be
> used separately. So, if people don't like our implementation of logs, they
> can surely use different ones like (log4php) which gives them all the
> functionality they need.
>
> There is also one more concern with using different libraries for logs. It
> is that with different libraries there will be different kind of logs
> generated and there will be no consistency. Lets talk about higher log
> functionality. Say with log4php I want to filter out all the "INFO" related
> logs. After using log4php for say 3 months, now suddenly I cannot change my
> logs to another logging library because after that the other logger might
> not give me the same logs as I received in log4php. Its better to stick to
> one logger and that one logger must be flexible enough to generate all
> kinds of logs.
>
> Also there are many other things we want from our logger functions. Those
> are like emailing to admins some particular logs, grouping of logs etc.
> To create a wrapper that will manage all these functions will be a
> separate project on its own. We want a simple logger, that can generate all
> kinds of logs (without hassle or even more than 2 lines of code), then we
> want search functions that can go to all records and search for some
> particular events (This part needs consistency in all log files), and we
> also want to group all our logs (Such as grouping in "HIGH", "LOW",
> "MEDIUM"   or maybe in "WARNING", "ERROR", "INFO"). For this we have to
> maintain all this setting. This part must be user customizable because they
> may want to add another category such as "CLASS". For this reason we may
> not want to handle different libraries because all libraries does not
> provide these functions.
>
>
> *To Abbas, *
> For my new library, you said that there must not be any config file or any
> other hassle. So, I made some changes. In new changes, there are many
> default config files already present that will make the noob developers
> life easier. More advanced ones can take their time to make their own
> config files.
> So, the library now works in two lines:
>
> $myLog = new Logger(); //by default logs goes to DB
> $myLog->log("This is the first log"); //Just stores message, no other data.
> $myLog->log("Another log", __FILE__, "HIGH");  //they can pass which file
> generated the logs, and the nature of log.
>
> In case the developer needs to send logs in two places, they can make
> another logger:
> $secondLog = new Logger("default_file_config");  //now the default file
> config is loaded, and this will send logs to file.
> $secondLog->log("This log goes to a file", __FILE__, "HIGH", "WARNING");
> // sends the message, the file location, nature of log, and type of log.
>
> I made many things default so that if a noob wants to use this, they dont
> have to touch anything. For advanced users, they can make some changes and
> even those changes are not more than 5-6 lines. I just received an email
> from Samantha about how to push my codes in github. So, hopefully you can
> analyze the codes then and give feedback.
>
> I know what you will say, you don't want to make objects. Use static  :P
>  . I am still trying for that. So, I guess at last, I will make a wrapper
> on top of this library to make static functions.
>
>
> On Wed, Jul 24, 2013 at 9:01 PM, Abbas Naderi <abiusx at owasp.org> wrote:
>
>> 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<http://abiusx.com/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<http://abiusx.com/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<http://abiusx.com/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<http://abiusx.com/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
>>
>>
>>
>> _______________________________________________
>> OWASP_PHP_Security_Project mailing list
>> OWASP_PHP_Security_Project at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp_php_security_project
>>
>>
>
>
> --
> Regards,
> Rahul Chaudhary
> Ph - 412-519-9634
>



-- 
Regards,
Rahul Chaudhary
Ph - 412-519-9634
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp_php_security_project/attachments/20130725/afd68227/attachment-0001.html>


More information about the OWASP_PHP_Security_Project mailing list