Comment écrire un logiciel sécurisé pour le web

Comment écrire un logiciel sécurisé pour le web

la sécurité des applications Web est critique. Des failles de sécurité dans les applications Web que vous écrivez peut entraîner votre site d'être défigurés, qui ne est que très embarrassant. Il pourrait entraîner dans les informations de votre utilisateur étant volé, ce qui est gênant et puis pourraient vous atterrir dans l'eau chaude légal dans votre juridiction. Ou il pourrait en résulter dans votre hôte utilisé pour faire du spam, des attaques par déni de service, ou de propager des logiciels malveillants, qui fait de l'Internet un pire endroit pour tout le monde distribué. Quelques étapes simples, et le bon état d'esprit, peuvent réduire le risque que cela se produise en raison des applications que vous avez écrites.

Les Étapes

1
Éviter les injections SQL. Injections SQL sont peut-être la façon la plus courante dans lequel le logiciel Web est compromise aujourd'hui. L'exemple de Wikipedia suit. Considérons la ligne de pseudo-code suivant.

déclaration: = "SELECT * FROM userinfo WHERE id =" + a_variable + "-"

Cela fonctionne très bien si "a_variable" on peut faire confiance. Cependant, si ce est une variable fournie par l'utilisateur, un attaquant pourrait fournir ceci:

1-DROP TABLE users

Ce qui aboutirait à cette requête en cours d'exécution:

SELECT * FROM userinfo WHERE id = 1-DROP TABLE utilisateurs-

Ce qui est évidemment une chose terrible d'avoir. La solution consiste à désinfecter toutes les variables fournies par l'utilisateur, religieusement. PHP a le mysql_real_escape_string fonction pour MySQL. Autres bibliothèques de base de données pour d'autres programmes ont la même chose. Utilise les, et vous serez beaucoup plus sûr. Il ya aussi des cartographes objet-relationnel (comme Django pour Python) qui vous évitent d'avoir à écrire du code SQL du tout, et prendre soin de protéger les chaînes avant de les transmettre à vos database- envisager d'utiliser l'un de ces.
2
Ne ouvrez jamais un nom de fichier basé sur un paramètre que l'Utilisateur fournitures. Par exemple, si vous affichez un fichier à un utilisateur, vous pourriez être tenté d'avoir une URL comme display.php? file = something.txt, et dans votre code PHP utiliser ceci:

require ("/ www / awesomeapp / fichiers texte /" $ _GET ["file"].) -

Ce est extrêmement dangereux, car il leur permettra d'utiliser des séquences de "../" (les emmener au répertoire parent) d'inclure ne importe quel fichier sur le système de fichiers, par exemple en allant à display.php? file = .. / .. / .. / .. / .. / etc / passwd.

Au mieux, cela leur permettra de recueillir des informations sur la configuration de votre serveur, ce qui pourrait fournir des informations utiles pour une attaque différente. Au pire, si PHP de exiger ou bien inclure fonctions (ou un équivalent dans votre langue) sont utilisées pour inclure le contenu du fichier, il peut permettre l'exécution de code (en manipulant la tête User-Agent puis y compris le fichier / Proc / self / environ).

La solution à cela est de trouver soit une autre façon d'inclure le fichier qui ne le fait pas en fonction des commentaires des utilisateurs, ou bien désinfecter soigneusement le nom de fichier fourni. Vérifiez chaque caractère de la validité, et jeter tout ceux interdits selon le principe que les caractères qui ne sont pas autorisés sont interdits, et puis ne pas en retirant simplement les nuisibles. En d'autres termes, ne pas essayer de remplacer les mauvaises caractères dans une chaîne. Faites une liste de ceux qui sont explicitement autorisés et scannent la chaîne pour ceux qui, en supprimant tout ce qui ne est pas dans la liste des celles autorisées. Ce est une) simple 2) défend contre les vecteurs d'attaque que vous ne aviez pas pensé.


