Recherche…


Introduction

Rappelez-vous que CodeIgniter est un framework de développement. Il ne cherche pas à sécuriser votre application. Cela vous donne simplement les outils pour le faire vous-même. Si vous consultez la page Sécurité de CI, il est évident que le développeur doit comprendre la sécurité des applications et l'intégrer à son application.

Si la sécurité WebApp est relativement nouvelle pour vous, je commencerais par OWASP. Il serait peut-être avantageux d’examiner d’autres frameworks tels que Zend ou Cake qui, je crois, font plus d’avant-garde.

Syntaxe

  • $ freshdata = $ this-> security-> xss_clean ($ user_input_data);

Paramètres

tableau de saisie utilisateur blanc
insérer un tableau de saisie utilisateur dans xss_filter($array of user input) Blanc

Prévention XSS

XSS signifie un script intersite. CodeIgniter est fourni avec la sécurité de filtrage XSS. Ce filtre empêchera tout code JavaScript malveillant ou tout autre code qui tente de pirater des cookies et de mener des activités malveillantes. Pour filtrer les données via le filtre XSS, utilisez la méthode xss_clean () comme indiqué ci-dessous.

$data = $this->security->xss_clean($data);

Vous ne devez utiliser cette fonction que lorsque vous soumettez des données. Le deuxième paramètre booléen facultatif peut également être utilisé pour vérifier le fichier image pour une attaque XSS. Ceci est utile pour la fonctionnalité de téléchargement de fichiers. Si sa valeur est vraie, cela signifie que l'image est sûre et non différente.

Prévention d'injection SQL

L'injection SQL est une attaque effectuée sur la requête de base de données. En PHP, nous utilisons la fonction mysql_real_escape_string () pour empêcher cela avec d'autres techniques, mais CodeIgniter fournit des fonctions et des bibliothèques intégrées pour empêcher cela.

Nous pouvons empêcher l'injection SQL dans CodeIgniter des trois manières suivantes -

  • Échapper à des requêtes
  • Query Biding
  • Classe d'enregistrement actif

Échapper à des requêtes

<?php
   $username = $this->input->post('username');
   $query = 'SELECT * FROM subscribers_tbl WHERE user_name = '.
   $this->db->escape($email);
   $this->db->query($query);
?>

$this->db->escape() ajoute automatiquement des guillemets simples autour des données et détermine le type de données afin qu'il ne puisse échapper que des données de chaîne.

Query Biding

<?php
   $sql = "SELECT * FROM some_table WHERE id = ? AND status = ? AND author = ?";
   $this->db->query($sql, array(3, 'live', 'Rick'));
?>

Dans l'exemple ci-dessus, le point d'interrogation (?) Sera remplacé par le tableau dans le deuxième paramètre de la fonction query() . Le principal avantage de la construction de requêtes de cette manière est que les valeurs sont automatiquement échappées, ce qui produit des requêtes sécurisées. Le moteur CodeIgniter le fait automatiquement pour vous, vous n'avez donc pas à vous en souvenir.

Classe d'enregistrement actif

<?php
   $this->db->get_where('subscribers_tbl',array('status'=> active','email' => '[email protected]'));
?>

À l'aide des enregistrements actifs, la syntaxe de requête est générée par chaque adaptateur de base de données. Il permet également des requêtes plus sûres, car les valeurs s'échappent automatiquement.

Cacher les erreurs PHP

Dans l'environnement de production, nous ne souhaitons souvent pas afficher de message d'erreur aux utilisateurs. C'est bien s'il est activé dans l'environnement de développement à des fins de débogage. Ces messages d'erreur peuvent contenir des informations que nous ne devons pas montrer aux utilisateurs du site pour des raisons de sécurité.

Il existe trois fichiers CodeIgniter liés à des erreurs. Niveau de rapport d'erreur PHP

Un environnement différent nécessite différents niveaux de rapport d'erreurs. Par défaut, le développement affichera des erreurs, mais les tests et le live les cacheront. Il y a un fichier appelé index.php dans le répertoire racine de CodeIgniter, qui est utilisé à cette fin. Si nous transmettons zéro comme argument à la fonction error_reporting (), cela masquera toutes les erreurs.

Prévention CSRF

CSRF est synonyme de falsification de requêtes intersites. Vous pouvez empêcher cette attaque en activant une option dans le fichier application / config / config.php, comme indiqué ci-dessous.

$config['csrf_protection'] = TRUE;

Lorsque vous créez un formulaire à l'aide de la fonction form_open() , il insère automatiquement un jeton CSRF dans un champ masqué. Vous pouvez également ajouter manuellement le jeton CSRF à l'aide de la fonction get_csrf_token_name() et get_csrf_hash() . Comme leur nom l'indique, la fonction get_csrf_token_name() retournera le nom du jeton CSRF, tandis que get_csrf_hash() renverra le hachage.

Le jeton CSRF peut être régénéré à chaque fois pour soumission ou vous pouvez également le conserver pendant toute la durée de vie du cookie CSRF. La définition de l'option de configuration 'csrf_regenerate' force la régénération du jeton comme indiqué ci-dessous.

$config['csrf_regenerate'] = TRUE;

Vous pouvez inclure les URL de la protection CSRF dans la liste blanche en définissant des correspondances dans le tableau de configuration à l'aide de la clé 'csrf_exclude_uris', comme indiqué ci-dessous. Vous pouvez également utiliser des expressions régulières.

$config['csrf_exclude_uris'] = array('api/person/add');

Supprimer les données d'abus de la saisie de l'utilisateur

// XSS Filtering
$data = array(
             'name'=> '<script>Abuse Data</script>'
        );
$data = $this->security->xss_clean($data); // Clean Data

// Escaping Queries
<?php $username = $this->input->post('username'); $query = 'SELECT * FROM subscribers_tbl WHERE user_name = '. $this->db->escape($email); $this->db->query($query); ?>

Prévention XSS sur entrée utilisateur

Ne comptez sur aucune entrée utilisateur. entrée utilisateur tout comme la <script> ou toute alert(); javascript alert(); nous devons donc éviter que toutes les données ne soient pas exécutées dans notre navigateur. Nous devons donc utiliser la méthode de prévention xss pour restreindre nos données sécurisées à celles conservées par les pirates, ainsi que la responsabilité du développeur quant à la validation des entrées de l'utilisateur et à la résolution des erreurs par programmation.

vérifiez donc que ceci est un exemple de prévention xss dans CodeIgniter.

$data = array(
            'name' => "<script>alert('abc')</script>",
            'email' => "[email protected]"
        );
var_dump($data);
// Print array without xss cleaning/xss filtering

array(2) { ["name"]=> string(29) "" ["email"]=> string(19) "[email protected]" } // Result with alert

// now print data after xss filtering

$data = $this->security->xss_clean($data);
var_dump($data);

//Print array without xss cleaning/xss filtering
array(2) { ["name"]=> string(38) "[removed]alert('abc')[removed]" ["email"]=> string(19) "[email protected]" } // Result Without alert

Ainsi, après avoir ajouté xss_filtering, nous n'avons aucun problème pour exécuter un code d'abus saisi par l'utilisateur. et CodeIgniter remplacent cette balise d’abus par le mot clé [removed] .



Modified text is an extract of the original Stack Overflow Documentation
Sous licence CC BY-SA 3.0
Non affilié à Stack Overflow