Content Disarm and Reconstruction (CDR)

Sekilas pandang

NextPDF Enterprise menetralkan PDF tak tepercaya melalui Content Disarm and Reconstruction (CDR): ia mengurai berkas, memeriksanya terhadap batas admisi, mendeteksi fitur berbahaya, menghapusnya, dan membangun ulang berkas baru dari objek yang tersisa. Fitur berbahaya tersebut adalah konten aktif — skrip tertanam, aksi launch, berkas tertanam, media kaya, dan sejenisnya — yang mungkin dieksekusi atau ditindaki oleh sebuah penampil. Halaman ini bersifat tingkat-perilaku: halaman ini menyatakan apa yang diterima mesin, apa yang dilucutinya, apa yang dibangun ulang, dan mengapa keluarannya bukan salinan bukti.

CDR adalah transformasi destruktif satu-arah. Keluaran yang dibangun ulang adalah proyeksi keamanan dari masukan, bukan salinan yang terpelihara atau setara-hash. Batas tersebut dinyatakan di bawah Keamanan dan kepatuhan.

Prasyarat dinyatakan dalam front matter dan diulang di bawah Prasyarat.

Ketersediaan & pelisensian

Kapabilitas ini disertakan dalam NextPDF Enterprise (nextpdf/enterprise) dan aktif dengan amplop lisensi tingkat-Enterprise. Deployment tanpa hak tersebut tidak memuat kelas-kelas kapabilitas ini. NextPDF Core dan NextPDF Pro tidak menyediakan CDR. Mesin berjalan di dalam proses; dokumen tak tepercaya diurai dan dibangun ulang di host Anda. Bandingkan edisi dan dapatkan lisensi.

Apa yang dilakukan kapabilitas ini

PDF mendukung konten aktif yang dapat dieksekusi atau ditindaki oleh sebuah penampil. Sebuah aksi ECMAScript menyebabkan prosesor PDF mengeksekusi skrip yang dapat mengubah nilai bidang dan tampilan, sesuai ISO 32000-2 §12.6.4. Sebuah aksi launch meluncurkan aplikasi atau membuka atau mencetak dokumen, sesuai ISO 32000-2 §12.6.4. Skrip tingkat-dokumen di kamus nama berjalan otomatis ketika dokumen dibuka, sesuai ISO 32000-2 §7.7.4. CDR menghapus permukaan-permukaan ini.

Mesin menjalankan pipeline terurut:

1. Urai PDF masukan.
2. Kontrol admisi — verifikasi dokumen berada dalam batas penerimaan (jumlah objek, jumlah halaman, ukuran aliran terdekode, dan rasio inflasi-aliran yang bertahan terhadap masukan decompression-bomb). Dokumen di luar batas ditolak, bukan disanitasi. Penolakan dilaporkan secara berbeda dari hasil sanitasi sehingga penanganan galat Anda dapat membedakan keduanya.
3. Deteksi ancaman — pindai tipe ancaman yang dikonfigurasi.
4. Saring — partisi objek menjadi himpunan aman dan himpunan yang dihapus.
5. Pembersihan referensi — bersihkan penunjuk yang menggantung akibat penghapusan.
6. Bangun ulang — serialkan objek aman menjadi PDF baru.

Tipe ancaman yang dapat dideteksi mencakup skrip tertanam (dan pelucutan skrip agresif yang menangkap skrip dalam struktur malformasi), pemicu additional-actions dan open-action, aksi launch, aksi remote go-to, aksi form submit dan import-data, berkas tertanam, media kaya dan konten tiga-dimensi, pohon nama skrip tingkat-dokumen, aksi Uniform Resource Identifier (URI) eksternal, data XML Forms Architecture, bidang formulir interaktif, lapisan optional-content non-baku, dan objek tanda-tangan-digital (yang tentu diinvalidasi oleh pembangunan ulang karena rentang byte tidak lagi cocok). Objek yang tidak dapat diurai itu sendiri diperlakukan sebagai potensi bypass dan dihapus.

Tiga kebijakan menetapkan baku:

• Standard — menghapus tipe ancaman konten-aktif yang dikonfigurasi dan dapat dideteksi mesin; incremental update selalu diratakan untuk bertahan terhadap signature-shadowing, dan perataan itu tidak dapat dikonfigurasi dalam mode ini.
• Paranoid — penghapusan yang sama dengan batas sumber daya yang lebih ketat.
• Permissive — untuk sumber tepercaya: menghapus skrip dan aksi launch tetapi mempertahankan aksi URI, dan membuat perataan incremental-update dapat dikonfigurasi.

