Sécurité d'application web au centre du développement

Version imprimable

Voir 40 message(s) de cette discussion en une page

05/11/2012, 14h50
redoran

Sécurité d'application web au centre du développement

Salut ; voila au bout certain moment j'ai terminé ma première application web avec l'appui des forumeurs. certes y'avait beaucoup d'insuffisances :aie:
je veux resté sur le plan sécurité:
application de type d’apprentissage qui tourne en locale,
pour la connexion j'utilise PDO,
accès sécurisé par user , mot de pass et captcha,
cryptage du mot de passe : aucun faute de choix de méthode ( MD5 ou autres..)
Mise a jour des données avec des requêtes préparées,
les pages du site sont géré de tel sorte une fausse URL renvoi vers la page d’authentification,

je sais que c'est pas suffisant contre les risques les plus sérieux et cela par ignorance , donc si je simule le risque d'attaque d'une application web par rapport a une pathologie (maladie ) vue mon domaine:
attaquant ==> vecteur/véhicule ==> brèche ==> organe cible.

je crois que la sécurité d'une application web doit être pensée avant le développement et afin de parvenir Comment peut on listé les risques?
06/11/2012, 11h02
redoran

Comment peut on listé les risques?
salut ; avant de répondre a cette question , je crois que la sécurité d'une application web touche l'humain , le matériel et le soft.
donc si je reste sur le soft et précisément l'application web:
- Le développeur prend en charge le coté sécurité de l'application ( code source)
- la formule : connaitre le risque = développez barrière
Connaitre le risque:
Une bonne lecture autour des risques liés aux vulnérabilités des applications web sur le net permet grandement d'avoir une vue d'ensemble sur les phénomènes d'attaques, et de ce développez un plan de sécurité.
partant de la frontière entre le net et l'application web (structure et contenu) , dans mon cas c'est :
1. adresse URL,
2. L'interface d’authentification porte d'entrée,
pour mois sa représente les deux entrés possible par l'attaquant.
mesures prises:
pour les gestion de l'URL : j'ai développé un petit code PHP de redirection vers la page authentification dans le cas ou l’attaquant entre l'adresse exemple www.monsite/admin ou autre user.
les mots communs comme admin user jamais utilisé dans mon site.
le contrôle de l'authentification ( utilisateur - mp) se fait par du code PHP + requêtes préparées + desactivation de l'auto-completion.
le crypatge du mot de passe est en instance ( actuellement je me documente sur la meilleur méthode).
avant de continué est ce que je suis dans la bonne voie ? :?
06/11/2012, 13h43
grunk

Un peu de lecture : http://owasptop10.googlecode.com/fil...0%20French.pdf
06/11/2012, 13h59
redoran

Re; merci grunck génial :ccool:

salut ; suite a l'orientation de grunk voila le constat:
mon but été d'arrivé a une programmation sécurisée, ma démarche est la suivante:
mise en place d'un fichier .htaccess pour protégé les répertoires,
pour la protection de la chaine de connexion (PDO) , j'ai pas pus su faire ! :oops:
ligne de défense contre les dix risques de sécurité applicatifs web ( OWASP)

A1-injection sql:
contrôle stricte par PHP le nombre de caractères des champs du formulaire d’authentification,
utilisation des requêtes préparées,

A2 –Cross-Site Scripting (XSS):
script de vérification en PHP des paramètres de l'URL
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 <?php ..... // On définit le tableau contenant les pages autorisées // ---------------------------------------------------- $navok = array('bord' => 'bord.inc.php', 'dec' => 'aff.inc.php', 'anal' => 'anal.inc.php', 'mp' => 'mp.inc.php', ); // On teste que le paramètre d'url existe et qu'il est bien autorisé // ----------------------------------------------------------------- if ( (isset($_GET['page'])) && (isset($navok[$_GET['page']])) ) { $page = htmlentities($_GET['page']); include($navok[$page]); // Nous appelons le contenu central de la page } else { // Page par défaut quant elle n'existe pas dans le tab include('bord.inc.php'); }
A3 -Violation de Gestion d'Authentification et de Session:
l'attaque par force brute pousse le serveur a généré des erreurs , ces dernières seront exploités par le hakers.
afin de paliers a ces attaquent ; jai realisé en php un script de tentative d'accés en 3 essais.
génération de messages d'erreurs générique " erreurs authentification...",

