Non è possibile che un pentestore possa garantire al 100% che i dati non vengano modificati o eliminati, nello stesso modo in cui non possono garantire che la disponibilità del sistema non ne risenta (ho abbattuto i sistemi con una porta scansione o un singolo 'carattere). come dici tu, un web crawler può cancellare dati da un sistema se è stato impostato male.

Direi che ciò che dovrebbe essere detto è qualcosa del tipo "sarà prestata ogni attenzione per garantire che il test non influenzi negativamente i sistemi in esame e che non vengano fatti tentativi deliberati per modificare o eliminare i dati di produzione o negativamente influire sulla disponibilità dei sistemi in ambito, tuttavia con tutti i test di sicurezza esiste il rischio che i sistemi siano interessati e il cliente deve assicurarsi che i backup di tutti i dati e i sistemi siano in atto prima dell'inizio della revisione "

Un pentecoste che afferma che mai altererà i dati di produzione è un bugiardo schifoso , o pensa di essere molto più competente di quello che è realmente, o strongmente intende non fare nulla (è l'unico modo sicuro per non rompere mai nulla). In ogni caso, non vuoi lavorare con quel tipo.

Un potenziale cliente che crede che i pentesters qualificati non danneggeranno mai i sistemi testati e che si rifiuta di lavorare con i pentesters a meno che non promettano esattamente questo, è un cliente che 1. vive nell'unico mondo delle fate e 2. è quasi garantito mai fare affari solo con sporchi bugiardi. Ha qualche disillusione ad un certo punto, probabilmente in un modo piuttosto spettacolare.

È un imperativo morale e anche auto-protezione di base per i pentesters per includere clausole sulla possibile rottura nei loro contratti. Il rischio di danno collaterale è reale, anche se il pentester è molto bravo in quello che fa (perché il danno non deriva da quanto è buono il pentester ma da quanto male è stato progettato il sistema testato e implementato ). Un pentestore potrebbe essere citato in giudizio per non dopo aver avvertito il cliente.

Un cliente che rifiuta un contratto con tale clausola ha un altro nome: "guai". Di solito è meglio saltare del tutto tali clienti.

Caveat: non sono un pentester professionista. E io lavoro nel software di backup.

Can a skilled and professional pentester always assure that no data will be deleted or modified in production during a pentest?

Direi di no, non ci sono garanzie assolute qualcosa che non verrà cancellato per errore quando stai cercando di rompere le cose. Tuttavia, detto questo, un pentestore dovrebbe generalmente cercare di sfruttare i sistemi in un modo che non comporta la cancellazione dei dati. Ad esempio, mentre l'istruzione SQL preferita di tutti è:

select * from users where userid='dave'; DROP ALL TABLES;

Un approccio più responsabile sarebbe semplicemente quello di elencare tutti i dati:

select * from users where userid='2' OR 1=1;

In generale, immagino che la maggior parte dei tester di penna abbia sviluppato una serie di exploit della varietà non distruttiva come quest'ultima.

L'iniezione di Javascript nelle sue varie forme può usare un codice di prova semplice come alert("exploited you"); piuttosto che un codice di exploit genuino.

Can a pentest be really done if the pentest team has the limitation that data cannot be created nor modified?

Direi di no. Come mostreresti una prova del concetto di XSS memorizzato senza poter archiviare il tuo XSS nel database? Questo sta invariabilmente andando a creare nuovi dati.

Ci sono numerosi esempi in cui un exploit richiede la scrittura di dati, anche se solo temporaneamente.

Should the pentesting company always include the disclaimer clause just in case?

Ancora una volta, sto estendendo la mia conoscenza personale qui, ma sto per dire di sì.

Tuttavia, in primo luogo, torna al punto di assumere una società di test delle penne. Il punto di un pen-test è identificare i rischi che potrebbero aver bisogno di essere valutati e risolti prima che i cattivi li trovino.

Spero anche che qualsiasi buon pentitore possa chiedere, e ogni buon affare avrebbe pensato, il ripristino di emergenza su una certa scala. Sicuramente dovresti avere un backup di qualche modulo sui tuoi sistemi in modo da poterlo ripristinare, se necessario. Ne hai bisogno non solo nel caso in cui il pentestuale ti distrugga i dati, ma nel caso in cui tu sia realmente infranto dai cattivi, nel qual caso potresti voler ripristinare un backup non contaminato.

Eseguo test di penetrazione abbastanza regolarmente sui miei siti.

La prima volta che ne ho eseguito uno ho fermato il sito e inondato il server di posta con spam.

Ho quindi twittato alcuni moduli, per eliminare lo spam e consentito identificare e correggere tutti gli altri buchi noti, senza interrompere il server.

Sono stato francamente stupito dalla devianza degli sfruttatori, ho dovuto tappare buchi che non avevo considerato.

Ma la cosa era che, prima di eseguire i test, pensavo che i miei siti fossero sicuri. Ho seguito le migliori pratiche, per quanto riguarda il design del sito web, ma c'erano ancora problemi.

Ora, con il senno di poi, apprezzo che il test possa avere conseguenze sul mio sito di produzione.

Quindi ho in programma.

Mi assicuro che venga eseguito il backup di tutto prima.

Se il sito è davvero, davvero critico, creerò un clone completo, quindi testerò prima quello clone.

Ho appreso dall'esperienza che se si crea il clone, crearlo su un altro server. Altrimenti, quando il clone si ferma, il server avrà comunque un impatto sull'ambiente di produzione.

Ma eseguo ancora i miei test. Come pensi che gli hacker abbiano accesso ai siti? Presumibilmente eseguono test come questi, in modo non autorizzato. Quindi finché il tuo sito non sarà protetto sarà sempre vulnerabile. È molto meglio fare i test prima, con le precauzioni (backup, ecc.) In atto, piuttosto che raccogliere i pezzi quando meno te lo aspetti.

Quindi, sì, è accettabile, ma è anche prevedibile e dovrebbe essere gestito di conseguenza.

La risposta al tuo titolo è "Sì" e il cliente deve saperlo!

Questo disclaimer non è un caso di CYA, è invece un'informazione vitale di cui il cliente ha bisogno per prepararsi al pentimento. Io non sono un tester di penna, ma IMO questo non dovrebbe essere sepolto nell'ultima pagina della stampa fine, ma dovrebbe essere sulla pagina 1 del contratto, davanti e al centro e in un grande carattere grassetto. L'azienda cliente deve prepararsi affinché le cose vadano storte - i backup devono essere fatti, i piani di recupero creati e posti in essere, ecc. Lasciare che il cliente creda che un pen-test sia privo di rischi è irresponsabile. Si sta tentando, per definizione, di attivare un comportamento scorretto, senza alcun controllo sulla misura in cui il comportamento interrotto si estende o si fa.

Le risposte alle 3 domande nel corpo del tuo post sono: (1) no, non puoi dare alcuna garanzia sul codice degli altri (2) una forma limitata di test delle penne potrebbe essere fatta senza modificare o creare INTENZIONALMENTE (se escludi qualsiasi registrazione che l'app potrebbe fare) ma i risultati non sarebbero completi, e infine (3) dovresti SEMPRE includere questo disclaimer - tanto per i clienti che ne beneficiano.

Il tester sta fondamentalmente cercando un difetto da sfruttare e non può in alcun modo garantire che non troverà un difetto che danneggia. Considera una tipica dichiarazione di non responsabilità del software per qualcosa che NON è destinato a incontrare o creare difetti, e quindi prendere in considerazione che probabilmente non hai scritto il codice che stai testando ...

Probabilmente puoi assicurarlo solo in determinate condizioni. Ovviamente Pentest è un compromesso tra molti fattori, alcuni fattori sono direttamente antagonisti alla disponibilità del sistema e uno di questi è la profondità della tua analisi. Alcune persone potrebbero obiettare che un pentito senza sfruttamento non è un pentimento.

In passato ho dovuto pentestire alcuni sistemi SCADA che sono abbastanza famosi per la loro fragilità e posso assicurarvi che è possibile accordare la maggior parte degli strumenti per essere abbastanza delicati. Ad esempio, disabilitare l'impronta digitale NMAP e aumentare il ritardo tra i pacchetti è stato di grande aiuto.

Comunque per rispondere alla tua domanda, personalmente, MAI accetto di mettere una clausola per garantirlo ad un mio cliente. Gli darò la mia parola, ma per quanto riguarda gli affari non puoi essere responsabile se la loro applicazione si interrompe da sola durante il tuo pentimento.

"Can a skilled and professional pentester always assure that no data will be deleted or modified in production during a pentest?"

No.

"Can a pentest really be done if the pentest team has the limitation that data cannot be created nor modified?"

Non pensare così ..

"Should the pentesting company always include the disclaimer clause just in case?"

Un accordo interno sembrerà molto diverso da un accordo con terze parti. Non conosco nessuna società di pen-test che non abbia limitazioni di assicurazione di responsabilità civile, tra le altre protezioni ...

I test di penetrazione dovrebbero seguire una metodologia in cui i test che possono causare danni sono fatti solo in scenari non di produzione, come un ambiente di staging o di laboratorio.

Il vero problema non è la cancellazione o la modifica dei dati perché i tester possono lasciare questi casi di test a sistemi non di produzione. Il vero problema è lasciare nuovi dati, come registri degli errori o file errati superflui che rivelano informazioni riservate, o persino l'esistenza del pentest stesso, incluso il materiale dei dati sul lato client del penetration tester.

Un altro problema prevalente nei test di penetrazione è la rivelazione di altri dati della clientela, email di lavoro o segnalibri del browser durante demo o screencast.