Printable View
Cercando per la rete, uno script in PHP da mettere per la segnalazione di bug in generale, quindi qualsiasi tipo, non ho trovato niente, quindi purtroppo ho dovuto realizzarne uno, molto semplice molto basic.
a voi il codice e lo script completo in download qui sotto! :top:
http://italiancafe.altervista.org/No...hp?viewpaste=7
Invece il Download Qui sotto:
https://mega.nz/file/B81ynTpb#IF757g...oZNUNCRHNjb1Q4
un parere?
La parte PHP complessivamente occupa circa il 2% del file che hai proposto, più che altro è un foglio di stile CSS.
Lo script, benché breve, ha comunque dei problemi:
- inizializzi la variabile $host senza mai utilizzarla, può essere rimossa
- la guardia dell'if controlla direttamente i valori dei parametri cercando di sfruttare le conversioni implicite: questo genera dei warning se le chiavi a cui accedi non sono definite: meglio utilizzare isset o empty
- i corpi degli if non sono indentati
- i nomi degli identificatori non sono significativi, e non riflettono i nomi dei parametri
- i nomi dei parametri pure sono poco chiari, per esempio cos'è "report1"? Esistono "report2", "report3", ecc?
- nessun controllo di sicurezza sui parametri, il codice è vulnerabile a script injection di qualsiasi tipo
- in caso di pagina esistente utilizzi die, bloccando l'esecuzione dell'intero script: in questo modo il restante codice HTML non viene inviato al client, che riceve una pagina incompleta, dovresti mostrare un messaggio d'errore senza compromettere l'integrità della pagina
- il codice attuale non permette di segnalare più di un bug per la stessa pagina, è un limite notevole
- nessun controllo sulla riuscita di fopen, potrebbe fallire per qualsiasi motivo (problema di permessi, nome del file non valido...)
- tramite fwrite scrivi del contenuto HTML: dovresti separare il contenuto dalla forma, scrivendo solo le informazioni necessarie in un formato strutturato come JSON XML o, probabilmente più adatto in questo caso, SQL
- nessun controllo sulla riuscita di fwrite, la quale potrebbe fallire o scrivere solo parte del contenuto
Ultimo, e probabilmente più complesso, è il problema delle race condition. Con il codice attuale, se due o più utenti cercano di sottomettere un bug relativo alla stessa pagina il comportamento risulta indefinito.
Nel caso migliore uno completerà l'operazione di scrittura prima che gli altri cerchino di accedere all'if.
Tuttavia è anche possibile che tutti i client, simultaneamente, accedano all'if: poiché nessuno ha ancora creato il file, nessuno riceverà messaggi d'errore, e tutti procederanno alla scrittura, sovrascrivendosi a vicenda. Per quanto improbabile, resta una vulnerabilità. Andrebbero usati meccanismi di lock e semafori, ma probabilmente è più semplice usare semplicemente SQL.
Bel progetto:)
Inoltre aggiungo, ogni cosa dovrà essere filtrata con una while list.
La variabili da fonte esterne, non sempre sono come il programmatore le pensa. È buona norma inizializzare le variabili da involucro nel tipo scelto dal programmatore. register_globals deprecated php 5.3 e Magic Quotes deprecated php 5.3.
le variabili esterne nel mio script possono essere di tipo stringa? Se siEcco spiegati Varisbles External e null bytes le funzioni del manuale di php con la dicitura binary safe, non hanno problemi con il null bytes.Codice PHP://sintassi multi creazione variabile
$key = $var1 = $var2 = '';
if(isset($_POST['key']) && is_string($_POST['key']) && strlen(($key = str_replace(chr(0), '', $_POST['key'])))) {
echo 'valido'; //solo se la stringa è maggiore 0 BYTE
} else {
echo 'non valido'; // se il contesto è di sicurezza,
// puoi anche non far capire al tuo attaccante
//che la tua applicazione lo valuta come errore.. non producendo output con messaggi di errore.
}
Ecco il motivo di while list (tipo esplicitamente voluto, e anche valore tra determinati caratteri). Poi ci sarebbe il discorso di aggiungere un header mysql e funzioni e anche se accettare solo url con caratteri equivalenti a US ASCII
Contesto speciale variabile esterna HTTP_HOST, il cliente potrebbe anche inviare la porta che per http il default è 80 o 443 in https, che non dovrà essere espressa.
Quindi nel contesto di sicurezza il codice potrebbe presentarsi in questo modoCodice PHP://sintassi multi creazione variabile
$key = $var1 = $var2 = $error '';
if!((isset($_POST['key']) && is_string($_POST['key']) && strlen(($key = str_replace(chr(0), '', $_POST['key'])))))
$error = 'user attack first variable'; // altrimenti l'espressione di $key è vera per definizione
Si ho letto, un pò di quello che avete scritto ragazzi, non avevo molto tempo quindi mi sono detto accetto le critiche rimbocchiamoci le maniche e vediamo di far uscire qualcosa di leggermente superiore al prodotto iniziale.
Ecco Qui Date un'occhiata(il codice):
http://italiancafe.altervista.org/No...hp?viewpaste=8
è attivo anche sul mio portale se volete testarlo:
https://internetcafe.altervista.org/Bug-Signaler.php
PS: la variabile $host non utilizzata, l'ho dimenticata per sbaglio c.c serviva per il redirect alla pagina appena creata ,ma poi non è servita, Rispetto alla vulnerabilità alle SQL injection non è vulnerabile perchè non si appoggia a MYSQl è un "FLAT" , cmq ho aggiunto dei controlli di sicurezza,rivista la formattazione etc etc..
vabbè date un'occhiata al codice aggiornato , aspetto qualche risposta grazie!:top:
No, prima devi per forza verificare l'esistenza con isset e poi il tipo di una variabile che proviene da fonte esterna.. boh sembra semplice il codice che ti ho espresso, no?
Non ti sto rimproverando, ma vige una regola non può essere quasi giusto (se è sbagliato almeno un po', il codice è tutto sbagliato).
Anche se passi $_POST['non_esisto'] e php gli assegna il valore NULL di default, questa funzione htmlspecialchars accetta razionalmente una stringa che sia almeno un carattere (o anche stringa vuota, che per me è un errore ma ben voluta da molti coder). Che poi comunque per essere coerente tra versioni php dovrà essere specificato il suo parametro encoding. È scritto qui su header mysql funzioni http://forum.it.altervista.org/php-m...ml#post1474228
Se poi ritieni che php non ti da errore ed è giusto.. ti apro le braccia per un un'abbraccio :D
ho capito cosa intendi, dimmi se sbaglio:
implementare per ogni variabile un controllo unico e diverso dalle altre secondo le esigenze di ciò che viene inserito dall'utente in quello specifico campo, ma io ho preferito generalizzare e velocizzare con htmlentities(); e poi se hai visto ho aggiunto il controllo sulle variabili con empty();
E se ti passano un array invece di una stringa, cosa ti dice htmlspecialchars? :)
sicuramente sarebbero meno righe di codice , per il resto non lo sò.
Nessuno ha mai parlato di SQL injection infatti, ma di script injection. Te ne ho creato un esempio qui.Citazione:
Rispetto alla vulnerabilità alle SQL injection non è vulnerabile [...]
Ho anche usato una null byte injenction per dimostrare la mancanza dei controlli su fopen e fwrite, basta lanciare questa cURL:
la pagina restituita riportaCodice:curl -X POST https://internetcafe.altervista.org/Bug-Signaler.php -d"sitebugged=a&urlvuln=b&type=c&report1=d&page=%00"
ma in realtà non viene creata alcuna pagina, tant'è che la stessa chiamata può essere eseguita più volte. Questo accade perché il valore restituito da fopen non viene controllato prima di essere usato.Codice:<a href='.bug.html'>Published!</a>
A parte la rimozione di $host e l'uso di empty, direi che tutti gli altri problemi segnalati prima restano, benché adesso ci sia un minimo di controllo sull'input.
Questo di per se non è sbagliato, solo sconveniente. Sarebbe molto più facile e veloce appoggiarsi a SQL senza doversi ricreare a mano le funzionalità che questo offre. Tieni conto che stai esponendo il file system del tuo sito a scritture [quasi] arbitrarie dall'esterno, è solo questione di tempo prima che qualcuno trovi il modo di sovrascrivere le pagine del sito.Citazione:
[...] perchè non si appoggia a MYSQl è un "FLAT"
Io la vedo come una semplice XSS, in una Pagina in HTML niente di più, non credo sia una grave falla ragazzi o boh:roll: , al massimo uno ci piazza uno script in JS per fare un pò di phishing con l'indirizzo del sito, ma non è il mio caso.
Da php 8.0.0 se il parametro non è lo dello stesso tipo della funzione genera errore fatale. https://3v4l.org/a0vjq
Il discorso velocità può essere contemplato solo se privo di difetti, altrimenti meglio buono e lento che un buco della sicurezza.
Ecco gli ingegneri che si preoccupano solo della velocità cosa creano. Directory trasversal https://www.acunetix.com/websitesecu...hp-security-2/ .. anche url con percent enconding
XSS è un caso particolare dello script injection segnalato.
Cosa considerare "grave" dipende da te, personalmente non sarei felice di avere questo tipo di problemi nel mio sito :=):.
Poi ci sarebbero anche questioni "ingegneristiche" se intendi pubblicare lo script, ma se intendi usarlo solo sul tuo sito non si pongono.
vi ringrazio cmq per i consigli e gli accorgimenti, spero in futuro quando pubblicherò qualcosa, di avere vostre critiche, per migliorare :|