Un hacker può cancellare i miei file server e il database dove sto usando la funzione di sotto?

Question

Un hacker può cancellare i miei file server e il database dove sto usando la funzione di sotto?

#1 da (6 voti)
#2 da (2 voti)

2

Voglio sapere come proteggere il mio sito web dagli hacker. Sono uno sviluppatore di php-mysql. Per il recupero dei dati dai database uso sempre MySQLi. Per impedire il mio sito Web dall'iniezione SQL, utilizzo sempre la funzione $db->real_esacpe_string() di PHP. Per impedire il mio sito web da XSS (cross-site scripting), ho usato questa funzione:

function parsing($text)
{
global $db;
        $text=$db->real_escape_string($text);
 $text= @trim($text);
       $text= strip_tags($text);
 if(get_magic_quotes_gpc()) {
            $text= stripslashes($text);
        }
    $text=str_replace('<','',$text);
    $text=str_replace('>','',$text);   
       $text=htmlspecialchars($text, ENT_QUOTES, 'UTF-8');
    return($text);
}
$name=parsing($_POST['name']);

Qualsiasi suggerimento da parte tua è ben accetto. Grazie in anticipo.

php mysql webserver xss

posta Dinesh Gurjar 24.12.2018 - 14:10

fonte

2 risposte

Leggi altre domande sui tag php mysql webserver xss

Query DNS con stringa esadecimale che è SHA1 di un nome di dominio! È un malware? autorità di certificazione rsa

score 6 · Answer 1

Per essere terribilmente onesto, questa funzione è solo una raccolta arbitraria di procedure più o meno inutili o dannose e talvolta persino contraddittorie, la maggior parte delle quali non ha nulla a che fare con la sicurezza. Ora per la parte più importante.

SQL Injection

For prevent my website from sql injection i always use $db->real_esacpe_string()

Che cosa stai sbagliando? Non sei solo però, lo elenco come la illusione più infame del PHP . Citando da quella pagina:

this function has absolutely nothing to do with safety or injections, merely escaping special characters in SQL string literals, making them immune to SQL injection as a side effect, but being utterly useless for any other query part, from a table name to a numeric literal. To protect from SQL injection, one should follow two simple rules:

Any variable data literal (i.e. a string or a number) should be substituted with a parameter, whereas actual value should be sent to the query separately, through bind/execute process.

All other query parts that happen to be added through a variable, should be explicitly filtered through a hardcoded list of allowed values.

Dato il mysqli non elaborato è piuttosto difficile con le istruzioni preparate, suggerirei di utilizzare il PDO.

Quindi l'idea principale che nulla di correlato alla sicurezza SQL dovrebbe essere in tale funzione.

XSS

Vediamo cosa stai facendo con% dannoso < e > caratteri:

prima, tutti i tag vengono rimossi da strip_tags($text);
quindi questi simboli (già estinti dal testo) vengono sostituiti con una stringa vuota
finalmente quei personaggi inesistenti vengono convertiti in entità HTML

Se mi chiedi di definire "overkill" ti mostrerò semplicemente questa funzione. htmlspecialchars() da solo dovrebbe essere sufficiente per prevenire l'XSS nel corpo della pagina.

Ciò che è più importante, sembra che tu stia usando questa funzione sull'input di dati che è sbagliato. Un testo deve essere formattato subito prima dell'output, in base alle regole di formattazione per il determinato supporto. Se stai eseguendo l'output nel corpo della pagina HTML, sarebbe htmlspecialchars . Il testo va in JavaScript, quindi dovrebbe essere un'altra formattazione e così via.

Materiale inutile

trim() non ha nulla a che fare con la sicurezza, è possibile utilizzare questa funzione per comodità.
- su una nota a margine, non utilizzare mai nemmeno questo operatore @ . È dannoso per la tua esperienza di programmazione.
stripslashes() pure, non ha nulla a che fare con la sicurezza. Inoltre, questa funzione è solo inutile, non fa mai nulla di sensato.
Per non parlare del fatto che get_magic_quotes_gpc() è due volte inutile, restituendo un valore che è stato rimosso da PHP 10 anni fa.

Conclusione

sbarazzarsi di questa funzione
per evitare che SQL injection segua 2 regole dall'alto
per impedire che XSS utilizzi htmlspecialchars durante l'output dei dati o qualsiasi altra formattazione appropriata.

score 2 · Answer 2

La risposta di @YourCommonSense è buona, ma per aggiungerne un po ': SQLi e XSS non sono le uniche minacce alla sicurezza webapp importanti! In effetti, ce ne sono alcuni che metterei ben al di sopra di quelli, come comando di iniezione (un rischio se il tuo server esegue comandi, specialmente in una shell, contenente l'input fornito dall'utente) o altri modi potenzialmente ottenere un'esecuzione arbitraria del codice (caricamento e esecuzione di file eseguibili, attacchi di deserializzazione, ecc.). Questi tipi di attacchi hanno più probabilità di consentire a qualcuno di eliminare file server rispetto a XSS o SQLi, comunque.

Senza saperne di più su ciò che fa il tuo sito e il suo modello di sicurezza, non posso produrre un elenco corretto di vulnerabilità di sicurezza a cui sei esposto, ma garantisco che è più di XSS e SQLi. Ad esempio, CSRF è quasi certamente un rischio. C'è un mucchio di modi per fare l'autenticazione e la gestione delle sessioni sbagliate. Caricamenti di file di qualsiasi tipo sono un potenziale rischio. L'elaborazione dell'XML è un rischio. Fare la crittografia è molto difficile da ottenere. Il clickjacking è un rischio. Questo non è un elenco esaustivo, con qualsiasi mezzo, ma si spera che tu abbia l'idea.

OWASP è un posto decente dove andare per saperne di più sull'incredibile varietà di modi in cui un'applicazione web non è sicura.