A4-Références directes non sécurisées à un Objet:
contrôle stricte par PHP le nombre de caractères des champs du formulaire d’authentification,
utilisation des requêtes préparées,

A5 -Falsification de requête intersite(CSRF):
surveillance des URL

A6-Mauvaise configuration Sécurité:
concerne le serveur et les applications installées,

A7-Stockage Cryptographique non Sécurisé:
pour le mot de passe je cherche toujours une bonne méthode de cryptage réversible.

A8 -Manque de Restriction d’Accès URL:
même solution que A2

voila je suis arrivé a ce niveau , c'est tous ce que j'ai pus faire

08/11/2012, 08h45
grunk

A2 : XSS

Ce n'est pas suffisant, tu dois également échapper tout ce qui est afficher sur une page (htmlentites ou htmlspecialchars).
Sinon un utilisateur s'enregsitre avec <script>alert('xss')</script> comme login et dès que son pseudo sera afficher sur le site , cela exécutera le code.

A5 : CSRF

Insuffisant également. Tu dois mettre en place un système de token qui permet d'être certains qu'une requête viens bien de ton site.
Par exemple pour un formulaire :
- A l'affichage du formulaire , générer un token que tu place en session et dans un champs hidden du formulaire
- Au traitement du formulaire , tu vérifie que le token reçue par get ou post correspond à celui en session et que sa durée de vie n'est pas expirée.

Tu peux voir un exemple de classe gérant celà ici : https://github.com/grunk/Pry/blob/ma...oken.class.php
un exemple d'utilisation dispo là : http://pry.oroger.fr/doc/ (choisir Util => token dans le menu)
08/11/2012, 13h08
redoran

salut ; grunk

Citation:

Ce n'est pas suffisant, tu dois également échapper tout ce qui est afficher sur une page (htmlentites ou htmlspecialchars).

là tu veut dire les données issues de l'utilisateur et non de la BDD !

Citation:

Sinon un utilisateur s’enregistre avec <script>alert('xss')</script> comme login et dès que son pseudo sera afficher sur le site , cela exécutera le code.

ici supposant que le champs du formulaire support 30 ou 40 caractères cela n'aide pas le haker a faire entré un code malicieux dans la BDD.

dans ton exemple : une fenêtre sera affichée , est ce que le faite de limité le nombre de caractère est suffisant de faire barrière ?
08/11/2012, 13h28
grunk

Citation:

Envoyé par redoran

salut ; grunk

là tu veut dire les données issues de l'utilisateur et non de la BDD !

Non toute les données quelque soit leur provenance

Citation:

Envoyé par redoran

ici supposant que le champs du formulaire support 30 ou 40 caractères cela n'aide pas le haker a faire entré un code malicieux dans la BDD.

dans ton exemple : une fenêtre sera affichée , est ce que le faite de limité le nombre de caractère est suffisant de faire barrière ?

Non , dans 40 caractère avec un eval et du cryptage on te faire tenir une fonction complète. Le nombre de caractère n'a rien d'une mesure de sécurité.
08/11/2012, 13h55
redoran

Re ,

Citation:

Le nombre de caractère n'a rien d'une mesure de sécurité.

même si le contrôle est du coté serveur (PHP) !
08/11/2012, 14h05
grunk

Oui , même si le contrôle est coté PHP. Toutes données affichées doit être échappées.
08/11/2012, 14h06
redoran

Ok ;
j'ai vue dans le lien pour les token que vous utilisé :

Code:

$token = hash('sha1', uniqid(rand(), true));

pour la protection et a titre d'information ( texte repris intégralement Guillaume Harry):
Citation:
.....Il ne faut pas utiliser d’algorithme de chiffrement ou de hachage faible, tels que MD5 ou SHA1 ni tenter de créer son propre algorithme. Il faut utiliser des algorithmes reconnus et éprouvés tels AES-256, RSA et SHA-256. Pour des raisons de capacité de calcul, l’ANSSI recommande que la taille minimale des clés symétriques utilisées jusqu’en 2020 soit de 100 bits et de 128 bits au-delà de 2020......
08/11/2012, 14h08
grunk

Le but ici , c'est juste de générer une chaîne aléatoire , pas de garantir la sécurité d'une données.
08/11/2012, 14h12
redoran

excuse de ta voir embêté;

Citation:

