Avoid using strip_tags() for sanitizationĮxtra care should always be taken with user input sanitization and handling. Care still needs to be taken with what gets run in it but approaches process creation more programmatically without exposing access to the core OS. This is actually run via a cron which then runs its own crons as part of the overall cron runtime. Also, it's important to not trust the content header (which can be faked) and to validate the file type.Ĭreate cron jobs dynamically using a Composer library like cron. Remember to take care not to access files created by exposed input and also with some of the functions around file based permissions like chmod() and chown(). Getting a list of files in a specified directory, for example, can be done via the scandir() function, which will return an array of files available in a directory then opened or referenced within code itself. PHP has file functions that can be utilised without needing to call the OS directly. Extra care needs to be taken with this however as it still could enable a traversal attack.Īpproach file system interaction programmatically by minimising the ways that it can be interacted with directly via input. There are a few more secure ways to approach the same functionality.Īs of PHP 7.4, archiving can be handled by the ZipArchive class, activated with -with-zip flag as part of a PHP compile. PHP does provide some functional operators with built-in input escaping, namely escapeshellcmd() and escapeshellarg(), which will pass input through some level of escape and sanitisation as part of the function call. These all will run without any built in code sanitisation, which is where the trouble begins in using them particularly with unvalidated or sanitised direct user input. Traditionally, functions like exec(), shell_exec(), system(), and passthru() would be utilised to perform functions like compressing or decompressing files, creating cron jobs and even navigating OS files and folders. From an attack vector point of view this has lots of opportunities to open all sorts of issues directly into your stack. Avoid using exec(), shell_exec(), system(), or passthru()Īs the saying goes “here be dragons.” As a rule, Avoid the use of anything that can directly call the operating environment from PHP when possible. Utilise a SAST tool to identify code injection issuesġ. 5 ways to prevent code injection in PHP app developmentĪvoid using exec(), shell_exec(), system() or passthru()Īvoid using strip_tags() for sanitisation The detailed report pages will allow you to trace back to repositories at the code level to explore how the vulnerabilities were identified. Something I've also been doing daily is checking the composer Snyk Vulnerability database to explore the techniques being used. It's highly recommended to always be using an open source security scanning tool like Snyk Open Source which will scan your package manager to identify potential vulnerabilities in library and dependency use. For example, avoid using core PHP functionality like shell_exec() and exec() where possible, which executes at the OS level. Sanitise everything coming in and be aware of how it’s stored within your application.Īs a fundamental rule, dynamic code execution should never be allowed in any application. Be aware of front facing inputs and how they are handled. How to prevent code injection in PHPĬode development security begins at the code front with the adoption of a secure coding convention. The vulnerability is processed in the PHP runtime, executing on either the server side or in the unsuspecting user's browser. ![]() It's important to note that PHP does not offer an escaper dedicated to JavaScript, which can also be problematic. ![]() The attacker can send executable PHP code or JavaScript that is executable either on the runtime side of the application or within the end user's browser. The aim is to compromise the integrity of the intended target application. ![]() What is code injection?Ĭode injection is an attack that delivers a malicious code payload through a vulnerable attack vector. Adopting secure coding practices not only helps keep end users secure, it also saves time and development costs by preventing rework. Be it entertainment, workplace or social network application, the end goal is to protect the users we build for by ensuring we build security into the code. As developers, we build apps to help make end users' lives easier. Following on from my previous post on testing for PHP Composer security vulnerabilities, I thought this post might be useful in helping create more secure applications that prevent PHP code injection.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |