Come difendersi dalle aggressioni di maleintenzionati che trovano il modo di scivolare furtivamente in DB altrui e potenzialmente possono fare danni alle nostre WEB APP: tips & tricks

Attenzione alla sicurezza delle nostre web app!

All’ indirizzo http://umbriawayformazione.altervista.org/php_project_earthquake/ abbiamo una bellissima applicazione che non nasconde volutamente nè utenti nè codici iban e neanche numeri di carta di credito. Il primo suggerimento che viene in mente è quello di usare la CLASSE PDO per la connessione ai dati, per dirne subito una che farà cadere dal seggiolone il potenziale attaccante. Ok sono de coccio e quando l’aggressore scriverà nei nostri campi testo qualcosa come:

“‘1’ OR ‘1’ = ‘1’”
$_POST[“nominativo”]= 1 ‘OR’ 1 ‘=’ 1
$_POST[“password”]= 1 ‘OR’ 1 ‘=’ 1

che servono per cercare di estrapolare nomi utenti e pwd per esempio aggirando il problema delle stringhe, con PDO ho la certezza che questo problemi non si verifichino? Niente paura se non ti fidi del vaccino puoi sempre lavare il campo di ricerca che arriva al DB. Come fare questa operazione?

Ipotizziamo di avere la nostra bella pagina come http://umbriawayformazione.altervista.org/php_project_earthquake/ dove l’attaccante si lecca i baffi per fare la sua operazione criminale SQL INJECTON. Bene, che faccio io sulla parte dinamica che deve recuperare i dati? Vediamo in dettaglio:

	if(isset($_GET['search'])){
	$camporipulito = ($_GET['user_query']);
  $camporipulito = clean($camporipulito);

	if($camporipulito==''){
	echo "<center><b>Please go back, and write something in the search box!</b></center>";
	exit();
	}

A quel punto nella query quando farò la mia SELECT mi basterà inserire:

like '%$camporipulito%'"

Ok ma questa funzionalità CLEAN da dove salta fuori cioé la PULIZIA del campo?

In testa alla pagina abbiamo inserito un

<?php require_once 'include/funzioni.php' ?>

che contiene le istruzioni:

<?php
function clean($input) {
  // Trims whitespace from input
  $input = trim($input);
  // Removes slashes from input data
  $input = stripslashes($input);
  //$input = htmlspecialchars($input);
  $input = strip_tags($input);
  // Escapes html characters from input data
  $input = htmlspecialchars($input);
  //problema apostrofo
  $input = addslashes($input);
  //caratteri speciali
  $input= mysql_real_escape_string($input);
  return $input;
}
?>

$input funziona da segnaposto e viene sostituito dalla nostra variabile $camporipulito impostata per recuperare i dati della parte statica del modulo!

Conclusioni:

Massima allerta quando ci sono moduli nelle nostre applicazioni web, che non sono altro che porte di ingresso e in stile canadese (senza chiave) che invitano malintenzionati a impossessarsi dei nostri dati riservati! Fortunatamente ci vengono offerte delle serrature per proteggerci, usiamole!

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo di WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione /  Modifica )

Google photo

Stai commentando usando il tuo account Google. Chiudi sessione /  Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione /  Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione /  Modifica )

Connessione a %s...

Blog su WordPress.com.

Su ↑

<span>%d</span> blogger hanno fatto clic su Mi Piace per questo: