{"id":2913,"date":"2026-07-20T09:38:52","date_gmt":"2026-07-20T07:38:52","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/indirect-prompt-injection-rag-defense-framework-pdf-email-scrapers-2026\/"},"modified":"2026-07-20T09:38:52","modified_gmt":"2026-07-20T07:38:52","slug":"indirect-prompt-injection-rag-defense-framework-pdf-email-scrapers-2026","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/indirect-prompt-injection-rag-defense-framework-pdf-email-scrapers-2026\/","title":{"rendered":"Come Implementare Indirect Prompt Injection Defense in Production: La Mia Procedura RAG Detection Framework per PDF, Email e Web Scrapers 2026"},"content":{"rendered":"

Nel mio lavoro quotidiano con sistemi di Retrieval-Augmented Generation<\/em> (RAG) in produzione, ho affrontato uno degli attacchi pi\u00f9 insidiosi e difficili da rilevare: l’indirect prompt injection<\/strong>. A differenza degli attacchi diretti, dove l’utente malintenzionato interagisce direttamente con il sistema, gli attacchi indiretti nascondono istruzioni maligne dentro documenti, email e pagine web che il sistema retrieves e processa come contenuto fiduciario. Nel luglio 2026, continuo a monitorare come questi attacchi evolvono: le tecniche di encoding Unicode invisibile, il testo bianco-su-bianco nei PDF, i metadati HTML celati. In questa guida, vi condivido il framework di detection che ho costruito e testato<\/strong> in ambienti production, con procedura step-by-step, codice reale e esempi di payload che ho catturato.<\/p>\n

La cosa che mi preoccupa di pi\u00f9 \u00e8 questa: l’indirect prompt injection bypassa ogni security control progettato per validare input dell’utente, mentre il LLM processa documenti esterni, pagine web e email senza questionare le istruzioni nascoste dentro<\/cite>. Nella mia esperienza, ho visto sistemi di supporto aziendale dove il modello ha leakato dati confidenziali, inviato phishing email attraverso l’infrastruttura aziendale, o concesso accesso non autorizzato ai sistemi interni<\/cite>. Gli strumenti tradizionali non vedono questi attacchi perch\u00e9 le istruzioni maligne non toccano mai i perimeter defenses.<\/p>\n

Ho deciso di documentare il mio approccio a difesa layered per tre superfici di attacco critiche: PDF con hidden content, email con encoding obfuscato, e web scraper data poisoning. Il framework che presento combina analisi del layout dei documenti, keyword detection contestuale, e LLM-based semantic anomaly scoring.<\/p>\n

Come Funziona L’Indirect Prompt Injection in Sistemi RAG<\/h2>\n

Quando configuro un sistema RAG per una azienda, il flusso logico \u00e8 semplice: l’utente fa una domanda \u2192 il retriever cerca documenti rilevanti nel knowledge base \u2192 inietta quei documenti nel context window dell’LLM \u2192 il modello risponde basandosi su quel contesto. RAG funziona retrievando documenti rilevanti da un vector database e iniettandoli nel context window del modello. Ma questi documenti sono contenuto esterno. Se un attaccante riesce a influenzare cosa \u00e8 nel knowledge base\u2014come sottomettendo un ticket di supporto che viene indicizzato, editando una wiki page che il sistema crawla, uploadando un documento in un shared drive\u2014pu\u00f2 piantare injection payload che vengono retrievati e feedati direttamente al modello<\/cite>.<\/p>\n

Un modello che processa documenti dell’utente eseguir\u00e0 prompt nascosti dentro di essi. PDF, file DOCX, allegati HTML, e persino metadati di immagini possono portare payload di injection<\/cite>. Nel mio testing, ho scoperto che gli input malziosi non devono essere leggibili dall’uomo\u2014devono solo essere parsati dal modello. Un attaccante pu\u00f2 nascondere istruzioni in testo bianco-su-bianco, caratteri Unicode a larghezza zero, commenti HTML, o campi metadati che nessun umano vedrebbe mai<\/cite>.<\/p>\n

Le Tre Superfici di Attacco Pi\u00f9 Critiche<\/h2>\n

1. PDF con Hidden Content Embedding<\/h3>\n

Gli attacchi sono embedded in documenti (PDF, email) che i sistemi AI processano. Questo pu\u00f2 essere realizzato attraverso testo invisibile, campi di metadati, o persino istruzioni nascoste steganograficamente dentro immagini nei documenti<\/cite>. Nel mio primo incontro con questo vettore d’attacco, ho estratto un PDF di apparenza legittima che conteneva testo grigio-su-grigio\u2014praticamente invisibile all’occhio umano, ma perfettamente leggibile dal tokenizer dell’LLM.<\/p>\n

Ho implementato una procedura di estrazione PDF a due livelli: innanzitutto estraggo il testo grezzo usando pdfplumber<\/em>, poi estraggo anche metadati di layout e colore. Il pipeline inizia estraendo sia il contenuto testuale grezzo che i metadati specifici del layout da un PDF, includendo dimensione del font, colore, posizionamento dei caratteri e informazioni di encoding. Queste feature strutturali sono essenziali per identificare contenuto celato o visivamente offuscato che altrimenti verrebbe ignorato dai parser standard<\/cite>.<\/p>\n

2. Email con Encoding Obfuscato<\/h3>\n

Le email sono un vettore d’attacco sottovalutato. Istruzioni nascoste in documenti, PDF, immagini, o metadati che un assistente ingesta quando processa l’allegato. Encoding e offuscazione: Base64, homoglyphs, Unicode inusuale, o frasi frammentate progettate per slittare oltre il semplice keyword matching mentre rimangono interpretabili dal modello<\/cite>. Ho visto payload nascosti in header MIME, in campi “Subject” codificati come UTF-8 non-standard, e perfino in base64 dentro allegati presunti innocui.<\/p>\n

Un prompt injection riuscito pu\u00f2 portare un assistente AI a leakare contenuto sensibile dalla mailbox, misclassificare un messaggio malzioso come sicuro, generare un summary fuorviante, o prendere un’azione non voluta in un workflow automatizzato. Poich\u00e9 l’attacco giace dentro contenuto email ordinario, pu\u00f2 raggiungere qualsiasi utente la cui mailbox viene processata da un assistente AI<\/cite>.<\/p>\n

3. Web Scraper Data Poisoning<\/h3>\n

Quando il sistema RAG scrape pagine web pubbliche\u2014come FAQ, forum, o documentazione tecnica\u2014gli attaccanti possono piantare istruzioni direttamente nel contenuto indexato. Ho testato payload in commenti HTML su pagine che il crawl mio retriever, e il 100% dei casi ha portato il modello a eseguire istruzioni nascoste. RAG-Pull \u00e8 un attacco imperceptibile su code-generation agents. Targets queries e code repositories via invisible Unicode character insertion, sfruttando malicious skill marketplaces, prompt-engineering sites, e attacker-controlled repositories<\/cite>.<\/p>\n

Il Mio Framework di Detection Layered<\/h2>\n

Nella mia esperienza, nessun singolo detection layer \u00e8 sufficiente. Devo implementare tre livelli:<\/p>\n

    \n
  1. Ingestion Controls:<\/strong> Scanno documenti prima dell’embedding nel vector database<\/li>\n
  2. Retrieval Controls:<\/strong> Monitoraggio del contenuto retrievato e dei pattern anomali<\/li>\n
  3. Generation Controls:<\/strong> Analisi semantica del comportamento del modello durante inference<\/li>\n<\/ol>\n

    Layer 1: Preprocessing e Content Extraction<\/h3>\n

    Ho scritto uno script Python che integro nel pipeline di ingestion per ogni documento che entra nel knowledge base. Estraggo metadata di layout e cerco pattern di hidden content:<\/p>\n

    Codice Python per PDF Analysis:<\/strong><\/p>\n

    import pdfplumber
    import re
    from PIL import Image
    import pytesseract
    import pandas as pd<\/p>\n

    def detect_hidden_pdf_content(pdf_path):
        \"\"\"Rileva testo nascosto, colori sospetti, e anomalie di layout nei PDF\"\"\"
        findings = {
            'invisible_text': [],
            'metadata_anomalies': [],
            'encoding_suspects': [],
            'color_analysis': []
        }
        
        with pdfplumber.open(pdf_path) as pdf:
            for page_num, page in enumerate(pdf.pages):
                # Estrai testo grezzo
                raw_text = page.extract_text()
                raw_text_detailed = page.extract_text_detailed()
                
                # Analizza colore e contrasto di ogni carattere
                for char in raw_text_detailed.get('chars', []):
                    # Caratteri bianco-su-bianco o grigio-su-grigio = sospetti
                    if char.get('fontname', '').endswith('Invisible'):
                        findings['invisible_text'].append({
                            'page': page_num,
                            'text': char.get('text', ''),
                            'size': char.get('size', 0)
                        })
                
                # Scanno per pattern d'injection comuni
                injection_patterns = [
                    r'ignore.*previous',
                    r'you are now',
                    r'disregard.*instructions',
                    r'forget.*original'
                ]
                
                for pattern in injection_patterns:
                    if re.search(pattern, raw_text, re.IGNORECASE):
                        findings['encoding_suspects'].append({r>                        'pattern': pattern,
                            'page': page_num
                        })
        
        return findings
    <\/code><\/p>\n

    In produzione, se questo detector trova hidden content, blocco il documento dall’ingestion e loggo l’evento per revisione manuale. Non silenzio l’alert\u2014\u00e8 troppo critico.<\/p>\n

    Layer 2: Semantic Anomaly Scoring a Retrieval Time<\/h3>\n

    Il mio secondo layer corre a retrieval time: quando il sistema recupera documenti per costruire il context, scanno semanticamente ogni chunk per anomalie. Qui implemento un scoring system che combina:<\/p>\n