[OWASP_PHPSEC] Replacement for Insecure Output Functions

rahul chaudhary rahul300chaudhary400 at gmail.com
Sat Aug 3 17:48:55 UTC 2013


First, why can we automate this task ? If the developers allows us to
change the code, we can replace every instance. We can also build some
options which allows us to exclude some files which developers dont want to
change.

Second, I did not understand your last paragraph.


On Thu, Aug 1, 2013 at 4:11 PM, Abbas Naderi <abiusx at owasp.org> wrote:

> Hi Folks,
> We need replacements for unsafe functions in PHP, for now all those that
> provide any plain output are deemed unsafe because they provide risk of
> XSS. We definitely can track them via TaintTracking, but a huge application
> probably has zillions of those, and running all possible paths are almost
> impossible.
>
> To solve this issue, we are introducing a static parser, that scans a
> whole folder of PHP code, and detects every usage of these functions where
> variables are concatenated and/or outputted. Those with constant strings
> are safe for now.
>
> Then we ask the developers to replace-all them with our replacements,
> which are available in core lib.
> *Now we need these replacements to be as logical as possible, to
> encourage developers to switch, and we need them wisely planned beacuse it
> will be very hard to change them at a later time.*
> *
> *
> That's why I need you to look at them, and propose ideas how to complete
> them. We need replacements for all output functions, e.g echo, print,
> printf, etc. Var_dump and print_r are debug functions and nobody uses them
> in a real app, so no need for those.
>
> Please see the approach I have taken in the core lib, to understand what I
> mean more.
>
> The final point is, we need to be able to introduce some *decontaminated* areas
> using PHPDOCs, and leave unsafe output be in those areas. These areas
> should be very limited, possibly only in a single file in the whole
> project, and are intended to be watched carefully by the developers, cuz
> they can probably fix XSS issues in a few lines of code, where they
> certainly can't in a whole project.
>
> I'm awaiting your responses,
> -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
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp_php_security_project/attachments/20130803/b25bab7a/attachment.html>


More information about the OWASP_PHP_Security_Project mailing list