3
Désinfectez toutes les données que vous écrivez à une page. Votre code pourrait accepter un paramètre appelé «personne» (c.-à- index.php? = Bob personne, et votre code devrait contenir quelque chose comme ceci:

Bonjour, ? lt;? php echo $ _GET ["personne"] ->



Cela permet à un attaquant d'écrire javascript arbitraire de la page, ce qui signifie que se ils convaincus que quelqu'un vous suffit de suivre un lien vers le site, ils pourraient les amener à provoquer une action avec un effet secondaire (par exemple, poster un commentaire, ou de soumettre toute autre forme). Remplacer tous les caractères connus-bad (guillemets, lt;, et puis gt avec leur entité HTML équivalent avant de l'écrire sur une page.

Beaucoup de moteurs de modèles feront automatiquement pour vous, et ne permettra caractères HTML dans une variable émis si elles sont explicitement déclarées sécurité. Vous pouvez envisager d'utiliser une.

Si vous avez besoin pour permettre à certains HTML limitée (par exemple, pour permettre la mise en forme de texte dans les commentaires), désinfecter tels HTML pour autoriser uniquement les balises connues pour être sûr et avoir des effets secondaires mineurs (tels que ), Rejeter tous les autres, et jetez les attributs HTML non désirées. Une fois de plus, le principe devrait être ne autoriser ce qui est explicitement permis, et dépouiller tout le reste. (Suite de ce principe aurait pu empêcher une vulnérabilité de WordPress notoire, où il aseptisé CSS dans un attribut "style", mais a laissé intact si le nom de l'attribut est en majuscules.)
4
Ne jamais passer une variable fournie par l'utilisateur à une coquille. Par exemple, vous pourriez avoir écrit un script pour envoyer un ping à un hôte donné. Il faudrait un paramètre appelé hôte (Par exemple, ping.php host = 127.0.0.1?), Et ainsi vous pourriez être tenté de le faire:

système ("ping" $ _GET ["host"].) -

Ce est extrêmement dangereux, parce que, par la fourniture d'un paramètre "host" avec un symbole de tuyau ou un point-virgule, il leur permet d'exécuter ne importe quelle commande sur votre système (par exemple, en donnant une foule de "127.0.0.1 | wget https://wikihow.com/»).

La solution est d'éviter d'utiliser la système fonction où possible- invoquer le programme externe d'une autre manière. pcntl_exec est une meilleure idée pour PHP. Si vous devez utiliser système, désinfecter soigneusement toutes les données fournies par l'utilisateur avant de passer à la coquille. (Un exemple pour notre "ping" scénario serait de vérifier chaque caractère pour se assurer qu'il était soit un chiffre, une lettre, ou de la période, et jeter tout caractère qui ne est rien d'autre.)
5
Utilisez les fonctions telles que PHP de eval très, très attentivement. Si la chaîne comprend une variable fournie par l'utilisateur, alors ce sera leur permettre d'exécuter du code arbitraire. En fait, il n'y a presque ne jamais une raison d'utiliser this- si vous vous trouvez à l'utiliser, votre code est probablement terrible et vous devriez repenser il.
6






Vérifiez le référent sur toutes les demandes HTTP POST qui ont des effets secondaires. Assurez-vous que le site se référant au site est votre cas contraire, il aurait pu tout simplement été un utilisateur qui a cliqué sur un bouton sur un formulaire sur un autre site internet. (Vous pouvez ou ne voulez pas de se assurer que le site de référence est non vide. Le parrain pourrait être vide si la page Web contrôlé par l'attaquant utilise le protocole HTTP sécurisé et le vôtre ne fait pas.). Un autre truc lorsque vous utilisez une forme génère un code unique, et de le stocker à la fois une variable de session et dans un champ caché sous la forme. Lors de la soumission, vérifier si la valeur du champ caché sont égales à celle de la variable de session.
7
Ne jamais laisser une requête HTTP GET pour avoir un effet secondaire. Par exemple, ne jamais écrire sur une base de données en utilisant les paramètres fournis dans une requête GET. Rappelez-vous que une requête GET pourrait être un utilisateur de votre site qui a été trompé en cliquant sur un lien.
8
Vérifiez les informations d'identification au tous les étape. Voici un exemple:

1. Les demandes des utilisateurs d'effectuer une certaine action.
2. Vous vérifiez pour voir se ils ont l'autorisation d'effectuer cette action, l'affichage d'une "permission denied" la page se ils ne le font pas.
3. Vous affichez une "Etes-vous sûr de vouloir faire cela?" la page avec l'action exprimée dans les champs de formulaire cachés.
4. Que la page affiche ensuite à un script qui effectue l'action.

L'astuce est, si vous ne vérifiez leur permission d'effectuer ces actions dans l'étape 2, mais pas au script en cours affecté à l'étape 4, cela compte sur eux de ne pas être en mesure de modifier la forme qui leur est donné à l'étape 3 (qui est grandement confiance mal placée), ou allant même à l'étape 4 directement.
9
Ne pas stocker les mots de passe en texte brut. Ce est une mesure d'atténuation au cas où votre site est compromise. Comme de nombreux utilisateurs de réutiliser des mots de passe, cela pourrait signifier que toute leur autre comptes en ligne se compromises. La contre-mesure standard pour cela est de stocker une hachage cryptographique (Par exemple en utilisant l'algorithme SHA-2) de la somme de quelques octets de données aléatoires en plus du mot de passe. Ainsi, il sera possible de vérifier si un mot de passe fourni est correct, sans mémoriser le mot de passe lui-même.

(Pour l'avenir épreuvage, il pourrait être une bonne idée de stocker le type d'algorithme utilisé ainsi, au cas où vous avez besoin de migrer vers un algorithme de hachage différent, devraient faiblesses graves se trouvent dans les actuels. Ce est arrivé à MD5 et SHA- 1, et peut encore arriver à des algorithmes de hachage les plus fiables d'aujourd'hui.)


10
Lorsque vous utilisez une base de données, ne pas stocker des informations base de données de connexion directement dans le dossier racine de votre application. Au lieu de cela, les stocker dans un dossier différent et ensuite, soit 1) refuser l'accès au dossier en utilisant les paramètres de votre serveur Web ou .htaccess 2) stocker le fichier en dehors de la racine du document. Puis inclure le Fichier- votre demande ne est pas affectée par les autorisations de votre serveur Web. Ceci empêchera les gens d'aller https://your-awesome-site.example.com/config.ini pour trouver votre base de données d'informations de connexion (mais il ne se arrêtera pas à un attaquant qui a trouvé une vulnérabilité inclusion de fichier comme dans l'étape 3, ou l'exécution d'un code shell exploit comme à l'étape 4).
11
Ne comptez pas sur le fichier robots.txt pour cacher les zones sensibles de votre site. Il ya parfois de bonnes raisons de le faire (par exemple, si votre tout site est sensible et que vous ne voulez pas indexé par les moteurs de recherche). Mais rappelez-vous que une des premières choses un attaquant mordicus à compromettre votre site va faire est de regarder votre fichier robots.txt pour voir ce que vous cachez. Une meilleure façon de le faire est d'utiliser un méta tag sur les pages que vous ne voulez pas être indexé (par exemple, vos pages d'arrière-administratives). Par exemple:

  • 12
    Entrez dans le bon état d'esprit. Cet article ne est pas destiné à être une liste exhaustive de tous les problèmes de sécurité qui pourraient affecter votre site, mais il donne quelques exemples du monde réel de l'application de certains principes importants:
    • Ne faites jamais confiance toute information qui peut être fournie par l'utilisateur. En Effet, supposons que l'utilisateur est un attaquant, et de traiter toutes les données fournies par l'utilisateur en conséquence.
    • Lorsque la désinfection données, ne autoriser ce qui est sûr, et dénuder autre chose. Ce défend contre la mauvaise entrée que vous n'avait pas pensé lorsque vous écriviez le code. Un exemple de ceci serait si vous avez développé votre logiciel sur et pour un système de type Unix, et défendu contre les vulnérabilités fichier-inclusion en supprimant toute barres obliques à partir d'un nom de fichier fourni. Cela fonctionnera OK, jusqu'à ce que quelqu'un déployé votre code sur une machine Windows (ce qui permettrait une barre oblique inverse comme séparateur de chemin).
    • Supposons que vous faites des erreurs, et appliquer le principe de défense en profondeur pour atténuer les effets. (Ce qui précède "permettent seulement ce qui est sans danger" est un cas particulier de la présente).
    • Supposons un attaquant potentiel sait tout ce que vous faites. Ce est à dire, écrire votre code comme si un attaquant potentiel était assis à côté de vous lire. Cette fois vous encourage à utiliser les bonnes pratiques à chaque étape du chemin, et puis atténue les effets de votre application se compromises. Ne pas écrire mauvais code de penser que personne ne verra jamais, ou comprendre à quel point il est. Et tandis que la sécurité par l'obscurité a sa place, ne comptez pas sur les secrets séjournant secrète et puis penser comme un attaquant.




    • » » Comment écrire un logiciel sécurisé pour le web