A l'affichage du formulaire , générer un token que tu place en session et dans un champs hidden du formulaire
- Au traitement du formulaire , tu vérifie que le token reçue par get ou post correspond à celui en session et que sa durée de vie n'est pas expirée.

le haker ne risque pas de piraté la session et le token.
08/11/2012, 14h28
grunk

Si tu as un hack de session et de token on est plus dans le CSRF. Un token csrf sert juste à s'assurer que la personne qui soumet les données est la même que celle qui à demander l'affichage du formulaire.

Ok très bien .
je reviens a la protection de la chaine de connexion:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 
<?php
// On se connecte à la bdd
try
{
			$PARAM_hote='localhost'; // le chemin vers le serveur
			$PARAM_nom_bd='moi'; // le nom de votre base de données
			$PARAM_utilisateur='root'; // nom d'utilisateur pour se connecter
			$PARAM_mot_passe=''; // mot de passe de l'utilisateur pour se connecter
			// connexion marche trés bien avec affichage de msg erreure
 
		// Options de connection
			$options = array
						(
							PDO::MYSQL_ATTR_INIT_COMMAND    => "SET NAMES utf8" ,  // indiquer à MySQL que echanger nos données en UTF8.
							PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION , 
							PDO::ATTR_PERSISTENT => true
						);
 
 
        $cbd = new PDO('mysql:host='.$PARAM_hote.';dbname='.$PARAM_nom_bd, $PARAM_utilisateur, $PARAM_mot_passe , $options  );
}
 
catch(PDOException $e)
{
        echo 'Une erreur de connexion est survenue !'; $e->getMessage();
        die();
}
 
?>

comment protégé la chaine ?

08/11/2012, 15h57
grunk

J'ai jamais protégé une chaine de connexion. Si le mec à accès à ton fichier , il à de toute manière accès à tous le reste.

Au mieux tu met tes identifiants dans un fichier de config non accessible depuis le web, comme ça si jamais l’interpréteur PHP venait à ne plus marcher les identifiants ne seront pas visible dans le code.
08/11/2012, 16h04
redoran

grunk:

Citation:

Au mieux tu met tes identifiants dans un fichier de config non accessible depuis le web, comme ça si jamais l’interpréteur PHP venait à ne plus marcher les identifiants ne seront pas visible dans le code.

ce que j'ai fait pour la protection:
dossier contenant fichier connexion : con.inc.php , protégé par .htaccess
je ne sais pas si c'est correct ou pas ?
08/11/2012, 18h29
RunCodePhp

Salut

Citation:

ce que j'ai fait pour la protection:
dossier contenant fichier connexion : con.inc.php , protégé par .htaccess
je ne sais pas si c'est correct ou pas ?

Je réagit sur ce point, sur ce que @Grunk a dit précédemment, et du point A2 (–Cross-Site Scripting (XSS)).

Mettre un .htaccess c'est nécessaire sans nulle doutes sur des fichiers sensibles tels que les identifiants de Bdd et autre.

Il y a tout de même un point qui n'a pas été évoqué (sauf erreur), c'est le comment l'ensemble du site Web est structuré sur le serveur (l'hébergeur on va dire).

Théoriquement, il ne faut jamais mettre de fichier sensible directement au niveau du virtualhost (ou le vhost), car celui-ci est (théoriquement) accessible par tout le monde via une simple URL.
Cela sous-entend qu'il faut normalement les placer en-dehors du vhost.

C'est à dire, admettons qu'on ait une structure (ou arborescence) comme ceci :
./espacedisque/www
- Et bien le répertoire "espacedisque" est la racine de notre espace disque.

- Le "www" est le répertoire du vhost, c'est à dire que la racine du vhost c'est lui ("www"), et il est associé au nom de domaine (admettons : domaine.com)
Donc si on saisi -http://www.domaine.com, le serveur Web (Apache par exemple) va rechercher un fichier index.php dans le répertoire "www" (et non pas "espacedisque".

Ce qui veut dire qu'il est impossible de remonter vers "espacedisque", donc de pointer (si on peu dire) sur celui-ci directement via une URL.

En somme, "espacedisque" est par nature (ou par défaut) inaccessible.

Là où je veut en venir, c'est que pour les fichiers comme "con.inc.php" seraient plus en sécurités s'ils étaient placés comme ceci par exemple :
./espacedisque/repPrive/con.inc.php