Mengapa cara kerjanya demikian

CDR membangun ulang berkas baru dari objek yang dinilai aman, alih-alih menghapus kunci berbahaya di tempat. Postur allow-list itu adalah keputusan yang memikul beban. Objek yang tidak pernah dikenali detektor — termasuk yang tidak dapat diuraikannya — tidak bertahan hingga ke keluaran, sehingga struktur tak dikenal gagal-tertutup alih-alih menyelinap melalui celah deny-list. Kontrol admisi berjalan pertama untuk alasan yang sama: masukan yang melebihi batas atau tak-terurai ditolak langsung, tidak pernah dibangun ulang sebagian. Biaya dari keamanan itu adalah pelestarian. Pembangunan ulang mengubah tata letak byte, menginvalidasi tanda tangan, dan membuang muatan yang tipe ancamannya dilucuti — itulah sebabnya keluarannya adalah proyeksi keamanan, tidak pernah salinan bukti.

Latar belakang desain: Menyanitasi PDF tak tepercaya: content disarm and reconstruction.

Prasyarat

1. Pasang NextPDF Core dan paket Enterprise, serta pertahankan lisensi Enterprise yang aktif.
2. Definisikan batas penerimaan untuk masukan Anda — jumlah objek maksimum, jumlah halaman, ukuran aliran terdekode, dan rasio inflasi — atau gunakan batas dari kebijakan prasetel.
3. Putuskan kebijakannya: standard untuk asupan tak tepercaya umum, paranoid untuk postur paling ketat, atau permissive hanya untuk sumber tepercaya.

Konfigurasi

Kebijakan bersifat imutabel dan membawa:

• Tipe ancaman yang dihapus — himpunan yang dipindai detektor dan dilucuti perakit-ulang.
• Penanganan aksi-URI — apakah aksi URI eksternal dipertahankan.
• Perataan incremental-update — selalu aktif dalam standard dan paranoid; dapat dikonfigurasi dalam permissive.
• Batas admisi — jumlah objek maksimum, jumlah halaman, ukuran aliran terdekode, dan rasio inflasi. Ini adalah batas penerimaan, bukan perilaku sanitasi; melebihinya menolak dokumen.

Langkah demi langkah

1. Baca byte PDF tak tepercaya.
2. Pilih kebijakan (standard, paranoid, atau permissive) atau bangun satu dengan batas eksplisit.
3. Jalankan operasi sanitasi mesin dengan byte dan kebijakannya.
4. Periksa hasilnya: jika melaporkan tidak diterima, munculkan alasan penolakan; jika tidak, gunakan byte yang dibangun ulang dan daftar ancaman yang dihapus.
5. Perlakukan keluaran yang dibangun ulang sebagai proyeksi tersanitasi, jangan pernah sebagai salinan bukti atau arsip dari masukan.

examples/enterprise/cdr-sanitize-guarded.php

<?php

declare(strict_types=1);

require_once __DIR__ . '/../../vendor/autoload.php';

use NextPDF\Enterprise\Security\Cdr\CdrEngine;
use NextPDF\Enterprise\Security\Cdr\CdrPolicy;
use NextPDF\Enterprise\Security\Cdr\CdrResult;
use Psr\Log\LoggerInterface;

final readonly class UntrustedPdfIntake
{
    public function __construct(
        private CdrEngine $engine,
        private LoggerInterface $logger,
    ) {}

    /**
     * Sanitize an untrusted PDF and distinguish rejection from a clean rebuild.
     *
     * An over-limit document is rejected by admission control, not sanitized;
     * the caller surfaces the rejection reason instead of trusting an empty
     * output. The rebuilt bytes are a security projection, never an
     * evidentiary copy of the input.
     *
     * @param string $pdfBytes The untrusted PDF bytes.
     *
     * @return CdrResult The sanitization result, including admission status.
     */
    public function sanitize(string $pdfBytes): CdrResult
    {
        $result = $this->engine->sanitize($pdfBytes, CdrPolicy::standard());

        if (! $result->admitted) {
            $this->logger->warning('PDF rejected by CDR admission control', [
                'reason' => $result->rejectionReason,
            ]);

            return $result;
        }

        $this->logger->info('PDF sanitized', [
            'removedThreats' => \count($result->removedThreats),
            'originalSize'   => $result->originalSize,
            'sanitizedSize'  => $result->sanitizedSize,
        ]);

        return $result;
    }
}

