Programmation sécurisée PHP – quelques principes de conception de sécurité de sites Web

Le contenu principal de cet article concerne certains principes de conception de sécurité de sites Web dans la programmation de sécurité PHP. Je vais maintenant le partager avec vous. Les amis intéressés peuvent y jeter un œil

.

Défense en profondeur

Le principe de défense en profondeur est un principe bien connu des professionnels de la sécurité. Il illustre l'intérêt des mesures de sécurité redondantes, qui a fait ses preuves. par l'histoire.

Le principe de défense en profondeur peut être étendu à d'autres domaines, ne se limitant pas à la programmation. Les parachutistes qui ont utilisé des parachutes de secours peuvent attester de l'intérêt de disposer de mesures de sécurité redondantes, même s'il ne faut jamais vouloir que le parachute principal tombe en panne. Une mesure de sécurité redondante peut jouer un rôle important dans l’échec potentiel des mesures de sécurité primaires.

De retour dans le domaine de la programmation, adhérer au principe de défense en profondeur nécessite de toujours disposer d'un plan de secours. Si une mesure de sécurité échoue, une autre doit assurer une certaine protection. Par exemple, c'est une bonne pratique de réauthentifier les utilisateurs avant d'effectuer des opérations importantes, même s'il n'y a aucune faille connue dans votre logique d'authentification utilisateur. Si un utilisateur non authentifié prétend être un autre utilisateur d'une manière ou d'une autre, le fait de demander un mot de passe peut potentiellement empêcher l'utilisateur non authentifié (non vérifié) d'effectuer certaines opérations critiques.

Bien que la défense en profondeur soit un principe raisonnable, l'ajout excessif de mesures de sécurité ne peut qu'augmenter les coûts et réduire la valeur.

Moyen privilège

J'avais une voiture avec une clé de femme de chambre. Cette clé ne peut être utilisée que pour le contact, elle ne peut donc pas ouvrir les portes, la console ou le coffre. Elle ne peut être utilisée que pour démarrer la voiture. Je peux la remettre au gardien du parking (ou la laisser sur le contact), et je confirme que la clé ne peut pas être utilisée à d'autres fins.

Il est logique de donner au préposé au stationnement une clé qui n'ouvrira pas la console ou le coffre, après tout, vous voudrez peut-être garder des objets de valeur à ces endroits. Mais ce qui n'a pas de sens pour moi, c'est pourquoi il ne peut pas ouvrir la porte. Bien sûr, c’est parce que mon propos porte sur la révocation de l’autorité. Je me demandais pourquoi le préposé au stationnement avait été déchu de son pouvoir d'ouvrir la porte. En programmation, c'est une très mauvaise idée. Au lieu de cela, vous devez réfléchir aux autorisations nécessaires et accorder à chaque personne uniquement les autorisations minimales nécessaires pour faire son travail.

L'une des raisons pour lesquelles la clé de femme de chambre ne peut pas ouvrir la portière de la voiture est que la clé peut être copiée et que la clé copiée peut être utilisée pour voler la voiture à l'avenir. Ce scénario semble peu probable, mais c'est un exemple de la façon dont une autorisation inutile peut augmenter votre risque, même par une légère augmentation des autorisations. La minimisation des risques est un élément majeur du développement d’un programme de sécurité.

Vous n'avez pas besoin de penser à toutes les façons dont une autorisation peut être utilisée de manière abusive. En fait, il est presque impossible de prédire les actions de chaque attaquant potentiel.

La simplicité est belle

La complexité engendre des erreurs, et les erreurs peuvent conduire à des failles de sécurité. Ce simple fait illustre pourquoi la simplicité est si importante pour une application sécurisée. Une complexité inutile est tout aussi néfaste qu’un risque inutile.

Par exemple, le code suivant est extrait d'un récent avis de vulnérabilité de sécurité :

<?php
	 
	$search = (isset($_GET[&#39;search&#39;]) ? $_GET[&#39;search&#39;] : &#39;&#39;);
 
?>

Ce processus peut confondre le fait que la variable $search est entachée*, en particulier pour les développeurs inexpérimentés ( Remarque : Une variable contaminée signifie que lors de l'exécution du programme, la valeur de la variable n'est pas directement spécifiée par l'instruction d'affectation, mais provient d'autres sources, telles qu'une entrée de console, une base de données, etc.). L'instruction ci-dessus est équivalente au programme suivant :

<?php
 
  $search = &#39;&#39;;
 
  if (isset($_GET[&#39;search&#39;]))
  {
		$search = $_GET[&#39;search&#39;];
  }
 
?>

Les deux flux de traitement ci-dessus sont exactement les mêmes. Veuillez maintenant faire attention à l'instruction suivante :

$search = $_GET['search'];

L'utilisation de cette instruction garantit que l'état de la variable $search reste intact sans affecter le processus, et on peut également voir si elle est contaminée.

Exposition minimisée

Les applications PHP nécessitent une communication fréquente entre PHP et des sources de données externes. Les principales sources de données externes sont les navigateurs clients et les bases de données. Si vous suivez correctement les données, vous pouvez déterminer quelles données ont été exposées. Internet est la principale source d'exposition car il s'agit d'un réseau très public et vous devez toujours faire attention à éviter que vos données ne soient exposées sur Internet.

L'exposition des données ne signifie pas nécessairement un risque pour la sécurité. Cependant, l’exposition des données doit être minimisée autant que possible. Par exemple, lorsqu'un utilisateur entre dans un système de paiement et transmet les données de sa carte de crédit à votre serveur, vous devez utiliser SSL pour le protéger. Si vous souhaitez afficher son numéro de carte bancaire sur une page de confirmation, puisque les informations du numéro de carte sont envoyées du serveur à son client, vous devez également utiliser SSL pour le protéger.

Par exemple, dans l'exemple précédent, afficher le numéro de carte de crédit augmente évidemment les risques d'exposition. SSL réduit le risque, mais la meilleure solution consiste à éliminer complètement le risque en affichant uniquement les quatre derniers chiffres.

Pour réduire l'exposition aux données sensibles, vous devez identifier les données sensibles, les suivre et éliminer toute exposition de données inutile. Dans ce livre, je vais vous montrer quelques techniques pour vous aider à protéger de nombreux types courants de données sensibles.

Recommandations associées :

Attaques et solutions de sécurité PHP courantes

Explication détaillée des exemples de sécurité PHP

Explication détaillée de la bibliothèque de développement de sécurité PHP

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!