Par ailleurs, la réécriture d'URL est aussi un concept permettant de renforcer la sécurité, raison de plus si on adopte le même principe que je viens d'évoquer.

C'est à dire de créer et placer 1 seul et unique fichier Php comme index.php dans la racine du vhost (le "www), et c'est tout.
Ce index.php serait le FrontController, et c'est lui qui va "construire" les pages (générer le HTML par exemple) en recherchant (inclure) les autres fichiers Php/Html/et autres qui eux se trouveront en-dehors du vhost.

Pour exemple, les FrameWork adoptent souvent une structure comme ceci :
./espacedisque/www (le vhost)
./espacedisque/www/index.php (le FrontColler du vhost)
./espacedisque/application (tous les fichiers, comme les classes, en-dehors du vhost, on y trouve le MVC : Model/View/Controller entre autre)
./espacedisque/systeme (Le Core du FrameWork)

Donc la quasi totalité des fichiers se trouvent au final en-dehors du vhost, donc par nature inaccessibles, donc plus en sécurités (théoriquement bien sûr).
08/11/2012, 20h45
ABCIWEB

Citation:

Envoyé par redoran

grunk:
ce que j'ai fait pour la protection:
dossier contenant fichier connexion : con.inc.php , protégé par .htaccess
je ne sais pas si c'est correct ou pas ?

Oui c'est une solution. Sinon il y a la méthode décrite par RunCodePhp mais ce n'est pas toujours pratique à mettre en place.
En tous cas évite de mettre tes identifiants de connexion directement dans tes script php car tu multiplie les risques.
Autre conseil de bon sens, préfère quand c'est possible la méthode post à la méthode get.
Et puis surtout il ne faut pas faire transiter ses mots de passe en clair lors d'une authentification.
10/11/2012, 22h27
redoran

salut ; @ RunCodePhp : ça fait un bail ;)

Citation:

Il y a tout de même un point qui n'a pas été évoqué (sauf erreur), c'est le comment l'ensemble du site Web est structuré sur le serveur (l'hébergeur on va dire).

certe vous avez raison d'ou mon intervention ici http://www.developpez.net/forums/d12...t/#post6967105
je suis partie a partir de deux portes (URL et/ou le formulaire).

Citation:

Là où je veut en venir, c'est que pour les fichiers comme "con.inc.php" seraient plus en sécurités s'ils étaient placés comme ceci par exemple :
./espacedisque/repPrive/con.inc.php

merci pour cette orientation , cela ma, fait decouvrire que j'avais une fausse idée sur les serveurs particulièrement comment les applications web sont installées dans un serveurs dédie ou mutualisé !!! :oops:

Citation:

Par ailleurs, la réécriture d'URL est aussi un concept permettant de renforcer la sécurité

là vous parlé de URL rewriting .? ( surtout en bon francais )

Citation:

C'est à dire de créer et placer 1 seul et unique fichier Php comme index.php dans la racine du vhost (le "www), et c'est tout.

c'est ce que j'ai fait et les autres fichiers sont dans des sous repertoires exemple : SR-conx , SR-css , SR-JS.....

Citation:

Ce index.php serait le FrontController, et c'est lui qui va "construire" les pages (générer le HTML par exemple) en recherchant (inclure) les autres fichiers Php/Html/et autres qui eux se trouveront en-dehors du vhost.

ici je crois que c'est le modél MVC , le mien c'est formulaire qui donne accès aune page Tbord qui elle même appel d'autre pages en utilisant des liens.
je crois qu'il est temps de passé au modèle MVC.

Citation:

Pour exemple, les FrameWork adoptent souvent une structure comme ceci :........

le seul outils que j'utilise c'est le NOTEPAD++ ( tous fait a la main ).

Citation:

Donc la quasi totalité des fichiers se trouvent au final en-dehors du vhost, donc par nature inaccessibles, donc plus en sécurités (théoriquement bien sûr).

donc y 'a un doute !!! :roll:
@ ABCIWEB:

Citation:

Oui c'est une solution. Sinon il y a la méthode décrite par RunCodePhp mais ~~ce n'est pas toujours pratique à mettre en place~~.
En tous cas ~~évite de mettre tes identifiants de connexion directement dans tes script php~~ car tu multiplie les risques.

plus de détailles serai la bienvenu . merci

Voir 40 message(s) de cette discussion en une page