Verifikasi

1. Jalankan sampel yang membawa permukaan konten-aktif yang diketahui (misalnya skrip tingkat-dokumen) dan pastikan ia muncul dalam daftar ancaman-dihapus dan absen dari keluaran yang dibangun ulang.
2. Jalankan dokumen di luar batas dan pastikan hasilnya melaporkan tidak diterima dengan alasan penolakan, dan byte yang dibangun ulang kosong.
3. Pastikan masukan yang ditandatangani secara digital memiliki objek tanda tangannya dihapus dalam pembangunan ulang — sebuah pembangunan ulang menginvalidasi tanda tangan asli karena rentang byte berubah, sehingga objek tanda tangan basi dilucuti secara sengaja.
4. Buka keluaran yang dibangun ulang di sebuah penampil dan pastikan tidak ada skrip yang dieksekusi saat dibuka.

Keamanan dan kepatuhan

• Bukan untuk bukti. Keluaran yang dibangun ulang adalah proyeksi destruktif yang tidak dapat dibalik. Jangan menggunakannya untuk pelestarian bukti hukum, untuk perbandingan hash dengan aslinya, atau sebagai salinan arsip. Simpan aslinya di bawah kustodi terpisah jika Anda memerlukan salinan bukti.
• Admisi sebelum sanitasi. Batas sumber daya adalah batas penerimaan; dokumen di luar batas ditolak, bukan disanitasi. Laporkan penolakan secara berbeda sehingga masukan di luar batas tidak pernah disalahartikan sebagai pembangunan ulang yang bersih.
• Konten aktif dihapus. Skrip, aksi launch, pohon nama skrip tingkat-dokumen, berkas tertanam, media kaya, dan permukaan sejenisnya dilucuti — justru aksi yang jika tidak akan dieksekusi oleh penampil (ISO 32000-2 §12.6.4 aksi ECMAScript; aksi launch; skrip tingkat-dokumen §7.7.4).
• Tanda tangan diinvalidasi oleh pembangunan ulang. Karena pembangunan ulang mengubah tata letak byte, tanda tangan asli tidak lagi dapat tervalidasi; objek tanda tangan dihapus alih-alih dibiarkan secara menyesatkan.
• Lossy secara desain. Muatan berkas-tertanam — termasuk lampiran faktur seperti Factur-X — dihapus ketika tipe ancamannya dilucuti. CDR adalah proyeksi keamanan, bukan lapisan pelestarian.

Halaman ini berkaitan dengan keamanan dokumen. Setiap sumber normatif diparafrasakan; tidak ada teks normatif yang direproduksi.

Penanganan kegagalan

• Kegagalan urai. Dokumen yang tidak dapat diurai menghasilkan hasil tidak-diterima dengan alasan galat-urai alih-alih pembangunan ulang parsial.
• Masukan di luar batas. Hasil melaporkan tidak diterima dengan alasan spesifik-batas; byte yang dibangun ulang kosong.
• Objek tak-terurai. Objek yang tidak dapat diurai diperlakukan sebagai potensi bypass dan dihapus, bukan dipertahankan diam-diam.
• Jumlah halaman best-effort. Pemeriksaan admisi jumlah-halaman bersifat best-effort; katalog malformasi tidak menghancurkan pipeline, tetapi batas jumlah-objek dan aliran tetap berlaku.

Batas publikasi

Halaman ini hanya mendokumentasikan perilaku yang dapat diamati secara eksternal dan permukaan API publik yang didukung. Jalur namespace internal, kelas pembantu, tabel mekanisme, nama berkas runbook, dan prefiks tiket berada di luar cakupan.

Lihat juga

• Security — NextPDF Enterprise — permukaan keamanan Enterprise gabungan.
• Validation — NextPDF Enterprise — pemeriksaan kesesuaian PDF yang dihasilkan atau dibangun ulang.
• Forensics — NextPDF Enterprise — pemeriksaan dan penelusuran dokumen.
• Security — NextPDF Core — permukaan enkripsi dan tanda tangan inti.
• CDR · active content · shadow attack — istilah glosarium.