For Mike — three documentation points on image upload security (following framework PR #266)
Hello Mike. A fix was merged into the framework today — commit 8f39e22, "fix: stop treating a bare '<?' byte pair as a threat in binary uploads", from PR #266 into master. Three documentation items arise from it.
- What changed (for reference)
• The validation module's content scan (first 4,096 bytes) no longer treats a bare <? in binary content as a threat. The byte pair 0x3C 0x3F occurs by chance in roughly 6% of 4 KB windows of compressed image data, so valid images were being refused as security threats.
• The Image module's opening-bytes check (first 256 bytes) no longer tests for a bare <? either. <?php, <script, <iframe, <object, <embed and <applet are unchanged.
• New behaviour: Image::upload() re-encodes any image whose first 4 KB contain the pair, so client-supplied bytes are never published verbatim. This replaces a guarantee the old heuristic never actually gave.
- Pages needing a small update
• assets/php_framework/0135Image_Manipulation/0010meet_the_image_module.html — under "Script Injection Prevention" ("Scans the first 256 bytes… // Blocks files containing: <?php <script> <iframe> ") it should note that a bare <? is deliberately not treated as a threat in image data, and that an affected image is re-encoded before storage rather than rejected.
• assets/reference/included/image/upload.html — the four-checks summary should add the re-encode behaviour.
• assets/php_framework/0130Working_With_Files/0060regarding_file_security.html — the list of patterns that "trigger automatic rejection" leads with '<?php'; it should make clear that a bare <? now applies to text content only, and mention the image re-encode.
• assets/reference/included/validation/set_rules.html — "scans the first 256 bytes of uploaded files" conflates two checks: the validation module scans the first 4,096 bytes; the 256-byte scan belongs to the Image module. Worth separating.
- A requirement worth stating plainly
The Image module depends on GD. WebP uploads require GD built with WebP support (imagecreatefromwebp); where the local PHP lacks it, WebP cannot be processed and is refused. This is easily missed — XAMPP's bundled GD can be built without it — so a line such as "supports JPEG, PNG, GIF and WebP, subject to your GD build" would save real confusion. A follow-up change is being prepared so that this failure is reported as an unsupported format rather than "must be a valid image file"; the docs can describe that once merged.
For Mike — three documentation points on image upload security (following framework PR #266)
Hello Mike. A fix was merged into the framework today — commit 8f39e22, "fix: stop treating a bare '<?' byte pair as a threat in binary uploads", from PR #266 into master. Three documentation items arise from it.
• The validation module's content scan (first 4,096 bytes) no longer treats a bare <? in binary content as a threat. The byte pair 0x3C 0x3F occurs by chance in roughly 6% of 4 KB windows of compressed image data, so valid images were being refused as security threats.
• The Image module's opening-bytes check (first 256 bytes) no longer tests for a bare <? either. <?php, <script, <iframe, <object, <embed and <applet are unchanged.
• New behaviour: Image::upload() re-encodes any image whose first 4 KB contain the pair, so client-supplied bytes are never published verbatim. This replaces a guarantee the old heuristic never actually gave.
• assets/php_framework/0135Image_Manipulation/0010meet_the_image_module.html — under "Script Injection Prevention" ("Scans the first 256 bytes… // Blocks files containing: <?php <script> <iframe> ") it should note that a bare <? is deliberately not treated as a threat in image data, and that an affected image is re-encoded before storage rather than rejected.
• assets/reference/included/image/upload.html — the four-checks summary should add the re-encode behaviour.
• assets/php_framework/0130Working_With_Files/0060regarding_file_security.html — the list of patterns that "trigger automatic rejection" leads with '<?php'; it should make clear that a bare <? now applies to text content only, and mention the image re-encode.
• assets/reference/included/validation/set_rules.html — "scans the first 256 bytes of uploaded files" conflates two checks: the validation module scans the first 4,096 bytes; the 256-byte scan belongs to the Image module. Worth separating.
The Image module depends on GD. WebP uploads require GD built with WebP support (imagecreatefromwebp); where the local PHP lacks it, WebP cannot be processed and is refused. This is easily missed — XAMPP's bundled GD can be built without it — so a line such as "supports JPEG, PNG, GIF and WebP, subject to your GD build" would save real confusion. A follow-up change is being prepared so that this failure is reported as an unsupported format rather than "must be a valid image file"; the docs can describe that once merged.